A compliance officer opens the morning queue and finds 140 alerts. Two of them involve a customer whose surname matches a listed person from a different country, born twenty years apart. One is a company whose ultimate owner does not appear on any list but whose two shareholders both do, at 30 percent each. The rest are noise from a fuzzy matching engine set too loose. Working out which of those needs a decision within the hour, and which can be cleared and documented, is what sanctions screening looks like in practice.
Most of the anti money laundering programme is risk based: a firm judges how much diligence a customer warrants. Sanctions are different. In the United States, civil liability for a breach attaches on a strict basis, meaning intent is not the test. The same posture runs through EU and UK regimes. A missed match is a breach even when nobody was careless in any obvious way.
The lists that matter, and why several apply at once
Firms often assume they only need the list of their own regulator. Payment rails decide otherwise. If a single leg of a transfer touches a US correspondent bank, US programmes are in play. If clients are EU resident, EU restrictive measures apply to servicing them.
| List | Published by | Why it reaches you |
|---|---|---|
| SDN and consolidated non SDN lists | OFAC, US Treasury | US dollar clearing, US persons, US owned entities |
| Consolidated financial sanctions list | European Union | EU clients, EU incorporated group entities, euro rails |
| UK sanctions list and the OFSI consolidated list | UK government and OFSI | UK clients, sterling settlement, UK service providers |
| Security Council consolidated list | United Nations | Implemented into almost every national regime |
Add the national lists of the licensing jurisdiction, plus any list your bank contractually requires. A licence application will normally ask which lists you screen and how often you refresh them, and the answer sits alongside the rest of the AML framework rather than in a separate silo.
Ownership and control beyond the name field
The trap that catches small firms is the ownership rule. Under OFAC guidance, an entity owned 50 percent or more, directly or indirectly, by one or more blocked persons is itself blocked even though its own name is nowhere on the SDN list. Two blocked owners at 25 percent each aggregate to 50. Nothing flags in a name screen, because there is no name to match.
The EU approach adds control as well as ownership, so an entity can fall in scope through voting arrangements or the power to appoint a majority of the board. For a corporate account this means the beneficial ownership questions collected during onboarding are the screening input, not paperwork filed after the fact. Screening a company name alone answers a question nobody asked.
Sanctions obligations bind the firm, not the vendor. A screening provider supplies data and a match engine. The decision to block, reject, freeze or report stays with the licensed entity and its nominated officer.
Why the false positive pile grows
Screening engines compare a customer record against millions of list entries and aliases. Because a listed person may appear as three transliterations of the same Arabic or Cyrillic name, the engine has to allow for variance, and variance produces matches on ordinary customers. Four causes account for most of a bloated queue:
Screening the name field alone, when date of birth, nationality and document number sit in the same record and would resolve most alerts instantly. A single global fuzzy threshold applied across Latin, Cyrillic and Arabic script names, which behave nothing alike under phonetic matching. Weak alias handling, so a shortened first name throws a fresh alert against a different list entry on every run. And no whitelist, so a customer cleared in March returns to the queue in April with no record of the decision attached.
Tuning is legitimate and expected. What matters is that changes are tested against known true matches before release, and the test is documented. A threshold loosened quietly to reduce workload, with no record, is the finding an examiner writes up.
Screening is a schedule, not an event
Three moments need coverage. Onboarding, where the check runs before the account is funded and sits next to identity verification. Ongoing, where the whole customer book is rescreened whenever a list changes, because designations are added on the regulator's timetable and a client who was clean in January may be designated in June. And payments, where beneficiary names, banks and counterparties on deposits and withdrawals are screened separately from the account holder.
Ongoing rescreening is the step firms skip. It is also the one that produces the true matches, since a person who is already listed rarely applies openly under their own name. Automating the list refresh so a designation update triggers a full book rescreen within a day is straightforward engineering, and the record of when each refresh ran belongs in the same audit trail as the rest of your client and compliance records.
When a match is real
Two separate obligations follow a confirmed hit, and they are not interchangeable. The asset action comes first: depending on the programme and the jurisdiction, funds are either blocked and held, or the transaction is rejected outright. Getting that wrong in either direction is itself a breach, so the decision tree needs to be written down before the day it is needed rather than improvised.
The reporting obligation runs in parallel to the relevant authority, on the deadline set by that regime, and it is separate from any suspicious activity report filed under the money laundering rules. Tipping off restrictions usually apply, so the customer facing message says the account is under review and nothing more. Every step, including the timestamps of the decision and who took it, goes into a record you can produce years later, because sanctions files get inspected long after the account is closed. Vendor selection helps here too: the verification providers that publish their list coverage and refresh frequency are easier to defend than the ones that do not.
"Nobody gets credit for a clean queue. You get credit for a queue where every cleared alert has a name, a reason and a date attached to it."
— Roman Onta, Executive Director, SINGUARD
Key Takeaways
- Sanctions liability does not depend on intent, so a missed match is a breach even without negligence.
- Your payment rails and client base decide which lists apply, not your licence jurisdiction alone.
- Ownership rules block entities whose names never appear on any list, so beneficial ownership data is the input.
- Rescreen the entire book on every list update and keep a dated record of each cleared alert.
Frequently Asked Questions
Which sanctions lists should a trading firm screen against?
At minimum the UN Security Council consolidated list, the lists of every jurisdiction the firm is licensed in, and the lists that govern its banking and payment partners. For most firms with US dollar settlement or EU clients that means OFAC, the EU consolidated list and the UK list are all in scope regardless of where the firm itself is incorporated.
What is the OFAC 50 percent rule?
An entity that is owned 50 percent or more, directly or indirectly, by one or more blocked persons is itself treated as blocked even though its name never appears on the SDN list. Aggregation across several blocked owners counts, which is why ownership and control questions belong in onboarding rather than in a later review.
How do you reduce false positives without weakening screening?
Screen richer data than the name alone, including date of birth, nationality and document number, tune fuzzy match thresholds per name script rather than globally, and keep a reviewed whitelist of cleared customers so the same alert does not return every week. Threshold changes should be tested against known true matches and documented before they go live.