Move from OFAC list downloads to a screening API

Decide which work the API will take over

OFAC's Sanctions List Service remains the authority for its published data. Moving from file downloads or manual lookup to SanctionsKit changes how your application submits a subject, receives candidates and hands them to a reviewer.

The service handles its supported ingestion and matching workflow. Your team still owns the customer identity, required sources, human review and business decision. Map those responsibilities before retiring the old process.

Preserve customer references and known identity facts

Map the legal name, subject type, dates and typed identifiers from your existing records. Preserve partial dates as partial dates. Use reference for your own customer or party ID, not an OFAC record ID.

Keep the old system's evidence in approved storage. A new API request creates a new check; it does not import a historical review decision or prove that the earlier source version was used.

Run a synthetic request from your backend

Create a Sandbox key with screenings:write and results:read in API keys. Keep the secret server-side. The example calls POST /api/v1/screenings with a fictional subject and the reference demo-legacy-vendor-1042.

Create REQUEST_KEY once and retain it with the exact request. Reuse both for an uncertain retry. Save data.id, status, matches and coverage after success. An error leaves the migration test incomplete; it must not become a no-match.

curl --fail-with-body "https://www.sanctionskit.com/api/v1/screenings" \
  -H "Authorization: Bearer $SANCTIONSKIT_API_KEY" \
  -H 'Content-Type: application/json' \
  -H "Idempotency-Key: $REQUEST_KEY" \
  --data '{
  "subject": {
    "name": "Example Trading Company",
    "entityType": "organization"
  },
  "package": "sandbox@1",
  "reference": "demo-legacy-vendor-1042",
  "retention": "standard"
}'

Discover actual Production coverage

Use an authorized Production key with sources:read to call GET /api/v1/sources. Verify each required source and subject type. Replace the sandbox package with the required available sources, such as SDN and non-SDN where applicable. Never send package and sources together.

When policy is required, read GET /api/v1/policies and use its actual ID and version. A failed source cannot be replaced with a local file while presenting the result as a completed SanctionsKit check.

Keep the reviewer handoff intact

Find the retained result in Screening history in the same environment. Review candidates in the case, complete outside checks and obtain required approval. Old decisions can provide context but must not silently dismiss new findings.

Retrieve evidence with GET /api/v1/results/{id}/evidence. Keep the source IDs and versions with the result. Downloading today's list later cannot recreate the exact data behind an older check.

Reconcile the portfolio before retiring the old process

For a larger migration, use batches and reconcile each input reference to a completed result or a recorded failure. Assign unresolved cases and correct bad inputs. Add continuing subjects to monitoring and confirm each first check completes.

Test the full path from input to review and evidence retrieval. Retire the earlier process through your approved change procedure, preserving its history and any required official-source validation. The rollout guide covers the next operational checks.

Frequently asked questions