Интеграция распознавания паспорта по API: пошаговый план от теста до запуска

Интеграция распознавания паспорта по API — это подключение бэкенда к методу, который извлекает поля паспорта из изображения, и к отдельному методу проверки его действительности по эталонным источникам. В России обработку данных при такой интеграции регулирует 152-ФЗ, идентификацию клиентов — 115-ФЗ. Применяется в банках, страховых компаниях и онлайн-сервисах с удалённым онбордингом клиентов.

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

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

Кратко:

• Тестовый контур команда собирает за один рабочий день: запрос на распознавание, разбор JSON, запрос к проверке паспорта, запись в журнал.
• IDX распознаёт документы 254 стран и территорий и международных организаций и проверяет их подлинность; действительность иностранного документа по государственному реестру эта проверка не подтверждает.
• В рабочий контур интеграцию переводят после пилота, подписания поручения по ч. 3 ст. 6 152-ФЗ и настройки получения согласий клиентов.
• Стартовые пороги уверенности: от 0,98 поле принимается автоматически, от 0,85 до 0,98 уходит специалисту, ниже 0,85 отправляется на повторный захват.
• Отказ только по итогам автоматизированной обработки допустим при письменном согласии клиента или в случаях, предусмотренных федеральным законом (ст. 16 152-ФЗ).

Что нужно для интеграции распознавания паспорта за один день

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

До начала работ подготовьте:

• ключи доступа к API;
• подключение ускоренной комплексной проверки паспорта, если она нужна в сценарии: в личном кабинете заказчик этот метод не подключает, его активирует служба поддержки IDX по запросу;
• канал поступления документов и стартовый модуль распознавания;
• перечень стран и типов документов во входящем потоке: по нему с IDX согласуют набор методов для подключения;
• механизм получения и фиксации согласия клиента на обработку персональных данных;
• проект поручения на обработку персональных данных; если команда использует в пилоте реальные документы клиентов, организация и провайдер подписывают его до начала пилота;
• выборку документов для пилота по каждому действующему каналу и каждому типу документа: сканы и мобильные фото.

Какие документы, кроме паспорта РФ, распознаёт и проверяет IDX

IDX распознаёт документы 254 стран и территорий, а также документы международных организаций, например ЕС, ООН, APEC и Интерпола, и проверяет их подлинность. База IDX содержит более 16 800 шаблонов документов. Текст распознаётся более чем на 138 национальных языках с разными системами письма: латиницей, кириллицей, арабским письмом, иероглифами и другими. Для определения подлинности подписи IDX применяет комплекс экспертиз.

Проверка подлинности касается самого документа и его действительность по государственному источнику не подтверждает: она не показывает, что документ не аннулирован. Сам по себе охват 254 стран и территорий не означает проверку по иностранным государственным реестрам. Проверка по эталонным источникам, о которой речь идёт дальше, относится к паспорту гражданина РФ, поэтому для иностранного документа команда должна построить отдельный маршрут решения.

Как интегрировать распознавание паспорта по API: 8 шагов

Шаги 1–4 команда разработки выполняет в первый день и получает ответ на тестовый запрос. Шаги 5–8 она проходит во время пилота, чтобы подготовить интеграцию к рабочему контуру.

1. Получить ключи доступа к API. Если в сценарии нужна ускоренная комплексная проверка паспорта, заранее запросить её подключение у службы поддержки.
2. Выбрать способ интеграции: прямые вызовы REST API из бэкенда или, для отдельных сценариев, встраивание страницы проверки в интерфейс с помощью iframe с доступом к камере.
3. Собрать два POST-запроса. Первым бэкенд отправляет изображение в метод распознавания. Вторым передаёт в метод проверки распознанные ФИО, дату рождения, серию, номер и дату выдачи паспорта вместе с признаком и датой согласия клиента.
4. Разобрать JSON-ответы и записать их в журнал: распознанные поля, код результата, идентификатор операции, оценку проверки паспорта. Статус действительности паспорта приходит только в ответе метода проверки.
5. Подключить классификатор типа документа, если на вход приходят разные документы, в том числе иностранные или несколько документов в одном файле.
6. Настроить передачу в гибридный режим документов, которые невозможно распознать автоматически с нужным качеством: рукописных частей и нешаблонных форм. Гибридный режим включает ручную обработку, поэтому поручение на обработку персональных данных должно её охватывать.
7. Настроить правила принятия решений по совокупности сигналов: результата проверки паспорта, качества распознавания полей и антифрод-проверок.
8. Подключить мониторинг: алерты по доступности API, времени ответа, доле технических ошибок, доле ручных проверок и резким изменениям в структуре отрицательных результатов.

Как настроить правила решений по результатам проверки паспорта

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

Шкалы оценки у методов проверки паспорта различаются, поэтому правила маршрутизации должны быть написаны под конкретные методы. В ускоренной комплексной проверке паспорта IDX без участия специалиста дальше проходит только заявка с оценкой 100, остальные значения ведут к специалисту или возвращают отрицательный сигнал:

В методе комплексной проверки паспорта шкала другая: 0 означает недействительный паспорт, 10 означает, что сведения о паспорте не найдены; полную шкалу команда уточняет у провайдера. Если команда переносит правила с одного метода на другой без сверки шкалы, заявка с оценкой 0 из комплексной проверки попадает в маршрут «данные не найдены», хотя в этом методе 0 означает недействительный паспорт.

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

• 0,98 и выше (поле принимается автоматически);
• от 0,85 включительно до 0,98 (поле уходит на проверку специалисту);
• ниже 0,85: повторный захват (если новый снимок снова ниже порога, сотрудник вводит поле по изображению).

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

