How to Store and Match Arabic Names in KYC Systems

A customer can present one Arabic name in several legitimate forms: the Arabic text printed on the document, an issuer-provided Latin rendering, a machine-readable zone (MRZ) value, and the spelling entered in an onboarding form. Treating one of those strings as the single "correct" name creates false mismatches and hides useful evidence.

The safer design preserves each source representation, derives comparison keys separately, and uses name similarity to find candidates rather than approve or reject a person. This guide is practical engineering information, not legal advice. Country, sector, and risk requirements still need local compliance review.

Cover and infographic: original SultanByte artwork.

One document can contain several valid name records

FATF Recommendation 10 requires financial institutions to identify customers and verify identity using reliable, independent source documents, data, or information. It does not define an Arabic matching algorithm or a universal similarity threshold.

A passport illustrates the gap between that objective and the strings an application receives. ICAO Doc 9303, Part 3 distinguishes the visual inspection zone from the MRZ. When mandatory information appears in a national script, the document also needs a Latin-character transcription or transliteration. The MRZ has tighter character and length rules, uses < as a separator, and may not preserve the full visual-zone name.

ICAO's informative Arabic appendix makes the engineering problem concrete: phonetic transcription can produce several Latin renderings for the same Arabic name. That does not make the issuer's Latin field optional. If the authority supplied one, store it as evidence. A library-generated transliteration is a search aid, not a replacement.

The onboarding form adds another representation. A customer may type the familiar English spelling used by an employer or bank, copy the Arabic value from a digital document, or omit optional marks and spacing. The job is to connect these records without pretending they are interchangeable.

Store evidence before deriving keys

Do not collapse every representation into first_name, middle_name, and last_name. Those fields assume semantics that the source may not provide. ICAO uses primary and secondary identifiers for travel documents; another authority or provider may expose different components.

A useful record keeps the source value and its provenance:

name_representation
- value_verbatim
- script
- source_field          # viz_native, viz_latin, mrz_raw, form_entry
- source_document_id
- component_role        # only when the source supplies it
- capture_method        # NFC, OCR, manual entry
- capture_confidence
- observed_at

name_comparison_key
- representation_id
- profile_id
- profile_version
- transformed_value
- transformations_applied

capture_confidence describes how well the system read the field. It is not confidence that two identities match. Keep those concepts separate.

Retain the exact source string, the raw MRZ, and parsed MRZ components. Store aliases or historical names as typed relationships with their own evidence. If an OCR result is uncertain, keep the document image and route the field for review rather than allowing the guessed text to overwrite the record.

This extends the same rule used for ordinary Arabic text input: the original value and comparison form have different jobs. KYC adds document provenance and a decision trail.

Unicode normalization does not settle identity

Unicode Standard Annex #15 defines normalization forms that give canonically equivalent text a consistent binary representation. NFC is a sensible exact-comparison layer for inputs that differ only because one uses a precomposed character and the other uses a base character plus combining mark.

That is useful, but narrow. NFC does not say that أ and ا identify the same person. It does not equate ى with ي, ة with ه, or one Latin transcription with another. Those are retrieval choices with collision costs.

NFKC applies compatibility mappings and can remove distinctions that NFC keeps. Do not destructively apply it to the authoritative name. If a product uses NFKC or broader Arabic folding for candidate retrieval, keep the output as a versioned feature and record which transformations ran.

The same caution applies to diacritics, tatweel, punctuation, spaces, and common name particles. A marks-insensitive or spacing-insensitive key may improve recall. It can also bring unrelated customers into the same candidate set. Preserve the source, measure collisions, and make each transform independently testable.

Unicode Technical Standard #39 provides mechanisms for detecting confusable and mixed-script identifiers. Those checks can flag unexpected characters or direction controls in an input. They cannot prove fraud or identity. Treat the result as a review signal, and version any generated skeletons because Unicode data changes across releases.

Build a feature pipeline, not one magic score

A production matcher should expose how it found a candidate. One workable sequence is:

