Fuzzy Name Matching for Sanctions Screening Explained
How fuzzy name matching catches transliteration, spelling, and phonetic variants in sanctions screening -- techniques, worked examples, and honest limits.
Fuzzy name matching is the set of techniques a screening system uses to catch a name on a sanctions or PEP list even when the spelling in front of it doesn't match the spelling on the list character-for-character. It exists because "no match" and "no risk" are not the same statement: a sanctioned individual whose name was transliterated one way on a US list and another way on your customer's passport is still the same person. A screening engine that only does exact string comparison will clear them.
This is not a solved problem. It's a layered one, and understanding the layers is the difference between a screening programme that actually catches variant spellings and one that just looks like it does.
Why is name matching hard in sanctions screening?
Because the same real person legitimately produces dozens of different correct strings, and a screening engine has to recognize all of them without also matching thousands of unrelated people who happen to share a common word.
Transliteration produces dozens of valid spellings for one name
A name written in Arabic, Cyrillic, or Chinese script has no single correct Latin-alphabet spelling. It has several, produced by different transliteration conventions, none of which is "wrong." Mohammed alone legitimately appears as Mohammed, Muhammad, Mohamed, Muhammed, Mohammad, Mohd, and more, depending on the source language dialect and which transliteration system produced the Latin spelling. Chinese names carry the same problem twice over: Wade-Giles versus Pinyin romanization can turn one surname into two visually unrelated strings (Mao Tse-tung vs. Mao Zedong). Cyrillic names pick up further variance from the source country's own transliteration standard: Russian, Ukrainian, and Bulgarian romanization rules diverge on the same letters. This isn't an edge case. It's the normal condition for a large share of sanctioned individuals. It's also why ICAO Doc 9303, the international standard for machine-readable travel documents, defines its own transliteration tables for Latin, Cyrillic, and Arabic script families rather than assuming one correct answer exists [ICAO Doc 9303].
Name order and structure vary by culture, not by error
Family-name-first order (most East Asian naming conventions) versus given-name-first order (most Western conventions) means the same two words can appear in either order on genuine documents. A system that assumes a fixed name/surname field mapping will silently fail on half the world's naming conventions. Patronymics compound the problem. Russian names carry a middle patronymic derived from the father's first name (Ivanovich, Ivanovna). Icelandic surnames are patronymic rather than family names entirely (Jónsson, Jónsdóttir, literally "Jón's son" / "Jón's daughter"). Arabic names may use bin or ibn ("son of") to chain several generations of ancestry into what looks, to a naive parser, like four unrelated given names. Honorifics (Al-, El-, Sheikh, Haji, Dr.) get typed inconsistently as part of the name or dropped entirely. None of this is noise to be stripped; it's structure that carries real information, and stripping it carelessly can erase the very token that would have matched.
Diminutives and compound surnames add further variance
Bob for Robert, Sasha for Alexander, Bill for William: informal names that never appear on any official document but do appear in submitted customer data. Spanish and Portuguese naming conventions routinely carry two family surnames (paternal followed by maternal). A system trained on a single-surname assumption will either drop one or treat the pair as a single unmatchable token.
OCR and keyboard errors are a fifth, unrelated source of noise
Separate from all of the above, a scanned passport or a manually typed customer form introduces character-level errors that have nothing to do with linguistics: a keyboard-adjacent substitution, a digit misread as a letter by OCR, a transposed pair of characters. These need a different technique than transliteration variance does, because they're single-character edits on an otherwise-correct spelling rather than a structurally different (but equally correct) rendering of the name.
How does fuzzy name matching actually work?
No single technique catches all five problems above. A real matching engine runs several in combination, each catching what the previous one misses, and each introducing its own false-positive risk in exchange.
| Technique | Catches | Misses | False-positive risk |
|---|---|---|---|
| Exact token match | All query tokens present on the list name, order-independent | Any spelling variant at all | None (the baseline) |
| Normalized names (diacritic/accent stripping) | Accented spelling variants: José vs. Jose, Müller vs. Muller | Consonant/vowel substitutions, transliteration divergence | Very low |
| Token-level edit distance (Levenshtein) | Single- or few-character typos and OCR errors: Marzook vs. Marzouk, Smith vs. Smyth | Structurally different transliterations that don't reduce to a small edit count, and any name-order/patronymic difference | Rises sharply on short tokens if left unscaled: a flat edit-distance ceiling applied to a 5-letter word treats a large fraction of that word as "fuzzy," which is why a length-aware ceiling (tighter tolerance on short tokens, looser on long ones) matters more than the raw distance number |
| Phonetic algorithms (Soundex, Metaphone, Double Metaphone, NYSIIS) | Same-sound, different-spelling names: the core transliteration problem above | Purely visual/spelling similarity with no phonetic overlap, and any structural (order/patronymic) difference | The highest of the four: phonetic codes are coarse by design, so a real engine can't treat every algorithm as equally trustworthy; ours weights multiple independent phonetic algorithms and treats their agreement as a confidence signal rather than scoring any single algorithm's hit at face value |
Layering them in that order (exact, then normalized, then edit-distance, then phonetic) mirrors how much unrelated volume each layer pulls in. Exact matching is free of false positives because it demands the most agreement. Phonetic matching is the most useful for the transliteration problem precisely because it tolerates the most disagreement, and precisely because of that has to be treated with the most caution downstream.
Double Metaphone is the phonetic layer most worth understanding for sanctions work. Unlike Soundex or original Metaphone, it emits a primary code and an alternate code for names that have more than one plausible pronunciation. That second code is why Arabic and Cyrillic romanizations that look unrelated on the page often still collide: the engine is matching sound patterns, not letters.
A worked example: three techniques, one name
Take a sanctioned individual listed as Putin and a submitted name Poutine (a genuine French-transliteration variant, not a typo). Exact token matching fails outright. The strings share no common token. Levenshtein distance between "putin" and "poutine" is 2, above the length-aware ceiling of 1 that a 5-letter token typically gets, so an edit-distance-only system also misses it. A phonetic algorithm, by contrast, encodes both strings by their consonant skeleton and vowel-independent sound pattern. This is exactly the case phonetic matching exists for. It's also exactly the kind of match that needs a second corroborating signal (a country flag, a partial identifier, an exact surname elsewhere in the record) before it should move an alert to a high-confidence review queue rather than a low-confidence one. That's precisely because phonetic-only agreement is the weakest of the four signals in the table above.
Why does matching quality depend on separating "finding candidates" from "scoring confidence"?
Because they're different jobs with opposite failure modes, and running them as one step lets the wrong one win.
Finding candidates (recall) needs to be generous: it exists to make sure a genuine match is still somewhere in the result set at all. Scoring confidence (precision) needs to be strict: it exists to rank that result set so a genuine hit surfaces near the top instead of buried under noise. A screening engine that conflates the two runs into a specific, non-obvious failure. A high-volume, low-precision signal (fuzzy text matching, which by design returns many loosely related candidates) can crowd out a low-volume, high-precision signal (an exact token match) if both are competing for the same fixed result budget. We hit exactly this failure in production: a fuzzy-text channel's sheer candidate volume pushed an exact name-token match for a real sanctioned individual far enough down a shared ranked list that it fell outside the results actually returned. The fix wasn't a smarter combined query. It was giving each matching signal its own separate search and its own separate budget, so that a noisy signal can never evict a clean one. It's a small architectural point, but it's the one that determines whether "we do fuzzy matching" is true in the way that matters.
The same discipline shows up in how a distinctive name is told apart from a generic one. "Ltd," "Group," "Holdings," "International," "Trading," "Solutions": corporate suffixes and industry-boilerplate words carry almost no distinguishing information. But an "all tokens present" rule applied naively will score an organization named entirely from words like these as a full exact match against any sanctioned entity that happens to share the same boilerplate (a real screening risk, since shell and front companies are frequently named exactly this blandly). The honest fix is not to block such names from matching (a genuinely sanctioned entity with a bland name still needs to be caught) but to score a match built entirely from generic tokens lower than one built from at least one distinctive word. Let corroborating evidence (a country, an identifier) carry the rest.
What can fuzzy name matching not solve?
Everything above assumes an honest name, imperfectly transcribed. That assumption breaks down in a few specific ways, and a matching engine should be judged partly on whether it's honest about where it stops working.
- Deliberate obfuscation. Someone actively trying to evade a name-based screen (adding a middle name, reversing characters on purpose, using an alias never linked to the sanctioned identity in any list) is playing a different game than transliteration variance. No amount of edit-distance or phonetic tuning closes that gap on its own. This is what identifier-based matching (passport numbers, dates of birth, national IDs) and beneficial-ownership screening exist to catch instead.
- Diminutives and nicknames. Bob for Robert, Sasha for Alexander: these are different words, not spelling variants of the same word. Phonetic and edit-distance layers will not map them unless the engine also carries a nickname dictionary, which most screening systems, including ours, do not.
- Shell and layered ownership structures. A sanctioned individual hiding behind a chain of holding companies isn't a name-matching problem at all. No name on the transaction ever matches the sanctioned name, because the entity in front of you genuinely isn't them on paper.
- No-name identifiers. Wallet addresses, vessel IMO numbers, aircraft tail numbers: these need their own exact-match channels entirely separate from name matching, because there's no "fuzzy" version of a 64-character hexadecimal string that means anything.
None of this is a reason to distrust fuzzy matching. It's a reason to keep it correctly scoped as one layer of a screening programme, with identifier matching, ownership screening, and threshold tuning as the layers that pick up where it stops.
Frequently asked questions
Is fuzzy matching the same as phonetic matching? No. Phonetic matching is one technique inside fuzzy matching. Fuzzy matching is the umbrella term for any technique that catches a non-exact match. Phonetic algorithms (Soundex, Metaphone, NYSIIS, and variants) are one such technique, alongside normalized-name matching and edit-distance matching, each catching a different category of spelling variance.
Does fuzzy matching increase false positives? Yes, and that's inherent to the trade-off, not a flaw to be engineered away entirely. Every layer beyond exact matching trades some false-positive volume for recall on genuine variant spellings. The engineering work is in scoring (giving each technique a confidence level proportional to how reliable it actually is, so low-confidence phonetic-only hits don't get the same weight as an exact token match). It's also in threshold tuning, which decides how much of that trade-off a given screening programme is willing to accept.
Can fuzzy matching be turned off? Technically yes. But doing so re-opens the exact problem it exists to close: a sanctioned individual whose name was transliterated differently on the list than on your customer's record would clear a screen they should have failed. Exact-only matching is faster and produces zero false positives from spelling variance, at the cost of missing a meaningful share of genuine matches. OFAC's own screening guidance discusses fuzzy matching as part of a risk-based programme; treating exact-string matching as sufficient is the gap that guidance is written against.
Why do different vendors get different results for the same name? Because "fuzzy matching" describes a category of technique, not one specific algorithm, and vendors differ in which techniques they run, how they weight and combine them, and where they set the confidence threshold for surfacing a result. Two engines can both legitimately claim to do phonetic matching and disagree on a specific borderline name.
Citations
- ICAO, Doc 9303: Machine Readable Travel Documents, Part 3 (transliteration tables for Latin, Cyrillic, and Arabic script families): https://www.icao.int/publications/doc-series/doc-9303
Matching that survives the spelling
Name matching is one layer of a screening programme, not the whole of it: how well it's tuned determines whether it protects you or drowns your review team.
DeRisk Hub runs tokenised, normalised, edit-distance, and multi-algorithm phonetic matching as one recall-and-scoring pipeline behind every screen. See the platform overview, what sanctions screening actually involves, or which lists you need to screen against. Start your free trial, or go to DeRiskHub.com.