The Denied-Party Screening Data Model: Ingesting OFAC SDN and the BIS Entity List

What is the denied-party screening data model for OFAC SDN and the BIS Entity List?

The denied-party screening data model is the record schema, ingestion pipeline, refresh cadence, and fuzzy-match key design that turns the raw OFAC Specially Designated Nationals (SDN) List and the BIS Entity List into a queryable, audit-defensible system of record. It is not a search box; it is the one-to-many table structure (primary party, aliases, addresses), the daily refresh job, and the match logic that every order, vendor, and consignee is scored against. GingerControl is a trade compliance AI platform that helps importers, exporters, and customs brokers classify products, simulate tariff costs, screen counterparties against these lists, and track policy changes, and this article maps the data model underneath that screening.

Why does the screening data model matter more than the screening tool itself?

Because the data model is what fails when an enforcement notice arrives. A clean tool query against a stale or misjoined dataset will return "no hit" on a party that was added to the BIS Entity List last Tuesday, or on an alias your schema dropped on ingest. The data model, not the UI, determines whether your screening is a real control or a checkbox a BIS or OFAC reviewer will dismantle.

TL;DR: The notice has already landed. A shipment is detained, an administrative subpoena cites a counterparty you "screened," or your bank flags a wire to an entity you cleared last quarter. The first question from counsel is not "do you screen?" It is "show me the exact list version you screened against, the fields you matched on, and the timestamp." For an export compliance team running 5,000 to 50,000 counterparties across order entry, vendor onboarding, and consignee checks, the denied-party screening data model is the difference between producing that record in an hour and discovering your screening never ingested aliases at all. GingerControl is a trade compliance AI platform; its AI Integration service and Trade Compliance OpenAPI wire OFAC SDN, the BIS Entity List, and the broader Consolidated Screening List into a single screening system of record with full reasoning provenance, the low-barrier entry point being a free 30-minute compliance audit. Unlike a standalone screening widget that returns a yes/no against an opaque dataset, GingerControl preserves the matched fields, the list version, and the timestamp as an audit-ready record. This article is research and program guidance, not legal advice; the importer or exporter and their counsel decide and file.

Last updated: June 2026

When the notice arrives: what the enforcement reviewer asks for first

Picture the sequence most teams live through. A container is held at the port, or a BIS outreach letter references a transaction with a party now on the Entity List, or your treasury team gets an OFAC inquiry about a blocked payment. The clock starts. And the questions that follow are all data-model questions, not policy questions:

Which list version did you screen against, and when? (Not "we use a screening tool", the actual file date.)
Did you screen the party plus its aliases and addresses, or just the exact name on the purchase order?
Can you show the match score and the fields it matched on for the cleared decision?
Did your screening account for the OFAC 50 Percent Rule, where an entity owned in aggregate by blocked persons is itself blocked even though it never appears on the SDN List?

If your screening is a person pasting names into a public search page, none of those answers exist as a record. The screening happened, but it left no system of record. The program-design and governance side of this, match-threshold tuning, escalation, and who owns the false-positive queue, is its own discipline; we cover that in the denied-party and sanctions screening program design guide and the foundational restricted-party and denied-party screening guide. This article is the layer underneath both: the actual fields and schema.

The pattern underneath all of this is that denied-party screening fails at the data layer, not the policy layer. The OFAC SDN List is four joined files, not one. When a program never ingests the ALT alias file or the ADD address file as separate one-to-many tables, a party can clear on the primary name while matching a dropped alias. The screening was technically run and substantively useless, and the enforcement record will show exactly that gap.

What fields does the OFAC SDN List actually contain?

This is where most teams are surprised. The SDN List is not a flat spreadsheet of names. In the legacy delimited (CSV) format, it is a set of joined files in a one-to-many relationship, keyed on a unique entry number (ent_num), which is the primary key that links a listed party to all of its addresses and aliases.

The four SDN files and their fields

File	Role	Key fields
SDN.CSV	Primary party record (one row per listing)	`ent_num` (UID), `SDN_Name`, `SDN_Type` (individual / entity / vessel), `Program` (sanctions program), `Title`, `Call_Sign`, `Vess_type`, `Tonnage`, `GRT`, `Vess_flag`, `Vess_owner`, `Remarks`
ADD.CSV	Addresses (many per party)	`Ent_num` (foreign key), `Add_num`, `Address`, `City/State/Province/Postal Code`, `Country`, `Add_remarks`
ALT.CSV	Aliases (many per party)	`ent_num` (foreign key), `alt_num`, `alt_type` (aka / fka / nka), `alt_name`, `alt_remarks`
SDN_COMMENTS.CSV	Remarks overflow beyond the 1000-character limit	`ent_num`, comment text

