Executive Summary: How compliance and engineering teams keep OFAC screening defensible when an upstream Treasury source degrades or goes dark for a window. The topic of OFAC API reliability outage handling is not about promising perfect uptime. It is about making one lender workflow survive a bad source hour without producing false confidence or silent gaps. The core problem is that many teams design the happy path, screen a name, read a clean response, continue, and never design the degraded path where the source is slow, partial, or unreachable. Cobalt's OFAC Sanctions Check API screens submitted names and returns potential matches with confidence scores, and the customer owns threshold policy, review routing, monitoring schedules, and final sanctions decisions.[1] Cobalt is a data source, not a decisioning engine, so reliability design belongs to the lender's workflow, not to a hidden vendor guarantee.[6]
Why does endpoint reliability matter before a sanctions decision?
What specific risk does a degraded source create?
A sanctions screen is a compliance control, and a control that quietly fails is worse than a control that loudly stops. When the underlying source is unreachable, three bad outcomes become possible. The workflow can treat a source outage as a clean result and let a file pass without a real screen. The workflow can hard-crash and block every application, including files that had nothing to do with the outage. Or the workflow can retry forever, hold the applicant in limbo, and never surface the problem to a human. Each outcome fails a different party. The first fails compliance, the second fails operations and revenue, and the third fails the applicant waiting for an answer.
The reliability question is therefore not only a systems question. It is an evidence question. If a reviewer later asks whether a specific applicant was screened against the sanctions list before funding, the record must answer clearly. A defensible record shows the submitted input, the source attempt, the source status, and the route the policy took when the source could not answer. OFAC publishes the Specially Designated Nationals list and a public search surface, which is exactly why a lender cannot pretend a screen happened when the source was down.[2][3]
Which buyer feels an outage first?
• Chief Compliance Officer. This buyer needs proof that no file cleared without a real screen, even during a degraded window.
• VP Risk. This buyer needs the outage to route files to a safe holding state, not to a blind pass.
• CTO. This buyer needs bounded retries, honest status labels, and observability instead of a silent swallow of source errors.
• Operations. This buyer needs a queue that names the outage clearly so support can answer applicants without guessing.
The article should not imply that Cobalt guarantees Treasury uptime or that any single screen approves a customer. It should show how the lender designs a route that stays honest when the source is imperfect.
What happens when teams ignore the degraded path?
When the degraded path is ignored, the failure surfaces at the worst time, during an audit or after a bad actor slips through. The team then has to reconstruct whether the applicant was actually screened, and the logs only show a generic success or a vague error. That ambiguity is the real cost. It turns a five-second question into a multi-day investigation, and it undermines the compliance narrative that the control was always active.
A better posture treats a source outage as a first-class outcome with its own label, its own route, and its own owner. The screen either happened against a live source, or it did not, and the record should never blur those two states. This is the same discipline the house verification stack uses across every source layer, where source facts and policy routes stay separate so a later reviewer can trust the trail.[7]
What should the workflow verify before it trusts a screen?
What is the minimum reliable screening loop?
The minimum reliable loop screens the submitted name, confirms the source responded with a real result, and only then records a screening outcome. If the source did not respond, the loop records a source-unavailable state and routes the file to a defined holding path rather than to a clean pass. The exact routing can vary by lender risk appetite, but the evidence should always let a later reviewer distinguish a clean screen from a screen that never completed.
| Source outcome | What it means | Reliable route |
|---|---|---|
| Live match data returned | Source answered with potential matches and scores | Send to review bands per policy |
| Live no-match returned | Source answered, no potential match found | Continue per policy, store proof of live screen |
| Timeout after bounded retries | Source did not answer in time | Hold file, label source-unavailable, do not pass blind |
| Error status from source | Source reachable but returned an error | Retry once, then route to manual review |
| Stale cached result only | No live confirmation this cycle | Flag freshness, require live re-screen before funding |
Why is a clean-looking response not always a clean screen?
A response object can arrive that looks successful at the transport layer but carries no real screening value. A cached fallback, a truncated payload, or a default empty result can all deserialize into something that a naive workflow treats as a pass. The reliability discipline is to verify that the response actually represents a live screen against current source data before recording a cleared status. Sanctions screening supports Bank Secrecy Act and anti-money-laundering obligations, and those obligations do not pause because an endpoint had a slow hour.[5] The Office of Foreign Assets Control frames sanctions compliance as an ongoing program obligation, which is why a lender cannot let one degraded window create a hidden gap in the record.[4]
What does an outage-aware OFAC workflow actually record?
How does Cobalt fit without overstating uptime?
Cobalt's OFAC Sanctions Check API screens submitted names and returns potential matches with confidence scores, and monitoring plus re-screening schedules are customer-owned patterns.[1] A representative event that an outage-aware workflow persists looks like this. It is a workflow illustration, not a published API schema.
{
"screenId": "scr-internal-00293",
"sourceState": "source_unavailable",
"attempts": 3,
"backoffPolicy": "exponential_bounded",
"recordedOutcome": "hold_for_re_screen",
"owner": "compliance",
"liveScreenConfirmed": false
}The value is in the fields that describe what did not happen. A workflow that only stores a match array cannot prove the screen was live. A workflow that stores the source state, the attempt count, and a live-screen-confirmed flag can prove exactly what the control did during the window and what route the policy chose in response.
Which fields must stay separate during an outage?
The most damaging shortcut is collapsing source availability and screening result into one status. During an outage that shortcut turns a source failure into a phantom clean result. Keep the availability of the source, the content of the result, and the policy route as three distinct facts.
| Field group | Stored example | Why it matters during an outage |
|---|---|---|
| Source availability | live, degraded, unavailable, cached-only | Proves whether a real screen happened this cycle |
| Screen result | no-match, potential-match, match-score, matched-fields | Captures what the source returned when it answered |
| Freshness | source timestamp, cache age, re-screen-due flag | Prevents stale data from passing as a current screen |
| Policy route | continue, hold, retry, manual-review | Shows how the lender interpreted an imperfect source |
| Reviewer action | analyst name, note, override reason, timestamp | Shows who accepted the route under degraded conditions |
This separation lets a lender defend older files under a newer policy. A reviewer can see that a file was held during an outage window, re-screened when the source recovered, and only then cleared, which is a far stronger story than a single flat pass with no context.
How should retries and backoff behave during a Treasury outage?
What makes a retry bounded and safe?
Retries protect against transient failures, but unbounded retries create their own outage. A safe retry policy caps the number of attempts, spaces them with increasing delay, and stops at a defined ceiling that routes the file to a human. The retry loop should react to technical failure, never to an unwelcome business answer. A confirmed potential match is not something to retry away. A timeout is.
Reliable sanctions screening does not mean the source never fails. It means the workflow always knows whether a real screen happened, and never lets a source outage masquerade as a clean result.
How should the workflow separate outage classes?
Not every failure deserves the same response. A short network blip merits a quick bounded retry. A sustained source outage merits a circuit-breaker that stops hammering the endpoint and switches the whole queue into a documented holding mode. A malformed input merits a correction request to the applicant, not a retry at all. Naming these classes keeps operations from treating a data-entry typo like a Treasury outage.
| Failure class | Signal | Correct behavior |
|---|---|---|
| Transient blip | One timeout, source recovers on retry | Bounded retry, then continue |
| Sustained outage | Repeated timeouts across many files | Trip circuit breaker, batch-hold, alert on-call |
| Source error status | Endpoint returns error, not data | Retry once, then route to manual review |
| Input problem | Missing or malformed name field | Correction request, no retry |
| Freshness lapse | Only stale cached data available | Flag re-screen-due, block funding until live screen |
Who owns the outage response?
Ownership must be assigned before an outage happens, because an outage is the worst time to negotiate roles. Engineering owns the retry rules, the circuit breaker, and the alerting. Compliance owns the rule that no file funds without a live screen on record. Operations owns applicant communication and queue hygiene while files sit in a hold. Risk owns any temporary policy exception and its documentation.
| Route | Primary owner | What good ownership looks like |
|---|---|---|
| Retry and backoff | Engineering | Capped attempts, exponential spacing, source error logs |
| Circuit breaker and alert | Engineering | Automatic batch-hold, on-call notification, recovery check |
| No-blind-pass rule | Compliance | Written policy that source-unavailable never equals cleared |
| Applicant hold messaging | Operations | Clear status without exposing internal risk labels |
| Temporary exception | Risk | Documented reason, expiry, and re-screen commitment |
This map keeps an outage from turning into a scramble. A source timeout is not solved by asking sales for more documents, and a compliance hold is not solved by an engineer quietly widening a retry ceiling. Each route has a named owner and a paper trail.
How should the workflow recover after the source returns?
What must happen when the endpoint comes back?
Recovery is not automatic just because the source is healthy again. Every file that was held during the outage needs a live re-screen before it can move, and that re-screen needs its own timestamp and proof. A workflow that simply releases held files without re-screening them recreates the exact gap the hold was meant to prevent. The recovery step should walk the held queue, re-screen each name against the recovered source, and record the fresh result beside the outage note.
How does the team prove the gap was closed?
The proof lives in the paired records. The outage record shows the source was unavailable and the file was held. The recovery record shows the live re-screen, its timestamp, and its result. Together they demonstrate that no file crossed the funding line on a phantom screen. This is the reliability equivalent of the evidence discipline used across the broader verification stack, where every source layer answers a distinct question and stores its own proof rather than folding into a single opaque status.[7]
What dashboards keep reliability honest?
A reliability dashboard should make degraded time visible instead of hiding it inside an overall success rate. Leadership needs to see how often the source was unavailable, how many files were held, and how quickly held files were re-screened after recovery.
| Metric | What it reveals | Better follow-up |
|---|---|---|
| Source-unavailable rate | How often the screen could not run live | Review retry ceilings and source health |
| Held-file count | How much work an outage parked | Staff the recovery queue, set hold SLAs |
| Re-screen latency | How fast holds cleared after recovery | Automate the recovery sweep |
| Blind-pass count | Files that passed without a live screen | Must stay at zero, alert immediately if not |
| Stale-screen block rate | Freshness rule catching old data | Tune re-screen cadence per policy |
The blind-pass count is the metric that matters most. In a reliable design it stays at zero by construction, because a source-unavailable state can never map to a cleared status. If that number is ever above zero, the workflow has a defect, not a tuning opportunity.
What should a buyer ask before trusting an outage design?
What questions expose a fragile screening integration?
The buying conversation should move past demo-day uptime claims and into degraded-path behavior. A screening integration is only as strong as its worst hour.
1. What does the workflow record when the source does not answer at all?
2. Can a source outage ever produce a cleared status, and how is that prevented?
3. How many retries run, with what spacing, before a file is held?
4. Who is alerted when a sustained outage trips the circuit breaker?
5. How are held files re-screened after recovery, and where is that proof stored?
6. What evidence defends a specific file six months later, including files touched during an outage?
What does a careful first rollout look like?
A careful rollout starts narrow and proves the degraded path on purpose. In the first week, the team screens a small file set live and confirms the happy path records a real screen with a source timestamp. In the second week, the team simulates a source outage in a test lane and confirms that files route to a hold, never to a blind pass, and that the circuit breaker and alert fire as designed. In the third week, the team practices recovery by restoring the simulated source and confirming that every held file is re-screened with fresh proof before it moves. In the fourth week, the team locks the retry ceiling, the freshness rule, the ownership map, and the dashboard metrics leadership will watch. This staged approach mirrors how careful lenders adopt any new verification layer, one file type and one intake path at a time, rather than switching everything at once.[6]
How should the final decision be framed?
The final decision should be framed as workflow resilience, not vendor uptime. Cobalt supplies the sanctions screening data layer, and the lender owns whether a source outage can ever slip a file past the control. If the team needs sanctions screening, OFAC belongs in the compliance lane with a designed degraded path. If the team also needs entity status, tax identity, or license evidence, those belong in their own lanes with their own coverage limits, and the contractor and court layers each carry state-level coverage boundaries the workflow must respect.[8][9] A reliable design is one where every one of those layers can fail loudly and recover honestly.
.jpg){kind=small}
.png)