Архитектура

eKYC архитектура: identity verification как переиспользуемая capability

eKYC нужна не только для подключения SIM. Identity bridge для банка, регистрация в app, partner verification. Архитектура reusable identity capability.

Обсудить задачу

Зачем eKYC отдельной архитектурной capability

eKYC исторически делалась для одной задачи — onboarding клиента в момент покупки SIM. Сегодня identity verification нужна в десятках сценариев:

Регистрация в operator’s app.
Восстановление SIM при потере.
Самообслуживание для смены тарифа выше определённой суммы.
Подключение fintech-продукта через оператора.
Identity bridge для партнёра-банка (signed token).
Compliance check при подозрительной транзакции (step-up authentication).

В каждом сценарии — те же шаги: документ, биометрия, liveness, registry check. Если каждый строит свой стек — получается 5 разных eKYC-флоу с разной точностью и compliance.

eKYC как platform capability: один engine, потребляемый разными сценариями.

Структурные компоненты

Document capture. Снятие документа — паспорт, ID, водительское. С guidance UX (положите в рамку, поверните), automatic detection качества.

Document validation. OCR + structural validation (форма, holograms, MRZ для passport, watermarks). Fraud detection — выявление поддельных или edited документов.

Biometric capture. Снятие селфи/face. С ML-моделями, оптимизированными под условия captureа на mobile (плохой свет, motion blur).

Face matching. Сопоставление лица из селфи с лицом на документе. Score with threshold.

Liveness detection. Активная (по запросу повернуть голову, моргнуть) или пассивная (анализ texture, depth). Защита от photo / video / mask attacks.

Registry checks. Запросы в государственные реестры (паспорт valid, person существует, не в blacklist). В Узбекистане — через ОМС или платформу единой идентификации.

Risk scoring. Combined score: document quality + face match + liveness + registry + behavioural signals. Decisioning: pass / step-up / decline.

Audit. Каждый verification event с full evidence chain (документ скан, селфи, scores, registry response, decision, timestamp). Для post-fact dispute resolution и regulator queries.

Где обычно ломается

Стек собран из нескольких vendors, и каждый отвечает только за свою часть. При проблеме «почему отклонили» нет single point of accountability.

OCR работает на 80% документов, остальные 20% уходят в manual queue. Очередь растёт, customer experience ухудшается.

Liveness detection устарел, fraud-кейсы (deepfake, screen-replay) проходят. Через 6 месяцев team обнаруживает inflated activations.

Registry check — bottleneck. Государственный API недоступен 30% времени, eKYC останавливается.

Reuse не реализован. Клиент, прошедший eKYC при покупке SIM, проходит её заново в app. UX страдает, customer cost растёт.

Identity bridge для partners построен ad-hoc, без security audit. Bank принимает signed token, в котором signature не проверяется.

Identity bridge use case (partner verification)

Если оператор имеет verified identity, он может предоставлять signed token партнёру: «этот человек верифицирован, паспорт X, биометрия match, last verification 30 дней назад». Партнёр accepts токен вместо повторной проверки.

Архитектурные требования:

Token format: JWT or VC (Verifiable Credentials) с подписью оператора.
Scope claims: что именно verified (identity, address, age).
Freshness claim: сколько прошло с last verification.
Consent claim: клиент согласился на передачу partner X.
Revocation: способ отозвать token при withdrawal consent.

Это не «отдадим данные партнёру». Это «подтвердим факт verification» — partner получает claim, не raw data.

Operating model

Owner — Head of Identity / Head of Trust. Не fraud, не IT — продуктовая identity функция.

Команды:

Platform engineering (capture, scoring, integration)
Identity science (biometric models, fraud patterns)
Compliance (regulator requirements, KYC level)
Partnership (identity bridge contracts)

Routine — ежемесячный обзор pass/fail/step-up rates, fraud incidents, partner usage.

Что меряется

Pass rate — какая доля verifications проходит без manual review.

Manual queue size and SLA — сколько в очереди, сколько занимает review.

Fraud detection rate — какую долю fraud-attempts ловит.

False reject rate — сколько legit клиентов отвергнуто.

Time to verify — end-to-end latency.

Reuse rate — какая доля verifications новой capability потребляется существующими identities (без полного re-KYC).

Как SamaraliSoft подключается

eKYC Blueprint — 8-10 недель. Inventory current eKYC fragments по продуктам, target architecture (capture, scoring, registry integration), identity bridge framework для партнёров, choice of stack (build / Onfido / Jumio / local). Pilot — обычно один сценарий (например, app onboarding) или один partner identity bridge.