Смена KYC-провайдера: чек-лист миграции

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

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

Кратко:

• Что проверить в первую очередь: роль нового подрядчика, поручение обработки по ч. 3 ст. 6 Закона № 152-ФЗ и место нахождения его баз данных (ч. 5 ст. 18).

• Когда нужны новые согласия: если действующее согласие не охватывает нового обработчика, цели или данные; для биометрии нужно письменное согласие (ст. 11 Закона № 152-ФЗ).

• Что делать с архивом: передавать новому провайдеру только необходимое (ст. 5 Закона № 152-ФЗ); организации, на которые распространяется 115-ФЗ, хранят документы и сведения, необходимые для идентификации, не менее пяти лет со дня прекращения отношений с клиентом.

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

• Когда отключать старый сервис: после приёмки интеграции и архива и закрытия открытых заявок; затем уничтожение данных и акт по приказу Роскомнадзора № 179.

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

В миграции участвуют продуктовая и ИТ-команда, специалисты по информационной безопасности, юристы и комплаенс-офицеры. Технические рекомендации адаптируют к архитектуре сервиса. Правовые требования применяют с учётом роли компании и конкретного сценария обработки данных.

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

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

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

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

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

• Как устроены статусы, причины отказов и обработка технических ошибок.

• Какие данные и подтверждения можно получить по каждой заявке.

• Каковы условия поддержки, ограничения нагрузки и порядок уведомления об изменениях.

• Есть ли у провайдера аккредитация по статье 17 Закона № 572-ФЗ, если он проводит биометрическую аутентификацию собственной системой.

• Где физически расположены базы данных провайдера и привлекает ли он иностранных подрядчиков.

• Как выгрузить историю и прекратить обработку данных при последующей смене поставщика.

Условия выхода согласуйте уже при подключении: порядок выгрузки и прекращения обработки понадобится при следующей миграции.

Компания-оператор до первой передачи данных проверяет, что базы данных подрядчика находятся в России, а если провайдер обрабатывает данные по поручению, оформляет поручение по ч. 3 ст. 6 Закона № 152-ФЗ. Там, где нужно согласие субъекта, оно должно охватывать нового обработчика. Сведения в уведомлении Роскомнадзора приводят в соответствие с новой схемой. Для биометрических данных дополнительно выполняют требования ст. 11 Закона № 152-ФЗ.

От правовой роли нового подрядчика зависит набор документов. Если он обрабатывает персональные данные по поручению вашей компании, применяются требования части 3 статьи 6 Закона № 152-ФЗ. По общему правилу такое поручение требует согласия субъекта, если федеральный закон не предусматривает иное; сам обработчик не обязан получать согласие субъекта (ч. 4 ст. 6). Перед субъектом за действия обработчика отвечает оператор, а обработчик отвечает перед оператором. Если обработка поручена иностранному лицу, перед субъектом отвечают и оператор, и это лицо (ч. 6 ст. 6).

Прямого ответа на вопрос, нужно ли согласие на поручение, когда сама обработка ведётся без согласия (например, во исполнение 115-ФЗ или договора с клиентом), в законе нет. Позицию по этому вопросу согласуйте с юристом заранее и зафиксируйте во внутренних документах. Если компания получает согласие, сведения о поручении и обработчике включают в сам текст согласия. Само согласие оформляют отдельно от оферты и других документов (ч. 1 и 4 ст. 9 Закона № 152-ФЗ).

Для организаций, на которые распространяется 115-ФЗ, технический провайдер выступает инструментом проверки, и идентификацию ему не поручают. Статья 7 Закона № 115-ФЗ допускает поручение идентификации только ограниченному кругу лиц, поэтому обязанность и ответственность остаются у самой организации.

В поручении необходимо определить перечень персональных данных, действия с ними и цели обработки, обязанность соблюдать конфиденциальность и обеспечивать безопасность данных, требования ч. 5 ст. 18 (локализация) и ст. 18.1 Закона № 152-ФЗ. Там же закрепляют обязанность по запросу оператора предоставлять подтверждающие документы, в том числе до начала обработки, и уведомлять оператора о неправомерной передаче данных. Для миграции дополнительно согласуйте формат экспорта, сроки передачи и уничтожения данных, работу с резервными копиями и порядок привлечения других подрядчиков.

