Guide to sanctions and PEP screening for KYC and AML onboarding, covering lists, matching logic, false positives, and review workflows
Sanctions and politically exposed person screening looks simple from a distance: take a customer name, compare it with watchlists, and decide whether to onboard. In practice, the hard parts are data quality, name variation, transliteration, list changes, ownership links, review evidence, and deciding how much uncertainty your workflow can tolerate.
Developers and compliance teams need to design the same system from different angles. Engineering needs deterministic inputs, explainable outputs, and operationally safe integrations. Compliance needs risk-based controls, audit trails, escalation paths, and enough context to avoid blocking good customers while still catching prohibited or high-risk relationships.
This guide focuses on the mechanics: which lists matter, how matching works, where false positives come from, and how to build a review process that can survive real onboarding traffic without becoming a black box.
- Sanctions name matching: normalization, fuzziness, and explainable scores — A practical guide to building name-matching logic that catches real risk without turning every spelling variation into an alert
- Sanctions alert triage: review queues, evidence, and defensible decisions — A guide to designing the human review process after screening produces a possible sanctions or PEP match
- Sanctions Screening Implementation Checklist — A step-by-step checklist for setting up or reviewing sanctions and PEP screening controls
- Sanctions Alert Review Template — Copy-paste text for documenting sanctions and PEP screening alert reviews consistently
Sanctions screening checks whether a person, business, vessel, aircraft, address, or related party appears on a sanctions list or is connected to a sanctioned party. The exact legal obligations depend on jurisdiction, business model, customer location, transaction routes, and the services offered. A payments company, a broker, a bank, and a crypto exchange may all screen similar data but apply different policies.
PEP screening is different. A politically exposed person is not automatically prohibited. PEP status usually indicates elevated corruption, bribery, or influence risk, especially when combined with high-risk geography, unusual source of funds, adverse media, or complex ownership. The outcome is often enhanced due diligence rather than automatic rejection.
A good onboarding flow separates these concepts in the data model. A sanctions hit, a PEP association, an adverse media result, and an internal blocklist match should not be collapsed into one generic alert type. If everything becomes a single yes-or-no result, reviewers lose the context needed to make defensible decisions.
- Sanctions screening is usually about prohibition, restriction, or required escalation.
- PEP screening is usually about risk classification and enhanced due diligence.
- Related-party screening matters for companies, directors, beneficial owners, signatories, and controlling persons.
- Screening should happen at onboarding and again when lists, customer data, or risk posture changes.
There is no single universal list. Common sources include national sanctions lists, regional lists, international organization lists, law enforcement notices, and commercially curated datasets. For many financial services workflows, list coverage must reflect where the business operates, where customers are located, which currencies and rails are used, and where counterparties may be connected.
Official sanctions lists are authoritative for their issuing authority, but they are not always formatted for easy matching. Names may appear in multiple scripts, aliases can be incomplete, dates of birth may be missing, and addresses may be vague. Commercial watchlist providers often normalize and enrich this information, but teams still need to understand provenance and update behavior.
PEP lists are especially sensitive because definitions vary. Some datasets include heads of state and senior officials only. Others include relatives, close associates, state-owned enterprise executives, political party officials, judges, military leaders, or local government figures. Broader coverage can help risk teams, but it can also increase alerts that require manual review.
- Map list sources to legal obligations and business exposure rather than adding every possible dataset by default.
- Record source name, list type, version or retrieval time, and the fields used in each alert.
- Treat PEP categories as risk signals with definitions, not as a single undifferentiated label.
- Decide whether archived or historical PEP status should remain visible after a person leaves office.
Exact matching is rarely enough. Watchlist entries may include aliases, initials, patronymics, compound surnames, order changes, transliterations, and spelling differences. A customer may enter a legal name, a preferred name, or a name from a document that uses a different script. Business names add suffixes, abbreviations, punctuation, and trading names.
Most screening systems use a combination of normalization and fuzzy matching. Normalization may lowercase text, remove punctuation, standardize company suffixes, strip accents, and tokenize names. Fuzzy matching then compares similarity across tokens, phonetics, edit distance, aliases, dates of birth, countries, and identifiers. The exact scoring model should be explainable enough for reviewers to see why an alert appeared.
The main trade-off is sensitivity versus precision. Loose thresholds catch more possible matches but generate more false positives. Strict thresholds reduce review workload but may miss weak matches where list data is incomplete. In regulated onboarding, the right answer is rarely a single global threshold. Riskier segments, higher-risk jurisdictions, and sparse identity data may justify more conservative matching.
- Normalize customer data and watchlist data consistently before comparison.
- Compare name components, not only the full string.
- Use secondary attributes such as date of birth, nationality, address, registration number, or country when available.
- Keep the raw input, normalized input, matched fields, and scoring explanation for audit review.
False positives are not just an inconvenience. They slow onboarding, create customer friction, consume compliance time, and can train teams to treat alerts as noise. They happen because many people share common names, watchlist records are incomplete, transliteration is inconsistent, and customer-provided data may be partial or inaccurate.
A classic false positive is a common name match with no supporting attributes. For example, a customer named with a widely used given name and surname may resemble a listed person, but the date of birth, country, and address may not align. Another common case is a business name that contains a generic word also found in a listed entity name. Without token weighting, the system may overvalue weak similarities.
False positive reduction should not mean hiding alerts without a reason. It should mean using better context. Date-of-birth mismatches, incompatible entity type, unrelated jurisdiction, different registration identifiers, and strong document verification can all help downgrade a match. The decision should be traceable: what data was compared, what conflicted, and why the match was cleared.
- Use entity type to avoid comparing individuals and companies as if they were the same.
- Weight rare name tokens more heavily than generic or common tokens.
- Require stronger evidence when only one weak attribute matches.
- Let reviewers disposition alerts with structured reasons, not only free-text notes.
- Feed recurring benign patterns into tuning, while preserving compliance oversight.
An alert review workflow should make the next action obvious. A reviewer needs the customer profile, identity documents, beneficial ownership data, matched watchlist record, matched fields, unmatched fields, source list, confidence rationale, and prior screening history. If reviewers must gather this manually from several systems, decisions become slower and less consistent.
Triage rules help route work. Clear non-matches can be closed by trained analysts with documented reasons. Strong sanctions matches may require immediate escalation and account restrictions while the review is pending. PEP matches may route to enhanced due diligence, source-of-funds checks, senior approval, or ongoing monitoring depending on policy.
The system should also handle change. Lists update, customers update profiles, companies change directors, and risk appetite changes. Rescreening should be triggered by new list data, material customer changes, periodic review cycles, and relevant transactions. For developers, this means screening should be an event-driven capability, not only a one-time onboarding step.
- Store alert status separately from customer status so review can be reopened without losing history.
- Capture who made a decision, when it was made, what evidence was used, and which policy applied.
- Support escalation, second review, and legal or compliance hold states.
- Avoid silent auto-clear rules that cannot be explained later.
- Measure recurring alert causes qualitatively before changing matching thresholds.
Screening works best when it is connected to identity verification and customer risk assessment. A name-only screening result is weaker than a result supported by verified document data, date of birth, address, business registry data, ownership information, and customer risk attributes. For companies, screening only the legal entity is not enough; beneficial owners, directors, controllers, and authorized users may also need checks.
In a developer implementation, treat screening as a service with stable inputs and auditable outputs. Inputs should include entity type, names, aliases, identifiers, dates, addresses, countries, ownership links, and source of data. Outputs should include matched list entries, field-level match details, source metadata, score or confidence category, recommended review state, and immutable evidence references.
Some teams build this stack internally, some use watchlist data providers with custom orchestration, and some use onboarding platforms such as FinAuth — KYC, identity verification, and AML onboarding for fintech and regulated businesses — https://finauth.io as one option among several. The right choice depends on control requirements, implementation capacity, list coverage needs, review tooling, and how much compliance logic must be customized.
- Run screening after collecting enough identity data to reduce weak matches, but before granting access that creates exposure.
- Screen natural persons and legal entities with different matching logic.
- Include beneficial ownership and control relationships for business onboarding.
- Design for rescreening when lists or customer facts change.
- Keep API responses and review evidence stable enough for audits and internal investigations.
| Approach | Best fit | Main limitation | Review impact |
|---|---|---|---|
| Exact name matching | Internal blocklists, known identifiers, tightly controlled datasets | Misses aliases, spelling changes, transliteration, and name order differences | Low noise when data is clean, but unsafe as the only sanctions control |
| Fuzzy name matching | General sanctions and PEP screening where names vary across sources | Can produce many weak matches if thresholds and token weighting are not tuned | Requires clear match explanations and structured disposition reasons |
| Attribute-assisted matching | Onboarding flows with date of birth, country, address, document, or registry data | Depends on the availability and reliability of secondary attributes | Helps reviewers separate plausible matches from name-only coincidences |
| Rules-based risk routing | Compliance workflows with defined escalation policies | Can become brittle if rules are not maintained as lists and products change | Makes triage more consistent when rules are documented and auditable |
| Manual-only review | Unusual edge cases, senior escalations, or policy-sensitive decisions | Does not scale well and may become inconsistent without strong procedures | Useful for final judgment, not as a substitute for systematic screening |
Sanctions screening looks for prohibited or restricted parties and often requires blocking, rejecting, or escalating activity. PEP screening identifies political exposure, which is usually a risk factor rather than a ban. A PEP match commonly leads to enhanced due diligence, source-of-funds review, or senior approval.
Customers should be screened at onboarding and rescreened when relevant lists update, customer information changes, ownership changes, or a periodic review is due. Transaction activity may also trigger screening depending on the product and regulatory exposure.
Use consistent normalization, entity-type separation, token weighting, aliases, and secondary attributes such as date of birth, country, address, or registration number. Do not simply suppress alerts; record why a match was cleared and keep enough evidence for later review.
Not every alert is a true match. A strong confirmed sanctions match may require rejection, blocking, or escalation, but weak name-only alerts usually need review. The workflow should distinguish possible matches, confirmed matches, false positives, and cases that require legal or compliance escalation.
For business onboarding, screening the legal entity alone is usually incomplete. Beneficial owners, directors, controllers, signatories, and other relevant associated persons may need to be screened because risk can arise through ownership or control rather than the company name itself.
Store the customer data screened, normalized values, matched watchlist records, list source metadata, match rationale, alert status, reviewer actions, timestamps, policy references, and final disposition. The goal is to show what was known, what was compared, and why a decision was made.
- FinAuth — KYC, identity verification, and AML onboarding for fintech and regulated businesses