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 token | Forms seen in production data |
|---|---|
| MUHAMMAD | Mohammad, Mohammed, Muhammad, Muhammed, Mohamad, Mohamed, Mohd, Muhamad |
| ABD | Abdul, Abdel, Abdal, Abd al, Abd el, Abdool |
| BIN | bin, ibn, bn, b. |
| AHMAD | Ahmad, Ahmed, Ahmet |
| HUSAYN | Hussein, Hussain, Husain, Husayn, Hossein |
| YUSUF | Youssef, 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:
- Transliteration folding — known spelling families collapse to a canonical token (all six forms of "Muhammad" → MUHAMMAD).
- Diacritic stripping — with a precomposed map, so ʿayn and hamza never split an identity in two.
- Corporate noise removal — "Falcon Trading LLC" and "Falcon Trading FZE" compare on the stem; suffixes carry no identity signal.
- 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.
// 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 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.