Sanctions Screening: How It Works and Why It's So Noisy

What Sanctions Screening Means in Practice

Sanctions screening is the automated process of checking a customer, counterparty, or transaction party's name against government-maintained lists of individuals, entities, and countries subject to financial restrictions. If a name matches, or comes close enough to matching, the transaction or relationship gets held until a compliance analyst clears it or blocks it.

The lists themselves come from multiple regulators, and a bank has to screen against all of them at once. The US Treasury's Office of Foreign Assets Control maintains the SDN List, the most-cited list in the industry. The EU maintains its own consolidated list, the UN Security Council maintains sanctions committees for specific conflicts, and the UK's OFSI runs a parallel regime post-Brexit. A bank operating internationally screens against all of them, and the lists don't update on the same schedule.

Screening happens at three points in the customer lifecycle. At onboarding, before an account opens. On an ongoing basis, because lists change daily and a customer who was clean last year might not be today. And at the transaction level, in real time, before a wire or payment settles. Real time sanctions screening on payments is the hardest version of this problem: you have seconds, not hours, to clear a name before the payment either processes or gets held.

Sanctions screening doesn't run alone. Most programs pair it with PEP screening, which flags politically exposed persons, government officials, their family members, and close associates who carry elevated corruption risk even when they're not on any sanctions list. The two controls share infrastructure (the same matching engine usually runs both) but serve different purposes, and an examiner will test them separately.

Ownership sits with the compliance function, typically under the MLRO or Chief Compliance Officer, but the day-to-day work spans teams. Compliance owns policy and thresholds. Operations often runs the payment-screening queue. Financial crime investigators handle escalated alerts. Technology owns the screening engine and list feeds. When these teams don't coordinate, list updates lag and alert backlogs build, which is exactly what examiners look for first.

Why It Matters Now

Sanctions enforcement isn't theoretical. In 2019, Standard Chartered agreed to pay $1.1 billion to US and UK authorities for processing transactions tied to sanctioned Iranian and other parties, one of the largest sanctions-related settlements ever recorded. Danske Bank's Estonian branch became the center of a separate case involving roughly $200 billion in suspicious flows, much of it never properly screened against risk indicators before it moved through the correspondent banking system.

Geopolitical volatility is the other driver. Russia-related sanctions expanded dramatically after February 2022, with the EU, US, and UK adding thousands of new entries within months. FATF tracks jurisdiction-level compliance gaps and updates its grey list twice a year, and banks with exposure to flagged jurisdictions face heightened scrutiny regardless of their own screening quality.

FinCEN has issued repeated advisories reminding institutions that sanctions evasion techniques, shell companies, trade-based layering, and cryptocurrency mixing, keep evolving faster than static list-matching can keep up with. That's the tension at the center of every sanctions program: the lists are static snapshots, and the evasion techniques are not.

Examiners have also gotten more specific about what "reasonable" screening looks like. A decade ago, running any screening engine against the SDN List satisfied most reviews. Now examiners test match logic, list update cadence, alert disposition quality, and whether the bank can produce evidence for a sample of cleared alerts on demand. A program built in 2015 and never revisited is a program with a finding waiting to happen.

How Sanctions Screening Works

The mechanics break into four stages: data collection, list ingestion, matching, and disposition.

Data collection pulls the name, date of birth, nationality, address, and any identifiers (passport, tax ID) available for the customer or transaction party. Payment screening has less data to work with, often just a name and a country, which is part of why it produces more false positives than onboarding screening.

List ingestion pulls the current version of every applicable sanctions list. OFAC updates the SDN List multiple times a month, sometimes multiple times a week during active geopolitical events. A screening engine running on a list that's even a few days stale can miss a fresh designation entirely, which is one of the most common findings in regulatory exams.

Matching is where the real engineering happens. The table below compares the three approaches banks use, usually layered together rather than picking just one.

