Sanctions and adverse media screening at scale

Two problems, one pipeline, and that is the bug

Sanctions screening asks a closed question: does this party appear on a published list, or is it owned by parties that do? The universe is bounded, the lists are machine-readable, and the standard for a civil violation does not turn on whether you meant to. Adverse media screening asks an open question: is there anything in the world's published record suggesting this party is a problem? There is no list, no authority, no closed universe, and no single right answer.

Those two questions want different architectures, thresholds, review workflows and measures of success. Point one product at both with one fuzziness setting and the predictable result is a sanctions engine loose enough to bury analysts in noise and a media engine tight enough to miss the story that mattered. Separating them is the highest-value change most programs can make, and it costs nothing but a decision.

What you screen against, and how the lists arrive

Start with an inventory, because half the programs we look at cannot produce one. Write down every list, its authority, its publication format, its update cadence, the date you last ingested it, and which populations you screen against it. That table is the first thing a reviewer will ask for and it takes an afternoon.

In the United States the core is the Treasury list of specially designated nationals and blocked persons, alongside the consolidated set of other Treasury-administered lists carrying narrower prohibitions. Beyond Treasury sit Commerce restricted-party lists, State Department lists, and government-wide exclusion records. Outside the United States, the United Nations, the European Union and the United Kingdom each publish their own consolidated lists, and they do not agree with each other. Which of these bind you is a legal question, not an engineering one.

Three properties of the data drive the engineering. Records are richer than names. A well-formed entry carries aliases with quality markers, dates and places of birth, nationalities, identification documents, addresses, vessel and aircraft identifiers, and in some cases digital currency addresses. A pipeline that reduces each entry to a name string is discarding most of the evidence that separates a real match from a coincidence.

Updates are event-driven, not periodic. Designations publish when they publish. Build for continuous ingestion rather than a nightly job you hope is fast enough, keep every version of every list forever, and be able to state exactly which version was in force at the moment of any decision.

Structure varies and changes. Publishers offer several formats with different fidelity, and they revise them. Parse the richest one available, validate each ingestion against the previous, and alarm on a list that shrinks unexpectedly. A truncated download that loads silently is the worst failure in this domain, because everything downstream looks healthy.

Name matching is a transliteration problem in a string-distance costume

Teams reach for edit distance first. Edit distance is the least interesting part of the problem, and tuning it is where months disappear.

The real difficulty is that the same human name is written in many scripts by many conventions. Arabic, Cyrillic, Chinese and Korean names reach a Latin-script system through romanization schemes that disagree with each other and with themselves. The Arabic definite article attaches or does not, with or without a hyphen. Patronymic particles appear, vanish, or fuse into the next word. Spanish names carry two surnames, and a system that keeps one will half-match forever. Korean and Hungarian names put the family name first. Honorifics and titles arrive glued to the front.

The consequence is a specific and correctable failure: a program with a well-tuned edit distance and no transliteration layer misses matches that a human would judge obvious, while generating noise on unrelated common names. Fix the normalization before touching the threshold. Apply consistent script-aware transliteration, normalize Unicode forms and diacritics, expand and strip particles as separate token features rather than deleting them, tokenize instead of comparing whole strings, and keep the original alongside every normalized form so a reviewer can see what the machine actually compared.

Then use structure, not just similarity. Token comparison handles reordering and missing middle names in ways whole-string distance never will. Phonetic keys are useful for candidate generation and dangerous as a decision rule. Weight rare tokens above common ones. Most importantly, score the secondary attributes separately: a name match that agrees on date of birth and nationality is a different object from one with no supporting field, and collapsing them into a single score is why analysts see hundreds of alerts a two-second glance dismisses.

One quiet source of improvement sits upstream of all of this. Screening quality is bounded by input quality, and most institutions have a customer file where the full name lives in one free-text field, country is inconsistently coded, and date of birth is captured for some populations and not others. Structuring those fields usually improves match performance more than any algorithm change, and it is unglamorous work that nobody assigns.

Thresholds, and the only honest way to set one

Every screening program has a fuzziness threshold, and most cannot say why it is where it is. The true history is usually that it shipped as a default, was loosened once after a bad audit, and has not been touched since.

What replaces guessing is a labeled evaluation set and a documented tuning exercise. Assemble a corpus of pairs adjudicated by analysts: true matches, near misses, and confusable non-matches, drawn from your own population rather than from a vendor's sample data. Include the hard categories deliberately — transliterated names, common names, entities with legal form suffixes, partial names in payment free-text fields.

Then run the two tests supervisors expect to see. Above-the-line testing samples alerts the system generated and asks how many were productive, which measures the cost you are paying. Below-the-line testing samples pairs that scored under the threshold and asks whether any should have alerted, which measures the risk you are carrying. The second one is the one that gets skipped and the one that matters, because it is the only evidence that your threshold is not hiding misses.

Two operational rules keep this from decaying. Suppressions — the list of pairs an analyst has already cleared — must be keyed to the specific party and the specific list entry, must expire, and must be automatically re-opened when the underlying list entry changes. A suppression keyed to a name alone will silence a future designation of a different person with the same name. And every threshold change is a change-controlled event with the tuning evidence attached, because the question is never “what is your threshold” but “how did you arrive at it, and when did you last check.”

Ownership is where sanctions screening stops being name matching

The largest exposure in most programs is not a fuzzy match that scored one point too low. It is an entity whose name appears on no list at all and which is owned by parties that do appear.

United States sanctions guidance has long taken the position that an entity owned fifty percent or more, directly or indirectly, individually or in the aggregate, by one or more blocked persons is itself blocked, whether or not it is named. That aggregation is the part systems get wrong. Two blocked owners holding thirty and twenty-five percent are a blocked entity, and no name matching engine will ever tell you that. Other jurisdictions apply their own tests, some resting on control rather than a percentage, so a single implementation will not satisfy every regime you touch.

