Name Screening

What name screening actually does

Name screening compares a name against reference data, sanctions lists, PEP databases, adverse media indexes, and scores how closely they match, rather than checking for an exact string match alone. Exact matching alone misses too much: names get transliterated differently across scripts, misspelled during data entry, shortened to nicknames, or deliberately altered, which is why every serious screening system relies on algorithms that measure similarity along a spectrum rather than a binary yes or no.

Levenshtein distance: counting the edits

Levenshtein distance counts the minimum number of single-character edits, insertions, deletions, or substitutions, needed to transform one string into another. Comparing “Stefan” and “Stephan” requires one substitution (f to ph, treated as a single edit in simplified form) or a small number of edits depending on exact spelling, giving a low edit distance and a high similarity score once normalised: score = 1 minus (distance divided by the longer string’s length).

Levenshtein works well for short strings with minor typos, product codes, postal codes, last names, but has two real weaknesses: it’s computationally slower on long strings, and it treats every character position as equally important, so a typo in the first letter costs the same as a typo in the middle, even though names are far more likely to have errors later in the string than at the very start.

Jaro-Winkler: weighting the beginning of a name

Jaro-Winkler distance addresses that specific weakness by giving extra weight to characters that match at the beginning of a string. This makes it particularly effective for personal names, where the first letters are usually correct and errors tend to cluster later, transliteration variants, missing middle characters, or swapped later letters. For this reason, Jaro-Winkler is generally considered the stronger default for screening individual names, especially names with transliteration variation from Arabic, Cyrillic, or other non-Latin scripts, while Levenshtein remains more suited to comparing addresses or company names where every character carries similar weight.

Phonetic algorithms: matching by sound, not spelling

Edit-distance algorithms have a specific blind spot: names that sound identical but are spelled very differently score poorly. “Jean” and “Gene” pronounce the same in English but have a low Levenshtein similarity, since almost every character differs. Phonetic algorithms exist specifically to catch this category of match.

Soundex, developed in 1918 and still in use, converts a name into a fixed four-character code based on English pronunciation; “Cyndi,” “Candy,” and “Condie” can all reduce to the same code because they sound alike, regardless of spelling. Metaphone improved on Soundex by applying a wider set of English pronunciation rules and allowing variable-length codes rather than Soundex’s fixed four characters. Double Metaphone went further still, generating both a primary and secondary code per name specifically to handle ambiguous pronunciations and names originating from Slavic, Germanic, Celtic, Greek, French, Italian, Spanish, and Chinese linguistic traditions, not just English.

Why real screening systems combine multiple algorithms

No single algorithm covers every failure mode. Edit-distance algorithms like Levenshtein and Jaro-Winkler catch typos and minor spelling variants but miss sound-alike names spelled very differently. Phonetic algorithms like Soundex and Metaphone catch sound-alike names but discard most vowel information, meaning they can’t reliably distinguish genuinely different names, such as Smith from Smoth, that happen to share a phonetic code. Effective name screening layers both approaches, edit distance to catch typos and near-misses, phonetic matching as a supplementary check specifically for sound-based variants, rather than relying on either category alone.

Transliteration: a problem neither approach fully solves

Names originating in non-Latin scripts, Arabic, Cyrillic, Chinese, and others, get converted to Latin characters through transliteration before most Western screening systems can process them at all, and that conversion step itself introduces variation, since there’s often no single, universally agreed transliteration standard for a given name. A name can legitimately appear in a database in several different Latin-script spellings, none of them wrong, simply because different transliteration conventions were applied at different points. This is a genuine limitation that neither edit-distance nor phonetic algorithms fully resolve on their own, which is part of why alias data quality in the underlying watchlist matters as much as the matching algorithm applied against it.

Why regulators don’t mandate a specific algorithm

Neither FinCEN nor OFAC mandates a specific name screening algorithm or technical methodology. Regulatory expectations focus on outcomes, effectively handling name variations, aliases, and typographical errors, rather than prescribing which specific algorithm or combination a firm must use. This is consistent with the risk-based approach that runs through AML regulation generally: firms are expected to justify their own methodology choices against their actual risk profile, not follow a single mandated technical standard.

Choosing and tuning algorithms in practice

In practice, the choice depends on what’s being screened. Jaro-Winkler tends to suit fast, real-time individual name screening in retail banking and payments, where speed and prefix-accurate matching both matter. Levenshtein remains useful for comparing addresses, company names, and other longer strings where character position matters less. Phonetic algorithms work best layered on top as a supplementary check, not a primary matching method, specifically to catch the sound-alike, spelled-differently case the edit-distance methods miss.

Whatever combination is chosen, the resulting thresholds need to be tuned against actual outcomes, part of the same rule tuning discipline that applies to transaction monitoring more broadly, rather than left at default settings indefinitely.

What this means for the false positive problem

Every algorithm choice is really a trade-off along the same axis: loosen the matching threshold and catch more genuine variants, at the cost of more false positives; tighten it and cut noise, at the risk of missing a genuine hit disguised through spelling or transliteration. There’s no threshold setting that eliminates both problems simultaneously, which is exactly why name screening remains, in the words of one industry analysis, one of the hardest practical problems in sanctions and AML compliance, not a solved technical exercise.

Frequently asked questions

Read more: our ultimate guides, whitepapers and templates

Related guides and resources to help you act on what you just read.