PEP/Sanctions Lists: Screening

1) Why PEP/sanction screening in iGaming

Screening is a basic compliance loop: it prevents work with prohibited persons/organizations and reduces the risk of regulatory sanctions, freezing payment channels and blocking banks/PSPs. At iGaming (MCC 7995), it complements KYC/KYB and AML monitoring and directly impacts payment infrastructure availability and withdrawal speed.

2) List sources and types

Sanctions lists: international (UN), supranational/regional (EU, UK), national (US OFAC, as well as local registers).
PEP (Politically Exposed Persons): current/former public officials + relatives and close related persons.
Adverse Media (negative media): criminal investigations, fraud, corruption, etc. - an auxiliary layer.
De facto bans and trade embargoes: countries, sectors, assets.
Crypto addresses with sanctions tags: exchanges/wallets/mixers, high KYT risk.

3) When and who to screen (ASC/ESC/surgery)

KYC (individuals): during registration (Tier 1), before the first withdrawal, when upgrading to Tier 2/3, when changing the full name/address/document, daily rescreening.
KYB (legal entity): company, directors/officers, UBO; onboarding, structure updates, scheduled rescreening every 6-12 months.
Operational events: large deposits/withdrawals (threshold triggers), geo/device change, risk growth in AML.

4) Data quality and normalization (before matches)

Normalization of full name: register, spaces, diacritics, transliteration (GOST/ISO/national rules), alternative forms (Aleksandr/Alexander).
Dates of birth: formats' DD/MM/YYYY'vs' YYYY-MM-DD ', error ± 1 day (document errors).
Addresses: countries/regions in ISO-codifications, city directories.
Organizations: legal form (LLC/Ltd/AO), aliases/former names, registration numbers.
Crypto: normalization of addresses and providers (exchanges, custodians), networks/chain.

5) Matching: accurate, fuzzy and false positive reduction

• Exact match by ID: Passport/Reg. number, date/place of birth, company registration number.
• Fuzzy match (distance algorithms: Levenshtein, Jaro-Winkler) with thresholds for similarity.
• Aliases/AKAs: matching by alternative names, maiden names, Latin/Cyrillic.

• Require at least two independent characteristics to match (name + date of birth/name + country/document number).
• Alert deduplication (consolidation of matches per person/company).
• Geofilters and context (country of birth vs current residence).
• Allow-lists for confirmed "false matches" with an expiration date.

6) Classification of alerts and prioritization

Choose the fuzzy match threshold by market/language (for Cyrillic - slightly higher, given transliteration).

7) Review process (workflow)

1. Enrichment: tighten customer/counterparty data (KYC/KYB, geo, payments).
2. Source verification: verify the entry in the registry/aggregator (relevance, date of update).
3. Decision making: Approve (false match), EDD/limits, Reject/Freeze.
4. Documentation: reason, used mapping fields, references to sources, solution validity (for allow-list).
5. Communication: request documents/explanations, compliance with the tipping-off prohibition in SAR.

• High: ≤ 4 h (critical interlocks)
• Medium: ≤ 24 ч
• Low: ≤ 72 h

8) Rescreening and events (event-driven)

Daily: automatic run of all active profiles/counterparties.
On-demand: when changing the name/address/document/UBO/directors, with large conclusions, with AML alerts.
List versioning: fix the date/source version in the logs to reproduce the solution in a year.

9) Integration with KYB/KYC/AML/Payments

KYC/KYB: screening at onboarding and at any level upgrade.
AML monitoring: positive screening increases alert priority (see Rapid In-Out, Structuring).
Payments Orchestrator: automatic holds/limits at High-alerts; routing to "safe" methods.
KYT/Travel Rule: sanctions risks for crypto addresses, exchange of attributes between VASP (where applicable).

10) Data, privacy and audit

Minimization: store only the fields used for the solution; Mask document numbers.
Encryption and access: KMS/HSM, RBAC, call log; preventing uploads outside protected channels.
Retention: storage of solutions/logs according to regulation (often 5 + years).
Trail audit: who/when/what matched, what version of the list, what outcome.

11) Process metrics and qualities

Accuracy and speed

Precision/Recall by manual marking (sample), false positive rate (FP).
SLA hit rate (High/Med/Low), average time to solution (p50/p95).

Operating

The share of rescreening with a change in status, the frequency of updating lists.
Number of alerts per 1k onboarding/per 1k active customers.
Unit cost per case.

Risk/Business

Number of Stop cases (sanctions) and payments prevented.
Correlation of "positive screening" with AML incidents, chargebacks.

12) Provider selection and architecture

• Coverage: international + local lists (official sources), refresh rate.
• Match quality: customizable thresholds, support for transliterations, aliases, fuzzy.
• Performance: API latency, SLA uptime, batch mode for rescreening.
• Confidentiality/compliance: DPIA, data location, logs, certificates.
• Functions: case-management, allow/deny-lists, source versioning, web hooks.

• Screening service (microservice) + hot results cache.
• Queues for batch rescreening (night tasks).
• Case system for manual reviews, with integration into KYC/KYB/AML.

13) Decision matrix (example)

14) Anti-patterns

"Deaf" exact-match by name only - FP avalanche.
Lack of transliteration/aliases - skipping real matches.
No allow-list with expiration - the command sinks into repeated FPs.
Rare rescreening - new listings are not caught.
No logging of list versions - solutions cannot be protected during audit.
Informing the client about SAR (tipping-off) is a serious violation.

15) Implementation checklist

• Sources: international, regional and local lists + aggregator.
• Normalization of data (full names/dates/addresses/organizations / crypto), transliterations and aliasa.
• Match strategy: exact + fuzzy with custom thresholds and geo-context.
• Review Process: Roles, SLA (4h/24h/72h), Solution and Communication Templates.
• Allow/deny-lists with expiration and audit.
• Daily rescreening + on-demand events; source versioning.
• Integrations: KYC/KYB/AML, KYT/Travel Rule, Payments Orchestrator (holds/limits).
• Data/Privacy: Encryption, RBAC, Logs, Retention.
• Quality metrics and regular QA sampling; FP reduction by targeted experiments.
• Continuity plan (fallback provider, API degradation).

16) Summary

Effective PPE/sanction screening is not only about "punching through the lists." These are normalized data, flexible exact + fuzzy matching, controlled review process with priorities and SLA, daily rescreening and integration with AML/KYC/KYB/KYT. Such a circuit minimizes false positives, catches real risks, protects payment rails and accelerates legitimate conclusions - which means it supports sustainable monetization.