MiCA разъясняем: ваша криптовалютная техническая документация не может быть просто Gitbook или PDF-файлом

«MiCA Decoded» — это еженедельная серия из 12 статей для Bitcoin.com News, написанная в соавторстве соучредителями и управляющими директорами LegalBison: Аароном Глауберманом, Виктором Юскиным и Сабиром Алиевым. LegalBison консультирует крипто- и финтех-компании по вопросам лицензирования MiCA, подачи заявок на CASP и VASP, а также по вопросам регуляторной структуры в Европе и за ее пределами.

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

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

В шестой части серии «MiCA Decoded» мы пошагово разберем, что это на самом деле означает.

Миф: белая книга MiCA — это просто GitBook или PDF

Белая книга MiCA имеет вес официального регуляторного документа.

Исполнительный регламент Комиссии (ЕС) 2024/2984, который регулирует формы, форматы и шаблоны белых книг по криптоактивам, требует, чтобы документ был подготовлен в структурированном цифровом формате, разработанном таким образом, чтобы ESMA и национальные компетентные органы во всех государствах-членах ЕС могли проводить идентичный автоматизированный анализ каждого представленного документа, независимо от того, кто и где его подал.

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

Белая книга, которую нельзя прочитать с помощью той же машины, что и все другие белые книги, поданные в Европе, не соответствует требованиям, независимо от ее содержания. ESMA опубликовала требуемую таксономию (структурированную систему, определяющую, что должна содержать соответствующая требованиям белая книга) 5 августа 2025 года. Правила вступают в силу 23 декабря 2025 года.

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

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

Кто несет юридические обязательства — и ответственность

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

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

(Примечание: эта структурная гибкость строго применяется к токенам OTHR. В отношении токенов, привязанных к активам (Asset-Referenced Tokens), и токенов электронных денег (E-Money Tokens) юридическая обязанность и строгая гражданско-правовая ответственность за белую книгу полностью лежат на уполномоченном эмитенте из ЕС и не могут быть делегированы).

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

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

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

Два кода, которые должны существовать до начала подачи документов

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

Первый — это идентификатор юридического лица (LEI), код ISO 17442, присваиваемый юридическим лицам и хранящийся в глобальной базе данных LEI, управляемой GLEIF. Требование его использования охватывает несколько нормативных стандартов: в то время как статья 14 RTS по ведению учета (Делегированный регламент Комиссии ЕС 2025/1140) налагает требования LEI на CASP в отношении их клиентов, статья 3 RTS по классификации белых книг (Делегированный регламент Комиссии ЕС 2025/421) строго предписывает, что все составители белых книг должны идентифицировать свое юридическое лицо с помощью действительного кода LEI. Любая организация, еще не имеющая такого кода, должна пройти процедуру подачи заявки на LEI до начала подготовки белой книги.

Второй — это идентификатор цифрового токена (DTI), код ISO 24165, который идентифицирует сам криптоактив и хранится в реестре DTIF. Его использование требуется в соответствии со статьёй 15 RTS по ведению учёта и статьёй 3 RTS по классификации белых книг (Делегированный регламент Комиссии ЕС 2025/421). Ключевой момент для любого проекта, запускающего новый токен: если DTI еще не существует в реестре, кто-то должен запросить его создание, прежде чем можно будет подать белую книгу. В случае, если CASP подает заявку на актив без централизованного эмитента и без существующей белой книги, платформа несет ответственность за получение или запрос DTI непосредственно из DTIF.

Источник: Реестр криптоактивов DTIF

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

Автоматический шлагбаум и его юридическое значение

Ни один сотрудник национального компетентного органа не рассматривает белую книгу, которая не прошла автоматическую проверку. Таксономия ESMA определяет 257 проверок наличия (проверка наличия обязательных полей) и 223 проверки значений (проверка достоверности содержимого полей). Заявка, не прошедшая проверку с оценкой серьезности «Ошибка», технически недействительна. Документ не проходит дальше.

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

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

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

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

Что это означает на практике

Распространенное представление о крипто-белой книге как о повествовательном питче (чем-то, написанном скорее для убеждения, чем для раскрытия информации) описывает тип документа, который MiCA заменила на нечто категорически иное.

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

Ключевые выводы:

• Белая книга — это не маркетинговый документ. MiCA переопределила этот термин. Ближайшим эквивалентом в традиционных финансах является проспект ценных бумаг, и к ней следует относиться с той же юридической значимостью.
• Три категории активов, три разных пути. К OTHR, ART и EMT предъявляются разные требования к белой книге и разные условия для получения разрешения. Характеристики актива определяют, к какой категории он относится, а не проект.
• Ответственность лежит на подателе, но правила зависят от актива. Для подавляющего большинства токенов (OTHR) юридическая обязанность лежит на оференте или лице, обращающемся за допуском к торговле, а не обязательно на первоначальном создателе токена. Когда CASP (например, оператор торговой платформы) соглашается подготовить и опубликовать белую книгу от имени проекта OTHR, он берет на себя значительные регуляторные обязанности, но не принимает на себя полную ответственность. Согласно статье 14(3) MiCA, первоначальное лицо, обратившееся с просьбой о допуске к торговле, остается юридически ответственным, если оно предоставило CASP неполную, недобросовестную, неясную или вводящую в заблуждение информацию. Вы можете передать оформление документов на аутсорсинг, но не можете полностью передать ответственность.
• В случае токенов, привязанных к активам (ART), и токенов электронных денег (EMT) строгая гражданско-правовая ответственность за белую книгу не лежит исключительно на уполномоченном эмитенте как юридическом лице; она явно распространяется на членов его административного, управленческого или надзорного органа. Любая договорная попытка ограничить или исключить эту ответственность является юридически недействительной.
• LEI и DTI являются обязательными условиями. Оба идентификатора должны быть готовы до начала подготовки белой книги. Если для актива не существует DTI, его необходимо запросить в реестре DTIF, прежде чем приступать к дальнейшим действиям.
• Автоматическая проверка является первым контрольным механизмом. Перед тем, как файл проходит проверку человеком, выполняется 257 проверок наличия и 223 проверки значений. Документ, не прошедший проверку на уровне ошибок, не попадает к регулирующему органу.
• Многоязычные подачи несут в себе скрытое техническое обязательство. Каждая языковая версия требует своего собственного отдельно структурированного файла, организованного идентично оригиналу. Перевод, который не соответствует исходной структуре на уровне полей, является несоответствующим.
• Точность содержания и техническая достоверность — это два отдельных обязательства. Юридическая проверка охватывает первое. Техническая структуризация охватывает второе. Оба обязательства лежат на заявителе, и ни одно из них не заменяет другое.

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