Underwriting merchant risk using a MCC code derived from an audit 6 months ago is inadequate in today's dynamic commerce market. Product Intelligence from Qredible looks beyond the industry MCC code and assesses risk at the product level - continuously.

Payments Has a Product Problem Nobody Wants to Own

Author: Noah Fitzgerald, CPP
Date: September 10, 2026

Payments Has a Product Problem Nobody Wants to Own

The Next Compliance Infrastructure Battle Won't Be About Knowing the Merchant. It Will Be About Knowing What the Merchant Sells.


Noah Fitzgerald, CPP - Chief Revenue Officer, Qredible, Inc.Next week, thousands of people from across the payments ecosystem will gather to discuss what's changing in our industry and what comes next. There will be conversations about AI, agentic commerce, stablecoins, embedded payments, fraud, faster payments, orchestration, new forms of acceptance, and the changing regulatory environment.

All of these topics deserve attention. But there is another massive issue sitting directly in front of the payments industry that I believe receives far too little discussion:

We still don't really know what our merchants are selling.

I'm not talking about what industry they're in, what their MCC says, what they disclosed on an application, or what their website looked like when underwriting reviewed them 18 months ago.

I mean something much more specific:

  • What products are our merchants actually selling today, and do those products comply with the regulations and institutional policies governing the commerce we're enabling?

For a growing number of industries, that is becoming a very difficult question to answer.

I believe solving it will become one of the next major infrastructure shifts in payments.


We Have Intelligence Around Almost Everything Except the Product

Think about how sophisticated payments technology has become.

We can validate identities in seconds. We can verify businesses against enormous databases, screen owners against sanctions and watchlists, analyze transaction patterns across massive portfolios, identify suspicious behavior, monitor chargebacks, evaluate devices and bank accounts, search adverse media, and use machine learning to recognize patterns humans would never detect on their own.

We've spent billions building intelligence around people, businesses and transactions.

But ask a processor a seemingly simple question:

  • “Show me every product currently being sold across your portfolio that violates your sponsor bank's policy.”

For most organizations, that's not a database query.

That's an audit project.

It means identifying merchants, crawling websites, reviewing products, collecting documents, evaluating evidence, comparing findings against policy, contacting merchants, remediating violations and then checking everything again.

That should tell us something.

We don't have a shortage of merchant data.

We have a product intelligence gap.


We Know the Merchant. But Do We Know the Commerce?

For decades, merchant risk has been organized primarily around the merchant. We perform KYC and KYB, assign an MCC, evaluate ownership, understand the business model, assess financial history, review the website and monitor transaction behavior.

Those things remain critically important.

But modern merchants are no longer simple businesses selling a predictable set of products within clearly defined industries. One merchant can represent hundreds or thousands of products, brands, manufacturers, ingredients, claims, documents and regulatory relationships.

Consider what can happen after underwriting:

  • A mainstream retailer introduces a single problematic product.
  • A restaurant adds hemp-derived beverages to its menu.
  • A convenience store begins carrying unauthorized vape products.
  • A health and wellness business introduces supplements containing problematic ingredients.
  • An e-commerce merchant adds hundreds of new products without changing its legal entity.
  • A marketplace seller begins offering a regulated product that wasn't present when the seller was originally approved.

Nothing fundamental about the merchant record necessarily changed.

The merchant ID didn't change.

The MCC didn't change.

Ownership didn't change.

The bank account didn't change.

Transaction behavior might look completely normal.

But the risk changed.

And much of the infrastructure we've traditionally built in payments is looking somewhere else.


This Isn't Just a “High-Risk Merchant” Problem

This is where I believe the industry's traditional thinking becomes particularly problematic.

Mention CBD, hemp, vape, kratom, peptides or mushrooms and the immediate reaction is often:

High risk.

These merchants get special underwriting requirements, additional documentation, higher pricing, enhanced monitoring, or they simply aren't accepted.

But consider what happens when the exact same product appears inside a merchant that isn't classified as high risk.

If a CBD merchant sells a hemp-derived beverage, the product may receive significant scrutiny. But what happens when that same beverage is sold by a restaurant, liquor store, golf course, hotel, or convenience store?

Where did the product risk go?

It didn't go anywhere.

Our classification system simply stopped looking for it.

This is one reason I believe the traditional distinction between “high-risk” and “low-risk” merchants is becoming increasingly inadequate.

Products don't care which MCC we assigned the merchant, and regulations generally don't become irrelevant because a regulated product represents only a small percentage of a merchant's overall business.

The product exists regardless of the merchant category surrounding it.


Regulation Is Moving Deeper Into the Product

The challenge becomes even more significant because many compliance requirements depend on characteristics that exist below the merchant level.

