Build vs Buy Sanctions Screening: 2026 Guide

Every engineering team facing sanctions requirements asks the same question first: can't we just download the lists and check names ourselves? This post gives you the framework to answer that honestly, including the cases where building is right.

LEGAL & REGULATORY NOTICE This document reflects publicly available regulatory and engineering practice as of October 2026. It is intended for educational purposes and does not constitute legal advice.

1. What "Build" Actually Entails

A production screening system has five layers, and teams consistently budget for two of them:

List ingestion. OFAC, the EU, the UN, the UK (UK Sanctions List) and others publish in different formats (XML, CSV, bespoke schemas) on independent schedules, sometimes multiple updates per week, with no advance notice. Each format change is a pipeline incident.
Normalization. Aliases, transliterations, dates of birth in a dozen formats, vessel IMO numbers, corporate registration IDs, phone numbers and email addresses (a renamed supplier in our Pegasus breakdown kept its listed phone number), all unified into one searchable entity model.
Matching. Fuzzy name matching tuned per script and language family, plus threshold calibration: every threshold choice trades false positives (analyst workload) against false negatives (enforcement exposure). See our fuzzy matching architecture.
Ownership analysis. The OFAC 50 Percent Rule means screening the named party is insufficient: you need graph traversal over ownership data your lists don't ship with.
Audit evidence. Timestamped records of what was checked against which list version, with a fingerprint that shows a record has not changed since it was saved. This is what an auditor or a bank will ask to see.

Layers 1 and 5 are where build projects die: unglamorous, perpetual, and the first things examined in an audit.

2. The True Cost Comparison

Cost center	If you build in-house	Question to ask any vendor
Initial engineering	Several engineers for several months before a credible first version	How long does a typical integration take, and what does it need from us?
Ongoing pipeline maintenance	A permanent on-call duty for list publishers you don't control	What happens when a publisher changes its format, and is that covered by a written service level?
Match tuning and QA	Labeled test data and analyst feedback loops you must build yourself	Will you run our own test names, including known matches, before we sign?
Audit evidence	You design the record-keeping, then defend its design to auditors	What does a saved screening record contain, and how can a third party check it?
Regulatory change response	Your team tracks every change to every regime	How and when do new programs and list changes reach the product?
Unit economics at scale	A fixed team cost that pays off only at high volume	What do our real volumes, including rescreening, cost per month, with overage?

Compare a fixed team cost against per-call pricing for your own volumes, and count the period when an in-house first version is weaker than a mature engine. Published API plan allowances and overage rates give a baseline for the per-call side.

3. Real-Time vs Batch Shapes the Decision

Your architecture need changes the calculus (see real-time vs batch):

Real-time inline screening (payments, onboarding) demands sub-second latency in your request path. Buying a low-latency API is usually cheaper than operating a globally replicated matching cluster.
Batch rescreening of an existing book is easier to build, but the list-ingestion and evidence layers still apply in full.

Many teams land on a hybrid: buy the screening API for decisions, build the workflow (case management, escalation, record-keeping integration) in-house. That split puts vendor capability where the regulatory risk is highest and your engineers where your business logic lives.

4. When Building Is the Right Call

Build when at least one is true:

Screening is your product. You sell compliance tooling; the matcher is your moat.
Volume economics favor it. You run high-single-digit millions of screens monthly and can amortize a team.
Data cannot leave your boundary. Residency or contractual constraints forbid external screening calls. (Even here, consider buying list-aggregation feeds and building only matching.)

And if you build: buy the audit-evidence design review from outside. The team that built the ledger should not be the only party that ever evaluated it: auditors will ask who else looked.

5. Evaluating a Vendor (If You Buy)

Score vendors on the same five layers: list coverage and freshness, match quality evidence, how they handle ownership, audit records, and API operability. Ask for every answer in writing before procurement. Our screening software buyer's guide turns this into twelve criteria and the demo questions that test them.

Frequently asked questions

Can a simple exact-match check against a downloaded SDN list work?

Only as a demo. Production screening needs fuzzy matching (transliteration variants, name order, aliases), daily list ingestion with normalization across OFAC, EU and UN formats, a way to handle the 50 Percent Rule, and audit records you can reproduce. Exact matching misses spelling and transliteration variants, so its gaps tend to show up as false negatives in testing.

What is the hardest part of building screening in-house?

Not the first version: list ingestion and normalization. Every authority publishes in different formats on different schedules with different identifier schemes, and all of them change without notice. The ongoing pipeline maintenance, plus tuning match thresholds against measured false-positive rates, is the cost build projects most often underestimate.

When does building in-house make sense?

When screening is a core differentiator (you sell compliance tooling yourself), when volumes are enormous enough that per-call pricing exceeds a dedicated team's cost, or when data-residency constraints forbid external calls. Even then, consider buying list-aggregation feeds and building only the matching and workflow layers.