SanctionsLookupTreasury OFAC API: Official SLS explained (2026)
The Treasury OFAC API, officially known as the Sanctions List Service (SLS), offers a RESTful endpoint for retrieving the SDN and Consolidated Sanctions lists. While it provides raw data (XML/CSV), it functions as a bulk file delivery service rather than a real-time screening engine with built-in search logic.
- Does the U.S. Treasury have an official OFAC API?
- How the Sanctions List Service (SLS) works
- Official data formats
- Treasury SLS vs. real-time screening APIs
- The infrastructure debt of the SLS
- When to use the official Treasury SLS
- When to upgrade to a real-time screening API
Does the U.S. Treasury have an official OFAC API?
Yes. The U.S. Department of the Treasury provides official OFAC sanctions data through the Sanctions List Service (SLS).
The SLS allows developers and compliance teams to programmatically retrieve the Specially Designated Nationals (SDN) List and the Consolidated Sanctions List in structured formats.
While it is technically an API, it functions primarily as a data distribution mechanism rather than a real-time screening API.
It delivers structured sanctions list files, but does not provide built-in identity matching, fuzzy logic, scoring, or transaction-level screening results.
Organizations that use the Treasury SLS must implement and maintain their own database infrastructure, search logic, and compliance workflows on top of the official data feed.
How the Sanctions List Service (SLS) works
The Sanctions List Service (SLS) is designed to enable automated synchronization of official OFAC sanctions data.
While the Treasury’s website offers manual downloads, the Sanctions List Service allows your systems to automate the synchronization of the SDN List and Consolidated Sanctions List via a RESTful interface.
By using the SLS, developers can:
- Filter by program: Instead of downloading the entire database, you can request specific data slices, such as only “Counter Narcotics” or “Regime-based” sanctions.
- Automate change logs: The service provides a way to check for the “Last Updated” timestamp, allowing your system to only pull new data when OFAC actually publishes a change.
- Integrate into CI/CD: It is built for compliance systems that require a direct, verifiable link to the U.S. Department of the Treasury’s source files to ensure audit integrity.
The service is intended for integration into internal compliance infrastructure, ensuring systems reference official Treasury source data for audit and regulatory purposes.
Official data formats
The Treasury SLS provides structured sanctions data files that must be parsed, normalized, and indexed into a database before they can be searched or used for screening.
- Advanced XML: The modern standard based on a structured XSD schema. It is more complex to parse but includes richer entity data, such as vessel names, specific identifier types (e.g., IMO numbers), multiple aliases, and original script names.
- Legacy XML (sdn.xml): An older, simplified XML structure with fewer structured elements, typically used by systems not yet adapted to the advanced schema.
- CSV and fixed-width files: Flat-file formats intended for spreadsheet imports or legacy systems. These formats are easier to ingest but do not fully represent complex entity relationships or metadata.
Because these files are distributed as raw datasets, organizations must implement indexing, matching logic, and screening infrastructure on top of the official data.
Treasury SLS vs. real-time screening APIs
While the Sanctions List Service (SLS) is the essential source for official data, it is fundamentally different from a modern screening API.
The primary distinction lies in utility: the Treasury provides the raw data files, whereas a screening API provides the logic to search that data.
| Feature | Treasury SLS API | Modern screening API |
|---|---|---|
| Primary goal | Bulk file download | Real-time identity search |
| Search logic | None (manual build) | Built-in fuzzy matching |
| Response | Raw XML/CSV files | JSON match results & scores |
| Maintenance | High (server + database) | Low (plug-and-play) |
| Data scope | U.S. lists only | Global lists (UN, EU, UK, etc.) |
The infrastructure debt of the SLS
Using the Treasury SLS directly creates significant infrastructure debt.
Because the SLS lacks built-in scoring, fuzzy matching, and case management, your team must build and maintain the entire screening engine, database, and parser.
Additionally, relying on the SLS carries the risk of stale data if local ingestion scripts fail, and it lacks the workflow tools necessary for audit-ready compliance.
When to use the official Treasury SLS
The Sanctions List Service (SLS) is generally suited for organizations with dedicated engineering resources and internal compliance infrastructure.
You may consider using the Treasury SLS if:
- Building an internal database: Your organization requires a self-hosted sanctions database for security, regulatory, or architectural reasons.
- Large-scale data processing: You need to ingest full SDN or Consolidated datasets for bulk analysis or modeling.
- Existing infrastructure: You have the technical capability to maintain XML parsing, indexing, and matching logic internally.
- U.S.-only requirements: Your screening obligations are limited to U.S. sanctions lists and do not require global coverage.
When to upgrade to a real-time screening API
To avoid the operational complexity of building and maintaining custom infrastructure, many organizations use a commercial screening API.
To understand how this is implemented in practice, see our OFAC API integration guide.
This API layer transforms raw data into an actionable, real-time workflow by adding:
- Fuzzy matching & scoring: Advanced logic that handles typos, aliases, and phonetic similarities with weighted confidence scores.
- Global reach: Access to international sanctions (UN, EU, UK, etc.) alongside U.S. feeds in a single request.
- Transaction infrastructure: The architecture required to screen high-volume transactions in milliseconds.
By providing built-in matching and broader data coverage out of the box, a commercial solution allows your team to focus on your core product rather than the engineering debt of manual data ingestion.