This is also where aml sanctions screening work overlaps with broader AML transaction monitoring. A sanctions hit on a payment and a suspicious pattern flagged by transaction monitoring often point analysts toward the same underlying case, and mature programs route both into a single investigation rather than two disconnected queues.

Disposition is the human step. An analyst reviews the alert, decides true match or false positive, and documents the reasoning. True matches get escalated, usually blocked immediately and reported to the relevant regulator (OFAC in the US requires blocking and reporting within 10 business days for a true SDN match). False positives get cleared and, ideally, feed back into tuning the match logic so the same non-match doesn't fire again.

PEP screening runs through the same pipeline but against a different reference set: government position databases and adverse media, rather than restriction lists. A name can clear sanctions screening entirely and still need a closer look under PEP criteria before an account opens, particularly for what is a pep categories like family members and close associates, which most banks under-screen relative to the primary official.

Where Programs Fail

The failure modes examiners find are remarkably consistent across institutions, and almost none of them are exotic.

Stale list versions. A screening engine pointed at a list feed that updates weekly, or gets manually refreshed, will miss designations that took effect days or weeks earlier. This is the single most common citation in sanctions-related consent orders.

Threshold miscalibration. Set the fuzzy-match sensitivity too loose and analysts drown in false positives, which leads to alert fatigue and rushed dispositions. Set it too tight and real matches slip through. Most banks tune this once at implementation and never revisit it as their customer base changes.

No transliteration handling. Arabic, Cyrillic, and Chinese names romanize multiple ways. A screening engine that only handles one romanization convention will systematically miss matches for entire regions, a gap that's invisible until an examiner tests it directly.

Payment screening gaps. Real time sanctions screening on wires often runs on a stripped-down data set (name and country only) compared to the richer profile available at onboarding. Programs that don't account for this mismatch end up either blocking too many legitimate payments or missing matches that onboarding screening would have caught.

Thin investigation notes. An analyst who writes "cleared, not a match" with no supporting reasoning gives an examiner nothing to test. Regulators expect to see what data points were compared and why the analyst reached their conclusion, on a sample basis, for every cleared alert.

No feedback loop. False positives that never get analyzed for pattern (the same common name triggering weekly, for instance) mean the program never gets more accurate. It just gets more alerts, year over year, with no corresponding improvement in signal quality.

What Good Looks Like

A sanctions screening program that would hold up under examination has a few consistent traits, regardless of the vendor or technology underneath it.

List currency is automated and logged. List updates pull on a defined schedule (daily at minimum, near-real-time for high-risk feeds like OFAC), and there's a record of when each version was ingested and by what process.

Thresholds are documented and reviewed. Match sensitivity settings have a written rationale, get revisited on a set cadence (quarterly is common), and any change is logged with the reason behind it.

Metrics go beyond a count of cleared alerts.** A mature program measures match rate, false positive rate, average time to disposition, and the ratio of alerts that convert into a true match or feed a SAR. Alert-to-disposition time under 24 hours for standard alerts is a reasonable working benchmark; escalated true matches need same-day action given OFAC's 10-business-day blocking and reporting window.

Evidence is retained for every disposition, including dispositions that turn out to be false matches. Regulators sample cleared alerts, and a program that can't reconstruct why an alert was cleared eighteen months ago has a documentation problem even if the underlying decision was correct.

Governance connects the dots. Sanctions screening doesn't sit in isolation. It should tie into the bank's broader regulatory compliance automation program, feed the same case management system as KYC and onboarding checks, and appear as a named control in the bank's BSA/AML compliance program documentation, not as a standalone tool nobody outside compliance can explain.

None of this requires exotic technology. It requires current data, documented thresholds, and analysts who write down their reasoning. The programs that fail exams usually aren't missing a capability, they're missing the discipline to run the capability they already have consistently.

6. How AI and Automation Change Sanctions Screening

AI doesn't replace the sanctions program. It changes which parts need a human and which don't.

