draconic21
Guide · Sanctions compliance

Tracking OFAC Sanctions List Changes: Where the Official Data Lives

By draconic21 · Published 2026-09-27 · Sources: U.S. Treasury OFAC

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

  1. Why change tracking matters more than a single snapshot
  2. The official sources
  3. The three kinds of change: add, remove, modify
  4. Diffing snapshots yourself — and why it's harder than it looks
  5. A practical workflow
  6. Try it: a free change tracker
  7. Do it via API (x402 / MCP / RapidAPI)
  8. FAQ

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.CSV exports, 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

  1. 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).
  2. 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.
  3. 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.
  4. 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.

See recent changes free →

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)

Mirror at /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.

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.