Humboldt, MATCH, and the Cost of Ignoring Merchant Risk

Four days after the FTC announced its proposed settlement with Nuvei, the agency announced another payment processor case.

This time, the allegations are against Humboldt Merchant Services.

If last week's Nuvei case was a reminder that merchant underwriting does not end at approval, Humboldt is the follow-up nobody in payments asked for but everybody should probably read.

Because this case gets very specific about what happens when warning signs exist and the processing relationship keeps moving anyway.

According to the FTC's announcement, Humboldt Merchant Services will pay $12 million and be permanently prohibited from processing for merchants with heightened fraud risk under a proposed settlement resolving allegations that it processed payments for merchants that defrauded consumers.

The FTC alleges Humboldt processed payments for more than 1,000 merchants that were shell entities serving as fronts or pass-throughs for fraudulent companies involved in unauthorized billing schemes. It also alleges Humboldt opened accounts despite red flags and that those sham merchants typically generated chargeback rates nearly 10 times higher than what card brands view as excessive.

Then there is the part that should get the attention of every processor, PayFac, ISO, marketplace, and software platform that participates in merchant onboarding.

The proposed order specifically restricts Humboldt from processing for several categories of merchants, including certain merchants appearing on Mastercard's MATCH list for reasons such as excessive chargebacks, laundering, and fraud.

MATCH is not the whole story here.

But it is a very useful way to understand the bigger one.

A risk signal does not protect the payments ecosystem just because it exists in a database.

Somebody has to do something with it.

MATCH Is a Signal, Not a Magic Answer

Mastercard's MATCH system exists to help acquiring institutions identify merchants that have been terminated for certain reasons before establishing a new merchant relationship.

In practice, payments people sometimes talk about MATCH like it is a binary answer.

Merchant is on MATCH: bad.

Merchant is not on MATCH: good.

Real underwriting does not work that way.

A MATCH result needs context. Why was the merchant listed? Which termination reason applies? Does the current application involve the same owners or business? Is there evidence of a legitimate change? Does the current merchant structure make sense? What additional due diligence is required? Can the relationship be accepted under network rules and internal policy?

More importantly, not appearing on MATCH does not mean a merchant is safe.

A brand-new shell entity may not have enough processing history to be listed anywhere. A deceptive business may operate through multiple entities. Ownership may be obscured. A merchant may change names, websites, addresses, descriptors, or processing relationships.

That is why MATCH should be treated as one signal inside a larger underwriting and monitoring program.

The danger is not only missing a MATCH result.

The danger is turning the lookup into compliance theater: run the database, store the response, check the box, move on.

A database check is not a risk program.

It is an input to one.

The Humboldt Allegations Go Beyond a Bad Merchant or Two

The scale alleged by the FTC is what makes the Humboldt case particularly important.

The agency says Humboldt processed payments for more than 1,000 merchants that were shell entities serving as fronts or pass-throughs for fraudulent companies. The FTC's complaint also alleges Humboldt knew, or consciously avoided knowing, that some of these companies were shells used by undisclosed third parties engaged in fraud.

That distinction matters.

Payment companies deal with bad merchants. Fraud exists. Applications contain lies. Legitimate businesses change. No underwriting program catches everything.

The regulatory question becomes very different when the issue is not simply whether a bad merchant slipped through once, but whether warning signs were repeatedly present and the organization had a process capable of responding to them.

That is where merchant identity matters.

Does the entity on the application actually operate the business?

Does the listed owner appear to control it?

Is the address a real operating location?

Does the website match the stated business?

Is another company actually benefiting from the processing account?

Do multiple merchants share owners, addresses, websites, devices, descriptors, bank accounts, IP information, or other connections that should cause someone to look deeper?

Shell merchants are dangerous precisely because each account can look small or isolated when viewed alone.

The risk becomes easier to see when the portfolio is viewed as a network.

That requires data, tooling, and people who know what they are looking for.

A Chargeback Rate Is Not Just a Percentage

The FTC alleges that Humboldt's sham merchants typically incurred chargebacks at rates nearly 10 times higher than levels card brands consider excessive.

That should make every payments operator uncomfortable for a very basic reason.

Chargebacks are noisy, but they are not meaningless.

A merchant can have elevated disputes because it has poor customer service. Maybe fulfillment is messy. Maybe its descriptor is confusing. Maybe the product does not match expectations. Maybe refunds take too long.

Or maybe the business is deceptive.

The chargeback rate does not answer that question by itself.

It tells you to ask it.

That is why a threshold is not a control either.

Imagine a dashboard turns red when a merchant crosses a certain chargeback level.

Great.

What happens next?

Does somebody review the reason codes? Are consumer complaints examined? Does the team compare current activity against the underwriting file? Does the merchant have to explain the increase? Are reserves adjusted? Is processing restricted? Is enhanced due diligence triggered? Does somebody review connected merchant accounts?

Most importantly, who has authority to say the relationship no longer makes sense?

If the answer to a red alert is another red alert next month, the monitoring system is producing information, not control.

Risk Avoidance Tactics Should Change the Question

One of the more unusual allegations in the Humboldt case involves transaction routing.

The FTC alleges Humboldt attempted to increase transaction approvals for sham accounts by placing them on a lower-risk bank BIN through an affiliated entity. The proposed order also prohibits tactics intended to avoid fraud and risk monitoring, including load balancing.

This gets to an important underwriting principle.

When activity appears structured to avoid a control, the question should change.

The question is no longer simply, "Does this transaction pass the rule?"

It becomes, "Why is the activity being structured this way?"

