What a TMF/MATCH Listing Actually Shows Acquirers

A TMF/MATCH listing does not function as a binary disqualification - it flags a specific reason code, and that code is the first thing a high-risk acquirer evaluates before making an underwriting decision. Mastercard's MATCH database contains 14 reason codes, and at SeamlessChex we see the full range of them in our application pipeline. Merchants listed under Reason Code 04 (Excessive Chargebacks) account for the largest share of our MATCH-listed applicants and carry the highest approval rate among them - roughly 60 to 65 percent when the documentation package is complete. Merchants listed under fraud or criminal codes - 03, 07, 11, or 13 - have an approval rate near zero, not because we decline them arbitrarily, but because no sponsor bank in our network will underwrite those risk profiles.

I've reviewed enough MATCH applications at SeamlessChex to know that the merchants who struggle most are not always the ones with the worst listings. They're often the ones who don't understand what their reason code communicates to an acquirer. They arrive with a generic decline from another processor, no explanation of why, and an assumption that all MATCH listings read the same to an underwriter. They don't. What the acquirer sees, how they interpret it, and what documentation changes the outcome are all specific to the reason code on the report - not to the existence of the listing itself.

The goal of this article is to give you the same frame the underwriter is working from. That means explaining the nine data fields in a MATCH query, what each reason code signals, why some codes lead to approvals and others close the file immediately, and what documentation turns a code-04 or code-12 listing into a functioning merchant account. If you've been turned down and you don't know your code, start there - everything else in the application process flows from it.

What the MATCH Database Actually Reports

MATCH - Member Alert to Control High-Risk Merchants - is a database operated by Mastercard.

As noted by an industry overview on the Mastercard MATCH List, it was originally known as the Terminated Merchant File (TMF) before being rebranded under the MATCH name. Acquiring banks are required to report merchants whose accounts they terminate for specific qualifying reasons. Any new acquirer reviewing an application can query the database. What they receive is not a red-flag icon or a generic "do not approve" notice. They see a structured record with nine primary data fields, as of September 2026.

Those fields are:

• Merchant legal name - the registered business name at time of termination
• DBA (doing business as) name - the trade name, if different from the legal entity name
• Business address - street, city, state, postal code, and country
• Business phone number
• Tax ID / EIN - the federal employer identification number on file at termination
• Principal name(s) - owners and executives listed on the original account
• Principal SSN or date of birth - used for individual-level matching across records
• Reason code - Mastercard's numeric designation (01-14) specifying why the account was terminated
• Termination date - the date the account was closed, which also starts the five-year listing clock

The acquiring bank that filed the report is also visible to any querying acquirer. That context shapes interpretation. A processor with a reputation for aggressive reporting on minor threshold violations may be weighted differently by an experienced underwriter than a fraud-focused risk team with a tighter standard for what triggers a filing.

How Acquirers Actually Query the Database

Acquirers don't run manual MATCH searches for most applications. The check runs automatically via API call during standard underwriting review. The query matches on multiple fields simultaneously. A merchant who changes their business name but retains the same EIN, the same principals, or the same SSNs will still surface in the database. This is why restructuring a business entity to escape a MATCH listing almost never succeeds - the principal-level SSN matching catches it regardless of the new name on the application.

What the acquirer receives is the complete record for any matches found. If there are multiple matches - a merchant who operated under several DBA names, or who has multiple listings from separate terminations - all records appear. The underwriter reviews the reason code and makes a credit decision based on their institution's underwriting guidelines for that specific code. The existence of the listing is one input; the reason code on that listing is the operative variable.

The Five-Year Clock and Early Removal

MATCH listings expire five years from the termination date - not from the reporting date, which can lag termination by several weeks. A merchant terminated in August 2024 stays listed until August 2029. There is no standard process for early removal. If a listing contains inaccurate information - a wrong reason code, incorrect principals - the merchant can dispute it with the acquirer that filed the report. Disputes are handled directly between acquirers; Mastercard does not arbitrate them. As one industry analysis of the MATCH list notes, Mastercard mandates the list's existence but exercises limited oversight over individual placement decisions - those are made by the acquiring banks.

The five-year window is a planning reality but not necessarily a processing reality. Merchants with underwritable reason codes do not need to wait out the listing period before accessing credit card processing. The listing is visible to any acquirer who looks; what determines whether an application advances is whether the acquirer can underwrite around the specific reason code - and that assessment happens code by code.

