Consumer Checks: Best Practices

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

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:

Submit POST /searches for the business entity
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.

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

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

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

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

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

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.

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.

KEY CONCEPTS

PLAYBOOKS

PRODUCT GUIDES

Consumer Checks: Best Practices

1. Selecting the Right Checks

Sanctions & Compliance (required for most regulated products)

Lending & Credit

Common Configurations by Use Case

2. Optimizing Inputs

SSN: Full vs. Last Four

Name Accuracy

Address and Lien Scoping

Submit Everything You Have

3. Designing Your Verification Workflow

Parallel Submission with Business Search

When to Use Standalone Endpoints Instead

4. Evaluating Results

Watchlist Hits (OFAC & PEP)

Dockets (Litigations & Bankruptcy)

Liens

TIN Matching

5. Monitoring Individuals

Who to Monitor

Recommended Monitoring Configuration

Organizing Individuals in Portfolio Groups

6. IRS Outage Handling

7. Implementation Checklist

​1. Selecting the Right Checks

​Sanctions & Compliance (required for most regulated products)

​Lending & Credit

​Military-Related

​Common Configurations by Use Case

​2. Optimizing Inputs

​SSN: Full vs. Last Four

​Name Accuracy

​Address and Lien Scoping

​Submit Everything You Have

​3. Designing Your Verification Workflow

​Parallel Submission with Business Search

​When to Use Standalone Endpoints Instead

​4. Evaluating Results

​Watchlist Hits (OFAC & PEP)

​Dockets (Litigations & Bankruptcy)

​Liens

​TIN Matching

​5. Monitoring Individuals

​Who to Monitor

​Recommended Monitoring Configuration

​Organizing Individuals in Portfolio Groups

​6. IRS Outage Handling

​7. Implementation Checklist

1. Selecting the Right Checks

Sanctions & Compliance (required for most regulated products)

Lending & Credit

Military-Related

Common Configurations by Use Case

2. Optimizing Inputs

SSN: Full vs. Last Four

Name Accuracy

Address and Lien Scoping

Submit Everything You Have

3. Designing Your Verification Workflow

Parallel Submission with Business Search

When to Use Standalone Endpoints Instead

4. Evaluating Results

Watchlist Hits (OFAC & PEP)

Dockets (Litigations & Bankruptcy)

Liens

TIN Matching

5. Monitoring Individuals

Who to Monitor

Recommended Monitoring Configuration

Organizing Individuals in Portfolio Groups

6. IRS Outage Handling

7. Implementation Checklist