Identity verification vendors publish pass rates. They put a number on the marketing page, usually somewhere between 95% and 99%, and frame it as a measure of their model's accuracy. What that number obscures is which errors they're tolerating to hit it. Pass rate and false-positive rate are not inverse measures. A vendor can hold a high pass rate while generating a substantial false-positive stream by tuning their threshold to minimize false rejections.
In practice, the false-positive rate is the number that matters most to companies building user-facing onboarding flows. A false negative (fraudster who slips through) has legal and financial cost, but it's often discovered later and handled through other controls. A false positive (legitimate user who gets flagged) is an immediate, visible, operational event with a measurable downstream cost. Most platforms don't calculate that cost explicitly. When we do the math with growing fintechs and marketplace operators, the numbers are usually surprising.
What a False Positive Actually Costs
Consider a fintech offering a business checking account to sole proprietors and small LLCs. The KYC flow checks the business owner against a document classifier, a liveness model, and a name/address matching service. The false-positive rate on the overall flow, across all three checks combined, sits at around 4%. That sounds manageable until you do the downstream accounting.
Each flagged application generates a manual review queue entry. Someone has to open the case, read the document images, compare the liveness frames, check the address discrepancy that triggered the flag, and make a decision. If the review team works through 50 cases a day and a review takes 12 minutes average, a 4% false-positive rate on 500 daily applications creates 20 review cases per day. That is nearly one person-day of labor before you add any fraud cases that also need to go through review.
Beyond the operational cost, there is the user experience branch. Most platforms send the flagged applicant to a "pending review" state with some form of delay notification. Some portion of those users will not wait. In a competitive market where the next alternative is two taps away, an applicant told their identity is "under review" has a significant probability of abandoning the application. We've seen platform-specific data suggesting abandonment in the pending state runs anywhere from 25% to 45% depending on product type and how the hold message is framed. That is not a verification cost. That is a customer acquisition cost.
Where False Positives Actually Come From
The misdiagnosis we see most often is treating false positives as a single-source problem, usually blamed on the liveness model or the document OCR accuracy. In practice, false positives in a multi-step verification flow are almost always compound: the triggering event is a combination of signals from different steps that individually would not cross a rejection threshold, but which sum to a risk score above the decision boundary.
Some common sources worth examining separately:
Name Normalization Failures
Accent marks, hyphenated surnames, legal name vs. common name, and transliterated names from non-Latin scripts all create mismatch signals that compound into false positives. A user whose government ID reads "Jose-Luis Herrera Fuentes" and whose bank record reads "Jose Herrera" will generate a name-mismatch signal even though they are the same person. Downstream, that mismatch gets combined with any other marginal signal in the session and can push the overall score over threshold.
Document Image Quality vs. Classifier Confidence
Document classifiers have confidence scores that don't always surface at the API level. When a user submits a photo of their driver's license in low light or with slight motion blur, the classifier will extract the text correctly but at lower confidence. Some systems convert that confidence score into a flag without distinguishing between "the document is suspicious" and "the image quality was marginal." The distinction matters: image quality problems are retry-able; suspicious documents are not.
Address Database Coverage Gaps
Address verification services have variable coverage quality by geography. Rural addresses, recently built properties, and non-standard addressing formats (apartment numbers, unit designations) generate match failures at a meaningfully higher rate than addresses in dense urban cores. A fintech growing into less urban markets will see their false-positive rate rise not because their users are riskier, but because their address verification vendor has worse coverage in those geographies.
The Threshold Tuning Problem
Every verification model has a decision threshold that translates a continuous risk score into a binary pass/fail. Where that threshold sits determines the tradeoff between false-positive rate and false-negative rate. Lower the threshold and you catch more fraud at the cost of more legitimate users getting flagged. Raise it and the false-positive rate drops while some marginal fraud passes through.
The problem is that most KYC vendors set a single global threshold, calibrated against their overall training data, and do not expose per-customer threshold tuning. The optimal threshold for a neobank serving gig workers in mid-size cities is different from the optimal threshold for a crypto exchange serving international users. A single global threshold will be wrong for most individual customer profiles, generating either too many false positives or too many false negatives depending on how the customer's user base differs from the vendor's training distribution.
We're not saying threshold tuning alone solves the false-positive problem. It doesn't. Threshold adjustments are a coarse tool, and they come with real compliance tradeoffs: if you raise the threshold to reduce false positives, you are explicitly accepting more fraud. Any adjustment needs to be documented and defensible under your BSA/AML obligations. But the starting point should at least be a threshold calibrated to your actual user population, not to an industry average that may not describe your users at all.
Step-Up Verification as a False-Positive Recovery Mechanism
One structural improvement that reduces both the cost of false positives and the compliance risk of loosening thresholds is step-up verification: instead of a binary pass/fail at the initial check, low-confidence sessions trigger an additional verification step targeted at the specific signal that created the doubt.
In practice, this means building a decision tree that differentiates between types of uncertainty. A session where the document OCR confidence is below threshold but the liveness check is clean and the name match is high-confidence might be routed to a document re-capture request, not to a full manual review. A session where the name match is marginal but the address is confirmed and liveness is clean might be routed to a knowledge-based verification question about the address history, not to a hold queue.
The key requirement for step-up to work is understanding which signal drove the initial flag. If your verification stack doesn't surface which component generated the alert and at what confidence level, you can't route intelligently. You're left with the blunt choice of pass/fail/hold. That is where we spend most of our integration work when onboarding a new fintech or marketplace client: making the individual signal breakdown visible so the routing logic can be specific.
Measuring False-Positive Rate Accurately
One complication worth naming: most platforms don't actually know their true false-positive rate. They know their pass rate and their fraud discovery rate, but the denominator for false positives (legitimate users who were incorrectly flagged) requires a ground truth about user legitimacy that usually only emerges weeks or months later through account activity.
A practical proxy is to look at your manual review queue outcomes. If your review team is clearing 80% of flagged cases as "approved, no issue found," the majority of your review volume is false positives. That is operational data you already have. It just needs to be tracked explicitly rather than treated as part of the normal operations cost of running verification. Building a dashboard that tracks review queue approval rate over time gives you a lagging indicator of false-positive rate that does not require a separate data science exercise.
The goal is not to minimize false positives at any cost. Some review volume is appropriate and expected, particularly at higher risk segments or for product types with elevated fraud exposure. The goal is to make the false-positive rate visible, attributable to specific signals, and subject to deliberate threshold and routing decisions, rather than something that just happens at whatever level the vendor's default configuration produces.
What We Optimize For
At IDPylon, the routing logic is designed around this specific problem. When we build a verification flow for a client, we instrument each step to surface confidence scores alongside pass/fail outputs, and we build the step-up routing rules to target the specific type of uncertainty rather than treating all flags as equivalent. The result is that the manual review queue shrinks and becomes more actionable, and the abandonment rate in the pending state drops because fewer legitimate users end up there in the first place.
Reducing false positives is not a compliance risk. It is a compliance hygiene outcome: the users who should clear, clear. The users who need more scrutiny get the specific additional check their case requires. And the users who are genuinely suspicious get the hard stop they deserve. Getting those three categories right takes work on the orchestration layer, not just on the underlying model accuracy.