Back to blog
Merchant Services9 min read

MATCH Is Now MATCH Pro. Here Is What the Rules Actually Require, and What Changes on 15 October.

Mastercard's terminated-merchant file is now MATCH Pro, legacy access is being switched off, and from 15 October 2026 an inquiry returns a merchant risk score with the possible matches. Here is what Chapter 11 of Mastercard's rules requires of acquirers and payment facilitators, the five-day clock, the eleven reason codes, the 30-day response duty, where Visa's rules point at the same file, and where the guidance most teams work from is out of date.

Kyle Hall

Kyle Hall

Founder

MATCH Is Now MATCH Pro. Here Is What the Rules Actually Require, and What Changes on 15 October.

Every acquirer, and every payment facilitator that signs sub-merchants, checks the terminated-merchant file before boarding an account, and most onboarding teams still call it MATCH. Mastercard's current rules call it MATCH Pro. Legacy access is being switched off under a compliance mandate, and from 15 October 2026 an inquiry will yield a merchant risk score as well as the possible matches. Visa's rules, meanwhile, now point every acquirer outside Chile at the same file.

Most of what circulates online about MATCH is vendor copy that predates the current rules, and some of it is wrong on the numbers. What follows is drawn from Chapter 11 of Mastercard's Security Rules and Procedures, Merchant Edition (4 August 2026), Mastercard's public developer documentation for MATCH Pro, and the Visa Core Rules (18 April 2026), as of September 2026.

What MATCH Pro Is, and Who Has to Use It

The Mastercard Alert To Control High-risk Merchants system is a database of merchants, sponsored merchants and their principal owners that an acquirer has terminated for one of a defined list of reasons. The manual says MATCH Pro is mandatory for every acquirer with merchant activity, and that using it means two things: adding a terminated merchant that meets one of the reason codes, and inquiring against the database before signing a new one. An acquirer with a live acquiring ICA that is not doing both is subject to noncompliance assessments.

Access is not limited to banks. A registered third-party processor, payment facilitator or data storage entity can be an Authorized User under its own CID once the sponsoring acquirer has registered it and approved its access, but every action must run under the ICA of the acquirer that processes, or will process, the merchant, and the acquirer stays responsible for the accuracy of every listing whoever entered it.

The name change carries a migration with it. Mastercard's developer documentation says legacy MATCH APIs and bulk files were to be decommissioned effective 1 January 2026, and currently carries an alert that under bulletin GLB 12773.1 all customers must migrate to the MATCH Pro API and bulk files, with those who do not classified as Category C noncompliant. We have not read that member-only bulletin.

The Inquiry: Before the Agreement, Under the Right ICA, With the URL

Chapter 7 of the manual makes the MATCH Pro inquiry one of the required screening procedures. An acquirer must ensure an inquiry is submitted for any prospective merchant or sponsored merchant that proposes to accept Mastercard cards, before signing an agreement or enabling acceptance, and where sales will be made through a website or app it must include the URL. The duty covers the sponsored merchants of the acquirer's payment facilitators, and the inquiry must run under the ICA that will actually process for the merchant; one under the wrong ICA can itself draw an assessment.

Failure to inquire carries an assessment of up to USD 5,000 per instance. Separately, an acquirer that signs a merchant without inquiring may receive an unfavourable ruling in a compliance case filed by that merchant's next acquirer, which is the route by which another acquirer's losses become yours. Every inquiry returns an Inquiry Reference Number, and the acquirer must retain it; date-stamped inquiry and addition records are on the manual's list of investigative records to keep for at least two years after the merchant agreement ends.

How Matching Works

MATCH Pro searches five years of reported data and returns two kinds of possible match. An exact match is letter-for-letter on any one of a list of merchant and principal-owner fields: name, DBA, phone, tax and government ID numbers, address, URL, date of birth or email. A phonetic match converts names and addresses to a sound-alike code, so that in the manual's own examples "Easy" matches "EZ" and "Lee", "Li" and "Leigh" match one another. Up to five principal owners can be searched per merchant.

