AML/CFT Sanctions Engine: Real-Time Screening + 60% False-Positive Cut Across Six Markets

Designed and shipped the AML/CFT sanctions and PEP screening engine for a regulated fintech operating cross-border across six MENA + South Asia markets. Replaced legacy batch-only screening with a real-time pre-send blocking layer + daily batch re-screen + monthly residual re-screen architecture. Tuned per-corridor false-positive rates, cut overall false-positive rate by ~60% while maintaining 100% true-positive coverage. Cleared two long-running regulator observations and earned a commendation in the most recent supervisory cycle. Tier-1 analyst throughput nearly tripled because the alert quality improved and routine name-collision FPs were auto-dismissed under documented controls.

The platform was screening sanctions and PEP lists in a daily batch, every transaction was potentially exposed for up to 24 hours before being checked against the latest list updates. Two market regulators had open observations on screening cadence; one had warned that the observation would escalate at the next supervisory visit. False-positive rates ran ~38%, half the alert queue was Arabic-to-Latin transliteration collisions, common Pakistani / Indian / Bangladeshi name overlaps, and stale per-country list entries that had not been tuned for the platform's actual merchant and consumer mix. Tier-1 analysts were processing ~35 alerts per day per analyst and the queue was growing; tier-2 escalations were taking 8-12 days to close. Six markets, three sponsor banks, two scheme partners, and the legal team were all asking different questions about screening posture.

• Real-time screening service: pre-send blocking call with p95 latency < 180ms; cached per-list results with appropriate TTLs (24h for sanctions, 1h for in-flight regulatory updates)
• Daily batch re-screen pipeline: every prior-day transaction re-screened against latest list updates; daily reconciliation against real-time results to catch list-delta hits
• Monthly residual re-screen: dormant counterparty records and merchant accounts re-screened on a rolling 30-day cycle
• Per-corridor tuning rules: market-aware name-matching thresholds (Arabic transliteration variants, Bengali script variants, Urdu script variants), per-corridor common-name suppression with documented controls
• Lists integrated: OFAC, EU consolidated, UK HMT, UN, GCC, per-country central-bank lists (CBUAE / SAMA / SBP / BB / CBE / CBI), WorldCheck + Dow Jones for PEP and adverse media
• Audit pipeline: every screening event logged with input, list version, matching result, analyst decision, list change since last screening; queryable per merchant, per regulator inquiry
• Analyst case-management surface: alert detail with all matching identifiers, prior decisions on similar cases, suggested triage based on cross-document consistency
• Per-list update ingestion: automated polling + parsing of OFAC SDN updates, EU consolidated list, UK HMT updates, UN designations, plus per-country list updates with manual review on format changes

• Screening service is a synchronous pre-send call on every transaction initiation; cached per-counterparty for 24h with explicit invalidation on list update
• Cache invalidation propagates within 60 seconds of a list update; pre-send latency budget includes the worst-case uncached call
• Per-corridor matching rules run as overlays on top of base name-matching scores, they can suppress likely-FP alerts (with documented controls) but cannot increase the score
• Audit log is the system of record; every screening event is keyed on (transaction ID, list version, decision) for regulator-facing replay
• List update ingestion is monitored on three dimensions: cadence (have we received the expected updates), format (did the list arrive in the expected shape), content (did the list contain the expected size and structure)
• Failure mode: if the real-time screening service is down, the platform fails closed, transactions are held for batch screening rather than passing un-screened

• Daily screening health review: alerts produced, alerts dismissed, alerts escalated, list-update freshness, real-time service uptime
• Weekly per-market tuning review: false-positive rate by market, by corridor, by name-script; suppression rule additions reviewed by senior analyst + audit team
• Monthly per-list audit: list update receipt evidence, format change handling, per-list match coverage
• Quarterly regulator-facing screening report: market-by-market alert volume, FP rate, true-positive disposition, list coverage attestation
• Annual external audit: full screening pipeline review with independent assessor

Owned the AML/CFT screening programme end-to-end, real-time service architecture, list integration, per-corridor tuning, analyst-tooling design, regulator-facing audit posture, and the change-control governance for matching-rule updates. Direct accountability for sanctions screening true-positive coverage, false-positive rate, regulator observation closure, and analyst throughput.

• Shipped real-time pre-send sanctions blocking across six markets with p95 latency below 180ms
• Cut overall sanctions false-positive rate by ~60%, from 38% of alerts being name-collision FPs to 14%
• Maintained 100% true-positive coverage, every sanctions hit that should have been caught was caught
• Cleared two long-running regulator observations on screening cadence
• Earned commendation in the most recent supervisory cycle for the per-corridor tuning evidence and the audit trail quality
• Lifted tier-1 analyst throughput from ~35 alerts/day to ~95 alerts/day per analyst
• Cut tier-2 escalation cycle time from 8-12 days to 3-5 days

• Chose real-time pre-send blocking over async screen-and-allow, added 100-200ms to the send latency budget; produced the regulator-facing posture that closed two open observations
• Built per-corridor suppression rules with explicit controls + audit, heavier governance overhead than a portfolio-wide tuning would carry; produced the false-positive rate cut without lowering coverage
• Integrated 8+ lists rather than relying on a single consolidated vendor list, more list-ingestion engineering; tighter regulator posture (every market regulator could verify their list was specifically integrated)
• Built fail-closed for real-time screening downtime, accepted that brief screening-service outages would degrade transaction throughput; protected against the alternative (transactions passing un-screened during the outage)

• Sanctions screening tuning is a continuous product job, not a configuration. Per-corridor false-positive rates diverge fast and must be re-tuned at least monthly.
• Real-time pre-send screening is non-negotiable for regulators in 2025. Batch-only screening reads as outdated in any supervisory cycle; the regulator's first question is 'how quickly are you blocked'.
• Per-corridor suppression rules need explicit controls: any rule that lowers false-positive rate must be defensible in the next regulator visit. Audit-trail governance on suppression is the part most teams miss.
• Tier-1 analyst throughput is the real lever. Better alert quality (lower FP rate) lifts throughput more than tooling improvements; both together is multiplicative.
• List ingestion monitoring is the under-invested guard rail. A list update that arrived in a new format on a Friday afternoon and silently failed to ingest is how sanctions hits get missed.

Sanctions and PEP screening is the single highest-risk surface in regulated payments operations. The teams that ship it well, real-time pre-send blocking, per-corridor tuning, list-update monitoring, regulator-facing audit posture, close regulator observations and earn the standing that justifies operating across multiple markets. The teams that ship it badly carry observations that escalate through the supervisory cycle until they cost the licence. The cost difference between a 14% false-positive rate and a 38% rate is the analyst headcount of an entire compliance function. This is the playbook.