Sanctions Screening and Watchlist Filtering: Tuning False Positives Without Missing a Real Name

Why screening is an operations problem with a legal edge

It is 15:20 and the wire room has forty three open hits. Fedwire has a cutoff. Each hit is a payment where a name, an address fragment or an intermediary institution scored above the threshold against a sanctions or watchlist entry. Most are the same handful of common surnames that generate hits every single day. Two are genuinely ambiguous. One analyst is working the queue in list order, oldest first, because the queue has no concept of which payment is about to miss its window or which hit has never been seen before.

Both failure modes in this domain are expensive and they pull in opposite directions. Let a real match through and you have a potential violation where liability can attach regardless of intent, plus the correspondent banking consequences that follow a public enforcement action. Over block and you delay legitimate commercial payments, your corporate clients notice, and your treasury sales team spends its week apologising. Tuning is the act of choosing where to sit between those, and the regulator's expectation is not that you get it perfect. It is that you can explain the choice.

Most institutions cannot. The threshold is a number in a vendor console, the reason it is that number is institutional memory, and the evidence that it works is the absence of a problem so far.

Problem one: the match logic has to fit your customer base, not a generic one

Name matching quality depends on the population you are matching. A bank with a large Arabic speaking customer base faces transliteration variance that a bank with a mostly Anglophone book never encounters. A payments company running corridors into South Asia sees patronymic patterns and name ordering that break assumptions built into default algorithms. A trade finance operation screens vessel names, ports and goods descriptions, which behave nothing like personal names.

LSEG World-Check and Dow Jones Risk and Compliance are data providers, and good ones, and it is worth being precise about that: they supply the lists and the enrichment, not the matching engine or your workflow. LexisNexis Bridger Insight is a capable mid market screening tool that gets an institution compliant quickly, with limited visibility into why a particular score was produced, which becomes the constraint when you are trying to tune. Fircosoft is the incumbent inline filter in large payment shops, proven at volume, and tuning it is specialist work that iterates slowly. Napier offers more configurable modern architecture and is still a platform you configure to your population.

What a custom build does: expose the pipeline. Normalisation, transliteration handling, tokenisation, the scoring function, and the threshold are separate, inspectable stages with parameters you can version. When your sanctions officer asks why a name scored 87, someone can answer with the stage by stage detail rather than an appeal to the vendor.

Problem two: a hit queue sorted by arrival time is a design defect

The operational reality is that payment screening is a race against cutoffs and customer screening is a race against onboarding SLAs. A queue that does not know either of those is going to lose one.

What a custom build does: order the queue by time remaining against the relevant deadline and by novelty. Hits identical to a hit you cleared last week on the same customer against the same list entry should present as a one click confirmation with the prior decision and its rationale attached, not as a fresh investigation. Hits that are genuinely new go to the top. That distinction alone typically removes the majority of the queue's clock time, and it depends on something most tools do not do well: keying a decision to the specific triple of subject, list entry and reason, so that recurrence is recognisable.

Structured dispositions matter as much here as in monitoring. A hit closed with a selected reason, referencing the identifier that differentiated the customer from the listed party, is evidence. A hit closed with the free text note cleared is not.

Problem three: good guy lists are a control, and they are usually a spreadsheet

Every screening operation builds a whitelist of subjects previously determined not to be matches. It is necessary. It is also the most dangerous artefact in the department, because a subject placed on it stops generating hits, and lists change.

What a custom build does: treat every whitelist entry as a governed object with an owner, an expiry, the evidence that supported it and the specific list entry it applies to. Never whitelist a name globally. Whitelist a customer against a named list entry, so that if a new list entry appears with a similar name the hit still fires. Then re screen the entire whitelist against every list update, and force review of any entry where the underlying list record changed. Sanctions authorities amend entries with new aliases and identifiers regularly, and an amendment to an entry you previously cleared is exactly the event your process needs to catch.

Problem four: list updates are events, not a refresh job

When OFAC amends the SDN list, or the EU consolidated list changes, or a national list adds names, the correct behaviour is not simply to load the new file. It is to compute the delta, re screen your existing customer base against the added and amended entries, and treat the results as a prioritised batch, while keeping a record of exactly which list version was in force when any payment was screened.

That last point is what an examination will test. If a payment was released on a Tuesday, you need to show which list version was loaded at that moment and what the matching parameters were. Keep list versions immutable and stamp each screening event with the version and parameter set that produced it. It costs almost nothing to build in at the start and is close to impossible to retrofit.

Problem five: the ownership rule is not a name matching problem

Sanctions exposure extends beyond the names on a list. The OFAC 50 percent rule means an entity owned in aggregate by blocked persons is itself blocked even where it appears nowhere on the list. No fuzzy matcher will find that, because the entity name is not there to match.

What a custom build does: join screening to the ownership data you already collect in onboarding. When you hold an ownership graph for a corporate client, evaluate every node against the lists and compute aggregate blocked ownership through the chain. This is the clearest example of why a screening tool bolted on the side of your onboarding platform underperforms a system that shares one data model with it.

What it costs and how long it takes

A first release, meaning list ingestion with versioning and delta computation, a configurable and inspectable matching pipeline, and an operations hit queue with structured dispositions and recurrence handling, runs $80,000 to $190,000 and ships in 12 to 18 weeks. A full platform adding inline screening in the payment path, historical replay for threshold testing, governed good guy lists, ownership rule evaluation and blocked property record keeping runs $240,000 to $550,000 across 8 to 16 months.

What pushes cost up specifically here: inline payment screening, because a filter sitting in a payment path has latency and availability requirements that a batch job does not, and failure behaviour has to be designed rather than defaulted. The number of lists, including internal and correspondent supplied lists. Non Latin script handling, which is genuine specialist work. Trade finance screening of vessels, ports and dual use goods, which is a different matching problem in the same building. And historical re screening, since replaying two years of payments through a candidate parameter set requires that data to be stored in a queryable form from the beginning.

Build versus buy for sanctions screening

Buy if you are a smaller institution screening modest volumes in batch, with a customer base that does not stress transliteration. Bridger Insight or a comparable product plus disciplined process is proportionate, and building a matching engine would be effort spent where your risk is not.

Build, or build the layer around a bought filter, when two or more of these are true. Screening sits inline in a payment path with a cutoff and the queue is the bottleneck. Your customer base or corridors create matching behaviour that default algorithms handle badly. You cannot currently evidence why your thresholds are set where they are. Your good guy list has grown past a few hundred entries and nobody governs it. Or you already hold ownership graphs from onboarding and want the 50 percent rule evaluated properly rather than by hand.

How to choose a developer for screening work

Ask them how they would prove a threshold change is safe before it goes live. The answer must involve replaying historical screening events through the candidate parameters and comparing the hits produced, including the ones that would no longer fire. Anything else is an opinion with a deployment date.

Ask how they will handle a repeat hit on the same customer against the same list entry. If the design does not key decisions to that triple, your analysts will re investigate the same three names every week forever.

Ask what happens when a list entry is amended rather than added. Teams who have built screening answer immediately, because it is the case that separates a real system from a nightly file load.

Ask who owns the code, the matching parameters, the disposition history and the cloud accounts, and get it in the contract before kickoff. Your tuning record and your disposition history are the evidence that defends the programme. At Digital Heroes they belong to the client from the first commit, and we would tell you to refuse any arrangement where your screening evidence lives somewhere you cannot extract it from.