Resiliencia Operativa Digital: El Riesgo de los Terceros Críticos

WAU Marketing

8 sept

5 min de lectura

Tu banco puede tener 99.99% de disponibilidad propia y aun así caerse por completo en un solo día. Porque la pregunta de la resiliencia ya no es "¿está arriba mi sistema?", sino "¿de cuántos terceros depende que lo esté, y qué pasa cuando uno de ellos falla?".

Durante años, la conversación sobre disponibilidad bancaria se quedó en las paredes del propio banco: redundancia, failover, tiempos de recuperación. Todo eso sigue importando. Pero el riesgo real migró hacia afuera. Hoy un banco moderno descansa sobre una pila de terceros —hiperescaladores de nube, proveedores de core, procesadores de pagos, antivirus, redes— y cada uno de ellos es un punto único de falla que el banco no controla. La paradoja es incómoda: mientras más tercerizas para ganar eficiencia, más concentras el riesgo en manos ajenas.

El día que un solo proveedor tumbó al mundo

No es teoría. El 19 de julio de 2024, una actualización defectuosa de CrowdStrike —una empresa de ciberseguridad, no un banco— dejó inoperables unos 8.5 millones de equipos con Windows en todo el mundo, en lo que se considera la mayor interrupción de TI de la historia, según documentó la enciclopedia del incidente. Entre los afectados hubo aerolíneas, hospitales y, por supuesto, bancos: Chase, Bank of America, Wells Fargo y Capital One en Estados Unidos; RBC, Scotiabank y TD en Canadá; y entidades en Sudáfrica, Israel y Filipinas. Ninguno de esos bancos tenía un problema en su propio sistema. Cayeron por un tercero.

El costo deja claro por qué esto es un asunto de resiliencia, no de soporte técnico. La firma Parametrix estimó las pérdidas directas de las empresas del Fortune 500 (sin contar a Microsoft) en 5,400 millones de dólares, con el sector bancario absorbiendo cerca de 1,150 millones de esa cifra, reportó Fortune. Un actor que la mayoría de los clientes ni conocía paralizó cajeros, sucursales y apps de medio planeta.

El nombre técnico del problema: riesgo de concentración

Lo que CrowdStrike volvió visible los reguladores ya lo venían advirtiendo. El problema se llama riesgo de concentración: cuando demasiadas instituciones dependen de un puñado de los mismos proveedores, la falla de uno solo deja de ser un incidente y se vuelve sistémica. El Consejo de Estabilidad Financiera (FSB) encuestó a casi 300 instituciones financieras de distintos tamaños y encontró que la mayoría tiende a apoyarse en un conjunto muy estrecho de grandes proveedores, lo que podría generar efectos sistémicos ante una falla operativa o insolvencia a gran escala, según su informe sobre adopción de nube y riesgo de concentración.

El Banco de Inglaterra puso número a esa concentración: ya en 2020, solo dos proveedores —AWS y Microsoft Azure— concentraban alrededor de dos tercios del uso de infraestructura en la nube de los bancos británicos, un dato que su Comité de Política Financiera identificó como riesgo material. La advertencia del comité es directa: la creciente dependencia de un número reducido de proveedores de nube y otros terceros críticos puede aumentar los riesgos a la estabilidad financiera si no hay supervisión directa de su resiliencia.

Lo que el regulador empezó a exigir (DORA como marco)

Europa fue la primera en convertir la advertencia en ley. El Reglamento de Resiliencia Operativa Digital (DORA) entró en vigor el 17 de enero de 2025 y aplica a 21 tipos de entidades financieras y a sus proveedores tecnológicos críticos, según la Autoridad Europea de Seguros y Pensiones de Jubilación. La pieza más novedosa: por primera vez, los proveedores tecnológicos críticos quedan bajo supervisión directa de los reguladores, precisamente para atacar el riesgo de concentración. El 18 de noviembre de 2025, las autoridades europeas publicaron la primera lista de 19 proveedores designados como críticos —entre ellos AWS, Microsoft, Google Cloud, Oracle y SAP—, que ahora enfrentan análisis de riesgo anuales, inspecciones in situ y obligaciones de reporte, informó FStech.

El Reino Unido siguió la misma lógica con su régimen de Terceros Críticos, cuyas reglas finales publicaron el Banco de Inglaterra, la PRA y la FCA el 12 de noviembre de 2024, según el comunicado oficial. El mensaje regulatorio global es uno solo: ya no basta con que el banco sea resiliente; el banco debe demostrar que su cadena de proveedores también lo es.

LATAM: la exigencia ya está sobre la mesa

La región no se quedó atrás. En México, la CNBV regula la contratación de servicios con terceros dentro de las Disposiciones de Carácter General Aplicables a las Instituciones de Crédito (la CUB), que fija requisitos técnicos, operativos y contractuales cuando un banco terceriza procesos o administración de bases de datos y sistemas, según el texto vigente publicado por la CNBV. En la guía de autorización, la CNBV exige diligencia debida, monitoreo del servicio, control de la subcontratación, confidencialidad de datos, derechos de auditoría y acceso, continuidad del negocio y —clave para este tema— portabilidad de datos, como detalla su guía para la contratación de servicios con terceros. Esa última palabra —portabilidad— es donde la arquitectura del core deja de ser un detalle técnico y se vuelve la diferencia entre cumplir y estar atrapado.

Cómo un core bien diseñado reduce el riesgo (y uno mal diseñado lo amplifica)

Aquí está el matiz que el ruido omite. El riesgo de concentración no se resuelve con un contrato más estricto; se resuelve con arquitectura. Un core legado, acoplado a un solo proveedor por integraciones propietarias y formatos cerrados, convierte cualquier dependencia en un secuestro: si ese proveedor cae, sube de precio o queda fuera de norma, salir cuesta años. Un core moderno hace lo contrario por diseño:

Portabilidad real. Si tus datos y tu lógica viven detrás de APIs estándar y en formatos abiertos, mover una carga de un proveedor a otro es una decisión, no una reconstrucción.
Estrategia multi-proveedor. Una arquitectura desacoplada permite repartir cargas críticas entre proveedores o regiones, de modo que la caída de uno no apague el banco entero.
Salida ordenada. El regulador pide planes de continuidad y estrategias de salida verificables. Sobre un core abierto, esos planes son ejecutables; sobre uno cerrado, son un documento de buenos deseos.
Visibilidad de la cadena. No puedes gestionar el riesgo de un tercero que no puedes ver. Un core moderno expone qué depende de quién, condición previa para cualquier prueba de resiliencia seria.

La resiliencia operativa, bien entendida, no es comprar más redundancia dentro de tu castillo. Es no haber construido el castillo sobre un solo cimiento que no controlas.

Cómo lo vemos en WAU

En WAU diseñamos el core para que la resiliencia frente a terceros sea una propiedad de la arquitectura, no un parche posterior. Datos y lógica expuestos por APIs estándar, en formatos abiertos, con portabilidad y estrategia de salida desde el primer día: eso es lo que vuelve creíbles tus planes de continuidad ante la CNBV y lo que te deja repartir el riesgo en lugar de concentrarlo. La disponibilidad 24/7 es la promesa; la independencia de un solo proveedor es lo que la sostiene cuando ese proveedor falla.

Si quieres saber qué tan expuesto está hoy tu banco al riesgo de un tercero crítico —y qué exige tu arquitectura para reducirlo—, hablemos. 👉 Agenda una conversación con nuestro equipo.