Sanctions, PEP and adverse-media screening architecture

Sanctions screening, PEP screening and adverse-media screening are often lumped together, but they answer different questions and carry different consequences. Sanctions screening checks legal restrictions. PEP screening flags people whose position calls for enhanced due diligence. Adverse-media screening surfaces negative news that may warrant investigation. Getting the architecture right is less about which data you buy and more about matching quality, thresholds, rescreening and how alerts are triaged. This guide explains how to design each part deliberately.

Legal and regulatory status was reviewed on 7 July 2026.

Different purpose of each screening type

The three screening types are not substitutes:

• Sanctions screening checks whether a party is subject to restrictive measures — a legal constraint on dealing with them.
• PEP screening identifies politically exposed persons, whose status warrants enhanced due diligence, not automatic exclusion.
• Adverse-media screening surfaces negative news as a signal to investigate, not as proof of wrongdoing.

Treating them as one blurred “screening” step leads to wrong decisions and unfair outcomes. The obligations sit within the EU anti-money-laundering framework, where the AML Regulation (EU) 2024/1624 will mainly apply from 10 July 2027 1.

Data sources

Screening relies on reference data: sanctions lists, PEP datasets and media sources, usually supplied by vendors who aggregate and structure them. Data differs in coverage, update frequency, structure and quality. Understand where each list comes from, how often it updates, and how the vendor handles corrections, because your screening is only as reliable as its underlying data.

Name normalisation

Names arrive in many forms — different orders, punctuation, titles, abbreviations. Normalisation puts names into a consistent form before matching. Poor normalisation causes both misses and excess noise. Confirm how the vendor normalises names and whether you can influence it for your customer base.

Transliteration

Names written in different scripts must be transliterated to compare them, and there is rarely a single correct transliteration. A robust system handles multiple transliteration variants so that a match is not missed simply because of spelling differences across scripts. Ask how transliteration is handled for the regions you serve.

Date-of-birth and geography matching

Secondary identifiers such as date of birth and country help distinguish real matches from coincidental name collisions. Using them well reduces false positives; using them naively (for example, discarding records with missing dates) can hide real matches. Define how secondary identifiers are weighted rather than treated as absolute filters.

False positives

False positives — alerts that turn out not to be true matches — are the dominant operational cost of screening. Common names, sparse identifiers and broad matching all inflate them. The goal is not zero alerts (which usually means missed matches) but a defensible balance where investigators can work the queue and true matches are not lost in noise.

Fuzzy matching

Fuzzy matching tolerates spelling variations and partial matches so near-matches are caught. The looser the matching, the more true matches you catch and the more false positives you generate. Fuzziness should be tuned per list and risk level, and the rationale documented. There is no universally correct setting.

Risk-based thresholds

Match thresholds decide when a comparison becomes an alert. Thresholds should be risk-based: tighter where the consequence of a miss is severe (sanctions), calibrated elsewhere. Threshold decisions must be governed and documented, and reviewed as data and typologies change — not left at a vendor default.

Onboarding and ongoing screening

Screening at onboarding is necessary but not sufficient. Customers, lists and news change, so screening must also run on an ongoing basis so that a customer who becomes sanctioned or newly appears in adverse media is caught. Design both the onboarding gate and the continuous process, as part of a broader lifecycle covered in KYC, KYB and transaction-monitoring architecture.

Event-driven rescreening

Beyond periodic rescreening, event-driven rescreening triggers on relevant changes: a list update, a change in customer data, or a new relationship. This keeps screening current without rescreening everyone constantly. Define which events trigger rescreening and how quickly, and record that the process ran.

Entity and ownership screening

Screening applies to businesses and their connected parties, not just individuals: the entity itself, its beneficial owners, directors and, where relevant, counterparties. Ownership screening requires resolving the ownership structure first. Ensure the screening scope matches the structure you established during business verification.

Payment screening

Payment screening checks parties to a transaction (for example, sender and beneficiary) against relevant lists in the payment flow, often in near real time. This is distinct from customer screening and has tighter latency constraints. Where it applies, design for both accuracy and speed, and coordinate with your monitoring and controls in build a fraud and transaction-monitoring stack.

Alert triage

