OFAC Sanctions Screening API: Resource Guide for Alternative Lender Compliance Teams [2026]

Executive Summary: An OFAC sanctions screening API automates the part of BSA/AML compliance that is non-negotiable. Every U.S. financial institution and every lender touching money in a federally regulated flow must screen applicants and counterparties against the Treasury Department's Specially Designated Nationals list and related watchlists.^[1] Doing this by hand is not viable at any meaningful volume. This resource explains how screening APIs work, where confidence scores fit into real underwriting decisions, how to build threshold policies auditors will accept, and where Cobalt sits in the vendor landscape.

What Is an OFAC Sanctions Screening API and Why Does Every Lender Need One?

An OFAC sanctions screening API accepts a name, searches it against the U.S. Treasury Department's Office of Foreign Assets Control watchlists, and returns potential matches with confidence scores. It exists because the alternative is manual list checking, and manual checking does not scale past a handful of applications per week.

The requirement is not a grey area. The Bank Secrecy Act, as enforced by FinCEN, obligates covered financial institutions to maintain a risk-based sanctions screening program as part of their AML program.^[2] OFAC itself makes clear that sanctions apply to all U.S. persons and entities, with penalties for violations that can reach $1 million or more per incident and criminal liability for willful violations.^[3]

For alternative lenders, MCA providers, and lending infrastructure platforms, this translates into three operational questions:

• Who gets screened? Business applicants as entities, and the individuals who control them (owners, officers, guarantors).

• When does screening happen? At application intake, before funding, and ideally on a recurring basis for existing customers.

• What evidence is preserved? The search query, the timestamp, the API response, and the review decision, stored for the examiner who will eventually ask about it.

A sanctions screening API answers the first two by running the check in milliseconds, and answers the third by producing a structured response the compliance system can log verbatim.

Who Is the Real Buyer for This Product?

The compliance officer owns the outcome, but the CTO or lead engineer owns the integration. A working sanctions screening program requires both roles to agree on the same policy before the code ships. Compliance writes the threshold rules (what triggers manual review). Engineering builds the routing logic (where flagged matches go). When the examiner arrives, both need to point to the same written policy and the same audit log.

Which Treasury Lists Does the OFAC API Screen Against?

The OFAC Specially Designated Nationals list is the most well-known sanctions dataset, but it is not the only one. A screening API intended for production compliance work covers several related lists maintained by the U.S. Treasury Department.^[4]

Cobalt's OFAC Sanctions Check API screens across four entity categories simultaneously:

• Person. Individuals named on the SDN list and related watchlists, including blocked persons and sanctioned officials.

• Organization. Businesses, foundations, front companies, and designated entities.

• Vessel. Sanctioned ships and watercraft (relevant for trade finance and marine-industry lending).

• Aircraft. Sanctioned aircraft (relevant for aviation finance).

Most alternative lenders only need Person and Organization results for standard underwriting. The vessel and aircraft categories matter for trade credit, transportation finance, and specialty lending where the collateral itself can be sanctioned.

What About EU, UK, and UN Sanctions Lists?

Cobalt's OFAC API covers U.S. Treasury lists only. Lenders operating internationally or funding cross-border deals will need separate screening against European Union, United Kingdom HM Treasury, and United Nations Security Council sanctions.^[5] For most U.S.-focused alternative lenders, the OFAC check alone is the compliance baseline, with non-U.S. screening added only if the business model involves foreign counterparties.

How Do Confidence Scores Work and Where Should You Set Threshold Policies?

Name matching is imprecise. A query for "John Smith" will return many candidates from a sanctions list because fuzzy matching casts a wide net to avoid missing true positives. Every match carries a confidence score between 0 and 100 that indicates how strongly the candidate matches the searched name.

The pattern that holds up in compliance reviews uses four tiers:

These tiers are not regulatory mandates. They are a practical starting point. Each lender should write its own threshold policy, reviewed by counsel, and be able to produce that policy in a regulatory examination.^[6]

"The question an examiner asks is not whether you screen, but whether you can show the policy you followed and the evidence that you followed it consistently." A recurring observation from AML program audits of mid-market non-bank lenders.^[7]

Why Score Transparency Matters

An API that returns only a yes or no answer is a liability. When a compliance officer reviews a flagged match, the question is always "why did this match?" The API response has to expose which fields matched (name, alias, city) and how strongly each field contributed. Cobalt's response includes a `matchSummary.matchFields` array that itemizes exactly which attributes triggered the flag, so the compliance review is not a guessing game.

What Data Does the OFAC API Return on a Match?

A typical call looks like this:

GET /ofac?searchQuery=John%20Smith&searchType=person
x-api-key: YOUR_API_KEY

The response for a matched name:

[
  {
    "name": "John Smith",
    "matchCount": 1,
    "matches": [
      {
        "score": 100,
        "matchSummary": {
          "matchFields": [
            {
              "fieldName": "name",
              "matchedValue": "SMITH, John",
              "searchedValue": "John Smith"
            }
          ]
        }
      }
    ]
  }
]

Four fields drive the compliance workflow:

• name. The name searched, echoed back for logging.

• matchCount. How many candidates were flagged; used for triage.

• matches[].score. The 0 to 100 confidence indicator for each candidate.

• matches[].matchSummary.matchFields. The field-level attribution that tells the compliance reviewer which attributes matched.

Everything a compliance team needs to decide, document, and defend the outcome is in this response. Logging it in full at intake is the audit-trail step that matters most.

How Should Alternative Lenders Integrate OFAC Screening Into Underwriting?

