TARGET2: la recuperación de la infraestructura de pagos como prueba de responsabilidad

Resumen

• Los servicios de liquidación de TARGET2 dejaron de estar disponibles aproximadamente a las 14:40 hora central europea del 23 de octubre de 2020. La recuperación en la misma región no funcionó, el módulo de contingencia no estaba disponible y el Eurosistema trasladó el servicio a la región alternativa. El procesamiento completo de mensajes FIN se reanudó alrededor de las 01:20 de la mañana siguiente, tras una secuencia de recuperaciones parciales y un reinicio manual de los servidores SWIFT.
• El desencadenante inmediato fue un defecto de software en equipos de red de terceros, activado por un parámetro de configuración durante la preparación para trabajos de red del fin de semana. Ese hecho no transfirió la responsabilidad operativa al proveedor. El operador controlaba la clasificación del cambio, el momento, las pruebas, la preparación para la reversión, la arquitectura del servicio, la escalada de conmutación por error y la comunicación con los participantes.
• El registro de impacto público respalda la evidencia de tráfico de pagos retrasados y rechazados, transferencias de liquidez interrumpidas, efectos en sistemas auxiliares, trabajo de conciliación y comportamiento inusual de liquidez. No respalda una cifra confiable agregada de pérdidas financieras. Aproximadamente 12 mil millones de euros de más de 900 transacciones rechazadas correspondían al valor de los pagos, no a pérdidas probadas, y unos 400 mil millones de euros menos en depósitos a un día fue una comparación de flujo de liquidez, no un daño.
• Una revisión independiente encontró 40 problemas en los cinco incidentes de los Servicios TARGET de 2020, incluidos 17 hallazgos de alta prioridad. Su conclusión más importante fue sistémica: la gestión de cambios, la planificación de la continuidad, las pruebas de conmutación por error, la documentación, las comunicaciones, la gobernanza y el marco de control no formaban un sistema operativo suficientemente integrado.
• El Eurosistema aceptó las conclusiones generales de la revisión y creó 155 acciones correctivas. En julio de 2025, informó que quedaba una acción por implementar. La evidencia posterior del servicio muestra cambios significativos, incluido un comité de riesgos independiente y una liquidación de contingencia utilizable durante un corte separado en 2025, pero también muestra que la resiliencia de los pagos mayoristas sigue siendo una obligación de rendición de cuentas continua, no un certificado de cierre único.

Un sistema de pagos cuya recuperación tiene consecuencias públicas

TARGET2 era el sistema de liquidación bruta en tiempo real del Eurosistema para pagos en euros cuando ocurrió el incidente. Los bancos comerciales, los bancos centrales y las infraestructuras de mercado lo utilizaban para liquidar obligaciones de alto valor y sensibles al tiempo en dinero de banco central. Por lo tanto, el sistema no era ni una aplicación corporativa ordinaria ni un canal de conveniencia que los usuarios pudieran simplemente abandonar durante unas horas.

Su disponibilidad afectaba las posiciones de liquidez de los bancos, los sistemas auxiliares, la financiación de la liquidación de valores y la finalización de los pagos que los bancos transmitían a los clientes.

La escala explica por qué la distinción es importante. ElInforme Anual de TARGET 2020dice que TARGET2 procesó 88,7 millones de transacciones por valor de 465,8 billones de euros ese año, con un promedio de 345.006 pagos y 1,8 billones de euros cada día hábil. Representó aproximadamente el 90 por ciento del valor liquidado en los sistemas de pagos de alto valor en euros. La mayor parte del volumen de transacciones no consistía en bancos centrales moviendo su propio dinero: el 83 por ciento correspondía a pagos de clientes e interbancarios clasificados como transferencias de terceros, mientras que el tráfico de sistemas auxiliares constituía otra parte material.

Ese rol público cambia el estándar de rendición de cuentas. Una explicación técnicamente correcta de un conmutador defectuoso es necesaria, pero no suficiente. El operador debe poder demostrar que un cambio riesgoso se clasificó y probó adecuadamente, que los sitios redundantes eran realmente recuperables, que se podía tomar una decisión de conmutación por error antes de que expirara el objetivo de recuperación, que los participantes sabían qué hacer y que se controlaban las obligaciones al final del día.

La evidencia también debe permitir a los organismos de supervisión y a los participantes afectados distinguir entre un riesgo residual inevitable y una falla de control prevenible.

TARGET2 tenía un diseño de resiliencia sofisticado sobre el papel. Funcionaba en cuatro sitios en dos regiones, con dos sitios en cada región. La estructura ofrecía tanto un sitio secundario en la región activa como una región alternativa. Un módulo de contingencia separado, comúnmente conocido como ECONS, estaba destinado a respaldar pagos críticos cuando la liquidación normal no estaba disponible. El incidente puso a prueba las tres capas: redundancia de componentes, recuperación en la misma región y recuperación entre regiones.

Dos de esas capas no produjeron un resultado operativo oportuno, y la tercera restauró el servicio solo después de que la jornada laboral normal se hubiera extendido hasta bien entrada la noche.

La lección central no es que la infraestructura compleja nunca pueda fallar. Es que la redundancia es una afirmación responsable. Debe tratarse como probada solo cuando pruebas similares a la producción, derechos de decisión claros, operadores capacitados, participantes localizables y evidencia de recuperación real la hagan realidad bajo estrés.

La cronología del incidente, con los límites de recuperación explícitos

El primer relato operativo público es lacomunicación del incidente del 23 de octubre del BCE. Registra que todos los servicios de liquidación dejaron de estar disponibles aproximadamente a las 14:40. Las instrucciones de pago, las instrucciones de sistemas auxiliares y las transferencias de liquidez hacia y desde TARGET2-Securities y TARGET Instant Payment Settlement no pudieron procesarse. El Módulo de Información y Control, la interfaz principal a través de la cual muchos participantes monitoreaban y gestionaban la actividad, tampoco estaba disponible.

