Схема ответа KYB: payload решения

Эта страница описывает полный payload, возвращаемый GET /v3/session/{id}/decision/ для сессии верификации бизнеса (KYB). Эндпоинт универсальный: если передать session_id бизнес-сессии, ответ содержит session_kind: "business" и массивы функций, специфичные для KYB, которые описаны ниже.

Структура верхнего уровня

{
  "session_id": "bs_01H...",
  "session_kind": "business",
  "session_number": 89,
  "session_url": "https://verify.didit.me/...",
  "status": "Approved",
  "status_override": null,
  "workflow_id": "wf_kyb_standard",
  "features": ["KYB_REGISTRY", "AML", "KYB_DOCUMENTS", "KYB_KEY_PEOPLE"],
  "vendor_data": "biz-acme-001",
  "metadata": { },
  "callback": null,

  "registry_checks": [ ... ],
  "aml_screenings": [ ... ],
  "document_verifications": [ ... ],
  "key_people_checks": [ ... ],

  "phone_verifications": null,
  "email_verifications": null,
  "questionnaire_responses": null,
  "ip_analyses": null,

  "reviews": [ ],
  "decision_trace": { ... },
  "linked_records": null,
  "contact_details": { ... },
  "expected_details": null,
  "created_at": "...",
  "expires_at": "..."
}

Все массивы функций могут содержать несколько элементов, и каждый элемент соответствует одному узлу в графе сценария. Значение null означает, что функция не входила в сценарий этой сессии.

Общие поля верхнего уровня

Поле	Тип	Описание
`session_id`	UUID	Уникальный идентификатор сессии
`session_kind`	enum	Всегда `"business"` для сессий KYB
`session_number`	int	Порядковый номер внутри заявки
`session_url`	URL	Ссылка на размещённую страницу верификации
`status`	enum	Общий статус сессии (см. статусы)
`status_override`	object или null	`{ overridden_at, automatic_status }`, когда проверяющий вручную установил `status` вопреки тому, что установила бы платформа (например, одобрил компанию, при этом связанная верификация ключевого лица отклонена). `null`, когда статус является автоматическим. Используйте это поле, чтобы отличить ручное одобрение от автоматического
`decision_trace`	object	Как было принято решение: `status`, `decided_by` (`manual`, `automatic` или `investigator`), `decided_at`, `automatic_status`, `terminal_node_id`, `actor`, `warning_counts` и `status_warnings` (предупреждения, которые определили статус)
`linked_records`	object или null	Краткая сводка о других записях, связанных с сессией. `null`, если показывать нечего
`workflow_id`	UUID	Сценарий, по которому работала эта сессия
`features`	массив строк	Идентификаторы функций, которые выполнил сценарий (например, `KYB_REGISTRY`, `AML`, `KYB_DOCUMENTS`, `KYB_KEY_PEOPLE`, `PHONE`, `EMAIL`)
`vendor_data`	string	Ваш идентификатор компании
`metadata`	object	Произвольный JSON, который вы передали при создании сессии
`callback`	URL или null	Необязательный URL для перенаправления после верификации
`contact_details`	object или null	`{ email, email_lang, send_notification_emails, phone }`. Заполняется, когда сценарий включает уведомления по e-mail или телефону
`expected_details`	object или null	Payload с ожидаемыми данными компании, который вы передали при создании: `company_name`, `registry_country` (`XX` или `XX-YY` с указанием штата для реестров на уровне штатов, например `US-CA`), `registration_number`
`reviews`	array	Последние заметки проверяющих по сессии
`created_at`, `expires_at`	временные метки ISO	—

`registry_checks[]`

Каждый элемент описывает одну проверку в реестре компаний (обычно одну на сессию; несколько в графовых сценариях с рекурсивной проверкой корпоративных бенефициарных владельцев в KYB).

{
  "status": "Approved",
  "node_id": "feature_kyb_registry",
  "data_resolved": true,
  "company": { ...see below... },
  "ownership_structure": { },
  "warnings": []
}

