Sanctions screening explained: how it works, the OFAC, UN, EU and UK lists, false positives, sanctions vs PEP, and how to screen in 2026 without storing PII.
Table of contents
- Sanctions screening checks customers, counterparties and transactions against government watchlists, so a business never deals with a designated party.
- The Office of Foreign Assets Control (OFAC) applies strict liability: you are liable for a prohibited dealing even with no knowledge or intent, and ignorance of a designation is not a defence.
- The maximum OFAC civil penalty under the International Emergency Economic Powers Act (IEEPA) is $377,700 per violation, or twice the transaction value, and penalties accrue per violation, so real exposure runs into the millions.
- In July 2025, OFAC settled with Interactive Brokers LLC for $11,832,136 over 12,367 apparent violations, with failures traced directly to screening gaps.
- The lists you must screen depend on your jurisdiction; commonly cited industry benchmarks put false positives at 90% or more of all alerts.
- The overlooked question is architectural: most screening vendors centralise customer data to run matches, which builds a breach honeypot you do not actually need.
Sanctions screening is the process of checking customers, counterparties and transactions against government watchlists, such as the OFAC SDN List, the UN Consolidated List and the EU Consolidated List, to ensure a business does not deal with sanctioned individuals or entities. It runs at onboarding, in real time on transactions, and continuously as lists update.
TL;DR
Sanctions screening matches customer and transaction data against government watchlists, the OFAC SDN List, the UN and EU Consolidated Lists, and the UK Sanctions List, so you never deal with a designated party. It runs at onboarding, in real time, and continuously, because OFAC applies strict liability and updates its lists frequently with no fixed schedule. The maximum penalty is $377,700 per violation, and penalties stack, as Interactive Brokers learned with an $11.8 million settlement in 2025. List coverage and fuzzy matching are table stakes. The question buyers miss is architectural: most vendors centralise customer data to screen it, building a breach honeypot. You can verify a customer is not sanctioned without holding that data centrally at all.
What is sanctions screening?
Sanctions screening is the process of checking customers, counterparties and transactions against government watchlists, such as the OFAC SDN List, the UN Consolidated List and the EU Consolidated List, to ensure a business does not deal with sanctioned individuals or entities. It runs at three points: at onboarding before an account opens, in real time on payments before they settle, and continuously, because a clean customer today can be designated tomorrow.
It helps to separate two things people often blur. Screening is the check itself, the act of matching a name, date of birth or wallet against a list. Sanctions compliance is the whole programme around it: policy, thresholds, alert handling, blocking, reporting and recordkeeping. Screening is a legal obligation, not a nice-to-have, and it reaches far beyond banks. Fintechs, neobanks, crypto and web3 platforms, iGaming operators, marketplaces and any regulated business that onboards customers or moves money has to do it. For the short reference definition, our OFAC checks and sanctions screening glossary entry owns the quick "what is it" answer; this page is the operator's version that goes deep.
Why does sanctions screening matter?
Sanctions screening matters because the penalty regime is unforgiving in a way most compliance rules are not. OFAC applies strict liability. United States persons are liable for prohibited dealings with a designated party even without knowledge or intent, and OFAC's own enforcement guidelines make clear that ignorance of a designation is not a defence. You do not get to argue you did not know.
The headline number that circulates in vendor blogs, roughly $1.3 million per violation, is wrong, and citing it in an audit policy will undermine you. The correct figure is in the primary source. Under the International Emergency Economic Powers Act (IEEPA), the maximum civil monetary penalty is $377,700 per violation, or twice the value of the underlying transaction, whichever is greater, following the inflation adjustment effective 15 January 2025. The reason exposure still reaches eight figures is that penalties accrue per violation, not per case.
The clearest recent proof is dated and named. On 15 July 2025, OFAC settled with Interactive Brokers LLC for $11,832,136 over 12,367 apparent violations between 2016 and 2024 across multiple sanctions programmes. Several of the failures were screening-related: a geo-block that could be bypassed, inadequate securities screening during automated margin liquidation, and transfers processed to blocked Russian banks. OFAC classed the conduct as non-egregious and voluntarily self-disclosed, and credited substantial cooperation and remediation, which is why the settlement came in at $11.8 million against a statutory maximum near $5 billion. That mitigation matters for context, but it does not soften the lesson: even a firm that self-reports and remediates still pays eight figures when a screening gap repeats across thousands of transactions. It was OFAC's first major brokerage enforcement action, and it shows how a screening gap, multiplied across thousands of transactions, becomes a settlement. List updates compound the pressure, because a customer who passes today can become a target overnight. Our AML transaction monitoring guide covers the wider programme this screening sits inside.
Which lists must you screen?
The lists you must screen depend on your jurisdiction, your customers and where you move money, and this is the section the keyword "sanctions list screening" is really asking about. There is no single global list. There are several authoritative ones, each with its own issuer, scope and update rhythm, and 2026 brought a structural change to the United Kingdom that older guides miss.
The big five for most regulated firms are the OFAC SDN List, the OFAC Consolidated Sanctions List, the United Nations Security Council Consolidated List, the EU Consolidated List, and, since January 2026, the UK Sanctions List. The OFAC SDN (Specially Designated Nationals) List is the primary United States enforcement list: being on it means your assets are blocked. The OFAC Consolidated List groups the non-SDN programmes, including the Sectoral Sanctions Identifications (SSI) List, the Foreign Sanctions Evaders (FSE) List, the Non-SDN Palestinian Legislative Council (NS-PLC) List, the Correspondent Account or Payable-Through Account Sanctions (CAPTA) List, and the Non-SDN Chinese Military-Industrial Complex Companies (NS-CMIC) List, which impose narrower restrictions rather than a full asset freeze. These programmes change: OFAC removed the last name on the FSE List on 18 December 2025, leaving it empty for now. Confirm the exact sub-list composition against OFAC's Consolidated Sanctions List page before you hard-code it into policy, because programme names and contents evolve.
Here is the original coverage and cadence matrix to lift straight into an audit document.
| List | Issuing authority | Who is bound and scope | What designation does | Update cadence | Must you screen it? |
|---|---|---|---|---|---|
| OFAC SDN List | US Treasury, OFAC | US persons worldwide; non-US persons causing US-nexus violations | Full asset freeze; dealings prohibited | Frequently, often multiple times per week, no fixed schedule | Yes, if any US nexus (US persons, USD, US-based systems) |
| OFAC Consolidated (SSI, FSE, NS-PLC, CAPTA, NS-CMIC) | US Treasury, OFAC | US persons; activity-specific restrictions | Sectoral or partial restrictions, not a full freeze | Frequently, alongside SDN updates | Yes, where the relevant programme applies to your activity |
| UN Security Council Consolidated List | UN Security Council | All 193 member states via Article 25 of the UN Charter, implemented in domestic law | Asset freeze, travel ban, arms embargo | Periodically as resolutions change | Yes, as implemented by your jurisdiction |
| EU Consolidated List | European Union (Council) | EU member states, citizens and entities | Asset freeze and economic restrictions | Periodically as regulations change | Yes, if you operate in or touch the EU |
| UK Sanctions List | UK Foreign, Commonwealth and Development Office (FCDO) | UK persons and entities worldwide | Asset freeze and restrictions | Periodically | Yes, if you have a UK nexus |

