Перейти к основному содержанию
Проверка по базам данных Didit сверяет идентификационные данные человека с официальным источником в соответствующей стране — национальным реестром актов гражданского состояния, налоговой службой, списком избирателей, кредитным бюро или биометрическим реестром, который изначально выдал документ. Каждая проверка возвращает результат сопоставления по каждому полю (identification_number, first_name, last_name, date_of_birth и поля адреса, если сервис их использует), а также агрегированный результат и исходные данные записи, если они доступны. Это самая надёжная защита от мошенничества с синтетическими личностями: украденный реальный DNI или CPF не пройдёт проверку в реестре, а сфабрикованного номера в официальной базе данных просто не окажется. Проверка по базам данных работает в связке с нашей биометрической функцией сравнения лиц в странах, где реестр хранит официальную фотографию (Аргентина через RENAPER, Панама через Tribunal Electoral SIB / SIB Plus). Благодаря этому вы можете убедиться не только в подлинности номера, но и в том, что человек перед камерой действительно является его владельцем.

​
Почему Didit

  • Самые низкие цены с оплатой за запрос. От $0.05 за проверку (Доминиканская Республика) до $7.00 для самых дорогих специализированных источников. Цена устанавливается за сервис, а не за страну — если реестр взимает высокую оптовую ставку, цена формируется соответственно (национальное удостоверение Финляндии стоит $2.10). Актуальный тариф для конкретного сервиса всегда можно посмотреть в таблице цен по сервисам. Никаких ежемесячных минимумов, плат за платформу или тарификации за места — оплачиваются только успешные запросы.
  • Самая быстрая интеграция. Зарегистрируйтесь, получите API-ключ в консоли и вызывайте POST /v3/database-validation/ уже через несколько минут. Никаких звонков в отдел продаж, циклов закупки и документов для проверки концепции — Didit полностью работает в режиме самообслуживания.
  • Прямые запросы к официальным источникам. RENAPER, Receita Federal (SERPRO), Tribunal Electoral, RENAPO, RENAP, RNP, RNPN, Junta Central Electoral, Registraduría Nacional, SEGIP, Servicio de Registro Civil, Tribunal Supremo de Elecciones, Dirección General de la Policía — никаких данных, собранных парсингом агрегаторов.
  • Биометрическое сравнение лиц, если в реестре есть официальное фото. Уверенность выше, чем при OCR, без дополнительных работ по интеграции.
  • Задержка, соответствующая требованиям продакшн-среды. Сквозная задержка p95 обычно составляет менее 1.5 с, квартальная доступность 99.9%.
Урок Didit Academy по чтению результатов верификации доходит до проверки по базам данных на отметке 11:05 и демонстрирует полное и частичное совпадение, а также отсутствие совпадения.

​
Глобальное покрытие

Наведите курсор на любую подсвеченную страну, чтобы увидеть все доступные в ней сервисы проверки по базам данных, категорию данных (идентификационные данные, финансовые данные, биометрические данные, адресные данные, телекоммуникационные данные, …) и цену за запрос. Страны, доступные в продакшне, готовы к использованию уже сегодня; остальные подключаются по запросу клиента.
Не нашли нужную страну? Свяжитесь с нами — наш каталог насчитывает 60+ стран с сотнями сервисов, которые мы активируем по запросу клиентов. Подключение новых интеграций обычно занимает 2–3 недели.

​
Как проходит Проверка по базам данных

Проверка по базам данных никогда не запускается наугад. Она выполняется только тогда, когда соблюдены все следующие условия:
  1. В сессии определена страна для запроса — из поля issuing_state шага Верификация личности либо, если в сценарии нет шага Верификации личности, из единственной страны, настроенной для шага Проверки по базам данных.
  2. Для этой страны в сценарии включен хотя бы один сервис Проверки по базам данных.
  3. Шаги, предшествующие шагу Проверки по базам данных, предоставили все обязательные поля, необходимые выбранному сервису.
