Build vs Buy Sanctions Screening: A Framework for Compliance Leaders
New! Listen to Concept to Cloud - Real stories from the trenches of software engineering
RegTech & Compliance

Build vs Buy Sanctions Screening: A Compliance Leader's Framework

TB
Tom Barber
July 9, 2026
0 min read

The right answer is almost never pure build or pure buy. It is a hybrid, and the way you draw the line determines whether your platform survives an OFAC audit and whether the vendor bill stops eating your budget.

Short answer. Buy the commodity pieces (list ingestion, fuzzy name matching, watchlist mirroring). Build the pieces that touch your risk methodology, your workflow, or your evidence chain (case adjudication, scoring, reporting, exceptions). The all-in-one vendor package is expensive precisely because you are paying for the parts you already have, and the pure in-house build is risky precisely because you are re-implementing the parts the vendors have been hardening for 15 years. The hybrid is the answer for almost every compliance team we work with.

That is the short version. The reason it is the short version and not the whole answer is that “hybrid” hides three or four decisions that regulators, auditors, and your CFO will each grade differently. This is the framework we use when a compliance leader asks us how to think about it, based on the sanctions-compliance platform we built for a global financial-crime advisory that is now live across 20+ financial institutions.

What you are actually deciding

Before you can decide build versus buy, get clear on what “sanctions screening” actually means in your organisation. In most compliance shops it collapses at least six distinct capabilities into one word:

  1. List ingestion and normalisation. Pulling OFAC SDN, EU consolidated, UN, HMT, and any secondary sanctions lists in a machine-readable form, deduplicating, resolving alias structures.
  2. Watchlist matching. Fuzzy string matching against payment messages, KYC records, or transaction counterparties, with configurable thresholds.
  3. Alert triage. Presenting matches to a human analyst with the context they need to disposition quickly.
  4. Case adjudication. Recording the reasoning behind a decision (true positive, false positive, escalate) with an audit-grade evidence trail.
  5. Reporting. SARs, regulatory returns, board packs, jurisdiction-specific reporting to FinCEN, FCA, OFSI, whichever regulators cover you.
  6. Model governance. Versioning the matching logic, backtesting new list versions against historical data, proving to a regulator that your threshold change did not accidentally hide true positives.

Compliance vendors sell all six as one product. That is fine when you are a mid-size bank buying a turnkey solution. It is expensive and inflexible when you are running any of the following:

  • A compliance advisory serving multiple clients with different risk frameworks
  • A neobank with a bespoke onboarding flow that does not match Actimize’s UI assumptions
  • A financial-crime platform serving several jurisdictions with different regulatory reporting requirements
  • A large bank whose adjudication workflow already lives in a case management system you are not going to rip out

In each case, three or four of the six capabilities are commodity and the other two or three are where your competitive advantage or your regulatory story lives. That is the seam.

The buy case

Buying is the right answer when your risk methodology looks like everyone else’s, your workflow is standard, and your reporting requirements are covered by what the vendor already ships. That is a lot of compliance teams, and vendors deserve the credit for making the commodity 80% of the job actually work at scale.

The strengths of the major vendors (Actimize, ComplyAdvantage, Fircosoft, LexisNexis, WorldCheck, Napier) are:

  • Coverage of the lists themselves. Their data operations pull, clean, normalise, and republish sanctions lists faster than you can, and they handle the annoying edge cases (transliterations, alias hierarchies, delisted-and-relisted individuals) that in-house teams underestimate.
  • Matching algorithms hardened over decades. The fuzzy matching in a mature vendor product is not a solved problem, but it is a well-hardened one. Rebuilding it in-house takes six to twelve months and a specialist hire before it will pass an OFAC comparison test.
  • Regulator familiarity. When your examiner sees Actimize or Fircosoft in the tooling section, they mentally check a box. That is a real, if slightly cynical, benefit.
  • SLAs and support. When the list format changes at 3am on a Sunday because OFAC pushed an emergency update, the vendor has a team that fixes it before you notice.

The weaknesses are:

  • Total cost of ownership. A mid-size implementation of any of the major platforms is $300,000 to $2.5 million per year once you count license, implementation, integration, and internal team. That number does not go down with usage.
  • Workflow rigidity. Every vendor has opinions about how a case should be adjudicated, and those opinions are not always yours. Bending the tool to fit is the source of most of the pain.
  • Data lock-in. Your case history, your adjudication reasoning, your model backtest data all live in the vendor’s schema. Migrating away is a two-year project.
  • Innovation ceiling. If your risk methodology gets sharper than the vendor’s product roadmap, you are stuck.