Lapresentación conjunta del incidente de AMI-Pay y AMI-SeCoproporciona una secuencia adecuada para una auditoría, aunque aún deja sin publicar algunos detalles técnicos minuto a minuto. La primera llamada de los gestores de crisis de TARGET2 ocurrió a las 15:15, 35 minutos después de la pérdida del servicio. La primera comunicación con los participantes siguió a las 15:30. A las 16:30, se había informado que ECONS no estaba disponible. Los operadores continuaron los intentos de recuperación dentro de la región activa.

Aproximadamente a las 20:30, casi seis horas después del inicio de la interrupción, el Eurosistema concluyó que la recuperación en la misma región no era factible y decidió trasladar TARGET2 a la región italiana. La conmutación por error técnica entre regiones se completó aproximadamente a las 22:30. Este hito no significó que todo el tráfico de pagos se hubiera recuperado. El tráfico de sistemas auxiliares y de aplicación a aplicación se reanudó aproximadamente a las 23:10. El tráfico FIN se reanudó y luego se detuvo de nuevo porque los servidores conectados a SWIFT requerían un reinicio manual.

El procesamiento completo de mensajes FIN se reanudó aproximadamente a las 01:20 del sábado 24 de octubre.

El Eurosistema extendió el horario operativo. El plazo de corte para pagos de clientes se fijó a las 03:00 y el plazo de corte interbancario a las 03:30. Su informe dice que todas las instrucciones en cola, incluidas las transferencias de liquidez de T2S, se procesaron antes del cierre de la fecha valor a las 03:30. Se identificó un bloqueo en el módulo de facilidades permanentes alrededor de las 04:15. La siguiente fecha valor se abrió a las 05:10 y la liquidación nocturna para el lunes 26 de octubre comenzó a las 05:55.

Los operadores realizaron 17 llamadas de crisis y enviaron 15 mensajes a los participantes a través de la distribución de información de mercado y los canales RSS durante la respuesta.

La duración requiere cuidado porque los documentos públicos utilizan diferentes puntos finales. Elanuncio de la revisión independiente del BCEdescribió la interrupción como de "casi 10 horas". La revisión externa posterior utilizó aproximadamente 11 horas. Contando desde las 14:40 hasta el procesamiento completo de FIN a las 01:20 se producen aproximadamente 10 horas y 40 minutos, mientras que la finalización técnica entre regiones a las 22:30 produce un intervalo más corto y el cierre final del día produce uno más largo. Estas descripciones son reconciliables una vez que se establece el límite del servicio medido. No deben colapsarse en un solo número falsamente preciso.

La cronología también previene un error opuesto. Sería engañoso decir que TARGET2 simplemente perdió el día hábil y nunca liquidó sus colas. El registro oficial dice que la fecha valor permaneció abierta y las instrucciones pendientes se procesaron. Sería igualmente engañoso llamar a esa finalización al final del día un resultado de continuidad exitoso. Los servicios críticos no estuvieron disponibles durante muchas horas, los horarios de corte se movieron, algunos participantes no pudieron reenviar tráfico y los archivos de clientes posteriores se retrasaron.

La recuperación del libro mayor no borra la disrupción operativa necesaria para alcanzarlo.

Un dispositivo defectuoso fue el desencadenante, no la causa completa

Laactualización posterior al incidente del BCEidentificó un defecto de software en un dispositivo de red de terceros dentro de una red interna de un banco central como la causa técnica raíz. El Eurosistema declaró que el defecto no fue un incidente cibernético, que se habían tomado medidas correctivas y que TARGET2 y T2S operaron normalmente el 26 y 27 de octubre. Un pequeño número de investigaciones de pagos permanecieron en conciliación.

El relato independiente posterior proporciona el contexto de control. En preparación para la activación de nuevos conmutadores durante el próximo fin de semana, los ingenieros introdujeron un parámetro de configuración en la red 4CBnet-NG. El parámetro había funcionado en seis de ocho dispositivos. En los dispositivos afectados, desencadenó un comportamiento de software que desestabilizó la conectividad de la red y se extendió en cascada por ambos sitios de la región activa.

La función de asistencia técnica del proveedor conocía el defecto desde mayo de 2020, pero el problema no había aparecido en los manuales relevantes ni en las notas de la versión disponibles para el operador.

Esa secuencia crea dos proposiciones diferentes de rendición de cuentas. La primera está confirmada: un defecto latente del proveedor fue activado por un cambio en la red de producción. La segunda es una inferencia institucional respaldada: la duración y amplitud de la interrupción dependieron de las defensas controladas por el operador en torno a ese defecto. Un proveedor puede controlar el código fuente, la divulgación de defectos y el soporte técnico.

No controla si el propietario del sistema clasifica un cambio de red como capaz de tener impacto en el negocio, lo programa durante el horario de servicio, lo prueba en un entorno representativo, valida la reversión, protege ambos sitios de una falla de modo común, o escala a la región alternativa dentro del objetivo de recuperación.

Larevisión externa de Deloitte, encargada por el Eurosistema y publicada en forma abreviada, encontró debilidades en cada uno de esos puntos de defensa. Los cambios tratados como sin impacto en el negocio no siempre tenían un razonamiento documentado. La evidencia de las pruebas era incompleta. Algunos cambios en la infraestructura de red, hardware, energía y refrigeración podían tratarse como estándar y de bajo riesgo a pesar de su capacidad para detener servicios. La revisión no encontró un entorno de pruebas funcional para los cambios de red, lo que significaba que cambios importantes podían pasar directamente a producción. También encontró deficiencias en la revisión de la información de las versiones de los proveedores.

Por lo tanto, el modelo causal correcto es por capas. El defecto del proveedor explica por qué el conmutador se comportó inesperadamente. La gobernanza del cambio explica por qué ese comportamiento entró en producción sin una contención adecuada. La arquitectura y la preparación para la conmutación por error explican por qué una falla en un dominio de cambio podría afectar a ambos sitios en la región activa y resistir la recuperación en la misma región. La gobernanza de crisis explica el tiempo necesario para elegir la región alternativa.