That is where the rules hand the decision back to you. The manual says, twice and with the words "for the avoidance of doubt", that an acquirer may onboard a merchant listed in MATCH Pro. A listing is information, not a prohibition. The obligation is to confirm the result is relevant to the applicant in front of you, and for a reason code 14 identity-theft listing, to do extra diligence to confirm the applicant is the legitimate person, who may not know their identity was used elsewhere.

A clean result on the day is not the end of it. If another Authorized User adds a matching merchant within 365 days of your inquiry, MATCH Pro generates a retroactive alert, displayed for 30 days and, per the developer documentation, emailed. If nobody is reading those, a merchant you boarded eleven months ago can be listed by its previous acquirer without anyone at your firm noticing.

The Addition: Five Calendar Days, One of Eleven Reasons

If either side moves to terminate, and at that moment the acquirer has reason to believe one of the listed conditions exists, it must add the merchant within five calendar days of the earliest of three events: its own decision to terminate, receipt of the merchant's notice of termination, or becoming aware of an issue that meets a reason code, regardless of when the termination takes effect. The acquirer must keep the Merchant Reference Number the system returns. The reason codes in Table 11.4 of the current manual are:

  • 01 Account data compromise.
  • 03 Transaction laundering.
  • 04 Excessive chargebacks: aggregate Mastercard chargebacks over the previous three months exceeded 1.5 percent of Mastercard sales transactions and totalled USD 5,000 or more.
  • 05 Excessive fraud: a fraud-to-sales dollar ratio of 8 percent or more over the previous three months, with 10 or more fraudulent transactions totalling USD 5,000 or more.
  • 06 Coercion.
  • 08 Mastercard Questionable Merchant Audit Program.
  • 09 Liquidation or insolvency.
  • 10 Violation of Standards, including the accuracy of the MCC, acceptor name and address where the merchant controls them.
  • 12 PCI DSS noncompliance.
  • 13 Illegal transactions.
  • 14 Identity theft.

Two things about that list are worth knowing. American Express acquirers, identified in the manual as ICA numbers 102 through 125, list into the same database, so a hit may have originated in an Amex relationship. And the list is shorter than most public explainers still print: codes 02 (common point of purchase), 07 (fraud conviction) and 11 (merchant collusion) do not appear in the 4 August 2026 table, and code 04 is defined over three months at 1.5 percent, not the single-month, one-percent test that widely republished summaries, including Stripe's public documentation page on terminated merchant files, still describe.

The rules also say what a listing is not. An acquirer may not use or threaten to use MATCH Pro as a collection tool for minor discretionary activity; a reason code must be met or suspected at the decision to terminate. Failing to list a merchant that qualifies is assessable too, and can produce an unfavourable ruling in a case brought by the next acquirer.

How Long It Lasts, and How a Merchant Gets Off

A listing stays for five years and is then purged automatically. Mastercard removes one in only two circumstances: the Authorized User reports it was added in error, or it was for reason code 12 and the merchant has since become PCI DSS compliant, evidenced by the acquirer's attestation and a validation letter from a Mastercard-certified forensic examiner; if the acquirer will not submit a code 12 request, the merchant may. There is no provision for removing a code 04 listing because the chargebacks later came down.

The rules do set a response clock. Any merchant may ask its former acquirer to be removed, and the manual says there is no requirement to engage legal counsel to do so. The acquirer must respond to a removal request within 30 calendar days and to questions about a listing within seven, and must tell the merchant or another acquirer which ICA added the listing and under which reason code. Mastercard may ask for a copy of any response.

What Arrives on 15 October: A Score With the Match

