Executive Summary: Speed is the reason most small business borrowers picked you over a bank, and every manual verification step you keep in the approval path spends that advantage. A litigation check is one of the last checks still done by a human opening a court website, typing a business name, and reading dockets, which is exactly the kind of step that turns a same-day answer into a next-day answer. This post is about that single number: how long the court check adds to your decision, and how an asynchronous API with a 30 to 120 second callback moves it from a blocking step into a parallel one.
Why Does Decision Latency Decide Whether You Win the Deal?
Alternative lenders do not win files on price. They win on the calendar. The Federal Reserve's Small Business Credit Survey has tracked a steady migration toward online and fintech lenders, with the share of applicants seeking financing from online lenders rising from 17% in the 2020 survey to 29% in the 2025 survey.[1] That migration is not driven by cost. Firms report that borrowing costs at these lenders ran higher than they expected, and they applied anyway because they wanted a faster decision and a better chance of being funded.[2]
What does the borrower actually experience while you wait?
The applicant does not see your verification stack. They see silence. A merchant who submitted at 9:40 a.m. and expected a call before lunch is, by 3 p.m., forwarding the same bank statements to two other funders. Patience for financial application flows has been shrinking, and research on digital financial onboarding puts the average abandonment point at roughly nineteen minutes, several minutes shorter than in prior years.[3] That number describes the application form itself, not underwriting, but it describes the same borrower psychology that governs the hours after submission.
The institutional version of that number is worse. Fenergo's 2025 industry research found that 70% of financial institutions lost clients in the past year because of slow or complicated onboarding, the highest level the firm has recorded, up from 67% in 2024 and 48% in 2023.[4] The study surveyed 600 senior decision makers across banks, asset managers, and fund administrators in the United States, United Kingdom, and Singapore.[5] Lost clients is the polite phrase. In merchant cash advance, it means the ISO funded the deal somewhere else and you paid the acquisition cost for nothing.
Why does a next-day answer cost you the file?
Because next-day is a different product. Banks and credit unions live in a world where time to decision for small business and corporate lending runs three to five weeks, and digital leaders have compressed time to yes to minutes with cash out in under 24 hours.[6] Your competitive position sits inside that gap. If your stated promise is a same-day decision and your actual median is 26 hours because one check runs overnight, you are selling a bank timeline with fintech pricing.
Automated decisioning collapses that window. McKinsey's work on digital credit documents automated processes cutting time to yes by roughly half, with one fully automated application flow dropping from a 24 to 48 hour window to about four minutes.[7] Nothing in those numbers is about the quality of your credit box. It is about which steps still require a person to be awake and at a keyboard.
Where does the litigation check sit in your timeline?
For most funders it sits near the end, after bank statement analysis, after the entity check, right before the offer goes out. That placement is the problem. A check placed at the end of a serial chain inherits every delay ahead of it and then adds its own, and when it is manual it also inherits the analyst's queue depth, lunch break, and time zone.
What Does a Manual Court Search Actually Cost in Clock Time?
Say the phrase "manual court search" and it sounds like a line item. Watch it happen and it is a person clicking through a state judicial website.
What happens when an analyst opens the New York portal?
New York's Unified Court System publishes case information through eCourts, which includes WebCivil Supreme, WebCivil Local, eTrack, and the NYSCEF electronic filing system.[8] WebCivil Supreme covers civil Supreme Court cases across all 62 New York counties and supports search by index number, party, attorney or firm, justice, and calendar.[9] NYSCEF maintains its own separate case search for e-filed matters.[10]
Read that again as a workflow rather than a feature list. Two distinct search surfaces. A party search that returns a list, not an answer. A results page that has to be opened case by case to see what the filing actually is. An analyst who is competent and not distracted does one clean entity in five to eight minutes. An entity with three name variants and a common surname takes twenty.
How does Miami-Dade add a second manual detour?
Miami-Dade County runs its own record access through the Clerk of the Court and Comptroller, with civil, family, and probate case information available under the Florida Supreme Court standards for access to electronic court records.[11] Civil case information sits in its own section of that system.[12] Different interface, different search grammar, different result formatting than New York.
Now count the switching cost. Your analyst does not run one court process. They run two unrelated ones, and the muscle memory from the first does not transfer to the second. Multiply that across a submission queue and the cost is not the search, it is the context switch.
Why do name variants multiply the minutes?
Because a party search matches strings, not businesses. The application says "Sunrise Logistics." The Secretary of State record says "Sunrise Logistics Group LLC." The judgment was entered against "Sunrise Logistics Grp., LLC." A human resolves that with judgment and three more searches. Each of those searches is another portal round trip, and none of them are billable minutes.
This is where the real operating pain shows up in customer conversations. Max Weisz, running an MCA shop at roughly 500 files a day and expecting 600 to 700 submissions a day, described the stack plainly: "we run New York court separately and then we run Unicourt, and then we run UCC searches." Three tools, three interfaces, three human passes, on every file that gets a serious look.
Why Do Sequential Verification Stacks Set Your Floor Too High?
Most underwriting pipelines were not designed. They accumulated. A check got added when a loss happened, and it got bolted onto the end of whatever was already running.
What is the difference between additive and concurrent latency?
In a serial pipeline, total latency is the sum of every step. In a concurrent pipeline, total latency is the duration of the slowest step. That distinction is the entire architectural argument, and it is not a Cobalt idea. It is the standard case for asynchronous request and reply patterns, where a client submits work, receives an immediate acknowledgment, and gets the result later through polling or a callback rather than holding a connection open.[13]
Consider a four-check stack: entity status, court records, TIN verification, and UCC filings. Run serially at, generously, 30 seconds each, you are at two minutes of machine time plus whatever human handoffs sit between them. Run concurrently and you are at whatever the slowest single call takes. The arithmetic does not care which vendor you use.
• Serial stacks compound every vendor's worst day. One slow dependency delays every check behind it, and chained synchronous calls degrade both response time and reliability across the whole path.[14]
• Concurrent stacks isolate failure. A court call that times out does not block the TIN result that already returned, so the underwriter can act on partial data.
• Callbacks remove the polling tax. A webhook delivers the result when it exists instead of asking every two seconds whether it exists yet.[13]
• Orchestration makes parallel branches resumable. Workflow engines pause each parallel branch and resume it when the external service reports completion, which is the correct pattern for long running third-party jobs.[15]
• Partial results are still decisions. If three of four checks clear in 40 seconds and the fourth is pending, a well-built queue routes the file to conditional review instead of dead time.
• Timeouts become policy, not accidents. You decide what happens at 180 seconds rather than discovering it during a Friday afternoon volume spike.
Which call actually sets the floor?
Whichever one you are honest about. Court records pulled live from a court site will typically complete in 30 to 120 seconds because the pull is happening against the court's own system in real time rather than against a stale cache. That is your floor. Entity and TIN calls return faster. If your total automated verification latency is meaningfully above two minutes, the cause is almost always serialization, not any individual data source.
How Does an Asynchronous Court Case API Change the Shape of the Pipeline?
The word asynchronous makes some underwriting leaders flinch, because it sounds like waiting. In a pipeline design it means the opposite.
What does the request and callback cycle look like?
You send one request with the business name, the jurisdiction, and a callback URL. You get an immediate acknowledgment. Your system moves on to the rest of the file. When the court pull completes, the result is posted to your endpoint and your case record updates. Nobody sat and watched a spinner. The Cobalt Court Case API works exactly this way: `GET /courtCases`, authenticated with an `x-api-key` header, with `businessName`, `jurisdiction`, and `callbackUrl` all required. There is no synchronous mode, by design.
curl -G "https://apigateway.cobaltintelligence.com/courtCases" \
-H "x-api-key: $COBALT_API_KEY" \
--data-urlencode "businessName=Sunrise Logistics Group LLC" \
--data-urlencode "jurisdiction=newYork" \
--data-urlencode "callbackUrl=https://underwriting.yourdomain.com/hooks/court-cases"Two things to note before you build against it. First, `jurisdiction` accepts `newYork`, `miamiDade`, `testNewYork`, and `testMiamiDade`. The two test values run without consuming credits, which means you can wire and load-test the entire callback path before a single billable lookup. Second, the callback endpoint has to be reachable from the public internet and it has to be fast, because it is receiving a POST, not negotiating with you.
Why is async an advantage rather than a compromise?
Because the alternative is a held-open HTTP connection while a court website is queried on your behalf, and that is a worse design under load. A synchronous court API would either lie to you with cached data or time out during exactly the volume peaks when you most need it. Cobalt's data is pulled live from the court site at request time, which is the reason the call takes 30 to 120 seconds and the reason the answer is current.
For a full walkthrough of building the receiving side, see Court Case API: Webhook Architecture for Lender Alerts and the Court Records API Integration: A 30-Minute Quickstart.
What Are Your Real Options for Getting Court Data Into the Decision Path?
Before this becomes a product pitch, be clear that there are several ways to solve it and they trade off differently. The honest comparison matters more than the sales case.
What do the existing routes cost you in turnaround?
Manual courthouse and portal search is the default and the slowest. It is accurate when done carefully, it requires no integration, and it cannot be scheduled. Its latency is your analyst's queue depth.
PACER covers federal courts and is genuinely inexpensive per unit at $0.10 per page, with no fee owed until an account accrues more than $30.00 in a quarterly billing cycle.[16] The catch for underwriting is that PACER charges by pages generated in a search even when the search returns no matches, and there is no per-search cap on those result pages.[17] More importantly for latency, PACER is federal. Most judgments against small businesses are state civil matters and never appear there.
Unicourt, LexisNexis, CSC, and Wolters Kluwer all sell court and public record data with broader footprints. They are legitimate choices, particularly if you need national reach. The friction is integration shape and turnaround: many are built for legal research workflows or for ordered searches with human fulfillment, which is a different latency profile than an automated underwriting hop.
That is the actual gap Cobalt fills. Not breadth. Integration shape. A single parameterized call that returns to a webhook in seconds, priced at one credit per lookup, the same as a Secretary of State lookup, so the check is cheap enough to run automatically rather than reserving it for files someone already suspects.
Yehudah Aron at Cucumber Capital put the economics in one sentence:
"If courts are cheap enough, then it's worth it to run on every [application] automatically."
That is the whole design goal. A check you run on every file is a control. A check you run on suspicious files is a hunch.
Where does the honest limit sit?
New York State and Miami-Dade County, Florida. That is the entire court records coverage. Not nationwide, not federal, not PACER. If your applicant is in Ohio, this API returns nothing for them and you should not build a workflow that pretends otherwise.
The reason for that scope is demand, not ambition. Roughly 80% of Cobalt's funder customers file judgments in those two venues. New York is the center of alternative lending, and Miami-Dade became the second hub after a large migration of funders to South Florida. Coverage was built where the filings actually are.
That limit costs deals, and the objections are direct. Lara Hodgson at RoxWrite: "Most of our clients are not in New York." Cameron Kelliher at Elementix: "We'll stay away from the court stuff then. I wish the court stuff was rounded." Both are reasonable positions. Broader jurisdictions are on the roadmap, including a planned human-assisted queue for unsupported venues that would run closer to an hour rather than seconds, and that queue has not shipped.
See the latency difference on your own files. Run a set of recent New York and Miami-Dade applicants through the Court Case API in test mode, then compare the callback timestamps against your current manual turnaround log. Book a demo and bring the file list.
How Do You Design the Concurrency Pattern in Practice?
There are two correct patterns and the right one depends on how much you trust the business name on the application.
When should you call Secretary of State first?
When the name on the application is user-entered and unverified, which is most of the time. Broker submissions carry DBAs, abbreviations, and outright typos. Firing a court search against a name the state does not recognize burns a credit and returns a clean result that means nothing.
So: call the SOS API first, take the confirmed legal name off the entity record, then fan out. You have added one call to the critical path, roughly a few seconds, and in exchange every downstream search runs against a name that exists in the state's own records. For high-volume shops this is the pattern that actually protects match quality.
When should you fire everything concurrently?
When you already trust the name. If the applicant came through a channel that validates entity data upstream, or the file is a renewal on a borrower whose legal name you verified months ago, there is no reason to serialize. Fire SOS, court records, TIN verification, and UCC concurrently, collect the callbacks, and let the slowest one set your floor.
The build looks like this:
• Normalize the input first. Strip punctuation, standardize the entity suffix, and record what you sent so a mismatch is debuggable later.
• Issue all four calls from the same orchestration step. A workflow engine that can pause and resume parallel branches on external callbacks is the natural fit here.[15]
• Persist a correlation identifier per application. The court callback arrives detached from your original request, so the receiver needs to know which file it belongs to.
• Make the callback handler idempotent. Retries and duplicate deliveries are normal in webhook systems, and double-writing a judgment record creates a review artifact you do not want.
• Set an explicit timeout with a defined fallback. At 180 seconds, route to manual review with the partial result attached rather than holding the file open.
• Log a per-call latency metric from request to callback receipt. You cannot claim a faster pipeline without this series.
• Gate on jurisdiction before spending the call. If the applicant's address is not New York or Miami-Dade, skip the court call and mark the file as court-unchecked rather than court-clear.
That last point is the one teams get wrong most often. A skipped check and a clean check are not the same fact, and letting them collapse into one field on a case record is how a coverage limit becomes a credit loss.
How does this interact with the rest of the verification stack?
New York is the one state where Secretary of State data, UCC filings, contractor licensing, and court records all overlap in Cobalt's coverage, which makes New York applicants the natural place to test a full concurrent stack. Elsewhere your fan-out is narrower and the court branch simply does not exist. For the jurisdiction-by-jurisdiction picture, see State-Specific Court Records: NY, FL, and CA Coverage Comparison.
How Do You Prove the Change Actually Moved Your Numbers?
An architecture argument is worth nothing if you cannot show the median moved. Instrument it before you migrate.
Which metrics matter?
Measure time from application submission to decision at the median and at the 95th percentile, separately. The median tells you what most applicants experience. The 95th percentile tells you where you are losing the files that got stuck, and stuck files are where manual court searches hide. Also track the share of applications where the court check was the last input to arrive, because that is the number that tells you whether the check is still your floor or has stopped mattering.
Then track blocking versus parallel time. If your court check is nominally automated but the underwriter still waits on it before opening the file, you moved the work without moving the latency. That failure mode is common enough to test for deliberately.
What changes downstream when the check is cheap and fast?
Coverage of the portfolio, not just speed. When a check runs in minutes at one credit, it moves from exception handling to standard processing, and that changes what your risk team can see. Anthony at CorFinGroup described the goal as "one cost effective solution for KYC and KYB" across 50 to 60 submissions a day with 10 to 15 deep dives. The point of automating the fast path is that the deep dives get the human hours.
Berkman Financial wants applications run automatically through Salesforce, which is the same requirement stated as an integration preference. Gate Rock Capital priced the value directly: "where I would pay $4 a pull is when you have the state index on court search." Different firms, one shared conclusion. The check earns its place when it stops requiring a person.
Credit decisioning models improve when the inputs arrive reliably and on time rather than being fetched by hand for a subset of files, which is a well documented pattern in next-generation decisioning work.[18] A litigation signal that exists on 12% of your files is an anecdote. One that exists on every New York and Miami-Dade file is a variable.
Cobalt is a data source, not a decisioning engine. It returns judgment details, case numbers, case type and division, filing dates, parties, and amounts where the record includes them. What you do with a $40,000 open judgment against a merchant requesting $75,000 is your credit policy, and it should stay that way. For the workflow layer above the data, see Pre-Funding Litigation Checks: A Workflow Guide.
.jpg){kind=small}
.png)