Выбор KYC-провайдера начинается с ответа на вопрос, что закон требует именно от этого бизнеса, — сравнение функций в презентациях вендоров имеет смысл только после этого. Идентификацию клиента обязана проводить сама организация, отнесённая к субъектам ст. 5 Федерального закона от 07.08.2001 № 115-ФЗ, — поручить её можно только прямо названным в законе лицам, и коммерческий KYC-вендор в этом перечне не значится. Из этого прямо следует, какие требования к поставщику вообще имеют смысл: провайдер поставляет техническое средство, саму обязанность это не закрывает.
У банка, микрофинансовой организации (МФО) и маркетплейса эта обязанность устроена по-разному и опирается на разные нормы и сроки. Банк вправе опираться на государственную инфраструктуру — единую систему идентификации и аутентификации (ЕСИА) и единую биометрическую систему. Микрофинансовые компании обязаны делать то же самое с 1 марта 2026 года; для микрокредитных компаний это отложено до 1 марта 2027 года. У маркетплейса обязанность проверки устроена иначе: она закреплена за оператором платформы и реализуется через закрытый перечень способов проверки.
С чего начинается выбор: кто отвечает за результат проверки
Круг обязанных лиц определяет ст. 5 115-ФЗ — в него входят и банки, и микрофинансовые организации, а сама обязанность идентифицировать клиента установлена пп. 1 п. 1 ст. 7. Закон разрешает поручить это только прямо названным лицам: кредитная организация вправе поручить идентификацию организации почтовой связи, оператору связи или аккредитованному удостоверяющему центру (п. 1.5 ст. 7); профессиональные участники рынка ценных бумаг, операторы инвестиционных платформ, управляющие компании, операторы информационных систем цифровых финансовых активов, цифровые депозитарии и страховые организации вправе поручить её только кредитной организации (п. 1.5-1 ст. 7); микрофинансовые организации — тоже только кредитной организации (п. 1.5-2 ст. 7). Требования к кредитным организациям, которым можно поручить идентификацию, и к поручающим МФО устанавливает Банк России по согласованию с Росфинмониторингом (п. 1.5-3 ст. 7).
Коммерческий KYC-вендор в этом перечне не упомянут ни разу. Поставщик технологии поставляет инструмент — распознавание документа, проверку по базам, антифрод-контур, — а обязанным лицом перед законом и регулятором остаётся сама организация. Формулировка «провайдер проводит идентификацию за компанию» или «подключение сервиса закрывает требования 115-ФЗ» этому распределению ответственности не соответствует. Подробно обязанности бизнеса по 115-ФЗ разобраны в статье «115-ФЗ: что обязан делать бизнес и как выполнить требования закона».
Что требует закон от банка, МФО и маркетплейса
Дальше — какая нормативная база стоит за каждым из трёх сегментов и что из неё следует для требований к поставщику. Сводить три сегмента в один список нельзя: нормы, сроки и даже сама доступность упрощённого порядка у них разные.
Банк
Кредитные организации и поднадзорные Банку России организации вправе идентифицировать физическое лицо и представителя юридического лица без личного присутствия — через ЕСИА и единую биометрическую систему (ЕБС) по 572-ФЗ (115-ФЗ, п. 5.8 ст. 7). Это право обусловлено закрытым перечнем условий (115-ФЗ, п. 5.8 ст. 7, абз. 2–9). Клиент не должен числиться в перечне причастных к экстремизму или терроризму и в перечнях Совета Безопасности ООН, в отношении него не должно быть решения межведомственной комиссии о замораживании средств, а его операции не должны быть приостановлены судом. Дополнительно нужно отсутствие подозрений в легализации доходов и оснований полагать наличие иного бенефициарного владельца, отсутствие в ЕГРЮЛ записи о недостоверности сведений и отсутствие информации о применении мер по пп. 5.2 и 11 той же статьи.
Для части банков то же самое — уже обязанность, не право: банк с универсальной лицензией, соответствующий критериям абз. 2–4 п. 5.7 ст. 7 и предоставляющий через сайт или мобильное приложение возможность открыть счёт или получить кредит в рублях, обязан обеспечить приём на обслуживание в порядке п. 5.8 (115-ФЗ, п. 5.8-1 ст. 7). Банк России вправе установить для отдельной организации ограничения по операциям с клиентами, идентифицированными таким способом (п. 5.10 ст. 7).
Удалённый приём на обслуживание в этом порядке опирается на государственную инфраструктуру — единую биометрическую систему и ЕСИА, и заменить их коммерческим решением нельзя: закон называет их прямо. KYC-провайдер закрывает другую задачу — распознавание и проверку документа, выявление следов редактирования изображения, проверки по внешним базам, проверку витальности и ведение истории проверок клиента. Цена ошибочного отказа здесь — потерянный клиент на дорогом канале привлечения; цена пропуска — операционный и регуляторный риск.
Микрофинансовая организация
У МФО похожая конструкция становится обязательной и жёстко привязанной к государственной инфраструктуре. При дистанционном приёме на обслуживание клиента — физического лица МФО обязаны идентифицировать клиента и его представителя с использованием ЕСИА и ЕБС по ст. 9 № 572-ФЗ (115-ФЗ, п. 5.8-2 ст. 7, абз. 1, введён Федеральным законом от 01.04.2025 № 41-ФЗ). При дистанционном заключении каждого договора потребительского кредита (займа) МФО обязаны дополнительно обеспечить аутентификацию клиента через ЕСИА и ЕБС по ст. 10 № 572-ФЗ — при условии, что идентификация при предшествующем приёме на обслуживание уже проведена по этому же порядку (абз. 2 того же пункта).
Для микрофинансовых компаний эта норма действует уже сейчас — с 1 марта 2026 года (ФЗ № 41-ФЗ, ст. 16 ч. 5). Для микрокредитных компаний (МКК — вид МФО по п. 2.2 ч. 1 ст. 2 ФЗ № 151-ФЗ) применение абз. 1 п. 1.5-2, абз. 2 п. 1.12-1 и п. 5.8-2 ст. 7 115-ФЗ отложено до 1 марта 2027 года (ФЗ № 41-ФЗ, ст. 16 ч. 6). Это две разные даты для двух разных видов МФО, и их легко перепутать при планировании интеграции.
Отдельное ограничение касается именно потребительского кредитования: использование упрощённой идентификации не допускается в целях заключения договора потребительского кредита (займа) микрофинансовой организацией (115-ФЗ, п. 1.12-1 ст. 7, абз. 2; для МКК — тоже с отсрочкой до 1 марта 2027 года). Поручить проведение идентификации или упрощённой идентификации МФО вправе только кредитной организации — для заключения договора займа и для обновления сведений, кроме этого запрещённого случая (п. 1.5-2 ст. 7, абз. 1).
Для дистанционного онбординга МФО коммерческий KYC-провайдер не замещает обязательную процедуру через ЕСИА и ЕБС — это следует непосредственно из нормы, без оценки рынка в целом. Как и у банка, он закрывает другую задачу в этом же процессе: проверку подлинности и читаемости документа, выявление следов редактирования, проверки по базам, сигналы для оценки риска, антифрод-контур. У МФО цена пропуска — прямой кредитный убыток, а стоимость ошибочного отказа считается для конкретного бизнеса — с учётом цикла сделки и стоимости привлечения клиента.
Маркетплейс и цифровая платформа
С 1 октября 2026 года действует Федеральный закон от 31.07.2025 № 289-ФЗ «О платформенной экономике в Российской Федерации» (ст. 23 ч. 1). Обязанность проверки сведений о партнёре закон адресует не любому маркетплейсу: она возникает у оператора посреднической цифровой платформы, включённой в реестр (289-ФЗ, ст. 2 п. 9, ст. 4 ч. 2), и проводится при заключении договора с партнёром или владельцем пункта выдачи (ст. 5 ч. 2).
Способы проверки устанавливает Постановление Правительства РФ от 20.06.2026 № 768, и этот перечень закрытый: государственные реестры и публичный сервис ФНС по статусу плательщика налога на профессиональный доход; ЕСИА либо иная информационная система, отвечающая требованиям законодательства об информации; цифровая платформа МСП; информационные ресурсы страны регистрации иностранного заявителя (ПП № 768, п. 2 Правил, разделы III–VI). Способ выбирает сам оператор, а сроки проверки различаются: по государственным реестрам — до 5 рабочих дней, через ЕСИА или иную информационную систему — один календарный день, через платформу МСП — один календарный день, для иностранного заявителя — до 15 рабочих дней (пп. 13, 23, 28, 32, 39 Правил).
Перечень закрытый, но он описывает способы проверки, не типы поставщиков: класса «коммерческий KYC-сервис» в нём нет просто потому, что Правила такой категорией не оперируют. Внутри способа по разделу IV закон прямо допускает две технические реализации — ЕСИА либо иную информационную систему и (или) программу для ЭВМ, соответствующую требованиям законодательства об информации, информационных технологиях и защите информации (ПП № 768, п. 24 подп. «б»). Условие к ней жёсткое: сведения о заявителе, переданные оператору платформы по итогам идентификации и аутентификации через такую систему, должны быть установлены оператором этой системы по требованиям к идентификации клиентов, предусмотренным законодательством о ПОД/ФТ (п. 26 Правил), а сама идентификация проходит на платформе и с согласия заявителя (п. 25).
Отсюда практический вывод для требований к поставщику: обязанность провести проверку остаётся на операторе платформы, способ он выбирает сам из закрытого перечня, и подключение стороннего сервиса само по себе исполнение этой обязанности не подтверждает. Если поставщик позиционирует себя как реализацию способа по разделу IV, у него стоит запросить, на каком основании он считает условие пункта 26 выполненным — это вопрос к оператору системы, не к платформе.
На маркетплейсе KYC-провайдер может решать и отдельную задачу — проверку физических лиц-пользователей и снижение фрод-риска; этот контур не совпадает с обязанностью проверки партнёра по ст. 5 289-ФЗ. Эти два контура стоит развести в требованиях к поставщику: объединять их в одну задачу не стоит. Подробный разбор 289-ФЗ — в статье «Проверка продавцов на маркетплейсах по 289-ФЗ».
| Сегмент | Кого проверяют | Норма | Что закрывает провайдер |
|---|---|---|---|
| Банк | Физлицо или представитель юрлица при удалённом приёме на обслуживание | 115-ФЗ, п. 5.8, 5.8-1 ст. 7 | Распознавание и проверка документа, антифрод изображения, проверки по базам, витальность — не замена ЕСИА и ЕБС |
| МФО | Физлицо или представитель при дистанционном онбординге и каждом договоре потребительского кредита (займа) | 115-ФЗ, п. 5.8-2 ст. 7 (с 01.03.2026, для МКК — с 01.03.2027) | То же, что у банка, — не заменяет ЕСИА и ЕБС там, где они обязательны |
| Маркетплейс | Партнёр или владелец пункта выдачи при заключении договора | 289-ФЗ, ст. 5 ч. 2; ПП № 768 | Техническая реализация способа по разделу IV — только при условиях пп. 24–26 Правил; обязанность остаётся у оператора. Проверка пользователей-физлиц и фрод-риск — отдельный контур |
Какие требования к провайдеру обязательны, а какие зависят от сценария
Требования к поставщику имеет смысл делить на три уровня: часть нужна почти любому сценарию, часть — только при определённых условиях, и часть зависит от масштаба и зрелости компании. Предъявлять их единым списком не стоит.
Базовые — нужны практически всем
- Какие типы документов и какие страны реально поддержаны именно в сценариях заказчика — общий перечень на сайте поставщика этого не подтверждает.
- Чтение полей и машиночитаемой зоны документа, проверка контрольных сумм.
- Выявление следов подделки и редактирования изображения: распечатка, фотографирование с экрана, ксерокопия, обработка в графическом редакторе, вклейка фрагмента.
- Что именно отдаётся в результате: статус, причина отказа, материалы сессии, структурированные поля.
- Способ получения результата — опрос статуса сессии или вебхук.
- Как настраивается строгость проверки и можно ли задать разные пороги для разных сценариев.
- Где обрабатываются и хранятся данные, что и в какой срок удаляется.
- Журналирование решений: что останется в системе через полгода, когда решение придётся объяснить.
Сценарные — только если сценарий этого требует
- Сличение лица и проверка витальности — с учётом ограничений, которые разбираются в следующем разделе.
- Защита от подмены изображения и видеопотока.
- Проверки по внешним источникам и скрининг по спискам — только если это требуется сценарию, не по умолчанию.
- Ручной разбор спорных случаев: кто его проводит, на чьей стороне, с какими материалами и в какой срок.
- Поддержка иностранных документов и клиентов-нерезидентов.
- Работа с юридическими лицами и их представителями — отдельная задача, не часть проверки физлица.
Дополнительные — зависят от зрелости и масштаба
- On-premise или изолированный контур обработки данных.
- Выделенные мощности и индивидуальные параметры SLA.
- Обнаружение повторных попыток одного и того же человека под разными данными — с учётом тех же ограничений на обработку биометрических персональных данных.
- Готовый виджет, позволяющий запустить проверку без разработки на стороне заказчика.
- Мультиязычный интерфейс.
| Критерий | Что спросить у поставщика | Какое подтверждение запросить | Как проверить на пилоте |
|---|---|---|---|
| Поддерживаемые документы и страны | Какие типы документов и страны реально работают на образцах заказчика | Результат на поданных образцах, не общий список с сайта | Прогнать образцы из своей выборки и зафиксировать расхождения с ожидаемым покрытием |
| Формат результата | Что именно возвращается: статус, причина отказа, структурированные поля, материалы сессии | Пример ответа на реальном кейсе | Проверить на реальных кейсах, хватает ли полей для решения, и зафиксировать пробелы |
| Пороги и настройка строгости | Можно ли задать разные пороги для разных сценариев | Документация по настройке порогов | Задать два порога на одной выборке и зафиксировать, как меняется результат |
| Хранение и удаление данных | Где обрабатываются и хранятся данные, какой срок хранения и что удаляется | Договорные обязательства по хранению и документация по доступным настройкам срока | Проверить, можно ли технически удалить тестовые материалы в своём контуре; если нельзя — зафиксировать это как ограничение |
| Сличение лица (если нужно по сценарию) | Какой режим реализован и кто по схеме отвечает за решение — автоматическое сличение или участие уполномоченного должностного лица | Документированная схема обработки и распределение ролей между поставщиком и заказчиком | Наблюдать, совпадает ли фактическое поведение сценария с описанной схемой — это проверка соответствия поведению, не юридическая экспертиза режима |
| Ручной разбор спорных случаев | Кто разбирает, на чьей стороне, с какими материалами и в какой срок | SLA на ручной разбор в договоре | Замерить фактический срок разбора на пилотных кейсах и сравнить с заявленным в SLA |
| On-premise и инфраструктура (если актуально) | Минимальные и рекомендуемые требования к оборудованию | Техническая спецификация поставщика | Проверка совместимости со своей инфраструктурой — отдельный технический этап, не часть пилота на облачном контуре |
| Условия выхода | Как экспортируются данные и журналы, срок миграции | Пункт договора про прекращение | Уточняется до подписания, не на пилоте |
Что ограничено законом и чего не стоит ждать от поставщика
В информационных системах организаций, индивидуальных предпринимателей и нотариусов запрещена обработка, включая сбор и хранение, биометрических персональных данных, используемых в целях идентификации, — кроме случаев сбора для размещения в единой биометрической системе в соответствии с федеральными законами (ФЗ от 29.12.2022 № 572-ФЗ, ст. 15 ч. 1 п. 1; норма действует с 1 июня 2023 года). Отдельно закон прямо выводит из-под этого ограничения случай, когда сверка предоставленных биометрических персональных данных с данными в информационной системе проводится не автоматизированным способом, а с участием уполномоченного должностного лица (572-ФЗ, ст. 1 ч. 2 п. 2).
Отсюда следует рамка, которую стоит держать в голове при формулировании требований к сценарию сличения лица: закон разводит автоматическое сличение в целях идентификации и ручную сверку с участием должностного лица — это два разных режима с разными требованиями, и вопрос о том, какой режим реализован у конкретного поставщика, стоит задать ему до пилота — выяснять это постфактум уже поздно. Статья описывает именно эту нормативную рамку. Оценку законности работы конкретных продуктов на рынке она не даёт — для этого нужна отдельная правовая экспертиза уже выбранного решения.
Независимо от того, какие функции заявляет поставщик, обязанным лицом перед законом остаётся заказчик. Договор с KYC-провайдером не переносит на него обязанность по 115-ФЗ, не подтверждает соответствие 289-ФЗ для оператора платформы и не заменяет ЕСИА и ЕБС там, где они обязательны по закону. Формулировки вида «провайдер обеспечивает соответствие закону» или «гарантирует отсутствие мошенничества» этому распределению ответственности не соответствуют ни для одного из трёх сегментов.
Как устроить пилот, чтобы он что-то показал
Презентации и демо-стенды годятся для первичного отбора — каждый поставщик показывает свой лучший случай, — но итоговый выбор по ним сделать нельзя. Показательное сравнение получается только при одном условии: все участники пилота тестируются на одной выборке, в одних условиях, по одной методике.
Собрать выборку, похожую на реальный поток: типы и годы выпуска документов, доля изношенных и иностранных, устройства и качество камер, условия съёмки, доля повторных попыток — и отдельно поток, похожий на мошеннический, если такой у заказчика есть.
Разметить эталон заранее: по каждому примеру в выборке должен быть заранее известен правильный ответ, установленный людьми. Без эталона пилот показывает только совпадение двух систем между собой — не качество решения.
Зафиксировать единые условия для всех участников: одно и то же ограничение, по которому выставляется рабочая точка — например, одинаковая доля ложных совпадений или одинаковая доля ручных разборов, — один сценарий шагов и один способ подачи изображений. Одинаковое числовое значение порога единым условием не является: шкалы оценок у разных систем свои, и одно и то же число означает у них разную строгость.
Проверить качество извлечения данных по каждому полю отдельно — фамилия, имя, отчество, дата рождения, серия и номер, дата выдачи, код подразделения, машиночитаемая зона. Сводная метрика «точность распознавания» прячет то, что одно поле читается плохо.
Считать ошибочные отказы и пропуски раздельно: отказ стоит потерянного клиента, пропуск — убытка и регуляторного риска. Сводить их в единый «процент точности» нельзя.
Замерить завершаемость сценария пользователем — долю дошедших до конца, долю бросивших и на каком шаге, — а также долю повторных попыток и долю случаев, ушедших в ручной разбор: это прямые операционные расходы.
Замерить задержки распределением, не средним значением: важна медиана и верхние перцентили при целевой нагрузке.
Проверить устойчивость к атакам, реальным именно для сценария заказчика, и посчитать стоимость завершённой проверки и стоимость принятого клиента — методика в следующем разделе.
Универсальных проходных порогов, пригодных для любого сценария, не существует, и переносить чужую процедуру подбора на свой сценарий не стоит. Порог подбирается под ожидаемые потери: цена ошибочного отказа и цена пропуска умножаются на то, как часто каждая из них случается на реальном потоке, — и граница сдвигается туда, где суммарный ущерб меньше. Если доля пропусков ограничена риск-аппетитом или требованием регулятора, это ограничение задаётся первым, а всё остальное оптимизируется уже внутри него. Подбирать порог и измерять результат по одним и тем же данным нельзя: выборку делят, на одной части порог выставляется, на отложенной считаются итоговые метрики. Для разных операций одного и того же бизнеса пороги по этой же причине обычно различаются — подробно калибровка порога под профиль риска разобрана в статье «Риск-ориентированный KYC», а метрики распознавания лица — в статье «Точность распознавания лица в KYC».
Один из вопросов, которые стоит проверить уже на этом этапе, — как у поставщика устроен тестовый доступ к KYC-платформе для самостоятельного пилота.
У NeuroVision тестовый доступ выдаётся после обращения, обычно с предварительным NDA; параметры нагрузки, лимиты сценариев и условия SLA обсуждаются индивидуально. Это пример того, какой порядок стоит ожидать от поставщика перед пилотом — у других вендоров процедура может отличаться.
Как считать полную стоимость
Для сравнения поставщиков важна стоимость принятого клиента, не цена одной проверки, — и список вопросов здесь обычно длиннее, чем ожидает закупка.
| Статья расходов | Что уточнять у поставщика |
|---|---|
| Интеграция | Объём работ на своей стороне, наличие тестовой среды, нужна ли разработка вообще |
| Тарифицируемые операции | Что считается проверкой: заявка, сессия или уникальный клиент |
| Повторные попытки | Тарифицируются ли повторы и сессии, прерванные пользователем |
| Неуспешные и пропущенные проверки | Тарифицируется ли проверка, которой не хватило данных, и отказ из-за качества фото |
| Внешние запросы | Тарифицируется ли каждая проверка по внешнему источнику отдельно |
| Ручная проверка | На чьей стороне проводится, входит ли в тариф, как считается |
| Минимальные обязательства | Минимальный платёж, минимальный объём, срок договора |
| Поддержка и SLA | Что входит в базовый тариф, что продаётся отдельно |
| Хранение | Срок бесплатного хранения материалов проверки, тариф после него |
| Инфраструктура (для on-premise) | Оборудование, лицензии, эксплуатация, обновления |
| Выход | Экспорт данных и журналов, срок миграции, судьба интеграции, что происходит с материалами проверок |
Ниже — условный пример самого метода расчёта; цифры не являются рыночными тарифами и не относятся к какому-либо конкретному поставщику. Допустим, одна проверка по прайсу стоит 20 ₽, и за месяц пришло 100 заявок. Из них 20 потребовали повторной попытки, а каждая повторная попытка тарифицируется как отдельная проверка — это ещё 20 × 20 ₽ = 400 ₽. Ещё 10 случаев ушли в платный ручной разбор по 100 ₽ за случай — 1000 ₽. Итого за месяц: 100 × 20 ₽ + 400 ₽ + 1000 ₽ = 3400 ₽. Если из 100 заявок успешно прошли проверку 90 клиентов, стоимость одного принятого клиента — около 38 ₽, почти вдвое выше цены единичной проверки по прайсу — именно эту итоговую величину стоит сравнивать между поставщиками, не цену по прайсу саму по себе. Это упрощённый расчёт только операционной части — повторов и ручных разборов; он не включает интеграцию, инфраструктуру, поддержку, хранение и цену ошибочных решений, поэтому 38 ₽ не стоит читать как полную стоимость владения. Развёрнутая модель с этими статьями и ценой ошибок разобрана в статье «Экономика KYC: как считать стоимость одобренного клиента и цену ошибок».
Что спросить про прекращение договора
Вопрос о прекращении договора стоит задавать до подключения, пока он ещё не стал актуальным. Пример того, почему это важно: по сообщению CNews от 15 октября 2026 года, ООО «Кабутек», работавшее под брендом IDnGo (до 2024 года — Cyberity), уведомило клиентов о прекращении деятельности в России; операционная деятельность завершается после 31 декабря 2026 года, юридическое лицо ликвидируется. По публикации, дословно: «Программное обеспечение компании не будет передаваться для дальнейшего коммерческого использования и будет выведено из эксплуатации».
Один случай ухода конкретного поставщика не говорит ничего о рынке KYC в целом: вывод о тенденции из него не следует, зато следует повод задать конкретные вопросы у любого поставщика заранее. Прежде чем подписывать договор, стоит получить ответы на три вопроса: как именно и в какой срок экспортируются данные и журналы решений при прекращении договора; что происходит с материалами уже проведённых проверок; и какой период отводится на миграцию на другое решение без разрыва процесса проверки клиентов.
Требования к KYC-провайдеру нельзя сформулировать одним списком для любого бизнеса: закон по-разному определяет обязанности банка, МФО и маркетплейса, и от этого напрямую зависит, какую часть задачи вообще можно отдать поставщику. Идентификация клиента остаётся обязанностью самой организации; провайдер поставляет инструмент и работает в границах, которые задаёт закон, — включая случаи, где ЕСИА и ЕБС обязательны и ничего коммерческого их не заменяет.
Осмысленное сравнение поставщиков строится на пилоте на одной выборке по единой методике, где ошибочные отказы и пропуски считаются раздельно, без сведения в один «процент точности»: презентации вендоров такого сравнения не дают. Полная стоимость решения складывается из тарификации повторов, ручных разборов, хранения данных и условий выхода из договора — и этот последний пункт стоит прояснить до подписания, пока он ещё не стал насущным.
FAQ
