Arabic Name Matching in Sanctions Screening

Ask a compliance analyst in Riyadh what slows their queue down and the answer is rarely "missing lists". It is names. The customer's passport says one thing, the bank record says another, and the sanctions entry says a third. All three describe the same man.

Take محمد عبدالله أحمد. On a passport it might read Mohammed Abdullah Ahmed. A remittance form typed by a teller could say Mohamad Abdalla Ahmad. A list entry built from a foreign intelligence file might hold Muhammad Abd Allah Ahmed. Exact matching sees three different people. A careless fuzzy matcher sees all three and also a hundred other Mohammeds.

Where the variation comes from

There is no single transliteration standard that everyone uses. Governments, banks, and list publishers each made their own choices, and they made them decades apart.

• Vowels: Arabic short vowels are usually not written, so محمد becomes Mohammed, Muhammad, Mohamad, or Mohamed depending on who heard it.
• The definite article: ال shows up as Al-, Al, El, al-, or attached with no space at all.
• Compound names: عبدالله can be one token (Abdullah) or two (Abd Allah), and the same goes for عبدالرحمن and عبدالعزيز.
• Lineage words: بن and ابن are written Bin, Ben, Ibn, or dropped.
• Name length and order: a full Saudi name chain carries the given name, father, grandfather, and family. Forms cut it at two or three parts and sometimes put the family name first.

None of this is exotic. It is the normal state of the data, and screening has to be built for it.

Why tuning the threshold doesn't fix it

The usual first reaction to missed matches is to lower the match threshold. That works for about a week. The queue fills with every Ahmed Mohammed in the country, analysts start clearing alerts in bulk, and the real hit gets cleared with the rest.

The fix is to make the comparison smarter, not looser. Normalize both sides before comparing: strip the article, collapse compound names, map the common vowel spellings to one form, and compare the parts of the name independently of order. Then score the candidate on the name and on everything else you know.

Let the other fields do the work

Name matching gets you a shortlist. Date of birth, nationality, and the full name chain decide what stays on it.

A strong name match with a different birth date and nationality is usually a namesake, so it scores low and lands at the bottom of the queue. To clear it, compare the full record: aliases, every recorded birth date, nationalities, and document numbers, and keep the evidence behind the decision. The same name with a matching birth date and nationality goes to the top and gets a person's attention today.

This is why we push teams to send everything they have on the screening call. A request with only inputName forces the engine to decide on the name alone. Add inputDob and inputNationality and most of the noise disappears without touching the threshold.

Screen the full chain, not two parts

If your KYC provider returns the full four-part name, screen the full four-part name. Cutting it to first and last name throws away exactly the information that separates two cousins with the same given and family names. Store the full chain on the customer record so ongoing re-screening uses it too.

What to check in your own setup

• Do you send date of birth and nationality on every screening call?
• Do you screen the full name chain, or a truncated version?
• Can your engine match Arabic script directly when a customer enters their name in Arabic?
• What share of REVIEW results turned out to be real last month? If it is close to zero, the matching is loose. If it is high but analysts take days, the evidence on screen is not good enough.

Naiza matches across Arabic script and the common Latin spellings and scores candidates on the supporting fields, so this works without pre-processing on your side. The AML screening API page shows the request and response, and the name transliteration entry covers the terminology.