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 September 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, EU, UN, UK OFSI 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 — 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, replayable records of what was checked against which list version, with tamper evidence. Regulators and banking partners ask for this by name.
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 | Build in-house | Buy (screening API) |
|---|---|---|
| Initial engineering | 2–4 engineers × 3–6 months for a credible v1 | Integration in days to weeks |
| Ongoing pipeline maintenance | Permanent on-call surface over external publishers you don't control | Vendor's problem, covered by SLA |
| Match tuning & QA | Requires labeled test data and analyst feedback loops you must construct | Pre-tuned, benchmarked across customer base |
| Audit evidence | You design the ledger, then defend its design to auditors | Verifiable artifacts (e.g., hash certificates) included |
| Regulatory change response | Your team tracks every regime change | Vendor ships list and logic updates centrally |
| Unit economics at scale | Fixed team cost; wins at very high volume | Per-call pricing; wins below ~millions of screens/month |
The crossover point surprises most teams: unless you screen at massive scale, a dedicated team's fully-loaded cost exceeds API spend for years — before counting the risk cost of the period where your v1 is weaker than a mature engine.
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, in this order:
- List coverage and freshness. Which authorities, what update lag after official publication, what happens when a publisher changes format mid-week.
- Match quality evidence. Not marketing claims — benchmark methodology, false-positive rates at stated thresholds, script coverage.
- Ownership analysis. Named-party matching only, or graph-based 50 Percent Rule support.
- Audit artifacts. Replayable records, tamper evidence, public verifiability a banking partner can check without your help.
- API operability. Latency percentiles (not averages), rate limits, idempotency, sandbox, and what a 429 looks like at 2 a.m.
Ask for all five in writing before procurement. The vendors worth buying answer quickly.
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/UN formats, ownership-graph analysis for the 50 Percent Rule, and replayable audit evidence. Teams that start with exact-match typically rebuild within a year once false negatives surface 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 where most build projects underestimate cost by an order of magnitude.
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, most builders buy list-aggregation feeds and build only the matching and workflow layers.
Technical architecture guides, API benchmark reports, and sub-millisecond screening research published by Sanctix Core Engineering.
