Skip to main content

​
Verifying the People Behind the Business

​
Why Consumer Checks Matter in KYB

Business verification confirms that a company is real, registered, and operating as expected. But every business is ultimately run by people — and understanding those individuals is a critical layer of any complete onboarding or underwriting workflow. Whether you need to screen a guarantor against sanctions lists, verify the SSN of a sole proprietor, check an applicant’s litigation history, or confirm a UBO is not a Politically Exposed Person, Baselayer’s consumer check tools let you perform these verifications within the same platform you use for KYB.

​
Two Approaches to Consumer Verification

Baselayer offers two paths for verifying individuals, depending on the depth and structure your workflow requires.

​
1. Person Search (comprehensive, structured)

The Person Search creates a persistent person record in Baselayer and runs one or more checks against it. This is the recommended approach when you need to verify the same individual across multiple dimensions (e.g., sanctions, liens, and litigations together) or when you intend to monitor that person over time via Portfolio Monitoring. A Person Search requires a name and SSN as inputs, and an options array that specifies which checks to run. The response returns a structured person object containing all results — dockets, liens, watchlist hits, etc. — in a single payload. Required fields:
  • first_name → legal first name
  • last_name → legal last name
  • ssn → full 9-digit SSN or last 4 digits
  • options → at least one check from the list below
Optional fields:
  • middle_name → middle name or initial
  • suffix → e.g., “Jr.”, “Sr.”
  • title → e.g., “Mr.”, “Mrs.”
  • date_of_birth → date of birth (required for MLA checks)
  • gender → M or F
  • marital_status → e.g., married, single, divorced
  • address → the individual’s address; the state will be used to scope lien searches if Order.Liens is selected
  • phone_number → E.164 format (e.g., “+14013059855”)
  • email → email address
Recommendation: Submit as much information as available on the individual. Optional fields do not affect the core check quality, but they build richer person profiles within Baselayer — enabling stronger matching, more complete records, and better monitoring over time.
Available options:
  • Order.Ofac → OFAC sanctions screening
  • Order.Pep → Politically Exposed Persons screening
  • Order.TinMatching → IRS TIN verification for the individual’s SSN
  • Order.Liens → Personal lien filings
  • Order.Litigations → Personal litigation and docket records
  • Order.Bankruptcy → Personal bankruptcy records
  • Order.Scra → Servicemembers Civil Relief Act status (requires full 9-digit SSN)
  • Order.Mla → Military Lending Act coverage status (requires full 9-digit SSN and date_of_birth)
Note: If the required inputs for Order.Scra or Order.Mla are not included in the Person Search request, those checks will not run.
Baselayer Endpoints:
Complete API details: Create Person Search

​
2. Standalone Endpoints (lightweight, targeted)

For cases where you need a single, specific check without creating a full person record, Baselayer offers independent verification endpoints. These are useful when you want to run a quick screening before committing to a full Person Search, or when your workflow only requires one type of check. TIN Verification Verify an individual’s SSN against IRS records by name. Useful for sole proprietor verification or confirming the identity of a guarantor or UBO.
Note: An error will be raised if the IRS validation service is experiencing an outage. Check status.baselayer.com for service updates, and our Guide: IRS Outage Handling for complete details.
Complete API details: Submit TIN Verification OFAC Screening Search for matches on the OFAC Specially Designated Nationals list by name.
Complete API details: Search OFAC PEP Screening Search for Politically Exposed Persons matches by name.
Complete API details: Search PEP SCRA Status Check whether an individual is covered under the Servicemembers Civil Relief Act, which affects loan terms and enforcement actions.
Complete API details: SCRA Search MLA Coverage Check whether an individual is a covered borrower under the Military Lending Act.
Complete API details: MLA Search

​
When to Use Each Approach

Use Person Search when:
  • You need to run multiple checks on the same individual
  • You want a persistent person record for audit and retrieval
  • You plan to monitor the individual over time via Portfolio Monitoring
  • You are verifying applicants, UBOs, or guarantors as part of a structured onboarding flow
Use standalone endpoints when:
  • You only need one specific check (e.g., OFAC-only screening)
  • You want a lightweight pre-screening before a full Person Search
  • You are building a workflow where checks are triggered independently at different stages
  • Cost efficiency matters and you don’t need the full Person Search record

​
Integrating Consumer Checks into Business Onboarding

