Sanctions Screening API for Onboarding and Payouts

A sanctions screening API lets your own product check people and companies against sanctions lists at the exact moment it matters: when someone signs up, when a business account is approved, and when money leaves your platform. Done well, it adds a short wait to a few steps, turns every possible match into a case a person reviews, and leaves an evidence record for each call.

Done badly, it blocks good customers for no reason, lets payouts slip through while a request times out, and leaves you unable to show an auditor what you checked. This guide walks through where to call the API, how to handle latency and retries, what to do with possible matches, and how webhooks keep existing customers covered after the lists change.

Where to call screening in the flow

Screening belongs at the points where a sanctioned party could gain access to your service or receive value. For most platforms that means a handful of moments, not every page view.

Moment	What you screen	Blocking or not
Account signup	Name, date of birth, country	Hold activation until the result is in
Business onboarding	Company name, registration country, owners and directors	Hold approval, screen owners too
Profile change	New legal name or new owner	Rescreen before the change takes effect
Payout or withdrawal	Beneficiary name, bank country	Hold the payout until cleared
Outgoing payment	Counterparty and payment details	Hold the payment on a possible match
After every list update	All saved customers	Runs in the background, alerts by webhook

The rule of thumb is simple. If a step grants access or moves money, screen before it completes. If a step only reads data, it does not need a new check. Ownership matters as well: a company can be blocked under the OFAC 50 percent rule even when its own name is on no list, so collect owners during onboarding and screen them along with the company.

Latency and how to keep the flow fast

A screening call compares one name, with all its aliases and spelling variants, against the current lists. That is quick enough to run inside a signup request, but your code still needs a plan for the slow or failed call.

Set a client timeout that fits the step. Signup can wait a moment, a checkout page usually cannot wait long.
On a timeout, do not treat the customer as clear. Put the account or payout in a pending state and retry in the background.
Send the extra fields you have, such as date of birth and country. They do not slow the call, and they make a possible match much easier to resolve later.
For large existing customer bases, use batch screening once, then call the API only for new and changed records.

The important design choice is that "no answer yet" never becomes "no match". A payout that waits a few minutes is a small cost. A payout released because a request failed is the failure you are trying to prevent.

Idempotency and retries

Networks fail and workers restart, so the same screening request will sometimes be sent twice. Your integration should make that harmless.

Generate a stable key for each screening event, for example the customer ID plus the event type plus a version number.
Send that key with the request and store it next to the result.
When you retry, reuse the same key, so you get the same check back instead of a duplicate case.
Only create a new key when the data changes, such as a new legal name or a new beneficiary.

This keeps your case queue clean. Reviewers should never see the same possible match twice because a job was retried at the wrong moment.

Handling possible matches as cases

Most hits on common names are false positives. That is expected, and the answer is not to raise the threshold until they disappear. The answer is a review step that is fast, consistent and recorded.

When the API returns a possible match, your system should pause the step, open a case and hand it to a person. A good case shows the customer data and the list entry side by side: name and aliases, match score, dates of birth, nationality, ID numbers and the sanctions program. The reviewer then clears it with a written reason, escalates it, or confirms it. Our guide to SDN list search covers how to compare those details without cutting corners.

Remember cleared matches

Once a reviewer clears a possible match for a specific customer and a specific list entry, that decision should stick. If the customer data and the list entry stay the same, the same match should not come back after every rescreen. If either one changes, it should.

The customer decides

Screening results support a compliance decision. They do not make it. Your team decides whether to block, reject, report or proceed, based on your own policy and, where needed, legal advice.

Webhooks for monitoring alerts

A customer who was clean at signup can be designated next month. That is why screening at onboarding is not enough on its own. With ongoing sanctions monitoring, saved records are rescreened after every list update, and new possible matches arrive at your endpoint as webhooks.

Treat webhook handling like any other money related input:

Verify the signature on every webhook before you act on it, and reject anything unsigned.
Respond quickly and process the alert in a background job.
Expect the same event more than once and deduplicate by event ID.
On an alert, pause payouts for that customer and open a case, the same way you do at signup.

Testing in a sandbox

Before you switch on screening in production, test the paths that rarely happen in real traffic. Use a sandbox or test keys and run through each of these:

A clean name that returns no match.
A name that matches a listed entry exactly.
A transliterated or misspelled variant of a listed name.
A timeout, to confirm the step stays pending.
A duplicate request with the same idempotency key.
A webhook with a bad signature, to confirm it is rejected.

The API documentation lists the request fields, responses and webhook events you need for these tests.

Evidence for every call

Each screening call should leave a record you can show later: what was screened, when, against which list version, what came back and what your team decided. OFAC recordkeeping rules require sanctions related records to be kept for a set period, and that period was extended from five to ten years in 2025. Plan your retention for the longer period, and keep the case decision with the screening result rather than in a separate inbox or chat.

Integration checklist

Screen at signup, business onboarding, profile changes, payouts and outgoing payments.
Send date of birth, country and ID data when you have them.
Treat timeouts as pending, never as clear.
Use idempotency keys and reuse them on retries.
Route every possible match into a case with a written decision.
Verify webhook signatures and deduplicate events.
Test edge cases in a sandbox before going live.
Keep an evidence record for each call and each decision.

How OfacScanner fits in

The OfacScanner sanctions screening API screens people and companies against the OFAC SDN and Consolidated lists with fuzzy matching for aliases and transliterated names. It returns match scores with the full list entry, opens cases for possible matches, remembers cleared decisions, sends signed webhooks after every list update and keeps an evidence record for each check. API access and payment screening are part of the Scale plan, with no overage fees.

Ready to plan your integration? Read how the screening API and webhooks work end to end, or write to [email protected] with questions about your flow. OfacScanner is not affiliated with OFAC or the US Treasury.

Want to see a result before anything else? Screen one name now with the OFAC search on our home page and look at the matches, scores and list date it returns.