How to Screen Customers Against Sanctions Lists via API

Data and APIs Team
API Usage Guides
8/31/2026
8/31/2026
APIsBackendSecurityTutorial
How to Screen Customers Against Sanctions Lists via API

If your product moves money, onboards businesses, or pays vendors, sanctions screening is not optional β€” it's the law. US sanctions run on strict liability: intent is not a defense, and a single prohibited transaction can cost hundreds of thousands of dollars in civil penalties, whether or not you knew the counterparty was listed.

The good news: the engineering half of the problem is very solvable. By the end of this guide you'll have working sanctions screening in your signup flow β€” one API call per name, fuzzy matching that catches transliterated spellings, and audit-ready results β€” plus a clear picture of when to screen and what to do with a hit.

The 30-Second Version

One GET request, one answer. Note the deliberately misspelled query β€” fuzzy matching is the whole point:

curl "https://api-sanctions.dataandapis.com/v1/screen?name=Sadam+Husein+al+Tikriti" \
    -H "x-api-key: YOUR_API_KEY"
{
    "hit": true,
    "min_score": 0.75,
    "matches": [{
        "score": 0.981,
        "match_type": "strong",
        "matched_name": "SADDAM HUSSEIN AL-TIKRITI",
        "matched_name_kind": "primary",
        "entity": { "source": "UN", "entity_type": "individual" }
    }],
    "screened_against": [
        { "slug": "ofac-sdn", "publish_date": "08/26/2026" }
    ]
}

hit tells you whether to pause the transaction; screened_against tells the auditor exactly which list versions you checked. The rest of this post explains what's behind those two fields and how to wire them into a real onboarding flow.

What Sanctions Screening Actually Means

Governments publish lists of people, companies, vessels, and aircraft that you are prohibited from doing business with. Screening means checking every customer and counterparty against those lists β€” at onboarding, and again whenever the lists change, which can be multiple times per day. The lists that matter for most businesses:

  • OFAC SDN (US): the Treasury's Specially Designated Nationals list β€” the big one for anything touching US dollars.
  • OFAC Consolidated (US): the non-SDN designations that still restrict what you can do.
  • UN Security Council Consolidated List: the closest thing to a global baseline.
  • UK OFSI and EU Financial Sanctions lists: mandatory if you serve UK or EU markets.
  • PEP registers: politically exposed persons β€” not sanctioned, but flagged for enhanced due diligence under AML rules.

Who has to do this? US persons and companies, anyone transacting in US dollars, and increasingly the "gatekeepers" β€” payment processors, marketplaces, crypto platforms, and professional service firms. Regulators recommend screening at onboarding and rescreening on every list update, because liability runs from the designation date, not from the day you noticed.

Why Exact Matching Fails (and DIY Is Harder Than It Looks)

The naive implementation β€” WHERE name = ? against a downloaded CSV β€” will pass every demo and fail exactly when it matters. Listed names don't arrive spelled the way your customer typed them:

  • Transliteration: "Usama bin Ladin" vs "Osama bin Laden", "Khalid" vs "Qalid" β€” same person, different romanization.
  • Word order: "AL-TIKRITI, Saddam Hussein" vs "Saddam Hussein al-Tikriti".
  • Partial names: the list says "Osama bin Muhammad bin Awad bin Laden"; your form says "Osama bin Laden".
  • Aliases and diacritics: most entries carry a dozen known aliases, with accents your users will never type.

Building this yourself is a real project: five official lists in five different formats that change without notice, a daily refresh pipeline (delistings must disappear as reliably as new names appear), phonetic indexing so you're not fuzzy-scoring 300,000 names per query, and threshold tuning where a false negative is a compliance failure. It's genuinely interesting work β€” and almost certainly not your product.

The Sanctions Screening API packages all of that: the five official lists plus a CC0 Wikidata PEP register, refreshed daily, behind a two-stage matcher (indexed phonetic candidate search, then Jaro-Winkler and token-set scoring) tuned recall-first β€” because a missed candidate is someone's compliance failure.

