Five Percent of Your Merchants Are the Problem.

You Built the Process for All of Them.

Most of the merchants sitting in your boarding queue right now are never going to cost you anything.

Platform data published in Adyen's 2026 fraud report puts numbers on how uneven the distribution is. Five percent of identities drive 41% of fraud incidents and 58% of fraud value, and 3% of identities account for half of all refund value. A small, dense population does most of the damage. It sits inside a much larger population doing none of it.

That is the shape of the risk.

Now look at the shape of your onboarding process. Every applicant gets the same document request. The same verification sequence. The same wait.

The two shapes do not match. The cost of that mismatch does not appear in your fraud numbers. It appears in the merchants who never finished.

You are taxing the entire portfolio to catch a population you could have isolated.

Risk is Concentrated. Onboarding is Not.

The same report, built on $1.6 trillion in platform transactions alongside a survey of 1,000 US enterprise merchant decision-makers, found that 50% of businesses report rising false declines, static controls block up to 10% of legitimate customers at checkout, and 58% report rising manual review costs. Close to 70% expect fraud and abuse to limit revenue growth over the next 12 to 24 months.

Ten percent is the figure worth sitting with. One in ten legitimate customers stopped by a control calibrated for a population that is one in twenty.

Merchant boarding compounds this, because verifying a business is a heavier question than verifying a person. The entity. The beneficial owners. The ownership chain. The jurisdiction, the business model, the expected volume. Each one is a separate query to a separate provider with its own latency and its own failure mode. The merchant does not experience that as diligence. They experience it as a queue.

The obvious response is to spend on better tooling. The industry already ran that experiment.

Fenergo's research across 600 senior decision makers found that reported use of advanced AI tools in KYC and AML rose from 42% in 2024 to 82% in 2025, while the share of institutions losing clients to slow and inefficient onboarding hit 70%, the highest level recorded. Average annual spend on AML and KYC operations now runs $72.9 million per firm.

The tools arrived. The outcome got worse.

That is not a technology gap. Models trained on signals that were never made comparable inherit the same blind spot the humans had. They just apply it faster.

The Tradeoff You Think You Are Managing is Not Real

Most risk teams run on the same assumption. Tighter controls mean less fraud but more abandonment. Looser controls mean the reverse. Pick a point on the line and defend it. The 2026 Global eCommerce Payments and Fraud Report from the Merchant Risk Council, built with Visa Acceptance Solutions and Verifi from 1,278 merchant professionals across 37 countries, makes that line difficult to defend.

Operators with mature fraud programs report a fraud rate of 0.6% by revenue against 3.9% for non-member enterprises, and 0.3% by order against 4%. They achieve that while rejecting 2.8% of orders on suspicion of fraud. The comparison group rejects 5.2%.

Better on both axes at once. Less fraud and fewer rejections, drawn from the same population of applicants.

That result is not compatible with the tradeoff. If tighter controls bought lower fraud, the operators rejecting nearly twice as many applicants would post the lower fraud rate. They post one roughly six times higher. For everyone else, easing the rejection rate without doing the work to see more clearly isn't discipline; it's just underwriting the fraud you never caught.

Rejection rate is not a measure of rigor. It is a measure of resolution. Programs that reject more are not being more careful. They are guessing more, because they cannot see enough to do anything else, and a false positive is what a low-resolution decision looks like from the applicant's side.

The Merchants Who Leave Are Not Random

There is a second distribution problem underneath the first, and it is the one that should be uncomfortable.

Abandonment is not spread evenly across your applicants either. The merchant who walks away from a slow boarding process is the merchant who has somewhere else to go. Established processing history. Volume worth competing for. Two other providers already in the evaluation, one of which boards in a day.

A merchant comparing three providers does not abandon the riskiest one. They abandon the slowest one.

Now consider who does not abandon. The applicant using a constructed entity has no alternative provider, no competing timeline, and no better option waiting. Clearing your process is the entire job. They will upload the document. They will wait four days. They will answer the follow-up email within the hour, because the payoff on the other side justifies every minute of it.

