OFAC SDN: what the sanctions list actually contains (and why matching against it is hard)

When you score a Fujairah-to-Djibouti tanker voyage in ArcNautical, one of the 10 intelligence signals that feeds the composite risk score is Sanctions Exposure. On the route shown above, it scores 100 — the maximum. The route passes through waters where sanctioned entities operate, near countries under partial or full OFAC programs, through the Gulf of Aden and Bab el-Mandeb where sanctions evasion is a documented concern.

But where does that score actually come from? What data feeds it? And why is matching a vessel name against a sanctions list so much harder than it sounds?

I spent a week pulling apart the OFAC SDN file to understand its structure. Here's what I found.

---

The file itself

OFAC publishes the Specially Designated Nationals and Blocked Persons List — the SDN list — as an XML file hosted at sanctionslistservice.ofac.treas.gov. (There's an older URL at treasury.gov that still works but adds a 302 redirect chain that roughly triples the download time.) The file is about 30MB of XML.

Inside that XML, each entry is an <sdnEntry> with a type: individual, entity, vessel, or aircraft. Most people think of OFAC as a list of people. It is, mostly. But the vessel entries are what matter for maritime screening.

Four hundred vessels sounds manageable. Just match by IMO number and you're done, right? Not quite.

The IMO number problem

Every commercial vessel over 300 GT gets a unique IMO number — a seven-digit identifier assigned by the International Maritime Organization that stays with the vessel for life, regardless of name changes, flag changes, or ownership transfers. In theory, this makes matching trivial.

In practice, a significant portion of SDN vessel entries have no IMO number listed. Some have only a name and a flag state. Some have an MMSI but no IMO. Some have a "Vessel Registration Identification" that isn't an IMO number at all.

This means you can't just do a database join on IMO numbers. You need name matching. And name matching in maritime is where things get interesting.

Vessel names are not unique

There is no global registry that prevents two vessels from having the same name. Right now, there are multiple vessels named "FORTUNE" sailing under different flags. There are at least three vessels named "GLORY" and multiple called "OCEAN STAR." A name match is not a vessel match — you need the combination of name, flag, IMO (if available), and often the registered owner to confirm identity.

It gets worse. Vessels change names. Frequently. A sanctioned vessel might be renamed, reflagged, and transferred to a new shell company in a matter of weeks. The SDN list includes aliases — OFAC calls them "a.k.a." entries — but these are often incomplete. The vessel might have been renamed twice since OFAC last updated the entry.

Challenge	Example	Why it breaks naive matching
Transliteration	"AL YARMOUK" vs "AL-YARMOUK" vs "AL YARMUK"	Arabic/Cyrillic names have multiple valid Latin spellings
Abbreviations	"MT FORTUNE" vs "M/T FORTUNE" vs "FORTUNE"	Vessel type prefix is sometimes included, sometimes not
Character variants	"GÜNEŞ" vs "GUNES" vs "GUNESH"	Diacritics stripped differently by different systems
Name reuse	Three different vessels named "GLORY"	Name alone is insufficient — need flag + IMO disambiguation
Frequent renaming	SUEZ RAJAN → various aliases	OFAC aliases lag behind real-world name changes

Beyond the name: the ownership graph

Here's the part most sanctions screening tools skip entirely. A vessel might not be on the SDN list itself, but its beneficial owner might be. Or the registered owner is a shell company whose parent is sanctioned. Or the ship manager operates three other vessels that are all sanctioned.

OFAC's 50 Percent Rule states that any entity owned 50% or more by a sanctioned person is itself blocked — even if it doesn't appear on the SDN list by name. This means that a proper sanctions screen isn't just matching against the list. It's walking the ownership chain and checking every entity in that chain.

A vessel can be effectively sanctioned without appearing on any sanctions list, if its beneficial owner is sanctioned under the 50 Percent Rule.

This is why ArcNautical doesn't just check the vessel name against OFAC. We pull the GLEIF LEI registry to find the registered owner's Legal Entity Identifier, walk the corporate parent chain (direct parent, ultimate parent), query beneficial ownership data, and then screen every entity in the chain against OFAC SDN, UN Consolidated Sanctions, and EU sanctions lists. Three lists, every entity, not just the vessel.

What the other sanctions lists add

OFAC SDN is the U.S. list, and it's the most consequential for most shipping companies because of the dollar's role in international trade. But it's not the only list that matters.

List	Publisher	Format	Update frequency	Maritime coverage
OFAC SDN	U.S. Treasury	XML (30MB)	Weekly	~400 vessels, entities, individuals
UN Consolidated	UN Security Council	XML	As needed	Vessels linked to DPRK, Iran programs
EU FSD	European Commission	XML / via OpenSanctions	As needed	EU-specific designations
OpenSanctions Maritime	OpenSanctions	JSON (139MB)	Daily	3,701 vessels, 3,362 companies

The OpenSanctions maritime dataset deserves special mention. It aggregates sanctions data from dozens of national lists into a single queryable dataset — 3,701 vessel records and 3,362 company records. It's the closest thing to a comprehensive maritime sanctions database that exists in the open-source world. We switched from their default dataset (2.6GB, routinely timed out) to the maritime-specific one (139MB, actually works). Pragmatism over comprehensiveness.

How fuzzy matching actually works

A sanctions screening system has two failure modes. False negatives (missing a real match) can mean OFAC enforcement action, which can run into hundreds of millions of dollars. False positives (flagging a clean vessel) waste time and delay commercial operations. The tension between these two is the entire art of sanctions screening.

Here's a simplified version of the matching logic:

// Normalize: strip prefixes, lowercase, collapse whitespace
// "M/T AL-YARMOUK" → "al yarmouk"
const normalized = name
  .replace(/^(M\/T|MT|MV|M\/V|SS|HMS)\s+/i, '')
  .toLowerCase()
  .replace(/[-_\/]/g, ' ')
  .replace(/\s+/g, ' ')
  .trim();

// Exact match against normalized SDN names + aliases
if (sdnIndex.has(normalized)) return { match: true, confidence: 1.0 };

// Fuzzy match: Levenshtein distance, bigram similarity
// Threshold tuned to minimize false negatives
// while keeping false positives manageable
for (const entry of sdnEntries) {
  const similarity = bigramSimilarity(normalized, entry.normalized);
  if (similarity > 0.85) {
    return { match: true, confidence: similarity, entry };
  }
}

The normalization step handles the "M/T" vs "MT" vs bare name problem. The fuzzy matching handles transliteration variants. But the threshold — 0.85 bigram similarity in this example — is the judgment call. Set it too low and every vessel named "STAR" matches every vessel named "STARS." Set it too high and you miss "AL YARMOUK" vs "AL-YARMUK."

There's no perfect threshold. There's only a threshold you've tested against enough real-world data to be confident in.

The spatial dimension

So far this has been about matching vessel identities against names on a list. But ArcNautical adds another layer: spatial sanctions exposure.

When a voyage route passes near Yemen, Iran, Syria, or North Korea — countries with active OFAC sanctions programs — the Sanctions Exposure signal increases. Not because the vessel itself is sanctioned, but because operating in these waters raises the probability of interaction with sanctioned entities, sanctioned cargo, or sanctioned port infrastructure.

The Fujairah-to-Djibouti route scores 100 on Sanctions Exposure specifically because it transits the Gulf of Aden, passing along the Yemeni coast. Yemen has been under a comprehensive OFAC sanctions program since the Houthi-related designations. The route doesn't stop in Yemen. But the proximity matters for risk assessment purposes — especially for underwriters pricing war risk or cargo coverage.

What most tools get wrong

Having worked through the data, here's what I think most maritime sanctions screening tools miss:

1. They check the vessel, not the chain. Matching the vessel name against OFAC is step one. But the 50 Percent Rule means you need to check every entity in the ownership structure. Most tools don't walk the ownership graph.
2. They treat it as a binary. "Sanctioned" or "not sanctioned." But risk exists on a spectrum. A vessel owned by a transparent Nordic group transiting the same waters as a vessel with three layers of shell companies in the Marshall Islands faces different scrutiny — even if neither is on the SDN list.
3. They ignore geography. A vessel's route matters. The same vessel on a Rotterdam-to-New York run has a different sanctions exposure profile than on a Fujairah-to-Djibouti run, even though the vessel itself hasn't changed.
4. They update too slowly. OFAC updates the SDN list roughly weekly. If your screening tool refreshes monthly, you're flying blind for three weeks out of four.

---

Sanctions screening sounds simple until you actually look at the data. It's not a lookup table. It's a fuzzy matching problem on ambiguous names, combined with an ownership graph traversal, combined with a spatial risk assessment against active sanctions programs. Getting any one of these wrong can cost a shipping company its banking relationships — or worse.

If you're doing vessel vetting or voyage risk assessment and you've run into these matching edge cases, I'd like to hear about it. What trips up your screening workflow? Which edge cases have bitten you?