Las acciones tokenizadas han dejado de ser un experimento de nicho. En marzo de 2026 la SEC aprobó el trading de valores tokenizados en Nasdaq para las acciones del Russell 1000 y los principales ETF, con los mismos derechos que el valor tradicional. El valor de las acciones tokenizadas supera ya los 2.000 millones de dólares y, según RWA.xyz, más de la mitad de su actividad se produce fuera del horario bursátil.
Para un banco, la cuestión ya no es si sus clientes retail van a acceder a este tipo de activos, sino desde dónde lo harán. Si la entidad no ofrece esa posibilidad en su propia app, el cliente la encontrará en otro intermediario, y con ella se irá una parte de su patrimonio y de su relación. Este artículo repasa qué necesita un banco, en la práctica, para distribuir a sus clientes acciones tokenizadas emitidas por terceros, con su marca y bajo sus licencias.
Por qué el cliente retail se está moviendo
Tres características explican buena parte del interés. La primera es el acceso fuera de horario: un activo tokenizado puede transferirse y liquidarse cualquier día y a cualquier hora, algo que el cliente ya espera de otros productos digitales. La segunda es el fraccionamiento, que permite invertir importes pequeños en valores cuyo precio unitario resultaría prohibitivo para muchos ahorradores. La tercera es la liquidación casi inmediata, que simplifica la experiencia y reduce la fricción.
Además, el cliente ya ve estos productos en aplicaciones de brokers y exchanges ajenos a su banco. Cada cuenta que abre fuera resta a la entidad visibilidad sobre su actividad financiera. Ofrecer el producto dentro de la propia app no responde a una moda, sino a una necesidad de retención.
El encaje regulatorio: MiFID II, no MiCA
Una acción tokenizada es un instrumento financiero. Por tanto, a las entidades que operan en la Unión Europea les aplica MiFID II, no MiCA, con independencia de que el registro del valor se lleve en una cadena de bloques. Para las infraestructuras de mercado basadas en DLT existe además el Régimen Piloto DLT (Reglamento (UE) 2022/858), pero la relación entre el banco y su cliente sigue el marco de servicios de inversión que la entidad ya conoce.
Eso implica que las obligaciones habituales siguen vigentes:
- Clasificación de clientes como minoristas, profesionales o contrapartes elegibles, con el nivel de protección correspondiente.
- Evaluación de idoneidad o de conveniencia, según el servicio prestado, antes de permitir la operación.
- Gobernanza de producto, con la definición del mercado objetivo de cada instrumento y de sus riesgos específicos, incluidos los derivados de la estructura del emisor y de la tecnología subyacente.
- Información precontractual y de costes, junto con la documentación del emisor que corresponda.
- Mejor ejecución y registro de operaciones, con la trazabilidad que exige el supervisor.
La ventaja para un banco es que ya dispone de las licencias y de los procesos. La tarea no consiste en obtener una autorización nueva, sino en extender los controles existentes a un nuevo tipo de instrumento y documentar cómo se aplican.
Custodia, claves y modelo de wallet
La diferencia operativa más visible respecto a una acción tradicional está en la custodia. El activo reside en una dirección de blockchain, y quien controla la clave privada controla el activo. Por eso la decisión sobre dónde se generan y se guardan las claves es central.
La opción más coherente con el perfil de riesgo de un banco es que las claves de los clientes se generen y se custodien en sus propios HSM, físicos o en su nube. Ambas alternativas ofrecen un nivel de seguridad equivalente y, en los dos casos, la entidad mantiene el control completo del ciclo de vida de las claves, de las políticas de firma y de los permisos.
Sobre esa base, el banco debe decidir el modelo de wallet:
- Wallets individuales, una por cliente, que facilitan la trazabilidad y la segregación de activos.
- Wallets ómnibus, en las que la entidad mantiene los activos agregados y lleva el registro individual en sus sistemas, más cercanas al modelo de custodia tradicional.
No hay una respuesta única. La elección depende de los requisitos del supervisor, del modelo contable de la entidad y de su política de riesgos, y la infraestructura debe admitir ambas opciones.
Liquidez, precio y ejecución
El banco no emite las acciones tokenizadas: las distribuye. Necesita, por tanto, acceso a emisores y a fuentes de liquidez fiables, con capacidad para ejecutar órdenes a precios coherentes con el mercado del subyacente. Esto exige decidir con qué emisores y centros de liquidez se conecta, evaluar su solidez jurídica y operativa, y establecer cómo se forma el precio que ve el cliente, incluidos diferenciales y comisiones.
La ejecución debe producirse bajo las licencias del banco y con sus controles: límites, verificaciones previas a cada operación, monitorización y registro. Fuera del horario bursátil del subyacente, la entidad debe definir además cómo se forma el precio y qué información recibe el cliente sobre ello.
Integración con el core y experiencia de cliente
Una acción tokenizada que no aparece en la posición global del cliente, en su extracto o en su información fiscal no está realmente integrada. Esta suele ser la parte más laboriosa del proyecto:
- Core bancario, para cargos, abonos y movimientos de efectivo asociados a cada operación.
- Registros contables coherentes con el modelo de custodia elegido.
- Conciliación diaria entre lo que figura en la blockchain y lo que registran los sistemas internos.
- Identidad del cliente, reutilizando el KYC y la autenticación ya existentes.
- Reporting regulatorio y fiscal, incluida la información que el cliente necesita para su declaración.
La experiencia de cliente merece la misma atención. El cliente espera encontrar el producto en la app de su banco, con su marca, junto a datos de mercado, gráficos y contenido que le ayuden a entender lo que compra. Cuando todo esto se ofrece dentro de la propia app, la relación sigue siendo del banco.
Infraestructura propia o servicio cerrado
Hay dos formas de abordar el proyecto. Una es contratar un servicio cerrado que lo resuelve todo desde fuera. La otra es desplegar la infraestructura dentro de la propia entidad, integrada con sus sistemas, sus HSM y sus procesos, de modo que el banco conserve el cliente, la marca, los datos, las claves, las licencias y el control operativo. La segunda opción exige más trabajo de integración al principio, pero deja a la entidad en una posición más sólida ante el supervisor y ante la evolución de su propio producto.
En cualquier caso, lo razonable es empezar por una prueba de concepto acotada, sobre la infraestructura del banco o en un entorno de pruebas, que permita validar custodia, ejecución, conciliación y experiencia antes de llevar nada a producción. En Finhattan trabajamos con este enfoque: un equipo de ingeniería que despliega y opera la infraestructura dentro de cada banco, como se describe en cómo trabajamos y en seguridad y control.
Para una entidad que esté valorando este paso, una primera conversación suele bastar para identificar qué piezas ya existen y cuáles faltan. El punto de partida está en contacto.