Поле	Описание
`status`	Статус жизненного цикла проверки (`Approved`, `Declined`, `In Review`, `Not Finished`, `Resub Requested`)
`node_id`	Идентификатор узла графа для этой проверки
`data_resolved`	`true`, когда данные реестра загружены или пользователь ввёл их вручную
`company`	Полный payload реестра, см. раздел блок `company` ниже
`ownership_structure`	Структура владения, подтверждённая реестром на момент получения уровня владения: `shareholders[]` и `beneficial_owners[]`. Каждый элемент содержит ту же идентификацию в реестре и ту же долю, что и `company.beneficial_owners[]` (`name`, `entity_type`, `roles`, `ownership_min_shares` / `ownership_max_shares` и др.), а также его каноническую `shareholding`. `null`, если реестр не подтвердил никакого владения. Актуальную запись смотрите в `company.beneficial_owners` и `company.ownership`
`warnings`	Структурированные предупреждения и записи журнала, относящиеся к этой проверке в реестре. См. Предупреждения верификации бизнеса.

Блок `company`

Вложенный объект company содержит полное представление юридического лица на основе данных реестра (и, при необходимости, отредактированных пользователем):

{
  "uuid": "...",
  "node_id": "feature_kyb_registry",
  "status": "Approved",
  "registry_status": "active",
  "data_resolved": true,
  "company_name": "Acme Corporation Limited",
  "registration_number": "12345678",
  "country_code": "GBR",
  "company_type": "Private Limited",
  "incorporation_date": "2010-05-14",
  "registered_address": "1 Main Street, London EC1A 1AA, United Kingdom",
  "tax_number": "SAMPLE-TAX-12345",
  "risk_level": null,
  "verification_status": "verified",
  "is_from_registry": true,
  "fetch_status": "resolved",
  "alternative_names": "Acme Ltd",
  "nature_of_business": "Software publishing",
  "registered_capital": "100000 GBP",
  "website": "https://acme.example",
  "email": "alex.sample@example.com",
  "phone": "+15550101000",
  "legal_entity_identifier": "529900XXXXXXXXXXXXX",
  "location_of_registration": "London",
  "vat_number": "GB980780684",
  "vat_validation_status": "format_valid",
  "vat_validated_number": "GB980780684",
  "vat_validation_source": "format_rules",
  "vat_validated_name": null,
  "vat_validated_address": null,
  "vat_checked_at": "2026-04-16T10:10:00Z",
  "financial_summary": { },
  "officers": [ ... ],
  "beneficial_owners": [ ... ],
  "addresses": [
    {
      "type": "registered",
      "address": "1 Main Street, London EC1A 1AA, United Kingdom",
      "street": "1 Main Street",
      "city": "London",
      "postal_code": "EC1A 1AA",
      "region": null,
      "country_code": "GB",
      "description": null
    }
  ],
  "industries": [
    { "code": "58290", "description": "Other software publishing", "scheme": "UK SIC 2007", "is_primary": true }
  ],
  "accounts": { ... },
  "ownership": {
    "status": "delivered",
    "tier_requested": "ubo",
    "tier_delivered": "ubo",
    "unavailable_reason": null,
    "direct_ownership_complete": true,
    "unresolved": []
  },
  "registry_tier": "ubo",
  "registry_tier_delivered": "ubo",
  "registry_ownership_status": "delivered",
  "registry_monitoring": null,
  "registry_data": { },
  "user_provided_data": { },
  "confirmed_by_user_at": "2026-04-16T10:10:00Z",
  "last_console_edit_at": null,
  "is_editable": false
}

