Диаграмма жизненного цикла
Статусы подробно
Изменение статуса через
PATCH /v3/users/{vendor_data}/update-status/ или PATCH /v3/businesses/{vendor_data}/update-status/ отправляет webhook (user.status.updated / business.status.updated), чтобы смежные системы могли реагировать в реальном времени.Этапы жизненного цикла
Создание
Сущность создаётся одним из трёх способов:
- Создана автоматически при запуске сессии с новым
vendor_data. Сущность создаётся в статусеACTIVE. - Создана заранее через API с помощью
POST /v3/users/create/илиPOST /v3/businesses/create/. Статус по умолчанию:ACTIVE. - Создана в консоли комплаенс-оператором. Статус изначально
ACTIVE, если оператор не указал иначе.
uuid, генерируемый Didit, и идентификатор vendor_data, который принадлежит клиенту.Верификация
К сущности привязываются сессии через
vendor_data. Каждая сессия проходит через настроенный вами сценарий: верификация личности, проверка живости, сравнение лиц, AML, документы, поиск в реестре для KYB и так далее.Завершённые сессии обновляют агрегированные счётчики сущности:session_count,approved_count,declined_count,in_review_count- карта
features: последний статус каждой функции по всем сессиям (например,{ "id_verification": "APPROVED", "aml": "IN_REVIEW" }) - поля профиля берутся из последней одобренной сессии (например,
full_name,date_of_birth,portrait_image).
Активное использование
Когда у сущности есть одна или несколько одобренных сессий, вы можете:
- Отправлять транзакции, ссылающиеся на сущность через
vendor_dataв теле транзакции - Запускать постоянный AML-мониторинг: периодические повторные проверки по спискам санкций, PEP и негативных публикаций в СМИ
- Повторно верифицировать по расписанию: создавать новые сессии для того же
vendor_dataчерез регулярные интервалы - Агрегировать сигналы риска по сессиям и транзакциям
Переходы статусов
Статус сущности меняется автоматически или вручную.Автоматические переходы
ACTIVE → FLAGGED, когда транзакция превышает порог проверки или правило добавляет сущность в список наблюдения.ACTIVE → BLOCKED, когда биометрические данные лица совпадают с записью в списке блокировки.
USER (vendor_data) переводит статус в BLOCKED.Ручные переходы происходят, когда аналитик меняет статус в консоли или когда вы вызываете endpoint update-status.Каждый переход отправляет webhook user.status.updated или business.status.updated.Удаление
Сущности удаляются через
POST /v3/users/delete/ или POST /v3/businesses/delete/ (пакетно). Запись сущности удаляется безвозвратно. Удаление User также очищает все биометрические шаблоны, сохранённые для него после удаления сессий, поэтому человек перестаёт совпадать при обнаружении дубликатов и в поиске по лицу.Эти endpoint’ы не распространяются на сессии верификации и на транзакции. Удаляйте сессии через Удаление сессии или Пакетное удаление сессий. Транзакции удаляются из консоли.Временные метки активности
Сущности отслеживают активность, чтобы помочь вам выявлять неактивные и активные профили:
Используйте эти метки, чтобы фильтровать неактивные сущности, планировать повторные верификации или запускать постоянный мониторинг.
События, отправляемые в ходе жизненного цикла
См. webhook сущностей для форматов payload и семантики доставки.
Следующие шаги
Связывание vendor_data
Как
vendor_data связывает сессии, транзакции и сущности между собой.Операции с User
Создание, обновление, смена статуса и удаление сущностей User.
Операции с Business
Создание, обновление, смена статуса и удаление сущностей Business.