La caída de Google Cloud dejó a Revolut sin pagos, transferencias y acceso a la aplicación durante horas.
Los clientes del neobanco no pudieron completar compras con tarjeta, ejecutar transferencias ni entrar en sus cuentas desde el móvil. El origen no estaba en la entidad, sino en la infraestructura que alquila a Google. Lo recogieron Investing.com España, Expansión y El País a lo largo de la jornada, y el alcance se extendió a otros servicios financieros europeos que operan sobre la misma plataforma.
Google Cloud dio por ‘mitigada’ su caída en Europa mientras Revolut recobraba la operativa de forma progresiva, según las primeras informaciones. La palabra importa: mitigada no significa reparada. Significa que el proveedor deja de ver crecer el fallo y empieza a cerrar servicios uno a uno, sin fecha cierta para el último de ellos.
Fuera del panel de estado de Google Cloud y de la web de Revolut, ninguna de las dos compañías ha detallado el alcance: no hay cifra de clientes afectados, ni duración exacta del incidente, ni explicación técnica de lo ocurrido. Tampoco se ha identificado a las entidades europeas que sufrieron el mismo golpe. Esa opacidad, más que el fallo en sí, es lo que incomoda en Fráncfort y en las autoridades nacionales.
Un fallo en la infraestructura que sostiene los pagos
La dependencia de la nube no es una decisión menor para una entidad financiera. Cuando un banco traslada su core bancario, sus motores antifraude y su aplicación móvil a un proveedor externo, gana velocidad de despliegue y pierde el control del último kilómetro. El fallo del proveedor se convierte en el fallo del banco, y el cliente no puede distinguir uno de otro. En un negocio donde la confianza se mide en segundos de interrupción, la distancia entre ‘la app va lenta’ y ‘no puedo pagar’ es la distancia entre una queja y una fuga de depósitos.
Un banco puede competir por marca, precio y experiencia; lo que no puede elegir es su punto único de fallo.
El incidente confirma que al menos una capa crítica de la operativa de Revolut corre sobre Google Cloud. La entidad, nacida digital y con licencia bancaria europea a través de Lituania, está diseñada para escalar sin sucursales y sin centros de datos propios, con una base que la propia compañía sitúa por encima de los 50 millones de clientes en todo el mundo. La ventaja competitiva y el riesgo operativo son el mismo diseño visto desde dos ángulos.
La banca europea comparte proveedor y compite en la misma nube
El episodio no es un accidente aislado. El 19 de julio de 2024, una actualización defectuosa de CrowdStrike tumbó sistemas de aerolíneas, hospitales y bancos en medio mundo sin que el proveedor fuera una entidad financiera. Las grandes interrupciones de Azure y de Amazon Web Services en los últimos años siguieron el mismo patrón: un fallo en la capa de infraestructura se propaga a todos los clientes a la vez.
La diferencia es el perímetro. Amazon Web Services, Microsoft Azure y Google Cloud concentran la mayor parte del negocio cloud mundial, y la banca europea no tiene una alternativa realista a corto plazo. Migrar un núcleo bancario lleva años, no semanas. Y en la práctica, la mayoría de los bancos medianos comparte la misma infraestructura de base, aunque los contratos estén a nombre de cada uno.
Quienes más han avanzado en la nube son, precisamente, las entidades con menos margen para una interrupción: neobancos y filiales digitales que compiten por experiencia de usuario y no pueden permitirse un fin de semana fuera de servicio. La paradoja es incómoda. La arquitectura que les permite crecer rápido es la que les deja sin defensa cuando el proveedor falla.
El riesgo de concentración que DORA todavía no ha resuelto
Europa lleva dos ejercicios construyendo la respuesta regulatoria. El reglamento DORA obliga desde enero de 2025 a las entidades financieras a mantener un registro de sus proveedores tecnológicos, probar la resiliencia de sus sistemas y reportar incidentes con plazos tasados. Sobre el papel, la norma cubre exactamente lo que ha ocurrido esta semana. En la práctica, la parte más delicada —la designación formal de los grandes proveedores cloud como proveedores críticos sujetos a supervisión directa— avanza a un ritmo bastante más lento que las caídas.
Ahí está la contradicción. Los supervisores exigen a cada banco planes de continuidad individuales, pero el riesgo es colectivo: si tres entidades comparten proveedor, comparten caída, y ninguna puede resolver la incidencia por su cuenta. Los planes de contingencia se redactan entidad por entidad; los fallos se producen sistema por sistema. En mi experiencia, los documentos de continuidad del sector dedican muchas más páginas al ciberataque que al proveedor caído, porque el primero se puede ensayar y el segundo solo se puede esperar.
Hay además un asunto que nadie quiere poner por escrito. La concentración no se mide en número de proveedores, sino en número de proveedores distintos. Una entidad puede cumplir con tres contratos firmados y depender en la práctica de una sola región de un solo proveedor. Los registros que exige DORA deberían revelar esa foto, y ahí es donde previsiblemente aparecerán las sorpresas cuando los supervisores empiecen a cruzar datos entre bancos.
Mi lectura es que el debate sobre la soberanía tecnológica europea seguirá siendo retórica mientras nadie obligue a publicar, entidad por entidad, el mapa de dependencias. No hace falta una ley nueva. Bastaría con que esos registros fueran comparables y agregables, en lugar de quedar archivados en un cajón de cada dirección de riesgos.
Mientras tanto, conviene recordar lo evidente: esta vez el fallo fue de Google y lo pagó Revolut. La próxima puede ser al revés, y entonces la pregunta que circulará por los comités de riesgo no será qué banco falló, sino cuántos comparten el mismo punto único de fallo. La respuesta llegará con la próxima interrupción, no antes.
