Адрес-идентификатор: как норма о согласии депозитария превращается в требования к криптографии

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

 Я Михаил Кулаков, ведущий инженер-аналитик направления «Блокчейн» в компании «Диасофт». 

В этой статье разберу Федеральный закон № 282-ФЗ «О цифровых валютах и цифровых правах» с точки зрения того, кто пишет требования к системе. Какие новые роли вводит закон? Какие компоненты можно будет переиспользовать и доработать, а что необходимо проектировать с нуля? Каким должен быть модуль работы с открытыми сетями и какие 12 требований есть? В конце – чек-лист вопросов, которые важно задать себе и подрядчику до старта проекта.

Развилка, с которой начинается проект

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

Третий элемент не имеет аналога в его системе. Адрес-идентификатор — это уникальная последовательность символов, по которой ведется учет приходных и расходных операций [ст. 2 ч. 1 п. 5], и живет он в открытой сети: информационной системе, где записи подтверждают независимые узлы, а не оператор. Депозитарий не управляет ее доступностью, не влияет на скорость записи и не может отменить совершенную операцию. Отвечать перед клиентом за исполнение своих обязанностей по предоставлению доступа он при этом обязан [ст. 20 ч. 2].

Дальше развилка: что переиспользовать из существующего стека и что проектировать заново.

Что именно изменил закон

Круг допущенных лиц закрыт списком

Организацию обращения цифровых валют осуществляют только лица, названные в статьях 14–18, и клиринговые организации [ст. 1 ч. 3]. Это организатор торговли, брокер, доверительный управляющий, цифровой депозитарий и организация, осуществляющая обмен цифровых валют.

С 1 июля 2027 года резидент, не входящий в этот круг, вправе совершать сделки и операции с цифровыми валютами только через таких лиц или с ними [ст. 30 ч. 1; ст. 56 ч. 2]. Исключения перечислены там же: сделки по внешнеторговым договорам, операции с майнерами, ряд других случаев. Сам закон вступает в силу 1 сентября 2026 года [ст. 56 ч. 1].

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

Появились две роли и два реестра

Цифровой депозитарий: деятельность вправе вести организация, включенная в реестр цифровых депозитариев [ст. 17 ч. 2]. Клиента у него два вида. Депонент пользуется услугами по учету и переходу активов, получатель доступа — услугами по доступу к адресу-идентификатору [ст. 17 ч. 3]. Это разные договоры, разные права и разная механика подтверждения обладания.

Перечень услуг задан двенадцатью пунктами [ст. 17 ч. 7]. Для архитектуры важен пункт 2: создание адресов-идентификаторов и предоставление доступа к ним названы одной услугой, но двумя действиями. Оба режима владения адресом легальны с первого дня.

Организация, осуществляющая обмен цифровых валют: систематическое совершение в своих интересах, от своего имени и за свой счет сделок купли-продажи цифровых валют с лицами вне круга организаторов обращения, вне организованных торгов [ст. 18 ч. 1]. Систематичность формализована: две и более сделки в течение месяца совокупным объемом свыше 3,5 миллиона рублей [ст. 18 ч. 2]. Реестр свой [ст. 18 ч. 3]. Собственные средства некредитной организации — не менее 15 миллионов рублей [ст. 44 ч. 3]. Для депозитария размер капитала закон не называет и оставляет Банку России [ст. 43 ч. 4].

Отдельно: сделки с цифровыми валютами по внешнеторговым договорам и в целях исполнения обязательств по ним деятельностью по обмену не признаются [ст. 18 ч. 5]. Компании с внешнеэкономической деятельностью в реестр за этим не идут.

Периметр существующих участников расширился, а не переехал

Брокер, доверительный управляющий, управляющая компания, организатор торговли и оператор информационной системы работают по своим отраслевым законам с особенностями 282-ФЗ [ст. 14–16, ст. 19]. Спутник 283-ФЗ вносит изменения в пятнадцать актов, среди них 39-ФЗ, 115-ФЗ, 161-ФЗ, 325-ФЗ, 173-ФЗ и 127-ФЗ.

