Повторная проверка данных исполнителя (реверификация) — это подтверждение достоверности сведений после первичного онбординга. В России обязанность обеспечивать актуальность персональных данных установлена ч. 6 ст. 5 Федерального закона от 27.07.2006 № 152-ФЗ «О персональных данных»; процедура применяется на маркетплейсах, в такси и доставке, на биржах фриланса — везде, где смена паспорта, ФИО или статуса самозанятого имеют значение.
Кратко:
- Проверку запускает изменение паспорта, ФИО, контактного идентификатора или статуса плательщика НПД.
- Автоматический запуск работает по событию, ручной — при жалобе, инциденте или внешнем сигнале риска.
- Подтверждённо неточные данные оператор уточняет в течение семи рабочих дней (ч. 3 ст. 20 152-ФЗ).
- Неправомерная обработка прекращается в течение трёх рабочих дней (ч. 3 ст. 21 152-ФЗ).
- Решение о блокировке нельзя принимать исключительно автоматизированной обработкой без основания из ст. 16 152-ФЗ.
- Результаты автоматических и ручных проверок хранятся в едином журнале как доказательная база.
Способ технической реализации закон не устанавливает: оператор выбирает его сам. Цифровая платформа обычно исполняет эту обязанность событийной моделью: изменение ключевого реквизита исполнителя (паспорт, ФИО, идентификатор связи, статус плательщика НПД) запускает повторную проверку по API без участия сотрудника. Жалобы, инциденты и внешние сигналы риска, напротив, требуют ручного вмешательства — в этих случаях проверку инициирует администратор.
Что 152-ФЗ требует от оператора и какие сроки установлены
Обязанность поддерживать актуальность персональных данных действует непрерывно, и в момент онбординга исполнителя не прекращается. Сведения проверяются при онбординге и поддерживаются в актуальном состоянии на протяжении всего срока обработки.
Принцип актуальности из ч. 6 ст. 5 152-ФЗ действует непрерывно, без привязки к отдельным датам. Закон также содержит ещё четыре требования с разными точками отсчёта:
- Уточнение по обращению субъекта. Часть 3 ст. 20 152-ФЗ даёт субъекту персональных данных право требовать уточнения сведений. Если гражданин представил доказательства неполноты, неточности или неактуальности данных, оператор вносит изменения в срок, не превышающий семи рабочих дней со дня представления таких сведений. Срок продлевается не более чем на пять рабочих дней при мотивированном уведомлении.
- Блокирование на период проверки. Часть 1 ст. 21 152-ФЗ обязывает заблокировать персональные данные с момента обращения субъекта или получения запроса Роскомнадзора. Блокированию подлежат спорные сведения; профиль исполнителя целиком закон блокировать не обязывает.
- Уточнение и снятие блокирования. Часть 2 ст. 21 отводит на подтверждённое уточнение те же семь рабочих дней и требует снять блокирование по итогам исправления.
- Прекращение неправомерной обработки. Часть 3 ст. 21 применяется, когда оператор сам выявил обработку без законного основания: нарушение устраняется в срок до трёх рабочих дней, а при невозможности обеспечить правомерность данные уничтожаются в срок до десяти рабочих дней с даты выявления.
На каком основании можно повторно проверять данные исполнителя
Повторная проверка опирается на то же основание обработки, что и первичная. Когда основанием служит согласие субъекта, оператор выполняет требования ст. 9 152-ФЗ. Часть 4 ст. 9 перечисляет обязательные сведения согласия: цель обработки, перечень персональных данных, перечень действий и способы обработки, срок действия и порядок отзыва.
Требование к форме согласия внёс Федеральный закон от 24.06.2025 № 156-ФЗ: с 1 сентября 2025 года ч. 1 ст. 9 152-ФЗ требует оформлять согласие отдельно от иных информации и документов, которые подтверждает или подписывает субъект. Правило применяется к согласиям, полученным начиная с этой даты; ранее оформленные согласия силу сохраняют и переподписания не требуют.
Если повторная проверка нужна для исполнения договора с исполнителем, оператор опирается на п. 5 ч. 1 ст. 6 152-ФЗ и фиксирует такое основание во внутренних документах, согласие субъекта в этом случае не требуется.
Второе ограничение вводит ст. 16 152-ФЗ: решения, порождающие юридические последствия и принятые исключительно на основании автоматизированной обработки, допустимы только с письменного согласия субъекта или в случаях, прямо предусмотренных федеральным законом. Отрицательный результат проверки, ведущий к блокировке аккаунта или расторжению договора, проходит контроль сотрудника; порядок обжалования сообщается исполнителю заранее. Возражение оператор рассматривает в течение тридцати дней (ч. 3, 4 ст. 16 152-ФЗ).
Что добавляет 289-ФЗ с 1 октября 2026 года
С 1 октября 2026 года требования к проверке партнёров платформы установит Федеральный закон от 31.07.2025 № 289-ФЗ «Об отдельных вопросах регулирования платформенной экономики в Российской Федерации». Статья 5 закона регулирует проверку перед заключением договора; порядок первичной проверки разобран в материале о проверке партнёров по 289-ФЗ. Актуализация сведений после онбординга обосновывается прежде всего нормами 152-ФЗ.
Какие поля запускают повторную проверку
Повторной проверки требует ограниченный набор реквизитов, от которых зависит юридическая и фактическая достоверность профиля. Ограничение набора полей снижает стоимость обращений к государственным реестрам и защищает оператора от избыточной обработки, которую запрещает ч. 5 ст. 5 152-ФЗ.
- Реквизиты документа, удостоверяющего личность: серия, номер и дата выдачи нового паспорта гражданина РФ либо документа иностранного гражданина.
- Фамилия, имя, отчество при изменении в связи с заключением брака, переменой имени или по решению суда.
- Номер телефона или адрес электронной почты, если они использовались идентификатором при первичной проверке.
- Истечение срока действия документа, предъявленного при онбординге.
- Утрата статуса плательщика НПД по нормам Федерального закона от 27.11.2018 № 422-ФЗ, прекращение деятельности в качестве индивидуального предпринимателя или исключение из ЕГРИП.
Статус плательщика НПД и статус индивидуального предпринимателя относятся к сведениям из открытых государственных реестров. Персональными данными в этом наборе являются ФИО, реквизиты документа и контактные идентификаторы; статус проверяется по ИНН как связанный с профилем факт.
Остальные изменения профиля (аватар, настройки уведомлений, адрес доставки) юридического риска не создают и обращения к реестрам не требуют.
Как работает событийная модель повторной проверки
Событийная модель обращается к государственным реестрам только при изменении ключевого поля, а календарный пересмотр базы отправляет запросы по всем профилям подряд. Цикл состоит из четырёх шагов:
- Детектирование события. Система фиксирует изменение значения ключевого поля: прямое обновление данных исполнителем в личном кабинете либо системное событие по календарю (наступление даты истечения срока действия документа).
- Маршрутизация триггера. Изменённое поле сопоставляется с картой ключевых полей. Совпадение запускает следующий шаг, остальные события записываются в журнал без обращения к реестрам.
- Блокирование спорного реквизита и вызов API. Непроверенный реквизит выводится из расчётных операций, после чего система направляет запрос по нужному каналу: проверка паспорта по сервису МВД России, проверка статуса плательщика НПД в сервисе ФНС, проверка индивидуального предпринимателя по ЕГРИП.
- Регистрация результата и принятие решения. Ответ реестра записывается в журнал с датой, составом запроса и источником ответа. Совпадение снимает блокирование и обновляет профиль. Расхождение переводит кейс на комплаенс-специалиста, который запрашивает подтверждающие документы у исполнителя.
Когда повторную проверку нужно запускать вручную
Автоматика срабатывает только на изменение поля в профиле исполнителя. Жалоба другого пользователя, уведомление контрагента, запрос правоохранительных органов, резкая смена платёжных реквизитов накануне вывода крупной суммы в профиле никак не отражаются, поэтому событие для триггера не возникает. Такие сигналы требуют отдельной процедуры: администратор платформы или комплаенс-специалист запускает повторную проверку вручную и указывает причину.
Ручной запуск сокращает время между обнаружением риска и фактической перепроверкой сведений. При подозрении на захват аккаунта ждать изменения поля бессмысленно: злоумышленник меняет платёжные реквизиты, а паспортные данные оставляет прежними. Результат ручной проверки записывается в общий журнал вместе с ответами государственных реестров.
Сроки и внутренний SLA: как встроить нормы в регламент
Внутренний регламент повторной проверки должен закладывать запас к каждому нормативному сроку отдельно, поскольку точки отсчёта у них разные.
|
Основание и норма 152-ФЗ |
Действие оператора |
Нормативный срок |
Внутренний SLA |
|---|---|---|---|
|
Обращение субъекта или запрос Роскомнадзора, ч. 1 ст. 21 |
Блокирование спорных персональных данных |
С момента получения обращения |
Автоматически, в день обращения |
|
Заявление об уточнении, ч. 3 ст. 20 и ч. 2 ст. 21 |
Проверка документов, обновление профиля, снятие блокирования |
До 7 рабочих дней (продление до 5 рабочих дней) |
До 3 рабочих дней |
|
Выявленная неправомерная обработка, ч. 3 ст. 21 |
Прекращение обработки без законного основания |
До 3 рабочих дней |
В день выявления |
|
Невозможность обеспечить правомерность, ч. 3 ст. 21 |
Уничтожение данных с составлением акта |
До 10 рабочих дней |
До 5 рабочих дней |
|
Технический цикл триггера, ч. 6 ст. 5 |
Обработка события и получение ответа реестра |
Нормативно не установлен |
1–2 рабочих дня |
Каждый нормативный срок отсчитывается от своего события, поэтому оператор закладывает отдельный запас по каждому основанию. Регламент с единым сроком реагирования формально выглядит строже, но при одновременном наступлении двух событий возникает риск их смешения и ошибки пропуска более короткого срока.
Объедините автоматическую и ручную повторную проверку исполнителей в одном процессе.
