One person, several spellings

Bottom line

A sanctions screening system matches strings. It only appears to match people, and the difference stays invisible until the strings cross alphabets. At that point the quality of the match stops being a property of the vendor and becomes a decision somebody made about data. Romanization is where that decision usually goes unmade, and leaving it unmade buys two failure modes at once: more alerts that were always going to be cleared, and fewer of the matches that mattered.

1. The problem is romanization rather than fuzzy matching

Name matching gets discussed as though the difficulty were general messiness — typos, nicknames, transposed fields. Crossing alphabets is a different and more structural problem, because here the variation is correct.

Several standards are in use at once, and they disagree. BGN/PCGN, ISO 9, ALA-LC, the GOST family, and whatever a passport authority actually printed each produce a different Latin string from the same Cyrillic one. Щ becomes Shch under BGN/PCGN and Ŝ under ISO 9; ё becomes e, ë, or yo; the ending -ий resolves to -iy, -ii, or -y. Each output is internally correct under its own system. None of them is a misspelling.

A travel document is a fourth authority. ICAO’s standard sets the transliteration used in a passport’s machine-readable zone, while issuing states apply national rules to the visual zone, so one document can carry two Latin forms of one name. Customers offer the spelling their document gave them, and they are right to.

Kazakh has been moving between scripts. A Kazakh name may reach a system in Kazakh Cyrillic, in a Russian-mediated romanization of that Cyrillic, or in one of the successive Latin orthographies published since 2017. Ж is Zh through Russian and J in the 2021 Latin alphabet, so Жанибек arrives as Zhanibek or as Janibek, and both are right.

Slavic surnames inflect for gender, and the patronymic is a third element. Щёголев becomes Щёголева for a woman, so one family carries two surname strings by design. The patronymic is stored by some systems, dropped by others, and concatenated into the given-name field by the rest.

Name order varies by convention. A record structured as given-then-family will silently invert some share of any population that writes family name first, and the inversion survives every downstream comparison intact.

2. What that does to a screening system

1. One person
2. Several legitimate romanizations
3. One stored string
4. A match threshold asked to absorb the difference

False positives. A common name and a loose threshold produce alerts faster than analysts clear them. The queue then teaches its own lesson: alerts on names from this region clear quickly, so clear them quickly.

False negatives. An unusual but entirely correct romanization sits too far from the stored string, and every threshold a business can operate at falls short of the distance.

The trap. Tuning the threshold trades one failure for the other, and the tuning gets reported as a fix. It moved the problem. The distance between two correct spellings of one name is a property of the data, and a scoring parameter has no way to reach it.

3. Where the fix actually lives

The useful interventions sit upstream of the matcher:

Intervention	What it changes
Normalize at ingest rather than at match time	Every downstream consumer sees the same form
Keep the original script alongside the romanization	The most reliable comparison is the one that stayed in its own alphabet
Store several romanizations rather than one canonical form	The list is a set of aliases, so the record should be too
Capture structured identifiers	Date of birth, place of birth, document and registry numbers cross alphabets unchanged
Make name order and patronymic handling an explicit rule	An assumption applied silently is still an assumption
Record which attribute produced the match	The only way to tell whether name matching works

One fact ties them together. The major lists publish original script and extensive alias sets, so a customer record holding a single Latin string is already a lossier object than the list it is being compared against. The gap opens on the institution’s side of the comparison.

4. A worked hypothetical

The following scenario is hypothetical and is included only to illustrate the framework. The individual, the company, and the list entry below are invented, and any resemblance to a real person or a real designation is coincidental.

A logistics company opens an account. Its director is recorded from a passport as Yevgeniy Shchyogolev. A consolidated list carries a designated individual as SHCHEGOLEV, Evgenii Yurevich, with the original script ЩЁГОЛЕВ, Евгений Юрьевич, a date of birth, and a passport number.

What the screening run produced. The two surnames differ at four positions across nine characters, and the given names share three letters out of eight. The score landed under threshold, and the account opened in silence.

The same run fired four alerts on the company’s finance contact, a common surname carried by three list entries. All four cleared inside ten minutes. The analyst’s working impression at the end of the shift: names from this region generate noise.

Where the match was eventually found. A payment six weeks later carried a passport number in a structured field. The number crossed alphabets unchanged and matched exactly. The name had been sitting in the file the whole time.

What would have caught it earlier. Storing Евгений Юрьевич Щёголев alongside the Latin form, since the list publishes it and a Cyrillic-to-Cyrillic comparison scores exactly. Generating BGN/PCGN, ISO 9, and passport-style forms at ingest and matching the set rather than one string. Capturing the passport number as a structured field at onboarding, rather than receiving it by luck in a payment message six weeks later.

The threshold was tuned twice that year. Both times it moved the failure rather than removing it.

5. Metrics, and the ones that mislead

• Alert-to-true-match ratio, segmented by name origin rather than published as one number
• Share of confirmed matches found on a structured identifier rather than on a name
• Clearing time by name origin: where names from one region clear systematically faster, the queue has learned something it should have been taught deliberately
• Count of customer records held in a single script
• Escalations that turned on a spelling rather than on the facts
• Alias coverage: how many of a list entry’s published aliases the stored record is capable of matching at all

A single aggregate alert-to-match ratio hides exactly the population this piece is about. The segmentation is the measurement.

6. What this changes operationally

A screening owner publishes the romanization standard the institution uses, in writing, and treats the choice as a control with an owner rather than as a vendor default inherited at implementation.

A data engineer stops storing one name string. Original script, one or more romanizations, and structured identifiers become distinct fields with distinct lineage, and normalization happens at ingest so every consumer downstream sees the same shapes.

An operations lead reads clearing time by name origin every month and treats a fast lane as a finding rather than as efficiency.

A tuning owner stops presenting a threshold change as an improvement without stating which failure mode absorbed it.

Limitations

This is a control-design argument rather than a tuning guide. It offers no thresholds, no scoring recommendations, and no assessment of any vendor, and it describes no institution’s screening configuration or coverage. Every claim rests on published romanization standards, public list formats, and public guidance.

It stops short of the legal question as well. Which lists apply, and what a match obliges, belong to the sanctions program itself. This piece addresses one narrower thing: whether the system is capable of finding the person it was asked to find.

Primary sources

• US Department of the Treasury, OFAC. The Specially Designated Nationals and Blocked Persons List, its published data formats, and the alias and original-script conventions carried in the advanced data files.
• Council of the European Union. The consolidated list of persons, groups, and entities subject to EU financial sanctions, and its published XML schema.
• United Nations Security Council. The Consolidated List, including original-script name fields and alias quality indicators.
• US Board on Geographic Names and the Permanent Committee on Geographical Names. The BGN/PCGN romanization system for Russian (1947).
• ISO. ISO 9:1995, Transliteration of Cyrillic characters into Latin characters — Slavic and non-Slavic languages.
• Library of Congress. ALA-LC Romanization Tables, Russian and Kazakh.
• ICAO. Doc 9303, Machine Readable Travel Documents, Part 3, on the transliteration of national characters into the machine-readable zone.
• Wolfsberg Group. Guidance on Sanctions Screening (2019). Data quality, list management, and screening structured identifiers alongside names.
• Republic of Kazakhstan. The presidential decrees moving the Kazakh alphabet to Latin script (2017, amended 2018) and the revised alphabet published in 2021.