OFAC Sanctions Lists: The Treasury Database Every Financial Institution Must Screen Against

The Office of Foreign Assets Control administers the most consequential financial prohibition list in the world. Every US bank, broker-dealer, money services business, cryptocurrency exchange, and exporter must screen their customers and transactions against it before moving a dollar. The underlying data is public, machine-readable, and updated daily—yet surprisingly few analysts have read the actual XML.

What OFAC is and why it matters

OFAC is a division of the US Treasury Department's Office of Terrorism and Financial Intelligence. Its statutory authority derives from the International Emergency Economic Powers Act (IEEPA), the Trading with the Enemy Act (TWEA), and specific country-by-country sanctions statutes. OFAC administers more than thirty active sanctions programs simultaneously, each targeting a different country, regime, or threat category.

The core mechanism is designation: OFAC formally names an individual, company, vessel, or aircraft as a Specially Designated National (SDN) or places it on one of several other restricted lists. Once designated, all US persons—citizens, permanent residents, and entities incorporated or operating in the United States—are legally required to block the designated party's assets if they come under US control and to refrain from any transaction with them. The prohibition is strict liability: intent is not an element of the violation.

The penalty exposure is severe. Civil penalties run up to approximately $1.3 million per violation or twice the value of the underlying transaction, whichever is greater, for most programs. Criminal penalties under IEEPA reach $1 million per violation and twenty years imprisonment. OFAC's enforcement posture has shifted toward larger institutional targets in recent years: Binance paid $4.3 billion in 2023 in the largest OFAC penalty in the agency's history, a settlement that also included DOJ criminal charges and a FinCEN penalty. Kraken settled for $362,000 in 2022; BitGo for $98,000 in 2020; Microsoft for $3.3 million in 2023 for allowing Azure cloud services to reach sanctioned parties; Apple Pay and Tencent for $1.27 million in 2023.

The Specially Designated Nationals and Blocked Persons list

The SDN list is the primary OFAC output. As of mid-2026 it contains approximately 8,000 entries spanning individuals, corporate entities, vessels, and aircraft. Each entry is assigned a permanent unique identifier (UID) that persists across updates and amendments. Deletions and additions are reflected in daily differential files as well as the full-list publications.

The scope of the prohibition for SDN-listed parties is total: all property and interests in property of SDNs that are in the United States or come within the possession or control of US persons must be blocked. Transactions are prohibited regardless of the currency, jurisdiction, or intermediary. A US bank receiving a wire transfer that involves an SDN—even as an undisclosed beneficiary two hops removed—has an obligation to block the funds and file a report with OFAC.

SDN record fields

The XML representation of an SDN entry is richer than the human-readable versions suggest. Each entry carries the following fields at minimum:

uid—permanent numeric identifier, never reused even after delisting.
lastName / firstName / middleName—for individuals; for entities, the full entity name appears inlastName and firstName is empty.
sdnType—one of Individual,Entity, Vessel, or Aircraft.
programList—one or more program codes (IRAN, DPRK, RUSSIA, SDGT, SDNTK, CUBA, VENEZUELA, BURMA, SYRIA, GLOMAG, TCO, and others). A single entry can carry multiple program codes.
title—organizational role where known (e.g., “Director of Procurement”).
Vessel fields—callSign,vesselType, tonnage, grossRegisteredTonnage,vesselFlag, vesselOwner. These populate only for vessel-type entries.
addressList—one or more address blocks, each with address1, city, stateOrProvince, postalCode, and country.
akaList—also-known-as names, each with its own type (strong, weak, formal, informal), and a separate firstName / lastName structure.
idList—identification documents: passport numbers, national ID numbers, tax identification numbers, company registration numbers, vessel IMO numbers, aircraft registration marks, and others. The idType field names the document type.
remarks—free-text field used for supplemental context, including cross-references to related SDN UIDs, family relationships, and alias explanations.

