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, ...
The payments industry is receiving two messages that, at first glance, appear to contradict each other.
Know your merchants better. Monitor them more closely. Identify misconduct. Investigate warning signs. Act when risk becomes unacceptable.
And now:
Be careful when you deny customers access to financial services.
In March, Federal Trade Commission Chairman Andrew Ferguson sent warning letters to four of the largest financial infrastructure and payment companies in the world: PayPal, Stripe, Visa and Mastercard. The letters addressed concerns about "debanking" and reminded the companies of potential obligations under Section 5 of the FTC Act.
The FTC specifically focused on allegations involving customers losing access to financial services because of political or religious views. The agency warned that denying access in ways inconsistent with customers' reasonable expectations may, depending on the facts, raise concerns under the FTC Act.
This deserves attention on its own.
But place it beside the FTC's more recent actions involving Nuvei and Humboldt Merchant Services, and something much bigger comes into focus.
In the Nuvei matter, the FTC alleged that the processor opened and maintained accounts for merchants it "knew or should have known" were engaged in deception. The resulting order requires merchant screening and monitoring, including enhanced investigation under specified circumstances.
Days later, the FTC alleged that Humboldt processed for more than 1,000 shell entities serving as fronts or pass-throughs for fraudulent companies and that it knew—or consciously avoided knowing—about certain misconduct. Humboldt agreed to $12 million in consumer redress and significant restrictions on future processing.
These are different matters involving different legal theories and facts. They should not be combined into a new legal standard that the FTC itself has not announced.
Operationally, however, the message for the payments industry is difficult to ignore:
You may increasingly need to prove not only that you managed merchant risk—but why you made the decisions you made.
And that changes the conversation around Merchant Intelligence.
Think about the position of a payment processor, PayFac, acquirer, sponsor bank or merchant-of-record platform.
When a problematic merchant remains in the portfolio, the questions can be:
Why didn't you identify the merchant?
What warning signs existed?
Why weren't they investigated?
What were you monitoring?
Why didn't you act sooner?
Nuvei and Humboldt illustrate how uncomfortable those questions can become when regulators believe warning signs should have received greater attention.
But terminating or restricting a customer can create another set of questions:
Why did you take action against this customer?
What policy did they violate?
What objective evidence supported the decision?
Was the policy disclosed and applied consistently?
What did you communicate to the customer?
Was there an opportunity to provide additional information or remediate where appropriate?
Can you reconstruct the decision months or years later?
That's the paradox.
Payment companies are being pushed toward greater oversight while simultaneously facing scrutiny over how financial access decisions are made.
The answer cannot be less monitoring.
And the answer cannot simply be more terminations.
The answer is better intelligence.
For decades, financial institutions have relied heavily on broad classifications.
High risk.
Reputational risk.
Restricted business.
Prohibited industry.
Elevated risk.
Enhanced due diligence.
Those classifications have legitimate uses. An institution has every reason to establish a risk appetite and determine what commerce it is prepared to support, subject to applicable law.
But classifications alone don't necessarily explain why a specific merchant represents a specific risk at a specific moment in time.
That's where the industry needs to evolve.
Consider the difference between these two decisions.
Decision A:
Now compare that with:
Decision B:
Both institutions may ultimately reach the same decision.
But only one has created a defensible intelligence trail explaining how it got there.
That distinction is going to matter.
An MCC isn't intelligence.
An industry label isn't intelligence.
A risk score by itself isn't intelligence.
A website screenshot isn't intelligence.
A folder full of documents isn't intelligence.
These things are inputs.
Merchant Intelligence begins when those inputs are connected and contextualized.
It should help an institution answer:
That's a fundamentally different operating model from assigning a risk category and putting documents into a merchant file.
This conversation becomes particularly interesting in product-driven regulated industries.
Traditional payments infrastructure generally evaluates these businesses at the merchant level.
But the actual compliance issue may exist at the product level.
Imagine a specialty retailer selling 3,000 products.
Perhaps 2,940 are completely within policy.
Thirty require additional documentation.
Twenty have issues requiring remediation.
Ten violate the institution's policy.
If your technology can only classify the merchant, your choices are crude:
Approve everything.
or
Terminate everything.
Product Intelligence creates another possibility.
Identify and manage the actual risk.
That means understanding which products create the problem, what evidence exists, which policy applies and whether the issue can be remediated without eliminating the entire merchant relationship.
This is what we refer to at Qredible as Risk Precision™.
And in an environment where institutions may face scrutiny for both failing to manage merchant risk and the basis for restricting access, precision becomes incredibly valuable.
This may be one of the least discussed benefits of Product Intelligence.
We typically think about compliance technology as a way to identify more risk.
But better intelligence can also help institutions identify where risk doesn't exist.
Consider a merchant labeled:
NUTRACEUTICALS — HIGH RISK
That category doesn't tell the institution whether the merchant's 500 products comply with its policies.
Likewise:
HEMP
doesn't tell us which cannabinoids are present, whether applicable documentation exists, what claims are being made or whether each product falls inside the institution's requirements.
FIREARMS
doesn't tell us which products are being sold.
VAPE
doesn't tell us the regulatory status of each product.
Without deeper intelligence, institutions may have little choice but to make decisions at the category level.
With Product Intelligence, the institution can potentially move from:
Industry → Assumption → Decision
to:
Merchant → Product → Evidence → Regulation → Policy → Decision
That's not weaker risk management.
It's stronger risk management with greater precision.
And greater precision can potentially allow financial institutions to support legitimate commerce they might otherwise simply avoid.
Suppose the technology identifies a violation.
What happens next?
This is where another major weakness exists in traditional compliance infrastructure.
A finding may generate an email.
Someone contacts the merchant.
The merchant sends a PDF.
An analyst saves it somewhere.
Someone makes a note in the CRM.
Operations receives a ticket.
The merchant makes a change.
Someone checks the website.
Another email gets sent.
Eventually the issue is considered closed.
Sixteen months later, an auditor asks:
"Why did you make this decision?"
And everyone starts searching.
Email.
CRM.
Shared drives.
Compliance folders.
Ticketing systems.
Underwriting notes.
Merchant portals.
Slack or Teams.
PDFs.
Screenshots.
People's memories.
The problem isn't that the organization did nothing.
The problem is that the evidence of what it did is fragmented across the organization.
That isn't just inefficient.
It creates governance risk.
Imagine instead that every material merchant exception creates a structured digital record.
A product or merchant issue is detected.
The evidence supporting the finding is preserved.
The applicable policy is identified.
The merchant is notified.
Information or remediation is requested.
The merchant responds.
Supporting evidence is uploaded.
The response is evaluated.
Remediation occurs.
The institution verifies it.
The issue is either resolved or escalated.
The final decision is documented.
Monitoring continues.
Now the institution has something much more valuable than an alert.
It has an auditable decision history.
The chain becomes:
FINDING → EVIDENCE → POLICY → COMMUNICATION → REMEDIATION → VERIFICATION → DECISION
That is what modern compliance infrastructure should look like.
This is something I believe the payments industry has historically underestimated.
Merchant communication is often treated as customer service.
In a modern compliance environment, it can also become evidence.
Consider the difference between these two records.
The first says:
The second shows:
March 3: Product compliance exception detected.
March 4: Merchant notified through compliance portal.
March 4: Applicable policy and affected products provided.
March 10: Merchant uploaded requested documentation.
March 11: Documentation evaluated.
March 12: Four products cleared; two remained outside policy.
March 12: Merchant asked to remove two products.
March 14: Merchant confirmed removal.
March 15: Website and catalog reverified.
March 15: Exception closed.
That isn't simply better merchant service.
That's evidence that your compliance program actually operated.
Now imagine the opposite outcome.
The merchant refuses to remediate.
The same record shows the institution clearly identified the issue, communicated it, provided an appropriate opportunity to respond, evaluated the response and ultimately took action consistent with policy.
The institution can explain why.
That's enormously valuable.
Traditional compliance systems are excellent at recording outcomes.
Approved.
Declined.
Restricted.
Suspended.
Terminated.
But outcomes alone aren't enough.
The more important question is often:
Why?
Why was the merchant approved?
Why was it considered high risk?
Why did the risk classification change?
Why did a product fail?
Why was remediation required?
Why was remediation accepted?
Why was the merchant ultimately terminated?
Why was another merchant in the same category allowed to remain?
The answer should not depend on finding the employee who made the decision two years ago.
It should exist in the system.
We often think about audit trails as something compliance teams need after the fact.
I think that's too narrow.
An auditable intelligence environment can improve the actual decision-making process.
It forces the organization to connect:
Evidence to findings.
Findings to policy.
Policy to decisions.
Decisions to communication.
Communication to remediation.
Remediation to verification.
That creates discipline.
It also creates consistency.
If two merchants present substantially similar facts, the institution should be able to understand why they received similar—or different—treatment.
That becomes increasingly important when questions arise about whether policies are being applied consistently.
The payments industry has spent decades building merchant files.
Maybe what we need now is something fundamentally different.
A Merchant Intelligence Ledger.
Not blockchain.
Not another document repository.
A persistent digital history of the merchant relationship.
It would answer:
What did we know?
When did we know it?
How did we know it?
What evidence supported it?
Which policy applied?
What changed?
What did we communicate?
How did the merchant respond?
What remediation occurred?
Who made the decision?
Why was that decision made?
What happened afterward?
That is dramatically more useful than a static merchant file.
Because the merchant isn't static.
Neither is the risk.
Look at the questions emerging from the FTC's recent payment-related activity.
The Nuvei case puts attention on merchant screening and monitoring. The FTC's September announcement says the resulting order requires Nuvei to screen and monitor existing and prospective clients, with enhanced screening and investigation under specified circumstances.
The Humboldt case puts attention on warning signs and alleged conscious avoidance. The FTC alleged that Humboldt processed for shell merchants despite red flags and unusually high chargeback activity.
And the March letters to PayPal, Stripe, Visa and Mastercard put attention on the other side of the relationship: how financial-service providers make and implement decisions restricting customer access.
Again, these matters should not be conflated legally.
But operationally they create an extraordinary set of questions for payment companies:
Those five questions could define the next generation of merchant compliance.
At Qredible, we have been thinking about this problem as an operating-system problem rather than a point-solution problem.
Merchant risk isn't one event.
It's a lifecycle.
That is why the Merchant Intelligence Operating System™ is organized around six continuous functions:
KNOW → EVALUATE → RESOLVE → MONITOR → PROVE → ENABLE
Each one addresses a different piece of the problem.
KNOW
Understand the merchant beyond identity verification.
Who are they?
What do they do?
What websites do they operate?
What products do they sell?
What evidence supports those products?
What licenses exist?
What claims are being made?
What other entities, domains or businesses are connected?
Know Your Merchant increasingly needs to include Know Your Product.
EVALUATE
Information has to be interpreted.
What regulations apply?
What does the sponsor bank permit?
What does the processor permit?
What do card-brand rules require?
What does institutional policy say?
Which specific facts create the exception?
Risk should become the output of intelligence, not simply an assumption made at the beginning.
RESOLVE
Finding problems isn't enough.
The merchant needs a structured mechanism to understand findings, provide evidence, correct information and remediate issues where appropriate.
Every meaningful interaction should become part of the record.
MONITOR
The merchant approved yesterday isn't necessarily the merchant operating today.
Products change.
Websites change.
Marketing changes.
Ownership changes.
Documentation expires.
Regulation changes.
Policies change.
Merchant Intelligence has to continuously detect meaningful change.
PROVE
This may become one of the most strategically important functions.
Can the institution demonstrate:
What was known → What changed → What was detected → What policy applied → What was communicated → What was remediated → Why the decision was made?
That's the difference between claiming to have controls and demonstrating that the controls actually operated.
ENABLE
This is where the entire model comes together.
Better compliance intelligence should not simply help institutions identify more reasons to say no.
It should help them identify more situations where they can responsibly say yes.
That's the point of Risk Precision.
The FTC's March warning letters do not prohibit legitimate risk-based account restrictions, nor do they prescribe a specific merchant-monitoring technology. The letters concern potential Section 5 issues and should be evaluated with counsel in the context of each institution's actual practices and obligations.
But payment companies don't need to wait for another enforcement action or warning letter to improve their operating models.
There are several questions leadership teams should be asking now:
The goal isn't to make merchant termination harder.
The goal is to make merchant decisions better informed, more consistent and more defensible.
The debanking conversation can easily become political.
Payment companies shouldn't allow that to distract from the operational lesson.
Financial institutions have legitimate responsibilities to manage fraud, compliance, regulatory, credit, reputational and operational risk.
They also operate enormous networks that legitimate businesses depend upon to participate in commerce.
Those two realities have to coexist.
The answer isn't eliminating risk controls.
And the answer isn't indiscriminately opening every account.
The answer is building the intelligence necessary to distinguish:
Known risk from assumed risk.
Merchant risk from industry risk.
Product risk from merchant risk.
Compliant activity from noncompliant activity.
Remediable problems from unacceptable problems.
Legitimate commerce from deceptive commerce.
That's a much more sophisticated model.
But that's where payments needs to go.
Perhaps the biggest shift in thinking is this:
Historically, compliance technology has largely been designed to help financial institutions find reasons to say no.
What if the next generation also helps institutions defend yes?
Imagine a merchant in a category traditionally considered high risk.
Instead of simply accepting or rejecting the category, the institution can demonstrate:
The merchant has been identified.
The products have been evaluated.
Required documentation exists.
Licensing has been verified.
Exceptions have been identified.
Remediation has occurred.
Policies have been satisfied.
Material changes are continuously monitored.
Evidence is retained.
The institution isn't blindly accepting risk.
It understands the risk.
That's very different.
And it may be one of the most important capabilities the payments industry develops over the next decade.
The FTC's recent activity creates a fascinating moment for payments.
Nuvei tells us to think seriously about what payment companies should know about merchants.
Humboldt tells us to think about what happens when warning signs allegedly aren't acted upon.
And the letters to PayPal, Stripe, Visa and Mastercard remind the industry that decisions restricting financial access can themselves attract scrutiny.
The future isn't simply:
MONITOR MORE.
And it certainly isn't:
TERMINATE MORE.
It's:
UNDERSTAND MORE.
Know the merchant.
Know the product.
Know the evidence.
Know the policy.
Know what changed.
Know what was communicated.
Know what was remediated.
Know why the decision was made.
And be able to prove all of it.
Because the next question from a regulator, auditor, sponsor bank, merchant—or your own board—may not simply be:
"What did you do?"
It may be:
"Show me why."
And if answering that question requires digging through email, spreadsheets, PDFs, screenshots, shared drives and people's memories, the industry still has work to do.
The future of merchant risk management is not simply better monitoring.
It's Merchant Intelligence™ + Product Intelligence™ + Policy Intelligence + Merchant Communication + Auditable Evidence.
That is how payments can become better at identifying the merchants it shouldn't support without unnecessarily excluding the merchants it should.
And that may be one of the most important applications of Merchant Intelligence yet.
Qredible is redefining merchant underwriting through Merchant Intelligence Operating System (MIOS)—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 →
