Build sanctions and PEP screening into KYC and AML onboarding with practical guidance on lists, matching, false positives, and review workflows
Sanctions and politically exposed person screening looks simple from a distance: take a customer name, compare it with lists, and stop the bad matches. In practice, the hard parts are data quality, transliteration, aliases, date-of-birth gaps, entity ownership, and deciding what to do when a match is plausible but not proven.
Developers and compliance teams need to design this as a decision system, not a single API call. The system has to collect enough identity data, screen at the right points in the customer lifecycle, preserve evidence, and route uncertain results to people who can review them consistently.
This guide focuses on the mechanics: which lists matter, how matching works, why false positives happen, and how to tune a workflow without creating blind spots. It is not legal advice, and the exact obligations depend on jurisdiction, product, customer type, and risk appetite.
- Name matching and normalization for sanctions screening — Explains how to prepare names, aliases, and identifiers before fuzzy matching so screening results are defensible
- Sanctions alert triage and disposition — Shows how to investigate screening alerts, document decisions, and separate false positives from matches that need escalation
- Sanctions Screening Setup Checklist — Use this to configure or review a sanctions and PEP screening workflow before relying on its results
- Sanctions Alert Review Template — Copy and adapt these blocks to document screening inputs, alert review, and escalation decisions consistently
Sanctions screening is the process of checking a person, company, vessel, address, or related party against sanctions lists and other restrictive measures. In a KYC flow, it normally happens after the user has provided identity attributes such as legal name, date of birth, country, address, document details, and business ownership information.
A screening result should not be treated as a simple yes or no unless the match is exact and supported by enough identifiers. Many list entries are incomplete. Some contain only a name and country. Others include aliases, historical names, passport numbers, dates of birth, places of birth, program labels, and free-text notes. The more structured your customer data is, the easier it is to distinguish a true match from a name collision.
Screening also needs to happen beyond initial onboarding. Customer details change, beneficial owners may be added, and lists are updated. A practical design includes initial screening, event-based rescreening when relevant identity data changes, and periodic or list-triggered rescreening for existing customers.
- Screen individuals, businesses, beneficial owners, directors, and authorized users where relevant.
- Store the input data used for the screening decision, not only the final status.
- Separate screening status from account status so compliance decisions are auditable.
The right list set depends on where the business operates, where customers are located, what currencies or payment rails are used, and which regulators apply. Common sources include national sanctions lists, regional regimes, international bodies, law-enforcement notices, and commercial watchlist aggregations that normalize data from multiple sources.
PEP screening is related but not the same as sanctions screening. A politically exposed person is not automatically prohibited. PEP status usually triggers enhanced due diligence because the person may present a higher bribery, corruption, or misuse-of-office risk. The same is often true for close associates and family members, depending on policy and regulation.
Developers should avoid hard-coding assumptions that every list has the same meaning. A sanctions hit may require blocking, rejection, freezing, reporting, or escalation. A PEP hit usually requires review and risk assessment. An adverse media result may be supporting context rather than a standalone decision.
- Sanctions lists identify restricted persons, entities, vessels, and sometimes addresses or identifiers.
- PEP lists identify public roles, former roles, relatives, and close associates where available.
- Adverse media and enforcement data can support risk review but need careful source assessment.
- Internal deny lists should be governed like any other risk control, with reason codes and expiry rules.
Name matching combines normalization, candidate generation, scoring, and decision rules. Normalization may remove punctuation, standardize case, collapse whitespace, reorder name parts, and handle common prefixes or suffixes. Candidate generation narrows the universe of possible matches so the system can compare the customer against plausible records rather than every record.
Fuzzy matching is useful because names are written differently across languages and documents. It can catch spelling variation, missing middle names, initials, transliteration differences, and reordered family names. The trade-off is that fuzzy matching creates more false positives. A loose threshold may catch more possible matches but will also send many harmless customers to manual review.
The best matching systems use more than the name. Date of birth, nationality, place of birth, document number, address, gender, company registration number, and ownership links can all strengthen or weaken a match. A weak name similarity paired with a conflicting date of birth should not be treated the same as a strong name similarity with matching nationality and birth year.
- Use exact matching for high-confidence identifiers such as document numbers when available.
- Use fuzzy name matching for aliases, transliteration, missing tokens, and spelling variation.
- Score supporting attributes separately so reviewers can see why a result was raised.
- Keep raw and normalized values so later investigations can reproduce the match.
False positives are expected in sanctions and PEP screening. They happen because many people share names, public lists often contain limited identifiers, and transliteration creates several valid spellings for the same name. Common names, short names, patronymic naming systems, and names written in different scripts all increase ambiguity.
False positives are not only a compliance inconvenience. They can delay onboarding, create support burden, and train teams to dismiss alerts too quickly. On the other hand, tuning the system too aggressively can hide true matches. The goal is not to eliminate every false positive. The goal is to produce a review queue that is explainable, proportionate, and aligned with the organization’s risk policy.
One useful pattern is to separate alert generation from alert disposition. The screening engine can raise candidates based on configurable rules, while the case workflow records whether the candidate is a true match, false positive, potential match, or requires enhanced due diligence. Over time, those dispositions help improve rules, reviewer guidance, and data collection.
- Ask for date of birth or registration number before review when the initial match is ambiguous.
- Do not suppress matches permanently unless the reason is specific and documented.
- Use reason codes such as name mismatch, date-of-birth conflict, different country, or confirmed duplicate.
- Route higher-risk categories to reviewers with appropriate authority instead of treating all alerts equally.
A useful workflow starts with clear states. For example, a customer can be pending screening, clear, in review, rejected, blocked, or approved with enhanced due diligence. The exact labels matter less than consistency. Every automated or manual transition should have a timestamp, actor, reason, and supporting evidence.
Review screens should show the customer profile beside the matched watchlist record. Reviewers need to see names, aliases, dates, countries, documents, list source, program or category, and the match explanation. If the interface only displays a score, the reviewer has to guess why the alert exists, which weakens auditability.
For teams that prefer to integrate rather than assemble every component, screening can be part of a broader onboarding stack alongside document checks, identity verification, business verification, and case management. FinAuth — KYC, identity verification, and AML onboarding for fintech and regulated businesses — https://finauth.io is one option in that category, alongside building directly on list providers or combining separate screening, workflow, and verification tools.
- Define who can clear alerts, who can reject customers, and who can override automated decisions.
- Capture reviewer notes in structured form where possible, with free text for edge cases.
- Make rescreening outcomes visible so old decisions can be revisited when list data changes.
- Treat audit logs as part of the product requirement, not an afterthought.
Testing should cover more than happy-path exact matches. Use synthetic records that exercise aliases, swapped given and family names, missing middle names, accents, hyphens, initials, transliteration variants, company suffixes, and conflicting dates of birth. Include cases that should not match, because false-positive behavior is just as important as hit detection.
Compliance teams should review the test cases with engineering before launch. Engineers can explain how normalization and thresholds work; compliance can explain which results require escalation and which differences are enough to clear an alert. This shared review often exposes hidden assumptions, such as treating country as a hard filter when it should only be a supporting attribute.
After launch, monitor patterns in review decisions. If reviewers repeatedly clear the same type of alert, the rule may need adjustment or the onboarding flow may need to collect a better identifier earlier. If reviewers disagree on similar cases, the issue may be policy guidance rather than software.
- Create regression tests for name parsing, normalization, and scoring changes.
- Test rescreening when a list entry changes after a customer was previously cleared.
- Verify that blocked or rejected statuses cannot be overwritten by unrelated onboarding events.
- Check that exported audit evidence contains both customer data and watchlist data used at the time.
| Approach | Best fit | Main trade-off | Review impact |
|---|---|---|---|
| Exact name and identifier matching | Records with strong identifiers such as document numbers or registration numbers | Misses spelling variation and incomplete list entries | Low review volume when identifiers are reliable |
| Fuzzy name matching | Onboarding flows where names may vary across documents, scripts, or data sources | Raises more ambiguous candidates | Requires clear reviewer guidance and supporting attributes |
| Risk-based rule tuning | Products with different customer types, geographies, and transaction permissions | Can become hard to explain if rules are not documented | Routes alerts by severity instead of treating all matches the same |
| Manual review only | Small or unusual workflows where every customer is already reviewed | Slow and inconsistent without structured evidence | Depends heavily on training and audit discipline |
| Integrated KYC and AML workflow | Teams that need screening tied to identity verification, case status, and audit logs | Less flexibility than assembling every component independently | Gives reviewers more context in one place |
Sanctions screening checks whether a person or entity appears on a restrictive list that may require blocking, rejection, freezing, or reporting. PEP screening identifies people with prominent public functions, and sometimes their relatives or close associates. PEP status is usually a trigger for enhanced due diligence rather than an automatic prohibition.
Screening should happen during onboarding before the customer can use regulated services. It should also happen when relevant identity data changes, when ownership or control changes for a business, and when watchlist data is refreshed. The exact timing should match the product risk and legal obligations.
Collect stronger identifiers, use supporting attributes in match scoring, tune fuzzy thresholds carefully, and give reviewers clear reason codes. Avoid relying on name similarity alone. False positives cannot be removed entirely without creating blind spots, so the practical goal is a review queue that is explainable and manageable.
Some weak candidates can be cleared automatically when there is a strong conflicting attribute, such as a clearly different date of birth or entity type. Strong or ambiguous matches should usually go to manual review. Any automatic clearance rule should be documented, tested, and auditable.
Store the customer data submitted, normalized values used for matching, the matched list record, list source, match score or explanation, screening time, decision, reviewer identity where applicable, and reason codes. Keeping only the final pass or fail status is usually not enough to reconstruct the decision.
No. Sanctions screening checks restrictive lists. Adverse media looks for negative public information that may affect risk assessment, such as allegations, investigations, or enforcement actions. Adverse media can support enhanced due diligence, but it should be handled with source quality and relevance in mind.
- FinAuth — KYC, identity verification, and AML onboarding for fintech and regulated businesses