Executive Summary: Most fraud reviews stop at the entity. The LLC is active, the formation date is old enough, the registered agent resolves, and the file moves forward. The problem is that entities are cheap to create and people are not, which means the strongest signal in a business application is usually attached to the officer names the Secretary of State returns, not to the entity itself. This post walks the two-step cross-reference concretely: pull the SOS record to get the confirmed legal entity name plus officer and registered-agent data, then feed those names into court record searches. Cobalt's court coverage is New York State and Miami-Dade County, Florida only, so treat this as a deep check for two jurisdictions rather than a national sweep.
Why Does a Clean Entity Record Still Leave You Exposed?
A Secretary of State record answers one question well: does this legal entity exist, in this state, in this status, as of right now. It does not answer whether the humans behind it have a pattern. Those are different risk questions, and underwriting operations that treat the first as a proxy for the second are the ones that get surprised after funding.
What Can an Applicant Change That the Entity Record Will Not Reveal?
Almost everything that matters. A person with a six-figure judgment can form a new LLC in an afternoon, list a clean registered agent, and present a file that passes entity verification without a single flag. Nothing in the entity record points backward to prior businesses, prior defaults, or prior litigation.
Worse, the entity record itself is an attack surface. State filing agencies have documented a pattern where someone submits an unauthorized amendment to a real, established business and changes the officers, address, or registered agent, then uses the altered record to apply for credit.[1] Texas and Georgia both publish public guidance on this specific scheme.[2][3] In those files the entity is genuinely old and genuinely in good standing. The officer name is the thing that is wrong, and only an officer-level check catches it.
How Large Is the Gap in Practice?
The measured picture is not comforting:
• Stolen legitimate business identity is now a leading SMB lending fraud type. Lenders report that stolen business identity and stolen owner identity are among the hardest categories to detect, precisely because the underlying entity data checks out.[4]
• Fraud rates are still climbing across the lender population. Alloy's benchmark survey found 67% of financial institutions and fintechs saw fraud rates rise, with 22% reporting more than $5 million in direct fraud losses in 2025.[5]
• Synthetic identity is a growing share of the mix. LexisNexis Risk Solutions reported synthetic identity accounted for 11% of fraud in its 2025 transaction data, an eight-fold increase over the prior year.[6]
• Background screening alone misses most repeat actors. The ACFE found that 88% of occupational fraudsters passed pre-employment background checks with no red flags surfaced, and only 4% of cases involved someone with a prior fraud conviction on record.[7]
• Federal programs learned this at scale. SBA's Inspector General estimated more than $200 billion in potentially fraudulent pandemic-era EIDL and PPP disbursements, roughly 17% of funds, after eligibility controls were relaxed.[8]
• The referral machinery behind those cases is still catching up. GAO found SBA lacked adequate controls for referring likely fraud in its pandemic loan programs, which is what happens when identity checks are decoupled from adjudicated outcomes.[9]
The through-line is that identity verification and behavioral history are two different data layers, and the second one lives in court records.
What Does the SOS Response Actually Give You to Search On?
This is the mechanical part most integration guides skip. Court searches are name searches. They are only as good as the name you hand them, and the name on a loan application is frequently not the name a court would have indexed.
Why Is the Applicant-Supplied Name the Wrong Search Key?
Applicants type the name they use, not the name they filed. "Ridgeline Logistics" on the application might be "RIDGELINE LOGISTICS GROUP LLC" in the state register, or it might be a DBA sitting on top of a holding entity with an entirely different legal name. Searching a court index for the marketing name returns nothing, and nothing reads as clean.
Calling SOS first converts a fuzzy applicant string into a confirmed legal entity name, and that is the string you search. Along with it you get the officer, member, or manager names and the registered agent on file. Those are the individual-level search keys, and they are the ones that carry personal history across entity boundaries.
Which Fields Become Search Keys?
Three categories come out of a live SOS pull that you should treat as inputs to the next call:
• Confirmed legal entity name. The exact registered string, including suffix and punctuation variants, which is what a court docket index is most likely to match.
• Officer, member, and manager names. The individuals with control. These are the names that let you find judgments the current entity has never touched.
• Registered agent. Useful less as a search key and more as a clustering signal, since commercial agents are shared by thousands of legitimate entities while an unusual private agent shared across several applicant files is worth a look.
• Formation date and status. A recent formation date combined with an officer carrying old judgments is a specific, actionable pattern rather than a vague concern.
• Prior or amended names. Where the state exposes them, name history gives you additional strings to run, because litigation is indexed against the name in force at filing.
Federal regulators describe the underlying red flags the same way. FinCEN and the FFIEC BSA/AML manual both call out nominee officers, mass-nominee arrangements, and rapid changes of registered agent or corporate secretary as indicators warranting enhanced due diligence.[10][11] Those are officer-level and agent-level observations, not entity-status observations.
How Do You Sequence the Two Calls: SOS First or Concurrent?
There are exactly two defensible sequences, and the choice depends on how much you trust the name you started with.
When Should You Call SOS First and Wait?
Call SOS first when the applicant-supplied business name is unverified, which is the normal case at application intake. You spend one round trip to get the confirmed legal name and officer list, then you search courts against strings you know are real. This is the pattern Cobalt's team recommends on demo calls, and it exists because a court search against a wrong name produces a false negative that looks exactly like a clean result.
Jonathan Rau at Empyrean described the same workflow from the buyer side: pull the officer off the entity record, check whether that officer is registered on other entities, then run court cases and lien data against the names that come back. The officer is the hinge. Everything downstream keys off it.
When Can You Fire Both Concurrently?
Fire concurrently when you already trust the legal entity name, which typically means a renewal, a portfolio re-check, or an application where the borrower supplied formation documents. In that situation you are not discovering the name, you are refreshing risk on a name you have already confirmed. Running SOS and court searches in parallel cuts total latency roughly in half.
The tradeoff is narrow but real. Concurrent execution means the court search is committed before you know whether SOS returns a name variant or an officer you were not expecting. If it does, you re-run. For a portfolio monitoring job that is a rounding error. For a first-time application it is a false-negative risk you do not need to take.
What Does This Look Like as a Decision Rule?
Write it as a rule, not as a judgment call, so it survives staff turnover:
• New applicant, unverified name. Sequential. SOS resolves the name, then court searches run against the resolved name plus each officer.
• Renewal or existing borrower. Concurrent. Both calls fire on the stored legal name, and a name change in the SOS response triggers a re-run.
• Applicant outside New York and Miami-Dade. SOS still runs. Court skips, and the file is routed to whatever manual or third-party path you use for that jurisdiction.
• Officer count above your threshold. Fan out one court search per officer rather than only searching the entity, since the entity is the least likely name to carry history.
• Officer appears on unrelated applicant files. Escalate before funding, independent of what the court search returns, because entity clustering is its own signal.
What Do the Public Court Systems Behind This Data Look Like?
Understanding the source explains both the value and the coverage limit. This is not a licensed aggregate database. It is a live pull against public court systems.
What Is Actually Behind the New York Coverage?
New York's Unified Court System operates WebCivil Supreme, a public portal covering Civil Supreme Court cases in all 62 counties, searchable by index number, party name, or attorney.[12] Party-name search is the relevant capability here, because that is what turns an officer name into a docket list.
New York is also where alternative lending litigation concentrates. The New York Attorney General's action against Yellowstone Capital and 25 affiliated entities produced a $1.065 billion judgment and canceled over $534 million in outstanding small business obligations.[13] An action of that scale generates a web of named parties across dozens of entities, and it is indexed in exactly the system a party-name search reaches.
What About Miami-Dade?
The Miami-Dade Clerk of the Court and Comptroller runs an online case search covering civil, family, and probate matters, with access governed by the Florida Supreme Court's standards for electronic court records.[14] Miami-Dade matters to this industry for a demographic reason rather than a legal one: a large share of funders relocated to South Florida during and after 2020, and their filings followed them.
Jordan Hansen at Cobalt has put the coverage logic plainly on demo calls. Roughly 80% of Cobalt's funder customers file judgments in these two places. Coverage is demand-driven, built where the customers actually litigate, not built as a national index. Broader jurisdictions are on the roadmap, including a planned human-assisted queue for unsupported jurisdictions that would run slower than an API call.
Why Does Live Pull Matter More Than Database Size?
Because the failure mode you care about is a judgment entered last month against an officer who is applying this week. Aggregated litigation databases refresh on a schedule, and the gap between docket entry and index refresh is where recent adverse events hide. A live pull against the court system has no cached lag, at the cost of taking 30 to 120 seconds instead of returning instantly.
Where Do Officer-Level Signals Change an Underwriting Decision?
The point of the cross-reference is not to collect data. It is to change outcomes on specific files. Four patterns come up repeatedly.
Which Patterns Are Worth Building Rules Around?
• Clean entity, dirty officer. New LLC, no litigation history, but the managing member carries an unsatisfied judgment under a prior entity. This is the single highest-value output of the cross-reference and it is invisible to entity-only checks.
• Dirty entity, explainable officer. The entity has litigation but the officer has none, which often means an inherited dispute, a landlord matter, or an acquired shell. Worth reading, frequently not worth declining.
• Officer clustering across your own pipeline. The same individual appearing as an officer on multiple applicant entities in a short window, which maps directly to the nominee red flags regulators publish.[11]
• Recent judgment against an established borrower. A portfolio-side signal rather than an origination-side one, catching deterioration between renewal cycles.
• Officer with a pattern of being sued as defendant, not plaintiff. Repeat defendant status is a different and more predictive signal than case count alone, which is why it is worth parsing party role rather than counting dockets. See our breakdown on detecting repeat defendants in lending applications.
What Do Practitioners Say They Do With It?
The demand for officer-level and court-level checks is not theoretical. Yehudah Aron at Cucumber Capital framed it as a volume question rather than a capability question:
If courts are cheap enough, then it's worth it to run on every application automatically.
That is the correct framing. Court checks stop being a deep-dive tool and start being a default layer the moment per-check cost drops below the marginal value of catching one bad file. Anthony at CorFinGroup described running 50 to 60 submissions a day and deep-diving only 10 to 15 of them, looking for one cost-effective solution covering both KYC and KYB. Peter Chong at Highwire, working construction pre-qualification, wants the same two questions answered on every contractor: are there open liens, and is there active litigation tied to this specific contractor.
Max Weisz, running an MCA operation at roughly 500 files a day, described the current state of the art bluntly: run New York court separately, then run Unicourt, then run UCC searches. Three tools, three integrations, three sets of results to reconcile by hand. That fragmentation is the actual problem the cross-reference is trying to solve.
What Are Your Options for Court Data, and Where Does Cobalt Fit?
Before getting into implementation, it is worth naming the alternatives honestly, because several of them are better choices for certain use cases.
What Else Can You Use?
PACER remains the authority for federal matters, including bankruptcy, and nothing here replaces it. Unicourt and LexisNexis both offer broad multi-jurisdiction litigation data with national reach that far exceeds two jurisdictions. CSC and Wolters Kluwer serve corporate legal departments with retrieval and monitoring services. Manual courthouse search still happens, and for a single high-value deal it is defensible.
Each of these solves coverage. What none of them solve well, for a lender running hundreds of files a day, is integration friction: getting a court result back into an automated decision flow, keyed to the same entity identifier your SOS check already produced, within one workflow and one credit model.
That is the narrow thing Cobalt's Court Case API is built for. Same API gateway, same authentication, same credit unit as the SOS lookup, so the officer names coming out of one call feed straight into the next without a second vendor contract or a second data model. The tradeoff is stated up front: two jurisdictions, deeply, rather than a national index.
Gate Rock Capital put the economics of that tradeoff in one line during a demo:
Where I would pay $4 a pull is when you have the state index on court search.
Where Does This Sit in the Verification Stack?
Court records are one layer, not a decision. The stack that most alternative lenders converge on runs SOS for entity existence and status, UCC for existing liens and stacking exposure, court records for adjudicated disputes, and TIN or EIN for tax identity. Cobalt is a data source in that stack, not a decisioning engine. Nothing in a court response tells you whether to fund. It tells you what a human or a model should weigh.
New York is worth calling out as a special case: it is the only state where SOS, UCC, contractor licensing, and court records all overlap in Cobalt's coverage. If you write meaningful volume in New York, that overlap is the deepest single-state picture available through one integration. Our state-specific court records comparison covers what that overlap does and does not include.
Running SOS checks already and want to see what the officer names surface? Test the cross-reference against your own declined files before you commit to anything. Book a working session at cobaltintelligence.com/lp/demo/ and bring five files you funded that went bad.
How Do You Wire the Cross-Reference Into Production?
The implementation is short. The design decisions around it are the part worth thinking about.
What Does the Call Actually Look Like?
The court endpoint is asynchronous only. You supply a callback URL, the request returns immediately, and results arrive at your endpoint when the live court pull completes, typically in 30 to 120 seconds. There is no synchronous mode and there is no polling product.
# Step 1: resolve the legal entity name and officers via SOS
curl -X GET "https://apigateway.cobaltintelligence.com/search?searchQuery=Ridgeline%20Logistics&state=NY" \
-H "x-api-key: $COBALT_API_KEY"
# Step 2: feed the confirmed legal name into the court search
curl -X GET "https://apigateway.cobaltintelligence.com/courtCases" \
-H "x-api-key: $COBALT_API_KEY" \
-G \
--data-urlencode "businessName=RIDGELINE LOGISTICS GROUP LLC" \
--data-urlencode "jurisdiction=newYork" \
--data-urlencode "callbackUrl=https://your-app.example.com/webhooks/court-results"
# Step 3: repeat step 2 once per officer name returned by the SOS callThe `jurisdiction` parameter accepts `newYork` and `miamiDade` for live searches, plus `testNewYork` and `testMiamiDade` for integration testing. Test modes return representative payloads without consuming credits, which means you can build and validate the entire webhook path before spending anything.
How Should You Design the Fan-Out and the Callback?
Three practical notes that save rework:
• Fan out on officers, not just the entity. One court call per officer name is one credit each, and the officer calls are where the surprises live. Budget for the fan-out rather than searching only the entity to save credits.
• Correlate on the callback. Because results arrive asynchronously and out of order, include your own application identifier in the callback URL path or query string so each result lands on the right file.
• Make the callback idempotent. Retries happen. Key stored results on a request identifier rather than appending blindly.
• Set a decision deadline, not an indefinite wait. If results have not arrived within your SLA, the file should proceed to human review flagged as court-pending rather than blocking indefinitely.
• Store the raw payload. Judgment amounts are present where available and absent where the court record does not include them, and you will want the original response when someone asks why a decision was made.
• Log every lookup for audit. Adjudicated data influencing a credit decision is the kind of thing examiners ask about, and a per-lookup log with timestamp and requester is cheap to build now and expensive to reconstruct later.
If you are wiring this alongside existing entity checks, our guide to finding related businesses across entity records covers the officer-clustering side of the same data.
What Should You Do When the Applicant Is Outside New York and Miami-Dade?
This is the honest limit, and pretending otherwise costs more trust than admitting it.
What Does the Coverage Boundary Mean for Your Workflow?
If your borrower base is national, the court cross-reference covers a minority of your files. Lara Hodgson at RoxWrite said it directly: most of our clients are not in New York. Cameron Kelliher at Elementix reached the reasonable conclusion for his own book, saying he would stay away from the court component and wished it were rounded out. Those are correct decisions given their geography, and they are worth stating because the alternative is selling a national capability that does not exist.
What the coverage boundary does not change is the SOS side. Officer and registered-agent data comes back from all 50 states on a live pull. The cross-reference logic, resolve the entity, extract the officers, cluster them against your own pipeline, still runs everywhere. Only the court leg is jurisdiction-bound.
How Do You Route the Rest?
Build the routing explicitly rather than letting it be implicit. Files with a New York or Miami-Dade nexus get the automated court leg. Everything else gets SOS plus UCC plus whatever national litigation vendor you already use, or a manual check on high-value deals only. The failure to avoid is a workflow that runs the court call on every file, gets an empty result for out-of-scope jurisdictions, and quietly reads that as a clean record.
For context on why adjudicated data belongs in the pre-funding sequence at all rather than post-approval, see our pre-funding litigation checks workflow guide.
Is Beneficial Ownership Data Going to Fill This Gap?
Not soon. As of March 2025, FinCEN exempted domestic entities and their beneficial owners from beneficial ownership information reporting, narrowing the requirement to foreign entities registered to do business in the United States.[15] GAO had already flagged that inspectors general struggle to determine beneficial owners of companies participating in federal programs.[16] The practical consequence is that state-level officer data plus court records remain the accessible individual-level signal, rather than a federal registry.
The enforcement record reinforces the point. The Prime Capital Ventures case ended with a 97-month sentence and more than $55 million in forfeiture over a scheme built on misrepresenting a lending business's capabilities.[17] Kabbage resolved False Claims Act allegations for up to $120 million after processing roughly $7 billion in PPP loans for more than 300,000 borrowers.[18] And the FBI's 2025 arrests in a small business loan scheme showed how organized the individual-level side of this has become.[19] In every one of those, the people were the story. The entity records were fine right up until they were not.
.jpg){kind=small}
.png)