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

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

> Аннотированный payload решения KYB от Didit: проверки реестров, ключевые лица, сводки UBO KYC, документы, AML-скрининг. От $2.00 за проверку.

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

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

```json theme={null}
{
  "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 | Общий статус сессии (см. [статусы](https://docs.didit.me/ru/business-verification/statuses.md)) |
| `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).

```json theme={null}
{
  "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` | Структурированные предупреждения и записи журнала, относящиеся к этой проверке в реестре. См. [Предупреждения верификации бизнеса](https://docs.didit.me/ru/business-verification/warnings.md). |

### Блок `company`

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

```json theme={null}
{
  "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` и др.). См. [статусы](https://docs.didit.me/ru/business-verification/statuses.md#статус-реестра-от-провайдера) |
| `is_from_registry` | `true`, если данные получены из официального реестра; `false` для данных, введённых вручную |
| `fetch_status` | `pending`, `resolved` или `failed`: состояние запроса к реестру |
| `verification_status` | `verified`, `failed` или `unknown` |
| `risk_level` | Необязательное значение, передаваемое из источника реестра. Обычно `null`: Didit не вычисляет уровень риска, поэтому принимайте решение на основе `warnings[]` и `status` сессии |
| `registry_monitoring` | Последний мониторинг реестра для компании или `null`, если его нет. Заполняется только после того, как станет доступен [мониторинг реестров](https://docs.didit.me/ru/business-verification/ownership.md#мониторинг-акционеров-и-ubo). Поля: `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](https://docs.didit.me/ru/sessions-api/update-data.md), и сведения из реестра, для которых нет собственного поля. Здесь никогда не содержится собственная запись источника реестра. Состав ключей зависит от компании, и это не стабильный контракт: используйте канонические поля |
| `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`. См. [Проверка НДС и налогового идентификатора](https://docs.didit.me/ru/business-verification/company-data.md#vat-и-проверка-налогового-номера) |
| `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`.
Ту же структуру возвращают [решение](https://docs.didit.me/ru/sessions-api/retrieve-session.md), отдельные endpoint [KYB-реестра](https://docs.didit.me/ru/standalone-apis/kyb-registry-ubo.md) и размещённый процесс верификации.

**Адрес** (каждый элемент `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](https://docs.didit.me/ru/sessions-api/update-data.md)) | Строки. Правки, внесённые через 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`)

```json theme={null}
{
  "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`)

```json theme={null}
{
  "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.

```json theme={null}
{
  "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-сессией:

```json theme={null}
{
  "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}/`](https://docs.didit.me/ru/sessions-api/update-data#пропуск-стороны-key-people), чтобы 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[]`

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

```json theme={null}
{
  "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](https://docs.didit.me/ru/business-verification/documents.md#группы-документов) |
| `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 на уровне компании и (если сценарий их подключает) на уровне физических лиц.

```json theme={null}
{
  "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-скрининга](https://docs.didit.me/ru/core-technology/aml-screening/report-aml-screening.md).

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

`phone_verifications`, `email_verifications`, `questionnaire_responses` и `ip_analyses` используют те же структуры элементов, что и пользовательские (KYC) сессии. Они имеют значение `null`, если сценарий их не включает. Схемы элементов см. в [ответе KYC](https://docs.didit.me/ru/sessions-api/retrieve-session.md).

Поле `signatures` присутствует, если в сценарии есть шаг [электронной подписи](https://docs.didit.me/ru/core-technology/electronic-signature/overview.md). Бизнес-сессия содержит по одному элементу на каждое ключевое лицо, которое подписывает от имени компании, с `signer.capacity: "company"`, названием компании и ролями ключевого лица. См. [отчёт об электронной подписи](https://docs.didit.me/ru/core-technology/electronic-signature/report-electronic-signature.md).

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

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

* `KYB_REGISTRY`: доступность реестра, структура владения, деятельность компании и ограничения по странам.
* `KYB_DOCUMENTS`: извлечение данных из корпоративных документов, перекрёстная проверка, метаданные, манипуляции, подтип, возраст и ограничения на количество попыток.
* `AML`: совпадения при AML-скрининге компании или отсутствующие данные скрининга.
* `KYB_KEY_PEOPLE`: проблемы на уровне физических лиц, связанные с директорами, должностными лицами, UBO или представителями.
* `PHONE`: риск номера телефона, дублирование, блокировка и попытки ввода кода подтверждения.
* `EMAIL`: риск адреса электронной почты, доставляемость, дублирование, блокировка и попытки ввода кода подтверждения.
* `QUESTIONNAIRE`: пользовательские правила статуса, основанные на ответах на анкету.
* `LOCATION`: Анализ устройства и IP, проблемы частной сети, блокировка IP-адресов и устройств, а также дублирование устройства и IP-адреса.
* `SIGNATURE`: отказы при электронной подписи, неудачные подтверждения кодом, несовпадение имени подписанта, непроверенные подписанты, изменённые документы и отсутствующие данные полей. См. [предупреждения электронной подписи](https://docs.didit.me/ru/core-technology/electronic-signature/warnings-electronic-signature.md).

Полный список кодов предупреждений см. в [предупреждениях о верификации бизнеса](https://docs.didit.me/ru/business-verification/warnings.md).

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

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

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

> [card] [Статусы](https://docs.didit.me/ru/business-verification/statuses.md)
>
> Что означает каждое значение статуса.

> [card] [Оценка риска](https://docs.didit.me/ru/business-verification/risk-assessment.md)
>
> Что определяет результат KYB.

> [card] [Отчёт AML](https://docs.didit.me/ru/core-technology/aml-screening/report-aml-screening.md)
>
> Полный справочник по данным о срабатываниях AML.

> [card] [Ключевые лица](https://docs.didit.me/ru/business-verification/key-people.md)
>
> Как стороны попадают в группы `registry` и `submitted` из реестра и из данных, переданных пользователем.

> [card] [Документы](https://docs.didit.me/ru/business-verification/documents.md)
>
> Группы документов, OCR и перекрёстная проверка.

> [card] [Получение сессии](https://docs.didit.me/ru/sessions-api/retrieve-session.md)
>
> Полный справочник по endpoint, включая примеры ответов.


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