Как оценить надёжность liveness‑проверки: гайд по метрикам для тех, кто выбирает KYC‑поставщика

Привет! Несколько абзацев о том, как понять, что человек, который проходит онлайн‑регистрацию — именно тот, за кого себя выдаёт? Поговорим про лабораторные метрики и реальные показатели.

Представьте, Ваш новый клиент проходит удалённую идентификацию за 30 секунд. Улыбается в камеру, поворачивает голову, делает селфи и вот он уже в системе. Но точно ли это тот самый человек, а не мошенник с чужой фотографией или подставным видеопотоком?

Для финтеха, банкинга, страхования, сфер с высоким риском вопрос, как определить, кто пришёл в личный кабинет — добропорядочный пользователь или злоумышленник — это повторяющаяся задача со множеством ответов. Внедрение KYC‑сервиса с технологией liveness‑проверок, как технологического этапа в процессе онбординга нового пользователя, — один из возможных ответов.

Однако от вендоров постоянно звучат одинаковые обещания: «точность 99,9%», «защита от deepfake», «сертифицировано по международному стандарту». А ведь за этими фразами могут стоять совершенно разные обещания: от простой проверки моргания до полноценной защиты.

Давайте посмотрим, по каким критериям оценивать liveness‑проверки в сервисе.

Зачем нужен liveness и от чего он защищает

Liveness detection или определение «живости» — это проверка, что перед камерой живой человек, а не его имитация.

Имитации живости называют атаками на предъявление (Presentation Attack). Вот наиболее частые:

• Print Attack — бумажная распечатка лица, поднесённая к камере или маска‑вырезка

• Replay Attack — видеозапись человека, воспроизводимая на экране другого устройства;

• 3D или объёмные маски — силиконовые, латексные или 3D‑печатные модели лица;

• Deepfake‑видео — синтезированное видео, транслируемое на экране высокого разрешения;

• Инъекция видеопотока — подмена данных на уровне программного интерфейса, виртуальной камеры.

Чем сложнее атака, тем более совершенная модель и архитектура требуются для её обнаружения.

Метрики: на что реально надо смотреть

Вендоры любят называть общую точность или F1-score, среднее между точностью (Precision) и полнотой (Recall).

Precision отвечает на вопрос: «Среди всех объектов, которые модель назвала положительными, какая доля действительно является положительными?»

Recall отвечает на вопрос: «Из всех существующих больных/мошенников/спам‑писем, сколько процентов мы нашли?»

F1 = 2  (Precision * Recall) / (Precision + Recall)

В задачах liveness detection значения F1-score варьируются:

F1-score полезный ориентир, но не главный, а для финтеха, например, даже вредный.

Дело в том, что стоимость пропуска атаки (мошенник получил доступ) и стоимость ложного отказа (реальный клиент не смог войти) несопоставимы.

В первом случае речь про деньги, возможно, большие деньги, и репутацию, во втором случае мы имеем дело с раздражением пользователя, что тоже нехорошо, но не наносит прямого ущерба.

Индустриальный стандарт для liveness — это не про F1-score, а про две отдельные метрики, закреплённые в международном стандарте ISO/IEC 30107–3 (Presentation Attack Detection).

APCER и BPCER: язык индустриального стандарта

В международном стандарте ISO/IEC 30107–3 оперируют двумя метриками:

APCER (Attack Presentation Classification Error Rate) — доля пропущенных атак. Для финтеха допустимо <= 1% (Уровень 1) или <= 0,1% (Уровень 2).

BPCER (Bona Fide Presentation Classification Error Rate) — доля заблокированных живых пользователей. Для приемлемого UX: <= 1–2%.

Уровни сложности атак: Level 1 и Level 2

В стандарте ISO 30 107 атаки разделяют на уровни, и система обязана блокировать каждый из них:

Level 1, базовый фрод:

• Бумажные распечатки и маски‑вырезки.

• Видеоповтор на другом смартфоне перед камерой.

Level 2, продвинутый фрод:

• Силиконовые и латексные маски

• Реалистичные 3D‑модели лиц

• Профессиональные deepfake‑видео на 4K‑дисплеях и планшетах с антибликовым покрытием.

Пассивный и активный liveness: два подхода, одна цель

Пассивный liveness

Нейросеть анализирует один кадр или короткий видеоролик без каких‑либо действий со стороны пользователя, чтобы найти:

• муаровые узоры (интерференция при съёмке экрана на камеру)

• текстуру бумаги или пиксельную сетку дисплея

• блики от плоской стеклянной поверхности

• отсутствие глубины, отсутствие объёма: плоский носитель не даёт микродисторсии и глубины настоящего лица, это проверяется через карты глубины (Depth Estimation).

Плюс: идеальный UX, клиент просто смотрит в камеру.

Минус: требует хорошо обученных моделей.

Активный liveness

Клиенту, который регистрируется, предлагают выполнить случайное действие: моргнуть, улыбнуться, повернуть голову, проследить за точкой на экране.

Плюс: эффективно против статичных распечаток.

Минус: уязвим к deepfake‑видео на экранах, если отсутствует этап пассивной проверки.

Эти детали — реальный повод задать своему потенциальному вендору вопрос: «А какие же, уважаемый, признаки атаки распознаёт твоя модель? И как ты это тестировал на реальных материалах: на бумаге, экранах, масках?»

Общая формулировка «у нас нейросеть», увы, ничего не сообщает о реальном покрытии типов атак.

