Как работает KYC и биометрия

Как ИИ помогает обходить KYC

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

ProKYC и похожие «deepfake as a service»

В 2024–2025 году исследователи обнаружили коммерческие инструменты, специально ориентированные на обход eKYC — один из известных примеров называется ProKYC. Такие комплекты способны генерировать правдоподобные ID-документы, синтетические фото и даже короткие видео с лицом, адаптированные под требования eKYC-флоу (углы, выражение, длительность), что делает их опасными для многих автоматизированных систем проверки. Отчёты показывают, что эти продукты продаются в дарквеб-сообществах и уже применяются для автоматизированного создания мошеннических аккаунтов.

Почему это важно для финтеха: инструменты ProKYC и им подобные сводят на нет преимущество простых face-match / OCR систем — они создают «правильные» входные данные, которые выглядят валидными для обычной ML-модели.

Синтетические личности и масштабы проблемы

Наряду с deepfake-видео растёт и явление synthetic identity fraud — когда отдельные реальные фрагменты чужих данных (имя, SSN, дата рождения) комбинируются с полностью выдуманными профилями. Исследования и отчёты крупных агентств показывают резкий рост таких случаев: по данным Experian/TransUnion, доля синтетического мошенничества значительно выросла в 2023–2024 годах и в рядах некоторых стран достигла двузначных процентов в общем пуле инцидентов. Это создаёт системную проблему: тысячи заявок, которые выглядят легитимно, но на деле — синтетика.

Доступность обходов через рынок «услуг»

Исследования криминального рынка указывают: обходы верификаций продаются дешёво и массово — от относительно небольших сумм за одну операцию до подписок на «инструменты обхода» с ежемесячной/годовой оплатой. Это означает, что масштаб атаки способен вырасти быстро: злоумышленник может автоматизировать сотни верификаций, если цена за проход будет невысокой. Отдельные обзоры рынков показывают предложения «bypass KYC» с ценниками на уровне сотен долларов или даже меньше за кейс.

Технические приёмы атак (обзор, без инструкции)

Ключевые техники, которые злоумышленники комбинируют при обходе eKYC:

• Генерация синтетических лиц (статические фото), иногда с последующей «оживляющей» обработкой для создания видео-файла.
• Deepfake-видео, синтезированные под требования liveness (моргание, движение головы).
• Синтетические документы, с MRZ/штрихкодовыми зонами, адаптированные под OCR.
• Массовая регистрация с использованием прокси/сим-ротации и автоматизации (scale-attacks).

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

Почему классические liveness-проверки иногда не спасают

Многие коммерческие KYC-решения используют пассивный или активный liveness (моргание, поворот головы, улыбка). Однако современные deepfake-алгоритмы научились симулировать эти действия или создавать короткие видеоролики с правдоподобной кинематикой, способной пройти простые проверки. Кроме того, некоторые аппаратные и программные особенности (разрешение камеры, компрессия, артефакты экрана) могут скрывать признаки подделки, затрудняя детекцию. Поэтому одной только проверки «пользователь моргает» часто недостаточно.

Что это означает для бизнеса (кратко)

1. Рост фрод-риска и затрат на расследования. Появление «bypass as a service» удешевляет атаки и повышает их количество.
2. Переосмысление модели доверия: простые face-match и OCR должны дополняться многомодальными сигналами и аналитикой.
3. Необходимость Red-Team/Blue-Team тестирования: имитация продвинутых атак (без нарушения закона) для оценки устойчивости flow.

Практические рекомендации (коротко, технические направления защиты)

(Подробные контрмеры будут в отдельном разделе статьи; здесь — тезисно)

• Многомодальная биометрия: сочетание лица + голоса + поведенческих паттернов снижает шанс обхода.
• Device & session fingerprinting: отслеживание уникальных признаков устройства/сессии (камера, браузер, прокси) и выявление аномалий при массовых регистрациях.
• Аналитика аномалий и риск-скоринг: скоринг заявок на основе совокупности сигналов (история IP/почты, скорость прохождения флоу, однотипные шаблоны контента).
• Human-in-the-loop и эскалация: для подозрительных кейсов — ручная проверка опытным оператором.
• Поставщики детекции deepfake: интеграция специализированных сервисов, которые фокусируются именно на обнаружении сгенерированного видео.

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

