Sanctions Screening Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the matching engine get scoped and the queue get skipped?

Because matching is the part that sounds like software. Transliteration, tokenisation, phonetic scoring and thresholds are concrete, demonstrable and fun to build. The queue is described as a screen, so it gets two weeks at the end of the project.

That inversion is backwards for almost every institution. Your screening risk is rarely that a name scored 82 instead of 87. It is that an analyst under deadline pressure cleared something quickly, or that a real hit sat behind thirty repeats of a name your team has dispositioned every week for two years.

The specific miss is recurrence. A hit that is identical to one you cleared last week, on the same customer against the same list entry for the same reason, should present as a one click confirmation with the prior decision and its rationale attached. It should not present as a fresh investigation. Doing that well depends on something most implementations get wrong at the data model level: keying a decision to the triple of subject, list entry and match reason, so recurrence is recognisable at all. Retrofitting that key after launch means every historical disposition is unusable for the purpose.

Scope the queue first. Order by time remaining against the relevant cutoff or onboarding service level, then by novelty. That alone typically removes the majority of the queue's clock time without touching coverage.

What goes wrong when you migrate lists, whitelists and disposition history?

The whitelist is the dangerous one. Every screening operation accumulates a list of subjects previously determined not to be matches, and in most institutions it is a spreadsheet with names in it. Migrating it as it stands imports a control you cannot defend, because a name whitelisted globally stops generating hits against list entries that did not exist when the decision was made.

Do not migrate it in that form. Convert each entry into a governed object: a specific customer against a specific list entry, with an owner, an expiry date and the evidence that supported the decision. Where that evidence cannot be reconstructed, the honest answer is to expire the entry and let it re screen, which will hurt for a fortnight and is far better than carrying an undocumented exemption into a new system that your examiner will now expect to be rigorous.

Disposition history has the same problem in a milder form. Records closed with a free text note saying cleared are not evidence and cannot be used to recognise recurrence. Migrate them for continuity, mark them as unstructured, and set a cutover date after which every disposition carries a selected reason and the identifier that differentiated your customer from the listed party.

List data itself should be reloaded from source rather than migrated, and loaded as immutable versions from the first day.

Why do payment path and onboarding integrations break after launch?

Inline screening breaks because it was built as a service call and not as a component of a payment path. A filter that sits between a payment being instructed and released has latency and availability requirements a batch job does not, and the failure behaviour has to be a deliberate decision. Blocking every payment when the screening service is unavailable is a choice with consequences. Releasing every payment is a different choice with worse ones. Teams that never make that decision explicitly discover their default during an outage.

Onboarding integrations break for a data reason. Screening consumes names, addresses, dates of birth and ownership structures, and those are entered by humans in a customer onboarding system that keeps evolving. A new field, a changed address format, a merged party record, and your matching input quietly changes shape while your thresholds stay where they were.

Two defences. Pin the input contract, validate every incoming record against it, and alert on drift rather than on failure, since partial degradation is more common than an outage. Then stamp every screening event with the list version, the parameter set and the input snapshot that produced it, so a payment released on a particular Tuesday can be reproduced exactly. That last point costs almost nothing at the start and is close to impossible to retrofit.

What happens when the OFAC 50 percent rule is not covered?

You screen names very well and miss entities that are blocked because of who owns them. Under the 50 percent rule an entity owned in aggregate by blocked persons is itself blocked even where its own name appears nowhere on any list. No fuzzy matcher will find it, because there is nothing to match against.

This is the clearest example of why a screening tool bolted onto the side of an onboarding platform underperforms a system that shares its data model. You already collect ownership information during onboarding for corporate clients. If screening cannot see it, the control simply does not exist, and the gap is invisible in every metric you report, because the entity never generated a hit to begin with.

