How to Integrate OFAC Screening API Into Your Lending Workflow

Executive Summary: Every lender operating in the United States is required to screen applicants against OFAC sanctions lists before funding. That is not optional, and it is not negotiable. In 2025 alone, OFAC enforcement penalties exceeded $254 million, with the agency increasingly targeting financial technology businesses and non-traditional lenders.^[1] For CTOs and engineering leaders at alternative lending companies, the question is not whether to screen, but how to build an integration that is fast, accurate, and audit-ready without becoming a bottleneck in your underwriting pipeline. This guide walks through the technical steps of integrating an OFAC screening API into a lending workflow: from understanding what the SDN list contains, to handling fuzzy matches and false positives, to deciding between real-time and batch screening architectures. If you have already read our overview of why OFAC screening matters for lenders, this is the hands-on implementation companion.

What Does the OFAC SDN List Actually Contain and Why Does It Matter for Lenders?

How Is the SDN List Structured?

The Specially Designated Nationals (SDN) list is maintained by the U.S. Treasury Department's Office of Foreign Assets Control. It includes individuals, companies, vessels, and aircraft whose assets are blocked, and with whom U.S. persons are generally prohibited from transacting.^[2] The list is updated 3 to 4 times per week, with over 200 modifications made in 2025 alone.^[3]

For lenders, this means any applicant, whether a business entity or its individual officers, could appear on the SDN list at any point during the lending lifecycle.

What Is the Difference Between the SDN List and the Non-SDN Consolidated List?

The SDN list involves entities and individuals that are fully blocked. Any transaction with an SDN-listed party triggers severe legal consequences. The Non-SDN Consolidated List, by contrast, imposes targeted restrictions such as sectoral sanctions, export prohibitions, or financing limitations, without a full asset freeze.^[4]

The consolidated list includes the Foreign Sanctions Evaders (FSE) List, the Sectoral Sanctions Identifications (SSI) List, the List of Foreign Financial Institutions Subject to Correspondent Account Sanctions, and several others.^[5]

Your screening integration should cover both lists. Engaging with a party on a Non-SDN list can expose your company to secondary sanctions, even if the restrictions are less severe than a full block.^[6]

Important: OFAC lists cover U.S. Treasury sanctions programs only. If your lending operations involve cross-border transactions or non-U.S. counterparties, you may also need to screen against EU, UK, UN, and other jurisdictional sanctions lists. Some API providers consolidate multiple global watchlists into a single screening call, but OFAC compliance alone does not satisfy multi-jurisdictional obligations.

What Entity Categories Does OFAC Track?

OFAC tracks four entity categories:

• Persons. Individuals designated for sanctions violations, terrorism financing, narcotics trafficking, or other prohibited activities.

• Organizations. Companies, shell entities, and government agencies subject to sanctions programs.

• Vessels. Ships and watercraft associated with sanctioned parties or prohibited trade routes.

• Aircraft. Aircraft linked to sanctioned entities or used in prohibited commerce.

A lending-focused integration should screen both "person" (for individual officers and guarantors) and "organization" (for the applicant business entity) categories at minimum.

Where Should OFAC Screening Sit in Your Underwriting Pipeline?

What Is the Optimal Placement for Sanctions Checks?

OFAC screening should occur early in your pipeline, after initial application intake but before any resource-intensive underwriting steps like financial analysis or site visits. The logic is straightforward: if an applicant is a sanctioned entity, every minute spent underwriting that deal is wasted.

A typical placement in an alternative lending workflow:

1. Application received
2. Basic data validation (name, EIN, address)
3. OFAC sanctions screening  <-- HERE
4. Secretary of State entity verification
5. TIN/EIN verification
6. UCC lien search
7. Financial underwriting
8. Funding decision

This ordering ensures you catch sanctioned entities before consuming credits on downstream verification steps. For lenders using a KYB compliance stack, OFAC screening pairs naturally with SOS verification and TIN matching to form a complete compliance gate.^[7]

Should You Screen Business Names and Individual Names Separately?

Yes. Screen the business entity name as an "organization" search, and screen each principal, officer, or beneficial owner individually as a "person" search. A business may not appear on the SDN list, but one of its officers might. Missing that connection means funding a deal tied to a sanctioned individual.

