What 'Should Have Known' Means for a Payment Processor

In early September the FTC settled with two payment processors over the merchants they let onto their books. Nuvei agreed to pay $4.85 million and Humboldt Merchant Services agreed to pay $12 million, both for consumer redress, which PYMNTS totals at $16.85 million. The FTC announced the Nuvei case on September 4 and the Humboldt case on September 8, and PYMNTS ran its analysis on September 22. None of this is news by now, and I’m not treating it as news. What I wanted was to read the FTC’s own releases, the orders and the Nuvei complaint rather than the coverage, because the documents say more than the headlines did. Read together, they’re about as close to a written specification for merchant underwriting as a regulator has published, and the part I find most important is about what a processor owes after a merchant is already processing.

What the FTC alleged, and what the settlements are

These are allegations. Both orders are stipulated, and both say the defendant neither admits nor denies the allegations in the complaint, except as stated in the order. Nuvei’s order was signed by the federal court in Arizona on September 9. Humboldt’s was filed in the Eastern District of Michigan as a proposed order, which the FTC notes has the force of law once a judge approves and signs it; I haven’t confirmed whether that has happened since. In a response reported by PYMNTS, Humboldt said the conduct involved a limited number of third-party agents and merchants between 2021 and 2023, under former leadership, and that it has improved its compliance since.

The FTC’s release says Nuvei “opened and maintained payment processing accounts for merchants that it knew or should have known were engaged in deception, including tech support scams.” The main example is Reimage, which the FTC describes as an offshore tech support scam, and for which Nuvei processed more than $30 million in consumer payments from 2017 to 2023. The release also names merchants the FTC had separately pursued, DK Automation over false earnings claims and American Tax Service over impersonating government tax authorities, and says Nuvei’s US subsidiary opened accounts “for merchants that other payment processors or acquiring banks previously terminated for excessive chargebacks or fraud.”

The complaint goes further. It says Nuvei Limited’s written policies listed “prohibited industries,” including anti-virus software sold through inaccurate advertising, and that it onboarded tech support merchants of that kind anyway. It says Reimage’s paperwork listed a paid nominee director from Cyprus as the beneficial owner. It says that in early 2020 Visa warned that Reimage was impersonating Microsoft, with a fine attached, and that Nuvei then “ramped up its payment processing for Reimage.” From the March 2020 Microsoft report until Reimage shut down in June 2023, the complaint counts more than 115,000 transactions worth over $9.5 million. And it quotes one internal reply on the risk side: “We will manage, will split their traffic with more banks.”

Humboldt’s case is a different shape. The FTC says Humboldt processed payments for more than 1,000 merchants that were shell entities serving as fronts or pass-throughs for companies running unauthorized billing scams, including Legion Media, which the FTC shut down in 2024. It says Humboldt opened those accounts despite red flags that they were shells, that they typically ran chargebacks at almost 10 times what the card brands treat as excessive, and that Humboldt placed them on a lower-risk BIN used by an affiliated entity to improve the odds that transactions would be approved. The proposed order bans Humboldt from processing for straw companies, for merchants on Mastercard’s MATCH list for reasons including excessive chargebacks, laundering and fraud, for merchants that have faced law enforcement action, and for e-commerce merchants whose only business address is a third-party mailbox and that either use negative option billing, are new, or have no processing history.

What “should have known” asks for

“Knew or should have known” is the FTC’s phrase in the Nuvei release, and the second half of it is the part I’d want every underwriting team to sit with. “Knew” is about what was in someone’s inbox. “Should have known” is about what the information available to the processor showed, whether or not anyone looked. That puts the standard somewhere other than the merchant’s application and somewhere other than the processor’s own policy document.

The Nuvei order then spells out, in effect, what that available information is. Before processing for a prospective client in the covered categories, Nuvei has to collect the merchant’s chargeback rate for the preceding five months, copies of monthly processing statements from any bank, processor, ISO, sales agent or acquirer the merchant used in the preceding six months (unless it has no prior processing history), and whether the merchant has been placed in a card network’s chargeback monitoring program in the past two years or terminated by a processor, acquirer, financial institution or payment system operator for excessively high chargeback rates. The order also asks for the more familiar items: what the merchant sells and how, who owns and controls it, its names, websites and physical locations.

Look at who writes each of those records. The processing statements come from the previous processor. The monitoring program placement comes from the network. The termination comes from another processor’s decision. None of it is the merchant’s description of itself. A merchant application is a self-report, and the order’s approach is to check it against records the merchant didn’t author.