Las comunicaciones y la preparación de los participantes explican por qué la restauración técnica no restableció inmediatamente todos los flujos de pago. Ninguna de esas capas requiere especulación sobre motivos personales. Son dominios de control documentados en la revisión pública.

La redundancia nominal se encontró con una falla de modo común

La interrupción expuso una debilidad recurrente en las afirmaciones de resiliencia: dos componentes o dos sitios pueden parecer redundantes mientras comparten una ruta de falla. Ambos sitios en la región activa dependían del entorno de red afectado. Por lo tanto, la recuperación intentada encontró la misma condición desestabilizante en lugar de evitarla. ECONS también no estaba disponible cuando los gestores de crisis buscaron por primera vez la opción de contingencia.

Cuando los operadores se comprometieron con la región alternativa, el punto de referencia de recuperación de dos horas utilizado para los sistemas de pago sistémicamente importantes ya había pasado.

El problema no fue simplemente que una conmutación por error tomara tiempo. La revisión encontró que los escenarios de conmutación por error se definían de manera inconsistente y a menudo eran específicos de componentes o estáticos en lugar de holísticos. Los sitios primario y secundario no siempre eran funcionalmente idénticos. No había un período de activación suficientemente claro que obligara a una decisión antes de que expirara el objetivo de tiempo de recuperación.

Las pruebas de conmutación por error de TARGET2 estaban vinculadas a rotaciones de sitios, y la revisión informó que tales pruebas no se realizaron entre las rotaciones de 2019 y 2020. Los informes de pruebas no agregaban de manera confiable las lecciones aprendidas para la mejora continua.

Un incidente anterior proporciona un contrafactual útil pero limitado. El 11 de agosto de 2020, TARGET2 sufrió una interrupción diferente y los operadores iniciaron la conmutación por error en la misma región a las 15:45. El nuevo sitio estuvo técnicamente disponible aproximadamente a las 16:43, aunque la restauración de los servicios residuales tomó más tiempo. La comparación en el informe anual muestra que la recuperación en la misma región podía funcionar bajo algunas condiciones de falla. También muestra por qué una prueba exitosa o una conmutación por error previa no pueden probar la resiliencia contra una falla de red de modo común.

Un conjunto de control válido necesitaba escenarios que eliminaran ambos sitios de la región activa, afectaran la interfaz de gestión, hicieran que el canal de contingencia no estuviera disponible y forzaran una decisión entre regiones con límite de tiempo.

El contrafactual debe enmarcarse como una prueba de control, no como una afirmación de que una decisión no observada ciertamente habría prevenido cada retraso. Si la configuración se hubiera ejercitado en un entorno de red funcionalmente representativo, el defecto del proveedor podría haberse detectado antes de la producción. Si los sitios se hubieran aislado del mismo efecto de cambio, el sitio secundario podría haber permanecido utilizable. Si las reglas de crisis hubieran requerido una decisión entre regiones lo suficientemente temprano para proteger el objetivo de dos horas, el procesamiento de pagos podría haberse reanudado antes.

Si la preparación de ECONS y el ensayo de los participantes hubieran sido más sólidos, el tráfico crítico podría haber continuado mientras se restauraba el servicio normal. Cada proposición está técnicamente respaldada por las recomendaciones de la revisión, pero el registro público no puede establecer los minutos exactos o las transacciones que cada control habría ahorrado.

Ese es el estándar apropiado para la rendición de cuentas contrafactual. Identifica quién controlaba una defensa faltante y qué resultado observable estaba diseñada para proteger la defensa. No convierte una alternativa plausible en una reconstrucción ficticia.

El daño a los pagos es más amplio que una estimación de pérdidas

Las interrupciones públicas de pagos crean varios tipos de daños que no deben reducirse a un solo número monetario. El primero es temporal: un pago aceptado o esperado llega más tarde de lo previsto por su originador, beneficiario o sistema vinculado. El segundo está relacionado con la liquidez: un banco no puede mover efectivo entre cuentas, financiar actividades de valores, liquidar una posición de un sistema auxiliar o colocar reservas según lo previsto. El tercero es operativo: el personal debe monitorear canales, extender horas operativas, reenviar instrucciones, conciliar estados de cuenta e investigar excepciones.

El cuarto está relacionado con la confianza: los participantes descubren que los caminos de contingencia y comunicación son más débiles de lo esperado.

La presentación del incidente informa que aproximadamente el 65 por ciento del tráfico del día y el 85 por ciento de su volumen de negocios ya se habían liquidado cuando ocurrió la interrupción. En comparación con los dos viernes anteriores, el volumen de negocios diario fue entre un 10 y un 15 por ciento menor y el tráfico entre un 3 y un 5 por ciento menor. Más de 900 transacciones, con un valor de pago combinado de aproximadamente 12 000 millones de euros, fueron rechazadas. Los efectos más grandes se informaron en varios componentes nacionales importantes y en el tráfico de sistemas auxiliares e interbancario.

Estos son indicadores materiales de flujo interrumpido. No son evidencia de que 12 000 millones de euros desaparecieron o se convirtieron en una pérdida económica.

El registro de los participantes añade consecuencias que el volumen agregado no revela. Algunos bancos y sistemas auxiliares no pudieron reenviar mensajes porque sus propios sistemas eran incapaces de hacerlo o ya habían cerrado. Las obligaciones críticas de los sistemas auxiliares se liquidaron, pero la falta de archivos de cámara de compensación automatizada para el tráfico SEPA retrasó las transferencias a los beneficiarios finales. Algunos participantes directos de T2S encontraron problemas de reasignación de garantías. Docenas de excepciones de pago requirieron conciliación.

