MiCA al detalle: tu libro blanco sobre criptomonedas no puede limitarse a ser un Gitbook o un PDF

«MiCA Decoded» es una serie semanal de 12 artículos para Bitcoin.com News, escrita conjuntamente por los cofundadores y directores generales de LegalBison: Aaron Glauberman, Viktor Juskin y Sabir Alijev. LegalBison asesora a empresas de criptomonedas y FinTech sobre licencias MiCA, solicitudes de CASP y VASP, y estructuración normativa en toda Europa y más allá.

En el marco de la MiCA, un libro blanco es un instrumento de divulgación legal obligatorio. Su analogía más cercana en las finanzas tradicionales es un folleto de valores, no un documento de marketing. La normativa prescribe quién debe prepararlo, en qué formato, qué identificadores debe contener, a qué validación automatizada está sujeto y que la responsabilidad recae sobre una persona concreta designada.

Cometer un error en cualquiera de esos elementos significa que el documento no existe a ojos de los reguladores europeos, independientemente de lo bien redactado que esté. Esta sexta entrega de «MiCA Decoded» desentraña, paso a paso, lo que eso significa realmente.

El mito: un libro blanco de MiCA es solo un GitBook o un PDF

Un libro blanco MiCA tiene el peso de una presentación reglamentaria formal. El Reglamento de Ejecución (UE) 2024/2984 de la Comisión, que regula los formularios, formatos y plantillas de los libros blancos de criptoactivos, exige que el documento se elabore en un formato digital estructurado diseñado de tal manera que la AEVM y las autoridades nacionales competentes de todos los Estados miembros de la UE puedan realizar un análisis automatizado idéntico de cada presentación, independientemente de quién la haya presentado o dónde.

El propósito legal de esa elección de diseño es más importante que los detalles técnicos. MiCA es un reglamento del mercado único, y la comparabilidad entre las presentaciones es una herramienta fundamental para su aplicación. Un libro blanco que no pueda ser leído por la misma máquina que cualquier otro libro blanco presentado en Europa no cumple con la normativa, independientemente de lo que diga su contenido. La AEVM publicó la taxonomía requerida (el marco estructurado que define lo que debe contener un libro blanco conforme) el 5 de agosto de 2025. Las normas se aplicarán a partir del 23 de diciembre de 2025. Las obligaciones de divulgación varían en función del tipo de criptoactivo de que se trate. La MiCA establece tres categorías distintas, cada una con su propia plantilla de libro blanco y requisitos de campos:

La categoría determina no solo el contenido del libro blanco, sino todo el proceso legal para su presentación. Un proyecto no puede elegir qué categoría se aplica en función de sus preferencias. Las características del activo lo determinan, y las obligaciones de preparación se derivan de ahí.

¿Quién asume la obligación legal y la responsabilidad?

Para la gran mayoría de los tokens del mercado (clasificados como criptoactivos «Otros», u OTHR), la obligación no recae automáticamente en la entidad que creó el token. Para estos activos, la MiCA impone la obligación al oferente o a la persona que solicita la admisión a cotización, que son roles definidos que pueden coincidir o no con el emisor original.

Esta distinción tiene consecuencias reales. Un proyecto que entre en la categoría OTHR, lanzado desde las Islas Vírgenes Británicas, las Islas Caimán o cualquier otra jurisdicción offshore, puede ser el oferente en virtud de la MiCA y asumir directamente la obligación del libro blanco, sin necesidad de trasladar su sede social a Europa.

(Nota: Esta flexibilidad estructural se aplica estrictamente a los tokens OTHR. En el caso de los tokens referenciados a activos y los tokens de dinero electrónico, la obligación legal y la responsabilidad civil estricta por el libro blanco recaen íntegramente en el emisor autorizado de la UE y no pueden delegarse). Como analizamos en la segunda entrega de esta serie, los registros de la AEVM confirman que esto ya es una práctica habitual: la mayoría de las solicitudes de registro de tokens independientes provienen de entidades con sede fuera de la UE.

