Home/Blog/Six Spellings

The Six Spellings Problem: Why Exact-Match Screening Fails in the Gulf

One man, six ways to write his name — and the screening system flagged none of them. The transliteration gap is the region's largest source of false negatives, and fixing it changes everything downstream.

It started with a name. A remittance customer — let's call him Salem — had banked with the firm for four years. His account funded a series of transfers to a counterparty who, it turned out, appeared on a sanctions list. When the compliance team ran the screening, the vendor's system returned no hit. The reason wasn't a missing list, a licensing problem, or a data pipeline failure. The reason was spelling.

The transaction record said "MOHAMMED ABDULLA". The watchlist said "MUHAMMAD ABDALLAH". To an exact-match engine, those are different people. To anyone who has worked in this region for a week, they are the same name, transliterated.

Six spellings, one identity

Arabic names written in Latin script have no single standard. The same given name arrives in six, sometimes eight forms depending on the passport, the bank's system, the remitter's handwriting and the year the record was created:

Canonical tokenForms seen in production data
MUHAMMADMohammad, Mohammed, Muhammad, Muhammed, Mohamad, Mohamed, Mohd, Muhamad
ABDAbdul, Abdel, Abdal, Abd al, Abd el, Abdool
BINbin, ibn, bn, b.
AHMADAhmad, Ahmed, Ahmet
HUSAYNHussein, Hussain, Husain, Husayn, Hossein
YUSUFYoussef, Yousef, Yusuf, Yousuf, Yusif

Watchlists are worse. A list maintained in one jurisdiction might carry "ABD AL-RAHMAN"; a bank in another writes "Abdulrahman". Diacritics flicker in and out: ʿ and ʼ are dropped, doubled or swapped for apostrophes. None of this is an edge case. In Gulf transaction data, the majority of Arabic-derived names have at least one variant in the wild.

Why fuzzy matching alone doesn't fix it

The naive answer is "just use fuzzy matching". Levenshtein distance will happily tell you that "MOHAMMED" and "MUHAMMAD" are similar — and that "Delta Marine Supplies" and "Meridian Shell Holdings" are also similar, because they share the shape of a string. That's how you get a queue full of nonsense: the system becomes permissive enough to catch variants, and noisy enough to drown the analyst.

The fix is to do the normalisation before comparing, and to do it with knowledge of the language, not just the alphabet:

  1. Transliteration folding — known spelling families collapse to a canonical token (all six forms of "Muhammad" → MUHAMMAD).
  2. Diacritic stripping — with a precomposed map, so ʿayn and hamza never split an identity in two.
  3. Corporate noise removal — "Falcon Trading LLC" and "Falcon Trading FZE" compare on the stem; suffixes carry no identity signal.
  4. Internal-descriptor filtering — cash tills, payroll files and card settlements are booking metadata, not parties. Screening them is pure false-positive generation.

Then — and only then — the similarity pass runs, with two complementary matchers: Jaro–Winkler, which is strong on the transpositions and shared prefixes that misspelled names actually exhibit, and token-set matching, which handles reordering ("SALEM AL FARSI" vs "AL FARSI SALEM MOHAMMED") and partial names.

engine excerpt · transliteration map
// The single largest source of Gulf-region false positives, handled up front.
MZ.TRANSLIT = [
  [/\b(mohammad|mohammed|muhammad|muhammed|mohamad|mohamed|mohd|muhamad)\b/g, 'MUHAMMAD'],
  [/\b(abdul|abdel|abdal|abd al|abd el|abd|abdool)\b/g, 'ABD'],
  [/\b(bin|ibn|b\.|bn)\b/g, 'BIN'],
  [/\b(ahmad|ahmed|ahmet)\b/g, 'AHMAD'],
  [/\b(hussein|hussain|husain|husayn|hossein)\b/g, 'HUSAYN'],
  [/\b(youssef|yousef|yusuf|yousuf|yusif)\b/g, 'YUSUF'],
  // …
];

And the guard that keeps it honest

Normalisation makes the engine permissive. A distinctiveness guard keeps it honest. A high similarity score built only from generic vocabulary — "trading", "marine", "holdings" — is an artefact of common words, not evidence of identity. If two names share no distinctive token, the score is suppressed. If they share all of them, it is boosted. The analyst sees which case it was, in the file, every time.

The balance, literally. Mizan — ميزان — means the balance. The engine weighs recall against precision the way a scale weighs evidence: too far one way and you miss the sanctioned counterparty; too far the other and the queue drowns. Both failures cost money; only one shows up in the press.

The outcome for the customer in the opening story: once the engine canonicalised before comparing, the name matched at a score of 91 against the watchlist entry — and the account's transfer history, re-read with that lens, showed a structuring pattern that had been sitting in plain sight for four years.

Try it yourself

On our product page there is a live playground running this exact logic in your browser. Type "Mohammed Abdulla" and "MUHAMMAD ABDALLAH" — then try "Delta Marine Supplies" vs "Meridian Shell Holdings" and watch the distinctiveness guard do its work. No account, no data leaves your machine.

LA
Layla Al-Haddad
Co-founder · CTO

Built name-matching research at a Gulf central bank before founding Mizan. Wrote the first version of the transliteration engine on a weekend and has been defending it to regulators ever since.

free 14-day trial

Run your own data through it.

Upload a sample of your transaction file. Watch what your queue looks like when names are read instead of compared.