This dual-screening approach is consistent with FFIEC guidance, which recommends that financial institutions screen both entities and their associated persons against OFAC lists as part of their BSA/AML compliance programs.^[8]

How Do You Make Your First OFAC API Call?

What Does the Request Look Like?

A basic OFAC screening call requires only a search query and your API key. Here is an example using Cobalt Intelligence's OFAC endpoint:

curl --location 'https://apigateway.cobaltintelligence.com/ofac?searchQuery=Acme%20Holdings%20LLC&searchType=organization' \
--header 'Accept: application/json' \
--header 'x-api-key: YOUR_API_KEY'

The `searchType` parameter accepts four values: `person`, `organization`, `vessel`, or `aircraft`. Omitting it searches all four categories simultaneously, which increases thoroughness but may also increase false positives for common names.

What Does the Response Payload Tell You?

A typical response returns the searched name, match count, and an array of match objects, each with a confidence score:

[
  {
    "name": "Acme Holdings LLC",
    "matchCount": 1,
    "matches": [
      {
        "score": 87,
        "matchSummary": {
          "matchFields": [
            {
              "fieldName": "name",
              "matchedValue": "ACME HOLDINGS LIMITED",
              "searchedValue": "Acme Holdings LLC"
            }
          ]
        }
      }
    ]
  }
]

Key fields to parse:

• `matchCount`: Zero means no matches found. Any value greater than zero requires evaluation.

• `matches[].score`: Confidence score from 0 to 100. Higher scores indicate stronger matches.

• `matchSummary.matchFields`: Shows exactly which fields matched and the values compared, enabling your team to understand why a flag was raised.

How Should You Handle a Zero-Match Response?

A zero-match result is a positive compliance signal. Log it. Proving that you screened an applicant and found no matches is as important for auditors as documenting how you handled a hit.^[9] Store the full JSON response, including the timestamp and searched name, in your loan file.

How Does Fuzzy Matching Work and Why Does It Generate False Positives?

What Algorithms Power OFAC Name Matching?

OFAC's own Sanctions List Search tool uses a combination of Jaro-Winkler character similarity and Soundex phonetic matching.^[10] Most commercial OFAC screening APIs implement similar or more advanced approaches. The system compares input names against the list in two ways: full-string comparison and name-part decomposition (splitting "John Michael Smith" into individual components for separate matching).

This fuzzy matching is necessary because sanctioned parties often use aliases, transliterated spellings, or variations of their names. A system that only matches exact strings would miss "Mohammad" vs. "Mohammed" or "Al-Qaida" vs. "Al Qaeda."

Why Are False Positive Rates So High?

Aggressive fuzzy matching generates false positive rates that often exceed 95% of initial matches.^[11] For lending operations, this means the vast majority of flagged applications are legitimate businesses that happen to share name components with sanctioned entities.

Common false positive triggers in lending:

• Common business names. "Global Trading LLC" or "Pacific Holdings" will match partial strings against multiple SDN entries.

• Common individual names. Names like "Ali" or "Mohammed" appear frequently on both the SDN list and in legitimate applicant pools.

• Abbreviated entity types. "LLC," "Corp," and "Inc" can inflate match scores by matching against organizational designations on the list.

How Do You Set a Match Threshold That Balances Risk and Throughput?

OFAC itself does not recommend specific match thresholds, stating that each search has unique facts and users must make their own threshold determinations.^[12] However, industry best practices suggest thresholds between 80 and 90 for name matching, calibrated to your institution's risk appetite.^[13]

A practical tiered approach for lending operations:

The key is documenting your threshold policy before integration, not after. Auditors will ask how you determined your cutoff, and "we picked 80 because it seemed reasonable" is not a defensible answer. Tie your threshold to a documented risk assessment.^[14]

Should You Use Real-Time Screening or Batch Screening?

When Does Real-Time Screening Make Sense?

Real-time screening means every application is checked against OFAC lists synchronously at the point of intake. The API call happens inline, and the response determines whether the application proceeds or is held. Modern OFAC APIs deliver response times under 2 seconds, making this viable for even high-volume onboarding flows.^[15]

Real-time screening is the right choice when:

• You need immediate go/no-go decisions. MCA and short-term lending products where speed-to-funding is a competitive advantage.