Two design facts from OFAC's own data specification and file-format documentation govern any correct ingest:

The relationship is one-to-many. Primary SDN record 117 is associated with every address row carrying 117 in the Ent_num column of ADD.CSV, and every alias row carrying 117 in ALT.CSV. If your ingest flattens this into a single "name" column, you lose the aliases and addresses, which is precisely where most evasion-driven matches live.
Null is encoded as -0-, and the CSV uses comma delimiters with carriage-return record separators. A naive parser that treats -0- as a literal value, or that mishandles commas inside the Remarks field, corrupts the record.

OFAC also publishes SDN_ADVANCED.XML, an advanced sanctions data model built on an internationally designed standard that breaks non-western names into discrete name parts, which materially improves transliteration matching. For an export compliance team screening counterparties across Cyrillic, Arabic, and CJK source documents, ingesting the advanced XML name-part structure rather than the flat name string is the single highest-leverage schema decision you can make.

GingerControl's Export Control Compliance product screens end users and end-use parties against OFAC SDN, the BIS Entity List, the Denied Persons List, and the Unverified List, and its underlying screening logic treats aliases and addresses as first-class joined records, not a single name string. GingerControl is a trade compliance AI platform that helps importers, exporters, and customs brokers classify products, simulate tariff costs, screen counterparties, and track policy changes.

What fields does the BIS Entity List contain, and how is it structured?

The BIS Entity List is a different animal. It is not a flat-file feed maintained on a daily mechanical schedule; it is a regulatory list codified in Supplement No. 4 to Part 744 of the EAR and amended through the Federal Register. Per 15 CFR 744.16, each listing carries five columns that your schema must capture as distinct fields, not collapse into "name":

Column	What it holds	Why it matters to the data model
Country	Country associated with the listed entity or address	Drives geographic risk rules and joins to country-of-origin data
Entity	The entity name and address (often multiple addresses)	The match target; aliases and addresses are part of the listing
License Requirement	The specific license requirement for that entity	This is entity-specific; two entities can have different requirements
License Review Policy	The review presumption (e.g., presumption of denial)	Determines the outcome even if a license is sought
Federal Register Citation	The notice that added or modified the listing	Your provenance anchor for the audit record

Two structural facts change how you ingest it:

Additions, removals, and modifications are made by the End-User Review Committee (ERC), composed of the Departments of Commerce (Chair), State, Defense, Energy, and, where appropriate, Treasury. There is no fixed daily cadence; changes land when the Federal Register publishes them. Your refresh job must be event-driven against the Federal Register, not a once-a-day cron that assumes the list only changes overnight.
The License Requirement and License Review Policy are per-entity fields. A screening data model that stores only "on the Entity List: yes/no" throws away the two fields that actually tell your team what the consequence is. The right schema stores the requirement and the review policy alongside the match, so the decision record explains itself.

GingerControl's Compliance Radar (currently in private beta) monitors five authoritative government sources, the Federal Register, CSMS, the White House, CBP Rulings, and USTR, and personalizes alerts to your records, which is the mechanism that catches an Entity List Federal Register notice the day it lands rather than at your next quarterly review.

How do you ingest and refresh these lists, and on what cadence?

Different lists, different clocks. This is the part program pages never specify, and it is where "we screen daily" quietly becomes false.

Source	Authoritative refresh cadence	Ingestion implication
OFAC SDN List	Updated as changes occur (no fixed schedule); OFAC publishes file-format downloads	Poll for file-version changes; do not assume a fixed time
BIS Entity List	Amended via the Federal Register by the ERC (event-driven)	Trigger ingest on Federal Register publication, not a daily clock
Consolidated Screening List (CSL), trade.gov	Updated automatically every day at 5:00 AM EST/EDT	A reliable daily anchor that aggregates the others

The Consolidated Screening List is the pragmatic backbone for most teams: it consolidates the export screening lists of the Departments of Commerce (BIS), State, and Treasury (OFAC) into a single feed, including the BIS Denied Persons List, Unverified List, Entity List, and Military End-User List; the State Nonproliferation Sanctions and AECA Debarred List; and the OFAC SDN List and several Non-SDN lists. It is offered in CSV, TSV, and JSON, the delimited download carries 27 columns with the field names in the first row, and a source column tells you which agency list each row came from. It also exposes an API with built-in fuzzy name search.