The alias and identification document fields are critical for screening. A single Iranian procurement front company may carry a dozen AKA names representing transliterations from Persian, English trade names, informal abbreviations, and former legal names. A vessel may have changed its name, flag, and registered owner multiple times; theidList IMO number is the stable cross-list identifier.

Other OFAC lists

The SDN list is the most broadly applicable, but OFAC administers several additional lists with distinct legal effects:

Consolidated Sanctions List

The Consolidated Sanctions List (CSL) is the union of all OFAC lists in a single download. It combines the SDN list with the Sectoral Sanctions Identifications list (SSI), the Non-SDN Palestinian Legislative Council List (PLC), the Foreign Sanctions Evaders list (FSE), the Non-SDN Menu-Based Sanctions List (NS-MBS), and the Non-SDN Communist Chinese Military Companies List (CMIC). Compliance programs that screen against the CSL cover all OFAC prohibitions and restrictions in one pass. The download formats parallel the SDN list—XML, CSV, and fixed-width text.

Sectoral Sanctions Identifications list

The SSI list targets Russia-related entities under the Ukraine/Russia executive orders and implementing directives. Unlike SDN designation, SSI listing does not result in a full asset block. Instead, SSI-listed entities are subject to restrictions on specific transaction types defined by OFAC Directives—typically prohibitions on new debt above a specified maturity (14 days for some categories, 60 or 90 days for others) and new equity. US persons may continue routine commercial transactions with SSI-listed entities but may not provide new financing above the defined thresholds. The nuance is significant: a US bank could wire operating funds to an SSI-listed Russian company but could not extend a six-month trade finance facility to the same entity.

Non-SDN Menu-Based Sanctions List

The NS-MBS list implements targeted sanctions on specific transaction types with China-related entities, primarily under executive orders addressing Chinese military-industrial complex companies. The “menu-based” designation reflects the regulatory structure: the underlying executive order specifies a menu of potential sanctions, and Treasury selects which sanctions from that menu apply to each listed entity. Common restrictions include prohibitions on US person investment in publicly traded securities of listed entities and prohibitions on transactions in derivatives whose value is linked to those securities.

Sanctions programs

Each SDN entry is tagged with one or more program codes indicating which sanctions authority justifies the designation. The major active programs include:

IRAN—the Iran sanctions program, one of the largest by entry count. Covers entities involved in Iran's nuclear program, ballistic missile development, oil sector, and sanctions evasion networks.
DPRK—North Korea. Covers weapons proliferation networks, coal export front companies, ship-to-ship transfer facilitators, and overseas labor contracting entities.
RUSSIA / UKRAINE-EO13661 / UKRAINE-EO13685— multiple overlapping Ukraine/Russia executive orders. Entry counts increased sharply after the February 2022 invasion. Covers oligarchs, state-owned defense enterprises, banks, and vessel lists.
SDGT—Specially Designated Global Terrorists. Designations under Executive Order 13224 cover Al-Qaeda, ISIS, Hamas, Hezbollah, and dozens of affiliated networks and financiers. SDGT is a cross-cutting designation: an SDGT-listed entity may simultaneously carry IRAN or SDNTK codes.
SDNTK—Specially Designated Narcotics Traffickers. Covers major drug trafficking organizations including Sinaloa Cartel, CJNG (Jalisco New Generation Cartel), and affiliated money laundering networks.
CUBA—the Cuban Assets Control Regulations, one of the oldest programs, trace to the Trading with the Enemy Act. Restricts transactions with the Cuban government, its ministries, and state-owned enterprises.
VENEZUELA—covers senior Venezuelan government officials, PDVSA affiliates, and corruption networks under executive orders targeting the Maduro regime.
GLOMAG—Global Magnitsky. Human rights and anti-corruption designations under the Global Magnitsky Human Rights Accountability Act. Covers kleptocrats, human rights abusers, and their business networks across jurisdictions.
TCO—Transnational Criminal Organizations. Covers organized crime groups including MS-13 and their financial networks.

The 50% rule