Un CASP que opere una plataforma de negociación también puede asumir la obligación del libro blanco, ya sea por iniciativa propia o mediante un acuerdo escrito con el equipo del proyecto. Esto no es una laguna jurídica ni una conveniencia administrativa. Cuando un CASP presenta una solicitud, asume la responsabilidad legal de la exactitud y la integridad de la información divulgada. Si el libro blanco contiene información engañosa o incumple las normas reglamentarias, la responsabilidad recae en quien lo haya presentado.

La persona que aprueba el libro blanco no puede delegar esa responsabilidad en un proveedor de software, un integrador técnico o un bufete de abogados. La revisión jurídica del contenido y la validez técnica son dos obligaciones de cumplimiento distintas, y ambas recaen en el oferente. Este es el punto que la mayoría de los proyectos subestiman.

Dos códigos que deben existir antes de iniciar la presentación

Dos identificadores obligatorios son requisitos previos para cualquier libro blanco que cumpla con la normativa. Ambos se derivan de normas internacionales anteriores a la MiCA. La normativa no los creó, sino que los hizo obligatorios.

El primero es el Identificador de Entidad Jurídica (LEI), un código ISO 17442 asignado a las entidades jurídicas y mantenido en la base de datos Global LEI administrada por GLEIF. La obligación de su uso abarca múltiples normas reguladoras: mientras que el artículo 14 de las normas técnicas de regulación (RTS) sobre el mantenimiento de registros (Reglamento Delegado de la Comisión UE 2025/1140) impone requisitos de LEI a los CASP para sus clientes, el artículo 3 de la RTS de clasificación de los libros blancos (Reglamento Delegado (UE) 2025/421 de la Comisión) exige estrictamente que todos los elaboradores de libros blancos identifiquen su propia entidad jurídica con un código LEI válido. Para cualquier entidad que aún no disponga de uno, el proceso de solicitud del LEI debe completarse antes de que comience la elaboración del libro blanco.

El segundo es el Identificador de Token Digital (DTI), un código ISO 24165 que identifica el propio criptoactivo, mantenido en el registro DTIF. El artículo 15 de la RTS sobre mantenimiento de registros y el artículo 3 de la RTS de clasificación de libros blancos (Reglamento Delegado (UE) 2025/421 de la Comisión) exigen su uso. El punto clave para cualquier proyecto que lance un nuevo token: si el DTI aún no existe en el registro, alguien debe solicitar su creación antes de que se pueda presentar el libro blanco. Cuando un CASP presenta una solicitud para un activo sin emisor centralizado y sin libro blanco existente, la plataforma es responsable de recuperar o solicitar el DTI directamente al DTIF.

Fuente: el Registro DTIF de criptoactivos Un libro blanco que no contenga un LEI y un DTI válidos no supera la validación automática antes de que lo revise un revisor humano. Los proyectos que lleguen a la fase de presentación sin ambos códigos se enfrentan a un reinicio completo.

La puerta de acceso automatizada y su implicación jurídica

Ningún humano de una autoridad nacional competente revisa un libro blanco que no supere sus comprobaciones automatizadas. La taxonomía de la AEVM define 257 comprobaciones de existencia (que verifican que los campos obligatorios estén presentes) y 223 comprobaciones de valor (que verifican que el contenido de los campos sea válido). Una presentación que no supere una comprobación calificada con la gravedad «Error» es técnicamente inválida. El documento no sigue adelante.

La implicación jurídica de esa arquitectura es directa: la validez técnica y la exactitud del contenido son responsabilidad del oferente por igual. Una divulgación legal perfectamente redactada pero con una estructura incorrecta no se acepta. Un archivo estructuralmente válido con contenido engañoso tampoco se acepta; simplemente se rechaza en una fase diferente y con consecuencias diferentes.

Los proyectos que ofrecen tokens en varios Estados miembros de la UE se enfrentan a una capa adicional. Cada versión lingüística del libro blanco requiere su propio archivo estructurado por separado. Todas las versiones lingüísticas deben ser internamente coherentes y no solo traducidas, sino organizadas de forma idéntica a nivel de campo. Una traducción que no refleje la estructura del original es técnicamente no conforme, independientemente de su precisión lingüística.

