Trade.gov Consolidated Screening List: The Federal Index of Who US Exporters Cannot Do Business With

Before a US company ships a single good across the border, transfers a line of software or technical data to a foreign engineer, or wires payment to an overseas counterparty, it has to answer one question: is the other party on a list? The Consolidated Screening List is where that question is answered. Maintained by the International Trade Administration at Trade.gov, it merges the principal restricted-party and sanctions lists from three departments—Commerce, State, and Treasury—into a single searchable feed of tens of thousands of entries, the names the United States government has decided its exporters may not freely do business with.

This article covers what the Consolidated Screening List is and why one consolidated feed exists at all; the three departments and the individual lists each contributes—the BIS Entity List, Denied Persons List, and Unverified List; the State Department's AECA Debarred List; and OFAC's Specially Designated Nationals and other sanctions lists; the legal authorities—the Export Administration Regulations and the ITAR—that turn an appearance on the list into a licensing requirement or an outright prohibition; what restricted-party screening actually is and where it sits in an export-compliance workflow; the fuzzy-name search that catches alias and transliteration variants exact matching misses; how a single real-world entity appears across more than one source list and why de-duplication matters; a Python workflow that screens a counterparty list against the CSL API and de-duplicates parties spanning multiple lists; and the caveats—name-only false positives, the entry-versus-entity distinction, the fifty-percent rule, and reporting lag—that every analyst must internalize before acting on a match.

What the dataset is

The Consolidated Screening List, universally abbreviated the CSL, is a single searchable and downloadable list maintained by the International Trade Administration (ITA) within the US Department of Commerce. Its purpose is consolidation: rather than forcing an exporter to check a dozen separately published lists scattered across three departments' websites, the CSL gathers the principal export-screening and restricted-party lists into one feed with one search interface and one bulk download. It does not create new restrictions of its own and it is not itself the legal authority for any bar—each entry remains governed by the originating list and the statute and regulation behind it—but as a practical matter the CSL is the front door through which most exporters and compliance systems actually do their screening. It is surfaced through Trade.gov's free public API and bulk download and comprises tens of thousands of entries.

In our database this record is stored as the table trade_screening, with the grain of one row per listed party-source entry. The qualifier is essential: a single real-world entity that appears on, say, both the OFAC Specially Designated Nationals List and the BIS Entity List contributes two rows, one per source list. The columns capture who is listed, where they are, which list flagged them, and under what authority:

name                      -- the listed party (entity or individual)
alt_names                 -- aliases, a.k.a.s, and transliteration variants
addresses                 -- street, city, country of the listed party
country                   -- primary country associated with the party
source                    -- the originating list (e.g. SDN, Entity List)
source_list_url           -- link to the authoritative source publication
programs                  -- the sanctions / control program(s) cited
legal_authority           -- the statute or regulation behind the listing
federal_register_notice   -- FR citation for the listing action (where applicable)
start_date                -- effective date of the listing
ids                       -- passport, tax, registration, and other identifiers
type                      -- Individual, Entity, Vessel, or Aircraft

The source column is the load-bearing field. Because the CSL is an aggregation, every row carries the name of the list it came from, and that provenance is what determines which legal regime applies and therefore what an exporter must do about a match—an entry from the Denied Persons List means something different, legally, from an entry on the Sectoral Sanctions Identifications List. The alt_names field is the next most important: restricted parties operate under many spellings, aliases, and front names, and a list that recorded only one canonical spelling would be trivially evaded, so the CSL records the known variants and exposes a fuzzy search over them. The programs and legal_authority fields explain why the party is listed—a nonproliferation program, a country sanctions program, an arms-export debarment—and the federal_register_notice ties a listing back to the formal action that created it. Together these fields turn a bare name into an actionable compliance record: who, where, which list, under what authority, and since when.

The three departments and their lists

The structure of the CSL mirrors the structure of US export and sanctions control, which is divided among three departments. Understanding which department owns which list—and what each list means—is the key to reading the source column and knowing what a match implies.

Commerce, through the Bureau of Industry and Security (BIS), contributes the lists that govern dual-use goods and technology—items with both commercial and potential military or proliferation applications. The Entity List names foreign parties—companies, research institutions, government bodies, individuals—subject to specific license requirements for the export of designated items, imposed because they present a risk of diversion to weapons programs, military end-use, or other activities contrary to US national security or foreign-policy interests; an Entity List designation typically carries a license requirement and a presumption or policy of denial. The Denied Persons List names parties whose export privileges have been denied outright, usually as the result of an enforcement action for violating the Export Administration Regulations—dealing with a denied person in an export transaction is itself a violation. The Unverified List is the softest of the three: it names foreign parties that BIS has been unable to verify through an end-use check, signaling heightened diligence and red-flag obligations rather than an outright bar. BIS also maintains a Military End User List, which the CSL likewise carries.