• Your application volume is moderate. Under 10,000 applications per month, real-time screening adds minimal latency.

• Regulatory expectations demand point-of-intake screening. Some state examiners specifically look for evidence of screening at onboarding.

When Should You Add Batch Screening?

Batch screening processes your entire customer database against updated OFAC lists on a scheduled basis. This is essential for periodic re-screening because a customer who was clear at onboarding can be designated at any time. Note: this is scheduled re-screening, not real-time continuous monitoring. You are re-running your existing customer list against the latest version of the sanctions lists at defined intervals.

Batch screening is the right choice when:

• You have an existing portfolio to monitor. OFAC modified its lists over 200 times in 2025.^[16] An entity cleared last month could be sanctioned today.

• You fund recurring products. Lines of credit, revolving facilities, or renewal MCA products require periodic re-screening.

• Your volume exceeds real-time practicality. Lenders processing 50,000+ active accounts benefit from off-peak batch runs.

Can You Use Both?

Most mature compliance programs use both. Real-time screening at onboarding, plus batch re-screening on a cadence aligned with OFAC list update frequency (at minimum weekly, ideally after every list update). The FFIEC has noted that failure to re-screen existing customers after list updates has resulted in enforcement actions against financial institutions.^[17]

A decision tree for your architecture:

IF new application → Real-time screen at intake
IF existing customer + list update → Batch re-screen
IF high-value transaction on existing account → Real-time re-screen
IF annual portfolio review → Full batch screen

How Do You Build a False Positive Resolution Workflow?

What Does the Review Process Look Like?

When a screening hit exceeds your threshold, the application should route to a compliance analyst, not to the underwriting team. The analyst's job is to determine whether the match is a true positive (actual sanctioned entity) or a false positive (name coincidence).

A structured resolution workflow:

• Step 1: Compare identifying details. Check the SDN entry's aliases, addresses, dates of birth, and identification numbers against your applicant's information. The API response's `matchFields` array tells you exactly which data points triggered the match.

• Step 2: Cross-reference additional data. Use your SOS verification data (entity formation date, registered agent, officer names) to differentiate the applicant from the SDN entry.

• Step 3: Document the determination. Whether true positive or false positive, record the analyst's rationale, the evidence reviewed, and the decision in the loan file.

• Step 4: Escalate or clear. True positives trigger a hard stop and potential SAR filing. False positives are cleared with documentation, and the application re-enters the pipeline.

How Do You Reduce False Positive Volume Over Time?

Several approaches can reduce alert fatigue without weakening your screening:

• Use `searchType` filters. When screening a business, specify `searchType=organization`. When screening an individual, specify `searchType=person`. This eliminates cross-category noise.^[18]

• Maintain a cleared-names list. After resolving a false positive, record the specific name-to-SDN entry comparison. On subsequent screens, if the same match recurs, auto-flag it as previously reviewed (still log it, but do not route to the analyst queue).

• Tune thresholds by risk tier. High-risk geographies or industries may warrant a lower threshold (more sensitive). Domestic small business lending may tolerate a higher threshold (fewer flags).^[19]

• Standardize input data. Clean applicant names before screening. Remove extra spaces, standardize entity suffixes ("LLC" vs "L.L.C."), and ensure consistent formatting. Poor input data is one of the largest contributors to false positives.^[20]

How Do You Handle Errors and Edge Cases in Production?

What Happens When the API Returns an Error?

Standard HTTP error codes apply to OFAC screening APIs. Your integration should handle each appropriately:

The critical rule: never auto-clear an application when the screening API returns an error. If you cannot confirm a clean screen, the application must be held until screening completes successfully. An unscreened funded deal is a compliance violation regardless of the technical reason.

What About Name Encoding and Character Issues?

International business names may contain characters outside the ASCII range: accented characters, Arabic script, Chinese characters. URL-encode your search query parameters. Most OFAC APIs will transliterate or normalize input, but garbage-in produces garbage-out. If your application form accepts Unicode input, sanitize before sending to the screening endpoint.

How Do You Handle Asynchronous Processing for Slow Responses?

While OFAC screening is typically synchronous (responses under 2 seconds), some providers support asynchronous patterns for batch operations. Two common approaches:

• Polling with retry ID. The initial request returns a `retryId`. Poll the same endpoint with that ID until results are ready.

