AML (Anti-Money Laundering) screening is the process of checking a customer or transaction against sanctions lists, politically exposed persons (PEP) registers, and adverse media data. Regulated firms — banks, payment institutions, e-money issuers, securities intermediaries and crypto exchanges — are legally required to run it under FATF Recommendations 10 through 19, EU AMLD5/AMLD6, the UK Money Laundering Regulations 2017, and equivalent local frameworks. This guide walks through the components of an AML screening system, why each list category matters, how to keep false-positive rates sustainable, and the architectural decisions that separate a working pipeline from a backlog factory.
TL;DR
AML screening rests on three pillars: sanctions lists, PEP registers, and adverse media data. They run at three operational moments: at onboarding, periodically over the customer lifecycle (rescreening), and on every financial transaction (transaction screening). A well-built system automatically closes tens of millions of matches per year and surfaces only marginal cases to a compliance analyst; a poorly built one consumes 70%+ of the team's time on manual review and still misses real risk.
The Three Pillars of AML Screening
1. Sanctions Screening
Sanctions screening checks whether a natural or legal person appears on international or domestic sanctions lists. For UK and EU operators the baseline lists are:
- UN Security Council Consolidated Sanctions List — binding for all UN member states; the foundational list every other regime builds on.
- OFAC SDN (Specially Designated Nationals) — US Treasury list. Any institution touching USD-denominated flows must screen against it because of correspondent banking exposure.
- EU Consolidated Financial Sanctions List — issued by Council of the EU, binding for all EU member states under the Common Foreign and Security Policy.
- UK HM Treasury OFSI Consolidated List — UK sanctions regime, now divergent from the EU post-Brexit.
- National lists — many jurisdictions maintain additional asset-freeze decisions (e.g. France's national list, Germany's, Turkey's MASAK decrees).
Each list ships in a different format (OFAC XML/CSV; UN XML; EU XML; HMT CSV), with different update cadence (OFAC 1-3 times daily; UN several times a week; EU every few weeks; national lists irregularly). Mapping them all into a single normalised record is an engineering problem in itself — see our OFAC vs UN vs EU vs UK sanctions lists comparison for the detail.
2. PEP Screening
Politically exposed person (PEP) screening flags whether a customer (or the ultimate beneficial owner) holds, or recently held, a prominent public function, or is a close family member or associate of someone who does. Being a PEP is not a crime; it elevates the AML risk profile and triggers Enhanced Due Diligence (EDD) under FATF Recommendation 12 and AMLD5 Article 20.
PEP categorisation typically distinguishes domestic PEPs, foreign PEPs and international organisation PEPs. AMLD5 Article 22 brought a 12-month "step-down" window after a PEP leaves office, after which the relationship may revert to standard CDD provided risk is reassessed. In practice most banks keep ex-PEPs flagged longer.
3. Adverse Media Screening
Adverse media (negative news) screening checks whether a customer's name appears in news content linked to financial crime, fraud, terrorism financing, corruption, sanctions evasion or similar. A CEO not on any sanctions or PEP list but recently named in a trade press money-laundering investigation is a case that should trigger EDD.
The three pillars are complementary: sanctions = binding (a hit means onboarding refusal or account freeze), PEP = risk elevator (EDD required), adverse media = signal source (case-by-case evaluation).
When Screening Runs: The Three Operational Moments
At Onboarding
When a prospective customer applies, screening runs before the account is opened. The objective is to prevent threshold breach. Under AMLD5 Article 13, identification and verification must be completed prior to establishing a business relationship; sanctions and PEP checks are part of that verification.
A well-designed flow completes screening in 100-300 ms — UX-critical. A synchronous API call with normalised name, date of birth, nationality, and where available passport or national ID number returns a match score and hit details.
Rescreening (Periodic Re-screening)
Everyone in your portfolio must be re-screened against the latest lists at regular intervals (typically daily or weekly). A customer clean at onboarding but added to the OFSI list six months later must be caught on a rescreening pass.
Two approaches in production:
- Full sweep: all customers against all lists (e.g. nightly). Compute-heavy but exhaustive.
- Delta sweep: only newly added list entries are checked against the existing portfolio. Cheap, low-latency — a newly designated party is caught within minutes.
Most institutions combine both: daily delta plus weekly full.
Transaction Screening
Every financial transaction — especially wires, SEPA, SWIFT — has its counterparties screened. The 50K and 59 fields of a SWIFT MT103, the BeneficiaryName of a SEPA Credit Transfer, the originator and beneficiary blocks of a pacs.008 — all run through the sanctions engine.
False positives are punishing here: a UK clearing bank processing 500,000 wires per day with a 1% hit rate is 5,000 manual reviews per day. Unsustainable. See how to reduce AML false positives for the techniques teams actually use.
The Matching Engine: Much More Than String Comparison
The heart of an AML screening engine is the fuzzy-matching layer that correctly links a query for "Mohammed Al-Faisal" to records for Mohamed Al Faisal, M. Al-Faisal, Muhammad Faisal, محمد الفيصل. The components:
Character normalisation: bridging diacritics (è, ü, ı, ñ) to a canonical form; transliteration between scripts (Arabic, Cyrillic, Chinese to Latin). Mohamed/Mohammed/Muhammad/Mohamad are the same person under transliteration variance. Without a strong transliteration library (ICU, Buckwalter, custom rules), false positives balloon by 10-15%.
Phonetic matching: Soundex, Metaphone, NYSIIS, Beider-Morse — algorithms that bucket "Stevenson" and "Stephenson" together. Most engines use Beider-Morse for European names and custom phonetic rules for Arabic and East Asian languages.
Distance metrics: Levenshtein (edit distance), Jaro-Winkler, n-gram similarity. Match scoring uses a weighted blend.
Token-based scoring: breaking "Ahmed Mohammed Al-Faisal" against "Ahmed Al-Faisal" piece by piece. Useful, but not sufficient on its own — common surnames in any region produce too many ties.
Identity disambiguators: date of birth, place of birth, nationality, passport number — these collapse the candidate set dramatically. A name-only engine has 3-5× the false-positive rate of one that uses identity attributes.
A good engine outputs a continuous match score (0-100). Matches above a threshold (e.g. ≥85) are surfaced for review; below it they are auto-cleared. Threshold calibration is the dial that trades false positives against false negatives — covered in detail in our AML risk scoring guide.
Real-Time vs Batch Screening
| Scenario | Mode | Why |
|---|---|---|
| Onboarding | Real-time (sync API) | UX-critical; decision must be at point of capture |
| Wire / payment | Real-time | Sanctions hit must block the message |
| Daily rescreening | Batch (scheduled job) | Volume high; latency not user-facing |
| Post list-update | Batch delta | Process only newly added list entries |
| Compliance investigation | Ad-hoc (manual) | Single case, deep analysis |
In a mid-tier EU bank we work with the volumes look roughly like this: 2,500 onboarding events/day (real-time), 400,000 transactions/day (real-time), and 1.8 million customer portfolio swept nightly. The system has to handle all three load profiles on the same screening service.
False Positives: The Operational Cost That Dominates Everything
A bank or PSP AML team spends 60-80% of the day closing false-positive matches. Typical ratios:
- Sanctions screening: 95-99% false positive (a true sanctions hit is rare)
- PEP screening: 85-95% false positive (common names appear on PEP lists too)
- Adverse media: 70-85% false positive (text-based, requires contextual interpretation)
A mid-size EU PSP shared figures with us: roughly 600 PEP matches per day, ~50 escalated to analyst review, 3-4 confirmed PEPs. So 99.4% false positive. A team of four spends the day on this work alone.
Industry-accepted false-positive reduction techniques:
- Match grouping — store previously cleared matches and auto-close repeat hits for the same identity
- Continuous learning — train on analyst close decisions; auto-suppress patterns the team has consistently judged false
- Risk-based thresholds — raise the threshold for low-risk customers, lower it for high-risk
- Multi-attribute scoring — combine name with DOB, country, ID number, gender
- Contextual NLP filtering — for adverse media, parse the context of the keyword
- Negative news vs positive context — "judge in a drug case" ≠ "defendant in a drug case"
- List source weighting — OFAC SDN vs OFAC consolidated; binding force differs
The practical playbook is in how to reduce AML false positives.
System Architecture: What an AML Screening Service Actually Looks Like
A production-grade AML screening service has these layers:
Data layer. Sanctions, PEP and adverse media sources are normalised into a single data model. Per individual we store: primary name, all known aliases, DOB, place of birth, nationality, ID number variants, source list, listing date, delisting date (if any), link to the underlying decision text. A single person may appear on 5+ lists; these are merged into a canonical record.
List-update layer. ETL jobs that pull each list from its official source, absorb format changes, and emit deltas. OFAC's weekly format tweaks, the EU Council's PDFs (from which the canonical name list has to be extracted), MASAK decrees — each needs its own parser and monitoring.
Matching engine. The fuzzy-matching layer described above. Production deployments are typically Lucene/Elasticsearch-based, with extra preprocessing for transliteration and phonetic rules.
Decision API. Takes customer payload, returns matches with score distribution. Synchronous (onboarding) and asynchronous (batch rescreening) modes.
Case management. Workflow for matches that escalate to analyst review: assignment, investigation notes, decision (true positive / false positive), escalation, immutable audit trail.
Audit & reporting. Every screen, every match, every decision is logged. In an FCA or BaFin inspection you must answer "why was this customer screened on 17 March 2024 and what was the outcome?" in seconds.
Monitoring. List update lag, hit rate, false-positive rate, analyst throughput — operational health metrics surfaced on a dashboard.
Operationalising the Pipeline: Team Shape and Workflow
Technology alone does not make an AML programme. Without the right team shape and workflow, even the best engine produces poor outcomes. A mid-size EU institution typically organises around:
MLRO (Money Laundering Reporting Officer). Personally accountable; reports to the board rather than line management. Final sign-off for SARs and external regulator communications. UK regimes formalise this under SMCR senior manager function.
AML analysts. Daily review of alerts coming out of the screening system. A typical tiered structure: Tier-1 (front-line manual review), Tier-2 (complex cases, EDD), Tier-3 (specialist — sanctions evasion, complex ownership structures, cross-border patterns). A mid-tier EU bank runs 15-30 analysts, a Tier-2 PSP 5-10.
Sanctions specialist. Owns sanctions list management and complex sanctions match disambiguation. Tracks OFAC, UN, EU, UK regulatory updates and translates them into screening configuration changes.
Transaction monitoring analyst. Watches transaction patterns; combines anomaly signals with AML screening hits to identify multi-signal cases warranting SAR.
Regulator liaison. Daily communication with the supervisor (FCA, BaFin, etc.), inspection preparation, regulatory update tracking.
The standard workflow: screening system → case management queue → analyst assignment → investigation + decision → MLRO sign-off (where required) → if SAR, export to FIU format → submission → audit log. Each step needs a defined SLA tracked on the dashboard.
Selecting a List Data Provider
Third-party list providers (Dow Jones, Refinitiv, ComplyAdvantage, LexisNexis) supply the raw data layer of an AML platform. Criteria when choosing:
- List coverage. Which lists are included? Are all relevant sanctions regimes covered without gaps?
- Update cadence. OFAC sub-30-minute, EU and UK sub-60-minute is typical expectation.
- PEP depth. How many countries with how much sub-national coverage? Foreign vs domestic balance.
- Alias richness. How many aliases per entry? Transliteration variants covered?
- API quality. Synchronous query latency, throughput, error rate, documentation.
- Match disambiguation. Does the provider ship its own match engine, or just raw data?
- Cost model. Annual licence + per-query, unlimited, by customer count, or other?
- Vendor robustness. Financial stability, SLA guarantees, customer references in your segment.
Most modern AML platforms (Legichain included) integrate the list-provider layer into the platform — the obligated entity does not have to manage a separate vendor relationship.
Regulatory Anchors by Jurisdiction
- EU: AMLD5 (Directive 2018/843), AMLD6 (Directive 2018/1673), the upcoming AML Package centralising under AMLA. Sanctions enforced via EU Council Regulations under Article 215 TFEU.
- UK: Money Laundering, Terrorist Financing and Transfer of Funds (Information on the Payer) Regulations 2017 (MLR 2017), as amended; Sanctions and Anti-Money Laundering Act 2018; OFSI enforcement.
- US (correspondent exposure): Bank Secrecy Act; USA PATRIOT Act; OFAC regulations 31 CFR Chapter V.
- Turkey: Law No. 5549 on Prevention of Laundering of Crime Proceeds; Law No. 6415 on Prevention of Financing of Terrorism; MASAK secondary regulation (Tebliğ Series).
- Global baseline: FATF Recommendations 10, 12, 13, 19; FATF guidance on PEPs (2013).
Screening Is One Part of a Whole AML Programme
Screening is the most visible component, not the only one. A full AML programme has roughly ten threads; screening is one:
1. Enterprise-wide Risk Assessment (EWRA). Annual: institution-level financial-crime exposure — customer segment, product portfolio, geographic footprint, distribution channels — assessed. EWRA output directly drives screening intensity and threshold calibration.
2. Customer Risk Assessment (CRA). Each customer scored (AML risk scoring guide). Screening thresholds and frequency depend on this score.
3. KYC / CDD processes. Identity verification, customer due diligence. Screening complements KYC; without KYC there is no screening.
4. Enhanced Due Diligence (EDD). Applied to high-risk customers — source of funds, source of wealth, closer monitoring.
5. Screening (sanctions / PEP / adverse media). The subject of this guide.
6. Transaction monitoring. Anomaly detection in transaction patterns — structuring, layering, smurfing, rapid in-out movement.
7. Suspicious Activity Reporting (SAR / STR). Filing to the national FIU.
8. Record-keeping. All AML decisions, documentation, screening logs, training records retained per the local rule.
9. Training. Annual AML/KYC training for all relevant staff; updated to reflect supervisor expectations and typology shifts.
10. Independent testing/audit. Internal audit (typically annual) tests the AML programme independently; findings reported to the board.
Screening sits at the centre but is not sufficient alone. A strong AML programme keeps all ten threads in good order; a weak one over-invests in one or two while neglecting others — supervisory reviews catch this.
AML Screening Performance Metrics
The metrics we use to track screening health:
- Recall: rate at which truly risky customers are surfaced by the system. Must be close to 100%.
- Precision: proportion of flagged matches that are genuinely risky.
- False positive rate (FPR): falsely flagged / total screened. Target 1-3%.
- Match closure time: average time an alert spends in queue. Below 24 hours.
- List update latency: time from official list publication to live in production. Below 30 minutes.
- Coverage: which lists / jurisdictions are in scope. Must match the regime your customer base operates under.
Track weekly, report monthly to compliance and risk committees.
Frequently Asked Questions
Is AML screening the same as KYC?
No. KYC (Know Your Customer) is identifying and verifying a customer's identity — collecting documents, address, source of funds. AML screening operates as part of, or alongside, KYC: it checks whether the identified customer appears on sanctions lists, PEP registers or adverse media. KYC answers "who is this person?"; AML screening answers "is this person risky?".
What do we do when a sanctions hit comes back?
The alert escalates to analyst review. The analyst confirms or rejects it as a true match. If true: at onboarding, refuse the relationship; for existing customers, freeze the account and notify the competent authority (OFSI in the UK, the national FIU in EU member states); assets must be reported under the relevant sanctions regulation. Every decision is documented and held under the jurisdiction's retention rule (typically 5-8 years).
How often should we rescreen the portfolio?
Most regulators do not prescribe a frequency but expect "appropriate ongoing monitoring." Industry practice: high-risk customers (foreign PEPs, high-risk jurisdiction nationals, high transaction volume) daily; medium-risk monthly; low-risk quarterly. For newly added list entries a real-time delta sweep (hourly or sub-hourly) is expected — a customer added to OFSI 24 hours ago whom you have not screened against will surface as a finding in a supervisory review.
Is adverse media screening mandatory?
No regulator literally writes "scan negative news," but Enhanced Due Diligence requirements in AMLD5 Article 18 and FATF Recommendation 12 both expect "publicly available adverse information" to be considered for high-risk customers. In practice, adverse media screening is operationally mandatory for PEPs, high-risk jurisdiction nationals, and customers above defined transaction thresholds.
Should a small fintech build its own AML screening engine?
Usually not. The combined cost of list licensing (Dow Jones, Refinitiv, LexisNexis), normalised data storage, fuzzy matching engine and continuous list maintenance comfortably crosses six figures USD annually before staff. Vendor solutions (Legichain among them) deliver it via a single API. Build economics start to make sense around mid-tier bank scale and a dedicated data engineering team.
How Legichain Helps
We deliver all three screening verticals — sanctions, PEP, adverse media — through a single AML screening API. Coverage spans UN, OFAC SDN and consolidated, EU, UK HMT OFSI, and major national sanctions regimes; OFAC list update latency averages under 15 minutes. The matching layer ships with strong transliteration (Arabic, Cyrillic, Chinese), Beider-Morse phonetics, and a Turkish-specific normaliser for clients with TR-resident counterparties.
Match grouping and continuous learning have helped a Tier-2 EU bank we work with cut onboarding alert review effort by 72% (before: 4 analysts × 8 hours/day; after: 1 analyst × 6 hours/day). Transaction screening runs at p99 <80 ms; SWIFT MT103 and SEPA pacs.008 parsers are built in.
See our cuts on architecture in AML screening for banks and sanctions screening for PSPs.
Next Steps
- What is sanctions screening — the technical detail of lists and matching
- What is a politically exposed person (PEP) — PEP risk management
- How to build an AML risk scoring model — threshold and segmentation calibration
- EU financial regulation guide — MiCA, AMLD, PSD3, TFR, AMLA