Estas son formas creíbles de daño operativo incluso cuando los montos principales finalmente se liquidan.

El comportamiento de la liquidez también cambió. Once bancos utilizaron la facilidad marginal de crédito por un total combinado de 19 millones de euros. Los bancos colocaron aproximadamente 400 000 millones de euros menos en depósitos a un día de lo que sugeriría un patrón normal porque la oportunidad de mover el exceso de reservas estaba restringida. Esos 400 000 millones de euros son particularmente fáciles de malinterpretar. Es un cambio en la colocación de la liquidez del banco central, no una estimación pública de daños, pérdidas o fondos de clientes congelados.

La fuente no cuantifica los intereses no percibidos, los gastos de personal de los participantes, la compensación a los clientes o los costos comerciales indirectos.

El efecto sobre la infraestructura de valores fue selectivo más que total. Según elInforme Anual de T2S 2020, la liquidación de valores en T2S permaneció disponible, pero las transferencias de liquidez entre T2S y TARGET2 no pudieron procesarse. T2S extendió su propio horario, cerrando a las 03:30 y comenzando la siguiente liquidación nocturna a las 06:05. Esta distinción es importante: el incidente no hizo que todos los registros de valores no estuvieran disponibles, pero afectó la movilidad de efectivo de la que dependen las operaciones fluidas de entrega contra pago y garantías.

Ningún registro público accesible revisado para este análisis proporciona una cifra verificada de pérdidas económicas agregadas, un recuento completo de beneficiarios finales retrasados o un calendario de compensación participante por participante. La información responsable debe mantener esos como desconocidos. Un sistema puede causar una interrupción grave sin producir un total de pérdidas publicable, y la ausencia de ese total no debe confundirse con la prueba de que no hubo daño.

Quién controlaba qué

La rendición de cuentas se vuelve más clara cuando el control se asigna por función en lugar de solo por nombre institucional.

La estructura de gobernanza del operador era en sí misma parte de la revisión. Las funciones de Nivel 1 residían en el Consejo de Gobierno, las de Nivel 2 en la Junta de Infraestructura de Mercado y las de Nivel 3 en los bancos centrales prestadores de servicios. Deloitte describió la toma de decisiones como concentrada en altos niveles y el panorama de comités como complejo. La documentación no siempre establecía responsabilidades completas. Una función central de control de segunda línea con suficiente autoridad y un marco de control interno general no estaba completamente implementada.

Algunas cuestiones de supervisión identificadas previamente habían tardado demasiado en cerrarse.

Esto no significa que cada participante fuera pasivo o que cada retraso downstream se controlara centralmente. Un banco que carecía de capacidad de reenvío controlaba esa debilidad local. Un sistema auxiliar que había cerrado controlaba parte de su propia disponibilidad. También se esperaba que los participantes monitorearan canales de información específicos. Sin embargo, esas responsabilidades no cancelan los deberes del operador de infraestructura. El operador eligió la arquitectura de comunicación, proporcionó las reglas de contingencia, estableció el calendario de servicio y representó la resiliencia de la plataforma compartida.

La rendición de cuentas es concurrente, no una competencia en la que la debilidad de una parte absuelve a otra.

La relación con el proveedor sigue la misma lógica. Un defecto de software conocido pero no divulgado es un hecho grave de control de proveedores. El registro público no identifica al proveedor, divulga el contrato, muestra si se incumplió un deber de asesoramiento o indica si el Eurosistema recuperó el dinero. Esas incógnitas impiden un juicio legal sobre la responsabilidad del proveedor. No impiden un juicio operativo de que el propietario del sistema necesitaba controles independientes capaces de contener un defecto del proveedor.

El punto de referencia regulatorio y los límites del registro legal público

En el momento de la interrupción, TARGET2 se regía como un sistema de pagos sistémicamente importante según elReglamento del BCE sobre requisitos de supervisión para sistemas de pagos sistémicamente importantes. El artículo 15 exigía un marco sólido de riesgo operativo, disposiciones de continuidad del negocio y un sitio secundario. Las disposiciones debían diseñarse de modo que los sistemas informáticos críticos pudieran reanudarse en dos horas después de eventos disruptivos y la liquidación pudiera completarse al final del día hábil. Los planes debían probarse y revisarse al menos anualmente. El reglamento también exigía la gestión de los riesgos de los participantes críticos, otras infraestructuras y proveedores de servicios.

La línea base internacional era coherente. El Principio 17 de losPrincipios para infraestructuras de los mercados financieros de CPMI-IOSCOexige la identificación de los riesgos operativos internos y externos, sistemas y controles adecuados, un sitio secundario, la reanudación de las operaciones críticas en un plazo de dos horas y la finalización de la liquidación al final del día de la interrupción. También aborda los riesgos creados por proveedores de servicios críticos e infraestructuras vinculadas. Estas disposiciones convirtieron el tiempo de recuperación en un objetivo de gobernanza, no solo en una métrica de rendimiento técnico.

En la cronología pública, el procesamiento completo de pagos no se reanudó en dos horas. El sitio de la misma región y el módulo de contingencia no estaban disponibles, mientras que la decisión entre regiones ocurrió muchas horas después del inicio de la interrupción. Esa es una base sólida para comparar el rendimiento con el punto de referencia regulatorio. No es, por sí misma, una prueba de una violación formalmente adjudicada.

Los materiales revisados aquí no contienen una decisión ejecutiva pública que imponga una sanción por el incidente de octubre, una sentencia judicial que asigne responsabilidad o una conclusión de un regulador que resuelva todos los elementos de cumplimiento.

El contexto institucional hace que la evidencia sea especialmente importante. Ladescripción de la política de supervisión del BCEexplica que el Eurosistema recopila información, evalúa los sistemas frente a los estándares e induce cambios cuando es necesario. Los Servicios TARGET también se operan dentro del Eurosistema. Las funciones operativas y de supervisión son distintas, pero existen dentro de la misma institución pública más amplia. Sería especulativo afirmar que la independencia de la supervisión se vio comprometida en este caso. No obstante, es razonable exigir una separación visible de funciones, un desafío documentado y evidencia de cierre para que el público no tenga que confiar únicamente en la garantía institucional.