What this requires is an ownership graph and path arithmetic: indirect interests multiplied along each path and summed across paths, ownership held separately from control, cycle-aware traversal, and a real distinction between “no owner found” and “no owner exists.” That is a data problem rather than a matching problem, and it is the reason a screening program eventually becomes an entity data program. Where ownership cannot be established, the honest system says so and routes the case to a human rather than returning a clean result.

Adverse media is a research problem, and it is harder

Move to media and every convenience disappears. There is no authority, no identifier, no closed universe, and the volume of published text about any common name is effectively unbounded.

Four difficulties dominate, and a system that does not name them will not perform. Disambiguation without identifiers: articles rarely give a date of birth or a registration number, so linking a story to your customer rather than to a namesake is genuinely uncertain, and the system should express that uncertainty rather than resolve it silently. Event deduplication: one arrest becomes four hundred articles through syndication and rewriting, and counting articles rather than events makes a single stale matter look like a pattern. Relevance: a lawsuit over a lease is not a predicate offense, and a taxonomy that flattens every negative mention to “adverse” produces a queue nobody can prioritize. Status and staleness: allegations, charges, dismissals, acquittals and convictions are different facts, and a system that captures the accusation and never the outcome will keep a cleared person permanently flagged.

The design that works keeps events, not articles, as the unit of record. Cluster articles into events with every source attached, map each event to a risk taxonomy your compliance function approved, record status and date, and carry a subject-link confidence a reviewer can see and override. Tier your sources and write the tiering down. Then decide in policy what drives a decision, because most media findings should inform a risk rating rather than trigger an action.

The honest measurement here is harder than for sanctions, and pretending otherwise is a mistake. You cannot compute recall against a universe you cannot enumerate. What you can do is maintain a set of known cases — matters your institution learned about through other channels — and ask whether the system would have surfaced them and how quickly. That is a weaker measure than a labeled corpus and it is far better than nothing.

Where language models help, and where they must not be the record

These models are genuinely useful in this pipeline, in specific places, and genuinely dangerous as a decision authority.

They are good at reading an article and judging whether the person described is plausibly your customer given the available context. They are good at classifying an event into a taxonomy, at clustering coverage of the same event, at extracting the status of a matter, and at drafting the summary an analyst edits. Each of those is a labeling task with a human on the other end, and each is measurable against an annotated sample.

They should not be the system of record for a screening decision, for reasons that have nothing to do with skepticism about the technology. A decision you must reproduce three years later needs a deterministic path from inputs to output. So: pin the model version, store the exact prompt and the raw output with every finding, record which fields the model produced and which came from deterministic code, keep a labeled evaluation set and re-run it on every model or prompt change, and treat that change as change-controlled exactly like a threshold change. Never let a model suppress an alert on its own — use it to enrich, rank and explain, and let the deterministic rules and the human do the clearing.

The operating record an examiner will ask for

The system is half the program. The other half is the record it leaves, and it should be a byproduct of running rather than a document written afterward.

Hold on to these, keyed together: the list versions in force at each run, the input record as screened, the normalized forms compared, every candidate with its score, the threshold and configuration in force, the disposition with the analyst and the reasoning, suppressions with owners and expiry, the change history for every threshold with its tuning evidence, and periodic testing results with sample sizes. Add coverage evidence, because the gap between “we screen customers” and “we screened all customers against the list version published on the fourteenth” is where findings live.

Report a few measures monthly and keep the history: alerts per thousand records screened, productive alert rate, auto-clear rate by class, time to disposition, backlog and its age, ingestion lag, and the last above-the-line and below-the-line results. A program that can show that chart over two years is in a different conversation from one that can only describe its process.

The mistakes we see

• One pipeline and one threshold for sanctions and adverse media
• Matching on names only, discarding dates of birth, nationalities and identifiers the list provides
• No transliteration layer, then months spent tuning edit distance to compensate
• A vendor default threshold with no tuning evidence behind it
• No below-the-line testing, so nobody knows what the threshold is hiding
• Suppressions keyed to a name, without expiry, silencing future designations
• No ownership arithmetic, so aggregate ownership by listed parties is invisible
• Counting articles instead of events, making one stale matter look like a pattern
• Capturing the allegation and never the outcome, so cleared people stay flagged
• A silent list ingestion failure, where a truncated file loads and everything downstream looks healthy

If you are rebuilding this

• Separate sanctions and adverse media into different pipelines with different thresholds
• Inventory every list, its authority, format, cadence and last ingestion
• Version and retain every list, and alarm on unexpected shrinkage
• Normalize scripts and tokenize before tuning any distance measure
• Score secondary attributes separately from the name score
• Structure the customer name, country and date of birth fields upstream
• Build a labeled pair set from your own population
• Run above-the-line and below-the-line testing at a stated cadence, with stated sample sizes
• Give suppressions an owner, a reason, an expiry and automatic re-opening
• Implement ownership aggregation, and route unknown ownership to a human
• Keep adverse media at event level with status, date and a subject-link confidence
• Pin model versions, store prompts and outputs, and never auto-suppress on a model

Bottom line

Screening rewards unglamorous work. Clean input fields, script-aware normalization, secondary attributes scored on their own, a threshold with tuning evidence behind it, ownership arithmetic that runs when a name match cannot help, and an operating record produced automatically by the system rather than assembled before an examination. None of that is a modeling breakthrough. All of it is what separates a program that can answer questions about itself from one that can only describe its intentions.

Frequently asked questions