Импорт общей сессии API: многоразовый KYC и KYB

Список функций верификации, настроенных для этой сессии, в виде отображаемых имён: ID_VERIFICATION, NFC, LIVENESS, FACE_MATCH, POA, PHONE, EMAIL_VERIFICATION, AML, IP_ANALYSIS, DATABASE_VALIDATION, QUESTIONNAIRE, AGE_ESTIMATION, FACE_SEARCH, GEOLOCATION (проверка местоположения) (сессии Верификации бизнеса используют набор функций KYB: KYB_REGISTRY, KYB_DOCUMENTS, KYB_KEY_PEOPLE, AML, PHONE, EMAIL_VERIFICATION, IP_ANALYSIS, QUESTIONNAIRE). При include=events каждая запись становится объектом {feature, node_id} вместо простой строки, а функция электронной почты переименовывается: в режиме событий она отображается как EMAIL вместо используемого здесь EMAIL_VERIFICATION.

Массив отчётов верификации личности (OCR), сформированных шагами проверки документов, удостоверяющих личность, в графе сценария. Всегда JSON-массив — считывайте id_verifications[0] и выполняйте итерацию, если ваш сценарий может выполнять более одной проверки документов, удостоверяющих личность (например, основную проверку плюс дополнительную). Имеет значение null, пока хотя бы один шаг проверки документов, удостоверяющих личность, не предоставит данные. Каждый элемент представляет собой полный отчёт, включая node_id, status на уровне функции, извлечённые поля документа, URL-адреса изображений, оценки качества, MRZ, разобранный адрес, совпадения между сессиями и warnings[].

Массив отчётов NFC / электронных паспортов, сформированных шагами NFC в графе сценария. Это всегда JSON-массив, а не отдельный объект nfc — считывайте nfc_verifications[0] и выполняйте итерацию, если ваш сценарий может выполнять NFC-проверку более одного раза. Имеет значение null, пока хотя бы один шаг NFC не предоставит данные. Каждый элемент представляет собой полный отчёт, включая node_id, status на уровне функции, chip_protocol, chip_data, authenticity (целостность SOD + DG), certificate_summary и warnings[]. Японская карта My Number Card считывается через JPKI вместо ICAO 9303: её элемент содержит chip_protocol: "jpki", содержит свои данные в jpki, а поля ICAO оставляет равными null. Если шаг NFC был обойдён ещё до того, как его можно было предложить (документ без чипа, отсутствие сертификата, не заявлена поддержка NFC, нечитаемый ключ MRZ, недоступность JPKI для My Number Card), этот массив остаётся null, а причина указывается в nfc_skip_reason; пропуск на самом шаге (пользователь нажал кнопку пропуска или считыватель оказался недоступен во время сканирования) всё равно формирует отчёт с is_nfc_skipped: true.

Массив отчётов проверки живости, сформированных шагами проверки живости в графе сценария. Всегда JSON-массив — никогда не отдельный объект liveness. Имеет значение null, пока хотя бы один шаг проверки живости не предоставит данные. Каждый элемент представляет собой полный отчёт, включая node_id, status на уровне функции, method, score, reference_image, video_url, опциональную age_estimation, matches[] между сессиями и warnings[].

Массив отчётов сравнения лиц, сформированных шагами сравнения лиц в графе сценария. Всегда JSON-массив — никогда не отдельный объект face_match. Имеет значение null, пока хотя бы один шаг сравнения лиц не предоставит данные. Каждый элемент представляет собой полный отчёт, включая node_id, status на уровне функции, score сходства, source_image, target_image и warnings[].

Массив отчётов проверки телефона — всегда JSON-массив, а не отдельный объект phone. Имеет значение null, пока хотя бы один шаг проверки телефона не предоставит данные. Каждый элемент представляет собой полный отчёт, включая node_id, status на уровне функции, номер телефона и метаданные страны, lifecycle[], matches[] и warnings[].