С 1 июля 2025 года при сборе персональных данных граждан РФ запрещено записывать, систематизировать, накапливать, хранить, уточнять и извлекать их с использованием баз данных за пределами России (ч. 5 ст. 18 Закона № 152-ФЗ в редакции Закона № 23-ФЗ). Исключения узкие и перечислены в самой норме. Если провайдер или его облачный подрядчик использует зарубежную инфраструктуру для первичного сбора, такая схема не подходит. Если данные уже собраны в России, дальнейшая передача за рубеж оценивается по правилам статьи 12.

Согласие, которое разрешает поручение обработки только прежнему поставщику, на нового автоматически не распространяется. Когда закон требует письменного согласия, статья 9 Закона № 152-ФЗ предусматривает указание наименования (или фамилии, имени, отчества) и адреса лица, которое обрабатывает данные по поручению оператора. Изменение текста политики не заменяет получение необходимого согласия.

Перед передачей данных новому провайдеру проверьте документы и интерфейсы:

• Политику обработки персональных данных: соответствует ли она фактической схеме работы.

• Согласия: охватывают ли они нового обработчика, необходимые данные, цели и действия с данными.

• Пользовательские документы и интерфейсы: не остались ли ссылки на прежнего поставщика.

• Внутренние регламенты: кто получает результаты, принимает решения и рассматривает обращения.

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

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

Смена подрядчика сама по себе не обязывает менять уведомление Роскомнадзора. Обновление требуется, если изменились сведения, перечисленные в части 3 статьи 22 Закона № 152-ФЗ, например место нахождения базы данных или наличие трансграничной передачи. Если новый провайдер хранит данные на своей инфраструктуре, место нахождения базы обычно меняется. Часть 3.1 детализирует сведения по части 3 для каждой цели обработки, поэтому об изменении категорий данных, правового основания или действий с данными сообщают в тот же срок: не позднее 15-го числа месяца, следующего за месяцем изменений. Освобождение от уведомления для обработки без средств автоматизации к онлайн-проверке не применяется.

Если новая схема предполагает трансграничную передачу, оцените её отдельно. Статья 12 требует уведомить Роскомнадзор до начала передачи, а перед подачей уведомления получить сведения от иностранного получателя. В страны, не обеспечивающие адекватную защиту прав субъектов, передавать данные до окончания рассмотрения уведомления нельзя. Уведомление не заменяет остальные условия законной обработки, включая локализацию при сборе.

При использовании биометрических персональных данных для установления личности по общему правилу нужно письменное согласие и соблюдение специальных требований статьи 11 Закона № 152-ФЗ. Те же требования распространяются на сравнение фотографии в документе с селфи, если снимок применяется для установления личности. Относится ли конкретная схема такого сравнения к идентификации или аутентификации по Закону № 572-ФЗ, зависит от того, как устроена проверка у провайдера: позицию по схеме нового провайдера согласуйте с юристом до подключения. Для биометрической аутентификации в собственной системе провайдер обязан иметь аккредитацию по статье 17 Закона № 572-ФЗ, тогда как первичная идентификация по биометрии проводится только с использованием ЕБС.

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

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

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

• Внутренний идентификатор клиента и идентификаторы заявок у прежнего поставщика.

• Дату, время и состав выполненных проверок.

• Результаты отдельных проверок, причины отказа или направления на ручное рассмотрение.

• Итоговое решение компании и сведения о сотруднике, если он участвовал в рассмотрении.

• Доступные версии правил и порогов, по которым принималось решение.

• Подтверждения согласий либо сведения об ином основании обработки.

• Исходные материалы в том объёме, для хранения которого есть необходимость и законное основание.

Хранить все перечисленные сведения каждый сервис не обязан: состав архива зависит от задач компании и применимых требований.

При переносе не перезаписывайте старое решение результатом новой проверки. Например, если автоматическая система отклонила заявку, а сотрудник затем одобрил её после рассмотрения документов, сохраните оба события и основание пересмотра. По одному итоговому статусу последовательность действий не восстановить.

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

1. Сверьте количество записей и обязательные поля.

2. Проверьте читаемость файлов и соответствие идентификаторов.

3. Найдите дубли и записи без связи с клиентом или заявкой.

4. Отдельно проверьте незавершённые заявки.

