Transliteration is rendering a name from one script into another, such as Arabic, Cyrillic, or Chinese into Latin letters, which produces several valid spellings of the same name. Because sanctioned parties often come from non-Latin-script regions, transliteration differences are a leading source of screening variation and missed matches.
What is transliteration, in plain English?
Transliteration is the act of writing a name from one alphabet into another, mapping the sounds of the original script into the letters of a new one. An Arabic, Cyrillic, or Chinese name written into Latin letters is transliterated, and because there is no single correct mapping, the same name legitimately comes out several different ways depending on who did the conversion and when.
For screening, this is a core problem rather than a curiosity. A large share of sanctioned individuals and entities originate in non-Latin-script regions, so the names on watchlists and the names on payments have both been transliterated, often by different people using different conventions. The result is that the same party can appear under multiple valid spellings, none of them wrong.
Those spelling differences cause errors in both directions: a real match gets missed because the two spellings do not line up, or an unrelated party gets flagged because a different transliteration happens to collide. Operators manage it by screening multiple transliterations, layering phonetic and fuzzy matching, and normalizing names consistently across languages.
How transliteration trips up screening
- Origin — Name starts in another script. The party's name is written in Arabic, Cyrillic, Chinese, or another non-Latin script.
- Convert — Rendered into Latin letters. Different people romanize it differently, producing several valid Latin spellings.
- Mismatch — List and payment diverge. The spelling on the watchlist and the spelling on the transaction were converted by different conventions.
- Fail — Missed or false match. Exact matching misses the real party, or a coincidental spelling collision fires a false positive.
Screening one spelling vs many
What changes | One spelling only | Multiple transliterations |
Coverage | Catches only the exact rendering you screened. | Catches the party under alternate valid spellings. |
Missed matches | A different valid spelling passes through. | Variants are normalized so the party is caught. |
Method | Exact string match on one form. | Phonetic and fuzzy matching plus normalization. |
Risk | False negatives on foreign names. | More noise to tune, but far fewer misses. |
What it looks like in practice
In practice
A sanctioned individual whose name in the original script is fixed appears on the watchlist as Aleksandr Shcherbakov. A payment routes through naming the same person as Alexander Scherbakov, a perfectly common alternate romanization. Exact matching sees two different strings and clears the payment.
The institution had already normalized both list and input names and added phonetic and fuzzy matching. Under that setup the two spellings resolve to the same underlying name and an alert fires. An analyst confirms the identifiers and blocks the payment. Screening only the single list spelling would have let an equally valid rendering of the same sanctioned party through.
Why it matters for operators
Transliteration is one of the most common reasons a sanctions screen fails silently. The name on the payment and the name on the list can both be correct and still not match character-for-character, so an exact-match engine reports clean while a listed party sails through. Because so many sanctioned parties come from non-Latin-script regions, this is not an edge case; it is a structural feature of the data.
It also runs the other way, generating false positives when unrelated names happen to transliterate into similar Latin strings. Handling it well, through multi-spelling screening, phonetic and fuzzy matching, and consistent normalization, is what separates a screening program that looks compliant from one that actually catches the parties it is meant to catch.
What to watch in the data
- Single-spelling screening. Matching one romanization of a foreign name lets the same party through under another valid form.
- Inconsistent normalization. If list names and input names are normalized differently, valid variants never line up.
- Non-Latin origin. Names from Arabic, Cyrillic, and Chinese scripts carry the highest transliteration variation and miss risk.
- Exact-match reliance. An engine without phonetic and fuzzy layers cannot bridge different transliterations of one name.
- Two-way error. Transliteration causes both missed matches and false positives, so tuning has to balance both.
Quick questions
Is transliteration the same as translation?
No. Translation converts meaning between languages; transliteration converts the letters or sounds of a name from one script into another. A name is transliterated, not translated, because you keep the name and only change how it is written.
Why does one name have several valid spellings?
Because there is no single agreed mapping from one script to another. Different conventions and different people romanize the same name in different ways, and all of them can be legitimate, which is exactly what makes screening hard.
How do teams handle transliteration in screening?
They screen multiple transliterations of a name, apply phonetic and fuzzy matching to bridge spelling differences, and normalize names consistently across list and input data so variants of the same party resolve together.
Does transliteration only cause missed matches?
No, it cuts both ways. It causes false negatives when a real party is spelled differently on the list and the payment, and false positives when unrelated names transliterate into similar Latin strings.
Which names carry the most transliteration risk?
Names originating in non-Latin scripts such as Arabic, Cyrillic, and Chinese. Since many sanctioned parties come from these regions, transliteration variation is a leading source of screening error and deserves extra matching logic.
Go deeper
- OFAC, US Treasury ↗ — Administers US sanctions programs, the SDN list, and licensing.
- European Banking Authority ↗ — EU banking regulator. Strong Customer Authentication under PSD2 and AML guidance.