Поле	Описание
`registry_status`	Статус, переданный провайдером (`active`, `dissolved`, `struck_off`, `inactive` и др.). См. статусы
`is_from_registry`	`true`, если данные получены из официального реестра; `false` для данных, введённых вручную
`fetch_status`	`pending`, `resolved` или `failed`: состояние запроса к реестру
`verification_status`	`verified`, `failed` или `unknown`
`risk_level`	Необязательное значение, передаваемое из источника реестра. Обычно `null`: Didit не вычисляет уровень риска, поэтому принимайте решение на основе `warnings[]` и `status` сессии
`registry_monitoring`	Последний мониторинг реестра для компании или `null`, если его нет. Заполняется только после того, как станет доступен мониторинг реестров. Поля: `uuid`, `status`, `unavailable_reason`, `enrolled_at`, `cancelled_at`, `last_bill_date`, `next_bill_date`, `last_event_at`, `events_count`, `watched_fields`
`is_editable`	`true`, пока конечный пользователь ещё может редактировать данные из реестра
`registry_data`	Нормализованные подробные данные реестра Didit: результат проверки владения (`ownership_error`, `section_errors`, `ubo_resolution`), исправления, внесённые через update-data, и сведения из реестра, для которых нет собственного поля. Здесь никогда не содержится собственная запись источника реестра. Состав ключей зависит от компании, и это не стабильный контракт: используйте канонические поля
`user_provided_data`	Поля, которые ввёл или отредактировал конечный пользователь (полезно для аудита: сравнение с данными реестра)
`confirmed_by_user_at`	Время, когда конечный пользователь подтвердил или отредактировал данные реестра
`vat_number`	Номер НДС в том виде, в каком его передали, если он был собран
`vat_validation_status`	Результат проверки номера НДС или, если его нет, `tax_number`: `valid`, `invalid`, `format_valid`, `invalid_format`, `could_not_validate` или `not_applicable`. См. Проверка НДС и налогового идентификатора
`vat_validated_number` / `vat_validation_source`	Номер, который проверяли, в том виде, в каком его знает источник, и источник, определивший статус (официальный реестр или `format_rules`)
`vat_validated_name` / `vat_validated_address`	Название и адрес, зарегистрированные в источнике, если он их раскрывает
`vat_checked_at`	Время проверки; `null`, если проверка не выполнялась
`officers[]`	Должностные лица со встроенным обогащением KYC (см. ниже)
`beneficial_owners[]`	Бенефициарные владельцы со встроенным обогащением KYC (см. ниже)
`addresses[]`	Все адреса, которые указывает реестр, в каноническом формате адреса (см. ниже). `null`, если реестр не указывает ни одного
`industries[]`	Виды деятельности, к которым реестр относит компанию, в каноническом формате отрасли (см. ниже). `null`, если реестр их не указывает
`accounts`	Даты подачи корпоративных документов, если они указаны: `last_annual_return_date` и `last_agm_date`. Они описывают подачи документов и собрания, а не финансовую отчётность
`ownership`	Итог проверки уровня владения (акционеры / UBO) в каноническом формате (см. ниже)
`registry_tier` / `registry_tier_delivered` / `registry_ownership_status`	Заказанный уровень проверки, предоставленный (и оплаченный) уровень и итог проверки владения. Те же значения есть в `ownership`

Один формат для всех стран и источников реестров

Didit получает данные реестров компаний во многих странах через несколько источников. Каждый источник публикует собственный макет, но блок company всегда имеет одну и ту же структуру: ключи ниже присутствуют всегда, с одними и теми же типами, независимо от страны и источника. Факт, который реестр не публикует, равен null. Вам никогда не нужно ветвить логику по стране или разбирать registry_data. Ту же структуру возвращают решение, отдельные endpoint KYB-реестра и размещённый процесс верификации. Адрес (каждый элемент addresses)

Поле	Описание
`type`	В нижнем регистре. `registered` для юридического адреса; другие типы указаны так, как их называет реестр (например, `postal`, `office`). `null`, если реестр не говорит, что это за адрес
`address`	Полный адрес одной строкой. Всегда присутствует
`street`, `city`, `postal_code`, `region`	Адрес по частям, если реестр их публикует
`country_code`	ISO 3166-1 alpha-2
`description`	Собственная метка реестра для адреса, если он её даёт

Отрасль (каждый элемент industries)

Поле	Описание
`code`	Код вида деятельности в том виде, в каком его печатает реестр
`description`	Название вида деятельности, если реестр его публикует
`scheme`	Система классификации, одно название на систему независимо от того, какой источник её указал (`UK SIC 2007`, `US SIC`, `NACE Rev. 2`, `NACE Rev. 2.1`, `NAF Rev. 2`, `CNAE`, `SBI`, `NOGA 2008`, `CAE Rev. 4`, `Canada SIC 1977`). Прочие национальные системы сохраняют название, которое дал реестр; `null`, если реестр её не называет
`is_primary`	`true` для основного вида деятельности. Ровно одна запись является основной

Когда реестр указывает виды деятельности, но не содержит описания бизнеса, nature_of_business заполняется из названий видов деятельности. Контактные данные и альтернативные названия заполняются, когда они доступны, при этом явные правки пользователя или проверяющего всегда имеют приоритет. Структура владения (ownership)

