Sovereign Nations. Different Laws. One Complicated Payments System.
Sovereign Nations. Different Laws. One Complicated Payments System. On Indigenous Peoples' Day, it's time to examine why tribal gaming, ...
Three payment companies.
Three FTC enforcement actions.
More than $21 million in announced monetary settlements or relief.
And one increasingly uncomfortable question for every processor, PayFac, merchant-of-record provider, acquirer and sponsor bank:
How much are you expected to know about the merchants you enable?
This is no longer a theoretical compliance discussion.
In June 2025, the Federal Trade Commission announced a $5 million settlement with Paddle over allegations that its payment infrastructure facilitated deceptive tech-support schemes. The resulting order required, among other things, effective client screening and monitoring.
On September 4, 2026, the FTC announced a $4.85 million settlement with Nuvei. The Commission alleged Nuvei opened and maintained payment-processing accounts for merchants it "knew or should have known" were engaged in deception. The resulting order requires merchant screening and monitoring, including enhanced screening and investigation in specified circumstances.
Four days later, the FTC announced its action against Humboldt Merchant Services. The complaint alleged Humboldt processed payments for more than 1,000 shell entities serving as fronts or pass-
throughs for fraudulent businesses and opened accounts for merchants it "knew, or consciously avoided knowing" were being used by undisclosed third parties engaged in fraud. Humboldt agreed to $12 million in consumer redress and was permanently prohibited from processing for merchants with a heightened risk of potential fraud under the terms of the order.
These cases involve different facts, entities and legal allegations.
They should not be treated as establishing a universal legal standard for every payment provider.
But taken together, they should cause executives across the payments industry to ask a very serious question:
Is our merchant monitoring program actually capable of discovering what we may someday be asked: Why didn't we know?
That is a board-level question.
For years, merchant monitoring has largely lived somewhere inside Risk, Compliance or Operations.
Executives might see portfolio statistics.
Boards might see chargebacks.
They might see fraud losses.
MATCH activity.
Regulatory matters.
High-risk concentrations.
Suspicious activity.
Exceptions.
But the mechanics of actually understanding merchants have often remained buried several organizational layers below the boardroom.
That's increasingly difficult to justify.
Because the consequences of merchant misconduct can travel upstream.
A merchant may commit the underlying misconduct.
But regulators can ask what the companies enabling that merchant knew, what warning signs existed, what systems were operating, what investigations occurred and what happened after the signals
appeared.
Look at the language surrounding these recent actions.
Paddle: the FTC said payment companies can face accountability when they knowingly facilitate scammers or ignore red flags.
Nuvei: merchants it allegedly "knew or should have known" were engaged in deception.
Humboldt: merchants it allegedly "knew, or consciously avoided knowing" were shell companies used by third parties engaged in fraud.
Different cases.
Different allegations.
But the operational lesson is hard to miss:
Not knowing is becoming a much more complicated defense when the warning signs were discoverable.
For years, financial institutions could reasonably ask:
Did we know?
I believe modern risk management increasingly requires another question:
Did we have reasonable systems designed to find out?
That's a profoundly different standard for operating a merchant portfolio.
Because the first question focuses on what happened to reach someone's desk.
The second focuses on the infrastructure responsible for getting it there.
Was the merchant screened?
Was the website reviewed?
Were products understood?
Were principals evaluated?
Were related businesses identified?
Were terminated relationships considered?
Were marketing practices examined?
Were chargebacks investigated?
Were complaints monitored?
Were material changes detected?
Were exceptions escalated?
Were remediation actions documented?
Was someone accountable for the outcome?
And perhaps most importantly:
Did monitoring continue after the merchant was approved?
That is where many legacy operating models begin to fail.
This distinction is becoming critical.
A monitoring system can tell you that something happened.
A merchant's website changed.
Chargebacks increased.
A domain appeared.
A product was added.
A complaint was published.
Ownership changed.
Negative media appeared.
Transaction velocity increased.
A license expired.
Monitoring produces signals.
But signals aren't necessarily intelligence.
Merchant Intelligence asks:
What changed?
Why does it matter?
What else is connected to it?
Does it conflict with policy?
Does it change the merchant's risk?
Does it require investigation?
Who needs to act?
What happened after they acted?
That's the difference between:
and:
The first is monitoring.
The second is intelligence.
And intelligence is what enables action.
The Nuvei order is particularly instructive because it doesn't merely say "monitor your merchants."
It gets much more specific.
Among other requirements, it calls for policies and procedures reasonably designed to identify certain prospective merchants and requires information concerning the nature of the merchant's business, including the goods and services sold and methods of sale.
The FTC's announcement also says the order requires Nuvei to screen and monitor existing and prospective clients and conduct enhanced screening and investigation for certain existing clients when chargeback rates exceed specified limits.
Read that again.
Existing and prospective clients.
That distinction matters.
This isn't simply:
Know Your Merchant before onboarding.
It's also:
Continue knowing your merchant after onboarding.
That is the operating-model shift I believe the industry needs to pay attention to.
This may be the biggest weakness in traditional merchant risk management.
A merchant submits an application.
KYB is completed.
Ownership is verified.
Websites are reviewed.
Products or services are evaluated.
Underwriting approves the account.
A merchant file is created.
And then the business keeps moving.
Six months later:
The website may be different.
The product catalog may be different.
The marketing may be different.
The ownership structure may have changed.
The fulfillment model may have changed.
New domains may exist.
New sales channels may exist.
Complaints may be accumulating.
A new regulated product category may have been introduced.
The merchant may have changed how it acquires customers.
Affiliates may be making claims the merchant never made during underwriting.
None of that necessarily changes the merchant's EIN.
Or its MCC.
Or its original application.
Static identity can hide dynamic risk.
That's why periodic merchant files and continuous commerce are increasingly incompatible.
Payments has historically been good at learning from enforcement.
A major action occurs.
Legal reviews it.
Compliance circulates a memo.
Policies get updated.
Training is conducted.
A new checkbox appears somewhere.
Everyone moves forward.
Until the next enforcement action.
That's reactive compliance.
The better question is:
What control weakness are these cases exposing before it becomes our case?
If I were sitting in a boardroom today, I would want answers to five questions.
1. Can we continuously identify what our merchants are actually doing?
Not simply what their applications said they intended to do.
What are they doing today?
2. Can we detect meaningful change?
If the business, website, products, claims, ownership, reputation or operating model changes, will we know?
3. Can we connect those changes to our policies?
Finding something is useless if nobody knows whether it matters.
4. Can we prove what we knew and what we did?
What was detected?
When?
By what system?
Who reviewed it?
What decision was made?
Was remediation required?
Did the merchant remediate?
Was the issue reverified?
5. Can we do all of this across the entire portfolio?
Because a monitoring program that works for 500 merchants but collapses at 50,000 isn't an enterprise control.
It's a pilot.
Banks and processors already have enormous amounts of merchant data.
Applications.
KYC.
KYB.
Transaction histories.
Chargebacks.
Fraud alerts.
MATCH results.
Web scans.
Documents.
Licenses.
CRM records.
Emails.
Risk scores.
Adverse media.
Compliance notes.
The problem is that much of it exists in different systems, at different points in time, with different owners.
We don't have a merchant-data shortage.
We have a merchant-intelligence fragmentation problem.
Sales knows one version of the merchant.
Underwriting knows another.
Risk knows another.
Compliance knows another.
Operations knows another.
The processor has information.
The sponsor bank has information.
The merchant has information.
The monitoring vendor has information.
But who has the continuously updated truth?
That question becomes extremely important when a regulator asks:
What did you know?
The natural reaction is to buy more monitoring.
More website monitoring.
More adverse media.
More fraud monitoring.
More transaction monitoring.
More sanctions screening.
More chargeback alerts.
More AI.
But there's a danger here.
More monitoring can simply create more noise.
If 100,000 merchant observations generate 10,000 alerts that analysts can't reasonably investigate, we haven't solved the problem.
We've digitized the backlog.
The goal shouldn't be maximum alert generation.
It should be maximum risk understanding.
That requires context.
Connection.
Prioritization.
Policy.
Workflow.
Resolution.
Evidence.
And continuous learning.
That is why I believe Merchant Intelligence must become the layer connecting the systems we already have.
At Qredible, we have been working from a simple premise:
Merchant Intelligence shouldn't stop after onboarding.
Commerce doesn't.
Qredible's Merchant Intelligence Operating System™ is designed around six continuous functions:
KNOW → EVALUATE → RESOLVE → MONITOR → PROVE → ENABLE
Qredible publicly describes MIOS as a connected platform spanning Merchant IQ, Q-Trust™, Merchant Risk Intelligence™, Q-Portal™, Q-Monitor™, Q-Audit™, MyCOA®, Q-Certified™ and Q-Commerce™, designed to provide continuous intelligence across the merchant lifecycle.
The important part isn't the individual technology.
It's the operating model.
Because each of those six functions answers a different question raised by the enforcement environment we're discussing.
Do we actually understand this merchant?
Identity.
Ownership.
Business model.
Websites.
Products.
Services.
Marketing.
Licenses.
Evidence.
Reputation.
Sales channels.
Relationships.
Historical activity.
Qredible defines Merchant Intelligence as the continuous collection, validation, monitoring and contextual understanding of merchant information throughout the lifecycle—not simply a one-time report.
This is where traditional KYB becomes the beginning of merchant understanding rather than the end.
Does what we know create risk?
Information without context doesn't answer that.
Merchant Intelligence needs to be evaluated against:
Regulation.
Card-brand requirements.
Sponsor-bank requirements.
Processor policy.
Product rules.
Jurisdiction.
Risk appetite.
Historical behavior.
That is particularly important in regulated commerce, where knowing the merchant may not tell you whether an individual product, ingredient, claim or method of sale creates a problem.
Qredible's Q-Trust is designed to evaluate merchants at the product level, including product classification, licensing, documentation, marketing claims, jurisdictional rules and continuous change.
What happens after we find something?
This is where many monitoring programs quietly fail.
Finding an issue is not resolving an issue.
Someone must:
Contact the merchant.
Explain the finding.
Request evidence.
Assign responsibility.
Establish deadlines.
Track remediation.
Escalate failures.
Document decisions.
Confirm resolution.
Monitoring without remediation is just observation.
Did anything meaningful change?
Not next year.
Not at annual review.
Continuously.
Qredible's model is built around ongoing intelligence rather than isolated merchant events, with Q-Monitor and related capabilities designed to detect meaningful merchant, website, product, regulatory and reputational changes.
Because the risk that matters tomorrow may not exist today.
This may become one of the most important functions of all.
Can you prove that your control environment actually operated?
Policies aren't proof.
A vendor contract isn't proof.
A screenshot isn't proof.
Saying "we monitor merchants" isn't proof.
Organizations need defensible evidence showing:
What was known → What changed → What was detected → What was evaluated → What action occurred → What was resolved → What remained monitored.
That creates something far more valuable than a merchant file.
It creates an evidence trail of diligence.
And if scrutiny ever comes, that history matters.
This is the piece compliance conversations frequently miss.
Better intelligence shouldn't simply help institutions terminate more merchants.
It should help them support legitimate merchants more confidently.
That's the ultimate opportunity.
When institutions understand risk with greater precision, they can distinguish:
Compliant from noncompliant.
Transparent from opaque.
Manageable from unacceptable.
Known risk from unknown risk.
That allows institutions to support markets that less capable organizations may simply decline altogether.
Qredible's MIOS positioning reflects that broader goal: continuous Merchant Intelligence supporting underwriting, compliance, portfolio management and stronger merchant relationships rather than treating intelligence as a one-time risk function.
The objective isn't more compliance.
It's more intelligent commerce.
I wouldn't wait for another enforcement action.
Processors, PayFacs, ISOs, merchant-of-record platforms and sponsor banks should conduct a serious assessment of their merchant-intelligence environment now.
Start with the questions these cases naturally raise:
Inventory what you actually monitor.
Don't accept "we have monitoring." Document exactly which merchant attributes, behaviors, websites, products, services, principals, transaction signals, complaints, licenses, marketing practices,
reputation signals and other material changes are monitored—and which aren't.
Map every signal to an owner.
When something changes, who receives it? Who decides whether it matters? What is the SLA? What causes escalation?
Test your systems against real merchants.
Select merchants that have been processing for one, two or three years. Compare what you approved with what exists today.
The results may be uncomfortable.
That's useful.
Examine your blind spots.
Products. Affiliates. New URLs. Claims. New business models. Fulfillment. Subscription practices. Related entities. Ownership changes. Complaints. Regulatory actions. Merchant relationships.
Ask what your existing systems cannot see.
Connect monitoring to policy.
A system shouldn't merely say something changed. Wherever feasible, it should help determine whether the change matters under your rules.
Build remediation into the operating model.
Detection → Investigation → Merchant Engagement → Resolution → Verification → Evidence.
Create an evidence architecture.
You should be able to reconstruct why a decision was made months or years later without searching through inboxes and shared drives.
And finally:
Give executive leadership portfolio-level Merchant Intelligence.
Boards shouldn't need to see every alert.
They need to understand whether the institution's merchant-control environment is functioning.
What risks are emerging?
Where are concentrations developing?
What changed?
What isn't being resolved?
Where are monitoring gaps?
How quickly are exceptions being addressed?
Where does the institution lack visibility?
That's the board-level conversation.
Forget dashboards for a moment.
Forget technology.
Imagine sitting across the table from a regulator or investigator.
They place a merchant in front of you.
And they ask:
When did you onboard them?
You answer.
What did they sell?
You answer.
What did their website say?
You answer.
Then:
When did that change?
Silence.
When did you detect it?
Silence.
What did your monitoring system flag?
Silence.
Who investigated it?
Silence.
What did the merchant say?
Silence.
What remediation occurred?
Silence.
Where is the evidence?
That is the scenario payment executives should be thinking about.
Because the most dangerous question may no longer be:
"Did you know?"
It may be:
"Why didn't your systems know?"
Paddle should have gotten the industry's attention.
Nuvei should have intensified it.
Humboldt should make the boardroom pay attention.
Again, these are distinct matters with distinct allegations, facts and orders. They do not establish that every processor has the same obligations or that any particular monitoring technology is
legally required.
But they illuminate something important about the direction of risk.
The merchant lifecycle cannot end at approval.
Monitoring cannot simply mean watching transactions.
Compliance cannot simply mean collecting documents.
And knowing the merchant cannot simply mean knowing who signed the application.
Modern payment companies need to understand:
Who the merchant is.
What the merchant does.
What the merchant sells.
How the merchant sells it.
What changed.
Whether the change matters.
What action was taken.
And whether they can prove it.
That is Merchant Intelligence.
And increasingly, I believe it belongs in the boardroom.
Three enforcement actions shouldn't cause the payments industry to panic.
They should cause it to look inward.
Because the lesson isn't that every merchant represents hidden fraud.
The lesson is that merchant risk changes continuously while much of our control infrastructure remains point-in-time.
That gap is where blind spots grow.
The next generation of merchant risk management won't be built around more merchant files, more spreadsheets, more periodic reviews or more disconnected alerts.
It will be built around a continuous operating model:
KNOW.
EVALUATE.
RESOLVE.
MONITOR.
PROVE.
ENABLE.
The FTC actions involving Paddle, Nuvei and Humboldt give the payments industry an opportunity to examine its systems before another case forces the conversation.
The question for every processor, PayFac, acquirer and sponsor bank isn't simply:
Are we monitoring our merchants?
It's:
If something important changes tomorrow, will we know?
And perhaps even more importantly:
Can we prove what we did about it?
That is the difference between having merchant monitoring and having a Merchant Intelligence operating system.
Qredible is redefining merchant underwriting through Merchant Risk Intelligence (MRI)—a product-first approach that continuously analyzes what businesses sell, how they market those products, and the evidence required to support compliant payment acceptance. By moving beyond static industry classifications, Qredible helps banks, payment processors, ISOs, and sponsor banks make faster, more informed, and more defensible underwriting decisions while reducing manual effort and strengthening ongoing portfolio oversight. Learn more about Qredible's product-first automated compliance management platform for regulated industries →