That’s the same argument I’ve been making on this site about AI agents: a self-report is a claim, and the check has to come from somewhere else. When TRM Labs checked whether AI agents were paying, the useful part was that it went to a record nobody in the story had written for their own benefit. Underwriting has the same problem, with the difference that the person writing the self-report sometimes has a strong reason to get it wrong.

The complaint adds a second self-report, and I think it’s the more uncomfortable one for processors. Nuvei Limited had a written list of prohibited industries. According to the FTC, it also onboarded merchants in one of them. A risk policy is the processor’s own account of how it underwrites, and it carries about as much weight as the merchant’s account of what it sells. The FTC looked at what was processed.

I should be clear about where this stops. The full screening applies to what the order calls Covered Clients: merchants selling through outbound telemarketing, merchants selling tech support products or services, several other listed categories, and any merchant named in a public complaint or settlement over fraud or deception in the past ten years. Most ordinary merchants wouldn’t fall into those categories. The orders also bind these two companies and nobody else. I’d read them as a signal of what the FTC considers reasonable screening for risky categories, not as a rule the rest of the industry has to follow, and I’m reading them as a practitioner, not a lawyer.

The duty after onboarding

PYMNTS puts it as “merchant screening doesn’t end once an account starts processing.” That’s PYMNTS’s framing rather than the FTC’s, but the Nuvei order backs it up in its structure. One section requires Nuvei to monitor the sales activity of all current clients to find ones that should now be treated as Covered Clients, so the classification itself isn’t a one-time decision. Another, headed “Chargeback monitoring of all clients,” requires Nuvei to calculate every client’s chargeback rate at least monthly and to investigate any client that, in any two of the past six months, had a monthly chargeback rate above 1.0% and more than 75 chargebacks. Within 60 days of starting that investigation, Nuvei has to stop processing and close the client’s accounts, unless it writes a report establishing by clear and convincing evidence that the client’s practices aren’t deceptive or unfair.

Two things about that stand out to me. The first is that the chargeback section covers all clients, not just the risky categories, so the ongoing duty is wider than the onboarding one. The second is where the burden sits. Once a merchant crosses the threshold, the default outcome is exit, and staying requires the processor to prove the merchant is legitimate.

The complaint shows why the FTC would build it that way. On the FTC’s account, much of what went wrong with Reimage happened long after onboarding: the network warning, the fine, the decision to increase volume, the $9.5 million processed after the Microsoft report. At onboarding, a processor is making a judgment from the merchant’s description and whatever history it can collect. Once the merchant is live, the processor holds its own record of the merchant’s chargebacks, complaints and network notices. That record is the best evidence about the merchant it will ever have, and the merchant didn’t write it. In my reading, “should have known” gets harder to defend every month a processor has been watching.

Load balancing is the part that touches my own work

Both orders prohibit tactics to avoid fraud or risk monitoring programs run by banks or card networks, including load balancing. This is the part of the story closest to what I do, because spreading a merchant’s traffic across several acquirers is a normal function of payment orchestration. I’ve argued before that a business running on one provider has no baseline to judge it against, and I still think that.

The mechanics of legitimate routing and of evasion can look the same in a transaction log. Volume goes to more than one acquirer either way. As I read these orders, what the FTC is describing is splitting traffic so that each account stays under a network’s monitoring threshold while the merchant’s real chargeback rate stays where it was. “We will manage, will split their traffic with more banks” is a fair summary of that intent, and Humboldt’s alleged BIN placement is a version of it aimed at approvals. Routing for approval rates, cost and resilience is a different purpose using the same tools.

For clarity about my own side: orchestration is what we build at Corefy, and an orchestration layer sees a merchant’s combined traffic across providers, which is where a merchant’s true chargeback rate becomes visible. That has two consequences. It makes the evasion pattern easier to spot, and it means anyone with that view is in a position to know. My practical test is simple. If the case for adding a second or third acquirer rests on keeping chargeback ratios under monitoring thresholds, rather than on approvals, cost or coverage, it’s the case these orders describe.

Where I’d leave it

An elevated chargeback rate is a reason to look, not proof of deception, and the Nuvei order treats it that way: crossing the threshold triggers an investigation, not an automatic termination. That matters in high-risk verticals, where plenty of legitimate businesses run closer to network thresholds than a mainstream merchant would. What the order removes is the option of not looking.

For merchants in risky categories, I’d expect more processors to ask for prior processing statements, chargeback history and termination history up front, and having them ready is simply part of applying. For processors, the takeaway I’d draw is narrower than “underwrite harder.” The record you build after approval is evidence, and under a “should have known” standard it can be used against you as easily as for you.