PEP screening: where the process breaks and what the company loses
Customer screening breaks not at database connection but at reviewing its output. Fuzzy matching returns matches by last name and year of birth — at a volume of several thousand records, this is hundreds of records per day.
The analyst reviews the first dozens, closes the rest with a formal “no match” flag, and the actual listed person passes in that tail.
The second point of failure is match quality. The same person comes in three transliterations, with a maiden name, without a patronymic, and with first and last names swapped.
Duplicates in the database are not reduced to a master record, and the match threshold is chosen at random: set it too low, and the manual match review queue grows faster than the team; set it too high, and real hits are cleared.
The third and most expensive issue is the absence of re-screening. Status is assigned on the onboarding date and never recalculated afterward: sanctions and PEP lists update, while client and counterparty records retain the previous decision.
Counterparty screening exists as a separate process with its own reference data, and the two loops do not see each other.
The company learns about the discrepancy from a bank or regulator request — already as a violation, not as a task. All three points are closed engineering-wise: list versioning, recalculation on update event, and match review with rationale and a decision log. Let’s break down exactly how this is designed.
What well-built customer and counterparty screening delivers
Turnkey screening turns compliance from a manual process into an auditable pipeline: every client and counterparty is checked against sanctions and PEP lists, and the result is recorded with date, list version, and reason for the decision.
Sources are connected as a service: public registries and commercial databases such as OpenSanctions update on schedule, so screening runs against the current snapshot, not a month-old export.
The effect is visible in three metrics: onboarding time, the share of cases sent to manual review, and the class of matches the system does not miss.
Onboarding speed and repeat requests
Real-time screening answers a request in seconds: first a quick index check, then targeted verification of matched candidates.
A repeat query for the same counterparty does not restart the cycle — the result is reused until the list version changes or the configured validity period expires.
Onboarding stops depending on compliance team workload: a typical client is processed on the day of request rather than waiting in a queue.
Fewer manual reviews and avoided rejections
The main source of manual work is last-name matches without context.
Match scoring considers date of birth, citizenship, year of appointment to a position, and a name appearing in several lists at once, and thresholds are configured separately for PEP, sanctions lists, and adverse media.
Compliance automation reduces the false positive rate, so the analyst reviews only borderline cases — and bona fide clients are less often rejected because of a namesake.
Screening modes: one-time, scheduled, continuous
The screening mode is chosen not for convenience but by the rate of list changes and the client’s risk profile.
Sanctions lists and PEP databases update more often than a client completes onboarding, so a one-time screening result becomes outdated almost immediately after it is completed. Below are three modes and the boundaries beyond which each stops working.
| Mode | When suitable | Limitations |
|---|---|---|
| One-time screening at onboarding | low risk profile, rare transactions, long onboarding | snapshot as of date: no reaction if the client is added to a listing later |
| Scheduled re-screening of the customer base | existing base with regular activity, regulatory reporting | window of days and weeks between runs; peak load on batch processing |
| Continuous monitoring | high risk, real-time transactions | requires a stable stream of list updates and event processing without gaps |
One-time screening at onboarding
The check is performed at onboarding: name, date of birth, and document are verified against sanctions and PEP lists, and the result is recorded together with the list version and fuzzy matching settings.
This is a cheap and predictable mode, but it answers only the question “was the client on the list on the screening date”. Transaction monitoring and repeat verification are not covered here.
Continuous control and customer base re-screening
Screening becomes a flow: subscription to list updates, recalculation only of affected records, a delta run across the entire customer base, and placement of matches into the manual review queue.
Key requirements are that a repeat run does not create duplicates and every decision leaves a trail: who, when, and according to which list version cleared or confirmed a match.
One-time and continuous modes are compatible: the first covers entry, the second covers the entire customer lifetime.
How we implement: stages from audit to handover
Implementation of compliance screening begins not with loading lists but with an audit of the customer base. Without the real distribution of matches, rules are configured blindly: one set misses PEP, another produces a stream of false positives that are reviewed manually. We go from data to rules and only then to configuration.
Audit of the database and current rules
We check field completeness, duplicates, transliteration variants, and document quality. We separately review the log of past matches: how many matches were closed manually and on what attributes — this shows where the rules do not work.
Match scheme and review queues
We break rules down by strictness levels: exact document match, name together with date of birth, and fuzzy transliteration comparison. Each level has its own threshold and review queue: blocking check, manual review, or automatic closure with rationale.
- Audit of the customer base: volume, field completeness, duplicates, transliteration quality.
- Inventory of current rules and the match log — what went to manual review and why.
- Match rule scheme: strictness levels, thresholds, review queues.
- Configuration: connecting lists, reference data, source update schedule.
- Testing on historical data: run past clients, measure the false positive rate.
- Calibration of thresholds based on the run results, approval of the procedure for reviewing disputed matches.
- Handover: documentation, training on review, procedure for updating lists and revising thresholds.
What we hand over: regulations, policies, settings
A project is closed not when PEP screening responds to test requests, but when your team can change rules and review disputed matches without us.
Therefore handover includes not only the service but also the operations layer: compliance procedure, access policies, screening documentation, and a decision log for every check. Below are the artifacts you work with independently.
- Compliance procedure — procedure for launching checks, match thresholds, rules for escalation to manual review, and response times by risk level.
- Access policies — roles of analyst, reviewer, and administrator, permission matrix for reference data, exports, and threshold changes.
- Screening documentation — how names are matched against sanctions and PEP lists, how to read the match score, and what to do with false positives.
- Decision log — who, when, and on what basis confirmed or cleared a match; the entry is immutable and exportable for internal control.
- Reference data — list sources, update frequency, procedure for manually adding a record.
- Acceptance checklist and support plan — how to verify operation after release and what to do when an external list is updated.
Data schema and access rules
The schema description records which fields are included in screening, which remain in the internal perimeter, and which are anonymized before export.
Access to personal data is granted not “just in case” but for a specific task and with logging — this is the first thing internal control looks at.
Case study: how we reduced the false positive rate in the flow
A case from the compliance team of a platform with a flow of onboardings and transfers: several thousand checks per day, a significant portion being individuals with cross-border ties.
Screening worked by exact string match against lists, so the queue was clogged by surname homonyms, transliteration variants, and outdated addresses, while analysts reviewed same-type signals manually.
Before and after
| Screening metric | Before | After |
|---|---|---|
| False positive rate | 74% | 18% |
| Manual review requests per day | 1200 | 260 |
| Time to clear from manual review | 40 minutes | 6 minutes |
| Review of one request by an analyst | 25 minutes | 8 minutes |
Matching was switched from exact string match to entity comparison: name with transliteration, date of birth, country, document, and roles in related companies.
PEP and sanctions lists are pulled from OpenSanctions together with local regulator lists, and match weight is calculated by the number of matching fields — a signal by last name alone no longer queues on par with a full match.
The load on compliance staff fell without expanding headcount: the queue shrank almost fivefold, and the freed-up time went to reviewing genuinely risky cases.
A human still makes the decision on every request — the system only ranks the queue, shows the match reason, and stores history for the reviewer, so the rate of missed matches did not increase.
How does one-time PEP screening differ from continuous monitoring?
One-time PEP screening is a snapshot on the date of onboarding: we compare full name, date of birth, country, and position against lists of public officials and record the conclusion.
The snapshot becomes outdated the same day the client changes position or a new revision of the list is released. FATF recommendations require not a one-time verification but a current risk profile throughout the relationship.
Continuous monitoring rests on two mechanisms: scheduled review by risk category and event triggers — list updates, position changes, publications about the client.
Each event launches reassessment: the risk category, circle of related persons, and depth of source-of-funds checks change. Without triggers, monitoring degenerates into a formal annual review that does not see changes between cycles.
The main point of divergence is a partial match. In one-time screening it is reviewed once and closed by a decision; in continuous monitoring the flow of matches arrives anew on each cycle, and without prioritization rules the queue grows in proportion to the review frequency.
Therefore names are normalized: transliteration, profile deduplication, and scoring by a set of attributes rather than a single string.
Technical concerns: data, access, limitations
Engineering objections usually concern not the idea of screening itself but its boundaries: where the data comes from, who sees it, and where the method stops working. Below are answers to those most often raised before the start.
Result quality is determined not by the comparison algorithm but by the source. Lists update at different frequencies, some records come with multilingual spelling variants and incomplete dates of birth — hence the different false positive rates.
What to do if the source data has gaps?
Screening reduces risk but does not exclude it: it works only on the connected sources. In the documentation we record which lists are connected, how often they update, and which record categories they cover.
If the required jurisdiction is not in them, this is visible before the start, not after the first check.
How is access to results segmented?
We describe roles by actions, not by departments: who launches the check, who sees a match with the source indicated, and who clears a mark manually.
Every record view and every decision enters an immutable log — a regulatory review can be passed without exporting the entire database.
What about confidentiality and record retention?
Personal data and the verdict are stored separately: the working database keeps a reference to the result, not the document itself. The retention period is set by policy — we keep history for as long as your internal procedure requires, after which it is automatically purged.
Let's discuss the task and come back with an estimate and plan
To come back with a project estimate rather than a vague range, we need input on the data and the screening process. The first step is a task review: we look at which PEP and sanctions lists you use, where screening fits in the customer journey, and who reviews the matches found.
As output you receive a solution design and a work plan with stages and acceptance criteria — they show what is done in what order and allow comparing approaches, not just timelines.
What we need from you to start and what we deliver at the first step:
- data sources: which PEP and sanctions lists are used, in what form the exports arrive, and how often they update;
- subject profile: individual, company, connections, and ownership shares — to what depth we traverse the chain;
- matching rules: match thresholds, transliteration, handling of namesakes and exact full-name matches;
- integration points: initial screening at customer onboarding, repeat screening, manual review of findings, and escalation;
- log and access: who sees findings, who confirms the decision, what enters the audit trail;
- solution design: data flow, storage, list updates, behavior when a source is unavailable;
- work plan: stages, scope of checks at each, acceptance criteria, and rollback procedure on failure.
Describe the task in free form — we will come back with an analysis, solution design, and stage-by-stage work plan.