OFAC sanctions (SDN) data feed
- Coverage
- SDN + consolidated
- Cadence
- Hourly detection, daily delta
- Typical volume
- ~300 changes
- Difficulty
- Low to acquire
- Price
- $250 / mo
What's in it
The Treasury sanctions lists, parsed into a typed entity model and delivered as changes rather than as a file:
- Entries - individuals, organizations, vessels, and aircraft with type, primary name, and program codes
- Aliases - strong and weak aliases carried separately, because collapsing them destroys screening precision
- Identifiers - passports, national IDs, tax numbers, IMO and registration numbers, with issuing country
- Dates and places of birth - flattened with precision carried, so a year-only date is not treated as a day-level match
- Addresses - as sub-records rather than a single flattened string
- Change events - new, updated with a field-level changeset, and delisted with confirmation, each citing the run that observed it
Delivered against the same entity model as the other screening sources, so an OFAC entry, a state enforcement action, and a corporate filing about the same party resolve into one record with every source row still individually addressable.
Delivery
Hourly conditional check on the published files with a delta emitted the moment anything changes, which is faster than the daily batch most screening vendors run. Lands in S3, a webhook, or your database. Delisting events publish as pending on the first clean observation and confirmed on the second, because a source fetch that quietly fails looks exactly like a delisting and only one of those is safe to act on.
Why this one is hard
Start with the honest part: the file is free. Treasury publishes the SDN and consolidated lists in XML and CSV specifically so they get screened against, and if all you need is the file, download it and keep your $250. I would rather tell you that here than have you discover it after signing.
What is actually hard is that a sanctions list is not a document, it is a stream of changes, and the file gives you no changes. Every consumer has to compute the delta themselves, and computing it correctly is where the work is: a name change, an added alias, a corrected date of birth, and a delisting are four different events with four different downstream actions, and a naive row diff reports them all as "updated".
Alias semantics are load-bearing. The lists distinguish alias types that carry different match weights, and a pipeline that flattens them into one name array will either flood your queue with false positives or miss a real hit. Same for date-of-birth precision: treating a year-only value as a specific date is how a screening system produces confident nonsense.
Removals are the dangerous case. A row disappearing means a party was delisted, which compliance teams act on. A row disappearing because a fetch failed looks identical in the data. Any feed that reports removals without a confirmation rule is one bad morning away from telling a client to unblock a sanctioned party.
The schemas disagree with each other. The enhanced XML, the legacy files, and the consolidated list do not carry identical fields or identical values for the same entry, so one has to be canonical and the choice has to be documented rather than silently made.
Build versus buy
Build it yourself. Genuinely, for this one source, if you have an engineer who will own the delta semantics and the alias weighting, the acquisition is a download and the rest is a well-specified parsing problem.
Buy it when you want the sanctions delta in the same entity model and on the same delivery rail as your other screening sources, so your queue gets one shape of event rather than six. That is the actual product here, and the price reflects the pipeline rather than the acquisition.
Related
This feed is the real-time spine of the Compliance Screening Stack ($3,650/mo), alongside state attorney general enforcement actions, FINRA BrokerCheck, and Secretary of State entity status.