For the Business-entity view of key people — how officers and UBOs aggregate across sessions — see Businesses → Key people.
How it works
Registry prefill (optional)
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.
Submission from the hosted flow
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.
Role-aware verification routing
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.
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 |
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 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.
Shape in the decision response
After submission, the collected key people surface in the KYB decision underkey_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.
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 |
Next steps
Ownership
Fields collected, custom data, and registry vs submitted reconciliation.
Officers & representatives
Governance roles within the key-people model.
Response schema
key_people_checks[] field-by-field reference.