Как оценить надёжность liveness‑проверки: метрики и вопросы, которые стоит задать KYC‑поставщику
Удалённая регистрация сегодня выглядит почти магией: пользователь за полминуты делает селфи, слегка поворачивает голову - и уже получает доступ к продукту. Но за этим удобством прячется главный риск онбординга: по ту сторону камеры может быть не реальный клиент, а злоумышленник, который "показывает" системе чужое лицо - на бумаге, на экране или даже в подменённом видеопотоке. Поэтому liveness проверка (она же liveness detection) стала обязательным элементом там, где цена ошибки измеряется деньгами, судебными спорами и репутацией: в финтехе, банкинге, страховании и сервисах с высоким уровнем фрода.
Проблема в том, что рынок любит громкие обещания: "99,9% точности", "защита от deepfake", "международная сертификация". На практике под одинаковыми формулировками могут скрываться решения совершенно разного класса - от простого контроля моргания до полноценной системы против современных атак на предъявление. Чтобы не выбирать "по красивому демо", полезно опираться на понятные метрики и правильно задавать вопросы вендору. В качестве ориентира можно использовать гайд по метрикам liveness detection для выбора KYC‑поставщика, но разберём логику оценки последовательно.
---
Что такое liveness detection и какие атаки он должен ловить
Liveness detection - это проверка "живости": система должна убедиться, что перед камерой действительно живой человек, а не его имитация. В индустрии такие попытки обмана называют Presentation Attack. Самые распространённые сценарии выглядят так:
- Print Attack: распечатка лица, фото на бумаге, вырезанная маска.
- Replay Attack: заранее записанное видео на экране другого устройства.
- 3D‑маски: силиконовые/латексные или 3D‑печатные модели лица.
- Deepfake‑видео: синтезированная "говорящая голова" с высокой детализацией.
- Инъекция видеопотока: подмена данных через виртуальную камеру, API или на уровне SDK.
Ключевой момент: чем "умнее" атака, тем больше требований к модели и архитектуре. И если система уверенно ловит распечатку, это ещё не означает, что она переживёт deepfake или инъекцию.
---
Почему "точность" и F1‑score - слабая опора для финтеха
Вендоры часто показывают общую точность или F1‑score (среднее между Precision и Recall). В лабораторных условиях это может выглядеть убедительно: условные 0,90-0,95 легко превращаются в красивую презентацию. Но в liveness‑проверках цена разных ошибок несравнима:
- пропуск атаки - потенциальная кража денег и компрометация аккаунта;
- ложный отказ живому пользователю - потеря конверсии, рост нагрузки на поддержку и раздражение клиента.
Если обе ошибки "смешать" в одну цифру, можно получить аккуратный F1‑score и при этом иметь неприемлемо высокий риск пропуска атак. Поэтому в зрелых процессах KYC проверка личности онлайн оценивается не одной метрикой, а парой показателей, которые разделяют эти ошибки.
---
Главные метрики: APCER и BPCER (ISO/IEC 30107-3)
Индустриальная база для оценки liveness - стандарт ISO/IEC 30107-3 (Presentation Attack Detection). В нём используются две метрики:
- APCER (Attack Presentation Classification Error Rate) - доля атак, которые система пропустила, приняв мошенника за "живого".
- BPCER (Bona Fide Presentation Classification Error Rate) - доля настоящих пользователей, которых система ошибочно заблокировала.
Для финтех‑сценариев ориентиры обычно такие:
- по APCER: до 1% для базового уровня защиты (Level 1) или до 0,1% для более строгого (Level 2);
- по BPCER: примерно 1-2%, чтобы UX оставался терпимым и конверсия не проседала.
Именно эти цифры позволяют сравнивать решения содержательно: одно дело - "у нас 99,9% точности", и совсем другое - "мы показываем APCER 0,1% на наборе атак уровня Level 2 при BPCER 1,5%".
---
Уровни атак: Level 1 против Level 2 - в чём разница
В оценке liveness‑защиты важно понимать, какие атаки включены в тестирование.
Level 1 обычно описывает базовый фрод: распечатки, простые replay‑атаки, примитивные маски. Такие сценарии относительно доступны и встречаются массово - их должна останавливать любая взрослая система.
Level 2 - это продвинутые попытки обхода: более качественные 3D‑маски, deepfake‑контент, "чистые" записи с высоким разрешением и, что особенно опасно, попытки инъекции видеопотока. Здесь уже важны не только "умные" модели, но и то, как построен клиентский SDK и серверная часть: где принимаются решения, как защищён канал, можно ли подменить кадры до анализа.
---
Пассивный и активный liveness: два подхода с разной ценой для UX
На рынке обычно встречаются два семейства решений.
Пассивный liveness старается понять "живость" без явных действий со стороны пользователя: анализирует микротекстуры кожи, отражения, динамику освещения, естественные микродвижения. Он часто выигрывает по удобству (выше конверсия), но требует хорошей устойчивости к видео‑подменам и качественного антиспуф‑пайплайна.
Активный liveness просит человека сделать действие: повернуть голову, моргнуть, выполнить жест по подсказке. Это может усложнить простые replay‑атаки, но не гарантирует защиту от более сложных сценариев (например, если злоумышленник подаёт "правильный" поток в обход камеры). Кроме того, активные сценарии иногда ухудшают UX: людям сложнее пройти проверку с первого раза, особенно при плохом свете или слабом устройстве.
Выбор не всегда "или/или": некоторые KYC‑платформы комбинируют методы, переключая режим в зависимости от риска, устройства и контекста.
---
То, чего не видно на демо: архитектура и защита от инъекций
Даже если на демо‑стенде всё выглядит идеально, реальная стойкость часто определяется архитектурой. Важно выяснить, как система защищается от подмены видеоданных:
- есть ли проверки целостности и признаки виртуальной камеры;
- как устроены SDK‑механизмы анти‑тампер;
- где выполняется критический анализ (на устройстве, на сервере, гибридно);
- можно ли вмешаться в пайплайн до момента оценки "живости".
Инъекция - "невидимый фронт": пользователь на экране может выглядеть настоящим, а система будет получать не то, что снимает физическая камера. Поэтому при выборе решения полезно обсуждать не только метрики APCER/BPCER, но и модель угроз.
---
Ловушка "официальных тестов" и громких сертификатов
Сертификация и лабораторные отчёты - важная часть картины, но они не отменяют вопросов о применимости к вашему сценарию. Тест мог проводиться на ограниченном наборе атак, на идеальных устройствах, при хорошем свете и с "чистым" трафиком. А в продакшене появятся дешёвые Android‑смартфоны, нестабильная сеть, попытки эмуляции камеры и новые виды дипфейков, которые не попали в набор тестов полгода назад.
Полезнее воспринимать сертификаты как стартовую точку: "минимальный уровень подтверждён", а дальше - проверять, что именно измеряли и как это соотносится с вашими рисками.
---
Вопросы, которые стоит задать вендору (и почему они важны)
Перед тем как подписывать договор с тем, кто позиционируется как KYC поставщик, имеет смысл заранее выяснить:
1) Какие атаки включены в заявленные APCER/BPCER? Уточните Level 1/Level 2 и примеры.
2) На каких устройствах и условиях получены цифры? Реальные смартфоны, разные камеры, плохое освещение, низкая пропускная способность сети.
3) Как система защищена от инъекций и виртуальных камер? Нужны не общие слова, а описание механизмов.
4) Какие настройки порогов доступны и как они влияют на метрики? Иначе "хорошие цифры" могут оказаться результатом слишком жёсткой блокировки.
5) Как устроен мониторинг качества после запуска? Дрейф данных и эволюция атак неизбежны.
Часть этих принципов хорошо резюмирована в разборе надёжности liveness‑проверки и метрик ISO, но лучше сразу превращать их в вопросы на встречах и в RFP.
---
Дополнение: как связать метрики с экономикой и выбрать разумный баланс
На практике выбор - это всегда компромисс между безопасностью и конверсией. Поэтому помимо "какая точность" важно считать, во что выливается каждая ошибка именно для вашего продукта. Пропуск атаки может стоить десятки тысяч рублей в одном сегменте и миллионы - в другом; ложный отказ может бить по LTV сильнее, чем кажется, если пользователь уйдёт к конкуренту после двух неудачных попыток.
Отсюда появляется приземлённый вопрос: проверка живости цена - это не только тариф за одну транзакцию, но и стоимость потерь от фрода, падения конверсии и ручных проверок. Дешёвый чек в прайсе иногда оказывается самым дорогим решением на дистанции.
---
Дополнение: почему пилот лучше "сравнения по презентациям"
Если есть возможность, проведите пилот на вашем трафике: разные устройства, типичные условия съёмки, реальные воронки. Просите у вендора отчёт с APCER/BPCER на согласованном наборе атак и фиксируйте настройки порогов, чтобы цифры нельзя было "улучшить" постфактум.
Отдельно полезно проверить, что происходит при пограничных ситуациях: блики, очки, маски медицинского типа, тёмное помещение, фронтальная камера низкого качества. Именно там чаще всего ломается UX, а вместе с ним - конверсия в KYC проверка личности онлайн.
---
Дополнение: что должно быть после запуска, иначе метрики "устареют"
Даже сильная модель не остаётся сильной навсегда: меняются камеры, появляются новые генераторы deepfake, злоумышленники адаптируются. Поэтому в зрелом процессе важно, чтобы у решения были регулярные обновления антиспуф‑моделей, аналитика по причинам отказов, а также механизм быстрого реагирования на всплеск подозрительных паттернов.
Хороший признак - когда вендор заранее обсуждает пост‑продакшен мониторинг, а не только демонстрирует красивый onboarding‑ролик.
---
Итог: как понять, что liveness действительно надёжен
Если свести всё к практическому минимуму, то надёжность liveness‑проверки лучше оценивать не по "99,9% точности", а по конкретным индустриальным метрикам (APCER/BPCER), уровню атак (Level 1/Level 2) и архитектурной стойкости к инъекциям. А затем - подтвердить цифры пилотом и привязать решение к экономике продукта, потому что безопасность и конверсия всегда идут рядом.
Так выбор KYC‑платформы перестаёт быть верой в маркетинг и превращается в управляемую инженерную задачу.