Cuando un banco decide ofrecer activos digitales a sus clientes, la primera decisión no es qué activos ofrecer ni sobre qué red. Es de quién será la infraestructura. De esa decisión dependen el control sobre las claves y los datos, la relación con el supervisor, el margen del producto y la facilidad para cambiar de rumbo dentro de unos años.
En la práctica hay tres caminos. Construir la infraestructura desde cero con equipos propios, alquilarla a una plataforma externa que se integra por API, o desplegar dentro del banco una infraestructura ya construida que se adapta a sus sistemas. Ninguno es correcto en abstracto. Este artículo describe qué implica cada uno y qué criterios suelen decidir la elección.
Construir: desarrollo propio desde cero
Construir significa que el banco diseña y desarrolla internamente todas las piezas: generación y custodia de claves, wallets, conexión con las redes, ejecución de órdenes, conciliación con el core, monitorización y cumplimiento. Algunas grandes entidades han seguido este camino. JPMorgan, por ejemplo, desarrolla su propia infraestructura de blockchain a través de Kinexys desde 2015.
La ventaja es el control total. La entidad decide la arquitectura, el ritmo y las prioridades, y no depende de la hoja de ruta de nadie. El inconveniente es el coste y el tiempo. Hace falta un equipo especializado en criptografía aplicada, redes blockchain y operaciones de custodia, un perfil escaso y caro. Y el proyecto compite por recursos con el resto de iniciativas tecnológicas del banco durante años antes de llegar a producción.
Para la mayoría de entidades medianas, construir desde cero supone dedicar a infraestructura un esfuerzo que el mercado no remunera: el cliente no paga más porque la entidad haya escrito su propio sistema de firma.
Alquilar: una plataforma de un tercero por API
Alquilar significa contratar a una plataforma externa que ya ofrece el servicio completo. El banco integra su app con las API del proveedor, y el proveedor se encarga de la custodia, la ejecución y la conexión con las redes. Es el camino más rápido para lanzar un producto.
El precio de esa rapidez aparece después. El cliente, sus datos y una parte del margen pasan por la plataforma del proveedor. Las claves suelen estar en su infraestructura, no en la del banco. La hoja de ruta del producto depende de lo que el proveedor decida construir, y los cambios de precio o de condiciones se aplican a todos sus clientes a la vez.
Desde enero de 2025, además, esta dependencia tiene una dimensión regulatoria explícita. El Reglamento DORA (Reglamento (UE) 2022/2554) obliga a las entidades financieras a gestionar el riesgo de sus proveedores tecnológicos:
- Registro de información de todos los contratos con proveedores de servicios TIC (artículo 28.3), que el supervisor utiliza para identificar dependencias y concentraciones.
- Estrategias de salida documentadas y probadas para los servicios que soportan funciones críticas o importantes (artículo 28.8), con planes de transición y alternativas evaluadas.
- Cláusulas contractuales mínimas sobre acceso, auditoría, localización de datos y terminación (artículo 30).
Una plataforma que concentra custodia, ejecución y datos de clientes difícilmente quedará fuera de la categoría de funciones críticas. La entidad debe poder demostrar al supervisor cómo saldría de ella sin interrumpir el servicio, y esa demostración es más difícil cuanto más profunda sea la integración.
Desplegar: infraestructura propia, construida por otros
Desplegar significa instalar dentro del perímetro del banco una infraestructura ya desarrollada, adaptada a sus sistemas, y operarla junto a sus equipos. Las claves se generan y se usan en los HSM de la entidad, los datos permanecen en sus sistemas y el producto se ofrece con su marca y bajo sus licencias.
Este modelo combina parte de las ventajas de los otros dos. Como en el desarrollo propio, el banco conserva el control de las claves, los datos y la relación con el cliente. Como en el alquiler, no parte de cero: las piezas existen y el trabajo se concentra en la integración con el core, la contabilidad, el KYC y los procesos de la entidad.
Exige más trabajo de integración al principio que una conexión por API, y requiere un equipo que conozca tanto la infraestructura como los sistemas bancarios. Por eso el despliegue suele hacerse con ingenieros que trabajan dentro de la entidad durante la integración y después en la operación.
Comparativa de los tres modelos
| Criterio | Construir | Alquilar | Desplegar |
|---|---|---|---|
| Control de claves | Total, en los HSM del banco | Normalmente del proveedor | Total, en los HSM del banco |
| Datos del cliente | En el banco | Pasan por el proveedor | En el banco |
| Plazo hasta producción | Largo | Corto | Intermedio |
| Equipo interno necesario | Grande y especializado | Reducido | Reducido, con apoyo del proveedor |
| Hoja de ruta | La decide el banco | La decide el proveedor | La decide el banco |
| Estrategia de salida DORA | No aplica a la pieza central | Compleja si la integración es profunda | Acotada, la infraestructura reside en el banco |
| Margen del producto | Para el banco | Compartido con el proveedor | Para el banco |
Modularidad: la pregunta que se suele olvidar
Más allá del modelo elegido, hay una cuestión que conviene plantear desde el principio: qué ocurre cuando cambia una pieza. El mercado de infraestructura blockchain es joven y se mueve rápido. Los proveedores de custodia, liquidez, emisión y conexión con las redes cambian sus precios y condiciones, dejan de dar soporte a una red, son adquiridos por otras compañías o salen de un mercado. Cuando las claves, las wallets y los datos de los clientes residen en la plataforma de un tercero, cambiar de proveedor deja de ser una decisión técnica y se convierte en una migración de activos de clientes, con su riesgo operativo y su coste.
Una infraestructura en la que cada proveedor externo está aislado en su propio módulo permite sustituirlo sin tocar el resto del sistema. Una infraestructura en la que el proveedor está integrado en todas las capas convierte cada cambio de condiciones en un proyecto. Al evaluar cualquiera de los tres caminos, es útil preguntar cuánto tiempo y esfuerzo costaría reemplazar cada pieza.
Cómo decidir
Algunas preguntas ayudan a orientar la elección:
- ¿Dónde deben estar las claves? Si la política de riesgos exige que residan en los HSM de la entidad, el alquiler queda limitado.
- ¿Qué funciones serán críticas o importantes? Cuantas más, más pesa la estrategia de salida exigida por DORA.
- ¿Qué capacidad interna existe? Construir sin un equipo especializado alarga los plazos y aumenta el riesgo.
- ¿Qué margen se quiere conservar? Si el producto es estratégico para la relación con el cliente, compartir el margen y los datos tiene un coste a largo plazo.
En Finhattan trabajamos con el tercer modelo: desplegamos la infraestructura dentro de cada banco, integrada con sus sistemas y sus HSM, con un equipo de ingeniería propio que acompaña la integración y la operación. Se describe con más detalle en cómo trabajamos y en seguridad y control. Las obligaciones de DORA aplicables a los proveedores tecnológicos se tratan en MiCA y DORA.
Para una entidad que esté valorando estas opciones, el punto de partida está en contacto.