MATCH vs. the Visa Terminated Merchant File

Mastercard operates MATCH. Visa maintains a separate terminated merchant database, also commonly called the TMF. The two are distinct systems with different data structures and reason code frameworks. Being reported to one does not automatically trigger a listing on the other, though a merchant terminated for conduct violating both card brands' standards may end up on both. High-risk acquirers with active sponsor bank relationships query both as part of standard underwriting practice.

In common usage, "MATCH" and "TMF" are often used interchangeably - particularly in the phrase "TMF credit card processing," which typically refers to getting card processing after any terminated-merchant listing rather than specifically to the Visa database. The mechanics in this article apply primarily to the Mastercard MATCH database, which is the more comprehensive and widely queried of the two systems.

What the acquirer sees is specific, structured, and interpretable. It is not a blunt instrument. A skilled underwriter reads the MATCH record and comes away with exactly what they need to evaluate the application - and that same information is what a prepared merchant should use to build their documentation package before they apply anywhere.

The 14 Reason Codes and What They Signal to Underwriters

Mastercard assigns one of 14 reason codes to every MATCH entry. The code number is the first thing an underwriter evaluates - before documentation, before application narrative, and sometimes before reading anything else in the file. The code places a merchant into one of three underwriting tiers: approvable, conditional, or disqualifying. Understanding that tiering is the most actionable frame a MATCH-listed merchant can bring to a processor application.

The Approvable Codes

Code 04 - Excessive Chargebacks is the most common MATCH listing and the most consistently underwritable. Mastercard's standard chargeback threshold is 1% of monthly transaction count, and exceeding it places merchants in elevated monitoring programs before termination. As one high-risk industry analysis notes, "the problem arises when your chargebacks are more than 1% of your overall sales transactions, as this may lead to the processing bank cancelling your account." High-risk acquirers see this code regularly. It surfaces when a subscription business's retention controls fail, when product quality disputes go unresolved at scale, when a billing descriptor doesn't match the trade name and drives friendly-fraud disputes, or when customer service response time collapses under volume growth. The condition is operational, not criminal. A merchant who demonstrates they've implemented chargeback mitigation tools, corrected billing descriptors, or improved fulfillment practices gives an underwriter something concrete to evaluate.

Code 09 - Bankruptcy / Liquidation / Insolvency is underwritable when the merchant operates under a new legal entity following reorganization and that entity has established clean banking history. The key underwriting question is whether the financial condition that led to insolvency has resolved. Underwriters want to see current bank statements and business financials showing the new entity is on sound footing - not that the principals have a pattern of walking away from creditors.

Code 12 - PCI DSS Non-Compliance is underwritable when a merchant can produce documentation of current compliance certification. As one payments industry critique notes, PCI DSS is the Payment Card Industry Data Security Standard governing how merchants handle cardholder data. The listing records a point-in-time compliance failure at termination. If the merchant has achieved PCI certification since that date, the condition is remediated. An Attestation of Compliance from a Qualified Security Assessor closes that gap cleanly in any underwriting review.

The Disqualifying Codes

Code 03 (Laundering), Code 07 (Fraud Conviction), Code 11 (Merchant Collusion), Code 13 (Illegal Transactions), and Code 14 (Identity Theft) represent deliberate misconduct - not operational failures or risk management lapses. No sponsor bank in SeamlessChex's network underwrites these codes. I want to be direct here because I see content that soft-pedals this point: if your MATCH code is 03, 07, 11, 13, or 14, the realistic path back to standard credit card processing runs through either the five-year listing expiration or legal counsel reviewing whether the listing itself is accurate. We can't help merchants in these categories, and any processor claiming to routinely approve code-07 or code-13 applications warrants serious scrutiny before you engage with them.

The distinction matters practically: these codes don't indicate a merchant who had a bad quarter or failed to manage chargebacks. They indicate conduct the card brands treat as fundamentally incompatible with network participation - a different problem entirely, calling for a different kind of response.

The Conditional Codes

Codes 01, 02, 05, 08, and 10 require individual evaluation. A code-05 (Excessive Fraud) listing might stem from a compromised payment integration rather than deliberate fraud - a meaningfully different risk profile than a merchant who knowingly processed fraudulent transactions. Code-08 (QMAP) and code-10 (Violation of Standards) depend heavily on what the underlying violation was and whether it has been addressed. These applications require a more detailed documentation review and, frequently, direct conversation with the underwriting team before a decision is made. A closed door is not the default for conditional codes - but expect a more involved process than code-04.

