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

# API проверки ключевых лиц KYB: бенефициары и директора

> Didit проверяет бенефициаров, акционеров, директоров и руководителей в KYB-процессе с проверкой по ролям. От $2.00 за проверку, без контрактов.

**Ключевые лица** представляют собой единую модель Didit для всех физических и юридических лиц, связанных с проверяемой компанией: UBO, акционеры (физические и юридические), директора, представители и другие роли должностных лиц. Один поток «Ключевые лица» охватывает всех, с маршрутизацией верификации по роли и полным параллельным сопоставлением сторон, полученных из реестра, и сторон, представленных пользователем.

> [!NOTE]
>
> Сведения о ключевых лицах в разрезе компании, то есть о том, как должностные лица и UBO агрегируются по сессиям, см. в разделе [Компании → Ключевые лица](https://docs.didit.me/ru/entities/businesses/key-people.md).

## Как это работает

**1. Предварительное заполнение из реестра (необязательно)**

Если в сценарии включено предварительное заполнение из реестра, экран «Ключевые лица» предварительно заполняется доступными UBO, акционерами и должностными лицами, извлечёнными из проверки реестра.
Конечный пользователь может редактировать, добавлять или удалять стороны до отправки, даже если информация о структуре владения ещё не готова.
Должностные лица, которые уже получены, остаются доступными, пока собирается отчёт о структуре владения.
Перед отправкой поздние результаты заполняют поля, которые не редактировались пользователем, и добавляют недостающих лиц, не заменяя изменения пользователя и не восстанавливая удалённые стороны.
Открытый редактор не меняется: дополнительное предварительное заполнение применяется после того, как заявитель его закроет.
Если предварительное заполнение из реестра отключено, заявители вводят лиц самостоятельно, а поздние результаты в эту форму не попадают.
Данные реестра, поступившие после отправки, остаются частью доказательств из реестра, но не меняют отправленный список лиц и не создают автоматически дополнительные дочерние сессии верификации.

**2. Отправка из размещённого сценария**

Конечный пользователь отправляет итоговый список ключевых лиц через размещённый сценарий верификации. По умолчанию вам не нужно вызывать этот шаг самостоятельно: он выполняется внутри KYB-сценария, URL которого вы передали из [Создать сессию](https://docs.didit.me/ru/sessions-api/create-session.md).
Чтобы вместо этого использовать собственный фронтенд, воспользуйтесь эндпоинтами [черновика сторон](https://docs.didit.me/ru/sessions-api/kyb-create-party-draft.md) и [отправки сторон](https://docs.didit.me/ru/sessions-api/kyb-submit-parties.md).

**3. Маршрутизация верификации по роли**

Для каждой отправленной стороны Didit проверяет настройки верификации, заданные для роли:

* Применяет порог владения сценария: UBO и акционеры с долей ниже заданного процента не требуют индивидуальной верификации.
* Учитывает флаг «пропуск верификации», который установил конечный пользователь, если роль разрешает пропуск.
* Создаёт дочернюю сессию User Verification (KYC) для физических лиц, которым требуется KYC.
* Создаёт дочернюю KYB-подсессию для юридических UBO, если во вложенном KYB в сценарии включена опция.

**4. Изменение статуса**

Статус функции «Ключевые лица» переходит в состояние `Awaiting User`, пока любая обязательная дочерняя сессия ещё выполняется. Когда все дочерние сессии завершаются, статус агрегируется в `Approved`, `Declined` или `In Review` в зависимости от результатов.

## Собираемые роли

Ключевые лица могут иметь одну или несколько из следующих ролей. Один человек может одновременно занимать несколько ролей (например, **директор** и **акционер**). Полный список:

| Категория | Роли |
| - | - |
| **Собственность** | `ubo`, `shareholder`, `beneficiary`, `settlor`, `protector`, `investor` |
| **Управление / представительство** | `director`, `non_executive_director`, `chairman`, `secretary`, `representative`, `authorized_signatory`, `trustee`, `company_officer`, `founder`, `legal_advisor`, `other` |

Каждую роль можно настроить отдельно в сценарии: включить или отключить, сделать обязательной или необязательной для KYC, привязать к определённому KYC-сценарию и при необходимости разрешить пропуск. Подробности маршрутизации верификации см. в разделе [Собственность](https://docs.didit.me/ru/business-verification/ownership.md).

## Данные по каждому ключевому лицу

Размещённый сценарий запрашивает набор полей по умолчанию и дополнительные пользовательские поля, заданные в сценарии. Полный список см. в разделе [Собственность → Собираемые поля](https://docs.didit.me/ru/business-verification/ownership.md#данные-которые-собираются-по-каждому-ключевому-лицу).

## Подтверждение данных из реестра

Перед шагом «Ключевые лица» конечный пользователь проверяет данные о компании, извлечённые из проверки реестра, и при необходимости редактирует любые поля. Затем размещённый сценарий сохраняет:

* **Подробные данные реестра**, которые Didit нормализовал из проверки реестра (`registry_data`).
* **Данные, подтверждённые пользователем** (`user_provided_data`), с временной меткой момента подтверждения.
* Объединённое каноническое представление в полях компании верхнего уровня: данные, подтверждённые пользователем, если они есть, иначе данные из реестра.

Полную модель см. в разделе [Данные компании → Данные реестра и данные, предоставленные пользователем](https://docs.didit.me/ru/business-verification/company-data.md#данные-реестра-и-данные-предоставленные-пользователем).

## Структура ответа с решением

После отправки собранные ключевые лица появляются в решении по KYB в поле `key_people_checks[]` и делятся на две группы: **реестр** (то, что раскрыл поставщик данных) и **отправленные** (то, что администратор компании подтвердил в сценарии). Также возвращается `ubo_kyc_summary`, которое сводит прогресс KYC по UBO. Полную информацию см. в [справочнике по key\_people\_checks](https://docs.didit.me/ru/business-verification/response-schema.md#key_people_checks).

## Повторная отправка

* **Ключевые лица** и **Проверка реестра** нельзя отправить повторно напрямую. Чтобы заново верифицировать конкретное лицо, отправьте повторно его отдельную дочернюю KYC-сессию.
* Когда дочерняя KYC-сессия отправляется повторно, статус родительской функции «Ключевые лица» автоматически возвращается в `Awaiting User`.
* Когда повторно отправленная дочерняя сессия завершается, родительский статус пересчитывается по статусам всех дочерних сессий.
* Дочернюю сессию, которая была удалена или истекла до того, как пользователь начал её, нельзя отправить повторно: [пересоздайте сторону](https://docs.didit.me/ru/sessions-api/regenerate-kyb-party.md), чтобы выпустить новую ссылку для той же стороны.

## Как долго действует ссылка для верификации ключевого лица

Дочерняя сессия KYC ключевого лица следует времени истечения сессии того сценария KYC, который настроен для его роли, а не сценария KYB. Если вы сопоставите роль со сценарием KYC, для которого установлен срок действия четыре недели, ссылка этого человека будет работать четыре недели, даже если сессия бизнеса настроена на более короткий срок.

Значение задаётся для каждого сценария: от 1 часа до 4 недель (`session_expiration_time`, в секундах) в разделе *Workflows → \[KYC workflow] → Settings*.

Истечение срока влияет на то, что вы можете сделать с участником. Ссылку, которая истекла до того, как человек начал верификацию, например ссылку на удалённую сессию, можно перевыпустить с помощью [Regenerate Key People KYC Session](https://docs.didit.me/ru/sessions-api/regenerate-kyb-party.md). Удалённые сессии подходят, даже если человек уже начал или завершил верификацию. Импортированные сессии по сроку действия не подходят: их необходимо удалить. Сессия, которая не удалена и которую человек уже начал, по сроку действия не подходит.

## Варианты настройки

Все параметры ключевых лиц настраиваются для каждого сценария в Business Console:

| Настройка | Что она контролирует |
| - | - |
| **Registry prefill** | Предварительно заполнять форму ключевых лиц данными из реестра |
| **Extra fields – persons** | Дополнительные поля, которые нужно собирать для каждого участника-физического лица |
| **Extra fields – companies** | Дополнительные поля, которые нужно собирать для каждого корпоративного участника |
| **Порог владения UBO** | Минимальный процент владения, при котором лицо классифицируется как UBO |
| **Порог владения акционера** | Минимальный процент владения, при котором лицо классифицируется как акционер |
| **Per-role settings** | Для каждой роли: включена или отключена, требуется ли KYC, какой сценарий KYC использовать, можно ли пропустить |
| **Corporate UBO nested KYB** | Если включено, корпоративные UBO запускают собственную дочернюю сессию KYB |
| **Повторное использование верифицированных лиц** | См. [Повторное использование верифицированных лиц в проверках KYB](#повторное-использование-верифицированных-лиц-в-проверках-kyb) ниже |
| **Уведомлять участников по электронной почте** | Автоматически отправлять каждому ключевому лицу письмо со ссылкой на верификацию |

Настройте в *Workflows → \[KYB workflow] → Key People* в консоли.

## Повторное использование верифицированных лиц в проверках KYB

Если на сценарии включена настройка **Повторное использование верифицированных лиц** (по умолчанию она включена), ключевому лицу не нужно заново проходить KYC при каждом новом появлении в проверке KYB. Didit ищет существующий одобренный KYC из предыдущей проверки KYB и привязывает его к новому участнику, вместо того чтобы создавать новую дочернюю сессию KYC.

> [!NOTE]
>
> Это отдельный механизм от [Многоразового KYC](https://docs.didit.me/ru/core-technology/reusable-kyc/overview.md). Многоразовый KYC позволяет конечному пользователю добровольно переносить одну завершённую сессию между отдельными приложениями, подключёнными к Didit, с помощью токена передачи или импорта. Повторное использование, описанное на этой странице, работает автоматически, настраивается в сценарии и ограничено ключевыми лицами внутри одного приложения. Токен передачи не нужен, и конечному пользователю ничего не требуется делать.

**Сопоставление.** Кандидат ищется сравнением полного имени указанного лица (без учёта регистра, пробелы по краям обрезаются) с ключевыми лицами из других проверок KYB этого приложения. Дополнительных признаков сопоставления нет: совпадение номера документа, адреса электронной почты или телефона не требуется и не проверяется. Имя, написанное с другим написанием, второе имя или транслитерация не совпадут, а в редких случаях два разных человека с одинаковым именем могут совпасть. Учитывайте это при разборе результатов ключевых лиц.

**Область поиска.** Поиск охватывает все другие проверки KYB, принадлежащие тому же приложению, а не только текущую проверку KYB и не другие приложения вашей организации. Лицо, верифицированное как UBO компании A, может совпасть, когда позже появится как директор компании B, если обе проверки выполняются в одном приложении.

**Допустимые статусы.** Для повторного использования подходит только последняя **одобренная** KYC-проверка участника. **Отклонённая** KYC-проверка с этим именем полностью блокирует повторное использование: участник помечается, и вместо отклонённого KYC запрашивается новый. KYC со статусом **На проверке** никогда не рассматривается как кандидат.

**Хранение.** Поиск учитывает только сессии KYC, созданные примерно за последний год и не удалённые. Если единственная подходящая сессия выходит за этот период либо человек или организация её удалили, проверка не находит подходящего совпадения и молча запрашивает новый KYC. Она никогда не завершается ошибкой и не блокирует отправку данных ключевых лиц.

**Оплата.** Повторно использованный KYC не тарифицируется снова. Привязка уже одобренной сессии к новому участнику не требует дополнительной оплаты: вы платите только один раз, за исходный KYC.

```txt Example theme={null}
Company A: Jane Doe submitted as UBO, KYC approved.
Company B (same application): Jane Doe submitted as a director.
"Reuse verified individuals" is enabled, so Company B's Key People
check links Jane's existing approved KYC instead of requesting a
new one - free, and instantly Approved for that party.
```

## Следующие шаги

> [card] [Владение](https://docs.didit.me/ru/business-verification/ownership.md)
>
> Собираемые поля, пользовательские данные и сверка данных реестра с отправленными.

> [card] [Должностные лица и представители](https://docs.didit.me/ru/business-verification/officers.md)
>
> Управленческие роли в модели ключевых лиц.

> [card] [Схема ответа](https://docs.didit.me/ru/business-verification/response-schema.md#key_people_checks)
>
> Справочник по каждому полю `key_people_checks[]`.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.