• Callback URL. Provide a `callbackUrl` parameter. Results are POSTed to your endpoint when processing completes.

For real-time onboarding, set a timeout of 5 to 10 seconds. If the screening call does not complete within that window, hold the application and retry, rather than letting it through unscreened.

How Do You Build an Audit-Ready Integration from Day One?

What Do Examiners Want to See?

Regulatory examiners evaluating your OFAC compliance program look for five things:^[21]

• Written policies and procedures. Documented screening thresholds, escalation workflows, and review timelines.

• Screening coverage. Evidence that every applicant (entity and individuals) is screened at onboarding and on an ongoing basis.

• Match resolution documentation. Records showing how each hit was evaluated, who reviewed it, and what decision was made.

• List update monitoring. Proof that you re-screen when OFAC updates its lists (3 to 4 times weekly).

• Independent testing. Periodic validation that your screening system catches known positives and processes them correctly.

What Should You Log for Every API Call?

Store these fields for every OFAC screening request, regardless of outcome:

• Timestamp. ISO 8601 format, timezone-aware.

• Searched name. Exactly as submitted to the API.

• Search type. Person, organization, or all categories.

• Match count. Including zero (proves screening occurred).

• Full response payload. The complete JSON response.

• Disposition. Auto-cleared, routed to review, or hard-stopped.

• Reviewer ID and rationale. For matches that required manual review.

• Loan file reference. Linking the screening record to the application.

As of March 2025, OFAC extended sanctions-related record-keeping requirements from five years to ten years.^[22] Plan your data retention accordingly.

How Does OFAC Screening Fit Into a Broader KYB Compliance Stack?

OFAC screening is one component of a complete business verification workflow. For alternative lenders, the standard compliance stack follows this sequence:

1. SOS API       → Verify the business entity is active and in good standing
2. TIN/EIN       → Confirm the business identity matches IRS records
3. OFAC Screening → Check against Treasury sanctions lists
4. UCC Search    → Discover existing liens and secured interests
5. Court Records → Identify outstanding judgments or litigation

Each step answers a different compliance question. SOS verification confirms the entity legally exists. TIN verification confirms its tax identity. OFAC screening confirms it is not a sanctioned party. Together, they form a defensible compliance gate that auditors can trace from application to funding decision.

If you are building this stack from scratch, consider providers that offer multiple verification products through a single API integration. Running SOS, TIN, and OFAC checks through one platform reduces integration complexity and consolidates your audit trail. For a deeper look at how compliance automation reduces manual overhead for alternative lenders, that piece covers the operational side in detail.

What Is the Implementation Timeline and What Resources Do You Need?

How Long Does a Typical Integration Take?

For a straightforward OFAC screening integration (real-time at onboarding, basic threshold routing), expect 3 to 5 engineering days. This includes:

• Day 1. API key provisioning, test mode validation, response parsing.

• Day 2. Threshold logic, routing rules, error handling.

• Day 3. Audit logging, compliance review workflow integration.

• Days 4 to 5. End-to-end testing with known positive names, edge case validation, production deployment.

Adding batch screening for ongoing monitoring adds 2 to 3 days for queue management, scheduling, and result processing.

What Should You Test Before Going Live?

Use test mode parameters to validate each scenario without consuming credits:

Run your integration against known SDN entries (OFAC publishes the full list publicly) to confirm that your threshold logic correctly routes matches. Test with common names like "John Smith" to verify your false positive handling works under load.

Engineering leaders evaluating OFAC screening solutions should look for three things: synchronous response times under 2 seconds, confidence scores that map directly to automated routing rules, and test mode support that lets you validate without production risk.

If your team is evaluating build-versus-buy for sanctions screening infrastructure, the calculus is similar to the SOS verification build-versus-buy question: you can build a basic screen against the SDN flat file, but maintaining fuzzy matching, list update monitoring, and audit-grade logging across all OFAC lists is ongoing maintenance that does not generate revenue.

Ready to add OFAC screening to your lending workflow? Cobalt Intelligence's OFAC API returns results in under 2 seconds, includes fuzzy matching with confidence scores, and supports test mode so you can validate your integration before going live. Schedule a free demo to see how OFAC screening bundles with SOS verification, TIN matching, and UCC searches into a single compliance pipeline.