How High-Risk Acquirers Underwrite Around a MATCH Listing

High-risk acquirers process MATCH-listed applications differently than standard processors. A standard ISO auto-declines on any MATCH hit - their underwriting guidelines don't include a framework for evaluating what kind of hit it is, so all results are treated identically. A high-risk acquirer with dedicated underwriting capability runs a two-stage review: code classification first, documentation second. Understanding that sequence changes how a merchant should prepare their application.

Stage One: Code Classification

Before any underwriter reads an application narrative or reviews bank statements, they classify the reason code. If the code is disqualifying, the file closes. No documentation package overcomes a code-03 or code-07 listing at any sponsor bank I'm aware of. This reflects card brand requirements and the underwriting guidelines sponsor banks pass to their ISOs - not arbitrary policy.

If the code falls into the approvable or conditional tier, the application advances. The underwriter's operative question from that point is: "What happened, has the situation changed, and does the documentation demonstrate that change in a way I can present to the sponsor bank for approval?"

Stage Two: Documentation Review

For code-04 applications, the documentation review addresses three core questions:

• What drove the chargebacks? Product delivery failures, unclear billing descriptors, subscription cancellation friction, and slow customer service response all have documented remediation paths. Each communicates a specific operational fix to an underwriter - and a specific problem that was, or wasn't, addressed.
• What controls are now in place? A merchant who enrolled in a chargeback alert service, updated their billing descriptor to match their trade name, simplified their refund policy, or implemented proactive outreach to subscribers at risk of filing disputes is demonstrating changed operations - not just promising better results.
• What does recent processing history show? Merchants who have processed anywhere since termination - through a payment facilitator, an alternative high-risk account, or any platform that accepted them - carry those statements into the application. A three-to-six month window of controlled chargeback ratios is the clearest evidence of operational remediation available to an underwriter reviewing a code-04 file.

In the payment processing community, it's not unusual to encounter merchants who were MATCH-listed but continued processing through alternate arrangements while addressing the underlying issue. That ongoing processing history, if it shows improvement, becomes one of the strongest arguments in a new application.

The Sponsor Bank Layer

One dynamic that most merchant-facing content leaves out entirely: the ISO you apply with doesn't make the final approval decision alone. The sponsor bank holding the merchant accounts makes the ultimate credit determination based on their own underwriting criteria, which they pass down to the ISO through program guidelines. A high-risk ISO like SeamlessChex can advocate for a MATCH-listed merchant, provide additional context in the underwriting review, and work across multiple sponsor bank relationships to find the right fit. But we can't approve a merchant the sponsor bank won't underwrite.

This explains why two high-risk processors can produce different outcomes for the same application. A processor with access to a broader sponsor bank network - one that includes institutions with explicit risk appetite for code-04 recurring-billing merchants, for instance - can place a merchant that a processor with narrower bank relationships cannot. The relevant question when evaluating where to apply is not just "do you work with MATCH-listed merchants?" but "which sponsor banks are in your network, and which reason codes do they underwrite?"

What SeamlessChex Evaluates in Practice

In my experience reviewing MATCH applications at SeamlessChex, the applications that advance most reliably share a few consistent characteristics regardless of code type:

• The merchant understands their reason code and explains the events that led to it without deflecting. "Here's what happened and here's what we did about it" moves a file forward; "the processor had it in for us" doesn't.
• The documentation package is complete at submission. Missing statements or an unsigned remediation plan extends review and often signals the merchant isn't operating with the discipline a high-risk account requires.
• The business is processing at least $25,000 per month. Our merchant accounts are built for established businesses with real volume, not pre-launch operations trying to establish a history from zero.
• The principals named in the new application match those in the MATCH record. This is not disqualifying - but principals who attempt to omit themselves when they appear in the database create a separate credibility problem that compounds the listing issue and turns a reviewable file into a declined one.

Transparency throughout the application accelerates review. An underwriter who finds a MATCH hit mid-process that wasn't disclosed at intake treats the omission as a standalone issue, independent of and compounding the original listing. The merchants who navigate this process successfully tend to be the ones who arrived at the table already knowing their code, their documentation, and what story those documents tell.

The Documentation That Changes the Outcome for MATCH-Listed Merchants

