Executive Summary: Lending teams comparing Cobalt Intelligence and OpenCorporates are usually solving two problems at once: confirming that an applicant entity is real and in good standing, and finding the other businesses tied to the same people. Those are different jobs, and the data model behind each provider answers them differently. This guide compares both on retrieval method, officer and agent coverage, related-entity discovery, and what each one will not do.
Why Does Primary-Source Verification Matter More After the CTA Rollback?
For several years, lenders assumed a federal beneficial ownership registry would eventually carry part of the identity burden. That assumption no longer holds for domestic entities, which moves the work back to state records and to whoever is underwriting the file.
What Changed When FinCEN Exempted Domestic Companies?
On March 21, 2025, FinCEN announced an interim final rule removing the requirement for U.S. companies and U.S. persons to report beneficial ownership information under the Corporate Transparency Act, published in the Federal Register on March 26, 2025.[1] Treasury confirmed the change in a public announcement the same month.[2] The revised definition of "reporting company" now covers only entities formed under the law of a foreign country that have registered to do business in a U.S. state or tribal jurisdiction.[3]
The practical effect for a lending team is narrow but important:
• No domestic BOI filings to query. Entities created in the United States, and their beneficial owners, are exempt from reporting BOI to FinCEN.[3]
• Foreign registrants still report. Entities meeting the new definition must file under revised deadlines, and are not required to report U.S. persons as beneficial owners.[1]
• The litigation history matters. Counsel tracking the Corporate Transparency Act have documented a long sequence of injunctions, stays, and deadline changes through 2025 and into 2026.[4]
• State filings become the practical record. Secretary of State registrations, registered agents, and officer listings remain the accessible public record of who is associated with an entity.
• Compliance guidance still moves. FinCEN maintains a small entity compliance guide that is worth re-checking before you hard-code any assumption.[5]
Why Does This Push Ownership Discovery Back Onto Lenders?
If there is no domestic registry to call, the officer and agent names returned on a state filing become the strongest widely available signal about who stands behind an applicant. That makes the quality and freshness of state-level retrieval a credit question, not just an operations question.
How Big Is the Related-Entity Fraud Problem in Small Business Lending?
Related-entity risk is not theoretical. The pattern that underwriters describe most often is a small set of individuals appearing across many entities, each applying separately.
Federal oversight bodies have documented the scale of the referral problem. GAO reported that the SBA Office of Inspector General was unable to fully investigate a large share of fraud referrals because SBA did not provide sufficient or correct information in those referrals.[6] Congress has since taken up the Small Business Lending Fraud Prevention Act in the 119th Congress.[7] Trade coverage of that bill placed the targeted small business lending fraud figure at roughly $335 million.[8] Experian's business information team reported that small business fraud losses exceeded $12 billion in 2024.[9]
Industry observation: the structural weakness is that each application is evaluated as an isolated record. An entity can be active, correctly registered, and accurately represented on its own filing while still belonging to a cluster of entities sharing officers or a registered agent. A single-entity lookup returns a clean result for every member of that cluster.
That blind spot is the specific thing related-entity discovery is meant to close.
What Does OpenCorporates Actually Give a Lending Team?
OpenCorporates operates as a large open database of company records collected from official registries across many jurisdictions.[10] It is genuinely useful, and it is worth being precise about where it fits.
Where Does Aggregated Registry Data Work Well?
• Breadth across jurisdictions. International coverage is a real strength when your book is not U.S. only.
• Exploration and research. Browsing corporate structures and tracing entity names across countries is well supported.
• Bulk and academic use. The open-data orientation suits research, journalism, and analysis workloads.
• Entity name resolution. Finding candidate matches for a business name across many registries is straightforward.
Where Does Aggregated Data Fall Short for Underwriting?
The limitation is not accuracy in principle, it is the gap between when a registry changed and when an aggregated copy reflects it. For a funding decision made today, "as of the last collection run" and "as of this second" are different answers. A lender who needs to prove what a state record said at the moment of the credit decision needs retrieval tied to that moment, plus an artifact that survives an audit.
How Does Cobalt's SOS API Differ From OpenCorporates?
The core architectural difference is retrieval timing and source.
What Does Primary-Source Retrieval Change?
Cobalt pulls data directly from official state websites on each live request rather than serving it from a secondary database, across all 50 states plus D.C. Supporting capabilities include timestamped screenshots as visual proof of verification, normalized status values across states so "Active" and "In Good Standing" resolve consistently, a confidence score from 0.0 to 1.0 for automated decisioning, and a cache plus live waterfall so pre-screening can be fast while final verification is real time.
A minimal request looks like this:
curl -X GET "https://apigateway.cobaltintelligence.com/v1/search?searchQuery=ACME%20HOLDINGS%20LLC&state=az" \
-H "x-api-key: YOUR_API_KEY"What Does Cobalt Not Do?
Stating this plainly matters more than the feature list:
• It is a data source, not a decisioning engine. Cobalt returns verified records. Your credit policy still makes the call.
• It is not a turnkey compliance platform. Teams that want a packaged compliance product with case management should evaluate a platform rather than a data layer.
• Coverage varies by product. SOS retrieval spans all 50 states plus D.C., but other Cobalt products in the verification stack carry narrower jurisdictional coverage.
• Related-entity discovery is in beta. See the next section, including what beta means for your rollout plan.
• It works best inside a stack. The intended sequence is SOS, then UCC, then court records, then TIN, not a single call standing alone.
For a fuller side-by-side on the SOS data layer specifically, see Cobalt Intelligence vs Middesk: SOS Data Comparison for Lenders and Top 8 Secretary of State API Solutions for Verifying Businesses.
How Do You Find Related Businesses Linked to the Same Officers?
This is the capability most directly relevant to anyone evaluating OpenCorporates for ownership work, and it is the part of the comparison that changed most recently.
How Does the findRelatedBusinesses Parameter Work?
Find Related Businesses is an opt-in enhancement to SOS Search. It surfaces other business entities linked to the agents and officers returned in your search result, across all states in Cobalt's dataset. You enable it by adding a single boolean parameter to an existing request:
curl -X GET "https://apigateway.cobaltintelligence.com/v1/search?searchQuery=ACME%20HOLDINGS%20LLC&state=az&findRelatedBusinesses=true" \
-H "x-api-key: YOUR_API_KEY"The system then extracts agent and officer names from your SOS search result, searches the full multi-state database for other entities where those names appear, and returns matches under a `relatedBusinesses` field split into `byOfficer` and `byAgent` groups.
What Does the Address Match Indicator Tell an Underwriter?
Each related business carries a true or false address match indicator showing whether the related entity's address matches the address returned for the original search result. That single flag separates two very different situations: a same-location cluster of entities, versus a name-only coincidence between unrelated people who share a common name. Treating those identically is how review queues fill up with noise.
What Does the Response Look Like in Practice?
The related-entity data arrives alongside the standard SOS payload rather than as a separate call, which keeps the integration to one request:
{
"relatedBusinesses": {
"byOfficer": [
{
"businessName": "SUMMIT LOGISTICS GROUP LLC",
"state": "nv",
"matchedName": "JOHN SMITH",
"addressMatch": true
}
],
"byAgent": [
{
"businessName": "PINE STREET VENTURES LLC",
"state": "az",
"addressMatch": false
}
]
}
}Two fields carry most of the decision value. The `matchedName` tells the reviewer which individual created the link, which matters when a filing lists several officers and only one of them appears elsewhere. The `addressMatch` boolean tells them how much weight to give it. In the example above, an officer-linked entity in Nevada sharing an address is worth a look, while an agent-linked entity in Arizona at a different address is almost certainly just a registered agent servicing many unrelated clients, which is that industry's normal business model.
That distinction is the practical difference between a signal and noise. Registered agent firms legitimately appear on thousands of filings, so `byAgent` results without an address match are rarely meaningful on their own. Officer matches with an address match are the pattern worth routing to a human.
Beta status and honest caveats. This capability is in beta. It is free during beta and activates only when you opt in, which makes it low-risk to trial, but you should not build a hard credit rule on it until you have validated hit rates against your own book. Name-based matching produces false positives on common names, and the address match indicator is a signal for triage, not proof of a relationship.
What Should Engineering Build Into the First Version?
How Should the Verification Waterfall Be Ordered?
Run SOS status first, because an entity that is not active makes downstream checks moot. Add related-entity discovery on the same call when the applicant profile warrants it. Then move outward to lien and litigation data. Cobalt's UCC and court record products fit that later stage, and Real-Time SOS API Verification Prevents B2B Credit Application Fraud walks through the sequencing in more detail.
How Should Exceptions Route to Manual Review?
• Make retries idempotent. Repeated verification calls should not create duplicate review items.[11]
• Design for partial failure. State portals go down. Treat unavailability as a queue condition, not a decline, following standard reliability practice.[12]
• Route address-matched clusters to a human. Two or more entities sharing officers and an address is a review trigger, not an automatic decline.
• Store the screenshot with the decision. The timestamped artifact is what an auditor will ask for later.
• Keep TIN and sanctions checks separate. IRS TIN matching[13] and OFAC screening against the SDN list[14] answer different questions and should not be collapsed into the entity check.
How Long Does Integration Take Compared to Building In-House?
This is the question that decides most evaluations, and it rarely gets an honest answer in a vendor comparison.
What Does a Minimum Viable Integration Involve?
A first working integration is smaller than teams expect. You need an API key, one outbound call at the point in your flow where an application is created, a place to store the returned status and screenshot URL, and a branch that routes anything other than a clean active status to review. That is genuinely a short piece of work for one engineer, because there is no data pipeline to build and no registry parsing to maintain.
What takes longer is everything around it. Mapping state-specific status values into your own credit policy, deciding which conditions auto-decline versus queue, backfilling existing accounts, and agreeing internally on who reviews the exception queue are organizational tasks, not engineering ones. Teams that budget only for the API call are usually surprised by the policy work.
What Does Building Your Own State Scraper Actually Cost?
The build path looks cheap in month one and expensive forever after. Fifty-one jurisdictions publish records through different portals, with different search behavior, different status vocabulary, different rate limits, and no obligation to warn anyone before a site changes. The recurring cost is not writing the scrapers, it is keeping them alive.
• Maintenance is continuous, not one-time. Every portal redesign silently breaks a parser, and you find out from a false negative in production.
• Status normalization is its own project. "Active," "In Good Standing," "Current," and "NGS" mean different things in different states and must be mapped deliberately.
• Audit artifacts need designing. A screenshot at the moment of decision is straightforward to consume from an API and awkward to build reliably yourself.
• Coverage gaps become credit policy gaps. The states you have not built yet turn into manual work that quietly stays manual.
• Reliability engineering is unavoidable. Portal downtime has to degrade into a queue rather than a decline, which means retry, idempotency, and backoff logic.
We have written the full cost breakdown separately in SOS API vs Building In-House: A Cost Comparison, and Build vs Buy SOS Verification: True Cost Analysis for CTOs works through the same decision from an engineering leadership view.
How Should You Think About Cost at Real Lending Volume?
What Drives Cost in a Verification Workflow?
Per-lookup pricing is the number buyers compare, and it is rarely the number that determines spend. Volume shape matters more. A book that screens every inbound application, including ones that never reach underwriting, generates far more lookups than a book that verifies only at the point of funding. Deciding where in the funnel verification happens changes the bill more than negotiating unit price.
The second driver is how often you re-verify. An entity's status is a moving fact, and a record checked at application is not a record checked at funding. Teams either re-verify at defined checkpoints or subscribe to change monitoring, and those are different cost profiles.
Where Do Teams Overspend?
• Verifying the same entity repeatedly within one decision. Cache the result for the life of the application rather than calling on every screen load.
• Running live retrieval where cached data would do. Pre-screening tolerates cached data. Final verification does not.
• Buying a full compliance platform to get a data field. If what you need is entity status and officer names, a data layer is the cheaper shape.
• Leaving related-entity discovery on for every request. It is most valuable on applications that already carry risk signals, not on every lookup.
What Should a Buyer Ask Before Approving This Workflow?
Ask each vendor the same five questions and compare the answers directly.
Which Questions Separate a Research Database From an Underwriting Source?
• When was this record retrieved, and can you prove it? A timestamp you can show an auditor is different from a claim of freshness.
• What artifact do I keep? Decide whether a screenshot, a raw payload, or both belong in your file.
• Do you return officer and registered agent names, and what else are those names attached to? This is the question OpenCorporates and a primary-source API answer differently.
• What happens when a state portal is down? The honest answer is a queue, and any vendor claiming perfect uptime against systems they do not control is worth a second look.
• What does this cost at my actual monthly volume? List price and effective price diverge quickly at lending scale.
The answers separate a research database from an underwriting data source faster than any feature matrix will.
.jpg){kind=small}
.png)