Реализация KYC/KYB проверки в мобильном приложении

Реализация 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 провайдера в мобильное приложение, настраиваем серверный webhook для получения результатов, строим UI flow и обрабатываем все состояния верификации.

Интеграция Sumsub как пример

Sumsub — популярный выбор для СНГ и Европы. SDK для iOS (SumSubSDK) и Android (com.sumsub.sns:core).

Общий flow:

1. Backend создаёт applicant через Sumsub API: POST /resources/applicants с externalUserId (ваш userId).
2. Backend генерирует access token для SDK: POST /resources/accessTokens с applicantId и levelName (тип проверки: basic-kyc-level, poa-level, etc.).
3. Мобильное приложение получает access token от вашего backend (не напрямую от Sumsub — API secret на клиенте хранить нельзя).
4. SDK запускается с этим токеном.

// iOS
import IdensicMobileSDK

let sdk = SNSMobileSDK.init(
    accessToken: receivedToken,
    baseUrl: "https://api.sumsub.com",
    flowName: "basic-kyc",
    locale: "ru"
)
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("ru"))
    .build()
sdk.launch()

Обработчик onTokenExpiration — важен: Sumsub access token живёт 10 минут. Если пользователь завис на фото-шаге дольше — токен истечёт. SDK вызовет этот callback и ждёт обновлённый токен.

Liveness Detection: технические подробности

Современный liveness detection — passive (пользователь просто смотрит в камеру) или active (моргнуть, повернуть голову). Passive на ML-моделях, активный — на motion detection.

Требования к камере: минимум 720p, автофокус. Слабое освещение — частая причина failure. В 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 есть database поддерживаемых документов с точностью по типам.

MRZ (Machine Readable Zone) — нижняя полоса паспорта с зашифрованными данными. SDK извлекает данные из MRZ и сравнивает с визуальной зоной — extra validation.

KYB: верификация бизнеса

KYB сложнее KYC: нужны регистрационные документы компании, подтверждение адреса (утилитный счёт не старше 3 месяцев), KYC бенефициарных владельцев (UBO — beneficial owners с долей от 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 notification в мобильное приложение.

Мобильное приложение показывает статус "На проверке" с анимацией. Polling каждые 30–60 секунд — резервный механизм, если push не дошёл.

Хранение и соответствие GDPR

Изображения документов не хранятся на наших серверах — только у провайдера KYC. Мы храним только 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 командой.