The buy case is strongest when you are small enough that the fixed cost is manageable, standard enough that the vendor UX fits, and stable enough that lock-in is not going to bite you in five years.

The build case

Building is the right answer when the commodity capabilities are not your problem, the differentiated capabilities are, and you have the engineering capacity to maintain financial-grade software over a long horizon. That is a smaller set of teams, but it is the set we most often see reaching out to us.

The strengths of build are:

  • Fit. Your adjudication workflow, your risk scoring, your reporting all match the way your compliance team actually thinks, rather than the way an Israeli or American vendor thought about compliance in 2007.
  • Economics that scale with usage. A well-built in-house platform’s marginal cost per screened transaction is close to zero. Vendor pricing rarely gets close.
  • No lock-in. You control the schema, the data, the model, the evidence chain. You can extend, refactor, or migrate at will.
  • Innovation ceiling as high as your engineering team. If your risk team wants to try a new scoring approach next quarter, you can ship it in a quarter. With a vendor, that is a support ticket in a queue behind 400 other feature requests.

The weaknesses are:

  • Six to twelve months to first regulator-passable version, minimum. Every compliance team underestimates this. Reference implementations we have built for clients ran 8 months for the core screening engine, 4 more months for the adjudication and reporting layer.
  • You now own the OFAC list ingestion problem forever. OFAC pushes emergency updates, EU sanctions lists move, HMT tweaks its format, UN changes its XML schema. That is a permanent team, not a one-time build.
  • Model governance is on you. Every threshold change, every new matching algorithm, every list version is now an artefact you have to version, backtest, and defend in audit.
  • Recruitment and retention. Compliance engineers who can build screening at bank scale are rare. Losing your two senior ones is an existential risk to the platform.

The build case is strongest when your risk methodology is genuinely differentiated, your engineering team has the maturity to run production financial software for a decade, and your unit economics justify the fixed investment.

The hybrid case (this is almost always the answer)

The team we most commonly see winning is the one that draws a line down the middle of the six capabilities above:

  • Buy list ingestion, watchlist matching, and (in some cases) alert generation. Use a vendor API or one of the emerging commodity providers (ComplyAdvantage, Sanctions.io, OpenSanctions) as the raw match layer.
  • Build case adjudication, scoring, evidence chain, reporting, and model governance. This is where your competitive advantage and your regulatory story live.

The commercial argument for the hybrid is that you push the OFAC-list treadmill onto a vendor whose entire company exists to run it, while keeping the pieces that touch your risk methodology in code you can change. The regulatory argument is that your evidence chain and adjudication reasoning stay inside a system your compliance team designed, which is the part regulators actually care about.

The technical shape of a hybrid platform is usually:

  1. A thin ingestion layer that calls the vendor’s API (or streams its list updates) and normalises into your internal schema.
  2. Your own matching engine that runs vendor matches plus your custom risk scoring against your KYC/transaction data.
  3. Your own case queue and adjudication UI, with your workflow and your evidence template.
  4. Your own reporting layer that generates the regulator-facing artefacts in the format each regulator expects.
  5. Your own model governance harness that versions threshold changes and backtests against historical alerts.

That is a 6 to 9 month build for the differentiated parts, if you have a team that has done it before. It is 18 months if you are learning it as you go, which is the failure mode most in-house teams fall into.

The cost model

This is the part where the vendor bakeoff usually collapses. A comparable-scope build/buy/hybrid comparison for a mid-size compliance team looks roughly like this (all figures are directional and depend heavily on scope):

  • Pure buy, mid-size vendor: $500,000 to $1.5 million per year all-in (license, implementation team, integration cost, internal admin). Predictable but sticky.
  • Pure build, senior in-house team: $1 million to $2 million in year one (2 to 3 senior engineers plus product plus infrastructure), $500,000 to $900,000 per year ongoing. High capacity to scale usage without cost curve, high recruitment risk.
  • Hybrid with vendor list layer + custom platform: $400,000 to $750,000 in year one (vendor license + 1 to 2 senior engineers to build the custom layer), $200,000 to $450,000 per year ongoing. Best of both, but requires deliberate seam design.