Depending on the category and applicable rule, determining whether a product is supportable may require answering questions such as:

  • What ingredients or compounds are present?
  • At what concentrations?
  • What does laboratory testing demonstrate?
  • When was the testing performed?
  • Does the evidence actually correspond with the product being sold?
  • What claims are being made about the product?
  • Where is it being sold?
  • Does the merchant or product require licensing?
  • Does it satisfy applicable federal and state requirements?
  • Does it meet the sponsor bank's policy?
  • Does it meet the processor's own policy?
  • Has anything changed since the product was last reviewed?

Those aren't simply merchant-level questions.

They are product-level compliance questions.

And this creates a fundamental mismatch in the payments ecosystem:

  • Regulation can operate at the product level while payment compliance still operates primarily at the merchant level.

Eventually, that gap has to close.


The Merchant Is No Longer the Smallest Unit of Risk

Our legacy risk architecture has generally worked something like this:

Portfolio → Merchant → MCC/Industry → Risk Classification → Policy

That model was useful when broad merchant classifications were reasonable proxies for the commerce taking place inside the business.

Modern commerce requires something deeper.

Increasingly, we need to understand:

Portfolio → Merchant → Business Model → Product → Ingredient/Attribute → Evidence → Regulation → Institutional Policy → Compliance Status

That doesn't mean abandoning merchant-level risk.

It means recognizing that the merchant is no longer always the smallest meaningful unit of risk.

For many regulated industries, the product is.


This Is Why Policy Changes Become So Painful

This product intelligence gap becomes painfully obvious when a sponsor bank, regulator, state government, card brand or internal risk committee changes a policy.

Updating the policy itself is relatively straightforward.

The difficult question is:

  • Where does this new requirement intersect with our existing portfolio?

Imagine your sponsor bank announces tomorrow that any merchant selling products containing Compound X must satisfy Requirement Y.

Your compliance team now needs to:

  • Identify every merchant selling products containing Compound X.
  • Identify every affected product.
  • Validate the supporting evidence for those products.
  • Evaluate each product against the new requirement.
  • Identify violations.
  • Contact affected merchants.
  • Manage remediation.
  • Verify that remediation actually occurred.
  • Preserve evidence demonstrating what was done.
  • Continue monitoring so the product or violation doesn't return.

If accomplishing that requires assembling an audit team, opening thousands of websites and reviewing thousands of PDFs, then we don't really have product compliance infrastructure.

We have a labor strategy.


Every Regulatory Change Shouldn't Require Another Audit

This is where the problem compounds.

A rule changes, so we launch an audit.

We identify products, collect documents, inspect websites, contact merchants, remediate violations and close the project.

Six months later another rule changes.

And we essentially do it again.

Why?

Because much of the intelligence created during the previous audit wasn't captured in a structured way that could answer the next question.

We identified products but didn't necessarily create persistent product identities.

We reviewed COAs but didn't digitize all of the relevant laboratory information.

We evaluated ingredients but didn't necessarily make those ingredients searchable across the portfolio.

We reviewed compliance but didn't connect the findings to machine-readable policy.

The result is that when the next requirement changes, we reopen the websites, PDFs and spreadsheets.

We're paying humans to rediscover information our organizations already paid humans to discover.

That operating model simply isn't sustainable.


The COA Problem Makes This Impossible to Ignore

Certificates of Analysis and laboratory reports provide one of the clearest examples.

For CBD, hemp and certain other regulated products, processors may collect enormous numbers of laboratory reports. An underwriter opens the document, reviews testing results, checks dates, performs calculations, evaluates applicable thresholds, attempts to match the report with the product, and makes a compliance determination.

Then the PDF is stored.

The problem is that much of the intelligence remains trapped inside the document.

Now imagine a regulation or bank policy changes one of the thresholds used in that original review.

If the underlying laboratory information was digitized, the organization could potentially query the data and immediately identify affected products.

If it wasn't?

Someone has to read the reports again.

The COA should remain the source evidence.

But the information contained inside it needs to become persistent, searchable intelligence.


A New Generation of Risk Technology Is Emerging

The encouraging news is that payments technology is beginning to move in this direction.

Companies such as Coris, Ballerine, and Under are demonstrating how AI, automation, website intelligence and data orchestration can transform merchant underwriting and risk management.

These emerging platforms are important because they fundamentally change how underwriting teams interact with information. Instead of requiring highly trained people to manually assemble every piece of information necessary to understand a merchant, technology can increasingly collect, extract, classify, compare, monitor and summarize information before surfacing exceptions for human judgment.

That's a major advancement.

But I believe another layer of technology is now emerging beneath traditional Merchant Intelligence:

Product Intelligence™.

And this could prove equally consequential.


The Emergence of Product-Level Compliance Infrastructure

I believe we're going to see a new infrastructure category emerge across regulated commerce:

