Единая система учёта банковских карт: что нужно перестроить в IT-процессах банка и финтеха

Как подготовить выпуск, перевыпуск и закрытие карт к обязательному обмену данными с НСПК

Федеральный закон предусматривает передачу банками сведений о выпуске и прекращении использования платёжных карт в срок, который установит Банк России, но не позднее 1 сентября 2027 года; такой порядок может начать действовать не раньше 1 сентября 2026 года [9]. С 1 сентября 2027 года заработает лимит — не более 20 действующих карт на человека, и перед каждым новым выпуском банк обязан проверять его через систему [9]. Для IT-подразделения банка и подрядчиков-финтех-компаний это означает не разовую доработку отчётности, а перестройку части процессов жизненного цикла карты: событийную модель выпуска/закрытия, контроль качества данных о держателе, дедупликацию клиентов и обработку сбоев при обмене с внешней системой.

Почему это не просто «ещё одна отчётность в ЦБ»

Раньше банк отвечал только за собственный карточный портфель: у него были данные о собственных клиентах и картах, а о том, сколько карт человек оформил в других банках, он не знал [6]. Новая система как раз и рассчитана на то, чтобы отслеживать количество карт, оформленных на одного человека сразу в разных банках [5]. Новая система собирает эти данные в одном месте, и её прямая цель — противодействие дропперским схемам, а не налоговый контроль за переводами между гражданами [3][6].

Для банка это означает новую обязанность: каждое событие в жизненном цикле карты — выпуск, замена номера, закрытие — должно вовремя и корректно попасть во внешнюю систему. Ошибка здесь — это не разовая жалоба клиента, а потенциальное искажение данных в федеральном реестре, на основании которого с 2027 года будут блокировать выдачу новых карт [9].

Что такое единая система учёта простыми словами

Правовая основа системы — Федеральный закон от 26.06.2026 № 210-ФЗ, который внёс изменения в Федеральный закон «О национальной платёжной системе» и в Федеральный закон «О банках и банковской деятельности» [9][11]. Закон дополнил статью 26 закона «О банках и банковской деятельности» новыми частями, обязывающими кредитные организации предоставлять в единую систему учёта платёжных карт сведения о номерах выданных клиентам-физлицам карт, о номерах карт, использование которых прекращено, и о видах этих карт [8]. Этим же законом введён и ряд других антифрод-мер — в частности, ограничение максимального количества банковских карт на человека и сервис «красной кнопки» на портале «Госуслуги» для приостановки дистанционных операций, — но именно единая система учёта карт становится инфраструктурной основой для контроля лимита [10].

Оператором системы стал НСПК — Национальная система платёжных карт [2][11]. Пользователями системы закон называет Банк России и операторов по переводу денежных средств [6]. В реестр попадают:

• номера и виды платёжных карт, с использованием которых можно переводить деньги;
• ИНН клиентов — физических лиц, которым эти карты предоставлены;
• сведения о количестве карт, оформленных на одного человека во всех банках [7].

Важное уточнение: система фиксирует факт выпуска карты, её тип и держателя, но не историю конкретных платежей и переводов — это остаётся зоной ответственности других механизмов банковского мониторинга [3]. В реестр включаются в том числе ранее выпущенные карты Visa и Mastercard и карты с истёкшим сроком действия, если банк продолжает их обслуживать [4].

Как устроен процесс передачи данных

Какие события формируют передачу данных

Проект указания Банка России описывает конкретные триггеры для передачи сведений в систему, и здесь важно, что событие «выпуск карты» привязано не к физической выдаче пластика, а к моменту присвоения карте данных о держателе в автоматизированной банковской системе (АБС) [9]. Именно этот момент, начиная с 1 сентября 2027 года, будет считаться моментом «предоставления» карты клиенту при передаче информации в систему [9].

Для банковского IT это значит, что процесс выпуска карты должен генерировать событие передачи данных не на этапе «карта физически передана клиенту», а на этапе, когда в АБС карта уже привязана к конкретному держателю — то есть раньше, чем считает бизнес-процесс сегодня во многих банках.

Момент фиксации закрытия карты

Для передачи сведений о прекращении использования карты проект указания предусматривает несколько сценариев в зависимости от ситуации [9]:

• сразу после того, как банк получил от клиента уведомление об отказе от карты или направил клиенту сообщение о её бессрочной блокировке;
• в день расторжения договора банковского счёта, привязанного к карте, или соглашения о её использовании — если перед этим не было ни уведомления клиента, ни сообщения о блокировке.