The most common pattern for using consumer checks is alongside the business verification process. As you submit a Business Search during onboarding, you should also submit a Person Search for each individual included in the application. Typical individuals to verify:
  • The person applying — the primary contact or business owner submitting the application
  • Ultimate Beneficial Owners (UBOs) — individuals who own or control 25% or more of the business
  • Guarantors — personal guarantors on a loan or credit facility
  • Authorized signers — individuals with signatory authority on business accounts
This parallel approach ensures that both the business entity and the people behind it are verified in a single onboarding workflow, reducing time-to-decision and eliminating the need for separate verification steps later.

​
Person Search: Understanding the Response

The Person Search response contains two distinct layers of information: the search envelope (status, IDs, TIN results) and the person object (the individual’s profile and all check results).

​
Search-Level Fields

These fields sit at the top level of the response and describe the search itself:
  • id → the person search id. This is the identifier you will use to poll for status, retrieve results, and add the individual to Portfolio Monitoring. Persist this value alongside your application record.
  • state → tracks the lifecycle of the search: PENDING → EXECUTING → COMPLETED or FAILED (a request can also end as CANCELLED)
  • error → populated if the search could not be completed
  • warnings → informational messages (e.g., "IRS Validation is unavailable." during an IRS outage)

​
TIN Matching (if Order.TinMatching was requested)

When TIN matching is included in the search options, the response includes:
  • tin_matched: true / false / null
    IRS confirmation that the SSN is valid and belongs to the input name. null may indicate an IRS outage (see IRS outage handling below).
These fields mirror the same TIN verification behavior available in the Business Search. For more detail on IRS outage handling, see the Guide: IRS Outage Handling.

​
The Person Object

The person object contains the individual’s profile and the results of all requested checks:

​
Identity & Profile

  • person.id → the unique identifier of the person record itself. This persists across multiple searches for the same individual.
  • first_name, last_name, ssn (masked to the last four digits) → core identity fields
  • middle_name, suffix, title, date_of_birth, gender, marital_status → additional profile details, populated when provided in the request
  • phone_number, email → contact information stored with the person record
Our recommendation: Submit as much information as available on the individual — including phone number, email, date of birth, gender, and address. These fields build richer person profiles within Baselayer, enabling stronger matching and more complete records over time.

​
Watchlist Hits (if Order.Ofac or Order.Pep was requested)

The watchlist_hits array contains matches against OFAC and PEP lists. Any positive match should be treated as a high-priority review item. For more detail on evaluating watchlist hits, see the Watchlists & Sanctions: Business Search guide — the same evaluation principles apply to both business and individual hits.

​
Dockets (if Order.Litigations was requested)

The dockets array contains litigation and bankruptcy records associated with the individual. Each docket includes risk_level and match_confidence to help assess severity and relevance. For more detail on interpreting docket results, see Litigation & Bankruptcy Search: Best Practices.

​
Liens (if Order.Liens was requested)

The liens array contains personal lien filings, including tax liens, judgment liens, and UCC filings tied to the individual.
Note: If you include address in your Person Search request, the state from that address will be used to scope the lien search. This is important for controlling lien search coverage and relevance.
For more detail on lien interpretation and filing strategies, see Lien Search: Best Practices.

​
Monitoring Individuals with Portfolio Monitoring

Portfolio Monitoring is not limited to businesses. You can also add individuals to your monitored portfolio using a completed Person Search, enabling ongoing surveillance of the people behind the businesses you serve.

​
How It Works

When creating a Portfolio Item, you can pass a person_search_id instead of a business_search_id. This creates a portfolio item linked to an individual, which Baselayer will monitor on the same frequency and policy structure used for business items.
This is particularly valuable for:
  • Sole proprietors — where the individual and the business are effectively the same entity
  • Guarantors on active loans — monitoring for new liens, litigations, or sanctions that affect credit exposure
  • High-risk UBOs — ongoing surveillance of individuals flagged during onboarding
The monitoring follows the same inheritance model as business monitoring: Portfolio → Group → Item. You can organize individuals into dedicated groups (e.g., “Guarantors” or “High-Risk UBOs”) with their own monitoring policies and notification subscriptions. For comprehensive guidance on portfolio monitoring configuration, see Portfolio Monitoring: Basics.

​
Console vs. API

Currently, consumer check functionality in the Baselayer Console is limited. Most person verification actions — including creating Person Searches, running standalone checks, and adding individuals to Portfolio Monitoring — are handled via the API. The API provides full access to all consumer check capabilities. All actions available in the console are also available via the API. Baselayer’s complete API documentation can be found at docs.baselayer.com.