Банк оказывается в особом положении. Требования к капиталу и нормативу достаточности, установленные для цифрового депозитария, не распространяются на депозитарий, являющийся кредитной организацией [ст. 43 ч. 16]. Порог входа для банка ниже, объем разработки тот же.

Роли «поставщик ликвидности» в законе нет

Слово «ликвидность» в тексте не встречается ни разу. Функция при этом описана дважды. Брокер вправе оказывать услуги по поддержанию цен, спроса, предложения и объема торгов на организованных торгах в случаях и при соблюдении требований, установленных Банком России [ст. 15 ч. 3]. Та же формулировка входит в определение деятельности обменной организации [ст. 18 ч. 1].

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

Исполнение замкнуто на счета и адреса депозитария

Исполнение обязательств в цифровых валютах по сделкам брокера по поручению клиента допускается только списанием с цифровых счетов или адресов-идентификаторов, доступ к которым предоставляет цифровой депозитарий, и зачислением на такие же счета и адреса [ст. 34 ч. 4]. Для доверительного управляющего — [ст. 34 ч. 9], для сделок между резидентом и обменной организацией — [ст. 34 ч. 11].

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

Ответственность разделена по границе информационной системы

Лица, организующие обращение цифровых валют, оператор и клиринговая организация не отвечают за убытки клиентов от нарушения бесперебойности и непрерывности функционирования информационной системы, организованной не в соответствии с российским правом, включая некорректную реализацию заложенных в ней алгоритмов и возможность их изменения третьими лицами [ст. 20 ч. 1].

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

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

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

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

Почему учет дорабатывается, а работа с сетью — нет

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

Отменить операцию нельзя, можно только сделать вторую

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

Закон это признает и описывает единственный доступный сценарий. Если цифровые валюты поступили на адрес-идентификатор, но их зачисление на счет депонента не допускается по перечню оснований из статьи 31 части 5, депозитарий уведомляет депонента и переводит их обратно на адрес, с которого они пришли [ст. 31 ч. 6]. Для получателя доступа порядок жестче: депозитарий уведомляет резидента, предлагает незамедлительно вернуть средства и не дает согласия ни на какие операции с поступившим, кроме возврата [ст. 31 ч. 7].

Ошибку исправляет не отмена, а новая транзакция, у которой своя стоимость, своя очередь и своя вероятность не пройти. В требованиях это означает, что возврат — полноценный бизнес-процесс с состояниями, повторными попытками и учетом расходов, а не обработчик исключения.

Комиссия сети — это остаток на счете, который может кончиться

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

Закон завел под это отдельный счет. По цифровому счету комиссионных выплат депозитарий учитывает принадлежащие ему цифровые валюты на администрируемых им адресах, которые он использует для оплаты комиссий, предусмотренных правилами или техническими особенностями информационной системы [ст. 22 ч. 35].

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

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

Адрес не привязан к лицу по своей природе

Цифровой счет открыт конкретному лицу, и связь счета с владельцем поддерживается системой. Адрес-идентификатор такой связи не несет: закон определяет его как уникальную последовательность символов для учета приходных и расходных операций [ст. 2 ч. 1 п. 5]. Кто за ним стоит, из самого адреса не следует.

Закон решает это двумя разными способами в зависимости от режима. На адресе, который не администрируется депозитарием, обладателем признается лицо, владеющее ключом доступа к нему и вправе распоряжаться активами от своего имени [ст. 24 ч. 3]. На адресе, доступ к которому предоставляет депозитарий, обладание подтверждается выпиской депозитария по состоянию на указанные в ней день и время [ст. 24 ч. 4], а сам доступ предоставляется на основании договора о предоставлении доступа к адресу-идентификатору [ст. 24 ч. 2].

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

