--- title: How to Run Sanctions and PEP Screening description: How to run sanctions screening and PEP checks: list coverage, matching thresholds, alert handling, and ongoing monitoring without alert overload. category: KYC & AML published: 2026-08-19 updated: 2026-08-22 keywords: sanctions screening, pep screening, aml screening order: 30 --- ## How do you run sanctions and PEP screening? Screen every customer against a list floor of OFAC (SDN and consolidated), UN, EU and UK OFSI. Tune matching between exact and loose fuzzy — adding date of birth, country and identifiers pulls false positives down by an order of magnitude. Work alerts as investigations with a written disposition, and re-screen continuously. This guide is for compliance owners standing up sanctions and PEP screening, or inheriting a program that drowns them in false positives. It covers list scope, match tuning, alert handling, and ongoing monitoring, with the operating numbers that keep the queue humane. ## Get the obligation straight Sanctions screening is binary and non-negotiable: doing business with a sanctioned party is prohibited, penalties are strict-liability in key regimes, and "we didn't find them" is not a defense if you weren't looking properly. PEP screening is different in kind: a politically exposed person is legal to serve. The obligation is to know you're doing it and apply enhanced due diligence, because public power plus money movement is a corruption risk pattern. Treat the two as separate programs sharing plumbing, not one check with two names. ## Choose your lists deliberately - [ ] **Sanctions floor:** OFAC (SDN and consolidated), UN, EU, and UK OFSI. Add regimes for every corridor you actually serve; a platform with Singapore volume screens MAS lists too - [ ] **PEP data:** commercial databases, since no official global PEP list exists. Ask vendors how they source, tier (heads of state versus municipal officials), and retire entries; stale PEP data generates alerts for people who left office years ago - [ ] **Adverse media**, if included, scoped to relevant crime categories, or it becomes a Google-alert firehose - [ ] **Update cadence:** sanctions lists change without notice, and enforcement expects you to catch changes fast. Daily refresh minimum; same-day for OFAC updates is the standard serious programs hold themselves to - [ ] Record what you screen against and since when. The first question after a miss is "which list version were you running" ## Tune matching before you drown Name matching is where screening programs live or die. Exact matching misses "Mohammed/Muhammad/Mohamed"; loose fuzzy matching flags half your customer base. 1. **Match on more than the name.** Date of birth, country, and identifiers pull false positives down by an order of magnitude. If your form doesn't collect a date of birth, your screening cost just became a product decision. 2. **Set thresholds per risk, not globally.** Payments to high-risk corridors deserve looser (more sensitive) thresholds than domestic low-value flows. 3. **Test with known cases.** Seed real list entries and near-misses through the system before launch, then quarterly. A screening engine nobody has ever seen catch anything deserves the skepticism it gets. 4. **Version your configuration.** Threshold changes are policy changes. Date them, sign them, keep the history for the auditor. ## Work alerts like investigations, not inbox An alert is a possible match, and most are name collisions. The discipline: | Step | What good looks like | |---|---| | Triage | Compare secondary identifiers (DOB, nationality, address) against the list entry. Most alerts close here in under two minutes | | Escalate | Genuine ambiguity goes to a second reviewer with more context, not the same reviewer squinting harder | | Confirm | A true sanctions match: freeze, don't tip off, report to the relevant authority. Have this path written down BEFORE the first true hit; improvising it is miserable | | PEP confirm | Enhanced due diligence: source of funds, senior-management approval to retain, closer ongoing monitoring | | Document | Every disposition gets a reason and a reviewer. "Closed, obviously not him" has ended careers in exactly the audits that found it | Watch two numbers: **false-positive rate** (if reviewers close 99%+ of alerts as noise, tune the matching; that's alert fatigue being farmed) and **time-to-disposition** (aging alerts are risk sitting in a queue). ## Screen ongoing, not just at onboarding The person you onboarded clean gets sanctioned later; the quiet customer becomes a minister. Point-in-time screening misses both. - Re-screen your full customer base against list updates automatically; delta screening (new list entries against existing customers) keeps the volume sane - Trigger re-screening on profile changes: name, country, ownership (for business customers, every UBO stays in scope, per the [KYB process](/guides/how-to-verify-a-business-kyb/)) - Log every re-screen sweep, including the ones that found nothing. Proving the negative is most of what the audit trail is for ## Common failure modes - **Screening the customer but not the counterparty.** Payments have two ends. - **One-time PEP checks.** PEP status changes with every election cycle. - **Whitelisting too broadly.** Suppressing a known false positive by name alone suppresses the real match with the same name later. Whitelist on the full identifier set. - **Ignoring transliteration.** Names from non-Latin scripts have many romanizations; your matching must handle them or your coverage quietly excludes the highest-risk geographies. Screening runs best fused into onboarding rather than bolted after it: identity verification establishes who the person is, screening establishes whether you may serve them, one flow, one audit trail. That's how Verifa's [KYC/AML platform](/products/kyc-aml/) runs it, with matching models in-house. For the onboarding half, start at [how to integrate a KYC API](/guides/how-to-integrate-a-kyc-api/); for business customers, [KYB step by step](/guides/how-to-verify-a-business-kyb/). For what the lists themselves contain, see [AML screening explained](/blog/aml-screening-explained/); for the compliance program around it, [KYC for fintech](/blog/kyc-for-fintech/).