Executive Summary: Most lenders run a credit pull and a business verification before funding, then discover an active lawsuit only after a borrower stops paying. A pre funding litigation check moves that discovery earlier, into the due diligence window where a judgment, an active case, or a pattern of filings can still change the decision. The goal is not to turn court records into a verdict on the borrower. The goal is to give one due diligence workflow a defensible place for litigation evidence, a clear picture of what that evidence should show, and an exception path for everything the source cannot answer. Cobalt's Court Records API covers NY State and Miami-Dade County only, returning judgment details, case information, filing dates, parties involved, and amounts where available, at one credit per lookup.[1] Cobalt is a data source, not a decisioning engine, so the workflow below shows where the evidence sits while the lender owns the credit policy.
Why does a litigation check belong in pre-funding due diligence?
What uncertainty does it remove before funding?
A litigation check removes a specific blind spot. A borrower can pass identity, entity, and basic credit review while carrying an active judgment, a pending lawsuit that threatens cash flow, or a filing history that signals distress. The uncertainty is not whether the business exists. The uncertainty is whether the business is quietly fighting a legal claim that will compete with the lender for the same cash. Without a litigation layer, that fact surfaces only after it becomes a repayment problem, which is the most expensive moment to learn it.
For risk teams, the value is a repeatable evidence layer that separates a clean file from one that needs a closer look. For operations, the value is fewer late-stage surprises, because the litigation signal is captured while the file is still in review rather than reconstructed after a default.
The cost of skipping this layer rarely shows up as one dramatic event. It shows up as a pattern of files that default sooner than the credit model predicted, where a later review finds an active lawsuit or a standing judgment that was visible in public records the whole time. The lender did not miss the information because it was hidden. It missed the information because no step in the workflow was responsible for looking. A litigation check assigns that responsibility to a defined point in the sequence, so the question of active legal exposure gets asked every time rather than only when someone remembers to ask it.
Which buyer should care most?
• VP Risk. This buyer needs litigation evidence positioned as one input to policy, not as an automatic decline.
• Underwriting. This buyer needs the case and judgment fields in a form that supports a documented decision.
• Compliance. This buyer needs the timestamp and source record that show the check ran before funding.
• Operations. This buyer needs a clear route for jurisdictions the source does not cover.
The article should not imply that a court record approves or declines a loan. It shows how one evidence layer sharpens the picture before the lender's own policy takes over.
What should the litigation evidence actually show?
Which fields make a court record usable?
A court record is only useful to underwriting if it arrives as structured fields, not a wall of docket text. Cobalt's Court Records API returns the fields that let a reviewer read a filing quickly and decide whether it matters.[1]
| Returned field | Question answered | Underwriting value |
|---|---|---|
| Case information | What kind of matter is this? | Frames severity and relevance |
| Filing dates | Is this active or historical? | Separates current risk from old news |
| Parties involved | Is the borrower plaintiff or defendant? | Changes the risk read entirely |
| Judgment details | Was a judgment entered, and for whom? | Signals an enforceable obligation |
| Amounts where available | How large is the exposure? | Sizes the potential competing claim |
The plain-language meaning of a judgment and the structure of a civil case both sit in the reference library, which helps a reviewer read the fields without guessing.[2][3]
Why does coverage scope shape the whole workflow?
Coverage limits must stay visible in every step. Cobalt's Court Records API covers NY State and Miami-Dade County only. It does not provide nationwide court coverage. A borrower litigated in another state or county falls outside the source, and that lookup routes to a manual search or another provider rather than a false all-clear. The Miami-Dade Clerk of Courts is the local source of record for that county, and a lender confirming a specific filing can check it directly.[4] A workflow that hides this scope produces the most dangerous outcome in due diligence, a clean-looking result that simply means the source could not see the case.
The practical rule is that a litigation result should always travel with its coverage label. A no-record answer for a borrower headquartered in the covered jurisdiction carries real weight, because the source can see the courts where that borrower would most likely be sued. The same no-record answer for a borrower operating three states away carries almost none, because the source was never positioned to find the relevant filing. Storing the coverage scope beside every result is what keeps a reviewer from reading the second case as if it were the first. When the scope and the result are stored together, the workflow can route the out-of-coverage borrower to a manual search automatically rather than depending on an analyst to notice the mismatch.
Where does the check sit inside the funding sequence?
What is the minimum viable workflow?
The minimum workflow places the litigation check after basic entity verification and before the funding commitment. Run the lookup against the covered jurisdiction, store the raw result with a timestamp, label the coverage scope, and route any judgment or active case to review before the file advances. A representative internal due diligence record for this workflow, showing the shape a lender might store rather than a Cobalt API response, looks like this:
{
"applicationId": "app-7731",
"coverageScope": "NY_State",
"litigationResult": "active_case_found",
"partyRole": "defendant",
"checkedBeforeFunding": true,
"checkedAt": "2026-07-15T15:05:00Z",
"policyRoute": "manual_review",
"reviewOwner": "underwriting"
}The record keeps the source fact, an active case found, separate from the policy route, manual review. That separation lets the lender adjust its thresholds later without rewriting the evidence of what the source returned.
Which fields should stay separate?
The recurring mistake is collapsing the court result and the lender's decision into one flat status. A litigation source can return no record, an active case, a satisfied judgment, an unsatisfied judgment, or an out-of-coverage answer. The lender's policy then routes that outcome to clear, hold, or manual review. Keeping the two apart protects the audit trail and future policy changes.
| Field group | Stored example | Why it matters |
|---|---|---|
| Applicant input | Legal name, entity, jurisdiction | Shows what was searched |
| Source result | Case data, filing date, judgment, amount | Shows what the source returned |
| Limitation label | Out-of-coverage jurisdiction, no record | Prevents a gap from reading clean |
| Policy route | Clear, hold, manual review | Shows how the lender interpreted it |
| Reviewer evidence | Notes, timestamp, reviewer name | Shows who accepted the route |
A litigation check does not decide the loan. It makes sure the lender saw the borrower's active legal exposure before committing capital, and it stores that fact where a later reviewer can find it.
What exception taxonomy keeps the workflow honest?
Which results are operational versus real risk?
Every litigation result deserves a label. Some are operational, such as an out-of-coverage jurisdiction, a name that needs disambiguation, or an old satisfied judgment. Some are genuine risk, such as a large unsatisfied judgment, an active case with the borrower as defendant, or a filing pattern that suggests distress. Treating every filing as a decline stalls good borrowers who were plaintiffs or who resolved an old matter. Treating every filing as harmless is how a competing claim reaches funded capital.
| Result | Likely meaning | Recommended route |
|---|---|---|
| No record in covered area | No litigation found in scope | Continue, note coverage scope |
| Out-of-coverage jurisdiction | Source cannot see the court | Manual search or other source |
| Satisfied judgment, old | Resolved historical matter | Note and continue, low weight |
| Active case, borrower defendant | Live exposure | Manual review before funding |
| Large unsatisfied judgment | Enforceable competing claim | Escalate to risk with evidence |
Who owns each route?
Ownership belongs on paper before the workflow launches. Underwriting owns the interpretation of a case or judgment. Operations owns the manual search for out-of-coverage jurisdictions and any name disambiguation. Compliance owns the audit record. Risk owns the policy that decides which findings require escalation. When ownership is clear, an active case does not sit in an unlabeled queue while a funding clock runs. The broader business verification workflow shows how litigation evidence sits beside entity, lien, and sanctions layers.[5]
Name disambiguation deserves particular attention, because it is where a litigation workflow most often produces a wrong read. Two businesses can share a common name, and a filing against one is not evidence against the other. A workflow that matches on name alone will generate both false positives, flagging a borrower for someone else's lawsuit, and false negatives, missing a real case filed under a slightly different entity name. The stored evidence should therefore include enough identifying detail, the entity form, the jurisdiction, and any registered identifier, that a reviewer can confirm the filing belongs to the borrower in front of them before it changes a decision. Operations owning this step means the disambiguation happens once, is documented, and does not get re-litigated every time the file moves.
How should a reviewer weigh a litigation finding?
What separates a material finding from noise?
A litigation finding is a starting point for judgment, not a verdict. The reviewer's job is to decide whether the finding changes the risk on the file, and that decision turns on a few readable factors. The role of the borrower matters first: a borrower suing to collect its own receivable reads very differently from a borrower being sued by a creditor. The status of the matter matters next: an active, unresolved case carries more weight than one that closed years ago. The size of the claim relative to the borrower's revenue matters, because a small dispute is a cost of doing business while a large one can threaten solvency. Recency matters, because a cluster of recent filings suggests current pressure rather than history. A reviewer who weighs these factors consistently produces decisions that another reviewer, or a later auditor, can follow.
How does the reviewer avoid over-reading the data?
The opposite failure of missing a case is over-reading one. A single lawsuit, especially one where the borrower is the plaintiff or one that was resolved, is weak evidence of distress and a poor reason to decline an otherwise sound borrower. The discipline is to hold the finding against a written standard rather than a gut reaction. The standard should state which findings are informational and noted, which route to a closer look, and which escalate to risk. When the standard is written down, the reviewer applies the same bar to every borrower, the decision is defensible, and the workflow does not quietly drift toward declining anyone with a legal footprint. The stored evidence supports this discipline by keeping the raw fields visible, so a later reviewer can see the finding and the reasoning rather than only the outcome.
How should the litigation layer be evaluated?
What questions expose weak implementations?
The evaluation should focus on scope, evidence, and ownership, not on a demo.
1. Which jurisdictions does the source actually cover, and how are the rest handled?
2. Does a clean result mean no litigation, or only that the source could not see the court?
3. What case and judgment fields are stored, and can the file be reconstructed later?
4. Which findings route to manual review, and which continue with a note?
5. Who owns the out-of-coverage search path?
6. What evidence defends the funding decision if the borrower later sues or defaults?
How does this compare with a nationwide expectation?
A lender used to a nationwide docket search needs to understand the trade. Cobalt provides structured, credit-scoped court data for NY State and Miami-Dade County, which is precise where it covers and silent where it does not. For federal matters and broader coverage, the federal court access system remains the reference point, and the comparison between the two sources is worth reading before setting policy.[7] The honest framing is that the covered-jurisdiction check is a sharp signal inside its scope and a routing trigger outside it.
What does a practical first rollout look like?
A practical rollout starts narrow rather than trying to cover every jurisdiction at once. The comparison of court record sources for lenders helps frame where this layer fits against alternatives before the team commits to a design.[6]
The first phase is a historical comparison. Take a small set of recently reviewed applications in the covered jurisdiction, run the litigation check where appropriate, and compare what the structured result shows against what the team actually stored. The point is not to reopen funded decisions. The point is to find the gaps: files where an active case existed but was never checked, results that would have been read as clean because the coverage scope was not stored, and fields the reviewer would need but the current process never captured.
The second phase is live shadow mode. Let the litigation check run beside the existing due diligence process while reviewers keep using the current decision path. Compare the two daily. When the check surfaces an active case the current process missed, inspect whether that evidence should change policy. When the check returns clean but the current process flagged a concern, inspect whether the concern came from a jurisdiction the source does not cover. This phase is where the exception taxonomy gets tuned against real files instead of hypotheticals.
The third phase is queue ownership. Decide who receives the manual-search tasks for out-of-coverage borrowers, who owns name disambiguation, who interprets a judgment, and who can escalate a large unsatisfied claim. The team also decides what gets communicated back to the applicant and what stays internal. A borrower needs a clear correction request, not an internal risk label.
The fourth phase is production controls. Lock the field map, document the coverage scope in the reviewer screen, approve the routing rules, and decide which metrics leadership reviews. A narrow launch with a defensible evidence trail is worth more than a broad launch where every out-of-coverage borrower becomes a special case handled from memory.
.jpg){kind=small}
.png)