5. Повторно выгрузите изменения, появившиеся после первого экспорта.

Универсального срока хранения для любого KYC-архива нет. Например, пункт 4 статьи 7 Закона № 115-ФЗ предусматривает хранение документов и сведений, необходимых для идентификации, не менее пяти лет со дня прекращения отношений с клиентом. Правило применяют только к организациям и сведениям, на которые распространяется эта норма.

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

Подтверждение уничтожения в случаях, предусмотренных статьёй 21 Закона № 152-ФЗ, оформляют по приказу Роскомнадзора № 179. Подтверждает уничтожение оператор; если данные обрабатывал провайдер по поручению, он указывается в акте. При автоматизированной обработке предусмотрены акт и выгрузка из журнала регистрации событий; подтверждающие документы хранят три года с момента уничтожения. Письмо «данные удалены» не заменяет акт и выгрузку из журнала.

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

Для параллельного тестирования подходит теневой режим: рабочие решения по-прежнему принимаются на основе ответов действующего провайдера, а новый обрабатывает согласованную выборку для сравнения. Его ответы пока не влияют на доступ клиента к сервису. Так интеграцию проверяют до полного переключения.

Передавая те же данные второму поставщику, компания начинает отдельную обработку. Проверьте, совместима ли она с целями сбора (ч. 2 ст. 5 Закона № 152-ФЗ), и ограничьте выборку минимально необходимым объёмом. Для фотографий и селфи, которые используются для установления личности, учитывайте требования к биометрическим персональным данным.

До начала испытаний определите критерии приёмки:

Пороговые значения установите с учётом текущих показателей и допустимого риска. Они должны быть известны до запуска, чтобы решение о расширении потока не зависело от субъективного впечатления команды.

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

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

Тестовые запросы на реальных данных тоже относятся к обработке персональных данных. Правовое основание и поручение должны охватывать такую обработку до начала прогона.

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

• Назначьте систему, которая завершает заявки, открытые до перехода.

• Определите порядок обработки повторных и запоздавших ответов.

• Установите условия остановки расширения потока и назначьте ответственного.

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

• Подготовьте сценарий на случай сбоя после окончательного отключения старого сервиса.

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

После полного перехода примите финальную выгрузку, сверьте незавершённые заявки и закройте неиспользуемые доступы. Отзовите старые API-ключи и отключите прежние маршруты запросов. Затем направьте прежнему провайдеру требование об уничтожении данных и оформите подтверждение по приказу Роскомнадзора № 179.

Автоматизируйте проверку клиентов

50+ проверок физических лиц и верификация данных в один клик. Легкая интеграция в ваши текущие бизнес-процессы.

Имя^*

E-mail^*

Телефон^*

Отправить

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

Что считается сменой KYC-провайдера с точки зрения Закона № 152-ФЗ?

Это замена поставщика, который проверяет клиентов в интересах компании и получает их персональные данные. Если провайдер работает по поручению, оператором остаётся компания: она определяет цели и состав обработки, а провайдер получает доступ к данным на основании поручения по ч. 3 ст. 6 Закона № 152-ФЗ. Поэтому миграция включает пересмотр поручения, согласий, уведомления Роскомнадзора, размещения баз данных и порядка уничтожения данных у прежнего поставщика.

Нужно ли заново проверять всех клиентов при смене KYC-провайдера?

Нет, сама смена подрядчика не создаёт обязанности повторно проверять всю базу. Для организаций, на которые распространяется Закон № 115-ФЗ, ориентиром остаётся ст. 7: сведения о клиентах обновляют не реже раза в год, а по клиентам низкой степени риска не реже раза в три года. Повторную проверку назначают клиентам с неполным досье, наступившим сроком обновления или неполной историей решений.

Нужно ли получать новые согласия на обработку персональных данных при смене KYC-провайдера?

Не всегда. Проверьте, охватывает ли действующее основание обработку данных новым подрядчиком. По части 3 статьи 6 Закона № 152-ФЗ поручение обработки по общему правилу требует согласия субъекта, если федеральный закон не предусматривает иное. Когда нужно письменное согласие, статья 9 предусматривает указание наименования и адреса лица, обрабатывающего данные по поручению оператора. Если в согласии назван только прежний поставщик, распространить его на нового автоматически нельзя; правка политики согласие не заменяет. Для биометрии, как правило, нужно письменное согласие по статье 11.