Что выбрать?

Надёжное решение — всегда комбинация двух методов, потому что ни один из них по‑отдельности не работает удовлетворительно:

• Пассивный метод проверки ловит текстуру подделки, но не гарантирует, что перед камерой не крутят видео с нужными движениями.

• Активная проверка ловит статичные атаки, но её саму можно обмануть качественным дипфейком.

Задавайте вендору прямой вопрос: работает ли его система только на пассивном/активном livenes‑анализе или комбинирует методы?

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

Самая точная модель бесполезна, если архитектура сессии допускает обход. Оценивая решение, обращайте внимание на три элемента:

1. Связывание сессии (Session Binding). Видеопоток с движениями и финальное статичное селфи должны быть сделаны в рамках одной неразрывной сессии, одним человеком, на одном устройстве. Должна быть исключена возможность пройти видео‑челлендж настоящим лицом, а на этапе селфи подставить фотографию другого человека или перехватить API‑запрос.

2. Динамическая генерация заданий (Challenge‑Response). Команды «поверните голову влево», «моргните», «улыбнитесь») должны генерироваться сервером случайно в реальном времени. Фиксированная последовательность = возможность записать видео заранее и воспроизвести его.

3. Жёсткие тайм‑ауты. На каждое действие отводится несколько секунд. Это лишает злоумышленника времени на переключение экранов, замену масок или запуск нужного фрагмента записи.

Защита от инъекций: невидимый фронт

В ISO 30107–3 оценивают не только что «видит» камера, но и как данные поступают в систему:

• Контроль целостности SDK: приложение защищено от подмены видеопотока на уровне кода.

• Детекция виртуальных камер: блокировка эмуляторов, виртуальных драйверов, инструментов захвата экрана, которые позволяют транслировать заранее подготовленное видео вместо реальной картинки с объектива.

• Контроль метаданных: анализ EXIF‑данных, проверка соответствия разрешения камеры заявленному устройству.

Эта информация редко попадает в маркетинговые материалы, но именно отсутствие этих параметров чаще всего эксплуатируют профессиональные мошенники, которые не стараются обмануть нейросеть, они просто пытаются её обойти, подменив поток данных до момента анализа.

Задайте три конкретных вопроса к вендору:

1. Генерируются ли задания для liveness случайно на сервере или берутся из фиксированного набора?

2. Как его решение проверяет, что видео и селфи сняты в одной сессии?

3. Какой тайм‑аут установлен на выполнение действия?

Опасная ловушка официальных тестов и сертификатов

Официальный аудит устроен так: эксперты создают сотни искусственных атак, используя для этого фотографии тестировщиков, маски и снимки экранов.

Результат оценивают всё по тем же двум критериям:

• APCER = 0%. Для сертификации система не должна пропустить ни одной атаки из тестового пула. Ни для Level 1, ни для Level 2, если заявлен именно этот уровень.

• BPCER <= 15%. Формально допускается, что система может ошибочно отклонить реального человека в 15% случаев. Это много: для прода обычно нужен показатель в разы ниже: 1–2%.

Здесь и кроется ловушка: сертификатом подтверждают факт защиты от атак, но не комфортный пользовательский опыт.

То есть система может иметь честную сертификацию и при этом отклонять каждого седьмого живого клиента: просто эта цифра формально укладывается в требования аудита.

Тривиальное, но необходимое следствие: каждую систему нужно протестировать самостоятельно, несмотря на заявленные цифры в предоставляемых отчетах. Сравнивайте показатель BPCER именно со своим продакшен‑ориентиром, а не с лабораторным порогом.

Чек‑лист вопросов вендору

Что стоит выяснить перед тем, как заключать договор:

• Комбинирует ли система пассивную и активную проверки или полагается на один метод?

• Как защищён канал передачи видео, блокируются ли виртуальные камеры, эмуляторы, инъекции видеопотока?

• Проверяются ли метаданные снимка на соответствие заявленному устройству?

• Если в сценарии есть связка «видео + селфи», как обеспечено связывание сессии и случайна ли генерация заданий?

• Какой тайм‑аут установлен на выполнение действия в active‑проверке?

Что нам с этого

Liveness detection или проверка на «живость» — это способ убедиться, что перед камерой живой человек, а не фотография, маска, записанное видео, дипфейк. Без этой проверки дистанционная идентификация слабо защищена от простейшей подделки.

• Оценивать надёжность liveness по общей цифре «точности» бессмысленно.

• Индустриальный стандарт предполагает, что анализ эффективности провели по раздельным метрикам APCER и BPCER, закреплённым в ISO/IEC 30107–3.

• Система может быть способна отражать атаки разного уровня сложности: Level 1 или Level 2

• Надёжная система сочетает пассивный и активный методы проверки. В ней также предусмотрена защита канала передачи данных от подмены и, если сценарий это предполагает, есть надёжная связка видео‑челленджа с финальным селфи в рамках одной сессии.

Выбирая поставщика, запросите:

1. Отчёт с цифрами APCER и BPCER, не ориентируйтесь на абстрактную точность. Лучше если это будет независимый аудит, а не внутренние бенчмарки, хотя это не так принципиально.

2. Сравните эти цифры с реальными требованиями своего продукта, а это всегда баланс между бесшовным пользовательским опытом для честных клиентов, репутационными рисками и реальными убытками.

3. Убедитесь, что архитектура включает session binding, динамический challenge‑response и защиту от инъекций.