Поле	Описание
`status`	`delivered`; `not_held`, когда реестр ответил по данным о собственности и не содержит эту компанию вообще, поэтому записи о собственности для выдачи нет; `unavailable`, когда данные не выданы по любой другой причине (запись без указания владельца, раздел о собственности не возвращён или поставщик данных не смог быть запрошен); `pending`, пока реестр ещё получает раздел о собственности; `not_requested` на уровне Basic
`tier_requested` / `tier_delivered`	`basic`, `shareholders` или `ubo`. Запрос UBO, на который ответили только прямые акционеры, выдаётся и тарифицируется как `shareholders`
`unavailable_reason`	Причина, по которой запрошенный уровень собственности не был выдан: `no_owners_on_record`, `no_natural_person_owner`, `ownership_section_unavailable`, `company_not_found`, `ambiguous_company_match`, `missing_registration_number`, `entity_type_not_covered`, `provider_unavailable` или `other`. `null`, когда собственность выдана
`direct_ownership_complete`	`true`, когда заявленные доли прямых акционеров в сумме дают 100% (с погрешностью округления в один процентный пункт), `false`, когда не дают, `null`, когда собственность не выдана или какая-либо доля не указана
`unresolved[]`	Части цепочки собственности, которые реестр не смог установить, в виде `{ reason, section }` (например, `no_group_structure_on_record` для `group_structure`: прямые владельцы известны, корпоративная группа над ними в реестре не значится)

Детали реестра (registry_data) Собственные сведения Didit о проверке по реестру, а не запись источника реестра. Каждый ключ необязателен и присутствует, только если у компании есть для него значение, при этом могут добавляться новые ключи: для всего, что покрывают канонические поля выше, читайте именно их.

Поле	Описание
Факты реестра (`legal_address`, `registered_address`, `registration_date`, `dissolution_date`, `registry_status`, `verification_status`, `company_type`, и остальные поля, которые принимает update-data)	Строки. Правки, внесённые через update-data, и факты, которые реестр указывает, но для которых нет отдельного поля (`registration_date`, `dissolution_date`)
`ownership_error`	Причина, по которой запрошенный уровень собственности не был выдан, теми же кодами, что и `ownership.unavailable_reason` (`no_owners_on_record`, `ownership_section_unavailable`, `company_not_found`, `provider_unavailable`, `other` и другие)
`section_errors`	Разделы, которые реестр не вернул, с ключом по разделу (`officers`, `shareholders`, `group_structure`), каждый в виде `{ status_code }`
`ubo_resolution`	Как уровень UBO прошёл по цепочке: `parent_chain[]` и `subsidiaries[]` в виде `{ name, country_code, registration_number }`, а `unresolved[]` в виде `{ reason, section }`
`lite_enrichment`	Пустые поля Lite, которые заполнил другой реестровый источник страны: `{ fields[], people_added }`
`registry_metadata`, `registry_sources[]`, `previous_names[]`, `parent_companies[]`, `documents_available`	Только для старых записей реестра: собственные поля реестра, официальные реестры, из которых читались данные (`{ name, source_type }`, названы только официальные реестры), прежние названия, названия материнских компаний и количество доступных документов

Структура элемента списка должностных лиц (внутри `company.officers`)

{
  "uuid": "...",
  "name": "Jane Doe",
  "first_name": "Jane",
  "last_name": "Doe",
  "date_of_birth": null,
  "date_of_birth_year": 1983,
  "date_of_birth_month": 2,
  "address": "1 Example Street, London",
  "appointment_date": "2024-07-01",
  "termination_date": null,
  "designation": "Director",
  "role": "director",
  "nationality": "USA",
  "is_active": true,
  "kyc_status": "Approved",
  "kyc_session_url": "https://verify.didit.me/..."
}

date_of_birth заполняется только тогда, когда реестр предоставляет полную дату. Если реестр указывает только год или месяц и год, используйте date_of_birth_year и date_of_birth_month: отсутствующий день никогда не выводится. Имена, данные о рождении, адрес и даты назначения остаются доступными как в списке должностных лиц компании, так и в реестровом списке ключевых лиц.

Структура элемента списка бенефициарных владельцев (внутри `company.beneficial_owners`)

{
  "uuid": "...",
  "name": "John Doe",
  "first_name": "John",
  "last_name": "Doe",
  "entity_type": "person",
  "date_of_birth": null,
  "country_of_birth": null,
  "email": null,
  "company_name": null,
  "registration_number": null,
  "nationality": null,
  "designation": null,
  "appointment_date": null,
  "voting_min_shares": null,
  "voting_max_shares": null,
  "roles": ["ubo"],
  "ownership_min_shares": "40",
  "ownership_max_shares": "40",
  "is_active": true,
  "kyc_status": "Pending",
  "kyc_session_url": "https://verify.didit.me/...",
  "effective_ownership_percent": 40.0,
  "shareholding": {
    "share_class": "Ordinary",
    "number_of_shares": 40,
    "currency": "GBP",
    "nominal_value": 1,
    "total_value": null,
    "percentage": 40
  }
}

