Underwriters Shouldn't Be Reading Lab Reports
Underwriters Shouldn't Be Reading Lab Reports The Manual COA Problem Is Becoming One of the Biggest Compliance Gaps in Regulated Payment...
| "A PDF sitting in a merchant file is not Product Intelligence. It is simply a document someone reviewed once." - Noah Fitzgerald, CPP, CRO Qredible, Inc. |
For payment processors supporting regulated-product merchants, there is a compliance problem hiding inside thousands—sometimes hundreds of thousands—of PDF files.
Certificates of Analysis.
Laboratory reports.
Testing documentation.
They arrive during underwriting. Someone opens them. Someone reviews the results. Someone attempts to match them to a product. Someone determines whether the results satisfy policy. Then the document gets stored somewhere and the merchant gets approved.
For years, this has been considered normal.
It shouldn't be anymore.
Because the real requirement isn't simply to collect a lab report.
The requirement is to understand what that report says, establish that it belongs to the product being sold, evaluate its results against applicable requirements, identify when it becomes outdated,
detect when the merchant changes products or batches, and be able to reassess all of that when regulation or policy changes.
And then do it again.
And again.
Across every relevant product.
Across every merchant.
Continuously.
That isn't document management.
It's a data and intelligence problem.
And continuing to solve it primarily with people reading PDFs may be one of the least scalable practices remaining in regulated merchant compliance.
Let's start with the misconception.
A merchant submits a Certificate of Analysis.
COA received: ✓
That tells us almost nothing.
Depending on the product and applicable requirements, somebody may still need to determine:
The exact requirements vary substantially by product, jurisdiction, institutional policy and regulatory framework.
That's precisely the point.
The PDF isn't the compliance decision.
The intelligence inside it is.
Now multiply the problem.
Suppose a CBD merchant sells 150 products.
Those products may represent different:
An underwriter isn't really reviewing one merchant.
They're potentially evaluating dozens or hundreds of product-to-evidence relationships.
Now multiply that across 500 merchants.
Or 5,000.
And we're surprised that regulated-product underwriting is expensive?
We're surprised that processors classify entire industries as “high risk”?
We're surprised compliance teams cannot continuously monitor everything?
The economics are broken because the operating model is broken.
CBD and hemp made the COA problem highly visible, but the broader issue spans regulated and emerging product categories.
Kratom provides a current example of why detailed product composition matters. FDA has focused specifically on concentrated 7-hydroxymitragynine, or 7-OH, while distinguishing those products from naturally occurring trace amounts in the kratom plant. In July 2026, FDA reported that DEA had begun a temporary scheduling process involving 7-OH above a proposed threshold and certain synthetic derivatives.
FDA laboratory testing has also previously identified significant levels of lead and nickel in certain kratom products.
Peptides demonstrate the complexity from another direction. FDA's recent materials discuss peptide-related impurities, aggregation, process-related impurities and characterization concerns, and FDA maintains information on various bulk substances that may present significant safety risks.
FDA laboratory analysis in April 2026 even identified an undeclared prescription drug ingredient in a product marketed as CBD.
The takeaway for payments isn't that every merchant selling one of these categories requires exactly the same laboratory review.
They don't.
The takeaway is:
When product composition, testing, evidence, formulation or concentration determines supportability, merchant-level information alone isn't enough.
Think about what happens today.
A COA arrives as a PDF.
An experienced analyst opens it.
They read it.
They interpret it.
They compare it against requirements.
They may perform calculations.
They inspect the merchant's product page.
They record a determination.
Then they move to the next document.
What happens to all the intelligence they just consumed?
Usually, very little.
The PDF survives.
Maybe a few fields make it into a case-management system.
Maybe someone maintains a spreadsheet.
Maybe notes are entered into the merchant file.
But most of the valuable data contained within that document remains trapped inside the PDF.
We use a highly trained human being to temporarily interpret structured scientific information—and then throw most of that intelligence away.
That should bother every compliance executive.
This is where the architecture really fails.
Imagine your sponsor bank changes its policy tomorrow.
A particular compound now has a new threshold.
Or a state modifies its requirements.
Or a previously acceptable product characteristic is no longer supportable.
Leadership asks:
“Which products in our portfolio violate the new requirement?”
If you digitized the underlying laboratory data, that could become a data query.
But if your “data” consists of 40,000 PDFs?
You have a different answer:
Read them again.
The organization already paid someone to perform the work once.
Now it pays someone to perform it again.
And when the next policy changes?
Again.
That's not compliance automation.
That's recurring manual labor.
It's the data.
This is the fundamental change the payments industry needs to understand.
A lab report should not simply be treated as a document.
It should become structured intelligence.
Imagine capturing relevant fields from each report into a normalized product record.
Now the institution can potentially query:
Show me every product containing X.
Show me products above threshold Y.
Show me testing older than Z.
Show me products without current evidence.
Show me products where the batch and COA don't match.
Show me merchants selling products affected by the new policy.
Show me products requiring remediation.
Suddenly, the COA stops being a static PDF.
It becomes part of the institution's Product Intelligence™.
That distinction is enormous.
There's another problem.
A PDF looks official.
That doesn't necessarily mean it is.
Documents can potentially be:
Altered.
Reused.
Misassociated.
Outdated.
Incorrectly matched.
Manipulated.
A merchant may also unintentionally associate the wrong report with the wrong product.
So merely possessing a COA does not answer another fundamental question:
Can we trust the evidence?
Modern compliance infrastructure should be capable of creating stronger relationships among:
Product
↓
Batch / Sample
↓
Laboratory Report
↓
Laboratory
↓
Test Results
↓
Merchant
↓
Website Product
↓
Applicable Policy
That is significantly different from attaching COA_Final_Updated_2.pdf to a merchant record.
This is another area where manual workflows become extremely difficult.
The merchant has 300 products on its website.
It submits 217 COAs.
Now someone needs to determine:
Which COA belongs to which product?
Which products have no documentation?
Which report covers multiple variations?
Which product changed?
Which product was removed?
Which new product appeared after underwriting?
Which product page is displaying outdated testing?
And perhaps most importantly:
Is the merchant actually selling the product represented by the evidence we're reviewing?
This is why the problem cannot be solved by document storage alone.
The evidence needs to be attached to a persistent digital identity for the product itself.
Let's assume everything works perfectly.
The merchant submits every required document.
Every report is reviewed.
Every product is matched.
Everything meets policy.
Merchant approved.
Congratulations.
Now what?
Tomorrow the merchant adds five products.
Next month a new batch arrives.
A COA is replaced.
Another report ages beyond your policy.
A manufacturer changes.
A product formulation changes.
A state changes its requirements.
Your sponsor bank updates policy.
The merchant changes its website.
Your beautiful underwriting review is now historical evidence.
This is the same mistake our industry repeatedly makes:
We solve continuous problems with point-in-time controls.
My previous article argued that payment companies need to stop becoming their merchants' compliance departments.
This is a perfect example.
Who should know that a COA needs updating first?
The merchant.
Who should know that a new product doesn't have supporting evidence?
The merchant.
Who should maintain the relationship between its products and laboratory reports?
The merchant.
Who should be responsible for maintaining its product compliance information?
The merchant.
The payment company still has independent obligations to verify, assess and oversee the relationship.
But the processor should not have to build the merchant's product-compliance infrastructure for it.
That infrastructure should already exist.
This isn't about shifting an unreasonable workload onto merchants.
The merchant has the same problem.
Imagine running a growing CBD, hemp, nutraceutical, kratom, mushroom or other regulated-product business.
And everybody wants some variation of the same information.
So merchants create folders.
Then someone asks for evidence and the scavenger hunt begins.
Neither side wants this workflow.
We've simply never given the ecosystem a better shared infrastructure.
Until now.
MyCOA® was designed around a very different premise:
Instead of a COA simply being uploaded and stored, MyCOA is designed to help create a structured relationship between the merchant, product and supporting compliance evidence.
That enables a fundamentally different workflow around:
The objective isn't simply to make PDFs easier to find.
It's to unlock the intelligence trapped inside them.
This is where the value becomes dramatically different.
Legacy model
Policy changes.
Product Intelligence model
Policy changes.
The compliance team hasn't disappeared.
The scavenger hunt has.
That's the transformation.
Now let's talk about the commercial opportunity.
Many processors supporting regulated merchants charge some form of monthly compliance, registration, monitoring, or risk fee.
There are legitimate reasons for doing so.
These merchants can require more underwriting.
More oversight.
More monitoring.
More personnel.
More sponsor-bank management.
That work costs money.
But think about this from the merchant's perspective.
They see:
Compliance Fee: $99
or
Compliance Fee: $199
What did they get?
Often, nothing tangible.
The fee offsets the processor's internal cost.
It doesn't necessarily give the merchant a better compliance system.
It doesn't organize its COAs.
It doesn't help maintain its products.
It doesn't help identify missing documentation.
It doesn't create customer transparency.
It doesn't help prepare for an audit.
It's a fee.
This is where the model gets much more interesting.
Instead of saying:
Imagine saying:
That is a completely different merchant conversation.
The processor can provide MyCOA as a value-added service.
The merchant gets real functional utility.
The merchant becomes better organized.
The processor receives better information.
Risk receives greater product visibility.
Underwriting becomes more efficient.
Compliance gains more structured evidence.
The sponsor bank gets a stronger control environment.
And the payment company can generate recurring revenue from providing the service.
This is the opportunity I believe payment companies are missing.
For decades, regulated compliance has been viewed almost entirely as expense.
More analysts.
More underwriters.
More reviews.
More monitoring.
More audits.
What if the infrastructure used to reduce that expense also created revenue?
Consider the alignment:
Merchant
Gets technology it actually needs.
Sales Organization
Gets a differentiated solution to offer regulated merchants.
Underwriting
Gets better-organized product information and evidence.
Risk & Compliance
Gets structured Product Intelligence.
Sponsor Bank
Gets improved transparency and auditability.
Processor
Gets a potentially cleaner portfolio, lower operational burden, stronger merchant relationships and recurring software revenue.
Everybody gets something.
That is very different from simply adding another fee.
Now take it upstream.
Instead of treating compliance technology as something imposed after a merchant applies, make it part of the merchant proposition.
Imagine telling a regulated merchant:
That's differentiation.
Especially in industries where merchants are accustomed to being treated as liabilities.
The payment company stops saying:
You're high risk, so we're charging you more.
And starts saying:
Your business is complex, so we're giving you better infrastructure.
Which relationship would you rather have?
This matters to executive leadership.
If MyCOA helps reduce:
while simultaneously creating merchant-facing recurring revenue, then the business case is no longer simply:
How much does compliance technology cost?
The question becomes:
That's a dramatically different ROI calculation.
This may be the most important question in this article.
Not:
How do you review COAs today?
Ask:
If your answer is:
We reopen the PDFs.
you don't have an intelligence system.
If your answer is:
We contact all the merchants.
you have a communication system.
If your answer is:
We hire more reviewers.
You have a labor strategy.
The goal should be:
That is where this industry needs to go.
The PDF isn't going away.
Nor should it.
It remains important source evidence.
But it should no longer be the only usable representation of the information.
The future looks like:
LAB REPORT
↓
DATA EXTRACTION
↓
DOCUMENT VALIDATION
↓
PRODUCT MATCHING
↓
STRUCTURED TEST RESULTS
↓
POLICY EVALUATION
↓
COMPLIANCE STATUS
↓
MERCHANT REMEDIATION
↓
CONTINUOUS MONITORING
↓
RE-EVALUATION WHEN RULES CHANGE
That's how you turn a point-in-time document into persistent Product Intelligence™.
And the question I would put directly in front of the executive team:
For years, there was a legitimate excuse.
The technology wasn't there.
Lab reports were unstructured.
Product catalogs were difficult to analyze.
Document extraction was unreliable.
Matching products to evidence required people.
Continuous monitoring was prohibitively expensive.
Those limitations are disappearing.
The technology has caught up with the problem.
The operating model hasn't.
That's the opportunity.
This is precisely the problem MyCOA was created to address.
Not another folder for COAs.
Not another merchant upload portal.
Not another spreadsheet.
A product-centered compliance environment designed to help merchants manage their own product evidence while giving payment organizations better intelligence into the commerce they support.
Products.
COAs.
Lab Intelligence.
Evidence.
Transparency.
Monitoring.
Compliance.
Connected.
Continuously.
For merchants, it creates a better way to manage regulated-product compliance.
For payment companies, it creates an opportunity to replace expensive manual workflows with structured intelligence.
And for organizations that choose to resell MyCOA, it can turn what has historically been a compliance expense into a recurring merchant technology revenue stream.
That's the part of this transformation I believe deserves far more attention.
The payments industry has spent decades asking merchants to send us their lab reports.
Perhaps we've been asking the wrong question.
The question shouldn't be:
“Do we have the COA?”
It should be:
“Do we understand the product?”
Do we know what it contains?
Do we know what was tested?
Do we trust the evidence?
Does it match the product?
Does it meet our policy?
Is it still current?
Has anything changed?
And if the rule changes tomorrow, can we immediately determine whether it still complies?
A PDF cannot answer those questions by itself.
Intelligence can.
The processors that recognize this will do more than reduce compliance workload.
They can create cleaner portfolios.
Faster underwriting.
Better merchant experiences.
Stronger sponsor-bank relationships.
More defensible controls.
And entirely new recurring revenue.
The industry doesn't need another compliance fee.
It needs compliance infrastructure.
And that's exactly what we built MyCOA® to become.
If your organization supports CBD, hemp, kratom, peptides, mushrooms, nutraceuticals, or other regulated-product merchants, we should talk.
We'll show you how MyCOA approaches product and COA management, how it can fit into merchant underwriting and ongoing compliance workflows, and how payment partners can turn it into a merchant-facing service and recurring revenue opportunity.
Schedule a Qredible MyCOA Demo
Regulatory context: FDA's recent actions demonstrate why product-specific intelligence increasingly matters—from concentrated 7-OH and kratom testing to peptide characterization and products marketed as CBD containing undeclared ingredients.
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 →
