Перейти к основному содержанию
Когда начинается сессия верификации бизнеса, Didit запрашивает официальные реестры компаний, чтобы получить и проверить информацию о компании. Этот автоматизированный запрос служит основой для всего процесса верификации бизнеса.

Поиск в реестре

Didit подключается к реестрам компаний в поддерживаемых странах, чтобы получить официальные данные. На размещённой странице верификации пользователь выбирает страну регистрации компании и заполняет название компании, регистрационный номер или оба поля. Нужно указать хотя бы одно из них. Где реестр этого требует, регистрационные номера приводятся к нужному формату (например, номера компаний в Великобритании дополняются нулями до восьми знаков). Если указаны оба идентификатора, поиск в реестре использует их вместе.

Предварительное заполнение поиска через expected_details

Если вы уже знаете компанию, передайте expected_details (company_name, registry_country, registration_number) при создании сессии. Размещённая страница верификации заранее выбирает и фиксирует страну (а для реестров уровня штата, таких как US-CA, также штат), заполняет соответствующие поля поиска и автоматически запускает поиск по указанным данным. Пользователь сразу видит результат по своей компании. Оба поля остаются редактируемыми, чтобы пользователь мог исправить неверные данные. Это только предварительное заполнение: если пользователь выбрал другую компанию, предупреждение не выводится.

Типы поиска

Поиск в реестре работает в двух режимах:

Порядок поиска

Поиск в реестре выполняется асинхронно:

Поиск

Didit отправляет запрос в реестр с выбранной страной и указанными идентификаторами: названием компании, регистрационным номером или обоими сразу. Поле ответа searched_by показывает, как были найдены результаты (name, registration_number или registration_number_and_name). Размещённый интерфейс при результатах по регистрационному номеру предлагает одним нажатием выполнить поиск по названию компании: «Искать вместо этого по названию компании». Поиск выполняется асинхронно.

Опрос статуса

Опрашивайте статус поиска, пока результаты не будут обработаны. Большим реестрам может понадобиться несколько секунд, чтобы вернуть результаты.

Выбор компании

Просмотрите найденные компании и выберите правильное совпадение. Didit связывает выбранную компанию с проверкой KYB и заполняет все доступные данные.

Подтверждение и продолжение

Подтвердите или исправьте данные компании и перейдите к следующему настроенному шагу. Некоторые реестры возвращают профиль компании раньше, чем готов отчёт о структуре владения. Этот отчёт продолжает формироваться в фоновом режиме, пока заявитель выполняет независимые шаги, например загрузку документов. Предварительное заполнение из реестра не блокирует форму «Ключевые лица»: заявитель может ввести людей вручную, а данные о людях из реестра появятся до отправки по мере поступления отчёта. Пользовательские решения, которые зависят от отчёта, ждут его получения и не угадывают результат. Ваши исправления сохраняются, когда отчёт поступает. Ожидающий отчёт не считается завершённой проверкой по реестру или автоматическим одобрением. Оплата за проверку по реестру начисляется по уровню, который был фактически предоставлен.

Ручная отправка

Если компания не найдена в реестре, отправьте данные о компании вручную. Сессия продолжается с переданными данными, а is_from_registry получает значение false.

Получаемые данные

Статусы компании

Компании со статусом, отличным от Активна, могут быть автоматически помечены или отклонены в зависимости от настроек вашего сценария.

Индикатор источника данных

Каждая запись о компании содержит флаг is_from_registry:
  • true: данные получены из официального реестра компаний
  • false: данные введены вручную, потому что компания не найдена в реестре
Поле fetch_status показывает, завершён ли запрос к реестру, завершился ли он ошибкой или ещё выполняется.

Уровни данных и цены

В размещённом сценарии выбор компании приводит к списанию платы за реестр, даже если заявитель уходит до подтверждения данных или завершения верификации. Если отчёт готов в момент выбора, за выданный уровень плата списывается сразу. Если данные о структуре владения ещё не готовы, при выборе списывается плата за Lite, а при выдаче более высокого уровня списывается только разница в цене. Если данные о структуре владения недоступны, доплата за структуру владения не применяется. Итоговая сумма рассчитывается по ценам, указанным при выборе, и никогда не превышает стоимость запрошенного уровня. Выбор и любая последующая корректировка структуры владения считаются одной проверкой по реестру; чтение купленного отчёта или подтверждение его данных повторно не списывает плату. По действующим контрактам с фиксированной ставкой одна проверка по реестру начисляется при выборе, без второй единицы контракта за последующую выдачу данных о структуре владения. Поиски в размещённых сценариях не имеют отдельной платы за поиск. Отдельные поисковые запросы API могут стоить $0.50 за каждый успешный запрос; см. тарификация поиска. Полную таблицу по странам см. в разделе тарифы KYB-реестров. В размещённом сценарии уровень для каждой страны выбирается в разделе Workflows → KYB Registry Check → Countries. Если в реестре нет записи о структуре владения компании, запрос на уровень Акционеры или Бенефициары выполняется и оплачивается по самому высокому уровню, который могут предоставить реестры страны, обычно это Lite. За компанию, которая не найдена и введена вручную (is_from_registry: false), взимается фиксированная плата $0.75: поиск выполнялся, хотя запись из реестра не была возвращена.
Lite возвращает только профиль компании, без акционеров, бенефициаров или структуры владения:
Уровень Акционеры добавляет ownership_structure и записи акционеров, а также руководителей и директоров. Уровень Бенефициары дополнительно определяет бенефициарных владельцев с процентами владения. См. Структура владения и Руководители и директора.