Порядок закрытия счёта, к которому привязана карта, при этом по-прежнему определяется договором клиента с банком [6]. Это означает, что событийная модель в АБС должна различать как минимум три источника сигнала о закрытии: инициативу клиента, блокировку по инициативе банка и расторжение договора счёта — и для каждого из них корректно определять дату, которая пойдёт в систему.

Как быть с перевыпуском карты

Отдельного явного регулирования именно для «перевыпуска» как отдельной категории события в открытых источниках на момент подготовки статьи найти не удалось — подтверждённых данных по этому пункту в опубликованных материалах нет. Но логика вытекает из того, что система оперирует именно номером карты [7][8]: при плановом перевыпуске номер карты иногда сохраняется, а при экстренном перевыпуске (утеря, кража, компрометация) банк всегда присваивает новый номер, оставляя счёт прежним [15].

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

Требования к качеству данных о держателе

Проверка ИНН

Поскольку в систему передаётся именно ИНН держателя, а не только паспортные данные, банку нужен надёжный источник подтверждения этого номера. Официальный канал — сервис ФНС «Сведения об ИНН физического лица» (service.nalog.ru/inn.do), который по паспортным данным возвращает присвоенный ИНН [12][13]. Помимо прямого использования официального сервиса, часть банков и финтех-компаний уже сейчас закрывает эту задачу через коммерческие API-провайдеры, которые технически обращаются к тем же государственным источникам данных, включая ФНС, и используются для идентификации клиента и соблюдения требований антиотмывочного законодательства [14].

Для банка практический вопрос — не «где взять ИНН», а как встроить эту проверку в момент оформления карты так, чтобы:

• ИНН проверялся и фиксировался до передачи события «выпуск» в реестр, а не постфактум;
• расхождения между ИНН, ранее сохранённым в CRM/АБС, и результатом свежей проверки обрабатывались отдельным процессом, а не тихо перезаписывались;
• при смене клиентом паспортных данных (например, после замужества) не терялась привязка к уже выпущенным картам.

Обработка дублей клиентов

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

Рыночная практика для такой задачи — механизмы дедупликации на основе связки ключевых атрибутов (ИНН, серия и номер паспорта, дата рождения, ФИО) с построением единого профиля клиента (подход, близкий к MDM — Master Data Management) и регулярной сверкой уже существующих профилей на предмет совпадений. Для банка это означает, что подготовку к передаче данных в единую систему учёта стоит начинать не с самого механизма передачи, а с ревизии качества и уникальности клиентской базы — иначе ошибки дублирования проявятся уже на стороне регулятора.

Сверка внутреннего реестра с внешней системой

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

• карты, которые в АБС отмечены как закрытые, но по какой-то причине не были переданы во внешнюю систему;
• карты, для которых передача прошла, но подтверждение от НСПК не было получено или обработано;
• расхождения, возникшие из-за сбоя интеграции или ручной правки данных в АБС в обход стандартного процесса.

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

Технические отказы: как обрабатывать и что хранить

Любая интеграция с внешней системой предполагает, что часть сообщений не дойдёт с первого раза — из-за сетевых сбоев, недоступности сервиса на стороне НСПК или ошибок формата на стороне банка. Для банка это означает необходимость:

• очереди повторной отправки (retry) с разумными интервалами и предельным числом попыток;
• журнала статусов по каждому переданному событию (отправлено, подтверждено, отклонено, ожидает повтора);
• отдельного процесса для событий, которые не удалось передать даже после исчерпания повторных попыток, — с эскалацией на ручную проверку, а не тихим списанием в архив.

Что касается подтверждений успешной отправки — конкретный формат квитанций и протокол подтверждения определяются правилами НСПК, детали которых на момент подготовки статьи публично не раскрыты в полном объёме. Тем не менее общий принцип для любой регуляторной интеграции такого рода не меняется: банку нужно хранить не только факт отправки, но и полученное от внешней системы подтверждение (либо код ошибки при отказе) в течение срока, достаточного для возможной проверки со стороны регулятора — и заранее заложить это в архитектуру хранения логов интеграции, а не собирать задним числом.

Подготовка к лимиту в 20 карт

