OFAC compliance testing methodology

A systematic way to prove a sanctions screening program works: test cases, edge cases, and continuous validation.

TL;DR

TL;DR: Compliance testing means proving the screen blocks what it should and allows what it should. Build fixed test cases, probe edge cases, and revalidate continuously.

Test cases

Start with a known set of blocked and clean counterparties. A blocked SDN name must return BLOCK from sanctions_check, and a clean counterparty must return ALLOW. Keep these fixtures stable so a regression is immediately visible. Because OFAC liability is strict, the passing bar is simple: no flagged counterparty may ever reach a payment step.

Edge cases

Probe the boundaries. Name variants, abbreviated entities, and the 50 Percent Rule all change results. A shell company owned 50 percent or more by a blocked person is itself blocked. Test fuzzy matches and near-misses so the screening logic does not quietly pass a variant spelling. Also test the failure path: a timeout should default to stop, not allow.

Continuous validation

Lists change, so one-time testing is not enough. Re-run the fixture suite on a schedule and after every deployment. The sanctionsai.dev data set is synced hourly from 16 jurisdictions, so a validation run against current data confirms the gate still reflects the latest SDN List. Record results so auditors can see the screen was active and correct.