kyc_status использует проекцию, безопасную для B2C: Approved, Declined или Pending (полные состояния сессии сводятся к Pending, пока KYC не завершён). shareholding описывает, какой долей владеет владелец, в одной и той же структуре для каждой страны и каждого источника реестра: share_class, number_of_shares, currency, nominal_value, total_value и percentage (точная доля с четырьмя знаками после запятой). Значение равно null, когда реестр не указывает владение. Диапазон, например от 25 до 50% у UK PSC, не является долей: percentage равен null, а диапазон остаётся в ownership_min_shares / ownership_max_shares. И акционеры, и UBO перечислены в beneficial_owners; поле roles позволяет их различать.

`key_people_checks[]`

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

{
  "status": "Approved",
  "node_id": "feature_kyb_key_people",
  "registry": {
    "officers": [ ...registry-derived officers... ],
    "beneficial_owners": [ ...registry-derived UBOs... ]
  },
  "submitted": {
    "parties": [ ...user-submitted key-people records... ]
  },
  "ubo_kyc_summary": {
    "total": 2,
    "approved": 1,
    "flagged": 0,
    "pending": 1
  },
  "warnings": []
}

registry.officers / registry.beneficial_owners: стороны, извлечённые из проверки реестра.
submitted.parties: стороны, которые администратор компании явно добавил в процессе Key People (записи с source = "USER").

`registry.officers[]` / `registry.beneficial_owners[]`

Данные реестра совпадают с company.officers / company.beneficial_owners выше. Key People дополнительно включает статус AML и подробную связь с верификацией, например kyc_session_id и поля сценария верификации. Списки компании сохраняют прежний упрощённый статус KYC и URL верификации.

`submitted.parties[]`

Стороны, добавленные пользователем, содержат связь с их KYC или дочерней KYB-сессией:

{
  "uuid": "...",
  "entity_type": "person",
  "name": "Alice Chen",
  "first_name": "John",
  "last_name": "Doe",
  "email": "alex.sample@example.com",
  "role": "ubo",
  "ownership_percent": 35.0,
  "nationality": "USA",
  "position": "CEO",
  "date_of_birth": "1990-01-01",
  "phone_number": "+34612345678",
  "source": "USER",
  "requires_verification": true,
  "is_skipped": false,
  "kyc_session_id": "sess-xyz...",
  "kyc_session_status": "Not Started",
  "kyc_session_url": "https://verify.didit.me/...",
  "kyc_session_deleted": false,
  "custom_fields": { }
}

Корпоративные стороны (entity_type: "company") дополнительно содержат company_name, registration_number и kyb_sub_session_id / kyb_sub_session_status / kyb_sub_session_deleted, если для корпоративных UBO включена вложенная KYB-проверка. kyc_session_deleted (а также его корпоративный аналог kyb_sub_session_deleted) имеет значение true, если дочерняя сессия стороны была удалена. Удалённая дочерняя сессия сохраняет тот статус, который у неё был на момент удаления, и уже не может завершиться, поэтому ориентируйтесь на этот флаг, а не на статус: соответствующий *_session_url возвращается как null, потому что ссылка больше не работает, а проверка Key People переходит в In Review вместо бесконечного ожидания. Удаление дочерней сессии никогда не засчитывается как успешная проверка. Освободите сторону от проверки с помощью PATCH /v3/session/{id}/kyb/parties/{party_uuid}/, чтобы KYB могла завершиться.

`ubo_kyc_summary`

Сводный прогресс KYC по UBO, удобен для одной карточки на панели управления:

Поле	Значение
`total`	Количество активных UBO, к которым привязана KYC-сессия
`approved`	UBO, у которых KYC-сессия имеет статус `Approved`
`flagged`	UBO, у которых KYC-сессия имеет статус `Declined` или `In Review`
`pending`	Все остальные (их проверка ещё не завершена)

Возвращает null, если ни к одному UBO не привязана KYC-сессия.

`document_verifications[]`

Документы, сгруппированные по узлам:

