01 сентября 2026 года стало не просто очередной датой в календаре платежной отрасли. С этого дня крупнейшие банки должны предоставить клиентам возможность совершать операции с цифровыми рублями, а часть торгово-сервисных компаний — принимать такие платежи. При этом важно сразу разделить две задачи. Первая — обеспечить клиентам банка доступ к платформе цифрового рубля Банка России, вторая — обеспечить технологическую готовность бизнеса, который принимает цифровые рубли в оплату товаров и услуг.
Для банка это означает работу не с отдельным платежным сервисом, а с новым контуром финансовой инфраструктуры. Для корпоративного клиента — необходимость связать этот контур с кассой, учетной системой, процессами возврата и внутренним контролем.
Цифровой рубль при этом не заменяет наличные или безналичные деньги. Один рубль в цифровой форме имеет ту же номинальную стоимость, что и рубль на банковском счете или наличный рубль.
Счет цифрового рубля существует на платформе Банка России. Банк-участник платформы предоставляет клиенту доступ к нему и обеспечивает технологическое взаимодействие. Поэтому привычная логика «деньги находятся на счете в банке — банк проводит платеж» здесь меняется.
Это означает, что надежность клиентского опыта определяется сразу несколькими уровнями: банковским приложением, каналами взаимодействия с платформой Банка России, криптографическими механизмами, процедурами аутентификации и внутренними системами учета.
Первая волна обязательного приема началась с сентября 2026 года. Требование распространяется на продавцов, которые одновременно соответствуют установленным законом условиям: их выручка за 2025 год превышает 120 млн рублей, а на 1 января 2026 года у них был договор о приеме электронных средств платежа с системно значимой кредитной организацией или кредитной организацией, признанной Банком России значимой на рынке платежных услуг.
Есть и исключения. В частности, обязанность не распространяется на торговые точки с выручкой за предыдущий год менее 5 млн рублей, а также на места продаж, где отсутствует доступ к интернету.
Дальнейшее расширение будет происходить поэтапно. С 1 сентября 2027 года в периметр попадут соответствующие условиям компании — клиенты банков с универсальной лицензией — с выручкой свыше 30 млн рублей. С 1 сентября 2028 года предусмотрен следующий этап, в том числе для банков с базовой лицензией и продавцов с выручкой от 20 до 30 млн рублей.
Как отметил Резниченко Сергей Анатольевич, заведующий Кафедрой информационной безопасности Финансового университета при Правительстве Российской Федерации, к.т.н., доцент: «Здесь важен не только собственно календарь. Банку необходимо заранее учитывать, что каждый новый этап увеличивает число корпоративных клиентов, которым потребуется технологическая поддержка цифрового рубля. Вопросы цифрового рубля напрямую связаны с компетенциями, которые сегодня формируются в Финансовом университете при Правительстве Российской Федерации. Кафедра информационной безопасности входит в состав Факультета информационных технологий и анализа больших данных. Одно из профильных направлений подготовки связано с управлением информационной безопасностью в кредитно-финансовой сфере».
Предлагаемая композиция: три горизонтальных уровня — «Банк России / платформа цифрового рубля», «банковские каналы», «Клиент / касса / 1С». Между уровнями — стрелки с подписями «счет цифрового рубля», «операция», «подтверждение», «сверка». Визуальный стиль — строгая корпоративная инфографика, без фотографий и стоковых элементов.
Если смотреть на задачу с позиции банка, подключение цифрового рубля нельзя свести к запуску отдельной функции в мобильном приложении.
Перед масштабированием решения банка и его корпоративным клиентам стоит пройти короткий тест.
Вопрос 1. Что произойдет при возврате товара?
Не «можем ли мы вернуть деньги?», а:
кто инициирует возврат, как система находит исходную операцию, куда направляются цифровые рубли и как результат попадает в 1С?
Если на один из этих вопросов нет четкого ответа, платежный контур еще нельзя считать полностью готовым.
Вопрос 2. Где виден платеж?
Проверить нужно сразу три точки:
касса → банковская система → учетная система.
Во всех трех местах должна быть согласованная информация об операции.
Отдельно следует проверить сверку в конце операционного периода. Платеж, который корректно отображается на экране кассира, но не попадает в отчетность, — это уже не пользовательская мелочь, а операционный риск.
Вопрос 3. Кто отвечает за разбор сбоя?
Должно быть определено ответственное лицо или подразделение.
Клиент не должен получать ответ в стиле «обратитесь в банк», если проблема возникла на стороне кассового ПО. В свою очередь, банк должен иметь возможность быстро определить, на каком участке цепочки возникла ошибка.
Для этого необходимы понятные идентификаторы операций, журналы событий и регламент эскалации.
Оформить как одностраничную инфографику с пятью блоками: «Периметр», «Счет», «Касса», «Учет», «Возврат». В каждом блоке — 2–3 проверяемых пункта и поле «готово / требуется проверка». Внизу — отдельная строка «Кто отвечает за инцидент?». Дизайн должен быть выполнен в единой стилистике с двумя предыдущими инфографиками.
Также следует отметить еще один важный принцип: безопасность цифровой финансовой системы определяется не одним защищенным компонентом, а согласованностью всей инфраструктуры. Для банка и его клиентов это особенно актуально.
Можно идеально настроить мобильное приложение и при этом получить проблему в кассовой системе. Можно обеспечить корректное проведение операции через платформу и потерять ее на этапе внутреннего учета. Можно защитить канал связи, но оставить недостаточно защищенным процесс управления ключами.
Поэтому тестирование должно идти по цепочке: Клиент → приложение → РСХБ → платформа Банка России → подтверждение → учет → возврат / сверка.
Для каждого этапа нужно проверить штатный сценарий и минимум один негативный сценарий. Такой подход позволяет обнаружить ошибки до того, как они попадут в реальную массовую эксплуатацию.