AI-Powered AML Screening: How Two-Pass Matching Cuts False Positives by 60–70%

Sanctions and PEP screening generates more false positives than almost any other compliance function. The root cause is not the size of the lists or the volume of customers to screen. It is that the names on those lists do not appear in a single canonical form, and most screening systems match on a single attribute.

Ahmad Al-Rashid, Ahmed El Rashid, and Ahmad Alrashid are the same individual. Keyword-matching logic treats them as three different people and misses the match unless the customer record uses the exact same string that appears on the list. Fuzzy matching improves coverage by catching name variants, but matching on name alone still generates large numbers of false positives: a partial name match on a common Arabic or Chinese name across tens of thousands of customer records produces alerts that consume investigator time without identifying genuine sanctions exposure.

Two-pass AI screening addresses both problems. The first pass casts a wide net using AI-enhanced fuzzy matching that handles name variants, transliterations, aliases, phonetic variations, and incomplete data. The second pass applies deep learning to evaluate multiple attributes together, separating genuine matches from coincidental partial matches. The outcome is 60 to 70 per cent fewer false positives compared with keyword-only screening, with support for 24 languages and 14 scripts.

This guide explains how each pass works, why the two-pass architecture outperforms single-pass approaches, and what the practical difference looks like for a compliance team running a high-volume screening programme.

Why keyword matching fails at scale

Keyword matching compares a customer attribute, typically a name, against the exact string that appears on a watchlist. It works reliably for exact matches and fails for everything else.

The failure modes are predictable. Transliteration from Arabic, Chinese, Cyrillic, or other scripts into Latin characters produces multiple valid romanisations of the same name. A customer whose name was romanised differently on their passport than on the sanctions list will not be flagged. An alias registered at a different point in a designation's history, or a name recorded in a different order between given and family names in different jurisdictions, will produce the same result.

Fuzzy matching solves the name variant problem but introduces a different one: name-only matching on a common name in a large customer base generates false positives at high volume. A bank with 500,000 customers in Malaysia screening against a list that includes a commonly held Malay name will generate hundreds of alerts on that name alone, most of which will not match once other attributes are examined.

Single-pass fuzzy matching also struggles with incomplete data. A customer record with a missing date of birth, an abbreviated name, or an address stored in a non-standard format may not match at the expected confidence level, producing a false negative on a genuine designation.

First pass: AI-enhanced candidate matching

The first pass in FinCense's screening architecture normalises customer information and screens it against current sanctions, PEP, and other configured watchlists. Pre-trained models generate matching thresholds for key attributes including names, addresses, and dates of birth.

AI-enhanced fuzzy matching then identifies plausible candidates despite the common sources of variation: misspellings, phonetic variants, transliteration differences, incomplete records, and formatting inconsistencies. The matching logic is trained on the types of name variation that appear on APAC-relevant sanctions lists, rather than applying generic string-distance algorithms that were not built for the specific transliteration patterns of Arabic, Chinese, or Malay names.

The first pass is intentionally wide. Its purpose is to ensure that no genuine match escapes review by failing on a name variant or a data quality issue. False positives at this stage are expected and handled by the second pass.

Second pass: deep-learning multi-attribute refinement

The second pass is where the false positive reduction happens. Potential matches identified in the first pass are analysed using deep learning and multi-attribute entity resolution.

Rather than evaluating name alone, the model evaluates name, address, date of birth, aliases, and nationality both individually and in relation to each other. A customer whose name is a close match to a designation but whose date of birth, nationality, and country of residence all differ from the designation record will score low on the holistic similarity assessment. A customer whose name is a moderate match but whose date of birth and nationality are consistent with the designation will score higher.

These signals are combined into a single similarity score that reflects the overall probability of a genuine match rather than the strength of a single-attribute comparison. The threshold for generating an alert is applied to this combined score, not to the name match alone.

The practical effect is that the second pass filters out a large proportion of the alerts that single-pass fuzzy matching would have generated, retaining the genuine candidates for investigator review. The result is 60 to 70 per cent fewer false positives compared with keyword-only screening, without reducing coverage of genuine designations.

What two-pass screening delivers in practice

Language and script coverage. FinCense's screening supports 24 languages and 14 scripts. This matters for APAC institutions whose customer bases include names in Arabic, Mandarin, Thai, Vietnamese, Bahasa Malay, and Tagalog, all of which produce transliteration variants when romanised for Latin-character watchlists. Matching logic built only for Latin-character comparison misses a substantial proportion of genuine matches in APAC customer bases.

Incomplete and inconsistent data. Many customer records in live systems contain incomplete address data, abbreviated given names, or date of birth fields left blank during digital onboarding. The first pass is trained to handle these gaps without generating excessive false negatives. The second pass uses the attributes that are present to build the similarity score rather than treating missing fields as automatic disqualifiers.

Reduced investigator workload. A compliance team running keyword-only screening on a customer base of 200,000 may receive hundreds of alerts per screening cycle, the majority of which are dismissed as false positives after manual review. Reducing false positives by 60 to 70 per cent brings that volume to a level the team can work through without creating a backlog that delays response on genuine matches.

