Sanctions Screening: Lists, Thresholds, and the False Positive Tax

Every regulated onboarding flow screens names against sanctions lists. The mechanics take minutes to wire up. The operational cost lands later, in the review queue, where an analyst decides whether "Ali Hassan" the applicant is "Ali Hassan" on a designation list. Get the tuning wrong and you either flood that queue with noise or let a true hit through. This is general information, not legal advice, but the engineering trade-offs are worth stating plainly.

Which Lists, and How Fresh

Sanctions screening starts with source data, not algorithms. The core lists are well known: OFAC SDN and its consolidated non-SDN entries, the EU consolidated list, the UK OFSI list, and the UN Security Council Consolidated List. Depending on your footprint you may add national lists and sector-specific designations.

• Update cadence: OFAC can add names any business day. A weekly refresh leaves a window; near-daily ingestion closes it. Log the version of each list used for every screening decision.
• Coverage of aliases: A single designated person may carry a dozen a.k.a. entries and multiple date-of-birth ranges. Screening only the primary name misses most real matches.
• Structured fields: Nationality, date of birth, and identifier numbers (passport, tax ID) let you confirm or clear a name hit that would otherwise sit ambiguous.

Match Logic and the Threshold Dial

Names rarely arrive clean. Transliteration, word order, missing middle names, and abbreviated legal suffixes all break exact matching. Fuzzy scoring bridges the gap, but every point you loosen the threshold widens the queue.

• Token-aware comparison handles reordered components: "Mohammed Al-Sayed" versus "Al Sayed, Mohammed" should score high without a literal string match.
• Phonetic and edit-distance methods catch spelling drift, but treat short and common names carefully — a two-token common name at a low threshold generates hits on nearly everyone.
• Secondary identifiers should raise or lower a score. A name that matches but with a date of birth 30 years off is not the same person; encode that instead of leaving it to the analyst.

Set the threshold against a labeled test set, not by intuition. Measure how many true designations you would still catch as you tighten, and how the false positive count falls. Document the chosen value and the rationale, because a supervisor may ask why it is set where it is.

The False Positive Tax

Most flagged names are not sanctioned. The cost is real: analyst hours, onboarding delay, and applicant friction. In a chat-based flow the delay is visible — the applicant sits waiting for a decision. Reducing false positives is therefore both a compliance and a conversion problem.

• Whitelisting cleared matches: once an analyst confirms an applicant is not the designated party, store that decision so the same benign hit does not re-fire on every rescreen.
• Enrichment before escalation: collect date of birth and nationality up front so the system can auto-clear scores that fail on those fields.
• Batch versus event: screen at onboarding, then rescreen against list deltas rather than the whole list, so only newly added names trigger review.

Rescreening and Recordkeeping

Sanctions status changes after onboarding. A customer clean at signup can be designated a year later, so ongoing screening against list updates is standard practice. Tie rescreening to list changes rather than a fixed calendar, and only re-evaluate the population affected by each delta.

For every screening event, retain what was checked: the input name and identifiers, the list versions, the match scores, the threshold, and the disposition with the analyst who made it. This is the record that demonstrates a hit was reviewed rather than ignored. Apply data minimization and configurable retention here too — keep the decision evidence you need for the required period, and no more identity data than the screening actually required.