Executive Summary: Lending engineering teams already pull Secretary of State data to verify business entities, but most throw away the officer and agent intelligence embedded in every result. Find Related Businesses is a single-parameter addition to existing SOS API calls that surfaces every other entity connected to those same principals, across all 50 states, without a new endpoint or schema change.
Why Can't Your SOS Integration Show You the Full Business Picture?
The standard approach to business entity verification answers a narrow question: is this specific business active in this specific state? For most lending platforms, that question gets answered thousands of times per month through Secretary of State API calls that return entity status, formation date, registered agent details, and officer names.[1]
The problem is what happens next. The officer and agent names in that response contain business intelligence that most verification systems ignore entirely. A standard SOS lookup might confirm that "Acme Capital LLC" is active in Delaware with John Smith listed as the managing member. What it does not tell you is that John Smith also appears as an officer on three other entities in Florida, two in Texas, and one in Nevada, all formed within the past six months.
That pattern, a single individual behind multiple recently-formed entities across states, is precisely the kind of signal that underwriting teams need before making a funding decision. But surfacing it has traditionally required a separate engineering effort: building cross-reference logic, normalizing names across state databases, and maintaining the infrastructure to query multiple states for every officer and agent returned in an initial search.
"That ownership piece is a really important piece," as one operations leader at Bitty Advance put it, describing the gap between entity-level verification and the deeper principal-level visibility that lending teams actually need.
The gap exists because cross-entity matching was never part of the original SOS verification workflow. It was treated as a separate problem, one that engineering teams would build when they had time. Most never did.
What Does Cross-Entity Matching Actually Cost to Build In-House?
The engineering economics of building cross-entity verification from scratch are worse than most CTOs estimate at the planning stage.
Start with the data layer. Querying a single state's Secretary of State database through their web interface is straightforward. Querying all 50 states programmatically requires building and maintaining 50 different integrations, each with its own data format, authentication method, and rate limits. States change their websites constantly: a new CAPTCHA in Florida, a redesigned search form in California, a layout change in Ohio.[2] Cobalt Intelligence estimates that building this infrastructure from scratch takes 6 to 12 months of development time, with ongoing maintenance that never stops.[3]
"Maybe a service might be better than us throwing engineers on like the verification aspect of it," acknowledged one CTO at FileJet, describing the moment the build-versus-buy calculus tipped.
Now layer on cross-entity matching. For every entity you verify, you need to:
- Extract officer and agent names from the response
- Normalize those names to account for middle initials, suffixes (Jr., Sr., II, III), and variations across states
- Query your database or external sources for other entities where those normalized names appear
- Return the matches with enough context to distinguish meaningful connections from coincidental name overlaps
Name normalization alone is a significant engineering challenge. "John F. Kennedy" and "John Kennedy" should match. "John F. Kennedy Jr." and "John Kennedy" probably should not, depending on context. Building a normalization layer that handles these edge cases without generating excessive false positives requires dedicated effort from engineers whose time could be spent on core lending infrastructure.
The total cost of ownership for in-house cross-entity matching includes initial development (6 to 12 months of engineering time), ongoing state website maintenance (5 to 10 hours per week industry-wide[4]), name normalization refinement, and the opportunity cost of pulling engineers away from revenue-generating product work.
"The data itself, it's not our core business," one CTO at a lending platform noted when explaining why they chose to buy rather than build verification infrastructure.
What Business Intelligence Are You Leaving on the Table?
Every SOS Search response already contains officer and agent names. Without cross-entity matching, those names are treated as flat data points, useful for confirming that the applicant matches the state record but nothing more.
With cross-entity visibility, the same data becomes a network map. Consider what becomes visible:
- Stacking detection. In the merchant cash advance industry, stacking refers to a business taking multiple advances from different providers simultaneously, often without disclosure.[5] When the same officer appears across multiple recently-formed entities, each applying for funding, that pattern is visible through related business data before it becomes a loss on your books.
- Shell company signals. The SBA Office of Inspector General has identified misrepresenting true ownership as a significant type of borrower fraud, with investigations revealing patterns where individuals create multiple entities to obscure beneficial ownership.[6] Cross-entity data surfaces those connections programmatically.
- Registered agent patterns. Established businesses typically use well-known registered agent services. When the same individual serves as both officer and registered agent across a cluster of entities, the pattern may warrant additional scrutiny.
- Address correlation. A group of businesses sharing the same officers and the same physical address creates a different risk profile than businesses sharing officers but operating from separate locations.
The global KYB verification market reached $4.8 billion in 2024 and is projected to grow at a 16.2% CAGR through 2033,[7] driven largely by the recognition that entity-level verification alone is insufficient. The shift toward relationship-level verification, understanding not just whether a business exists but who controls it and what else they control, represents the next layer of due diligence that lending platforms are being forced to address.
Synthetic identity fraud exposure for U.S. lenders exceeded $3.3 billion in 2024, with synthetic identities linked to a record number of newly opened accounts.[8] Cross-entity verification is one of the few signals that can surface network-level patterns that individual entity checks miss entirely.
What Would a Single-Parameter Solution Look Like?
Instead of building the infrastructure described above, Cobalt Intelligence's Find Related Businesses feature adds cross-entity matching to any existing SOS Search call with a single query parameter:
GET /api/sos-search?searchQuery=Acme+Capital&state=delaware&findRelatedBusinesses=true
No new endpoint. No schema migration. No additional authentication. The same API key, the same base URL, the same response structure, with one additional field in the response.[9]
Here is what the response adds:
{
"status": "Complete",
"statusCode": 200,
"results": [
{
"name": "Acme Capital LLC",
"status": "Active",
"officers": ["John Smith"],
"agent": "Jane Doe"
}
],
"relatedBusinesses": {
"byOfficer": [
{
"name": "Smith Holdings Inc",
"state": "Florida",
"status": "Active",
"addressMatch": false
},
{
"name": "JS Ventures LLC",
"state": "Texas",
"status": "Active",
"addressMatch": true
}
],
"byAgent": [
{
"name": "Doe Registered Services",
"state": "Nevada",
"status": "Active",
"addressMatch": false
}
]
}
}
The response separates related businesses into two arrays: `byOfficer` (entities linked through shared officers) and `byAgent` (entities linked through shared registered agents). Each related entity includes a boolean `addressMatch` indicator that shows whether the related business shares the same address as the original search result.
For engineering teams already integrated with Cobalt's SOS API, the implementation cost is measured in hours, not months. Add the parameter, parse the new response field, and route the data into existing underwriting logic.
"It was one of the faster integrations," noted Joe Salvatore, CTO at Idea Financial, describing Cobalt's API integration experience. "The format and protocol is up to date and simple relative to some of the more traditional bureaus."[10]
How Does Name Normalization Work Without False Positives?
Name matching across 50 states is the technical challenge that makes cross-entity verification difficult to build in-house. Different states record names differently. The same person might appear as "John F. Kennedy" in Delaware, "John Kennedy" in Florida, and "JOHN F KENNEDY JR" in Texas.
Cobalt's Find Related Businesses uses a two-pass matching approach:
- Pass 1 (Exact match): Searches the name exactly as returned by the state, uppercased. If the SOS result returns "John F Kennedy," Pass 1 searches for "JOHN F KENNEDY" across all states in Cobalt's database.
- Pass 2 (Normalized match): Strips middle initials, suffixes (Jr., Sr., II, III), and reduces the name to first name plus last name only. "John F Kennedy Jr." normalizes to "JOHN KENNEDY," catching matches that exact search would miss.
This two-pass approach balances precision with recall. Pass 1 catches the straightforward cases. Pass 2 catches legitimate variations without over-matching on common names.
Corporations listed as registered agents are filtered out of results. This is a deliberate design choice: corporate registered agent services (CT Corporation, Registered Agents Inc.) appear on thousands of entities and would generate noise rather than signal. The filtering applies almost universally; the rare case of a corporation listed as an officer would still trigger a match.
The normalization runs against Cobalt's own database, not external sources. This means the matching operates on data that Cobalt has already normalized from 50 different state formats into a consistent schema, reducing the false positive rate compared to matching against raw, inconsistent state data.
What Is the Real Performance Impact on Your Pipeline?
Engineering leaders evaluating any new API feature need to understand the latency cost. For Find Related Businesses, the numbers are transparent:
- Additional response time: 1 to 2 seconds at the top end
- Data source: Cobalt's own database only (no external API calls)
- Billing impact: No additional charge during beta
- Availability: Opt-in via parameter; does not affect calls that omit it
The 1 to 2 second addition is a function of querying Cobalt's multi-state database for officer and agent name matches. Because the system queries internal data rather than making external calls, the performance is consistent and predictable.
For most lending workflows, this latency is negligible. Underwriting pipelines that already accommodate live SOS lookups (10 to 180 seconds depending on the state[11]) are not materially affected by an additional 1 to 2 seconds. Cached SOS lookups return in under one second; adding Find Related Businesses to a cached call still completes in under three seconds total.
"Very much appreciate the service provided by Cobalt. The ability to reach in and explore across all 51 jurisdictions has proven very valuable," shared Martin Taylor, CEO of Practiom. "The service has saved lots of time developing and managing my own APIs across many areas."
For engineering teams concerned about the latency tradeoff, the parameter is opt-in. Calls that omit `findRelatedBusinesses=true` are unaffected. This allows teams to enable the feature selectively, perhaps on initial applications but not on portfolio monitoring lookups, based on their specific latency requirements.
Cobalt holds SOC 2 Type II certification, and all API responses include unique request IDs and ISO 8601 timestamps for audit trail purposes.[12]
How Are Lending Engineering Teams Using This Today?
The feature launched in beta on February 25, 2026. Early adoption patterns reflect three primary use cases:
Pre-funding cross-reference. The most common implementation adds `findRelatedBusinesses=true` to the SOS verification call that already runs during underwriting. No additional API call, no additional workflow step. The related businesses data arrives alongside the entity verification data and gets routed into existing risk scoring logic. If the applicant's officer appears on zero other entities, that is a data point. If the same officer appears on seven entities formed in the past 90 days, that is a different data point entirely.
Address match flagging. The `addressMatch` boolean creates a simple binary signal. Related businesses at the same address as the applicant may indicate legitimate multi-entity operations (a holding company structure, for example). Related businesses at different addresses with the same officer may indicate broader business interests worth understanding before funding. Engineering teams are using this indicator to route applications into different review queues based on address correlation.
Agent network analysis. Registered agents who appear across clusters of entities can be a legitimate business service or a pattern worth investigating. By separating `byAgent` results from `byOfficer` results, engineering teams can apply different scoring weights to each category. An officer appearing across many entities carries different risk implications than an agent doing the same.
Ready to see what your SOS data has been missing? Add `findRelatedBusinesses=true` to your next API call, or schedule a technical walkthrough with the Cobalt engineering team.
"Working with the Cobalt team has been a consistently positive experience. They're extremely responsive and proactive about checking in on our company," said Theo Mills, CTO at Onramp Funds. "They're also open to feedback and suggestions, which makes problem-solving collaborative and efficient."
Should You Build or Buy Business Network Discovery?
The build-versus-buy decision for cross-entity verification follows a familiar pattern for CTOs in lending technology. The question is not whether the capability is valuable; the question is whether building it is the best use of your engineering team's time.
Here is the decision matrix:
FactorBuild In-HouseBuy (Cobalt FRB)Development time6-12 monthsHours (add one parameter)Data coverageStates you choose to buildAll 50 states + D.C.Name normalizationCustom engineering effortTwo-pass system includedMaintenanceOngoing (state sites change)Managed by CobaltAddress matchingBuild the logicBoolean field includedCostEngineering salary + infrastructureNo additional charge (beta)
The fundamental question is whether cross-entity matching is core to your product or peripheral infrastructure. For most lending platforms, the answer is clear: entity verification is necessary infrastructure, not a competitive differentiator. Engineering time spent building and maintaining state integrations is time not spent on underwriting models, borrower experience, or portfolio management, the areas where lending platforms actually compete.
The Trust Science acquisition of Lenders API in 2025 signaled that the industry is moving toward consortium-level fraud defense, where shared data across lenders creates visibility that no single lender can build alone.[13] Cross-entity matching from a provider with multi-state data coverage represents a step in the same direction: network-level visibility from a data layer that serves the broader market.
For 2024, false identity fraud cases increased 60% compared to the prior year, now representing nearly a third of all identity fraud.[14] The window for treating cross-entity verification as a "nice to have" is closing as fraud patterns grow more sophisticated and regulators increase scrutiny on beneficial ownership verification.[15]
Conclusion
Find Related Businesses converts officer and agent data that your SOS integration already returns into actionable network intelligence. One parameter. No new endpoint. 1 to 2 seconds of additional response time. No charge during beta.
The engineering decision is straightforward: add `findRelatedBusinesses=true` to an existing call and evaluate the data. If the related businesses data surfaces patterns your underwriting team cares about, you have gained a new risk signal at near-zero implementation cost. If it does not, you have lost nothing.
The alternative, building cross-entity matching infrastructure across 50 states with custom name normalization and address correlation logic, remains available. The question is whether that is the best use of your next engineering sprint.
Schedule a technical walkthrough to see Find Related Businesses in your test environment, or add the parameter to your next live call and see what surfaces.
.jpg){kind=small}
.png)