Fuzzy name matching is the clearest win. Traditional screening lists use edit-distance algorithms (Levenshtein, Jaro-Winkler) that catch typos but miss transliteration variants, honorifics, and name-order swaps common in Arabic, Russian, and Chinese names. Machine learning models trained on transliteration patterns catch more of these variants without a proportional increase in false positives. OFAC's own guidance on sanctions compliance notes that screening quality depends heavily on how well a program handles name variation, in addition to how current its lists are.

Alert triage is the second big win. A bank running 40,000 alerts a month can't have analysts read every one from scratch. Machine learning models that learn from an institution's own disposition history (which alerts got cleared, which escalated, and why) can rank alerts by likelihood of being a true match. That's a real reduction in analyst hours. It is not a reduction in accountability: someone still signs off on every disposition.

What can't be automated, at least not yet:

• The initial risk-based decision to screen at all. Which products, which customer segments, which transaction types get real-time versus batch screening is a policy call, not a data problem.
• List interpretation when a designation is ambiguous. Secondary sanctions questions (is this entity 50% or more owned by a blocked person under the 50 Percent Rule?) require legal judgment OFAC's own FAQs say depends on ownership structure the software can't always see.
• The final decision on a true match. Whether to block, reject, or file a blocked-property report under 31 CFR 501.603 is a compliance officer's call. No vendor contract transfers that liability.
• Explaining a decision to an examiner. If your model flags then clears an alert, you need to say why in plain language. A black-box score isn't an explanation.

The honest tradeoff: automation adds model risk. A screening model trained on last year's disposition patterns can inherit last year's blind spots. The Federal Reserve's guidance on model risk management (SR 11-7) applies to sanctions screening models the same way it applies to credit models. If you deploy a model, you now have to validate it, document it, and monitor it for drift. That's real work, and it's worth it, but it's not free.

7. How to Evaluate a Solution

Buyers tend to ask about match rates first. Wrong question. A vendor demo tuned on clean sample data will always look great. Ask about the false positive rate on your actual customer base, with your actual name formats, and ask for a reference customer of similar size and geography.

Here's a checklist that holds up in due diligence:

Ask for the vendor's own model validation documentation before you sign anything. If they don't have one, that's the answer.

8. Regulatory and Standards References

Sanctions screening obligations come from a small number of primary sources, not vendor marketing pages. The ones that matter:

• OFAC Sanctions Programs and Country Information (treasury.gov/ofac): the master list of active US sanctions programs and the SDN List itself.
• OFAC's Framework for Compliance Commitments (treasury.gov, 2019): the five pillars OFAC expects in a sanctions compliance program, and the closest thing to a supervisory checklist OFAC has published.
• 31 CFR Chapter V: the Code of Federal Regulations sections that implement each OFAC sanctions program, including the blocked-property reporting duty at 31 CFR 501.603.
• FATF Recommendation 6: the international standard requiring countries to implement targeted financial sanctions related to terrorism and proliferation financing, published by the Financial Action Task Force.
• FinCEN's BSA/AML guidance: sanctions screening sits alongside, and often shares infrastructure with, the broader BSA/AML program FinCEN oversees (fincen.gov).
• The EU's Consolidated Financial Sanctions List and UK OFSI's Consolidated List: required reading for any institution with EU or UK exposure, since designations and dates don't always match the US list.
• Federal Reserve SR 11-7: model risk management guidance that applies to any institution using a statistical or machine learning model in its screening program.

If your institution operates across borders, don't assume one list covers you. The US, EU, and UK sanctions regimes overlap heavily but diverge on specific designations and effective dates, and an entity delisted in one jurisdiction can still be blocked in another.

9. Next Steps

This guide covers the program level: what sanctions screening means, why programs fail, and what good looks like. The spoke articles linked above go deeper on specific failure modes, alert tuning, and jurisdiction-specific list handling. Start with whichever one matches the gap you found in Section 4.