{
  "status": "Approved",
  "node_id": "feature_kyb_documents",
  "items": [
    {
      "uuid": "...",
      "document_type": "LEGAL_PRESENCE",
      "document_subtype": "CERTIFICATE_OF_INCORPORATION",
      "document_group": "LEGAL_PRESENCE",
      "status": "Approved",
      "file_url": "https://didit-storage.s3...",
      "document_metadata": {
        "file_size": 246810,
        "content_type": "application/pdf",
        "creation_date": "2024-05-15",
        "modified_date": "2024-05-15",
        "overlay_manipulation": null
      },
      "ocr_data": {
        "company_name": "Acme Corporation Limited",
        "registration_number": "12345678",
        "incorporation_date": "2010-05-14"
      }
    }
  ],
  "groups": {
    "LEGAL_PRESENCE": { "total": 1, "approved": 1, "pending": 0, "declined": 0, "in_review": 0, "other": 0, "missing": 0 },
    "OWNERSHIP_STRUCTURE": { "total": 1, "approved": 1, "pending": 0, "declined": 0, "in_review": 0, "other": 0, "missing": 0 }
  },
  "required_groups": ["LEGAL_PRESENCE", "OWNERSHIP_STRUCTURE"],
  "warnings": []
}

Поле	Описание
`items[]`	Отдельные строки документов. У каждой свои `status`, `document_type` и `document_group` (группа), `document_subtype`, `file_url` (подписанная ссылка), `document_metadata` и извлечённые данные OCR
`groups`	Счётчики прогресса по группам с ключом, равным значению группы (`LEGAL_PRESENCE`, `COMPANY_DETAILS`, `OWNERSHIP_STRUCTURE`, `REPRESENTATIVES_AUTHORIZATION`, а также `OTHER` для документов без классификации). Каждая группа содержит `total`, `approved`, `pending`, `declined`, `in_review`, `other` и `missing`. См. группы документов KYB
`required_groups`	Группы, которые ваш сценарий верификации пометил как обязательные. Одобрение сессии возможно только при выполнении требований всех этих групп

Метаданные корпоративных документов

Для корпоративных PDF-документов поле items[].document_metadata.overlay_manipulation может содержать криминалистические признаки возможного редактирования наложенного текста. Если поле присутствует, оно включает:

Поле	Описание
`analysis_incomplete`	Присутствует и равно `true` только в случае, когда файл не удалось проверить полностью. Там, где это возможно, результаты проверки сохраняются, а документ получает `KYB_DOCUMENT_UNPROVEN_TEXT_REPLACEMENT`.
`detected`	Найдены ли признаки редактирования наложенного текста
`analyzed`	Удалось ли проанализировать PDF
`signals`	Сработавшие криминалистические сигналы, например `duplicate_font_subset` или `glyph_fragmentation`
`manipulated_regions`	Прямоугольники в координатах страницы PDF вокруг предполагаемо отредактированного текста: `page`, `x`, `y`, `width`, `height`, `page_width`, `page_height`

Поле имеет значение null, если признаков редактирования наложенного текста не найдено, документ не является PDF или PDF не удалось проанализировать.

`aml_screenings[]`

Проверки AML на уровне компании и (если сценарий их подключает) на уровне физических лиц.

{
  "node_id": "feature_aml",
  "status": "Approved",
  "total_hits": 0,
  "score": 0,
  "entity_type": "COMPANY",
  "screened_data": {
    "company_name": "Acme Corporation Limited",
    "country_code": "GBR"
  },
  "is_ongoing_monitoring_enabled": true,
  "next_ongoing_monitoring_bill_date": "2027-04-16",
  "last_ongoing_screening_at": "2026-09-12T04:03:11Z",
  "last_ongoing_screening_datasets_updated_at": null,
  "hits": [],
  "warnings": []
}

Если total_hits > 0, каждое совпадение содержит оценку совпадения, оценку риска, источники списков наблюдения и review_status для каждого совпадения, который можно обновить через endpoint update-aml-hit-status. Структура совпадения описана в отчёте AML-скрининга.

Общие массивы функций

phone_verifications, email_verifications, questionnaire_responses и ip_analyses используют те же структуры элементов, что и пользовательские (KYC) сессии. Они имеют значение null, если сценарий их не включает. Схемы элементов см. в ответе KYC. Поле signatures присутствует, если в сценарии есть шаг электронной подписи. Бизнес-сессия содержит по одному элементу на каждое ключевое лицо, которое подписывает от имени компании, с signer.capacity: "company", названием компании и ролями ключевого лица. См. отчёт об электронной подписи.