Step 1: Screen One Name

Grab an API key from the dashboard β€” every request authenticates with a single x-api-key header. The simplest integration point is your signup handler:

import os
import requests

def screen(name: str) -> dict:
    resp = requests.get(
        "https://api-sanctions.dataandapis.com/v1/screen",
        headers={"x-api-key": os.environ["SANCTIONS_API_KEY"]},
        params={"name": name, "min_score": 0.8},
        timeout=15,
    )
    resp.raise_for_status()
    return resp.json()

result = screen("Elena Petrova")
if result["hit"]:
    # Don't auto-reject β€” queue for human review (see gotchas below)
    flag_for_compliance_review(result["matches"], result["screened_against"])

Step 2: Screen in Batches at Onboarding

KYB onboarding is never one name β€” it's the company, its directors, and its beneficial owners. POST up to 25 names in a single call:

const response = await fetch("https://api-sanctions.dataandapis.com/v1/screen", {
    method: "POST",
    headers: {
        "Content-Type": "application/json",
        "x-api-key": process.env.SANCTIONS_API_KEY,
    },
    body: JSON.stringify({
        names: ["Acme Trading FZE", "Elena Petrova", "Marcus Webb"],
        min_score: 0.8,
    }),
});

const batch = await response.json();
console.log(`${batch.hits} of ${batch.count} names matched`);

for (const r of batch.results) {
    if (r.hit) {
        await pauseOnboarding(r.query, r.matches);
    }
}

Each entry in results carries its own query, hit, and scored matches, so one flagged director doesn't force you to re-screen the whole application.

The Options That Actually Matter

  • min_score (default 0.75): the match threshold. Raise it toward 0.85–0.9 to cut review noise on common names; lower it when recall matters more than reviewer time. Scores near 0.97+ usually mean the same name in a different word order.
  • list=sanction | pep: screen against sanctions lists only, PEPs only, or (default) both. Many teams screen sanctions on every user but PEPs only for high-value accounts.
  • source: restrict to a specific list (e.g. ofac-sdn) when a regulator asks for exactly that.
  • type: individual, entity, vessel or aircraft β€” screen a company name without noise from same-named people.
  • match_type and matched_name: every match tells you how strong it is and which alias it hit β€” feed both into your review UI so analysts see why something was flagged.

Gotchas That Separate Real Compliance from a Demo

  • Screening is not a one-time event. Lists change constantly and liability is retroactive to the designation date. Rescreen your customer base on a schedule β€” a nightly batch job over active accounts is the standard pattern.
  • Never auto-reject on a hit. Fuzzy matching flags candidates, not verdicts β€” "false positives" on common names are normal. Route hits to a human review queue; block only confirmed matches.
  • Store the evidence. Log the query, the score, the matched alias, and the screened_against list versions with every decision. A clean result is only defensible if you can show what it was clean against.
  • A PEP hit is not a sanctions hit. Politically exposed persons require enhanced due diligence, not refusal of service. Treat the two lists differently in your workflow.

Five Places to Put This

  • Fintech onboarding: screen the applicant and beneficial owners before the account goes live.
  • Marketplace KYB: screen sellers at registration and before the first payout.
  • Crypto withdrawals: screen recipient names on off-ramps where you have them.
  • Vendor and payroll runs: batch-screen the payee file before the payment batch executes.
  • Nightly rescreening: a cron job that re-screens active customers and opens review tickets for new hits.

Wrap-Up

Sanctions screening comes down to three engineering decisions: match fuzzily (exact matching is a compliance failure waiting to happen), screen at onboarding and on a schedule, and keep evidence of every check. With screening behind an API, all three become a few dozen lines of code instead of a data-pipeline team.

Ready to flag your first name? Get an API key on the Sanctions Screening API page and run the curl example from the top of this post β€” you'll have your first screened result in minutes.