One Transaction, Eight Sanctions Lists, Zero Margin for Error

OFAC updated the SDN list three times last week. No advance notice. No set schedule. If your screening engine pulls the list on a nightly batch, Monday's payments ran against Friday's data.

In 2024, OFAC added 3,135 new entries to the SDN list, a 25% increase over 2023.¹ The legal standard is strict liability. There is no "we did not know yet" defense.

Now multiply that by the EU's 40-plus sanctions regimes,² the UN consolidated list, UK OFSI, and the 43 active U.S. sanctions programs OFAC administers.³ You are not screening against one list. You are screening against a constantly shifting network of overlapping designations, each maintained by a different authority, on a different schedule, in a different format.

The list count is not the problem. The update velocity is.

Most teams focus on coverage. "Do we screen against OFAC, UN, EU, and UK?" Yes. But coverage is the easy part.

The hard part is keeping every list current. OpenSanctions tracks 86 distinct sanctions lists globally, covering over 70,000 designated targets across nearly 290,000 total entities including aliases, vessels, and crypto wallets.⁴ These lists update independently. OFAC publishes on no set timetable, sometimes several times in a single week.⁵ The EU adds new packages as geopolitics shift. The UN consolidated list updates whenever a committee acts.

FATF expects sanctions action "without delay," ideally within hours of a new designation.⁶ If your lists are stale by 24 hours, you have a compliance gap that examiners will find.

What a unified screening engine actually does

The core idea is simple. Instead of running separate checks against each list, you normalize everything into one system and screen once.

Here is how it works:

1. Normalize every list into a common entity model. OFAC publishes XML. Other lists use CSV, JSON, or PDF. Different schemas, different fields. You map them all into one standardized format so the matching engine sees consistent data regardless of source.

2. Deduplicate across lists. The same sanctioned entity often appears on OFAC, UN, and EU lists simultaneously. Without deduplication, one entity generates three separate alerts. Your analyst clears the same person three times.

3. Apply list-specific matching logic. OFAC SDN requires precision because of strict liability. PEP databases require broader recall because you are casting a wider net. One matching threshold does not fit all lists. The model learns which signals matter most for each source.

4. Ingest updates in real time. Pull from authoritative feeds as they publish. No batch windows, no manual downloads, no stale data gaps.

5. Consolidate alerts and route decisions. Single alert per entity regardless of how many lists carry it, with full list provenance attached. Your analyst sees one case with all the context, not five fragments.

For a deeper look at how the matching layer works, see how entity resolution replaces fuzzy string matching, and how AI cuts false positives without lowering sensitivity.

Where payments teams get this wrong

Running separate screening passes per list. You build one integration for OFAC, another for EU, another for UN. Each has its own matching logic, its own threshold, its own alert queue. When one integration fails silently, you lose coverage on that list and nobody notices until an examiner asks.

Applying the same fuzzy matching threshold to every list. OFAC SDN and a PEP database have fundamentally different precision and recall requirements. A single threshold either over-flags on one or under-catches on another. You end up tuning for the loudest list and accepting noise or gaps on the rest.

Batch-mode list ingestion. OFAC updates on no set timetable, sometimes several times in a single week.⁵ A 24-hour batch cycle creates a window where your screening runs against yesterday's data. FATF expects action "without delay."⁶ Batch mode creates the exact gap examiners look for.

What this costs when it breaks

OFAC issued 12 enforcement actions in 2024 totaling $48.8M.⁷ That averages $4.1M per action. The companies that paid those penalties were not ignoring compliance. Most had screening programs. The gap was coverage, recency, and documentation.

On the operational side, if your team screens across five list integrations and each produces overlapping alerts on the same entity, your analyst reviews the same person three to five times per transaction. That multiplier on alert volume is the real cost. Fragmented screening compounds the problem far beyond what any single-list false positive rate would suggest.

Why building this in-house stalls

You could build multi-list aggregation. The concept is not the barrier. The hard part is keeping it running.

Consolidated-list vendors solve format normalization, but they still apply uniform matching logic and batch ingestion windows that leave the core problems intact. Building it yourself means list formats that are inconsistent and change without warning, unpredictable update frequencies, deduplication across different entity schemas that requires ongoing curation, and every new sanctions package from any jurisdiction adding another integration to maintain.

As we covered in sanctions screening 2.0, the hard part is not the model. It is the system behind it: the data pipelines, the monitoring, the retraining, the audit trails that hold up under regulatory scrutiny.

What to do in the next 30 days

Week 1: Audit your list coverage. Document every sanctions list your engine currently queries, the update frequency of each, and how your engine ingests updates (API, batch download, vendor feed). If you cannot produce this document in one day, that is your first gap.

Week 2: Map your update lag. For your three highest-risk corridors, measure the average time between a list update and when that update is reflected in live screening decisions. Document the exposure window. This is what you would explain to OFAC if a payment went through during that gap.

Week 3: Identify cross-list duplicate alerts. Pull last month's alert log. Flag every case where the same entity name appeared across multiple list matches on the same transaction. Count how many analyst hours went to clearing the same entity repeatedly.

Week 4: Build the business case. One-page memo with three numbers: (1) your current update lag on each list, (2) analyst hours consumed by cross-list duplicate alerts last month, (3) what a single OFAC enforcement action would cost relative to your compliance budget. This is your prioritization document for the next investment decision.

How Devbrew builds this

We build unified sanctions screening systems that normalize every watchlist into a common entity model, apply list-specific matching tuned for each source, and ingest updates in real time. Custom AI trained on your transaction data, your corridors, and your entity mix, not generic thresholds from a vendor platform. Cross-list deduplication means your analysts review each entity once, not once per list. You can see this architecture in practice in Sentinel. Your existing screening platform stays in place.

Walk through your current list coverage

If you are not certain your screening engine covers all relevant lists in real time, or your team clears the same entities repeatedly because lists overlap, that is worth solving before your next exam. Book a discovery call to understand where the gaps are and what the options look like, or reach out at joe@devbrew.ai.