Структурированный JSON-вывод и интеграция распознанных документов в контур банка

Структурированный JSON-вывод и интеграция: что это меняет для финсектора

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

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

Схема вывода: типизированные поля, а не строка текста

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

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

Казахский и русский в одном документе

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

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

Интеграция с 1С и внутренними системами

JSON удобен тем, что его понимают почти все принимающие стороны, но реальная интеграция начинается не с формата, а с сопоставления полей. У банка есть своя АБС, у бухгалтерии — 1С со своей структурой справочников контрагентов и договоров, у скоринга — собственная анкета. Структурированный вывод становится промежуточным контрактом: распознаватель отдаёт стабильный набор полей, а тонкий слой маппинга раскладывает их по конкретным реквизитам целевой системы.

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

JSON как контракт между модулями KYC и сверки

В KYC структурированный вывод выполняет роль контракта между этапами. Модуль распознавания не знает бизнес-логику проверки клиента, а модуль KYC не должен разбираться, как был устроен исходный скан. Их связывает согласованная схема: на вход KYC приходят ИИН, ФИО, дата рождения и реквизиты документа в предсказуемом виде, и правила проверки пишутся против этих полей, а не против сырого текста.

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

Изолированное развёртывание: где физически живёт JSON

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

Такой сценарий снимает целый класс рисков согласования с безопасностью и упрощает интеграцию по-своему — принимающие системы обращаются к сервису по внутренней сети, а не через внешние каналы. Именно на этой модели построен подход ZoomApps: структурированный вывод как стабильный контракт для интеграции и обработка данных строго внутри периметра заказчика.

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