Mastercard MATCH: documenting sub-merchant boarding decisions
A MATCH inquiry tells you something true at one moment. The problem comes later, when an audit asks what you knew at boarding and the list has already changed. Here is how MATCH works, and how to capture the state as it stood.
What MATCH is, and where it sits in boarding
MATCH, the Member Alert to Control High-risk Merchants system, is a Mastercard database of merchants that acquirers have terminated for cause. When you board a sub-merchant, your acquirer or gateway queries MATCH; when you terminate one for cause, it is added with a reason code such as excessive chargebacks, fraud, or money laundering. A listing is generally retained for about five years. Treat the inquiry as one input into the boarding decision, alongside KYB, sanctions, and fraud.
The state at boarding is the thing that matters
A MATCH result is point in time. It reflects the list on the day you queried it. Months later, when a sponsor bank or an internal audit asks why you boarded a sub-merchant that later went bad, re-pulling MATCH shows today's list, not the one you decided on. The defensible answer is the inquiry result, the reason codes returned, and the list date, captured at boarding and kept.
Most boarding stacks do not keep that. The inquiry happens inside the acquirer or gateway console, the KYB sits with another vendor, the fraud score with a third, and the boarding decision in a workflow tool. Reconstructing what you knew at boarding means stitching those back together after the fact.
One record per sub-merchant: capture the state, decide on the whole picture
FinQub is the single source of truth for fintech risk decisions. It sits alongside the acquirer, gateway, KYB, sanctions, and fraud tools you already use, and lands every signal each one produces on one record per sub-merchant.
MATCH state, captured at boarding. The inquiry outcome, the reason codes, and the list date land on the record when you board, so a later inquiry cites the exact state you saw, not a re-pull.
Decide on the whole picture. The MATCH result sits next to the KYB, the sanctions screen, and the fraud score on the same record, so the boarding decision is made with all of it in view. The result is a signal; your rulebook or your analyst makes the call.
Queryable when the request comes. When a sponsor bank or acquirer asks for boarding history on a set of sub-merchants, one query produces a signed exam packet per merchant, with the MATCH state as it stood.
A checklist for defensible MATCH documentation
- Capture the MATCH inquiry result, reason codes, and list date at boarding, not at audit time.
- Keep the MATCH state on the same record as the sub-merchant's KYB, sanctions, and fraud signals.
- Record the boarding decision, who made it, and the signals it stood on.
- Confirm you can reproduce the boarding evidence, MATCH state included, on one query for any sub-merchant.
Frequently asked questions
What is the Mastercard MATCH list?
MATCH (Member Alert to Control High-risk Merchants) is a Mastercard-operated database of merchants that acquirers have terminated for cause. Acquirers query it when boarding a merchant and add merchants they terminate, each with a reason code. A listing is generally retained for around five years. Confirm the current retention and reason-code set against Mastercard's program rules.
Why capture the MATCH state at boarding instead of re-pulling later?
MATCH changes over time as acquirers add and age off listings. If you re-pull months later to answer an audit, you are showing today's list, not what you saw when you boarded. Capturing the inquiry result, the reason codes returned, and the list date at boarding lets you show exactly what informed the decision.
Does FinQub query MATCH for me?
No. Your acquirer or gateway performs the MATCH inquiry. FinQub is the record the result lands on: the inquiry outcome, the reason codes, and the list date sit on one record per sub-merchant alongside your KYB, sanctions, and fraud signals, so the boarding decision is made on the whole picture and stays reproducible later.
How does this connect to VAMP exposure?
A prior MATCH listing is one of the signals that predicts dispute and fraud risk, which is what VAMP measures. Keeping the MATCH state on the same record as the sub-merchant's fraud and dispute history means a merchant likely to move your VAMP ratio is visible at boarding, not in next month's report.
FinQub keeps the boarding record on the vendors you already run. It is the single source of truth for fintech risk decisions beneath your PayFac stack. See how the same record handles VAMP exposure, or book a short walkthrough below.