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.
- 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.
- Set thresholds per risk, not globally. Payments to high-risk corridors deserve looser (more sensitive) thresholds than domestic low-value flows.
- 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.
- 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)
- 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 runs it, with matching models in-house. For the onboarding half, start at how to integrate a KYC API; for business customers, KYB step by step. For what the lists themselves contain, see AML screening explained; for the compliance program around it, KYC for fintech.