Introduction: Inputs & their impact

For an overview of what Business Search does and when to use it, see Business Search: Basics. This guide focuses on practical implementation strategies and decision logic.

Your inputs determine how strong your match will be. The more complete the information you send - especially name, address, and optional fields like TIN or website - the richer and more reliable your results become. This section helps you understand which inputs matter most and how they influence what Baselayer returns.

Minimum to run a high-quality search

name → legal name of the business
address → legal address of the business

These two are the only required fields.
The address field requires only the US state at a minimum. The more accurate the address, the more accurate the results will be.

Optional inputs (don’t change match quality, but unlock additional checks)

tin → EIN associated to the application, enables live IRS verification and tin_matched outcomes
website → enables website consistency checks such as business_website_match
officer_names → unlocks officer match signals such as business_officer_match
phone_number → stored for context/comparison
email → stored for context/comparison
reference_id → optional string you can use to associate this request with an internal ID or case in your system
options → request Website Analysis, Industry Prediction and/or Enhanced Search as add-ons
These enrich verification depth; they don’t impact the core entity match

Orderables you can request at search time

Order.WebsiteAnalysis → domain age/registrar, deliverability, parked status, contacts/social links found on the website, etc.
Order.NaicsPrediction → NAICS/MCC/SIC prediction; for best accuracy, request together with Website Analysis.
Order.EnhancedSearch → launches WebsiteAnalysis, NAICSPrediction, discovers social media profiles and online reviews, and uncovers addresses and officers found online for increased match rates.

More information on orderables can be found in the guide Web Presence & Orderables Guide.

Best practices for business verification

Match strictness to product: Minimize friction while ensuring the checks that matter for your risk, channel, and ticket size.
Balance match requirements: Requiring EXACT matches everywhere drives avoidable manual reviews - allow SIMILAR name with EXACT address, or EXACT name with looser address, depending on your appetite.
Monitor performance: Track outcomes and tune thresholds over time.
Persist the IDs: On Completed searches you’ll receive the full response (via webhook or API polling). Persist the search and business_id, they anchor follow-ups and analyst review flows.

KYB Check Recommendation (balanced rules to ship today)

There isn’t just one “right” way to use Baselayer data. Here you’ll find two proven approaches: a quick-start option using our built-in KYB and Risk ratings, and a more granular rules-based method that offers greater control. You can adopt one or blend both depending on your product, risk appetite, and decisioning workflow.

Why pick each option?

Ratings-first: simpler, straightforward for quick integration.
Standard rules: granularity, tunable by product/performance, and yields more explanatory flags for analysts.

The workflows explained in this section are standard recommendations and best practices that other Baselayer customers have implemented. The exact workflow and decisioning should be adjusted to each product and customer base to optimize its performance.

1. Ratings-first (simplest)

Use Baselayer’s KYB and Risk ratings as primary gates.

Decision: If either rating is C or F → Manual Review; otherwise continue (and apply your own minimal gates like “no watchlist hits” outside of the ratings).

Pros: Simpler, very fast to integrate, clear ops triage.

Cons: Less granular; you’ll know that it failed, less why.

Where to learn more: See the dedicated Scores/ Ratings Guide.

2. Standard rules (balanced granularity)

Approve when all are true:

Name + Address:
- EXACT business_name_match with EXACT/CITY/STATE business_address_match or
- SIMILAR business_name_match with EXACT business_address_match
TIN: tin_matched = true (see IRS outage handling below)
Registrations: status = active for the domestic registration; if operating out-of-state, an active foreign registration in that operating state.
Watchlists: No positive hits at search-level or business-level.

Optional product-specific flags

Business age: months_in_business ≥ 12 months (requirement commonly used in lending)
Prohibited structures: business.structure = NONPROFIT → reject (tailor to your risk policy)

IRS outage handling

During IRS outages, you'll see tin_matched = null with a warning in the response. Baselayer automatically retries IRS validation and emits a BusinessSearch.Updated webhook when validation completes.

Recommended strategies during outages:

Pause applications until IRS is operational
Issue conditional approval and freeze account if TIN fails post-validation
Skip TIN requirement temporarily (only if your risk policy allows)

For detailed implementation guidance including webhook handling and retry logic, see Handling IRS Outages.