La compensación de pagos es otra área donde la precisión importa. LaDirectriz TARGET2entonces aplicable incluía un esquema de compensación para órdenes de pago aceptadas que no pudieran liquidarse en el mismo día hábil debido a un mal funcionamiento técnico. Abordaba las tarifas de administración, la compensación de intereses, las exclusiones y la relación entre la compensación aceptada y otras reclamaciones. Debido a que el Eurosistema dice que todas las instrucciones en cola se procesaron antes del cierre de la fecha valor extendida, el registro público del incidente no establece cuántas órdenes, si las hubo, calificaron, si se presentaron reclamaciones o qué se pagó. Los mensajes rechazados y los archivos downstream también pueden plantear cuestiones legales diferentes a las órdenes aceptadas en el sistema central.

Por lo tanto, la responsabilidad legal tiene un piso documentado y un resultado no documentado. El piso es el objetivo de diseño de recuperación de dos horas, la liquidación al final del día, las pruebas anuales y la gestión de riesgos de los proveedores de servicios. El resultado que sigue siendo desconocido incluye el tratamiento ejecutivo, las reclamaciones privadas, los montos de compensación y el recurso contractual contra el proveedor. Una evaluación creíble debe establecer ambos.

La revisión independiente convirtió un incidente en un diagnóstico del sistema

El Eurosistema encargó a Deloitte la revisión de cinco incidentes importantes de tecnología de la información de los Servicios TARGET que ocurrieron en 2020. El trabajo se realizó desde finales de diciembre de 2020 hasta marzo de 2021 y utilizó documentos, entrevistas y pruebas bajo una metodología de aseguramiento definida. El informe publicado fue abreviado y redactado por razones de seguridad y confidencialidad del cliente. No fue una auditoría general de todos los controles. Esos límites de alcance importan, pero no debilitan la importancia de los problemas que la revisión sí corroboró.

La revisión informó 40 hallazgos: 17 calificados como de alta prioridad, 17 medios y seis bajos, sin ninguno calificado como muy alto. Los agrupó en seis áreas problemáticas amplias: gestión de cambios y versiones; gestión de la continuidad del negocio; pruebas de conmutación por error y recuperación; protocolos de comunicación; gobernanza; y operaciones de centros de datos y tecnología de la información. El incidente de octubre afectó a las seis.

La documentación de continuidad del negocio estaba fragmentada y a veces desactualizada. Los roles detallados no se definían de manera coherente y la prueba de la capacitación era insuficiente. La revisión no recibió un análisis de impacto empresarial válido y actualizado que cubriera tanto TARGET2 como T2S. El análisis de T2S disponible databa de antes del lanzamiento del servicio en 2015 y no se había mantenido actualizado. Sin un análisis de impacto actualizado, las prioridades de recuperación, las dependencias y los supuestos de interrupción tolerable no pueden vincularse de manera confiable con la realidad empresarial actual.

La gestión de cambios carecía de un ciclo de vida común y rico en evidencia. La revisión encontró debilidades en la evaluación de riesgos, la clasificación, la documentación de pruebas, la aprobación y la planificación de la implementación. Los cambios durante las horas operativas no siempre recibían un tratamiento proporcional a su posible impacto. La preparación para la reversión y las dependencias de la infraestructura necesitaban controles más sólidos.

La información de las versiones de los proveedores y la ausencia de un entorno de pruebas de red representativo aumentaban la dependencia del comportamiento de producción como prueba definitiva.

La comunicación funcionó mejor dentro de la gobernanza de crisis que a través del perímetro de los participantes. La revisión encontró que las llamadas de crisis internas y la coordinación eran generalmente efectivas. Externamente, algunos participantes no conocían el sitio web de TARGET2 o no estaban suscritos a su canal RSS. Los mensajes de los bancos centrales nacionales podían divergir, y las comunicaciones no siempre decían a los participantes qué acción tomar. Las lecciones aprendidas no siempre tenían propietarios formales y fechas de finalización.

La documentación y la gestión de la configuración abarcaban todas estas áreas. La revisión encontró material operativo fragmentado u obsoleto y ninguna base de datos de gestión de configuración integral capaz de conectar activos, propietarios, dependencias y cambios. La evidencia de control a veces no estaba disponible. Esa deficiencia es importante porque la rendición de cuentas después de una falla compleja depende de reconstruir qué componente cambió, quién era su propietario, qué servicios dependían de él, qué prueba lo cubrió y qué aprobación aceptó el riesgo residual.

El resultado más importante de la revisión no fue, por lo tanto, una lista de 40 defectos aislados. Fue la evidencia de que las defensas alrededor de la infraestructura crítica de pagos no se gestionaban como un sistema coherente. Un defecto de dispositivo se convirtió en una interrupción de producción; las dependencias comunes vencieron la redundancia local; los desencadenantes poco claros consumieron tiempo de recuperación; las debilidades de comunicación redujeron la capacidad de acción de los participantes; y la evidencia fragmentada dificultó el aseguramiento.

El diagnóstico justificó una remediación en toda la gobernanza, no solo el reemplazo o la corrección del equipo de red.

El programa de reparación y lo que sus métricas demuestran y no demuestran

Larespuesta formal del Eurosistema a la revisión independienteaceptó las conclusiones y recomendaciones generales del informe. La aceptación fue un paso importante de rendición de cuentas porque evitó tratar el incidente como una anomalía irrepetible del proveedor. El paso más difícil fue convertir las recomendaciones en controles que pudieran observarse y probarse.

