Screening a counterparty against a restricted list is one of the oldest automated compliance tasks and one of the least satisfying. Tighten the matching and real hits are missed. Loosen it and the queue fills with unrelated people who share a common surname. Neither dial position is correct, because the dial is not the problem.
Why string similarity is the wrong primitive
Names arrive transliterated from scripts with no single romanization, ordered differently across cultures, abbreviated inconsistently, and entered by people under time pressure. Edit distance treats all of these as the same kind of variation, which they are not.
Meanwhile the strongest disambiguating signals — date of birth, jurisdiction of registration, address, identifier numbers, known associates — are either not used or used as a post-filter after the damage to the queue is already done.
The queue is not full because the threshold is wrong. It is full because the match ignored everything except the name.
The exposure that name matching cannot see
Restrictions commonly extend through ownership and control, not just to named parties. A counterparty that appears nowhere on any list may be majority-owned by an entity that does. No amount of name matching on the counterparty finds this.
Catching it requires a resolved supplier ownership graph — resolved entities, evidence-bearing links, versioned so a determination made last quarter can be reproduced. Screening and ownership resolution are usually run as separate programs by separate teams, and the gap between them is where the real exposure sits.
What a better screening decision looks like
- Multi-signal scoring where name is one input among identifiers, dates, and geography
- Explicit handling of transliteration families rather than character-level distance
- Ownership and control traversal to a defined depth, with the path shown
- Every disposition recorded with the signals that produced it, not just the outcome
- A measured false-negative estimate from seeded testing, not only a false-positive rate
The seeded test is the part most programs skip. Inserting known-positive synthetic counterparties into the live flow, at low volume, is the only practical way to measure what the system misses rather than what it flags.
Discriminating power of each screening signal
Relative weighting from delivery practice, not a measured statistic — shown to rank where attention belongs.
Where language models fit, and where they do not
They are useful for reading unstructured counterparty documentation and extracting the identifiers and relationships that the matching layer needs — turning a messy onboarding packet into structured, span-linked facts.
They are not the right tool for the match decision itself, which needs to be deterministic, reproducible, and explainable to an examiner years later. A determination that cannot be re-run identically is not a determination, and generative components make re-running identically difficult by construction.
The narrative layer, again
As with AML alert triage, the drafting of the disposition rationale is where fabrication enters. The same rule applies without modification: the drafting model receives the structured determination object, and any assertion it produces that does not resolve to a field in that object is removed before the record is written.
The signals, and what each one is good for
Moving beyond name similarity means being explicit about what other evidence exists and how much weight it can bear.
| Signal | Strength | Caveat |
|---|---|---|
| Government identifier | Very high when present and well-formed | Frequently absent; formats vary; transcription errors common |
| Date of birth or incorporation | High as a discriminator | Partial dates are common on lists; year-only is weak |
| Jurisdiction | Good for exclusion | Registration jurisdiction may differ from operating location |
| Address | Moderate | Shared service addresses produce spurious agreement at scale |
| Known associates | High where the graph exists | Requires relationship data most programs do not maintain |
| Name string | Low alone | The only signal always present, which is why it dominates by default |
Reading that table top to bottom explains the queue. The signal that is always available is the weakest one, so systems built on availability rather than strength generate volume proportional to how common the name is.
Transliteration deserves better than edit distance
A large share of list entries originate in scripts with no single romanization convention. The same name arrives through different conventions, through different intermediary languages, and through inconsistent handling of prefixes and particles.
Edit distance treats a two-character difference produced by a legitimate romanization variant identically to a two-character difference between unrelated names. That is wrong in both directions: it under-matches genuine variants that differ by more characters, and over-matches unrelated names that happen to be close.
The better approach maps names to a phonetic or script-aware representation that reflects how the variants arose, handles particles and honorifics explicitly, and treats name-order variation as a structural rather than a character-level phenomenon. This is well-trodden ground with mature open approaches, and programs still commonly run generic fuzzy matching because it was what the platform shipped with.
Seeded testing: measuring what you miss
Every program measures false positives because they arrive in the queue and demand attention. Almost none measure false negatives, because a missed match generates no artifact.
Seeded testing is the practical remedy. Synthetic counterparties, constructed to match list entries in specific ways, are injected into the live screening flow at low volume and tracked.
- Exact-name seeds confirm the basic path works end to end
- Transliteration-variant seeds test the matching layer where it actually operates
- Name-order and particle seeds test structural handling
- Ownership seeds — a clean counterparty majority-owned by a listed entity — test whether the traversal runs at all
- Partial-identifier seeds test whether weak-but-real signals are used or discarded
The results are frequently uncomfortable and always actionable. The ownership category in particular tends to reveal that the traversal exists in the design document and not in the running system.
Documenting the tuning
Thresholds get adjusted in every program. The adjustment is defensible when the record shows a risk analysis and indefensible when it shows a volume motivation, and the two look identical in the configuration.
What the record needs: what was changed, the analysis of what falls newly outside the threshold, an estimate of the risk accepted, the approver, and the date. Where a model confidence cutoff replaces a rule threshold, the same standard applies without modification — a model boundary is a threshold with extra steps.
A useful discipline is to require that any threshold change be accompanied by a re-run of the seeded test set. If the change causes seeds to be missed that were previously caught, that is the risk analysis, produced automatically, in a form nobody can argue with.
Connecting screening to the ownership graph
Screening and ownership resolution are typically owned by different teams with different systems, and the exposure lives in the seam. A counterparty that clears name screening while being controlled by a listed entity is the exact case the rules contemplate, and it requires both capabilities operating together.
Practically this means the screening decision consumes the resolved ownership graph rather than the raw counterparty name, traverses it to a defined depth, and records the depth and the graph version with the determination. When the graph updates and a new controlling relationship appears, previously cleared counterparties are re-evaluated automatically rather than at the next scheduled review.
That re-evaluation loop is what turns two static processes into a control that actually responds to change, and it is usually a modest engineering effort relative to the exposure it closes.
Onboarding and payment screening are different problems
They are usually run on the same engine with the same lists and treated as one capability. The constraints are not comparable and the shared configuration is where trouble starts.
| Onboarding | Payment | |
|---|---|---|
| Time available | Hours to days | Milliseconds to seconds |
| Data available | Full application, identifiers, documents | Whatever the message carries, often a name and a country |
| Cost of a false positive | A delayed application | A blocked payment and a customer call |
| Ownership traversal | Practical and expected | Only against a pre-resolved cache |
The bottom row is the operational key. Ownership traversal cannot happen inside a payment window, which means the graph has to be resolved in advance and cached, with the payment path doing a lookup rather than a computation. Programs that discover this late end up either skipping the traversal on payments or accepting latency nobody agreed to.
List management is its own discipline
Screening quality depends on list currency, and list ingestion is more failure-prone than it appears. Lists change format, add fields, publish corrections, and occasionally issue entries with malformed or partial identifiers.
A program that ingests without validating will silently degrade — a parsing change that drops a field reduces match quality with no error anywhere. The controls are unglamorous: record counts compared against the publisher's stated totals, schema validation on ingest, alerting when an expected update does not arrive, and retention of every list version so a historical determination can be reproduced against the list as it stood.
Governance the examination will ask about
Beyond the tuning record described above, three artifacts are consistently requested and inconsistently maintained.
A written scope statement — which lists, which populations, which transaction types, and what is deliberately out of scope. A documented escalation and override procedure, with evidence that overrides are reviewed rather than merely recorded. And periodic independent testing of the screening itself, distinct from the institution's own tuning analysis.
None of this improves detection. All of it determines whether the detection you have is credited, which is the practical difference between a program that works and a program that can be shown to work.
Frequently asked questions
Only if the added volume is genuinely reviewed. A queue too large to review carefully converts a false-positive problem into a false-negative one, which is the worse of the two.
Deep enough to satisfy the applicable rule, and the depth used must be recorded with the determination so a later reviewer knows what was and was not examined.