> ## Documentation Index > Fetch the complete documentation index at: https://docs.baselayer.com/llms.txt > Use this file to discover all available pages before exploring further. # Litigation & Bankruptcy Search: Best Practices > Decide which court records matter, rank them by risk, and build them into your approval rules. 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](https://docs.baselayer.com/docs/litigation-bankruptcy-search-basics.md) and complete the [Litigation & Bankruptcy Search: API Quickstart](https://docs.baselayer.com/docs/litigation-bankruptcy-search-api-quickstart.md) 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:** | Type | Signal | | - | - | | Chapter 7 (Liquidation) | Business ceased operations and liquidated assets - highest severity | | Chapter 11 (Reorganization) | Business restructuring under court supervision - active cases are high risk; emerged cases require review | | Chapter 13 (Individual) | Personal debt repayment plan - relevant for sole proprietors and guarantors | *** ## 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:** | Workflow | Recommended approach | | - | - | | Automated, high-velocity, small-ticket | EXACT only | | Semi-automated with manual review for high-risk | EXACT for automated; optionally add SIMILAR | | Full manual underwriting, large-ticket | EXACT + SIMILAR | *** ## 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. ```json theme={null} { "business_search_id": "1504f313-9721-4006-b813-82faf6c6f02d", "additional_search_entities": [ { "name": "Jane Smith", "type": "Person" } ] } ``` **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](https://docs.baselayer.com/docs/litigation-bankruptcy-search-for-individuals.md). *** ## 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](https://docs.baselayer.com/docs/litigation-bankruptcy-search-api-quickstart.md) for the full flow. *** ## 9. Where to Go Next * **[Litigation & Bankruptcy Search: API Quickstart](https://docs.baselayer.com/docs/litigation-bankruptcy-search-api-quickstart.md)** — Step-by-step implementation with full code examples * **[Litigation & Bankruptcy Search for Individuals](https://docs.baselayer.com/docs/litigation-bankruptcy-search-for-individuals.md)** — Searching litigation for sole proprietors, guarantors, and beneficial owners * **[Litigation & Bankruptcy Search: Basics](https://docs.baselayer.com/docs/litigation-bankruptcy-search-basics.md)** — Full response field reference * **[Litigation and Bankruptcy Records](https://docs.baselayer.com/docs/litigation-and-bankruptcy-records.md)** — Background on court types, bankruptcy chapters, and key terminology This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.