Анонимизированные технические выдержки

Цитата A (анализ): злоумышленник использует статическое изображение, отображаемое на внешнем мониторе (27–32″ в портретной ориентации), как исходный материал, затем «оживляет» его нейросетью, получая короткое видео с имитацией естественных микродвижений (моргание, лёгкая улыбка, небольшой поворот головы).
Техническая интерпретация: комбинирование экранного источника + генерация видео (deepfake) с целью пройти селфи-чекинг; использование крупного монитора в портрете позволяет контролировать framing и уменьшить видимые рамки экрана в кадре.

Цитата B (анализ): злоумышленник намеренно снижает яркость монитора и яркость экрана смартфона при съёмке, чтобы ослабить проявление пиксельной сетки и других экранных артефактов.
Техническая интерпретация: попытка минимизировать характерные для фотосъёмки экрана признаки (Moiré, пиксельная сетка, полосы мерцания), которые могут служить сигналом «съёмка с дисплея» при детекции. Это показывает, что атакующие экспериментируют с оптическими условиями, чтобы обойти детекторы экранных артефактов.

Цитата C (анализ): предпочтение отдаётся ряду моделей телефонов (в описании — iPhone 6S–12); при этом рекомендовано многократно переинициализировать устройство (полный сброс) и менять системные параметры (language/locale, часовой пояс, имя устройства).
Техническая интерпретация: подбор «совместимых» комбинаций аппарат/ПО и попытки «обнулить» устойчивые признаки device fingerprint путем переинициализации/смены метаданных, чтобы снизить вероятность корреляции с предыдущими подозрительными сессиями.

Цитата D (анализ): злоумышленник использует прокси/специальные VPN-приложения или вручную задаёт прокси в настройках Wi-Fi, чтобы замаскировать географию и сетевой след.
Техническая интерпретация: попытки размыть сетевую телеметрию (IP/ASN/geo), чтобы усложнить дедупликацию сессий и репутационную оценку источников; это типичный приём для масштабных автоматизированных атак.

Цитата E (анализ): при автоматической съёмке (auto-capture) злоумышленники советуют ждать появления кнопки ручного фотографирования или манипулировать временем, чтобы избежать нежелательной автоматической фиксации.
Техническая интерпретация: атакующие отслеживают особенности UX приложения (automatic snapshot triggers) и подстраиваются под них, чтобы подать «удобный» для генератора материал; это подчёркивает, что уязвимости могут быть не только в моделях детекции, но и в конкретных поведениях клиентского приложения.

Цитата F (анализ): после успешной верификации рекомендация — не совершать транзакций минимум 48 часов и не менять номер на временные/анонимные сервисы, чтобы снизить вероятность раннего мониторинга и триггеров.
Техническая интерпретация: злоумышленник управляет «таймингом» пост-верификационной активности, чтобы избежать автоматических триггеров AML/behavioral monitoring, которые чаще срабатывают на ранних действиях после верификации.

Цитата G (анализ): в инструкции подчёркивается, что разные камеры (модели телефонов) по-разному обрабатывают изображение (цветокоррекция, компрессия, интерполяция пикселей) — и это используется при подборе комбинаций «источник картинки + модель камеры» для улучшения шансов прохождения.
Техническая интерпретация: атакующие empirically подбирают комбинации «source + capture device» для совпадения со статистикой легитимных примеров в обучающих датасетах KYC-провайдеров; это указывает на важность широкого охвата device-вариаций в обучении детекторов.

Короткое резюме по добавленным моментам

• Атакующие не ограничиваются генерацией контента — они системно калибруют оптические и системные параметры (яркость, угол, дистанция, модель камеры, метаданные устройства, сеть) для минимизации признаков подделки.
• Особая ставка делается на сведение экранных артефактов к минимуму (регулировка яркости, дистанции, ориентации), потому что эти артефакты — один из ключевых сигналов для screen-detectors.
• Есть явная стратегия «подготовка → тест → калибровка → боевой прогон», где шаги подготовки включают обмен снимками с «оператором» и подбор оптимальных параметров; это превращает единичную атаку в воспроизводимый, масштабируемый процесс.