Данные реестра и данные, предоставленные пользователем

Didit хранит данные, полученные из реестра, и данные, подтверждённые пользователем, как отдельные аудиторские записи, а также объединённое каноническое представление, которое используют последующие проверки. Каждая компания содержит три связанных блока: Временная метка confirmed_by_user_at фиксирует момент, когда конечный пользователь подтвердил или изменил данные реестра. Пока эта метка не заполнена (null) и is_editable равно true, конечный пользователь может продолжать изменять поля в размещённом сценарии. Для компаний, введённых вручную (is_from_registry: false), user_provided_data является единственным источником, а is_editable становится false после отправки пользователем данных. Аналитики могут увидеть два источника рядом в разделе просмотра сессии в Business Console и сравнить данные реестра с данными, подтверждёнными пользователем.

Настраиваемые поля формы реестра

Вы управляете тем, какие поля данных о компании размещённый сценарий верификации запрашивает на шаге подтверждения по реестру. Настраивайте их в Business Console: откройте редактор сценария, выберите узел KYB Registry check и перейдите на вкладку Поля. Каждое поле имеет одно из трёх состояний: Три поля всегда отображаются и всегда обязательны, их нельзя настроить, так как они идентифицируют компанию: company_name, country_code и region (штат или регион, если реестр региональный). Настраиваемых полей 16: registration_number, incorporation_date, legal_address, vat_number, alternative_names, tax_number, company_type, legal_entity_identifier, location_of_registration, nature_of_business, registered_capital_amount, registered_capital_currency, website, email, phone, control_scheme По умолчанию, и для всех существующих сценариев, обязательным является только incorporation_date, а все остальные настраиваемые поля необязательны. Поэтому форма работает так же, как до появления этой настройки. Обязательность заполнения проверяется на стороне сервера: если отправить форму реестра с пустым обязательным полем, сервер вернёт 400 с сообщениями об ошибках для каждого поля, а интерфейс размещённой страницы верификации отображает только включённые поля. В API сценария настройка задаётся объектом kyb_registry_fields_config в узле KYB Registry. Его структура описана в разделе конфигурации функций.
Поле vat_number, отмеченное как Обязательно, проверяется только для компаний, учреждённых в стране ЕС, где применяется НДС (см. ниже). Для всех остальных стран оно считается необязательным, даже если отмечено как обязательное, поскольку собирать номер НДС ЕС не требуется. Номер tax_number всё равно проверяется, если он указан.

VAT и проверка налогового номера

