Name Transliteration and Sanctions Matching

Sanctions screening sounds simple — check a name against a list — until you realize that a name is not a fixed string. The same person's name can be written a dozen ways when it crosses scripts, languages, and clerical conventions. Transliteration is at the heart of why sanctions matching is a fuzzy, probabilistic problem rather than a database lookup, and why screening systems throw so many false positives.

The transliteration problem

Transliteration is the process of representing a name from one writing system in another — rendering Arabic, Cyrillic, Chinese, or other scripts into the Latin alphabet. Crucially, there is no single correct answer. The Arabic name commonly written Muhammad also appears as Mohammed, Mohamed, Muhammed, and Mohammad. The Russian surname often written Yusuf may appear as Yusof or Youssef. Libyan leader's name has been rendered as Gaddafi, Qaddafi, Kadafi, and many more. Sanctions lists themselves often carry multiple spellings and known aliases for exactly this reason.

Because the underlying source scripts encode sounds differently and different languages transliterate differently, a payment message and a sanctions entry can refer to the same person while sharing not a single identical character in some fields.

Why exact matching fails

Given this, exact string matching is useless for sanctions screening in two directions. It produces false negatives — a genuine sanctioned party spelled slightly differently slips through undetected, which is a serious compliance failure. And any attempt to catch variants by loosening the match produces false positives — innocent customers whose names happen to resemble a listed name get flagged, generating huge volumes of alerts that analysts must clear by hand. The two error types trade off directly against each other.

Fuzzy matching techniques

Screening systems therefore use fuzzy matching to score similarity rather than demand identity. Common techniques include:

• Edit distance (such as Levenshtein) — counting the insertions, deletions, and substitutions needed to turn one string into another, catching Mohammed vs Mohamed.
• Phonetic algorithms — Soundex, Metaphone, and successors that map names to a sound-based code so that similarly pronounced spellings match.
• Token and n-gram methods — comparing name parts or character sequences to handle reordered or partial names.
• Cultural name handling — accounting for name order (given/family reversal), patronymics, compound surnames, and titles that are not part of the name.

Each candidate pair gets a similarity score, and the system flags matches above a configured threshold.

Tuning the threshold

The matching threshold is the central control, and it embodies a risk decision. Set it high (demanding near-identical names) and you reduce false-positive noise but risk missing a real match — a compliance and legal risk. Set it low (accepting looser similarity) and you catch more variants but bury analysts in alerts, most of them innocent. There is no threshold that eliminates both errors; the job is to calibrate it to the institution's risk appetite and then manage the residual alerts efficiently. Many programs use different thresholds by context — stricter for high-risk corridors, and combined with secondary data like date of birth, nationality, or address to disambiguate a name match.

Reducing false positives without missing hits

Because loosening the match is dangerous, the better lever is adding corroborating data. A name match alone is weak; a name match plus a matching date of birth, nationality, or identifier is strong. Screening systems reduce false positives by requiring or weighting these secondary attributes, by maintaining good-guy/whitelist records for previously cleared customers, and by using list metadata (aliases, weak-AKA flags) that indicate how reliable a given spelling is. Analysts also build institutional knowledge — documenting why a particular alert was cleared so the same false positive does not consume time repeatedly. The strategic point is that transliteration guarantees noise, so a mature program invests as much in disambiguation and alert management as in the matching algorithm itself.

Key takeaways

• Transliteration — rendering names across scripts — has no single correct spelling, so one person's name has many variants.
• Exact matching fails both ways: false negatives miss real hits, and loose matching floods analysts with false positives.
• Fuzzy matching uses edit distance, phonetic algorithms, token methods, and cultural name handling to score similarity.
• The match threshold trades false negatives against false positives; there is no setting that removes both.
• Corroborating data (date of birth, nationality, identifiers) and good alert management reduce false positives without missing hits.