Name Screening: Taming Transliteration and Fuzzy Matches

Sanctions and PEP screening lives or dies on how you compare names. A single individual can appear as Mohammed, Muhammad, Mohamed, or Mehmet depending on the source language, transliteration standard, and data-entry habits of whoever typed it. Exact string matching misses these variants; naive fuzzy matching floods your queue. The goal is a pipeline that catches genuine list hits while keeping the reviewable volume proportionate to your risk appetite.

Why Names Break Matching Engines

Name data is messy for structural reasons, not just typos. Screening teams routinely deal with:

• Transliteration divergence — Arabic, Cyrillic, and CJK scripts have multiple romanization systems (BGN/PCGN, ISO 9, Pinyin vs Wade-Giles), so one source name maps to several Latin spellings.
• Word order — given/family order flips across cultures, and patronymics or maternal surnames may or may not appear.
• Particles and prefixes — al-, bin, van der, and de la get split, merged, or dropped inconsistently.
• Aliases and diminutives — Bill for William, Sasha for Alexander, plus deliberate aliases recorded on sanctions lists.
• Diacritics and encoding — José vs Jose, ß vs ss, and mojibake from broken UTF-8 conversions.

Because you collect names at onboarding, the cleanliness of your intake shapes everything downstream. Chat-based verification helps here: a structured prompt that captures name fields separately, and confirms the spelling back to the user, reduces the entropy your matcher has to absorb.

Building a Layered Matching Pipeline

No single algorithm handles every case, so combine techniques in stages. A practical order:

• Normalize first — Unicode NFKC normalization, case folding, diacritic stripping, and consistent handling of particles before any comparison runs.
• Transliterate to a common script using a documented standard so cross-script comparisons are apples to apples.
• Apply phonetic keys — Double Metaphone or Beider-Morse for European names, though be aware these are English-biased and weaken on non-Latin origins.
• Compute edit-distance scores — Jaro-Winkler and token-based measures (e.g., token sort ratio) catch reordering and truncation better than raw Levenshtein.
• Match on components, not the full string, and weight rare tokens higher than common ones so a shared surname alone does not trigger an alert.

Layering lets you require agreement across methods, which suppresses the coincidental matches that any one technique produces in isolation.

Tuning Thresholds and Secondary Attributes

A name match alone is weak evidence. The single most effective way to cut false positives is to fuse names with corroborating identifiers. Date of birth, nationality, and country of residence turn a 40-name candidate set into one or two reviewable hits. Where a list entry lacks a date of birth, treat the match as lower confidence rather than discarding it.

Set score thresholds per list and per risk band, not globally. Sanctions lists warrant lower thresholds and wider nets; marketing suppression lists do not. Document your chosen cutoffs, the rationale, and the test data behind them so an examiner can see the decision was deliberate. Re-run threshold tests whenever you change vendors or normalization logic, because a quiet library upgrade can shift match rates measurably.

Auditing, Retention, and Rescreening

Every match decision — hit, discounted, or escalated — needs a durable record showing the name compared, the algorithm and score, the corroborating attributes, and the reviewer's disposition. Keep the list version and date so you can reconstruct why a customer cleared on a given day.

Screening is not one-and-done. Lists change, so rescreen your book against deltas rather than reprocessing everyone from scratch. Store only the identifiers screening actually needs, and apply configurable retention so match evidence expires on a defined schedule instead of accumulating indefinitely. For a broader treatment of the intake side, see our note on data minimization in KYC. This article is general information, not legal advice; confirm obligations with qualified counsel.