The US Consolidated Screening List is not OFAC's consolidated list
Thirteen US restricted-party lists in one daily file from Commerce, State and Treasury — what it holds, and the stale rows inside it.
Two American files are called a consolidated list, and confusing them is the most common mistake in a US screening programme. OFAC's Consolidated Sanctions List gathers Treasury's non-SDN programmes. The Consolidated Screening List, published by the International Trade Administration at the Department of Commerce, is something else entirely: an aggregation of thirteen restricted-party lists run by three departments, assembled so that an exporter can check one file instead of thirteen. It carries the SDN List, the four Bureau of Industry and Security lists, the State Department's ITAR Debarred and Nonproliferation lists, and OFAC's non-SDN programmes, each row tagged with the list it came from. The ITA rebuilds it automatically every day at 05:00 Eastern and serves it as CSV, TSV and JSON with no key and no registration, alongside a fuzzy-search API. The catch is that the ITA aggregates rather than curates. The file we downloaded on 4 September 2026 held 26,079 rows, and 1,133 of the 1,596 Denied Persons rows in it carried an expiry date already in the past — BIS's own denial-order file, published on 14 April 2026, has 564 rows, of which 38 had expired. If you screen the CSL as it ships, a meaningful part of your Commerce hit rate will be orders that lapsed years ago.
What this workflow covers
SCOPE- Row counts by source list on 4 September 2026: SDN 19,326; BIS Entity List 3,419; Denied Persons 1,596; ITAR Debarred 801; SSI 286; Unverified List 222; Nonproliferation (ISN) 161; Palestinian Legislative Council 78; Military End User 70; CMIC 68; NS-MBS 51; CAPTA 1. The Foreign Sanctions Evaders List is a named source with no rows in it.
- 29 columns per row, including the parsed identifiers the raw SDN.CSV never gives you: separate dates_of_birth, ids, nationalities, citizenships and places_of_birth fields rather than one remarks blob.
- Only 19,810 of the 26,079 rows carry an entity_number, and every one of them comes from a Treasury list. BIS and State rows have no stable numeric key at all, which is why deduplication across days is harder than it looks.
- The _id field is a 56-character content hash, not an identifier. Change one character in an address and the row gets a new _id, so it cannot be used to track a listing over time.
- Downloads: consolidated.csv, consolidated.tsv and consolidated.json under https://data.trade.gov/downloadable_consolidated_screening_list/v1/, plus a search API with fuzzy name matching. No authentication, no fee.
- Rebuilt daily at 05:00 EST/EDT. There is no delta file and no change log: to see what moved you diff yesterday's download against today's, keyed on source plus name plus address rather than on _id.
- Ownership analysis is entirely outside the file. The 50 percent rule, the BIS affiliates rule and the Entity List's licence-review policies all sit outside the file, and a subsidiary of a listed party will not appear in it.
- False positives concentrate in three places — the expired Denied Persons rows described above, the 6,269 rows with a blank type field where you cannot tell a person from a company, and the 18,568 rows with no date of birth to discriminate on.
- Treat a hit by reading the source column first. An SDN row blocks. An Entity List row triggers a licence requirement on the specific items in Supplement No. 4. An Unverified List row triggers a statement requirement. The response is not the same, and a single 'CSL hit' flag hides the difference. Our own coverage register lists the OFAC and BIS sources behind this file separately rather than as one blob; the two State Department lists in the CSL, ITAR Debarred and Nonproliferation Sanctions, are not on it.
Key statistics
DATA- Rows in the CSL downloaded 4 September 2026
- 26,079 across 12 populated source lists
- Counted from consolidated.csv
- Denied Persons rows with an expiry date already past
- 1,133 of 1,596
- Counted from consolidated.csv against 4 September 2026
- Rebuild schedule
- Every day at 05:00 EST/EDT
- International Trade Administration, Consolidated Screening List
Compliance glossary
TERMS- Consolidated Screening List (CSL)
- The International Trade Administration's daily aggregation of thirteen US restricted-party lists published by the Departments of Commerce, State and the Treasury, distributed as CSV, TSV and JSON with a search API.
- Source list tag
- The column in every CSL row naming the originating list. It is the field that decides what a hit means, because a Treasury blocking designation and a Commerce licence requirement arrive in the same file.
- Restricted party screening
- Checking counterparties in a trade transaction — buyer, consignee, end user, freight forwarder, bank — against export-control and sanctions lists before goods, software or technology move.
- Content hash identifier
- A record key derived from the record's own contents. It is stable only while nothing in the record changes, so it cannot be used to follow a listing through amendments.
Authoritative references
SOURCES- 01Consolidated Screening List
U.S. Department of Commerce, International Trade Administration
- 02consolidated.csv — Consolidated Screening List bulk export
U.S. Department of Commerce, International Trade Administration
- 03Denied Persons List
U.S. Department of Commerce, Bureau of Industry and Security
- 04Sanctions List Service
U.S. Department of the Treasury, OFAC
Frequently asked questions
Q&A- Is the Consolidated Screening List the same as OFAC's consolidated list?
- No, and the names are genuinely unhelpful. OFAC's Consolidated Sanctions List is a Treasury file containing Treasury's non-SDN programmes. The Consolidated Screening List is a Commerce file that contains the SDN List, OFAC's non-SDN programmes, the four BIS lists and two State Department lists. If a policy says 'we screen the consolidated list', find out which one it means.
- Do I still need the SDN file if I pull the CSL?
- For most purposes the CSL's SDN slice is the same population, and it arrives with the identifiers already parsed out of the remarks field. What you lose is OFAC's own publication metadata, the delta files and the advanced XML relationship model. Trade-compliance teams tend to live on the CSL; financial-crime teams tend to keep pulling from OFAC directly.
- How do I find out what changed in the CSL overnight?
- You diff it yourself. The ITA publishes no change file and the _id is a content hash, so a row that gets a corrected postcode looks like a deletion plus an insertion. Build your own key from source, name and the first address line, store yesterday's snapshot, and compare. Anything else will over-report changes.
- Why does the CSL show denial orders that expired years ago?
- Because the ITA keeps the historical rows rather than pruning them. On 4 September 2026 the CSL held 1,596 Denied Persons rows against 564 in BIS's own current file, and 1,133 of those CSL rows had an end_date in the past. Filter on end_date before you alert, or your export team will spend its week on orders that lapsed in 2009.
- Is the CSL API good enough to screen against directly?
- It is good enough to check a name interactively and to prototype against. It is not a compliance programme: the ITA itself describes the list as an aid to industry, there is no service commitment, and you get no evidence artefact you can put in a file. Most teams pull the flat file, match locally and keep the API for ad-hoc lookups.
- Does the CSL cover non-US lists?
- No. Every source in it is a US federal list from Commerce, State or Treasury. EU, UK, UN, Canadian and Australian designations are not in the file and never will be. A screening programme built on the CSL alone is a US export-control programme, not a sanctions programme.