Most compliance desks we talk to treat PEP and sanctions lists as “already solved”. Probe a bit deeper and you find the opposite: the stack is fragile, the data is stale, matching produces gross false positives, and rescreening does not exist. This is the area regulators look at first, and where most fines come from.
What is at stake
PEP (Politically Exposed Person) is someone who holds, has held, or is close to someone who holds a relevant public office. They are not banned from holding an account, they are clients that demand enhanced monitoring because the statistical risk of involvement in laundering or corruption is higher.
Sanctions lists (sanctions, terrorism, narcotics, money laundering) contain clients or counterparties your institution cannot serve, under penalty of direct legal violation and exposure to multi-million-dollar fines. UN, EU, and local sanctions lists are published by the relevant bodies, and they change every day.
The PEP + sanctions combination is the minimum check for any serious RegTech onboarding. And it is where most institutions stumble.
The five real problems
1. Stale data
Official lists are updated by the issuing bodies daily. If your institution runs weekly or monthly updates, you have sanctioned clients on the books, and that, legally, is your problem.
Mature programs run automated daily ingestion of official sources, with logs of when each list was updated and which version was active when the client was screened.
2. Fragile matching
Name is the worst identifier in the world: there are millions of “João Silva”. Systems that rely on exact match only miss 80% of real hits (because “Joao Silva” without the accent already escapes). Systems that rely on fuzzy match only generate a lake of false positives where the analyst drowns.
Good matching combines:
- Exact match with high priority.
- Phonetic match (Soundex, Metaphone) for spelling variations.
- Fuzzy match (Levenshtein) with a calibrated threshold.
- Structured match: name + date of birth + country of nationality.
- Transliterated match: Arabic, Russian, Chinese names transliterated differently across lists.
And it returns a confidence level, not a yes/no.
3. No rescreening
A client who was clean at onboarding can become a PEP two months later (appointed to public office). A client can be sanctioned after becoming a client (regime change, added to a new list). If you only screen at onboarding, you have ghost clients on the books.
Best practices:
- Overnight rescreening of the ENTIRE base against the day’s updated lists.
- Automated alert when a new match appears.
- Case opened for the decision desk, without depending on manual operation.
4. False positives without governance
The desk marks the case as “not the same João Silva”. Great. But does the system remember that decision? When the name shows up again tomorrow, will it generate the same alert? In fragile programs, yes, and the analyst redoes the work. In mature programs, decisions become institutional knowledge: the alert does not fire for a match already reviewed and dismissed.
5. Ultimate beneficial owners (UBO) ignored
Screening only the direct client is half the job. The client is a legal entity, but the owner hidden through a holding is a PEP, and nobody saw it. Good KYB discovers UBO down the chain to the real point of control, and every UBO discovered goes through the same PEP and sanctions check.
How to handle it at scale
Scale changes the equation. A team with 500 clients can solve it by hand. A team with 50,000 or 5 million needs architecture.
The essential building blocks:
- Unified source: lists arrive via API or automated feed, are normalized into an internal schema, and the matching engine consumes that schema. Whether the source changes format, your desk does not feel it.
- Matching as a service: the same service serves onboarding, continuous monitoring, rescreening, and ad-hoc queries. No duplicated logic.
- Review workflow: the alert lands in a queue with calibrated priority (high-rank PEP, critical sanction, high value), is reviewed by an analyst, and the decision is logged with a reason.
- Complete audit trail: every alert, decision, list consulted, and engine version is recorded with a timestamp for audit and regulator use.
The cost of not doing it
A single sanctioned client slipping through costs, on average, several times the compliance program’s annual budget between fines, administrative proceedings, and reputational damage. And the risk is binary: you are not punished by the number of errors, you are punished for ONE error.
This is not the place to cut corners.
Conclusion
PEP and sanctions are a data engineering problem disguised as a compliance problem. Those who treat it that way, with an ingestion pipeline, a configurable matching engine, false positive governance, and an audit trail, have no surprises. Those who treat it as a checklist item, do.
Guardline treats sanctions lists as critical infrastructure. Daily updates, calibrated matching, decision governance, and audit trail by default. Want to see the engine running against your base? Book a demo.