Если сервис включен, но обязательные поля так и не поступили (например, CPF не удалось извлечь из размытого бразильского RG), сервис пропускается, с вас не взимается плата, а для сессии формируется предупреждение: DATABASE_VALIDATION_NOT_APPLICABLE, если в документе попросту нет идентификатора, по которому этот сервис делает запрос, или COULD_NOT_PERFORM_DATABASE_VALIDATION, если он должен был присутствовать, но отсутствовал. Оба предупреждения перечислены в каталоге предупреждений. Сотрудник вашей команды с правами на проверку сессии может вручную заполнить недостающее поле на странице сведений о сессии в Console, и сохранение изменений автоматически перезапустит проверку. Это действие проверяющего, а не то, что может сделать конечный пользователь. Чтобы позволить пользователю предоставить поле, которого нет в его документе, запросите его в Анкетах (либо через извлечение в Document AI, либо в виде значения, передаваемого при создании сессии) и сопоставьте его на шаге Проверки по базам данных, как описано ниже.

​
Проверка по базам данных не требует Верификации личности

Раньше шаг Проверки по базам данных предполагал обязательное наличие предшествующего шага Верификации личности, поскольку OCR документа, удостоверяющего личность, было единственным встроенным способом получить данные конечного пользователя. Теперь это не так: для каждого обязательного поля указывается, какие шаги могут его предоставить, и сервис становится доступным, как только ваш сценарий начинает содержать шаг, предоставляющий все необходимые ему поля. Это означает, что сервис биометрической идентификации по лицу может работать только на основе шага Проверки живости, без какого-либо документа, удостоверяющего личность, в сценарии, а сервис, использующий налоговый номер, номер телефона или адрес электронной почты, может получить соответствующее значение из ответа на вопрос анкеты, шага Проверки телефона или Проверки электронной почты или извлечения через Document AI. Безопасность обеспечивается двумя правилами:
  • Сценарий без Верификации личности должен содержать ровно одну настроенную страну на шаге Проверки по базам данных. Без поля issuing_state из документа это единственный однозначный сигнал о том, к какому национальному реестру обращаться, поэтому конфигурация для нескольких стран без Верификации личности ничего не запустит, чтобы избежать догадок.
  • Проверка обязательных полей остаётся неизменной. Сервис, для которого на момент выполнения предоставлены не все поля, пропускается до отправки запроса какому-либо провайдеру, поэтому с вас никогда не списываются средства за обращение к базе данных, к которой фактически не обращались.

​
Сопоставление полей Document AI и анкет

Поля извлечения Document AI и вопросы анкет используют ваши имена ключей, а не имена Didit. Ключ, точно совпадающий с именем входного поля Проверки по базам данных (tax_number, date_of_birth, phone, …), сопоставляется автоматически и не требует настройки. Для всех остальных редактор сценариев отображает на шаге Проверки по базам данных список ещё не заполненных полей, где вы указываете для каждого из них соответствующий ключ поля Document AI или ответ из анкеты. В Console сервис, который ваш сценарий пока не может выполнить, отображается отключённым с указанием причины — какие поля отсутствуют и какой шаг мог бы их предоставить — а редактор предлагает добавить этот шаг. Его добавление сразу же активирует все сервисы, которые он разблокирует.
Практический пример — идентификатор, отсутствующий в документе. Сервис национальных ID Нигерии выполняет запрос по 11-значному NIN, который часто не напечатан на загружаемых пользователями документах. Поэтому опора исключительно на документ приводит к тому, что проверка пропускается как неприменимая для значительной доли пользователей. Добавьте шаг Анкеты перед шагом Проверки по базам данных с запросом NIN, а затем сопоставьте national_id с этим вопросом на шаге Проверки по базам данных. Такое же сопоставление позволяет использовать внутри сценария идентификаторы, которых вообще никогда не бывает на документах — например, банковский верификационный номер или регистрационный номер компании.
Для сервисов, работающих на основе адреса, Didit автоматически разбивает единый address из документа на структурированные адресные элементы: При вызове автономного API вы можете передавать как единую строку address, так и эти структурированные поля напрямую. При наличии обоих вариантов приоритет имеют структурированные поля. Сервисам, требующим поиска по адресу, необходим address_element_1 плюс хотя бы один дополнительный элемент адреса; если Didit не сможет извлечь их из документа, удостоверяющего личность, или Подтверждения адреса в сценарии, сервис пропускается и плата не взимается. Если определённая страна не включена вовсе, шаг пропускается без уведомлений, без предупреждений и без списания средств.
Didit database validation flow checking user data against government identity registries

