MiCA Decoded — это еженедельная серия из 12 статей для Bitcoin.com News, написанная в соавторстве соучредителями и управляющими директорами LegalBison: Аароном Глауберманом, Виктором Юскиным и Сабиром Алиевым. LegalBison консультирует криптовалютные и FinTech компании по вопросам лицензирования MiCA, заявок CASP и VASP, а также нормативного структурирования в Европе и за ее пределами.
Согласно MiCA, Белый список представляет собой обязательный инструмент юридического раскрытия информации. Его ближайшей аналогией в традиционных финансах является проспект ценных бумаг, а не маркетинговый документ. Регламент предписывает, кто должен его подготовить, в каком формате, какие идентификаторы он должен содержать, какой автоматической проверке подлежит и с какой ответственностью конкретного указанного лица.
Ошибка в любом из этих элементов означает, что документ не существует в глазах европейских регуляторов, независимо от того, насколько хорошо он написан.
Эта шестая часть MiCA Decoded подробно раскрывает, что это на самом деле означает, шаг за шагом.
Миф: Белый список MiCA — это просто GitBook или PDF
Белый список MiCA имеет вес формального регуляторного документа.
Имплементационный регламент Комиссии (ЕС) 2024/2984, который регулирует формы, форматы и шаблоны для белых списков криптоактивов, требует, чтобы документ был подготовлен в структурированном цифровом формате, разработанном таким образом, чтобы ESMA и национальные компетентные органы во всех государствах-членах ЕС могли проводить идентичный автоматизированный анализ каждой заявки, независимо от того, кто и где ее подал.
Юридическая цель этого выбора дизайна важнее технических деталей. MiCA — это регламент единого рынка, и сопоставимость заявок является основным инструментом правоприменения.
Белый список, который не может быть прочитан той же машиной, что и любой другой Белый список, поданный в Европе, не соответствует требованиям, независимо от того, что говорит его содержание. ESMA опубликовала требуемую таксономию (структурированную основу, определяющую, что должен содержать соответствующий Белый список) 5 августа 2025 года. Правила применяются с 23 декабря 2025 года.
Обязательства по раскрытию информации различаются в зависимости от типа вовлеченного криптоактива. MiCA выделяет три различные категории, каждая со своим шаблоном Белого списка и требованиями к полям:
| Тип актива | Кто подготавливает Белый список | Ключевая характеристика |
| OTHER (Другие криптоактивы, например, Утилитарный токен) | Оферент, лицо, добивающееся допуска к торговле, или CASP, управляющий торговой платформой | Самая широкая категория; охватывает большинство Токенов, находящихся в настоящее время на рынке |
| ART (Токены, привязанные к активам) | Уполномоченный эмитент или кредитное учреждение | Привязан к корзине активов; требуется авторизация перед выпуском |
| EMT (Токены электронных денег) | Кредитное учреждение или учреждение электронных денег | Привязка к одной валюте; требуется авторизация EMI или банковская |
Категория определяет не только содержание Белого списка, но и весь юридический путь к его подаче. Проект не может выбрать, какая категория применяется, на основе предпочтений. Характеристики актива определяют это, и обязательства по подготовке следуют из этого.
Кто несет юридическое обязательство — и ответственность
Для подавляющего большинства Токенов на рынке (классифицированных как криптоактивы «Другие», или OTHR), обязательство не автоматически возлагается на организацию, создавшую Токен. Для этих активов MiCA возлагает обязательство на оферента или лицо, добивающееся допуска к торговле, которые являются определенными ролями, которые могут совпадать или не совпадать с первоначальным эмитентом.
Это различие имеет реальные последствия. Проект, попадающий в категорию OTHR, запущенный с Британских Виргинских островов, Каймановых островов или любой другой оффшорной юрисдикции, может быть оферентом в соответствии с MiCA и нести обязательство по Белому списку напрямую, без каких-либо требований о переносе своего юридического местонахождения в Европу.
(Примечание: Эта структурная гибкость строго применяется к Токенам OTHR. Для токенов, привязанных к активам, и токенов электронных денег юридическое обязательство и строгая гражданская ответственность за Белый список полностью лежат на уполномоченном эмитенте ЕС и не могут быть делегированы).
Как мы рассмотрели во второй части этой серии, реестры 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: кВтч и tCO2 соответственно. Это юридические требования по раскрытию информации, а не необязательная экологическая отчетность. Подача с другими единицами или пропуск полей вызывает сбой проверки.
Шаблон для всех этих требований одинаков: Белый список — это юридическая заявка с машинно применяемыми стандартами. Проекты, которые подходят к этому как к упражнению по написанию документа, а не как к процессу соблюдения требований со структурированными предпосылками и автоматизированным контролем, столкнутся с этим правоприменением до того, как дойдут до человека-регулятора.
Что это означает на практике
Популярное понимание криптовалютного Белого списка как повествовательной презентации (чего-то написанного для убеждения, а не для раскрытия) описывает тип документа, который MiCA заменил чем-то категорически другим.
Белый список MiCA — это юридический инструмент с предписанным содержанием, обязательными идентификаторами, структурированным форматом, разработанным для автоматической трансграничной сопоставимости, и именной личной ответственностью, привязанной к тому, кто его подписывает. Входные ворота на европейский крипторынок проходят через него. Проекты, которые понимают заявку такой, какой она является юридически, а не такой, какой термин исторически подразумевал, — это те, кого не разворачивают при автоматической проверке.
Ключевые выводы:
- Белый список — это не маркетинговый документ. MiCA переопределила термин. Ближайший эквивалент в традиционных финансах — проспект ценных бумаг, и к нему следует относиться с той же юридической серьезностью.
- Три категории активов, три разных пути. OTHR, ART и EMT каждый несет различные требования к Белому списку и различные предпосылки для авторизации. Характеристики актива определяют, какая категория применяется, проект не выбирает.
- Ответственность следует за подающим заявку, но правила зависят от актива. Для подавляющего большинства Токенов (OTHR) юридическое обязательство принадлежит оференту или лицу, добивающемуся допуска к торговле, не обязательно первоначальному создателю Токена. Когда CASP (например, оператор торговой платформы) соглашается подготовить и опубликовать Белый список от имени проекта OTHR, он берет на себя значительные регуляторные обязанности, но не берет на себя ответственность полностью. Согласно статье 14(3) MiCA, первоначальное лицо, добивающееся допуска к торговле, остается юридически ответственным, если оно предоставляет неполную, несправедливую, неясную или Ложную информацию CASP. Вы можете передать оформление документов на аутсорсинг, но вы не можете полностью передать ответственность на аутсорсинг.
- Для токенов, привязанных к активам (ART) и токенов электронных денег (EMT), строгая гражданская ответственность за Белый список лежит не только на уполномоченном эмитенте как корпоративной структуре; она явно распространяется на членов его административного, управленческого или надзорного органа. Любая договорная попытка ограничить или исключить эту ответственность юридически недействительна.
- LEI и DTI являются предпосылками. Оба идентификатора должны быть на месте до начала подготовки Белого списка. Если DTI не существует для актива, он должен быть запрошен из реестра DTIF, прежде чем что-либо еще двинется вперед.
- Автоматическая проверка — это первый привратник. 257 проверок существования и 223 проверки значений выполняются до того, как человек просмотрит файл. Документ, который не проходит утверждение уровня ошибки, не доходит до регулятора.
- Многоязычные заявки несут скрытое техническое обязательство. Каждая языковая версия требует отдельного структурированного файла, организованного идентично оригиналу. Перевод, который не соответствует исходной структуре на уровне полей, не соответствует требованиям.
- Точность содержания и техническая валидность — это два отдельных обязательства. Юридическая проверка охватывает первое. Техническое структурирование охватывает второе. Оба лежат на оференте, и ни одно не заменяет другое.
Эта статья основана на исследовании, проведенном LegalBison в апреле 2026 года. Содержание предназначено только для информационных целей и не является юридической консультацией.
Источник: https://news.bitcoin.com/mica-decoded-your-crypto-white-paper-cant-just-be-a-gitbook-or-pdf/
