How to Scrape the OFAC Sanctions List (SDN) in 2026

Every financial institution, fintech and compliance team needs the same thing: a current, structured copy of the US Treasury’s OFAC sanctions lists to screen customers and counterparties against. The data is public and free — OFAC publishes it as raw CSV files on treasury.gov — but “public” doesn’t mean “usable.” The files are split across three separate tables joined by ID, the interesting identifiers (passport numbers, dates of birth, IMO vessel numbers) are buried in a free-text remarks field, and null values are encoded as a -0- sentinel. This guide covers how the OFAC data is structured and how to turn those raw CSVs into enriched, screening-ready entity records.

What’s worth extracting

Each output row is one sanctioned entity — an individual, company, vessel or aircraft — with 18 structured fields. Grouped by purpose:

• Identity & designation — uid (OFAC’s unique entity ID), name (primary name), type (individual, entity, vessel, aircraft), programs (the sanctions program codes, e.g. SDGT, IRAN, RUSSIA) and listType (SDN or Consolidated).
• Enriched detail — aliases (a JSON array of {type, name} objects covering aka/fka/nka names), addresses (a JSON array of address strings), nationalities, and ids (a JSON array of {type, value} objects for passport, tax ID, DOB, POB, IMO and more).
• Context — title (position, for individuals) and remarks (the original free-text block, kept for reference).
• Vessel-specific — callSign, vesselType, tonnage, grt (gross registered tonnage), vesselFlag and vesselOwner.

Plus a scrapedAt timestamp on every row. The value here is the enrichment: the raw OFAC files don’t hand you aliases and addresses attached to each entity, and they don’t parse passport numbers out of prose — this data does both.

How the OFAC data actually works

OFAC doesn’t run a REST API. It publishes flat CSV files at official download URLs under treasury.gov/ofac/downloads/, and the actor fetches them directly over plain HTTP GET — no key, no login, no HTML scraping. There are three interconnected files behind the primary SDN list:

• sdn.csv — the primary Specially Designated Nationals list, one row per entity.
• alt.csv — the alternate-names (alias) file, keyed back to entity IDs.
• add.csv — the addresses file, also keyed by entity ID.

For broader coverage there’s also cons_prim.csv, the Consolidated Sanctions List, which merges all OFAC-administered programs into a single file.

The actor’s real work is the join and parse pipeline. It cross-references alt.csv and add.csv back onto each SDN row to attach the alias and address arrays, then it pattern-matches the remarks free-text field to pull out structured identifiers — dates of birth, places of birth, passport numbers, tax IDs, IMO numbers. It normalizes the -0- null sentinel to empty strings and classifies each entity into one of the four types. A minimal full-list run is just:

{
  "mode": "sdn"
}

To narrow to a single sanctions regime, add filters. This pulls only Russia-program individuals:

{
  "mode": "sdn",
  "programFilter": "RUSSIA",
  "typeFilter": "individual"
}

And a targeted name search across both lists:

{
  "mode": "all",
  "nameFilter": "Putin"
}

The mode field selects sdn, consolidated or all (the union of both, de-duplicated by UID). nameFilter is a case-insensitive substring match on name and aliases; programFilter matches program codes; typeFilter restricts by entity type. Filters apply before rows are written, so you only pay for the entities you actually want.

▶ Open the OFAC Sanctions Scraper on Apify — one run returns the full SDN list with aliases, addresses and parsed IDs already joined. Pulls directly from treasury.gov, no API key, no login. Export to CSV, JSON, Excel or Google Sheets.

The access reality

This is open US government data, so the friction isn’t anti-bot defenses — it’s volume, freshness and the shape of the source data.

• List sizes. A full sdn run returns roughly 19,000–19,500 entries (the list grows as new designations land). A consolidated run returns around 440. mode: "all" returns the union of both.
• Freshness matters more than anything. OFAC updates its lists on an irregular but frequent cadence — sometimes multiple times a week, and major geopolitical events (new executive orders, UN resolutions) trigger immediate updates. The actor fetches the live files on every run, so scheduling it daily is the recommended pattern for compliance-critical workflows.
• Datacenter proxies are enough. These are US .gov endpoints; datacenter IPs work fine, which keeps cost low. No residential proxy needed.
• Speed. A full SDN extraction of 19,000+ entries completes in under three minutes on a single datacenter connection, with no concurrency tuning.

