Sanctions, PEP & adverse-media screening with AI alert adjudication

Banks, insurers, payment firms and exporters must not do business with sanctioned parties and must apply enhanced due diligence to politically exposed persons (PEPs). Name screening is notoriously noisy: fuzzy matching against transliterated names produces mostly false positives that analysts clear by hand. AI improves name matching, enriches hits with context (dates of birth, ownership, news) and drafts a documented clear/escalate recommendation. The legal decision stays with a named human.

Problem & value

• Today: list-based screening engines (rules, edit distance, phonetic codes) generate alerts for every customer onboarding, periodic review, list update and payment. Analysts open each alert, compare identifiers, search the web for adverse media and write a justification. Misses carry legal and reputational risk; false positives cost capacity and delay payments and onboarding.
• AI value: better multilingual/transliteration matching, risk-based alert prioritisation, ownership-chain resolution (entities owned 50% or more by listed parties), automated evidence gathering and structured rationale drafts. Vendors report large automation shares, e.g. ComplyAdvantage markets agentic workflows that "resolve up to 85% of routine alerts autonomously" [4] — a vendor claim, not an independent benchmark; validate on your own alert history.
• Regulatory pull: EU financial sanctions are published in the Consolidated Financial Sanctions List maintained by the Commission [1]; in Germany the Bundesbank handles financial sanctions and BAFA embargoes on goods and economic resources [5]. The EU AML Regulation (EU) 2024/1624 harmonises customer due diligence, including PEP and targeted-financial-sanctions screening, and applies from 10 July 2027, with the new AMLA coordinating supervision [6][7].

Variants

• Customer onboarding & periodic review (KYC/KYB): screen persons, companies, UBOs; re-screen on every list change (delta screening). Overlaps AGENT-015.
• Payment & transaction screening: real-time screening of SWIFT/ISO 20022 messages incl. vessels, ports and free-text fields; very low latency budget.
• Supplier, trade and export screening (non-bank): manufacturers and traders screening business partners, end users and logistics parties against EU/UN/US lists and dual-use rules; links to ANOM-011 and DOC-006.
• PEP and RCA screening: domestic/foreign PEPs, family members and close associates, with tiered risk and expiry rules.
• Adverse-media screening: LLM-based news search and classification (fraud, corruption, terrorism financing) with entity disambiguation.
• Ownership & 50% rule analysis: graph resolution of corporate structures from registries to detect indirect control.
• Fund / insurance / crypto variants: securities and insurance onboarding; wallet and counterparty screening, see ANOM-023.
• Private use: not applicable; individuals have no screening duty (landlords, charities and small shops mostly rely on their bank or a platform).

How it works

1. data intake (customers, UBOs, suppliers, payments)
2. normalisation (transliteration, name parsing, script handling, alias expansion)
3. list ingestion (EU FSF, UN, OFAC SDN, OFSI, PEP/RCA data, delta updates)
4. candidate retrieval (blocking via search index + phonetic/embedding recall)
5. pairwise scoring (name, DoB, country, ID; learned match model)
6. alert triage model (rank by likelihood of true match, segment-specific thresholds)
7. AI adjudication assistant (LLM agent gathers registry/news evidence, drafts rationale)
8. human analyst (four-eyes on true matches, sanctions officer decision, freeze/report)
9. audit log + feedback to thresholds and models

• Matching: classic algorithms (Jaro-Winkler, Levenshtein, double metaphone) plus learned pairwise models and multilingual embeddings for transliterated and reordered names. OpenSanctions' open-source yente API offers search and bulk matching over FollowTheMoney entities on an Elasticsearch/OpenSearch index [2][3].
• Alert triage: a gradient-boosted or encoder classifier trained on historical analyst decisions predicts "false positive" probability; low-risk clusters may be auto-closed only under a validated policy.
• LLM adjudication: a reasoning LLM with retrieval over registry data and news compares identifiers (DoB, nationality, role), reports contradictions and produces a structured recommendation with citations. It never decides on its own for potential true matches.
• Human-in-the-loop: analysts clear or escalate; a sanctions officer decides on freezing and reporting; model changes follow model-risk governance with periodic below-the-line testing.

Data preparation

Screening needs clean customer and counterparty master data (names, aliases, dates of birth, nationality, company registers and beneficial owners), plus the external sanctions, PEP and media sources. In an SMB these live in the ERP or CRM, the accounting system, supplier lists in Excel, onboarding forms and mail. Typical gaps: duplicates and spelling variants, missing birth dates or identifiers, transliteration problems, unstructured beneficial-owner information, undocumented past alert decisions and unclear access rights to compliance files.

Preparation steps: (1) extract master data from ERP and CRM (PREP-005); (2) de-duplicate and standardise names and identifiers (PREP-011); (3) define the alert categories and decision codes (PREP-019); (4) harvest past alert dispositions as labelled examples and build a test set with compliance staff (PREP-020, PREP-018); (5) review permissions and the GDPR purpose for reusing the data (PREP-023, PREP-025). Master-data quality drives false-positive rates directly. Plan roughly 30-40 percent of effort for data cleaning; tools such as OpenRefine or the vendor's import checks help.