Elplan de acción de los Servicios TARGETpublicado lo hizo a través de seis líneas de trabajo correspondientes a la revisión. Las acciones de gestión de cambios incluían un ciclo de vida estandarizado, una evaluación de riesgos y seguridad más sólida, documentación común, verificaciones explícitas de reversión, una aprobación más alta para los cambios fuera de las ventanas de mantenimiento y el análisis de un entorno de pruebas de red dedicado. Las acciones de continuidad incluían procedimientos de crisis revisados, una guía para gestores de crisis, capacitación del personal, disposiciones holísticas de continuidad y una revisión anual de los análisis de impacto empresarial y los planes de continuidad.

Las acciones de conmutación por error fueron particularmente relevantes para la evidencia de octubre. Exigían roles clarificados, frecuencia de pruebas definida, un desencadenante de decisión que protegiera el objetivo de dos horas, escenarios más representativos, informes de pruebas comunes, pruebas periódicas de transacciones y simulaciones con participantes. Las acciones de comunicación buscaban avisos fácticos más rápidos, mejores canales de estado y suscripción, contacto directo con grupos de participantes críticos, mensajes alineados entre bancos centrales y depositarios de valores, y aprendizaje formal posterior al incidente.

Las acciones de gobernanza y tecnología cubrían un modelo operativo más simple, un inventario legal, una función de riesgo y control empoderada, un mejor monitoreo, acceso de monitoreo a la región alternativa, reglas para terceros, operaciones auditables y una base de datos de configuración con propietarios identificados.

El plan de acción también informó cambios operativos en lugar de solo promesas. Se implementaron procedimientos de activación de ECONS y se capacitó al personal. Se revisó la guía de crisis para que los tomadores de decisiones consideren la activación temprana de la contingencia y limiten el tiempo de inactividad frente al objetivo de recuperación de dos horas. Se introdujeron verificaciones regulares de la conectividad de los bancos centrales a la red de contingencia, junto con pruebas periódicas de transacciones y ejercicios más amplios. Estos son los tipos de controles que abordan directamente la ruta fallida.

Luego, los informes de progreso proporcionaron evidencia intermedia. Unaactualización de implementación de diciembre de 2022consolidó 155 acciones derivadas de la revisión externa, los hallazgos de supervisión y la auditoría interna. La Junta de Infraestructura de Mercado monitoreaba el trabajo mensualmente; la auditoría interna y los supervisores principales evaluaban la evidencia de respaldo; y el Consejo de Gobierno recibía informes semestrales. Al 31 de marzo de 2022, los evaluadores habían revisado 79 acciones: 58 estaban cerradas y 21 necesitaban más evidencia o mejora. Al 30 de septiembre, la junta informó que 121 de 155 estaban completadas, 16 en camino y 18 retrasadas, muchas porque dependían del programa de consolidación TARGET2-T2S.

La distinción entre "completado por la gerencia" y "cerrado después de la evaluación" es esencial. Un equipo de proyecto puede finalizar una acción sin probar que el control funciona. Por lo tanto, el uso del informe de 2022 de la revisión de evidencia por parte de la auditoría interna y la supervisión fue más sólido que un simple porcentaje de finalización. También reveló desviaciones en lugar de restablecer silenciosamente la línea base.

A finales de 2023, elInforme Anual de T2S 2023dijo que más del 90 por ciento de las medidas planificadas se habían implementado, y el resto se esperaba para 2024. En julio de 2025, lasdecisiones publicadas del Consejo de Gobiernoestablecieron que solo una de las 155 acciones aún necesitaba implementación y que el Comité de Auditores Internos continuaría monitoreándola. El Consejo puso fin al ciclo de informes anuales. Esa es una fuerte evidencia de una ejecución sostenida del programa. No es evidencia de que las 155 acciones estuvieran cerradas en julio de 2025, porque el Consejo preservó explícitamente un elemento abierto.

La gobernanza también continuó evolucionando. En septiembre de 2025, elConsejo de Gobierno revelóque se había completado una revisión organizativa de la gobernanza de los Servicios TARGET, solicitada originalmente en 2021, y que se informarían más medidas hasta 2027. Ese trabajo posterior no debe fusionarse automáticamente con la única acción restante, cuyo tema no se especifica en el aviso público. Muestra por qué "los informes del programa terminaron" no es lo mismo que "la mejora de la gobernanza terminó".

Las operaciones posteriores son la verdadera prueba de durabilidad

Los documentos de política pueden mostrar que los controles se diseñaron y asignaron. Solo la operación posterior puede mostrar si siguen siendo utilizables. ElInforme Anual de TARGET 2023registra que el servicio T2 consolidado no sufrió una suspensión completa en 2023, aunque experimentó incidentes menores. También informa el establecimiento de un Comité de Riesgos independiente de los Servicios TARGET a finales de 2023, respaldado por marcos de riesgo y control revisados. Esta es una evidencia relevante de que la debilidad de la gobernanza de segunda línea identificada después de 2020 recibió una respuesta institucional.

Una prueba mucho más difícil llegó el 27 de febrero de 2025. ElInforme Anual de los Servicios TARGET 2025, publicado en 2026, describe una falla separada de hardware y almacenamiento que interrumpió tanto T2 como T2S durante muchas horas. T2 no estuvo disponible durante aproximadamente 10 horas y T2S durante unas ocho. El hardware crítico y su redundancia fallaron. El diagnóstico inicial se centró en un problema de base de datos, lo que retrasó la decisión de cambiar de región. Los servicios regresaron después de las 18:00 y el día hábil cerró alrededor de la medianoche.

El evento de 2025 no puede presentarse como una recurrencia del mismo defecto de red, y no prueba que el plan de acción de 2020 fracasara por completo. Su valor es como una prueba de estrés en vivo. ECONS apoyó pagos críticos de T2 durante la interrupción posterior, evidencia de que una capacidad de contingencia no disponible en octubre de 2020 se había vuelto operativamente útil. Al mismo tiempo, la pérdida concurrente de T2 y T2S dificultó la movilización de garantías y retrasó los procesos conectados.