​
Результат сопоставления

Каждый включённый сервис возвращает результат проверки для каждого поля: Агрегированный match_type сводится к следующим значениям:
  • full_match — каждое запрошенное поле совпадает как минимум с одним источником.
  • partial_match — частичное совпадение; кейс направляется в очередь на проверку согласно правилам вашего сценария.
  • no_match — ни один источник не подтвердил данные; обычно следует отклонить.

​
Как определяется сопоставление (1×1 / 2×2)

Мы больше не требуем заранее выбирать «1×1» или «2×2» — они определяются тем, сколько отдельных сервисов вернули полное совпадение с входными данными:
  • Результат 1×1 — один сервис вернул полное совпадение (данные подтвердил один авторитетный источник).
  • Результат 2×2 — два или более сервисов вернули полное совпадение (независимое подтверждение; максимальный уровень уверенности).
В сценарии можно включить любое количество сервисов для каждой страны; оплата взимается за каждый сервис, который фактически вернул результат. Сервисы, для которых не удалось извлечь обязательные поля, пропускаются без взимания платы. ➡️ Полную логику принятия решений и то, как она взаимодействует с partialMatchAction / noMatchAction, см. в разделе Методы сопоставления.

​
Биометрическая проверка по базам данных

Реестры актов гражданского состояния некоторых стран содержат биометрический шаблон (портрет или отпечаток пальца). Если он доступен, мы совмещаем поиск по реестру с биометрическим сравнением лиц с селфи пользователя:
  • Аргентина (arg_renaper) — биометрическое сравнение лиц с официальной фотографией из базы RENAPER. Охват населения 100%; каждый гражданин Аргентины с DNI внесён в базу данных.
  • Панама (pan_cedula_sib, pan_cedula_sib_plus) — биометрическое сравнение лиц через сервис SIB избирательного трибунала (Tribunal Electoral). SIB Plus представляет собой вариант повышенного уровня с более строгими биометрическими порогами и более подробными метаданными сопоставления.
Для этих сервисов поле selfie является обязательным. В рамках сессии повторно используется селфи из проверки живости (наивысшее качество), а в качестве запасного варианта используется портрет из документа. Вне сессии, при вызове автономного API (POST /v3/database-validation/, режим B выше), вы передаёте JPEG/PNG самостоятельно.

​
Глобальное обогащение данных о личности

glb_identity_enrichment представляет собой глобальный сервис Проверки по базам данных, доступный только через автономный API. По адресу электронной почты и/или номеру телефона он определяет связанных физических лиц (имена, даты рождения, адреса, телефоны, адреса электронной почты и национальные идентификаторы) и возвращает оценку совпадения имени, сопоставленную со стандартными кодами результатов MATCH / PARTIAL_MATCH / NO_MATCH / DOCUMENT_NOT_FOUND (с соответствующим match_type: full_match / partial_match / no_match). Поскольку это глобальный сервис (GLB), привязанный к электронной почте или телефону, а не к стране выдачи документа, он недоступен в конструкторе сценариев. Вызывайте его напрямую через автономный API с параметром issuing_state, установленным в GLB:
Его стоимость составляет $0.20 за запрос (плата взимается только в том случае, если провайдер возвращает результат).

​
Настройка

Проверка по базам данных настраивается индивидуально для каждого сценария в Console. Для каждой страны вы выбираете конкретные сервисы, которые хотите запускать; обязательные и необязательные входные поля определяются объединением требований этих сервисов. Действие, выполняемое при результатах partial_match и no_match, настраивается отдельно и может принимать значения approve, review или decline.
Настройки проверки по базам данных в Didit Console: выбор сервисов реестров для отдельных стран и правил для результатов

​
Уведомления о доступности

