Skip to main content
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.

​
How it works

1

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.
2

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.
3

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.
4

Status progression

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: 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 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 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 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.

​
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: Configure at Workflows → [KYB workflow] → Key People in the console.

​
Reusing verified individuals across KYB checks

When Reuse verified individuals is enabled on a workflow (the default), a key person doesn’t have to redo KYC every time they show up on a new KYB check. Didit looks for an existing approved KYC from a previous KYB check and links it to the new party instead of spawning a fresh child KYC session.
This is a distinct mechanism from Reusable KYC, which lets an end user voluntarily carry one finished session across separate Didit-integrated applications via a share/import token. The KYB reuse setting on this page is automatic, workflow-configured, and scoped to key people within a single application - no share token, and no action from the end user.
Matching. A candidate match is found by comparing the submitted person’s full name (case-insensitive, whitespace-trimmed) against key people from the application’s other KYB checks. There’s no additional matching signal - a document number, email, or phone match is not required or checked. A name entered with different spelling, a middle name, or a transliteration won’t match, and in rare cases two different people who share a name could match; review your Key People results with this in mind. Scope. Matching looks across every other KYB check that belongs to the same application, not just the current KYB check and not other applications in your organization. A person verified as a UBO on Company A can be matched when they later appear as a director on Company B, as long as both checks run under the same application. Eligible statuses. Only a party’s most recent Approved KYC is eligible for reuse. A Declined KYC for that name blocks reuse entirely - the party is flagged and a fresh KYC is requested instead of falling back to the declined one. A KYC that’s still In Review is never considered a candidate. Retention. Matching only considers KYC sessions created in roughly the last year that haven’t been deleted. If the only matching session falls outside that window, or the person or org has deleted it, the check finds no eligible match and silently requests a new KYC - it never fails or blocks Key People submission. Billing. A reused KYC is not billed again. Linking an already-approved session to the new party carries no additional charge; you’re only billed once, on the original KYC.
Example

​
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.