La revisión posterior al incidente generó 20 acciones; el informe dice que la mayoría se completaron para el cuarto trimestre de 2025, mientras que algunos elementos no críticos en el tiempo permanecieron en curso.

Ese resultado mixto es más informativo que una afirmación de victoria o una de fracaso. Un canal de contingencia procesó pagos críticos, pero el diagnóstico y la recuperación en la región alternativa consumieron nuevamente un tiempo sustancial. El sistema demostró una capacidad mejorada y expuso dependencias residuales. La rendición de cuentas duradera requiere que ambos hechos permanezcan visibles.

El trabajo aún estaba activo en 2026. Elresultado de la reunión de AMI-Pay de mayo de 2026registra la consulta sobre las extensiones del día operativo y el uso de ECONS después del incidente de 2025. El Eurosistema y los bancos centrales nacionales todavía estaban determinando cuántas horas serían necesarias para procesar la mayoría de los pagos críticos en ECONS y cuándo deberían comenzar los preparativos para cerrar el día allí. Los participantes también destacaron la necesidad de evitar instrucciones duplicadas y efectos adversos en sus sistemas internos. Esto no es una prueba de una acción no resuelta de 2020. Es evidencia de que la liquidación de contingencia es un ecosistema operativo que involucra el comportamiento del operador y de los participantes, y que sus procedimientos deben continuar refinándose después de eventos reales.

Hechos confirmados, inferencia respaldada e incógnitas

Hechos confirmados.Los servicios de liquidación de TARGET2 dejaron de estar disponibles aproximadamente a las 14:40 del 23 de octubre de 2020. El Módulo de Información y Control, las transferencias de liquidez que involucraban a T2S y TIPS, la liquidación normal de pagos y las instrucciones de sistemas auxiliares se vieron afectados. La recuperación en la misma región no restauró el servicio, ECONS no estaba disponible durante la respuesta inicial, y el Eurosistema eligió la conmutación por error entre regiones aproximadamente a las 20:30. El procesamiento completo de FIN se reanudó aproximadamente a las 01:20. La fecha valor se extendió y el operador dice que todas las colas restantes se procesaron antes del cierre de las 03:30.

También se confirma que un parámetro de configuración activó un defecto de software en equipos de red de terceros, que el proveedor conocía el defecto y que el defecto no estaba documentado para el operador en el material de la versión relevante. El incidente no se atribuyó a un ciberataque. Los informes públicos registran tráfico rechazado, archivos downstream retrasados, transferencias de liquidez restringidas, trabajo de conciliación y un comportamiento alterado de los depósitos a un día.

La revisión independiente documentó 40 hallazgos en todos los incidentes de 2020 y el Eurosistema creó 155 acciones correctivas, de las cuales una aún estaba pendiente de implementación en julio de 2025.

Inferencia respaldada.La escala y duración de la interrupción no fueron determinadas únicamente por el defecto del dispositivo. Las debilidades en la evaluación de cambios, las pruebas representativas, el aislamiento de modo común, los desencadenantes de conmutación por error, la preparación para contingencias y la comunicación con los participantes eliminaron o retrasaron defensas que estaban bajo el control del operador. Esta inferencia está respaldada por la revisión externa y por la correspondencia directa entre sus hallazgos y el plan de acción.

También es razonable inferir que preservar la fecha valor y procesar todas las colas redujo las consecuencias de la finalidad de liquidación y el riesgo principal en comparación con un día no recuperado. Las fuentes no permiten cuantificar esa reducción. Del mismo modo, el uso exitoso posterior de ECONS en 2025 respalda la inferencia de que la capacidad de contingencia mejoró después de 2020, pero no aísla qué acción produjo la mejora ni prueba que todos los escenarios estén ahora cubiertos.

Incógnitas.El registro público no nombra al proveedor del equipo, divulga su contrato ni muestra si se buscaron recursos contractuales. No proporciona registros de configuración completos, todos los registros de decisiones internas, colas a nivel de participante ni la razón exacta por la que cada banco no pudo reenviar tráfico. La revisión abreviada retiene información técnica sensible y de clientes. Estos límites impiden una reconstrucción completa de las acciones individuales y la responsabilidad legal.

Se desconoce el coste económico total. No existe un agregado verificado de pérdidas de clientes, coste de liquidez, horas extras del personal, coste de oportunidad, compensación, reclamaciones o recuperación del proveedor. Las fuentes públicas no establecen si la interrupción de octubre generó una decisión formal de infracción regulatoria, una sanción o un caso judicial. Tampoco identifican el último elemento restante entre las 155 acciones en el aviso de julio de 2025 ni proporcionan evidencia de prueba pública para cada acción cerrada. Estas ausencias deben permanecer visibles en lugar de ser rellenadas con estimaciones.

Una prueba duradera de rendición de cuentas para la infraestructura de pagos mayoristas

El incidente respalda una prueba práctica que puede aplicarse a los Servicios TARGET y otras plataformas de pago sistémicamente importantes. La rendición de cuentas es duradera solo cuando las siguientes proposiciones pueden responderse con evidencia en lugar de garantía.

Primero, ¿puede el operador mapear cada servicio crítico a la infraestructura y dependencias de su propiedad?Una base de datos de configuración actualizada debe conectar dispositivos, software, sitios, redes, proveedores, servicios empresariales, propietarios responsables y procedimientos de recuperación. Un cambio en un parámetro de red debe revelar todos los servicios y dominios de redundancia que puede afectar.

Segundo, ¿son las decisiones de cambio proporcionales al posible impacto en el servicio?La clasificación no debe hacer que el trabajo fundamental de red, energía, almacenamiento o refrigeración sea de bajo riesgo simplemente porque parece rutinario. La evidencia debe incluir razonamiento de impacto empresarial, pruebas representativas, revisión por pares, ventanas de implementación aprobadas, monitoreo, condiciones de parada y una reversión ensayada.

