At a fraud risk conference in late 2024, the head of fraud operations at a major e-commerce platform gave a number that got very little reaction in the room: their ML-based fraud system was blocking approximately 3,400 legitimate transactions per day. The room moved on. When pressed afterward about the dollar value of those blocks, she estimated around $1.1 million in declined legitimate revenue — per day.
That's $400 million annually in legitimate transactions killed by a system designed to prevent fraud. Their fraud losses in the same period were roughly $85 million.
Nobody wants to say this out loud at fraud conferences because the messaging is uncomfortable. But in a meaningful number of organizations, the false positive problem is bigger than the fraud problem it was supposed to solve.
Why false positives are systematically undervalued
Fraud losses are easy to count. There's a chargeback, a dispute, a write-off — it shows up in the ledger. False positive cost is diffuse and mostly invisible. The declined transaction doesn't generate a visible financial record the same way a fraud loss does. The customer who gets declined at checkout doesn't file a formal complaint in most cases — they just abandon the purchase and, frequently, the merchant relationship.
This accounting asymmetry creates a systematic bias in how fraud teams set decision thresholds. The fraud loss number is visible and attributable. The false positive cost is estimated, distributed across departments, and often not attributed to fraud operations at all. When you're managing to a fraud loss metric and your false positive cost is invisible, you optimize for low fraud loss. The correct optimization target — minimizing total cost — requires accurately measuring both sides.
Most organizations haven't done that math. The ones that have are operating their systems differently.
What false positive cost actually includes
The direct revenue impact — declined transactions that would have been legitimate — is only part of it. The full accounting looks like this:
Immediate revenue loss. Transaction value of the declined purchase. For high-value categories (electronics, travel, luxury goods), individual declines can represent hundreds to thousands of dollars. Aggregate that across daily volume and the number gets large fast.
Customer support costs. A portion of falsely declined customers will contact support. Each contact costs money — typically $8 to $25 per ticket depending on channel, more if it escalates. Multiply by daily false positive volume and you're looking at material operational overhead that the customer support team usually absorbs without connecting it back to the fraud decision engine.
Churn. This is the hardest to quantify but probably the largest. Studies on payment decline experience consistently show that 30-40% of customers who experience a false decline don't return to that merchant. In a subscription business, that's a lifetime value loss. In e-commerce, it's a customer acquisition cost that you paid but never converted. The true cost of a false decline includes a probability-weighted customer lifetime value component that almost nobody is computing.
Reputation and trust signals. For B2B payments platforms and financial institutions, a high decline rate for legitimate transactions becomes a product quality problem that affects contract renewals and new customer acquisition. This is nearly impossible to put a number on but is real.
How ML models produce false positives at scale
ML-based fraud models don't make errors uniformly. They tend to produce false positives in specific transaction clusters — customers with unusual-but-legitimate behavior patterns that the training data labeled as high-risk because similar patterns appeared in historical fraud cases.
Common examples: customers who travel frequently and make purchases in unfamiliar geographies; customers who make occasional large purchases after long periods of low-value activity; customers using new devices because their old one broke; first-time purchases at a new merchant category. Each of these patterns has legitimate explanations that a human reviewer would recognize immediately. An ML model trained on historical fraud data sees the surface-level pattern similarity and scores it high.
The problem compounds when threshold decisions are made without adequate attention to the false positive distribution. A model might achieve 95% fraud detection rate at a threshold that also produces a 2.5% false positive rate on legitimate transactions. If your transaction volume is 500,000 per day, that's 12,500 legitimate customers declined daily. The 95% detection sounds good in a model performance summary. The 12,500 daily declines is buried in operational data that fraud teams often don't look at directly.
Measurement as a prerequisite to improvement
Before you can address false positives, you need to measure them accurately. That requires a few things that many organizations don't have in place:
First, a feedback loop that confirms which declined transactions were actually legitimate. This typically means sampling declined transactions and following up — either through customer service records, post-decline authentication flows, or periodic retrospective labeling. Without this feedback, your false positive rate is an estimate at best.
Second, attribution of false positive costs to the fraud decision system specifically. This requires cross-departmental data sharing — fraud operations needs access to customer service ticket volumes, churn analysis, and revenue impact data that usually lives in separate systems under separate owners.
Third, a defined total cost metric that weights fraud losses and false positive costs on the same scale. This is usually where the organizational challenge is: fraud teams are measured on fraud loss, not on total decision cost. Changing the measurement framework requires executive alignment that's genuinely hard to achieve in large organizations.
Practical threshold management
Assuming you have the measurement infrastructure, threshold management becomes a cost optimization problem rather than a fraud detection problem. The question isn't "what threshold minimizes fraud?" — it's "what threshold minimizes total cost?"
In practice, this usually means running separate threshold calibrations for distinct customer and transaction segments. High-value, long-tenure customers with established behavioral baselines can operate at more permissive thresholds without meaningfully increasing fraud exposure. New accounts with no behavioral history or thin identity signals warrant tighter controls. Applying a single threshold across all segments is almost always suboptimal.
It also means building in manual review capacity for the middle band — transactions that score in the gray zone where automatic decision is most likely to err. Automated decisions at the extremes (obvious good, obvious fraud) are fine. The middle band is where human judgment adds value and where the cost of a false positive is most easily avoided through brief additional verification.
The model performance metrics that matter
Fraud model evaluation often focuses on AUC-ROC, which measures separability across all thresholds but doesn't directly tell you about performance at the threshold you actually deploy. What matters in production is precision and recall at your operating point — and the precision-recall tradeoff curve in the neighborhood of your current threshold.
A model with marginally lower AUC but better calibration in the high-score range can significantly outperform a higher-AUC model when measured on total decision cost. This is a nuanced evaluation that requires operational data, not just holdout set metrics. The teams that understand this are making better threshold decisions than the teams optimizing on AUC alone.
If your fraud program hasn't quantified its false positive cost recently — or ever — that's the highest-leverage analysis you can do right now. The number may be uncomfortable. It should be.