Two honest limitations. First, this actor extracts OFAC data — it does not match against your customer database. You build the matching logic separately: load the output into a database and run fuzzy name matching (Levenshtein, Metaphone) against your records. Second, sparse fields are normal, not bugs: vessels carry IMO/flag data but no DOB; individuals carry DOB/passport data but no tonnage; older entries have thin remarks. The -0- sentinel is already normalized to empty strings for you.

Example output

A trimmed entity record:

{
  "uid": "26765",
  "name": "BANK MELLI IRAN",
  "type": "entity",
  "programs": "IRAN",
  "listType": "SDN",
  "aliases": "[{\"type\":\"aka\",\"name\":\"MELLI BANK\"},{\"type\":\"aka\",\"name\":\"NATIONAL BANK OF IRAN\"}]",
  "addresses": "[\"Ferdowsi Avenue, PO Box 11365-171, Tehran, Iran\",\"43 Avenue Montaigne, Paris 75008, France\"]",
  "ids": "[{\"type\":\"Registration\",\"value\":\"10100459\"}]",
  "scrapedAt": "2026-07-08T10:00:00.000Z"
}

The aliases, addresses and ids fields are JSON strings — parse them with JSON.parse() when processing in code to get back the arrays.

Typical use cases

• Customer screening — screen an onboarding list against every OFAC-sanctioned individual and entity to flag matches before account opening.
• Daily-refresh compliance pipelines — download the latest OFAC data on a schedule and insert new or changed entries into an internal sanctions database.
• Program research — pull every entity under a specific program (DPRK, RUSSIA, IRAN) for policy analysis or investigative journalism.
• Maritime compliance — extract vessel data (IMO, flag, tonnage, call sign) with typeFilter: "vessel" to power dashboards tracking sanctioned ships.
• Third-party risk assessment — generate an enriched export of sanctioned individuals with aliases, addresses and passport numbers to feed a risk tool.
• KYC/CDD without a paid vendor — fintechs and banks building automated onboarding checks that need fresh OFAC data without a commercial screening-API subscription.

Build-it-yourself vs. managed

The CSVs are free, so a DIY pipeline is feasible — but the enrichment is where the effort concentrates:

• The three-way join. You have to key alt.csv and add.csv back onto sdn.csv correctly to attach aliases and addresses per entity.
• Remarks parsing. The passport numbers, DOBs, POBs and IMO numbers only exist as prose inside remarks. Extracting them reliably means pattern-matching against inconsistent free text — the fiddliest part of the job.
• Sentinel and type handling. Normalizing -0- to empty strings and classifying individual/entity/vessel/aircraft.
• Consolidated-list support and de-duplication by UID when merging SDN and Consolidated.
• Refresh scheduling — the data is only as good as its freshness, so you own a cron job and a change-detection step forever.

The managed actor already does the join, the remarks parsing and the sentinel normalization, and runs on pay-per-result pricing — a fraction of a cent per entity — so a full 19,000-row SDN pull costs well under a dollar, refreshable daily, with no proxy bill against treasury.gov.

Common pitfalls

Specifics that trip up OFAC pipelines:

• programFilter is a partial match. Passing "IRAN" catches IRAN, IRAN-EO13622, IRAN-TRA and every related sub-program — usually what you want, but know that it’s a substring, not an exact code.
• Aliases, addresses and IDs are JSON strings, not arrays. Run JSON.parse() on aliases, addresses and ids before using them. For screening, match against both name and the parsed aliases to maximize hit rates.
• Freshness is the whole game. A sanctions list from last week is a compliance liability. Schedule the run to match your refresh cadence — daily is safest.
• Sparse fields are expected. Empty vessel or DOB fields aren’t errors; not every entity type carries every field, and -0- nulls are already blanked.
• This is extraction, not matching. Don’t expect it to compare against your customers — build fuzzy-matching separately on top of the extracted data.
• SDN vs. Consolidated coverage. SDN is the large primary list; Consolidated merges the other OFAC-administered programs. Use mode: "all" for full coverage rather than assuming SDN alone is complete.

Wrapping up

OFAC data is free and public, but the gap between the raw CSVs and a screening-ready dataset is real — joins across three files, identifiers hidden in prose, and a null sentinel to normalize. If you need it once and want to write the parser yourself, the files are right there on treasury.gov. If you want enriched, filterable, always-fresh sanctions records dropped straight into your compliance database, the managed actor delivers that on a daily schedule.

▶ Run the OFAC Sanctions Scraper on Apify — one run returns the full SDN or Consolidated list (~19,000+ entities) with aliases, addresses and parsed passport/DOB/IMO IDs already joined. No API key, no login. Export to CSV, JSON, Excel or Google Sheets. Start on Apify’s free monthly credit.