Product-Level Compliance Infrastructure.

I define it as:

  • Technology that continuously identifies the products being sold through commerce, connects those products to supporting evidence, evaluates them against applicable regulation and institutional policy, detects changes, and maintains an auditable record of compliance over time.

Think about the difference.

Traditional merchant information might tell us:

Merchant sells CBD products.

Product Intelligence should be able to tell us something closer to:

The merchant sells 137 products. Ninety-four require COAs. Ninety-one have current supporting evidence. Three require attention. These products contain these cannabinoids. These laboratory reports correspond with these products or batches. These marketing claims were identified. These institutional policies apply. These products currently meet policy. These don't.

And when something changes, the system should tell us.

That is a fundamentally different level of visibility.


From KYC to KYP

The evolution makes sense when we look at how financial services has progressively expanded what it needs to know.

KYC — Know Your Customer: Who is the person?

KYB — Know Your Business: Is this a legitimate business?

KYM — Know Your Merchant: What kind of merchant are we actually dealing with?

The next layer is increasingly:

KYP — Know Your Product: What exactly are they selling?

KYP doesn't replace KYC, KYB, transaction monitoring, fraud technology or human underwriting.

It fills a different intelligence gap.

And as regulations become more product-specific, that gap becomes increasingly difficult to ignore.


Product Data Is Not Product Intelligence

This distinction is important.

Scraping a merchant's website and generating a list of product names isn't Product Intelligence.

That's product data.

Intelligence requires context.

A meaningful product record should increasingly help answer questions about:

  • Product identity and classification
  • Manufacturer or brand
  • Relevant ingredients or compounds
  • Supporting documentation
  • COAs and laboratory results
  • Licensing
  • Marketing claims
  • Applicable jurisdictions
  • Applicable regulations
  • Sponsor-bank and processor policy
  • Compliance status
  • Changes over time

Product Intelligence connects the product to the evidence, the rule and ultimately the decision.

That's where the value exists.


This Is the Problem We're Tackling at Qredible

This is precisely why we've been building Qredible around Product Intelligence.

Q-Trust™ is designed around the premise that understanding a regulated merchant requires understanding the products inside that merchant. The architecture moves below the merchant level to connect product discovery, evidence, regulatory intelligence, institutional policy, compliance status and ongoing monitoring.

But I believe this issue is much bigger than Qredible.

The payments ecosystem itself increasingly needs this capability.

Whether the infrastructure ultimately comes from specialized technology providers, acquiring platforms, sponsor banks, card brands, marketplaces—or some combination of all of them—the underlying problem isn't going away.

Commerce is becoming more complex while regulation is becoming more granular.

We cannot expect human compliance teams to bridge that gap indefinitely through manual work.


I Believe Product-Level Compliance Will Eventually Become Required Infrastructure

I don't know exactly when.

And I don't know who will force the issue first.

It could be sponsor banks.

Card brands.

Regulators.

Acquiring banks.

Major commerce platforms.

Or another major enforcement action that causes the industry to reconsider what constitutes reasonable oversight.

But I believe the direction is increasingly difficult to avoid.

Not because Qredible says so.

Because the alternative becomes increasingly difficult to defend.

The progression of questions is fairly predictable:

“Did you underwrite the merchant?”

Yes.

“Did you know what products they were selling?”

Maybe.

“Did you know whether those products complied?”

We reviewed them during underwriting.

“Did you know the merchant added new products afterward?”

They didn't tell us.

“When the regulation changed, how did you determine which products were affected?”

We initiated an audit.

Eventually the question becomes:

  • “What controls did you have in place to know?”

That's a very different question.


Technology Changes What Is Reasonably Knowable

Twenty years ago, continuously inspecting every merchant website, product, COA, claim and relevant regulatory change would have been economically impossible.

Even ten years ago, it would have been extraordinarily difficult.

Today the technology landscape is fundamentally different.

AI, large language models, document intelligence, web crawling, machine learning, cloud computing, regulatory databases and continuous monitoring are dramatically changing what can be discovered and analyzed economically.

That doesn't mean perfect visibility is possible.

It never will be.

There will always be bad actors, incomplete information and merchant deception.

But there is a significant difference between perfect visibility and reasonable controls designed to create continuous visibility.

And that distinction matters.

Because as technology changes what is reasonably knowable, expectations around what institutions should know may eventually change with it.


Plausible Deniability Has an Expiration Date

For years, payment companies have had a legitimate explanation when merchants changed after onboarding.

The merchant was compliant when we underwrote them.

They changed their website.

They introduced the product later.

They didn't disclose it.

We didn't know.

Sometimes those statements are completely true.

But I believe the industry's reliance on that defense has a shelf life.