The comparison that changes minds is not year one, it is year five. Pure-buy TCO over five years lands somewhere between $2.5 million and $7.5 million with almost none of that going into an asset you own. Hybrid TCO over five years lands closer to $1.5 million to $2.5 million with a platform, a schema, and an adjudication history that are yours.

What the regulators actually care about

An examiner does not care whether you built or bought. An examiner cares about four things:

  1. Coverage. Can you show every relevant sanctions list is being screened against every relevant transaction, with time-stamped evidence.
  2. Model governance. Every threshold, every algorithm, every list version is versioned, and you can prove the trail.
  3. Adjudication quality. Every alert has a documented outcome with a reasoned decision.
  4. Escalation. When a true positive is found, the path from analyst to compliance officer to law enforcement (where applicable) is clear.

Every one of those is achievable with a hybrid platform, and the deciding factor is not the technology but the process discipline around it. We have seen pure-buy shops fail examinations because their case adjudication reasoning was thin, and we have seen pure-build shops pass with flying colours because their evidence chain was rigorous. The build/buy line is not what determines the outcome.

A decision framework

We use a five-question triage when a compliance leader asks us where to draw the line:

  1. How differentiated is your risk methodology from your peers? If the answer is “same as every other retail bank,” lean buy. If the answer is “we serve five jurisdictions with three different regulatory regimes,” lean hybrid or build.
  2. Do you have or can you hire the engineering capacity to run production financial software for the next decade? If not, buy or hybrid. Build is not a one-year commitment.
  3. How much of your commercial value depends on your compliance UX? If your operating model requires proprietary workflow (compliance advisory, RegTech vendor, high-touch KYC), build the workflow, buy the data.
  4. What is your five-year cost trajectory under pure-buy pricing? If it grows faster than your revenue, the hybrid or build economics start to bite immediately.
  5. What is your appetite for lock-in? If a five-year migration off Actimize sounds fine, buy. If it sounds catastrophic, hybrid.

If four or more of those answers point to hybrid, that is your answer.

When to bring in outside help

We think about this in three phases:

  • Pre-decision. A technical due diligence engagement (our Technical Read) that specifically covers your current compliance stack, your risk methodology, and the seam you should draw, before you commit to a vendor RFP or a build spec. If you would rather scope this yourself first, the pre-acquisition tech diligence checklist walks the same seven-section audit as a free PDF.
  • Build. If you decide hybrid or build, the fastest failure mode is scoping the engineering effort like a normal product build rather than like regulated software. We build compliance platforms specifically for RegTech teams with the audit trail, deterministic reruns, and model governance baked in from day one.
  • Post-implementation. Sanctions screening is not a one-time build. Ongoing engineering support (fractional CTO cover, model governance reviews, list-format regression testing) is how you keep the platform passing exams year after year.

If you are inside a PE-owned business making this decision post-close, the technology choice is one of the biggest levers on unit economics for the next five years. Get it wrong and you are locked into a rising vendor bill for the hold period. Get it right and you have a platform that scales with the portfolio company’s revenue without a step function on the cost side. That is worth a proper diligence pass before you commit.

Further reading

TB
Written by Tom Barber

Ex-NASA engineer and cloud architect with over a decade of experience building scalable systems for startups and enterprises.

Work with Tom →

Related Articles

Private Equity

The Operating Partner's Technology Playbook: From Close to Exit

How PE operating partners should think about technology as a value-creation lever. What to read in diligence, what to do in the first 100 days, what to leave alone during hold, and what to fix before exit.

Read More →
Cloud Architecture

What to Use Instead of AWS QLDB: An Audit-Grade Ledger in Postgres

AWS quietly killed Quantum Ledger Database, and its own migration advice points at Postgres. Here's the append-only, audit-grade ledger we actually build there, what you get for free, and the one thing you have to add back by hand.

Read More →
Strategy

The Essential Guide to Cloud Migration: Navigating Your Digital Transformation

A comprehensive cloud migration roadmap for 2025, covering foundational assessment through legacy system decommissioning, migration strategies, planning, execution, and long-term success factors.

Read More →

Ready to Build Your Product?

Let's discuss how we can help you bring your vision to life with expert cloud solutions

Get Started