Executive Summary: Three-layer stack matters when a lending team needs evidence that survives both speed pressure and audit review. The core problem is simple: single-source verification leaves gaps between entity status, tax identity, and secured debt. Cobalt's Secretary of State API retrieves business entity data from official state sources and can return normalized status, officers where available, confidence, and screenshot evidence. The API supports live and cached modes, which should be treated as different evidence levels.[1] This guide is written for CTO and VP Risk teams that want operational rules, not a generic vendor overview. Cobalt remains a data source, not a decisioning engine. The customer owns the credit policy, threshold logic, and final underwriting decision.[1]
Why does three-layer stack matter before funding?
What risk does this topic remove from the file?
The lender's job is not to collect every possible data point. The job is to remove avoidable uncertainty before money leaves the door. In this topic, the avoidable uncertainty is that single-source verification leaves gaps between entity status, tax identity, and secured debt. A clean workflow turns that uncertainty into a route: clear, correct, retry, or manual review.
For a risk team, the operational value is consistency. The same input fields, the same source hierarchy, and the same exception codes make it easier to defend why one applicant moved forward and another did not. For a CTO, the value is lower maintenance cost, because the integration has a defined endpoint, response shape, and error path instead of ad hoc staff lookups.
Which buyer should care most?
• VP Risk. This buyer wants a faster way to separate clean files from files that need review.
• Compliance. This buyer wants evidence, timestamps, response codes, and a repeatable process.
• CTO. This buyer wants an API pattern that can be tested, logged, retried, and monitored.
• Operations. This buyer wants fewer late-stage corrections and fewer files bouncing between teams.
The article should not be read as a promise that one API call can approve a loan. It should be read as a narrow way to remove a specific data gap and preserve evidence for the human or automated policy that follows.
What should the lender verify first?
What is the minimum viable workflow?
The minimum viable workflow is entity status first, EIN/name validation second, lien discovery third. The exact order may vary by lender policy, but the evidence should be stored in a way that lets the next reviewer see the source, timestamp, request ID, and result code. Cobalt's API documentation is explicit that customers build the business rules on top of returned data rather than outsourcing decisions to the data provider.[1]
| Evidence layer | Question answered | Routing value |
|---|---|---|
| Entity record | Does the business exist in the expected state record? | Confirms legal-name and status evidence |
| Tax identity | Does the supplied name and EIN match IRS records? | Separates format checks from identity validation |
| Risk overlays | Are there liens, watchlist hits, or stale records? | Routes the file to review before funding |
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 show an active entity while the EIN/name pair fails IRS validation. EIN validation can match while the entity status or UCC lien picture still needs review. OFAC screening can be clean while the legal-name evidence is thin. The stack works because each source answers a different question, not because any one source is universal.[7][8]
How does Cobalt fit without overstating the product?
What does the endpoint actually do?
Cobalt's Secretary of State API retrieves business entity data from official state sources and can return normalized status, officers where available, confidence, and screenshot evidence. The API supports live and cached modes, which should be treated as different evidence levels.[1] The practical integration starts with a narrow request, then stores the full response. For this topic, a basic request looks like this:
curl --location 'https://apigateway.cobaltintelligence.com/v1/search?searchQuery=Acme%20Corp&state=delaware&liveData=true&uccData=true&screenshot=true' \
--header 'Accept: application/json' \
--header 'x-api-key: YOUR_API_KEY'The request is only the beginning. The lender should persist the raw response, map the result into internal status values, and show the reviewer why a file cleared or routed to correction. That discipline matters more than hiding complexity behind a vague pass or fail label.
What limitation should stay visible?
UCC coverage is limited to supported states, and TIN/EIN verification validates a supplied name plus EIN rather than discovering an unknown EIN. The right content posture is to state that limitation plainly, then explain the route around it. For example, a cached SOS result can be useful for pre-screening, but final funding may need a live lookup. A TIN/EIN match can validate the submitted name and number, but it does not discover a missing EIN. A UCC search adds lien context only where coverage exists.[5]
What should engineering build into the first version?
What should be logged?
The first production version should be small, observable, and recoverable. Store the external request and the internal routing decision separately. That prevents a later auditor from confusing source data with lender policy.
• Request identifiers. Store Cobalt request IDs, your own application ID, and the applicant record ID.
• Input snapshot. Store the submitted legal name, EIN when present, state, and any normalized variant used.
• Source mode. Mark live versus cached data, IRS match status, and any customer-side batch job ID.
• Response code. Preserve IRS codes, HTTP status codes, and review route codes.
• Reviewer action. Store whether the file was cleared, corrected, retried, or sent to manual review.
What should not be automated first?
Do not start with an automatic rejection rule for every exception. Start with classification. A format error needs correction, an IRS service outage needs retry, a business-name mismatch needs document review, and a not-issued code may become a hard stop only if the lender's policy says so. Classification before automation protects the team from turning data quality into false declines.
{
"name": "ACME CORPORATION",
"tin": "123456789",
"status": "Match",
"irsCode": 0,
"irsServiceStatus": "Available"
}How should exceptions route to manual review?
Which exceptions are operational, not fraud?
Every exception deserves a label. Some are operational, such as missing suffixes, punctuation differences, applicant typos, or IRS service unavailability. Some are risk signals, such as a not-issued EIN or a name mismatch after the applicant confirms the legal name. Treating all exceptions as fraud creates unnecessary friction. Treating all exceptions as harmless creates loss exposure.
Use an explicit review matrix:
| Result | Likely cause | Recommended route |
|---|---|---|
| Format invalid | Dashes, spaces, missing digits, or wrong field | Ask applicant to correct input |
| Name mismatch | DBA entered instead of legal name, typo, or identity issue | Request W-9 or legal-name evidence |
| Service unavailable | IRS or state source unavailable | Retry later with bounded backoff |
| No state match | Wrong registration state or recent filing | Try state correction or full verification |
| Clean match | Evidence aligns with policy | Continue to next underwriting step |
How do retries stay safe?
Retries should be bounded and tied to technical failures, not to business outcomes. HTTP reads are generally idempotent, which makes retrying transient errors defensible, but uncontrolled retries can amplify a source problem.[9] AWS reliability guidance recommends designing for failure isolation and recovery instead of assuming every dependency is always available.[10] The same logic applies here: retry service problems, do not retry a confirmed mismatch without corrected input.
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 policy and audit needs.
1. Which source answers this exact question?
2. What input fields are required, and which ones are optional?
3. What does the response include for clean, no-match, partial, and service-unavailable cases?
4. How are live data, cached data, IRS match status, and screenshots labeled in storage?
5. Which exceptions are automated, and which ones route to manual review?
6. What evidence is available to defend the decision six months later?
How should the final decision be framed?
The final decision should be framed as workflow fit. If the team needs primary-source entity status, SOS belongs in the stack. If the team needs tax identity validation, TIN/EIN verification belongs in the stack. If the team needs secured-interest context, UCC belongs where coverage exists. If the team needs sanctions screening, OFAC belongs in the compliance lane. Cobalt can provide those data layers, but the lender decides how the layers translate into approval, hold, correction, or decline.[2]
Good verification architecture does not hide exceptions. It makes exceptions visible early enough that risk, compliance, and operations can act before funding.
.jpg){kind=small}
.png)