The State Department, through the Directorate of Defense Trade Controls (DDTC), contributes the AECA Debarred List. Where BIS governs dual-use items, State governs defense articles and services—munitions—under the Arms Export Control Act (AECA) and the International Traffic in Arms Regulations (ITAR). The Debarred List names parties barred from participating in the export of defense articles and defense services, typically following a conviction for violating the AECA (statutory debarment) or an administrative debarment. A party on this list is prohibited from ITAR-controlled transactions, the arms-trade counterpart to the Denied Persons List.

The Treasury Department, through the Office of Foreign Assets Control (OFAC), contributes the sanctions lists, of which the Specially Designated Nationals and Blocked Persons List (SDN) is the most significant. The SDN List names individuals and entities—and vessels and aircraft—whose property and interests in property are blocked and with whom US persons are generally prohibited from transacting at all, under the country- and activity-based sanctions programs OFAC administers. The CSL also carries OFAC's other sanctions lists, including the Foreign Sanctions Evaders List and the Sectoral Sanctions Identifications List, the latter of which restricts only certain categories of dealing rather than imposing a full block. The crucial point is that OFAC sanctions answer a different question from the export-control lists: not “may I export this item to this party?” but “may I deal with this party at all?”

The EAR, the ITAR, and what a listing means

An appearance on the Consolidated Screening List is not a mere advisory—it triggers obligations under one of the two great bodies of US export law, and which one depends on the source list. The two regimes are distinct in scope, in administering agency, and in the severity of the consequences.

The Export Administration Regulations (EAR), administered by BIS and built on the Export Control Reform Act, govern the export, reexport, and in-country transfer of dual-use items—commercial goods, software, and technology that also have military or proliferation potential. Under the EAR, whether a transaction needs a license turns on three things at once: what the item is (its classification on the Commerce Control List), where it is going (the destination country), and—the point that makes the CSL essential—who the end user and other parties to the transaction are. A party on the BIS Entity List carries item-specific license requirements that may not otherwise apply; a party on the Denied Persons List cannot lawfully participate in an export transaction at all. A distinctive feature of the EAR is the concept of a deemed export: releasing controlled technology or source code to a foreign national, even inside the United States—a foreign engineer reading a controlled specification—is treated as an export to that person's home country, which is why screening reaches employees, visitors, and collaborators, not only shipments crossing a physical border.

The International Traffic in Arms Regulations (ITAR), administered by State's DDTC under the Arms Export Control Act, govern defense articles and defense services—items and technical data specifically designed or modified for military application and enumerated on the United States Munitions List. The ITAR is generally stricter than the EAR: it requires registration of manufacturers and exporters, imposes licensing on a broad range of activity, and tightly restricts the involvement of foreign persons. A party on the AECA Debarred List is prohibited from participating in ITAR-controlled exports. The dividing line between the EAR and the ITAR—is a given item dual-use or a defense article?—is one of the recurring hard questions of export compliance, and the source list on a CSL match is the first signal of which regime an analyst is in.

Overlaying both, and reaching beyond exports, are the OFAC sanctions behind the SDN and related lists. These flow from the International Emergency Economic Powers Act and the various country and program authorities, and a blocking designation does not merely require a license—it generally prohibits any dealing by a US person with the designated party and freezes that party's property within US jurisdiction. The consequences of getting any of this wrong are severe and run to strict-liability civil penalties and, for willful violations, criminal exposure, which is precisely why screening against the CSL is a non-negotiable control rather than a best-practice nicety.

Restricted-party screening in practice

Restricted-party screening is the operational act of checking the parties to a transaction against the restricted-party and sanctions lists before the transaction proceeds. It is one leg of a three-part export-compliance question—what is the item, where is it going, and who are the parties—and the CSL is the instrument for the third leg. In a mature compliance program, screening is not a one-time gate but a recurring control applied at multiple points in the lifecycle of a relationship and a transaction.