La divulgación de información sobre sostenibilidad añade una restricción más. La taxonomía exige unidades de medida específicas para el consumo de energía y las emisiones de CO2: kWh y tCO2, respectivamente. Se trata de requisitos legales de divulgación, no de informes medioambientales opcionales. Presentar los datos con unidades diferentes u omitir los campos provoca un fallo de validación.

El patrón en todos estos requisitos es el mismo: el libro blanco es una presentación legal con normas aplicadas automáticamente. Los proyectos que lo aborden como un ejercicio de redacción de documentos, en lugar de como un proceso de cumplimiento con requisitos previos estructurados y controles automatizados, se encontrarán con esa aplicación antes de llegar a un regulador humano.

Qué significa esto en la práctica

La concepción popular del libro blanco de criptomonedas como un argumento narrativo (algo escrito para persuadir más que para divulgar) describe un tipo de documento que la MiCA ha sustituido por algo categóricamente diferente.

El libro blanco de la MiCA es un instrumento legal con contenido prescrito, identificadores obligatorios, un formato estructurado diseñado para la comparabilidad transfronteriza automatizada y responsabilidad personal nominal atribuida a quien lo firme. La puerta de entrada al mercado europeo de criptomonedas pasa por él. Los proyectos que entienden la presentación por lo que es legalmente, en lugar de por lo que el término sugería históricamente, son los que no son rechazados en el control automatizado.

Conclusiones clave:

• El libro blanco no es un documento de marketing. La MiCA ha redefinido el término. El equivalente más cercano en las finanzas tradicionales es un folleto de valores, y debe tratarse con el mismo peso legal.
• Tres categorías de activos, tres vías diferentes. OTHR, ART y EMT tienen cada uno requisitos distintos para el libro blanco y diferentes requisitos previos de autorización. Las características del activo determinan qué categoría se aplica; el proyecto no elige.
• La responsabilidad recae en el solicitante, pero las normas dependen del activo. Para la gran mayoría de los tokens (OTHR), la obligación legal recae en el oferente o en la persona que solicita la admisión a cotización, no necesariamente en el creador original del token. Cuando un CASP (como un operador de plataforma de negociación) acepta preparar y publicar un libro blanco en nombre de un proyecto OTHR, asume importantes obligaciones reglamentarias, pero no asume la responsabilidad en su totalidad. En virtud del artículo 14, apartado 3, de la MiCA, la persona original que solicita la admisión a cotización sigue siendo legalmente responsable si proporciona información incompleta, desleal, poco clara o engañosa al CASP. Se puede externalizar el papeleo, pero no se puede externalizar por completo la responsabilidad.
• En el caso de los tokens referenciados a activos (ART) y los tokens de dinero electrónico (EMT), la responsabilidad civil estricta por el libro blanco no recae únicamente en el emisor autorizado como entidad corporativa, sino que se extiende explícitamente a los miembros de su órgano de administración, dirección o supervisión. Cualquier intento contractual de limitar o excluir esta responsabilidad es nulo desde el punto de vista jurídico.
• El LEI y el DTI son requisitos previos. Ambos identificadores deben estar disponibles antes de que comience la preparación del libro blanco. Si no existe un DTI para el activo, debe solicitarse al registro DTIF antes de que se avance en nada más.
• La validación automatizada es el primer filtro. Se ejecutan 257 comprobaciones de existencia y 223 comprobaciones de valores antes de que ningún humano revise el archivo. Un documento que no supere una comprobación de nivel de error no llega al regulador.
• Las presentaciones multilingües conllevan una obligación técnica oculta. Cada versión lingüística requiere su propio archivo estructurado por separado, organizado de forma idéntica al original. Una traducción que no coincida con la estructura de origen a nivel de campo no cumple con los requisitos.
• La exactitud del contenido y la validez técnica son dos obligaciones distintas. La revisión jurídica cubre la primera. La estructuración técnica cubre la segunda. Ambas recaen en el oferente, y ninguna sustituye a la otra.

Este artículo se basa en un estudio realizado por LegalBison en abril de 2026. El contenido tiene fines meramente informativos y no constituye asesoramiento jurídico.