MATCH Listings and MATCH List Removal

MATCH is a database published and maintained by Mastercard and governed by Mastercard’s Security Rules and Procedures (SPME).

MATCH Rules require acquiring banks to query the system before onboarding a merchant. If a merchant appears on MATCH, the application is typically declined. As a result, a MATCH entry functions as a gatekeeping mechanism within the card payment ecosystem, restricting access to merchant processing at onboarding.

Those requirements extend beyond onboarding. Many acquiring banks, particularly in higher-risk segments, conduct periodic MATCH queries as part of ongoing monitoring. When one provider adds a merchant to MATCH, the entry can affect existing processing relationships with other providers, resulting in account reviews, suspensions, or terminations across multiple accounts.

The effect is immediate and system-wide. A MATCH entry is an operational restriction on access to the card networks.

MATCH is often described as a blacklist. In practice, it is a rule-based merchant reporting system. The governing rules define when a merchant may be added, how the entry must be recorded, and what information must be included. An entry does not resolve whether those rules were followed, whether the assigned reason code is accurate, or whether the underlying conduct satisfies Mastercard’s standards.

How MATCH Entries Arise

A MATCH entry is tied to conditions defined by the applicable reason codes at the time of termination, irrespective of which party terminates the relationship. The relevant question is not who ended the relationship, but whether a MATCH-qualifying condition existed when the relationship ended.

Where that condition exists, MATCH Rules require the acquirer to add the merchant’s information to MATCH Pro within five calendar days of the earliest of three events: the acquirer’s decision to terminate the acquiring relationship, receipt of notice of termination by or on behalf of the merchant, or the acquirer becoming aware of a MATCH issue meeting one of the applicable reason codes.

In practice, MATCH entries arise in connection with account closures driven by internal risk determinations, chargeback or fraud monitoring programs, underwriting reversals, or platform-driven shutdowns. These decisions are often made quickly and with limited transparency, particularly in multi-party environments involving merchants, payment facilitators, processors, ISOs, and acquiring banks. 

Disputes arise where the identified condition does not satisfy the requirements of the assigned reason code, or where the entry reflects internal risk judgments rather than Mastercard-defined standards.

MATCH as a Gatekeeping System

MATCH operates as a gatekeeping layer across the payments ecosystem.

Because acquirers are required to query MATCH before onboarding, an entry affects not only the relationship in which it arose, but also the merchant’s ability to obtain replacement processing. Ongoing monitoring extends that impact to existing accounts, allowing a single MATCH entry to trigger broader disruption across multiple providers.

MATCH entries also extend beyond the merchant entity itself. The database records the merchant and the principal who signed the merchant application, along with identifying business information. As a result, an entry can affect not only a single account, but the ability of related entities or principals to obtain processing across multiple relationships.

At the same time, MATCH is not an adjudicative system. It records information submitted by acquiring banks and does not provide a built-in mechanism for merchants to challenge or appeal entries within the system. The rules expressly permit a MATCH merchant to contact an acquirer to request removal, and Mastercard states that legal counsel is not required to do so. In practice, however, correction or removal still depends on the reporting acquirer acting on that request.

This creates a structural imbalance. The consequences of a MATCH entry are immediate, while the process for correcting it depends on the entity that initiated it.

Inquiries, Matching Logic, and Retroactive MATCH

MATCH Rules require an acquirer to check MATCH Pro before signing an agreement with a merchant or enabling the merchant to accept transactions. The system does not search only for exact matches. It searches for exact, phonetic, and retroactive possible matches using merchant and principal information stored during the prior five years.

This matters because a merchant may not appear on an initial inquiry, yet still surface later. Under the retroactive inquiry process, if an initial inquiry does not return a possible match, a retroactive alert is generated if the merchant is entered into MATCH by another acquirer within 365 calendar days and had not previously been returned during that period. In that situation, the acquirer must determine whether additional investigation is appropriate and whether the merchant should be onboarded subject to other measures addressing the identified risk issues.