The 50% rule is the most compliance-critical concept in OFAC policy and the one most frequently misunderstood by institutions that treat sanctions screening as a simple list-matching problem. Under OFAC guidance, any entity that is owned 50 percent or more—directly or indirectly—by one or more SDN-listed persons is itself treated as if it were on the SDN list, even if that entity's name does not appear in any OFAC publication.

The implications are significant. A Russian oligarch designated as an SDN who owns 60 percent of a holding company, which in turn owns 70 percent of an operating subsidiary, renders both the holding company and the subsidiary subject to SDN-equivalent restrictions— without OFAC ever publishing those companies' names. A US bank that wires funds to the operating subsidiary has violated OFAC regardless of whether it screened against the SDN list and found no match. Effective compliance requires looking through ownership chains, not merely matching counterparty names.

The ownership threshold is aggregate: if SDN A owns 30 percent and SDN B owns 25 percent of the same entity, the combined 55 percent SDN ownership subjects the entity to restrictions even though neither individual SDN owner crosses 50 percent alone. Institutions with complex counterparty books—prime brokers, correspondent banks, trade finance providers—have built dedicated beneficial ownership resolution workflows to address this requirement.

How to access the data

OFAC publishes the SDN list and all consolidated lists in multiple formats at no cost through the Sanctions List Service atsanctionslistservice.ofac.treas.gov. Three formats are available for each list:

XML—the authoritative machine-readable format. The namespace is versioned; the current namespace URI ishttps://sanctionslistservice.ofac.treas.gov/api/PublicationPreview/exports/XML. All structured fields, AKAs, identification documents, and address data appear in XML; the fixed-width and CSV formats are lossy.
CSV—a flat file with one row per SDN entry and multi-value fields (programs, AKAs, addresses) concatenated with semicolons. Suitable for spreadsheet analysis but inadequate for production screening because the concatenation destroys field boundaries.
Fixed-width text—a legacy format dating to the pre-web era. Still published for backward compatibility with mainframe compliance systems at large financial institutions that have not migrated their core parsing infrastructure.

OFAC also exposes a REST API at ofac.treasury.gov/api that accepts name queries and returns matching SDN records with a confidence score. The API is rate-limited and intended for interactive lookup, not bulk processing. For batch screening and offline analysis, downloading the full XML list and parsing locally is the correct approach.

Parsing the SDN XML in Python

The following script downloads the SDN XML directly from the OFAC Sanctions List Service, parses each sdnEntry element, and writes a CSV to stdout with the primary fields and AKA names pipe-delimited. The namespace prefix must be expanded in every find call; the helper function ns() wraps that expansion.

import requests
import xml.etree.ElementTree as ET
import csv
import sys

# OFAC publishes the SDN XML at a stable URL; no auth required
SDN_XML_URL = "https://sanctionslistservice.ofac.treas.gov/api/PublicationPreview/exports/SDN.XML"

NS = "https://sanctionslistservice.ofac.treas.gov/api/PublicationPreview/exports/XML"

def ns(tag):
    return "{" + NS + "}" + tag

def fetch_sdn_xml():
    print("Downloading SDN XML...", file=sys.stderr)
    r = requests.get(SDN_XML_URL, timeout=120)
    r.raise_for_status()
    return r.content

def parse_programs(entry_el):
    progs = []
    for prog in entry_el.findall(".//" + ns("program")):
        if prog.text:
            progs.append(prog.text.strip())
    return "|".join(progs)

def parse_akas(entry_el):
    akas = []
    for aka in entry_el.findall(".//" + ns("aka")):
        parts = []
        for field in ("firstName", "lastName"):
            el = aka.find(ns(field))
            if el is not None and el.text:
                parts.append(el.text.strip())
        if parts:
            akas.append(" ".join(parts))
    return "|".join(akas)

