Executive Summary: How a lender should build litigation risk scoring with court data that it owns, validates, and governs itself. The goal is not to promise a pre-built litigation score from a vendor. The goal is to make one internal scoring workflow easier to defend when a regulator, an auditor, or a credit committee asks how court records translated into a risk band. The core problem is that teams either ignore court data entirely or bake a vague litigation flag into a model without separating the raw evidence from the policy weight, which makes the score impossible to audit later. Cobalt's Court Records API returns judgment details, case information, filing dates, parties involved, and amounts where available for New York State and Miami-Dade County, at one credit per lookup, and the lender builds and owns the scoring model on top of those fields.[1] Cobalt supplies the data; it is a data source, not a decisioning engine.
Why build litigation risk scoring instead of buying a score?
What ownership of the model protects
The lender is not scoring court data for its own sake. The lender is trying to turn raw filings into a consistent, explainable risk band that fits its own credit policy. Owning the scoring model matters because the lender, not a vendor, has to defend the decision. When the model is internal, the team can explain exactly which fields fed a band, why a threshold was set where it was, and how the score interacts with the rest of underwriting. A bought score hides that logic and moves the burden of proof to a black box the lender cannot open in an audit.
For risk teams, ownership means the score reflects the lender's actual loss experience and appetite, not a generic vendor curve. For engineering teams, it means the scoring layer sits in the lender's own code, versioned and testable, fed by clean source fields rather than a pre-computed number. Cobalt supplies judgment details, case information, filing dates, parties, and amounts where available; the lender decides what those fields are worth.
What the data supports and what it does not
Court data supports a defensible input to a score, not a finished verdict. A judgment is the court's final determination and carries real weight, while a filing is a claim still in progress and carries less.[2] Civil procedure explains why case stage matters, since an early filing may settle or be dismissed before it ever affects the borrower.[3] The honest framing is that a litigation score is a lender-built heuristic on top of factual court fields; it is not a Cobalt product, and Cobalt does not compute default probability.
Which buyer should care most
• VP Risk. This buyer owns the scoring policy and must defend it to a credit committee.
• Data science and modeling. This buyer needs clean, separable inputs to build and validate the score.
• Compliance. This buyer needs governance, versioning, and audit evidence for the model.
• Engineering. This buyer needs the scoring layer separated from raw source storage.
What court fields become scoring inputs?
Why raw fields must stay separate from the score
The most damaging mistake is writing a computed score back over the raw court record, so no one can later see what the source actually returned. The raw fields and the policy score are different facts and must live in different places. The source returns a party role, a case type, a filing date, and a judgment amount where available. The lender's model turns those into a weighted band. Keeping the two separate lets the team revalidate or re-weight the model without corrupting the historical evidence.
This separation is also what makes the model auditable. When a reviewer asks why an applicant scored high, the answer should trace from the stored raw fields, through the documented weighting, to the final band, with each step visible. A score that cannot be traced back to its source fields cannot be defended.
There is a practical reason this matters beyond audit. Models get revised, and a lender that fuses source and score cannot revise safely. If next quarter the team decides a pending contract dispute should weigh less, or a recent judgment should weigh more, it needs the original court fields intact to re-score historical files under the new logic. When the raw response has been overwritten with an old score, that history is gone, and the team is left comparing bands produced by two different, undocumented versions of the model. Keeping the court fields as immutable source records, with the score computed as a separate, versioned layer on top, is what lets the model be revised without erasing its own past. The Miami-Dade Clerk's public docket is a reminder that the underlying court status can also change over time, so the model should record when a field was captured, not treat it as permanent truth.[4]
Which fields carry scoring weight
| Court field | What it measures | Typical weighting logic |
|---|---|---|
| Party role | Defendant versus plaintiff | Defendant status carries more weight |
| Case type | Debt, fraud, contract, or routine | Debt and fraud cases weigh heavier |
| Filing recency | How current the activity is | Recent filings weigh more than old ones |
| Judgment presence | Claim versus entered ruling | An entered judgment outweighs a pending claim |
| Amount where available | Materiality to the facility | Larger relative amounts raise the band |
The weighting column describes policy choices the lender makes, not values Cobalt assigns. Cobalt returns the fields; the lender sets the weights and documents why.
Where coverage stops and the model must account for it
Cobalt's Court Records API covers New York State and Miami-Dade County only. A scoring model must treat an out-of-coverage jurisdiction as unknown, not as clean, or it will systematically underscore applicants the source cannot see. Federal matters, including bankruptcy, are searched through PACER, and the model should either route those applicants to manual review or ingest a supplemental source before scoring.[5] A score that treats missing coverage as a zero-risk input is a model defect, not a feature.
How should the scoring bands be structured?
How Cobalt fits without overstating the product
Cobalt's Court Records API returns judgment details, case information, filing dates, parties involved, and amounts where available, at one credit per lookup, for its covered jurisdictions.[1] The scoring model is entirely the lender's. A representative workflow illustration for this topic, showing the separation of source and score and not a fabricated API schema, looks like this:
{
"workflow": "internal_litigation_scoring",
"sourceFields": ["party_role", "case_type", "filing_date", "judgment_amount"],
"coverage": ["ny_state", "miami_dade_county"],
"coverageGapHandling": "route_to_review",
"lenderModel": {
"owner": "risk",
"outputBands": ["low", "moderate", "high"],
"versioned": true
}
}The illustration makes the boundary explicit. The `sourceFields` and `coverage` come from Cobalt; the `lenderModel` is built, tuned, and owned by the lender.
What each band should represent
The lender should define bands in terms of action, not just a number. A low band means the court evidence supports proceeding under normal policy. A moderate band means the evidence warrants a closer look or an added condition. A high band means a material, recent, defendant-side judgment or a fraud-type case that should reach senior review before funding. The bands are policy, and they should be documented so any reviewer can see what triggers each one.
| Band | Illustrative trigger logic | Policy action |
|---|---|---|
| Low | No record in coverage, or old plaintiff-side matter | Proceed under normal policy |
| Moderate | Recent pending defendant case, immaterial amount | Add condition or reviewer note |
| High | Material entered judgment or fraud-type case | Route to senior review before funding |
| Unknown | Out-of-coverage jurisdiction | Route to manual review, do not score as low |
Why the unknown band is not the low band
Collapsing unknown into low is the quiet failure that makes a litigation model dangerous. An applicant the source cannot see is not a clean applicant; they are an unmeasured one. A defensible model keeps a distinct unknown band that routes to review rather than rewarding a coverage gap with a good score. This single distinction is often the difference between a model that survives audit and one that does not.
How should the model be validated and governed?
Why validation must come before the model decides anything
A scoring model that has never been tested against outcomes is an assumption, not a tool. Before the score influences a decision, the lender should backtest it against a sample of resolved files to see whether the bands separated good and bad outcomes as intended. The point is not to prove the model perfect; it is to find where the weights are miscalibrated before they affect live funding. Validation should be repeated on a schedule, because case mix, portfolio, and policy all drift over time.
A litigation score the lender cannot explain is a liability, not an asset. Governance is what turns a clever weighting into a decision the institution can stand behind.
What governance the model needs
| Governance element | What it requires | Why it matters |
|---|---|---|
| Version control | Every weight change dated and recorded | Lets reviewers reconstruct old decisions |
| Documented weights | Written rationale for each field weight | Makes the score explainable in audit |
| Change approval | Risk and compliance sign-off on changes | Prevents silent, undocumented drift |
| Backtest records | Stored validation results per version | Shows the model was tested, not assumed |
| Coverage disclosure | Explicit handling of out-of-coverage cases | Prevents unknown from masquerading as low |
Cobalt's business verification hub is the internal reference for placing court-based scoring inside a broader verification and modeling stack, and the court records comparison guide shows how court coverage differs across sources feeding the model.[8][9]
How to keep the score in its lane
A litigation score is one input to underwriting, not the decision. It should combine with entity status, lien evidence, and identity checks under the lender's overall policy, and it should never silently auto-decline a file. FinCEN resources keep financial-crime screening in a separate compliance lane, a reminder that a litigation risk score and sanctions or BSA obligations are distinct workflows with their own governance.[7]
How should the scoring workflow route and who owns it?
What each role owns
Ownership must be explicit before the score goes live. Data science owns the weighting logic and validation. Engineering owns the separation of raw source storage from the scoring layer and the versioned deployment. Risk owns the band thresholds and policy actions. Compliance owns governance, sign-off, and audit records. Operations owns the review queues that the unknown and high bands feed. Revenue teams can request less friction, but they cannot quietly re-weight the model.
| Route | Primary owner | What good ownership looks like |
|---|---|---|
| Weighting and validation | Data science | Documented weights, scheduled backtests |
| Source and score separation | Engineering | Raw fields stored apart from computed bands |
| Band thresholds | Risk | Written policy for low, moderate, high, unknown |
| Governance and sign-off | Compliance | Version records, change approvals, audit trail |
| Review queues | Operations | Staffed handling of unknown and high-band files |
How to confirm the score applies to the right party
A score is meaningless if it rests on a court record that belongs to someone else. Before a filing feeds the model, the reviewer or automated match should confirm the party against entity and principal evidence, because common names and shared principals create false inputs. An unconfirmed match should route to review, not silently raise a score. Bankruptcy context shows why identity precision matters, since a misattributed bankruptcy would corrupt the score.[6]
What a practical rollout looks like
A practical rollout starts with the model running in shadow mode. The first week defines the fields, weights, and bands on paper and stores them under version control. The second week scores a sample of resolved files and compares bands against actual outcomes to calibrate weights. The third week runs the score beside live underwriting without letting it decide, so reviewers can compare the band to their judgment. The fourth week sets governance, locks the first model version, documents coverage handling, and defines the metrics leadership will review, such as band distribution and unknown-rate.
Two rollout metrics deserve close attention because they reveal whether the model is honest. The first is the unknown-rate, the share of scored applicants who fall into the out-of-coverage band. If that rate is high, the model is being asked to score a population it largely cannot see, and the team should either narrow its use to covered jurisdictions or add a supplemental source before the score influences decisions. The second is band stability across model versions. If a small weighting change swings a large share of applicants between bands, the thresholds are fragile and the score will feel arbitrary to reviewers and auditors alike. Watching both metrics during shadow mode, before the score touches a live decision, is what separates a governed model from a spreadsheet formula that happens to produce numbers. The lender owns these choices, and documenting the rationale for each is the difference between a model that survives a credit-committee review and one that does not.
What should a risk leader ask before trusting the model?
Questions that expose weak implementations
1. Are raw court fields stored separately from the computed score?
2. How does the model treat out-of-coverage jurisdictions, and is unknown distinct from low?
3. How is party identity confirmed before a record feeds the score?
4. Are the field weights documented, versioned, and approved by risk and compliance?
5. Has the model been backtested against resolved outcomes, and how often?
6. Can a reviewer trace a band from raw fields through the weighting six months later?
How to frame the final decision
Before framing that decision, the team should remember that the score is a tool for consistency, not a replacement for judgment. A well-built litigation score makes reviewers apply the same logic to similar files and gives the credit committee a clear line from evidence to band. It does not remove the reviewer, and it does not decide a loan on its own. Held to that standard, an owned model earns its keep by making decisions more repeatable and more explainable, which is exactly what an auditor and a regulator want to see.
The final decision should be framed as owning a defensible internal model, not buying a score. The lender builds the litigation risk scoring, sets the weights, validates the bands, and governs the versions; Cobalt supplies the underlying court fields for its covered jurisdictions and computes nothing. The court records comparison guide and the PACER comparison show where covered court data feeds the model and where federal or out-of-state searches take over.[9][10] Cobalt provides the data fields; the lender owns the scoring model, the governance, and the decision.
.jpg){kind=small}
.png)