Інтеграція KYC-провайдера: де ламається шлях користувача
Інтеграція KYC-провайдера в типовому проєкті виглядає як виклик методу з форми реєстрації: отримали посилання на сесію, відправили користувача, дочекалися відповіді. Ламається все на стику — там, де перевірка особи зустрічається з логікою акаунта, лімітів і виплат.
Перший розрив — розбіжність статусів. Провайдер і ваша база живуть кожен своїм життям: повідомлення не дійшло або надійшло із затримкою, повтор доставлено двічі і без ідемпотентності перезаписав уже прийняте рішення, заявка зависла в ручному розборі в оператора. Користувач у цей момент бачить «перевірка триває», хоча вердикт винесено давно.
Другий — відвал на верифікації, і він рідко пов'язаний із підробкою документа. Люди йдуть на вимозі зробити селфі раніше, ніж вибрано тип документа, на камері без підказок про світло й кадр, на повторному завантаженні після невиразної помилки.
Для верифікації користувачів криптопроєкту це особливо дорого: непройдена перевірка — це не відкладений клієнт, а втрачений.
Третій — ручні розбори й завислі заявки. Кожен випадок, що застряг між двома системами, хтось звіряє вручну, час відповіді зростає з хвилин до годин, а користувач за цей час уже відкрив акаунт у конкурента.
Провайдери — Sumsub, Onfido, Jumio — віддають статуси й причини відмови по-різному, і без єдиної моделі станів на вашій стороні це перетворюється на постійний потік таких розборів.
Далі розбираємо, як це закривається: де ставити точки контролю статусів, як проєктувати повторні спроби й що врахувати при підключенні перевірки особи, щоб вона не з'їдала воронку.
Що дає підключена перевірка: швидкість, відмови, ручна робота
Швидкість верифікації задається не провайдером, а місцем перевірки в сценарії реєстрації. Коли запит іде після відправлення форми, людина чекає вердикт на екрані завантаження: проходження займає 40–90 секунд, і частина користувачів просто закриває сторінку.
Ми виносимо перевірку в окремий крок із явними статусами й повертаємо управління сценарію за фактом відповіді.
Основна інженерна робота — обробка статусів. Результат приходить асинхронно, відповідь може повторитися або затриматися; без ідемпотентної обробки й повторних спроб з'являються завислі заявки та дублі.
Ми тримаємо одне джерело правди по клієнту й розділяємо проміжні та фінальні статуси — клас помилок «перевірку пройдено, доступ закрито» зникає разом із ручними звірками.
Окремо налаштовуються правила ручного розбору. Поріг ризику й тригери підбираються під ваш профіль: частка заявок, що доходять до живого спеціаліста, падає з більшості до одиниць відсотків, а кожне рішення пояснюване — видно спрацьоване правило, а не лише вердикт.
Повторні перевірки — прихована витрата часу підтримки.
Якщо відмова викликана якістю знімка, користувач повертається в ту саму сесію зі збереженим станом, а не починає заново: повторних звернень на клієнта стає одне замість трьох-чотирьох, а конверсія реєстрації зростає за рахунок тих, хто раніше кидав на другій спробі.
Логіка переносима між провайдерами: Sumsub, Onfido і Jumio відрізняються наборами методів і порогами, але контур обробки статусів, повторів і розбору залишається тим самим — зміна постачальника не потребує переписувати продукт.
Три способи підключити перевірку особи та їхні обмеження
Перевірку особи підключають до запуску, але вимоги у проєктів розходяться: одна юрисдикція чи п'ять, стандартні паспорти чи змішаний потік документів, готовність тримати свою команду на підтримці. Звідси три робочі схеми, між якими реально обирають.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Власна збірка: порівняння Sumsub, Onfido і Jumio, свої правила маршрутизації | Кілька юрисдикцій, нетипові документи, потрібен контроль над кожним кроком | Довший запуск, потрібно підтримувати адаптери й стежити за змінами на боці постачальників |
| Один готовий сервіс перевірок | Один ринок, стандартні документи, запуск у короткий строк | Жорстка логіка сценарію; при збої постачальника перевірки стають повністю |
| Гібридна схема: основний постачальник плюс резервний маршрут із перемиканням за відмовою | Високий потік реєстрацій, вимоги до безперервності | Потрібен шар нормалізації відповідей і правило, який результат вважається підсумковим |
Гібрид — не компроміс, а окремий режим роботи: при відмові або затримці основного постачальника заявка йде в резервний маршрут, а відповіді приводяться до єдиного формату на нашій стороні. Цей шар нормалізації й визначає, отримає бізнес безперервну реєстрацію чи простій на час збою.
Етапи впровадження: від аудиту потоку перевірок до передачі в підтримку
Порядок робіт майже не залежить від провайдера: Sumsub, Onfido і Jumio розрізняються набором готових перевірок і форматом повідомлень про статус, але інженерна послідовність одна.
Починаємо з аудиту потоку верифікації — де користувач відвалюється, які маршрути обов'язкові, а які можна залишити необов'язковими.
- Аудит потоку верифікації — проходимо користувацький шлях по кроках, фіксуємо точки відмови й місця, де документ запитується повторно; на виході карта статусів і вузьких місць.
- Схема маршрутів перевірки — визначаємо, які рівні кому потрібні: мінімальний для поповнення, розширений для виведення коштів і корпоративних акаунтів.
- Налаштування правил перевірки — задаємо пороги спрацьовування, автоприйняття простих випадків, ручний розбір спірних; правила версіонуються, щоб рішення можна було пояснити.
- Ролі й доступи — оператор розбору бачить лише потрібний обсяг даних, дії пишуться в журнал; це знімає питання при зовнішніх перевірках.
- Тестовий контур перевірок — проганяємо сценарії в пісочниці провайдера: успіх, відмова, повторна подача, сесія, що минула, розбіжність у документах; окремо дивимося, що повторне повідомлення не створює дублів.
- Запуск із поступовим включенням — спочатку частка трафіку на новому маршруті, порівняння частки проходжень і часу перевірки; відкат робиться перемиканням правил, без правки коду.
- Передача в підтримку — регламенти розбору, шаблони відповідей, порядок ескалації до провайдера, панель зі статусів; перша лінія закриває типові випадки сама.
Що залишається у вас після впровадження: конфігурації, схеми, регламенти
Передаємо не «доступ до особистого кабінету провайдера», а відтворюваний комплект: за ним ваш інженер або підтримка піднімуть процес верифікації на новому контурі без звернення до нас за усними поясненнями. Кожен артефакт версіонується у вашому репозиторії — зміни проходять через рев'ю, як звичайний код.
- Схема інтеграції перевірок — послідовність викликів, точки отримання результату, обробка повторних доставок і збоїв зовнішнього сервісу, поведінка при недоступності провайдера.
- Матриця правил і ролей — який рівень перевірки спрацьовує для якої юрисдикції та обсягу операцій, хто з операторів бачить персональні дані, хто лише вердикт.
- Регламент ручних перевірок — критерії відправлення кейса людині, порядок розбору сумнівних документів, строки реакції, точки ескалації та правила відмови.
- Документація з верифікації — словник статусів і кодів, опис полів звіту, розшифрування розбіжностей між відповіддю провайдера та вашим станом користувача.
- Конфігурації порогів — ліміти спроб, строки життя перевірки, списки заборонених юрисдикцій, шаблони повідомлень — у файлах, а не в інтерфейсі чужої панелі.
- Порядок роботи із секретами — де зберігаються ключі, як ротуються, хто власник доступу і що робити при відкликанні співробітника.
- Набір тестових сценаріїв — пісочний контур і добірка кейсів: нечитабельний документ, збіг із санкційним списком, повторна подача тієї самої особи.
- Журнал рішень для аудиту — що і коли зафіксовано по кожному кейсу, з яким формулюванням і на якій підставі.
До комплекту додаємо коротку інструкцію із супроводу: типові звернення підтримки і що в якому місці правити. Далі процес живе у вас — доопрацювання, зміна провайдера або додавання другого контуру верифікації йдуть без нас.
Кейс: підключення другого провайдера без зупинки реєстрації
Проєкт — криптоплатформа з обов'язковою перевіркою особи на вході. Увесь потік реєстрації йшов через одного постачальника: коли на його боці зростали затримки відповідей, реєстрація ставала повністю, заявки накопичувалися, а підтримка розбирала їх вручну. Другого маршруту перевірки не було — переключитися було нікуди.
Перевірки винесли в окремий сервіс-оркестратор із єдиним контрактом, а за ним поставили двох провайдерів — Sumsub і резервного.
Кожній заявці присвоюється ключ ідемпотентності: повторний запит не створює другої перевірки, а результат рішення зберігається в нашому профілі користувача й залишається доступним, навіть коли зовнішній сервіс недоступний.
Статуси приходять асинхронними повідомленнями, заявки, що відстали, добираються періодичним опитуванням — жодна перевірка не зависає без відповіді.
Маршрутизацію задали правилами: частка трафіку, регіон документа, потрібний рівень перевірки — документ, біометрія, санкційні списки. Переведення потоку йшло частками: 5%, 25%, 50%, 100%, на кожному кроці звіряли частку успішних перевірок і частку ручних розборів. Реєстрація не зупинялася ні на хвилину.
Результат
Частка перевірок, завершених із першої спроби, зросла з 71% до 92%, медіанний час від подання документа до рішення скоротився вдвічі, а деградація будь-якого одного провайдера більше не впливає на прийом користувачів: перемикання — параметр конфігурації, відкат займає хвилини й не потребує викочування.
Що робити, якщо перевірка вже розгорнута на іншому рішенні?
Повний перенос потрібен рідко. Якщо верифікація вже розгорнута на іншому рішенні, першим кроком ми розділяємо потік за типом суб'єкта, юрисдикцією та стадією життєвого циклу користувача — і переносимо не все одразу, а ті ділянки, де нова логіка дає вимірюваний виграш. Решта залишається працювати як є, поки не закриті прогалини в покритті.
KYC і KYB відрізняються за обсягом робіт із міграції та за обсягом даних, які треба переносити. По фізособі це набір документів, результат звірки із санкційними й репутаційними списками, оцінка ризику — їхній перенос передбачуваний.
По юрособі додаються структура володіння, бенефіціари, ролі директорів, реєстрові документи: тут частіше залишають перевірку на попередньому сервісі, а на нову сторону переводять лише нові реєстрації та повторні перевірки.
Паралельний запуск перевірок — основний робочий режим. Новий потік іде через цільового провайдера, наявні користувачі та спірні кейси залишаються на попередньому.
Далі ми звіряємо вердикти на контрольній вибірці: частка розбіжностей, частота переходу в ручний розбір, час проходження від старту до фінального статусу. Поки розбіжності пояснювані й не зростають, попередній сервіс не вимикаємо.
Історія перевірок переноситься не як перевірка, а як її результат і докази: статус, рівень ризику, позначка часу, посилання на збережені документи та їхні відбитки, ідентифікатори подій.
Користувач при цьому не проходить верифікацію повторно — внутрішній ідентифікатор пов'язує профіль у двох системах, а рішення щодо нього можна пред'явити регулятору або партнеру будь-якої миті.
Критерій вимкнення попереднього сервісу — стійкий збіг вердиктів і відсутність зростання ручних розборів на всій контрольній вибірці, а не лише на нових реєстраціях.
Відкат на цьому етапі зводиться до перемикання маршруту перевірок: користувач не втрачає доступ, історія залишається на місці. Саме так ми закриваємо частковий перенос — розбираємо, що переводити, а що залишити.
Технічні сумніви: безпека даних, відмови, повторна перевірка
Документи клієнта не зобов'язані лежати у вашій базі. Провайдер верифікації приймає файл, зберігає його у своєму контурі й віддає вам результат: пройдено, відхилено, відправлено на ручний розбір — плюс ідентифікатор перевірки.
Файли видаються за підписаними посиланнями з коротким строком життя, тому персональні дані не осідають у логах і резервних копіях вашого сервісу, а доступ до них ріжеться рольовою моделлю.
Хибні відмови частіше йдуть не від підробки, а від вхідних даних: змазане фото, відблиск на голограмі, незбіг транслітерації імені. Санкційний скринінг додає другий клас — збіг прізвища із записом у списку при різних датах народження.
Знімається це порогом збігу, ручною чергою й повторним прогоном за оновленими списками, а не відмовою з першого спрацьовування.
Чи можна перевірити клієнта повторно без нового завантаження документів?
Так, якщо провайдер зберігає вихідний файл і вердикт. Повторний прогін іде за тим самим ідентифікатором перевірки — змінюються лише правила: пороги збігу, версія санкційного списку, набір обов'язкових полів.
Як повторна верифікація впливає на доступ до акаунта?
Тригери — закінчення строку давності перевірки, зміна юрисдикції, різке зростання обігів за рахунком. На час повторної перевірки логіка доступу переводить акаунт у режим лише читання, але не блокує вхід: інакше клієнт не зможе дозавантажити документ.
Обговоримо задачу: розберемо ваш потік перевірок і повернемося з планом
Перевірки — найпомітніша частина шляху клієнта: від того, скільки кроків він проходить і як швидко отримує відповідь, залежить частка завершених реєстрацій.
Щоб розбір був предметним, а не загальним, надсилайте ввідні по вашому потоку — за ними ми зберемо схему й повернемося з оцінкою та планом впровадження.
- Сценарії перевірок: кого перевіряємо (фізособа, компанія, представник, кінцевий власник) і на якому кроці — реєстрація, перша угода, виведення коштів.
- Потрібні рівні: які документи й підтвердження обов'язкові, а які опціональні, для яких юрисдикцій.
- Поточний шлях даних: де зараз збираються дані клієнта і куди має повернутися результат — в особистий кабінет, у систему обліку, в чергу ручного розбору.
- Статуси провайдера: які відповіді потрібно підтримати (успіх, відмова, доопрацювання, ручна перевірка) і що при кожному робити далі.
- Політики зберігання: строки зберігання персональних даних, порядок видалення, хто відповідає за обробку запитів клієнтів.
- Провайдер і доступи: обраний із пулу (Sumsub, Onfido, Jumio) або відкрите питання, тестові ключі й контакт підтримки з боку провайдера.
- Обмеження: дата запуску, вікно відповіді клієнту, очікуване навантаження на добу.
Далі порядок такий. Спочатку розбираємо ваш потік перевірок і показуємо, де саме перевірка ламає воронку. Потім — оцінка та план впровадження: етапи, точка перемикання трафіку, порядок відкату на попередній потік.
Після узгодження називаємо строки підключення перевірок і стартуємо; до цього моменту рішення залишається за вами.
