Sanctions Screening
Sanctions screening is the process of checking customers, counterparties and payments against lists of individuals, entities, vessels and jurisdictions that a government has restricted dealings with. Unlike most financial crime controls, it is not risk-based: a sanctions prohibition is absolute, and there is no threshold below which a match can be ignored.
That absoluteness is what makes the control difficult. The obligation is to catch every match, and the cost of trying is an enormous volume of matches that are not real.
| What is checked | Customers at onboarding, the book periodically, and payments in flight |
| Against what | OFAC SDN, UN, EU, UK OFSI and other national lists |
| Legal character | Strict liability in most regimes — intent is not a defense |
| Typical false positive rate | Commonly above 90% of alerts generated |
| Screened attributes | Name, date of birth, place of birth, nationality, address, identifiers |
| Related but distinct | Adverse media and PEP screening, which are risk signals rather than prohibitions |
How sanctions screening works
Screening runs at three moments, and they are not interchangeable.
At onboarding, before the relationship begins, so a prohibited party is never taken on. Across the existing book, rescreened whenever lists change — which is frequent, and matters because a customer onboarded legitimately can be designated afterward. On payments in flight, where the check has to complete in the time a payment message takes to process, against names in free-text fields that were never designed for matching.
The matching itself is fuzzy by necessity. Exact string comparison would fail immediately: names are transliterated differently from Arabic, Cyrillic and Chinese, order varies by culture, spellings differ between sources, and sanctioned parties deliberately use variants. So screening systems apply phonetic algorithms, edit-distance scoring and cultural name-handling rules, producing a similarity score against a configured threshold.
Everything above the threshold becomes an alert requiring human disposition. Lowering the threshold catches more and generates more noise; raising it does the reverse. There is no setting that avoids the trade, which is the central operational fact of this control.
Why false positives dominate
Alert volumes in the tens of thousands per month with true-match rates well under one percent are ordinary rather than exceptional. Four causes account for most of it.
- Common names. A sanctioned individual with a name shared by hundreds of thousands of people generates a hit on every one of them.
- Sparse list data. Where an entry carries a name and little else, there is nothing to discriminate with. A full date of birth resolves most name collisions instantly; many entries do not have one.
- Poor input data. Payment messages carry truncated names, missing addresses and inconsistent formatting, so the system matches on the weakest possible evidence.
- Conservative thresholds. Since a missed match is a strict liability breach and a false positive is only expensive, every incentive pushes the threshold down.
The consequence is that sanctions screening is mostly a data quality problem wearing a matching problem’s clothes. Teams tune algorithms because that is the visible lever, when the constraint is usually that the identity data being screened is too thin to discriminate on.
Why it matters for identity verification
Screening quality is capped by the quality of the identity data going into it, and this is the connection most discussions of the topic skip.
A screening engine comparing a self-asserted name against a list entry is matching two strings. The same engine comparing a verified full name, date of birth, nationality and document number extracted from an authenticated identity document is matching a record. The second discriminates; the first cannot, because there is nothing to discriminate with.
The practical effect is direct. A shared name plus a differing date of birth is a clear non-match that closes in seconds. A shared name and nothing else is an investigation. Every additional verified attribute collapses a category of false positive, which means document verification at onboarding reduces alert volume for years afterward — a compliance cost saving that shows up in a different department from the one that paid for it.
It also addresses the failure mode nobody wants to discuss. Screening a name that was never verified produces a clean result against an identity that may not belong to the customer. The control ran correctly and confirmed nothing.
Sanctions screening compared with adjacent checks
| Sanctions screening | PEP screening | Adverse media | |
|---|---|---|---|
| What a hit means | A legal prohibition | A risk factor | An allegation |
| Correct response | Block, freeze, report | Enhanced due diligence | Assess and document |
| Risk-based? | No — absolute | Yes | Yes |
| Source | Government lists | Commercial and official data | News and public sources |
| Declining on a hit alone | Required | A failure to apply the control | Rarely appropriate |
Conflating these is a common and consequential error. Sanctions hits are prohibitions; PEP and adverse media hits are inputs to a judgment. Treating all three the same way produces both over-declining and the appearance of control where none was applied.
What sanctions screening cannot do
It cannot catch a party who is not on a list. Screening is a lookup. Ownership structures, nominees and newly formed entities exist precisely to keep the screened name off the list, which is why beneficial ownership work sits alongside screening rather than after it.
It cannot fix bad input. A truncated name in a payment message limits what any engine can conclude, regardless of sophistication.
Alert volume is not evidence of effectiveness. A system generating 50,000 alerts a month may be well-tuned or may be substituting volume for precision. Regulators increasingly ask about disposition quality and tuning methodology rather than counts.
It does not verify identity. Screening confirms whether a claimed identity appears on a list. Whether the claim is true is a separate question, answered earlier, by a different control.
Frequently asked questions
What is the difference between a sanctions list and sanctions screening?
The list is the published set of restricted parties; screening is the process of checking your customers and payments against it. A sanctions list is data, maintained by a government; screening is an operational control you run and must evidence.
Why are sanctions screening false positive rates so high?
Because matching must be fuzzy to handle transliteration, name order and deliberate variation, and because thresholds are set conservatively given that a missed match carries strict liability. Combined with sparse list data and poor-quality input names, this produces alert volumes where the great majority are not real matches.
Can sanctions screening be fully automated?
Alert generation is automated. Disposition generally is not, and most regimes expect human judgment on potential matches. Automation is increasingly accepted for closing clearly weak alerts, provided the logic is documented, tested and independently validated.
How often should the existing customer book be screened?
Whenever the lists change, which for major regimes is frequently. Periodic rescreening on a fixed cycle leaves a gap between a designation and the next run, and that gap is exactly when a newly designated customer is still being served.
Related reading
- Sanctions list — the underlying lists screening checks against
- Global watchlist — the commercial compilations most systems actually screen
- False positive ratio — the metric that governs screening tuning
- Anti-money laundering — the wider framework screening sits inside