Чем поручение обработки отличается от передачи данных другому оператору?

При поручении провайдер обрабатывает данные только в целях и объёме, которые определил оператор. Перед субъектом за действия провайдера отвечает оператор (ч. 3 и 5 ст. 6 Закона № 152-ФЗ). Если провайдер сам определяет цели (например, обучает собственные модели или пополняет свои базы), в этой части он становится самостоятельным оператором, и для передачи ему данных нужно отдельное правовое основание. Границу ролей фиксируют в договоре до подключения.

Сколько хранить историю KYC-проверок после смены провайдера?

Универсального срока для любого KYC-архива нет. Для организаций, на которые распространяется Закон № 115-ФЗ, пункт 4 статьи 7 предусматривает хранение документов и сведений, необходимых для идентификации, не менее пяти лет со дня прекращения отношений с клиентом. Смена провайдера на этот срок не влияет, поэтому архив должен оставаться доступным оператору после отключения прежнего сервиса. Для остальных сервисов срок определяют цели обработки, федеральный закон или договор с субъектом по части 7 статьи 5 Закона № 152-ФЗ.

Нужно ли менять уведомление в Роскомнадзор при смене KYC-провайдера?

Не всегда: выбор другого подрядчика сам по себе не обязывает менять уведомление. Обновление нужно, если изменились сведения из ч. 3 ст. 22 Закона № 152-ФЗ, например место нахождения базы данных или наличие трансграничной передачи; при хранении данных на инфраструктуре нового провайдера это обычно так. Изменения подают не позднее 15-го числа месяца, следующего за месяцем изменений. Трансграничная передача требует отдельного уведомления по ст. 12 до её начала.

Какие штрафы грозят за ошибки при смене KYC-провайдера?

Основные штрафы для юридических лиц установлены ст. 13.11 КоАП. За обработку без письменного согласия там, где оно обязательно, или с нарушением требований к его содержанию штраф составит от 300 до 700 тысяч рублей (ч. 2). За нарушение локализации при сборе данных граждан РФ предусмотрен штраф от 1 до 6 миллионов рублей (ч. 8), за повторное нарушение от 6 до 18 миллионов (ч. 9). За нарушения Закона № 115-ФЗ отвечает сама организация: привлечение технического поставщика ответственность на него не переносит.

Как подтвердить уничтожение данных у прежнего KYC-провайдера?

Письма «данные удалены» недостаточно. Требования к подтверждению уничтожения персональных данных установлены приказом Роскомнадзора № 179: при автоматизированной обработке оформляют акт об уничтожении и выгрузку из журнала регистрации событий. Подтверждение оформляет оператор, а прежний провайдер указывается в акте как лицо, обрабатывавшее данные по поручению. Документы хранят три года с момента уничтожения. В договоре заранее перечислите рабочие базы, временные выгрузки, файлы и резервные копии. Если подрядчик сохраняет часть сведений на собственном законном основании, запросите описание их состава и срок хранения.

Когда можно отключать прежнего KYC-провайдера?

После приёмки новой интеграции и архива, с учётом договорных сроков и обязанностей по обработке данных. До отключения назначьте систему, которая завершает заявки, открытые до перехода, получите финальную выгрузку изменений и подготовьте аварийный сценарий без старого сервиса: очередь отложенных проверок, ручное рассмотрение там, где оно разрешено, или приостановку операции. Затем отзовите API-ключи, закройте доступы, направьте требование об уничтожении данных и оформите подтверждение по приказу Роскомнадзора № 179.

Сколько времени занимает миграция KYC?

Срок определяют после обследования интеграции и пробной выгрузки архива; по времени подключения API его не оценивают. В план включают согласование поручения и согласий по Закону № 152-ФЗ, проверку локализации и уведомления Роскомнадзора, сопоставление полей и статусов, пробный экспорт с повторной выгрузкой изменений, параллельный прогон, разбор расхождений и поэтапное переключение потока. Отдельно учитывают договорный срок, в течение которого прежний поставщик завершает открытые заявки и сохраняет доступ к архиву: от него зависит дата окончательного отключения.

Реклама: ООО «Системы управления идентификацией», ИНН 7709982222, erid: 2W5zFH7iq7X