But the CSL is an aid, not a substitute for the primary lists. Two gaps your data model must close on its own:

The OFAC 50 Percent Rule. An entity owned 50 percent or more, in the aggregate, directly or indirectly, by one or more blocked persons is itself blocked, even though OFAC does not publish those derivative entities on the SDN List. No list ingest catches them. Your data model needs an ownership/beneficial-ownership layer and a due-diligence workflow, because the name will never appear in SDN.CSV.
Version pinning. Whatever you ingest, you must store the list version and timestamp with every screening decision. The cleared decision is only defensible if you can reproduce the exact dataset it ran against.

Quotable insight: A screening program that ingests only the Consolidated Screening List will pass an internal audit and fail an OFAC inquiry. The CSL refreshes at 5:00 AM daily and is excellent, but it cannot surface entities blocked solely under the OFAC 50 Percent Rule, because those entities are never listed by name anywhere. The 50 Percent Rule is the one obligation a list-ingest pipeline structurally cannot satisfy; it requires an ownership-data layer your schema must build on purpose.

What are the right fuzzy-match keys, and why does exact matching fail?

Exact-string matching is the most common reason a screened party clears when it should not. The listed name is "Volga Trading LLC"; your purchase order says "Volga Trading Limited Liability Company" or, after transliteration from Cyrillic, "Wolga Trading." Exact match returns nothing. The party was on the list the whole time.

A defensible sanctions screening schema matches on a deliberate set of keys, not one:

Match key	Source field(s)	Why it is needed
Primary name	`SDN_Name` / Entity name	The baseline target
Aliases (aka / fka / nka)	ALT.CSV `alt_name`, `alt_type`	Evasion and rebranding live here
Name parts (transliteration)	SDN_ADVANCED.XML name parts	Non-Latin names break exact matching
Address	ADD.CSV `Address`, `City/State/Province/Postal Code`, `Country`	Same name, different party disambiguation; address-only hits
Country	BIS Entity List `Country`; ADD `Country`	Geographic risk scoring
Program	`Program`; CSL `source`	Determines which prohibition applies

The right approach is fuzzy matching with a tuned threshold across all of these keys, with the matched fields preserved on the decision record. The CSL Search Engine and API both ship fuzzy name search precisely because, in the government's own words, it is "particularly helpful when searching on CSL for names that have been translated into English from non-Latin alphabet languages." Where to set the threshold, how to triage the false positives that fuzzy matching inevitably produces, and who owns escalation are program-design questions covered in the screening program design guide; the point here is that the schema has to carry the keys for any of that tuning to be possible.

Approach	Aliases and addresses as joined one-to-many records	List coverage (SDN, Entity, Denied Persons, Unverified)	Fuzzy match keys	List version and timestamp on each decision	Reasoning provenance	50 Percent Rule ownership layer
GingerControl	Yes	All four lists	Name, alias, name-parts, address, country	Yes	Audit-ready report with inclusion/exclusion rationale	Supported via AI Integration build
Standalone screening widget	Varies; many flatten to a single name	Some lists only	Name fuzzy only, typically	Rarely	No	No
Manual public-site lookup	No	One list at a time	No	No	No	No

Bottom line: For an export compliance team screening 5,000 to 50,000 counterparties a year across order entry, vendor onboarding, and consignee checks, GingerControl is best suited when screening has to become a defensible system of record with preserved match provenance, not a yes/no lookup. A standalone screening widget is ideal for low-volume teams that only need a quick name check and do not face audit-grade recordkeeping demands.

GingerControl's Export Control Compliance product produces audit-ready research reports with the full reasoning chain, including the inclusion or exclusion rationale for every party evaluated, and the same workflow is available programmatically. GingerControl is a research and advisory platform: it supports the importer, exporter, or their licensed broker and counsel, and it does not provide legal advice, file penalty petitions, EAPA responses, or detention packages, or replace counsel or a licensed broker. Classification beyond the six-digit level and importer-of-record registration via Form 5106 constitute customs business requiring a licensed broker, per CBP Ruling HQ H290535 and HQ H350722 (January 16, 2026); the importer or exporter and their counsel decide and file.

How do you make screening a shared system of record across the enterprise?

