How to Reduce False Positives in AML Screening

Screen one investor against global sanctions, PEP and adverse media lists, and you can easily generate dozens of hits. Screen a fund-of-funds structure with a dozen underlying limited partners, several offshore trusts and a couple of corporate general partners, and that number climbs into the hundreds. Almost all of them will be false positives: a common surname, a shared date-of-birth range, a company name that happens to match a sanctioned entity in a different jurisdiction.

The problem is that every one of those hits still has to be looked at. And this has a cost: slower onboarding, alert fatigue among analysts who have learned to click through hits on autopilot, and, ironically, a higher chance that a genuine sanctions or PEP match gets missed because it is buried in the noise.

This article sets out why sanctions and PEP false positives happen, the practical techniques compliance teams use to reduce them, and the governance that has to sit around any false positive management process so that dismissals remain defensible.

Why AML Screening Produces So Many False Positives

False positives are not a sign that screening is working too hard. They are usually a sign that the matching logic has too little to work with.

Name-only matching against global lists. Most sanctions and PEP screening starts with a name match against a watchlist entry. Names alone are a weak identifier. "Mohammed Al Amin," "John Smith," "Chen Wei" and thousands of similar names appear repeatedly across sanctions lists, PEP databases and adverse media, entirely unconnected to the individual being onboarded.

Common and transliterated names. Sanctions lists pull from dozens of source jurisdictions using different scripts and romanisation conventions. A single Arabic, Russian or Chinese name can appear on a list under several different Latin-alphabet spellings. Fuzzy-matching algorithms, which exist precisely to catch these variants, inevitably widen the net and catch unrelated people whose names happen to sit close in edit distance.

Missing contextual data. A name match with no date of birth, nationality, residency or entity identifier to compare against cannot be narrowed down. If the screening tool only has "Maria Garcia" to work with, it cannot distinguish the entity's actual beneficial owner from any of the other people who share that name on watchlists.

Stale or duplicated list entries. Sanctions and PEP lists are maintained by different bodies on different schedules and are not always de-duplicated against each other. The same individual can appear multiple times with slightly different spellings, each generating a separate hit for what is, in substance, one alert.

Overly broad thresholds. Fuzzy-match sensitivity tuned to catch every possible variant, with no compensating logic to rule out non-matches, produces a process that flags almost everything and resolves almost nothing.

Practical Techniques to Reduce False Positives

None of these causes requires accepting a high false positive rate as the price of thorough sanctions screening. Each one has a corresponding fix, and most funds already hold the data needed to apply them; it is a question of using it at the point of screening rather than after.

Use the context already captured at onboarding

Onboarding forms already collect date of birth, nationality, country of residence, and, for entities, registration number and jurisdiction of incorporation. Feeding that data into the matching logic, rather than treating screening as a name-only exercise run in isolation, is the single highest-leverage change most teams can make. A name match against a sanctioned individual with a mismatched date of birth or a residency thousands of miles from the listed address can be resolved with far more confidence than a name match alone.

Match on secondary identifiers, not just names

Where they exist, secondary identifiers such as passport numbers, national ID numbers, LEIs and company registration numbers narrow a hit dramatically faster than any amount of name-similarity tuning. Entity screening in particular benefits from matching on registration number and jurisdiction rather than company name alone, since corporate names are reused across markets far more often than individual names.

Tune fuzzy-match thresholds deliberately

Fuzzy matching is necessary to catch genuine transliteration and spelling variants, but the threshold should be a considered, documented decision rather than a vendor default left untouched. Thresholds that are too loose generate volume without value; thresholds that are too tight risk missing a genuine variant spelling. The right threshold is usually set per list type (sanctions lists warrant more sensitivity than lower-risk adverse media categories) and revisited periodically as the false positive rate is measured.

De-duplicate before an analyst ever sees a hit

If the same underlying list entry is producing multiple near-identical hits because of formatting differences between source lists, that duplication should be resolved in the matching layer, not left for an analyst to notice and manually merge. De-duplication alone can meaningfully cut the number of alerts an analyst has to open without changing the substance of what gets reviewed.

Build a consistent disposition workflow

Every hit should resolve to one of a small number of defined outcomes: true match, false positive, or escalate for further investigation. A structured disposition workflow, with a mandatory reason code and free-text rationale for every dismissal, does two things at once: it forces analysts to record why a hit was cleared, and it creates a consistent dataset that can be used to review matching quality over time. It is also what keeps screening hit remediation, working through a backlog of unresolved alerts after the fact, from becoming a recurring exercise rather than a one-off clean-up.

Bias toward surfacing, not hiding

None of this should be read as a licence to suppress hits. The objective of false positive management is to reduce the noise around genuine matches, not to reduce the number of things a human ever sees. Any technique that narrows matches automatically, without a documented rationale attached to each dismissal, shifts risk rather than removing it. The lower the false positive rate, the more scrutiny each remaining hit deserves, not less.

Governance: Every Dismissal Has to Be Defensible

Reducing false positive volume only has value if what remains is handled properly. That means three things.

A person reviews and signs off on every dismissal. Automated pre-assessment and contextual matching can narrow the field and draft a rationale, but the decision to clear a hit as a false positive is a human decision. Regulators expect human oversight on screening outcomes, not automated dismissal. The role of any tooling here is to make that human review faster and better informed, not to remove it.

Every dismissal is explainable. A reviewer, an internal auditor or a regulator should be able to look at any cleared hit and see, in plain terms, why it was dismissed: which contextual data points ruled out the match, who made the decision, and when. "Cleared: no match" with no supporting detail is not a defensible record.

A complete audit trail is maintained. Every hit, its disposition, the identifier or context used to resolve it, the reviewer, and the timestamp should be retained and retrievable. This is what turns false positive management from a productivity exercise into a compliance control that will hold up under examination.

How AI Changes the Economics of False Positive Management

The manual version of everything above is slow. An analyst working through hundreds of hits by hand, opening each source article, checking each list entry, cross-referencing residency and date of birth by memory or by flipping between browser tabs, is doing valuable work but doing it inefficiently.

Contextual reasoning changes what the analyst's job looks like day to day. Rather than starting from a blank hit and doing the research from scratch, the analyst starts from a hit that has already been assessed against the available context, with a proposed disposition and a stated rationale citing the specific data points involved: a date-of-birth mismatch, a residency that does not align, a source article that clearly describes a different person of the same name. The analyst's job shifts from investigation to verification: reviewing the reasoning, checking it against the source, and confirming or overriding the outcome. For a complex investor structure that might otherwise generate hundreds of hits, that shift in workload, from clicking through link after link to reviewing a set of pre-reasoned dispositions, is the difference between screening being a bottleneck and screening being a control that keeps pace with onboarding.

Where Steward Fits

Steward's screening is built directly into the onboarding workflow so that the contextual data captured during KYC (date of birth, nationality, residency, entity registration) feeds the matching logic from the outset, rather than being screened separately and reconciled afterwards.

Steward's AI contextualises each hit against that data and drafts an explained disposition with its supporting rationale, so analysts review and confirm rather than research from a blank screen. Every decision keeps human oversight, and every disposition is logged in a full audit trail, so false positive management stays defensible under examination rather than becoming a black box.

If your team is working through the same volume of screening noise described above, it is worth seeing how that looks in practice: book a demo.