Skip to main content
This guide covers how to get the most out of Baselayer Docket Search: how to prioritize results, classify risk, use match levels correctly, and build litigation signals into automated and manual decisioning workflows. Make sure to review Litigation & Bankruptcy Search: Basics and complete the Litigation & Bankruptcy Search: API Quickstart before reading this guide.

​
1. Always Prioritize Bankruptcy

Any docket where is_bankruptcy == true is a critical event and should be the first thing evaluated in any workflow, regardless of ticket size. A recent bankruptcy indicates insolvency, court-supervised restructuring or liquidation, and restrictions on extending new credit. Practical threshold: Flag any bankruptcy where date_filed is within the last 5–7 years. Older bankruptcies are still worth surfacing to the underwriter as context, but carry lower immediate risk. Bankruptcy types and their risk weight:

​
2. Using risk_level for Prioritization

Baselayer’s risk_level field combines case type, age, status, match level, and court metadata into a single signal. It is the recommended starting point for building decisioning logic. How to use risk_level:
  • high → always escalate to manual review, regardless of ticket size or automation level. This category captures bankruptcy proceedings.
  • medium → include in the underwriting file; escalate only when aligned with your internal must-review case types, or when other risk signals are present in the file.
  • low and no_risk → informational. Include for completeness in large-ticket underwriting; not actionable on their own.
Closed cases (normalized_status = closed) are categorized as no_risk by Baselayer, regardless of original case type. They can still provide useful historical context. Building on top of risk_level: risk_level is a strong default that works out of the box. For more tailored workflows, customers can layer their own case type classifications on top. For example, always routing case_type values like Fraud or Regulatory Violation to review regardless of Baselayer’s categorization.

​
3. Understanding and Applying match_level

Because most US court systems do not provide reliable business identifiers (EINs, registration numbers), docket searches rely on name matching. match_level tells you how closely a docket’s case title matched the entity name you searched. match_level is deprecated. Use match_confidence, which returns a confidence level plus name_match, address_match and date_match signals. Default approach: use EXACT matches only EXACT matches provide high confidence that a case refers to an entity with the exact same name as the business under review. For automated decisioning and high-velocity workflows, rely only on EXACT matches to minimize false positives. When to include SIMILAR matches Court records across the US are not standardized, and naming accuracy varies significantly by jurisdiction. A case that genuinely belongs to your subject business may appear as a SIMILAR match because the court omitted a legal suffix (LLC, Inc, Corp), abbreviated the name, recorded only part of it, or used a slightly different form than the official registered name. Counsel errors and filing inconsistencies are also common. Including SIMILAR matches helps capture these cases and reduces the risk of missing material litigation. The tradeoff is that it may also surface filings from unrelated businesses with similar names - so SIMILAR results should be treated with more scrutiny than EXACT ones, and are best reviewed manually rather than used in automated decisioning. Including SIMILAR results is most appropriate when:
  • Thoroughness is the priority (large-ticket or long-duration products)
  • The business operates under multiple names, uses a DBA, or has a common name
  • Your workflow already routes medium and high-risk cases to manual review
Match level strategy by workflow type:

​
4. Evaluating Case Type and Recency

case_type is provided directly by the court and is not standardized across jurisdictions. Treat it as a useful signal, not a strict taxonomy. Build an internal “must-review” list Define which case types your program always routes to manual review, regardless of risk_level. Common entries:
  • Bankruptcies (always)
  • Evictions
  • Class actions
  • Fraud or misrepresentation
  • Regulatory or compliance violations
  • Significant financial disputes
Remove low-relevance case types from operational workflows Trademarks, service marks, and patent application history (risk_level = no_risk) are typically informational and can be filtered out of review queues to reduce noise, while still being retained in the underwriting record. Recency matters An open case filed two years ago is materially more concerning than a closed case filed ten years ago. As a practical threshold:
  • Cases with date_filed within the last 5 years and normalized_status = open are the most material
  • Cases older than 5 years, or with normalized_status = closed, provide historical context but should not drive escalation on their own

​
5. Recognizing Patterns

Individual dockets should be evaluated in context. Multiple cases - especially of the same type - often reveal structural issues that a single case would not. Patterns that warrant closer review:
  • Multiple payment or contract disputes: repeated non-payment behavior with vendors, customers, or lenders
  • Multiple lender cases: suggests a pattern of defaults or financing disputes
  • Recurring employment or contractor claims: potential HR, compliance, or workforce management issues
  • Multiple evictions: common in commercial real estate but signals payment stress
  • Cases across multiple jurisdictions: indicates the business has legal exposure in more than one operating area
A cluster of similar cases filed within a short timeframe is a stronger signal than any individual case alone.

​
6. Using additional_search_entities for Officers and Guarantors

The BusinessSearch request variant supports additional_search_entities, allowing you to search for officers, guarantors, or alternate business names alongside the primary business in a single API call.
When to include individuals:
  • Personal guarantors: litigation and bankruptcy history of a guarantor affects the value of the guarantee
  • Sole proprietors and single-member LLCs: personal legal history is directly relevant to business risk
  • Beneficial owners: for higher-risk programs or regulated financial institutions
For a full walkthrough of individual docket searches, see Litigation & Bankruptcy Search for Individuals.

​
7. Baselayer’s Recommendation

Match level strategy typically depends on operational priorities: If minimizing noise is the priority:
  • High velocity of operations / automation focus
  • Small to medium-sized loan tickets
  • Concerns about false positives
→ use EXACT only If thoroughness is the priority:
  • Deep due diligence and underwriting
  • Medium to large-sized loan tickets
  • “Can’t miss anything” mindset
→ use EXACT + SIMILAR

​
Small-ticket or high-velocity products

Reserve manual review for the highest-confidence signals only. Recommended approach:
  • Flag all risk_level = high dockets with match_level = EXACT for review
  • Display all other dockets as a non-blocking informational flag (“Dockets present”)
  • Optionally surface risk_level = medium for specific case types you always want reviewed

​
Large-ticket or long-duration products

Full visibility is appropriate given the exposure. Recommended approach:
  • Include all dockets (EXACT + SIMILAR) in the underwriting file
  • Highlight all risk_level = high cases explicitly for the underwriter
  • Include medium and low-risk cases as background context
  • Flag patterns of repeated case types for underwriter attention

​
8. When to Request Case Details

Case details - the full chronological timeline of filings, hearings, and court orders - are available on request but not needed for most workflows. Request details when:
  • A high-risk case warrants deeper review (e.g., an open bankruptcy or major financial dispute)
  • The outcome of a specific case is material to the credit decision (e.g., a large judgment)
  • There are suspicious patterns in the docket metadata that require timeline context
  • Large-ticket underwriting requires documentary evidence
How to request: Use PUT /dockets/{docket_id}/details, then retrieve via GET /dockets/{docket_id}/details. See Litigation & Bankruptcy Search: API Quickstart for the full flow.

​
9. Where to Go Next