С 1 сентября 2027 года банки смогут выдать одному физлицу в совокупности максимум 20 платёжных карт, с помощью которых можно переводить деньги, если Банк России не установит более высокий лимит [9]. Перед каждым оформлением новой карты банк обязан будет проверять через систему, не превышен ли этот лимит [9]. Отдельного ограничения на количество карт в одном банке в итоговом законе нет — лимит общий, по всем банкам сразу [6].

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

• подзаконный порядок может запустить передачу данных начиная с 1 сентября 2026 года, а закон устанавливает крайний срок 1 сентября 2027 года; поэтому историю нужно готовить заранее — если в этот период в данные попадут ошибки (дубли клиентов, неверный ИНН), к моменту включения лимита они будут мешать реальным клиентам оформлять новые карты;
• интеграция канала проверки лимита в процесс оформления карты — это дополнительная синхронная зависимость от внешней системы в критичном пользовательском сценарии, и её отказоустойчивость нужно проектировать заранее, а не в последний момент.

Варианты реализации: доработка или интеграция

В зависимости от того, как у банка или финтех-компании уже устроен обмен данными с внешними системами, объём работы будет разным.

Если банк уже интегрирован с НСПК по другим сервисам (например, СБП или сервис проверки признаков перевода без согласия клиента), потребуется, скорее всего, точечная доработка: добавить новые типы сообщений в существующий канал обмена, расширить событийную модель АБС и настроить отдельный процесс сверки состояний.

Если у банка нет собственной интеграции с НСПК или обмен данными до сих пор велся через сторонний процессинговый центр, потребуется более глубокая работа: спроектировать канал передачи данных, синхронизировать событийную модель выпуска/закрытия карт между АБС и процессингом, выстроить обработку ошибок и очередь повторной отправки с нуля.

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

Команда «Пятого фактора» может изучить, как у банка или финтех-компании сейчас устроен обмен данными между АБС, процессингом и внешними системами, оценить качество клиентских данных и предложить решение — от точечной доработки существующего канала интеграции с НСПК до построения полноценного процесса сверки и обработки ошибок обмена. Если для задачи достаточно донастройки уже используемого процессингового решения без заказной разработки — это тоже разумный и более быстрый путь.

Практические этапы для банка

1. Провести инвентаризацию событий жизненного цикла карты в АБС — сверить, какие события выпуска, перевыпуска и закрытия сейчас фиксируются и в какой момент, и сопоставить их с моментами, которые требует система (в частности, момент присвоения данных о держателе, а не момент физической выдачи пластика) [9].
2. Оценить качество клиентской базы: долю профилей без подтверждённого ИНН, потенциальные дубли клиентов, устаревшие паспортные данные.
3. Встроить проверку ИНН в процесс оформления карты через официальный сервис ФНС или через уже используемый банком канал идентификации клиента в рамках антиотмывочных процедур [12][13][14].
4. Спроектировать или доработать канал передачи данных в единую систему учёта: формат сообщений, очередь повторной отправки, журнал статусов.
5. Настроить регулярную сверку внутреннего реестра карт банка с последним подтверждённым состоянием во внешней системе.
6. Заложить процесс синхронной проверки лимита карт в сценарий оформления новой карты — с запасом по времени до 1 сентября 2027 года.
7. Провести тестовый обмен данными в доступной тестовой среде НСПК до перехода в промышленную эксплуатацию, если такая среда предусмотрена правилами НСПК.
8. Определить срок и формат хранения подтверждений отправки и статусов обработки событий для внутреннего контроля и возможных проверок.

Ограничения, риски и типичные ошибки

• Путаница между моментом физической выдачи карты и моментом события в реестре. Если процесс выпуска в банке привязан к выдаче пластика, а не к присвоению данных о держателе в АБС, дата в отчётности может не совпадать с требуемой [9].
• Дубли клиентов, не устранённые до подключения к системе. Технически исправная интеграция при этом будет передавать формально верные, но фактически искажающие картину данные.
• ИНН, взятый из устаревшей записи в CRM, а не проверенный через актуальный источник на момент оформления карты.
• Отсутствие процесса для необработанных технических отказов. Если сообщения, которые не прошли даже после повторных попыток, не эскалируются на ручную проверку, часть событий рискует навсегда «потеряться» между АБС и реестром.
• Недооценка синхронной зависимости от внешней системы при проверке лимита карт: если канал связи с реестром окажется недоступен в момент оформления карты клиентом, банку нужен заранее продуманный сценарий (отказ в выдаче, отложенная обработка или иной регламент), а не непредсказуемое поведение системы.
• Ожидание финальной версии указания Банка России без подготовки процессов заранее. Часть требований по протоколу обмена может уточняться, но структура события (какие данные, по какому триггеру) уже описана в проекте достаточно конкретно, чтобы начинать подготовку АБС и клиентской базы уже сейчас [9].

