Tracking OFAC Sanctions List Changes: Where the Official Data Lives
A one-time sanctions check tells you about today. A compliance program needs to know when the list itself changes — a new designation, a delisting, or a modified entry. Here's where that data actually comes from, officially.
In this guide
Why change tracking matters more than a single snapshot
A one-off sanctions screen — "is this name or address on the list right now" — answers a single moment in time. But OFAC's SDN list is a living document: entities are added when new designations are made, removed after delistings or settlements, and modified when OFAC updates an alias, an address, or program tags on an existing entry. A business with ongoing exposure (an exchange re-screening its customer base, a bank re-checking counterparties, a compliance team monitoring a watchlist of politically exposed persons) needs to know when something changed, not just what the list looks like today.
This matters practically: someone you cleared last month could be added tomorrow, and re-running a full screen against your entire customer base every day is expensive and slow compared to asking "what changed since my last check."
The official sources
- Sanctions List Service — recent changes (sanctionslistservice.ofac.treas.gov) — alongside the full
SDN.XML/SDN.CSVexports, OFAC's list service publishes structured data documenting what changed between publications: which UIDs were added, removed, or had fields modified. This is the closest thing to an authoritative machine-readable "diff" feed, and it's the right foundation for any automated tracker. - OFAC Recent Actions (ofac.treasury.gov/recent-actions) — human-readable notices, usually published the same day as a designation or delisting action, with narrative context (which sanctions program, why) that the raw data files don't include.
- Treasury/OFAC email subscription (GovDelivery) — Treasury operates an official subscription service so recent-actions notices land in your inbox as they're published, useful as a low-effort backstop even if you also run an automated tracker.
- SDN list data formats & schemas tutorial (ofac.treasury.gov/sdn-list-data-formats-data-schemas) — documents the legacy flat-file schema in detail, including how the comments/continuation file relates to the base SDN export, which matters if you're building your own diff logic rather than using OFAC's changes feed directly.
The three kinds of change: add, remove, modify
- Add — a brand-new SDN entry (new designation), or a new identifier (like a digital-currency address) attached to an existing entry.
- Remove — a delisting. Entities are removed for reasons ranging from a negotiated settlement, a change in circumstances, litigation, or an administrative correction. A removal is worth investigating on its own, not just noting — the removal notice or associated Federal Register entry usually explains why.
- Modify — the entity stays listed, but a field changes: a new alias is added, an address is corrected, a program tag changes, or additional identifying information (like a newly attributed wallet address) is appended. Modifications are easy to miss with a naive full-list diff because the entity's core name/UID hasn't changed — only a sub-field has.
Diffing snapshots yourself — and why it's harder than it looks
It's tempting to just download SDN.XML daily and diff it against yesterday's copy. In practice this runs into real gotchas:
- Formatting noise. Field ordering, whitespace, or record ordering can shift between publications without any substantive change, producing false positives in a naive text diff.
- Continuation records. Long remarks (including digital-currency identifiers) are split across the base export and a comments file; a diff that only looks at the base file can misread a comments-only update as "no change," or misattribute which UID a changed address belongs to.
- Remove-vs-modify ambiguity. If OFAC re-issues an entry under a corrected UID, a naive diff might read that as one removal plus one unrelated addition rather than a single modification — losing the continuity that matters for an audit trail.
This is exactly the class of problem OFAC's own changes feed is built to solve — it's worth building on top of that structured source rather than reinventing snapshot-diffing.
A practical workflow
- Maintain a durable, dated index of past publications and their diffs (don't just keep "latest" — keep history so you can answer "what changed since date X" for any X, not just yesterday).
- On a schedule (hourly to every few hours is reasonable for most use cases; OFAC itself doesn't publish on a fixed cadence), pull the changes feed and append any new entries to your index.
- For anything time-sensitive (e.g. a customer you're about to onboard right now), also take a live top-up check against the freshest available data rather than relying solely on your last scheduled sync.
- Alert on removals and modifications, not just additions — a delisting or address change on an entity you previously flagged is just as actionable as a brand-new hit.
Try it: a free change tracker
draconic21's free OFAC Sanctions List Changes tool shows the last 30 days of additions, removals, and modifications from OFAC's own change-tracking feed — free, no filters, no signup.
Re-screen your own wallet list after each change
When the list changes, the addresses you already screened need a fresh look. The OFAC Wallet Screening Kit ($29 one-time) includes Python and Node CLIs that build a local address index from OFAC's official SDN XML, check your wallet list offline, and write a screening log for human review. Refresh the source data before relying on a result. It checks published addresses only and is not a full compliance program.
See the $29 wallet screening kit on Gumroad →
Screening names rather than wallet addresses? ofac-screen local name screener, $9 suggested, $5 minimum →
Do it via API (x402 / MCP / RapidAPI)
x402 (pay-per-call, USDC on Base)
curl -X POST https://draconic21-x402-api.onrender.com/v1/sanctions_delta \
-H "content-type: application/json" \
-d '{"since_date":"2026-08-27"}'
# unpaid: HTTP 402 + PAYMENT-REQUIRED header (sign with a Base USDC wallet, retry)
$0.008/call — returns SDN entries added, removed, or modified since the given date, built from a durable index derived from OFAC's own change-tracking feed, with a live top-up so a same-day change isn't missed. See /v1/sanctions_delta/availability.
MCP (any MCP-enabled agent)
See /.well-known/mcp.json for the sanctions_delta tool.
RapidAPI (billed by card)
Prefer card billing over a crypto wallet? Subscribe on RapidAPI — same data, billed by RapidAPI. Raw mirror spec: /rapid/v1/openapi.json.
FAQ
Does OFAC publish a dedicated change feed, or do I have to diff snapshots myself?
OFAC's Sanctions List Service publishes structured recent-changes data alongside its full-list exports — more reliable than diffing two snapshots yourself, which can mistake formatting noise for real changes.
How often does the SDN list change?
No fixed schedule — OFAC updates it whenever it takes an action, which can happen several times a week or go days without a change. A periodic manual check isn't reliable for anything time-sensitive.
Can I get notified automatically instead of polling?
Treasury runs an official email subscription (GovDelivery) for recent actions; for a structured, queryable history, a change-tracking API built on OFAC's own feed is the practical middle ground.
Agent / funded runtime? Choose the API that matches your task. Check its free example and availability links, then follow the payment guide to inspect its unpaid HTTP 402 challenge before paying. For agent-market research, Daily Agent Signal (free JSON example) is a separate option ($0.03 per paid call). Free service check: GET /health · Skill card.
Not legal or compliance advice. This guide and the linked tools are informational only. A compliance program's screening cadence and escalation process should be designed with a qualified sanctions-compliance professional or attorney.