Court Case API: Reducing Manual Underwriter Hours

July 30, 2026
July 29, 2026
18 Minutes Read
Business Verificationblog main image

Executive Summary: Manual court searching is the clearest example of low-judgment, high-repetition work sitting inside a senior analyst's day. The question is not whether a person can run a court search faster than an API, because they cannot; it is whether the hours a team spends typing business names into court portals are hours that should have been spent structuring deals and working exceptions. Cobalt Intelligence's Court Case API covers New York State and Miami-Dade County, Florida only, and this post looks strictly at what that narrow coverage does to analyst labor economics.

What Does a Manual Court Search Actually Cost an Underwriting Team?

Most underwriting shops do not carry a line item for court search labor. The cost is real, it is just distributed across dozens of people doing three-minute tasks a hundred times a week, which makes it invisible on a P&L and impossible to manage.

How much is an hour of analyst attention worth?

Credit analysts in the United States earn a median of $83,510 per year, or $40.15 per hour, according to Bureau of Labor Statistics wage data.[1] That is base wage alone, before benefits, payroll taxes, management overhead, and software seats. Fully loaded, most lenders should model a senior analyst hour between 1.4 and 1.8 times base wage. The multiplier matters less than the discipline of assigning a number to the hour at all, because until you do, "the team just checks courts" reads as free.

Why does per-file cost stay invisible on the P&L?

Origination cost data from adjacent lending markets shows how quickly small per-file tasks compound. Independent mortgage banks reported total loan production expenses of $11,898 per loan in the first quarter of 2026, up from $11,102 in the fourth quarter of 2025, against a long-run average of $7,903 per loan since the first quarter of 2008.[2] The Mortgage Bankers Association's own release attributes the quarter's roughly $800 per loan increase to production costs growing faster than volume.[3] Freddie Mac's cost to originate work found origination costs had risen 35%, or about $3,000 per loan, over a three-year window, and that lenders with high adoption of digital underwriting capabilities originated loans that were $1,500 less costly.[4]

MCA and alternative lending files are smaller and faster than mortgages, but the structural point transfers directly: cost inflation in lending operations is a labor story, and labor accounts for roughly 62% of total processing cost in document-driven financial operations.[5]

What does the repetition actually look like?

A manual New York court check is not one action. It is opening the state court search interface, entering a party name, choosing a county or accepting statewide scope, paging through returns, opening candidate cases, reading enough of each docket to decide whether the party is the same entity, then writing a note in the file.[11] Miami-Dade runs on a separate clerk-operated system with its own record conventions.[12] Two jurisdictions, two interfaces, no shared output format.

Where Should Underwriter Attention Actually Go?

The value of an analyst is judgment under ambiguity. Everything else in the job is either data collection or data entry, and both of those are reproducible by systems that do not get bored.

What is the real triage math in a working shop?

Anthony at CorFinGroup described his volume plainly during a Cobalt demo: 50 to 60 submissions a day, of which only 10 to 15 justify a deeper dive, and roughly 20 do not even qualify for a deeper look. Sit with those numbers. Somewhere around a third of daily volume is a file that a competent screen should have stopped at intake. If any part of a court check happens on those files before they are declined, that labor is pure waste, and it is waste performed by the most expensive person in the process.

The same shop that runs 50 to 60 a day cannot afford to spend senior hours on the 20 that were never going to fund. Neither can Max Weisz's MCA operation, which handles roughly 500 files per day and expects to reach 600 to 700 submissions per day. At that scale, a three-minute manual court check applied to every file is not a workflow, it is a headcount plan.

What work is genuinely low-judgment and high-repetition?

Name entry into a court portal. Typing a business name into a search box is mechanical and produces no analyst insight, yet it gates every downstream decision.

Paging through returns. Scrolling result sets to find candidate matches is pattern recognition that a system performs without fatigue.[5]

Recording a clean negative. When a search returns nothing, the entire task produced one line of file documentation, and a person did it.

Repeating the search per jurisdiction. Running the same party name against two separate court systems doubles the mechanical work without doubling the judgment.

Re-running the search later. Files that sit for a week get re-checked before funding, which means the identical mechanical sequence executes twice on the same deal.

Transcribing results into the credit memo. Copying case numbers, filing dates, and amounts into a template is data movement, not analysis.

None of that is underwriting. All of it currently happens inside underwriting.

Why does moving the screen earlier change the labor math?

An automated court check is cheap enough to run before a human opens the file, which changes what the human sees. Instead of a queue of 55 undifferentiated submissions, the analyst gets a queue where the files carrying open judgments are already flagged and the obvious declines are already surfaced. The labor saving is not primarily in the seconds of the search itself; it is in the files that never reach a person.

Yehudah Aron at Cucumber Capital framed the economics exactly this way: "If courts are cheap enough, then it's worth it to run on every [application] automatically." That is the whole argument in one sentence. A check that costs a fraction of an analyst minute can be applied universally. A check that costs three analyst minutes has to be rationed, and rationing means the screen moves late, which means people work files that should have died at intake.