The integration pattern that survives a compliance examination has five steps in the automated workflow:

• Screen at intake. Run the business name as `searchType=organization` and each individual (owner, officer, guarantor) as `searchType=person` separately.

• Apply threshold policy. Match scores route automatically: auto-clear under 50, flag for enhanced due diligence between 50 and 99, hold for manual compliance review at 100.

• Log the full response. Write the entire API response to the audit log, including zero-match results. Proving you screened is as important as finding matches.

• Route flagged applications. A compliance officer queue receives every non-clean match with the full response, the supporting application data, and the timestamp of the screening call.

• Re-screen at funding and periodically. Sanctions lists update constantly. An applicant who cleared at intake may not clear at funding 48 hours later.

Two integration decisions get debated in almost every build:

Should Screening Block Underwriting or Run in Parallel?

Run it in parallel. OFAC responses return in sub-second time, so there is no technical reason to serialize it. If the response comes back clean, the result is logged and the workflow continues. If it comes back flagged, funding is paused pending review but other data collection (bank statements, credit, identity checks) continues. This avoids the scenario where a trivial false positive on a common name stalls an entire application.

Should You Screen Once or Continuously?

Screen at intake, at funding, and on a recurring schedule for the life of the relationship. Sanctions lists change, and a customer who was clean when you onboarded them a year ago may not be clean today.^[8] Continuous monitoring is not a technical requirement built into most screening APIs. It is a workflow the lender implements by running periodic re-screens in a background job.

When Should You Build In-House vs Use an OFAC Screening API?

The OFAC SDN list is published as a public file. In theory, a lender could download it and build an internal matching system. In practice, several teams have tried this and regretted it.^[9] The cost surface includes:

• List ingestion and refresh cadence. Treasury publishes updates frequently; stale data is a compliance failure.

• Name matching logic. Sanctioned individuals often appear under aliases, alternate transliterations, and variant spellings. Naive string matching misses cases that fuzzy matching catches.

• Multi-list coverage. The SDN list is one of several Treasury lists. Comprehensive screening pulls from multiple sources.

• Response auditability. Regulators want structured evidence, not engineering-team spreadsheets exported from internal systems.

• Ongoing maintenance. Sanctions compliance is a category of engineering work that has no natural owner in a lending company. It gets deprioritized and rots.

The calculation that matters is not "API cost versus in-house build cost this quarter." It is "what is the cost of a sanctions screening failure in a regulatory examination?" The answer is in the seven figures for most mid-market lenders, and it is reputational as well as financial.

What Are the Honest Limitations of Cobalt's OFAC Screening API?

Four constraints every buyer should factor into evaluation:

• Common names generate noisy matches. Screening "John Smith" returns many candidates. The client is responsible for disambiguation using address, date of birth, and other context the API does not see.

• Screening, not decisioning. Cobalt returns matches with scores. The lender owns the threshold policy and the action taken on each match. This is appropriate, but it means the compliance team cannot delegate the policy to the vendor.

• U.S. Treasury lists only. No EU, UK, or UN screening. Multi-jurisdictional compliance requires additional tooling.

• Point-in-time checks, not continuous monitoring. Each API call is one screening event. Ongoing monitoring is a workflow the lender implements by scheduling periodic re-screens, not a feature built into the API.

Cobalt positions the OFAC API as a data source in a broader compliance stack, not as a full compliance platform. It pairs naturally with Secretary of State verification (entity existence), TIN/EIN verification (identity), and UCC filings (collateral visibility) to produce a complete KYB record.^[10]

How Does Cobalt Compare to LexisNexis Bridger, Dow Jones, and WorldCheck?

The sanctions screening vendor landscape includes several enterprise platforms that bundle OFAC screening with broader compliance workflow features. Each serves a different buyer profile.

Cobalt sits in a separate row because the product is not a compliance platform. It is the screening data layer that compliance platforms, lending systems, and internal tools call when they need an OFAC answer. The platforms above own the case management, workflow, and adverse-media curation. Cobalt owns the U.S. Treasury sanctions data layer with a clean API contract, primary-source data, and pricing aligned with alternative-lender volumes.

The honest answer for most alternative lenders: if the institution needs adverse-media screening, global PEP lists, and a full case-management UI, an enterprise platform is the right call. If the institution needs OFAC screening embedded in its own underwriting pipeline at a per-lookup cost structure that fits lending volume, Cobalt is the data layer that plugs in.^[11]

What Should an OFAC Vendor RFP Actually Ask?

Generic questions like "do you screen against OFAC" or "can you return a match score" are table stakes. Five questions that surface real differences:

• List refresh cadence. How quickly after Treasury publishes an SDN update does your API reflect the change?

• Match field transparency. Can you show me the specific attributes that drove a given match, in a format my audit log can ingest verbatim?

• Categories covered. Are person, organization, vessel, and aircraft all searched by default, or are they separate products?

• False positive patterns. Show me the distribution of score ranges for a batch of 1,000 clean names so I can calibrate my threshold policy realistically.

• Audit evidence format. If a regulator asks us to produce the query, response, and timestamp for a screening event from 18 months ago, what does your system return and how do I retrieve it?

The RFP that fails to ask these ends up comparing vendors on slide decks rather than on the properties that matter when a regulator is sitting in the conference room.

For lenders building a complete KYB and compliance stack, see the compliance automation guide for BSA/AML. For the integration-focused perspective on wiring OFAC into an existing underwriting pipeline, the OFAC integration how-to walks through the code-level patterns. For the foundational verification work that pairs with sanctions screening, the Business Verification APIs guide covers the entity side of the stack.