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

Функция Проверка по базам данных от Didit сопоставляет идентификационные данные с официальными государственными реестрами — RENAPER (Аргентина), Receita Federal (Бразилия), Tribunal Electoral (Панама, биометрия), Junta Central Electoral (Доминиканская Республика) и другими — с оплатой за успешный запрос без ежемесячных минимальных платежей. Когда ни один сервис не может выполнить запрос (обязательные поля отсутствуют или некорректны, реестр недоступен), сам документ не может быть проверен (в нём нет идентификатора, необходимого настроенным сервисам, например, паспорт без национального идентификационного номера), либо итоговый результат неубедителен (частичное совпадение, отсутствие совпадения), функция генерирует предупреждение в сессии. Если страна выдачи вообще не включена в сценарии, шаг автоматически пропускается без предупреждений и без списания средств. На этой странице описаны все коды предупреждений, причины их срабатывания и способы настройки реакции сценария.

Обзор

Предупреждения генерируются как в сессиях сценария, так и при использовании отдельного API (POST /v3/database-validation/). Все пять рисков помечаются функцией DATABASE_VALIDATION, отображаются в отчёте в database_validations[].warnings[] и соответствуют стандартной структуре объекта предупреждения (feature, risk, additional_data, log_type, short_description, long_description, node_id). В проверке по базам данных нет жестких триггеров автоматического отклонения. Для двух рисков по результатам совпадения, риска заменённого документа и риска неприменимости проверки используется настраиваемое действие (DECLINE, REVIEW или NO_ACTION); COULD_NOT_PERFORM_DATABASE_VALIDATION — единственное фиксированное поведение, оно всегда переводит функцию в статус На проверке.

Настраиваемые риски

Настройка	Код риска	Поведение
Действие при отсутствии совпадения	`DATABASE_VALIDATION_NO_MATCH`	`REVIEW` (по умолчанию в сценарии) переводит функцию в статус На проверке; `DECLINE` отклоняет; `NO_ACTION` фиксирует предупреждение без изменения статуса. В отдельном API параметр `no_match_action` по умолчанию имеет значение `DECLINE`.
Действие при частичном совпадении	`DATABASE_VALIDATION_PARTIAL_MATCH`	`NO_ACTION` (по умолчанию) фиксирует предупреждение без изменения статуса; `REVIEW` переводит функцию в статус На проверке; `DECLINE` отклоняет.
Действие при отсутствии совпадения	`DATABASE_VALIDATION_DOCUMENT_SUPERSEDED`	Использует настройку Действие при отсутствии совпадения — отдельного переключателя нет. Реестр опроверг предоставленные данные, поэтому организация, отклоняющая при отсутствии совпадения, отклоняет и при использовании устаревшего документа.
Действие при неприменимости	`DATABASE_VALIDATION_NOT_APPLICABLE`	`NO_ACTION` (по умолчанию) фиксирует предупреждение без изменения статуса; `REVIEW` переводит функцию в статус На проверке; `DECLINE` отклоняет. Срабатывает, когда документ невозможно проверить вовсе — он не содержит идентификатора, который запрашивают настроенные сервисы (например, паспорт без национального идентификационного номера).

Настроенное действие также определяет значение log_type предупреждения: DECLINE → error, REVIEW → warning, NO_ACTION → information. Сам результат совпадения агрегируется из записей validation по каждому сервису (любое полное совпадение → full_match; иначе любое частичное → partial_match; иначе no_match) — см. Методы сопоставления для подробного описания логики принятия решений 1×1 / 2×2.

Создаваемые предупреждения