The parties screened are everyone with a role in moving the item: the end user who will ultimately receive and use it, the ultimate consignee, intermediate consignees and freight forwarders, the purchaser, and any other party to the transaction—and, under the deemed-export rule, foreign-national employees and visitors who may be exposed to controlled technology. Screening typically happens at onboarding of a new customer or vendor, again at order entry, again before shipment, and on an ongoing basis through periodic re-screening of the existing book of counterparties against the updated list, because a party that was clean when onboarded can be designated later. This rescreening cadence is why the CSL's currency matters: a designation added on Monday must be caught before Tuesday's shipment.

What an exporter must do upon a match depends on the source list. A hit against the Unverified List raises a red flag that must be resolved before proceeding—additional due diligence, an end-use statement, sometimes a license. A hit against the Entity List means the transaction likely requires a license that will be reviewed under a stated—often denial—policy. A hit against the Denied Persons List, the AECA Debarred List, or the SDN List generally means the transaction cannot lawfully proceed at all without specific authorization that may be unavailable. The screening step does not make these legal judgments on its own; it surfaces the match so that a compliance professional can apply the correct regime. The CSL's job is to make sure the match is surfaced in the first place—which is where the quality of the name matching becomes decisive.

Fuzzy matching, aliases, and transliteration

The hardest technical problem in restricted-party screening is not maintaining the list—it is matching against it. Restricted parties have every incentive to obscure their identity, and even those who do not, frequently have names that resist clean matching, so a naive exact-string comparison against a canonical spelling is close to useless. The CSL is built around this reality, which is why it records aliases and exposes a fuzzy search.

Several distinct difficulties converge. The first is aliases and a.k.a.s: a sanctioned entity may operate under multiple trade names, a front company, or a deliberately varied corporate style, and the authoritative listing captures the known variants in the alt_names field. The second is transliteration: an enormous share of listed parties have names originally written in Arabic, Cyrillic, Persian, or Chinese, and there is no single correct way to render those names in the Latin alphabet—Muhammad, Mohammed, Mohamad, and Muhammed are the same name, and a Russian company can be Romanized several ways. A list that recorded only one spelling would be evaded by anyone using another. The third is ordinary noise: word order, the presence or absence of corporate suffixes, abbreviations, punctuation, and typographical errors in the transaction data being screened. Fuzzy matching—edit-distance, phonetic, and token-based techniques—is the standard answer, and the CSL's fuzzy_name search parameter applies it server-side so a caller does not have to reimplement it.

Fuzzy matching is a balance, not a free lunch. Loosen the threshold and the system catches more true variants but also generates more false positives—innocent parties whose names happen to resemble a listed one—each of which must be cleared by a human, at real operational cost. Tighten it and false positives fall but a cleverly varied alias can slip through. There is no setting that is correct for every program; the right balance depends on an organization's risk tolerance, transaction volume, and the consequences of a miss. The practical discipline the CSL enforces is that a fuzzy match is a candidate to be adjudicated against the full identifying detail—address, country, identifiers, the source listing itself—and never a conclusion on its own. This is the same lesson that runs through every name-based federal screening list, and it is the single most important thing to get right.

One entity, many lists: de-duplication

Because the CSL is a consolidation of independently maintained lists, one of its most important and most easily mishandled features is that a single real-world entity can appear on more than one source list at once. A company that has been both denied export privileges by BIS and blocked by OFAC will appear as separate entries—one from each list—and our table, with its grain of one row per party-source entry, faithfully preserves both. This is correct: each listing rests on a different authority with different consequences, and collapsing them would lose the legal provenance that the screening depends on.

But it has a consequence for analysis. A raw count of CSL entries is a count of listings, not of distinct parties; the full set of entries resolves to a smaller number of unique real-world entities once cross-list duplicates are collapsed. Any analyst who wants to count “how many parties are restricted” rather than “how many listing actions exist” has to de-duplicate—and de-duplication on a free-text, multiply transliterated name field is exactly the entity-resolution problem that the fuzzy-matching section describes, now turned inward on the list itself. Two entries that are the same party may carry slightly different spellings; two entries with identical names may be different parties. Done carefully, de-duplication also yields a genuinely useful signal: the parties that appear on multiple source lists are, almost by definition, the highest-concern names—an entity that both Commerce and Treasury have independently acted against is one that has drawn the attention of more than one part of the government. Surfacing those multiply listed parties is one of the more valuable things the consolidated structure makes possible, and the Python workflow below does exactly that.

Analytical uses

Beyond the operational lookup an exporter performs before each shipment, the CSL as a structured dataset supports a range of analysis that a single search cannot.