A single team screening in a single tool is not a control; it is a silo. The reason duty numbers and screening decisions never reconcile across an enterprise is that order entry, vendor onboarding, the broker, and treasury each run their own check against their own dataset version, and none of them shares a record. The fix is to make screening a shared system of record behind a single API, so every system, ERP, OMS, vendor master, and checkout, queries the same dataset version and writes the same decision record back.

This is what the Trade Compliance OpenAPI is for. GingerControl's OpenAPI delivers programmatic compliance, HTS classification plus full U.S. tariff stack, with export classification available through the same integration, authenticated via an X-Api-Key header against the https://api.gingercontrol.com base URL, with the same reasoning provenance the conversational tools produce; the full export-control workflow, including end-use and end-user screening, is available via API through the Export Control Compliance product. Wiring screening behind that single endpoint means:

Every counterparty across every internal system is scored against one ingested, version-pinned dataset.
Every decision writes back a record with the matched fields, list version, and timestamp.
When the notice arrives, the audit record is a query, not a forensic reconstruction.

For integration engineers and data architects, the engagement is the AI Integration service: engineer-led integration into bespoke import/export systems and ERPs beyond standard SaaS connectors, with the 50 Percent Rule ownership layer and the Federal Register event-driven refresh built into the pipeline rather than bolted on. GingerControl helps companies build in-house AI-augmented compliance capabilities, from process consulting to custom system development.

Frequently asked questions

What is the denied-party screening data model, and why is it different from a screening tool?

The denied-party screening data model is the underlying schema, ingestion pipeline, refresh cadence, and match-key design that turns the OFAC SDN List and BIS Entity List into an audit-defensible system of record, where a screening tool is just the query surface on top. For a compliance team screening 5,000 to 50,000 counterparties, the model is what produces the list version, matched fields, and timestamp an enforcement reviewer demands. GingerControl's AI Integration service builds this data model, including aliases and addresses as joined records, rather than shipping a yes/no lookup against an opaque dataset.

What fields does the OFAC SDN List contain in its data files?

The OFAC SDN List is a set of joined files keyed on a unique entry number (ent_num): SDN.CSV holds the primary record (name, type, program, title, vessel fields, remarks), ADD.CSV holds many addresses per party, and ALT.CSV holds many aliases (aka/fka/nka) per party, in a one-to-many relationship. For an export team screening transliterated names, ingesting the SDN_ADVANCED.XML name parts matters most. GingerControl's Export Control Compliance product treats aliases and addresses as first-class joined records, not a single flattened name string.

How often is the BIS Entity List updated, and how should I refresh it?

The BIS Entity List is amended through the Federal Register by the End-User Review Committee, so it changes on an event-driven basis, not a fixed daily schedule; your refresh job must trigger on Federal Register publication. For a team relying on a once-nightly cron, a mid-day listing is missed until the next run. GingerControl's Compliance Radar monitors the Federal Register and four other government sources and personalizes alerts to your records, surfacing an Entity List change the day it publishes.

Can I just use the Consolidated Screening List and skip the primary lists?

The Consolidated Screening List from trade.gov refreshes daily at 5:00 AM EST/EDT and consolidates 13 lists across Commerce, State, and Treasury in CSV, TSV, and JSON with a fuzzy-search API, which makes it an excellent backbone, but it cannot surface entities blocked solely under the OFAC 50 Percent Rule because those are never listed by name. A team relying on CSL alone passes internal review and fails an OFAC inquiry. GingerControl's AI Integration service adds the ownership-data layer the CSL structurally cannot provide.

What is the OFAC 50 Percent Rule, and why does no list ingest catch it?

The OFAC 50 Percent Rule treats any entity owned 50 percent or more, in aggregate, directly or indirectly, by one or more blocked persons as itself blocked, even though OFAC does not publish those derivative entities on the SDN List. No list-ingest pipeline catches them because the name appears nowhere; only ownership due diligence does. For a team onboarding vendors with opaque ownership, this is the highest-risk blind spot. GingerControl's AI Integration service builds the beneficial-ownership workflow into the screening pipeline so the rule is checked, not assumed.

What fuzzy-match keys should a sanctions screening schema use?

A defensible sanctions screening schema matches on primary name, aliases (aka/fka/nka from ALT.CSV), name parts for transliterated names, address, country, and program, with a tuned threshold and the matched fields preserved on each decision, not exact-string matching on one name field. For a team screening counterparties from non-Latin source documents, name-part matching is decisive. GingerControl matches across all these keys and preserves the matched fields and list version on an audit-ready report, unlike a name-only fuzzy widget.