"I'm looking for one cost effective solution for KYC and KYB." Anthony, CorFinGroup, describing 50 to 60 submissions per day against a deep-dive capacity of 10 to 15.

What Does Automation Not Replace in Court Work?

This is the section most vendors skip, and skipping it is how underwriting teams end up disappointed six weeks after integration. An API returns records. It does not return conclusions.

Who reads an ambiguous docket?

Court dockets are written for court participants, not for credit teams. A case can be open, closed, settled, vacated, stayed, on appeal, or dormant with no entries for two years, and the docket text distinguishing those states is inconsistent across courts and clerks. A returned record showing an active case tells an analyst that something exists. It does not tell them whether the matter is a live collection risk or a fee dispute that resolved eighteen months ago and never got a closing entry. Our guide to reading civil court dockets exists precisely because that reading is a human skill.

How do you resolve a common-name match?

Anthony at CorFinGroup raised this objection directly during his demo: if there is a John Smith in the New York courts, how do you know it is their John Smith? This is not a hypothetical edge case. Census Bureau surname analysis found about 6.3 million different surnames reported in the 2010 Census, of which 11 were reported more than a million times each, with Smith, Johnson, Williams, Brown, and Jones at the top.[6] New York's courts collectively recorded 1.89 million new filings in 2024.[7] In Florida, statewide circuit civil filings for fiscal year 2024-25 included 29,981 contract and indebtedness cases and 31,451 foreclosure cases.[8]

Volume plus name collision produces exactly the ambiguity that requires a person. An API can surface every candidate. Deciding which candidate is your applicant, using address, entity type, filing date, counterparty, and everything else in the file, is judgment work. It is also the good kind of work, the kind that justifies an analyst's salary.

Who decides what a judgment means for this deal?

A $40,000 judgment against a business with $2M in annual revenue and a clean payment history means something different than the same judgment against a business that already carries three positions. A mechanics lien on a construction file is close to routine. The same lien on a retail merchant is a signal. No data source makes that call, and no data source should. Nearly 40% of documents in a typical bank's back office fail automated capture and route to manual review, which is a useful reminder that exception handling is a permanent function, not a transitional one.[5]

The public record supplies a cautionary example. The Justice Department announced settlements with Kabbage Inc. worth up to $120 million, including a tranche of up to $56.7 million tied to allegations that the company failed to put appropriate fraud controls in place.[10] Automation that removes mechanical work is a gain. Automation presented as a substitute for review is a liability.

How Do Teams Get Court Data Today, and Where Does It Break?

Before any discussion of a specific API, it is worth being accurate about what underwriting teams already use, because most of them are not starting from zero.

What are the existing options?

Manual courthouse and portal search is still the default at smaller shops, free in cash terms and expensive in hours. PACER covers federal courts, but most judgments against small businesses are filed in state court, so PACER alone leaves the relevant gap open; we covered that division in our federal court records versus state court records breakdown. Unicourt aggregates state and federal dockets across a wide footprint. LexisNexis offers deep legal research priced for law firms. CSC and Wolters Kluwer sell search and filing services that serve corporate legal and lien workflows well.

Each is a legitimate choice. The friction is rarely coverage in isolation; it is what happens when a high-volume team tries to put any of them inside an automated pre-funding flow.

Where does integration friction actually show up?

Max Weisz described his current process in a demo as running New York court separately, then running Unicourt, then running UCC searches. Three tools, three interfaces, three output formats, and a person stitching them together per file. Berkman Financial's ask was different in form and identical in substance: they want applications run automatically through Salesforce rather than through a browser. Neither of those is a data coverage problem. Both are integration problems, and integration problems are what turn a two-minute check into a fifteen-minute one.

That is the specific gap Cobalt's Court Case API is built for: not the broadest court coverage available, but court data that drops into an automated intake flow beside the other checks a lender already runs.

How Does the Cobalt Court Case API Fit an Underwriting Workflow?

What does it cover, and what does it not?

Coverage is New York State and Miami-Dade County, Florida. That is the complete list. Not nationwide, not federal, not PACER. Jordan Hansen has confirmed this in demo after demo, including to Netevia, Clearview Funding Group, Berkman Financial, and SuperMoney, because the honest answer is more useful than a vague one.

The reason for the limit is demand, not capability. Roughly 80% of Cobalt's funder customers file judgments in exactly these two places. New York is the center of alternative lending, and Miami-Dade became the second hub after a large migration of funders to South Florida during COVID. Broader jurisdictions are on the roadmap, including a planned human-assisted queue for unsupported jurisdictions that would run slower, on the order of an hour, and is not yet shipped.

That limit will disqualify some teams, and it should. Lara Hodgson at RoxWrite put the objection cleanly: "Most of our clients are not in New York." Cameron Kelliher at Elementix reached the same conclusion from the other direction: "We'll stay away from the court stuff then. I wish the court stuff was rounded." Both responses are correct for their books. If your applicant base sits in Texas and California, the labor argument in this post does not apply to you yet.

