"Fuzzy matching" is a family of techniques, and each one has a blind spot. This is how KYCWire combines them, with examples from the actual lists.
1. Normalisation
Every name is transliterated to Latin, lower-cased, stripped of diacritics; legal forms (LLC, GmbH, OOO) and stop-words are removed for the candidate search but kept for scoring. «Владимир Владимирович ПУТИН» becomes vladimir vladimirovic putin.
2. Trigram similarity
Split names into three-letter chunks and compare the sets. Cheap, indexable (PostgreSQL pg_trgm), and good at typos: zawahri and zawahiri share most trigrams. Blind spot: different scripts. kim cen yn and jong un kim share almost nothing.
3. Phonetic keys
Metaphone-style codes make Mohamed and Muhammad collide. Blind spot: the same across-script problem, plus false collisions on short names.
4. Name symbols
A dictionary maps name parts to language-independent identifiers: the Russian «Ким», the English Kim and the Korean 김 resolve to the same symbol. Candidates sharing two or more symbols are retrieved regardless of spelling. This is the step that finds Jong Un KIM from «Ким Чен Ын»; without it, that query returns nothing.
5. Scoring
Retrieval is deliberately generous (recall); scoring is where precision happens. We use logic-v2 from the nomenklatura library (MIT, the engine behind OpenSanctions): name similarity across scripts, identifier matches as strong positives, penalties for conflicting birth date, gender or country. The output is a 0–1 score plus the list of signals that fired.
Measured, not claimed
On our public set of 400 cases — exact names, publisher aliases, typos, word-order swaps, Cyrillic queries and 15 clean names — recall@5 is 0.99 and no clean name scores as likely. Median latency 66 ms, p95 142 ms, measured with cold caches on a single node. The two misses are typos inside legal forms («LIMITED LIABILTY COMPANY …»), where the normaliser fails to recognise the form; we list them on the methodology page rather than hide them.