Отсюда же вырастает задача проверки адресов. Цифровой анализ по закону включает присвоение характеристик не только валютам и правам, но и адресам-идентификаторам, а также оценку и присвоение уровня риска операции на предмет связи с деятельностью, за которую установлена уголовная или административная ответственность [ст. 35 ч. 1]. Проверять надо строку символов, про которую по умолчанию неизвестно ничего.

Момент завершения операции определяет участник, а не закон

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

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

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

С другой, сверка количества цифровых валют и цифровых прав проводится каждый рабочий день [ст. 25 ч. 6], а при выявлении превышения депозитарий обязан списать разницу в срок не более одного рабочего дня со дня, когда превышение выявлено или должно было быть выявлено [ст. 25 ч. 7 п. 1]. До момента списания вносить записи по затронутым счетам нельзя.

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

Каким должен быть модуль работы с открытыми сетями

Двенадцать требований. К каждому — зачем оно нужно и что будет, если его нет.

1. Первая сеть одна, следующие подключаются адаптером

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

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

Закон подталкивает к тому же решению. Он оперирует адресом-идентификатором как универсальным понятием [ст. 2 ч. 1 п. 5] и нигде не привязывает его к конкретной сети или технологии. Требования к учету, сверке и цифровому анализу сформулированы одинаково для любого адреса. Система, устроенная по-другому, будет каждый раз доказывать регулятору соответствие заново для каждой сети.

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

2. Клиент либо получает адрес от оператора, либо приносит свой

Закон описывает два режима, и оба легальны. Услуги по созданию адресов-идентификаторов и по предоставлению доступа к ним перечислены как разные действия в рамках одной услуги [ст. 17 ч. 7 п. 2]. Из этого следуют два разных клиента и два разных договора: депонент пользуется услугами по учету и переходу, получатель доступа — услугами по доступу к адресу [ст. 17 ч. 3].

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

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

3. Ни одна сторона не должна подписывать операцию единолично

Здесь закон формулирует результат и оставляет способ участнику. Невозможность совершения операции с цифровыми валютами и цифровыми правами без согласия цифрового депозитария обеспечивается способом, предусмотренным условиями осуществления его деятельности [ст. 24 ч. 6]. Ни мультиподписи, ни разделения ключа, ни требований к хранилищу в тексте нет.

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

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

Когда мы проектировали этот блок, команда выбрала разделение ключа между клиентом и депозитарием с принципом, что единолично не подписывает никто. Причина в статье 20 части 2: депозитарий отвечает за убытки от неправомерного распоряжения активами клиента. Схема, где депозитарий технически способен подписать транзакцию в одиночку, делает эту ответственность безграничной и превращает компрометацию одного контура в компрометацию всех клиентских активов. Схема, где клиент подписывает в одиночку, не позволяет исполнить статью 24 части 6 и 7. Разделение долей закрывает обе стороны сразу и работает одинаково в сетях с поддержкой мультиподписи и без нее.

Отдельный слой — где физически лежат доли ключа. Закон предъявляет требования к программно-техническим средствам в целом: основной и резервный комплексы на территории Российской Федерации плюс система резервного копирования [ст. 43 ч. 6], а Банк России вправе установить требования к ним по согласованию с органом по безопасности критической информационной инфраструктуры и органом безопасности [ст. 43 ч. 7]. Практический вывод: доля ключа хранится в аппаратном модуле безопасности или защищенном хранилище секретов, процедура доступа журналируется, а восстановление после отказа отрабатывается до запуска, а не после первого инцидента.

Если этого нет, система остается работоспособной ровно до первого судебного акта в отношении клиента и до первого спора о том, кто отправил транзакцию.

4. Адрес проверяется до операции, и списки ведет оператор

Проверка адреса перед отправкой или приемом средств вырастает прямо из закона. Цифровой анализ включает присвоение характеристик цифровым валютам, цифровым правам и адресам-идентификаторам, а также оценку и присвоение уровня риска сделке или операции [ст. 35 ч. 1].

