Cutting sanctions screening false positives without missing real matches
Most sanctions false positives come from thin customer data, not oversensitive matching. Screen with verified date of birth, nationality and ID numbers, record why each match was cleared so it does not return, and leave fuzzy matching alone.
Charles Archibong, Co-founder
· 6 min read
Key takeaways
- OFAC's own guidance says many potential screening matches are false positives, and that it does not confirm matches for you.
- The safest lever is better customer data: a verified date of birth, nationality or ID number disqualifies most name-only hits.
- Raising the name-match threshold cuts alerts by missing spelling variants, which is the failure OFAC tells firms to guard against.
- A clearance should be tied to one customer and one list entry, and re-opened when either changes.
Most sanctions false positives are a data problem, not a matching problem. A screening engine that only knows a customer's name has no way to tell "Ibrahim Musa, born 1994 in Kano" from a listed person with the same name. Give it a verified date of birth, nationality and ID number, and most of those alerts disqualify themselves. Loosening the name matching does the opposite: it cuts alert volume by making the system blind to the spelling variants that real evasion depends on.
So the order of work is: improve the identifiers you screen with, make each analyst decision stick so the same match does not come back, and only then look at list and alias configuration. The name-matching threshold is the last lever to touch, and usually the wrong one.
Why do false positives happen in the first place?
The US Treasury's Office of Foreign Assets Control (OFAC) is plain about it. Its guidance on determining whether you have a valid match (opens in a new tab), updated on 9 September 2026, says: "Many potential matches identified through screening are false positives."
The usual causes:
Common names. Names shared by millions of people will match list entries that share them.
Transliteration. The same name written from Arabic or Cyrillic script into Latin letters has many spellings. The FATF's 2013 guidance on politically exposed persons (opens in a new tab) notes that inconsistent transliterations affect matching, and that screening against data with "insufficient or inadequate identifier information" produces many false positives and "increases the risk of missing true matches".
Thin customer records. If your record holds a name and nothing else, nothing can disqualify a name match.
Weak aliases. Some list entries include broad aliases that OFAC itself classifies as weak.
Lists you did not mean to screen. Screening tools often include non-sanctions lists; OFAC's first step is to check which list an alert came from.
Which levers reduce false positives without hiding real matches?
Lever | Effect on false positives | Risk to real matches | Verdict |
|---|---|---|---|
Screen with verified date of birth, nationality and ID number | Large reduction | Low | Do first |
Remember each clearance for that customer and that list entry | Stops repeat alerts on re-screening | Low, if scoped narrowly | Do second |
Exclude weak aliases | Moderate reduction | Some; OFAC treats this as a risk-based decision | Document the decision |
Screen only the lists relevant to each product | Moderate reduction | Low, if the policy is written down | Review yearly |
Auto-clear on a verified date-of-birth mismatch | Moderate reduction | Moderate; only safe where the list entry has a date of birth and yours is verified | Pilot with sampling |
Raise the name-match threshold | Large reduction | High | Avoid as a first move |
Why the last row: OFAC's sanctions compliance guidance for the virtual currency industry (opens in a new tab) (October 2021) tells firms to use fuzzy logic to catch "common name variations and misspellings", giving the example of a listed "Krayinvestbank" appearing in transaction data as "Krajinvestbank" or "Kray Invest Bank". A higher threshold is exactly what lets those through.
How should an analyst work a hit?
OFAC's FAQ sets out a sequence that works well beyond US sanctions. In short:
Confirm which list the hit is from. A match against a non-OFAC list goes to that list's owner or your own policy.
Pull the full list entry. Names, aliases, dates of birth, nationalities, ID numbers, addresses, and for entities, registration numbers.
Compare every identifier you hold. OFAC asks: does only the first or last name match, does the party have a different date of birth, identification number or nationality, is the address distinct? It also warns that an address match alone may not be enough, because many businesses share an address.
Decide. If very little matches beyond the name, you can reasonably clear it. If several details match (OFAC's example is full name, date of birth and country), treat it as a likely match under your procedures.
Record why. OFAC asks for complete records of the steps taken and the information relied on. It also says it does not confirm matches or false positives for you.
A worked example
An illustrative lender in Nigeria screens a new customer, Ibrahim Musa. Identity verification against the government record returned a date of birth in 1994 and Nigerian nationality. Screening returns a potential match to a listed individual of the same name.
The list entry gives a date of birth in 1958, a different nationality and a passport number. Three independent identifiers disagree and only the name agrees. The analyst clears the match, citing the date of birth, nationality and document number, and the decision is recorded against this customer and this list entry.
Now change one fact: the customer's record was imported from an old system with no date of birth. The same alert cannot be cleared on the evidence held. The right move is to collect the missing data (for example, by asking the customer to complete a verification), not to clear on a hunch.
How do you stop the same false positive coming back?
Ongoing screening means every customer is screened again and again. Without memory, a cleared homonym re-alerts on every run, and analysts learn to click through alerts, which is how a real match gets missed.
A clearance should be:
Scoped to one customer and one list entry. Never suppress a list entry for everyone, and never suppress a customer for every entry.
Re-opened when either side changes. A list entry that gains a new date of birth or alias, or a customer whose identity data changes, is a new question.
Explained. Record which identifiers disqualified the match, so a later reviewer or examiner can follow the reasoning.
How do you know it is working?
Track four things over time, per product: alerts per thousand customers screened, the share of alerts cleared, the time from alert to decision, and a quality sample. For the sample, a second analyst re-reviews a random set of cleared alerts each month. If clearances are being made on name difference alone, the sample shows it. You can also seed test names that should always alert and check that they still do after any configuration change.
A falling alert count with a stable quality sample is progress. A falling alert count with a worsening sample means you tuned out real risk.
Where does Myaza Trust help?
Watchlist Screening is built around the order above.
Verified identifiers. Customers onboarded through Identity Verification carry identity data checked against the government record in our five government-database markets, so screening has more than a name to work with.
Evidence on each match. A match shows the matched name, a match score, match types, aliases and selected identity evidence, so an analyst can compare identifiers in one place (screening documentation).
Decisions that stick. Clearing a false positive whitelists that match for that customer, so it does not re-flag on later re-screens. Confirming a match flags the identity. Each screening keeps a review history with the outcome, time, note and score at the time of the decision.
Honest gaps. When a profile cannot support the check, you receive
screening.insufficient_datarather than a clear result, andscreening.adjudication_overduefires when a match passes its review deadline (screening webhooks).
Screening reduces risk; it cannot guarantee that every listed person is caught, and your team still makes the call on each match.
A checklist for your next tuning cycle
Find the customers you screen with a name only, and plan how to collect verified identifiers for them.
Confirm clearances are stored per customer and per list entry, and re-open on change.
Write down your weak-alias and list-selection decisions and who approved them.
Leave the name-match threshold alone until the steps above are done, then test any change against seeded variants.
Start a monthly quality sample of cleared alerts.
Requirements differ by jurisdiction, and this article is general information, not legal advice.
Sources
Charles Archibong
Co-founder
Charles Archibong co-founded Myaza Trust. He writes about identity verification, financial technology, and the practical work of building trusted digital services.