• ложные отказы, то есть добросовестные клиенты, которым отказали;
• доля повторных захватов;
• ложные принятия, то есть заявки с неверными или подложными данными, прошедшие автоматически.

Решение, которое порождает для клиента юридические последствия и принято только на основании автоматизированной обработки его персональных данных, допустимо при письменном согласии клиента или в случаях, предусмотренных федеральным законом (ч. 1 и 2 ст. 16 152-ФЗ). Оператор обязан разъяснить порядок такого решения и его последствия, дать возможность заявить возражение и рассмотреть его в течение 30 дней (ч. 3 и 4 ст. 16 152-ФЗ). Если этих оснований нет, заявка с отрицательным сигналом передаётся специалисту.

Заявку с совпадением по перечню организаций и физических лиц, в отношении которых имеются сведения об их причастности к экстремистской деятельности или терроризму (перечню Росфинмониторинга), организация обрабатывает по отдельному маршруту, вне обычной маршрутизации. Организации, которые проводят операции с денежными средствами, применяют меры по замораживанию (блокированию) незамедлительно, но не позднее 24 часов с момента размещения сведений на сайте Росфинмониторинга, и информируют Росфинмониторинг о принятых мерах (пп. 6 п. 1 ст. 7 115-ФЗ). По перечням, которые Совет Безопасности ООН составляет в целях противодействия распространению оружия массового уничтожения, срок составляет не более 20 часов с момента получения уведомления Росфинмониторинга (п. 2 ст. 7.5 115-ФЗ). Итоговое решение по заявке принимает организация и закрепляет порядок во внутренних правилах.

Что проверить перед рабочим запуском распознавания паспорта

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

В журнал бэкенд записывает идентификатор операции, дату, метод и результат каждой проверки; по этим записям организация восстанавливает, на каком основании принято решение. Если организация обязана хранить сведения по 115-ФЗ, документы и сведения, необходимые для идентификации, она хранит не менее пяти лет со дня прекращения отношений с клиентом (п. 4 ст. 7 115-ФЗ). Изображения паспорта и технические данные, которые для идентификации не нужны, по ч. 7 ст. 5 152-ФЗ организация хранит не дольше, чем требуют цели обработки. Сроки по отдельным видам сведений и состав досье организация сверяет по статье о хранении клиентского досье по 115-ФЗ.

Если провайдер обрабатывает данные по поручению заказчика, до запуска оператор и провайдер подписывают поручение по ч. 3 ст. 6 152-ФЗ. В нём оператор определяет перечень персональных данных, перечень действий с ними и цели обработки, а также закрепляет:

• обязанность провайдера соблюдать конфиденциальность и обеспечивать безопасность данных;
• требования ч. 5 ст. 18 и ст. 18.1 152-ФЗ;
• обязанность по запросу оператора подтверждать документами принятые меры;
• требования к защите данных по ст. 19 152-ФЗ, включая уведомление оператора об инцидентах по ч. 3.1 ст. 21 152-ФЗ.

По ч. 5 ст. 18 152-ФЗ при сборе персональных данных граждан России их запись, систематизация, накопление, хранение, уточнение и извлечение с использованием баз данных за пределами РФ не допускаются, кроме случаев из п. 2, 3, 4 и 8 ч. 1 ст. 6 152-ФЗ. Поручить обработку оператор вправе с согласия клиента, если иное не предусмотрено федеральным законом; сам провайдер получать согласие не обязан (ч. 3 и 4 ст. 6 152-ФЗ). Ответственность перед клиентом за действия провайдера несёт оператор, провайдер отвечает перед оператором (ч. 5 ст. 6 152-ФЗ). Обязанность провести идентификацию по 115-ФЗ лежит на организации-заказчике: сервис IDX выполняет проверки по её запросу, а порядок идентификации организация определяет в правилах внутреннего контроля.

Целевую доступность и метрики мониторинга заказчик и провайдер закрепляют в договоре.

Какие проверки подключить после распознавания паспорта

Распознавание ускоряет ввод данных и проверку, но идентификацию клиента по ст. 7 115-ФЗ не заменяет. После распознавания организация проверяет, что документ предъявляет его владелец: сравнивает лица и проводит liveness detection. Обе проверки входят в состав KYC при удалённом онбординге клиента. После распознавания документов сценарий дополняют проверкой паспорта, проверкой по перечню Росфинмониторинга, сравнением лиц и liveness detection. Видеозахват подключают, когда в мобильном канале растёт доля снимков с бликами и размытием.

Сколько ручной работы убирает распознавание паспорта: условный расчёт

Допустим, организация получает 40 000 заявок в месяц, а ручной ввод и проверка паспортных данных занимают 6 минут на заявку. При полностью ручной обработке на это уходит 4 000 часов в месяц. Если после подключения распознавания и проверки паспорта специалисту достаётся 2% заявок, остаётся 800 ручных проверок, или 80 часов вместо 4 000. Доля 2% взята как допущение для расчёта и точность распознавания не описывает.

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

Тем не менее масштаб эффекта виден уже на условных цифрах: если специалисту уйдёт в пять раз больше заявок, то есть 10%, ручная работа сократится с 4 000 до 400 часов в месяц. Поэтому автоматическое распознавание документов при онбординге применяют банки, страховые компании, операторы связи, онлайн-ритейл и логистика, а ручной ввод оставляют для нечитаемых снимков, нешаблонных документов и спорных заявок. Какую долю заявок распознавание обработает без участия специалиста на собственном потоке организации, покажет только пилот.