How to Get Off the Mastercard MATCH List
It’s an unfortunate truth that MATCH tends to show up when a business is trying to move forward. A new processor application gets declined without much detail, or a new MID is approved, then paused during review. An existing relationship might suddenly tighten overnight, with reserves, rolling holds, or a blunt “we can’t continue to process this account,” with no rhyme or reason.
In many cases, the underlying issue is not a single transaction or a sudden fraud spike, but a historical issue that has gone unnoticed. Mastercard’s MATCH database, or MATCH list, is designed to preserve information about merchants that were terminated by an acquirer, so future acquirers can see that termination history during underwriting and risk reviews.
Getting “off the MATCH list” is a common search phrase because it sounds like a standard appeals process. Unfortunately, the reality of achieving this is extremely procedural, and the odds are stacked against those who end up appearing on it.
What the MATCH List is Really Used For
MATCH is not a monitoring program, nor is it a warning letter; it is a shared termination file. When an acquirer terminates a merchant relationship under certain conditions, the merchant can be added to MATCH with a reason code and identifying data. Other acquirers then see this when they search the file as part of onboarding and periodic reviews.
The problem is that MATCH is a long-term pain point for merchants who wind up on the list. It’s designed to last for years, not weeks or months, with MATCH Pro records potentially being retained for up to five years. That long retention window exists because it solves a problem the ecosystem cares about by reducing the chance that a terminated merchant can quietly reboard somewhere else with the same underlying issues.
That does not mean a listed merchant can never process cards again, but it does mean that “getting off MATCH” is not a quick form submission for most reason codes. A workable plan starts with the record you are actually dealing with, rather than the record you assume is there.
Step One: Confirm What is On The Record
Trying to fix MATCH blind is where time gets burned. The first goal is to establish some form of clarity. Three important questions need to be asked and answered: who added the record, what reason code was used, and which identifiers are attached.
Identify the Listing Acquirer and the Reason Code
Start with the acquirer that terminated the account, even if the relationship ended badly. Mastercard’s merchant-facing guidance expects the listing acquirer to be identifiable and the reason code to be available to the merchant or to a subsequent acquirer. In practice, processors vary in how helpful they are, but this is still the cleanest path to the facts.
If the termination happened through a chain — e.g., a payment facilitator, ISO, or sub-merchant arrangement — work backwards until you reach the party that can see the actual MATCH data. The aim is to obtain:
- the reason code
- the date of listing
- the legal entity and DBA listed
- key identifiers (address, URL, phone, tax ID, where applicable)
Those identifiers are important because MATCH is not a “name-only” database. Acquirer searches can use business and principal details, which is why simply reapplying under a new DBA rarely behaves the way merchants expect.
Check Whether the Record Describes the Correct Entity
MATCH errors do happen; it’s not an infallible system. Records can be duplicated, attached to the wrong legal entity, or populated with outdated identifiers. That does not mean correction will be easy, but it does mean it is worth verifying the basics before you plan around a five-year wait.
A practical way to approach this is to treat it like underwriting preparation. Make a simple internal file containing your legal entity documents, historical processing relationships, website history (if relevant), product/service descriptions, and anything else a risk team will use to reconcile identity. This same file will be useful later when you are trying to board again.
Why the Reason Code is Crucial
Merchants often talk about MATCH as though it is one condition. It is not. MATCH reason codes cover very different termination drivers, and the removal options differ significantly. Once the reason code is known, however, things become a lot clearer.
Excessive Chargebacks and the Math Behind It
One of the most common pain points is excessive chargebacks. Mastercard’s published definition for the excessive chargebacks reason code uses a three-month lookback and combines a percentage threshold with a dollar threshold. In Mastercard’s Merchant Edition of the rules dated August 2025, the threshold is described as chargebacks exceeding 1.5% of Mastercard sales transactions for the month, and $5,000 or more in total chargebacks across the previous three months.
That’s an important detail because it changes what an acquirer needs to see before they will take a remediation story seriously. “We will try harder” does not address a ratio problem. A credible plan is built on numbers, timing, and controls.
PCI DSS Noncompliance is a Different Category of Problem
PCI DSS noncompliance is one of the few areas where Mastercard describes a structured path to request removal once compliance is restored. In the same Mastercard guidance, removal under the PCI reason code requires documentation that goes beyond a merchant stating they are now compliant. It includes an acquirer attestation and validation by a Mastercard-certified forensic examiner, with an option for the merchant to submit a request directly if the acquirer will not. This reason code is still serious, but it is procedural in a way that other codes are not. The path is clearer because the remediation can be documented in a way that maps cleanly to network requirements.
Other Codes Can Imply Deeper Trust Issues
Some reason codes, such as transaction laundering or illegal transactions, tend to trigger stronger reactions from underwriting teams because they suggest intentional behavior rather than oversight. The removal conversation in those cases is rarely about paperwork, but more about whether a provider is willing to take on the reputational and compliance risk of reboarding the business at all.
Two Situations Where Early Removal Might Be Possible
Most MATCH listings will not be removed early. It’s as simple as that, and we’re not going to gloss over that fact. That said, two categories tend to offer the most realistic path to removal before the record naturally ages off.
Incorrect Listings and Administrative Errors
If the listing is factually wrong, then correction or removal is possible. “Wrong” in this context can mean the wrong legal entity, a duplicate record, or a reason code that does not match the termination circumstances. The best approach for merchants is to make the removal request easy to evaluate. Provide documentation that demonstrates identity, shows the processing relationship, and explains why the record does not apply as listed.
PCI Remediation for Reason Code 12
PCI-based removals are documentation-heavy, with the requirements described in Mastercard’s rules focusing on proving the remediation path. A workable plan typically includes: completing the required validation, obtaining the required attestations, and presenting the evidence in the format expected by the acquirer or Mastercard’s process. If the business has been breached or card data was exposed, expect this to be more involved.
Instead of Removal, Focus On Reboarding Credibility
A MATCH record does not automatically end card acceptance forever, but it does mean the next provider will ask tougher questions.
Excessive chargebacks, for example, are rarely fixed by a single change. They are reduced through a chain of improvements: clearer policies, better descriptors, predictable billing, faster refunds, and customer support paths that intercept disputes before they become chargebacks. When those controls exist, underwriting becomes a conversation about risk management rather than a rerun of the termination. Acquirers also want to see the work that has gone into improving operations and processes, and that usually means being able to show:
- a dispute and refund policy that matches how you actually sell
- evidence that refunds are processed quickly and consistently
- proof of delivery or service completion, where applicable
- customer contact records that demonstrate accessible support
- internal reporting that tracks disputes by root cause, not only by totals
This is also the stage where honesty helps. A new acquirer will see the MATCH record anyway. Being direct about what caused the termination and what changed is generally more productive than trying to minimize it.
ChargebackStop Can Help Reduce Termination Risk
MATCH, ultimately, is a consequence. The practical way to avoid living under it is to reduce the conditions that can lead to termination in the first place, especially the operational breakdowns that inflate chargebacks and complaints.
ChargebackStop’s platform is built around this. Pre-dispute tools such as Ethoca Alerts and Verifi RDR are designed to resolve disputes before they become chargebacks. Resolution Rules automate consistent decision-making at scale, which matters when case volume rises and teams start making inconsistent calls under pressure.
Meanwhile, fraud notifications (TC40/SAFE) add visibility into fraud patterns that can distort portfolio performance, and the Transaction Portal supports customer self-service, so more issues are resolved before escalation.
Keep in mind that these tools do not “remove” a MATCH record. What they do is help merchants build the processing history that underwriters want to see when risk is reassessed: fewer preventable disputes, tighter response workflows, and reporting that connects outcomes to causes.
ChargebackStop helps teams reduce preventable disputes, standardize resolution decisions, and maintain clear visibility across alerts, chargebacks, and fraud data, so risk discussions are grounded in evidence rather than assumptions. Book a demo to see how ChargebackStop supports the operational controls underwriters expect to see before trust is rebuilt.
