Реалізація KYC/KYB верифікації в мобільному додатку
KYC (Know Your Customer) та KYB (Know Your Business) — це не просто "завантажити фото паспорта". Комплекс технічних та регуляторних вимог: верифікація особистості, liveness detection, перевірка по санкційним спискам, AML-скрининг, зберігання та аудит даних. Мобільний додаток — точка збору даних та orchestration процесу. Помилки коштують — відзив ліцензії або штрафи регулятора.
Вибір провайдера vs власна реалізація
Самостійна реалізація KYC — рідкість. Обробка документів, liveness detection з захистом від атак (фотографії, deepfake video, 3D-маски), перевірка по санкційним спискам (OFAC, EU, UN) — окремий продукт, який вимагає років розробки та постійних оновлень.
На ринку є зрілі SDK: Onfido, Jumio, Sumsub, IDnow, Veriff, Stripe Identity. Вибір залежить від географії користувачів, типів документів, вимог регулятора, ціноутворення.
Ми інтегруємо SDK провайдера у мобільний додаток, налаштовуємо server webhook для отримання результатів, будуємо UI flow, обробляємо всі стани верифікації.
Інтеграція Sumsub як приклад
Sumsub — популярний вибір для СНГ та Європи. SDK для iOS (SumSubSDK) та Android (com.sumsub.sns:core).
Загальний flow:
-
Backend створює applicant через Sumsub API:
POST /resources/applicantsзexternalUserId. -
Backend генерує access token для SDK:
POST /resources/accessTokensзapplicantIdтаlevelName. - Мобільний додаток отримує access token від вашого backend (не напряму від Sumsub — ніколи не зберігайте API secret на клієнті).
- SDK запускається з цим токеном.
// iOS
import IdensicMobileSDK
let sdk = SNSMobileSDK.init(
accessToken: receivedToken,
baseUrl: "https://api.sumsub.com",
flowName: "basic-kyc",
locale: "uk"
)
sdk.onStatusDidChange = { sdk, prevStatus in
switch sdk.status {
case .ready: break
case .incomplete: self.handleIncomplete()
case .pending: self.showPendingScreen()
case .approved: self.handleApproved()
case .declined: self.handleDeclined()
case .failed: self.handleError(sdk.failReason)
@unknown default: break
}
}
sdk.present(from: self)
// Android
val sdk = SNSMobileSDK.Builder(this)
.withAccessToken(token, onTokenExpiration = { callback ->
// обновити токен та викликати callback(newToken)
viewModel.refreshApplicantToken { newToken -> callback(newToken) }
})
.withLocale(Locale("uk"))
.build()
sdk.launch()
Обробник onTokenExpiration — важливий: Sumsub access token живе 10 хвилин. Якщо користувач завис на фото-кроці довше — токен закінчиться. SDK викличе цей callback та чекає оновленого токена.
Liveness Detection: технічні деталі
Сучасний liveness detection — passive (користувач просто дивиться у камеру) або active (моргнути, повернути голову). Passive на ML-моделях, активний — на motion detection.
Вимоги до камери: мінімум 720p, автофокус. Слабке освітлення — часта причина невдачі. SDK Onfido, Jumio мають real-time feedback: "Поліпшите освітлення", "Тримайте телефон рівніше". Sumsub аналогічно.
Атаки на liveness:
- Фотографія — базовий захист у всіх SDK.
- Видео replay — складніший захист.
- 3D-маски — захищають SDK класу enterprise (Jumio, Onfido).
- DeepFake — активна область розробки, не всі SDK захищають.
Рівень захисту залежить від тарифного плану провайдера. Для фінансових ліцензій (EMI, банк) — потрібен enterprise рівень.
Сканування документів
Всі SDK підтримують автоматичний capture: детектують краї документа, перевіряють blur, відображення, читаність. Користувач не натискає кнопку — SDK робить знімок при досягненні порога якості. Це критично: ручний capture дає 30–40% поганих знімків, автоматичний — 5–8%.
Підтримувані документи залежать від SDK та регіону. Sumsub охоплює 220+ країн. Onfido — 195. Кожен SDK має базу підтримуваних документів з точністю за типами.
MRZ (Machine Readable Zone) — нижня смуга паспорта з зашифрованими даними. SDK витягує дані з MRZ та порівнює з візуальною зоною — extra validation.
KYB: верифікація бізнесу
KYB складніше KYC: потрібні реєстраційні документи компанії, підтвердження адреси (утилітний рахунок не старше 3 місяців), KYC бенефіціарних власників (UBO — 25%+ частки).
Sumsub Business Verification та Jumio KYB підтримують KYB flow з wizard для збору документів. Особливість: кожен UBO проходить повний KYC окремо. Три бенефіціари — три KYC-перевірки, які можуть проходити асинхронно.
Мобільний додаток повинен підтримувати цей асинхронний flow: користувач відправив документи компанії, сейчас очікує верифікацію UBO-1, UBO-2 у процесі, UBO-3 ще не почав. Будуємо status dashboard з прогресом для кожного учасника.
Webhooks та polling
Верифікація — асинхронний процес (від хвилин до днів при ручній перевірці). Після сабміту документів SDK повідомляє статус pending. Реальний результат приходить через webhook на ваш backend.
Backend отримує webhook (applicantReviewed, applicantPending), оновлює статус користувача, відправляє push у мобільний додаток.
Мобільний додаток показує статус "На перевірці" з анімацією. Polling кожні 30–60 секунд — резервний механізм, якщо push не дійшов.
Зберігання та відповідність GDPR
Зображення документів не зберігаються на наших серверах — лише у провайдера. Ми зберігаємо лише applicantId, статус та дату перевірки. Права користувача на видалення даних (GDPR Article 17) — реалізуємо через API провайдера: DELETE /resources/applicants/{applicantId}.
Retention policy: більшість провайдерів зберігають дані 5–7 років (вимоги AML/FATF). При видаленні з провайдера задокументовуємо для аудиту — дані видалені.
Етапи роботи
Аналіз вимог регулятора та вибір провайдера → backend інтеграція (applicant creation, token generation, webhooks) → mobile SDK integration → UI flow (початок верифікації, очікування, результат) → handling всіх statuses (approved, declined, incomplete) → тестування на реальних документах у sandbox → security review → підготовка до audit.
Сроки: 15–25 робочих днів. Залежить від SDK провайдера (у кожного своя специфіка), вимог регулятора (деякі вимагають специфічних document types або додаткових перевірок), наявності KYB-компонента.
Серверна частина (webhook handling, AML integration, audit trail) — окрема оцінка з backend командою.