Executive Summary: The business verification API lenders 2026 conversation has moved past a single Secretary of State lookup into a layered data stack, because no one source proves a borrower is real, solvent, and clean. Federal beneficial-ownership reporting and customer due-diligence rules now expect lenders to verify the entity, its owners, and its risk exposure before money moves.[1][2] This hub guide maps the data categories an alternative lender needs, how to evaluate each one, and where a primary-source Secretary of State feed fits in the verification stack.
What does a business verification API lenders 2026 stack include?
Which data categories matter most?
A lender does not buy "verification." A lender assembles a stack of distinct data types, each answering a different underwriting question. The order matters because the cheapest, broadest checks should run first and the slower, narrower checks should run only when the file justifies them.
• Secretary of State / entity status. Confirms the business exists, is in good standing, and identifies officers and formation dates from the registering state.
• KYB and beneficial ownership. Identifies who controls the business, a federal expectation under the FinCEN reporting framework.[1]
• EIN / TIN match. Confirms the tax identification number ties to the legal name on file with the IRS.[3]
• UCC liens. Reveals existing secured-party claims that affect collateral recovery.
• Court records. Surfaces judgments and litigation that signal repayment risk.
• OFAC sanctions. Screens the business and its principals against blocked-party lists.[4]
Each category is a separate decision input. A clean entity status with an unresolved sanctions hit is still a stop.
Why is one data source never enough?
A Secretary of State record proves the entity is registered. It does not prove the tax ID matches, the owners are not sanctioned, or the collateral is unencumbered. Customer due-diligence rules treat verification as identification plus ongoing risk assessment, not a one-time lookup.[2] The stack exists because a single feed leaves gaps a fraudster can walk through.
How should lenders evaluate a verification data provider?
What evaluation criteria separate providers?
Most providers look similar in a sales deck. They diverge on a few measurable dimensions that an underwriting and engineering team can test directly.
• Coverage. Which states, which entity types, and which data fields are returned.
• Freshness. Whether the data is pulled live from the source or served from a periodic cache.
• Latency. How long a real-time call takes under load.
• Audit trail. Whether the result includes timestamped, examiner-ready proof.
• Source model. Whether the provider is the primary source or an aggregator reselling someone else's data.
A risk leader should weight freshness and audit trail. A CTO should weight latency and coverage. A CFO should weight the per-check cost against the fraud and default losses avoided.
Why does primary-source versus aggregated matter?
An aggregator caches data and resells it, which means the record can be weeks or months stale by the time a lender reads it. A primary-source provider pulls from the registering authority at request time. For a funding decision, a stale "active" status on a business that dissolved last month is worse than no answer at all, because it creates false confidence.
The practical test is not how clean the API response looks. It is whether the lender can prove, to an examiner, what the source said at the moment the decision was made.
How does KYB and beneficial ownership verification work?
What does KYB confirm that entity status does not?
Know Your Business verification ties the entity to the humans who control it. Federal customer due-diligence rules require covered institutions to identify and verify beneficial owners, not just the legal entity.[2] Entity status tells a lender the company is registered. KYB tells a lender who would be on the hook and whether those people carry risk.
Where do providers like Middesk and Alloy fit?
Several platforms package KYB, identity, and decisioning into one product. Middesk markets business verification and identity products to lenders and fintechs.[5] Alloy positions itself as an identity-decisioning orchestration layer. Dun and Bradstreet and Experian sell business data drawn largely from historical and credit-bureau records. These are reasonable starting points for a lender that wants a bundled workflow. The tradeoff is that bundled platforms often aggregate underlying data, which reintroduces the freshness question for the entity layer.
How do UCC, court, and sanctions data reduce funding losses?
Which records expose hidden borrower risk?
UCC filings show whether another secured party already claims the borrower's assets, which is the core signal in stacking detection. Court records surface judgments and active litigation that standard credit data misses. OFAC screening checks the business and its principals against sanctions lists, a Bank Secrecy Act expectation for covered lenders.[6]
How should these layers sequence in underwriting?
Run the cheap, broad checks first and the slow, narrow checks last. A workable order is Secretary of State entity status, then UCC lien discovery, then court records, then TIN match, then OFAC. Entity verification gates everything because a normalized legal name and state are required inputs for the searches that follow. Cobalt documents this sequencing across its cluster, including the pre-funding UCC search and OFAC screening guides.[7][8]
How does Cobalt fit as a primary-source SOS option?
What is Cobalt's role in the stack?
Cobalt Intelligence is a data source, not a decisioning engine. It returns real-time Secretary of State data, UCC filing information, TIN verification codes, OFAC match results, and court records where covered. The lender keeps full control of the policy: Cobalt provides the fresh data, and the lender's rules decide whether a result clears, conditions, or declines a file. Cobalt's positioning is that it pulls directly from state sources with each request rather than serving a stale aggregated database.
What does a Cobalt API call look like?
A single Secretary of State search can return entity status, officers, formation data, and, when enabled, UCC filing information in one request. The call uses an `x-api-key` header against the gateway.
curl --location 'https://apigateway.cobaltintelligence.com/v1/search?searchQuery=Acme%20Corp&state=delaware&liveData=true&uccData=true' \
--header 'x-api-key: YOUR_API_KEY' \
--header 'Accept: application/json'Setting `liveData=true` pulls real time from the state source and returns a timestamped result with a screenshot URL for the underwriting file. Setting `liveData=false` serves a fast cached response suited to high-volume pre-screening. That two-mode design lets a lender pre-screen cheaply at scale and reserve live calls for final verification.
How do the API categories compare across the stack?
Which category answers which question?
No single category is a complete control. The table below maps each data type to the underwriting question it answers, its freshness profile, and its main limitation.
| Data category | Underwriting question | Freshness | Main limitation |
|---|---|---|---|
| Secretary of State / entity status | Does the business legally exist and stand in good standing? | Real-time when pulled live | Officer fields vary by state |
| KYB / beneficial ownership | Who controls the business? | Varies by provider | Owner data quality depends on source |
| EIN / TIN match | Does the tax ID match the legal name? | IRS-record based | Confirms match, not solvency |
| UCC liens | Who already claims the collateral? | Depends on state filing lag | Public-record signal, not a balance |
| Court records | Is there litigation or a judgment? | Depends on court coverage | Limited jurisdiction coverage |
| OFAC sanctions | Is any party sanctioned? | List-update dependent | Name matches need adjudication |
Where are the coverage caveats?
Cobalt supports all 50 states plus DC for Secretary of State search, but other layers are narrower. Court records cover limited jurisdictions, and UCC coverage does not span every state. A correct workflow treats an unsupported jurisdiction as "unknown, route to fallback," never as "clean." Stating coverage limits plainly is what separates a data source a risk team can trust from a black box.
What implementation path should a lending team follow?
How should engineering phase the rollout?
Start with the entity layer because it produces the normalized name and state that every downstream search needs. Then add the risk layers in cost order.
1. Integrate Secretary of State search and normalize the legal name and state.
2. Add UCC lien discovery on the normalized name.
3. Add OFAC screening for the business and principals.
4. Add TIN match to confirm the tax identity.
5. Add court-record checks where jurisdiction is covered.
6. Store raw responses, parsed flags, and the decision reason for every file.
7. Route unsupported jurisdictions to a documented fallback, never to auto-clear.
What should risk and compliance own?
Risk owns the thresholds: what match score declines a file, how many active liens trigger review, which entity statuses pass. Compliance owns the audit trail: timestamped proof, retention, and the ability to reconstruct any decision for an examiner. Engineering owns latency and uptime handling. When those three roles share one written policy, the verification stack holds up under both fraud pressure and regulatory review. For the entity foundation, Cobalt's 50-state guide and EIN verification resources document the baseline.[9][10]
.jpg){kind=small}
.png)