Two facts anchor the table. The United Nations Security Council Consolidated List is binding on all 193 member states under Article 25 of the UN Charter, with each state implementing through its own domestic law. As of 6 November 2025 it contained 727 individuals and 273 entities, and it was last updated on 21 May 2026. The 2026 change is the one to flag loudly: the UK Office of Financial Sanctions Implementation (OFSI) "Consolidated List of Asset Freeze Targets" closed at 9am on 28 January 2026 and is no longer updated. The UK Sanctions List, maintained by the FCDO, is now the single authoritative source for UK designations. Any guide still pointing you at the OFSI Consolidated List as a live source is stale.
Sanctions lists are not the only watchlists in a screening pass. Politically exposed person (PEP) lists and adverse media feeds usually run in the same sweep, which we cover in the PEP and sanctions distinction below.
How does sanctions screening work?
Sanctions screening works as a pipeline that turns raw customer data into a defensible decision, and understanding the order matters because false positives are born at one specific step. The flow is the same whether you run it in-house or buy it.
First comes data collection and normalisation. You gather the identifying fields, name, date of birth, country, and for businesses the registered entity and its beneficial owners, then standardise formats so a match engine can compare them. Second is matching. The engine compares your data against list entries using exact, fuzzy and phonetic logic. Fuzzy and phonetic matching exist because names travel badly across alphabets: the same person appears as Gaddafi, Qaddafi and Kadafi depending on transliteration, and a screen that only does exact matching would miss all but one spelling. Third is alert generation and scoring, where the engine assigns a confidence score to each candidate match and surfaces anything above a threshold you set.
Fourth, and non-negotiable, is human review and disposition. A flagged hit is a candidate, not a verdict. A trained analyst examines it, checks secondary identifiers, and records a documented decision: true match or false positive. Fifth is blocking, reporting and recordkeeping. A confirmed match means you block the asset or transaction, file the required reports, such as an OFAC blocked-property report, and retain an auditable trail of who decided what and why. That trail is what an examiner asks for first. The tuning of the matching threshold in step two is where the cost is decided, which is the subject of the false positives section below.
When should you screen customers?
You should screen customers at three checkpoints, and skipping any one of them leaves a strict-liability gap. Treating screening as a one-time onboarding gate is the most common and most expensive mistake, because it assumes the world stops changing after an account opens.
The first checkpoint is onboarding, before the account opens, as part of your Customer Identification Program (CIP). This is where sanctions screening connects to the broader KYC software flow: you verify who the customer is, then confirm they are not on a list. The second is real-time transaction screening, where each payment is checked before it settles, so a transfer to a newly designated counterparty is stopped rather than recovered after the fact. The third is ongoing, or periodic, rescreening of your existing customer base against updated lists. Because OFAC and others update frequently with no fixed schedule, a customer who was clean at onboarding can be designated months later, and only rescreening catches it. Daily rescreening is widely treated as best practice for exactly this reason. Our decentralised KYC explainer shows how these checkpoints fit a privacy-first onboarding design.
Why are false positives so expensive?
False positives are expensive because most alerts are noise, and every piece of noise still costs an analyst's time. This is the "John Smith problem": a common name collides with a sanctioned individual who shares it, and your innocent customer is flagged as a potential terrorist financier. Multiply that across a large book and the review queue balloons.
The scale is well documented. Industry benchmarks from sources including Alessa, LexisNexis and KPMG cluster around 90% to 95%, and a peer-reviewed study indexed in PubMed Central confirms that false positives comprise over 90% of all sanctions alerts. So the commonly cited figure of "90% or more of alerts are false positives" is a reasonable industry estimate to work from, not a single official statistic. The cost is twofold: direct review labour, and indirect friction, because customers abandon onboarding while their alert sits in a queue.
The lever is the matching threshold, and it cuts both ways. Set fuzzy sensitivity too high and you drown in false positives. Set it too low and you miss a true match, which under strict liability is the far more dangerous error. The honest answer is not to pick a sensitivity, it is to add context. Screening on name alone is what generates the noise; screening on secondary identifiers, date of birth, country, and known aliases, lets you confirm or clear a candidate far faster and with a documented basis. Contextual matching is the difference between a queue you can defend and one that buries your team. The same matching logic governs the wider alerting programme, which our AML transaction monitoring guide breaks down, and feeding verified attributes from KYC software into the match is what keeps the false-positive rate down at source.
What is the difference between sanctions and PEP screening?
The difference between sanctions screening and PEP screening is the difference between a prohibition and a risk flag, and conflating them creates both legal and commercial errors. They run in the same pass but mean opposite things for whether you can do business.
Sanctions screening identifies prohibited parties. If a customer is a true match to a sanctions list, you cannot transact at all; this is strict liability and the consequence is blocking and reporting. PEP screening identifies politically exposed persons, individuals who hold or held prominent public functions and therefore carry a higher risk of corruption or conflict of interest. A PEP match is not a prohibition. You can transact with a PEP, but you must apply enhanced due diligence, establish their source of wealth and funds, and monitor the relationship more closely. Treating a PEP like a sanctioned party means turning away legitimate business; treating a sanctioned party like a PEP means committing a violation. Well-run programmes run sanctions, PEP and adverse media checks together in one screening pass, then route each hit down the correct path. The enhanced due diligence a PEP triggers sits inside the same onboarding flow as your AML compliance software, so the PEP path and the sanctions path share one verified identity rather than re-collecting data twice.
What should you look for in software?
What you should look for in sanctions screening software is easy to list and easy to get wrong, because most evaluations stop one criterion short of the one that matters. The table-stakes requirements are real and you should demand them, but they are not where vendors differ most.
Start with the obvious checklist: list coverage and update latency across OFAC, UN, EU and UK sources; matching accuracy with controls to manage false positives; both real-time and batch screening; secondary-identifier matching on date of birth and country; an audit trail with explainability for every disposition; clean API integration into your existing onboarding and payment stacks; and ongoing rescreening, not just onboarding. Incumbents you will meet in this category, by function rather than ranking, include Sumsub, Onfido, Veriff, Jumio, Trulioo, Persona, ComplyAdvantage and LSEG. Our identity verification software comparison and AML compliance software guide break the category down.
Then add the criterion most buyers never put on the list: data handling. To screen a customer, does the vendor have to ingest and centrally store that customer's personal data? Most do, and most buyers treat it as an unavoidable cost of compliance. It is not, and the next section explains why that question belongs at the top of the evaluation, not the bottom.
Who holds your customers' data during screening?
The question almost no screening guide asks is who is holding your customers' personal data while you screen them, and whether they need to hold it at all. Every incumbent in this market treats screening as a list-matching and software-selection problem and quietly assumes the vendor must centralise customer identity data to run the match. That assumption is the actual risk, because a central store of verified identity data is a breach honeypot, valuable to attackers precisely because it is complete and concentrated.
This is not hypothetical, and the 2026 evidence is specific. The KYC vendor Sumsub ran an intrusion that went undetected for roughly 18 months: initial access came in July 2024 through a third-party support ticketing platform, the breach was discovered in a January 2026 security audit, and Sumsub disclosed it in early February 2026. It exposed names plus a subset of emails and phone numbers of users across the crypto exchanges that relied on it. No biometrics or identity images were confirmed accessed, but the pattern is the point: a vendor's central store became everyone's problem. Shortly after, security researchers found that age-verification vendor Persona, running Discord's UK trial, had left its government dashboard codebase, around 2,500 files, exposed on a public endpoint; the code revealed Persona ran 269 verification checks including watchlist, PEP and adverse-media screening across 14 adverse-media categories. Discord cut ties. That exposure surfaced months after a separate breach at its customer-service vendor 5CA, disclosed in early October 2025, that exposed roughly 70,000 government identity documents, a figure Discord confirmed even as the attackers disputed it with extortion claims of more than two million.
The honest counter-argument deserves a hearing. Plenty of well-run vendors hold customer data in a SOC 2 environment, encrypt it at rest, minimise what they keep, and pass their audits year after year. Centralisation is not negligence, and a careful operator can manage it. But the Sumsub case shows the limit of that defence: encryption and certification did not prevent an 18-month undetected breach through a third party. The structural fact remains that a complete, standing store of identity data is a single target, and the strongest control is not to hold it at all. Our analysis of why your KYC vendor is your biggest data breach risk walks through the architecture.
That is the reframe Zyphe was built around. You can verify a customer is not sanctioned without ever assembling a central store of their data. Zyphe shards personal data across a decentralised network of more than 60,000 nodes, so no single node holds a complete record, and reconstruction requires a 29-of-100 threshold scheme. The customer holds the key; there is no master key and no central honeypot to breach. Screening still runs, and the audit trail is exportable and examiner-ready, but the standing target that turned Sumsub and Persona into headlines is simply not created. Removing the obligation to store and secure that data internally also removes the cost of defending it. The result is a reusable credential, a KYC passport, verified once and re-presented elsewhere, integrated through a single API in about fifteen minutes. See how Zyphe works for the mechanics, or our AML software page for the screening side.
The sanctions screening coverage and compliance checklist
Use this seven-point checklist to pressure-test a programme or a vendor. It is built to lift straight into an audit policy, and it is a starting point, not legal advice.
Download: the sanctions screening coverage matrix (PDF) is a one-page, print-ready version of the list coverage and cadence table you can keep beside your onboarding and policy documents.
- ] Confirm required lists by jurisdiction: map OFAC (SDN and Consolidated), UN, EU and the UK Sanctions List to your customer base and money flows, and retire any reference to the closed OFSI Consolidated List.
- ] Screen at every checkpoint: at onboarding, in real time on transactions, and on an ongoing or daily rescreening cadence against updated lists.
- ] Tune matching with secondary identifiers: use date of birth, country and known aliases, not name alone, to cut the 90%-plus false-positive noise.
- ] Document every alert disposition: record who reviewed each hit, the evidence, and the true-match or false-positive decision.
- ] Block and report true matches: freeze the asset or transaction and file the required reports, such as OFAC blocked-property reports, on time.
- ] Retain auditable records: keep an exportable, examiner-ready trail for the full retention period your jurisdiction requires.
- ] Audit the vendor's data architecture: ask whether they centrally store customer PII to screen it, and whether a decentralised or no-central-store design removes that breach honeypot.
The bottom line
Sanctions screening is a strict-liability obligation, not a best-effort one: OFAC can penalise you up to $377,700 per violation with no need to prove intent, and the Interactive Brokers settlement shows how a screening gap multiplied across transactions becomes an eight-figure number. List coverage, fuzzy matching and real-time checks are table stakes every credible vendor offers. The decision that actually separates programmes is architectural. Most vendors centralise your customers' identity data to screen it, building the exact breach honeypot that turned Sumsub and Persona into 2026 headlines. The better question is not whose match rate is highest, it is whether anyone needs to hold that data centrally at all. They do not.
Related resources
- AML transaction monitoring guide
- Why your KYC vendor is your biggest data breach risk
- Decentralised KYC: what it is and how it works
- Identity verification software comparison 2026
- Zyphe AML software
- Zyphe KYC software
Cited sources
- OFAC and Treasury inflation adjustment of civil monetary penalties, Federal Register, 15 January 2025 ($377,700 IEEPA cap)
- OFAC Economic Sanctions Enforcement Guidelines, 31 CFR Part 501 Appendix A (strict liability)
- OFAC FAQ #20 on SDN List update cadence (no predetermined timetable)
- OFAC enforcement actions, including the Interactive Brokers LLC settlement, July 2025 (voluntarily self-disclosed, non-egregious)
- OFAC Additional (non-SDN) Sanctions Lists: SSI, FSE, NS-PLC, CAPTA, NS-CMIC composition
- UN Security Council Consolidated List (binding on 193 member states)
- GOV.UK, moving to a single UK Sanctions List, 28 January 2026 (OFSI Consolidated List closed)
- EU Consolidated List of financial sanctions targets (EU open data)
- Peer-reviewed study on sanctions screening false-positive rates, PubMed Central
Michelangelo Frigo (Co-Founder at Zyphe) Michelangelo Frigo is a privacy and identity infrastructure expert and co-founder of Zyphe.