> ## 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.

# Consumer Checks: Best Practices

> Choose the right checks for each person, send the inputs that improve accuracy, and act on the results.

This guide covers how to select the right checks for your use case, optimize inputs for accuracy, handle edge cases, design efficient workflows, and operationalize person monitoring.

Make sure to review [Consumer Checks: Basics](https://docs.baselayer.com/docs/consumer-checks-basics.md) before reading this guide.

***

## 1. Selecting the Right Checks

Not every workflow requires every check. Selecting the appropriate `options` for your Person Search reduces cost, speeds up results, and keeps your review queues focused on what matters.

***

#### Sanctions & Compliance (required for most regulated products)

* `Order.Ofac` and `Order.Pep` — should be included for virtually all onboarding and underwriting workflows. These are typically non-negotiable for compliance.

***

#### Lending & Credit

* `Order.Liens` — personal liens affect collateral position and indicate financial stress
* `Order.Litigations` — litigation history, directly impacts creditworthiness
* `Order.Bankruptcy` — personal bankruptcy records, clear sign for credit risk
* `Order.TinMatching` — confirms the applicant's identity through IRS records

***

#### Military-Related

* `Order.Scra` — required if your product is subject to SCRA protections (interest rate caps, foreclosure restrictions). Relevant for lending, servicing, and collections. **Requires full 9-digit SSN** — if only last-4 SSN is provided, this check will not run.
* `Order.Mla` — required if your product falls under MLA coverage (payday loans, auto title loans, certain credit cards). Check before finalizing loan terms. **Requires full 9-digit SSN and `date_of_birth`** — if either is missing, this check will not run.

***

#### Common Configurations by Use Case

**Payment processor or marketplace vendor onboarding:** `Order.Ofac`, `Order.Pep`
Sanctions screening for individuals associated with merchant applications. Typically sufficient when combined with a Business Search.

**Business lending (applicant & guarantors):** `Order.Ofac`, `Order.Pep`, `Order.Liens`, `Order.Litigations`, `Order.Bankruptcy`, `Order.TinMatching`
Full coverage for credit risk and identity verification. Run on the applicant, each UBO, and each guarantor.

**Bank account opening:** `Order.Ofac`, `Order.Pep`, `Order.TinMatching`
Identity verification and sanctions compliance. Litigations and liens are typically less relevant when no credit exposure exists.

**Servicing & collections:** `Order.Scra`, `Order.Mla`
Check military status before taking enforcement actions, adjusting rates, or pursuing collections.

***

## 2. Optimizing Inputs

The quality and completeness of your inputs directly affects match confidence and result accuracy.

***

#### SSN: Full vs. Last Four

Baselayer accepts either a full 9-digit SSN or the last 4 digits. Both return the same quality of results — the difference is in **matching confidence**. Full SSN provides a stronger identity match, which reduces the likelihood of false positives in docket and lien results.

**Full SSN is required for `Order.Scra` or `Order.Mla` options.**

**Our recommendation:** Use the full SSN whenever your application flow collects it. Fall back to last-4 only when the full SSN is not available (e.g., early-stage pre-screening before a full application).

***

#### Name Accuracy

Provide the legal name as it appears on official documents. Common issues that reduce match quality:

* Nicknames instead of legal first names (e.g., "Bill" instead of "William")
* Missing middle names or initials — include `middle_name` when available
* Incorrect suffixes — omit rather than guess if uncertain

***

#### Address and Lien Scoping

If you include `address` in your Person Search request, Baselayer uses the state from that address to scope lien searches (when `Order.Liens` is selected). This is an important operational decision:

* **Providing an address** → lien search is scoped to that state, producing more relevant results with less noise
* **Omitting the address** → lien search may cover a broader scope, potentially returning more results but with lower relevance

**Our recommendation:** Always include the individual's address when requesting lien searches. This mirrors the domestic vs. all-state scope decision in Business Search lien configuration.

***

#### Submit Everything You Have

Beyond the required fields, Baselayer accepts: `date_of_birth`, `gender`, `marital_status`, `phone_number`, `email`, `address`, `suffix`, and `title`. These optional fields do not change the quality of the core checks, but they build richer person profiles within Baselayer. Richer profiles enable stronger matching, more complete records, and better monitoring outcomes over time.

**Our recommendation:** Pass every field your application collects. The marginal effort is minimal, and the long-term value in profile completeness is significant.

***

## 3. Designing Your Verification Workflow

#### Parallel Submission with Business Search

The most efficient onboarding pattern is to submit both Business Search and Person Search requests at the same time. As soon as the application data is available:

1. Submit `POST /searches` for the business entity
2. Submit `POST /person_searches` for each individual in the application

Both run concurrently. When each completes, evaluate results independently and combine them into a single onboarding decision.

```python theme={null}
# Pseudocode: parallel submission during onboarding

# Business verification
business_search = POST /searches {
    "name": application.business_name,
    "address": application.business_address,
    "tin": application.ein,
    "options": ["Order.Enhanced"]
}

# Person verification for each individual
FOR EACH person IN [applicant, ubos, guarantors]:
    person_search = POST /person_searches {
        "first_name": person.first_name,
        "last_name": person.last_name,
        "ssn": person.ssn,
        "middle_name": person.middle_name,
        "date_of_birth": person.date_of_birth,
        "address": person.address,
        "phone_number": person.phone_number,
        "email": person.email,
        "options": ["Order.Ofac", "Order.Pep", "Order.Liens",
                     "Order.Litigations", "Order.TinMatching"]
    }
```

> **Tip:** Store both the `business_search_id` and all `person_search_id` values against the application record. You will use these to add items to Portfolio Monitoring after approval.

***

#### When to Use Standalone Endpoints Instead

Standalone endpoints are best suited for specific stages in your workflow:

**Pre-screening:** Run `POST /ofac/searches` before collecting full application data to catch obvious sanctions hits early, avoiding unnecessary data collection from blocked individuals. Both OFAC and PEP standalone endpoints accept a `similarity_threshold` parameter (0.0 to 1.0, default 0.9) — consider lowering it slightly (e.g., 0.8) during pre-screening to cast a wider net, then rely on the Person Search for definitive results.

**Sole proprietor TIN verification:** If you already know the applicant is a sole proprietor, use `POST /tin_verifications` for a fast, cost-efficient IRS check without the overhead of a full Person Search. See the [Sole Proprietorship Verification](https://docs.baselayer.com/docs/sole-prop-verification.md) for more detail.

**Servicing checks:** Use `POST /scra/searches` or `POST /mla/searches` independently when evaluating military status for loan servicing decisions. These are typically run at a different stage than onboarding. Both require full 9-digit SSN, and MLA additionally requires `birth_date`.

***

## 4. Evaluating Results

#### Watchlist Hits (OFAC & PEP)

Any positive watchlist hit should be treated as a high-priority review item. However, not every hit is a true match — false positives occur, especially with common names.

**Recommended evaluation logic:**

```python theme={null}
# Evaluate watchlist hits from person search response
person = response.get("person", {})
watchlist_hits = person.get("watchlist_hits", [])

FOR EACH hit IN watchlist_hits WHERE hit.count > 0:
    IF hit.code == "OFAC":
        flag = "RED"
        reason = "OFAC match detected"

    IF hit.code == "PEP":
        # Review the matched records in hit.details
        flag = "YELLOW"
        reason = "Potential PEP match - manual review required"

IF no watchlist_hits with count > 0:
    flag = "PASS"
```

> **Note:** OFAC hits should always trigger review or rejection per your compliance policy. PEP status is not inherently disqualifying but requires enhanced due diligence.

***

#### Dockets (Litigations & Bankruptcy)

Use the `risk_level` and `match_level` fields to triage docket results:

```python theme={null}
# Evaluate docket results
dockets = person.get("dockets", [])
medium_risk_count = 0

FOR EACH docket IN dockets:
    IF docket.risk_level == "high" AND docket.match_level == "EXACT":
        flag = "RED"
        reason = "High-risk litigation or bankruptcy with exact match"

    IF docket.risk_level == "medium":
        medium_risk_count += 1

IF medium_risk_count > 2:
    flag = "YELLOW"
    reason = "Multiple medium-risk litigation cases"
```

> **Note:** This logic provides basic docket risk assessment. Tailor thresholds to your product's risk appetite — lending products typically require stricter scrutiny than payment processing.

***

#### Liens

Active personal liens indicate financial stress and may affect your collateral position:

```python theme={null}
# Evaluate lien results
liens = person.get("liens", [])
active_liens = [l for l in liens if l.status == "Active"]

IF any active_liens with filing_type starting with "tax.":
    flag = "YELLOW"
    reason = "Active personal tax lien"

IF len(active_liens) > 3:
    flag = "RED"
    reason = "Multiple active personal liens"
```

***

#### TIN Matching

TIN verification confirms the individual's identity through IRS records. The response includes `tin_matched` (boolean), mirroring the same TIN verification behavior available in the Business Search.

```python theme={null}
# TIN result is at the search level (not inside person object)
tin_matched = response.get("tin_matched")

IF tin_matched is True:
    # Identity confirmed with IRS
    PASS

IF tin_matched is False:
    flag = "RED"
    reason = "SSN does not match name per IRS records"

IF tin_matched is None:
    # IRS may be temporarily unavailable
    # Check warnings for "IRS Validation is unavailable."
    # Baselayer will auto-retry; listen for PersonSearch.updated webhook
    flag = "PENDING"
    reason = "IRS validation pending — outage detected"
```

***

## 5. Monitoring Individuals

#### Who to Monitor

Not every individual verified at onboarding needs ongoing monitoring. Focus monitoring resources on individuals where a change in their status would directly impact your risk exposure:

**Always monitor:**

* Guarantors on active loans — new liens or litigations affect your recovery position
* UBOs of high-risk businesses — sanctions or PEP changes require immediate action
* Sole proprietors — where the individual and business risk are inseparable

**Monitor selectively:**

* Applicants on standard-risk products — monthly monitoring is typically sufficient
* Authorized signers — only if they have significant decision-making authority

**Skip monitoring for:**

* Individuals on closed or fully repaid accounts
* Low-risk, passive investors with no operational role

***

#### Recommended Monitoring Configuration

For individuals added to Portfolio Monitoring, configure your monitoring policy based on risk:

**High-risk individuals (e.g., guarantors on large exposures, flagged UBOs):**

* Monitoring frequency: weekly
* Monitor for: OFAC, PEP, liens, litigations
* Notification frequency: daily for sanctions, weekly for liens/litigations

**Standard-risk individuals (e.g., primary applicants on approved accounts):**

* Monitoring frequency: monthly
* Monitor for: OFAC, PEP, litigations
* Notification frequency: weekly

**Compliance-only (e.g., marketplace vendor principals):**

* Monitoring frequency: monthly
* Monitor for: OFAC, PEP
* Notification frequency: monthly

***

#### Organizing Individuals in Portfolio Groups

Use portfolio groups to separate individuals by role, risk tier, or product:

* **Guarantors** — weekly monitoring, full attribute coverage
* **UBOs** — monthly monitoring, sanctions-focused
* **Sole Proprietors** — monthly monitoring, same configuration as associated business

This structure ensures that monitoring resources are allocated proportionally to risk exposure.

For comprehensive guidance on portfolio groups, policies, and notifications, see [Portfolio Monitoring: Best Practices](https://docs.baselayer.com/docs/portfolio-monitoring-best-practices.md).

***

## 6. IRS Outage Handling

TIN verification for individuals follows the same IRS outage pattern as business TIN verification. When the IRS service is temporarily unavailable:

* `tin_matched` will return `null`
* `warnings` will include `"IRS Validation is unavailable."`
* Baselayer will automatically retry every 15 minutes for up to about 24 hours
* Once the IRS service is restored, a `PersonSearch.updated` webhook is sent with the final TIN result

**Recommended approach during outages:**

* Process the Person Search normally for all non-TIN checks
* Flag the TIN result as pending in your system
* Listen for the updated webhook to finalize the TIN decision
* If your policy requires TIN confirmation before approval, issue a conditional approval or hold the decision until the result arrives

For more detail on IRS outage handling, see the [Guide: IRS Outage Handling](https://docs.baselayer.com/docs/webhook-guide-businesssearchupdated.md).

***

## 7. Implementation Checklist

**Setup**

* [ ] API key configured for person search endpoints
* [ ] Webhook endpoint configured for `PersonSearch.submitted`, `PersonSearch.completed`, `PersonSearch.failed`, `PersonSearch.updated`
* [ ] Internal mapping between application records and person search IDs

**Onboarding Integration**

* [ ] Person Searches submitted in parallel with Business Searches during onboarding
* [ ] Options configured per product and risk policy
* [ ] Watchlist hit evaluation logic implemented
* [ ] Docket and lien evaluation logic implemented (if applicable)
* [ ] TIN matching evaluation logic implemented (if applicable)
* [ ] IRS outage handling implemented

**Portfolio Monitoring**

* [ ] Approved individuals added to portfolio via `POST /portfolio/items` with `person_search_id`
* [ ] Portfolio groups created for individuals (e.g., Guarantors, UBOs, Sole Props)
* [ ] Monitoring policies configured per group
* [ ] Notification subscriptions configured for individual-level changes

For questions about implementation, contact your Baselayer account representative.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.