Sanctions screening validation Saudi Arabia has become a priority for compliance heads at banks and payment firms since the Saudi Central Bank (SAMA) began scrutinizing not just whether institutions screen, but whether their screening tools actually catch what they are supposed to catch. A name-screening platform that looks robust in a vendor demonstration can fail quietly in production when confronted with the realities of Arabic-English transliteration, diacritics and the name-order conventions that appear across UN, OFAC, EU and UK sanctions lists.
Three recent validation engagements at Riyadh-based banks revealed a consistent pattern: screening tools configured with default fuzzy-matching thresholds missed between eighteen and twenty-two percent of exact name matches when those names appeared in transliterated forms, contained diacritical marks or followed non-Western name-order conventions. The tools were running. Alerts were being generated. But a material portion of true positives never surfaced because the matching logic had not been tuned to the linguistic and structural characteristics of the data flowing through Saudi payment rails.
This article describes the three most common validation findings in sanctions-screening engagements at Saudi financial institutions, the four fuzzy-matching parameters that compliance teams should test, and the data-quality checks to run before the next SAMA AML inspection.
The Three Validation Findings That Recur Across Saudi Banks
Finding One: Transliteration Variants Defeat Exact-Match Logic
A customer name arrives in Arabic script. The sanctions list entry exists in Latin script, transliterated by the UN or OFAC according to their respective conventions. The screening tool compares the two and finds no match because the institution's core banking system applies a different transliteration standard—or none at all, relying instead on whatever the customer typed into the account-opening form.
In one engagement at a retail bank, validation testing revealed that names containing the Arabic letters ع (ayn) and ح (ha) were transliterated inconsistently. The core banking system rendered محمد as "Mohamad" while the OFAC list used "Muhammad". The screening tool, set to exact-match mode with a fuzzy threshold of eighty-five percent, returned no alert. When the threshold was lowered to seventy-five percent and phonetic matching was enabled, the tool flagged the entry.
The pattern is not confined to one letter or one list. OFAC, the UN Security Council, the EU and the UK Treasury each apply different transliteration conventions. A single Arabic name may appear in four different Latin forms across four lists. If the screening tool relies on exact string matching or a narrow fuzzy threshold, it will miss three of the four.
Finding Two: Diacritics and Special Characters Break String Comparison
Sanctions lists published by European authorities often retain diacritical marks: é, ñ, ü. Payment messages arriving via SWIFT or domestic rails may strip these marks, either because the originating system does not support extended character sets or because an intermediary gateway normalizes the text to basic ASCII.
Validation testing at a commercial bank showed that names containing diacritics were stored in the core system without those marks, while the screening vendor's list feed preserved them. The tool's matching engine treated "José" and "Jose" as distinct strings. The fuzzy-matching algorithm assigned a similarity score of ninety-two percent—just below the configured threshold of ninety-five percent—so no alert was raised.
The fix required two steps: enabling diacritic normalization in the screening tool's pre-processing layer, and lowering the threshold to ninety percent. After tuning, the tool correctly flagged all test cases.
Finding Three: Name-Order Variations Across Cultural Conventions
Western sanctions lists typically follow a given-name-then-family-name order. Arabic naming conventions layer a given name, father's name, grandfather's name and family name. Asian conventions may place the family name first. When a payment message or account record presents a name in one order and the sanctions list uses another, string-matching algorithms struggle.
A payment firm discovered during validation that its screening tool missed matches when the customer name was stored as "Ahmed Ali Mohammed Al-Farsi" but the UN list entry read "Al-Farsi, Ahmed Ali Mohammed". The tool's fuzzy-matching logic calculated similarity on the full string, and the transposition of the family name to the front dropped the score below threshold.
The solution involved enabling token-based matching, which breaks the name into individual tokens and compares subsets, and adjusting the threshold to account for partial matches. After tuning, the tool flagged the entry.
The Four Fuzzy-Matching Parameters to Test
Compliance teams responsible for sanctions-screening platforms should validate the following parameters, using a representative sample of names drawn from actual transaction data and the full set of sanctions lists the institution is required to screen against.
1. String Similarity Threshold
Most screening tools express fuzzy matching as a percentage: how similar must two strings be to trigger an alert? A threshold of one hundred percent means exact match only. Ninety percent allows minor differences. Seventy percent casts a wider net but generates more false positives.
The correct threshold depends on the quality of the data in your core systems and the transliteration conventions in your sanctions lists. Validation should test thresholds at five-percentage-point intervals—ninety-five, ninety, eighty-five, eighty, seventy-five—and measure both the true-positive rate (how many known matches were caught) and the false-positive rate (how many alerts were noise).
2. Phonetic Matching Algorithm
Phonetic algorithms such as Soundex, Metaphone and Double Metaphone convert names into phonetic codes, so that "Muhammad" and "Mohamad" produce the same code and match even if the strings differ. Not all screening tools support phonetic matching, and those that do may offer multiple algorithms.
Validation should enable phonetic matching, run the same test set and compare results. In the retail-bank engagement mentioned earlier, enabling Double Metaphone increased true positives by fourteen percentage points without materially increasing false positives.
3. Diacritic Normalization
This parameter controls whether the tool strips or preserves diacritical marks before comparison. Enabling normalization ensures that "José" and "Jose" are treated as identical.
Validation should test with normalization on and off. In every engagement where diacritics were present in either the source data or the sanctions lists, enabling normalization improved match rates.
4. Token-Based vs. Full-String Matching
Token-based matching splits a name into individual words and compares subsets. Full-string matching compares the entire name as a single unit. Token-based matching is more resilient to name-order variations but may increase false positives if common tokens (such as "Mohammed" or "Ali") appear frequently.
Validation should compare both modes and measure the trade-off. In the payment-firm engagement, switching to token-based matching and lowering the threshold to eighty percent captured all name-order variations in the test set, while the false-positive rate rose by twelve percent—a trade-off the compliance team accepted.
Data-Quality Checks to Run Before SAMA Walks In
Fuzzy-matching parameters matter only if the underlying data is fit for purpose. Validation engagements routinely uncover data-quality issues that undermine screening effectiveness.
Completeness: Are all customer names populated in the fields the screening tool reads? In one engagement, fifteen percent of account records had the customer name in a free-text "remarks" field that the screening tool did not ingest.
Consistency: Are names stored in a standard format, or does format vary by branch, by onboarding channel or by customer type? Retail customers onboarded through mobile apps often have names in a different structure than corporate customers onboarded through relationship managers.
Character encoding: Are Arabic names stored in Unicode, or has an older system converted them to a legacy encoding that the screening tool cannot parse? One bank discovered that names containing certain Arabic letters were corrupted during migration from a legacy core system.
List coverage: Does the screening tool ingest all the sanctions lists your institution is required to screen against? SAMA's AML/CTF rules require screening against lists designated by the UN Security Council, and many Saudi banks also screen against OFAC, the EU and the UK. Validation should confirm that the tool's list feed includes all required sources and that updates are applied promptly.
What SAMA Expects During an AML Inspection
SAMA's supervisory approach to AML and sanctions compliance has matured. Inspectors now ask not only whether a screening tool is in place, but whether the institution has validated its performance. They review validation reports, tuning documentation and evidence that thresholds have been set based on testing rather than vendor defaults.
The Financial Action Task Force (FATF) standards, which inform SAMA's requirements, emphasize the effectiveness of controls, not merely their existence. A screening tool that generates alerts is not effective if it misses a fifth of true matches because no one tested the fuzzy-matching logic against the institution's actual data.
Compliance heads should be prepared to demonstrate:
- That the screening tool has been validated within the past twelve months.
- That validation included testing of fuzzy-matching parameters, transliteration handling and name-order variations.
- That thresholds have been tuned based on evidence, and that the tuning rationale is documented.
- That data-quality issues identified during validation have been remediated or are subject to a documented action plan.
How Independent Validation Works
Independent validation of transaction monitoring scenarios and name-screening tools examines data quality, thresholds, fuzzy-matching performance and coverage of the institution's risk assessment, with the goal of proving that monitoring and screening actually work.
The process includes data lineage and completeness testing, scenarios mapped to the institution's risk assessment, threshold and matching-quality testing, and model governance documentation. Validation is delivered as a project over six to ten weeks.
Deliverables include a validation report, tuning recommendations with evidence, and a model inventory and governance pack. The engagement covers data lineage and completeness testing, threshold and scenario tuning, screening match-quality testing, and model governance documentation, aligned to SAMA AML/CTF requirements, FATF standards and sanctions frameworks.
Validation work is conducted on extracts in the client's environment or a secure copy; data never leaves the institution's control. Validation includes evidence-based tuning recommendations, and implementation support is available.
If your institution has not validated its sanctions-screening tool in the past year, or if you have questions about the fuzzy-matching parameters your vendor has configured, now is the time to test before the next inspection cycle.
