Name Matching Across Alphabets: Screening Names That Don't Spell Themselves

A watchlist entry reads Muhammad. Your customer typed Mohamed. A third system stored Mohammad. All three refer to names that sound nearly identical in the source language, yet a naive exact-match check treats them as three unrelated strings. Multiply that across Arabic, Cyrillic, Chinese, and Latin scripts, plus reversed name order and dropped middle names, and you have the central engineering problem of sanctions and watchlist screening: matching people, not spellings.

Why Exact Matching Fails

Screening names carries two opposing error costs. A miss lets a sanctioned party through and creates regulatory exposure. A false positive stops a legitimate customer, triggers manual review, and adds cost and friction. Exact string comparison maximizes both problems at once: it misses legitimate variants while offering no cushion for the ones it does catch.

The variation is not random. It comes from predictable sources:

• Transliteration — one Arabic, Cyrillic, or Han character maps to several Latin spellings depending on the standard used (ICAO, BGN/PCGN, or none at all).
• Name order — given name and surname swap between cultures and between the passport MRZ and the display field.
• Compound and particle names — al-, bin, van der, de la may be joined, split, or omitted.
• Diacritics and encoding — José versus Jose, ü versus ue.
• Nicknames and initials — William, Bill, W.

The Matching Toolkit

Robust screening combines several algorithms rather than trusting one. Common layers:

• Edit distance (Levenshtein, Damerau-Levenshtein) counts insertions, deletions, and swaps. Good for typos, weak for phonetic drift.
• Phonetic encoding (Soundex, Metaphone, and the multilingual Beider-Morse) collapses words that sound alike. This is what links Mohamed to Mohammad.
• Token-based scoring (Jaccard, Jaro-Winkler) handles reordered and partial name components.
• Transliteration normalization converts scripts to a canonical form before comparison, so the same person written in two alphabets lands in the same space.

Each match produces a score, and you set a threshold. Set it high and you cut false positives but raise the miss rate; set it low and you drown reviewers in alerts. The threshold is a policy decision, not a technical constant, and it should be documented, tested against known cases, and revisited as list quality changes.

Cutting False Positives Without Cutting Coverage

Fuzzy matching alone is blunt. The practical gains come from secondary identifiers that disambiguate the hits. Date of birth, nationality, and a document number turn a 30-name alert into a single defensible decision. A customer named Ivan Petrov who is 24 and born in one country should not be flagged against a sanctioned Ivan Petrov born in a different decade elsewhere.

This is where a chat-based flow helps operationally. When onboarding runs as a structured conversation, you collect the disambiguating fields — full legal name, date of birth, nationality — in a consistent, validated shape before screening runs, rather than parsing free-text forms. Cleaner input means fewer spurious matches and a clearer record of what was compared. Following data minimization, you screen against the identifiers you actually need and retain the match evidence under a configurable schedule rather than hoarding raw data indefinitely.

Governing the Match Engine

Auditors and examiners will ask how the engine behaves, so treat it as a governed system:

• Record the list version and date used for each screening, since sanctions lists change frequently.
• Log the algorithm, score, and threshold that produced or cleared each alert.
• Keep a test suite of known variants and known non-matches, and re-run it after any tuning change.
• Preserve the reviewer's rationale for dispositioning each hit.

Name matching will never be perfectly precise, because human names are not precise. The goal is a calibrated, explainable process that catches the entries that matter and can show why it cleared the rest. This is general information, not legal advice; confirm screening obligations and thresholds with your compliance counsel and applicable regulators.