Batch counterparty screening is the foundational use: running an entire customer, vendor, or partner book against the list in one pass rather than one lookup at a time, with the fuzzy search catching alias and transliteration variants, and the results triaged by source list so that the highest-consequence hits—SDN, Denied Persons, Debarred—rise to the top. This is the engine inside every compliance screening tool, and building it directly against the free CSL API puts the same capability in reach of an organization without a commercial subscription.

Composition and trend analysis by source list and programtreats the full feed as data: how the entries distribute across the source lists, which sanctions and control programs account for the most listings, and—by tracking the list over time—how designations rise and fall as geopolitical events drive new sanctions programs and Entity List additions. The start_date and Federal Register fields make it possible to date listing actions and connect surges in the list to the policy moments that produced them.

Cross-list overlap analysis exploits the consolidated structure to find the parties that appear on multiple lists—the multiply designated, highest-concern entities described above—and to study how the three departments' actions correlate. Finally, country and network analysisuses the country and address fields to map where restricted parties concentrate, and the addresses and shared identifiers to surface clusters of related entities—front companies, corporate families, and procurement networks—that no single entry reveals on its own. As with the SAM exclusions list, the analytical value rises sharply once the list is joined to other data and once careful entity resolution is applied to the name and identifier fields.

Python workflow: screening a counterparty list against the CSL API

The script below screens a list of counterparties against the Consolidated Screening List API, uses the fuzzy-name search so that alias and transliteration variants are caught, and then de-duplicates—reporting how many distinct parties the raw hits resolve to and, crucially, which parties appear on more than one source list. The CSL API is free for basic use; Trade.gov asks callers to register for an API key on the ITA Data Services Platform, passed as the api_key query parameter, and applies a rate limit, so the script isolates the key in one place and paces its requests. Because a single real-world entity routinely appears across several source lists, the raw hit count overstates the number of distinct restricted parties—de-duplication is not optional cleanup but the step that turns listings into parties.

import requests, time
import pandas as pd
from collections import defaultdict

# Trade.gov Consolidated Screening List (CSL) API.
#
# The CSL aggregates the principal US restricted-party and sanctions
# lists from three departments into one searchable feed. The search
# endpoint supports an exact "name" query and a "fuzzy_name" query that
# tolerates alias and transliteration variants, plus filters for
# country and source list. Basic use is free; Trade.gov asks callers to
# register for an API key on the ITA Data Services Platform, passed as
# the "api_key" query parameter, and applies a rate limit -- isolate the
# key here rather than hard-coding it inline.
BASE = "https://api.trade.gov/consolidated_screening_list/search"
API_KEY = "YOUR_TRADE_GOV_KEY"  # register at developer.trade.gov


def search(name, country=None, fuzzy=True, size=50):
    # fuzzy_name=true makes the match alias- and transliteration-aware,
    # which is the whole point of screening against a list whose entries
    # carry many spellings of the same real-world party.
    params = {
        "api_key": API_KEY,
        "size": size,
        "fuzzy_name": "true" if fuzzy else "false",
        "name": name,
    }
    if country:
        params["countries"] = country  # ISO-3166 alpha-2, e.g. "RU,CN"
    r = requests.get(BASE, params=params, timeout=60)
    r.raise_for_status()
    return r.json().get("results", [])


def screen(counterparties):
    # counterparties: list of (name, country) tuples to screen.
    hits = []
    for name, country in counterparties:
        for row in search(name, country=country, fuzzy=True):
            hits.append({
                "screened_name": name,
                "screened_country": country,
                "match_name": row.get("name"),
                "alt_names": "; ".join(row.get("alt_names") or []),
                "source": row.get("source"),           # which list flagged it
                "programs": "; ".join(row.get("programs") or []),
                "fr_notice": row.get("federal_register_notice"),
                "match_country": (row.get("addresses") or [{}])[0].get("country"),
            })
        time.sleep(0.2)  # stay under the rate limit
    return pd.DataFrame(hits)


# A real-world entity often appears on more than one source list -- e.g.
# the SDN List and the Entity List -- so the raw hit count overstates
# the number of distinct parties. De-duplicate on the normalized name.
def dedupe_parties(df):
    if df.empty:
        return df
    df["_key"] = df["match_name"].str.upper().str.replace(r"[^A-Z0-9 ]", "", regex=True).str.strip()
    by_party = defaultdict(set)
    for _, row in df.iterrows():
        by_party[row["_key"]].add(row["source"])
    multi = {k: sorted(v) for k, v in by_party.items() if len(v) > 1}
    print(f"Distinct flagged parties: {df['_key'].nunique():,} "
          f"(from {len(df):,} raw source-list hits)")
    print(f"Parties on 2+ source lists: {len(multi):,}")
    for party, sources in list(multi.items())[:10]:
        print(f"  {party[:40]:<40} -> {', '.join(sources)}")
    return df.drop_duplicates(subset=["_key", "source"])


