Интеграция KYC-провайдера для криптопроектов: Sumsub, Onfido, Jumio

Интеграция KYC-провайдера: где ломается путь пользователя

Интеграция KYC-провайдера в типовом проекте выглядит как вызов метода из формы регистрации: получили ссылку на сессию, отправили пользователя, дождались ответа. Ломается всё на стыке — там, где проверка личности встречается с логикой аккаунта, лимитов и выплат.

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

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

Третий — ручные разборы и зависшие заявки. Каждый случай, застрявший между двумя системами, кто-то сверяет вручную, время ответа растёт с минут до часов, а пользователь за это время уже открыл аккаунт у конкурента. Провайдеры — Sumsub, Onfido, Jumio — отдают статусы и причины отказа по-разному, и без единой модели состояний на вашей стороне это превращается в постоянный поток таких разборов.

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

Что даёт подключённая проверка: скорость, отказы, ручная работа

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

Основная инженерная работа — обработка статусов. Результат приходит асинхронно, ответ может повториться или задержаться; без идемпотентной обработки и повторных попыток появляются зависшие заявки и дубли. Мы держим один источник правды по клиенту и разделяем промежуточные и финальные статусы — класс ошибок «проверка пройдена, доступ закрыт» уходит вместе с ручными сверками.

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

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

Логика переносима между провайдерами: Sumsub, Onfido и Jumio отличаются наборами методов и порогами, но контур обработки статусов, повторов и разбора остаётся тем же — смена поставщика не требует переписывать продукт.

Три способа подключить проверку личности и их ограничения

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

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

Этапы внедрения: от аудита потока проверок до передачи в поддержку

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

1. Аудит потока верификации — проходим пользовательский путь по шагам, фиксируем точки отказа и места, где документ запрашивается повторно; на выходе карта статусов и узких мест.
2. Схема маршрутов проверки — определяем, какие уровни кому нужны: минимальный для пополнения, расширенный для вывода средств и корпоративных аккаунтов.
3. Настройка правил проверки — задаём пороги срабатывания, автопринятие простых случаев, ручной разбор спорных; правила версионируются, чтобы решение можно было объяснить.
4. Роли и доступы — оператор разбора видит только нужный объём данных, действия пишутся в журнал; это снимает вопросы при внешних проверках.
5. Тестовый контур проверок — прогоняем сценарии в песочнице провайдера: успех, отказ, повторная подача, истёкшая сессия, расхождение в документах; отдельно смотрим, что повторное уведомление не создаёт дублей.
6. Запуск с постепенным включением — сначала доля трафика на новом маршруте, сравнение доли прохождений и времени проверки; откат делается переключением правил, без правки кода.
7. Передача в поддержку — регламенты разбора, шаблоны ответов, порядок эскалации к провайдеру, панель по статусам; первая линия закрывает типовые случаи сама.

Что остаётся у вас после внедрения: конфигурации, схемы, регламенты

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

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

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

Кейс: подключение второго провайдера без остановки регистрации

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

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

Маршрутизацию задали правилами: доля трафика, регион документа, требуемый уровень проверки — документ, биометрия, санкционные списки. Перевод потока шёл долями: 5%, 25%, 50%, 100%, на каждом шаге сверяли долю успешных проверок и долю ручных разборов. Регистрация не останавливалась ни на минуту.

Результат

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

Что делать, если проверка уже развёрнута на другом решении?

Полный перенос нужен редко. Если верификация уже развёрнута на другом решении, первым шагом мы разделяем поток по типу субъекта, юрисдикции и стадии жизненного цикла пользователя — и переносим не всё сразу, а те участки, где новая логика даёт измеримый выигрыш. Остальное остаётся работать как есть, пока не закрыты пробелы в покрытии.

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

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

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

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

Технические сомнения: безопасность данных, отказы, повторная проверка

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

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

Как повторная верификация влияет на доступ к аккаунту?

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

Обсудим задачу: разберём ваш поток проверок и вернёмся с планом

Проверки — самая заметная часть пути клиента: от того, сколько шагов он проходит и как быстро получает ответ, зависит доля завершённых регистраций. Чтобы разбор был предметным, а не общим, присылайте вводные по вашему потоку — по ним мы соберём схему и вернёмся с оценкой и планом внедрения.

• Сценарии проверок: кого проверяем (физлицо, компания, представитель, конечный владелец) и на каком шаге — регистрация, первая сделка, вывод средств.
• Требуемые уровни: какие документы и подтверждения обязательны, а какие опциональны, для каких юрисдикций.
• Текущий путь данных: где сейчас собираются данные клиента и куда должен вернуться результат — в личный кабинет, в систему учёта, в очередь ручного разбора.
• Статусы провайдера: какие ответы нужно поддержать (успех, отказ, доработка, ручная проверка) и что при каждом делать дальше.
• Политики хранения: сроки хранения персональных данных, порядок удаления, кто отвечает за обработку запросов клиентов.
• Провайдер и доступы: выбранный из пула (Sumsub, Onfido, Jumio) или открытый вопрос, тестовые ключи и контакт поддержки со стороны провайдера.
• Ограничения: дата запуска, окно ответа клиенту, ожидаемая нагрузка в сутки.

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