Retroactive MATCH reinforces the gatekeeping function of the system. The impact of a later entry may not be limited to future applications. It can also affect existing relationships if an acquirer re-runs MATCH as part of ongoing monitoring.

Reason Codes and Misapplied Standards

Each MATCH entry must be associated with a defined MATCH reason code corresponding to specific categories of conduct.

In many disputes, the issue is not whether underlying activity occurred, but whether that activity satisfies the requirements of the assigned reason code. Internal processor thresholds, generalized risk assessments, or monitoring categories are often treated as substitutes for Mastercard standards.

For example, excessive chargeback classifications require defined ratios and dollar thresholds over specified time periods. Entries based on internal “high risk” determinations or unsupported metrics may not meet those criteria. The same is true of other reason codes. The controlling question is whether the conditions required by the specific code were present at the relevant time, not whether a processor or platform viewed the account as too risky or otherwise undesirable.

A MATCH entry is therefore not determined by how the termination is characterized, but by whether the conditions required for the assigned reason code were present when the relationship ended.

Attribution and Responsibility

MATCH entries are formally submitted by acquiring banks, but in practice they are often initiated by processors, ISOs, or payment facilitators operating through the acquirer’s credentials.

As a result, the MATCH record typically reflects the acquirer’s ICA number rather than the identity of the service provider that made or drove the decision. This can obscure the source of the MATCH entry and complicate efforts to determine responsibility.

For example, a merchant may know that its acquiring relationship runs through Chase. But unless it knows the relevant ICA mappings, which are not publicly available, it may not be clear whether the decision was made through a particular sponsored provider operating under that relationship, such as Stripe or QuickBooks. The MATCH data may identify the ICA without identifying the service provider whose decision or recommendation actually led to the entry.

Merchants are therefore often directed among processors, platforms, and acquiring banks, with each attributing the entry to another. Identifying the reporting acquirer, the underlying decision-maker, and the applicable MATCH criteria is essential to addressing an entry.

Approach to MATCH Matters

MATCH issues require a focused, time-sensitive analysis grounded in Mastercard’s rules.

Because MATCH functions as a gatekeeping system and does not provide a direct dispute mechanism, the analysis centers on whether the entry satisfies the applicable standards, whether the assigned reason code is supported, whether the reporting acquirer complied with its obligations in submitting the entry, and whether retroactive matching or ongoing monitoring may affect other processing relationships.

These matters often proceed on an accelerated timeline, with the objective of restoring access to merchant processing while addressing the conditions that led to the entry.

Brad Cebeci handles MATCH list removal and access-to-processing matters as part of the firm’s payments practice, which includes reserve holds, account terminations, and billing disputes. His work focuses on identifying unsupported MATCH entries, addressing misapplied reason codes, and structuring strategies to resolve restrictions on payment processing access.

This work includes removal of MATCH entries where the assigned reason code was unsupported, where the underlying conditions did not meet Mastercard standards, or where the listing conflicted with the parties’ agreements and course of dealing. These outcomes are based on targeted, rule-based challenges directed to the responsible service provider and acquiring bank, often on an expedited basis.

Duration of MATCH Entries

MATCH entries are not permanent. If no action is taken, a merchant is automatically removed from the MATCH list after five years.

That duration reflects the system’s design as a historical risk database, but it also underscores the practical impact of an entry. For most businesses, waiting for automatic removal is not a viable option given the immediate restriction on access to payment processing and the possibility that additional providers may identify the entry through later MATCH queries.

Relationship to Broader Payment Disputes

MATCH entries rarely occur in isolation.

They often reflect the same underlying issues that arise across payment processing disputes, including how risk is assessed and applied, how transaction activity is measured and reported, how contractual standards are interpreted, and how responsibility is allocated across multiple participants.

A MATCH entry is often the point at which those issues become operational, translating internal decisions into system-wide restrictions on access to the card networks and merchant processing.