1. Validate encoding and identify unexpected controls or script mixtures.
2. Compare raw values and NFC forms exactly.
3. Generate narrowly scoped features for marks, tatweel, punctuation, and spacing.
4. Link the document's own Arabic, Latin, and MRZ representations.
5. Run optional fuzzy retrieval against the candidate set.
6. Compare independent attributes such as document number, date of birth, and issuing source.
7. Approve, reject for a separately supported reason, or send the case to review.

Name similarity belongs in the retrieval stage. The OFAC Sanctions List Search documentation is a useful example of this boundary: fuzzy logic applies to the name field, while other fields use character matching. OFAC says its score expresses name similarity, not a complete identity decision. Its public tool uses Jaro-Winkler and Soundex, but that implementation is not an Arabic KYC standard and its thresholds should not be copied into onboarding.

Keep per-feature output instead of flattening everything into an unexplained 87% match. A reviewer needs to know whether a candidate appeared because of canonical Unicode equivalence, a document-linked Latin value, spacing removal, fuzzy similarity, or a broad spelling rule.

A strong name match with a conflicting document number is different from a weaker name match supported by the same issuer, date of birth, and document. The decision layer should represent that difference.

Arabic-name KYC decision flow. Sources: FATF Recommendations; ICAO Doc 9303 Part 3, 8th edition (2021); Unicode UAX #15; NIST SP 800-63A-4. Original SultanByte infographic.

Give reviewers the evidence, not a red button

NIST SP 800-63A-4 separates identity resolution, evidence validation, attribute validation, and verification that an applicant owns the presented evidence. It also requires documented exception and redress procedures in its US federal context. Those categories provide a useful process model even where NIST is not the governing rule.

A reviewer screen should show the Arabic source in correct right-to-left rendering, the issuer's Latin field, raw and parsed MRZ values, and the customer's entry. Highlight differences by token and code point. Show which transformations produced the candidate, along with corroborating and conflicting fields.

Require a reason code, a short rationale, the policy version, and the evidence viewed. High-impact ambiguity may need an Arabic-capable second reviewer. Customers also need a route to correct capture errors or provide name-change evidence. Human review without tooling, quality sampling, and redress simply moves the hidden rules from code into an operator's judgment.

Do not infer nationality, religion, gender, or language from a name or script. Arabic script is used beyond Arab countries, and people choose different Latin spellings for legitimate reasons.

Test each transformation as a separate product decision

Use synthetic fixtures or properly governed historical cases. Each transform needs positive examples, collision cases, and regression tests across matcher versions.

Start with cases such as:

• canonically equivalent sequences that should meet at the NFC exact layer;
• text with and without harakat, where the original marks remain stored;
• a tatweel-insensitive candidate that records the transform;
• احمد and أحمد, which are not canonically equivalent;
• علي and على, which must not be globally substituted;
• فاطمة and فاطمه, where a spelling feature may suggest review but not equality;
• عبد الرحمن and عبدالرحمن, where spacing affects candidate retrieval;
• a full Latin visual-zone value beside an uppercase, separated, or truncated MRZ value;
• a mixed-script name containing an unexpected Latin character or direction control;
• two different customers with the same normalized Arabic and Latin name.

Measure more than aggregate accuracy. Track candidate recall, collision rate after each transform, false-positive review volume, false negatives from labelled cases, reviewer agreement, overturns, and outcomes by script, document type, capture channel, and matcher version.

Before changing a profile, run the old and new versions against the same corpus. Inspect which candidates appeared or disappeared and why. A rule that improves recall can still be a bad release if it floods reviewers or merges common names.

Preserve the name, explain the comparison

An Arabic-capable KYC system does not need a fictional regional matching rule. It needs a clean separation between evidence, derived features, and decisions.

Keep the strings the authority and customer supplied. Normalize only for a named purpose. Use fuzzy methods to retrieve candidates, then corroborate with independent evidence. When the system is uncertain, make the uncertainty visible to a trained reviewer and record how the case was resolved.

That design is slower to sketch than one canonical name column and a percentage score. It is far easier to audit when two spellings refer to the same person, or when one spelling unexpectedly refers to two people.