False Positives Are a Revenue Problem: Costing a Wrong Decline

The cost nobody logs

A fraud loss creates a chargeback, a ledger entry, a number the team is measured against. A false positive — a legitimate transaction wrongly declined — creates none of that. It just doesn't happen. So teams optimize against the loss they can see and quietly accept the cost they can't, and the fraud false positive cost stays off the books while it grows.

What a wrong decline actually costs

Three layers, roughly in increasing size and decreasing visibility:

1. The lost margin on that order.
2. The failed recovery. Some customers retry, use another card, or contact support. Many just leave. The ones who leave take their basket with them.
3. The lifetime value of the customer who churns after being treated as a criminal at their own checkout. This is usually the biggest layer and the hardest to attribute.

On our fraud-scoring project the rules engine's false positives on legitimate high-value transactions were a measurable source of churn — reducing them by 40% was a revenue outcome, not just a model metric.

Estimating it without ground truth

You rarely know which declines were wrong. Use a few methods together, and apply the same method before and after any change so the delta is comparable:

• Cold re-review. Pull a random sample of declines and have a senior analyst adjudicate them without context. The share they'd have approved is your rough false-positive rate.
• Re-attempt-and-succeed. Track customers who were declined and then completed a similar purchase shortly after on another channel or card. A high rate points at false positives.
• Complaint and contact rate. Declines that generate a support ticket are a floor on the error, not the whole of it.

Then: false-positive rate × decline volume × (margin + a lifetime-value factor for the share who churn).

The re-review that anchors the number

The estimate is only as good as the method behind it, so make the method concrete and repeat it unchanged. Pull a random sample of a few hundred declines. Give a senior analyst exactly what the model saw — no more — and have them adjudicate each one cold: approve or decline, and a one-line reason. The approve rate across the sample is your false-positive-rate estimate. Run it the same way every quarter and after every model change, with the same rubric, so the number moves for real reasons and not because the method drifted. Report it as a range, because a few-hundred-row sample has real uncertainty.

The asymmetry that matters

A fraud loss is bounded by the transaction amount. A false positive's cost can be several times that, through churn. So a model that "catches more fraud" while raising false positives can be net-negative — and a model change should never be judged on the fraud-caught number alone.

Who owns this number

Not the fraud team. They're measured on losses and will rationally trade false positives for lower losses unless someone owns the other side. Growth or finance should own the false-positive cost, so the trade-off is made with both numbers on the table.

Where this stops being right

• The lifetime-value layer is genuinely hard to attribute. Carry it as a range and state the assumption.
• Thin margins and transactional customers (no repeat purchase) mean the cost is mostly lost margin and smaller.
• Many alternative payment methods make recovery easier, so the cost per wrong decline drops.

FAQ

How do we even know our false-positive rate? You estimate it — cold re-review of a decline sample, re-attempt-success tracking, complaint rate — and hold the method constant across changes.

Is a false positive really worse than a fraud loss? Often, once churn is counted. A fraud loss is capped at the transaction; a wrong decline can cost a customer's lifetime value.

Who should own the false-positive number? Growth or finance — the fraud team optimizes losses and needs a counterweight. In practice, put the fraud-loss number and the false-positive-cost number in front of the same review, owned by different people, so a model change is judged on both at once rather than on whichever one the presenter cares about.

ISTRALLEN builds fraud scoring instrumented so the false-positive cost is measured, not assumed, and weighed against fraud caught; see AI for Fintech.