Что такое liveness detection в мобильных банках

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

На фоне роста генеративных атак регуляторы, банки и поставщики биометрии устроили вокруг этих зрачков настоящую гонку вооружений. Камера стала не просто способом войти в приложение или открыть счёт, а пограничным пунктом: она решает, действительно ли пользователь предъявляет себя или показывает системе удачную копию собственного лица. Кто в этой гонке побеждает — клиент, банк или мошенник? Разберём по порядку.

Банк не спрашивает, кто вы. Он спрашивает, живой ли вы. И это не философия — это алгоритм.

Что именно «видит» камера

Liveness detection, дословно «обнаружение жизни», — это программный слой поверх селфи-камеры, который пытается отличить живого человека от его изображения или имитации. В контексте мобильного банка технология нужна для проверки живого присутствия: пользователь действительно находится перед камерой в момент идентификации, а не предъявляет заранее подготовленный материал.

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

Термин Presentation Attack описывает попытку обмануть систему биометрической идентификации предъявлением искусственного объекта или изображения вместо живого человека. В случае банка таким объектом может быть фотография, запись лица, экран с воспроизведённым видео или изготовленная маска. Важна не форма атаки, а её логика: мошенник не взламывает модель напрямую, а пытается подсунуть ей убедительное доказательство присутствия.

Международный стандарт ISO/IEC 30107 посвящён именно противодействию таким атакам и описывает общие принципы, термины и подходы к тестированию систем. Его части, включая ISO/IEC 30107-3, используются как ориентир для лабораторных оценок. Но это не означает, что любой поставщик обязан автоматически иметь один и тот же отчёт или что сам факт упоминания стандарта превращает продукт в гарантированно защищённый. Стандарт задаёт язык и методологию проверки, а конкретные требования зависят от юрисдикции, сценария применения, политики банка и условий закупки.

Что именно анализирует алгоритм на стороне пользователя? Обычно не один «магический» признак, а совокупность сигналов:

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

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

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

Ниже установленного порога операция может быть отклонена, отправлена на повторную проверку или передана в дополнительный контур контроля. Выше порога — пройти дальше. Сам порог не является универсальным: банк меняет его в зависимости от операции, стоимости ошибки и общего риск-профиля клиента.

Активный против пассивного: где кончается безопасность и начинается UX

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

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

Преимущество очевидно: подделать не только внешний вид, но и корректную реакцию на конкретную последовательность команд сложнее, чем просто показать фотографию. Алгоритм получает дополнительный источник информации — поведение пользователя в момент проверки. При этом активная проверка не превращается в непробиваемую стену. Злоумышленник может подготовить более сложную атаку, а живой пользователь — не пройти проверку из-за плохого света, очков, особенностей мимики или неудачной инструкции.

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

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

Но слово «пассивный» не означает «примитивный» и тем более «автоматически слабый». Пассивная система может анализировать множество признаков, включая микродвижения, глубину, освещение и свойства видеопотока. Разница прежде всего в том, что пользователь не получает явной команды совершить действие. В некоторых сценариях этого достаточно, в других банку нужен дополнительный уровень уверенности.

Активный и пассивный подходы поэтому не всегда противопоставляются как «безопасность против удобства». На практике банк может использовать каскадную модель: сначала провести незаметную оценку, а при повышенном риске попросить пользователя выполнить дополнительное действие. Если первый этап обнаружил плохое качество изображения, несоответствие лица или признаки воспроизведения, система не обязана сразу завершать процесс отказом. Она может предложить повторить съёмку или перевести операцию в более строгий сценарий.

Это важная деталь: решение принимается не только по типу liveness. На него влияют сумма операции, новый ли это телефон, менялась ли SIM-карта, совпадает ли география, знакомо ли банку устройство и как ведёт себя аккаунт в целом. Биометрия — один сигнал в системе управления риском, а не самостоятельный судья.

Язык отрасли: APCER, BPCER и лабораторные тесты

Вендоры не продают liveness. Они продают протокол испытаний — и обещание, что его результаты имеют смысл за пределами рекламного слайда.

