Если статья описывает вашу ситуацию, мы можем взять на себя проверку документов, подготовку комплекта, подачу и ответы на замечания экспертизы.
Смарт-контракты в цифровых рублях: какие возможности ЦБ предлагает российским ИТ-разработчикам
У цифрового рубля появляется направление, которое может оказаться значительно интереснее для российского ИТ-рынка, чем сам новый способ оплаты. Банк России предложил создать платформу коммерческих смарт-контрактов, на которой сторонние разработчики смогут создавать собственные алгоритмы автоматического исполнения сделок в цифровых рублях, проходить проверку, размещать решения в специальной витрине и в перспективе получать вознаграждение за их использование.
Для ИТ-компаний это потенциально новый рынок финансового ПО: автоматизация расчетов между предприятиями, безопасные сделки, корпоративное казначейство, контроль целевого расходования средств, страховые выплаты, торговое финансирование и сценарии, связанные с логистикой и цепочками поставок.
Но здесь особенно важно отделять уже работающую инфраструктуру цифрового рубля от планируемого функционала. На сентябрь 2026 года коммерческая платформа смарт-контрактов еще не является готовым массовым сервисом для разработчиков. 18 июня 2026 года Банк России опубликовал концепцию платформы коммерческих смарт-контрактов и вынес ее на обсуждение с рынком. Предложения регулятор принимает до 30 сентября 2026 года.
Для российских разработчиков это редкая ситуация: архитектура будущей платформы еще формируется, а значит, компании могут не только готовить продукты под новый рынок, но и направлять Банку России предложения по требованиям, источникам данных, способам монетизации и другим элементам системы.
Что именно Банк России предлагает изменить в работе смарт-контрактов
Смарт-контракт Банк России описывает как программу, или алгоритм, автоматически выполняющий условия сделки при наступлении заранее определенных событий. Например, деньги могут перечисляться поставщику только после подтверждения поставки, а очередной транш финансирования — после выполнения определенного этапа проекта.
Базовые смарт-контракты на платформе цифрового рубля уже существуют. В официальной концепции ЦБ отмечает, что реализованы сценарии регулярных и разовых переводов. Кроме того, в ходе пилотирования цифрового рубля участники уже тестировали несколько типов смарт-контрактов.
Однако есть принципиальное ограничение: сейчас смарт-контракты для самой платформы цифрового рубля создает Банк России. Именно это ЦБ предлагает изменить.
Новая модель получила название ПКСК — платформа коммерческих смарт-контрактов. Предполагается, что она станет отдельным компонентом инфраструктуры цифрового рубля и позволит внешним разработчикам создавать собственные программируемые сценарии.
| Параметр | Текущая модель | Предлагаемая модель ПКСК |
|---|---|---|
| Кто разрабатывает смарт-контракты | Банк России | В том числе сторонние юридические лица |
| Где размещается решение | В инфраструктуре платформы цифрового рубля | В специальной витрине коммерческих смарт-контрактов |
| Можно ли создать собственный коммерческий сценарий | Возможности ограничены моделью платформы | Предполагается предоставить такую возможность разработчикам |
| Использование внешних данных | Ограниченные сценарии | Планируется подключение государственных, коммерческих и открытых источников |
| Монетизация разработчика | Отдельная коммерческая модель отсутствует | ЦБ рассматривает получение комиссии за использование смарт-контракта |
| Статус | Платформа цифрового рубля действует | ПКСК находится на стадии концепции |
Кто сможет разрабатывать смарт-контракты цифрового рубля
Это один из наиболее интересных пунктов опубликованного Банком России документа.
Согласно концепции, разработчиком смарт-контракта сможет стать юридическое лицо, соответствующее требованиям оператора ПКСК.
Конкретный перечень таких требований пока не установлен. Он должен быть разработан позднее. Поэтому сейчас преждевременно говорить, что для доступа обязательно понадобится лицензия, определенный размер капитала, конкретная аккредитация или статус в каком-либо государственном реестре.
Таких требований в опубликованной концепции нет.
При этом ЦБ отдельно указывает, что доступ иностранных лиц к ПКСК на рассматриваемом этапе не предполагается. Таким образом, архитектура изначально ориентирована прежде всего на российских участников.
Для российского ИТ-бизнеса это может открыть несколько ролей:
- разработчик коммерческих смарт-контрактов;
- создатель отраслевых финансовых сервисов на базе таких контрактов;
- поставщик корпоративных систем, интегрируемых с ПКСК;
- поставщик доверенных внешних данных;
- разработчик решений для банков и других финансовых организаций;
- в перспективе — участник рынка проверки смарт-контрактов, если ЦБ утвердит модель с привлечением специализированных проверяющих организаций.
Для компаний, которые одновременно развивают российское ПО, полезно отдельно оценить стратегию включения продукта в реестр российского программного обеспечения. Однако важно подчеркнуть: в опубликованной концепции ПКСК наличие записи в реестре Минцифры не названо обязательным условием допуска разработчика.
Как будет выглядеть путь ИТ-продукта до платформы цифрового рубля
Концепция ЦБ предполагает значительно более строгий жизненный цикл продукта, чем обычная публикация приложения или SaaS-сервиса.
Причина очевидна: ошибка в программном коде здесь потенциально означает ошибочное распоряжение реальными цифровыми рублями.
Шаг 1. Описание бизнес-логики
До разработки необходимо будет описать, что именно делает смарт-контракт, какие условия запускают его исполнение, какие параметры используются и какие операции должны происходить при наступлении события.
Это описание предполагается передавать вместе с исходным кодом во время проверки.
То есть подход «сначала написали код, потом решили, как его использовать» для ПКСК, вероятно, работать не будет. Бизнес-логика становится частью проверяемой документации продукта.
Шаг 2. Разработка смарт-контракта
Банк России намерен подготовить специальные руководства для разработчиков. При этом сама разработка и первоначальное тестирование должны проходить на инфраструктуре компании-разработчика.
Разработчик будет отвечать как минимум за:
- описание логики смарт-контракта;
- разработку исходного кода;
- поиск и устранение уязвимостей;
- исправление дефектов бизнес-логики;
- поддержку и выпуск новых версий.
Шаг 3. Тестирование
До передачи решения на публикацию разработчик должен будет протестировать его на ошибки, уязвимости и некорректное исполнение заложенного алгоритма.
Для финтех-команд это означает, что тестирование становится не только внутренней процедурой качества, но и частью допуска продукта к инфраструктуре.
Шаг 4. Проверка
Перед размещением в витрине смарт-контракт должен будет пройти проверку сразу по нескольким направлениям:
- соответствие заявленной бизнес-логике;
- соответствие законодательству;
- соответствие требованиям информационной безопасности;
- корректность реализации условий сделки.
Банк России пока рассматривает различные варианты организации проверки. В одном из них разработчик самостоятельно направляет исходный код проверяющей организации, после чего предоставляет оператору отчет. Во втором код передается оператору ПКСК, а уже оператор организует его проверку.
Окончательная модель еще не определена.
Шаг 5. Публикация в витрине
После успешной проверки смарт-контракт предполагается размещать в специальной витрине.
Пользователь сможет увидеть:
- назначение решения;
- описание автоматизируемого процесса;
- изменяемые параметры;
- условия использования;
- размер комиссии;
- используемые внешние источники данных.
По сути, может появиться отдельный каталог программируемых платежных сценариев, из которого организации смогут выбирать готовый смарт-контракт для своей задачи.
Витрина смарт-контрактов может стать новым рынком для российских ИТ-компаний
Именно идея единой витрины делает инициативу особенно интересной для небольших разработчиков.
Сегодня финтех-компания, создающая автоматизацию расчетов, обычно должна отдельно интегрироваться с банками, платежными системами, корпоративными клиентами и внешними источниками информации. При масштабировании продукта каждая новая интеграция увеличивает стоимость разработки и поддержки.
В модели ПКСК Банк России предлагает стандартизировать значительную часть инфраструктуры.
В официальной концепции ЦБ прямо указывает, что единые интерфейсы и правила подключения могут снизить порог выхода на федеральный уровень. Отдельно отмечается, что это особенно важно для небольших команд разработчиков.
То есть перспективный рынок может выглядеть примерно так:
разработчик создает специализированный смарт-контракт → проходит установленную проверку → публикует его в общей витрине → финансовые организации предоставляют доступ своим клиентам → разработчик получает вознаграждение в зависимости от использования решения.
Это существенно отличается от классической заказной разработки банковского ПО.
Как ЦБ предлагает монетизировать смарт-контракты
Еще одна важная часть концепции — возможность зарабатывать на разработанных алгоритмах.
Банк России прямо рассматривает комиссию за использование смарт-контракта как один из возможных вариантов вознаграждения разработчика.
В документе указано, что доход может быть связан с фактическим спросом и масштабом использования решения.
Например, потенциально коммерческая модель может строиться вокруг:
- комиссии за каждое исполнение смарт-контракта;
- комиссии за использование определенного сервиса;
- платного доступа к данным, необходимым для выполнения контракта.
При этом конкретная тарифная модель еще не утверждена. Банк России специально вынес вопрос монетизации на публичное обсуждение.
Регулятор спрашивает рынок в том числе о том, какие модели вознаграждения следует предоставить разработчикам и нужно ли ограничивать максимальный размер комиссии.
Поэтому заявлять сегодня конкретную стоимость публикации или процент вознаграждения разработчика нельзя.
Какие смарт-контракты можно будет создавать
ЦБ приводит целый набор потенциальных сценариев. Для ИТ-разработчиков особенно важно, что речь идет не только о простых переводах между кошельками.
Безопасная сделка
Один из самых понятных сценариев — автоматический расчет после выполнения обязательства.
Например:
- покупатель резервирует необходимую сумму;
- товар отправляется поставщиком;
- внешняя информационная система подтверждает исполнение условия;
- смарт-контракт автоматически перечисляет деньги продавцу.
Сегодня для подобных операций используются, например, эскроу-счета, аккредитивы и другие механизмы, часто предполагающие проверку документов.
ЦБ рассматривает возможность автоматизировать часть этого процесса.
Особенно интересен пример с государственными закупками. В концепции прямо упоминается возможность использования информации из Единой информационной системы в сфере закупок и электронных торговых площадок для автоматизации оплаты и контроля расходования средств.
Мы уже разбирали, как цифровой рубль пересекается с закупочным регулированием, в материале «Цифровой рубль в госконтрактах: что меняется для поставщиков».
Автоматические платежи нового уровня
Обычный автоплатеж чаще всего работает по достаточно простой логике: определенная сумма переводится в установленный день.
Смарт-контракт позволяет сделать алгоритм значительно сложнее.
Платеж потенциально сможет:
- запускаться после конкретного события;
- приостанавливаться;
- изменять размер;
- учитывать информацию из внешней системы;
- завершаться после выполнения заданного условия.
Для разработчиков ERP, финансового ПО и корпоративных сервисов это создает пространство для совершенно новых продуктов.
Контроль целевого использования денег
Еще один сценарий — запрограммировать допустимые направления расходования средств.
Например, отправитель и получатель могут предусмотреть, что полученные деньги разрешается использовать только в определенных сценариях.
ЦБ рассматривает возможность устанавливать:
- максимальную сумму одной операции;
- лимит расходов за период;
- частоту операций;
- поэтапное разблокирование средств;
- транши;
- паузы между платежами.
Именно здесь цифровой рубль может пересекаться с государственным финансированием, промышленными субсидиями и проектными программами поддержки.
Однако возможность технически ограничивать расходование средств нельзя интерпретировать как утверждение, что все государственные субсидии будут обязательно программироваться таким образом. Конкретный порядок определяется законодательством и условиями соответствующей программы.
Корпоративное казначейство
Для промышленных предприятий это один из наиболее практичных сценариев.
Сейчас крупная компания может использовать многоступенчатую схему:
заявка на платеж → проверка бюджета → согласование → контроль лимита → подтверждение → перечисление.
Банк России предлагает рассмотреть возможность переноса части этих правил непосредственно в код.
Например, компания сможет заранее установить:
- бюджет подразделения;
- лимит проекта;
- период действия лимита;
- роли согласующих сотрудников;
- условия проведения платежа.
Смарт-контракт сможет проверять доступный лимит и проводить операцию после получения необходимых подтверждений.
Для разработчиков корпоративных ERP, казначейских платформ, систем электронного документооборота и промышленного ПО это потенциально важное направление интеграции.
Страховые выплаты
ЦБ также предлагает сценарий автоматизированных страховых выплат.
Если страховое событие может быть однозначно подтверждено независимым источником данных, смарт-контракт получает эту информацию, проверяет условия полиса, рассчитывает сумму и автоматически выполняет перевод.
В концепции приводится простой пример — подтвержденная задержка авиарейса.
Для ИТ-рынка это означает спрос не только на сами смарт-контракты, но и на качественные сервисы внешних данных.
Внешние данные могут стать отдельным ИТ-бизнесом
Смарт-контракт способен самостоятельно принимать решение только на основании информации, которой он располагает.
Поэтому один из ключевых элементов будущей ПКСК — доверенные поставщики внешних данных.
Банк России рассматривает три группы источников:
- государственные информационные системы;
- коммерческие информационные системы;
- открытые источники информации.
Внешним событием может быть, например:
- статус доставки груза;
- рыночная котировка;
- регистрация имущества;
- приемка выполненных работ;
- данные электронного документооборота;
- информация из учетной системы организации;
- подтверждение наступления страхового события.
Таким образом, вокруг ПКСК потенциально может сформироваться отдельный рынок поставщиков доверенных данных.
Причем ЦБ рассматривает возможность их коммерческой монетизации: поставщик сможет получать комиссию за использование его данных при исполнении коммерческих смарт-контрактов.
Для российских разработчиков API, отраслевых информационных платформ, операторов электронного документооборота и владельцев специализированных баз данных это может стать не менее интересным направлением, чем непосредственно разработка смарт-контрактов.
Почему интеграция с государственными системами особенно важна
В предложенной архитектуре ПКСК информационная система может фактически подтверждать событие, которое запускает финансовую операцию.
Например, концепция Банка России рассматривает использование данных:
- ЕИС в сфере закупок;
- электронных торговых площадок;
- Росреестра;
- ГИБДД;
- систем электронного документооборота;
- корпоративных информационных систем.
Это принципиально меняет характер разработки.
Разработчику недостаточно написать условие:
«если товар поставлен — перечислить деньги».
Необходимо определить доверенный источник, который способен достоверно подтвердить факт поставки, обеспечить корректный обмен данными и предусмотреть поведение системы при ошибке или недоступности источника.
В архитектуре смарт-контрактов именно качество внешних данных может стать одним из критических факторов надежности.
Информационная безопасность станет главным барьером входа
У обычного программного продукта ошибка может вызвать сбой интерфейса или неправильный расчет. Ошибка в смарт-контракте способна привести к неверному перечислению денег.
Поэтому требования Банка России предполагаются существенно жестче обычной процедуры публикации ПО.
Концепция предусматривает контроль безопасности на протяжении всего жизненного цикла:
- разработка;
- тестирование;
- проверка;
- публикация;
- исполнение;
- обновление;
- вывод версии из эксплуатации.
Для доступа планируется использовать идентификацию и авторизацию участников, разграничение прав, защищенные каналы связи и криптографическую защиту.
Отдельное внимание уделяется исходному коду.
Банк России указывает среди рисков:
- неоптимальный код и чрезмерную нагрузку на инфраструктуру;
- уязвимости;
- несанкционированные переводы;
- ошибки бизнес-логики;
- сбои внешних источников;
- возможный взлом смарт-контракта;
- утечки информации.
Поэтому разработчикам финтех-продуктов разумно уже на этапе проектирования использовать подход secure by design, а не пытаться «добавить безопасность» после завершения продукта.
Как будут обновляться коммерческие смарт-контракты
Еще одна деталь концепции, важная именно разработчикам, касается версий.
Нельзя будет просто заменить старый код новым.
Новая версия должна проходить те же процедуры тестирования и проверки, что и первоначальная.
Кроме того, разработчик должен будет предусматривать контролируемое переходное окно, в течение которого старая и новая версии могут работать параллельно.
Это необходимо, чтобы:
- корректно завершить уже начатые операции;
- не нарушить действующие сделки;
- уведомить пользователей об изменениях;
- обеспечить прозрачность новой бизнес-логики.
Разработчику также предполагается формировать описание изменений между версиями.
Для ИТ-компании это означает необходимость заранее выстроить полноценный жизненный цикл продукта: version control, тестовые контуры, сопровождение старых версий, управление уязвимостями и процедуры безопасного обновления.
Пять перспективных продуктов для российского ИТ-рынка
Из опубликованной концепции уже можно выделить несколько направлений, вокруг которых способны появиться самостоятельные коммерческие решения.
| Продукт | Что автоматизирует | Основные потребители |
|---|---|---|
| Смарт-контракт безопасной сделки | Оплату после подтверждения поставки или исполнения обязательства | B2B, маркетплейсы, закупочные площадки |
| Корпоративное цифровое казначейство | Лимиты, бюджеты, согласования и платежи | Холдинги и промышленные предприятия |
| Контроль целевого финансирования | Транши, лимиты и допустимые направления расходов | Банки, предприятия, институты развития |
| Сервис автоматических страховых выплат | Проверку события и автоматический перевод | Страховые компании |
| Поставщик доверенных событий | Передачу подтвержденных данных в смарт-контракт | Разработчики ПКСК и финансовые организации |
Перечень не является закрытым. Сам Банк России предлагает участникам рынка направлять дополнительные сценарии применения.
Почему у небольших ИТ-команд появляется шанс конкурировать с крупными банками
Один из наиболее примечательных выводов концепции касается инфраструктурного барьера.
Сегодня маленькому разработчику сложно вывести финансовый сервис сразу на федеральный рынок. Даже сильный продукт требует большого количества интеграций, договоренностей и инфраструктуры.
ПКСК задумана иначе.
Банк России ожидает, что стандартизация интерфейсов и единые правила подключения позволят разработчикам масштабировать решения без необходимости самостоятельно создавать полный платежный контур.
При этом финансовые организации должны стать для граждан и компаний своеобразной «последней милей»: пользователь выбирает необходимые смарт-контракты через привычный интерфейс своей финансовой организации.
Поэтому небольшая российская ИТ-компания потенциально сможет конкурировать не размером инфраструктуры, а качеством алгоритма и удобством конкретного финансового продукта.
Что пока НЕ определил Банк России
Несмотря на подробность документа, ПКСК пока остается концепцией. Поэтому существует целый ряд вопросов, ответы на которые появятся позже.
На сентябрь 2026 года окончательно не установлены:
- дата полноценного запуска ПКСК;
- детальные технические требования к разработчикам;
- окончательная архитектура подключения;
- конкретные технические инструменты разработки;
- модель проверки исходного кода;
- перечень проверяющих организаций;
- порядок и размер комиссий разработчиков;
- предельные тарифы;
- исчерпывающий перечень доступных внешних источников;
- класс защищенности будущей платформы;
- окончательное распределение ответственности между участниками.
Поэтому разработчикам сейчас не стоит строить бизнес-план на предположении, что любое приложение уже можно подключить к платформе цифрового рубля.
Правильнее воспринимать 2026 год как этап формирования будущей инфраструктуры.
Что российской ИТ-компании можно делать уже сейчас
1. Выбрать конкретную бизнес-задачу
Самый перспективный продукт — не «смарт-контракт вообще», а решение конкретной проблемы.
Например:
- оплата промышленной поставки после приемки;
- поэтапное финансирование проекта;
- автоматическое управление корпоративными лимитами;
- расчеты между участниками производственной кооперации;
- контроль исполнения договора поставки;
- автоматическая страховая выплата;
- управление целевыми средствами.
2. Определить необходимые источники данных
Нужно заранее понимать, какое событие запускает финансовую операцию и откуда поступает достоверное подтверждение.
Если смарт-контракт зависит от информации, которой нельзя доверять или которую невозможно получить автоматически, коммерческий сценарий становится значительно сложнее.
3. Описать бизнес-логику до написания кода
Именно такой подход предусматривает концепция ЦБ.
Полезно заранее составить:
- события запуска;
- участников;
- условия исполнения;
- исключения;
- лимиты;
- источники данных;
- порядок обработки ошибки;
- правила остановки смарт-контракта.
4. Продумать информационную безопасность
Архитектура решения должна предусматривать защиту кода, контроль версий, журналирование, безопасное обновление и работу с отказами внешних источников.
5. Проверить права на программный продукт
Для будущего коммерческого размещения важно заранее определить, кому принадлежат исключительные права на исходный код и отдельные компоненты системы.
Для российских разработчиков мы отдельно разбирали различия между патентованием и регистрацией программы для ЭВМ.
6. Определить реестровую стратегию продукта
Создание смарт-контракта для ПКСК и включение программного обеспечения в российские государственные реестры — разные процедуры.
Тем не менее для ИТ-компании статус российского ПО может иметь самостоятельное значение при работе с государственными заказчиками и корпоративным сектором.
Подробнее требования можно изучить в материале «Реестр Минцифры: преимущества и порядок включения».
Если программная часть поставляется вместе с российским оборудованием, следует отдельно оценивать модель программно-аппаратного комплекса. Этой теме посвящен наш разбор двойного включения ПАК в контуры Минпромторга и Минцифры.
Сейчас разработчики могут напрямую повлиять на будущую модель ПКСК
Особенность текущего этапа заключается в том, что Банк России не просто опубликовал описание будущей системы, а проводит общественное обсуждение.
Предложения принимаются до 30 сентября 2026 года на электронную почту fintech@cbr.ru.
Регулятор предлагает участникам рынка высказаться, в частности, по следующим вопросам:
- какие дополнительные функции нужны платформе;
- какие сценарии смарт-контрактов будут наиболее востребованы;
- какие модели монетизации следует предоставить разработчикам;
- нужно ли устанавливать предельные комиссии;
- какие государственные и коммерческие источники данных подключать;
- как должна проходить проверка смарт-контрактов;
- какие требования предъявлять к проверяющим организациям;
- следует ли предоставлять пользователям доступ к исходному коду;
- какие дополнительные риски необходимо учитывать.
То есть российская ИТ-компания, которая действительно планирует создавать продукт в этой области, пока может участвовать в обсуждении еще до утверждения окончательных правил.
Смарт-контракты и промышленность: где может возникнуть практический спрос
Для промышленного сектора особенно интересным выглядит соединение цифрового платежа с данными корпоративных систем.
Представим типовую поставку промышленного оборудования.
- Предприятие заключает договор с поставщиком.
- Средства резервируются.
- Оборудование производится и отгружается.
- Информационная система фиксирует доставку.
- Заказчик оформляет электронную приемку.
- Доверенный источник передает подтверждение.
- Смарт-контракт автоматически выполняет платеж.
Более сложный алгоритм может дополнительно учитывать размер аванса, промежуточные этапы, гарантийное удержание, лимит проекта и другие параметры.
Если такие модели получат практическую реализацию, для разработчиков промышленного ПО появится новая зона интеграции между ERP, ЭДО, закупочными платформами, логистическими системами и платежной инфраструктурой.
Смарт-контракт — это не криптовалютный токен
Из-за терминологии новую инициативу иногда ошибочно связывают с классическими blockchain-проектами и криптовалютными смарт-контрактами.
В случае цифрового рубля речь идет о другом контуре.
Смарт-контракт выполняет запрограммированную бизнес-логику, а перевод цифровых рублей происходит в регулируемой инфраструктуре платформы цифрового рубля.
Банк России рассматривает ПКСК как отдельный компонент этой инфраструктуры, оператором которого на первом этапе предполагает выступать сам регулятор.
Поэтому разработчику нужно ориентироваться прежде всего не на практику публичных криптосетей, а на будущие технические стандарты, требования к безопасности и правила, которые установит оператор ПКСК.
Основные риски для разработчика смарт-контрактов
| Риск | Почему важен | Что предусматривает концепция |
|---|---|---|
| Ошибка бизнес-логики | Платеж может исполниться неправильно | Предварительное описание и проверка алгоритма |
| Уязвимость кода | Риск несанкционированных операций | Тестирование и проверка ИБ |
| Неоптимальный код | Дополнительная нагрузка на платформу | Технические ограничения и оценка операций |
| Недостоверные внешние данные | Контракт может сработать по ложному событию | Доверенные источники и возможная диверсификация данных |
| Ошибка новой версии | Может нарушить уже выполняемые операции | Повторное тестирование и переходное окно |
| Инцидент информационной безопасности | Риск финансовых потерь и утечки информации | Контроль доступа, целостности и защищенные каналы |
FAQ: смарт-контракты цифрового рубля для разработчиков
Можно ли российской ИТ-компании уже сейчас опубликовать собственный смарт-контракт цифрового рубля?
Нет. По состоянию на сентябрь 2026 года Банк России опубликовал концепцию будущей платформы коммерческих смарт-контрактов. Массовый механизм подключения независимых разработчиков к ПКСК еще не запущен.
Кто сможет стать разработчиком?
В концепции указано, что разработчиком сможет стать юридическое лицо, соответствующее требованиям оператора платформы. Конкретные требования должны быть определены позднее. Доступ иностранных лиц на рассматриваемом этапе не предполагается.
Сможет ли разработчик зарабатывать на своем смарт-контракте?
Да, такая возможность рассматривается. ЦБ предлагает модель, при которой разработчик сможет получать комиссию за использование смарт-контракта. Однако окончательная тарифная схема пока не установлена.
Будут ли смарт-контракты проверять перед публикацией?
Да. Концепция предусматривает обязательное тестирование и проверку соответствия бизнес-логике, законодательству и требованиям информационной безопасности.
Можно ли использовать сведения государственных информационных систем?
Банк России рассматривает ГИС как один из трех основных типов внешних источников наряду с коммерческими информационными системами и открытыми источниками. Конкретный перечень подключаемых систем еще формируется.
Нужен ли разработчику реестр Минцифры?
В опубликованной концепции ПКСК включение программного продукта в реестр российского ПО не установлено как обязательное условие допуска. Это отдельный механизм подтверждения российского программного обеспечения, который может иметь самостоятельное значение для госзакупок, льгот и работы с заказчиками.
Что в итоге меняется для российского ИТ-рынка
Предложенная Банком России платформа коммерческих смарт-контрактов может создать принципиально новый сегмент российского финтеха.
Если концепция будет реализована в предложенной форме, разработчики смогут не просто создавать программное обеспечение для отдельных банков или заказчиков, а размещать стандартизированные сценарии автоматических расчетов в общей инфраструктуре цифрового рубля.
Наиболее важные возможности для ИТ-компаний выглядят так:
- разработка собственных смарт-контрактов;
- публикация решений в единой витрине;
- доступ к широкому кругу пользователей через финансовые организации;
- создание отраслевых сценариев автоматизации платежей;
- работа с государственными и коммерческими источниками данных;
- монетизация смарт-контрактов;
- создание сервисов доверенных данных;
- выход небольших команд на федеральный рынок без построения собственной полноценной платежной инфраструктуры.
При этом сегодня важно не опережать регулятора. ПКСК — пока концепция, а не готовый магазин приложений для цифрового рубля. Технические требования, модель допуска, проверки, тарифы и распределение ответственности еще предстоит определить.
Для российского разработчика сейчас наиболее разумная стратегия — выбрать перспективный сценарий, описать его бизнес-логику, определить необходимые источники данных, подготовить архитектуру с учетом требований информационной безопасности и следить за публикацией дальнейших документов Банка России.
Компания «МинпромХелп» работает с российскими ИТ-компаниями и производителями по вопросам подтверждения российского происхождения продуктов, включения программного обеспечения в профильные реестры и оформления программно-аппаратных комплексов. Если будущий сервис на базе цифрового рубля является частью российского ПО или ПАК, важно заранее разделить требования платежной инфраструктуры, реестра Минцифры и реестра Минпромторга — это три разных направления регулирования.
Если вы разрабатываете российское ПО, финтех-сервис или программно-аппаратный комплекс и планируете работать с государственными и крупными корпоративными заказчиками, специалисты «МинпромХелп» помогут определить подходящую реестровую стратегию и подготовить продукт к необходимым процедурам подтверждения.
Официальные источники
- Банк России — «Платформа коммерческих смарт-контрактов в цифровых рублях: концепция Банка России», 18 июня 2026 года.
- Концепция платформы коммерческих смарт-контрактов, Банк России, 2026 год.
- Банк России — материалы по развитию финансовых технологий.
- Банк России — документы и стандарты платформы цифрового рубля.
Нужно применить это к вашей продукции?
Разберем изделие, код ОКПД2/ТН ВЭД, требования реестра, доказательную базу и подготовим понятный план действий.