When the AMLC tested sanctions screening systems across Philippine financial institutions, the results split into two categories. Systems screening unmanipulated names against watchlists performed well. Systems screening names that had been transliterated, abbreviated, or recorded with common Filipino naming variations dropped to significantly lower match rates. The gap between the two results is where compliance risk lives.
The gap is not a technology problem. It is a configuration problem. Most AML name screening platforms use the same foundational matching techniques: phonetic algorithms, edit-distance scoring, token reordering. The difference between a system that catches a manipulated name and one that misses it is how those techniques are weighted, layered, and tuned for the institution's actual customer base.
This article explains how sanctions screening match logic works, why default configurations fail on Southeast Asian names, and what compliance teams need to configure to close the gap the AMLC found.
How name matching works in sanctions screening
A watchlist screening system compares customer names against entries on designated lists: the AMLC Targeted Financial Sanctions list, UN Security Council consolidated lists under Resolutions 1267/1989, 1988, and 2253 for terrorism financing, Resolutions 1718 and 2231 for proliferation financing, and domestic designations under the Anti-Terrorism Act of 2020.
The comparison is not a simple string match. Names arrive in different scripts, transliteration systems, abbreviation conventions, and ordering patterns. A system that requires an exact match will miss the target it was built to find.
Screening platforms address this through layers of matching logic, each handling a different type of name variation.
Phonetic matching
Phonetic algorithms convert names into sound-based codes so that names pronounced similarly receive the same code regardless of spelling. Soundex, the oldest algorithm, maps English consonant sounds to digits. Metaphone and Double Metaphone extend the approach to handle non-English phonetic patterns.
The limitation is that phonetic algorithms designed for English phonology perform poorly on names from languages with different sound systems. A Tagalog surname that uses "ng" as a single phoneme, or an Arabic name where "al-" is a grammatical prefix rather than part of the root name, will not produce the same phonetic code as the watchlist entry if the algorithm treats them as English letter sequences.
Edit-distance scoring
Edit-distance algorithms measure how many character operations (insertions, deletions, substitutions, transpositions) are needed to transform one string into another. Levenshtein distance is the standard. Jaro-Winkler adds a bonus for strings that share a common prefix, which helps with names where the surname is consistent but given names vary.
Edit distance catches typographical errors and minor spelling variations. It does not handle reordering (given name and surname swapped), omission (a middle name dropped), or structural differences (a compound surname split across two fields).
Token-based matching
Token-based methods break a full name into individual words and compare the tokens independently, regardless of order. This catches the case where "Maria Santos dela Cruz" appears on the watchlist but the customer record reads "dela Cruz, Maria S." Each token is compared separately, and the match score reflects how many tokens align.
Token matching is where compound Filipino surnames create problems. "dela Cruz" is one surname, but a tokeniser that splits on whitespace treats "dela" and "Cruz" as separate units. The token "dela" then matches against every other "dela" prefix in the database, inflating false positives while simultaneously failing to recognise "dela Cruz" as a single unit that must match as a whole.
Transliteration handling
Names originating in non-Latin scripts (Arabic, Chinese, Cyrillic, Thai) arrive in the screening system after transliteration. Transliteration is not standardised. The same Arabic name can be rendered as Mohammed, Muhammad, Mohamed, or Mohamad depending on the transliteration system, the country of origin, and the preference of the document issuer.
A screening system that does not normalise across transliteration variants will miss matches that a human reviewer would catch on sight. Effective systems maintain equivalence tables that map common transliteration variants to a canonical form before the matching algorithms run.
Why default configurations fail on Southeast Asian names
Most sanctions screening platforms ship with matching algorithms tuned for Western European naming conventions: a given name followed by a surname, both drawn from a Latin-script alphabet with predictable phonetic patterns. Southeast Asian names break every one of those assumptions.
Filipino naming patterns
Filipino names combine Spanish-origin compound surnames (dela Cruz, de los Santos, San Juan), Tagalog names with phonemes absent from English (Mangansakan, Dimangadap), Chinese-Filipino surnames (Tan, Sy, Ong, Cojuangco), and Muslim Moro names following Arabic naming conventions (Mama, Guiamadin, Pangandaman). A single customer base in a Philippine bank spans all four patterns.
The "dela Cruz" problem is the most documented. FyscalTech's own analysis found that standard configurations mishandle compound Filipino surnames because the tokeniser cannot distinguish a multi-word surname from a sequence of independent name parts. The result: genuine matches missed, and thousands of false alerts generated on partial token overlaps.
Indonesian and Malay single-name conventions
A significant portion of the Indonesian population uses a single legal name with no surname. Screening systems that require a populated surname field either reject the record, assign a placeholder, or concatenate the single name into the wrong field. Each workaround introduces a different matching failure mode.
Thai transliteration inconsistency
Thai names transliterated into Latin script vary by issuing authority, embassy, and era. The same name can appear in a passport, a bank account, and a watchlist entry in three different Latin spellings. Without a Thai-specific transliteration normalisation layer, the screening system treats each spelling as a distinct identity.
Arabic naming conventions in Mindanao
The Bangsamoro population uses Arabic naming conventions where the father's name, grandfather's name, and clan name may all appear in different orders across documents. A watchlist entry recording "Abubakar bin Ibrahim al-Maguindanao" may not match a customer record reading "Ibrahim Abubakar Maguindanao" under default token-matching rules, even though they refer to the same individual.
What the AMLC expects from your screening programme
The AMLC's thematic review on sanctions screening tested institutions against two scenarios: screening unmanipulated names directly from watchlists, and screening names that had been altered through common variations (transliteration differences, abbreviations, reordering). The second test is the one that matters, because it reflects how names actually appear in customer records.
The review assessed four areas: whether the system generates alerts on unmanipulated watchlist names, whether fuzzy matching catches manipulated variations, how the institution manages false positives, and whether the screening programme meets the regulator's performance expectations.
Institutions are expected to screen against the full set of applicable lists: the AMLC list, UNSC consolidated lists, and domestic designations under the Anti-Terrorism Act. Screening must occur at onboarding and on an ongoing basis as lists are updated. Failures in screening quality feed directly into suspicious transaction reporting obligations when a sanctioned party transacts undetected.
The practical requirement is that the institution's screening system must catch a sanctioned name even when the customer record does not spell it identically to the watchlist entry. That is a configuration requirement, not a procurement one. The system needs to be tuned.
How to tune your screening configuration
Match-score weightings
Every screening platform assigns a score to each potential match based on how closely the customer name aligns with the watchlist entry across multiple fields. The fields typically include name, date of birth, gender, citizenship, and address. Each field carries a weighting that determines its contribution to the overall score.
Default weightings treat all fields equally or over-weight the name field. For a Philippine institution, this creates two problems. First, common surnames (Santos, Reyes, Garcia, Cruz) generate high name-match scores against unrelated individuals, flooding the queue with false positives. Second, supplementary fields that could disambiguate (date of birth, citizenship) are under-weighted, so genuine matches score the same as coincidental name overlaps.
The compliance team, not the vendor, should control these weightings. A system where adjusting match-score fields requires a vendor support ticket and a two-week turnaround is a system where the screening programme is defaulted, not calibrated. Every weighting change should be logged in an auditable trail, because the examiner's question is not just what your thresholds are — it is who set them, when, and on what basis.
Threshold calibration
The match-score threshold determines which potential matches become alerts and which are suppressed. Set the threshold too low and the alert queue fills with false positives that exhaust analyst capacity. Set it too high and genuine matches pass through undetected.
Threshold calibration for name screening follows the same principle as transaction monitoring threshold tuning: test the threshold against known outcomes before applying it to live screening. Run the candidate threshold against historical screening data and measure both detection (did it catch the names it should have caught?) and precision (how many of the alerts it generated were actionable?).
The AMLC expects institutions to demonstrate that their thresholds are calibrated, not arbitrary. A threshold set at 80% because "that is what the vendor recommended" is not a defensible answer in a thematic review.
Delta screening
Batch screening the entire customer base against the full watchlist on a fixed schedule creates two problems. It consumes significant processing time, which means institutions run it infrequently. And it rescreens customers who have already been cleared against entries that have not changed, generating repeat alerts on the same previously resolved matches.
Delta screening solves both problems. Instead of rescreening everything against everything, the system screens the existing customer base against only the new additions and changes to watchlists since the last run. This can be configured to run daily, weekly, or monthly depending on the institution's risk appetite and list-update frequency.
The result is faster screening cycles, fewer repeat alerts, and continuous coverage instead of periodic coverage with gaps between runs.
Handling compound surnames and multi-word names
The compound-surname problem requires specific configuration. The screening system needs rules that recognise multi-word surname patterns ("dela Cruz", "de los Santos", "San Juan") as single units and match them accordingly. Without these rules, the tokeniser splits each compound surname into fragments that generate false matches and miss genuine ones.
Some platforms handle this through a configurable compound-name dictionary. Others use pattern-recognition rules that identify common prefix particles (de, dela, del, de los, San, Santa) and bind them to the following word. The implementation matters less than the outcome: a screening system deployed in the Philippines that cannot correctly match "dela Cruz" has a configuration gap that the AMLC's manipulated-name test is designed to find.
What to look for in your screening platform
The platform matters less than the configuration, but certain platform capabilities make effective configuration possible while their absence makes it impossible.
Real-time screening at onboarding, not batch-only, closes the window where a sanctioned individual can open an account and transact before the first screening run. An API-driven screening call that returns results before the onboarding workflow completes is the standard the industry has moved to.
Configurable match weightings that the compliance team can adjust directly, without filing an engineering ticket, ensure the screening programme reflects the institution's risk assessment rather than the vendor's default. Every adjustment must carry a timestamped audit trail.
Associate linkage that surfaces all linked individuals and entities from the watchlist record within the same alert view means the analyst can assess the full network without leaving the screen. A screening alert that identifies a match but does not show known associates forces research in a separate system, adding minutes to every disposition.
Delta screening at configurable intervals keeps the customer base continuously screened without the processing overhead and false-positive volume of full-list rescreening.
Side-by-side match comparison with per-field confidence scores lets the analyst see exactly which fields contributed to the match and by how much, rather than a single opaque score. This is the explainability the examiner expects.
If you want to see how configurable match weightings, delta screening, and associate linkage work inside a single platform, book a walkthrough of Fyscal ARCX and bring your current screening configuration with you.