Реестр токенизированных ценных бумаг: три модели учёта

Реестр, имеющий юридическую силу (registry of record), — это юридически определяющий перечень того, кому что принадлежит: реестр, который суд, регулятор или ликвидатор считает решающим при споре о праве собственности. В токенизированной структуре таким реестром является либо сама ончейн-запись — если закон признаёт реестры на основе DLT, — либо офчейн- или гибридный реестр, который ончейн-токены лишь отражают. Какой из них имеет приоритет, — вопрос юрисдикции и документации, а не технологических предпочтений. Ошибка здесь не ухудшает пользовательский опыт: она ставит под сомнение исполнимость позиции каждого инвестора.

Почему вопрос о реестре — несущий

Большинство обсуждений токенизации начинаются с токена. Комплаенс-специалистам и юристам стоит начинать уровнем ниже: если право собственности оспаривается, какую запись признаёт закон?

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

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

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

Три модели реестра

Работающие сегодня токенизированные структуры решают вопрос о реестре одним из трёх способов.

Отсюда два вывода. Во-первых, спор «ончейн против офчейн» по большей части — шум. Все три модели легитимны; они обслуживают разные юрисдикции и типы инструментов. Нелегитимна неопределённость: документы предложения, из которых следует, что токен и есть ценная бумага, тогда как реестр участников SPV говорит иное, и нет никакого письменного правила о том, какая запись имеет приоритет.

Во-вторых, настоящий реестр проверяется тем, как он обрабатывает расхождения. Ключи теряются, переводы совершаются под принуждением, суды выносят решения. Реестр, который не может выразить «этот перевод отменён» или «этот держатель заменён его наследниками», — не реестр, а кэш. Это одна из областей, где юридическую структуру и архитектуру платформы нужно проектировать вместе: механизмы исправления должны существовать и в юридических документах, и в программном обеспечении.

Что требуется от реестра, который выдержит проверку

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

• Записи, привязанные к личности. Каждая запись реестра соответствует верифицированному физическому или юридическому лицу, а не адресу кошелька. Адреса меняются, компрометируются и наследуются; право собственности принадлежит лицам. Соответствие между личностью и адресом само является частью реестра.
• Обработка корпоративных действий. Распределения, дробления, требования о взносах капитала, погашения, конвертации и права голоса должны рассчитываться на основе реестра на установленную дату фиксации — а значит, нужно хранить историческое состояние, а не только текущие остатки.
• Неизменяемый аудиторский след. Каждое изменение реестра — кто его внёс, на каком основании и по какому документу — фиксируется так, что любое вмешательство обнаруживается. При инспекции история реестра важна не меньше, чем его текущее состояние.
• Возможность исполнять судебные решения и принудительные переводы. Реестр, который не может исполнить перевод по решению суда, заморозить позицию под санкциями или заменить запись умершего держателя, не может служить юридическим реестром. Эта возможность должна быть разграничена по правам доступа, журналироваться и подчиняться правилам управления — но она должна существовать.
• Резервное копирование и восстановление. Запись, имеющая юридическую силу, должна переживать отказ инфраструктуры с заданными целевыми показателями восстановления, а процедура восстановления должна быть задокументирована и протестирована. Невосстановимый реестр — это структурный дефолт, который ждёт своего триггера.

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

Допустимость инвестора — это данные реестра, а не отдельная таблица

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

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

Работа в нескольких юрисдикциях повышает планку: инвестор, допустимый на момент подписки, может стать недопустимым после обновления санкционных списков или смены резидентства, и реестр должен показать это до следующего корпоративного действия или перевода, а не после. Автоматизация обновления KYC/AML и санкционного скрининга как потоков данных в реестр делает контроль переводов в нескольких юрисдикциях работоспособным — и именно это регуляторы всё чаще ожидают видеть подтверждённым доказательствами, а не декларациями. Как эти контроли распространяются на вторичные переводы, описано в нашем подходе к контролируемым процессам перевода и стратегии ликвидности.

