False Positive

A false positive is a result that indicates a condition is present when it is not. In fraud prevention and compliance it means a legitimate customer, application or transaction was flagged as suspicious — a real person stopped by a control that exists to stop someone else.

It is one half of a pair. The other, a false negative, is fraud that passed. Every control produces both, and no setting eliminates either.

The four outcomes

Any control that makes a binary decision produces four results, and naming them precisely is what makes the rest of the discussion possible.

The two errors are linked by the decision threshold. Tightening it converts false negatives into true positives and true negatives into false positives at the same time. There is no threshold that reduces both, which is why arguments about whether a system is “too strict” or “too loose” are really arguments about the relative cost of the two errors.

Who actually pays for a false positive

The cost is usually described as review labor, which is the smallest part of it and the only part the organization sees directly.

The larger share is borne by the customer, and it is not evenly distributed. A flagged application is somebody waiting — often at the moment they most need the service to work. A frozen payment is a bill unpaid. A declined onboarding sends a person to a competitor, and they rarely come back. None of these appear in the fraud team’s numbers, and most appear in someone else’s: conversion, support volume, complaints.

The distribution matters more than the average. False positives fall disproportionately on people who deviate from whatever the system treats as normal: thin-file customers, recent arrivals, people with names that transliterate in multiple ways, those who have recently moved or changed name, users of older devices. An aggregate false positive rate can improve while the burden on a specific group gets worse, and nothing in the headline number would show it.

That is a fairness problem, and in regulated markets it is increasingly a supervisory one. It is also a commercial problem, because the groups most affected are frequently the growth segments.

Why it matters for identity verification

The framing that makes false positives tractable: a false positive is usually not a case the system got wrong. It is a case the system could not decide, escalated by default.

A sanctions screening alert on a customer who shares a name with a designated individual is not an error in the matching. The engine did what it should. It had a name and nothing else, and a name alone cannot separate two people.

That distinction points at the only intervention that improves both errors at once. Moving the threshold trades one for the other along a curve the data fixes. Adding a discriminating attribute moves the curve. A verified date of birth closes the name collision outright. Verified identifiers let several applications be resolved to the same real person, which turns an ambiguous velocity signal into a clear answer in either direction.

This is why identity verification at onboarding reduces alert volume for years afterward, and why that benefit is usually invisible in the business case — the cost is paid by onboarding and the saving accrues to compliance operations.

What reducing false positives cannot do

It cannot be done by tuning alone. Every threshold change that reduces false positives increases false negatives. Only new information escapes the trade.

It cannot be judged from the rate alone. A control that flags nothing has a perfect false positive rate and catches nothing. The figure is meaningless without the catch rate it was achieved at.

It cannot be compared across organizations. Different populations with different fraud rates produce different alert compositions from identical controls.

It does not fix the underlying asymmetry in measurement. False positives generate work and complaints, so they are counted well. False negatives are undetected by definition, so they are counted badly. Organizations tend to tune against the error they can see, which is not necessarily the one that costs most.

Frequently asked questions

What is the difference between a false positive and a false negative?

A false positive flags something legitimate as suspicious; a false negative lets something fraudulent pass. They move in opposite directions as the decision threshold changes, so reducing one by tuning always increases the other.

Why are there so many false positives in compliance screening?

Because matching must be fuzzy to handle name variation and transliteration, thresholds are set conservatively where liability is strict, and list entries often carry too little data to discriminate on. The result is alert volumes where the large majority are name collisions rather than matches.

Is a false positive the same as a type I error?

Yes. Type I error is the statistical term for incorrectly rejecting a true null hypothesis, which corresponds to flagging something that was actually fine. Type II error is the false negative. The plain-language terms are more common in fraud operations.

How do you reduce false positives without letting more fraud through?

By adding information rather than adjusting the threshold. A verified date of birth, a confirmed document number or a resolved identity removes the ambiguity that caused the alert, which improves both error types at once. Threshold changes can only trade one for the other.

Related reading

• False positive ratio — how the error is measured and what drives the rate
• Sanctions screening — the control where false positives dominate most
• Fraud score — what the decision threshold is applied to
• Area under the curve — measuring a model across all thresholds