Если открыть сайт крупного поставщика биометрии, вы не обязательно увидите там слово «надёжный». Гораздо чаще будут аббревиатуры. APCER — Attack Presentation Classification Error Rate, доля атак, которые система ошибочно классифицировала как добросовестные предъявления. BPCER — Bona Fide Presentation Classification Error Rate, доля живых пользователей, которых система ошибочно отклонила как атаки.

Обе метрики нужны одновременно. Низкий APCER означает, что системе удаётся не пропускать презентационные атаки. Низкий BPCER показывает, что за безопасность не расплачиваются массовыми отказами нормальным клиентам. Если оптимизировать только один показатель, результат получится неудобным. Можно сделать модель крайне подозрительной и блокировать почти всех — формально атаки будут проходить хуже, но и банковский сервис перестанет быть сервисом. Можно, наоборот, упростить проверку ради конверсии и получить красивый пользовательский путь, через который легче пройдут подделки.

Лабораторные испытания нужны как раз для того, чтобы вынести оценку за пределы слов самого поставщика. Независимая организация может проверять систему по согласованной методике, используя разные типы предъявлений, устройства, условия освещения и сценарии атак. Среди известных участников рынка тестирования часто упоминают iBeta, но сам факт наличия лабораторного отчёта не отменяет необходимости смотреть, что именно тестировалось.

У любого отчёта есть контекст:

• какая версия алгоритма проходила проверку;
• использовалось ли конечное мобильное приложение или только отдельный модуль;
• какие типы атак вошли в испытания;
• на каких устройствах и при каком освещении всё происходило;
• какие пороги принимались для APCER и BPCER;
• как определялись успешная атака и ошибочный отказ;
• можно ли перенести результат лаборатории на конкретный банковский сценарий.

Поэтому фраза «технология протестирована по ISO/IEC 30107-3» сама по себе недостаточна. Она может означать, что определённый компонент проверяли в рамках методологии стандарта. Но это не универсальный знак качества на весь продукт, мобильное приложение и все возможные будущие атаки. Как только меняется камера, версия модели, способ интеграции или сценарий идентификации, часть выводов приходится пересматривать.

В России существуют собственные нормативные документы и процедуры оценки биометрических систем, в том числе ГОСТ Р 58624.3-2019. Его корректнее воспринимать как документ, описывающий подходы к тестированию и оценке устойчивости к презентационным атакам, а не как автоматическое доказательство того, что каждая банковская проверка должна быть устроена одинаково. Наличие стандарта не означает, что во всех сценариях обязательны активные команды или, наоборот, что пассивная архитектура является единственно правильной.

Здесь появляется первая настоящая щель в маркетинге. Вендоры любят писать «точность 99,9%». Почти всегда нужно уточнить, о чём именно речь: о распознавании лица, о прохождении liveness, об одном наборе данных или о конкретном типе атаки. На чужих данных, в чужих условиях освещения, на других телефонах и при иной компрессии видео цифры ведут себя иначе.

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

Как банки соединяют liveness с остальной системой

Проверка живого присутствия не существует в вакууме. Она встроена в цепочку идентификации, где каждый этап отвечает за свою часть задачи. Сначала приложение получает изображение с камеры, затем система оценивает качество кадра и наличие лица. После этого liveness проверяет, нет ли признаков презентационной атаки. Отдельный модуль может сопоставлять лицо с фотографией в документе или ранее созданным биометрическим шаблоном. Наконец, риск-движок учитывает контекст операции.

В этой цепочке liveness отвечает на вопрос: «Перед нами живой человек или предъявленный вместо него материал?» Он не отвечает на вопросы «тот ли это человек, за которого себя выдаёт?» и «имеет ли этот человек право проводить операцию?». Для них нужны сопоставление биометрии, документы, факторы аутентификации и поведенческие сигналы.

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

Для клиента это выглядит странно: «Я же настоящий». Для алгоритма — недостаточно. Настоящий человек может находиться перед камерой, но система должна быть уверена, что камера видит именно живое лицо, а не лицо на дисплее или в заранее подготовленном видеопотоке. Человеческая очевидность и машинное доказательство — разные вещи.

Почему один и тот же liveness ведёт себя по-разному

На результат влияют не только характеристики модели, но и эксплуатационная среда:

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