Государственные реестры и другие источники периодически выходят из строя. Пока база данных недоступна, проверки по ней не возвращают ответа и за них не взимается плата. Внутри сценария сервис переходит в статус REGISTRY_UNAVAILABLE. В отдельном API такой сбой может проявляться в одной из трёх форм, поэтому обязательно проверяйте результаты по каждому сервису и database_validation.errors[], а не только HTTP-статус:
  • 200 с outcome_code: "REGISTRY_UNAVAILABLE" у этого сервиса в validations, если Didit сохранил результат, о котором можно сообщить.
  • 200 с этим сервисом в database_validation.errors[] как code: "empty_provider_response", retryable: true, когда сервис не вернул пригодного для использования ответа, но другой выбранный сервис ответил успешно. В этом случае сбойный сервис отсутствует в validations и в services_used, поэтому errors[] является единственным местом, где он отображается.
  • 502 с validation_errors[].code: "empty_provider_response" и retryable: true, когда ни один из выбранных сервисов не вернул пригодного для использования результата (см. отклонённые входные данные и недоступные результаты).
Общий status определяется сервисами, которые вернули ответ, поэтому сам по себе он не является надёжным индикатором сбоя. Запрос, в котором не с чем было выполнить сравнение, переходит в статус In Review, но запрос, в котором было выбрано несколько сервисов, может получить статус Approved на основе совпадения из другого сервиса, даже если один из источников был недоступен. Повторите проверку только для сбойного сервиса, указанного в errors[], а не весь запрос целиком. Ни один из этих вариантов ничего не говорит о проверяемом человеке. Didit отслеживает фактические результаты реальных проверок по каждой базе данных отдельно и отправляет вашей организации уведомление по электронной почте, если сбой затянулся, а не представляет собой единичный неудачный запрос: Уведомления направляются участникам и контактам по биллингу каждой организации, которая выполняла проверку именно по этой базе данных за последние 48 часов. Ничего настраивать не требуется, и отдельно подписываться не нужно. Трафик в песочнице никогда не инициирует такие уведомления, как и сбои, вызванные отправленными вами данными (отклонённые или некорректно сформированные входные данные), либо сервисами, работающими с учётными данными, подключёнными вашей собственной организацией. Проверка, получившая ответ через резервный источник, считается доступной, как и окончательный результат об отсутствии совпадения.

​
Цены — платите только за то, что используете

Проверка по базам данных тарифицируется за каждый успешный запрос к каждому сервису по ставке, опубликованной для данного сервиса. Ставки варьируются от $0.05 за проверку (Доминиканская Республика через Junta Central Electoral) до $7.00 для самых дорогих специализированных источников. Запросы ко многим государственным реестрам находятся в диапазоне от 0.20 до 0.30 USD, однако целый ряд источников стоит значительно дороже, поскольку сам источник взимает более высокую плату — например, проверка удостоверения личности Финляндии (fin_national_id) стоит $2.10 за успешный запрос. Определяйте цену для страны по её собственной строке в таблице цен, а не по диапазону. Здесь нет ежемесячных минимальных платежей, обязательств или комиссий за использование платформы. Вы платите только тогда, когда сервис возвращает результат. Сервисы, пропущенные из-за отсутствия входных данных, не тарифицируются. Не тарифицируется и сервис, вызов источника которого завершился ошибкой: ошибка реестра или его недоступность (REGISTRY_ERROR / REGISTRY_UNAVAILABLE) означают, что запрос так и не получил ответа, поэтому такой результат не подлежит оплате. Каждый успешный запрос к реестру оплачивается начиная с самого первого, независимо от того, выполняется ли он в рамках сценария или через отдельный API POST /v3/database-validation/. Он списывается с кредита вашего тарифа или баланса пополнения, как и любая другая проверка, и скидка по вашему тарифу применяется ко всей его стоимости. См. страницу с ценами. ➡️ Цены на Проверку по базам данных · Зарегистрироваться и получить API-ключ

​
Все сервисы

​
Что читать дальше

  • Методы сопоставления — как формируются результаты 1×1 / 2×2 и как на них реагировать.
  • Коды результатов — полный список кодов ответов провайдеров (умерший, несовершеннолетний, документ не найден, биометрическое несовпадение, …) и их сопоставление с решениями по сессиям.
  • Предупреждения — что отображается, когда сервис не может быть запущен из-за отсутствия данных.
  • Отчёты — ежемесячные выгрузки биллинга по сервисам с указанием страны, идентификатора сервиса, объёма использования, цены за единицу и общей стоимости.
  • Поддерживаемые страны — статическая таблица со всеми странами, которые поддерживаются на сегодняшний день.
Последнее изменение 7 ноября 2026 г.