Проводить его обязаны все лица, организующие обращение цифровых валют, клиринговая организация и оператор — в отношении и активов, и адресов, с использованием которых совершается операция [ст. 35 ч. 3]. Правила цифрового анализа участник утверждает сам, они не раскрываются третьим лицам [ст. 35 ч. 6] и направляются в Банк России в течение пяти рабочих дней со дня принятия, если Банк России не установил иного [ст. 35 ч. 7].

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

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

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

5. Проверка транзакции проводится до операции, а не после

Срок в законе задан жестко. Цифровой анализ проводится до момента совершения сделки или операции, а при отсутствии фактической возможности — в срок, установленный внутренним документом участника, но не позднее трех рабочих дней с момента совершения [ст. 35 ч. 3].

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

Для исходящих операций все наоборот: проверка обязана быть синхронной, до сборки и подписания транзакции. После отправки исправить решение нельзя. Отсюда два разных процесса с разными требованиями к скорости.

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

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

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

6. Допустимость зачисления — это справочник оснований, а не эвристика

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

Среди них: валюты приобретены брокером по поручению депонента, приобретены у организации, осуществляющей обмен, получены по договору доверительного управления, получены в порядке универсального правопреемства, при разделе совместно нажитого имущества супругов, для расчетов по внешнеторговому договору, на основании судебного акта, получены в результате майнинга, получены как заем от лица, организующего обращение, получены по итогам клиринга. Отдельные пункты касаются активов, которые до зачисления уже учитывались на администрируемом депозитарием адресе, и активов, допущенных к публичному обращению на организованных торгах российского организатора торговли, с разными условиями для квалифицированного и неквалифицированного инвестора [ст. 31 ч. 5 пп. 8–10]. Четырнадцатый пункт оставляет Банку России право добавить случаи.

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

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

Практический вывод: процесс зачисления должен уметь останавливаться и ждать, а не только пропускать или отклонять. Между поступлением средств и записью по счету депонента появляется состояние, в котором активы уже в сети, но еще не в учете. Это состояние надо уметь показывать клиенту, объяснять поддержке и закрывать по таймеру.

7. Что делать с поступлением, которое нельзя зачислить

Закон описывает развилку по режиму адреса, и это два разных алгоритма.

Если валюты пришли на адрес, администрируемый депозитарием, и зачисление на счет депонента не допускается, депозитарий уведомляет депонента о поступлении и осуществляет перевод обратно на адрес, с которого валюты были зачислены, если Банк России не предусмотрел иного [ст. 31 ч. 6].

Если валюты пришли на адрес, доступ к которому депозитарий предоставил резиденту, депозитарий уведомляет резидента и предлагает незамедлительно осуществить возврат, а также не дает согласия на операции с поступившими валютами, за исключением их возврата на адрес отправителя [ст. 31 ч. 7].

Разница принципиальная. В первом случае возврат делает оператор, во втором инициатива у клиента, а оператор блокирует все направления, кроме одного. Второй сценарий прямо опирается на механизм согласия из статьи 24 части 6: без технической возможности не дать согласия исполнить норму нельзя.

Отдельно отмечу возврат как объект учета. Операция возврата сама попадает в перечень допустимых оснований для перевода на адрес вне контура депозитариев [ст. 31 ч. 8 п. 4]. Но она стоит комиссии, которую платит оператор из собственных средств, поскольку зачислить средства клиенту он не имеет права и удержать комиссию из них не может. При регулярных нежелательных поступлениях это превращается в статью расходов, которую надо мониторить.

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

8. Комиссия сети закупается, хранится и лимитируется

Закон дал комиссии отдельный счет [ст. 22 ч. 35]. Все остальное — политика участника.

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

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

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

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

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

9. Одно поручение — одна транзакция, сколько бы раз его ни повторили

Исполнение поручений депонента и получателя доступа закон называет отдельной услугой депозитария [ст. 17 ч. 7 п. 4]. Поручение приходит извне: из личного кабинета, от брокера, от доверительного управляющего, по программному интерфейсу. Канал ненадежен по определению, а последствия дубля необратимы.

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

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

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

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