Mastercard's developer documentation states that effective 15 October 2026 it is introducing MATCH Pro with New Merchant Insights, which adds a merchant risk score and a set of fraud risk signals to the inquiry. From the 28 July 2026 API release and its FAQ: the inquiry itself does not change and needs no new fields. The acquirer submits the termination inquiry as before, keeps the Inquiry Reference Number, and up to 60 seconds later can retrieve the insights against that number, the delay being the time MATCH Pro takes to look the merchant up online. The score runs from 0 to 1, higher meaning more risk, with a class of low, medium or high and reason codes such as high reputational risk or high website security risk.

The signals come in two groups: a network assessment drawn from prior MATCH inquiries and the merchant's history on the Mastercard network, with fields for the number of acquirers and inquiries associated with the same address or principal and, for a known merchant, its chargeback, refund and authorization rates and number of past acquirers; and a digital presence assessment of the URL, covering domain age, encryption, replicated or minimal content, redirects, whether refunds are prohibited, and social media engagement and negative reviews.

Two cautions. The documentation refers readers to a publication on Mastercard's Technical Resource Center for the full details and related requirements, which we have not read; whether acquirers must act on the score, or simply receive it, is not settled by the public material. And a score built partly from web presence will rate a new business with a two-month-old domain and no reviews as riskier than an established one, which is true and unhelpful in equal measure for an ISO whose book is new businesses. Treat it as one input to the file, logged against the IRN, not as a decision.

Visa Points at the Same File

Visa's rules define the Terminated Merchant File as the file currently known as MATCH, maintained by Mastercard. Under the 18 April 2026 edition of the Visa Core Rules, a US acquirer must add a terminated merchant to that file no later than close of business on the day after the merchant is notified of the intent to terminate, and must list a merchant terminated for, among other things, laundering, excessive disputes, or identification under VAMP or VIRP. Effective the same date, and everywhere except Chile, an acquirer must query a common terminated-merchant database before entering a merchant agreement, use the data only as an informational tool, and on a possible match both verify that the merchant is the one inquired about and contact the listing member to find out why. An acquirer that fails these requirements can be held liable for another member's losses. Visa separately requires listing on its own Visa Merchant Screening Service where that service's criteria, which are not public, are met.

For a team that acquires on both networks, which is nearly everyone, the listing clock is therefore Visa's: where a termination reason falls under both sets of rules, the file has to be updated by close of business on the day after the merchant is notified, and Mastercard's five calendar days is the outer limit only for reasons Visa does not list.

What to Do With This

  • Log the Inquiry Reference Number on every file and keep it for two years past termination. It is the proof the inquiry happened, and from October it is also the key to the insights.
  • Put the URL in every e-commerce inquiry, confirm it runs under the ICA that will process the merchant, and give someone the retroactive alert screen as a daily task.
  • Decide the reason code at the decision to terminate, not afterwards. If the reason is one Visa lists, the clock is close of business the day after the merchant is notified. Never list, or threaten to list, as leverage in a collection dispute; the rules name that as a noncompliance.
  • A hit is not a decline. Confirm the match is really the applicant, contact the listing acquirer, and document the decision either way. Visa's rules now require the first two steps in terms, and Mastercard's the first.
  • Answer removal requests within 30 days and questions within seven, and keep the responses. Only an error, or cured PCI noncompliance, gets a listing removed; do not tell a merchant anything else.

Tags

About the author

Kyle Hall

Kyle Hall

Founder

Kyle Hall is a fintech entrepreneur, software engineer, and marketing strategist with over a decade of experience in high-risk payment processing and SaaS development. He is the CEO of PayKings, a leader in high-risk merchant services, and the founder of PulseCRM, a purpose-built CRM platform for the payments industry. Kyle specializes in building custom payment processing systems and growth strategies that empower merchant services providers to scale and succeed in the digital marketplace.

Now onboarding software partners

Turn your software into a payments business.

We sell it, board it, underwrite it, and run it. You add a revenue line to your platform without adding headcount.

Built for vertical SaaS platforms ready to monetize payments.

PCI DSS compliantSOC 2 Type II99.9% uptimeMulti-processor