Cloud Banking en 2026: la guía completa
Análisis en profundidad del cloud banking en 2026: core bancario SaaS, nube pública, privada e híbrida, DORA, Banco de España, patrones de migración y los proveedores que hacen funcionar bancos reales en la nube.
¿Qué es el cloud banking?
Cloud banking es el modelo en el que un banco o entidad financiera autorizada ejecuta su core bancario, el libro mayor, el motor de pagos, la analítica y los canales de cliente sobre infraestructura en la nube pública, privada o híbrida, en lugar de servidores alojados en su propio centro de datos. En 2026 ya no es un caso excepcional. Es el punto de partida por defecto para toda nueva licencia en Europa, Norteamérica y APAC, y el destino final de casi todos los programas de modernización de la banca tradicional.
El cambio lo empujan tres fuerzas al mismo tiempo: los hyperscalers con ofertas dedicadas a la banca (AWS Financial Services, Microsoft Cloud for Financial Services, Google Cloud for Financial Services), una nueva generación de proveedores de core bancario cloud-native (Mambu, Thought Machine, Finxact, Tuum, 10x, Pismo) y los supervisores, que han pasado de "la nube es arriesgada" a "la nube está bien si se gestiona el riesgo". El Reglamento de Resiliencia Operativa Digital (DORA) es plenamente aplicable en la UE desde el 17 de enero de 2025 y codifica de forma exacta cómo los bancos deben gobernar a sus proveedores de nube.
Core bancario SaaS
Libro mayor, cuentas, préstamos y pagos entregados como servicio gestionado, actualizados por el proveedor y consumidos vía API.
Arquitectura cloud-native
Microservicios, contenedores, event streaming, infraestructura como código. Escala horizontal en vez de batch nocturno.
Resiliencia supervisada
DORA en la UE, orientaciones del Banco de España y del BCE, guías FFIEC en EE. UU. La nube se supervisa como dependencia crítica.
El destino es el mismo en todas partes: un banco capaz de lanzar un producto nuevo en un sprint, abrir mercados sin levantar un centro de datos, resistir una caída regional sin impacto al cliente y demostrárselo a su supervisor con un rastro documental que se genera solo.
Hablemos de tu proyecto y veamos cómo podemos lanzar tu Producto bancario digital Juntos
Solicita una demoNube pública, privada e híbrida, mono frente a multitenant
No toda "nube" significa lo mismo. Cuando un CIO elige un modelo, en realidad decide sobre dos ejes: dónde vive la infraestructura y cómo se particiona el software entre clientes. Ambas decisiones tienen consecuencias regulatorias directas.
| Modelo | Qué es | Uso típico | Compromiso |
|---|---|---|---|
| Nube pública | Infraestructura compartida de un hyperscaler (AWS, Azure, Google Cloud, Oracle, IBM) consumida bajo demanda. | Neobancos greenfield, fintechs y la mayoría de despliegues nuevos de core bancario. | Mejor economía y escala. El riesgo de concentración y la estrategia de salida deben documentarse bajo DORA. |
| Nube privada | Infraestructura dedicada, en las instalaciones del banco o en colocation, operada como una nube. | Grandes incumbentes con restricciones de residencia de datos o de legacy. | Control total, mayor coste unitario y menor rapidez para desplegar nuevas capacidades. |
| Nube híbrida | Una mezcla: cargas sensibles en privada, cargas elásticas en pública, con un plano de control común. | Bancos medianos y grandes durante programas de migración plurianuales. | Operativamente realista, arquitectónicamente más pesado. Buen compromiso para un trayecto de 3 a 5 años. |
| SaaS multitenant | Muchos bancos comparten la misma plataforma lógica, aislados a nivel de datos y de políticas. | Mambu, Tuum, Pismo y núcleos cloud-native similares. | Despliegue más rápido, coste más bajo, menos personalización por banco. |
| Mono-tenant | Una instancia dedicada por banco, normalmente en la propia cuenta cloud del banco. | Thought Machine Vault, 10x, grandes transformaciones. | Más control, más comodidad regulatoria y precio más alto. |
Regla práctica en 2026: los proyectos greenfield van a nube pública y multitenant. Los grandes incumbentes, a híbrida con núcleos mono-tenant. Lo que está entre medias se negocia caso por caso con el supervisor, no con el proveedor.
Por qué la nube y por qué ahora
El business case solía girar en torno al coste. En 2026 el coste es la parte menos interesante de la conversación. Los cinco motores siguientes, en este orden, son los que realmente llevan a un consejo a aprobar una migración a la nube.
Velocidad
Lanzar un producto en semanas, no en ventanas de release. Los entornos se levantan en minutos.
Escalabilidad
Absorber picos de nómina, Black Friday y crecimientos súbitos sin sobredimensionar.
Resiliencia
Multi-AZ, multi-región, failover automático. Objetivos de recuperación de nivel DORA por defecto.
Innovación
Acceso directo a servicios de IA, datos y analítica. Sin contratar cada pieza por separado.
Coste
Opex en lugar de capex. Unit economics que se mueven con el negocio, no con el rack.
En el lado del supervisor, el ánimo cambió entre 2022 y 2025. El BCE, el Banco de España y el Bank of England manejan ya expectativas supervisoras que asumen abiertamente la adopción de la nube. No usarla dejó de ser la opción segura; hoy es la que cada vez más necesita una justificación propia en una inspección.
El mapa de proveedores de cloud banking
La pila se divide con claridad en dos capas: hyperscalers que aportan infraestructura y servicios sectoriales, y proveedores de core bancario que aportan el producto de registro. Un despliegue real suele mezclar uno de cada.
Infraestructura cloud para bancos
- AWS Financial Services - mayor huella en banca global, red de partners profunda.
- Microsoft Cloud for Financial Services - fuerte en Europa y en incumbentes con Dynamics y M365.
- Google Cloud for Financial Services - contratos impulsados por datos, IA y analítica, Vertex AI para fraude.
- Oracle Financial Services - Flexcube y OFSAA sobre Oracle Cloud Infrastructure.
- IBM Cloud for Financial Services - marco de políticas construido con Bank of America, fuerte en híbrida.
Core bancario cloud-native
- Mambu - SaaS multitenant, retail, pymes y lending, usado por N26 y ABN AMRO (New10).
- Thought Machine Vault - mono-tenant, impulsa Lloyds, Standard Chartered Mox e Intesa Isybank.
- Finxact - enfocado en EE. UU., adquirido por Fiserv, core centrado en depósitos.
- Tuum - core europeo de nueva generación, componible, fuerte en países nórdicos y DACH.
- 10x Banking - plataforma meta-core detrás de Chase UK y Westpac en Australia.
- Pismo - tarjetas y core en LATAM y APAC, adquirido por Visa en 2024.
La elección entre proveedores rara vez va de funcionalidades sobre una hoja de cálculo. Va de las tres preguntas que hará el supervisor: quién es responsable, cómo salimos y qué pasa durante una caída del proveedor de nube. Un buen proveedor llega a la primera reunión con las respuestas ya escritas.
Regulación: DORA, Banco de España y el mapa de cumplimiento 2026
Dos marcos dominan la conversación en 2026. En la UE, DORA (Reglamento UE 2022/2554) está en vigor desde el 17 de enero de 2025 y cubre riesgo TIC, notificación de incidentes, pruebas de resiliencia y supervisión directa de los proveedores terceros críticos, incluidos los hyperscalers. En España, esto se combina con la Circular 2/2016 del Banco de España sobre externalización y con la Guía del BCE sobre externalización de servicios en la nube, finalizada en julio de 2025.
- Registro de contratos de nube. Bajo el artículo 28 de DORA, las entidades mantienen un Registro de Información con todos los acuerdos TIC con terceros y lo remiten anualmente al Banco de España. La entrega de 2026 se espera antes del 31 de marzo.
- Estrategia de salida documentada. Antes de firmar con cualquier proveedor cloud que soporte una función crítica o importante, el banco debe demostrar que puede migrar fuera en un plazo definido. "Confiamos en AWS" no es un plan de salida.
- Pruebas de resiliencia operativa. El threat-led penetration testing (TLPT) sobre funciones críticas es obligatorio bajo DORA para las entidades significativas. El Banco de España y el BCE esperan ver los resultados y los planes de remediación.
- Riesgo de concentración. DORA reconoce explícitamente que demasiada banca sobre un único hyperscaler es un problema sistémico. La diversificación, el multi-región y las arquitecturas portables son ya un tema de consejo.
- Soberanía del dato. RGPD, la Ley de Servicios Digitales, el Reglamento de Datos de la UE y las reglas nacionales en España condicionan la transferencia transfronteriza. La elección de la región cloud es tanto una decisión regulatoria como de ingeniería.
A lo anterior se suman SOC 2, ISO 27001, PCI DSS 4.0, NIS2, el Reglamento europeo de IA para riesgo de modelo y las directrices de la EBA sobre externalización. Nada de esto es opcional. La buena noticia es que los proveedores cloud-native maduros traen los controles de fábrica, y los hyperscalers publican la matriz de responsabilidad compartida línea a línea.
Beneficios para incumbentes y para nuevos entrantes
El business case cambia según el punto de partida. Un banco Tier-1 que migra desde un mainframe tiene poco que ver con una fintech que arranca desde cero. Ambos ganan, pero no de la misma manera.
Incumbentes (migración)
- Retirar parques COBOL y mainframe caros
- Reducir huella de centro de datos y capex de infraestructura
- Acelerar la entrega de producto de trimestres a sprints
- Habilitar analítica e IA en tiempo real sobre datos de cliente
- Cumplir por diseño los objetivos de resiliencia de DORA
Nuevos entrantes (greenfield)
- Sin legacy, sin deuda técnica, sin centro de datos que construir
- Salir a producción con un core SaaS en 6 a 12 meses
- Entrar en nuevos países sin nueva infraestructura
- Coste fijo bajo, opex que escala con los ingresos
- Talento cloud-native, no jubilados del mainframe
El hilo común: ambos campos dejan de competir en infraestructura y empiezan a competir en producto. Resuelta la capa cloud, el diferencial es lo que se construye encima.
Seguridad, disponibilidad y postura de cumplimiento
La vieja objeción decía que "la nube es menos segura que mi centro de datos". Los datos ya no la sostienen. Los hyperscalers invierten más en seguridad al año que cualquier banco individual, y las certificaciones lo demuestran. Así se ve sobre el papel una pila de cloud banking en 2026:
La responsabilidad compartida es el único concepto que importa. El hyperscaler asegura la nube; el banco asegura lo que pone dentro. Identidad, segmentación de red, gestión de secretos, propiedad de las claves (BYOK o HYOK), logs hacia el SIEM y una respuesta a incidentes bien ensayada son tarea del banco. Con eso bien hecho, se pasa la auditoría; sin eso, ningún certificado colgado en la pared del proveedor ayuda. El cuestionario CAIQ de la Cloud Security Alliance es la vía habitual para demostrar estos controles ante el Banco de España.
Rutas de migración: strangler, parallel run y big-bang
Hay tres estrategias de migración honestas. Ninguna es indolora y la correcta depende del punto de partida, del apetito por el riesgo y del supervisor.
| Patrón | Cómo funciona | Tiempo | Perfil de riesgo |
|---|---|---|---|
| Strangler | Se envuelve el core legacy con APIs, se llevan las capacidades nuevas a una plataforma cloud-native y se retira el legacy pieza a pieza. | 2 a 4 años | Riesgo más bajo. Preferido por los Tier-1. Entrega de valor continua. |
| Parallel run | Legacy y core cloud funcionan en paralelo, los segmentos de clientes migran en olas con reconciliación completa. | 12 a 24 meses | Riesgo medio. Ideal para bancos con carteras o geografías diferenciadas. |
| Big-bang | Se migra toda la cartera en un solo fin de semana tras largos ensayos. | 9 a 18 meses | El de más riesgo y más rápido retorno. Viable sobre todo para bancos pequeños o medianos con productos simples. |
Se elija lo que se elija, dos cosas son innegociables: un plan de despliegue reversible y una estrategia de reconciliación que demuestre, céntimo a céntimo, que ningún saldo de cliente se movió en la dirección equivocada. El supervisor querrá ver ambos.
Lanza tu cloud banking con Crassula
Crassula es una plataforma bancaria cloud-native que se ejecuta sobre el hyperscaler de tu elección y se comporta como un producto SaaS cuando te interesa. El core, el libro mayor, la provisión de IBAN, la emisión de tarjetas, la orquestación del KYC, el enrutado de pagos y el back office ya vienen construidos. Tú eliges el modelo de despliegue (SaaS multitenant, mono-tenant en tu cuenta cloud o híbrido) y nosotros nos ocupamos del resto.
Lanzamiento en semanas
Producto de cloud banking de marca en producción en 6 a 12 semanas, sobre AWS, Azure o Google Cloud.
Listo para DORA
Estrategia de salida, notificación de incidentes, Registro de Información y pruebas de resiliencia integradas en la plataforma.
Modular
Sustituye cualquier módulo, trae tu propio core, conéctate a raíles BaaS de socios. Sin vendor lock-in por diseño.
Si estás planificando una migración, un nuevo banco digital o una fintech vertical, Crassula te entrega una pila de cloud banking que ya cumple, ya es resiliente y ya está integrada con las redes de pago que necesitas.
Preguntas frecuentes
Cloud banking es cuando un banco ejecuta sus sistemas centrales, libro mayor, pagos y canales de cliente sobre infraestructura cloud pública, privada o híbrida en vez de en su propio centro de datos. Normalmente implica usar un core bancario SaaS sobre un hyperscaler como AWS, Azure o Google Cloud.
Sí. En la UE, DORA está en vigor desde el 17 de enero de 2025 y regula con detalle cómo pueden usar la nube los bancos. En España se suman la Circular 2/2016 del Banco de España sobre externalización y la Guía del BCE sobre externalización cloud de julio de 2025. La nube se supervisa como dependencia crítica, pero está explícitamente permitida y ampliamente esperada.
La nube pública usa un hyperscaler compartido como AWS o Azure. La privada es infraestructura dedicada operada al estilo cloud, normalmente por motivos de residencia de datos o legacy. La híbrida mezcla ambas con un plano de control común. La mayoría de los bancos nuevos van a pública y multitenant; la mayoría de los grandes incumbentes usan híbrida durante la migración.
Mambu, Thought Machine Vault, Finxact, Tuum, 10x Banking y Pismo lideran la categoría cloud-native. Corren sobre hyperscalers y dan servicio a bancos como Lloyds, Standard Chartered Mox, Chase UK, N26 e Intesa Isybank. Consulta nuestra guía de core banking para una comparativa completa.
DORA exige un Registro de Información con cada contrato TIC con terceros, una estrategia de salida documentada para proveedores críticos, pruebas de penetración basadas en amenazas, notificación de incidentes graves en 24 horas y una gestión explícita del riesgo de concentración cuando el banco depende de un único hyperscaler. En España, la entrega del Registro se espera antes del 31 de marzo de 2026.
Un lanzamiento greenfield sobre un core SaaS puede estar en producción en 6 a 12 meses. Una migración completa de un banco incumbente suele durar de 2 a 4 años con el patrón strangler. Los parallel run se mueven entre 12 y 24 meses y el big-bang solo es habitual en bancos medianos con gamas de producto simples.
Los hyperscalers tienen certificaciones SOC 2, ISO 27001 y PCI DSS 4.0 e invierten más en seguridad que cualquier banco individual. El modelo es de responsabilidad compartida: el proveedor asegura la nube y el banco asegura identidad, datos, claves y configuración. Bien ejecutado, el cloud banking iguala o supera la seguridad on-premise. El CAIQ de la Cloud Security Alliance sigue siendo la herramienta estándar para evidenciarlo.
Crassula aporta una plataforma bancaria cloud-native con libro mayor, IBAN, emisión de tarjetas, KYC, pagos y back office ya construidos. Corre sobre AWS, Azure o Google Cloud, se despliega como SaaS multitenant o mono-tenant y se entrega con controles preparados para DORA. Lanzas un producto bancario de marca en semanas sin reconstruir la fontanería.
Otras guías
Crea un banco digital en cuestión de días
Solicita una demo