Reading Non-Latin IDs: OCR and Transliteration for Arabic, Cyrillic and CJK Documents

If your onboarding flow only works for documents in Latin script, it does not work for a large share of the world. National ID cards, residence permits and driver licenses from the Middle East, Eastern Europe, Central Asia and East Asia often print key fields only in Arabic, Cyrillic or CJK (Chinese, Japanese, Korean) characters.

Reading those characters is only half the job. You also have to decide how to store them, how to compare them with Latin-script data, and how to screen them against watchlists. This post covers the problems developers and compliance teams run into after the OCR step.

Why Non-Latin Documents Are Harder

Each script family creates its own extraction problems.

Arabic

Arabic is written right to left, and letters change shape depending on their position in a word. Short vowels are usually omitted, so one written name can map to several pronunciations. Documents may use Eastern Arabic numerals (٠١٢٣) instead of Western digits. A document can also mix Arabic text with Latin-script numbers or codes on the same line.

Cyrillic

Cyrillic looks deceptively easy because several letters resemble Latin ones: А, В, Е, К, М, Н, О, Р, С, Т, Х. These homoglyphs are a real data-quality risk. A name that looks identical on screen may contain different Unicode code points, so string comparisons and database lookups fail without any visible cause.

Chinese, Japanese and Korean

CJK scripts have very large character sets. Many characters are visually dense, and small differences in strokes change meaning, so image resolution matters more than it does with Latin text. Names are usually written without spaces, which means family name and given name have to be split using field position rather than whitespace. Some older or regional documents also use vertical text.

Transliteration Is Not a Single Answer

Transliteration converts text from one script to another. It is not translation, and it rarely produces one correct output.

The same Arabic name can be romanized as Mohammed, Muhammad or Mohamad. Russian names vary depending on whether a national system, ICAO rules or an older convention was used. Chinese names may appear in Hanyu Pinyin, Wade-Giles or a Cantonese romanization. Japanese names may follow Hepburn or another system. Korean passport holders can often choose their own romanized spelling, so it may not follow the Revised Romanization rules at all.

For identity verification, this means the Latin spelling you generate may not match the Latin spelling on the person's passport, bank record or sanctions entry, even when every system is technically correct.

Use What the Document Already Gives You

Many non-Latin documents already contain an official Latin rendering:

• Passports usually print names in both native script and Latin characters in the visual inspection zone.
• The MRZ uses only A–Z, 0–9 and the < filler. Names there follow ICAO Doc 9303 transliteration guidance or the issuing state's own conventions, and long names may be truncated.
• Barcodes on some cards encode data that can be cross-checked against the printed fields.

When an issuer-provided Latin form exists, treat it as authoritative for that document. Generate your own transliteration only when the document has no Latin version, and label it as derived.

A Data Model That Survives Transliteration

Most problems with non-Latin data come from flattening everything into a single name column. A better approach is to keep each representation and its source:

• Native-script value exactly as read from the document
• Issuer Latin value from the printed Latin field, if present
• MRZ value, as encoded, including any truncation
• Derived transliteration, clearly marked as system-generated
• Source and confidence for each field

Store text as Unicode and normalize it consistently (NFC is a common choice for storage). Use a separate, more aggressive normalization for comparison only. This can include case folding, removing diacritics and mapping homoglyphs, but it should never replace the stored value.

Dates and Numbers Need Conversion Too

Names get most of the attention, but date fields cause their own issues:

• Some documents use the Hijri calendar alongside or instead of Gregorian dates.
• Japanese documents may show years using imperial era names.
• Taiwanese documents may use Minguo (ROC) years, which are offset from the Gregorian calendar.
• Eastern Arabic and Persian digits must be converted before validation or age calculation.

Convert dates to ISO 8601 for business logic, and keep the original printed value alongside the converted one. Cross-check converted dates against the MRZ where one is available. A mismatch can point to an OCR error, a conversion bug or a tampered document.

Matching and Screening Across Scripts

Comparing Fields Within a Document

Comparing data across scripts introduces avoidable noise, so compare like with like. Check the native-script name against other native-script sources, and the Latin name against the MRZ. When you have to compare across scripts, use fuzzy matching with transliteration variants instead of exact string equality.

AML, PEP and Sanctions Screening

Watchlists often include aliases and multiple spellings, and some entries include original-script names. Screen on every representation you hold: native script, issuer Latin and derived transliteration. Screening only one generated spelling increases the risk of missing a true match. Tune your fuzzy-matching thresholds with transliteration variance in mind, and send ambiguous hits to human review rather than auto-clearing them.

Capture Tips That Improve Extraction

• Resolution matters more for CJK. Dense characters need sharper images, so encourage users to fill the frame.
• Watch for glare. Holographic overlays on many national IDs can wash out fine strokes.
• Capture both sides. Native-only fields and barcodes are often on the back.
• Let the document type drive parsing. Field positions, not text direction or spacing, should determine which value is the surname.

Bringing It Together

Reliable non-Latin ID processing depends on accurate OCR, careful storage that keeps native and Latin values separate, sensible date conversion and screening that accounts for spelling variants. ID Analyzer reads 3,000+ document formats from 190+ countries. It combines document OCR with MRZ and barcode reading, so you can capture native-script fields and issuer-provided Latin data together and cross-check them.