OFAC Sanctions Screening API — No API Key Required

No API key required. This actor screens names against the official U.S. Treasury OFAC Specially Designated Nationals (SDN) list and the Consolidated (non-SDN) sanctions list for AML/KYB compliance — via the official, keyless Sanctions List Service. No account, no registration, no scraping: just supply names and screen. Optional incremental monitoring flags newly-added listings on scheduled runs.

Live-validated 2026-07-15 against the real, current lists (19,217 real SDN entries fetched and correctly parsed/filtered in testing) — the CSV parsing, name matching, and monitor-mode diff logic have all been exercised against live data, not just fixtures.

This is a screening aid, not legal advice. It does substring matching against the official lists, not certified fuzzy/phonetic compliance matching. Use it to narrow down candidates for review, not as a standalone legal clearance — see Limitations below.

What makes this different

Zero setup. Treasury's Sanctions List Service (sanctionslistservice.ofac.treas.gov) is a free, official REST service — no account, no API key, nothing to configure beyond your search input. Most comparable actors on the Store require registration or scrape a web UI; this hits the official bulk-data service directly.

Built for ongoing monitoring, not just one-off lookups. Incremental new-listing detection flags newly-added sanctions designations on scheduled runs — most comparable actors in this category only support one-off searches.

Natural pairing: combine with our SAM.gov Federal Contracting Suite actor for a combined "federal debarment + OFAC sanctions" screening pass.

How it works

• No API key needed. Nothing to register, nothing to configure beyond your search input.
• Supply names to screen (case-insensitive substring match against the official SDN_Name field). Any real screen always checks both SDN and CONSOLIDATED by default — the primary sanctions list is never silently dropped just because you didn't specify lists yourself.
• Choose which lists to check (SDN, CONSOLIDATED, or both) and optionally filter by sanctions program code (e.g. "CUBA", "IRAN"). Explicitly narrowing lists yourself is always respected exactly as given.
• Leaving names empty with no explicit lists choice (nothing to screen at all) uses a cheaper, CONSOLIDATED-only default rather than pulling the full ~19,659-entry combined list — this keeps a zero-configuration run fast and inexpensive. This run always pushes an explicit lists-coverage record naming exactly what was and wasn't included, so it's never silent. Pass lists explicitly (with or without names) to include SDN in a no-screen run too.
• This actor downloads and filters locally — Treasury's service is a bulk-file distribution endpoint, not a server-side search API, so there's no way to query it more surgically than "fetch the current list, then filter." The full SDN list is a manageable ~5-6MB/~19K entries, so this is fast and cheap in practice, not a real limitation in disguise.
• Optional incremental monitor mode: remembers which ent_num values it has seen (Apify key-value store) and emits a separate new-listing record for anything newly added since the last run — designed for scheduled runs watching for new designations. Confirmed live: a second run against unchanged data produces zero false-positive new-listing flags.
• An optional maxRecordsPerRun per-list cap (default 0 = uncapped). Screening is exhaustive by default — every matching record on every requested list is returned, because a silently partial sanctions screen is the worst failure mode this actor could have (see below). If you set a cap and it truncates a list, the actor emits a loud screening-status record with status: "TRUNCATED" plus a warning log — it never lets a capped run look like a complete one.
• The actor aborts the whole run (non-zero exit, clear error) if a list fails to fetch — it never reports "0 matches" when the authoritative list simply never loaded. A compliance user reading a clean result must be able to trust that the list was actually checked.

⚠️ Limitations — read this before relying on it for compliance decisions

• This is substring matching with diacritic-folding and Last,First/First-Last order-swapping — not a certified compliance-screening engine. Real sanctions screening products use fuzzy/ phonetic matching (to catch typos, transliteration variants beyond simple accent differences, etc.) — this actor doesn't. A name spelled meaningfully differently than OFAC's listing, or a nickname/alias not captured in the SDN_Name field itself, can still produce a false negative (a real match that this actor misses). Results are binary substring candidates, not scored/ranked matches. This is not legal advice. For compliance-critical decisions, always cross-check against OFAC's own official search tool (sanctionssearch.ofac.treas.gov) — do not treat a clean result from this actor as a legal clearance.
• The Consolidated (non-SDN, e.g. NS-PLC) list is fetched and screened in full — as of 2026-07-15 it's ~442 real entries. This actor never treats a near-empty result as normal for either list; an unexpectedly small or missing list is treated as a fetch problem, not a quiet "nothing to report."
• The legacy CSV format is undocumented/positional (no header row, no official published schema for the exact column order) — the 12-column mapping used here (entNum, sdnName, sdnType, program, title, callSign, vesselType, tonnage, grt, vesselFlag, vesselOwner, remarks) is inferred from the well-known, long-standing OFAC SDN.CSV format and confirmed against real live data, but OFAC could change this format without notice since it isn't a versioned/documented API contract the way SAM.gov's or FMCSA's JSON APIs are.
• Aliases (a.k.a./f.k.a. names) are not broken out as separate searchable records in v1 — they appear only within the free-text remarks field if present, not as structured, individually matchable entries. A more complete implementation would use the richer SDN_ADVANCED.XML format (which does have structured alias records) — deferred for now, since that file is ~126MB with a complex ID-based reference schema, too heavy for a cost-efficient per-run fetch.
• A full-list export with no names to screen can hit a real cost limit if left uncapped. Leaving names empty with the default lists gets a cheap, bounded default automatically (see above). But if you explicitly request a full list with nothing to screen (e.g. lists: ["SDN"] alone, no names) and leave maxRecordsPerRun at 0, fetching and delivering the entire ~19,000-row SDN list can exceed Apify's own per-run cost limit and abort partway through. This is a loud abort, not a silent miss — but set an explicit maxRecordsPerRun for a full-list export to avoid it.

Pricing

Pay per event:

• sanctions-record — $0.004 / screened record returned
• monitor-run — $0.05 / scheduled monitor-mode run, in addition to per-record charges

Input

Key fields (see the Input tab for the full form): names, lists, programFilter, monitorMode, maxRecordsPerRun. No required fields — a run with all defaults screens against both full lists.

Output

Each dataset item has a recordType of "sanctions-listing", "new-listing" (monitor mode only), "screening-status" (only when a run is truncated), or "lists-coverage" (only when a run covers fewer than both sanctions lists — see Limitations below). See the Output tab for the full field reference.

Local development

npm install
npm test                # recorded-fixture unit tests, no network needed
npx apify-cli run       # local end-to-end run — works immediately, no key/account needed

Support

Built and maintained by Moose & Raven. Questions or issues: support@mooseandraven.com.