Payments systems are full of thresholds. Volume limits. Chargeback thresholds. fraud scores. velocity rules. reserve triggers. network monitoring programs.

Sophisticated bad actors learn those thresholds too.

If volume is intentionally spread across merchant accounts, descriptors, MIDs, acquiring relationships, or other structures to stay underneath monitoring thresholds, a risk program that reviews each account independently may never see the pattern.

Fraud does not have to beat your rules if it can route around them.

Portfolio-level monitoring matters because the relationship between accounts can be more informative than the activity inside any one account.

The MATCH List Should Trigger Questions, Not End Them

The proposed Humboldt order would prohibit processing for merchants appearing on MATCH for specified reasons including excessive chargebacks, laundering, and fraud.

That makes MATCH a useful focal point for the case, but there is a broader lesson for platforms.

Risk teams should think in terms of evidence chains.

A MATCH result may tell you a prior acquirer terminated a merchant.

A high chargeback rate may tell you consumers are disputing transactions.

Customer complaints may tell you what those consumers believe happened.

A merchant's website may tell you what was promised.

Transaction data may tell you what the business is actually doing.

Ownership data may connect the account to other merchants.

Law-enforcement or regulatory actions may provide additional context.

None of those signals necessarily answers everything by itself.

Together, they can tell a very different story.

Good underwriting is not collecting as many databases as possible.

Good underwriting is knowing how to combine signals into a defensible decision.

This Is an ISV and PayFac Problem Too

Software companies may be tempted to look at Humboldt and file it under "processor problem."

That would be convenient.

It would also miss how embedded payments actually works.

ISVs, PayFacs, marketplaces, and vertical SaaS platforms often have context an acquirer or processor does not.

The software platform may know what services were scheduled. It may see inventory. It may see invoices, refunds, subscriptions, appointments, fulfillment, customer messages, seller behavior, cancellations, or other operating data.

That context can make merchant monitoring dramatically better.

It can also create an uncomfortable question when warning signs appear:

What did the platform know, and what did it do with that information?

This does not mean every ISV inherits every regulatory obligation of its processor or acquiring bank. Roles, contracts, network rules, and program structures matter.

But the operational principle is straightforward.

If your company sees risk signals, there should be a defined path for those signals to reach whoever owns merchant risk.

Support complaints should not die in support.

Refund anomalies should not live only in finance.

Merchant business-model changes should not stay inside customer success.

Fraud indicators should not live in a separate dashboard nobody checks until Monday.

Embedded payments works because software platforms have richer context.

Merchant risk should benefit from that context too.

Two FTC Cases in Four Days Is Worth Noticing

We wrote last week about the FTC's proposed settlement with Nuvei and the lesson that merchant underwriting does not end at approval.

Four days later, the agency announced Humboldt.

The cases are different and should not be collapsed into one set of facts. Both involve allegations, and both proposed orders require court approval before they have the force of law.

But the timing is hard to ignore.

Payment processors are an important control point in the commercial ecosystem because deceptive merchants need access to payments to turn a scam into money.

That means the FTC does not have to focus only on the merchant making the deceptive claim.

It can also ask what the companies enabling payment acceptance knew, what warning signs existed, and what happened when those warning signs appeared.

For processors, PayFacs, sponsor banks, ISOs, and platforms, that should sharpen the operational question.

Can you prove your monitoring program produces decisions, not just alerts?

What Payments Companies Should Review Now

The lesson from Humboldt is not "terminate every risky merchant."

Risk-based payments programs need judgment. Some alerts are false positives. Some chargeback spikes have legitimate explanations. Some MATCH records require context. Some merchants can be remediated through reserves, enhanced monitoring, clearer disclosures, operational improvements, or tighter controls.

But judgment needs a process behind it.

Payments companies should review whether they can answer a few practical questions:

• Are MATCH checks performed at the appropriate points in the merchant lifecycle, not just stored as an onboarding artifact?
• When a MATCH result appears, is the termination reason understood and documented?
• Can risk teams identify connected merchants, owners, addresses, accounts, websites, and processing relationships?
• Do chargeback thresholds automatically create an investigation or merely a report?
• Are consumer complaints visible to merchant-risk teams?
• Can monitoring detect activity spread across multiple accounts or MIDs?
• Are exceptions documented with an owner, rationale, additional controls, and a review date?
• Can commercial teams override risk decisions, and if so, under what governance?
• Does someone have clear authority to restrict or terminate processing?
• Can the company reconstruct why it decided to keep processing when serious warning signs were present?

That last question is the one that matters after the fact.

If your answer requires fifteen Slack searches and somebody saying, "I think Mike approved it," the process needs work.

The Takeaway

The FTC's Humboldt case is not a story about MATCH being a magic blacklist.

MATCH is one signal.

Chargebacks are another.

Merchant identity is another.

Consumer complaints are another.

Regulatory history is another.

Transaction behavior is another.

The real control is the system that connects those signals, investigates them, documents the decision, and gives someone authority to act.

That is why the Humboldt allegations matter beyond one processor.

Payments companies already have more risk data than they sometimes realize. ISVs have software data. Processors have transaction data. Acquirers have portfolio data. Support teams have complaint data. Networks have monitoring programs. Databases like MATCH add historical context.

The challenge is not simply collecting another signal.

It is making sure somebody owns what happens next.

Because a MATCH check is not a control by itself.

A chargeback threshold is not a control by itself.

An alert is not a control by itself.

The control is what your organization does after the warning light turns on.

Want to get featured on the Cents Chat podcast? Complete our survey.