def parse_sdn(xml_bytes):
    root = ET.fromstring(xml_bytes)
    rows = []
    for entry in root.findall(".//" + ns("sdnEntry")):
        uid_el = entry.find(ns("uid"))
        uid = uid_el.text.strip() if uid_el is not None and uid_el.text else ""

        last_el = entry.find(ns("lastName"))
        last = last_el.text.strip() if last_el is not None and last_el.text else ""

        first_el = entry.find(ns("firstName"))
        first = first_el.text.strip() if first_el is not None and first_el.text else ""

        sdn_type_el = entry.find(ns("sdnType"))
        sdn_type = sdn_type_el.text.strip() if sdn_type_el is not None and sdn_type_el.text else ""

        programs = parse_programs(entry)
        akas = parse_akas(entry)

        rows.append({
            "uid": uid,
            "last_name": last,
            "first_name": first,
            "sdn_type": sdn_type,
            "programs": programs,
            "akas": akas,
        })
    return rows

def main():
    xml_bytes = fetch_sdn_xml()
    rows = parse_sdn(xml_bytes)
    print("Parsed " + str(len(rows)) + " SDN entries", file=sys.stderr)

    writer = csv.DictWriter(
        sys.stdout,
        fieldnames=["uid", "last_name", "first_name", "sdn_type", "programs", "akas"],
    )
    writer.writeheader()
    writer.writerows(rows)

if __name__ == "__main__":
    main()

The output CSV has one row per SDN entry. The programscolumn pipe-delimits all program codes for entries with multiple designations. The akas column pipe-delimits all AKA names—a single complex entity like a major Iranian procurement network may carry ten or more. For production use, the AKAs and identification documents should be normalized into separate tables keyed by UID to support efficient fuzzy matching across all name variants.

Compliance screening in practice

Financial institutions approach OFAC screening at two distinct points in the customer lifecycle: batch screening of the existing customer population against updated lists (typically nightly, after each OFAC publication update) and real-time transaction screening at the point of payment initiation.

Real-time screening is the more operationally demanding requirement. A correspondent bank processing high-volume SWIFT message traffic has milliseconds to screen each payment's originator, beneficiary, and all intermediary parties against the SDN list before releasing the message to the next correspondent. Commercial sanctions screening platforms—Refinitiv World-Check, Dow Jones Risk & Compliance, MSCI OFAC Compliance, and others—maintain in-memory indexes of the SDN list and all supplemental lists, updated within minutes of each OFAC publication, and expose screening APIs that return match scores in single-digit milliseconds.

The core algorithmic challenge in sanctions screening is not list storage but name matching. The SDN list contains names derived from Arabic, Persian, Russian, Korean, Chinese, and dozens of other languages, each with multiple transliteration conventions and no canonical romanization standard. An Iranian individual designated under IRAN may appear with four AKA entries representing different Persian transliterations, the name as it appears on the individual's French-issued residence permit, and an informal nickname used in intercepted communications. A payment system receiving a wire with the individual's name typed by a Turkish bank using its own romanization convention must match that input against all six variants without generating unacceptable false-positive rates on the millions of transactions involving unrelated individuals with common name components.

Production screening engines handle this through a combination of phonetic normalization (Soundex, Metaphone, and language-specific variants), edit-distance scoring (Levenshtein, Jaro-Winkler), token-order-independent comparison (to handle surname/given-name transpositions common across naming conventions), and score thresholding with configurable sensitivity. The threshold setting is a regulated compliance judgment: too low and the institution generates thousands of false positives requiring manual review per day; too high and it risks missing true matches. OFAC has issued guidance that institutions should calibrate their screening to the risk profile of their business, but has not published a minimum score requirement.

Vessel and aircraft screening

Vessel screening adds a dimension that name matching alone cannot address. Sanctioned vessels—particularly those involved in Iranian oil exports and North Korean coal shipments—routinely change their registered names, flags, IMO registration numbers where possible, and reported ownership. The IMO number assigned by Lloyd's Register is theoretically permanent and non-transferable, but the OFAC SDN list has documented cases where fraudulent IMO reassignments have been used as evasion techniques. Effective vessel screening combines IMO number lookup against the SDN idList, MMSI (Maritime Mobile Service Identity) tracking via AIS receivers, and cross-reference against commercial vessel databases like Lloyd's List Intelligence and MarineTraffic to detect flag-of-convenience registrations and ownership chains that connect to SDN-listed entities under the 50% rule.