Отсюда следует практический вывод, который редко помещается в презентацию вендора: результаты лабораторного теста нельзя механически переносить на каждого пользователя. В банке важен не только показатель модели, но и то, как приложение подсказывает клиенту выбрать освещение, удерживать телефон и повторить попытку. Хороший UX в данном случае — часть безопасности, а не украшение вокруг неё.

Экономика безопасности: что liveness реально экономит банку

Возьмём кейс, который любят пересказывать вендоры на отраслевых конференциях. Крупный банк в Юго-Восточной Азии внедрил пассивное liveness-детектирование при открытии счетов. До внедрения уровень фрода оценивался в 15%, после — менее чем в 2%, а экономический эффект составлял около 500 000 долларов в год. Цифры красивые, но здесь нужно задать неудобный вопрос: это результат одного liveness или всего пакета изменений, в который входили новые правила проверки, мониторинг и другие защитные меры?

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

Пассивное liveness — фильтр первого уровня. Он может отсекать распечатанные фотографии, видео с экрана и некоторые варианты масок, не заставляя клиента выполнять дополнительные команды. При этом он не ловит социальную инженерию, когда живой человек сам диктует коды из СМС «сотруднику банка». Он не исправляет утечку биометрических данных и не останавливает захват уже авторизованной сессии. Он работает на конкретном участке — в момент предъявления лица.

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

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

Хорошая архитектура умеет не только отказать, но и объяснить, что делать дальше. Переснять лицо при равномерном освещении, снять очки, протереть камеру, обновить приложение или перейти к ручной проверке — это разные ответы на разные причины сбоя. Если всем пользователям показывать одинаковое «не удалось пройти проверку», банк экономит несколько строк интерфейса и приобретает волну обращений в поддержку.

Границы возможностей: почему liveness не панацея

Liveness detection защищает ровно один участок — момент предъявления биометрии. Это замок на входной двери: он не остановит того, кто залезет через окно.

Технология не делает следующего:

• Не защищает от утечки биометрических шаблонов из баз данных. Если злоумышленник получил доступ к данным на сервере, камера на телефоне не остановит атаку, которая идёт в обход пользовательской проверки.
• Не защищает от социальной инженерии. Модель не знает, что вы пять минут разговаривали по телефону с «сотрудником банка», который убедил вас пройти проверку для разблокировки счёта.
• Не заменяет второй фактор. Пароль, PIN-код, одноразовый код, подтверждение на доверенном устройстве и другие механизмы остаются частью общей схемы, если они предусмотрены конкретным сценарием.
• Не подтверждает право на операцию. Живой человек может пройти liveness, но это ещё не означает, что он владелец аккаунта или что операция соответствует его обычному поведению.
• Не устраняет риск захвата устройства. Если мошенник получил контроль над телефоном или сессией, проблема может возникнуть уже после успешной биометрической проверки.
• Не гарантирует стопроцентную защиту. Любая модель ограничена данными, на которых её обучали, устройствами, для которых её проверяли, и типами атак, которые попали в тестирование.

Отдельно стоит тема дипфейков. В публичных материалах Sumsub приводился показатель, согласно которому использование активных проверок помогало снизить уровень мошенничества с дипфейками до 91% в рассматриваемом контексте. Это показатель снижения мошенничества, а не утверждение, что система заблокировала 91% всех атак в любых условиях. Переносить его на каждый банк, рынок и сценарий было бы некорректно.

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

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

Самая опасная ошибка — считать, что проверка лица подтверждает всю личность и всю операцию. Она подтверждает только то, что смогла измерить.

Так стоит ли доверять морганию в камеру

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

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

Покупателю банковской технологии стоит смотреть не на обещание «99,9% точности», а на контекст: какие атаки тестировали, на каких устройствах, с какими порогами ошибок, как система ведёт себя при плохом свете и что происходит после отказа. Пользователю — понимать другое: если приложение просит моргнуть, это не попытка убедиться в вашем здоровье и не странный ритуал ради ритуала. Банку нужно проверить, что перед камерой не фотография и не экран.

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

Банк действительно заботится о том, живой ли вы. Но заботится не о вашем здоровье — о ваших деньгах. А это, согласитесь, две большие разницы.