Executive Summary: Most underwriting operations check court records once, at origination, and never look again. That single check has a shelf life measured in weeks, because a merchant who was clean on funding day can be sued in month three and you will not hear about it until the ACH fails. This article covers how to build a portfolio re-screening cadence on top of a request/response court records API, including how to tier your book, how often to re-query each tier, what to store, and how to diff today's result against last month's so a new filing surfaces automatically.
Why does a clean file at origination stop being true by month three?
Origination-time diligence answers a question about a single day. Every day after that, the answer decays. For short-duration products like merchant cash advances, where the repayment window is often four to twelve months, the borrower spends most of the contract in a state you have never re-verified.
What actually changes in the first 90 days?
The Federal Reserve's 2026 Report on Employer Firms, drawn from the 2025 Small Business Credit Survey, found that rising costs of goods, services, and wages were the most commonly reported financial challenge, and that 77 percent of firms reported cost pressure from that category, tariff-related increases, or both.[1] The same survey found that expectations for revenue and employment growth fell to their lowest levels since 2020.[2]
Cost pressure of that kind does not show up in a bank feed on day one. It shows up as a stretched payables cycle, then a vendor demand letter, then a filed complaint. By the time a supplier sues, the merchant has usually already been late with several other counterparties.
How fast does a civil filing become a collection problem?
A civil complaint is a public statement that a counterparty has given up on getting paid voluntarily. That is a materially different signal from a slow month in the deposit data, and one your servicing team can act on: reprioritize collections, tighten the renewal decision, or decline the second position.
The macro backdrop matters here. The delinquency rate on business loans at all commercial banks, reported by the Board of Governors of the Federal Reserve System, sat at 1.34 percent in the fourth quarter of 2025, up from 1.27 percent a year earlier.[3] That is a slow drift in aggregate. Inside a concentrated small-business book, the same drift lands unevenly, and it lands on the accounts that were already litigating.
Why does portfolio risk concentrate in the same names?
Litigation clusters. A business that is being sued by one supplier is usually being sued, or about to be sued, by several. The names that generate a filing in month three are disproportionately the names that generate the charge-off in month seven. We covered the underlying pattern in more depth in civil court filings as early warning signals for portfolio risk.
The regulatory framing is not new. The OCC's loan portfolio management guidance has long told examiners that risk evaluations must allow prompt detection of changes in portfolio quality so management can modify strategy in response.[4] The OCC reissued its lending and loan portfolio risk management booklet in 2026, covering risk management practices applicable to all phases of a loan's life cycle rather than only the underwriting phase.[5]
What does a re-screening cadence actually look like?
A cadence is three decisions: who gets re-checked, how often, and what makes you check early. Get those three right and the rest is scheduling.
How do you tier the book by risk and exposure?
Tier on the two variables that determine how much a missed filing costs you: outstanding exposure and remaining term. A large balance with six months left is worth far more attention than a small balance with three weeks left.
A workable starting split for a small-business funding book:
• Tier A, high exposure and long remaining term. Largest outstanding balances, more than four months remaining, or any account already flagged by servicing. These carry the most recoverable dollars.
• Tier B, mid exposure or renewal candidates. Accounts you expect to see again in a renewal request, where a stale file directly drives a new funding decision.
• Tier C, small exposure and short tail. Low balances with weeks remaining, where the cost of the check can exceed the exposure at risk.
• Tier D, paid and closed. No routine re-screening. Re-check only if the merchant reapplies.
• Event tier, any account with a trigger. Missed or reduced ACH, a bank change request, a sudden drop in deposit volume, or an inbound renewal application. These jump the queue regardless of tier.
What cadence fits each tier?
There is no universally correct interval. There is only the interval where the expected value of catching a filing early exceeds the cost of the query. A defensible default:
• Tier A: every 14 to 30 days. Short enough that a new filing surfaces while the balance is still meaningful.
• Tier B: every 30 to 60 days, plus a mandatory check at renewal underwriting. The renewal check is the one that pays for itself.
• Tier C: every 90 days or not at all. Run the arithmetic against average outstanding balance before committing.
• Event tier: within one business day of the trigger. This is where the fastest read matters.
• Full-book sweep: quarterly. A backstop that catches anything the tiering logic mis-sorted.
When should an event trigger an off-cycle check?
Treat any change in payment behavior as a reason to re-query rather than a reason to wait for the next scheduled sweep. A first missed ACH is often the same week a merchant is served, and checking at that moment tells you whether you are looking at a temporary cash gap or a business with a queue of creditors ahead of you. The reverse case matters too: if a merchant calls asking to restructure and the court check comes back clean, you have evidence that supports working with them rather than accelerating.
What does a court records API actually give you, and what does it not?
The re-screening problem is not that court data is unavailable. It is that court data is hard to schedule. Unicourt aggregates state and federal dockets with API access at coverage and pricing that vary by jurisdiction. LexisNexis CourtLink and similar platforms are built for legal research rather than automated portfolio sweeps. PACER covers federal courts only, excluding the state civil filings where most supplier disputes and judgments live. CSC and Wolters Kluwer sell search and filing services with strong lien footprints. And many funders still run manual clerk portal searches, which works for ten deep-dives a week and collapses at portfolio scale. Anthony at CorFinGroup put it plainly: "I'm looking for one cost effective solution for KYC and KYB." His shop takes 50 to 60 submissions a day and deep-dives 10 to 15. The deep dives are not the problem. The other 45 are.
The gap is integration friction: the inability to call one endpoint from your own decisioning code, on your own schedule, and get back a structured result you can store and compare. That is what the Cobalt Intelligence court records endpoint is built for. Start with the limit, because everything downstream depends on it.
Which jurisdictions are covered?
Coverage is New York State and Miami-Dade County, Florida. That is the entire footprint. Not nationwide, not federal, not PACER. If your borrower was sued in Texas, Illinois, or Broward County, this endpoint will not find it.
There is also no monitoring product. No subscription, no alert stream, and no webhook that pushes a notification when something new is filed. The API is request and response: you call it, you get one result for one business in one jurisdiction. Any cadence in this article is one you build and schedule on your side.
What the API does give you is currency. Data is pulled live from the court site at query time rather than served from a cached index, so a result reflects what the court publishes at the moment of the call rather than at an overnight refresh. New York's court system publishes statewide caseload data in its annual report,[6] and the underlying dockets are searchable through NYSCEF for e-filed matters.[7] Miami-Dade civil, family, and probate records run through the Clerk of the Court and Comptroller's online case search.[8]
Why only New York and Miami-Dade?
Because that is where the customers file. Roughly 80 percent 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 the COVID period. Coverage was built demand-first rather than breadth-first. 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 has not shipped.
That trade has real costs, and funders say so plainly. Lara Hodgson of RoxWrite pushed back in a demo: "Most of our clients are not in New York." Cameron Kelliher at Elementix was blunter: "We'll stay away from the court stuff then. I wish the court stuff was rounded." Both reactions are reasonable. If your book has no New York or South Florida concentration, this is not the layer to add first.
What does one request/response cycle look like?
The endpoint is asynchronous only. You pass a `callbackUrl` and the result is delivered there, typically in 30 to 120 seconds. There is no synchronous mode.
curl -G "https://apigateway.cobaltintelligence.com/courtCases" \
-H "x-api-key: $COBALT_API_KEY" \
--data-urlencode "businessName=Sample Trucking LLC" \
--data-urlencode "jurisdiction=newYork" \
--data-urlencode "callbackUrl=https://risk.yourdomain.com/hooks/court-cases"Valid `jurisdiction` values are `newYork`, `miamiDade`, `testNewYork`, and `testMiamiDade`. Results include judgment details, case number, case type and division, filing dates, and parties. Amounts are returned where the court record includes them, which is not every record. Pricing is 1 credit per lookup, the same unit cost as a Secretary of State lookup. For a walkthrough of the first integration, see the court records API integration quickstart.
How do you diff results to detect a new filing since the last check?
This is the part that turns a request/response API into something that behaves like a watch list. The API will not tell you what changed. Your datastore will, if you build it to.
What should you store from each response?
Store the full response body, not a summary. The moment you store only a case count or a boolean, you lose the ability to answer why something changed six months later, and you lose the audit record. At minimum, persist:
• The raw payload. Complete JSON as returned, immutable, one row per query.
• Query parameters and timestamp. Exact `businessName` and `jurisdiction` you sent, plus the UTC time of the call. A diff between two different name spellings is not a diff.
• A normalized case list. Each case flattened to case number, court, division, case type, filing date, party names, and amount where present.
• A run identifier tied to the account. So you can reconstruct the check history for a specific funded deal during an audit.
• The credit consumed. Attribution by account and tier, which is what makes the cost review in the next section possible.
The OCC's credit risk rating guidance expects the reasoning behind a risk assessment to be documented and reviewable rather than inferred.[9] A stored payload plus the query that produced it is that documentation.
How do you build a stable case fingerprint?
A diff is only as good as the key you diff on. Case numbers are the natural primary key but are not always formatted consistently, and party names carry punctuation and suffix variation that generates false positives when compared as raw strings. A practical fingerprint is a normalized composite: case number stripped of separators and uppercased, plus court or division code, plus filing date. Normalize party names separately for display, not for the key. The comparison is then set arithmetic against the prior run:
• New fingerprints present now and absent last run. These are your alerts.
• Fingerprints present last run and absent now. Usually a sealed, corrected, or reindexed record. Log it, do not alert on it, and review the pattern monthly.
• Fingerprints present in both runs with a changed amount or status. Treat as a material update if the amount moved or the case reached judgment.
What counts as a material change worth an alert?
Not every new row deserves a page to the servicing team. Set thresholds before you turn this on, and write them down. A reasonable first pass: alert on any new case where the merchant is a defendant, on any transition to entered judgment, and on any amount above a threshold set relative to typical deal size. Batch everything else into a weekly digest. Be careful with plaintiff-side filings, because a business suing someone else is a different signal from a business being sued, and conflating the two will erode trust in the alert within a month.
How do you batch re-screens against an active book without blowing the budget?
The cost model is simple enough to reason about on a whiteboard, which is exactly why you should do that before writing the scheduler.
How does the credit math work at 1 credit per lookup?
One lookup is one credit, per business, per jurisdiction. That last clause matters. A merchant you want checked in both New York and Miami-Dade costs two credits per pass, not one.
Work the arithmetic per tier rather than for the book as a whole. Take the count of accounts in a tier, multiply by jurisdictions checked, multiply by passes per year, and compare that total against the recoverable exposure in the tier. For Tier A the ratio is usually obvious. For Tier C it frequently is not, and the honest answer is quarterly or not at all.
Yehudah Aron at Cucumber Capital framed the decision in exactly those terms: "If courts are cheap enough, then it's worth it to run on every [application] automatically." That is the right test. Run it against your own numbers rather than against a vendor's.
How do you sequence the queue and handle callbacks?
Because the endpoint is asynchronous, your scheduler is a producer and your callback handler is a consumer, and they should be decoupled. Enqueue the accounts due for a pass, dispatch at a rate your infrastructure can absorb, and let the callback endpoint write results into the same table the diff job reads.
Spread a sweep across days rather than firing an entire book at once. A quarterly full-book sweep executed over ten business days is easier to operate, retry, and reconcile than the same volume compressed into an hour. Make the callback handler idempotent, because retries and duplicate deliveries are normal in any callback design. The same discipline applies to scheduled lien checks, walked through in how to monitor UCC filings across multiple states via API.
How do you test without spending credits?
Use `testNewYork` and `testMiamiDade`. Both run the full request and callback path without consuming credits, so you can exercise the scheduler, the callback handler, the fingerprint normalizer, and the diff logic against realistic response shapes before a single billable call. Build the diff engine against test mode first. The bugs here are almost never in the API call; they are in the normalization step, and test mode is where you should find them.
Ready to see whether a re-screening cadence pencils out for your book? Book a demo and bring your account counts by tier. We will walk the credit math with you and tell you honestly if your portfolio concentration does not justify it.
What do lenders actually say they want from court data?
The demand side of this is unusually well documented, because funders describe their current workflow without being asked.
Where does the two-jurisdiction limit break down?
It breaks down for any book with meaningful geographic spread. A funder underwriting nationally still needs a second source for everything outside New York and Miami-Dade, and pretending otherwise sets up a coverage gap that surfaces at the worst possible moment. Gate Rock Capital put a value on the piece that does work: "where I would pay $4 a pull is when you have the state index on court search." That is a statement about the New York state index specifically, not about national coverage.
Who gets the most value from the current footprint?
Operations with New York or South Florida concentration, running enough volume that manual clerk searches have already stopped scaling. Max Weisz, running an MCA shop at roughly 500 files a day with expectations of 600 to 700 submissions daily, described the current workflow:
"we run New York court separately and then we run Unicourt, and then we run UCC searches."
Three separate manual paths for one applicant, at that volume, is the problem an API call solves even when it covers only one of the three.
Adjacent shops describe versions of the same need. Peter Chong at Highwire, working on construction pre-qualification, asks: "are there any open liens against them? Any litigations associated to this specific contractor?" Berkman Financial wants applications run automatically through Salesforce. Elad Kolet at Comeryx wants Secretary of State status and court cases in the same pass.
How does court re-screening fit alongside SOS, UCC, and TIN checks?
Court records are one layer, not a decision. Treated as a standalone signal, a filing produces false alarms. Treated as a layer, it sharpens what the other layers already suggested.
What does the layered stack look like?
The order that holds up in practice is Secretary of State, then UCC, then court records, then TIN. Secretary of State tells you the entity exists and is in good standing, across all 50 states with a live pull. UCC tells you who already has a security interest, across roughly 10 to 11 states, billed as a separate credit even though it returns in the same call as the SOS lookup. Court records tell you who has already stopped negotiating, in New York and Miami-Dade. TIN and EIN verification, available in all states, confirms the tax identity ties back to the entity you funded. OFAC screening runs globally across all of it. At re-screening time the same order applies, and an entity that has fallen out of good standing plus a new judgment is a materially worse picture than either signal alone.
Why is New York the one state where every layer overlaps?
New York is the only state where Secretary of State data, UCC filings, contractor license verification, and court records are all available together, which lets a New York-concentrated book run a genuinely layered re-screen from one provider on one schedule. Contractor licensing coverage exists in only a few states, New York, Texas, and California among them, so that four-way overlap does not reproduce elsewhere today.
What should you put in place before turning re-screening on?
Two things: documentation, and a plan for what goes wrong.
What governance and documentation do examiners expect?
Write down the cadence, the tier definitions, the alert thresholds, and the escalation path before the first sweep runs, then keep the stored payloads. The OCC's lending and loan portfolio risk management guidance frames risk management as applying across the whole loan life cycle, not only at approval,[10] and a documented re-screening policy with retained evidence is how you demonstrate that.
The public enforcement record is a reminder of what weak controls cost. Kabbage agreed to pay up to $120 million to resolve False Claims Act allegations tied to its PPP lending, after processing roughly $7 billion in PPP loans for more than 300,000 borrowers as the second-largest PPP lender by application volume.[11] The settlements addressed allegations of thousands of false claims for loan forgiveness, guarantees, and processing fees.[12] Counterparty risk is just as real: Kris Roglieri, chief executive of Prime Capital Ventures, was sentenced to 97 months in prison for a wire fraud conspiracy tied to the collapse of his purported commercial lending business, with a forfeiture money judgment of $55,484,674.84.[13] On the funding side, a federal court entered a $20.3 million judgment against merchant cash advance operator Jonathan Braun and permanently banned him from the industry.[14] Public dockets are where these stories became visible before they became headlines.
What are the failure modes to plan for?
• Name drift. The `businessName` you queried at origination may not match the name the court indexed. Store the query string and review no-hit accounts periodically.
• Coverage blind spots. A no-result response means no matching record in New York or Miami-Dade. It does not mean no litigation anywhere.
• Alert fatigue. Unfiltered new-row alerts will be ignored within weeks. Set thresholds first.
• Callback loss. Design for retries and idempotency, and reconcile dispatched queries against received callbacks daily.
• Records that vanish between runs. Sealing and reindexing happen. Log disappearances, do not alert on them, and review the pattern before changing your fingerprint logic.
• Missing amounts. Not every record includes a dollar figure, so any threshold rule needs a defined behavior for null amounts.
Court re-screening will not tell you a merchant is going to default. It will tell you that someone else already concluded they would not get paid. On a short-duration book, that is often the earliest external confirmation you will get, and it costs one credit to ask.
.jpg){kind=small}
.png)