Build vs buy sanctions screening software

Choose the screening system your team can keep operating

Building sanctions screening gives your team control over ingestion, matching, and the review experience. Buying an integrated screening product gives you an existing API, review workspace, and evidence workflow to evaluate. In either case, your organization owns its coverage requirements, customer identity data, review policy, and business decisions.

The useful build-versus-buy question is whether you want to maintain the screening system as a product of your own. A successful name lookup is only one part: the workflow must also handle a changed source file, an uncertain identity, an unavailable list, a reviewer handoff, and a later request for evidence.

This analysis compares responsibilities, not measured implementation time or savings. For a three-way purchasing comparison that also includes manual searches, see manual lookup, internal development, and screening software.

Compare the work behind the API

Use this responsibility map with engineering, compliance, and whoever will operate the service. An internal implementation can provide every capability below if your team funds and maintains it. The SanctionsKit column describes its documented product workflow; production availability and your own acceptance criteria still need verification.

Data maintenance continues after the first import

OFAC makes its SDN and consolidated non-SDN data available through its Sanctions List Service. Access to published data is a starting point for a screening implementation. It does not supply your application’s parser validation, scheduled imports, source-version history, or response when a refresh fails.

For a build, identify the owner of each required source, its usage terms, supported formats, and refresh procedure. Preserve original artifacts and list identities, detect unexpected schema or record changes, and define when stale or failed data stops a screening. Budget maintenance for every required source, not just the simplest feed.

For a purchase, inspect the same evidence rather than counting logos on a coverage page. SanctionsKit distinguishes implementation, fixture testing, live-fetch testing, rights approval, and activation. Check current coverage and source discovery; an unavailable required source must leave the operation incomplete instead of becoming a no-match result.

Matching quality needs a test set and an explanation

A matcher must retrieve relevant candidates and provide enough context for a reviewer to investigate them. Evaluate original scripts, aliases, reordered names, partial dates, missing fields, and typed identifiers using an authorized test set that reflects your intended workflow. Record expected candidates and known different identities before running the evaluation.

Use the same subjects, source scope, and expected outcomes when comparing a build with a product. Track missed expected candidates and unnecessary alerts separately. A lower alert count alone does not prove better matching, and a similarity score is not a probability of identity or wrongdoing.

SanctionsKit publishes its matching methodology and screening-testing guide. Start with synthetic examples to verify result handling. Quality for your production population requires a separate authorized evaluation; the demo is not a performance benchmark.

Budget for the analyst workflow and retained evidence

Ask a reviewer to follow one potential match from the application to a finished case. They need the submitted identity, each candidate’s source evidence, recorded reasoning, unresolved questions, and any required independent approval. The identity conclusion and the decision about the business relationship are separate records.

An internal build must connect those records and control who can view or change them. SanctionsKit connects retained API results to case review in the included dashboard, with candidate decisions and a separate business disposition. Verify the retention policy before relying on the result for later review.

Test an evidence export as part of the evaluation: can another authorized reviewer understand what was checked, when, against which source versions, and why the decision was made? An exported file needs your own approved storage and access controls. Neither an export nor a no-match result is a general clearance certificate.

Estimate total operating cost with your own workload

Compare the same planning period and the same scope. For an internal build, include initial engineering plus recurring source maintenance, infrastructure, matching evaluation, security, reviewer time, and incident response. For a product, include the subscription, integration, vendor review, reviewer time, retention needs, and your own operational work.

A useful worksheet is: initial work + recurring service and infrastructure charges + maintenance effort + review effort. Keep one-time and recurring costs separate, use your own labor rates, and record assumptions. The formula is a planning model, not a claim that either option is cheaper.

As a fictional workload, 2,000 newly screened subjects plus 500 retained subjects screened four times each produces 4,000 planned subject screenings, before corrections or other rescreens. Cases and HTTP requests are different units. Check current plan allowances and the screening API cost guide, then measure actual usage during an authorized evaluation.

Choose build when control justifies continuing ownership

An internal system can be a sensible choice when unusual data, deployment, or workflow requirements cannot be met by a product and the organization will fund a team to operate it. Make the recurring ownership explicit: who responds when a publisher changes a format, an evaluation fails, or the reviewer queue stops advancing?

An integrated product is worth evaluating when your application needs a screening boundary and your analysts need an existing review workspace. SanctionsKit is designed for that API-and-dashboard handoff. Your application still controls the customer journey, and your team still decides which sources, evidence, and approvals its process requires.

• Engineering signs off on integration, error recovery, access controls, and observability.
• Compliance signs off on required coverage, identity review, and decision records.
• Operations signs off on ownership, escalation, support expectations, and ongoing cost.

Run a bounded evaluation before committing

Create a free synthetic sandbox workspace, follow the API quickstart, and ask an analyst to open the resulting case. Keep all evaluation subjects invented until the organization authorizes a production test. The sandbox needs no credit card and does not screen live sanctions lists.

Frequently asked questions