UN sanctions list screening Arabic names is a problem that looks solved until a true match slips through. Many engines load each list entry as one concatenated string and compare it with the customer name. That approach works tolerably for names written consistently in Latin script. It fails when the same Arabic name is rendered differently by the UN, OFAC, the EU and local designating authorities. This article explains the four UN Security Council fields your engine should parse and weight separately, and the alias-expansion logic that reduces false negatives without flooding analysts with noise.
Why concatenation fails
A concatenated string mixes a primary name, aliases, identifiers and free-text notes into one block. Fuzzy matching against that block produces two failures. A genuine match scores low because the customer name is compared with a long string rather than with a single name variant. Unrelated customers score high because fragments of different fields happen to overlap.
Arabic adds a further layer. Each regime transliterates independently, so one person may appear as Abd al-Rahman, Abdul Rahman or Abdurrahman, with the definite article attached, detached or dropped. The same applies to an entity. A single designated entity can carry three distinct Latin renderings of its Arabic name across lists, each defensible and none identical. A screening engine that does not model this will treat them as three unrelated strings.
The four fields to parse separately
The UN consolidated list provides structured data. Four fields deserve their own parsing rules and their own weight.
1. Primary name
The primary name is the anchor. Store it as discrete name parts (given name, patronymic, family or tribal name) rather than as a single line. Matching should run at part level first, then at whole-name level. Give the primary name the highest name-based weight, but not an absolute one, because it is only one of several renderings in circulation.
2. Alias
The UN list distinguishes good-quality aliases from low-quality ones. Keep that distinction as a field attribute. A good-quality alias should score close to the primary name. A low-quality alias should still be screened but should raise an alert only when corroborated by a second data point, such as a date of birth or an identifier. Treating all aliases equally is a common cause of false-positive volume.
3. Passport identifier
Passport numbers are exact-match data. Parse them separately, normalize formatting (spaces, hyphens, letter case) and compare them as identifiers, never as fuzzy text. A passport match combined with even a moderate name similarity should escalate, because identifiers do not vary by transliteration.
4. National identifier
National identification numbers are also exact-match data but carry different issuing-country semantics. Store the issuing country alongside the number. This prevents a numeric coincidence between two countries' formats from generating an alert, and it lets a genuine match raise confidence sharply.
Weighting these four fields separately lets identifiers confirm what names only suggest. Names generate candidates; identifiers and corroborating data resolve them.
Alias-expansion logic
Alias expansion generates the variants a name might plausibly take, so that the comparison set reflects real-world spelling. Three techniques do most of the work.
Diacritic and article normalization
Strip diacritics and vowel marks from Arabic script and from Latin renderings that carry them. Normalize common letter forms, for example the different forms of alef and the variants of ya and ta marbuta. In Latin script, treat the definite article as optional and as attachable: al-, el-, Al and the fused form should all resolve to the same token.
Phonetic variants
Arabic consonants without a single Latin equivalent produce predictable spelling families. Examples include the Kh, Gh, Q and K alternatives, and the Sh and Ch choices. Vowel variation such as Mohammed, Muhammad and Mohamed follows the same pattern. Build a maintained variant table, and generate expansions from it rather than relying on a general phonetic algorithm designed for another language.
Name-part reordering
Arabic names are structured with chains such as given name, father's name, and family name, and with prefixes such as Abu, Ibn and Bin. Different lists order and truncate these chains differently. Match at part level regardless of order, and allow omission of middle parts, but require that the distinctive parts match. A shared common given name should not be enough.
Keeping false positives under control
Expansion without discipline multiplies alerts. Four controls help:
- Score by part rarity. A match on a distinctive family name counts for more than a match on a common given name.
- Require corroboration for low-quality aliases and for expansions that are several steps from the source spelling.
- Record which expansion produced each alert, so analysts and testers can see which rules earn their volume.
- Review closed alerts periodically and tune the variant table from confirmed outcomes.
Reconciling the same entity across regimes
Consider a pattern that occurs in practice: an entity designated by OFAC and by the EU, with three different Arabic-to-Latin renderings across the two lists. The correct response is not to screen three unrelated strings. Link the entries into a single logical subject, with a cross-list identifier held in your own data model, and merge the primary names and aliases into one expanded profile. A customer that matches any rendering then resolves to the same subject record, and the analyst sees all the designating regimes together. Saudi local designations should be linked in the same way, so that a decision on one regime is not made without sight of the others.
When to review your screening
Signs that it is time to review:
- The engine loads list entries as a single field.
- Alert tuning is done only by adjusting a global match threshold.
- Analysts report repeated manual searches in alternative spellings.
- Identifier fields are not used in scoring.
- Different lists are screened in separate tools with no linked subject record.
- The last test of screening quality did not include Arabic name variants.
What a good outcome looks like
A well-run program parses the four fields separately, expands aliases from a maintained and documented variant table, links the same subject across UN, OFAC, EU and local lists, and can show evidence of testing against known variants. Alert volumes are explainable, and decisions are traceable for SAMA reviews against its AML/CTF requirements.
How we approach it
Our Sanctions Compliance Program covers the design or review of your sanctions compliance program across UN, local, OFAC and EU regimes, including screening, trade and payment controls, escalation and reporting. We work through four stages: assess, design, test and train.
- Assess: sanctions risk across products and geographies.
- Design: policy, screening coverage and escalation.
- Test: screening quality and control testing.
- Train: front-line and decision-maker training.
For the issues described above, the test stage is where name handling is examined. The deliverables are a sanctions policy and procedures, a screening coverage assessment, control testing results and training for front-line staff. The work runs as a project of 6–12 weeks, and the frameworks are Sanctions, SAMA AML/CTF and Wolfsberg.
Next step
If your engine treats list entries as a single string, or you cannot show how Arabic variants are tested, a screening coverage assessment is a sensible starting point. Speak to us about the Sanctions Compliance Program and we will agree the scope around your products, payment flows and lists.
