> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tesouro.com/llms.txt
> Use this file to discover all available pages before exploring further.

# What KYB collects

> The three entities the bank's Know Your Business pipeline collects, and what to pre-fill to reduce drop-off.

KYB collects information on three entities. The bank's pipeline uses all three to decide.

<CardGroup cols={3}>
  <Card title="Business" icon="building">
    Legal name, DBA, EIN, structure (LLC, C-Corp, etc.), business address, phone, website, and NAICS industry code.
  </Card>

  <Card title="Controller" icon="user-tie">
    The individual who directs or significantly influences the business's finances — CEO, CFO, or equivalent. Full PII: legal name, DOB, SSN, home address, phone, work email. The controller is always one person and is always collected, regardless of ownership.
  </Card>

  <Card title="Beneficial owners" icon="users">
    Any individual who owns 25% or more of the business. Same PII as the controller, plus an ownership percentage. A business may have zero, one, or several. If the controller also owns 25%+, they are listed once as the controller with their ownership percentage set.
  </Card>
</CardGroup>

These are the conceptual buckets. Exact field names live in the [bank account application creating guide](/embedded-banking/guides/bank-account-applications/creating) and the [onboarding component pre-fill tables](/embedded-banking/guides/embedded-components/onboarding#pre-filling-onboarding-data).

## Pre-fill: what to send up front

Anything you already know about the business or the people running it should be passed when you create the application. Pre-filled fields show up populated in whichever surface the applicant ends up using, which cuts drop-off — every empty field on a KYB form is a place the applicant can stall, mistype, or abandon.

* **Send what you have, even if it's partial.** A pre-filled legal name and EIN is better than nothing, even if you don't have SSNs.
* **The applicant can always edit.** Pre-filled fields are not locked. If you have stale data, that's fine — the applicant corrects it before submitting.
* **PII passes through your backend.** SSNs and DOBs go in the create payload over your authenticated server-to-server connection. They are never returned in plaintext on subsequent reads.
* **Industry code matters.** NAICS code drives risk scoring on the bank's side. If you collected the business's industry during sign-up, send it — generic codes get scrutinized harder than specific ones.

Field-by-field pre-fill is enumerated in the [onboarding component reference](/embedded-banking/guides/embedded-components/onboarding#pre-filling-onboarding-data). The same fields are accepted on the REST create endpoint.