Приватная и открытая сети: как будет устроен цифровой депозитарий

Привет, Хабр!

Я Михаил Кулаков, в «Диасофт» занимаюсь развитием импортонезависимой платформы распределенных реестров Digital Q.Blockchain.

Про закон «О цифровых валютах и цифровых правах» написано уже достаточно, и подробных разборов по статьям хватает. Ограничусь рамкой: закон вступает в силу 1 сентября 2026 года, требования к предотвращению операций без добровольного согласия клиента – годом позже, и на финансовом рынке появляется новый профессиональный участник. Цифровой депозитарий ведет учет цифровых валют и цифровых прав по цифровым счетам и предоставляет доступ к адресам-идентификаторам, а работать в этом статусе можно только после включения в соответствующий реестр Банка России.

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

Цифровой депозитарий: что собой представляет

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

• С одной стороны – внутренний учет: более десяти видов цифровых счетов, ежедневная сверка остатков, обособление клиентских активов от собственных, регулярная отчётность в Банк России, пятилетнее хранение документов и информации об операциях. Это привычная депозитарная дисциплина, изложенная в новых терминах.

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

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

Технологическая основа: почему важна гибридная архитектура

Мы регулярно сталкиваемся с возражением: если активы в любом случае обращаются в открытых сетях, зачем создавать еще и приватный реестр внутри – не достаточно ли классической базы данных с интеграцией наружу?

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

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

Все перечисленные функции относятся к внутреннему контуру, и вот на этом уровне приватная сеть дает то, чего не дает реляционная СУБД, – техническую невозможность незаметно изменить запись. Различие в аргументации перед регулятором принципиально: в первом случае организация предъявляет регламент и заверение об ограничении прав доступа, во втором – криптографическую связку блоков, при которой подмена задним числом обнаруживается арифметически. На очной проверке это разные по силе аргументы.

Важно: внутренний реестр и внешние сети не конкурируют между собой, а дополняют друг друга.

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

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

Платформа Digital Q.Blockchain развивается нами именно под эту модель, и ниже я остановлюсь на тех механизмах, необходимость которых подтвердилась в реальных внедрениях.

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

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

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

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

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

Два показательных кейса

Практическую проверку этот подход уже прошел в проектах.

В работе с оператором информационной системы Мадригал блокчейн-модуль защищался на очной проверке Банка России, и 14 августа 2025 года компания получила лицензию оператора информационной системы; предметом обсуждения с регулятором стали децентрализованное хранение и хеширование данных в формате транзакций на инфраструктуре заказчика, формирование отчётности непосредственно по данным из блокчейн-сети и дополнительный шаг проверки подписи транзакции узлами сети с использованием отечественного криптопровайдера.

Задача Ozon Банка была шире – создание собственной инфраструктуры для выпуска, учета и обращения цифровых финансовых активов, включая поддержку гибридных цифровых прав, и получение статуса оператора информационной системы. Банк успешно прошел аудит Банка России и был включен в реестр операторов информационных систем, причем от старта внедрения до прохождения проверки прошло полтора месяца. Такие сроки достижимы в одном случае: когда платформа поставляется с готовым учетным контуром и отчетностью, а проект сводится к настройке под конкретную бизнес-модель.

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

Что стоит сделать до сентября

Исходя из этого, наиболее полезное, что можно сделать до сентября, – это не выбор поставщика, а проработка трех вопросов:

1. Как виды цифровых счетов ложатся на вашу учетную схему и какой их состав поддерживается на старте, а какой переносится на следующий этап.

2. Как организована ежедневная сверка внутреннего учета с внешними адресами и, что важнее, каков сценарий расхождения – кто, в какие сроки и какими проводками его устраняет.

3. Собирается ли отчетность из первичных записей в присутствии проверяющего.

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

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