MATCH, formally MATCH Pro, Mastercard Alert To Control High-risk Merchants, is a database that Mastercard requires acquiring banks to check before signing a new merchant agreement. If a previous acquirer terminated a business under one of Mastercard's specific reason codes, that acquirer must add a record to MATCH Pro, and current rules require it within 5 days of the termination decision (Mastercard Developer Portal, MATCH Pro documentation).
For merchants, the practical concern is not only the record itself, but how it affects new merchant account approval and future payment processing. A MATCH list placement does not mean an automatic, permanent ban. A new acquirer sees the reason code, assesses the risk itself, and decides independently whether to onboard the merchant. In practice, most self-serve processors decline anyway rather than take on that manual review.
This article covers how merchants actually end up in MATCH, what the reason codes mean in practice, when a record can be disputed or removed, and where alternative payment rails like crypto settlement help, and where they do not touch the record itself.
MATCH Pro is a merchant verification database, not an automatic ban
Before signing a merchant agreement, a Mastercard acquirer is required to submit an inquiry to MATCH Pro with the merchant's information and its principal owners. MATCH Pro searches for possible matches against records added by other acquirers over the past five years and returns whether it found an exact or phonetic match (Mastercard Developer Portal, MATCH Pro documentation).
Mastercard's own rule is explicit: MATCH Pro exists so an acquirer can develop, assess and review risk information "prior to entering into a Merchant Agreement," not so it can auto-reject on sight. An acquirer that finds a match still has to make its own risk determination. What actually happens at most mainstream processors is different: since they run mass, automated onboarding, a MATCH hit is treated as a hard stop rather than something a human underwriter reviews case by case.
In other words, payment processors check MATCH as part of underwriting, but the result is risk information, not a mandatory rejection notice. The problem is that many credit card processors are not built to review high risk accounts manually.
A MATCH listing requires a specific reason code, not just a high-risk category
Operating in an elevated-risk niche is not, by itself, a reason for listing. A record only appears after an acquirer terminates a merchant agreement and the termination meets one of Mastercard's defined reason codes. The issue is account termination under card network rules, not simply that a merchant looks like a questionable merchant or belongs to a high-risk sector.
The list includes 14 codes in total, and the ones that come up most often for high-risk merchants are:
| Code | Reason | What triggers it |
|---|---|---|
| 03 | Laundering | Presenting false sales records to the acquirer or otherwise misrepresenting transactions |
| 04 | Excessive chargebacks | Exceeding both a 1% chargeback ratio and $5,000 in total chargeback amounts in a single calendar month, with both conditions required together |
| 05 | Excessive fraud | An abnormal rate of suspected fraud or fraudulent transactions relative to sales volume |
| 10 | Violation of standards | Exceeding transaction limits, running prohibited transactions, or breaking PCI-related guidelines |
| 12 | PCI DSS noncompliance | Failing to meet Payment Card Industry Data Security Standard requirements |
| 13 | Illegal transactions | Processing payments for goods or services that violate local, state or federal law |
| 14 | Identity theft | The merchant's or an owner's identity was unlawfully used to open or run the account |
(Global Legal Law Firm, Mastercard MATCH List Codes guide)
MATCH is not meant to be used as leverage in a disputed debt or a commercial disagreement. A specific reason code, tied to one of these defined grounds, is required for a listing to be valid.
A MATCH record stays for five years and can surface during any new onboarding
A MATCH Pro record covers a five-year lookback: when an acquirer runs an inquiry, the system searches records added by any acquirer over the past five years (Mastercard Developer Portal, MATCH Pro documentation). In practice, this means a MATCH listing typically lasts five years unless it qualifies for one of the narrow removal routes.
Changing the brand, domain or legal entity does not solve this on its own, because MATCH Pro matches on the underlying data: principal owners, addresses, phone numbers, emails, tax identifiers, MCC, website URL, contract and termination dates, and the reason code itself.
MATCH Pro is not a public search tool. Access is limited to authorized acquirers and certain service providers, so a merchant usually cannot look themselves up directly. For the merchant, the practical effect is that every new onboarding attempt runs this check before an agreement is signed, whether or not the merchant is aware a MATCH list entry exists.
A record can only be removed in two narrow cases
A MATCH record cannot be removed just because a business changed its practices or found a new provider willing to work around it. There are two defined removal paths before the five-year period runs out.
| When removal is possible | What needs to be shown |
|---|---|
| The record was added by mistake | Documentation proving the listing was inaccurate or did not apply |
| Code 12: PCI DSS noncompliance | Restored PCI DSS compliance, confirmed by the relevant parties |
If the record is accurate and the underlying reason genuinely existed, there is no general "remove after fixing" mechanism outside of these two paths. The record stands until the five-year period ends.
For that reason, MATCH list removal usually starts with direct communication with the acquirer that filed the record. A merchant can request removal only if the listing was wrong, unsupported, or eligible under the PCI DSS noncompliance path.
Alternative payment rails reduce dependency on card acquiring, but they do not touch the MATCH record
MATCH restricts access specifically to card acquiring, not to every way of accepting payment. Crypto processing, local alternative payment methods (APMs) and bank transfers can operate as separate rails that do not run through the card networks MATCH governs.
What an alternative rail actually provides:
- Reduced dependency on card acquiring for revenue.
- A way to keep accepting payments while a MATCH issue with a card processor is being resolved.
- Fewer single points of failure in the overall payment stack.
- Less dependency on standard payment processing if card payments are blocked or unstable.
One clarification on crypto specifically: pure wallet-to-wallet crypto settlement does not run through card network merchant category codes at all, since no card transaction occurs. Where a card is used to fund a purchase, such as a card-to-crypto on-ramp, that funding leg still needs its own classification and approval. Crypto and other quasi-cash businesses are generally coded under MCC 6051, not MCC 7995, which is reserved specifically for gambling and betting transactions (PayCompass, MCC 6051 guide). Conflating the two is a common source of misclassification, and misclassification is itself a compliance issue, not a workaround.
But an alternative rail has real limits:
| What it does not solve | Why |
|---|---|
| Does not remove the MATCH record | The record stays inside Mastercard's system regardless of what other rails a merchant adds |
| Does not remove KYB/AML requirements | A new provider still runs its own onboarding and due diligence |
| Does not fix the underlying reason for termination | Chargebacks, fraud, PCI gaps or standards violations still need to be addressed on their own |
An alternative rail makes sense as diversification. It can reduce risk exposure to one acquiring relationship, but it should not be treated as a way to hide termination history from a new provider, since MATCH Pro's matching logic is built specifically to catch that.
Finassets adds a crypto settlement channel without erasing a MATCH record or its cause
A MATCH record lives inside Mastercard's card-network infrastructure. Nothing on the crypto side removes it, restores compliance, or resolves the chargeback or fraud pattern that caused the termination in the first place.
What a crypto channel can do is give a business a way to keep accepting payments through a rail that does not depend on the card acquirer relationship MATCH governs. That is one reason some high-risk verticals have added crypto settlement alongside card processing rather than treating it as optional (TechBullion, High-Risk E-Commerce Payment Solutions Guide, 2026).
Finassets is a Panama-registered B2B crypto payment infrastructure provider supporting iGaming operators licensed under recognised regimes (Curaçao, Anjouan, Kahnawake, and others) and eCommerce merchants. What it provides:
- Structured Checkout: a unique address is generated for each payment session, and the transaction is automatically linked to the order or deposit it belongs to.
- Partial payments: a single deposit can be completed with several transfers across different assets, and the session stays open (it does not reset) until the full amount is covered.
- Auto-Convert: automatic conversion of crypto into whichever asset or stablecoin the merchant sets rules for, with a conversion fee applied to that operation and taken from the amount being converted.
- TRON Energy Saving System: pre-purchased Energy fixes the cost of a TRC20 transfer before confirmation, which can reduce the fee by up to 50%+ compared to the burn model, depending on Energy availability and network conditions, based on client results, with individual outcomes varying.
- Pricing: a progressive processing fee of 0.40% down to 0.20% by volume, fixed in the contract.
- Onboarding: 2-7 business days, subject to KYB and compliance review.
Important: the crypto rail is not a way around due diligence. Finassets runs its own KYB and compliance review on every merchant. It is a separate payment channel, not a mechanism for MATCH removal or for concealing the reason a previous account was terminated.
What changed in the last 12 months
Mastercard has been pushing acquirers off the legacy MATCH workflow and onto MATCH Pro's API and bulk-file system. Mastercard's own documentation states that under rule reference GLB 12773.1, all customers must migrate to the MATCH Pro API and bulk files, and acquirers who do not migrate are classified as Category C Noncompliant, which triggers standard compliance program assessments (Mastercard Developer Portal, MATCH Pro documentation).
The practical effect for merchants is speed: Mastercard states the API integration cuts the time associated with MATCH due-diligence activity and post-termination reporting from about one day down to a real-time response. That means both new listings and new-onboarding checks now move faster than they did under the older manual process.
Separately, card-network scrutiny of chargeback ratios generally has stayed tight through 2026, with both Visa's and Mastercard's monitoring programs continuing to enforce sub-2% dispute thresholds (HighRiskIntel, Visa & Mastercard Chargeback Thresholds Explained, 2026), which lines up directly with the specific 1% ratio built into MATCH reason code 04.
A MATCH record is rarely the actual problem. It is documentation of a problem, tied to a specific reason code, that happened at a specific acquirer. Figuring out which code applies and whether it was even added correctly determines whether the real fix is a formal dispute, remediation and time, or an additional payment rail while that gets resolved.
If you are evaluating a crypto settlement channel as part of that fix, or as a way to diversify away from a single card acquirer relationship, get in touch with Finassets.
Disclaimer: This article does not constitute legal or compliance advice. Consult qualified legal and compliance counsel for guidance specific to your MATCH listing, reason code and jurisdiction.
Author: Anastasia M., payments content, Finassets.
