Sanctions & PEP Screening: Build vs Buy

What sanctions and PEP screening actually is

Sanctions screening compares a person or entity against lists of individuals and organisations subject to legal restrictions — OFAC, the EU and UN consolidated lists, and others — where a match is a legal bar to transacting. PEP screening compares against lists of politically exposed persons, where a match is not a prohibition but a signal to apply enhanced due diligence.

The distinction matters because the consequences differ: a true sanctions match is a hard stop, while a PEP match changes the level of scrutiny, not the decision to proceed. Treating them identically either blocks legitimate customers or under-scrutinises risky ones.

What you are really buying: data, matching, workflow

Screening is three components stacked. Data is the lists themselves, kept current as they change. Matching is the fuzzy logic that decides whether "Mohammed Al-Rashid, 1984" is the sanctioned "M. Al-Rashid, 1982" or a different person. Workflow is what happens next: alerts, case management, escalation, four-eyes review, and the audit trail that proves a decision was made and who made it.

Buy or build is a different question for each layer — and most teams that get this wrong answer the whole thing as one.

The case for buying

• List data is a full-time operational burden: dozens of lists, updated constantly, with coverage and quality guarantees you cannot easily replicate.
• Matching quality is hard to build well; false-positive reduction is where specialist vendors have spent years of modelling.
• You get live in weeks rather than months, which matters when a licence or a partner depends on screening being in place.
• Regulators recognise established providers, which simplifies your own risk narrative.

The case for building

• Workflow and case management are specific to your risk policy, your teams and your SLAs — and generic vendor tools force you into their process.
• When compliance is your product, the alert handling, audit evidence and policy configuration are things you want to own and shape, not rent.
• Multi-entity, multi-jurisdiction and multi-tenant rules rarely fit a single vendor’s model without customisation.
• An orchestration layer lets you switch or add data providers without re-touching everything built on top.

The hybrid most regulated teams land on

The pattern that holds up is custom orchestration and workflow over best-of-breed screening data. Buy the lists and the matching engine from whoever does it best; build the layer that decides what to screen, when, at what threshold, how alerts are handled and how the decision is recorded.

This keeps provider optionality — you can add a new list source or switch vendors without a rebuild — and keeps your compliance logic where it belongs, in code you control and can prove. It is the same approach we take across compliance and trust engineering.

How to decide

• If screening is peripheral to your product and you need speed, buy end to end.
• If list data is the only need, buy the data and matching; do not build list infrastructure.
• If your risk policy, audit requirements or multi-tenancy are specific, build the orchestration and workflow layer, and buy the data underneath it.
• Whatever you choose, own the audit trail: which lists ran, at what date, with what result and what action.