Карта «шаг атаки → уязвимость → рекомендованная контрмера»

Конкретные детекции и сигналы, которые повышают вероятность обнаружения атаки

(высокоуровневые, не пошаговые)

• Temporal inconsistency score — измерять статистику микро-движений во времени: deepfake-видео часто имеет отличную спектральную подпись движений по сравнению с натуральной видеозаписью.
• Sensor noise fingerprinting (PRNU) — искать несоответствие между ожидаемым шумом конкретной камеры и шумовой подписью загруженного контента.
• Screen-artifact detectors — искать типичные признаки фото/видео, снятых с экрана: Moiré, полосы мерцания, повторяющиеся пиксельные паттерны, характерные для ЖК/OLED-сканов.
• Device attestation — если клиентское приложение поддерживает аппаратную аттестацию (например, SafetyNet/Play Integrity, Apple DeviceCheck / attestation APIs), повышать доверие к сессии только при наличии валидного HW-backed токена.
• Behavioral baselining — динамические профили: скорость прохождения шага, количество попыток, время между действиями; массовые похожие паттерны указывают на автоматизацию.
• Cross-channel verification anomalies — несоответствия между атрибутами: IP гео vs SIM/телефонный код vs почтовый домен vs паспортные данные.

Практические рекомендации по усилению защиты

• Внедрить многомодальное принятие решения (face match + document OCR + device attestation + behavioral score).
• Интегрировать специализированные датасеты и модели детекции deepfake (внешние поставщики + собственный fine-tuning).
• Разделять риск-политику: для повышенного риска — автоматически требовать ручную модерацию или дополнительные challenge-responses.
• Проводить регулярные red-team тесты, моделирующие современные AI-перегибы (без преступных действий) и верифицировать слабые места.
• Логировать и связывать метрики устройства/сессии и анализировать по агрегированным паттернам — это ключ к выявлению «bypass as a service» кампаний.

Заключение по кейсу

Анализ присланной инструкции показывает комбинацию трёх трендов:

1. Использование экранных источников как «сырья» для генерации контента;
2. применение генеративных моделей для создания правдоподобных видео;
3. Попытки скрыть или варьировать device/signal footprint.

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

Технический чек-лист контрмер для инженерной команды (KYC / биометрия)

Ниже — практичный, высокотехнологичный и приоритетный чек-лист по защите eKYC-флоу от современных атак (deepfake / synthetic identity / screen-based spoofing и т.д.). Всё ориентировано на реалии продакшена: какие сигналы собирать, какие модели/модули внедрять, как тестировать и какие метрики контролировать. Это защитный план — никаких инструкций по обходу.

Общая логика и приоритеты

• P0 (критично, внедрить в 1-й итерации): device attestation, device/session fingerprinting, базовые anti-proxy, passive+active liveness fusion, risk-scoring + escalation flow.
• P1 (важно, внедрить в 2-й волне): deepfake-детекция, PRNU / sensor fingerprint, screen-artifact detection, document authenticity features.
• P2 (дополнительно): голос/поведенческая биометрия, federated learning, advanced network reputation.

Архитектура и данные (обязательное)

1.1. Внедрить централизованный event pipeline для KYC (все события: попытки регистрации, загрузки селфи/видео, OCR-результаты, аттестация устройства, IP/ASN, почта, попытки входа) → хранилище аналитики (warehouse/stream).
1.2. Формат событий: JSON с набором рекомендованных полей (user_id, session_id, device_id, device_metadata, ip, asn, geolocation, attempt_number, timestamp, kyc_step_result, risk_score).
1.3. Обеспечить WORM-/immutable logs для расследований (с соблюдением retention policy).
1.4. Настроить RBAC для доступа к биометрическим данным; шифрование at-rest и in-transit (KMS).
1.5. Хранить минимально необходимые биометрические шаблоны; применять псевдонимизацию там, где возможно.

Device & Session fingerprinting (P0)

