Распознавание документов через API

Зачем финсектору распознавание документов через API

Распознавание документов через API — это способ встроить извлечение данных из сканов, PDF и фотографий прямо в существующие информационные системы, не заставляя оператора вручную перебивать поля. Для банка или страховой компании в Казахстане это означает, что при открытии счёта, оформлении полиса или проверке контрагента документ уходит не в отдельную десктопную программу, а в HTTP-эндпоинт, который возвращает уже разобранные поля: номер удостоверения, ИИН, срок действия, сумму договора. Разница между ручной обработкой и API-подходом видна на объёме: там, где отделение принимает сотни клиентов в день, каждый сэкономленный на вводе минут превращается в пропускную способность фронт-офиса.

Ключевое отличие интеграционного сценария от коробочного сканера в том, что API становится частью бизнес-логики. Ответ распознавания сразу попадает в скоринг, в антифрод-проверку, в карточку клиента. Поэтому к такому сервису предъявляют инженерные требования: предсказуемая схема ответа, стабильные коды ошибок, возможность повторить запрос без потери идемпотентности. Подробнее о линейке поддерживаемых типов документов мы пишем в разделе распознавание документов.

Архитектура интеграции: синхронный и пакетный режим

На практике встречаются два режима. Синхронный — когда оператор в момент обслуживания загружает удостоверения клиента и ждёт ответ за секунды: запрос уходит с изображением, ответ приходит с распознанными полями и метрикой уверенности по каждому из них. Пакетный режим применяется для бэк-офиса, где ночью нужно разобрать накопленный поток отсканированных договоров или счетов-фактур: документы ставятся в очередь, обрабатываются потоком, а система-инициатор забирает результаты по идентификатору задачи.

С инженерной стороны важны детали, которые обычно всплывают только на нагрузке. Тайм-ауты стоит разводить: короткий на приём файла, длинный на саму обработку, чтобы медленная страница с мелким шрифтом не рвала соединение. Крупные пакеты выписок лучше отдавать по одному документу с общим идентификатором сессии, а не одним многостраничным блобом — так проще ретраить сбойный лист и не гонять заново гигабайты. Ответ по каждому полю сопровождается оценкой уверенности, и правильный интеграционный слой не подставляет вслепую всё подряд, а отправляет сомнительные значения на ручную проверку оператору.

Изолированное развёртывание в контуре клиента

Для банков, страховых и микрофинансовых организаций Казахстана определяющим требованием оказывается не точность как таковая, а то, где физически обрабатываются персональные данные. Документ клиента — это ИИН, адрес, данные удостоверения личности, то есть категория, которую регулятор не позволяет свободно выносить во внешние облака. Поэтому распознавание документов через API мы поставляем в модели изолированного развёртывания: сервис ставится внутри периметра клиента, на его серверах или в его частном облаке, и наружу не ходит ни один байт изображения.

Такой контур снимает целый класс вопросов у службы информационной безопасности. Трафик не покидает сеть организации, обновления моделей доставляются контролируемым каналом, а журналирование остаётся под контролем самого банка. API при этом выглядит для интегратора одинаково — тот же протокол, та же схема ответа, — но за эндпоинтом стоит сервис в вашем ЦОД, а не удалённый провайдер. Это принципиальная позиция ZoomApps: экспертиза в распознавании не должна оплачиваться утечкой периметра.

Структурированный вывод и стыковка с 1С

Само по себе распознавание текста ценности для бэк-офиса не несёт — оператору не нужен поток символов, ему нужна проводка. Поэтому API возвращает структурированный вывод: не сплошное полотно текста, а именованные поля с типами. Для счёта это БИН поставщика, номер и дата, сумма и НДС в тенге, разложенные по позициям; для банковской выписки — строки операций с датой, суммой и назначением платежа. Такой JSON ложится в учётную систему без ручного разбора.

На стыке с 1С важно учитывать местные детали формата. Суммы приходят нормализованными к числу, чтобы разделители разрядов и запятая в дробной части не ломали импорт; даты приводятся к единому виду независимо от того, как они были напечатаны в исходнике. Реквизиты контрагента сверяются по контрольной разрядности БИН, что отсекает часть ошибок распознавания ещё до попадания в учёт. В результате бухгалтер видит уже готовую к разноске карточку, а не задачу перепечатать документ вручную.

Казахстанская специфика: два языка, ИИН и БИН

Документооборот в Казахстане двуязычный, и это не абстрактная трудность, а конкретное требование к движку. В одном договоре соседствуют казахский и русский, шапка может быть на государственном языке, а тело — на русском; удостоверение личности содержит поля на обоих языках сразу. Движок, обученный на одном языке, на таком материале деградирует, поэтому распознавание документов через API должно вести оба алфавита в рамках одной страницы, не теряя специфические казахские символы.

Отдельная работа — валидация национальных идентификаторов. ИИН физического лица и БИН организации имеют жёсткую структуру с контрольным разрядом, и это можно использовать как встроенную проверку: если распознанный ИИН не проходит контроль, поле помечается как сомнительное и уходит на ручную сверку, а не в KYC-конвейер как достоверное. Для процессов знай своего клиента такая проверка на входе экономит дорогие ошибки идентификации ниже по потоку. То же касается срока действия удостоверения — просроченный документ система отмечает сразу, не дожидаясь ручного контроля.

С чего начать интеграцию

Разумный порядок внедрения — начать с одного узкого типа документа, на котором бизнес теряет больше всего времени. Чаще всего это либо поток удостоверений на этапе онбординга, либо счета-фактуры в бухгалтерии. На пилоте отрабатывается схема ответа, пороги уверенности и маршрут для сомнительных полей, а уже потом контур расширяется на договоры и выписки. Такой подход даёт измеримый результат за недели, а не абстрактную интеграционную стройку на кварталы.

Инженерная команда ZoomApps разворачивает сервис в вашем контуре, отдаёт спецификацию API и помогает состыковать структурированный вывод с учётной системой. Начать удобнее всего с обзора поддерживаемых типов в пилларе распознавание документов и выбора того сценария, где ручной ввод сегодня стоит дороже всего.

Хотите увидеть распознавание на своих документах? Посмотрите что умеет ZoomApps или сразу напишите нам в WhatsApp — покажем на демо.