The application itself doesn't move a MATCH-listed merchant from decline to approval. The documentation package does. From what I've seen in our underwriting process at SeamlessChex, the difference between an application that stalls and one that advances almost always comes down to whether the merchant submitted a complete set of supporting materials - not whether they drafted a more persuasive cover letter or chose a more sympathetic framing for their situation.

Here is what a complete documentation package looks like for a Code 04 (Excessive Chargebacks) application:

• Six months of processing statements from the terminated account, showing the chargeback ratio history over time. Underwriters want to see the peak and the trajectory - a merchant whose chargebacks spiked and then trended downward before termination is a different risk profile than one whose ratio was still climbing at the point of termination.
• Chargeback dispute documentation - evidence that the merchant filed representments and won reversals where applicable. This demonstrates active management of the chargeback problem rather than passive acceptance of disputes.
• A written remediation plan addressing the specific operational conditions that caused the chargebacks. This needs to be concrete: "We implemented a chargeback alert service through Verifi on [date] and enrolled in Ethoca by [date]" is useful. "We plan to improve our customer service response time" is not. Underwriters evaluate whether the fix is real or aspirational.
• Current bank statements, minimum three months, from the business's primary operating account. This confirms the business is active and cash-flowing, not dormant between applications.
• Updated refund and cancellation policy - a readable policy posted to the business website (with screenshot) showing customers a clear path to resolution that doesn't require them to file a dispute with their card issuer.
• Billing descriptor confirmation - documentation of what the transaction will appear as on a customer's statement. A descriptor that matches the trade name and includes a contact number or website URL materially reduces the friendly-fraud chargebacks that drive many code-04 listings.
• Evidence of chargeback alert enrollment - if the merchant has enrolled in Verifi Order Insight or Ethoca, documentation of that enrollment. Alert services give merchants the opportunity to resolve a dispute before it posts as a formal chargeback against the merchant ID.

For Code 12 (PCI DSS Non-Compliance) Applications

The core document is an Attestation of Compliance from a Qualified Security Assessor confirming current PCI DSS certification status. For smaller-volume merchants using a self-assessment pathway, a completed Self-Assessment Questionnaire and a passing Approved Scanning Vendor scan report accomplish the same purpose. The listing records a past compliance failure; the current AOC closes that chapter in the underwriting review. What the underwriter is confirming is that the condition that caused the listing - the non-compliance - no longer exists.

For Code 09 (Bankruptcy) Applications

Legal documentation of the bankruptcy filing, discharge order, and formation of the new operating entity form the foundation. The underwriter needs to verify the new entity is legally distinct from the insolvent one and that the principals are in good standing. Three months of business bank statements for the new entity establish current operational health. If the new entity has any processing history, those statements belong in the package as well.

What Incomplete Documentation Actually Signals

From what I observe in our application flow, incomplete documentation isn't just a procedural gap - it signals readiness. A merchant who has genuinely remediated the condition that caused the listing has the paperwork. The chargeback dispute records exist because they filed representments. The remediation plan exists because they built and executed one. The processing statements exist because they tracked the problem over time.

When documentation is missing, the most common explanation is not that the merchant is disorganized. It's that they haven't actually addressed the underlying condition and are hoping the application narrative will substitute for evidence. Underwriters notice this - not always explicitly, but they feel it when a file goes thin at exactly the point where remediation should be demonstrated. The merchants who move through our process quickly are the ones who arrive knowing that documentation is the argument, not the paperwork that supports the argument.

A MATCH listing is not a permanent verdict on a business. It is a record of what happened, and the reason code is what an underwriter reads to understand what they're evaluating. Merchants who come to SeamlessChex with a code-04 listing and a complete documentation package are not in an unusual situation for us - we work with this profile routinely, and we evaluate each application on its specific facts, not on the existence of the listing alone.

What I'd encourage any MATCH-listed merchant to do before applying anywhere is to know their code. Request the information from the processor that terminated you - you have a right to it. Understand what the code means, what documentation addresses it, and whether the high-risk acquirer you're considering can actually place that code with their sponsor bank network. That knowledge makes the application process faster and more productive for both sides.

SeamlessChex works with established businesses processing at least $25,000 per month. If your reason code is in the underwritable tier and you're ready to submit a complete application, we're a practical next step. If you're in a disqualifying code category, I'd rather tell you that clearly than take your application and waste your time. Transparency on both sides is how we build processing relationships that actually hold.