Sanctions lists, PEP databases, and customer records are mostly stored in the Latin alphabet. A large share of the people on those lists have names that were originally written in Arabic, Cyrillic, Chinese, or another non-Latin script. Every one of those names was converted into Latin letters before it could sit in a screening database, and the conversion is the problem. Transliteration is a choice, not a fact.
There is often no single correct spelling. One Arabic name can be validly written as Mohammed, Muhammad, Mohamed, or Muhamad, and all four appear in real documents and on real sanctions lists. The name is the same. The spellings are not.
The conversion happens in several places, and each one can choose differently. The passport office renders the name once, following the issuing state's transliteration rules. The bank's onboarding form captures it again, often exactly as the customer typed it. The list compiler converts it a third time, under the listing authority's conventions. Three conversions, three spellings, one person, and none of them wrong. The name travels through every system as a series of independent choices.
That creates two failures at once. False negatives: The sanctioned spelling on the list does not match the customer's spelling, so a real match is missed. False positives: Over-broad matching flags unrelated people who share a common transliterated name. The two failures pull in opposite directions, which is why tuning goes wrong so easily. Loosen the matching to catch variants and the alerts on common names become unmanageable. Tighten it to cut the noise and the sanctioned spelling you never had slips through.
There is a structural reason this never gets fully fixed. Transliteration is one-to-many in one direction: one Arabic or Cyrillic name produces several Latin forms. It is many-to-one in the other: different Chinese characters with different tones collapse into one Latin spelling. Screening sits in the middle of both, trying to reconstruct identity from spellings that were never unique to begin with.
Most name-matching tools were designed for Latin names, where the name and the spelling are close to the same thing. Non-Latin names break that assumption, and every script breaks it differently.
The article works through the problem script by script, then turns to the fixes:
- Arabic names: The hardest case
- Cyrillic names: Multiple romanization systems
- Chinese and other CJK names: Order and systems
- How to screen non-Latin names effectively
- The role of secondary identifiers
- How Sanction Scanner helps
Arabic names: the hardest case
Arabic is the hardest script for screening, for reasons built into the writing system and the naming system.
The script itself creates spelling drift. Short vowels are usually not written in Arabic, so a transliterator has to supply them from knowledge of the word. Two competent transliterators can produce different vowels for the same name, and both are defensible. The definite article al- adds more drift: It is attached, hyphenated, or dropped depending on the convention (al-Rahman, Alrahman, Rahman), and it assimilates with certain consonants, which is how al-Sham becomes ash-Sham. Patronymics vary too: bin, ibn, and bint all appear, with different conventions for spacing and capitalization.
The examples matter more than the explanation. Mohammed, Muhammad, Mohamed, and Muhamad are one name. Abd al-Rahman, Abdulrahman, Abdul Rahman, and Abdelrahman are one name. These are not edge cases. They are among the most common names in the world, and each variant has appeared on a sanctions list or a customer record at some point.
The naming system adds a second layer. Many Arabic names are chains: a given name followed by the father's name, sometimes the grandfather's, with no fixed family surname in the Western sense. Any part of the chain can be dropped or reordered depending on the document, the country, and the registrar. A full name on one record is a fragment on another.
The same person's spelling can also change between documents. A passport, a bank form, and a sanctions list can carry three different renderings, each defensible under a different convention. The ALA-LC tables used by libraries differ from the renderings used by commercial list vendors, which differ again from what a customer types on a form. The variance is not sloppiness. It is the writing system.
Teams that screen Middle East customer bases learn this from the alert queue itself. The Muhammad variants alone can dominate a false-positive report, which pushes teams toward tighter thresholds, which then miss the very variants the tighter threshold was never shown. Normalization is the way out: strip diacritics, standardize the al- forms, and treat the patronymic chain as tokens before matching. A system that skips this step produces the worst of both worlds.
What this means for matching is direct. Exact matching fails, and so does basic edit-distance matching, because two spellings of the same name can be far apart in character terms: Abdulrahman and Abd al-Rahman share most of their letters but not their structure. Phonetic matching, such as Metaphone or Double Metaphone, treats them as close, because it compares what the name sounds like rather than how it is spelled. Token-based matching handles the chain problem, matching on the parts of the name that survive across documents. Both are essential for Arabic, and exact matching alone is close to useless.
Cyrillic names: Multiple romanization systems
Cyrillic has the opposite problem: Too much standardization in competing flavors. Several romanization systems are in active use, and each produces different Latin spellings for the same Cyrillic name.
The main systems: GOST, the Russian national standard; BGN/PCGN, used by US and UK government bodies for names and places; and ISO 9, a scientific standard built to be reversible, so that the Latin form can be converted back to Cyrillic without loss. On top of these sit the traditional English renderings that most people actually use.
The result is that one person has several official spellings. Aleksandr is GOST or BGN/PCGN for a name that most English readers write as Alexander, and Alexandr is a third version seen on older and French-influenced records. Yevgeniy, Evgeny, and Evgenii are the same person depending on whether BGN/PCGN, traditional English, or scientific transliteration produced the record.
Russian patronymics add more variation. The middle name is built from the father's name: Ivanovich for a son, Ivanovna for a daughter. A list entry may carry the full patronymic, the initial, or nothing, and a customer record may differ again. Gender forms change surnames too: Ivanov and Ivanova are the same family. Declension adds the last wrinkle: Russian names change shape by grammatical case, and official documents occasionally carry genitive or dative forms, so a surname can appear with an ending it does not normally have.
The problem is not confined to Russia. Ukrainian names carry their own renderings, and the differences are visible in the news: The capital is Kyiv in Ukrainian usage and Kiev in Russian-derived usage, and the Ukrainian president's surname appears as Zelenskyy and Zelensky depending on the source. Two spellings, one person, and a compliance team somewhere has to decide whether they are the same name. The same divide runs through Belarusian, Kazakh, and other Cyrillic-script names on sanctions lists.
The operational fix is alias generation. At list-load time, expand each Cyrillic-origin entry into the spellings each major system would produce, so the screening engine compares against all of them at once rather than the single spelling the list vendor chose. It costs storage and it costs noise, and it is still cheaper than missing the variant that matters.
None of this is exotic to anyone screening Russia sanctions, where the list volume is large and the stakes are high. The practical question is always the same: Which romanization did the list use, and which one did the customer form use. A screening system that treats Aleksandr and Alexander as different people will miss matches. One that treats them as the same without other evidence will drown in false positives.
Chinese and other CJK names: Order and systems
Chinese, Japanese and Korean (CJK) names have their own set of problems, starting with the existence of two major romanization systems. Pinyin is the modern standard, adopted in China and recognized internationally. Wade-Giles is the older system that still lives on in legacy records and in some overseas names. Mao Zedong and Mao Tse-tung are the same person, and a screening engine that does not know both will miss one of the two most famous name pairs in modern history.
Name order is the second problem. Chinese places the surname first: Mao is the family name. Latin records often reverse the order, and different lists handle the reversal differently, so the same person appears as Mao Zedong and Zedong Mao in different databases. The same city gap shows up in everyday names too: Beijing is Pinyin, Peking is Wade-Giles, and older overseas Chinese families kept spellings that no longer match anything produced in China. Both spellings sit in real databases. Token-based matching that ignores order, or that handles surname and given name explicitly, is the only way to keep both forms connected.
Tones are the third problem. Mandarin distinguishes syllables by tone, and romanization drops the tones. Different characters with different tones collapse into the same Latin syllable, and different names collapse into the same Latin spelling. The surnames Zhang and Zhang can be two entirely different families: The character that means bow-arrow and the one that means chapter are both written Zhang. A list entry for Zhang Wei can correspond to many different people, and usually does.
The common surnames then do the rest of the damage. Wang, Li, and Zhang are among the most common surnames in the world, with the surname Wang alone shared by tens of millions of people. A loose threshold on a Chinese name produces false positives by the thousand, which teaches the wrong lesson: Teams tighten the threshold to survive, and the tightened threshold misses the transliteration variants the loose one was meant to catch.
The other CJK languages have the same shape of problem with different details. Korean names appear in Revised Romanization, in the older McCune-Reischauer system, and in conventional spellings, so Lee is also Yi or I, and Park is also Pak or Bak. Japanese long vowels are rendered differently by system, so the same surname appears as Sato and Satou across databases, and Tokyo appears as Toukyou in some records. Every one of these variants has appeared on a real document.
Two mechanics round out the CJK problem. When tones are gone, order is reversed, and two romanization systems coexist, a single Latin string can stand for a startling number of different people. Tightening the threshold to survive that volume misses exactly the sanctioned names that share a common surname.
How to screen non-Latin names effectively
The fixes are a mix of matching technology, data policy, and threshold discipline.
Use phonetic matching and Jaro-Winkler. Metaphone and Double Metaphone compare how names sound, which is what transliteration variants have in common, and Jaro-Winkler rewards matching prefixes, which is where transliterated names usually agree. Basic edit distance punishes names for the spaces and vowels that transliteration rearranges, so it underperforms on exactly the names that need it most.
Screen against original-script data where available. If a list or a database carries the Arabic or Cyrillic or Chinese form, match on that too. Original-script matching sidesteps the transliteration problem entirely for the entries that have it, and a surprising share of well-run commercial databases do carry it.
Account for name order. Token-based matching should compare surname to surname and given name to given name, then the reversed pairing, not just the concatenated string. This matters for Chinese and Korean names, and for Arabic patronymic chains.
Handle patronymics and honorifics explicitly. Normalize al-, bin, ibn, bint, -ovich, and -ovna before matching rather than letting them act as random noise. A rule that strips or standardizes these elements removes a large share of avoidable misses.
Calibrate thresholds by script. The same threshold that works for a Latin name is wrong for a Chinese or Korean name. Scripts with very common surnames need tighter thresholds plus secondary identifiers, or the false-positive load forces the team to abandon the whole exercise. Measure the false-positive rate per script, not in aggregate. A program whose overall alert rate looks healthy can be drowning on Chinese names while missing Cyrillic variants, and an aggregate number hides both.
Use secondary identifiers to disambiguate. Date of birth, nationality, passport or ID number, and place of birth are what separate the sanctioned Zhang Wei from the other fifty thousand. Name-only matching on transliterated names is always a candidate generator, never a decision. The next section covers this properly.
Know which romanization the list uses. Different regulators and data vendors use different systems, and the mismatch between list and customer data is a screening gap in itself. A sanctions list built on BGN/PCGN will not line up with customer records captured under traditional English spellings unless the matching layer is built to bridge them.
None of this is exotic, and none of it requires new data. The phonetic algorithms have existed for decades, original-script fields are already in the databases that carry them, and the identifiers live in the onboarding file. The gap is mostly configuration: Systems get installed with defaults tuned for Latin names and never revisited. The Wolfsberg Group's sanctions screening guidance treats calibration and testing as permanent program elements rather than one-time setup, because thresholds drift as lists and customer bases change, and a match rate that was right last year is not necessarily right now.
The pattern across all three scripts is the same. The name is the weakest available identifier, and the systems that treat it as the only one fail in both directions.
|
Script |
Main sources of variation |
Matching approach |
|
Arabic |
Unwritten short vowels, al- attachment, patronymic chains |
Phonetic and token matching, al- and patronymic normalization |
|
Cyrillic |
Competing romanization systems, patronymics, gender forms |
Multi-system alias generation, suffix and gender handling |
|
CJK |
Two romanization systems, name order, dropped tones |
Token order handling, calibrated thresholds, secondary identifiers |
The role of secondary identifiers
Name-only matching on transliterated names is unreliable by construction, which means secondary identifiers do most of the real work. Date of birth, nationality, passport or ID number, and place of birth are what turn an ambiguous name match into a confident decision.
This is not a workaround. It is the standard the regulators built into customer due diligence in the first place: Identifying a customer means collecting exactly these fields, name, date of birth, address, and identification number. Most onboarding files already contain them. The failure is that many screening systems never use them in the match.
The difference is easiest to see in volume terms. A screening run on a large customer base produces a queue of Zhang Wei candidates. With no secondary identifiers, an analyst reviews every one and closes most with no basis for the decision. With a date of birth and nationality attached, the system prunes the queue before the analyst sees it, and the ones that remain are decisions rather than guesses.
For common names the difference is visible immediately. A screening hit on Zhang Wei with no other identifier is a queue of candidates, not a match. The same hit with a date of birth and a nationality collapses to one or two people, and the alert becomes reviewable. Every identifier removes a share of the candidate pool, and for high-frequency surnames the identifiers are the only reason the pool is manageable at all.
Two practical points follow. First, capture identifiers in structured fields at onboarding, not free text. A date of birth that the matching engine can read is worth ten that an analyst has to hunt for in a PDF. Second, treat an identifier mismatch as a signal in its own right. A strong name match with the wrong date of birth is usually a false positive, but sometimes it is a deliberate near-match, and both cases deserve the same thing: A look.
A third point belongs on the same list: Show the identifiers next to the name in the alert itself. An analyst who has to open the customer file to see the date of birth will stop using it after the first hundred alerts.
One more advantage sits quietly in this list: ID numbers do not transliterate. A passport number is the same in every script, which makes it the only identifier in the file that is immune to the whole problem this article describes. It is also the one teams forget to capture, because it feels like an afterthought. It is not.
How Sanction Scanner helps
Sanction Scanner's screening handles transliteration through phonetic and fuzzy matching, multi-script data, and secondary-identifier disambiguation, which reduces both false negatives and false positives on non-Latin names. The matching layer treats transliteration variants as the same candidate pool, and the disambiguation uses the identifiers in the file rather than the name alone. See the AML screening and monitoring, AML transaction screening, and PEP screening capabilities for the mechanics.
Two operational consequences follow. On the false-negative side, the matching layer applies the normalization rules this article has described as defaults rather than as analyst memory: al- handling, patronymic suffixes, name order, and the alias sets for each script run before the score is computed. On the false-positive side, secondary identifiers shrink a queue of Zhang Wei candidates into the one or two people who matter, which is where the analyst hours come back. Ongoing monitoring keeps the gains from decaying, because lists acquire new aliases and spellings, and a record that passed last year can fail this year. The documentation trails the decisions, so an examiner sees not just that a match was resolved, but which spellings and identifiers resolved it.
The name is where screening starts, and where it most often goes wrong. Transliteration variance is a permanent feature of non-Latin names, not a data-quality accident, so the systems that work are the ones built around it: Match on sound and tokens, respect script differences, and let the identifiers decide what the name only suggests.
Sources
[1] Financial Crimes Enforcement Network. Customer Identification Program Requirements (31 CFR 1020.220). 2025.
[2] Library of Congress and American Library Association. ALA-LC Romanization Tables (Arabic). 2022.
FAQ's Blog Post
ID numbers do not transliterate, which makes a passport number the only field in the file immune to this problem entirely. Customer identification rules already require it alongside name, date of birth and address, so the data is usually there. Teams leave it out of the match because it feels like an onboarding formality.
Mohammed and Muhammad are the same name, and so are Mohamed and Muhamad. Arabic short vowels are usually unwritten, so two competent transliterators supply different vowels and both spellings are defensible. All four appear in real documents and on real lists. Treating them as separate people is how a designated party clears screening.
Al- breaks matching because it is attached, hyphenated or dropped by convention, and it assimilates with certain consonants, so al-Sham becomes ash-Sham. Abd al-Rahman, Abdulrahman, Abdul Rahman and Abdelrahman are one name in four shapes. A rule that standardizes the prefix before scoring removes a large share of otherwise avoidable misses.
Romanization of Cyrillic runs on three competing systems: GOST, the Russian national standard, BGN/PCGN, used by US and UK government bodies, and ISO 9, built to be reversible back to Cyrillic. Traditional English renderings sit on top of all three. Yevgeniy, Evgeny and Evgenii are one person, and a list vendor picks only one.
Pinyin is the modern romanization standard adopted in China and recognized internationally, and Wade-Giles is the older system that survives in legacy records and overseas names. Mao Zedong and Mao Tse-tung are the same person, and Beijing and Peking are the same city. An engine that knows only one system misses every entry written in the other.
Phonetic matching should carry transliterated names, not basic edit distance. Metaphone and Double Metaphone compare how a name sounds, which is what variants share, and Jaro-Winkler rewards the matching prefixes where transliterations usually agree. Abdulrahman and Abd al-Rahman are far apart in character terms and close in sound. Edit distance alone drops them.
Chinese names should be matched on tokens in both orders, not on the concatenated string. Chinese places the surname first, Mao is the family name, and Latin records often reverse it, so the same person sits in two databases as Mao Zedong and Zedong Mao. Order-blind token matching keeps both forms connected.
Normalization should strip diacritics, standardize the al- forms, and handle patronymic elements such as bin, ibn, bint, -ovich and -ovna as tokens rather than as part of the surname. Russian gender forms belong here too, since Ivanov and Ivanova are one family. A system that skips this step misses variants no threshold can recover.
Transliteration is the conversion of a name from its original script into Latin letters, and it is a choice rather than a fact. A passport office renders it under ICAO Doc 9303 conventions, the onboarding form captures what the customer typed, and the list compiler converts it again. Three conversions, three spellings, one person.
Arabic is the hardest script because the writing system itself creates spelling drift. Short vowels are usually unwritten, so a transliterator supplies them from knowledge, and the definite article al- is attached, hyphenated or dropped depending on convention. Mohammed, Muhammad, Mohamed and Muhamad are one name. Exact matching treats them as four people.