Triage is how analysts work alerts: reviewing the match, gathering context, deciding true or false, and escalating where needed. Consistent triage — with clear criteria and documented decisions — is what turns screening output into defensible outcomes. Investigators need enough context to decide, and every decision should be recorded.

Audit trail

Screening decisions must be evidenced: what was screened, against which data version, what matched, who decided what and why. Coordinated supervision expects this evidence, and national frameworks transposing the AML directive set the surrounding obligations 2. Build the audit trail into the workflow so it is a by-product of doing the work, not a later reconstruction.

Vendor governance

Screening vendors must be governed like any critical dependency: data quality, update cadence, matching behaviour, explainability, support and change management. Do not treat a vendor’s list as infallible or its matching as a black box. See how to run fintech provider due diligence and an RFP for a structured approach.

Data-quality testing

Regularly test screening quality: known-match tests to confirm true matches are caught, and false-positive analysis to check noise. Testing should cover normalisation, transliteration and thresholds. Because screening processes personal data, testing and data handling must respect data-minimisation and retention principles under the General Data Protection Regulation 3.

Screening type	Question it answers	Consequence of a hit
Sanctions	Is this party subject to restrictions?	Legal constraint; escalate immediately
PEP	Does position warrant enhanced due diligence?	Enhanced due diligence, not exclusion
Adverse media	Is there negative news to investigate?	Documented investigation; not proof
Payment screening	Are transaction parties on a list?	Hold/review within payment latency
Ownership	Are owners/connected parties flagged?	Review scoped to the structure

• Sanctions, PEP and adverse-media purposes documented separately
• Data sources, coverage and update cadence understood per list
• Name normalisation and transliteration behaviour confirmed
• Secondary identifiers (DOB, geography) weighted, not used as hard filters
• Fuzzy matching and thresholds tuned per list and risk, with rationale
• Onboarding, ongoing and event-driven rescreening designed
• Entity, ownership and payment screening scoped correctly
• Alert triage criteria and decision recording defined
• Audit trail captured as a by-product of the workflow
• Data-quality testing and data-protection handling in place

Questions to ask providers

• Where does your sanctions, PEP and adverse-media data come from, and how often is it updated?
• How do you handle name normalisation and transliteration for our regions?
• How are secondary identifiers such as date of birth and country used in matching?
• Can we tune fuzzy matching and thresholds per list and risk level?
• How do you support ongoing and event-driven rescreening?
• How does the tool present context for alert triage, and how are decisions recorded?
• What audit trail do you produce, and against which data version?
• How can we run known-match and false-positive testing?
• What is your data-protection posture on minimisation and retention?

Common failure modes

• Treating PEP status as grounds for automatic exclusion rather than enhanced due diligence.
• Presenting adverse media as proof of wrongdoing instead of a signal to investigate.
• Leaving thresholds at vendor defaults with no documented rationale.
• Screening only at onboarding and never rescreening.
• Discarding records with missing secondary identifiers, hiding real matches.
• Treating the vendor’s matching as an unexaminable black box.
• Ignoring data-minimisation and retention when handling screening data.

What this does not cover

This guide does not provide legal advice, does not determine whether any screening setup is compliant for your institution, and does not describe the AML Regulation as already fully applicable, since it mainly applies from 10 July 2027 1. It complements — but does not replace — advice tailored to your entity, products and jurisdictions.

FAQ

Should a PEP match automatically block a customer?

No. PEP status warrants enhanced due diligence, not automatic exclusion. The point is to apply proportionate scrutiny and document the decision, not to reject the customer outright.

Is an adverse-media hit proof of wrongdoing?

No. Adverse media is a signal to investigate. It should trigger a documented review that considers relevance and source quality, not an automatic adverse decision.

Why do we get so many false positives?

Common names, sparse identifiers and loose matching all inflate false positives. Better normalisation, transliteration handling and risk-based thresholds reduce noise, but aiming for zero alerts usually means missing true matches.

Is screening at onboarding enough?

No. Customers, lists and news change, so screening must also run on an ongoing and event-driven basis so newly sanctioned parties or new adverse media are caught after onboarding.

How do sanctions and PEP screening differ?

Sanctions screening enforces legal restrictions on dealing with a party. PEP screening identifies people whose position requires enhanced due diligence. One is a legal constraint; the other is a risk indicator.