My Merchant Is on MATCH. Does That Mean They’re Declined?

Last Updated on June 16, 2026

With most processors, yes. A MATCH listing will trigger an automatic decline without anyone looking at the reason code or the circumstances. But that’s a process failure, not a verdict. The reason code matters, the circumstances matter, and what the merchant can document matters. Some MATCH listings have a clear and documented path to approval. Some genuinely don’t. The difference is in the details, and knowing which situation you’re in is what separates agents who place these merchants from agents who accept the first decline and move on.

What MATCH Actually Is

MATCH stands for Member Alert to Control High-Risk Merchants. It’s a database maintained by Mastercard that acquirers use to flag merchants and their principals when a merchant account is terminated for cause. When an underwriter runs a MATCH check on a new applicant, they’re searching to see whether the merchant or any of its signers has been listed by a prior acquirer.

A MATCH listing does not mean the merchant is a fraudster. It means a prior acquirer decided to terminate the relationship and believed the circumstances met the reporting threshold. The reason code assigned to the listing tells you what you need to know.

There are 14 reason codes. Most are hard closes. A handful have legitimate paths forward. Knowing which is which lets you tell a merchant immediately whether it’s worth pursuing rather than putting them through a document collection process that goes nowhere.

Who Actually Runs the MATCH Check and When

This is worth understanding clearly, because agents often assume they’re responsible for surfacing this information.

The MATCH check is run by the acquirer’s underwriting team as a standard internal step on every submission. Agents don’t run it, merchants don’t self-report it, and you don’t need access to the MATCH database to submit a deal. You submit the application and supporting documents, and the underwriter runs the check on their end as part of the review process.

That has a practical implication: you may not know your merchant is on MATCH until underwriting reports back. That’s normal. Merchants don’t always know they’ve been listed, especially when a prior processor terminated them for cause without communicating clearly about what was filed. And even merchants who know they were terminated don’t always know whether the termination generated a MATCH entry, or under which reason code.

What this means for how you approach the submission: don’t delay submitting while trying to pre-screen for a MATCH listing you have no way to verify independently. Submit the deal with the complete document package, let underwriting run the check, and work with whatever comes back. If a listing surfaces, the reason code and the documentation available to address it are the next conversation, not something you needed to solve before the application went in.

How Payment Processors Actually Handle MATCH Merchants

Here’s the honest industry reality: most processors decline any MATCH hit automatically, without reviewing the reason code or the circumstances. The check runs, a listing surfaces, and the application is declined. No conversation, no documentation request, no evaluation of whether the underlying issue has been resolved. The decline is the process.

That approach is defensible from a pure risk management standpoint. MATCH exists because a prior acquirer believed something went wrong badly enough to file a report. Declining categorically means never inheriting someone else’s problem. For processors managing high volumes of applications with limited underwriting bandwidth, it’s the path of least resistance.

The consequence for agents is that a MATCH listing (even one with a clear path forward) ends the conversation before it starts at most places you’d submit. The merchant hears “declined” and assumes the listing is permanent. Many agents accept that conclusion and move on. That’s often the wrong call.

What a more considered approach looks like

Acquirers who work through MATCH situations rather than reflexively declining them do it through reason code evaluation. The 14 reason codes are not equivalent. Some reflect conduct so serious (fraud, laundering, data compromise, collusion) that no documentation or changed circumstances makes the merchant workable. Others reflect problems that are real but addressable: excessive chargebacks that have since been remediated, a standards violation the merchant has corrected, an identity theft the true applicant can document.

The distinction matters because the path forward, if one exists, is entirely different depending on the code. A Reason Code 04 listing turns on current processing metrics. A Reason Code 14 listing turns on whether the applicant can produce contemporaneous records of the theft. Treating them the same, either by declining all of them or by pursuing all of them with the same documentation approach, misses the point entirely.

The practical implication for agents: when a merchant surfaces a MATCH listing, the first question isn’t “is this a declined deal?” It’s “what’s the reason code?” That single answer determines whether there’s anything worth pursuing, what documentation would actually move the analysis, and how long the path is likely to take. An acquirer who skips that question and defaults to a decline is giving you an answer that isn’t informed by the facts.

What you should expect from the acquirer you’re working with

A well-structured underwriting process on a MATCH deal should tell you the specific reason code, whether an exception path exists under their policy for that code, what documentation is required to pursue it, and what the authorization process looks like if the documentation supports moving forward. That information lets you have a real conversation with the merchant rather than delivering a generic decline.

If you’re getting a decline on a MATCH listing without any of that context, it’s worth asking whether the reason code was actually evaluated or whether the system just declined on the hit. The answer will tell you a lot about whether that acquirer is built to help you place the harder deals.

The Reason Codes, Sorted by What They Mean for Boarding

Hard Declines — No Exception Path Under Standard Policy

These reason codes reflect conduct that no reserve, pre-fund, or conditions package can address. If your merchant is listed under any of the following, the deal is not workable under standard policy:

• Reason Code 01 — Account Data Compromise. The merchant’s systems were involved in a card data breach.
• Reason Code 02 — Common Point of Purchase. The merchant’s account was identified as the common source in a fraud pattern.
• Reason Code 03 — Laundering. The merchant processed transactions on behalf of an undisclosed business or individual.
• Reason Code 05 — Excessive Fraud. Fraud-to-sales ratio exceeded card brand thresholds.
• Reason Code 08 — Collusion with Fraud. The merchant knowingly participated in fraudulent activity.
• Reason Code 09 — Bankruptcy / Insolvency / Dissolution. Self-explanatory.
• Reason Code 11 — Noncompliance with Card Network Rules. Ongoing, unresolved violations of card brand operating rules.
• Reason Code 12 — Merchant Fraud Performance. Fraud metrics exceeded card brand program thresholds.
• Reason Code 13 — Questionable Merchant Activity. Suspicious activity that didn’t fit a cleaner category.

If your merchant is listed under one of these, the honest answer is that there’s no standard path at most acquirers. Be direct with the agent about that early rather than letting them collect documents for a deal that won’t move.

Codes with a Potential Path Forward

Three reason codes have exception paths that are worth pursuing with the right documentation. None of them are automatic approvals. All of them require internal sign-off and bank-level authorization before any commitment is made to the agent. But they’re real paths.

Reason Code 04 — Excessive Chargebacks

This is the most common listing agents encounter, and it’s the one most frequently misunderstood as a permanent bar. It isn’t.

A Reason Code 04 listing means the merchant’s chargeback ratio exceeded the card brand’s threshold at some point during their prior processing relationship, and the prior acquirer terminated them for it. That’s meaningful context. It’s not a verdict.

The question underwriters are actually asking is: does the problem still exist?

A merchant who had a chargeback problem 18 months ago, identified the root cause, made specific operational changes, and has since maintained clean metrics has a genuine case to make. A merchant who had a chargeback problem 18 months ago and hasn’t changed anything has a very different situation, regardless of how well they can articulate what happened.

What resolves a Reason Code 04:

• Root cause and remediation. What specifically drove the elevated chargebacks, and what specific operational changes were made in response. This doesn’t need to be an elaborate narrative — it needs to be credible and specific. “We switched from a manual refund process to automated same-day refunds and enrolled in Ethoca alerts” is useful. “We addressed the issues” is not.
• Current processing statements, minimum three months. This is the controlling evidence. The statements show whether the problem is actually resolved or whether the merchant is describing a fix they haven’t fully implemented. If the most recent months show clean metrics, generally under 1% count-based, that’s the case for approval. If current ratios are still elevated, the remediation story doesn’t hold regardless of how well it’s told.
• Evidence of chargeback prevention tools. Enrollment in alert services like Ethoca or Verifi, use of 3D Secure, enhanced fraud screening, or similar tools demonstrates that the operational changes are structural, not cosmetic.

One important note: don’t ask the merchant to write a narrative explanation of why chargebacks were elevated. That’s self-serving and unverifiable. The ask is documentation — the statements that show current metrics, the evidence of the tools in place. The numbers either tell the story or they don’t.

Reason Code 10 — Violation of Card Network Standards

A Reason Code 10 listing means a prior acquirer determined the merchant violated card brand operating rules and terminated the relationship on that basis. This one is more fact-specific than Reason Code 04, and the exception path is narrower.

The question here is whether the violation finding was wrong, whether it’s been remediated, or both.

What gives this code a path forward:

• A legal opinion from qualified counsel explaining either why the violation finding was factually or legally incorrect, or how the merchant has brought their operations into compliance.
• Supporting documentation backing the legal analysis.
• Current compliance documentation showing the merchant’s operations today.

The legal opinion has to pass a reasonability test — it’s not a rubber stamp. A credible legal argument from experienced payments counsel carries weight. A letter saying “we didn’t violate anything” without substantive legal analysis doesn’t move the needle.

This path is more time-intensive than Reason Code 04, and it genuinely requires legal counsel involvement. Be clear with merchants about that upfront so they understand what they’re committing to before the process starts.

Reason Code 14 — Identity Theft

Reason Code 14 is the most complicated listing to evaluate, because it’s genuinely ambiguous in a way the other codes are not.

On one hand, it could mean exactly what it says: the applicant’s identity was stolen, someone used their information to open a fraudulent merchant account, and the listing reflects that fraud — not anything the applicant did. Legitimate identity theft victims end up on MATCH through no fault of their own and deserve a path back to processing.

On the other hand, Reason Code 14 is sometimes used strategically. An operator who opened and ran a fraudulent merchant account under a stolen identity may present themselves as the victim when applying at the next acquirer.

The framework for navigating this starts with one non-negotiable step: identity verification first, victim determination second. Before anything else, before reviewing documentation, before evaluating the victim claim, the person applying needs to be confirmed as who they say they are through government-issued ID and SSN validation. If identity can’t be confirmed, the conversation ends there regardless of what documentation is offered.

If identity is confirmed, the victim path requires:

• A police report or FTC identity theft report filed by the confirmed applicant.
• Documentation showing the applicant was not the operator of the terminated account.
• Any correspondence with the listing acquirer or card brands.

The critical detail here is timing. Legitimate identity theft victims produce a paper trail at the time of the theft — not years later when they’re applying for a merchant account and need something to show an underwriter. A police report, an FTC complaint, bank fraud claims, credit bureau fraud alerts, correspondence with the listing acquirer disputing the account — these records exist if the person actually experienced identity theft when the listing was created.

If a merchant claims identity theft but cannot produce any contemporaneous documentation — and by “contemporaneous” we mean records created at or near the time of the original listing, not explanations created now — that absence is itself the answer. The documentation either exists or it doesn’t. A narrative explanation of what happened doesn’t substitute for records that should exist if the story is true.

When contemporaneous documentation does exist and identity is confirmed, the listing is effectively disregarded and the deal proceeds through normal underwriting.

What the Exception Path Actually Requires

For any MATCH listing where an exception path exists, one thing doesn’t change: no commitment is made to the agent until internal authorization is confirmed.

Exception path deals require bank-level approval and, depending on the circumstances, executive sign-off. That’s not a formality — it’s the actual decision point. An agent who’s been told “this looks workable” before that authorization comes back has been told something that isn’t yet true. Be careful with language in these situations. The path is worth pursuing; the commitment comes after the internal review, not before.

When you’re talking to an agent about a MATCH exception path, be explicit that the outcome is subject to bank approval and that specific documentation is required before any decision can be made. That’s not discouraging — it’s the information the agent needs to set accurate expectations with the merchant.

What Never to Ask a MATCH Merchant

One mistake agents and processors make consistently: asking the merchant to write a narrative explanation of the MATCH listing.

Don’t do this. A written explanation of the circumstances is self-serving and unverifiable. Every merchant is going to tell you their situation was an anomaly, a misunderstanding, a prior processor acting unreasonably, or circumstances outside their control. Some of those stories are true. You have no way to know which.

The documentation-specific ask is what actually moves the analysis: processing statements showing current metrics, contemporaneous records for an identity theft claim, legal opinion for a standards violation. Those either establish the case or they don’t. A narrative around the MATCH listing doesn’t add to it.

The One Thing That Changes Everything

For Reason Code 04 — the most common listing agents deal with — the current processing statements are the whole case. Not the explanation of what happened. Not the description of changes made. The actual numbers from the last three months.

If those statements show clean chargeback metrics and the operational changes described are credible and documented, the listing is workable. If current metrics are still elevated, no amount of good explanation changes the outcome. The statements tell the story. Everything else is context.

Frequently Asked Questions

Does a MATCH listing automatically appear when I submit a merchant? The acquirer’s underwriting team runs the MATCH check internally on every submission — you don’t trigger it manually and the merchant doesn’t self-report. As covered above, you may not know a listing exists until underwriting reports back, and that’s expected. The right move is to submit a complete package and work with what the check returns rather than trying to pre-screen for something you can’t independently verify.

Can a MATCH listing ever be removed? Yes, under specific circumstances. The listing acquirer can request removal if the listing was made in error. Mastercard also has a process for disputing inaccurate listings. This is a longer-term path that doesn’t resolve the immediate boarding question, but for merchants with incorrectly applied listings, it’s worth knowing. The appropriate contact is the acquirer who placed the listing.

If my merchant’s principal is on MATCH but the entity isn’t, does that affect the application? Yes. MATCH searches are run against both the merchant entity and individual signers. A principal listed on MATCH from a prior business follows them to any new entity they sign for. The reason code and circumstances are evaluated the same way regardless of whether the listing is on the entity or the individual.

My merchant was listed for excessive chargebacks three years ago. Does the age of the listing matter? Age matters less than current state. A three-year-old listing with current clean metrics is a better situation than a six-month-old listing with metrics that are still elevated. The exception path for Reason Code 04 turns on whether the problem has been resolved, not on when it occurred.

My merchant has a MATCH listing and elevated current chargebacks. Is there any path? Under standard policy, no. The exception path for Reason Code 04 requires current clean metrics as the controlling evidence. If current ratios are still elevated, the remediation claim doesn’t hold. The path opens when the merchant can demonstrate — through statements — that the problem is actually resolved.

Should I tell my merchant they’re on MATCH before submitting? That’s a relationship judgment call. What’s useful to know: the MATCH check is a standard part of underwriting that runs on every submission. If your merchant knows they were terminated for cause by a prior acquirer, they likely know there’s a listing. Having the conversation about what documentation might be relevant — processing statements, prior-period records — before submission is often more productive than waiting for underwriting to surface it.

Back