The Scale Problem: Why Manual AML Does Not Work
In 2019, a major Indian private bank's compliance team was manually screening 800 new customers a day against sanctions lists using Excel exports from vendor databases. By 2024, that same bank was onboarding 12,000 customers daily across digital and branch channels. The manual process had not just failed to scale — it had become a liability, with junior analysts spending 70% of their time on obvious false positives and the genuinely risky profiles buried underneath.
This is the AML scaling problem that most growing financial institutions now face. This post covers how modern compliance teams are solving it.
What AML Screening Actually Involves
Effective AML screening at onboarding and on an ongoing basis requires checking individuals and entities against multiple data sources simultaneously:
- Sanctions lists: OFAC (US), EU Consolidated List, UN Security Council Consolidated List, India's PMLA Schedule, FATF blacklist and greylist
- PEP databases: Politically Exposed Persons and their immediate family and close associates — typically using commercial aggregated databases like World-Check or LexisNexis
- Adverse media: News articles linking the person or entity to financial crime, corruption, fraud, or regulatory action — requires NLP-based filtering to separate relevant hits from noise
- Internal watchlists: Previously rejected customers, known fraud patterns from your own portfolio
The False Positive Problem
The most common failure mode in AML screening is not missed hits — it is alert fatigue. When your screening system generates 500 alerts a day and 480 of them are clearly false positives (common names, transliteration mismatches, name collisions with legitimate public figures), your compliance team stops taking the alerts seriously. The genuinely risky profiles in that list of 480 get waved through.
The technical solution to this is fuzzy matching with configurable confidence thresholds combined with contextual disambiguation:
- Match on name plus date of birth, nationality, and other available identifiers — not just name alone
- Apply transliteration normalisation for names in Hindi, Tamil, Arabic, and other scripts
- Weight matches differently based on the data source: an OFAC exact match is categorically different from a soft name match on adverse media
- Build a feedback loop where compliance team dispositions (true positive / false positive) train the model's scoring over time
Continuous Screening: Why Onboarding Checks Are Not Enough
Sanctions lists are updated multiple times a week. A customer who was clean at onboarding may be added to the OFAC list three months later. Without continuous screening, you are compliant at the point of onboarding and unknowingly non-compliant for everything after.
Modern AML platforms run ongoing screening in one of two modes:
- Batch re-screening: Your entire active customer base is re-screened against updated lists on a nightly or weekly basis
- Event-triggered screening: Re-screening is triggered by specific events — a large transaction, a change of address, a new beneficial owner — rather than on a calendar schedule
For most RBI-regulated entities, monthly re-screening of the full base combined with event-triggered checks for high-risk customers is the current expectation.
Building the Compliance Workflow Around the Technology
Technology solves the data problem. The workflow design problem requires equal attention:
- Risk-tiered review queues: Exact sanctions matches go to a senior compliance officer immediately. Soft adverse media hits go into a 48-hour review queue. This keeps the team focused on severity-appropriate actions.
- Documented disposition records: Every alert must have a documented outcome — matched and reported, investigated and cleared, or escalated to financial intelligence. Audit trails must be immutable.
- SAR filing integration: When a match leads to a Suspicious Activity Report, the platform should support the FIU-IND XML filing format directly to reduce manual transcription errors.