Как выбрать путь: готовое решение или доработка

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

Более глубокая доработка потребуется, если: обмен данными с процессингом до сих пор устроен вручную или через нетиповые каналы; в клиентской базе не проводилась систематическая дедупликация; событийная модель АБС не разделяет разные сценарии закрытия карты (отказ клиента, блокировка банком, расторжение договора счёта); либо банк одновременно готовится и к передаче данных в реестр, и к работе с проверкой лимита карт, и эти два процесса нужно спроектировать согласованно, а не как два независимых модуля.

Вывод

Единая система учёта банковских карт — это в первую очередь требование к качеству и своевременности данных о жизненном цикле карты, а не разовая техническая интеграция. Банку нужно точно фиксировать момент выпуска карты в привязке к присвоению данных о держателе, различать сценарии прекращения использования карты, поддерживать актуальный и проверенный ИНН держателя, устранять дубли клиентов и выстраивать устойчивый к сбоям канал обмена с внешней системой — заранее, до того как с 1 сентября 2027 года эти данные начнут напрямую влиять на возможность клиента получить новую карту. Финальные технические детали протокола обмена ещё уточняются правилами НСПК и указанием Банка России, но структура требуемых событий уже достаточно ясна, чтобы начать подготовку АБС и клиентской базы уже сейчас.

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

Источники

[1] journal.sovcombank.ru — Единая система учета банковских карт появится в России: что это и зачем — https://journal.sovcombank.ru/news/ucet-bankovskix-kart

[2] finance.mail.ru — В России введут единый реестр банковских карт с 1 сентября: как будет работать, подводные камни — https://finance.mail.ru/article/s-1-sentyabrya-2026-goda-v-rossii-vvedut-sistemu-ucheta-bankovskih-kart-69220363/

[3] kucoin.com — Единая система учета платежных карт в России: что изменится с 1 сентября 2026 года — https://www.kucoin.com/ru/blog/russias-unified-payment-card-registry-what-changes-on-september-1-2026

[4] osnmedia.ru — Единая система учета банковских карт заработает в РФ с 1 сентября 2026 — https://www.osnmedia.ru/obshhestvo/edinaya-sistema-ucheta-bankovskih-kart-zarabotaet-v-rf-s-1-sentyabrya-2026

[5] amic.ru — Сколько банковских карт можно иметь россиянам? — https://www.amic.ru/news/v-rossii-razyasnili-novye-pravila-dlya-bankovskih-kart-590990

[6] bistrodengi.ru — Единая система учета карт с 1 сентября 2026 года — https://bistrodengi.ru/articles/edinaya-sistema-ucheta-bankovskih-kart/

[7] garant.ru — В России появится единая система учета платежных карт для борьбы с дропперством — https://www.garant.ru/news/2187806/

[8] v2b.ru — Федеральный закон от 26.06.2026 № 210-ФЗ (текст поправок) — https://www.v2b.ru/documents/federalnyy-zakon-ot-26-06-2026-210-fz/

[9] consultant.ru — ЦБ РФ подготовил для банков правила направления информации в единую систему учета платежных карт — https://www.consultant.ru/legalnews/32347/

[10] pnp.ru — «О внесении изменений в Федеральный закон «О связи» и отдельные законодательные акты Российской Федерации» № 210-ФЗ от 26.06.2026 — https://www.pnp.ru/law/2026/06/26/federalnyy-zakon-210-fz.html

[11] klerk.ru — С 1 сентября 2026 года заработает единая система учета платежных карт — https://www.klerk.ru/user/599302/702402/

[12] kod.ru — Как узнать ИНН физического лица по паспорту: онлайн-инструкция на 2026 год — https://kod.ru/kak-uznat-svoi-inn-po-pasportu-onlayn

[13] service.nalog.ru — Узнать ИНН (официальный сервис ФНС России) — https://service.nalog.ru/inn.html

[14] newdb.net — API проверки паспорта и ИНН через ФНС — https://newdb.net/fiz/fns

[15] fpa.ru — Что значит перевыпустить карту: причины, способы, сроки — https://fpa.ru/info/kak-zamenit-bankovskuju-kartu-instrukcija-po-perevypusku/