Групповая проверка ИНН для банков: как новый механизм упростит массовую идентификацию клиентов

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

Как банки проверяют ИНН сейчас

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

В линейке Системы "iDБанк" для этих задач предусмотрены два модуля:

• "ФНС. ИНН по документу, удостоверяющему личность" — позволяет получить ИНН физического лица по ФИО, дате и месту рождения, а также сведениям о документе, удостоверяющем личность, если клиент не знает или не сообщил свой ИНН.
• "ФНС. ИНН" — позволяет проверить соответствие ИНН паспортным данным физического лица, если номер предоставлен самим клиентом.

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

Какие изменения предлагает законопроект

30 марта 2026 года Правительство РФ внесло в Государственную Думу законопроект «О внесении изменений в часть первую Налогового кодекса Российской Федерации».

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

Одновременно предлагается дополнить статью 132 НК РФ ответственностью за передачу в налоговый орган сведений, не соответствующих данным, имеющимся в распоряжении банка или оператора платформы цифрового рубля. В перечень таких сведений входят, в частности, ФИО, дата рождения, реквизиты документа, удостоверяющего личность, номер счета и ИНН. Размер предлагаемого штрафа — 40 тысяч рублей.

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

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

Почему единичной проверки может быть недостаточно

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

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

Поэтому возникает потребность в групповом запросе ИНН — получении сведений сразу по нескольким физическим лицам в рамках одного обращения через соответствующий вид сведений СМЭВ.

Как работает групповой запрос ИНН

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

Для банка это позволит:

• массово получать ИНН физических лиц по паспортным данным;
• проверять клиентские массивы до передачи сведений в ФНС;
• заранее выявлять отсутствующие или не соответствующие паспортным данным ИНН;
• снижать риск направления некорректных сведений и последующих уточнений;
• сокращать количество отдельных запросов и связанные с ними операционные издержки;
• автоматизировать обработку результатов и получать юридически значимые сведения об ИНН.

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

Зачем групповая проверка нужна в процессах при передаче сведений в ФНС об открытии, закрытии, изменении счетов

Один из наиболее очевидных сценариев применения групповой проверки — процессы, связанные с формированием и передачей в ФНС сведений об открытии, закрытии и изменении реквизитов банковских счетов.

В линейке iDSystems эти процессы реализуются двумя взаимосвязанными, но разными по назначению компонентами:

• "ФНС, СФР. Сообщения об открытии, закрытии, изменении счета" — мастер-система, которая обеспечивает головной бизнес-процесс: формирование, обработку, контроль и подготовку сведений.
• "ФНС, СФР. Транспорт СМЭВ для сообщений об открытии, закрытии, изменении счета" — транспортный модуль, который обеспечивает обмен архивными файлами с ФНС и СФР через соответствующие виды сведений СМЭВ, загрузку и выгрузку сообщений, а также их подписание УКЭП.

Модуль групповой проверки ИНН может использоваться как отдельный предварительный контур контроля данных перед формированием сообщений. Мастер-система получает результаты сверки, выявляет записи, требующие уточнения, и только после этого формирует сведения для передачи. Транспортный модуль, в свою очередь, обеспечивает их отправку через СМЭВ.

Таким образом, групповая проверка дополняет решение, но не подменяет ни мастер-систему, ни транспортный модуль. Ее задача — повысить качество исходных клиентских данных и сократить число ошибок, возвратов и повторных отправок.

Какие требования уже действуют для обмена с ФНС и СФР

С 1 января 2026 года банки перешли на взаимодействие с ФНС и СФР через СМЭВ по ряду процессов, ранее выполнявшихся с использованием инфраструктуры Банка России.

В частности, через СМЭВ направляются сообщения в ФНС об открытии или закрытии счета, вклада или депозита, об изменении их реквизитов, а также сообщения о предоставлении или прекращении права использовать электронные средства платежа и об изменении их реквизитов. В СФР направляются сведения об открытии или закрытии счета и изменении его реквизитов в электронной форме.

При этом Указание Банка России № 6951-У регулирует отдельный процесс — сообщения в ФНС о предоставлении или прекращении права использовать электронные средства платежа и об изменении их реквизитов. Его некорректно обозначать как документ, заменивший одновременно Положения № 311-П и № 562-П: для сообщений об открытии и закрытии счетов и для взаимодействия с СФР применяются отдельные нормативные основания и форматы.

Как механизм связан с платформой "Антидроп"

Дополнительный драйвер массовой проверки ИНН — развитие платформы "Антидроп" Банка России. Регулятор рассматривает ИНН как ключевой идентификатор для сопоставления платежных данных с клиентами кредитных организаций и указывает, что банки должны будут обеспечить наличие этого реквизита по всем счетам, включая ранее открытые.

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

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

Какие решения развивает iDSystems

Сейчас iDSystems предлагает модули:

• ФНС. ИНН по ДУЛ – обеспечивает возможность получения ИНН физического лица по его паспортным данным: ФИО, дате и месту рождения, сведений о документе, удостоверяющем личность.
• ФНС.ИНН – обеспечивает проверку соответствия ИНН и паспортных данных физического лица.

В настоящее время компания планирует реализовать новый модуль Системы "iDБанк" для получения ИНН физических лиц по полным паспортным данным в рамках группового запроса через СМЭВ3.

Новое решение предполагается использовать для:

массовой проверки действующей клиентской базы;
подготовки сведений к передаче в ФНС;
предварительной валидации данных;
подготовки банков к использованию ИНН как ключевого идентификатора в рамках платформы "Антидроп";
сокращения ручных операций и затрат на последовательную обработку единичных запросов.

Функциональность и сроки промышленного запуска будут зависеть в том числе от реализации и параметров соответствующего группового вида сведений в СМЭВ. О выпуске решения iDSystems сообщит отдельно.

Вывод

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

Групповой запрос позволит встроить такую проверку в регулярные банковские процессы, дополнить предварительной валидацией клиентских данных и упростить подготовку к новым требованиям ФНС и развитию платформы "Антидроп".

В случае заинтересованности в реализации групповых запросов ИНН просим обращаться: post@id-sys.ru