A payments firm we spoke with last year had everything a vendor checklist would tell you to buy. World-Check feed, OFAC integration, a screening engine with a reputable logo. And yet a junior analyst spent the better part of a Tuesday morning manually clearing 340 alerts on a single batch of new customers, almost all of them matches on common surnames. Buried in that pile was a genuine hit against an EU consolidated list entry that had been updated eleven days earlier. Their feed was on a weekly refresh. By the time anyone looked properly, the account had already moved money.
That is the real shape of sanctions screening. Not a question of which provider has the most names. A question of whether your programme can keep its lists current, separate the genuine matches from the noise, and prove to a regulator that every decision was made for a reason.
Coverage is table stakes. The lists are the same lists
Let us deal with the vendor headcount myth first. The major sanctions lists are public. The US Office of Foreign Assets Control (OFAC) publishes the Specially Designated Nationals and Blocked Persons (SDN) List. The United Nations maintains its Consolidated List. The UK's Office of Financial Sanctions Implementation (OFSI), part of HM Treasury (HMT), publishes the UK Sanctions List. The European Union maintains the EU Consolidated List of persons, groups, and entities subject to financial sanctions. Commercial aggregators such as World-Check and Dow Jones layer on adverse media and politically exposed person (PEP) data, but the core sanctions content traces back to the same official sources every regulated firm can access.
So when a vendor sells you on the size of its database, it is mostly selling you something you can already get. What actually separates a working screening programme from a failing one is three things the database alone never solves: how fast updates reach your engine, how well you handle false positives, and whether you can explain a decision after the fact.
Stale lists are the failure mode nobody budgets for
Direct answer: real-time list coverage means your screening engine reflects a sanctions designation within hours of publication, not days or weeks. The gap between the two is where exposure lives.
Sanctions lists are not static reference data. OFSI, OFAC, and the EU can add or amend designations at any time, often in response to fast-moving geopolitical events. The Financial Action Task Force (FATF) Recommendation 6 requires countries to implement targeted financial sanctions "without delay", and that obligation flows down to the firms doing the screening. A list that refreshes weekly leaves a window in which you are transacting against names that are already designated and you simply do not know it yet.
This is an integration problem, not a data problem. The question to ask any provider is not how many names they hold. It is how quickly a new OFSI designation published this morning appears in your match results this afternoon, and whether your existing customer base gets rescreened against it automatically or only at the next periodic review.
False positives are where the cost actually sits
Here is the uncomfortable arithmetic of screening. The work is not in the genuine hits. It is in everything that looks like a hit and is not. Common names, transliteration variants, partial matches, two different people who happen to share a date of birth. An analyst clears each one by hand, and at scale that becomes the single largest line item in a screening operation.
The instinct is to tighten the matching to reduce the volume. That is exactly the wrong move if you do it blindly, because a threshold tuned only for fewer alerts is a threshold tuned to miss real matches. The discipline is configurable match thresholds you can set per list, per risk appetite, and per jurisdiction, then defend. A higher fuzzy-match tolerance on a sanctions list where the consequence of a miss is severe. A tighter setting on adverse media where the volume is enormous and the regulatory weight is lower. The point is that the threshold is a deliberate, documented choice, not a vendor default nobody has looked at since go-live.
A Head of Financial Crime at a European fintech put it to us plainly: "We were not drowning because we had too many names on the list. We were drowning because every borderline match looked identical to the analyst, and nobody had agreed in advance what borderline even meant."
This is exactly the workflow gap Zenoo's Compliance Hub was built to close. If your analysts are clearing the same noise every day with no agreed rules behind the thresholds, it is worth seeing how configurable matching changes the maths. Book a demo to run it with your own screening data.
Explainability is what the regulator actually asks for
When a supervisor reviews a sanctions programme, they rarely ask how many names you hold. They ask why you cleared a particular alert. They ask what the match score was, which list it came from, which attributes matched, who reviewed it, and what they decided. If your answer is "the system passed it", you have a problem.
The FCA expects firms to demonstrate that their screening is effective and that decisions can be evidenced. OFSI guidance is explicit that firms must be able to show the steps they took. That means explainable match reasoning, the system telling the analyst precisely why two records were flagged as a possible match, and a full audit trail capturing every screening event, every threshold in force at the time, every disposition, and every reviewer. Not as an export you assemble in a panic before an inspection, but as a record that exists by default for every decision.
Multi-jurisdiction coverage matters here too. A firm onboarding customers across the UK, the EU, and the US is screening against OFAC, OFSI, the EU Consolidated List, and the UN list simultaneously, often with different obligations attached to each. Audit-ready means you can show, jurisdiction by jurisdiction, which lists applied to which customer and why.
What good looks like
A screening programme that holds up under scrutiny tends to share the same characteristics, whatever the vendor logos involved.
| Operational area | Failing programme | Working programme |
|---|---|---|
| List currency | Weekly or manual refresh | Updates reach the engine within hours, existing base rescreened automatically |
| Match thresholds | Vendor defaults, never reviewed | Configurable per list and jurisdiction, documented and owned |
| False positives | Cleared by hand with no rules | Triaged against agreed criteria, noise reduced without raising miss risk |
| Explainability | "The system passed it" | Match reasoning shown for every alert |
| Audit trail | Assembled before an inspection | Captured by default for every screening event |
| Workflow | Screening sits outside onboarding | Screening runs inside the onboarding flow, not as a separate step |
The last row matters more than it looks. Screening that lives in a separate tool, disconnected from the onboarding decision, is screening that gets skipped under pressure or run too late. When screening is part of the onboarding workflow itself, the result reaches the case file before the account opens, not eleven days after.
How the decision flow should branch
The core of a working programme is what happens when a name produces a match score. That is a decision tree, not a straight line.
Notice the loop. Screening is not a one-time gate at onboarding. Every designation change feeds the existing customer base back through the same logic, which is why automatic rescreening against new list updates is not a nice-to-have. It is the difference between catching a newly designated party and finding out from your regulator that you did not.
Practical guidance for a screening review
If you are evaluating or rebuilding a screening programme, the questions worth asking are operational, not promotional. How quickly does a new OFSI or OFAC designation reach live match results, and does your existing book get rescreened automatically when it does? Who owns the match thresholds, when were they last reviewed, and can you produce the rationale for each setting? For a cleared alert from last quarter, can you show the match score, the list, the matched attributes, the reviewer, and the decision in under a minute? And does screening run inside onboarding, or does an analyst have to remember to go and do it?
If those answers are uncomfortable, the gap is rarely the size of anyone's database. It is the operations around it.
Frequently asked questions
What is sanctions screening?
Sanctions screening is the process of checking customers, counterparties, and transactions against official lists of sanctioned individuals, entities, and jurisdictions, such as the OFAC SDN List, the UK Sanctions List maintained by OFSI, the EU Consolidated List, and the UN Consolidated List, to prevent regulated firms from doing business with designated parties.
How often should sanctions lists be updated?
As close to real time as the operation allows. Designations can be published at any time, and FATF Recommendation 6 requires targeted financial sanctions to be implemented without delay. A weekly or manual refresh leaves a window in which you may be transacting against a name that is already designated. The practical standard is that updates reach your screening engine within hours and your existing customer base is rescreened automatically against them.
Why are there so many false positives in sanctions screening?
Because matching has to be fuzzy enough to catch name variants, transliterations, and partial matches, it inevitably flags people who are not the sanctioned party, common surnames and shared dates of birth being the usual culprits. The answer is not blunt threshold tightening, which raises the risk of missing a real hit, but configurable thresholds set per list and per jurisdiction with a documented rationale, paired with explainable match reasoning so analysts can clear noise quickly and defensibly.
What does an auditor look for in a sanctions screening programme?
Evidence that decisions were made for a reason. That means a full audit trail of every screening event, the match thresholds in force at the time, the match reasoning behind each alert, the analyst disposition, and the reviewer, all captured by default rather than assembled before an inspection. Multi-jurisdiction firms should also be able to show which lists applied to which customer.
Does a bigger sanctions database mean better screening?
No. The core sanctions content comes from public official sources every firm can access. What separates a working programme from a failing one is list currency, false positive management, and audit-ready explainability, all of which are operational disciplines rather than database size.
Key takeaways
- The core sanctions lists (OFAC SDN, UK Sanctions List, EU Consolidated List, UN Consolidated List) are public, so vendor database size rarely decides whether a programme works.
- Real-time list coverage matters because a stale feed leaves a window in which you transact against names that are already designated. FATF Recommendation 6 requires sanctions to be implemented without delay.
- False positives are the largest cost in screening, and the fix is configurable, documented match thresholds rather than blunt tightening that raises miss risk.
- Explainable match reasoning and a full audit trail, captured by default, are what a regulator actually inspects.
- Screening belongs inside the onboarding workflow, with automatic rescreening of the existing book against every list update.
If you are stitching screening together across multiple feeds and clearing the same noise every day, it is worth seeing how Zenoo's Compliance Hub handles configurable thresholds, explainable matching, and audit trails in one place. Visit zenoo.com to book a demo. 30 minutes. Your data. No slides.
