MiFID II y tokenización: clasificación, servicios y límites

La tokenización permite representar instrumentos financieros mediante un registro digital. Las acciones, los bonos y otros productos mantienen derechos y obligaciones que determinan cómo pueden emitirse y comercializarse. En la Unión Europea, esa naturaleza jurídica es el punto de partida para entender qué normativa se aplica a cada token.

MiFID II forma parte del marco que regula los instrumentos financieros y los servicios relacionados con ellos. MiCA, por su parte, excluye de su ámbito los criptoactivos que tienen esa consideración. Comprender la relación entre ambos marcos permite definir la emisión y los servicios de la plataforma antes de trasladar sus requisitos al desarrollo técnico.

Qué determina la clasificación jurídica de un token

Tokenizar un derecho cambia su representación técnica, pero no elimina su naturaleza jurídica. El artículo 2 de la Ley 6/2023 incluye instrumentos financieros emitidos, registrados, transferidos o almacenados mediante DLT. Acciones, deuda, participaciones en vehículos de inversión y derivados requieren analizar los derechos concretos.

Llamar utility token a un activo no determina su clasificación. Tampoco toda expectativa de subida de precio convierte automáticamente un token en valor negociable. El análisis debe documentar características, negociabilidad, derechos y estructura de la oferta con arreglo al marco aplicable.

Cómo se relacionan MiFID II y MiCA

El artículo 2 de MiCA excluye los criptoactivos que sean instrumentos financieros. Eso evita tratar el mismo instrumento como si se pudiera elegir libremente entre MiCA y MiFID II. La exclusión de MiCA no supone una exención de otras normas.

MiFID II regula servicios y actividades de inversión y aspectos de los mercados. El régimen de folletos, la normativa societaria y otras obligaciones tienen sus propios ámbitos. Por eso decir que una emisión cumple MiFID II no basta para describir todos sus requisitos.

Separar instrumento, servicios y canal

• Instrumento: qué derecho recibe el titular y frente a quién puede exigirlo.
• Servicios: quién coloca, asesora, ejecuta órdenes, custodia o administra.
• Oferta: a quién se dirige, en qué países y con qué documentación.
• Negociación: dónde pueden transferirse posiciones y bajo qué permisos.

Esta separación permite asignar responsables y detectar actividades que pueden requerir autorización. El análisis cambia si una aplicación solo muestra información o si recibe órdenes, recomienda productos o controla activos de clientes.

De los requisitos al software

Las restricciones de transferencia, comprobaciones de identidad y registros de operaciones deben derivarse del modelo jurídico. No basta con escoger una biblioteca que se describa como compliant. Define qué ocurre cuando cambia la elegibilidad de un inversor, vence una comprobación o se solicita una recuperación.

Prueba tanto operaciones permitidas como rechazadas. Conserva evidencia de configuración, versión y permisos, además de procedimientos para corregir errores. La auditoría del código revisa su alcance técnico; no autoriza el servicio ni valida la oferta.

Cómo documentar la clasificación

El análisis empieza con documentos que permitan reconstruir la relación entre emisor y titular: condiciones de emisión, estatutos cuando proceda, derechos de cobro o voto, vencimiento, reglas de transmisión y compromisos comerciales. El código ayuda a entender la operativa, pero la descripción del contrato no agota el contenido jurídico del producto.

El anexo I de MiFID II distingue categorías de instrumentos y servicios. Una revisión debe identificar la categoría concreta que se está evaluando, en lugar de utilizar «security» como respuesta suficiente. Si se concluye que el activo no es un instrumento financiero, todavía hace falta examinar si entra en MiCA, alguna exclusión o un régimen diferente.

Como método de trabajo, conviene registrar qué característica sostiene cada conclusión y qué cambio obligaría a revisarla. Añadir derechos económicos, alterar el régimen de reembolso o permitir nuevas formas de transmisión puede modificar el análisis. Esa revisión no debería quedar oculta dentro de una actualización de software.

Ejemplo de una plataforma con funciones diferentes

Imaginemos un proyecto que muestra información sobre una emisión, permite enviar una solicitud de suscripción y ofrece un espacio donde titulares publican su interés en vender. Es un ejemplo de análisis de alcance, no una clasificación jurídica cerrada.

La ficha informativa, la recepción de solicitudes y el encuentro entre compradores y vendedores deben examinarse por separado. Hay que determinar qué hace realmente cada componente, quién toma decisiones, cómo se ejecutan las operaciones y qué entidad presta el servicio. La etiqueta «plataforma tecnológica» no resuelve esas preguntas.

Para el equipo de desarrollo, el resultado debe convertirse en una especificación: qué acciones permite la interfaz, cuáles requieren intervención de una entidad habilitada y cuáles quedan fuera del alcance. Es más verificable establecer que el sistema transmite una instrucción a un participante identificado que prometer que una aplicación es «MiFID compliant» sin explicar su operación.

Evidencia que debería conservar el proyecto

La documentación útil conecta requisitos con comportamiento: versión de las condiciones aceptadas, fecha de una comprobación, entidad que autorizó una operación y resultado registrado. Si una transferencia se rechaza por una restricción, el sistema debe permitir investigar qué regla estaba vigente sin exponer innecesariamente datos personales.

También conviene definir cómo se gestionan reclamaciones, rectificaciones y cambios materiales. La evidencia de una prueba demuestra lo ocurrido bajo una configuración concreta; no garantiza que toda configuración futura conserve el mismo encaje. Por eso la revisión jurídica, la gestión de cambios y las pruebas de regresión necesitan puntos de contacto explícitos.

Qué aporta el régimen piloto DLT

El régimen piloto habilita un marco específico para determinadas infraestructuras de negociación y liquidación, con permisos y condiciones. No transforma cualquier dApp en un centro autorizado ni debe confundirse con la simple emisión de un token.

Antes del desarrollo, reúne un mapa de actividades, documentación de derechos y responsables. Contrasta su encaje con las orientaciones publicadas por la CNMV y asesoramiento adecuado a la operación. Así la tecnología implementa requisitos definidos y verificables.

Para concretar el diseño, consulta ERIR en España: funciones y requisitos para valores tokenizados y cómo se implementa un proyecto de tokenización.