Селфи больше не доказывает, что перед камерой находится реальный клиент. У мошенника может оказаться фото паспорта из утечки, изображение лица из соцсетей и инструмент для подмены видео. Поэтому в KYC-процессе одной сверки селфи с документом уже недостаточно. Бизнесу нужна связка проверок документа, лица, живого присутствия, цифрового следа устройства и журнал решений.
Почему проверка на живость стала обязательной в 2026 году
Проверка на живость (liveness detection) показывает, что перед камерой находится реальный человек, а не фотография, видео с экрана, маска или дипфейк. В международной терминологии она относится к обнаружению атак на биометрическое предъявление (Presentation Attack Detection, PAD). Сверка селфи с паспортом отвечает на вопрос «одно ли это лицо», проверка на живость отвечает на другой вопрос: «присутствует ли человек сейчас» (ГОСТ Р 58624.3-2019).
Удалённая идентификация стала удобнее для клиента и привлекательнее для мошенника. Злоумышленники всё чаще пытаются украсть «цифровое лицо» пользователя под видом проверки личности: просят включить камеру, показать лицо в разных ракурсах, а затем используют запись для доступа к сервисам с видеоидентификацией, создания поддельных документов, фейковых профилей и дипфейков («Российская газета»).
Мошенники проводят атаку в несколько этапов: звонят, переводят человека в мессенджер, отправляют ссылку на фейковое приложение, просят показать лицо или прислать видео. По данным BI.ZONE AntiFraud, в III квартале 2025 года телефонные и мессенджер-атаки выросли на 50 % по сравнению с предыдущим кварталом, фейковые приложения на 35 %, а сценарии подмены руководителя (fake boss) с подменой голоса или изображения на 30 %. Для KYC-процесса такие атаки повышают риск подмены личности при регистрации, входе и подтверждении операций.
В онлайн-займах биометрия закреплена в правилах, но рынок проходит переходный период. МФК обязаны идентифицировать клиентов через ГИС ЕБС при дистанционной выдаче займов с 1 марта 2026 года; для МКК срок установлен на 1 марта 2027 года («Российская газета»). Банк России до 1 января 2027 года воздерживается от мер надзорного характера к МФК, которые пока не исполняют обязанность удалённой идентификации через ЕБС («Коммерсантъ»). Временное смягчение надзора меняет сроки внедрения, но сохраняет требование к доказуемой идентификации, поэтому KYC-командам стоит готовить интеграцию, журналирование и понятный сценарий проверки клиента уже сейчас.
С 20 февраля 2026 года вступил в силу федеральный закон № 38-ФЗ о цифровых финансовых активах и цифровой валюте. Он установил требования к идентификации клиентов криптоплатформ и обменников: площадки обязаны использовать методы автоматизированной биометрической верификации при регистрации и крупных операциях. Проверка живого присутствия в таком сценарии становится обязательным элементом KYC-процесса для операторов обмена цифровой валюты и криптовалютных бирж (подробнее о требованиях 38-ФЗ). Закон не разрешает идентификацию только по статичному фото: нужна проверка в реальном времени.Банк России отдельно предупреждал, что качество дипфейков растёт, мошенники активнее используют голосовые и видеоподделки для хищения денег, а вернуть похищенное непросто (Банк России на «Банки.ру»). Сервису нужно заранее определить правила эскалации: когда хватит пассивной проверки на живость, когда нужен активный сценарий, когда заявка переходит в ручной режим. От этих правил зависит баланс между безопасностью и конверсией в онбординге.
Финтех-компании всё чаще проектируют KYC сразу под несколько рынков. Локальные требования различаются, но проверка живого присутствия остаётся базовой задачей удалённой идентификации. В Казахстане Национальный банк запустил промышленную эксплуатацию сервиса удалённой биометрической идентификации для финансовых услуг ещё в октябре 2020 года: с его помощью открывают счета, выпускают карты и оформляют кредиты. В Узбекистане для кредитных и платёжных организаций вводятся требования использовать биометрическую идентификацию с функцией определения живости в реальном времени; идентификация по фотографии не допускается (Gazeta.uz). Проверку живого присутствия лучше сразу проектировать как часть масштабируемого KYC-процесса с учётом разных документов, камер, языков интерфейса и локальных правил хранения данных.
Как работает проверка на живость: от камеры до антифрод-решения
Модель оценивает живое присутствие по нескольким группам сигналов: текстуре кожи, бликам, глубине сцены, движениям головы, микромимике, частоте кадров, шуму сенсора и качеству видеопотока. По отдельности эти сигналы могут ввести модель в заблуждение: на них влияют освещение, особенности камеры, качество связи и движения пользователя. Поэтому проверка на живость опирается на совокупную оценку.
Базовая проверка отличает живое лицо от плоского изображения. На распечатанном фото система видит плоскую геометрию, бумажную фактуру и однородную подсветку. На экране второго устройства появляются муар, пиксельная сетка, неестественные блики и следы подсветки. Более зрелая проверка анализирует отражения в зрачках, микродвижения лицевых мышц, согласованность лица с фоном, временную стабильность кадров и реакцию на смену освещения. На анализе этих сигналов строится защита от дипфейка в реальном времени (live deepfake).
Проверка на живость хорошо отвечает на один вопрос: перед камерой реальный человек или подмена. Но по одному лицу сервис не видит весь контекст заявки: с какого устройства пришёл пользователь, включён ли VPN, используется ли эмулятор, были ли повторные попытки и почему видеопоток выглядит необычно. Поэтому в рабочем KYC-сценарии определение живости лучше связывать с анализом цифрового следа устройства (device fingerprint), риск-скорингом и журналом событий. Тогда итоговая оценка учитывает и лицо, и обстоятельства проверки.
В трансграничных сценариях такая связка становится особенно важной. Пользователь может проходить проверку с недорогого устройства, при разном освещении, качестве связи и типе документа. Модель должна сохранять качество проверки даже там, где селфи получилось неидеальным.
Если анализ селфи уже есть в KYC-процессе, логичным представляется следующий шаг: добавить проверку на живость. IDX предлагает Liveness Detection как часть биометрического антифрода для удалённой идентификации.
Активный и пассивный режим: что выбрать и для каких целей
Активная проверка просит пользователя сделать простое действие: моргнуть, повернуть голову, приблизить лицо к камере или произнести фразу. Такой сценарий легко объяснить клиенту, человек понимает, что сервис проверяет его присутствие перед камерой. Но активный шаг добавляет 2–3 секунды к онбордингу и чаще приводит к отказам из-за плохого света, слабой камеры или непонятной инструкции.
Пассивная проверка работает без команд. Пользователь просто смотрит в камеру 1–2 секунды, а модель оценивает текстуру лица, глубину, микродвижения, блики и качество видеопотока. Такой сценарий лучше подходит для массового мобильного онбординга: он почти не меняет путь пользователя. Но отказ в таком сценарии нужно обрабатывать особенно аккуратно: пользователь не выполнял видимого действия, а решение строилось на сигналах, которые он не видит.
На практике финтех-сервисы редко выбирают только один режим. Пассивная проверка хорошо работает в массовом онбординге, активная подходит для точек повышенного риска. Поэтому удобнее собирать их в один гибридный сценарий. Пассивная проверка идёт по умолчанию, активная включается, когда появляются признаки риска: низкая уверенность модели, новое устройство, крупная сумма, рискованный регион, совпадение с фрод-паттерном или повторная попытка после отказа.
Такой подход особенно удобен для продуктов, работающих сразу на нескольких рынках СНГ. Сервис сохраняет один маршрут онбординга для всех клиентов, но настраивает риск-правила под конкретный продукт: кредит, кошелёк, P2P-площадку, криптообменник, страховой или инвестиционный сервис.
|
Сценарий |
Рекомендуемый режим |
Почему |
|---|---|---|
|
Регистрация в мобильном приложении |
пассивный |
минимальное влияние на конверсию |
|
Вход с нового устройства |
пассивный, активный при аномалиях |
проверка усиливается только при риске |
|
Стандартный заём без признаков риска |
пассивный |
риск умеренный, конверсия важна |
|
Крупная операция |
активный |
цена ошибки выше, чем лишние секунды проверки |
|
Повторная попытка после отказа |
активный и ручная проверка |
нужно отделить фрод от плохого света или камеры |
Проверка должна работать как управляемая процедура с понятным запасным сценарием (fallback). Если клиент не прошёл проверку из-за плохого освещения в комнате или блика, правильнее подсказать, что изменить, дать повторную попытку и при необходимости перевести заявку на ручную проверку. Автоматический отказ по одному слабому сигналу ломает конверсию и создаёт жалобы.
Дипфейки и спуфинг-атаки: какие бывают и как им противостоять
Атаки на биометрический онбординг делятся на несколько классов:
- атака с распечатанной фотографией (print attack): перед камерой показывают фото на бумаге;
- воспроизведение фото или видео с экрана (replay attack): используют второе устройство;
- атака с 3D-маской (3D-mask attack): мошенник применяет силиконовую, латексную или напечатанную маску;
- дипфейк в реальном времени (live deepfake): подмена лица идёт прямо в видеопотоке.
У этих атак разная цена для мошенника и разная сложность защиты. Атаки с фотографией и видео с экрана может применить почти любой злоумышленник, поэтому их должны блокировать даже базовые модели. 3D-маски встречаются реже, их используют точечно и обычно ради дорогих операций. Сложнее всего противостоять дипфейку в реальном времени: подмена лица идёт прямо в видеопотоке, и если сервис ограничивается простой проверкой реакции, атака может пройти. Отразить такую атаку получится, когда сервис учитывает и лицо, и параметры устройства, поведение видеопотока и другие признаки заявки.
Базовое решение и зрелый антифрод различаются именно тем, каким из этих атак они противостоят. Базовая модель справляется с фотографией и видео с экрана, но плохо распознаёт подмену лица в реальном времени. У зрелого подхода другая архитектура: проверка на живость, сверка лица, проверка документа, цифровой след устройства, поведенческий анализ и журнал событий работают в одном процессе. В блоге IDX эта логика уже описана в статье «Подделка лица (Face Spoofing)»: чтобы остановить подделку лица, недостаточно его распознать, нужно проверить само предъявление перед камерой.
В трансграничных сценариях атака редко ограничивается одним шагом. Сначала мошенник получает фото документа или лица, потом пытается пройти регистрацию, затем меняет устройство, номер телефона или платёжные реквизиты. В такой цепочке одной проверки при онбординге недостаточно: liveness нужно подключать и при крупных операциях, смене реквизитов и других точках повышенного риска.
ГОСТ, ЕБС и ISO/IEC 30107-3: как оценивать liveness-поставщика в России
Для площадки, которая собирает KYC-процесс, важно учитывать, что liveness работает с биометрическими персональными данными пользователя. Команде нужно заранее знать, где обрабатываются биометрические образцы, сохраняются ли они, как распределены роли сторон и какие данные попадут в журнал проверки. Закон 152-ФЗ относит к биометрическим персональным данным сведения, которые характеризуют физиологические и биологические особенности человека и используются для установления личности, и устанавливает особый порядок их обработки.
Отдельно для идентификации и аутентификации с использованием биометрических персональных данных действует закон 572-ФЗ. Он регулирует работу Единой биометрической системы и порядок идентификации или аутентификации физических лиц с использованием биометрии. Поэтому поставщика liveness-решений важно оценивать шире, чем по качеству самой модели. Для KYC значимы обработка биометрии, хранение данных, защищённый обмен, журналирование и возможность восстановить ход проверки при споре.
Для KYC-команды базовый набор вопросов выглядит так:
- где обрабатывается биометрический образец: на устройстве пользователя, в контуре поставщика, в инфраструктуре заказчика или через сервис ЕБС;
- сохраняется ли образец после проверки или используется только для разового решения;
- как распределены роли сторон: кто выступает оператором персональных данных, кто обрабатывает данные по поручению, кто отвечает за биометрическое взаимодействие;
- какие события попадают в журнал: request_id, дата и время, версия модели, оценка уверенности, класс атаки, итоговый вердикт;
- можно ли восстановить ход проверки при споре, жалобе клиента, внутреннем расследовании или запросе партнёра.
У ЕБС есть отдельный сервис проверки «живости». В методических рекомендациях ЕБС он описан как государственный сервис ГИС ЕБС для биометрических систем в процессах аутентификации, верификации и идентификации. В тех же материалах указано, что при использовании сервиса Liveness биометрические образцы обрабатываются без сохранения в информационной системе контрагента и в средствах съёма.
Для площадки здесь возникает развилка: если сценарий должен работать через ЕБС, команда заранее проверяет роли сторон, порядок обмена данными и совместимость пользовательского маршрута, если liveness используется внутри собственного KYC-процесса, остаются требования к законности обработки биометрии, хранению, защите канала, логированию и управлению отказами.
Для оценки liveness-поставщика в России есть профильный стандарт ГОСТ Р 58624.3-2019. Он описывает, как испытывать механизмы обнаружения атак на биометрическое предъявление и как оформлять протоколы таких испытаний. Стандарт введён в действие с 1 июня 2020 года и основан на ISO/IEC 30107-3:2017, но принят как модифицированный национальный стандарт.
В техническом задании лучше избегать общей формулировки «защита от дипфейков». Она звучит убедительно, но плохо проверяется. Надёжнее описывать требование через обнаружение атак предъявления (Presentation Attack Detection, PAD): какие атаки должен распознавать сервис, какие метрики показывает поставщик, как проводились испытания, какая версия продукта тестировалась и какие данные попадут в журнал проверки.
Международный стандарт ISO/IEC 30107-3 помогает сравнивать PAD-механизмы у разных поставщиков. Аккредитованная лаборатория iBeta проводит испытания PAD-подсистем по этому стандарту и публикует в отчётах метрики APCER и BPCER, а также связанные показатели отсутствия ответа. APCER показывает риск принять атаку за живого пользователя. BPCER показывает риск ошибочно отклонить настоящего клиента как атаку.
Отдельный сигнал риска: обещание «100 % защиты от дипфейков». В биометрическом антифроде такая формулировка некорректна. Корректный поставщик объясняет границы модели: какие типы атак закрывает решение, какие ошибки возможны, как часто обновляется модель, что происходит при низкой уверенности и когда заявка должна уходить на повторную или ручную проверку.
Для российского рынка к техническим критериям добавляются локальные требования: обработка биометрических персональных данных, совместимость с ЕБС при применимости, защищённый обмен, хранение журналов и доказуемость каждого решения. Хороший liveness-поставщик должен быть понятен не одной ML- или антифрод-команде. Его ответы должны выдерживать вопросы compliance, DPO, юристов и службы поддержки.
Интеграция liveness в KYC-процесс: API, SDK и типовые ошибки
В рабочем KYC-процессе liveness работает вместе с остальными проверками: документом, селфи, сверкой лица с фото в документе, анализом устройства и итоговым скорингом. Документ предоставляет эталонные данные, проверка на живость подтверждает присутствие человека перед камерой, сверка лица связывает пользователя с документом, а цифровой след устройства добавляет контекст заявки.
Подключить liveness можно через мобильный SDK, веб-захват изображения (web capture) или API. Мобильный SDK обычно даёт больше сигналов: нативную камеру, стабильный видеопоток, параметры устройства и более управляемый сценарий захвата. Веб-захват быстрее встроить в веб-воронку или лид-форму, но часть сигналов устройства может быть недоступна. API удобен, когда KYC-процесс уже собирается из нескольких внутренних и внешних модулей.
Для финтеха часто подходит гибридная архитектура. На раннем этапе воронки можно использовать веб-сценарий, чтобы не усложнять путь клиента. На финальном KYC, при выпуске продукта, изменении лимитов или рискованной операции лучше подключать SDK или усиленный сценарий с дополнительными сигналами.
API-ответ должен быть пригоден для интерфейса, антифрода и расследований. В нём стоит предусмотреть:
- вердикт: живой пользователь, атака, неопределённый результат или аналогичные статусы;
- оценку уверенности модели (confidence-score) или другой показатель надёжности решения;
- класс атаки при отказе, если сервис его определяет;
- качество захвата: свет, положение лица, резкость, стабильность потока;
- идентификатор проверки (request_id);
- версию модели или правил, по которым принято решение;
- связь с KYC-заявкой, пользователем, документом и устройством.
Если сервис работает в нескольких странах, API лучше проектировать с запасом. В нём стоит предусмотреть страну документа, тип документа, язык интерфейса, локальные правила хранения, источник риск-оценки и настройки повторной проверки. Такой запас помогает выходить на новый рынок без перестройки всего онбординга.
Самая частая ошибка: liveness запускают только при регистрации. Риск появляется и после создания аккаунта: при входе с нового устройства, изменении реквизитов, восстановлении доступа, крупной операции, повышении лимита или подозрительном поведении. В таких сценариях повторная проверка живого присутствия может быть важнее, чем первичный онбординг.
Вторая частая ошибка состоит в том, что компания не логирует PAD-события. Без request_id, версии модели, статуса проверки и причины отказа сложно разбирать жалобы, доказывать корректность решения и улучшать правила антифрода. Для compliance-команды отсутствие журнала иногда становится такой же проблемой, как слабая модель.
Третья ошибка возникает там, где liveness воспринимается как замена проверки документа. Живой человек перед камерой ещё не доказывает, что он предъявляет свой паспорт. Поэтому проверка на живость должна работать вместе с распознаванием документа, проверкой признаков подделки, сверкой лица, анализом устройства и скоринговыми правилами.
Четвёртая ошибка возникает там, где клиент получает автоматический отказ по одному слабому сигналу. Плохой свет, старая камера, нестабильный интернет или блик на очках могут дать неуверенный результат. В зрелом процессе предусмотрены запасные сценарии: подсказка пользователю, повторная попытка, активный сценарий, ручная проверка или альтернативный маршрут.
Если компания уже внедряет распознавание паспорта или удалённую идентификацию, liveness лучше закладывать сразу как часть общего KYC-процесса. Так проще связать документ, лицо, живое присутствие, устройство, журнал событий и правила ручной проверки. В IDX такой сценарий можно собрать вокруг Liveness Detection и других инструментов подтверждения личности.