Tercero, ¿es la redundancia independiente bajo los escenarios que importan?Dos sitios no proporcionan dos defensas cuando un cambio o plano de control puede deshabilitar ambos. Las pruebas deben incluir la pérdida de una región activa, la pérdida de interfaces de gestión, la degradación de servicios conectados y la falla de la ruta de contingencia nominal. Las configuraciones de producción y copia de seguridad deben ser funcionalmente equivalentes cuando la recuperación depende de la equivalencia.

Cuarto, ¿obliga la gobernanza de crisis a tomar una decisión antes de que expire el objetivo de recuperación?Las reglas de escalada deben especificar quién puede invocar el procesamiento en la misma región, en la región alternativa y de contingencia, qué evidencia necesitan y la hora límite para la decisión. Un objetivo de recuperación de dos horas no puede cumplirse mediante un comité al que se le permite seguir diagnosticando más allá de dos horas sin elegir una ruta alternativa.

Quinto, ¿pueden los participantes actuar según la comunicación?Un mensaje de estado debe ser oportuno, accesible y operativamente específico. Debe indicar qué servicios están afectados, qué deben detener o continuar los participantes, si los mensajes deben reenviarse, qué plazo de corte se aplica y cuándo llegará la próxima actualización. Los grupos críticos requieren rutas de contacto probadas más allá de una página web que algunos usuarios no saben que existe.

Sexto, ¿puede el procesamiento de contingencia manejar tráfico crítico realista?ECONS o cualquier capacidad sucesora debe probarse con bancos centrales, bancos comerciales y sistemas auxiliares utilizando patrones de mensajes reales y volúmenes realistas. Las pruebas deben cubrir la evitación de duplicados, la liquidez, las restricciones de garantía, el cierre al final del día y la transición de vuelta al servicio normal. La conectividad por sí sola no es suficiente.

Séptimo, ¿se miden los daños y las excepciones a lo largo de toda la cadena de pagos?Las métricas del operador deben distinguir las instrucciones en cola, rechazadas, reenviadas, duplicadas, retrasadas y finalmente liquidadas. Deben capturar archivos auxiliares, transferencias de liquidez, casos de conciliación y retraso de beneficiarios downstream sin etiquetar erróneamente el principal del pago como pérdida financiera.

Octavo, ¿una función de control independiente desafía el cierre?La finalización de la gerencia, la validación de segunda línea, la evaluación de la auditoría interna y el cierre de la supervisión son etapas diferentes. Las acciones de alta prioridad deben conservar propietarios, plazos y evidencia hasta que un revisor independiente confirme la operación, no solo el diseño.

Noveno, ¿son visibles los recursos legales y de los participantes?La infraestructura pública no necesita divulgar reclamaciones sensibles, pero debe explicar el marco de compensación aplicable, el tratamiento agregado de reclamaciones cuando sea legal y si se buscó la responsabilidad del proveedor o del participante. El silencio no debe convertirse en una suposición de que no se disponía o necesitaba ningún recurso.

Décimo, ¿aprende la institución nuevamente después del próximo incidente?Una falla posterior debe compararse con los compromisos de control anteriores. La evidencia de un mejor uso de la contingencia merece crédito; el retraso repetido en el diagnóstico o la conmutación por error merece examen. Un programa completado debe convertirse en una línea base operativa mantenida, no en un archivo.

Estas pruebas evitan dos extremos inútiles. Uno trata cada interrupción como una prueba de que la inversión en resiliencia fracasó, un estándar imposible para sistemas complejos. El otro acepta diagramas de arquitectura, recuentos de acciones y una alta disponibilidad anual como prueba de que la continuidad funciona. El punto medio defendible es exigente pero medible: ocurrirán fallas, y la institución responsable debe demostrar que la prevención fue proporcionada, la recuperación fue oportuna, los daños se controlaron, las decisiones fueron reconstruibles y las mismas debilidades no persisten sin ser cuestionadas.

Conclusión

La interrupción de TARGET2 de octubre de 2020 comenzó con un defecto de software de terceros, pero se convirtió en un evento de rendición de cuentas porque varias defensas del operador fallaron juntas. Un cambio en la red de producción activó el defecto. Ambos sitios en la región activa estaban expuestos. La recuperación en la misma región y la liquidación de contingencia no estaban disponibles. La conmutación por error entre regiones llegó después de horas de intentos de recuperación. Las comunicaciones no equiparon a todos los participantes para responder, y el día hábil tuvo que extenderse hasta la madrugada del sábado.

El Eurosistema finalmente procesó sus colas y preservó la fecha valor, encargó una revisión independiente, aceptó un diagnóstico sistémico y llevó a cabo un gran programa de remediación con informes de progreso externalizados. Esas son acciones de rendición de cuentas sustanciales. La creación posterior de un comité de riesgos independiente y el uso operativo de ECONS durante un corte diferente en 2025 añaden evidencia de que algunos controles importantes cambiaron.

El registro no es una base para declarar la resiliencia completa. Una de las 155 acciones permanecía abierta en julio de 2025, las medidas de gobernanza continuaron en un cronograma posterior, y el incidente de 2025 expuso nuevas dificultades en el diagnóstico, la redundancia y las dependencias simultáneas del servicio. Tampoco es el registro una base para inventar pérdidas, violaciones legales o culpas individuales que la evidencia oficial no establece.

TARGET2 hizo de la recuperación misma la prueba. Para la infraestructura de pagos compartida, la rendición de cuentas no se satisface identificando el componente defectuoso o informando la disponibilidad anual. Se satisface cuando las instituciones con control práctico pueden demostrar que los cambios están contenidos, las decisiones de conmutación por error protegen el tiempo de recuperación prometido, los canales de contingencia funcionan con participantes reales, los pagos retrasados y los efectos de liquidez se miden honestamente, la supervisión puede desafiar al operador, y las reparaciones sobreviven al próximo choque operativo.