watchlist = [
    ("Mahan Air", "IR"),
    ("Huawei Technologies", "CN"),
    ("Rosoboronexport", "RU"),
    ("Acme Trading Company", "AE"),  # a benign counterparty, expected: no match
]

results = screen(watchlist)
results = dedupe_parties(results)

# Which source lists are doing the flagging across this watchlist?
if not results.empty:
    print("\nHits by source list:")
    for src, n in results["source"].value_counts().items():
        print(f"  {src[:48]:<48} {n:>4,}")

Two things about this script deserve emphasis. First, the fuzzy search is the point, not a convenience: screening against this list with exact matching would miss precisely the aliased and transliterated names that the list exists to catch, so the fuzzy_name parameter is doing the heavy lifting—at the cost, as the caveats stress, of false positives that a human must clear. Second, the de-duplication step is what converts a pile of source-list hits into a defensible answer to “how many distinct parties did we flag, and which ones drew action from more than one department?” For production screening at scale, the CSL bulk download—the full list as a single file—is more efficient than thousands of paginated API calls and ships with the authoritative field definitions for the release; the API is the right tool for targeted, on-demand screening and the download for whole-book passes and longitudinal analysis.

Limitations and analytical caveats

The CSL is the most convenient consolidated record of US restricted parties, but it carries structural limitations that an analyst must internalize before drawing conclusions—or, far more dangerously, before acting on a match.

Name-only matching produces false positives, and a hit is a candidate, not a conclusion. This is the most consequential caveat, and it is the same one that governs every name-based federal screening list. Fuzzy matching, tuned to catch alias and transliteration variants, will inevitably flag innocent parties whose names resemble a listed one—common names collide, and corporate names recur across unrelated firms. A match is a flag to be adjudicated against the full identifying detail—address, country, identifiers, the underlying source listing—not a determination that a counterparty is restricted. Treating a fuzzy hit as a conclusion can wrongly block a legitimate party, while over-tuning to suppress false positives can let a true match slip through; both failures are real, and resolving them is irreducibly a matter of human judgment over the candidate set.

An entry is a listing, not a party. Because the grain is one row per party-source entry, a raw count of CSL rows counts listing actions, not distinct entities. The same real-world party appears multiple times when it sits on multiple source lists, so the full set of entries resolves to a smaller number of unique parties. Any head-count of “restricted parties” that skips de-duplication overstates the universe, and de-duplication itself is an entity-resolution problem on a free-text, multiply transliterated name field, with all the difficulty that implies.

The list does not capture the fifty-percent rule and other derived restrictions. OFAC's sanctions reach beyond the named parties: under OFAC's aggregation rule, an entity that is owned fifty percent or more, directly or indirectly, by one or more blocked persons is itself treated as blocked—even though it may not appear on the SDN List by name. The CSL lists the explicitly designated parties; it does not and cannot enumerate every entity that is restricted by virtue of ownership. A clean CSL screen is therefore necessary but not sufficient: a counterparty absent from the list may still be restricted through ownership by a listed party, which is why thorough due diligence reaches into beneficial ownership rather than stopping at a name check.

There is reporting lag, and consolidation is not the legal source. An entry reaches the CSL after the originating department publishes the designation and the consolidation refreshes, so there is a window—usually short—between an action and its appearance in the consolidated feed. For a high-stakes determination the authoritative source is the originating list and the Federal Register notice behind it, not the convenience aggregation; the CSL itself flags that it is a screening aid and that users should confirm against the source publications. More broadly, the CSL covers the principal restricted-party and sanctions lists but is not the entirety of US trade restriction—debarments, licensing requirements driven by item and destination, and other program-specific controls live outside it. The list is the indispensable first screen, not the last word.

Held with these caveats in mind, the trade_screening table is a uniquely useful resource: tens of thousands of entries that consolidate, into one searchable feed, the restricted-party and sanctions lists the United States maintains across Commerce, State, and Treasury—the single index every exporter must consult to answer the question that precedes every cross-border deal, which is simply whether the other party is one the government has said they may not freely do business with.