Tag	Short description	Description
`COULD_NOT_PERFORM_DATABASE_VALIDATION`	Не удалось выполнить проверку по базам данных	Ни один сервис не вернул пригодный результат (`match_type` остаётся `null`) — как правило, из-за отсутствия обязательных полей, неверного формата данных или ошибки реестра. Поле `additional_data` содержит сводку пропуска по каждому сервису (`reason`, `database_validation_errors`, `missing_required_fields_by_service`, `invalid_format_fields_by_service`, `field_reasons_by_service`); отдельный API вместо этого использует `{ "validation_errors": [...] }`. С вас не взимается плата, когда срабатывает это предупреждение; функция переходит в статус На проверке, пока данные не будут исправлены.
`DATABASE_VALIDATION_NOT_APPLICABLE`	Проверка по базам данных неприменима к этому документу	Предоставленный документ не содержит идентификатор, необходимый настроенным сервисам баз данных (`match_type` остаётся `null`) — например, паспорт Бразилии не содержит CPF, поэтому запрос к реестру CPF невозможен. Это ожидаемо для данного типа документа и не указывает на проблему с документом. Поле `additional_data` содержит сводку пропуска по сервисам. С вас не взимается плата, когда срабатывает это предупреждение. Действие настраивается (по умолчанию `NO_ACTION`).
`DATABASE_VALIDATION_PARTIAL_MATCH`	Частичное совпадение при проверке по базам данных	Агрегированный `match_type` равен `partial_match` — часть проверенных полей совпала с данными реестра, но не все. Действие настраивается (по умолчанию `NO_ACTION`).
`DATABASE_VALIDATION_NO_MATCH`	Нет совпадения при проверке по базам данных	Агрегированный `match_type` равен `no_match` — реестр не смог подтвердить проверяемую личность. Действие настраивается (по умолчанию `REVIEW` в сценариях, `DECLINE` в отдельном API).
`DATABASE_VALIDATION_DOCUMENT_SUPERSEDED`	Устаревшая версия документа	Сервис вернул `DOCUMENT_SUPERSEDED`: реестр подтвердил личность, но представленная версия документа не является той, что указана в реестре — с тех пор была выпущена более новая версия. Срабатывает независимо от `match_type`, который остаётся `full_match`, поскольку все персональные поля совпали, иначе этот факт остался бы незамеченным. Поле `additional_data` содержит сервисы, сообщившие об этом. Применяется настройка Действие при отсутствии совпадения.

COULD_NOT_PERFORM_DATABASE_VALIDATION охватывает две разные ситуации, и поле long_description предупреждения (а для ошибки конкретного сервиса, database_validation_errors[].message) теперь указывает, какая именно из них произошла, вместо единого общего предложения: проверяемые данные отсутствовали или имели неверный формат до обращения к сервисам, либо сервис был вызван и не вернул пригодный результат. Во втором случае, если реестр передал собственные диагностические данные для этой попытки, эти сведения включаются в сообщение, чтобы вам не приходилось обращаться в поддержку для выяснения причины. Вышестоящий сервис никогда не называется в ответе.

Когда COULD_NOT_PERFORM_DATABASE_VALIDATION или DATABASE_VALIDATION_NOT_APPLICABLE срабатывает в сессии сценария, проверка автоматически перезапускается после заполнения недостающих данных на странице сведений о сессии в Console — сохранение поля повторно запускает валидацию, и в случае успеха предупреждение снимается. Это также работает, если действие для неприменимой проверки отклонило сессию, благодаря чему отклонённую сессию можно исправить корректировкой данных. Для DATABASE_VALIDATION_NOT_APPLICABLE повторный запуск полезен, когда документ может содержать идентификатор, но он не был считан (например, карта резидента, с которой не удалось извлечь номер национального идентификатора); для типов документов, которые никогда не содержат этот идентификатор (например, паспорта без национального идентификатора), предупреждение сохраняется. Плата за пропущенные сервисы не взимается; вы платите только тогда, когда сервис возвращает тарифицируемый результат.

Пример

{
  "warnings": [
    {
      "feature": "DATABASE_VALIDATION",
      "risk": "DATABASE_VALIDATION_NO_MATCH",
      "additional_data": null,
      "log_type": "warning",
      "short_description": "Database validation no match",
      "long_description": "The system identified a no match in the database validation, requiring further investigation.",
      "node_id": "feature_db_validation_1"
    }
  ]
}

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

Каждому риску присваивается уровень серьёзности на основе настроек вашего приложения. Уровни серьёзности делятся на три категории:

Связанные материалы

Обзор Проверки по базам данных — как устроена функция от начала до конца и поддерживаемые реестры.
Отчёт Проверки по базам данных — полная структура ответа, включая validations[] по каждому сервису.
Методы сопоставления — как формируются результаты 1×1 / 2×2 (validation_type: one_by_one / two_by_two) на основе совпадений в сервисах.
Коды результатов — полная таксономия результатов с детальными кодами для конкретных стран.
Поддерживаемые страны и сервисы — все действующие реестры, обязательные поля и цена за вызов.
Модели данных — проверка по базам данных — каноническая схема с описанием всех полей.

Аутентификация

Верификация

Мониторинг

Платформа

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

Обзор

Настраиваемые риски

Создаваемые предупреждения

Пример

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

Связанные материалы

​Обзор

​Настраиваемые риски

​Создаваемые предупреждения

​Пример

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

​Связанные материалы

Обзор

Настраиваемые риски

Создаваемые предупреждения

Пример

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

Связанные материалы