The fix is to evaluate every node in the ownership structure against the lists and compute aggregate blocked ownership through the chain, including indirect holdings, then treat a threshold breach as a hit with its own disposition path. Two practical points. Ownership data is often stale, so record the date it was collected and flag structures older than your refresh policy rather than silently trusting them. And re evaluate the whole population when a list changes, because the trigger for a new breach is frequently a list addition rather than a change in the ownership itself.

Should you build custom or configure what you already own?

If you are a smaller institution screening a few hundred names a day in batch, with a customer base that does not stress transliteration, buy. LexisNexis Bridger Insight or a comparable mid market product plus disciplined process is proportionate, and building a name matching engine is effort spent a long way from where your risk actually sits.

Be precise about what you already own. LSEG World-Check and Dow Jones Risk and Compliance are data providers, and good ones, supplying lists and enrichment rather than a matching engine or your workflow. Fircosoft is the incumbent inline filter in large payment operations and is proven at volume, with tuning that is specialist work and iterates slowly. Napier offers a more configurable modern architecture and is still a platform you configure to your population. If your gap is coverage of lists, you have a data subscription question, not a build question.

Build, or build the layer around a bought filter, when two or more of these are true. Screening sits inline against a payment cutoff and the queue is the bottleneck. Your customer base or corridors create matching behaviour that default algorithms handle badly, for example heavy transliteration variance or patronymic name ordering. You cannot evidence why your thresholds sit where they do. Your good guy list has passed a few hundred entries and nobody governs it. Or you already hold ownership graphs and want the 50 percent rule evaluated properly rather than by hand. Keeping a proven filter and owning the tuning and disposition layer around it is the most common sensible answer.

How do hidden costs get into the quote?

Screening quotes go wrong in the same five places.

• Inline screening is priced like batch screening. A filter in a live payment path carries latency budgets, availability targets and a designed failure mode, and all three cost more than a scheduled job.
• Historical replay is assumed to be free. Proving a threshold change is safe means rerunning past screening events through candidate parameters, which requires that those events were stored in a queryable form from day one.
• List count is underestimated. Beyond the major sanctions programmes there are internal lists, correspondent supplied lists and politically exposed person data, each with its own shape and update rhythm.
• Non Latin script handling is treated as a library choice. It is genuine specialist work and it is the difference between usable precision and an unworkable queue for large parts of your book.
• Trade finance is folded in silently. Vessel names, ports, goods descriptions and dual use item references behave nothing like personal names and need their own normalisation, scoring and reference data.

The honest bands from Digital Heroes delivery experience are $80,000 to $190,000 over 12 to 18 weeks for a first release covering list ingestion with versioning and delta computation, an inspectable matching pipeline and an operations queue with structured dispositions, and $240,000 to $550,000 across 8 to 16 months for a full platform adding inline screening, historical replay, governed good guy lists, ownership evaluation and blocked property record keeping.

What separates a build that works from one that fails here?

Whether the pipeline is inspectable. Normalisation, transliteration handling, tokenisation, scoring and threshold should be separate, versioned stages, so that when your sanctions officer asks why a name scored 87 somebody can answer stage by stage rather than appealing to a vendor. That answer is the difference between tuning and guessing.

Second, list updates have to be treated as events. When a programme amends an entry, the correct behaviour is to compute the delta, re screen the existing customer base against additions and amendments, and force review of any whitelist entry whose underlying record changed. Authorities add aliases and identifiers to existing entries regularly, and an amendment to something you previously cleared is precisely what the control exists to catch. A nightly file load does none of this.

Third, no threshold change ships without a replay. Rerun historical events through the candidate parameters and look at which hits would no longer fire, not just how many. Anything else is an opinion with a deployment date.

Fourth, dispositions are structured. A hit closed with a selected reason referencing the identifier that differentiated your customer from the listed party is evidence. Free text is not.

Fifth, ownership. You should own the repository, the matching parameters, the full disposition history and the cloud accounts, in the contract before kickoff. At Digital Heroes the client owns all of it from the first commit. That record is what defends the programme in an examination, and an arrangement where it sits somewhere you cannot extract it from should be refused.