A false positive is a legitimate party wrongly flagged as a possible match to a list entry. It is the single biggest source of alert volume in screening and the main day-to-day operational cost, tying up analysts on clears.
What is a false positive, in plain English?
A false positive is a false alarm. Screening flags a legitimate customer or transaction as a possible match to a sanctions or watchlist entry, an analyst investigates, and it turns out to be the wrong person. No prohibited party was involved; the name just looked close enough to a listed one to trip the match.
False positives are unavoidable in name-based screening because names are not unique. Common names, weak aliases, and loose matching thresholds all produce collisions between real people and list entries. The result is the bulk of the alert queue: most alerts a screening team works are false positives that get cleared.
Because they dominate volume, false positives are the main operational cost of screening. The work of clearing them is where analyst time goes, so managing them well is central to running a program that is both effective and sustainable.
False positive vs false negative
What changes | False negative | False positive |
What happened | Real match missed. | Legitimate party wrongly flagged. |
Main cost | A prohibited party gets through. | Analyst time on needless clears. |
Visibility | No alert; found by testing. | Shows up as alert volume. |
Driven by | Thresholds too tight. | Thresholds too loose, common names. |
What drives them
Driver | Why it flags the wrong party |
Common names | A widely shared name collides with a listed party who happens to have the same one. |
Weak aliases | Partial or common AKAs match large numbers of unrelated legitimate people. |
Loose thresholds | Fuzzy matching set too permissive scores distant names as possible hits. |
Missing identifiers | No date of birth or address to disambiguate, so a name alone drives the alert. |
What it looks like in practice
In practice
A customer named after a common name shares it with a listed individual. Every batch rescreen flags the account, and each time an analyst pulls the customer's date of birth and nationality, confirms they do not match the list entry, and clears it.
To stop the repeat work, the team adds a governed allow-list entry scoped to that verified customer record and layers date of birth into the matching logic so future collisions on that name self-resolve. The underlying name is still screened, so a genuinely new listed party under the same name would still alert. The noise drops without weakening coverage.
Why it matters to operators
False positives are the day-to-day reality of running screening. They are common with common names, weak aliases, and loose thresholds, and left unmanaged they bury analysts in clears and slow the response to genuine hits. Teams manage them with better matching logic, secondary identifiers like date of birth or address to disambiguate, and governed allow-listing of already-cleared matches.
The trap is over-correcting. Cut thresholds too aggressively to kill the noise and you start creating false negatives, real matches that no longer surface, which is a far worse failure. The two errors have to be balanced on purpose, not by accident, so noise reduction always comes with a check that real hits still fire.
What to watch in the data
- Volume concentration. A handful of common names or weak aliases often drive a large share of the queue; target those first.
- Secondary identifiers. Date of birth, nationality, and address turn name-only collisions into quick, defensible clears.
- Governed allow-listing. Recurring cleared matches can be suppressed, but only with a documented reason, owner, and review.
- Threshold balance. Track false-negative risk whenever you tighten to cut false positives; do not trade one for the other blindly.
- Match quality. Better fuzzy, phonetic, and token logic reduces weak matches without dropping real ones.
Quick questions
Why are false positives so common?
Names are not unique, and screening has to be cautious enough not to miss real hits. Common names, weak aliases, and fuzzy matching all produce collisions with legitimate people, so most alerts a team works turn out to be false positives.
How do teams reduce false positives?
With better matching logic, secondary identifiers like date of birth and address to disambiguate, and governed allow-listing of already-cleared matches. The goal is to cut noise without weakening the coverage that catches genuine hits.
Can cutting false positives cause harm?
Yes. Tightening match logic too far to reduce noise can create false negatives, where real matches no longer surface. That is a much more serious failure, so the two error types must be balanced deliberately and any change validated.
What is a secondary identifier?
A data point beyond the name, such as date of birth, nationality, or address, used to confirm whether a flagged party really is the listed one. Secondary identifiers turn ambiguous name matches into clear, documented decisions.
Is allow-listing a safe way to cut false positives?
It can be, if governed. An entry must be scoped to a specific verified identity, with a documented reason, owner, and review. Scoped that way it suppresses a known clear without silencing a future match on a genuinely different listed party.
Go deeper
- OFAC, US Treasury ↗ — Administers US sanctions programs, the SDN list, and licensing.
- European Banking Authority ↗ — EU banking regulator. Strong Customer Authentication under PSD2 and AML guidance.