OFAC SDN Sanctions Screening — with the delisting history

Screen names against the OFAC Specially Designated Nationals (SDN) list and get an answer that distinguishes "never sanctioned" from "no longer sanctioned".

Standard OFAC screening answers one question: is this name on the SDN list right now? For a party OFAC removed last month, the answer is no match — the same empty result, byte for byte, as for a name that was never sanctioned in the history of the programme.

That is not a shortcoming of the tools. It is how the source works.

The mechanism

OFAC does not flag a delisted party. It deletes it. The current SDN.XML export has no status field and no designation date anywhere in its schema — each record carries a uid, names, aliases, programmes, addresses and identity documents, and nothing at all about when the designation began or whether one ever ended. A party removed from the list simply is not in the file, and the file does not record that it ever was.

Measured 2026-08-06: FLY BAGHDAD AIRLINES COMPANY was designated 2024-01-22 under SDGT / Executive Order 13224 and removed in OFAC's 2026-08-05 publication. Streaming the entire 28.7 MB current SDN.XML finds FLY BAGHDAD zero times and its a.k.a. IRAQ EXPRESS zero times. Nothing in the export it was removed from records that it was ever on it.

The removal history lives on a different surface of the same host: OFAC publishes every action as a separate delta file at /changes/{publicationId}. There is no index endpoint and no bulk export — the ids are sequential in date order back to the 2022-09-22 seed, roughly a third of the integers are allocated, an unallocated one answers 400, and the host rate-limits. Walking the whole space is ~935 paced requests. This Actor does that walk once, offline, ships the result inside its image, and at run time walks only forward from the snapshot to OFAC's live publication — so results are current to OFAC's latest action without every run re-walking four years of history.

Verdicts

Verdict	Meaning
CURRENTLY_SANCTIONED	On the SDN list in OFAC's current export
SANCTIONED_NON_SDN_LIST	Not on SDN, but on OFAC's Consolidated (non-SDN) list — still restricted
FORMERLY_SANCTIONED	Delisted — with listedOn, removedOn and the programmes it was under
NO_MATCH	No record on any of the three surfaces

SANCTIONED_NON_SDN_LIST is here because "removed from the SDN list" and "no longer sanctioned" are not the same event. Parties leave the SDN List onto another OFAC list: OFAC's 2026-07-17 publication moved 39 parties from the SDN List to the Non-SDN Menu-Based Sanctions List while delisting only 9. Every one of those 39 is absent from SDN.XML and every one is still restricted.

That distinction is also the trap in the delta feed, and it is why the delisting counts here are what they are. action="remove" appears at two levels in those files and means different things: on the <entity> element it is a delisting, but on a <sanctionsList> element inside an otherwise unchanged entity it is a move. Counting the string in that 2026-07-17 file finds 165 "removals" where 9 parties were delisted. Worse, a move record carries only the elements that changed — it has no names in it at all — so the delta feed cannot even name the parties who moved. They are reached by name from OFAC's Consolidated export instead, which this Actor screens as a third surface.

Point-in-time screening

Supply asOfDate (YYYY-MM-DD) and every row gains sanctionedOnAsOfDate, answering the question a lookback audit actually asks: was this counterparty sanctioned on the day we transacted?

It returns true, false, or null where the source genuinely cannot say — a party still listed today whose designation predates OFAC's 2022-09-22 delta seed has no designation date anywhere in the published data. That gap is reported rather than filled with a guess, because an audit artefact with an invented date in it is worse than one with an honest blank.

Matching

Two deterministic rules, and nothing else:

1. exact — the normalised name matches a primary name or an a.k.a.
2. all_tokens — every significant token of your query appears in the record's name (RODRIGUEZ OREJUELA matches RODRIGUEZ OREJUELA, Gilberto Jose). Corporate-form words — LTD, GMBH, OOO, COMPANY and so on — are ignored, and a single-token query never matches on the token rule, because one shared surname would match half the list.

Deliberately not fuzzy. A screening hit that a compliance officer cannot reproduce by eye is not evidence, and an edit-distance threshold is a knob whose false-positive rate nobody can state. Both rules above fit in one sentence each, which is the bar for something that goes in an audit file.

Aliases are indexed alongside primary names. That matters: the delisted party above is FLY BAGHDAD AIRLINES COMPANY, and the name on a shipping manifest is IRAQ EXPRESS.

Output

One row per name screened:

Field
query	the name you submitted
verdict	one of the four above
matchedName / matchType	the OFAC name that matched, and how (exact / all_tokens)
entityType	Individual / Entity / Vessel / Aircraft
programs	e.g. SDGT, SDNTK, UKRAINE-EO13662
onList	which OFAC surface the match came from
listedOn	designation date
removedOn	date OFAC removed it, on FORMERLY_SANCTIONED
ofacUid	OFAC's own record identifier
remarks	OFAC's free-text remarks on the record
sanctionedOnAsOfDate	point-in-time verdict when asOfDate is given
matchCount / otherMatchedNames	other OFAC records the query also hit
sdnPublishDate / consolidatedPublishDate / historyThroughDate	provenance for all three surfaces

It refuses rather than degrades

The failure this Actor has to refuse is specific: if the history is missing, truncated or stale, every formerly-sanctioned party silently becomes NO_MATCH — a confident false clear on a sanctions screen, which is the worst possible output. So each of these aborts the run with zero rows instead of degrading:

• the shipped history snapshot is missing or holds fewer than 500 delisted records
• OFAC's latest publication is more than 45 days old
• the forward walk cannot reach OFAC's live publication (id allocation changed)
• SDN.XML parses to fewer than 10,000 entries, or its own Publish_Date is more than 30 days old — freshness is read from the file's own date, never from an HTTP header
• CONSOLIDATED.XML parses to fewer than 100 entries, or is over 180 days old
• more than a quarter of delisted names also appear on the current SDN list, which would mean the two surfaces are describing different worlds

Data-load charges are applied after the sources are validated, so an aborted run costs nothing.

Source

Both surfaces are keyless, US federal public-domain data:

• https://sanctionslistservice.ofac.treas.gov/api/PublicationPreview/exports/SDN.XML
• https://sanctionslistservice.ofac.treas.gov/api/PublicationPreview/exports/CONSOLIDATED.XML
• https://sanctionslistservice.ofac.treas.gov/changes/{publicationId}

Requests are paced sequentially; this Actor is not going to be the reason a free public service gets a rate limit.

Not legal advice

This is a data tool, not a compliance determination. OFAC's published lists are the authority, and a name match is a starting point for review — not a conclusion about any person or entity.