Implementation paths

Which path for whom

• SMB: Path A - established EU-hostable screening services with maintained sanctions, PEP and media lists are affordable and the process is standard.
• Enterprise: Path B - volume and core compliance processes justify API-based adjudication layers integrated with own KYC, case management and list providers.
• Developer: Path B - combine list and media APIs with LLM-based alert adjudication in your own compliance product.
• Public: Path A - authorities and public bodies should use certified, accountable products with a clear audit trail.

Path A — Buy (recommended for most firms)

• Global screening and risk-data vendors: LSEG World-Check and FircoSoft (LexisNexis Risk Solutions), Dow Jones Risk & Compliance, Moody's, ComplyAdvantage [4] (Sanctions & Watchlists, PEPs & RCAs, Adverse Media, agentic alert handling), Napier AI, Quantexa, SymphonyAI, Silent Eight.
• EU/German vendors (mark: EU): Hawk (Munich, AI AML/screening), ACTICO (Germany), Lucinity (Iceland/EEA), Salv (Estonia), sanctions.io (Netherlands), Dilisense (Switzerland, non-EU). Verify current product scope with the vendor.
• For SMBs outside banking: screening-as-a-service or API (OpenSanctions hosted API, per-query pricing [3]), or modules in ERP/KYC suites. Many core-banking providers and German banking IT service providers bundle screening.
• Choose A when: you are regulated but have no in-house data-science team; vendors carry list maintenance, SLA and evidence for supervisors.

Path B — Build on cloud APIs

• Lists: download EU FSF [1], UN consolidated list, OFAC Sanctions List Service (SDN, consolidated non-SDN, delta files, Advanced Sanctions Data Model) [8]; commercial datasets for PEP/adverse media.
• Matching: managed search (OpenSearch / Azure AI Search, EU region) with a custom scorer; embeddings from EU-hosted models.
• LLM adjudication: frontier or EU models (e.g. Claude, Gemini, GPT via EU regions; Mistral as EU provider) with structured outputs, tool use for registry/news lookup and a strict "cite or abstain" policy; keep PII minimised and log all prompts.
• Orchestration: n8n / Temporal / case-management system (e.g. Camunda); results written to the compliance case system.
• Choose B when: you have a bespoke workflow (e.g. ERP supplier screening) and data may leave to EU cloud under a DPA.

Path C — Self-host (open source)

• Screening engine: yente (MIT) with OpenSearch; OpenSanctions data is licensed CC BY-NC for open download, so commercial use needs a paid licence (screening or reseller licence) [2][3]. Alternative: build on public lists (EU/UN/OFAC) that are free to use.
• Models: open-weight LLMs (Qwen3, Llama, Mistral families — check each licence) for adjudication drafting on HW2–HW3; multilingual embedding models (e.g. BGE-M3, multilingual-e5) for name recall; small encoder classifier for triage.
• Stack: PostgreSQL/OpenSearch, Neo4j or Memgraph for ownership graphs, vLLM or Ollama, Langfuse for traces.
• Hardware: HW1 suffices for matching; HW2 for a ~30B quantised LLM adjudicator; HW3 if you run longer evidence documents or high volume.
• Choose C when: data may not leave premises (banks with strict outsourcing rules, public bodies) and you have engineers to own list updates and testing.

Path D — Custom training

Worth it for large institutions with years of labelled analyst decisions: train a pairwise name-matching model (siamese encoder / cross-encoder) and an alert-prioritisation model on historical alerts, with adversarial name perturbations (transliteration variants). Needs thousands to hundreds of thousands of labelled alert dispositions and a robust model-validation process. For small firms, vendor models or thresholds tuning are sufficient.

State of the art (2026)

• Agentic alert handling is the main 2025–2026 trend: vendors present AI agents that gather evidence and close routine alerts autonomously [4]. Supervisors expect explainability, testing and human accountability, so most deployments use AI for prioritisation and drafting rather than final decisions.
• Entity-resolution and graph methods (FollowTheMoney-style entity schemas, ownership graphs) replace pure string similarity; open data projects make such tooling accessible [2].
• LLM adverse media: retrieval plus LLM classification handles multilingual news and entity disambiguation better than keyword rules, but quality depends on source coverage and recall testing.
• Delta screening and list velocity: sanctions lists change several times a week; continuous re-screening of the customer base is standard.
• Limits and failure modes: transliteration and common names; missing identifiers; hallucinated "evidence" from LLMs; prompt injection via news pages; stale data; bias against names from specific regions (nationality-driven false positives); over-tuned thresholds causing missed true matches. There is no public, standard benchmark for name-screening accuracy; measure on your own labelled data and with synthetic perturbed lists.

Shared resources & combinations

