Sanctions Screening: Why One Threshold Is Always Wrong

Sanctions screening content is genuinely useful on the surface mechanics: exact matches score highest, minor spelling variations score somewhat lower, and a configurable similarity threshold decides what actually generates an alert for a human reviewer to look at. What that content consistently skips is why a name actually fails to exact-match in the first place beyond simple typos, and why applying one similarity threshold uniformly across every name in a screening population is a mathematically flawed approach, not just a tuning inconvenience.

This is the actual, real transliteration problem underneath sanctions name matching, a core piece of compliance risk automation, why the standard, widely used edit-distance algorithm handles it so poorly, and why a single threshold cannot be correct for every population a screening system actually processes. It sits alongside the broader AML document workflow covered in our AML document checks guide.

Why sanctions screening cannot be exact-match by design

A sanctions list entry and a customer's submitted name frequently do not fail to match because of a simple typo, a common misconception worth correcting directly. They fail to match because the same underlying name, particularly a name originally written in a non-Latin script, has multiple, entirely legitimate, correct spellings once transliterated into Latin characters, and the specific variant appearing on a sanctions list is not guaranteed to be the same variant a customer's own documents happen to use.

The transliteration explosion, and why it is not a rounding error

A single Arabic name can produce over 3,000 distinct, individually defensible Latin transliterations depending on which specific romanization convention is applied, differences in how vowel sounds get rendered, how the definite article gets attached or separated, and how specific consonant sounds with no direct Latin equivalent get approximated. This is not a handful of edge-case spelling variants, it is a combinatorial explosion arising from the structural mismatch between the source script's phonetic system and Latin script's more limited character set. Screening a name only against its single, most common transliteration, or worse still, only exact-matching it, misses the overwhelming majority of the legitimately possible spellings of that exact same real name.

Why Levenshtein distance, the standard fuzzy-matching tool, handles this specific problem poorly

Edit-distance algorithms like Levenshtein distance measure how many character insertions, deletions, or substitutions separate two strings, and they treat every substitution as equally costly: changing a "c" to a "p" counts the same as changing a "c" to a "k," even though a "c" to "k" substitution is far more likely to represent the same underlying sound rendered through a different transliteration convention, while a "c" to "p" substitution more often signals an actual typo or a genuinely different name. This uniform weighting is a real, structural limitation, not a configuration mistake: Levenshtein distance was designed to measure general string similarity, not phonetic similarity specific to cross-script name transliteration, and applying it as the sole matching method treats a linguistically expected transliteration variant with exactly the same suspicion as a random data-entry error, without distinguishing the two at all.

A worked example: two spellings of the same name, one weak Levenshtein score

Take "MOHAMMED" and "MUHAMMAD," two extremely common, individually correct, entirely legitimate transliterations of the exact same underlying Arabic name, both encountered constantly in real screening populations. Both strings are eight characters long. Comparing position by position: the second character differs, O versus U, and the seventh character differs, E versus A, every other position matches exactly. That is a Levenshtein distance of exactly two, the minimum number of single-character substitutions needed to turn one string into the other. Normalized against the string length, that distance corresponds to roughly 75% similarity, a full ten percentage points below the illustrative 85% threshold often used as the alert-triggering cutoff in practice. Two spellings of the identical name, differing only in vowel transliteration convention, can score meaningfully below a threshold that sounds intuitively generous, precisely because raw edit distance has no concept of "these are both valid renderings of the same sound," only "these two characters differ."

Why name matching alone always needs a supplementary identifier as a tiebreaker

Even a well-tuned, genuinely phonetically-aware matching system cannot fully resolve ambiguity from name similarity alone, no matter how carefully calibrated, particularly against extremely common given and family names shared by large numbers of genuinely unrelated people. Date of birth, nationality, and any available government identification number all function together as the actual disambiguating signal in a mature screening program, narrowing a name-based fuzzy match down to a specific individual rather than treating every plausible name collision as equally uncertain. A name-only match against a common name, with no date of birth or nationality corroboration available at all, should carry meaningfully less weight in a review queue than the identical name-similarity score paired with a matching date of birth, since the second case has independently corroborating evidence the first entirely lacks.

Why the SDN list's own alias field is an admission of this exact problem

Sanctions list entries very commonly include multiple "also known as" aliases attached to a single designated individual, precisely because the maintaining authority recognizes that no single transliteration is sufficient to reliably match every real-world spelling a screened name might arrive in. A screening system that checks a submitted name only against a designated individual's single, primary listed name, ignoring the alias field entirely, is discarding exactly the data the list's own maintainers included to address this specific gap, an avoidable, self-inflicted coverage hole sitting inside data the system already has access to.

Why one universal similarity threshold is mathematically the wrong choice

A similarity threshold decides how close a fuzzy match needs to be before it actually generates an alert, commonly illustrated somewhere around 85% for what counts as a meaningful, genuinely actionable match worth a reviewer's time. That threshold implicitly assumes something about the underlying distribution of name similarity across the screened population: how similar two genuinely unrelated names are likely to be purely by chance. Populations with naming conventions that cluster more tightly together, common patronymic structures, a smaller effective pool of common given and family name combinations, produce meaningfully higher baseline similarity between unrelated individuals than populations with more naming diversity. Applying the identical threshold to both populations produces a materially different false-positive rate for each one, not because the matching logic is broken, but because the same numeric threshold means something different against two different underlying similarity distributions.

Population naming pattern	Baseline similarity between unrelated names	Effect of a fixed 85% threshold
High naming diversity	Low, unrelated names rarely score close to 85%	Threshold performs close to as intended, few false positives
Tightly clustered naming conventions	Higher, unrelated names can naturally score closer to the threshold	Same threshold produces a higher false-positive rate purely from population structure

The list-refresh timing problem sitting alongside the matching problem

A genuinely well-tuned matching algorithm, however carefully built, is still only ever as good as the underlying list it actually screens against, and sanctions lists genuinely do change, additions, removals, and alias updates all happening on an ongoing, continuous basis rather than on any predictable, fixed schedule anyone could simply plan around. A screening system running against a stale, outdated, cached copy of a sanctions list will correctly apply excellent matching logic to entirely the wrong underlying data, entirely missing a recently added designation, regardless of how genuinely sophisticated the fuzzy-matching and threshold calibration underneath it actually is. This is a separate failure mode from the matching-algorithm problems described above, a data-freshness problem rather than an algorithmic one, but it produces an identical practical outcome: a genuine sanctioned individual passing screening undetected, this time because the list itself was out of date at the moment of the check rather than because the name comparison logic failed to recognize a valid match.

What actually works better: combining methods, not raising the threshold universally

Simply raising the threshold for populations with higher baseline similarity trades one problem for another, since a higher threshold applied broadly also raises the risk of missing a genuine match, a false negative, which is a materially worse outcome in sanctions screening than an extra false positive requiring manual review. A better approach combines edit-distance scoring with phonetic matching methods designed to weight substitutions by actual sound similarity rather than treating every character change identically, alongside population-aware threshold calibration that accounts for known baseline similarity differences rather than applying one number everywhere. None of this eliminates manual review entirely, but it shifts review volume toward genuinely ambiguous cases rather than distributing false positives unevenly across populations purely as an artifact of a single, uncalibrated threshold.

What I would check in your current sanctions screening pipeline

Ask whether your matching logic screens against every listed alias for a designated individual, not just the primary name, since the alias field exists specifically to cover the transliteration gap a primary-name-only check misses. Then ask whether your similarity threshold is a single fixed number applied universally, or whether it accounts for known differences in baseline name similarity across different naming-convention populations, since a uniform threshold produces measurably uneven false-positive rates by population even when the matching algorithm itself is working exactly as designed. Confirm your fuzzy-matching approach combines edit-distance with a phonetic or transliteration-aware method, rather than relying on Levenshtein distance alone, since edit-distance's uniform substitution weighting specifically mishandles the cross-script transliteration variants that account for a meaningful share of genuine near-misses. And check how frequently your underlying sanctions list data actually refreshes, since even ideal matching logic run against stale list data produces the same practical failure as a genuine matching miss, the same document-freshness discipline covered from a different mechanism in our KYB verification piece, where a similarly stale reference source undermined an otherwise well-designed check.

Frequently asked questions

Why does a legitimate name fail to exact-match a sanctions list entry?
Most commonly because the name was originally written in a non-Latin script and has multiple, equally valid Latin transliterations, not because of a typo. The specific variant on the sanctions list may differ from the variant on a customer's documents.

Why can a single Arabic name have thousands of valid transliterations?
Because romanization conventions vary in how they render vowel sounds, the definite article, and consonants with no direct Latin equivalent, producing a combinatorial explosion of individually defensible spellings for the same underlying name.

Why does Levenshtein distance handle transliteration variants poorly?
It weights every character substitution equally, treating a phonetically plausible transliteration substitution the same as an unrelated typo, since it was designed for general string similarity rather than cross-script phonetic similarity.

Why do sanctions list entries include multiple aliases per person?
Because list maintainers recognize a single transliteration is not sufficient to reliably match every real-world spelling variant. A system that only checks the primary listed name discards this built-in coverage.

Why is a single universal similarity threshold mathematically wrong?
Because different naming-convention populations have different baseline similarity between unrelated names. The same threshold produces a meaningfully different false-positive rate depending on the underlying population's name diversity.

Does raising the threshold for high-similarity populations solve the problem?
Not cleanly. A higher threshold reduces false positives but increases the risk of missing genuine matches. A better approach combines phonetic matching with population-aware calibration rather than a single blunt threshold adjustment.

A configurable similarity threshold and an illustrative example score are useful for explaining that fuzzy matching exists. They say nothing about why exact matching fails in the first place, or why the exact same threshold number means something different depending on which population it is being applied to, and that gap is exactly where a screening program's real false-positive and false-negative rates actually get decided. The "MOHAMMED" versus "MUHAMMAD" example above is not a contrived edge case built for this piece; it is close to the median case for a large share of the world's population, which is precisely why it deserves more attention than a single illustrative percentage on a vendor's pricing page ever gives it. Written by Nupura Ughade.