Executive Summary: How risk teams combine sanctions screening, tax identity validation, and Secretary of State entity evidence into one defensible pre-funding route. The OFAC EIN SOS triple verification pattern works because each of the three layers answers a different question, and a lender who treats them as one blurred check loses the very separation that makes the evidence useful. The core problem is that many intake flows ask a single yes-or-no question, is this business real and safe, when the honest answer requires three distinct facts that can each be true or false on their own. Cobalt supplies these as separate data layers, and the OFAC Sanctions Check API returns potential matches with confidence scores while the customer owns thresholds, routing, and final decisions.[1] Cobalt is a data source, not a decisioning engine, so the pattern below is a workflow the lender owns end to end.[7]
Why do three layers answer three different questions?
What does each layer actually establish?
The three layers are not redundant, and reading them as interchangeable is the most common design mistake. Sanctions screening answers an exposure question, is this name associated with a party the lender is prohibited from transacting with. Tax identity validation answers an identity question, does this business have a legitimate Employer Identification Number consistent with the name and entity supplied. Secretary of State evidence answers a status question, does this entity exist on the state record and is it active and in good standing. A clean SOS record does not clear a sanctions exposure, and a clean sanctions screen does not confirm the tax identity. Each layer closes a gap the others leave open.
| Layer | Question answered | What a clean result does and does not mean |
|---|---|---|
| OFAC screening | Is this party sanctioned or a potential match? | Clears exposure only, says nothing about identity or status |
| EIN validation | Does the tax identity match the business? | Confirms tax identity only, says nothing about sanctions or good standing |
| SOS entity | Does the entity exist and is it active? | Confirms state status only, says nothing about sanctions or tax identity |
Which buyer relies on the combined picture?
• VP Risk. This buyer needs the three facts kept distinct so a weak result in one layer does not hide behind a strong result in another.
• Chief Compliance Officer. This buyer needs the sanctions layer to stand on its own with its own evidence and its own audit trail.
• Underwriting lead. This buyer needs to know which layer failed when a file stops, because the correction path differs by layer.
• CTO. This buyer needs three logged source calls with separate statuses rather than one collapsed boolean.
The pattern should never imply that passing all three approves a loan. It shows how three evidence layers reduce three separate ambiguities before the lender's own credit policy takes over.
What breaks when the three collapse into one status?
When a workflow flattens the three layers into a single pass or fail, the failure mode is a false sense of completeness. A file marked verified might have a strong SOS match, a strong EIN match, and a sanctions layer that timed out and was never really run. The flat status hides which fact is actually established. Later, when a reviewer asks whether the applicant was screened against the sanctions list, the record cannot answer, because the sanctions fact was never stored on its own. Keeping the three layers separate is the same discipline the broader verification stack uses, where source facts and policy routes stay distinct so a later reviewer can trust each fact independently.[7] The flat status also hides its own decay over time. A file that was fully verified at onboarding might now carry a dissolved entity or a newly sanctioned owner, but a single verified flag cannot express that any one of its three underlying facts has since changed. Three separate fields can each be re-checked and re-dated on their own cadence, which is the only way a lender can prove which specific fact was current at the moment a decision was made and which fact has since gone stale.
What order should the three checks run in?
Is there a correct sequence?
There is no single mandatory order, but a practical sequence puts the cheapest disqualifying check first and the exposure check where it cannot be skipped. Many teams run SOS first to confirm the entity exists at all, then EIN to confirm the tax identity of that entity, then OFAC to screen the confirmed party. Running SOS first avoids spending a sanctions screen on an entity that does not exist on the state record. The IRS frames the EIN as the business tax identity, which is why the EIN layer belongs after the entity is confirmed and before funding.[6]
Why should sequence never let a layer be skipped?
Sequence is an efficiency choice, not a permission to drop a layer. A common shortcut is to skip the sanctions screen when the SOS and EIN layers look clean, on the theory that a well-documented business is unlikely to be sanctioned. That shortcut is exactly what a sanctioned party structured through a clean-looking entity would exploit. The sanctions screen supports Bank Secrecy Act and anti-money-laundering obligations that do not bend because two other layers passed.[5] The Office of Foreign Assets Control treats sanctions screening as a standing program obligation, not a step that a strong entity record can excuse.[4]
| Step | Layer | Why it sits here |
|---|---|---|
| 1 | SOS entity | Confirms the entity exists before spending other checks |
| 2 | EIN validation | Confirms tax identity of the confirmed entity |
| 3 | OFAC screening | Screens the confirmed party, never skipped |
What does the combined workflow return?
How does Cobalt fit each layer honestly?
Cobalt supplies each layer as its own source call with its own result. The OFAC Sanctions Check API returns potential matches and confidence scores, and monitoring plus re-screening cadence are customer-owned patterns.[1] A representative combined event that the lender persists looks like this. It is a workflow illustration, not a published API schema.
{
"applicant": "internal-app-4471",
"sosResult": "active",
"einResult": "identity_match",
"ofacResult": "no_potential_match",
"ofacLiveScreenConfirmed": true,
"combinedRoute": "continue",
"owner": "underwriting"
}The important detail is that each layer keeps its own field. A reviewer can see the SOS status, the EIN outcome, and the sanctions result as three facts, plus the route the policy took. If any layer were missing or degraded, the gap would be visible instead of hidden inside a single verified flag.
Which fields must never merge?
The fields that must stay separate are the three source results, the freshness of each, and the single policy route. Merging any two source results destroys the ability to answer a targeted question later.
| Field group | Stored example | Why separation matters |
|---|---|---|
| SOS result | active, inactive, not-found, name-mismatch | Answers only the entity status question |
| EIN result | identity-match, mismatch, unverifiable | Answers only the tax identity question |
| OFAC result | no-match, potential-match, score, matched-fields | Answers only the sanctions exposure question |
| Layer freshness | per-layer source timestamp | Lets each fact be aged and re-checked on its own |
| Combined route | continue, correct, hold, manual-review | Shows how the lender read three facts together |
How should exceptions route across the three layers?
Which layer produced the exception?
An exception in this pattern is only actionable once the team knows which layer raised it, because the correction path is different for each. A name mismatch at the SOS layer is a data-entry or entity-selection problem. An EIN mismatch is a tax-identity problem that usually needs applicant documentation. A sanctions potential match is a compliance problem that routes to a specialist, never to a general operations queue. Labeling the exception by layer prevents a sanctions alert from being handled like a typo.
A combined verification is only as honest as its weakest layer. The pattern works when a strong result in two layers can never quietly cover for a missing or failed result in the third.
How should each layer's exception route?
| Layer | Exception | Correct route |
|---|---|---|
| SOS | Entity not found or name mismatch | Correction request or entity re-selection |
| SOS | Inactive or not in good standing | Risk review of status implications |
| EIN | Tax identity mismatch | Request supporting documentation |
| EIN | Unverifiable identity | Manual review with documentation |
| OFAC | Potential match with score | Compliance specialist review, never auto-clear |
| OFAC | Source unavailable | Hold and re-screen, never blind pass |
Who owns each layer's route?
Ownership should be assigned per layer before launch. Engineering owns the three source calls, their logging, and their error handling. Operations owns SOS and EIN correction loops with applicants. Underwriting owns the status implications of an inactive entity. Compliance owns every sanctions exception and its documentation.
| Layer route | Primary owner | What good ownership looks like |
|---|---|---|
| SOS correction | Operations | Clear request for correct legal name or state |
| EIN documentation | Operations plus underwriting | Documented tax identity evidence |
| Status review | Underwriting | Policy note on inactive or non-good-standing entities |
| Sanctions review | Compliance | Match evidence, escalation record, final disposition |
| Source reliability | Engineering | Bounded retries, per-layer error logs, alerts |
This map keeps a sanctions exception from landing in a general correction queue and keeps a simple name typo from consuming a compliance analyst's time. It also lets leadership see which layer generates the most friction, which is often the fastest path to a better intake form rather than a different data source.
What should a buyer ask before adopting the triple pattern?
What questions expose a shallow implementation?
The buying conversation should test whether the three layers stay genuinely separate under load and under failure.
1. Are the three source results stored as three fields, or collapsed into one status?
2. Can a strong SOS and EIN result ever cause the sanctions screen to be skipped?
3. What does the record show when one layer is degraded and the other two are clean?
4. How is each layer's freshness tracked so a stale fact does not pass as current?
5. Which exceptions route to compliance, and how are they kept out of general queues?
6. What evidence defends each of the three facts independently six months later?
What does a staged rollout look like?
A staged rollout proves each layer on its own before combining them. In the first week, the team runs SOS lookups on a small file set and confirms the status field is stored and readable. In the second week, the team adds EIN validation and confirms the tax-identity result is a separate field with its own correction path. In the third week, the team adds OFAC screening with a designed degraded path so a source outage holds rather than blind-passes. In the fourth week, the team wires the three into one combined route, locks the ownership map, and confirms a readback report shows all three facts for a sample file. This mirrors how careful lenders adopt any verification layer, one source at a time with proof at each step, rather than launching a merged black box.[10]
How should the final decision be framed?
The final decision should be framed as evidence separation, not a single verified badge. Cobalt supplies three data layers, and the lender owns how those three facts translate into continue, correct, hold, or decline. The sanctions layer belongs in the compliance lane with its own audit trail, the EIN layer in the identity lane, and the SOS layer in the entity-status lane. If the lender later needs litigation or license evidence, those are additional lanes with their own coverage limits, and the court and contractor layers each carry state and county boundaries the workflow must state plainly rather than assume nationwide reach.[8][9]
How should the three layers be re-verified over time?
Which layer ages fastest?
The three facts do not age at the same rate, and a re-verification schedule that treats them uniformly wastes effort on stable facts while missing volatile ones. Sanctions exposure is the most time-sensitive of the three, because the Specially Designated Nationals list is updated as designations change, so a screen that was clean six months ago is not evidence of a clean screen today.[2] Entity status can shift when a business dissolves, lapses, or falls out of good standing, but usually on a slower cadence than a sanctions designation. Tax identity is the most stable of the three, since an EIN rarely changes once issued and validated. A sensible re-verification schedule screens sanctions most often, checks entity status periodically, and revalidates tax identity only when the underlying business details change.
| Layer | Volatility | Sensible re-check cadence |
|---|---|---|
| OFAC screening | High, list changes with designations | Most frequent, per lender monitoring policy |
| SOS entity status | Moderate, changes on dissolution or lapse | Periodic, tied to renewal or portfolio review |
| EIN tax identity | Low, stable once validated | On material change to business details |
Who owns the monitoring schedule?
Monitoring and re-screening cadence are customer-owned patterns, not a native product feature, which means the lender decides how often each layer re-runs and stores the result.[1] A workflow that assumes the data source will push an alert when a sanctions status changes has misread the boundary, because the source returns a point-in-time screen and the lender owns the schedule that keeps it current. Assigning that ownership is the difference between a monitoring program and a stale snapshot. Compliance typically owns the sanctions re-screen cadence, risk owns the entity-status refresh tied to portfolio review, and operations owns the trigger that revalidates tax identity when an applicant reports a name or structure change. The Office of Foreign Assets Control frames sanctions compliance as an ongoing obligation, which is exactly why the re-screen schedule cannot be a one-time onboarding event.[4]
How should re-verification evidence be stored?
Re-verification evidence should stack, not overwrite. When a layer re-runs, the new result should be stored alongside the prior one with its own timestamp, so the record shows the full history of what was true when. Overwriting the old sanctions result with the new one destroys the ability to prove the file was clean at the moment of the original funding decision. A stacked history lets a later reviewer answer both questions, whether the party was clear when the loan was made and whether it remains clear now. This is the same evidence discipline the broader verification stack applies to every layer, where source facts are preserved with their timestamps rather than flattened into a single current status.[7]
.jpg){kind=small}
.png)