Когда отправляется шаг реестра, Didit проверяет vat_number компании по официальному источнику её страны. Компания без vat_number проверяется по tax_number. Номер можно передавать с кодом страны или без него и с любыми разделителями (DE 123 456 789, DE123456789 и 123456789 для немецкой компании эквивалентны). Официальные реестры. В этих странах номер проверяется в режиме реального времени по государственному или официальному реестру предприятий, который также возвращает зарегистрированное название (а для большинства и адрес): Французский SIREN или SIRET, голландский RSIN или полный венгерский налоговый номер, переданные как VAT-номер, перед проверкой преобразуются в соответствующий VAT-номер. VAT-номера Греции проверяются с префиксом EL автоматически. Правила контрольных цифр. В этих странах запрос к реестру невозможен, поэтому номер проверяется по официальному формату и правилам контрольных цифр страны: Албания, Андорра, Аргентина, Австралия, Азербайджан, Беларусь, Канада, Чили, Китай, Доминиканская Республика, Египет, Сальвадор, Гана, Гватемала, Исландия, Индия, Индонезия, Израиль, Япония, Кения, Лихтенштейн, Мексика, Молдова, Монако, Черногория, Марокко, Мозамбик, Новая Зеландия, Северная Македония, Перу, Россия, Сан-Марино, Сербия, Сингапур, ЮАР, Южная Корея, Тайвань, Таиланд, Тунис, Türkiye, Украина, Великобритания, США, Уругвай, Венесуэла и Вьетнам. Эти правила применяются и в ЕС, когда tax_number является национальным налоговым идентификатором без VAT-номера для проверки, например немецким Steuernummer. tax_number указывает только на наличие налогового идентификатора, а не на регистрацию по НДС, поэтому, если VIES его не находит, результат определяется по этим правилам, а не становится invalid. Компании из любой другой страны получают vat_validation_status: "not_applicable". Так же обрабатываются и сессии песочницы, которые никогда не обращаются к налоговым реестрам. Результат сохраняется у компании и передаётся в payload решения KYB: vat_validation_source принимает одно из значений: eu_vies, pl_vat_white_list, no_brreg, ch_uid_register, br_receita_federal, co_rues, cr_hacienda, ec_sri, py_dnit или format_rules. Когда номер получает статус valid, invalid, format_valid или invalid_format, результат сохраняется на всю сессию, и реестр повторно не запрашивается, если только номер не изменился. Сверка названия. Когда номер имеет статус valid и источник раскрывает зарегистрированное название, Didit сопоставляет его с указанным названием компании с учётом неточных совпадений. Значимое расхождение вызывает предупреждение KYB_COMPANY_VAT_NAME_MISMATCH без изменения статуса сессии: это мягкий сигнал для проверяющих. Его additional_data содержит registry_name, registry_source и submitted_name, а также vies_name, если источником является VIES. Некоторые страны-члены ЕС не раскрывают название или адрес; поля в этом случае возвращаются пустыми, и сравнение не выполняется. Настраиваемые действия. Две настройки в узле проверки реестра KYB определяют, что происходит с сессией при неуспешной проверке (значения REVIEW, DECLINE, NO_ACTION): tax_number со статусом invalid_format отображается в payload без запуска действия, поскольку в свободном текстовом поле для налогового номера часто указывается другой идентификатор компании. Каждый результат также вызывает соответствующее предупреждение (KYB_COMPANY_VAT_INVALID, KYB_COMPANY_VAT_COULD_NOT_VALIDATE) в проверке реестра. См. предупреждения о верификации бизнеса (KYB).

Перекрёстная проверка данных

Didit автоматически сравнивает данные, предоставленные пользователем, и канонические данные с данными, которые вернул реестр, и с данными OCR, извлечёнными из загруженных документов:
  • Название компании: нечёткое сопоставление, которое учитывает сокращения и различия в оформлении
  • Регистрационный номер: проверка на точное совпадение
  • Страна: проверка согласованности страны, указанной пользователем, и страны из реестра
  • Адрес: геокодирование и нормализация для сравнения
Все расхождения отмечаются как предупреждения в сессии и видны аналитикам в консоли.

Финансовая сводка

Если данные доступны, Didit получает из реестра сводные финансовые данные:
  • Выручка или оборот
  • Количество сотрудников
  • Коды отраслей SIC/NACE
  • Даты подачи отчётности и статус соответствия требованиям

Дополнительные поля реестра

В зависимости от охвата юрисдикций ответ реестра может также содержать:
  • alternative_names: торговые наименования, DBA-названия, прежние юридические названия
  • legal_entity_identifier (LEI): для финансовых учреждений и публичных компаний
  • website, email, phone: контактные данные, которые есть в реестре
  • nature_of_business: краткое описание деятельности (на языке реестра)
  • registered_capital: уставный или выпущенный капитал в виде объекта {amount, currency}
Все поля попадают в блок business решения KYB.

Достоверность и статус верификации

Каждый ответ реестра содержит verification_status: Используйте вместе с is_from_registry, чтобы строить собственную логику последующей обработки:

Результаты перекрёстной проверки

Каждая перекрёстная проверка выполняется по отдельному полю и возвращает одно из значений:
  • MATCH: предоставленные данные совпадают с данными реестра.
  • MISMATCH: существенное расхождение. Отмечается как предупреждение.
  • NO_DATA: одна из сторон была пустой, поэтому сравнение невозможно.
Расхождения видны для каждого поля при просмотре сессии в консоли.

Что влияет на результат

Статус компании, страна регистрации, результаты AML-проверки и соответствие заявленным данным передаются в решение в виде тегов предупреждений для проверки по реестру и AML-скрининга. Ваш сценарий определяет, одобряет, отправляет на проверку или отклоняет каждое предупреждение. Сигналы и ключи сценария, которые ими управляют, описаны в разделе оценка рисков.

Поддерживаемые страны

Покрытие зависит от страны. Разбивку по уровням для каждого региона смотрите в разделе поддерживаемые страны.

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

Структура владения

Идентификация UBO и цепочки владения.

Схема ответа

Где каждое поле находится в payload.

Поддерживаемые страны

Покрытие по регионам.
Последнее изменение 7 ноября 2026 г.