What Is Sanctions Screening? A Complete Guide
Sanctions screening checks customers and counterparties against government prohibition lists. How the process works, and why screening once isn't enough.
Sanctions screening is the process of checking a name (a customer, counterparty, vessel, or supplier) against government lists of restricted parties. When a name matches, the check holds until a human decides whether the listed party and the party before you are the same person.
This guide covers what gets screened, how the pipeline works, why exact matching fails, and screening versus monitoring. Current as of August 2026.
What is sanctions screening, and why does it exist?
Sanctions screening exists because sanctions are prohibitions, not advisories. Governments designate people, companies, vessels and aircraft, then prohibit dealing with them. Screening is how a business finds out, before the money moves, whether it is about to break that prohibition.
Three properties shape every system built to meet the obligation:
- The prohibition is on you, not on your software. A missed designation is your violation regardless of which vendor's engine missed it.
- Liability does not require intent. OFAC civil liability is strict: a business that dealt with a designated party can be penalised without any finding that it knew or should have known [31 CFR Part 501, App. A]. The IEEPA civil maximum is the greater of roughly $377,700 per violation or twice the transaction value (2025-adjusted, unchanged into 2026) [Federal Register, 15 January 2025].
- The list changes without warning you. A customer clear at onboarding can be designated the following Tuesday.
Sanctions screening is not KYC, and it is not an AML programme:
- KYC / CDD establishes who your customer is: identity, documents, ownership, source of funds [FATF Recommendation 10].
- Sanctions screening establishes whether that verified identity is prohibited, a binary legal test.
- AML is the wider programme (transaction monitoring, SAR filing, risk assessment, governance) of which screening is one control.
Screening sits immediately downstream of KYC; you cannot screen a customer you have not identified.
What actually gets screened?
Names are the primary input, but a mature programme screens seven object types, and only some are name-matching problems. Confusing the categories is how teams buy the wrong tool.
| What you screen | Screened against | Key identifiers | Note |
|---|---|---|---|
| Customers and applicants | Sanctions lists, PEP data, law-enforcement lists | Name, DOB, nationality, country of residence | Default case; onboarding plus continuous thereafter |
| Beneficial owners, directors, signatories | Same | Name, DOB, ownership percentage | An unlisted company can still be blocked via owners: see the 50% Rule below |
| Counterparties and payment beneficiaries | Sanctions lists | Name, address, bank identifiers | Inside the payment flow; latency constrains design |
| Suppliers, distributors, end users | Sanctions plus export-control lists | Entity name, country, end-use | Export-control listings restrict items, not accounts |
| Vessels and aircraft | Lists carrying vessel/aircraft designations | IMO number, call sign, flag, tail number | Prefer structured identifiers over name matching |
| Goods and technology | Control-list classifications | HS code, ECCN | Classification against control lists, not name screening |
| Crypto wallet addresses | Blockchain-analytics data | Address string | Exact-match, not fuzzy; usually a different vendor category |
The last two rows are commercial traps. A name-screening vendor does not classify export goods or trace on-chain flows; an analytics vendor does not screen customer names. Most regulated businesses need name and entity screening as the base layer, then add the others as their activity requires.
How does the sanctions screening process work, step by step?
Six stages: input, normalisation, candidate retrieval, scoring, decision, and record. Every screening system worth the name does all six, and the failure modes are stage-specific.
| # | Stage | What happens | What goes wrong here |
|---|---|---|---|
| 1 | Input and validation | The entity is submitted with whatever attributes exist: name, type, date of birth, country | Garbage in: initials-only names, entire addresses stuffed into the name field, blank countries |
| 2 | Normalisation | Case folding, accent and punctuation stripping, transliteration to a common script, honorific and legal-suffix removal, tokenisation, phonetic encoding | Silent loss: over-aggressive stripping destroys the signal that would have matched |
| 3 | Candidate retrieval | The normalised forms are searched against indexed list data across several strategies at once, producing a candidate set | Recall failure. A designation missed here can never be recovered downstream |
| 4 | Scoring | Each candidate is scored on name similarity plus corroborating attributes: date of birth, nationality, entity type | Score inflation from a single strong signal; no allowance for common-name frequency |
| 5 | Decision | Above the threshold, the match becomes an alert for human review: true match, false positive, or escalation | Undocumented decisions: defensible only if the reasoning is captured, not just the outcome |
| 6 | Record and monitor | The screening, the matches, the decision and the decider are written to an immutable audit trail, and the entity is enrolled in ongoing monitoring | Records that capture the decision but not the configuration that produced it |
Stages 2–4 are where vendors differ. Stage 6 is where examinations are won or lost.
One point that surprises people: a high match score is not a match. It is a ranked hypothesis. The system should present enough context (dates of birth, nationalities, which list, which programme) for a person to resolve it. Auto-blocking on score alone blocks real customers; auto-clearing on score alone eventually clears a designated one.
Why doesn't exact name matching work?
Because the name on the list and the name on the application are almost never spelled identically, and a sanctions evader is actively working to keep it that way. Exact matching catches only the party who filled in your form using the same transliteration a designating government chose.
The gap comes from five sources:
- Transliteration. Arabic, Cyrillic, Chinese and Korean names have no single correct Latin spelling. Mohammed, Muhammad and Mohamad are all valid Latin spellings of the same Arabic name.
- Name order and structure. Given-name/family-name order inverts across cultures; patronymics, matronymics, compound surnames and particles (van, de, al-) all move.
- Partial and informal forms. Middle names dropped, initials substituted, diminutives, married versus maiden names, anglicised forms.
- Data quality. OCR errors from document capture, adjacent-key typos, fields transposed at entry.
- Deliberate obfuscation. Small spelling variations introduced on purpose, or a shell company interposed so that no listed name appears anywhere in the transaction.
Screening engines answer this with layered techniques: normalised comparison, token-level matching, phonetic encoding such as double metaphone, and edit-distance measures, each catching what the previous one misses, and each adding false positives. See our guide to fuzzy name matching for sanctions for the technique-by-technique breakdown. For a buyer, "we do fuzzy matching" is not a specification: ask which techniques, against which fields, and at what measured cost in alert volume.
Honest limit: no name-matching technique solves deliberate obfuscation through an unlisted intermediary. That is what ownership screening and transaction monitoring are for.
What is the difference between sanctions screening and ongoing monitoring?
Screening is a check at a point in time. Monitoring is re-running that check every time the lists change. This is the distinction beginners miss most often.
A customer screened clear on 1 March is not clear on 1 June. Nothing about them changed. The lists did. Whether you find out depends on your re-screening model:
| Model | What it is | Typical exposure window | Operational load |
|---|---|---|---|
| Onboarding only | Screen once, at account opening | Unbounded: grows for the life of the relationship | Lowest, and effectively indefensible for a regulated firm |
| Periodic re-screening | Re-screen the whole book on a fixed cycle (annual, quarterly, monthly) | Half the cycle on average: six weeks on a quarterly cycle | Large, spiky batches; a review queue that arrives all at once |
| Event-driven | Re-screen on a trigger: a large transaction, a change of address, a periodic review | Depends entirely on trigger coverage | Moderate; risk sits in the events you didn't think to trigger on |
| Continuous monitoring | Re-screen affected entities whenever a source list changes | Bounded by ingestion cadence: minutes to hours | Steady and small; alerts arrive as designations happen |
Most frameworks require ongoing due diligence without prescribing a frequency: FATF Recommendation 10 and OFAC's Framework for Compliance Commitments both expect controls to keep pace with list changes, without setting an interval [FATF Recommendation 10; OFAC, May 2019]. That silence is not permission to screen once; the burden is on you to show your cadence is proportionate to risk. A cadence measured in months against lists that change in days is a hard argument in front of an examiner.
The fair counterargument: continuous monitoring produces more alerts. The answer is not to re-screen less often. It is to tune thresholds and route by risk.
What happens when there's a match?
A match is a question, not a verdict. Three outcomes exist, and treating the middle one as either of the outer two is where programmes fail.
| Outcome | What it means | What happens next |
|---|---|---|
| No match | Nothing above threshold on any screened list | Proceed. Record that the screening ran, against which list versions, and with what result: a clear screening is evidence and must be retained |
| Potential match, pending review | One or more candidates above threshold, unresolved | Hold the relationship or transaction pending review. An analyst compares all available identifiers and decides |
| True match | Confirmed as the designated party | Freeze or reject per the applicable regime, escalate internally, and meet the reporting obligation |
For a true match, reporting is concrete and fast. Under US rules, blocked property must be reported to OFAC within 10 business days, with an annual blocked-property report due by 30 September; rejected transactions carry their own 10-business-day report [31 CFR 501.603, 501.604]. Comparable duties exist under UK and EU regimes.
Two cautions. First, what you tell the customer is constrained: a freeze generally has to be explained, but related suspicion reports typically must not be disclosed. Decide the script with counsel before you need it. Second, an unlisted company can still be blocked. Under OFAC's 50% Rule, an entity owned 50% or more in aggregate by blocked persons is itself blocked even though it appears on no list [OFAC guidance, 13 August 2014]. The EU and UK apply comparable ownership-and-control tests with different thresholds. Name screening alone will never surface these entities. You need ownership data. Our comparison of the OFAC, EU, UN, UK and DFAT lists works through the three ownership tests side by side.
Who is legally required to screen?
Almost everyone is bound by sanctions prohibitions; a narrower set is required to run a formal screening programme. The distinction gets missed constantly, and it cuts against the intuition that only banks need to care.
Prohibitions apply by jurisdictional nexus, not by industry. US persons (citizens and permanent residents anywhere, entities organised under US law, and anyone physically in the US) are prohibited from dealing with SDNs regardless of sector. EU and UK measures work the same way for their respective persons. A software company, freight forwarder or marketplace often has no screening mandate in the rulebooks and is still fully exposed to the underlying prohibition.
Regulated sectors additionally carry a programme obligation: documented policies, screening controls, testing, training and record-keeping. Banks, payment institutions, e-money firms, crypto service providers, insurers, and regulated lenders sit here in most jurisdictions. For the jurisdiction-by-business-type breakdown, see sanctions screening legal requirements.
Practical read for an unregulated business with international exposure: you probably have no explicit screening mandate, and you certainly have liability. Screening is the cheapest way to manage it.
Frequently asked questions
Is sanctions screening the same as KYC? No. KYC verifies who the customer is; sanctions screening checks that verified identity against prohibition lists. KYC is a risk-based process with graded outcomes. A sanctions designation is binary. The party is listed or is not.
How often should I screen? At onboarding, and thereafter whenever the lists change rather than on a calendar. Periodic re-screening leaves an exposure window averaging half the cycle length: six weeks on a quarterly cycle. If continuous monitoring isn't available to you, screen at least monthly and document why that interval is proportionate to your risk.
Can sanctions screening be automated? Matching, scoring, monitoring and record-keeping can and should be: the volume is far beyond manual capacity. Adjudication of a potential match should stay with a person, with the reasoning recorded. Auto-clearing below a threshold is normal; auto-clearing above one is a finding waiting to happen.
What is a false positive? An alert where review confirms the customer is not the listed party, usually a common name, partial match, or phonetic collision. False positives are the dominant operational cost; the fix is threshold tuning and better corroborating data, never lowering recall.
Do I need to screen existing customers, or only new ones? Both. Your existing book is where risk accumulates: those relationships have been exposed to every list change since they opened.
Citations
- FATF, International Standards on Combating Money Laundering and the Financing of Terrorism & Proliferation, Recommendations 6, 7 and 10, https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Fatf-recommendations.html
- OFAC, A Framework for OFAC Compliance Commitments, May 2019, https://ofac.treasury.gov/media/16331/download
- OFAC, Revised Guidance on Entities Owned by Persons Whose Property and Interests in Property Are Blocked, 13 August 2014, https://ofac.treasury.gov/faqs/399
- 31 CFR Part 501 (Reporting, Procedures and Penalties Regulations), §§ 501.603–501.604 and Appendix A (Economic Sanctions Enforcement Guidelines), https://www.ecfr.gov/current/title-31/subtitle-B/chapter-V/part-501
- Federal Register, Inflation Adjustment of Civil Monetary Penalties, 15 January 2025 (90 FR 3687), https://www.govinfo.gov/content/pkg/FR-2025-01-15/html/2025-00786.htm
Screening that keeps pace with the lists
The hard part of sanctions screening isn't the first check. It's the ten thousandth: re-run every time a government publishes a change, with every decision recorded well enough to explain two years later.
DeRisk Hub screens individuals, organisations, vessels and aircraft against global sanctions, export-control, law-enforcement and PEP data, re-screens monitored entities when a source list changes, and writes every decision to an audit trail. See the screening platform, the compliance glossary, or the API documentation. Start your free trial, or go to DeRiskHub.com.
This article is informational and does not constitute legal advice. Regulatory positions described here were verified against the issuing bodies' published material in August 2026 and change frequently; confirm against the primary source before relying on any of it.