2.1. Собирайте и агрегируйте: device model, OS + build, camera model (если доступно), browser UA, screen resolution, timezone, locale, device name, boot_time, number_of_resets (если есть), app install timestamp.
2.2. Используйте HW-backed attestation (если доступно): SafetyNet / Play Integrity, Apple DeviceCheck / attestation APIs — использовать как высокодоверительный сигнал.
2.3. Отслеживайте «миграции» устройства: частые переинициализации/смены device metadata → повышенный риск.
2.4. Detect SIM-swap / SIM-rotate (если у вас telco-интеграция) — ставьте в риск-модель.

Критерий качества: false positive при fingerprinting < 5% на контрольной выборке; увеличение precision по фабрикованным кейсам.

Network & IP intelligence (P0)

3.1. Proxy/VPN/tor detection: агрегируйте общие признаки (known proxy IP lists, data center ASN, HTTP headers anomalies).
3.2. Оценка репутации IP / ASN / гео: сравнивайте с предыдущими сессиями одного user_id.
3.3. Correlation: множество регистраций/попыток с одного ASN/подсети → автоматический рост риска.

Actionable: блок/эскалация на подсетях с массовыми попытками; пометка для manual review.

Liveness / Biometric fusion (P0 → P1)

4.1. Fusion подход: не полагаться на один сигнал. Сочетать:

• passive liveness (micro-motion stats),
• active challenges (если риск высокий),
• device attestation,
• document ↔ face OCR match score,
• behavioral features.

4.2. Passive liveness metrics (собирать тайм-серии): blink_rate, head_rotation_spectrum, microexpression_variability, optical_flow_consistency.
4.3. Active challenges: только как эскалация для подозрительных сессий (не как default, чтобы не ухудшать UX).
4.4. Ensemble decision: weighted scoring of signals → final liveness_score. Настраивать threshold динамически.
4.5. Метрика: TPR/ FPR для liveness модулей; целевой FPR < configurable (бизнес-настроено).

Deepfake / Synthetic video detection (P1)

5.1. Внедрять специализированный модуль/модель, который анализирует видео на temporal inconsistencies, spectral artifacts, compression fingerprints и face rendering artifacts.
5.2. Добавить temporal inconsistency score (анализ движений во временной домене) и сравнение с эталонным распределением естественных движений.
5.3. Использовать внешние датасеты и собственный fine-tuning на ваших real/attack samples (anonymized).
5.4. При высоком риске — принудительная ручная верификация.

Тестирование: A/B тест против known deepfake samples, отчёт precision/recall.

Screen-artifact detection (P1)

6.1. Алгоритмы выявления съемки с экрана: Moiré pattern detector, stripe/refresh artifacts, repeating pixel grids, color banding, luminance pulsing.
6.2. Сигнал «screen_artifact_score» интегрировать в финальный risk_score.
6.3. При превышении порога — требовать альтернативный метод (video with challenge or manual review).

Camera sensor fingerprinting (PRNU) (P1)

7.1. Использовать PRNU / sensor noise fingerprinting, чтобы проверять, соответствует ли шумовая подпись файла ожидаемой для заявленной камеры модели.
7.2. Обновлять модель с новыми моделями камер и компрессиями.
7.3. PRNU использовать как приоритизированный сигнал (не абсолютное правило).

Document verification & OCR (P0 → P1)

8.1. Проверять MRZ, holograms, template consistency, fonts, element placement.
8.2. OCR confidence + template matching → document_authenticity_score.
8.3. Сопоставление данных из OCR с провайдерскими базами/реестрами (где возможно).
8.4. Detect synthetic doc features: repeated texture tiles, inconsistent lighting on microprint, unexpected compression artifacts.

Behavioral analytics & risk scoring (P0)

9.1. Создать централизованный risk engine (feature store) — в нём: device signals, network signals, liveness scores, document scores, behavioral features.
9.2. Risk bands и автоматические действия:

• low → allow, standard monitoring;
• medium → require challenge / delay limits;
• high → manual review / deny.

9.3. Features: attempts_per_hour, time_to_complete_kyc, click_timing_entropy, interaction_pattern_similarity (с историей аккаунтов).
9.4. Машинное обучение: использовать градиентные бустеры / LR / neural ensembles, важную роль играет feature importance и explainability (SHAP).

