> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.
# Key People
> Verify UBOs, shareholders, directors, and officers in one unified KYB flow with role-aware checks and linked KYC sessions. Pay-per-call $2.00, no contracts.
**Key people** is Didit's unified model for every natural person and corporate entity tied to the business you're verifying: UBOs, shareholders (individual and corporate), directors, representatives, and other officer roles. A single Key People flow covers the lot — with role-aware verification dispatch and full side-by-side comparison between registry-sourced and user-submitted parties.
For the Business-entity view of key people — how officers and UBOs aggregate across sessions — see [Businesses → Key people](/entities/businesses/key-people).
## How it works
If the workflow enables registry prefill, the Key People screen is pre-populated with UBOs, shareholders and officers extracted from the registry check. The end user can edit, add, or remove parties before submitting.
The end user submits the final list of key people through the hosted verification flow. You don't call this step yourself — it happens inside the KYB flow whose URL you delivered from [Create Session](/sessions-api/create-session).
For each submitted party, Didit checks the role's configured verification settings:
* Applies the workflow's ownership threshold — UBOs and shareholders below the configured percentage don't require individual verification.
* Honours the "skip verification" flag the end user set, if the role allows skipping.
* Spawns a child User Verification (KYC) session for person parties that require KYC.
* Spawns a child KYB sub-session for corporate UBOs when nested KYB is enabled on the workflow.
The Key People feature status becomes `Awaiting User` while any required child session is still in progress. When every child session finishes, the status aggregates to `Approved`, `Declined`, or `In Review` based on the outcomes.
## Roles collected
Key people can carry one or more of the following roles — a single person can hold several at once (for example, director **and** shareholder). The full taxonomy:
| Category | Roles |
| ------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Ownership** | `ubo`, `shareholder`, `beneficiary`, `settlor`, `protector`, `investor` |
| **Governance / representation** | `director`, `non_executive_director`, `chairman`, `secretary`, `representative`, `authorized_signatory`, `trustee`, `company_officer`, `founder`, `legal_advisor`, `other` |
Every role can be individually configured in the workflow — enabled or disabled, required or optional for KYC, mapped to a specific KYC workflow, and optionally skippable. See [Ownership](/business-verification/ownership) for the verification dispatch details.
## Data collected per key person
The hosted flow asks for a default set of fields and additional workflow-configured custom fields. See [Ownership → Fields collected](/business-verification/ownership#data-collected-for-each-key-person) for the full list.
## Registry confirmation
Before the Key People step, the end user reviews the company data extracted from the registry check and optionally edits any fields. The hosted flow then stores:
* The **raw registry payload** as an immutable audit record (`registry_data`).
* The **user-confirmed data** (`user_provided_data`) with a timestamp that marks when the user confirmed.
* A merged canonical view on the top-level company fields — user-confirmed when present, registry fallback otherwise.
See [Company data → Registry vs user-provided data](/business-verification/company-data#registry-data-vs-user-provided-data) for the full model.
## Shape in the decision response
After submission, the collected key people surface in the KYB decision under `key_people_checks[]`, split into two buckets — **registry** (what the provider disclosed) and **submitted** (what the business admin confirmed through the flow) — plus a `ubo_kyc_summary` that rolls up UBO KYC progress. See the full [key\_people\_checks reference](/business-verification/response-schema#key_people_checks).
## Resubmit behaviour
* **Key People** and **Registry Check** cannot be resubmitted directly. To re-verify a specific person, resubmit their individual child KYC session.
* When a child KYC session is resubmitted, the parent Key People feature status automatically returns to `Awaiting User`.
* When the resubmitted child finishes, the parent re-aggregates based on all child statuses.
## Configuration options
All Key People behaviour is configured per workflow from the Business Console:
| Setting | What it controls |
| ----------------------------------- | ---------------------------------------------------------------------------- |
| **Registry prefill** | Pre-populate the Key People form from registry data |
| **Extra fields — persons** | Custom fields to collect for each person party |
| **Extra fields — companies** | Custom fields to collect for each corporate party |
| **UBO ownership threshold** | Minimum ownership percentage to classify someone as a UBO |
| **Shareholder ownership threshold** | Minimum ownership percentage to classify someone as a shareholder |
| **Per-role settings** | For each role: enabled/disabled, require KYC, KYC workflow to use, skippable |
| **Corporate UBO nested KYB** | When enabled, corporate UBOs trigger their own child KYB session |
| **Notify parties by email** | Automatically email each key person with their verification link |
Configure at *Workflows → \[KYB workflow] → Key People* in the console.
## Next steps
Fields collected, custom data, and registry vs submitted reconciliation.
Governance roles within the key-people model.
`key_people_checks[]` field-by-field reference.