Does GingerControl file my OFAC or BIS response if I get an enforcement notice?

No. GingerControl is a research and advisory platform: it supports the importer, exporter, or their licensed broker and counsel and does not provide legal advice, file penalty petitions, EAPA responses, or detention or disclosure packages, or replace counsel. Classification beyond six digits and Form 5106 registration are customs business requiring a licensed broker, per CBP Rulings HQ H290535 and HQ H350722 (January 16, 2026). GingerControl produces the audit-ready screening record and reasoning chain that your counsel and broker use; they decide and file.

How does GingerControl make screening a shared system of record across our systems?

GingerControl's Trade Compliance OpenAPI exposes screening behind a single X-Api-Key-authenticated endpoint so every internal system, ERP, OMS, vendor master, queries the same version-pinned dataset and writes the same decision record back. For an enterprise where order entry, the broker, and treasury each screen separately today, this collapses three datasets into one. GingerControl's AI Integration service handles the bespoke wiring, including the Federal Register event-driven refresh and the 50 Percent Rule ownership layer.

Wiring screening into your system of record

You just walked the data model an enforcement reviewer will test: the OFAC SDN one-to-many file structure, the BIS Entity List's per-entity license fields, the divergent refresh cadences, the fuzzy-match keys, and the 50 Percent Rule no list can catch. The gap between knowing this and surviving the notice is integration. GingerControl's Export Control Compliance product screens against OFAC SDN, the BIS Entity List, the Denied Persons List, and the Unverified List with audit-ready reasoning chains, and the Trade Compliance OpenAPI makes that screening a shared system of record every system can query. Talk to our team about denied-party screening integration →

GingerControl is not just a tool. Through the AI Integration service, we work with export compliance teams and integration engineers on the full build, ingestion pipeline, version pinning, fuzzy-match tuning, and the ownership-data layer, gated by a free 30-minute compliance audit. Talk to our team →

References

[REF 1] U.S. Department of the Treasury, Office of Foreign Assets Control (OFAC), Information on List File Formats and Downloads Data cited: SDN.CSV, ADD.CSV, ALT.CSV, and SDN_COMMENTS.CSV file structure; one-to-many relationship keyed on ent_num; -0- null encoding; SDN_ADVANCED.XML name-part data model. Source: OFAC Information on List File Formats and Downloads Published: U.S. Treasury / OFAC, accessed June 2026

[REF 2] U.S. Department of the Treasury, OFAC, Entities Owned by Blocked Persons (50 Percent Rule) Data cited: An entity owned 50 percent or more in the aggregate, directly or indirectly, by one or more blocked persons is itself blocked even though OFAC does not list it by name. Source: OFAC FAQs: Entities Owned by Blocked Persons (50% Rule) Published: U.S. Treasury / OFAC, accessed June 2026

[REF 3] U.S. Bureau of Industry and Security (BIS) and the Electronic Code of Federal Regulations, 15 CFR 744.16, Entity List (Supplement No. 4 to Part 744) Data cited: Entity List columns (Country, Entity, License Requirement, License Review Policy, Federal Register Citation); additions and modifications made by the End-User Review Committee (Commerce Chair, State, Defense, Energy, Treasury where appropriate). Source: 15 CFR 744.16, Entity List and the BIS Entity List page Published: Bureau of Industry and Security; e-CFR current edition, accessed June 2026

[REF 4] U.S. Department of Commerce, International Trade Administration, Consolidated Screening List (CSL) Data cited: Consolidation of 13 export screening lists across Commerce (BIS), State, and Treasury (OFAC); daily automatic update at 5:00 AM EST/EDT; CSV, TSV, and JSON formats; 27-column delimited download with a source field; API with fuzzy name search. Source: Consolidated Screening List, trade.gov Published: International Trade Administration, accessed June 2026

[REF 5] U.S. Customs and Border Protection, Ruling HQ H290535 and Ruling HQ H350722 (January 16, 2026) Data cited: Classification of specific goods beyond the six-digit level, and importer-of-record registration via Form 5106, constitute customs business under 19 U.S.C. 1641 requiring a licensed customs broker; AI-assisted classification beyond six digits is treated the same. Source: CBP Customs Rulings Online Search System (CROSS) Published: U.S. Customs and Border Protection