Sanctions Name Matching: Fuzzy Logic Without False Positive Floods

Sanctions screening looks simple: compare a customer name against a list, flag the matches. In practice, a single name can appear a dozen ways across scripts, spellings, and word orders, while the consolidated lists from OFAC, the EU, the UN, and HMT/OFSI carry aliases, low-quality entries, and thousands of near-identical strings. The engineering problem is not detection. It is separating the one true hit from the several thousand plausible-looking coincidences.

Why Exact Matching Fails

Names do not survive digitization cleanly. "Mohammed" appears as Muhammad, Mohamad, Mohd, and at least a dozen other forms. Cyrillic and Arabic names arrive through competing transliteration standards, so the same person is spelled two or three ways in different feeds. Add these routine distortions and exact string comparison misses real targets:

• Transliteration variance — one source-language name maps to many Latin-script spellings.
• Name order — given-name-first versus surname-first, plus optional patronymics and honorifics.
• Truncation and tokens — middle names dropped, initials only, or compound surnames split.
• Diacritics and encoding — accented characters stripped or mangled during data entry.

Because exact matching produces false negatives, screening systems deliberately widen the net with fuzzy logic. That trade is what generates the false positive problem everyone complains about.

The Matching Techniques

Most engines combine several algorithms and blend their scores. Each handles a different failure mode:

• Edit distance (Levenshtein, Damerau) measures character insertions, deletions, and swaps — good for typos and truncation.
• Phonetic encoding (Soundex, Metaphone, NYSIIS) collapses names that sound alike, catching spelling variants that edit distance misses.
• Token-based similarity (Jaccard, Jaro-Winkler) compares name components independently, tolerating reordering and missing tokens.
• Transliteration normalization converts non-Latin scripts to a canonical form before comparison, reducing cross-script noise.

Preprocessing matters as much as the algorithm. Normalizing case, stripping honorifics and business suffixes, standardizing diacritics, and handling stop words all happen before a single comparison runs. A weak normalization stage forces the fuzzy layer to work harder, which inflates false positives.

Tuning Thresholds and Cutting Noise

Every fuzzy match carries a similarity score, and the threshold that separates "alert" from "ignore" is the single most consequential setting in the system. Set it high and you miss variant spellings of a genuine target; set it low and analysts drown. Firms rarely land on one universal number — they tune per list, per name type, and sometimes per script.

Several controls reduce the alert volume without discarding real hits:

• Secondary identifiers — date of birth, nationality, and place of birth confirm or dismiss a name match. A shared name with a 30-year age gap is not a hit.
• Match categorization — routing strong, medium, and weak matches to different review queues so analysts spend time where it counts.
• Good-guy lists — recording confirmed false positives so the same benign customer is not re-alerted on every rescreen.
• List hygiene — filtering out entries with insufficient identifying data that generate disproportionate noise.

The more attributes you can bring to disambiguation, the fewer names you escalate — but each attribute is additional personal data. That tension is real. Collecting date of birth and nationality sharpens matching precision; collecting them for every customer expands the data you must protect and eventually delete. The resolution is scoping: gather the minimum needed to disambiguate at the risk level you operate under, and set retention on match evidence deliberately rather than by default. In a chat-based onboarding flow, that means requesting a secondary identifier only when a name screen produces an ambiguous result, rather than harvesting everything up front.

Screening quality is measurable. Track false positive rate, analyst time per alert, and periodic testing against known-hit control sets. A system that never fires is broken; one that fires on everything is worse. This is general operational guidance, not legal advice — calibrate against your own obligations and regulator expectations.