The friction meant to function as a filter selects in the wrong direction. It costs you the least among applicants who are patient because they are motivated, and the most among applicants who are impatient because they have options. That is precisely the population that clears a point-in-time check and then goes quiet.

Friction is a filter that the motivated bad actor passes and the busy good merchant fails. 

The pattern repeats after boarding, which is where most of this gets forgotten. Card network rules require ongoing due diligence across a merchant portfolio rather than a clean check at signup, so the merchant does not prove themselves once. They prove themselves again at review, again after a volume change, again when a document expires. Every one of those is another opportunity to lose a merchant who has alternatives, and another opportunity for one who does not to simply comply.

Which means the abandonment number on your dashboard is not a customer experience metric. It is a composition metric. It is telling you something about who is left in the book, and the answer is not visible from a fraud rate.

Over-Blocking Now Fails on Its Own Terms

For payment service providers, there is a second reason this matters, and it arrived in April. The Visa Acquirer Monitoring Program merchant threshold dropped from 2.2% to 1.5% on April 1, 2026, with an $8 fee assessed per fraudulent or disputed transaction and no warning tier. A merchant sitting at 1.8% in March was compliant. The same merchant, with identical volume and identical disputes, was in violation in April.

The reflex is to tighten everything. Flag more. Decline anything ambiguous. Add a document request.

Under this program, that reflex is counterproductive. The ratio divides combined fraud reports and disputes by total card-not-present transactions. Declining legitimate transactions shrinks the denominator without touching the numerator, which pushes the ratio further out of compliance.

The fraud reports stay. The disputes stay. The good volume you turned away comes out of the bottom of the fraction. You tightened, and the number went up.

Over-blocking used to be an invisible cost paid in lost revenue. It is now a visible cost paid in enforcement exposure.

The Portfolio Math is Worse Than the Merchant Math

For a payment facilitator, the exposure is structural rather than per-account. VAMP operates as a portfolio ratio, rather than a per-merchant pass or fail, so a handful of high-fraud or high-dispute sub-merchants moves the number for everyone boarded underneath. Many acquirers hold their portfolios to internal lines stricter than the published thresholds, which means the effective limit is often lower than 1.5%.

So a PSP now has two failure modes pulling in opposite directions.

Board the wrong merchant and the portfolio absorbs it, quietly, across every other merchant in the book. Over-verify everyone to avoid that, and the denominator shrinks while the merchants with alternatives go somewhere faster.

This is the same structural problem that lets fraudulent accounts sit on a portfolio for months before anyone measures them. The checks ran and passed. Nothing was corroborated against anything else, and nothing was reassessed after boarding.

Uniform friction cannot solve a problem that is not uniformly distributed. It can only move the cost from one column to another.

Why Your Stack Can Only Pull One Lever

The reason almost everyone applies uniform friction is not laziness. It is that uniform friction is frequently the only thing the architecture can express.

Consider what arrives during a single merchant application, pulled from three to five or more separate point providers. A registry match on the entity. A sanctions and adverse media screen. A document verification result. A device intelligence signal. A beneficial ownership resolution across a chain that may run three layers deep. Each comes from a different provider, in a different format, on a different scale, with a different response structure and a different meaning attached to the word confidence.

Getting even one of those providers live is not a single decision. Someone has to provision the integration, map its response fields, and QA the whole path before it can touch a real application. Do that three to five times over, and the stack is not a system. It is a row of separate pipes that happen to feed the same decision.

A sanctions screening result does not speak the same language as a device integrity flag or a registry match on an ownership chain. Until those outputs are translated into a consistent, comparable format, they cannot be corroborated against each other. They can only be collected and read in sequence.

That is why the only available lever is a global threshold. You cannot route what you cannot compare. You tighten for everyone or you loosen for everyone, and you argue in quarterly reviews about which direction to move a number that was never the right control in the first place. It is the layer the market's spending has largely skipped, and skipping it is what makes the tradeoff feel real when the data says it is not.