What does a call look like?

curl -X GET 'https://apigateway.cobaltintelligence.com/courtCases?businessName=Acme%20Logistics%20LLC&jurisdiction=newYork&callbackUrl=https://your-domain.com/webhooks/court-cases' \
  -H 'x-api-key: YOUR_API_KEY'

The endpoint is asynchronous only. The `callbackUrl` parameter is required, results post back to your endpoint, and typical completion runs 30 to 120 seconds because the data is pulled live from the court site rather than served from a cache. Valid `jurisdiction` values are `newYork`, `miamiDade`, `testNewYork`, and `testMiamiDade`. Each lookup costs one credit, the same as an SOS lookup. The two test jurisdictions run without consuming credits, which matters for the pilot design discussed below.

Returns include judgment details, case number, case type and division, filing dates, parties, and amounts where the record includes them. Not every record includes an amount, and building a workflow that assumes one will produce silent gaps.

Where does it sit in the verification stack?

Court records are one layer, not the stack. The sequence most lenders run is entity status from Secretary of State data, then UCC filings for existing liens and stacking signals, then court records for judgments and active litigation, then TIN or EIN verification for identity. Cobalt is a data source in that chain, not a decisioning engine. It returns records; your credit policy decides what they mean.

New York is the only state where SOS, UCC, contractor license, and court records all overlap in Cobalt's coverage, which makes a New York applicant the one case where a single vendor call can populate four layers. That is a genuine advantage in one state, and stating it as a national capability would be false.

Running court checks on New York or Miami-Dade files today? Book a demo and bring three real applicant names. Fifteen minutes of live lookups against your own book will tell you more about the labor math than any projection.

How Should You Model the Labor Impact Before You Buy?

What baseline do you need first?

Measure before you buy, because a vendor cannot tell you what your current process costs. Three numbers are enough to start:

Files touched per day. Total submissions reaching an analyst, not just files that fund.

Share of files receiving a court check today. If it is not 100%, the current process is already rationing, which is itself a finding.

Minutes per manual check. Time it with a stopwatch on ten real files rather than asking the team to estimate, because estimates on repetitive tasks skew low.

Share of applicants in New York or Miami-Dade. This determines the ceiling on any benefit from this specific API.

Decline rate at first review. The higher this is, the more value moves to running the check earlier.

Multiply minutes per check by files per day by your loaded analyst hourly rate, then multiply the result by the share of your book in covered jurisdictions. That last multiplier is the one most vendor ROI calculators quietly omit.

What should you not promise your ops team?

Do not promise that court review disappears. It does not. Ambiguous dockets, common-name resolution, and deal-level interpretation all remain, and they remain expensive because they require your best people. What changes is the mix: fewer mechanical minutes, a higher share of analyst time on files that are genuinely hard, and a screen that fires before a person opens the file rather than after.

Do not promise decision turnaround improvements as the primary benefit either. Turnaround is a separate argument with separate measurement. The labor argument stands on its own and is easier to verify.

How do you pilot without spending credits?

The `testNewYork` and `testMiamiDade` jurisdictions run without consuming credits, so engineering can validate the full callback path, error handling, and result parsing before a production credit is spent. Build against test mode, then run a shadow period where the automated check runs in parallel with the existing manual process and compare outputs on the same files. If the automated check misses something a person caught, you want to know that during the shadow period, not after you have reassigned hours.

What Does the Analyst Day Look Like After the Change?

Which tasks disappear?

Portal navigation, repeated name entry, result paging on clean negatives, and cross-jurisdiction re-runs. On a book concentrated in New York and Miami-Dade, that is the bulk of the mechanical court work. Automation eliminates 60% to 80% of manual processing cost in the operations where it can be applied.[5] The qualifier in that sentence is doing real work: it applies where it applies.

Which tasks get harder and more valuable?

Exception handling. When the mechanical work is removed, what remains in the analyst queue is denser: the ambiguous matches, the judgments that need interpretation, the files where the court record contradicts the application. That is harder work per file and better work per hour, and it is the work that actually differentiates one underwriting shop from another.

Demand context supports investing there. The share of small business financing applicants seeking credit from online and fintech lenders rose from 17% in the 2020 Small Business Credit Survey to 29% in the 2025 survey.[9] Survey analysis published alongside those findings shows the shift toward non-bank channels holding across firm sizes.[14] More applicants routing to non-bank channels means more files per analyst, and the only sustainable responses are more headcount or a better allocation of the heads you have.[13] Our earlier piece on whether manual underwriting is dead argues the same distinction: manual judgment survives, manual verification should not.

Gate Rock Capital summarized the pricing side of this in a demo: "where I would pay $4 a pull is when you have the state index on court search." That is a team telling you exactly what the labor is worth to them. The right question for your own shop is the same one, answered with your own numbers.