Массив отчётов проверки электронной почты — всегда JSON-массив, а не отдельный объект email. Имеет значение null, пока хотя бы один шаг проверки электронной почты не предоставит данные. Каждый элемент представляет собой полный отчёт, включая node_id, status на уровне функции, адрес электронной почты, данные об утечках, lifecycle[], matches[] и warnings[].

Массив отчётов подтверждения адреса (POA) — всегда JSON-массив, а не отдельный объект poa. Имеет значение null, пока хотя бы один шаг подтверждения адреса не предоставит данные. Каждый элемент представляет собой полный отчёт, включая node_id, status на уровне функции, URL-адрес файла документа, орган выдачи, даты, разобранный адрес и warnings[].

Отчёты Document AI, сгруппированные по узлам сценария — всегда JSON-массив, а не одиночный объект. null, пока хотя бы один шаг Document AI не сформирует данные. Присутствует, только когда session_kind = user. Каждый элемент представляет собой группу узла с агрегированным status, node_id, массивом items[] с результатами по каждому документу (извлечённые данные с ключами по настроенному ключу поля) и warnings.

Массив отчётов с ответами на анкеты — всегда JSON-массив, а не отдельный объект questionnaire. Имеет значение null, пока хотя бы один шаг анкеты не предоставит данные. Каждый элемент представляет собой полный отчёт, включая node_id, метаданные анкеты, разделы с элементами формы и ответы пользователя.

Результаты верификации банковских счетов, по одному элементу на каждый шаг проверки банка, для проверки пользователей и верификации бизнеса. Имеет значение null, пока шаг не сформирует результат. Поле method каждого элемента указывает, как был подтверждён счёт: open_banking (вход в банк) или account_lookup (проверка счёта), либо резервные варианты statement или microdeposits, и none, если пользователь продолжил без банка до оценки какой-либо попытки (continued_without_bank). См. раздел Методы верификации счетов.

Результаты электронной подписи, по одному элементу на каждого подписанта и шаг подписания, для Проверки пользователей и Верификации бизнеса (KYB). Присутствует только в том случае, если в сценарии есть шаг электронной подписи; пустой массив, пока подписант не дойдёт до него. См. Отчёт об электронной подписи.

Массив отчётов AML-скрининга — всегда массив JSON, а не одиночный объект aml. Имеет значение null, пока хотя бы один шаг AML не сгенерирует данные. Каждый элемент представляет собой полный отчёт, включая node_id, status на уровне функции, total_hits, entity_type, hits[], score, screened_data, is_ongoing_monitoring_enabled и warnings[].

Массив отчётов анализа устройства и IP — всегда JSON-массив, а не отдельный объект ip_analysis. Имеет значение null, пока хотя бы один шаг анализа IP не предоставит данные. Каждый элемент представляет собой полный отчёт, включая node_id, status на уровне функции, данные об IP и геолокации, цифровой отпечаток устройства и warnings[]. Записи с повторяющимися значениями (node_id, ip_address, device_fingerprint) дедуплицируются на стороне сервера.

Массив результатов верификации местоположения, по одному на каждый шаг верификации местоположения: принятая попытка этого шага. Имеет значение null, пока шаг верификации местоположения не предоставит данные. Более ранние попытки того же шага находятся в geolocation_attempts.

Каждая попытка каждого шага проверки местоположения (Location) в этой сессии, начиная с самых старых. Попытки, заменённые повторной отправкой, исключены. Сценарий, который скрывает geolocation_checks через свои атрибуты ответа, также скрывает и этот список.

Массив отчётов Проверки по базам данных — всегда массив JSON, а не отдельный объект database_validation. Имеет значение null, пока хотя бы один шаг проверки по базам данных не вернёт данные. Каждый элемент представляет собой полный отчёт, включая node_id, status на уровне функции, screened_data, массив validations[] для каждого сервиса (каждый с данными из реестра source_data) и warnings[]. Поля screened_data и source_data различаются в зависимости от страны:

ARG (Аргентина): screened_data: {document_number, selfie, gender, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name, date_of_birth, date_of_death, tax_id, tax_id_type, face_match_score, sit_1_since, banks, last_position, highest_position, rejected_checks}. Использует биометрическую валидацию RENAPER со сравнением лиц. Пол определяется автоматически на основе анализа лица или имени, если он отсутствует в документе (например, в водительских удостоверениях)

BOL (Боливия): screened_data: {document_number, date_of_birth, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name, date_of_birth, gender}

BRA (Бразилия): screened_data: {tax_number, first_name, last_name, date_of_birth}. source_data всегда включает {identification_number, first_name, last_name, date_of_birth, lgpd_minor, minor_under_18, minor_under_16} при успешных совпадениях по CPF. При успешных запросах по совершеннолетним эти флаги устанавливаются в false. Сервис Receita Federal Consulta CPF может возвращать HTTP 422 (несовершеннолетний до 18 лет) или 451 (до 16 лет) с данными, скрытыми в соответствии с LGPD; в таких случаях source_data устанавливает соответствующие флаги несовершеннолетнего в true, включает HTTP-статус вышестоящего сервиса, а валидация на уровне полей получает значение no_match. Полный список кодов см. в разделе по Бразилии справочника Database Validation Outcome Codes.

CHL (Чили): screened_data: {personal_number, first_name, last_name, date_of_birth}. source_data: {identification_number, first_name, last_name, date_of_birth, gender}

COL (Колумбия): screened_data: {document_number, document_type, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name, date_of_birth, document_type}

CRI (Коста-Рика): screened_data: {personal_number, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name}

DOM (Доминиканская Республика): screened_data: {personal_number}. source_data: {identification_number} (возвращает только valid/invalid)

ECU (Эквадор): screened_data: {personal_number, first_name, last_name}. source_data: {identification_number, first_name, last_name, street, formatted_address, gender, nationality, education, marital_status, spouse, mother_name, father_name, profession}

ESP (Испания): screened_data: {personal_number, document_type, expiration_date, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name, document_type, expiration_date}

GTM (Гватемала): screened_data: {document_number, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name}

HND (Гондурас): screened_data: {document_number, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name}

MEX (Мексика): screened_data: {personal_number (CURP), first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name, date_of_birth, gender, nationality, curp_status, state_of_birth, doc_probatorio, registration_year, registration_state, registration_municipality, num_acta, crip, issuing_state_code, foreign_registry_number, folio_carta, folio_certificado}. Использует реестр актов гражданского состояния RENAPO. Отдельный сервис проверки действительности INE также доступен для MEX в качестве дополнительной поочерёдной валидации.

PAN (Панама): screened_data: {personal_number, selfie}. source_data: {identification_number}. Использует биометрическую валидацию SIB

PER (Перу): screened_data: {personal_number (DNI), first_name, last_name}. source_data: {identification_number, first_name, last_name, paternal_name, maternal_name, verification_number, verification_letter}

PRY (Парагвай): screened_data: {document_number, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name}

SLV (Сальвадор): screened_data: {document_number, date_of_birth, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name}

URY (Уругвай): screened_data: {personal_number, date_of_birth, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name}

VEN (Венесуэла): screened_data: {document_number, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name, gender, date_of_birth, document_type}

Проверки по реестру компаний. Присутствует только в случае, если session_kind = business. Каждый элемент содержит полный payload реестра компаний.

Агрегированные проверки ключевых лиц. Присутствует только при session_kind = business. Каждый элемент использует структуру с двумя категориями (registry, submitted, ubo_kyc_summary).

Проверки верификации документов, сгруппированные по узлам сценария. Присутствует, только если session_kind = business.

Возвращается только при include=resubmissions, для сессий пользователей и сессий компаний. По одной записи на каждый запрос повторной отправки, начиная с самых старых. Каждая запись содержит результаты, возвращённые повторно отправленными шагами до запроса, поэтому более ранние отправки остаются доступными для чтения. Удаление сессии удаляет все отправки.