Normalization is not a feature. It is the precondition for every decision that follows. Once signals are comparable, a low-risk merchant and a high-risk merchant stop looking the same at the moment the decision is made, and friction can finally be pointed somewhere.

And normalization only solves half of it. Comparable signals still have to trigger something. That is the other piece almost every stack is missing: logic that acts on the comparison the moment it is available, instead of waiting for someone to review it.

What Conditional Friction Requires

Routing scrutiny toward risk instead of spreading it evenly takes several things, and most stacks are missing at least three.

• Signals normalized into a common format so they can be corroborated against each other, rather than evaluated one at a time and read independently.

• Waterfall logic, so that when one check flags or fails, it automatically triggers the next check instead of stopping at a single provider's answer or waiting for someone to notice.

• More than one workflow, so a low-risk applicant and a high-risk one do not move through the same sequence. Risk tolerance, application type, and jurisdiction can each route to a different set of checks.

• Decision logic that risk and compliance teams can change themselves. Calibration is not a one-time setting. A network threshold moves, a merchant category shifts, a new geography opens, and the rules that were correct in Q1 are wrong in Q3.

• Exceptions that reach a human with the full case attached, rather than landing in a queue where someone reassembles the application from five browser tabs.

In practice, that looks unremarkable from the merchant's side, which is the point. A merchant with a clean registry match, a resolvable ownership chain, and corroborating device and behavioral signals clears without a document request. A merchant with a jurisdiction mismatch and an unresolved beneficial owner gets the enhanced path, the document request, and the analyst. A flagged document result does not end the application; it triggers the additional check that resolves it, automatically, before anyone has to intervene. The scrutiny goes where the signals point. This is what Grid was built to do, and it is why the decisioning layer sits above the providers rather than beside them.

Because the workflow builder is code-free, changing a threshold after a network rule update takes less than a minute, made by the team that owns the outcome, not an engineering sprint scheduled behind a product roadmap. Providers can be added, replaced, or brought in from existing contracts, without rebuilding the logic that sits on top of them. Waterfall paths and separate workflows for different risk tiers are built the same way, inside the same builder, without a new integration for each variation.

But none of that is useful after the fact if you cannot see it after the fact. Case Management is native to Grid and included at no additional cost, and it holds every document, check, decision, and note tied to a single application in one place, searchable at any point in that merchant's relationship with you. When a card network audit asks for the file on a specific merchant, or a random merchant review comes up, or a flag six months into the relationship triggers a new check, the case is already assembled. Nobody reconstructs it from five provider dashboards under a deadline.

One payments provider running this architecture recorded a 25% increase in conversion rates. A financial services organization recorded a 30% reduction in manual reviews and a 35% reduction in repeat fraud attempts. Those are the two directions moving at once that the tradeoff says should not be possible.

What to Evaluate Before you Renew any Point Providers

• How many individual point providers does your verification stack actually call, and did engineering have to integrate and QA each one before it went live?

• If one provider in that stack flags or fails, does that automatically trigger the next check, or does the application just sit until someone notices?

• Can a high-risk applicant move through a different verification sequence than a low-risk one, or does every application run the same fixed path regardless of what the early signals returned?

• When you need to add a provider, drop one, or change the order checks run in, is that a configuration change or an engineering sprint?

• If an auditor, a network, or a compliance reviewer asked for every document, check, decision, and note tied to one merchant, could you produce it in minutes, or would someone have to rebuild it from multiple dashboards and other supportive documentation?

The fraud population in your book is small, but it is dense. The process built to catch it is neither.

Every merchant you make prove themselves twice is a merchant deciding whether the second time is worth it. The ones who decide it is not are rarely the ones you were worried about.

The question worth asking before the vendor evaluation: if you cut your rejection rate in half tomorrow, do you actually know whether your fraud rate would move?

If your current reporting cannot answer that, take our Risk Assessment and see where you stand.