Группы предупреждений

Предупреждения о верификации бизнеса сгруппированы по функции, которая их сформировала:

KYB_REGISTRY: доступность реестра, структура владения, деятельность компании и ограничения по странам.
KYB_DOCUMENTS: извлечение данных из корпоративных документов, перекрёстная проверка, метаданные, манипуляции, подтип, возраст и ограничения на количество попыток.
AML: совпадения при AML-скрининге компании или отсутствующие данные скрининга.
KYB_KEY_PEOPLE: проблемы на уровне физических лиц, связанные с директорами, должностными лицами, UBO или представителями.
PHONE: риск номера телефона, дублирование, блокировка и попытки ввода кода подтверждения.
EMAIL: риск адреса электронной почты, доставляемость, дублирование, блокировка и попытки ввода кода подтверждения.
QUESTIONNAIRE: пользовательские правила статуса, основанные на ответах на анкету.
LOCATION: Анализ устройства и IP, проблемы частной сети, блокировка IP-адресов и устройств, а также дублирование устройства и IP-адреса.
SIGNATURE: отказы при электронной подписи, неудачные подтверждения кодом, несовпадение имени подписанта, непроверенные подписанты, изменённые документы и отсутствующие данные полей. См. предупреждения электронной подписи.

Полный список кодов предупреждений см. в предупреждениях о верификации бизнеса.

Фильтрация полей по сценарию

Сценарии могут ограничивать, какие вложенные поля отображаются в каждом элементе функции, с помощью response_attributes. Поля status, warnings и node_id включаются всегда. Все остальные поля, которых нет в списке разрешённых, обнуляются: ключ остаётся в ответе, чтобы схема оставалась стабильной.

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

Статусы

Что означает каждое значение статуса.

Оценка риска

Что определяет результат KYB.

Отчёт AML

Полный справочник по данным о срабатываниях AML.

Ключевые лица

Как стороны попадают в группы registry и submitted из реестра и из данных, переданных пользователем.

Документы

Группы документов, OCR и перекрёстная проверка.

Получение сессии

Полный справочник по endpoint, включая примеры ответов.

Начало работы

Функции

Профили компаний

Справочник

Консоль

Схема ответа KYB: payload решения

Структура верхнего уровня

Общие поля верхнего уровня

`registry_checks[]`

Блок `company`

Один формат для всех стран и источников реестров

Структура элемента списка должностных лиц (внутри `company.officers`)

Структура элемента списка бенефициарных владельцев (внутри `company.beneficial_owners`)

`key_people_checks[]`

`registry.officers[]` / `registry.beneficial_owners[]`

`submitted.parties[]`

`ubo_kyc_summary`

`document_verifications[]`

Метаданные корпоративных документов

`aml_screenings[]`

Общие массивы функций

Группы предупреждений

Фильтрация полей по сценарию

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

Статусы

Оценка риска

Отчёт AML

Ключевые лица

Документы

Получение сессии

​Структура верхнего уровня

​Общие поля верхнего уровня

​registry_checks[]

​Блок company

​Один формат для всех стран и источников реестров

​Структура элемента списка должностных лиц (внутри company.officers)

​Структура элемента списка бенефициарных владельцев (внутри company.beneficial_owners)

​key_people_checks[]

​registry.officers[] / registry.beneficial_owners[]

​submitted.parties[]

​ubo_kyc_summary

​document_verifications[]

​Метаданные корпоративных документов

​aml_screenings[]

​Общие массивы функций

​Группы предупреждений

​Фильтрация полей по сценарию

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

Статусы

Оценка риска

Отчёт AML

Ключевые лица

Документы

Получение сессии

Структура верхнего уровня

Общие поля верхнего уровня

`registry_checks[]`

Блок `company`

Один формат для всех стран и источников реестров

Структура элемента списка должностных лиц (внутри `company.officers`)

Структура элемента списка бенефициарных владельцев (внутри `company.beneficial_owners`)

`key_people_checks[]`

`registry.officers[]` / `registry.beneficial_owners[]`

`submitted.parties[]`

`ubo_kyc_summary`

`document_verifications[]`

Метаданные корпоративных документов

`aml_screenings[]`

Общие массивы функций

Группы предупреждений

Фильтрация полей по сценарию

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