False-positive hygiene in sanctions screening

Ask a compliance analyst what's wrong with their screening tool and the answer is rarely "we miss things." It's almost always "we get too many alerts, and most of them are nothing." That complaint sounds like an efficiency problem. It's actually a risk problem: OFAC's sanctions liability is strict — intent and knowledge are not a defense — and a program generating hundreds of low-quality alerts a day trains its own analysts to clear things quickly, which is exactly the condition under which a real match gets waved through. False-positive hygiene isn't a UX nicety. It's a control that determines whether the true positives in the pile actually get caught.

Why false positives happen

Most false positives trace back to one of a small number of root causes, and they compound:

• Common names. "Mohammed Ahmed" or "John Smith"-shaped names produce matches against a meaningful fraction of any customer base, independent of any real connection to the sanctioned individual.
• Transliteration variance. Names transliterated from Arabic, Cyrillic, or Chinese script into Latin characters have multiple valid romanizations — "Gaddafi," "Qaddafi," and "Kadhafi" are the same name. A matching algorithm tuned for Latin-script typos handles this differently than one built for cross-script variance, and the wrong one either misses the real variant or treats every romanization choice as a near-match to everything.
• Weak or absent secondary identifiers. A hit based on name alone, with no date of birth, nationality, or national ID to narrow the field, cannot distinguish the sanctioned individual from an unrelated person who happens to share the name.
• Alias sprawl with no strength signal. Designated entities frequently carry ten or more known aliases — full legal-name variants, single-word nicknames, prior company names. Treating a thin, one-word AKA with the same matching weight as a strong, unique alias increases hits against anyone whose name happens to contain that fragment.

The tension, stated plainly

Every lever that reduces false positives also has the ability to reduce false negatives if pulled too far. That's the whole difficulty of this problem: a fuzzy-matching threshold tightened enough to stop flagging "John Smith" against every customer named John Smith is also a threshold that can let a genuine near-miss transliteration through unflagged. Tuning for a quiet queue and tuning for defensible coverage are not the same objective, and a program that only measures "alerts per day" going down has no way to tell which one it actually achieved. Any false-positive reduction effort needs to state, and be able to demonstrate, that recall on true matches didn't move.

Concrete techniques

1. Match on more than the name. The single highest-leverage change is using every identifier a source actually publishes — date of birth, place of birth, nationality, passport or national ID number, and for vessels, the IMO number, which is far more discriminating than a vessel name. A name-only match against a common name is close to unusable; the same name plus a date of birth narrows the field by orders of magnitude, in both directions — it clears unrelated namesakes and raises confidence on a genuine match. This is why the source catalog lists exactly which identifiers each list publishes: two sources with the same nominal coverage can have very different matchability depending on what fields the issuing authority actually discloses.

2. Treat aliases as having different strengths, not one undifferentiated list. A full legal-name alternate spelling and a single-word nickname are not equally diagnostic. Programs that score every AKA identically inherit the false-positive rate of their weakest alias. Where a source distinguishes strong and weak aliases, carry that distinction into matching logic rather than flattening it.

3. Use a matching algorithm suited to the script and language, not one general-purpose edit-distance function. Cyrillic and Arabic transliteration variance is a known, bounded problem — phonetic and transliteration-aware matching handles it meaningfully better than raw string-edit-distance thresholds tuned for typos in Latin text. A single global threshold, applied uniformly across name origins, is a common and avoidable source of both kinds of error at once.

4. Track disposition history — without ever suppressing screening. When an analyst clears a hit as "reviewed, not a match" for a specific customer, recording that determination avoids re-litigating the identical low-value alert every screening cycle. The discipline that matters here: this reduces repeat noise on a documented non-match, not the underlying screening. The list is still checked every time; only the alert-fatigue cost of an already-resolved determination goes down. Silently suppressing a name from future screening is a materially different, much riskier decision, and should never be a side effect of noise reduction.

5. Use source lineage to help analysts triage, not just to audit after the fact. Knowing which authority, program, and list a hit came from lets a reviewer sanity-check plausibility quickly — a hit against a Democratic Republic of Congo sanctions program for a customer with no African business nexus carries different priors than a hit against an OFAC Russia-program listing for a customer with Russian counterparties. This is a direct, practical payoff of the same source-transparency posture that underlies our data catalog: provenance isn't just for the audit trail, it's a triage signal in the moment.

The regulatory backdrop

OFAC's own Framework for Compliance Commitments treats screening quality — coverage, freshness, fuzzy-matching calibration, and resolution of the 50 Percent Rule's ownership chains — as a documented control examiners look for, not an internal implementation detail left to vendor discretion. A program that can't explain why its match thresholds are set where they are, and can't show that a false-positive-reduction change didn't cost it recall, doesn't have a defensible control — it has a queue that happens to be shorter.

Where to check your own matching

Browse the source catalog to see which identifiers and alias structures each list actually publishes, browse the full corpus to see real alias density and identifier coverage record by record, and see our AML/CFT jurisdiction guides for how each regulator frames screening-quality expectations in its own supervisory language.