Интеграция с ГБД ЮЛ: проверка и регистрационные сведения о юрлицах через шлюз

Кратко: Государственная база данных «Юридические лица» (ГБД ЮЛ) — реестр Министерства юстиции РК, где хранятся актуальные регистрационные сведения о каждом юридическом лице, филиале и представительстве по бизнес-идентификационному номеру (БИН). Через ШЭП (Smart Bridge) банки и корпорации получают эти данные программно: проверка контрагента, KYB (Know Your Business), онбординг юрлиц, комплаенс-скрининг. В статье — что даёт ГБД ЮЛ, какие сервисы описаны в каталоге sb.egov.kz и как подключить их через интеграционный шлюз Smartconnect без месяцев ручной работы с шиной ШЭП.

Статус сервиса в SmartConnect. ГБД ЮЛ — перспективный сервис нашего каталога ШЭП: он подключается по запросу под конкретный сценарий интегратора по той же архитектуре, что и уже действующие адаптеры (например, Адресный регистр и сервисы КГД). Точный состав методов, формат идентификатора, лимиты и SLA фиксируются при подключении по паспорту сервиса в Smart Bridge и условиям доступа владельца данных — см. раздел «Что подготовить перед подключением».

---

Что такое ГБД ЮЛ и зачем она бизнесу

ГБД «Юридические лица» — государственная информационная система под управлением Министерства юстиции РК. Её задачи:

• автоматизация регистрационных процедур для юрлиц, филиалов и представительств;
• ведение Национального реестра бизнес-идентификационных номеров (БИН);
• предоставление актуальных и достоверных регистрационных сведений о юрлицах госорганам и другим субъектам.

Для бизнеса это единый первоисточник «правды» о компании: наименование, БИН, дата регистрации, статус (действующее / бездействующее), руководитель, учредители, участие в других организациях, обременения на доли. Именно на этих данных строятся:

• проверка контрагента (KYB) перед заключением договора или выдачей кредита;
• онбординг юрлиц в банке или на платформе — автозаполнение реквизитов по БИН вместо ручного ввода;
• комплаенс и AML-скрининг — проверка аффилированности, статуса, бенефициаров;
• актуализация клиентской базы — периодическая сверка изменений по БИН.

Какие сервисы ГБД ЮЛ описаны в каталоге ШЭП

Официальная композитная услуга egov — «Предоставление сведений из государственной базы данных "Юридические лица"» (владелец — Минюст РК, услуга автоматическая, бесплатная). Она объединяет ряд атомарных сервисов, которые в интеграционном контуре вызываются по отдельности. По публичным egov-паспортам в её состав входят, в частности:

Сервис (egov-код)	Что возвращает
e_032	Сведения о зарегистрированном юрлице / филиале / представительстве
e_033	Наличие филиалов и представительств у юрлица
e_034	Участие юрлица в других организациях
e_035	Участие физлица в юридических лицах
e_053	Статус «бездействующее» юрлицо
e_080	Все регистрационные действия по юрлицу
e_081	Сведения о юрлице на конкретную дату
e_082	Последние изменения в учредительные документы
e_083	Обременения на доли участия

В каталоге sb.egov.kz (раздел «Юридические лица», владелец — Минюст) эти возможности публикуются как сервисы ШЭП: предоставление регистрационных сведений по БИН, проверка статуса юрлица, сведения об аффилированных лицах.

Приведённые коды и наименования — это публичная декомпозиция композитной услуги egov, а не внутренний реестр методов адаптера. У сервисов ГБД ЮЛ нет единого «универсального» справочника результатов: каждый сервис описывает свой набор полей и кодов в собственном паспорте (WSDL/XSD) в Smart Bridge. Точный состав методов, которые подключаются под конкретный сценарий, и формат идентификатора фиксируются по паспорту сервиса на этапе подключения — SmartConnect подбирает нужный набор под задачу интегратора.

Боль интеграторов: почему «просто дёрнуть API» не получается

Прямое подключение к ГБД ЮЛ через ШЭП — это не REST-запрос «в одну строчку». Команды сталкиваются с типовым набором проблем:

1. Транспорт и формат ШЭП. Обмен в шлюзе eGov исторически построен на SOAP/XML-конвертах с жёсткими XSD-схемами, тогда как корпоративные системы говорят на REST/JSON. Нужна конвертация форматов в обе стороны и валидация по схеме.
2. ЭЦП на каждом сообщении. Запросы в ШЭП подписываются электронной цифровой подписью; ответ тоже приходит подписанным и требует проверки. Самописная работа с ключами и криптопровайдером — источник ошибок и уязвимостей.
3. Гарантированная доставка. Госсистемы дают таймауты и периодические сбои. Без очередей, retry и журнала транзакций часть запросов теряется — а для KYB это означает «зависший» онбординг клиента.
4. Регламент доступа. Подключение к сервису ГБД ЮЛ через ШЭП требует оформленного доступа (соглашение, роли, регламент с владельцем данных). Это организационный, а не только технический шаг.
5. Изменяемость схем. Паспорта сервисов и XSD периодически обновляются — интеграцию приходится сопровождать.

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

Как это решает интеграционный шлюз Smartconnect

Smartconnect — интеграционный шлюз, который берёт на себя весь «низ» интеграции с ШЭП и отдаёт разработчику чистый REST/JSON-контракт. Базовый функционал шлюза одинаков для всех сервисов каталога, и для ГБД ЮЛ он выглядит так:

• Единый REST/JSON-фасад. Ваша система отправляет обычный JSON-запрос вида «дай регистрационные сведения по БИН X», а шлюз сам собирает SOAP/XML-конверт нужного сервиса ШЭП, отправляет и разбирает ответ.
• Конвертация XML ↔ JSON с XSD-валидацией. Шлюз валидирует и запрос, и ответ по актуальным схемам — класс ошибок «невалидный конверт» исчезает до отправки в госсистему. Подробнее — в разборе XML ↔ JSON конвертации.
• Встроенная ЭЦП. Подпись исходящих сообщений и проверка подписи ответов выполняется шлюзом; ключи хранятся в защищённом хранилище (HashiCorp Vault), без самописного кода на стороне разработчика. См. как работает ЭЦП в Казахстане.
• Гарантированная доставка. Очереди, повторные попытки с backoff при сбоях, dead-letter и полная история транзакций — ни один KYB-запрос не теряется, любой вызов прослеживается.
• Гранулярный доступ. Права микросервисов на конкретные сервисы ГБД ЮЛ настраиваются по принципу наименьших привилегий.
• ISO 27001. Шифрование, управление доступом и аудит соответствуют требованиям, которые проверяет служба ИБ банка.

Эти возможности — транспорт ШЭП, подпись и проверка ЭЦП, ретраи с backoff, dead-letter, журнал транзакций, гранулярный доступ — базовый функционал шлюза, общий для всех сервисов каталога. Под конкретный сервис ГБД ЮЛ остаётся сопоставить его паспорт (методы, схему запроса/ответа), настроить авторизацию и подключить модель вызова, которую сервис поддерживает по паспорту (синхронный запрос-ответ по БИН и, где сервис это предусматривает, передачу изменений для актуализации данных). Конкретные лимиты, время ответа и коды ошибок регулируются регламентом сервиса и условиями владельца данных и уточняются на этапе подключения — мы не подменяем их собственными значениями.

Итог: интеграция с ГБД ЮЛ сокращается с 6–12 месяцев (при самостоятельной разработке транспорта, криптографии и доставки) до 2–4 недель подключения готового адаптера по паспорту сервиса.

Типовой сценарий: онбординг и проверка контрагента-юрлица

1. Пользователь (или бэкенд) вводит БИН контрагента.
2. Система шлёт в Smartconnect REST-запрос на регистрационные сведения.
3. Шлюз подписывает запрос ЭЦП, конвертирует в формат ШЭП, вызывает сервис ГБД ЮЛ, проверяет подпись ответа и возвращает JSON: наименование, статус, руководитель, дата регистрации.
4. При необходимости — доп. вызовы: аффилированность (участие в других организациях), статус «бездействующее», обременения на доли.
5. Данные попадают в CRM/скоринг/комплаенс-модуль; если сервис поддерживает передачу изменений по БИН, клиентская база может актуализироваться автоматически.

Разработчик при этом не пишет ни строчки SOAP, ЭЦП или очередей — он работает с одним REST-контрактом.

ГБД ЮЛ и ГБД ФЛ: в чём разница

ГБД ЮЛ отвечает за юридические лица (идентификатор — БИН), тогда как ГБД ФЛ — за физических лиц (идентификатор — ИИН). В реальных сценариях они часто работают в паре: проверить компанию по БИН и её руководителя/учредителей-физлиц по ИИН. Про интеграцию с реестром физлиц — в статье «Интеграция с ГБД ФЛ». Через один шлюз оба сервиса подключаются под единым REST-контрактом и с единой моделью доступа.

Что подготовить перед подключением

• Оформленный доступ к сервису ГБД ЮЛ через ШЭП — договор/соглашение с владельцем данных (Минюст РК) и права вашей ИС на конкретный сервис в Smart Bridge. Порядок оформления и состав ролей регулируются регламентом оператора ШЭП и уточняются при подключении по паспорту сервиса.
• Сертификаты ЭЦП организации для подписи запросов.
• Перечень нужных сервисов — какие именно сведения (базовая справка, аффилированность, статус, история) требуются вашему процессу; точный состав методов берётся из паспорта сервиса в каталоге sb.egov.kz.
• Согласованный контур развёртывания — шлюз разворачивается в вашей инфраструктуре, в том числе в Kubernetes.

Полный перечень — в чек-листе готовности к интеграции с госсистемами РК.

---

Итог

ГБД ЮЛ — ключевой первоисточник для проверки и онбординга юрлиц в РК: KYB, комплаенс, автозаполнение реквизитов по БИН. Прямое подключение через ШЭП тянет за собой SOAP/XML-транспорт, ЭЦП, гарантированную доставку и регламент доступа — недели и месяцы работы. Интеграционный шлюз Smartconnect закрывает этот слой готовым адаптером и отдаёт чистый REST/JSON, сокращая срок подключения до 2–4 недель. ГБД ЮЛ подключается по запросу под конкретный сценарий по той же архитектуре, что и уже действующие адаптеры ШЭП.

CTA: Нужна проверка и регистрационные сведения о юрлицах по БИН в вашей системе? → Запросить подключение к ГБД ЮЛ — обсудим сценарий, подберём методы по паспорту сервиса и подключим к шлюзу.

---

Источники: каталог sb.egov.kz (Smart Bridge), раздел «Юридические лица» (владелец — Минюст РК); паспорт композитной услуги egov «Предоставление сведений из ГБД "Юридические лица"» и атомарные сервисы e_032–e_083 на egov.kz; описание ИС ГБД ЮЛ (назначение, реестр БИН) на nitec.kz / govarch.kz. Технические детали приведены по открытым источникам; состав методов, форматы идентификатора, коды ошибок, лимиты и SLA уточняются по паспорту сервиса и условиям доступа владельца данных при подключении.