Тесты: ROC AUC, precision@k, lift vs baseline.

Human-in-the-loop и операционные процессы (P0)

10.1. Разработать UI/PLC для модераторов с prioritized queue (sorted by risk_score, likelihood_of_synthetic).
10.2. SLAs: max TAT для manual review (например, < 2 часа для P1) — настраиваемо.
10.3. Feedback loop: результаты ручной проверки должны попадать в обучающий датасет для моделей.

Escalation & post-verification controls (P0)

11.1. Для новых/высоко-рисковых аккаунтов: лимитировать операции (withdrawals, transfers) на период наблюдения (например, adaptive hold). (Бизнес-параметр — настраивать.)
11.2. Автоматический мониторинг post-KYC поведения (первые 48–72 часа) с повышенным scrutiny.
11.3. Триггеры: резкое изменение поведенческой модели, попытки смены контактных данных, множественные failed_login с new device.

Testing, Red-team и мониторинг (P0)

12.1. Регулярные red-team упражнения с легальными сценариями имитации атак (без нарушения законов).
12.2. Load & stress testing: массовые сессии, чтобы исключить bypass через scale.
12.3. Автоматические Quality Gates в CI: модели и правила не деплоятся без тестов на holdout и attack samples.
12.4. Постоянный мониторинг drift: мониторьте distribution drift для ключевых фич (device metadata, liveness stats).

Метрики: MTTR по инцидентам, percent of suspicious cases escalated, model drift alerts.

Логи, телеметрия и расследования (P0)

13.1. Логировать raw artifacts (изображения/видео) в зашифрованном хранилище с audit trail (только для расследований).
13.2. Собрать набор диагностических сигналов: liveness_score, deepfake_score, prnu_mismatch, device_attestation_validity, ip_reputation, attempts_count.
13.3. Отчёты по инцидентам: root_cause, attack_pattern_tag, remediation_action.

Privacy / Compliance (P0)

14.1. Явное согласие пользователя на обработку биометрии.
14.2. Data minimization: хранить только то, что нужно; retention policy для raw biometrics.
14.3. Оценка DPIA (Data Protection Impact Assessment) при внедрении новых биометрических модулей.
14.4. Документируйте причины автоматизированных решений (для регулятора и для возможности appeal).

CI/CD, модельный lifecycle и governance (P1)

15.1. Модельный pipeline: training → validation → bias checks → deployment → monitoring.
15.2. Versioning моделей и ability to rollback.
15.3. Explainability: сохранять feature importance и примерные объяснения решений для manual review.
15.4. Регулярный audit моделей на bias (age/ethnicity/device model).

KPI и дашборды (что показывать менеджменту)

• % успешных KYC, % false positives KYC, % false negatives (fraud slipped), average time to manual review, number of blocked attacks/month, model AUC, # of escalations.
• Мониторинг трендов: рост попыток обхода, новые ASN/ВАШ-паттерны.

Быстрый старт: минимальный набор действий (MVP)

• Включить device attestation + device/session fingerprinting.
• Собрать и централизовать логи KYC.
• Внедрить passive liveness + risk engine с простыми правилами (suspicious if attempts_per_hour > X, proxy detected, device_reset_count > Y).
• Настроить manual review queue и SLAs.

Рекомендации по валидации и тестовым наборам

• Собрать аннотированный датасет: реальные легитимные кейсы + known attack samples (анонимизировано).
• K-fold validation, A/B тестирование на production traffic (canary).
• Постоянный сбор обратной связи от модераторов и автоматическое пополнение training set.

Заключение — как читать этот чек-лист

1. Начните с MVP (device attestation, central logging, passive liveness, risk engine + manual review).
2. Далее последовательно добавляйте P1 элементы: deepfake detection, PRNU, screen detectors.
3. Параллельно запускайте red-team и настраивайте feedback loop для моделей.
4. Тюнинг thresholds и политик делайте на основе метрик (FPR/FNR, business loss) — нет «универсальных» настроек, всё зависит от специфики продукта.

Сравнительная таблица