Fuzzy Name Matching for Sanctions Screening: How the Architecture Fits Together

Sanctions lists are published by different authorities, in different formats, with names written in different scripts. A screening engine has to decide whether "Moammar El-Kaddafi" typed into an invoice system is the same person as "Muammar Gaddafi" on a list. This article explains the usual building blocks and the trade-offs between them. It describes the general architecture, not a benchmark of any particular product.

1. Normalization first

Most matching errors start before any fuzzy algorithm runs. Typical normalization steps:

• Unicode normalization (NFKC or NFD) and removal of diacritics, so "Müller" and "Muller" compare equal.
• Case folding, punctuation and whitespace clean-up.
• Handling of honorifics and legal-form suffixes ("Mr", "LLC", "OOO", "GmbH") so they neither create nor hide a match.
• Transliteration of non-Latin scripts. Cyrillic and Greek transliterate fairly predictably. Arabic is harder because short vowels are usually not written, so several Latin spellings map to one Arabic name. Chinese names add romanization systems and word-order questions.

Whatever is done to the query must also be done to the list entries, or the two sides stop being comparable.

2. Candidate retrieval

Comparing one query against every name and alias on every list is simple and has perfect recall for a given scoring function, but its cost grows with the size of the index. Engines therefore often add a retrieval step that narrows the field before detailed scoring:

• Token or n-gram indexes (for example trigram indexes in PostgreSQL) find entries sharing fragments of the query.
• Phonetic keys (Soundex, Metaphone and their variants) group names that sound alike.
• Automata and tries (Levenshtein automata, finite-state transducers) find every entry within a given edit distance without scanning the rest.

Each of these can drop a true match that a full scan would have found, for instance when a transliteration differs in its first letters. That is the core trade-off: faster retrieval usually costs some recall, and in sanctions screening a missed designation is worse than a slower answer.

3. Scoring

Once candidates are retrieved, a scoring function ranks them. Common ingredients:

• Edit-distance measures (Levenshtein, Damerau-Levenshtein) for typos.
• Jaro-Winkler, which rewards shared prefixes and suits short personal names.
• Token-based measures (token sort, token set) for reordered names such as family-name-first formats.
• Phonetic agreement as a supporting signal rather than a match on its own.

Scores from several measures are usually combined, then adjusted with secondary data when both sides have it: date of birth, nationality, country, or an identifier such as a passport or IMO number. A matching date of birth raises confidence; a clearly different one lowers it.

4. Thresholds and review

No threshold separates true and false matches perfectly. Engines typically define bands, for example a high band that needs review before a transaction proceeds and a lower band that is recorded but not escalated. Where the bands sit is a policy decision for the compliance team, and it should be documented along with the reasons.

5. Keeping the index current

A matching engine is only as good as its lists. Lists change without notice, so the pipeline that downloads, parses and validates them matters as much as the matching code. A partial or broken download should never silently replace a complete list.

Related reading

Matching is one layer of the problem. When screening should run, inline or on every list update, is covered in real-time vs batch screening. What to ask a vendor about match quality is in the buyer's guide. And for a real case where a listed company changed its name but kept its listed phone number, see our Pegasus breakdown.

Summary

Good sanctions matching is mostly careful normalization, a retrieval strategy whose recall limits are understood, a transparent scoring function, and documented thresholds. Speed matters, but it is the last of these to optimize, not the first.