Обзор
Предупреждения в отчёте о верификации личности отмечают каждое условие, зафиксированное Didit при считывании и валидации документа. Они передаются в массивеwarnings[] каждого элемента списка id_verifications[] (см. Отчёт о верификации личности) в структуре, описанной в разделе Модели данных — Объект предупреждения: feature, risk, additional_data, log_type, short_description, long_description, node_id.
Каждое предупреждение имеет три уровня:
- Код
risk— неизменный идентификатор, который можно использовать для сопоставления в вашем коде. log_type— определяется действием, назначенным риску в вашей конфигурации на момент оценки: Отклонить →error, Проверить →warning, любое другое →information.- Влияние на решение — задаётся настраиваемыми группами рисков сценария. Один и тот же код
riskможет приводить к результатам Одобрено, На проверке или Отклонено в зависимости от конфигурации вашего приложения.
Условия автоматического отклонения
В сценариях следующие риски всегда приводят к переводу отчёта о верификации личности (и сессии) в статусDeclined. Их нельзя перенастроить:
Для автономного OCR API набор безоговорочного отклонения включает:
DOCUMENT_EXPIRED, MINIMUM_AGE_NOT_MET, PORTRAIT_IMAGE_NOT_DETECTED, SCREEN_CAPTURE_DETECTED, PRINTED_COPY_DETECTED, PORTRAIT_MANIPULATION_DETECTED и PUBLIC_DOCUMENT_IMAGE_DETECTED. В сценариях минимальный возраст настраивается (по умолчанию Отклонить), а три риска проверки живости документа определяются порогами (см. ниже).
Настраиваемые риски этого API принимают параметры запроса DECLINE или NO_ACTION, а не решение Проверка. Единственный результат «На проверке», который он может возвращать, не настраивается: когда запрошенная проверка живости документа не позволяет получить пригодную оценку, возвращается ответ In Review с предупреждением DOCUMENT_LIVENESS_NOT_COMPUTED (см. Живость документа).
Настраиваемые параметры верификации
В консоли Didit оставшиеся риски верификации личности объединены в настройки, для которых можно задать действие Одобрить, Проверить или Отклонить (для каждого сценария и для каждого узла в сценариях с графом):
Риски дубликата при тихом захвате и списка блокировки возникают в результате Поиска по лицу на селфи, сделанном при захвате документа. Поиск выполняется, если включён параметр Поиск по лицу при тихом захвате (
document_selfie_face_search_enabled) (по умолчанию он включён) и Поиск по лицу не отключён на шаге проверки живости; в противном случае ни один из этих шести рисков не формируется.
Два семейства рисков верификации личности управляются порогами, а не переключателями Одобрить/Проверить/Отклонить:
- Проверка живости документа —
SCREEN_CAPTURE_DETECTED,PRINTED_COPY_DETECTED,PORTRAIT_MANIPULATION_DETECTED. Для каждого вида мошенничества предусмотрены собственные пороги отклонения и проверки: балл ниже порога отклонения →error+ Отклонена; ниже порога проверки →warning+ На проверке; иначеinformation. - Сравнение лиц с разных камер —
LOW_FRONT_CAMERA_FACE_MATCH_SIMILARITY, регулируется параметрамиdocument_selfie_portrait_match_decline_threshold/document_selfie_portrait_match_review_threshold.
Настройка порогов проверки живости документа
В редакторе сценариев эти пороги находятся на вкладке Подделка шага Верификация личности, по одной карточке для каждого вида мошенничества: Замена портрета, Распечатанная копия и Снимок экрана. Каждая проверка выставляет документу балл от0 до 100 в зависимости от степени его подлинности. Более высокий балл означает более высокую вероятность того, что документ подлинный. Два значения на карточке делят эту шкалу на три диапазона:
Повышение любого из значений делает проверку более строгой: больше сессий попадает в диапазон выше этого значения. Снижение значения позволяет пропустить больше сессий. В редакторе значение Отклонить не может превышать значение Проверить. При вызове через API значение Отклонить выше значения Проверить удаляет диапазон «На проверке».
Значения платформы по умолчанию, используемые, если они не заданы в сценарии:
Начинайте со значений по умолчанию и изменяйте по одному значению за раз. На каждой карточке отображается значение по умолчанию и кнопка Сбросить к значению по умолчанию, чтобы вы всегда могли к нему вернуться. Редактор также предупреждает о следующих конфигурациях:
- Проверка на уровне
100. Проходят только сессии с идеальным баллом, поэтому практически каждая сессия переходит в статус «На проверке» или отклоняется. - Отклонить на уровне
100. Только идеальный балл позволяет избежать отклонения, поэтому практически каждая сессия отклоняется. - Оба значения на уровне
0. Ни один балл не будет помечен, поэтому проверка фактически отключена.
SCREEN_CAPTURE_DETECTED.
Сравнение лиц с разных камер использует тот же принцип с одним отличием на границе: балл, равный порогу проверки, всё равно переводит сессию в статус «На проверке».
Четыре риска, связанных с удостоверением личности, не настраиваются и не зависят от порогов. POSSIBLE_FRONT_CAMERA_FACE_IN_BLOCKLIST всегда направляет на этап Проверка: селфи, похожее на лицо из списка блокировки, но не являющееся подтвержденным совпадением, должен оценивать человек, оно никогда не отклоняется автоматически и никогда не игнорируется. BARCODE_SIGNATURE_INVALID всегда направляет на этап Проверка. Оно срабатывает только тогда, когда штрихкод содержит подпись органа выдачи, не прошедшую криптографическую проверку, поэтому нет такой конфигурации, при которой доказанная подделка была бы проигнорирована. DOCUMENT_BACK_SIDE_NOT_AVAILABLE всегда носит статус информация и никогда не влияет на решение: оно сообщает об ограничении каталога документов Didit, а не о свойстве представленного документа, поэтому ни при какой конфигурации оно не может привести к отклонению или отправке на проверку подлинного владельца.
FRONT_CAMERA_CAPTURED_DOCUMENT всегда направляет на этап Проверка.
Оно срабатывает только тогда, когда кадр с фронтальной камеры, сделанный во время сканирования документа, показывает документ, удостоверяющий личность, и ни одного человека, поэтому снимок, не дающий информации о том, кто держал документ, всегда поступает на проверку проверяющему.
Оно проверяется всякий раз, когда включено сопоставление селфи при захвате документа (is_document_selfie_portrait_match_enabled).
Сформированные предупреждения
Проверено поcollect_ocr_logs, процессу захвата документа и process_ocr_logs_and_get_status. Краткие описания ниже представляют собой точные строки short_description, возвращаемые API.
Распознавание и качество документа
Процесс захвата также может отклонить загрузку с кодами обратной связи
IMAGE_RESOLUTION_TOO_LOW, DOCUMENT_NOT_FULLY_VISIBLE, IMAGE_QUALITY_TOO_LOW и DOCUMENT_OCCLUSION_DETECTED (палец или посторонний предмет физически закрывает печатный текст). Каждый из них вызывает предложение переснять снимок в SDK и фиксируется в отчете как отдельный риск, обрабатываемый настройками Image Quality — DOCUMENT_OCCLUSION_DETECTED и IMAGE_QUALITY_TOO_LOW используют одно общее действие. Они относятся к процессу захвата: успешный повторный снимок снимает предупреждение. Вопрос о том, должно ли перекрытое поле влиять на решение, относится к отдельной проверке целостности CRITICAL_FIELD_OCCLUSION_DETECTED ниже, которая срабатывает во время принятия решения и по умолчанию имеет действие Review.Извлечение полей
MRZ, QR, штрихкод
Все три риска MRZ пропускаются для типов документов с заведомо ненадежными MRZ.Проверка подписи штрихкода в настоящее время охватывает национальные удостоверения личности Франции, чей штрихкод ANTS 2D-Doc подписан органом выдачи.
BARCODE_SIGNATURE_INVALID возникает только тогда, когда сама проверка подписи отклоняет payload. Штрихкод без подписи, с подписью органа, еще не входящего в хранилище доверенных сертификатов Didit, или с подписью, которую невозможно декодировать, считается неаутентифицированными данными и валидируется по MRZ и печатному тексту, как и раньше, без формирования этого риска.Штрихкоды водительских удостоверений США и Канады (AAMVA) не проверяются криптографически: цифровая подпись там является опциональной и зависит от юрисдикции, и ни одна юрисдикция не публикует ключи проверки, поэтому Didit лишь обнаруживает и фиксирует в журнале факт наличия подписи в payload; сама подпись никогда не проверяется. Сбои подписи AAMVA сегодня не служат сигналом риска. Измененный payload AAMVA проявляется только как BARCODE_VALIDATION_FAILED, и только если изменение также приводит к расхождению данных штрихкода с MRZ или печатным текстом/OCR - поддельная подпись на внутренне согласованном payload проходит вообще без какого-либо сигнала.При возникновении BARCODE_SIGNATURE_INVALID повторный снимок у пользователя никогда не запрашивается: подпись, не соответствующую payload, нельзя исправить с помощью более качественной фотографии.Сопоставление личности
Проверка живости документа (подделка)
Настраивается на основе порогов для каждого типа мошенничества в сценариях. В автономном OCR API эти три риска безоговорочно отклоняются, а запрошенная проверка, которая не дает пригодной оценки, возвращаетIn Review вместо одобрения.
Сами оценки присутствуют в каждом отчете V3 в виде document_liveness, в том числе когда предупреждения не срабатывали, поэтому одобренный документ по-прежнему можно проверить.
Целостность канала захвата
Поле
log_type отражает настроенное действие: error для отклонения, warning для проверки, information для отсутствия действия.
Рекомендуемое действие: считать отклоненную сессию результатом инъекционного захвата и предложить пользователю повторить попытку на физическом устройстве со встроенной камерой.
Сигналы, которые может сгенерировать реальный человек, никогда не приводят к срабатыванию INJECTION_ATTACK_DETECTED и остаются информационными.
Приложения, транслирующие изображение с реальной камеры, например телефон, используемый в качестве веб-камеры, или слой эффектов поверх реальной веб-камеры, не определяются как инъекционные атаки.
Это обнаружение инъекционных атак, которое работает отдельно от обнаружения атак предъявления (предъявление подделки настоящей камере).
Известные публичные изображения документов
Несовпадения с ожидаемыми данными
Когда вы передаетеexpected_details в сессию, Didit формирует предупреждение о несовпадении для каждого поля, значение которого не совпало. Одна группа (expected_details_mismatch_action, по умолчанию «На проверку») управляет маршрутизацией для всех этих случаев:
Каждое предупреждение о несовпадении содержит ожидаемые и извлеченные значения в
additional_data.
Возраст
Адрес
Межсессионные совпадения документов
В дополнение к предупреждениям выше, отчет по верификации личности V3 передает массивmatches[] — до 5 других документов в вашем приложении с такой же датой рождения, той же страной выдачи и очень похожим полным именем (для документов из списка блокировки дополнительно требуется точное совпадение номера документа), за исключением сессий, принадлежащих тому же пользователю. Документы, добавленные в ваш список блокировки, отображаются с флагом is_blocklisted: true. Документы из списка разрешений по-прежнему отображаются в совпадениях, но действие для дублирующегося пользователя по ним пропускается.
Каждое совпадение включает session_id, session_number, vendor_data, verification_date, user_details (name, document_type, document_number), status, is_blocklisted, api_service и подписанный front_image_url.
Примеры
Настраиваемое предупреждение при маршрутизации по умолчанию (информационное)
Автоматическое отклонение при истекшем сроке действия документа
Несовпадение с ожидаемыми данными с payload
Типы предупреждений
Каждому риску присваивается уровень серьезности на основе конфигурации вашего приложения. Существует три уровня серьезности:Связанные материалы
- Отчет о верификации личности — полная схема отчета и статусы.
- Мониторинг документов — как Didit выявляет несанкционированные изменения и межсессионные дубликаты.
- Webhooks — событие
session.status.updatedпередает предупреждения сразу после завершения шага верификации личности. - Модели данных — Верификация личности — каноническая схема полей.
- Модели данных — Объект предупреждения — структура каждого элемента в
warnings[].