PEP screening without a paid feed: a practical OpenSanctions setup

Politically exposed persons are not criminals by definition. The reason regulators single them out is risk of position: someone holding or close to public office has more opportunity for bribery, embezzlement and undue influence, so the EU AML framework requires enhanced due diligence when a customer — or a customer's beneficial owner — is a PEP.

For a business onboarding team that means every declared director and every beneficial owner has to be screened. The question is how, and at what cost.

The cost problem for small EMIs

Commercial PEP and sanctions data feeds are priced for tier-one banks. For a small electronic money institution or a young neobank onboarding a few hundred businesses a month, a per-query or six-figure annual feed is hard to justify — and the temptation is to under-screen, or to screen only the customer-facing director and skip the ownership chain. Both are exactly the gaps an examiner looks for.

OpenSanctions as the alternative

OpenSanctions is an open dataset that consolidates official sanctions lists — the EU Financial Sanctions File, OFAC's SDN list, the UN Security Council consolidated list, the UK HMT list, the Swiss SECO list — alongside a PEP dataset of several hundred thousand entities sourced from public registers and structured data.

It is free, it is openly licensed, and it is the same underlying data many commercial products repackage. For a small institution it is a credible foundation for screening, provided you handle the matching properly.

The matching pitfalls

Raw list data is not a screening system. The hard part is deciding whether a name on a list is your customer.

Transliteration. Names from non-Latin scripts arrive in multiple romanisations. "Aleksandr", "Alexander" and "Oleksandr" can be the same person or three different people. Exact string matching misses real hits; loose matching drowns you in false positives.

False positives. Common names match constantly. A screening result that flags every "Maria Silva" is a result nobody reads. Matches need corroboration — date of birth, nationality, an identifier — before they are worth a reviewer's time.

Disambiguation by date of birth. A name match against a PEP born in 1850 is a historical-figure collision, not your customer. A date-of-birth gate that drops matches with an implausible age difference removes a large share of the noise automatically.

Staleness. Sanctions lists change constantly. Screening against a snapshot from three months ago is a finding waiting to happen. The data has to refresh, and the system should refuse to trust data past a defined age rather than screen silently against stale lists.

How Veritas does it

Veritas mirrors the OpenSanctions consolidated sanctions lists and the full PEP dataset on disk and refreshes them nightly. Screening runs locally against that mirror — no per-query API cost, no roundtrip latency, and a complete record of exactly which list version produced a finding.

Matching is fuzzy but corroborated: a name match is weighed against date of birth, country and identifiers before it is surfaced, and an age-plausibility gate drops historical-figure collisions. A staleness gate refuses to screen against expired data.

Every declared director and every beneficial owner is screened — not just the customer-facing name. The result is one line per person in the dossier, each with the list and match basis cited.

See the full screening pipeline → — or open the RED demo dossier, where a declared beneficial owner is an exact match against the UK sanctions list.

Related reading: KYB vs KYC — what EU neobanks actually need.