How to test a sanctions screening API before it becomes a production control

Most proof-of-concepts are too polite. A vendor supplies a few obvious sanctioned names; the API finds them; everyone celebrates; production begins. That is not a sanctions-screening test. It is a demonstration that a search box can find a record when given its most recognisable spelling.

A production control has to survive ambiguity, incomplete customer data, language variation, source changes, workflow failures and human review. It also has to leave a trail that another person can inspect months later. The test plan should therefore evaluate the whole decision path, not just match recall on a vendor-chosen dataset.

Short answer

Test a sanctions screening API across seven dimensions: identity and matching behaviour, source freshness/scope, candidate explanation, false-positive disposition, ownership boundaries, operational resilience, and durable evidence. Keep an independent test ledger with the inputs, expected outcome, evidence requirement and actual result. A low-latency match score is one measurement—not proof that the control is ready.

Build a test corpus that reflects your risk, not the sales demo

Start by creating a controlled test set with legal approval and careful handling of personal data. It should include synthetic or appropriately permitted examples for:

• exact legal names and clear unique identifiers;
• common names with deliberately conflicting dates, countries or registration numbers;
• aliases, transliterations, reordered names, diacritics, punctuation and abbreviated company forms;
• parent/subsidiary structures where the list result alone is insufficient;
• subjects with missing information, because production onboarding rarely arrives as a perfect record;
• previously cleared false positives relevant to your customers and geographies.

The objective is not to force every record into “match” or “no match.” The expected result may be “retrieve this candidate, identify that the date of birth conflicts, request more information and preserve the reviewer’s disposition.” That is what a usable system does under uncertainty.

The seven test areas

Separate retrieval quality from decision quality

This separation eliminates a great deal of vendor-comparison theatre.

Retrieval quality asks whether the system returns the right candidate for review. Decision quality asks whether the user had enough context and process to decide correctly. Operational quality asks whether the system works predictably under load, failure and change. A benchmark can be helpful, but only if it says exactly which of these it measures and what it does not.

For example, a high candidate-recall result says little about the analyst effort created by false positives. An impressive F1 score says little about how a stale source is exposed to a customer. A fast endpoint says nothing about whether the final clearance can be reconstructed. Track the measures separately.

Test the unhappy path deliberately

Production bugs hide in the cases teams assume will never happen:

• A source ingests late or becomes stale.
• A customer resubmits the same entity because a network timeout obscured the prior result.
• A webhook is delivered twice or arrives out of order.
• An analyst clears a candidate, then a new identifier arrives that should reopen the case.
• A dashboard user sees a status that the API consumer cannot retrieve.
• A nightly batch completion is mistaken for evidence that every required subject was reviewed.

Ask the vendor to demonstrate these paths in a sandbox with logs and exports, not with a slide deck. If the answer is “that never happens,” write a test for it.

A practical acceptance record

For each test, keep a small ledger: test ID, input version, policy expectation, result, screenshots only where necessary, API correlation ID, source state, reviewer decision and defect/status. The ledger becomes the start of your implementation assurance record. It also makes renewals and audits less dependent on whoever ran the original proof-of-concept.

Where Verifex fits

Use Verifex’s published benchmark as a starting point, not as a substitute for your own test plan. Verify the current matching methodology, live source status and API behaviour against your target workflow. The value of an evidence-preserving API is that the same test discipline can carry into production: candidates, source context, analyst decisions and later re-screening remain traceable.

Sources and further reading

• Verifex: benchmark methodology and caveats
• Verifex: matching methodology
• OFAC: Sanctions List Search
• NIST SP 800-53 Rev. 5: assessment and monitoring controls