Configurable thresholds, auditable decisions. Match sensitivity thresholds in FinCense are configurable per list and per jurisdiction, and every threshold setting is retained in the audit trail. When a regulator asks how the screening programme is calibrated, the compliance team can show the threshold settings, the reason for those settings, and the alert volumes they produced. This is the calibration evidence regulators expect to see, not just the output.

What this means for screening programme design

The move from keyword to two-pass AI screening does not change the lists a compliance programme is required to screen against. It changes the quality of the screening output.

A programme that produces thousands of false positive alerts per cycle creates operational problems that compound over time. Investigators develop shortcuts to manage the volume: alerts dismissed by pattern rather than by individual review, documentation that records dismissal without reasoning, review cycles that extend past the regulatory expectation for timely response. These are the gaps that examinations find.

A programme that produces a manageable, well-prioritised alert queue allows investigators to review each case properly, document their reasoning, and respond within the timeframes regulators expect. The compliance outcome is not just better efficiency; it is a stronger audit trail.

For APAC institutions specifically, the language and script coverage in two-pass screening is not optional. Screening programmes that cannot match across transliteration variants of Arabic, Mandarin, or other APAC-relevant names have a structural gap that keyword-only systems cannot address.

For a breakdown of specific sanctions list requirements across Singapore, Malaysia, and the Philippines, see our guides to sanctions screening under MAS, sanctions screening under BNM and sanctions screening under BSP.

How FinCense implements two-pass screening

FinCense Screening runs the two-pass architecture described above as its baseline configuration. The first pass uses pre-trained models and AI-enhanced fuzzy matching calibrated for the name variation patterns common on APAC-relevant sanctions lists. The second pass applies deep learning and multi-attribute entity resolution to produce a holistic similarity score for each candidate match.

List coverage is configurable by institution and by transaction type. MAS TFS, BNM TFS, AMLC, OFAC, UN Security Council lists, EU consolidated lists, and additional sources can be applied based on the institution's payment corridors and customer profile. List updates are incorporated automatically on publication, without manual intervention.

Match thresholds are configurable and documented per jurisdiction, so each regulator's examination team sees a screening programme calibrated for their specific requirements. Alert history, false positive documentation, freeze decisions, and regulatory report workflows are managed in a single case management environment connected to the screening output.

FinCense screens at the transaction level in real time before settlement, satisfying the real-time screening requirements of MAS, BNM, BSP, and AUSTRAC for payment providers and banks. The screening API operates at under 350 milliseconds at the 99th percentile with sustained throughput of 50 transactions per second at peak.

For a broader look at how AI operates across the full FinCense platform, see our guide to what AI-native AML means. To see how FinCense handles screening for your institution, book a demo with our team.

Frequently asked questions

What is two-pass AML screening?

Two-pass screening uses two sequential AI steps to identify genuine sanctions and PEP matches while reducing false positives. The first pass casts a wide net using AI-enhanced fuzzy matching to identify all plausible candidates despite name variants, transliterations, aliases, and incomplete data. The second pass applies deep learning and multi-attribute entity resolution to evaluate all available attributes together, producing a holistic similarity score that separates genuine matches from coincidental partial matches.

Why does keyword-only screening generate so many false positives?

Keyword matching compares customer attributes against exact strings on a watchlist. It fails when names appear in variant forms: different transliterations, name order differences between jurisdictions, aliases, misspellings, and phonetic variants. Fuzzy matching improves coverage but still generates high false positive volumes when matching on name alone in large customer bases with common names. Two-pass screening resolves this by evaluating multiple attributes together rather than relying on name matching alone.

What languages and scripts does AI screening support?

FinCense Screening supports 24 languages and 14 scripts. This covers the major APAC-relevant languages including Arabic, Mandarin, Malay, Thai, Vietnamese, and Tagalog, as well as their romanised variants. Name matching logic is trained for the transliteration patterns that appear on APAC-relevant sanctions lists rather than applying generic string-distance algorithms.

What is the false positive reduction from two-pass screening?

FinCense's two-pass architecture reduces false positives by 60 to 70 per cent compared with keyword-only screening. This brings alert volumes in high-volume customer bases to a level that compliance teams can review properly, with sufficient time to document each decision.

Does AI screening still satisfy real-time requirements under MAS, BNM, and AUSTRAC?

Yes. FinCense Screening operates as a real-time API call at the point of transaction initiation, returning a result before the payment is released. The API operates at under 350 milliseconds at the 99th percentile with sustained throughput of 50 transactions per second. This satisfies the real-time screening requirements of MAS, BNM, BSP, and AUSTRAC for payment providers and banks.

How are screening thresholds documented for regulators?

Match sensitivity thresholds in FinCense are configurable per list and per jurisdiction and are retained in the audit trail with version history. When a regulator examines the screening programme, the compliance team can show the current threshold settings, the date and reason for each change, and the alert volumes those settings produced. This provides the calibration evidence regulators expect to see rather than just a summary of outputs.