Executive Summary: Court party roles determine whether a litigation search result describes a claim against your borrower or an effort by your borrower to collect money owed. This article walks through how to read plaintiff, defendant, and counterclaim designations before assigning any exposure to a commercial applicant, using a documented reconciliation method, an illustrative worked example, a decision table, and a reviewer worksheet an underwriting team can adapt.
Why Does a Plaintiff Hit Get Misread as Borrower Risk?
What happens when a reviewer skips the role check?
A common shortcut in file review is to treat any court search hit as a negative signal regardless of which side the applicant sits on. New York's official court glossary defines a plaintiff as the party who brings a civil action, and a defendant as the party who is sued[1]. Those are two different positions with different implications for a lender. A business that files as plaintiff is frequently the party trying to recover money, enforce a contract, or collect a receivable, not the party accused of owing it. If a reviewer flags every appearance in a court search as adverse without checking which column the borrower's name sits in, the file can penalize a company for pursuing its own collections.
Why does role confusion happen more with commercial applicants?
Commercial borrowers frequently operate under multiple related entities, and a search by business name can return cases where the applicant is plaintiff in one matter and defendant in another. New York's basic steps in a court case page confirms the plaintiff starts the case and the defendant responds, with the matter proceeding through motions and potentially trial[2]. Nothing in that structure implies fault attaches automatically to either party. A reviewer working quickly through a stack of applications, especially when court search responses vary in the amount of case detail returned, can conflate "case exists" with "borrower is in trouble." Cobalt's documented New York response structure shows the first result in an array typically carries more detail, including a plaintiff field, petitioner field, and a defendants array, while later results in the same response may include only top-level fields like caption and courtCaseType[3]. A workable policy is to read the specific party fields on each record rather than reacting to the presence of a case alone.
We recommend that no litigation search result be logged as a risk factor until a reviewer has recorded which party role the borrower occupies and what relief is sought, because the role field changes the entire meaning of the hit.
How Do NY Court Definitions Separate Plaintiff, Defendant, and Counterclaim?
What do the four core terms actually mean?
New York's glossary lays out four terms a reviewer needs before touching a court search result: plaintiff, defendant, counterclaim, and complaint[1]. The plaintiff brings the civil action. The defendant is the party being sued. A counterclaim is a claim the defendant brings back against the plaintiff within the same case, meaning a party who started as defendant can also be asserting an affirmative claim of its own. A complaint is the plaintiff's initiating pleading describing the claim. These definitions are specific to New York court usage and should not be assumed to carry identical meaning in every jurisdiction, a distinction the glossary source itself makes clear by presenting them as NY definitions rather than universal legal consequences[1].
Why does disposition status change the read on a case?
The same glossary defines disposition as the result of a case reached through withdrawal, settlement, order, judgment, or sentence[1]. It also distinguishes dismissal with prejudice, which prevents the same claim from being renewed, from dismissal without prejudice, which allows the claim to be re-filed. A docket summarizes the case, while a judgment determines the parties' rights. Combining party role with disposition status gives a materially different picture than role alone. A borrower listed as defendant in a case dismissed with prejudice sits in a different position than a borrower listed as defendant in a case that ended in judgment against it. A search hit by itself, without role and disposition, tells a reviewer almost nothing usable. The following practices support a defensible internal read of a court record before any risk conclusion is logged:
• Party role. Record whether the borrower's name appears as plaintiff, defendant, or in a counterclaim position, since these carry distinct meanings[1].
• Case status. Note whether the case is open or resolved through withdrawal, settlement, order, judgment, or sentence before drawing any conclusion[1].
• Dismissal type. Distinguish dismissal with prejudice from dismissal without prejudice, since only the latter permits the claim to return[1].
• Available detail level. Confirm whether the specific record includes party fields and documents or only top-level caption information[3].
• Entity match. Verify the case actually names the applicant business rather than a similarly named or affiliated entity before filing any note in the underwriting record.
How Should a Reviewer Reconcile Borrower A's Case File?
What does the illustrative worked example show?
Consider an illustrative example, not an observed transaction. Borrower A applies for working capital financing and lists Entity B as its operating name. A court search by business name returns two matters. In the first, Borrower A appears in the plaintiff field of a case captioned as a commercial collections action, with Entity B named among the defendants array, consistent with the fields Cobalt's documented New York response structure can return[3]. Read alone, an untrained reviewer might log this as "litigation involving Borrower A" without noting that Borrower A is the party seeking recovery, not the party accused. In the second matter, the response returns only top-level fields, meaning the caption and case type are visible but no plaintiff or defendants detail was included in that record[3].
What does a correct reconciliation record look like?
The correct next step is not to guess. The reviewer should note that the second matter requires follow-up before any role can be assigned, since the documented response structure means detail can vary between the first result and later results in the same array[3]. Applying the same interpretation from the detailed first result to the thinner second result would be an unsupported assumption. A related editorial discussion on how detail levels vary within a single response makes the same point: a thin record can justify further investigation without establishing a judgment, a current obligation, or misconduct by the applicant[4]. For Borrower A, the reconciliation entry would show: matter one, role confirmed as plaintiff, case type collections, follow-up needed only to confirm the debtor named matches an unrelated third party rather than Borrower A itself; matter two, role undetermined, follow-up required through a document pull or manual docket check before any note is added to the credit file. This reconciliation step, performed before any interpretation, is what separates a defensible file from a reflexive litigation flag.
What Decision Table Helps Sort Plaintiff Hits From Defendant Exposure?
How should a reviewer route each combination of role and status?
A decision table gives underwriting staff a consistent way to route court search hits once party role and case status are known. This table is a proposed internal control, not a Cobalt feature or an automated decision output.
| Party Role | Case Status | Suggested Reviewer Action |
|---|---|---|
| Plaintiff | Open, seeking recovery | Note as collections effort by borrower; confirm entity match; no adverse flag from role alone[1] |
| Defendant | Open, unresolved | Escalate for pleading review; determine claim amount and subject matter before any exposure estimate |
| Defendant | Dismissed with prejudice | Note resolved; claim cannot be renewed; document but do not treat as ongoing exposure[1] |
| Defendant | Dismissed without prejudice | Flag for follow-up since the claim may be re-filed[1] |
| Defendant with counterclaim | Open | Treat as two-sided dispute; record both the original claim and the counterclaim separately before assigning any net position[1] |
| Role undetermined | Any | Do not log a risk conclusion; obtain additional detail through document pull or manual docket check first[3] |
Why does the "role undetermined" row matter most?
The last row is where most avoidable errors happen. A reviewer under time pressure often forces a hit into either the plaintiff or defendant category based on assumption rather than confirmed data. The documented API structure shows that not every result in a response carries the same field detail, so a table row explicitly permitting "undetermined, needs follow-up" keeps staff from inventing a role that the record does not actually support[3]. This table should sit alongside, not replace, a written policy on how far follow-up must go before a file can close.
Why Do Counterclaims Deserve Separate Research Treatment?
What does a counterclaim change about a plaintiff hit?
The objection an underwriter might raise here is straightforward: if the borrower is the plaintiff, the case describes collection, so exclude it from risk consideration. That objection is only partly right. New York's glossary defines a counterclaim as a claim the defendant brings back against the plaintiff within the same action[1]. That means a borrower who appears as plaintiff in a collections case could simultaneously be facing a counterclaim asserting the borrower owes money, breached a contract, or caused damages. A search result that shows only the caption and the plaintiff field, without the pleadings, will not reveal whether a counterclaim exists. Treating every plaintiff hit as automatically favorable skips a step that the source material does not support skipping.
How should a reviewer confirm whether a counterclaim exists?
Counterclaims typically surface in the case documents rather than in a summary caption, and Cobalt's documented response structure includes a documents array with fields like documentName, documentFiledBy, and documentStatus for records that carry that level of detail[3]. Where the response includes those document-level fields, a reviewer can check whether a filing was made by the defendant that might indicate a counterclaim, though the API documentation does not represent that this field will always be populated. Where the response provides only top-level fields, the reviewer has to look elsewhere, whether through direct docket review, a document request from the borrower, or a manual pull, since the plaintiff designation alone does not close the question of whether money is actually owed back. A workable policy treats counterclaim research as a mandatory second step for every plaintiff hit that reaches a certain dollar threshold or case type, rather than an optional deep dive reserved for defendant hits only. This keeps the "borrower is collecting" reading from becoming an automatic pass.
How Do Alternative Verification Paths Compare to an API Lookup?
What can a reviewer check directly through public sources?
Before or alongside any vendor lookup, a reviewer has several direct paths available. New York's Department of State Corporation and Business Entity Search Database covers corporations, limited partnerships, limited liability companies and limited liability partnerships, along with assumed-name filings, so a reviewer can look up an entity named in a case caption and test whether the party in the court record is actually the applicant or a similarly named entity[5]. The Department of State's FAQ page for corporations and business entities describes what the registry search shows for an entity, including its name, date of organization, jurisdiction, registered agent, and current status[6]. The search database page itself cautions that, because the Department relies on information provided to it, completeness and accuracy cannot be guaranteed[5]. A reviewer can also request certified copies of filed documents directly from the Division of Corporations for a fee, which supports deeper verification when a case or entity name is ambiguous[7].
When should a reviewer rely on borrower-submitted documents or internal review instead?
Borrower-submitted documents, such as a settlement agreement, dismissal order, or attorney letter, can resolve a court role question faster than any external search when the borrower is cooperative and forthcoming. Internal review, meaning a compliance or credit analyst reading the actual court docket or pleadings directly on a court's public access system, remains the most complete method when the matter is material to the credit decision, since no summarized API response substitutes for the underlying pleadings. Each of these approaches has a tradeoff: direct registry lookups confirm entity identity but not litigation content; borrower documents are fast but depend on borrower cooperation and honesty; full docket review is thorough but slow and jurisdiction-specific. None of these approaches, alone or combined, produces a credit decision, a sanction determination, or a legal clearance. They produce facts that a lender's own policy then has to weigh.
Where Does a Bounded API Lookup Fit Into This Workflow?
What does Cobalt's court cases endpoint actually return?
Cobalt's Court Cases API accepts a businessName, a jurisdiction limited to newYork or miamiDade (with testNewYork or testMiamiDade available for sample data), and a required callbackUrl, since the endpoint returns results asynchronously to that callback rather than in the initial response[3]. The initial call returns a requestId and a status indicating the completed request will be sent to the callback URL. When results arrive, the documented New York response structure returns an array where the first result carries fields including plaintiff, petitioner, defendants, caseDetails, and a documents array, while subsequent results in the same array may carry only caption, courtCaseType, status, and searchType[3]. The Miami-Dade structure differs, returning fields like caseInfo, caseType, caseStatus, caseFiled, and case numbers, without the same plaintiff and defendant fields shown in the New York example[3].
What should a reviewer document about scope and gaps?
This is a documented scope, not a complete national court coverage claim. The endpoint covers only the two named jurisdictions, and within those jurisdictions the amount of detail returned per case can vary, meaning some fields may arrive empty or absent for a given record. Because the response is asynchronous, a reviewer's workflow needs a step for confirming callback receipt before treating the search as complete, rather than assuming a fast initial response equals a finished lookup. A related editorial piece on repeat defendant detection notes that the customer owns the matching logic, the escalation policy, and the final decision, with Cobalt functioning as a data source rather than a decisioning engine[8]. The same logic applies here: the API returns party fields and case information where available; the lender's own policy decides what those fields mean for the file.
What Belongs on a Reviewer Worksheet Before a File Closes?
What fields should the worksheet capture for every hit?
A usable worksheet keeps the role-reconciliation habit consistent across analysts rather than dependent on individual judgment. Below is an illustrative customer-owned review record format a lender might adapt internally; this is a proposed control pattern, not a Cobalt output.
{
"recordType": "illustrative customer-owned review record",
"applicationId": "application-example-1",
"borrowerLegalName": "Entity B",
"searchedName": "Borrower A",
"jurisdictionSearched": "newYork",
"caseCaption": "example-caption-1",
"partyRoleFound": "plaintiff",
"counterclaimPresent": "unknown, follow-up required",
"caseStatus": "open",
"dismissalType": "not applicable",
"detailLevelReturned": "first-result full detail",
"documentsReviewed": false,
"entityMatchConfirmed": "pending secretary of state check",
"reviewerNotes": "Role recorded as plaintiff per case caption; counterclaim status not yet confirmed; do not log adverse flag until document review complete.",
"nextStep": "pull case documents or request borrower explanation"
}How should the worksheet guide escalation and sign-off?
Each field on the worksheet forces the reviewer to separate what the search returned from what it means. The partyRoleFound field should never be left blank or assumed; if the returned record only carries top-level fields, the worksheet should say so explicitly rather than guessing. The counterclaimPresent field defaults to "unknown, follow-up required" until the reviewer has either read the documents array or pulled the docket directly, consistent with the point that a plaintiff role alone does not close the counterclaim question[1]. Sign-off should require the entityMatchConfirmed field to move from pending to confirmed or rejected, ideally cross-checked against the Department of State's entity database before the case is treated as belonging to the applicant[5]. A workable policy holds that no file closes with a court search noted as "reviewed" while any of these fields remain blank or default.
One more field belongs on the worksheet: which court documents were retained and where they are stored. Pleadings and case papers pulled into a review file can contain personal information about individuals, such as guarantors or individual defendants named alongside the business. The FTC's business guidance on protecting personal information sets out five principles for records like these: know what personal information the business holds, keep only what it needs, protect what it keeps, dispose of what it no longer needs, and plan for a security incident[9]. Recording retained documents on the worksheet gives the lender's records team the inventory that guidance starts from, and it keeps a reviewer from copying a full docket into the file when a caption, index number, and role note would answer the underwriting question.
What contrasting exception shows why role alone is not enough?
Consider a short contrasting exception, again illustrative rather than observed. Entity B, the operating name used by Borrower A, appears as plaintiff in a breach-of-contract action seeking payment from a vendor. On its face, this matches the "collecting, not owing" pattern discussed earlier in this article. But the case documents, where available through the documents array, show a filing labeled as an answer and counterclaim from the vendor, alleging that Entity B failed to deliver goods under the same contract and owes damages exceeding the amount Entity B originally sought[3]. A reviewer who logged this record as "plaintiff, no concern" based on the caption alone would have missed a live counterclaim asserting Entity B owes money, not the reverse.
This exception does not mean every plaintiff case hides a counterclaim, and it should not be generalized that way. It means the plaintiff label describes only who filed first, not the full financial exposure disclosed once pleadings are read. The New York glossary's separation of complaint, counterclaim, and disposition exists precisely because a case can carry claims running in both directions simultaneously[1]. A related discussion on distinguishing DBA names from legal entities makes a parallel point about resisting shortcuts: a defensible workflow keeps the submitted identity, the source record, and the reviewer's normalized conclusion as separate, traceable fields rather than collapsing them into one fast label[10]. The same discipline applies to court role: record what the search returned, record what the documents say when available, and let the underwriting policy, not the caption, decide what the case means for the file.
For a reviewer team that wants to walk through how this reconciliation habit would apply to a specific pending application, bring the actual case caption, jurisdiction, and borrower entity name to a working session through Cobalt's demo page and discuss the concrete scenario directly rather than relying on a generic script.
.jpg){kind=small}
.png)