As technology makes continuous merchant and product visibility increasingly practical, the question becomes less about whether the institution knew at a particular moment and more about whether it maintained reasonable systems capable of detecting material changes.

“We didn't know” is very different from “we had reasonable controls designed to know.”

That difference will become increasingly important.


But This Isn't Just About Compliance

This is where the discussion becomes much more interesting from a business perspective.

Product Intelligence isn't simply defensive technology.

It can become growth infrastructure.

Payment companies frequently avoid regulated categories because supporting them requires more underwriting, more documents, more expertise, more monitoring, more remediation and greater sponsor-bank oversight.

Complexity costs money.

Eventually:

Complex Merchant → Expensive Merchant → High-Risk Merchant

But what happens when technology dramatically reduces the cost of understanding that complexity?

The economics change.

And suddenly some markets that were prohibitively expensive to underwrite and monitor manually become commercially viable.

That's not simply risk reduction.

That's market expansion.

Better Intelligence Creates Risk Precision

This does not mean accepting more risk.

It means understanding risk more precisely.

Instead of:

CBD Merchant = High Risk

a processor can move toward:

Merchant → Product → Evidence → Regulation → Policy → Actual Risk

That allows the organization to distinguish between merchants selling supportable products with strong evidence, merchants with remediable compliance issues, merchants selling prohibited products, merchants creating unacceptable financial exposure, and merchants that simply fall outside the institution's risk appetite.

Those are very different situations.

Broad classifications treat them similarly.

Intelligence doesn't have to.

  • The competitive advantage isn't necessarily greater risk tolerance. It's greater risk precision.

Risk Precision Creates Market Opportunity

Imagine two processors competing for the same regulated merchant.

One says:

  • “We don't support that vertical.”

The other says:

  • “We support specific products within that vertical when they meet defined requirements, and we have the infrastructure to continuously verify them.”

Which organization has the larger addressable market?

Which can have a more sophisticated conversation with its sponsor bank?

Which can approve legitimate merchants competitors decline?

Which can remediate rather than terminate?

Which can react faster when regulation changes?

Which can build specialized merchant programs?

Which can turn compliance services into merchant value?

Which one is positioned to grow?

That's why I believe Product Intelligence will ultimately become much more than another compliance technology.


The Product Problem Is Bigger Than Payments

Payment processors aren't the only organizations that need this intelligence.

Banks need it.

Marketplaces need it.

Commerce platforms need it.

Manufacturers need to maintain product evidence.

Laboratories need their testing connected to actual products.

Merchants need better compliance infrastructure.

Insurers and lenders may increasingly care about the same information.

Regulators need evidence.

Consumers increasingly expect transparency.

Everyone is trying to understand a different aspect of the same object:

The product.

That starts looking less like another underwriting application.

It starts looking like commerce infrastructure.


A Question to Take to Next Week's Conference

Next week we'll spend a lot of time discussing the future of payments.

We should.

But while we're talking about the next generation of commerce, I hope we also talk about the infrastructure required to safely support the commerce we're already enabling.

Because somewhere tonight an already-approved merchant is going to add a new product to its website.

Its merchant ID won't change.

Its MCC won't change.

Its ownership won't change.

Its bank account won't change.

Its transaction may look completely normal.

Its fraud score may not move.

Nothing inside the traditional merchant profile may indicate that anything happened.

But the risk just changed.

So when you're talking with risk leaders, sponsor banks, compliance teams, technology providers and card-brand representatives next week, ask them one question:

  • If I asked you right now to show me every product being sold across your merchant portfolio that violates one of your bank's policies, could you?

Not after a three-month audit.

Not after emailing merchants.

Not after hiring consultants.

Not after manually reviewing websites.

Could you identify them today?

I suspect the answer for most of the industry is no.

That's not an indictment.

It's an opportunity.


Final Thought

Payments does not have a shortage of data.

We have more data and more sophisticated technology than at any point in the industry's history.

We have identity intelligence.

Business intelligence.

Transaction intelligence.

Fraud intelligence.

Risk intelligence.

And increasingly sophisticated AI connecting all of it.

Yet beneath that enormous technology stack remains a remarkably simple question:

What are our merchants actually selling?

Followed immediately by:

Is it compliant?

Merchant Intelligence tells us who we're doing business with.

Product Intelligence tells us what commerce we're actually enabling.

The industry is going to need both.

We can wait until sponsor banks, card brands, regulators or another major enforcement event makes product-level visibility a requirement.

Or we can recognize what is already happening and build the infrastructure before we're forced to.

The biggest opportunities in payments rarely begin after everyone agrees the change is necessary.

They begin with the organizations willing to see the change first.

The next compliance infrastructure battle won't simply be about knowing the merchant.

It will be about knowing the product.

 

About Qredible

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 →



crossmenu