La resiliencia operativa suele asociarse con continuidad de negocio, recuperación ante desastres, infraestructura robusta y planes de contingencia. Todo eso importa. Pero en banca digital hay una dimensión que muchas veces se subestima: la resiliencia también depende de la calidad de los datos con los que la organización observa, decide, responde, recupera y aprende.
Una institución financiera puede tener infraestructura redundante y, aun así, operar con poca claridad si no sabe qué está fallando, qué clientes están afectados, qué procesos se degradaron, qué tercero participa en la falla, qué dato es confiable o qué decisión debe tomarse primero.
La resiliencia no es solo resistir una interrupción. Es mantener operaciones críticas, reducir impacto, recuperar con evidencia y aprender para que el siguiente evento sea menos costoso.
La idea de fondo es simple: en banca digital, una organización resiliente no solo tiene sistemas disponibles. Tiene datos suficientes para entender qué está ocurriendo y actuar con criterio.
¿Qué es la resiliencia operativa basada en datos en banca digital?#
La resiliencia operativa basada en datos es la capacidad de una institución financiera para observar, interpretar, responder, recuperar y aprender ante interrupciones, degradaciones o eventos críticos usando información confiable, oportuna y trazable. En banca digital, conecta arquitectura de datos, observabilidad, continuidad, riesgo operacional, riesgo tecnológico, automatización, ciberseguridad, terceros TIC (Tecnologías de Información y Comunicación) y experiencia del cliente.
El error: pensar que resiliencia es solo infraestructura#
Muchas organizaciones reducen la resiliencia a una pregunta técnica:
¿La plataforma está disponible?
La pregunta es importante, pero incompleta.
En banca digital también hay que saber qué servicios críticos están afectados, qué clientes experimentan fricción, qué transacciones quedaron pendientes, qué canales presentan degradación, qué dependencias externas participan y qué evidencia queda para auditoría, riesgo o regulador.
Una plataforma puede estar “arriba” y, aun así, generar una mala experiencia. Un canal puede responder técnicamente, pero fallar en una integración crítica. Un tablero puede mostrar disponibilidad aceptable mientras los clientes enfrentan rechazos, duplicidades, demoras o inconsistencias.
La resiliencia real no se mide únicamente con disponibilidad técnica. Se mide por la capacidad de sostener operaciones críticas bajo presión.
Y para eso, los datos importan.
De continuidad a capacidad de respuesta#
La continuidad tradicional suele enfocarse en respaldos, redundancia, recuperación y procedimientos. La resiliencia operativa va más allá.
El Basel Committee on Banking Supervision (BCBS), en Principles for operational resilience, plantea una visión orientada a la capacidad de las entidades financieras para entregar operaciones críticas durante una disrupción. La idea relevante para una arquitectura de banca digital es que la resiliencia no se limita a recuperar sistemas; implica responder, adaptarse, recuperarse y aprender ante eventos que pueden afectar la operación.
Eso cambia la conversación.
No basta con tener un sitio alterno o una arquitectura técnicamente redundante. La organización necesita saber qué operaciones son críticas, qué dependencias las sostienen, qué datos permiten monitorearlas, qué umbrales indican degradación y qué acciones deben ejecutarse cuando algo falla.
La resiliencia operativa se convierte entonces en una capacidad de decisión bajo presión.
La arquitectura de datos como base de resiliencia#
La arquitectura de datos contribuye a la resiliencia operativa porque permite construir una visión confiable de la operación. No se trata solo de almacenar información histórica. Se trata de diseñar flujos, eventos, métricas, logs, trazas, indicadores y modelos de datos que permitan entender la operación en tiempo casi real y con suficiente contexto.
Una arquitectura de datos orientada a resiliencia debe responder preguntas concretas:
- ¿qué datos describen la salud de un canal digital?
- ¿qué eventos representan fallas reales para el cliente?
- ¿qué información permite priorizar un incidente?
- ¿qué datos permiten distinguir falla técnica, fraude, saturación, error operativo o degradación de un tercero?
- ¿qué evidencia debe conservarse?
- ¿qué información permite aprender después del incidente?
Sin esta arquitectura, la organización puede tener muchas herramientas y poca claridad.
- Puede tener monitoreo técnico, pero no visión de impacto.
- Puede tener logs, pero no trazabilidad de negocio.
- Puede tener dashboards, pero no decisiones.
- Puede tener alertas, pero no aprendizaje.
La resiliencia necesita datos diseñados para operar.
Observabilidad: ver la operación como sistema#
La observabilidad no debería limitarse a saber si un servidor, contenedor, base de datos o API está disponible. En banca digital, debe ayudar a entender cómo se comporta el sistema completo desde la perspectiva de una operación financiera.
Una transacción puede cruzar canal digital, API management, servicios de negocio, motor antifraude, core bancario, procesador de pagos, sistemas de terceros, herramientas de mensajería, almacenamiento de evidencias y tableros operativos.
Si cada componente observa su propia parte sin correlación, la institución ve fragmentos. Pero la operación real ocurre de punta a punta.
Por eso, una arquitectura resiliente necesita correlacionar métricas técnicas, logs de aplicación, trazas distribuidas, eventos de negocio, estado de integraciones, alertas de seguridad, datos de fraude, tickets, incidentes y evidencia operativa.
El National Institute of Standards and Technology (NIST), en The NIST Cybersecurity Framework (CSF) 2.0, estructura la gestión de ciberseguridad alrededor de funciones como gobernar, identificar, proteger, detectar, responder y recuperar. Aunque su foco es ciberseguridad, esta lógica es útil para pensar resiliencia digital: no basta con prevenir; también hay que detectar, responder, recuperar y gobernar.
La observabilidad es el puente entre detectar y responder.
DORA: una señal importante para la resiliencia operativa digital#
Aunque su aplicación corresponde al contexto europeo, el Digital Operational Resilience Act (DORA) es una referencia importante para entender hacia dónde se mueve la conversación regulatoria sobre resiliencia operativa digital en servicios financieros.
La European Securities and Markets Authority (ESMA) explica que DORA entró en vigor el 16 de enero de 2023 y aplica desde el 17 de enero de 2025. Su objetivo es fortalecer la seguridad de las tecnologías de información y comunicación (TIC) de las entidades financieras y asegurar que el sector financiero europeo pueda mantenerse resiliente ante disrupciones operativas digitales severas.
El texto oficial de Regulation (EU) 2022/2554 consolida una visión estructurada sobre riesgo TIC, gestión de incidentes, pruebas de resiliencia operativa digital, gestión de terceros TIC e intercambio de información.
Para México y Latinoamérica, DORA no debe interpretarse como una regulación local aplicable de forma directa. Su valor está en otra parte: funciona como una señal internacional sobre lo que empieza a exigirse a las instituciones financieras digitales.
La conversación ya no se limita a continuidad, ciberseguridad o cumplimiento documental. Ahora se pide demostrar que la organización entiende sus servicios críticos, sus dependencias tecnológicas, sus terceros, sus incidentes, sus pruebas de resiliencia, su capacidad de recuperación y la evidencia que sustenta sus decisiones.
Esa es una lección relevante para bancos, SOFIPOs, fintechs, procesadores, emisores, adquirentes y cualquier entidad financiera digital que dependa fuertemente de tecnología.
Riesgo tecnológico, riesgo operacional y resiliencia#
La resiliencia operativa está estrechamente conectada con el riesgo operacional.
Un incidente tecnológico puede convertirse en afectación al cliente, interrupción de servicios críticos, pérdida financiera, exposición de información, fraude, incumplimiento, reprocesos, daño reputacional, observaciones de auditoría o presión regulatoria.
Por eso, la arquitectura de datos debe conectar señales técnicas con taxonomías de riesgo, impactos operativos y decisiones ejecutivas.
Aquí también es útil mirar principios como los de ISO 31000, no como una plantilla documental, sino como una forma de ordenar la conversación sobre riesgo: contexto, identificación, análisis, evaluación, tratamiento, comunicación, monitoreo y revisión. En resiliencia digital, esto significa que una falla tecnológica no debería quedarse como “incidente de TI”; debe poder evaluarse como exposición real para operación, cliente, cumplimiento y continuidad del negocio.
No basta con decir que falló un servicio. Hay que entender qué operación crítica fue afectada, cuál fue el impacto real, qué controles mitigaron, qué exposición quedó abierta, qué acciones correctivas se requieren y qué evidencia demuestra recuperación.
La resiliencia basada en datos permite que riesgo, tecnología, operación, seguridad y negocio hablen sobre el mismo hecho con lenguaje común.
Caso aplicado: una falla intermitente en originación digital#
Imaginemos una institución financiera que empieza a recibir quejas de clientes durante el proceso de originación digital.
Algunos usuarios no pueden completar su solicitud. Otros reciben mensajes inconsistentes. Algunos expedientes quedan incompletos. El equipo técnico revisa la aplicación y no encuentra una caída general. Los tableros muestran disponibilidad aceptable. El canal parece estar “arriba”.
Pero la operación no está sana.
Una mirada superficial diría:
“La aplicación funciona; son casos aislados.”
Una mirada basada en resiliencia operativa preguntaría:
- ¿en qué paso del flujo ocurre la fricción?
- ¿qué porcentaje de clientes abandona el proceso?
- ¿qué API presenta mayor latencia?
- ¿qué dependencia externa falla intermitentemente?
- ¿qué segmento de clientes está afectado?
- ¿qué expedientes quedaron en estado inconsistente?
- ¿qué clientes requieren atención proactiva?
- ¿qué evidencia existe para reconstruir el caso?
- ¿qué cambio reciente pudo introducir la degradación?
La diferencia es importante.
La disponibilidad técnica puede decir que el sistema está activo. Los datos operativos pueden revelar que la experiencia está rota.
Ahí aparece el valor de la arquitectura de datos para resiliencia: permite traducir señales técnicas en impacto operativo y de cliente.
Capacidades mínimas de una arquitectura de datos para resiliencia#
Una arquitectura de datos orientada a resiliencia operativa no debe quedarse en repositorios o tableros. Debe habilitar capacidades concretas.
Primero, necesita una taxonomía de operaciones críticas. La organización debe identificar qué procesos, servicios y capacidades son críticos para clientes, operación, riesgo, cumplimiento y negocio. No todo tiene la misma criticidad.
Segundo, requiere un modelo de eventos operativos. Los eventos relevantes deben capturarse, normalizarse y correlacionarse: errores, rechazos, reintentos, latencias, validaciones, decisiones, cambios de estado, alertas y excepciones.
Tercero, debe permitir correlación técnica y de negocio. Una falla debe poder relacionarse con clientes afectados, productos, canales, transacciones, servicios, integraciones y procesos internos. Sin correlación, hay señales aisladas.
Cuarto, debe incluir observabilidad de datos. No basta con observar sistemas. También hay que observar si los datos llegan, llegan completos, llegan a tiempo, llegan con calidad y se procesan correctamente.
Quinto, debe conservar evidencia para decisiones y auditoría. La arquitectura debe registrar eventos, decisiones, controles, acciones correctivas, responsables y tiempos de respuesta.
Sexto, debe incorporar gestión de terceros TIC. Una banca digital resiliente debe observar sus dependencias externas: nube, procesadores, burós, proveedores de identidad, servicios antifraude, mensajería, monitoreo, redes de pago y componentes críticos de integración.
DORA refuerza precisamente esta conversación: los terceros tecnológicos ya no pueden verse solo como proveedores contractuales. Deben entenderse como dependencias operativas que pueden afectar continuidad, seguridad, experiencia y confianza.
BIAN, TOGAF e ITIL: ordenar la resiliencia sin convertirla en burocracia#
La resiliencia no debería analizarse solo por aplicaciones. También debe analizarse por capacidades y servicios críticos.
El Banking Industry Architecture Network (BIAN) puede ayudar a ordenar dominios y capacidades bancarias. Esto permite preguntar qué capacidades son críticas, qué procesos las sostienen, qué datos permiten observarlas, qué sistemas participan, qué terceros intervienen y qué eventos indican degradación.
The Open Group, mediante TOGAF Standard, aporta una visión de arquitectura empresarial para conectar estrategia, capacidades, procesos, información, aplicaciones y tecnología. Esa mirada es importante porque la resiliencia es transversal: involucra negocio, operación, tecnología, datos, seguridad, proveedores, procesos, gobierno y cultura.
Por su parte, ITIL ayuda a recordar que la operación tecnológica debe gestionarse como servicio: con responsabilidades, incidentes, cambios, problemas, proveedores, mejora continua y enfoque en valor. El punto no es llenar documentos; es asegurar que la organización pueda operar con disciplina cuando algo se degrada.
Usados con criterio, estos marcos ayudan a ordenar decisiones. Usados como decoración, solo generan burocracia.
Automatización operativa: acelerar respuesta sin perder control#
La automatización puede fortalecer la resiliencia si está bien diseñada. Puede ayudar a detectar patrones anómalos, enrutar incidentes, abrir tickets, notificar equipos, activar runbooks, cambiar tráfico, ejecutar validaciones, generar evidencias o informar a atención a clientes.
Pero automatizar sin datos confiables puede empeorar un incidente.
Una alerta mal calibrada genera ruido. Un runbook automático puede ejecutar acciones equivocadas. Un proceso de recuperación puede ocultar la causa raíz. Una decisión automática puede afectar clientes sin suficiente contexto.
Por eso, la automatización operativa requiere arquitectura de datos, reglas claras, límites, trazabilidad y revisión humana cuando el impacto lo amerita.
La resiliencia no consiste en automatizar todo. Consiste en automatizar lo que puede responder mejor, más rápido y con control.
Antipatrones de resiliencia operativa#
Algunos antipatrones aparecen con frecuencia en instituciones digitales:
- medir solo disponibilidad técnica;
- separar monitoreo técnico de impacto de negocio;
- tratar dashboards como evidencia suficiente;
- ignorar dependencias de terceros;
- generar alertas sin priorización;
- resolver incidentes sin aprendizaje estructural;
- automatizar respuestas sin límites;
- delegar la resiliencia únicamente a tecnología.
El problema de estos antipatrones es que fragmentan la visión. Infraestructura ve métricas, negocio ve quejas, operación ve tickets, seguridad ve alertas y riesgo ve exposición. Pero nadie ve el sistema completo.
La resiliencia madura exige romper esa fragmentación.
Mi postura: resiliencia es capacidad de decisión bajo presión#
Una organización resiliente no es la que nunca falla. Eso no existe.
Una organización resiliente es la que puede detectar más rápido, entender mejor, decidir con evidencia, responder con coordinación, reducir impacto, recuperar con confianza y aprender de forma estructural.
Eso requiere tecnología, pero también requiere datos.
- Datos para observar.
- Datos para priorizar.
- Datos para coordinar.
- Datos para explicar.
- Datos para automatizar.
- Datos para aprender.
La resiliencia operativa basada en datos es, en el fondo, una arquitectura de decisión bajo presión.
Reflexión de arquitectura: diseñar resiliencia es diseñar visibilidad#
Como arquitecto, considero que uno de los errores más costosos es diseñar sistemas sin diseñar cómo serán observados durante una falla.
La arquitectura no termina cuando el sistema funciona. También debe responder cómo se comporta cuando algo se degrada, cómo se detecta, cómo se entiende, cómo se contiene, cómo se recupera y cómo se aprende.
Diseñar resiliencia implica diseñar visibilidad.
No basta con componentes robustos. Se necesitan relaciones visibles: qué depende de qué, qué evento afecta a quién, qué dato permite explicar qué decisión y qué evidencia queda después.
La arquitectura de datos juega un papel central porque convierte señales dispersas en comprensión operativa.
Reflexión CTO: la resiliencia no se delega, se gobierna#
Desde una mirada CTO, la resiliencia operativa no puede delegarse por completo a infraestructura, operaciones o seguridad. Es una responsabilidad de dirección tecnológica porque conecta continuidad, experiencia del cliente, riesgo, proveedores, arquitectura, datos, inversión y confianza.
La pregunta ejecutiva no es solo:
¿Tenemos plan de continuidad?
La pregunta real es:
¿Podemos demostrar que entendemos nuestras operaciones críticas, sus dependencias, sus datos, sus puntos de falla, sus umbrales de impacto y nuestra capacidad de respuesta?
Esa demostración requiere arquitectura y evidencia.
La resiliencia no se declara. Se gobierna.
Y en banca digital, gobernarla exige que los datos sean parte del diseño, no un subproducto de la operación.
Conclusión: una banca resiliente observa, responde y aprende#
La resiliencia operativa en banca digital no depende solo de infraestructura robusta, redundancia o planes de recuperación. Depende también de la capacidad de observar la operación con datos confiables, interpretar señales, priorizar impacto, gestionar terceros, automatizar respuestas, coordinar equipos y aprender de cada evento.
La arquitectura de datos permite convertir eventos dispersos en visibilidad operativa. Permite conectar tecnología con negocio, incidentes con clientes, alertas con riesgo y recuperación con evidencia.
DORA confirma una señal importante para la industria financiera global: la resiliencia digital ya no puede tratarse como asunto técnico aislado. Es una capacidad de gobierno, riesgo, continuidad, seguridad, proveedores, operación y confianza.
Una banca digital resiliente no es la que presume que nunca falla.
Es la que está diseñada para responder mejor cuando algo falla.
Y, sobre todo, para aprender.
Glosario breve#
Resiliencia operativa
Capacidad de una organización para mantener operaciones críticas durante una disrupción, responder, recuperarse, adaptarse y aprender de eventos adversos.
Arquitectura de datos
Disciplina que define cómo se estructuran, integran, protegen, transforman y consumen los datos para habilitar operación, decisiones, analítica, automatización e inteligencia artificial.
Observabilidad
Capacidad de entender el estado interno y comportamiento de un sistema mediante señales como métricas, logs, trazas, eventos y datos operativos.
BCBS — Basel Committee on Banking Supervision
Comité internacional de supervisión bancaria que emite principios y recomendaciones para fortalecer la gestión de riesgos, supervisión y estabilidad del sistema financiero.
DORA — Digital Operational Resilience Act
Regulación de la Unión Europea orientada a fortalecer la resiliencia operativa digital del sector financiero, incluyendo riesgo TIC, incidentes, pruebas de resiliencia, terceros TIC e intercambio de información.
TIC — Tecnologías de Información y Comunicación
Conjunto de tecnologías, sistemas, plataformas, redes, aplicaciones, datos y servicios que soportan la operación digital de una organización.
NIST CSF — NIST Cybersecurity Framework
Marco del National Institute of Standards and Technology para gestionar riesgos de ciberseguridad mediante funciones como gobernar, identificar, proteger, detectar, responder y recuperar.
ISO 31000
Estándar internacional de gestión de riesgos. Ayuda a estructurar cómo identificar, analizar, evaluar, tratar, monitorear y comunicar riesgos.
BIAN — Banking Industry Architecture Network
Red global orientada a desarrollar modelos de referencia para arquitectura bancaria. Ayuda a estructurar capacidades, dominios de servicio y escenarios de negocio en servicios financieros.
TOGAF — The Open Group Architecture Framework
Estándar de arquitectura empresarial desarrollado por The Open Group. Ayuda a conectar estrategia, capacidades, procesos, información, aplicaciones y tecnología.
Runbook
Conjunto de pasos definidos para ejecutar una respuesta operativa ante incidentes, alertas, fallas o escenarios recurrentes.
Referencias#
Basel Committee on Banking Supervision (BCBS), Principles for operational resilience
https://www.bis.org/bcbs/publ/d516.pdfEuropean Securities and Markets Authority (ESMA), Digital Operational Resilience Act (DORA)
https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/digital-operational-resilience-act-doraEuropean Union, Regulation (EU) 2022/2554 — Digital Operational Resilience Act (DORA)
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554National Institute of Standards and Technology (NIST), The NIST Cybersecurity Framework (CSF) 2.0
https://www.nist.gov/publications/nist-cybersecurity-framework-csf-20National Institute of Standards and Technology (NIST), The NIST Cybersecurity Framework (CSF) 2.0 PDF
https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdfInternational Organization for Standardization (ISO), ISO 31000 — Risk management
https://www.iso.org/iso-31000-risk-management.htmlBanking Industry Architecture Network (BIAN), Service Landscape
https://bian.org/deliverables/service-landscape/The Open Group, The TOGAF Standard
https://www.opengroup.org/togafPeopleCert, ITIL 4 Foundation
https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil-4-foundation-2565Comisión Nacional Bancaria y de Valores (CNBV), Sitio institucional
https://www.gob.mx/cnbvBanco de México, Seguridad de la información
https://www.banxico.org.mx/sistema-financiero/seguridad-informacion-banco.html