How to reduce false positives in sanctions screening
Photo by RDNE Stock project on Pexels
Ask any compliance analyst what the worst part of sanctions screening is, and "wading through false positives" comes up almost every time. Common names generate possible matches against a list of tens of thousands of entities as a simple fact of statistics — "Mohammed Ali," "John Smith," and "Ahmed Hassan" will always produce hits somewhere on a list that size. The goal isn't to get to zero false positives — that's not achievable without also losing true positives — it's to get the noise down to a level a team can actually review carefully, every time.
1. Search full legal names, not initials or nicknames
"J. Smith" fuzzy-matches against a huge number of entries because there's almost nothing to distinguish it on. "John Robert Smith" narrows the candidate pool immediately. If your intake form or onboarding flow captures a shortened or preferred name rather than the full legal name, you're handing the matching engine less to work with before it even starts. This is the single highest-leverage change most teams can make, and it costs nothing — it's a data-collection habit, not a tooling change.
2. Supply supporting attributes when you have them
Date of birth, nationality, and entity type (individual vs. organization) are the details that let a matching engine — or a human reviewer — distinguish "this is the sanctioned person" from "this is someone who happens to share a name with the sanctioned person." When a screening API accepts optional DOB and nationality fields, use them: a name match against a list entry with a contradicting date of birth should be demoted, not surfaced as a top hit. Even when you don't have every field, supplying what you do have compounds — two corroborating attributes narrow the field far more than either alone.
3. Set entity type on every screen
A person's name can collide with an unrelated company name, and vice versa. Explicitly marking a query as "individual" or "organization" is a cheap filter that eliminates an entire class of spurious matches before scoring even happens. It's a single form field or API parameter, and skipping it means asking the matching engine to guess something you already know.
4. Understand the difference between primary-name and alias hits
Not all aliases carry equal weight. Sanctions data sources flag some aliases as "weak" or "low quality" — a phonetic guess or an unverified spelling variant — versus a verified primary name. A possible match against a weak alias, with no corroborating attributes lining up, is meaningfully less likely to be a true positive than a match against the primary designated name. A good screening result surfaces which kind of name produced the hit; use that information rather than treating every hit identically. Our guide to name screening in AML goes deeper on how matching engines score these variants.
5. Build a documented review process for the "possible match" band
The single biggest driver of alert fatigue isn't the existence of a possible-match band — it's not having a consistent, fast way to work through it. Teams that treat every possible match as a fresh investigation burn out. Teams that build a short, repeatable checklist (matched name type → supporting attributes → program and date → documented decision) get through the same volume in a fraction of the time, with more consistent outcomes across analysts. See how to review a possible match for the specific sequence.
6. Don't confuse "reduce false positives" with "lower your matching thresholds"
It's tempting to just tighten the score threshold that counts as a "possible match" until the queue gets shorter. This works, but it trades false positives for false negatives — you'll start missing true matches that scored just under your new, tighter bar. The tips above reduce noise by giving the matching engine and your reviewers more signal, not by silently discarding borderline results. If your queue volume is still unmanageable after applying them, the right lever is usually better intake data collection or a triage step (auto-clearing possible matches only when multiple supporting attributes contradict), not a blanket threshold change.
7. Re-screen instead of re-searching from scratch
If you're manually re-running the same subjects periodically to catch new designations, you're re-doing review work you already did last time on names that already cleared. Ongoing monitoring — saving a subject once and letting the system re-screen it automatically on every list refresh — means your review queue only ever surfaces genuinely new information (a new hit or a changed score), not the same name coming back around for a fresh manual look.
Put it together
None of these individually eliminates false positives — that's not the right goal. Together, they shift your review queue from "mostly noise, occasionally something real" to "manageable, mostly-relevant possible matches with the context needed to resolve them quickly." Try a screen with a full name and a date of birth to see the difference supporting attributes make to the result.
Frequently asked questions
What causes false positives in sanctions screening?
Mostly common names matching against a list of tens of thousands of entries, combined with thin intake data — initials, nicknames, or missing date of birth and nationality — that gives the matching engine nothing to disambiguate on.
Should I just raise my match threshold to cut false positives?
Be careful with this. Tightening thresholds trades false positives for false negatives — you risk missing true matches that score just under the new bar. Better first steps are collecting fuller intake data and supplying supporting attributes like DOB and nationality.
Does supplying a date of birth actually reduce false positives?
Yes, meaningfully. A name match against a list entry with a contradicting date of birth is strong evidence against a true match, and a well-built matching engine demotes it accordingly rather than surfacing it as a top hit.
Run this check on a real name
Free, no account required. Screen against the OFAC SDN, OFAC Consolidated and UN Security Council lists.