Cómo debe prepararse un banco para la tokenización de activos

Blockchain Arbitration & Commerce Society (BACS) · nº 11 · 8 de octubre de 2026

Las entidades españolas están pasando de la prueba de concepto al producto. Y en casi todos los proyectos que hemos visto, el trabajo jurídico llega tarde: se elige la tecnología, se diseña la operativa y después se pregunta si aquello es legal.

El orden correcto es el inverso, porque hay tres decisiones jurídicas que condicionan la arquitectura técnica y no al revés.

La primera pregunta no es tecnológica

Antes de elegir red, custodio o proveedor, hay que responder qué es el token. De esa calificación dependen la licencia, el supervisor, el folleto, las normas de custodia y el régimen de comercialización.

Si el token representa un instrumento financiero —acciones, bonos, participaciones de fondos—, queda fuera de MiCA y entra en el perímetro de MiFID II y, en su caso, del régimen piloto de infraestructuras basadas en tecnología de registro descentralizado, el Reglamento (UE) 2022/858. Si es un token de dinero electrónico o un token referenciado a activos, es MiCA. Y si no es ninguna de las dos cosas, el análisis se desplaza al Derecho nacional, que es donde las respuestas dejan de estar armonizadas.

MiCA se aplica plenamente desde 2024 y en España el periodo transitorio para los proveedores que ya operaban terminó el 1 de julio de este año. La CNMV ha publicado criterios interpretativos y remite al registro que ESMA mantiene de proveedores autorizados.

Conviene decirlo sin rodeos: resolver esta calificación cuando el producto ya está diseñado es la forma más habitual de perder un año de trabajo.

La custodia es donde está el riesgo real

Un banco que guarda criptoactivos por cuenta de clientes hace algo que se parece a la custodia pero no es la custodia para la que se construyeron sus sistemas. El artículo 75 de MiCA lo ordena con bastante precisión, y merece leerse entero porque casi todo lo que importa está ahí.

Exige un contrato de custodia que identifique a las partes y describa el servicio, la política de custodia, los métodos de comunicación y autenticación del cliente, los sistemas de seguridad, las comisiones y la ley aplicable.

Exige un registro de posiciones abierto a nombre de cada cliente, en el que consten sus derechos sobre los criptoactivos y se anoten los movimientos ordenados por él lo antes posible, de modo que todo movimiento que afecte a las tenencias tenga su correspondiente asiento.

Exige una política de custodia que garantice la salvaguarda o el control de los criptoactivos o de los medios de acceso a ellos, y que minimice el riesgo de pérdida por fraude, amenazas informáticas o negligencia.

Exige segregación, y en tres planos: jurídica respecto del patrimonio del proveedor, de modo que sus acreedores no puedan alcanzarlos en caso de insolvencia; operativa; y en la propia cadena, donde los activos de los clientes deben mantenerse separados de los propios y los medios de acceso identificados como pertenecientes a aquellos.

Y establece la responsabilidad. El proveedor responde frente a sus clientes por la pérdida de criptoactivos o de los medios de acceso cuando el incidente le sea atribuible, con un límite: el valor de mercado del activo perdido en el momento de la pérdida.

El límite del artículo 75 es lo que hay que explicar al cliente

Esa última regla tiene un reverso que conviene leer con atención, porque es el punto que ningún folleto comercial recoge.

El proveedor no responde de los incidentes que acredite que se produjeron con independencia de la prestación del servicio o de sus operaciones, como un problema de la propia cadena que no controla.

Dicho de otro modo: el banco responde de lo que controla. De lo que no controla nadie, no responde nadie. Y el perímetro de lo que nadie controla —un fallo de un puente entre cadenas, un error en un contrato inteligente de un tercero, una decisión de los validadores— no es pequeño ni teórico.

Ese riesgo residual existe, no desaparece porque el contrato no lo mencione, y la entidad tiene dos obligaciones respecto de él: informarlo con claridad y asignarlo expresamente en el contrato. Un contrato de custodia que guarda silencio sobre quién soporta la pérdida cuando falla la infraestructura no es un contrato que proteja al banco; es un contrato que traslada la discusión a un juez que no la ha pensado antes.

La tercera pieza: dónde se resuelve

Aquí es donde la práctica bancaria tradicional encaja peor.

Las condiciones generales de una entidad remiten a sus tribunales. Funciona para la relación con el cliente. No funciona para todo lo demás, que en una operación tokenizada es casi todo: el emisor puede estar en otro Estado, el proveedor de infraestructura en un tercero, el vehículo emisor en un cuarto, y el activo no está en ningún sitio concreto.

Cuando algo falla entre esos actores, determinar qué tribunal conoce y qué ley se aplica consume meses antes de entrar en el fondo. Mientras tanto, el activo se mueve.

Un convenio arbitral bien construido resuelve ese tramo: una sede, un reglamento, un árbitro que entiende la tecnología y un laudo ejecutable bajo el Convenio de Nueva York en más de ciento setenta Estados. Lo que no resuelve —y conviene saberlo antes y no después— es la ejecución material: un laudo obliga a una persona a hacer algo, pero no mueve por sí mismo un activo en cadena, ni revierte una transacción confirmada, ni alcanza a quien controla unas claves y decide no obedecer. De ahí que el diseño de la operación deba prever, desde el principio, un punto de control sobre el que la decisión pueda actuar: un depósito en garantía, una autorización multifirma, un intermediario sujeto a jurisdicción.

El convenio arbitral y la arquitectura técnica son la misma decisión tomada dos veces. Si se toman por separado, no encajan.

La prueba, que es lo que se olvida

Cuando el asunto llega a un procedimiento, la entidad tendrá que acreditar qué ocurrió: qué instrucción dio el cliente, cuándo, desde dónde, quién tenía los medios de acceso y en qué estado estaba el registro.

El registro de posiciones del artículo 75 no es solo una obligación regulatoria. Es, en la práctica, el principal activo probatorio del banco. Conviene diseñarlo pensando en que algún día habrá que exhibirlo ante un tercero que no conoce la tecnología, y no solo en que satisfaga al supervisor.

Seis decisiones antes del primer piloto

1. Calificar el token antes de elegir la tecnología, y dejar la calificación por escrito con su razonamiento.

2. Decidir si la custodia se presta o se externaliza, y si se externaliza, revisar qué dice el contrato del proveedor sobre el artículo 75 y sobre el riesgo que excluye.

3. Documentar el perímetro de lo no controlado y asignarlo expresamente en la contratación con clientes.

4. Redactar el convenio arbitral junto con la arquitectura técnica, no después, y comprobar que existe al menos un punto sobre el que una decisión pueda actuar.

5. Diseñar el registro de posiciones como prueba, no solo como cumplimiento.

6. Definir quién, dentro de la entidad, responde de todo lo anterior. En la mayoría de los proyectos que fracasan, la respuesta a esta última pregunta era «nadie en concreto».

BACS es una institución arbitral sin ánimo de lucro inscrita en el Registro de Transparencia de la Unión Europea (REG 9106897105368-14) y opera una Corte de Arbitraje especializada en activos digitales. Este artículo tiene finalidad divulgativa y no constituye asesoramiento jurídico.

Las referencias al artículo 75 siguen el texto del Reglamento (UE) 2023/1114 tal como lo recoge el código normativo interactivo de ESMA.