Search Attributes (the first fields to review)

The search response is your first line of insight into the match quality. It tells you how well the information you submitted matched Baselayer’s records - covering name, address, TIN, officers, and watchlists. This section explains which of these top-level attributes to review first and how to interpret them at a glance.

Below you can find some of the most relevant signals in the search response:

tin_matched: true / false / null
IRS confirmation that the TIN is valid and belongs to the input business name. null may indicate IRS outage (see above).
business_name_match: EXACT / SIMILAR / NO_MATCH
How close the input name is to the matched entity's legal name.
business_address_match: EXACT / CITY / STATE / NO_MATCH
Closeness of the input address to known addresses.
business_officer_match: EXACT / SIMILAR / NO MATCH(only populated if officer names were provided)_
Alignment between submitted officers and Baselayer's identified officers.
business_website_match: true / false / null (only populated if website was provided)
Whether the submitted website matched the website identified by Baselayer.
watchlist_hits: arrays with counts for matches of the search inputs with official sanctions lists. Treat any positive count as a hard stop or manual review trigger.

Scores

Every business search will return the array scores containing a list of scores (0-100) and ratings (A/B/C/F) that summarize different aspects of the business search. Two scores and ratings are currently being returned:

KYB rating (type = kyb): evaluates the quality of the business verification search and initial company assessment.
Risk rating (type = risk): identifies potential financial risk factors common in lending and payment processing evaluations.

A large number of Baselayer customers rely on the KYB and Risk ratings to make KYB and onboarding decisions every day.

Where to learn more: See the dedicated Scores/ Ratings Guide.

Orderables

If options were requested as part of the business search, the response will include orderables items with IDs/URLs to fetch full Website Analysis / Industry Prediction results.

For more information please read the Web Presence & Orderables Guide.

Business Attributes (understanding the core business profile)

The business object is the center of your response. It’s Baselayer’s structured representation of the entity we matched your search to, including identifiers, contact details, registrations, and addresses. This section helps you understand how to read the business summary, what information to store, and which fields tend to be most reliable for follow-up checks.

When a search successfully matches to a record, Baselayer returns a business object inside the search response. It serves as your single, authoritative snapshot of that entity.

id and business_url: unique identifiers of the business profile, persist for future pulls and quick analyst reviews.
name: the official name as filed with the domestic Secretary of State.
structure: the legal entity type (e.g., LLC, C_CORPORATION, NONPROFIT, TRUST, etc.). This field is often used early in decisioning to block or reroute certain structures for a given product or flow.
months_in_business: the number of months since incorporation. Many customers apply thresholds here (e.g., six months minimum for moderate-risk products).
registrations\[]: all SoS registrations (domestic & foreign) including status, key dates/IDs, and officers (more below).
addresses\[]: all known addresses with USPS-based signals (more below).
watchlist_hits[]: Baselayer’s list of potential sanctions matches associated with the business record itself (distinct from hits tied to your input data in the search). Treat any positive hit here as a high-priority review item.

Best practices

Use the domestic registration (incorporation state) as identity ground truth, and leverage foreign registrations to understand footprint and scale of the business.

Store the id of the business object (called business_id throughout the documentation) and associate it internally to the unique identifier of that business in your systems. This will be critical to retrieve additional information of the business later, or streamline lien/docket requests - which require the business_id as the only input for the API request.

Remember there are two places where watchlist hits can appear: one tied to the search inputs (data you submitted) and one tied to the business record itself (data collected by Baselayer). Both must be clear for an automated pass.

Address Attributes (spotting location risk signals)

Addresses reveal more than location, they often signal legitimacy or risk. Baselayer includes every address connected to a business, each with USPS-based attributes like RDI, CMRA, and deliverability. This section shows how to spot inconsistencies, identify mail-forwarding or virtual offices, and decide which addresses matter most for your use case.

Each entry in the addresses[] array provides detailed metadata about a single location tied to the business.

You’ll typically find:

id: Baselayer’s unique identifier for the address.
street, city, state, zip: normalized address fields.
latitude, longitude: geolocation coordinates for mapping or distance checks.
rdi: Residential Delivery Indicator, showing whether USPS classifies the address as Residential or Commercial.
deliverable: boolean indicating if mail can be successfully delivered to the address. If deliverable = false, usually means that USPS considers this address as vacant.
cmra: boolean identifying whether the address is a Commercial Mail Receiving Agency (e.g., UPS Store, virtual office, or shared mailbox). Some of Baselayer customers require a non-CMRA address to approve an application.
delivery_type: enum representing USPS delivery point types. Used to classify how mail is delivered:
FIRM, GENERAL_DELIVERY, HIGH_RISE, POST_OFFICE, RURAL_ROUTE, STREET. This can be useful for detecting unusual delivery setups (e.g., businesses listing a Post Office or General Delivery address).
url: Baselayer API link to the full address resource, where extended details (such as associated registered agents) can be retrieved.
associated_registered_agents[]: list of registered agents historically linked to the address. This attribute is the only one not included directly in the search due to its possible size.

Best practices

Focus on the right address for your workflow: Baselayer often returns multiple addresses for the same business (registered, operating, mailing). Define which one is most relevant to your verification use case - typically the operating or search-input address.

Industry context matters: Residential/CMRA flags may be normal for software/consultancies, but questionable for manufacturing or retail. Leverage Web Presence & Orderables to obtain this context.

Undeliverable or CMRA flags at the primary operating address can indicate fake or inactive locations. CMRA = true or delivery_type = POST_OFFICE / GENERAL_DELIVERY can flag virtual offices or P.O. boxes used to conceal real operations.

Registered-agent clustering: If an operating address equals the registered agent’s and hosts many agents, it likely reflects a formation service address, and not the operating address of the business.

Business Officer Attributes (people-level data to strengthen identity verification)

Officer information links a business to the people behind it. When available, Baselayer includes officers drawn from registrations and additional sources, and can evaluate whether the names you provided match ours. This section outlines how to use officer data to strengthen verification, flag mismatches, or add confidence to borderline cases.

business_officer_match on the search tells you whether submitted officer names align with Baselayer’s records (EXACT/SIMILAR/NO_MATCH). Use this to lift confidence on borderline cases.

Each officer entry in the business_officers array follows this structure:

name: officer’s full name as recorded in official filings or online sources.
titles: roles associated with the officer (e.g., “CEO”, “Manager”, “President”, “Director”).
states: states where the officer is registered or listed in filings. Often matches the states in the business’s registrations array.
sources: data sources confirming this officer. By default, this is “SOS” (Secretary of State). When Enhanced Search is requested, it may also include “Online”, representing individuals Baselayer identified through external signals like the company website, LinkedIn, or other verified online sources.

Practical tip: Collect officer names only where proportional to risk; asking for them everywhere increases friction.

Best practices

Leverage business_officer_match: when you submit officer names in the search payload, Baselayer compares them to the officers in the matched business. The field business_officer_match (EXACT, SIMILAR, or NO_MATCH) summarizes this comparison. We don't recommend including it as part of the basic KYB check due to its potential impact into auto-approval rates - officer confirmation is best used as a supporting factor, not a hard requirement, unless your product requires proof of executive authorization.

Leverage sources to understand where data came from:

SOS → official Secretary of State records; legal authority.
Online → found through Enhanced Search (website, LinkedIn, or other digital signals). These can identify operational leads, founders, or signatories not listed in public filings - extremely useful for thin-file or early-stage businesses.

Registrations Attributes (legal standing information across states)

Registrations are the legal backbone of a business profile. Each business can have one or multiple registrations - one domestic (its incorporation state) and potentially several foreign registrations in other states. This section walks through how to interpret those registration objects, understand their status fields, and identify which registration matters most for KYB decisions.

This section explains how to interpret these registration objects, understand which one is most relevant for verification, and recognize how registration data impacts KYB decisioning.

Each registration entry includes structured legal and status information derived directly from Secretary of State sources and Baselayer’s enrichment systems:

id: Baselayer’s unique identifier for the registration.
state: U.S. state where this registration record exists.
registration_type: identifies whether the registration is domestic (the state of incorporation) or foreign (registered to do business in another state).
status: current legal standing of the registration, which can be one of:
- active: in good standing with the state
- inactive: no longer in good standing or dissolved
- unknown: returned when the Secretary of State system does not provide a definitive status (common for Delaware or NJ)
file_number: the state’s internal reference number for this business record.
issue_date: the date the entity was incorporated or first registered.
inactive_date: the date the registration became inactive (when applicable).
dissolution_date: the date the registration was dissolved (when applicable).
officers[]: officers or authorized signatories listed on that registration (when available).
url: Baselayer API link to the registration record for additional enrichment or re-verification.

Best practices

The domestic registration (state of incorporation) is the business’s anchor record. It represents the entity’s legal identity - use this to confirm existence and formation date.

Foreign registrations show where the business is authorized to operate outside its home state. They are useful for confirming footprint but less critical for identity verification.

Approve automatically only when at least one registration is active: treat inactive statuses as grounds for rejection or manual review. Unknown statuses (especially in Delaware) should be handled via enrichment before final decisioning.

Enriching a DE Registration (to get 100% of the status for DE registrations)

Delaware is home to more than 60% of Fortune 500 companies, and also one of the most complex Secretary of State systems to interpret. Because of this, a percentage of Delaware registrations may return with their status = "unknown" even when the entity exists and is in good standing. Baselayer resolves roughly 20% of these automatically, but for the remaining 80%, you can use the Registration Enrichment endpoint to obtain the definitive status.

This section explains when to trigger an enrichment, how the enrichment object works, and how to incorporate it into your KYB workflow for full Delaware coverage.

When to trigger an enrichment

You should only request a Delaware registration enrichment when:

The incorporation_state of the business is DE, and
The registration.status field in the API response is "unknown".

Baselayer will already include full registration details (name, ID, issue_date, etc.), but because Delaware doesn’t always return status through its public feed, enrichment is needed to confirm if the business is active, inactive, or revoked.

Triggering the enrichment fetches an up-to-date status directly from Delaware’s registry and replaces the original “unknown” value once complete.

What the enrichment request looks like

To perform an enrichment, you make a POST request to the /registration_enrichments endpoint, referencing the id of the Delaware registration you want to update.

Payload example:

{
"registration_id": "6883901"
}

Once completed, the enriched registration record is returned in the same structure as any other registration, but with a definitive status value. An enrichment request can take between 2 and 10 seconds depending on the DE SoS traffic load.

Associated Cost

The DE SoS charges data providers $10 per registration enrichment. Baselayer will pass through the cost to you without any additional charges.

Putting It All Together

Baselayer’s Business Search response gives you everything needed to automate and optimize KYB.
The key is knowing how to use each layer together, progressively building trust in the entity you’re evaluating.

Start with the right inputs
Provide the legal name and address as a minimum, and include optional fields like TIN, website, and officer names when available. The more complete the inputs, the richer your verification results.
Choose your decisioning path
- For simplicity: rely on Baselayer’s KYB and Risk ratings (A/B = pass, C/F = review).
- For flexibility: use the Standard KYB Check Recommendation to design granular logic tailored to your product and risk tolerance.
Review the Search Response first
Check top-level fields like business_name_match, business_address_match, and tin_matched to quickly assess the quality of the match and detect any immediate red flags (e.g., watchlist hits or IRS outages).
Evaluate the Business object
Confirm that the entity’s structure, months_in_business, and watchlist_hits meet your product’s criteria.
If applicable, store the business_id to link follow-on products like Lien or Docket Searches.
Optionally analyze addresses or officers objects
Addresses or officers can reveal risk patterns - like mail-forwarding, virtual offices, or unrelated individuals. Consider adding these checks to your KYB flow.
Verify registrations and standing
Ensure there’s at least one active domestic registration, and, if the business operates in another state, an active foreign registration there too.
For Delaware entities with a status of “unknown,” consider triggering a registration enrichment to complete your verification.
Monitor and refine
Track verification outcomes over time. Baselayer’s structured data allows you to analyze approval rates, fraud patterns, and friction points; helping you continuously tune your KYB policy for the best balance between safety and conversion.

In short:
Start broad, review key signals in order, and apply enrichment only where needed.
By combining Baselayer’s structured attributes, you can build a KYB workflow that’s both intelligent and efficient, capable of adapting to your customers, products, and risk goals.