Почему регулируемые организации хотят контролировать уровень реестра

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

Владение исходным кодом. Если реестр работает на SaaS поставщика, а поставщик обанкротится, будет поглощён или уйдёт с рынка, что станет с записью, имеющей юридическую силу? Экспорт данных — не ответ: выгруженный CSV без программного обеспечения, которое применяет ограничения на перевод, рассчитывает корпоративные действия и ведёт аудиторский след, не является работающим реестром.

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

Контроль развёртывания и локализация данных. Данные реестра — это персональные данные инвесторов плюс данные о праве собственности, то есть именно те категории, которые чаще всего подпадают под правила защиты и локализации данных в юрисдикциях, где работают регулируемые организации. Размещение реестра on-premise или в собственном облачном периметре оператора сохраняет данные реестра в регионе, оставляет управление доступом внутри регулируемой организации и даёт проверяющим систему, которую организация действительно может подтвердить и контролировать. Общие аргументы в пользу развёртывания под контролем клиента — включая то, что означает и чего не означает «on-premise», — изложены в нашем обзоре on-premise платформы токенизации.

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

Одна система учёта или пять поставщиков и проблема сверки

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

Цепочка из нескольких поставщиков может работать. Но каждый стык — место, где записи могут разойтись: KYC-система помечает инвестора как недопустимого, а реестр всё ещё показывает его держателем; платёжная инфраструктура показывает платёж, который реестр не отразил; баланс токенов и запись реестра расходятся, и ни одна система не уполномочена исправить другую. В обычном программном стеке это баги. В стеке реестра, имеющего юридическую силу, разрывы сверки — это юридические разрывы: периоды, когда запись, имеющая юридическую силу, возможно, неверна и заведомо не проверена.

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

Именно такую архитектуру Asset Haus разворачивает как инфраструктуру токенизации для частных рынков капитала: реестр, комплаенс-данные и контроль переводов в одной системе под контролем клиента, а юридическая настройка координируется с квалифицированными юристами юрисдикции выпуска. В 32 структурированных сделках с объёмом $200M+, проведённым при содействии Asset Haus, в 9+ юрисдикциях решение о реестре, имеющем юридическую силу, было частью работы по структурированию с первого дня, а не исправлением после запуска. Примеры того, как это решение принимается для разных классов активов и юрисдикций, — в наших кейсах.

Частые вопросы

Что такое реестр, имеющий юридическую силу, в токенизации?

Это юридически определяющая запись о том, кому принадлежат токенизированные ценные бумаги, — реестр, который суд или регулятор считает решающим. В зависимости от юрисдикции и структуры это либо сам ончейн-реестр (если закон признаёт DLT-реестры), либо традиционный офчейн-реестр, который отражают токены, либо гибрид с задокументированными правилами приоритета.

Является ли блокчейн юридической записью о праве собственности?

Только если это установлено законом и выпуск структурирован соответствующим образом — например, ценные бумаги на основе реестра по ст. 973d и след. Обязательственного закона Швейцарии или выпуск с использованием DLT по законам Люксембурга о блокчейне. В большинстве других структур, включая распространённую в США модель с трансфер-агентом, юридическую силу имеет офчейн-реестр, а токены служат его синхронизированным представлением. Ответ зависит от юрисдикции, и его должен подтвердить квалифицированный юрист.

Что происходит, если балансы токенов и реестр расходятся?

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

Что будет, если поставщик платформы прекратит работу?

Если реестр работает на SaaS, размещённом у поставщика, без прав на исходный код, запись о праве собственности, имеющая юридическую силу, рискует остаться «сиротой»: одна лишь выгрузка данных не сохраняет работающий реестр. Поэтому регулируемые организации всё чаще требуют владения исходным кодом и развёртывания on-premise или в облаке клиента для уровня реестра, с задокументированными процедурами непрерывности и упорядоченного прекращения работы.

Может ли суд обязать провести перевод в токенизированном реестре?

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

---

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