Executive Summary: How lending platforms can isolate OFAC screening evidence across tenants without mixing customer policies or review queues. The goal is not to turn multi tenant OFAC platform into a vague technology promise. The goal is to make one lender workflow easier to defend before funding, audit review, or portfolio monitoring. The core problem is that platform teams may serve many lenders, but each lender can have different thresholds, retention rules, and manual-review ownership. Cobalt's OFAC Sanctions Check API screens submitted names and returns potential matches with confidence scores. The customer owns threshold policy, review routing, and final sanctions decisions.[1] Cobalt should be positioned as a data source, not a decisioning engine.
Why does multi-tenant OFAC screening matter before funding?
What operational risk does this remove?
The lender is not collecting records for decoration. The lender is trying to remove a specific uncertainty before a file advances. In this case, the uncertainty is that platform teams may serve many lenders, but each lender can have different thresholds, retention rules, and manual-review ownership. A useful workflow turns that uncertainty into a small set of routes: clear, correct, retry, unsupported, or manual review.
For risk teams, the value is repeatability. The same source fields, exception labels, and reviewer routes make it easier to explain why one applicant moved forward and another did not. For engineering teams, the value is a bounded source workflow that can be logged and tested without turning underwriting policy into hidden application code.
Which buyer should care most?
• VP Risk. This buyer needs faster separation between clean files and files that need review.
• Compliance. This buyer needs source evidence, timestamps, response fields, and documented exception handling.
• CTO. This buyer needs a pattern that can be logged, monitored, and changed without rewriting credit policy.
• Operations. This buyer needs fewer late-stage corrections and fewer files bouncing between sales, underwriting, and compliance.
The article should not imply that one verification step approves a loan. It should show how one evidence layer reduces ambiguity before the lender's policy takes over.
What happens when teams skip this layer?
When this layer is skipped, the failure rarely appears as one obvious production incident. It shows up as avoidable back-and-forth. Sales asks why a file is stalled. Underwriting asks for another screenshot. Compliance asks whether the applicant was screened before the decision. Engineering sees a queue full of vague failed statuses that do not say whether the issue was source coverage, bad input, a technical timeout, or a real risk signal.
That confusion is expensive because it moves work to the worst possible moment. The file is already in motion, the applicant expects an answer, and the team has to reconstruct evidence after the fact. A better pattern is to capture the source result while the workflow is fresh, label the limitation immediately, and route the exception before the file depends on memory, Slack notes, or one analyst's local spreadsheet.
The operator question is not whether this topic sounds useful. The operator question is whether the lender can explain the route under pressure. If a reviewer asks why the file cleared, the record should show the submitted input, the source response, the policy route, and the person or automation that accepted the route. If a reviewer asks why the file stopped, the record should show the same chain without forcing the team to rerun the search.
What should the lender verify first?
What is the minimum viable workflow?
The minimum viable workflow is to partition tenant policy, call OFAC with tenant context, store raw results separately, and expose only that tenant's review queue. The exact order can vary by lender, but the evidence should be stored in a way that lets a later reviewer see the source, timestamp, applicant input, and policy route. OFAC publishes the SDN list and sanctions data formats, while Treasury's search surface demonstrates why exact, partial, and contextual matching need clear review policy.[5][6][7]
| Evidence layer | Question answered | Routing value |
|---|---|---|
| Submitted name | Who or what is being screened? | Business or owner screening route |
| Search type | Is the target a person, organization, vessel, or aircraft? | Noise control and match focus |
| Match score | How strong is the potential match? | Review band and escalation route |
| Matched fields | Which fields caused the alert? | Reviewer evidence and audit record |
Why is one source not enough?
One source can be accurate and still incomplete for the decision in front of the lender. SOS data can confirm the state record while lien, tax identity, sanctions, owner, or litigation evidence may still need separate review. The stack works because each source answers a different question, not because any source answers every question. Sanctions screening supports BSA and AML workflows, but the lender still needs its own documented review and escalation policy.[8]
Cobalt's broader business verification hub is the internal link base for placing sanctions screening inside a KYB stack.[10]
What does the OFAC workflow actually return?
How does Cobalt fit without overstating the product?
Cobalt's OFAC Sanctions Check API screens submitted names and returns potential matches with confidence scores. The customer owns threshold policy, review routing, and final sanctions decisions.[1] A representative request or downstream event for this topic looks like this:
{
"tenantId": "lender_123",
"policyVersion": "ofac-policy-2026-07",
"visibility": "tenant_isolated"
}The request is only the start. The lender should persist the raw response, map the result into internal statuses, and show the reviewer why a file cleared, corrected, retried, or moved to manual review. That discipline matters more than hiding the result behind a vague pass or fail label.
Which fields should stay separate?
The most common implementation mistake is turning source fields and policy fields into one flat status. That makes the first version look simple, but it creates audit and maintenance problems later. A source can return no match, partial match, unsupported coverage, timeout, or a valid record. The lender's policy can then route that source outcome to correction, retry, hold, manual review, or continue. Those are related facts, but they are not the same fact.
Keep these fields separate in the database and in the reviewer screen:
| Field group | Stored example | Why it matters |
|---|---|---|
| Applicant input | Legal name, state, entity type, submitted identifier | Shows what the applicant or system supplied |
| Source result | Source status, match data, filing data, matched fields, response code | Shows what the source returned |
| Limitation label | Unsupported state, partial match, source outage, stale record | Prevents unsupported results from looking clean |
| Policy route | Clear, correct, retry, manual review, hold | Shows how the lender interpreted the source |
| Reviewer evidence | Notes, corrected document, reviewer name, timestamp | Shows who accepted or changed the route |
This separation also protects future changes. The lender can update a threshold, add a required field, or change a review route without rewriting historical source evidence. That matters when risk teams need to explain older files under a newer policy version.
What limitation should stay visible?
Cobalt returns screening data. Multi-tenant routing, permissions, retention, and downstream audit exports belong to the platform. The right posture is to state that limitation plainly, then design the route around it. A data source is valuable because it gives the lender a cleaner fact pattern. It is not valuable if copy causes the buyer to expect a decision engine.
Strong verification architecture does not hide exceptions. It makes exceptions visible early enough that risk, compliance, and operations can act before the file moves too far.
What should engineering build into the first version?
What should be logged?
The first production version should be small, observable, and recoverable. Store external source data and internal policy routes separately. That prevents a later reviewer from confusing what the source returned with what the lender decided.
• Input snapshot. Store the raw submitted business name, state, entity type, and normalized value used for the request.
• Source response. Preserve source mode, status code, source timestamp, and raw response fields before internal mapping.
• Coverage label. Show whether the result was supported, unsupported, partial, source-unavailable, or review-required.
• Policy route. Keep the lender's clear, correction, retry, and manual-review route separate from source data.
• Reviewer action. Log who changed the route, why it changed, and which document or corrected input supported the change.
What should dashboards show?
Dashboards should make exception volume visible without pretending that every exception is the same kind of risk. A useful dashboard separates source problems, input problems, policy holds, and true review signals. That lets operations fix preventable data capture problems while risk and compliance focus on files that genuinely need judgment.
| Dashboard metric | What it tells the team | Better follow-up |
|---|---|---|
| Unsupported coverage rate | How often the source cannot answer the question | Add fallback route or adjust source expectations |
| Input correction rate | How often applicants submit unusable fields | Improve form labels and validation |
| Manual-review rate | How often policy requires human judgment | Staff the queue and refine thresholds |
| Retry rate | How often technical failures interrupt the workflow | Improve timeout and backoff handling |
| Clear rate by source | How often evidence supports the next step | Monitor drift over time |
The first dashboard does not need to be complex. It needs to be honest. If unsupported coverage is high, the lender should see that before it becomes a sales complaint. If input correction is high, the fix may be an application-form change rather than a different data provider. If manual review is high, the issue may be threshold design or missing context, not the API call itself.
What should not be automated first?
Do not start with automatic rejection for every exception. Start with classification. A format problem needs correction. A source outage needs retry. A confirmed mismatch needs policy review. Unsupported coverage needs a fallback route. Classification before automation protects the team from turning data quality into false declines.
How should exceptions route to manual review?
Which exceptions are operational, not fraud?
Every exception deserves a label. Some are operational, such as applicant typos, source outages, unsupported coverage, ambiguous names, or incomplete fields. Some are risk signals, such as a confirmed mismatch, a high-score sanctions match, an unexpected secured party, or conflicting entity evidence. Treating all exceptions as fraud creates unnecessary friction. Treating all exceptions as harmless creates loss exposure. FinCEN resources keep this topic in the compliance lane, while BOI reporting context reinforces why entity evidence and owner evidence are separate layers.[8][9]
| Result | Likely cause | Recommended route |
|---|---|---|
| Format invalid | Input problem or missing field | Ask applicant to correct input |
| Source unavailable | Source outage or timeout | Retry later with bounded backoff |
| Ambiguous record | Weak match, name variation, or missing context | Request source evidence or manual review |
| Coverage unsupported | Product does not cover the record needed | Use alternate source or manual review |
| Clean result | Evidence aligns with policy | Continue to the next underwriting step |
How do retries stay safe?
Retries should be bounded and tied to technical failures, not to business outcomes. If the source returned a real mismatch or a finding that changes risk, the next step is corrected evidence or review, not repeated calls until the answer changes. That distinction keeps the integration honest and reduces noise for operations.
Who owns each route?
Ownership should be assigned before the workflow goes live. Otherwise, every exception becomes a small meeting. Engineering owns technical reliability, request shape, logging, and error handling. Operations owns applicant correction loops and queue hygiene. Risk owns underwriting policy interpretation. Compliance owns sanctions, audit, and documentation rules. Product or revenue teams can request lower friction, but they should not silently weaken review routes.
| Route | Primary owner | What good ownership looks like |
|---|---|---|
| Technical retry | Engineering | Bounded retry rules, source error logging, alerting |
| Applicant correction | Operations | Clear request for corrected legal name, state, or document |
| Risk review | Underwriting or risk | Policy note, reviewer decision, evidence attached |
| Compliance hold | Compliance | Match evidence, escalation record, final disposition |
| Unsupported source | Operations plus risk | Fallback source or manual review route |
This ownership map keeps the workflow from turning into a generic failed queue. It also helps leaders see where the bottleneck actually lives. A compliance queue problem should not be solved by engineering guesses. A source timeout should not be solved by asking sales to collect extra documents. A policy hold should not be hidden as a technical error.
What should a buyer ask before approving this workflow?
What questions expose weak implementations?
The buying conversation should focus on source, evidence, and ownership. A polished demo is less important than whether the data route matches the lender's actual underwriting and compliance needs.
1. Which source answers this exact question?
2. What fields are required before the API call can be trusted?
3. What does the response include for clear, mismatch, partial, unsupported, and source-unavailable cases?
4. How are source mode, timestamp, request ID, and reviewer route stored?
5. Which exceptions are automated, and which ones route to manual review?
6. What evidence is available to defend the decision six months later?
What does a practical first rollout look like?
A practical rollout starts with a narrow use case and a small group of reviewers. The lender does not need to rebuild every underwriting system before getting value from a cleaner source route. It needs one file type, one intake path, one source call, one exception taxonomy, and one readback report that proves the workflow can be trusted.
The first week should focus on historical comparison. Take a small set of recently reviewed files, rerun the source workflow where appropriate, and compare what the API route would have shown against what the team actually stored. The point is not to retroactively change old decisions. The point is to find missing fields, ambiguous labels, and evidence gaps before launch.
The second week should focus on live shadow mode. Let the API route run beside the existing process while reviewers keep using the current decision path. Compare routes daily. If the API route says clear but the current process says review, inspect why. If the current process says clear but the API route finds an exception, inspect whether the new evidence should change policy.
The third week should focus on queue ownership. Define who receives correction tasks, who receives manual-review tasks, who receives compliance holds, and who can override a route. The team should also decide what gets sent back to sales and what stays internal. Borrowers need clear correction requests, not internal risk labels.
The fourth week should focus on production controls. Lock the field map, document the source limitations, approve retry rules, and decide which dashboard metrics leadership will review weekly. A small launch with clear evidence beats a broad launch where every exception turns into a special case.
How should the final decision be framed?
The final decision should be framed as workflow fit. If the team needs entity status, SOS belongs in the stack. If the team needs lien visibility, UCC belongs where coverage exists. If the team needs sanctions screening, OFAC belongs in the compliance lane. If the team needs tax identity validation, TIN/EIN belongs in the identity lane. Cobalt can provide data layers, but the lender decides how those layers translate into approval, hold, correction, or decline.
.jpg){kind=small}
.png)