How OFAC relates to FinCEN, FARA, and DOJ enforcement

OFAC sanctions compliance intersects with several other federal regulatory regimes. The relationship with FinCEN is the most direct: when a financial institution blocks funds under OFAC authority, it must report the blocking to OFAC within ten business days and file an annual report of all blocked property. If a transaction involves a suspected OFAC violation that the institution cannot block—because the sanctioned party's involvement is discovered after funds have already been released—the institution faces overlapping OFAC civil penalty exposure and a FinCEN Suspicious Activity Report (SAR) filing obligation under the Bank Secrecy Act. OFAC violations are a standard SAR filing trigger across financial institution types.

The DOJ connection runs through criminal enforcement. OFAC civil penalties are Treasury administrative actions; DOJ prosecutes the criminal IEEPA violations that accompany large-scale, willful sanctions evasion. The Binance case combined OFAC's $968 million civil penalty with DOJ criminal charges under IEEPA and the Bank Secrecy Act, and a FinCEN penalty of $3.4 billion—all arising from the same course of conduct. DOJ's National Security Division handles IEEPA prosecutions; the False Claims Act has been used in cases where government contractors or financial institutions concealed OFAC violations in federally funded programs.

The FARA connection is less direct but analytically relevant. Agents of foreign governments that are themselves subject to comprehensive OFAC sanctions programs—Iran, North Korea, Cuba, Syria— are typically prohibited from registering under FARA at all, because the act of serving as an agent of those governments would itself constitute an OFAC violation. For Russia-related sanctions, the picture is more complex: SSI-listed Russian entities are not fully blocked, meaning representation of some Russian interests in US proceedings remains permissible under applicable OFAC licenses, while the FARA obligation exists independently.

Building an OFAC screening database

For institutions building internal sanctions screening infrastructure rather than licensing a commercial platform, the SDN XML download is the starting point. The operational requirements beyond the parser above include: a database schema that normalizes entries, AKAs, ID documents, and addresses into separate relational tables; a daily update process that computes deltas against the previous publication and updates the screening index without requiring a full table rebuild; a phonetic normalization pipeline adapted to the specific language families represented in the list; and a case management system for tracking manual reviews of potential matches.

OFAC publishes a delta file in addition to the full list, identifying entries added, deleted, and modified since the previous publication. The delta file uses the same XML schema and references entries by UID. Using delta updates rather than full-list replacement each day is important for institutions with screening indexes that take significant time to rebuild.

The OFAC API at ofac.treasury.gov/api provides a name-search endpoint that returns SDN matches with a score and list of matching fields. The API is useful for ad hoc investigative lookups and for validating that a local screening implementation is producing results consistent with OFAC's own matching logic. It is not suitable as the primary screening mechanism for high-volume payment processing due to rate limits and latency.

For cryptocurrency compliance specifically—the sector that has generated the largest recent OFAC penalties—additional complexity arises from the fact that OFAC has begun including blockchain addresses (Bitcoin, Ethereum, and others) in SDN records' idListfields. A designated individual's known wallet addresses appear as identification documents with idType values ofDigital Currency Address. Exchanges must screen deposit and withdrawal addresses against these, in addition to performing standard name-based KYC screening on account holders.

For the DOJ FARA registration database—which intersects with OFAC in cases involving agents of comprehensively sanctioned foreign governments and Russia-related SSI entities: FARA: The Foreign Agent Registration Database Behind US Influence Operations →

For SEC enforcement actions and how OFAC violations in the securities context intersect with SEC registration and broker-dealer obligations: SEC Enforcement Actions: The Public Record of Every Securities Law Violation →

For DOJ False Claims Act settlements and how sanctions violations in federally funded programs can trigger qui tam liability in addition to OFAC civil penalties: DOJ False Claims Act Settlements: The $70 Billion Fraud Recovery Database →