10. Сверка с сетью проводится каждый рабочий день

Цифровой депозитарий обязан осуществлять сверку количества учитываемых им цифровых валют и цифровых прав [ст. 25 ч. 1]. Количество на цифровых счетах, включая счета неустановленных лиц, должно быть равно количеству на счетах номинального держателя, открытых этому депозитарию, на счетах по статье 17 части 14 и на администрируемых им адресах-идентификаторах, за исключением адресов, к которым он предоставляет доступ клиентам [ст. 25 ч. 2]. Периодичность — каждый рабочий день [ст. 25 ч. 6].

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

Если количество на счетах стало больше, чем в сети, депозитарий обязан списать разницу в порядке, предусмотренном условиями осуществления его деятельности, в срок не более одного рабочего дня со дня, когда превышение выявлено или должно было быть выявлено [ст. 25 ч. 7 п. 1]. До момента списания вносить записи по затронутым счетам нельзя, кроме записей, необходимых для самого списания. Для клиринговых и торговых счетов списание производится пропорционально учитываемым на них количествам.

Формулировка «должно было быть выявлено» — это про качество мониторинга. Срок отсчитывается не от момента, когда система заметила расхождение, а от момента, когда она обязана была его заметить. Пропущенная сверка не отодвигает дедлайн, а сокращает его.

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

11. Отказоустойчивость начинается с того, где стоят узлы

Депозитарий обязан иметь основной и резервный комплексы программно-технических средств, расположенные на территории Российской Федерации, и сформировать систему резервного копирования; средства должны соответствовать характеру и объему проводимых операций и обеспечивать бесперебойную деятельность [ст. 43 ч. 6]. Для организации, осуществляющей обмен, требования аналогичны [ст. 44 ч. 4, ч. 5].

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

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

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

12. Отчетность и доказуемость: система должна отвечать через пять лет

Депозитарий обязан хранить документы, относящиеся к ведению учета цифровых валют и цифровых прав, документы, связанные с их учетом и переходом, и информацию о совершенных операциях не менее пяти лет со дня поступления активов или совершения операции [ст. 23 ч. 11]. Отчетность предоставляется в Банк России по формам, установленным им [ст. 43 ч. 13; ст. 54 ч. 1 пп. 5, 6]. Уведомление об открытии цифрового счета иностранного номинального или иностранного уполномоченного держателя направляется не позднее двух рабочих дней после наступления события [ст. 43 ч. 14].

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

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

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

Как это выглядит целиком

Сквозной сценарий, на котором видно, где заканчивается учет и начинается сеть: клиент заводит адрес и получает на него первое зачисление.

Шаги 1–4 — привычная депозитарная работа: договор, реквизиты, запись в учете. Шаги 5–8 целиком принадлежат новому модулю, и в них нет ни одной операции, которую можно было бы отменить. Шаг 9 возвращает процесс в учетный контур и делает это ежедневно, независимо от того, были операции или нет.

Что из этого не решается покупкой ноды и парой скриптов

Развернуть узел и написать скрипт отправки транзакции — работа на несколько дней, и именно поэтому задача выглядит проще, чем она есть. Узел дает доступ к сети и не дает ничего из перечисленного выше. Он:

• не разделяет роли при подписании и не умеет не давать согласия на операцию по судебному акту [ст. 24 ч. 6, ч. 7].

• не знает оснований зачисления и не может остановить поступление, для которого основания нет [ст. 31 ч. 5].

• не сверяет состояние сети с учетом и не закрывает расхождение за один рабочий день [ст. 25 ч. 6, ч. 7].

• не ведет счет комиссионных выплат и не управляет запасом комиссии [ст. 22 ч. 35].

• не хранит основание, решение комплаенса и состав подписантов, а значит, не отвечает на вопросы регулятора через пять лет [ст. 23 ч. 11].

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

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

Восемь вопросов до старта

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

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