• Shared building blocks: search-engine (OpenSearch), embedding-text, text-classifier, knowledge-graph, llm-reasoning, agent-framework, plus a case-management and audit-log layer. The same HW2/HW3 LLM server can serve other compliance agents.
• Combine with: ANOM-002 (AML transaction monitoring; shared customer risk rating and case management), AGENT-015 (onboarding & KYC workflow), ANOM-014 (ID document forgery and liveness check before screening), ANOM-017 (synthetic-document fraud), ANOM-023 (crypto-asset monitoring), ANOM-011 (supply-chain and supplier risk), DOC-001 and DOC-006 (extract parties, vessels and ports from invoices and logistics documents for trade screening).
• Data pipelines: one list-ingestion service (EU/UN/OFAC) feeds onboarding, payment and supplier screening.

Effort, cost & KPIs

• Path A: weeks to a few months (data mapping, threshold tuning, parallel run); licences per volume or per screened entity.
• Path B: 3–6 months incl. validation; costs from search/LLM tokens, data licences and compliance testing.
• Path C: 4–9 months and ongoing list/model operations; PEP/adverse-media data still needs a licence.
• KPIs: false-positive rate, alert-to-true-match ratio, analyst minutes per alert, time-to-clear, backlog age, true-match recall on seeded test cases (below-the-line testing), delta-screening latency, auditor findings, share of AI recommendations overridden by analysts.

People & change

Involve management and the compliance or money-laundering officer first: they carry the legal responsibility and define the risk appetite. The head of onboarding or procurement and the analysts who clear alerts are the end users; bring them into the pilot early because they know the typical false positives. IT and IT security cover integration and access rights; legal checks the vendor contract and audit duties (GUIDE-010). The DPO is required: screening processes personal data and adverse media may touch criminal-offence data, so check the legal basis, the data processing agreement and a DPIA (Art. 35 GDPR; GUIDE-005).

Works council: depends. Customer screening alone is not employee monitoring, but case-management tools record handling time and decisions of individual analysts, which can be suited to monitor performance and triggers section 87(1) no. 6 BetrVG. Inform the council about changed work processes under section 90 (1) no. 3 (GUIDE-004).

AI literacy: support analysts with training on how the LLM summary was produced, its possible errors and when to escalate (AI Act Art. 4, GUIDE-006). Typical concern: fear of missing a true hit. Address it by keeping the AI as a prioritising and drafting aid, with a person making and documenting every final decision. Run the pilot in parallel with the existing process (GUIDE-009).

Risks, regulation & compliance

• EU AI Act: typically minimal risk. Annex III lists credit-worthiness assessment (5(b)) and insurance pricing, not sanctions screening, so a pure sanctions/PEP screening tool is generally not high-risk; classification is context-dependent, and a screening result feeding automatic credit or access decisions about natural persons needs separate review. AI literacy (Art. 4) applies. Not legal advice [9].
• Sanctions law: EU restrictive-measure regulations, German AWG/AWV, Bundesbank/BAFA responsibilities [5]; strict liability in practice, so recall matters more than precision. US OFAC rules apply to USD flows and US persons [8].
• AML law: national GwG now, EU AMLR 2024/1624 from 10 July 2027 and AMLA supervision [6][7]; PEP enhanced due diligence.
• GDPR: screening processes personal data and sometimes data on criminal allegations (Art. 10) from adverse media; need a legal basis (legal obligation), data minimisation, retention limits, DPIA, and Art. 22 care where a decision with legal effect is automated.
• Mitigations: human decision on every potential match, model validation and below-the-line testing, source whitelisting for LLM tools, injection filters, full audit trail, regular fairness checks on name origins, vendor due diligence on data provenance.

Getting started

1. Inventory what must be screened (customers, UBOs, suppliers, payments) and which lists apply (EU, UN, OFAC, UK).
2. Export 6–12 months of alerts with analyst outcomes; compute the false-positive rate and time per alert.
3. Run two vendors or yente on your data in parallel with the current engine; seed known true matches and perturbed names to measure recall.
4. Add an AI triage/drafting layer in shadow mode; compare recommendations with analyst decisions before any auto-closing.
5. Write the policy (thresholds, four-eyes, retention, escalation to the Bundesbank/FIU as required) and set up periodic model validation.

Sources

1. European Commission — EU Consolidated Financial Sanctions List / Financial Sanctions Files — https://finance.ec.europa.eu/eu-and-world/sanctions-restrictive-measures/overview-sanctions-and-related-resources_en
2. OpenSanctions — yente (GitHub, MIT) — https://github.com/opensanctions/yente
3. OpenSanctions — Licensing and API pricing model — https://www.opensanctions.org/licensing/
4. ComplyAdvantage — Sanctions, PEP, adverse media and agentic workflows (vendor claim) — https://www.complyadvantage.com/
5. BAFA — Embargoes / sanctions responsibilities (BAFA, Bundesbank) — https://www.bafa.de/EN/Foreign_Trade/Export_Control/export_control_node.html
6. Regulation (EU) 2024/1624 (AML Regulation) — https://eur-lex.europa.eu/eli/reg/2024/1624/oj
7. AMLA — EU Anti-Money Laundering Authority — https://www.amla.europa.eu/index_en
8. U.S. Treasury OFAC — Sanctions List Service — https://ofac.treasury.gov/sanctions-list-service
9. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj