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

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.

# Pseudocode: parallel submission during onboarding

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

# 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 Proprietors Guide 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:
    IF hit.list == "OFAC":
        flag = "RED"
        reason = "OFAC match detected"

    IF hit.list == "PEP":
        IF hit.match_score >= 0.85:
            flag = "RED"
            reason = "High-confidence PEP match"
        ELSE:
            flag = "YELLOW"
            reason = "Potential PEP match — manual review required"

IF no watchlist_hits:
    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 type == "TAX_LIEN":
    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) and tin_match_type (SSN, EIN, UNKNOWN, or null), mirroring the same TIN verification behavior available in the Business Search. For Person Searches, tin_match_type will typically return SSN; a value of EIN may appear when the individual operates as a sole proprietor using an EIN.

# TIN result is at the search level (not inside person object)
tin_matched = response.get("tin_matched")
tin_match_type = response.get("tin_match_type")

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.completed 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 at increasing intervals
• Once the IRS service is restored, a PersonSearch.completed webhook will be re-emitted 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 TIN Check Retry Guide.

7. Implementation Checklist

Setup

• API key configured for person search endpoints
• Webhook endpoint configured for PersonSearch.submitted, PersonSearch.completed, PersonSearch.failed
• 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.