TARGET2: Wiederherstellung der Zahlungsinfrastruktur als Rechenschaftstest

Zusammenfassung

• Die Abwicklungsdienste von TARGET2 wurden am 23. Oktober 2020 gegen 14:40 MEZ nicht mehr verfügbar. Die regionsgleiche Wiederherstellung funktionierte nicht, das Kontingenzmodul war nicht verfügbar, und das Eurosystem verlagerte den Dienst in die alternative Region. Die vollständige FIN-Nachrichtenverarbeitung wurde gegen 01:20 Uhr am nächsten Morgen nach einer Reihe von teilweisen Wiederherstellungen und einem manuellen Neustart der SWIFT-Server wieder aufgenommen.
• Der unmittelbare Auslöser war ein Softwarefehler in Netzwerkgeräten von Drittanbietern, der durch einen Konfigurationsparameter während der Vorbereitung auf Netzwerkarbeiten am Wochenende aktiviert wurde. Diese Tatsache übertrug die operationelle Verantwortung nicht auf den Anbieter. Der Betreiber kontrollierte die Änderungsklassifizierung, das Timing, die Tests, die Rollback-Bereitschaft, die Servicearchitektur, die Failover-Eskalation und die Teilnehmerkommunikation.
• Die öffentlichen Auswirkungsaufzeichnungen belegen verspätete und abgelehnte Zahlungsverkehrsströme, unterbrochene Liquiditätstransfers, Auswirkungen auf Nebensysteme, Abstimmungsarbeiten und ungewöhnliches Liquiditätsverhalten. Sie stützen keine zuverlässige aggregierte finanzielle Verlustzahl. Von den mehr als 900 abgelehnten Transaktionen war etwa 12 Milliarden EUR Zahlungswert, kein nachgewiesener Verlust, und rund 400 Milliarden EUR weniger bei Einlagen über Nacht war ein Liquiditätsflussvergleich, kein Schaden.
• Eine unabhängige Prüfung ergab 40 Probleme bei den fünf TARGET Services-Vorfällen des Jahres 2020, darunter 17 Prioritätsbefunde. Die wichtigste Schlussfolgerung war systemisch: Änderungsmanagement, Kontinuitätsplanung, Failover-Tests, Dokumentation, Kommunikation, Governance und das Kontrollrahmenwerk bildeten kein ausreichend integriertes Betriebssystem.
• Das Eurosystem akzeptierte die allgemeinen Schlussfolgerungen der Überprüfung und erstellte 155 Abhilfemaßnahmen. Bis Juli 2025 berichtete es, dass eine Maßnahme noch umzusetzen sei. Spätere Servicenachweise zeigen bedeutende Änderungen, darunter ein unabhängiges Risikokomitee und eine nutzbare Kontingenzabwicklung während eines separaten Ausfalls im Jahr 2025, aber sie zeigen auch, dass die Widerstandsfähigkeit des Großzahlungsverkehrs eine kontinuierliche Rechenschaftspflicht bleibt und nicht ein einmaliges Abschlusszertifikat.

Ein Zahlungssystem, dessen Wiederherstellung öffentliche Konsequenzen hat

TARGET2 war zum Zeitpunkt des Vorfalls das Echtzeit-Bruttoabwicklungssystem des Eurosystems für Zahlungen in Euro. Geschäftsbanken, Zentralbanken und Marktinfrastrukturen nutzten es, um hochwertige und zeitkritische Verpflichtungen in Zentralbankgeld abzuwickeln. Das System war daher weder eine gewöhnliche Unternehmensanwendung noch ein praktischer Kanal, den die Nutzer einfach für einige Stunden aufgeben konnten. Seine Verfügbarkeit beeinflusste die Liquiditätspositionen der Banken, Nebensysteme, die Wertpapierabwicklungsfinanzierung und die Durchführung von Zahlungen, die Banken an Kunden weitergaben.

Der Maßstab erklärt, warum die Unterscheidung wichtig ist. DerTARGET-Jahresbericht 2020sagt, dass TARGET2 in diesem Jahr 88,7 Millionen Transaktionen im Wert von 465,8 Billionen EUR verarbeitete, durchschnittlich 345.006 Zahlungen und 1,8 Billionen EUR pro Geschäftstag. Es machte etwa 90 Prozent des in Euro abgewickelten Wertes in Großzahlungssystemen aus. Das meiste Transaktionsvolumen war nicht auf Zentralbanken zurückzuführen, die ihr eigenes Geld bewegten: 83 Prozent bestanden aus Kunden- und Interbankenzahlungen, die als Drittparteitransfers klassifiziert wurden, während der Verkehr von Nebensystemen einen weiteren wesentlichen Anteil ausmachte.

Diese öffentliche Rolle ändert den Maßstab für Rechenschaftspflicht. Eine technisch korrekte Erklärung eines defekten Schalters ist notwendig, aber nicht ausreichend. Der Betreiber muss nachweisen können, dass eine riskante Änderung angemessen klassifiziert und getestet wurde, dass redundante Standorte tatsächlich wiederherstellbar waren, dass eine Entscheidung zum Failover vor Ablauf des Wiederherstellungsziels getroffen werden konnte, dass die Teilnehmer wussten, was zu tun ist, und dass die Verpflichtungen zum Tagesende kontrolliert wurden.

Die Beweise müssen es Aufsichtsbehörden und betroffenen Teilnehmern auch ermöglichen, ein unvermeidbares Restrisiko von einem vermeidbaren Kontrollversagen zu unterscheiden.

TARGET2 hatte auf dem Papier ein anspruchsvolles Resilienzdesign. Es lief über vier Standorte in zwei Regionen, mit zwei Standorten pro Region. Die Struktur bot sowohl einen sekundären Standort in der aktiven Region als auch eine alternative Region. Ein separates Kontingenzmodul, allgemein als ECONS bezeichnet, sollte kritische Zahlungen unterstützen, wenn die normale Abwicklung nicht verfügbar war. Der Vorfall testete alle drei Ebenen: Komponentenredundanz, regionsgleiche Wiederherstellung und regionsübergreifende Wiederherstellung.

Zwei dieser Ebenen lieferten kein rechtzeitiges operatives Ergebnis, und die dritte stellte den Dienst erst wieder her, nachdem der normale Geschäftstag tief in die Nacht verlängert worden war.

Die zentrale Lehre ist nicht, dass komplexe Infrastruktur niemals ausfallen kann. Es ist, dass Redundanz eine rechenschaftspflichtige Behauptung ist. Sie sollte nur dann als bewiesen gelten, wenn produktionsähnliche Tests, klare Entscheidungsrechte, geschulte Operateure, erreichbare Teilnehmer und Nachweise einer tatsächlichen Wiederherstellung sie unter Stress wahr machen.

Die Ereigniszeitlinie, mit explizit gemachten Wiederherstellungsgrenzen

Der erste öffentliche operative Bericht ist dieEreigniskommunikation der EZB vom 23. Oktober. Sie verzeichnet, dass alle Abwicklungsdienste gegen 14:40 Uhr nicht mehr verfügbar waren. Zahlungsanweisungen, Anweisungen von Nebensystemen und Liquiditätstransfers zu und von TARGET2-Securities (T2S) und TARGET Instant Payment Settlement (TIPS) konnten nicht verarbeitet werden. Das Informations- und Kontrollmodul, die wichtigste Schnittstelle, über die viele Teilnehmer ihre Aktivitäten überwachten und verwalteten, war ebenfalls nicht verfügbar.

Die detaillierteregemeinsame AMI-Pay- und AMI-SeCo-Vorfallpräsentationliefert eine für eine Prüfung geeignete Abfolge, während einige minütliche technische Details unveröffentlicht bleiben. Die erste Krisenmanager-Besprechung zu TARGET2 fand um 15:15 Uhr statt, 35 Minuten nach dem Dienstausfall. Die erste Teilnehmerkommunikation folgte um 15:30 Uhr. Bis 16:30 Uhr wurde ECONS als nicht verfügbar gemeldet. Die Operateure setzten die Versuche zur Wiederherstellung innerhalb der aktiven Region fort.

Gegen 20:30 Uhr, fast sechs Stunden nach Beginn des Ausfalls, kam das Eurosystem zu dem Schluss, dass eine regionsgleiche Wiederherstellung nicht machbar war, und beschloss, TARGET2 in die italienische Region zu verlagern. Der technische regionsübergreifende Failover war gegen 22:30 Uhr abgeschlossen. Dieser Meilenstein bedeutete nicht, dass der gesamte Zahlungsverkehr wiederhergestellt war. Der Verkehr von Nebensystemen und Anwendung-zu-Anwendung wurde gegen 23:10 Uhr wieder aufgenommen. Der FIN-Verkehr wurde wieder aufgenommen und dann wieder gestoppt, weil die SWIFT-verbundenen Server einen manuellen Neustart erforderten.

Die vollständige FIN-Nachrichtenverarbeitung wurde gegen 01:20 Uhr am Samstag, den 24. Oktober, wieder aufgenommen.

Das Eurosystem verlängerte den Betriebsplan. Der Kundenzahlungsschluss wurde auf 03:00 Uhr und der Interbankenschluss auf 03:30 Uhr festgelegt. Laut Konto wurden alle zurückgestellten Anweisungen, einschließlich Liquiditätstransfers von T2S, verarbeitet, bevor der Valutatag um 03:30 Uhr schloss. Eine Blockade im Standing-Facilities-Modul wurde gegen 04:15 Uhr festgestellt. Der nächste Valutatag wurde um 05:10 Uhr eröffnet, und die nächtliche Abwicklung für Montag, den 26. Oktober, begann um 05:55 Uhr.

Die Operateure hielten 17 Krisentelefonate ab und verschickten 15 Teilnehmernachrichten über die Marktinformationsverteilungs- und RSS-Kanäle im Laufe der Reaktion.

Die Dauer erfordert Vorsicht, da öffentliche Dokumente unterschiedliche Endpunkte verwenden. In derAnkündigung der unabhängigen Überprüfungder EZB wurde die Unterbrechung als "fast 10 Stunden" beschrieben. Die spätere externe Überprüfung verwendete etwa 11 Stunden. Zählt man von 14:40 Uhr bis zur vollständigen FIN-Verarbeitung um 01:20 Uhr, ergibt sich etwa 10 Stunden und 40 Minuten, während der technische regionsübergreifende Abschluss um 22:30 Uhr ein kürzeres Intervall und der endgültige Tagesschluss ein längeres ergibt. Diese Beschreibungen sind vereinbar, sobald die gemessene Dienstgrenze angegeben wird. Sie sollten nicht zu einer einzigen falsch genauen Zahl zusammengefasst werden.

Der Zeitplan verhindert auch einen entgegengesetzten Fehler. Es wäre irreführend zu sagen, dass TARGET2 einfach den Geschäftstag verloren und seine Warteschlangen nie abgewickelt habe. Der offizielle Bericht sagt, dass der Valutatag offen blieb und ausstehende Anweisungen verarbeitet wurden. Es wäre ebenso irreführend, diesen Tagesschluss als erfolgreiches Kontinuitätsergebnis zu bezeichnen. Kritische Dienste waren viele Stunden lang nicht verfügbar, Grenzzeiten wurden verschoben, einige Teilnehmer konnten den Verkehr nicht erneut senden, und nachgelagerte Kundendateien wurden verzögert.

Die Wiederherstellung des Hauptbuchs löscht nicht die operationelle Störung, die erforderlich war, um es zu erreichen.

Ein defektes Gerät war der Auslöser, nicht die vollständige Ursache

DasUpdate nach dem Vorfallder EZB identifizierte einen Softwarefehler in einem Netzwerkgerät eines Drittanbieters innerhalb eines zentralbankinternen Netzwerks als technische Grundursache. Das Eurosystem erklärte, dass der Vorfall kein Cybervorfall sei, Korrekturmaßnahmen ergriffen worden seien und TARGET2 und T2S am 26. und 27. Oktober normal funktionierten. Eine kleine Anzahl von Zahlungsuntersuchungen verblieb in der Abstimmung.

Der spätere unabhängige Bericht liefert den Kontrollkontext. In Vorbereitung auf die Aktivierung neuer Switches am kommenden Wochenende führten Ingenieure einen Konfigurationsparameter im 4CBnet-NG-Netzwerk ein. Der Parameter hatte auf sechs von acht Geräten funktioniert. Auf den betroffenen Geräten löste er ein Softwareverhalten aus, das die Netzwerkkonnektivität destabilisierte und auf beide Standorte in der aktiven Region übergriff. Die technische Unterstützungsfunktion des Anbieters kannte den Fehler seit Mai 2020, aber das Problem war in den dem Betreiber verfügbaren relevanten Handbüchern oder Versionshinweisen nicht aufgetreten.

Diese Abfolge schafft zwei unterschiedliche Rechenschaftsbehauptungen. Die erste ist bestätigt: Ein latenter Anbieterfehler wurde durch eine Änderung im Produktionsnetzwerk aktiviert. Die zweite ist eine gestützte institutionelle Schlussfolgerung: Die Dauer und Breite der Unterbrechung hing von den vom Betreiber kontrollierten Abwehrmaßnahmen um diesen Fehler ab. Ein Anbieter kann Quellcode, Fehleroffenlegung und technischen Support kontrollieren.

Er kontrolliert nicht, ob der Systembesitzer eine Netzwerkänderung als geschäftsbeeinträchtigend einstuft, sie während der Dienstzeiten plant, in einer repräsentativen Umgebung testet, das Rollback validiert, beide Standorte vor einem gemeinsamen Fehlermodus schützt oder innerhalb der Wiederherstellungsfrist zur alternativen Region eskaliert.

Dieexterne Überprüfung von Deloitte, die vom Eurosystem in Auftrag gegeben und in gekürzter Form veröffentlicht wurde, fand Schwachstellen an jedem dieser Verteidigungspunkte. Änderungen, die als nicht geschäftsbeeinträchtigend eingestuft wurden, hatten nicht immer eine dokumentierte Begründung. Testnachweise waren unvollständig. Einige Änderungen an Netzwerk-, Hardware-, Strom- und Kühlungsinfrastruktur konnten trotz ihrer Fähigkeit, Dienste zu stoppen, als Standard und risikoarm behandelt werden. Die Überprüfung fand keine funktionale Testumgebung für Netzwerkänderungen, was bedeutete, dass wichtige Änderungen direkt in die Produktion gehen konnten. Es wurden auch Mängel bei der Überprüfung von Lieferantenfreigabeinformationen festgestellt.

Das korrekte Kausalmodell ist daher geschichtet. Der Anbieterfehler erklärt, warum sich der Switch unerwartet verhielt. Die Änderungs-Governance erklärt, warum das Verhalten ohne ausreichende Eindämmung in die Produktion gelangte. Die Architektur und Failover-Bereitschaft erklären, warum ein Fehler in einem Änderungsbereich beide Standorte in der aktiven Region betreffen und einer regionsgleichen Wiederherstellung widerstehen konnte. Die Krisen-Governance erklärt die Zeit, die für die Wahl der alternativen Region benötigt wurde.

Kommunikation und Teilnehmerbereitschaft erklären, warum die technische Wiederherstellung nicht sofort jeden Zahlungsfluss wiederherstellte. Keine dieser Schichten erfordert Spekulationen über persönliche Motive. Es sind Kontrollbereiche, die in der öffentlichen Überprüfung dokumentiert sind.

Nominelle Redundanz traf auf einen gemeinsamen Fehlermodus

Der Ausfall offenbarte eine wiederkehrende Schwäche in Resilienzbehauptungen: Zwei Komponenten oder zwei Standorte können redundant erscheinen, während sie einen gemeinsamen Fehlerpfad teilen. Beide Standorte in der aktiven Region hingen von der betroffenen Netzwerkumgebung ab. Die versuchte Wiederherstellung traf daher auf denselben destabilisierenden Zustand, anstatt ihm zu entkommen. ECONS war ebenfalls nicht verfügbar, als die Krisenmanager zuerst die Kontingenzoption suchten.

Als sich die Operateure für die alternative Region entschieden, war der für systemisch wichtige Zahlungssysteme verwendete Zwei-Stunden-Wiederherstellungsbenchmark bereits überschritten.

Das Problem war nicht nur, dass ein Failover Zeit in Anspruch nahm. Die Überprüfung ergab, dass Failover-Szenarien inkonsistent definiert und oft komponentenspezifisch oder statisch statt ganzheitlich waren. Primäre und sekundäre Standorte waren nicht immer funktional identisch. Es gab keinen ausreichend klaren Auslösezeitraum, der eine Entscheidung vor Ablauf der Wiederherstellungszeit erzwingt. TARGET2-Failover-Tests waren an Standortrotationen gebunden, und die Überprüfung berichtete, dass solche Tests zwischen den Rotationen 2019 und 2020 nicht durchgeführt wurden.

Die Testberichterstattung aggregierte Lehren nicht zuverlässig in kontinuierliche Verbesserungen.

Ein früherer Vorfall liefert ein nützliches, aber begrenztes Kontrafaktisches. Am 11. August 2020 erlitt TARGET2 eine andere Unterbrechung, und die Operateure leiteten um 15:45 Uhr einen regionsgleichen Failover ein. Der neue Standort war technisch um etwa 16:43 Uhr verfügbar, obwohl die Wiederherstellung der restlichen Dienste länger dauerte. Der Vergleich im Jahresbericht zeigt, dass regionsgleiche Wiederherstellung unter bestimmten Fehlerbedingungen funktionieren kann. Er zeigt auch, warum ein erfolgreicher Test oder ein vorheriger Failover die Resilienz gegen einen gemeinsamen Netzwerkfehler nicht beweisen kann.

Ein gültiger Kontrollsatz benötigte Szenarien, die beide aktiven Regionen-Standorte entfernten, die Managementschnittstelle beeinträchtigten, den Kontingenzkanal unverfügbar machten und eine zeitgebundene regionsübergreifende Entscheidung erzwangen.

Das kontrafaktische Szenario sollte als Kontrolltest formuliert werden, nicht als Behauptung, dass eine nicht beobachtete Entscheidung jede Verzögerung sicher verhindert hätte. Wäre die Konfiguration in einer funktional repräsentativen Netzwerkumgebung durchgeführt worden, hätte der Anbieterfehler vor der Produktion erkannt werden können. Wären die Standorte von demselben Änderungseffekt isoliert gewesen, wäre der sekundäre Standort möglicherweise nutzbar geblieben.

Hätten Krisenregeln eine regionsübergreifende Entscheidung früh genug gefordert, um das Zwei-Stunden-Ziel zu schützen, hätte die Zahlungsverarbeitung möglicherweise früher wieder aufgenommen werden können. Wären die ECONS-Bereitschaft und die Teilnehmerübungen stärker gewesen, hätte kritischer Verkehr fortgesetzt werden können, während der normale Dienst wiederhergestellt wurde. Jede Behauptung wird technisch durch die Empfehlungen der Überprüfung gestützt, aber die öffentliche Aufzeichnung kann nicht die genauen Minuten oder Transaktionen festlegen, die jede Kontrolle eingespart hätte.

Das ist der angemessene Maßstab für kontrafaktische Rechenschaftspflicht. Er identifiziert, wer eine fehlende Verteidigung kontrollierte und welches beobachtbare Ergebnis die Verteidigung schützen sollte. Er macht aus einer plausiblen Alternative keine fiktive Rekonstruktion.

Zahlungsschaden ist umfassender als eine Verlustschätzung

Öffentliche Zahlungsausfälle verursachen verschiedene Arten von Schäden, die nicht auf eine einzelne Währungszahl reduziert werden sollten. Der erste ist zeitlicher Natur: Eine angenommene oder erwartete Zahlung kommt später an, als vom Urheber, Begünstigten oder verbundenen System geplant. Der zweite betrifft Liquidität: Eine Bank kann kein Bargeld zwischen Konten bewegen, Wertpapieraktivitäten finanzieren, eine Nebensystemposition abwickeln oder Reserven wie beabsichtigt platzieren.

Der dritte ist operativer Natur: Mitarbeiter müssen Kanäle überwachen, Betriebszeiten verlängern, Anweisungen erneut senden, Kontoauszüge abstimmen und Ausnahmen untersuchen. Der vierte betrifft das Vertrauen: Teilnehmer stellen fest, dass Kontingenz- und Kommunikationswege schwächer sind als erwartet.

Die Vorfallpräsentation berichtet, dass etwa 65 Prozent des Tagesverkehrs und 85 Prozent des Umsatzes bereits abgewickelt waren, als die Unterbrechung eintrat. Im Vergleich zu den beiden vorherigen Freitagen war der tägliche Umsatz 10 bis 15 Prozent niedriger und der Verkehr 3 bis 5 Prozent niedriger. Mehr als 900 Transaktionen mit einem kombinierten Zahlungswert von etwa 12 Milliarden EUR wurden abgelehnt. Die größten Auswirkungen wurden in mehreren großen nationalen Komponenten und im Nebensystem- und Interbankenverkehr gemeldet. Dies sind materielle Indikatoren für gestörte Ströme.

Sie sind kein Beweis dafür, dass 12 Milliarden EUR verschwunden sind oder einen wirtschaftlichen Verlust darstellen.

Die Teilnehmeraufzeichnung fügt Konsequenzen hinzu, die das aggregierte Volumen nicht offenbart. Einige Banken und Nebensysteme konnten Nachrichten nicht erneut senden, weil ihre eigenen Systeme dazu nicht in der Lage waren oder bereits geschlossen hatten. Kritische Verpflichtungen von Nebensystemen wurden beglichen, aber fehlende automatisierte Clearinghaus-Dateien für SEPA-Verkehr verzögerten Überweisungen an Endbegünstigte. Einige direkte T2S-Teilnehmer hatten Probleme mit der Neuverteilung von Sicherheiten. Dutzende von Zahlungsausnahmen erforderten Abstimmungen.

Dies sind glaubwürdige Formen operationeller Schäden, selbst wenn die Hauptbeträge letztendlich abgewickelt werden.

Das Liquiditätsverhalten änderte sich ebenfalls. Elf Banken nutzten die Spitzenrefinanzierungsfazilität für insgesamt 19 Millionen EUR. Banken platzierten etwa 400 Milliarden EUR weniger in Einlagen über Nacht, als ein normales Muster vermuten ließe, da die Möglichkeit, überschüssige Reserven zu bewegen, eingeschränkt war. Diese 400 Milliarden EUR sind besonders leicht missbrauchbar. Es handelt sich um eine Veränderung der Platzierung von Zentralbankliquidität, nicht um eine öffentliche Schätzung von Schäden, Verlusten oder eingefrorenen Kundengeldern.

Die Quelle quantifiziert weder entgangene Zinsen, Personalkosten der Teilnehmer, Kundenentschädigungen noch nachgelagerte kommerzielle Kosten.

Die Auswirkung auf die Wertpapierinfrastruktur war selektiv und nicht total. Laut demT2S-Jahresbericht 2020blieb die Wertpapierabwicklung in T2S verfügbar, aber Liquiditätstransfers zwischen T2S und TARGET2 konnten nicht verarbeitet werden. T2S verlängerte seinen eigenen Zeitplan, schloss um 03:30 Uhr und begann die nächste nächtliche Abwicklung um 06:05 Uhr. Diese Unterscheidung ist wichtig: Der Vorfall machte nicht alle Wertpapieraufzeichnungen unverfügbar, aber er beeinträchtigte die Bargeldmobilität, von der reibungslose Lieferung-gegen-Zahlung und Sicherheitenoperationen abhängen.

Keine zugängliche öffentliche Aufzeichnung, die für diese Analyse geprüft wurde, liefert eine verifizierte aggregierte wirtschaftliche Verlustzahl, eine vollständige Anzahl von verzögerten Endbegünstigten oder einen teilnehmerweisen Entschädigungsplan. Verantwortliche Berichterstattung sollte diese als unbekannt behandeln. Ein System kann ernsthafte Störungen verursachen, ohne eine veröffentlichbare Verlustsumme zu produzieren, und das Fehlen dieser Summe sollte nicht als Beweis für keinen Schaden missverstanden werden.

Wer kontrollierte was

Rechenschaftspflicht wird klarer, wenn Kontrolle nach Funktion und nicht nur nach institutionellem Namen zugewiesen wird.

Die Governance-Struktur des Betreibers war selbst Teil der Überprüfung. Funktionen der Ebene 1 lagen beim EZB-Rat, Ebene 2 beim Marktinfrastrukturrat und Ebene 3 bei den diensterbringenden Zentralbanken. Deloitte beschrieb die Entscheidungsfindung als auf hohen Ebenen konzentriert und die Ausschusslandschaft als komplex. Die Dokumentation legte nicht immer vollständige Verantwortlichkeiten fest. Eine zentrale Kontrollfunktion der zweiten Linie mit ausreichender Autorität und einem übergreifenden internen Kontrollrahmen war nicht vollständig vorhanden.

Einige zuvor identifizierte Aufsichtsprobleme hatten zu lange gebraucht, um geschlossen zu werden.

Dies bedeutet nicht, dass jeder Teilnehmer passiv war oder jede nachgelagerte Verzögerung zentral kontrolliert wurde. Eine Bank, die nicht über die Fähigkeit zum erneuten Senden verfügte, kontrollierte diese lokale Schwäche. Ein Nebensystem, das geschlossen hatte, kontrollierte einen Teil seiner eigenen Verfügbarkeit. Von den Teilnehmern wurde auch erwartet, dass sie bestimmte Informationskanäle überwachen. Doch diese Verantwortlichkeiten heben die Pflichten des Infrastrukturbetreibers nicht auf.

Der Betreiber wählte die Kommunikationsarchitektur, stellte die Kontingenzregeln bereit, legte den Servicekalender fest und repräsentierte die Resilienz der gemeinsamen Plattform. Rechenschaftspflicht ist gleichzeitig, kein Wettbewerb, bei dem die Schwäche einer Partei eine andere entlastet.

Die Beziehung zum Anbieter folgt derselben Logik. Ein bekannter, aber nicht offengelegter Softwarefehler ist eine schwerwiegende Lieferantenkontrolltatsache. Die öffentliche Aufzeichnung identifiziert den Anbieter nicht, legt den Vertrag nicht offen, zeigt nicht, ob eine Hinweispflicht verletzt wurde, oder gibt an, ob das Eurosystem Geld zurückerhalten hat. Diese Unbekannten verhindern ein rechtliches Urteil über die Haftung des Anbieters. Sie verhindern kein operationelles Urteil, dass der Systembesitzer unabhängige Kontrollen benötigte, die in der Lage sind, einen Lieferantenfehler einzudämmen.

Der regulatorische Maßstab und die Grenzen der öffentlichen Rechtsaufzeichnung

Zum Zeitpunkt des Ausfalls wurde TARGET2 als systemisch wichtiges Zahlungssystem gemäß derEZB-Verordnung über Aufsichtsanforderungen für systemisch wichtige Zahlungssystemebetrieben. Artikel 15 verlangte einen robusten operationellen Risikorahmen, Geschäftskontinuitätsvereinbarungen und einen sekundären Standort. Die Vereinbarungen sollten so gestaltet sein, dass kritische Informationstechnologiesysteme innerhalb von zwei Stunden nach störenden Ereignissen wieder aufgenommen werden können und die Abwicklung bis zum Ende des Geschäftstages abgeschlossen sein kann. Die Pläne sollten mindestens jährlich getestet und überprüft werden. Die Verordnung verlangte auch das Management von Risiken durch kritische Teilnehmer, andere Infrastrukturen und Dienstleister.

Die internationale Basislinie war konsistent. Grundsatz 17 derCPMI-IOSCO-Grundsätze für Finanzmarktinfrastrukturenfordert die Identifizierung interner und externer operationeller Risiken, geeignete Systeme und Kontrollen, einen sekundären Standort, die Wiederaufnahme kritischer Operationen innerhalb von zwei Stunden und den Abschluss der Abwicklung bis zum Ende des Störungstages. Er befasst sich auch mit Risiken, die durch kritische Dienstleister und verbundene Infrastrukturen entstehen. Diese Bestimmungen machten die Zeit bis zur Wiederherstellung zu einem Governance-Ziel und nicht nur zu einer technischen Leistungskennzahl.

Nach der öffentlichen Zeitlinie wurde die vollständige Zahlungsverarbeitung nicht innerhalb von zwei Stunden wieder aufgenommen. Der regionsgleiche Standort und das Kontingenzmodul waren nicht verfügbar, während die regionsübergreifende Entscheidung viele Stunden nach Beginn der Unterbrechung erfolgte. Dies ist eine starke Grundlage für den Vergleich der Leistung mit dem regulatorischen Maßstab. Es ist für sich genommen kein Beweis für einen formell festgestellten Verstoß.

Die hier geprüften Materialien enthalten keine öffentliche Durchsetzungsentscheidung, die eine Strafe für den Oktobervorfall verhängt, kein Gerichtsurteil, das eine Haftung feststellt, und keine Feststellung einer Aufsichtsbehörde, die jedes Element der Einhaltung klärt.

Das institutionelle Umfeld macht Nachweise besonders wichtig. DieBeschreibung der Aufsichtspolitik der EZBerklärt, dass das Eurosystem Informationen sammelt, Systeme anhand von Standards bewertet und bei Bedarf Änderungen herbeiführt. TARGET Services werden auch innerhalb des Eurosystems betrieben. Operationelle und Aufsichtsfunktionen sind getrennt, aber sie existieren innerhalb derselben breiteren öffentlichen Institution. Es wäre spekulativ zu behaupten, dass die Aufsichtsunabhängigkeit in diesem Fall beeinträchtigt wurde. Es ist dennoch vernünftig, eine sichtbare Trennung der Rollen, dokumentierte Herausforderungen und Abschlussnachweise zu verlangen, damit die Öffentlichkeit nicht allein auf institutionelle Zusicherungen angewiesen ist.

Zahlungsentschädigung ist ein weiterer Bereich, in dem Präzision wichtig ist. Die damals geltendeTARGET2-Leitlinieenthielt ein Entschädigungsschema für angenommene Zahlungsaufträge, die aufgrund einer technischen Störung nicht am selben Geschäftstag abgewickelt werden konnten. Es befasste sich mit Verwaltungsgebühren, Zinsentschädigung, Ausschlüssen und dem Verhältnis zwischen anerkannter Entschädigung und anderen Ansprüchen. Da das Eurosystem sagt, dass alle zurückgestellten Anweisungen vor dem verlängerten Valutatagsschluss verarbeitet wurden, legt die öffentliche Vorfallaufzeichnung nicht fest, wie viele Aufträge, falls überhaupt, qualifiziert waren, ob Ansprüche eingereicht wurden oder was gezahlt wurde. Abgelehnte Nachrichten und nachgelagerte Dateien können auch andere rechtliche Fragen aufwerfen als angenommene Aufträge im Zentralsystem.

Die rechtliche Rechenschaftspflicht hat daher einen dokumentierten Boden und ein undokumentiertes Ergebnis. Der Boden ist das Zwei-Stunden-Wiederherstellungsentwurfsziel, die Tagesschlussabwicklung, die jährlichen Tests und das Risikomanagement des Dienstleisters. Das Ergebnis, das unbekannt bleibt, umfasst Durchsetzungsbehandlung, private Ansprüche, Entschädigungsbeträge und vertragliche Rückgriffsmöglichkeiten gegen den Anbieter. Eine glaubwürdige Bewertung sollte beides angeben.

Die unabhängige Überprüfung machte aus einem Vorfall eine Systemdiagnose

Das Eurosystem beauftragte Deloitte mit der Überprüfung von fünf größeren IT-Vorfällen bei TARGET Services im Jahr 2020. Die Arbeit lief von Ende Dezember 2020 bis März 2021 und verwendete Dokumente, Interviews und Tests unter einer definierten Sicherstellungsmethodik. Der veröffentlichte Bericht wurde aus Sicherheits- und Vertraulichkeitsgründen gekürzt und redigiert. Es handelte sich nicht um eine allgemeine Prüfung aller Kontrollen. Diese Umfangsgrenzen sind wichtig, aber sie schwächen nicht die Bedeutung der Probleme, die die Überprüfung tatsächlich bestätigte.

Die Überprüfung berichtete 40 Feststellungen: 17 als hohe Priorität, 17 als mittlere und 6 als niedrige, wobei keine als sehr hoch eingestuft wurde. Sie gruppierte sie in sechs große Problembereiche: Änderungs- und Freigabemanagement; Geschäftskontinuitätsmanagement; Failover- und Wiederherstellungstests; Kommunikationsprotokolle; Governance; und Rechenzentrums- und IT-Betrieb. Der Oktobervorfall berührte alle sechs.

Die Geschäftskontinuitätsdokumentation war fragmentiert und teilweise veraltet. Detaillierte Rollen waren nicht konsistent definiert, und der Nachweis von Schulungen war unzureichend. Die Überprüfung erhielt keine gültige, aktuelle Geschäftsauswirkungsanalyse, die sowohl TARGET2 als auch T2S abdeckt. Die verfügbare T2S-Analyse stammte aus der Zeit vor der Dienstaufnahme im Jahr 2015 und war nicht aktuell gehalten. Ohne eine aktualisierte Auswirkungsanalyse können Wiederherstellungsprioritäten, Abhängigkeiten und tolerierbare Ausfallannahmen nicht zuverlässig an die aktuelle Geschäftsrealität gebunden werden.

Das Änderungsmanagement entbehrte eines gemeinsamen, nachweisreichen Lebenszyklus. Die Überprüfung stellte Schwächen bei der Risikobewertung, Klassifizierung, Testdokumentation, Genehmigung und Umsetzungsplanung fest. Änderungen während der Betriebszeiten wurden nicht immer in einem ihrer möglichen Auswirkungen angemessenen Umfang behandelt. Die Rollback-Bereitschaft und Infrastrukturabhängigkeiten benötigten stärkere Kontrollen. Lieferantenfreigabeinformationen und das Fehlen einer repräsentativen Netzwerktestumgebung erhöhten die Abhängigkeit vom Produktionsverhalten als ultimativem Test.

Die Kommunikation funktionierte innerhalb der Krisen-Governance besser als über den Teilnehmerperimeter hinweg. Die Überprüfung ergab, dass interne Krisentelefonate und Koordination im Allgemeinen effektiv waren. Extern kannten einige Teilnehmer die TARGET2-Website nicht oder waren nicht für ihren RSS-Kanal abonniert. Nachrichten von nationalen Zentralbanken konnten abweichen, und die Kommunikation gab den Teilnehmern nicht immer zu verstehen, welche Maßnahmen zu ergreifen waren. Gewonnene Erkenntnisse erhielten nicht konsequent formelle Verantwortliche und Abschlusstermine.

Dokumentation und Konfigurationsmanagement zogen sich durch alle diese Bereiche. Die Überprüfung fand fragmentiertes oder veraltetes Betriebsmaterial und keine umfassende Konfigurationsmanagement-Datenbank, die Vermögenswerte, Verantwortliche, Abhängigkeiten und Änderungen verbinden kann. Kontrollnachweise waren manchmal nicht verfügbar. Dieser Mangel ist wichtig, weil Rechenschaftspflicht nach einem komplexen Ausfall davon abhängt, zu rekonstruieren, welche Komponente geändert wurde, wer sie besaß, welche Dienste davon abhingen, welcher Test sie abdeckte und welche Genehmigung das Restrisiko akzeptierte.

Das wichtigste Ergebnis der Überprüfung war daher nicht eine Liste von 40 isolierten Mängeln. Es war der Nachweis, dass die Verteidigungsmechanismen um die kritische Zahlungsinfrastruktur nicht als ein einziges kohärentes System verwaltet wurden. Ein Gerätefehler wurde zu einem Produktionsausfall; gemeinsame Abhängigkeiten besiegten die lokale Redundanz; unklare Auslöser verbrauchten Wiederherstellungszeit; Kommunikationsschwächen reduzierten die Handlungsfähigkeit der Teilnehmer; und fragmentierte Nachweise erschwerten die Sicherstellung.

Die Diagnose rechtfertigte Abhilfe auf Governance-Ebene, nicht nur den Austausch oder das Patchen von Netzwerkgeräten.

Das Reparaturprogramm und was seine Kennzahlen beweisen – und was nicht

Dieformelle Antwort des Eurosystems auf die unabhängige Überprüfungakzeptierte die allgemeinen Schlussfolgerungen und Empfehlungen des Berichts. Die Akzeptanz war ein wichtiger Rechenschaftsschritt, da sie vermied, den Vorfall als einmalige Anomalie des Anbieters zu behandeln. Der schwierigere Schritt war, Empfehlungen in Kontrollen umzuwandeln, die beobachtet und getestet werden können.

Der veröffentlichteAktionsplan für TARGET Servicestat dies durch sechs Arbeitsströme, die der Überprüfung entsprachen. Änderungsmanagementmaßnahmen umfassten einen standardisierten Lebenszyklus, eine stärkere Risiko- und Sicherheitsbewertung, gemeinsame Dokumentation, explizite Rollback-Prüfungen, höhere Genehmigungen für Änderungen außerhalb von Wartungsfenstern und die Analyse einer dedizierten Netzwerktestumgebung. Kontinuitätsmaßnahmen umfassten überarbeitete Krisenverfahren, einen Leitfaden für Krisenmanager, Personalschulungen, ganzheitliche Kontinuitätsvereinbarungen und die jährliche Überprüfung von Geschäftsauswirkungsanalysen und Kontinuitätsplänen.

Failover-Maßnahmen waren für die Oktober-Nachweise besonders relevant. Sie forderten geklärte Rollen, definierte Testhäufigkeit, einen Entscheidungsauslöser, der das Zwei-Stunden-Ziel schützt, repräsentativere Szenarien, gemeinsame Testberichte, periodische Transaktionstests und Teilnehmersimulationen. Kommunikationsmaßnahmen zielten auf schnellere faktische Mitteilungen, bessere Status- und Abonnementkanäle, direkten Kontakt mit kritischen Teilnehmergruppen, abgestimmte Nachrichten über Zentralbanken und Wertpapierdepots hinweg und formelles Lernen nach Vorfällen.

Governance- und Technologiemanagementmaßnahmen umfassten ein einfacheres Betriebsmodell, ein rechtliches Inventar, eine gestärkte Risiko- und Kontrollfunktion, bessere Überwachung, Überwachungszugriff in der alternativen Region, Drittparteienregeln, prüfbare Abläufe und eine Konfigurationsdatenbank mit identifizierten Verantwortlichen.

Der Aktionsplan berichtete auch über operationelle Änderungen und nicht nur über Versprechen. ECONS-Aktivierungsverfahren wurden implementiert und das Personal geschult. Die Krisenleitlinie wurde überarbeitet, um Entscheidungsträger zu veranlassen, eine frühzeitige Kontingenzaktivierung in Betracht zu ziehen und die Ausfallzeit gegen das Zwei-Stunden-Wiederherstellungsziel zu begrenzen. Regelmäßige Checks zur Konnektivität der Zentralbank mit dem Kontingenznetzwerk wurden eingeführt, zusammen mit periodischen Transaktionstests und breiteren Übungen. Dies sind die Arten von Kontrollen, die sich direkt mit dem fehlgeschlagenen Pfad befassen.

Die Fortschrittsberichterstattung lieferte dann Zwischennachweise. EinUmsetzungsupdate vom Dezember 2022konsolidierte 155 Maßnahmen, die aus der externen Überprüfung, Aufsichtsfeststellungen und interner Prüfung resultierten. Der Marktinfrastrukturrat überwachte die Arbeit monatlich; interne Prüfung und leitende Aufseher bewerteten die unterstützenden Nachweise; und der EZB-Rat erhielt halbjährliche Berichte. Bis zum 31. März 2022 hatten die Prüfer 79 Maßnahmen überprüft: 58 waren abgeschlossen und 21 benötigten weitere Nachweise oder Verbesserungen. Bis zum 30. September berichtete der Rat, dass 121 von 155 abgeschlossen, 16 auf Kurs und 18 verzögert waren, viele, weil sie vom TARGET2-T2S-Konsolidierungsprogramm abhingen.

Die Unterscheidung zwischen "vom Management abgeschlossen" und "nach Prüfung geschlossen" ist wesentlich. Ein Projektteam kann eine Maßnahme abschließen, ohne nachzuweisen, dass die Kontrolle funktioniert. Die Verwendung der Nachweisprüfung durch interne Prüfung und Aufsicht im Bericht von 2022 war daher stärker als ein einfacher Abschlussprozentsatz. Sie offenbarte auch Verzögerungen, anstatt die Basislinie stillschweigend zurückzusetzen.

Bis Ende 2023 sagte derT2S-Jahresbericht 2023, dass mehr als 90 Prozent der geplanten Maßnahmen umgesetzt seien, der Rest werde für 2024 erwartet. Im Juli 2025 erklärte derveröffentlichte Beschluss des EZB-Rats, dass nur noch eine der 155 Maßnahmen umgesetzt werden müsse und der Interne Prüfungsausschuss deren Überwachung fortsetzen werde. Der Rat beendete den jährlichen Berichtszyklus. Dies ist ein starkes Zeichen für eine nachhaltige Programmumsetzung. Es ist kein Beweis dafür, dass alle 155 Maßnahmen bis Juli 2025 abgeschlossen waren, da der Rat ausdrücklich einen offenen Punkt bestehen ließ.

Die Governance entwickelte sich ebenfalls weiter. Im September 2025 gab derEZB-Rat bekannt, dass eine organisationsbezogene Überprüfung der Governance von TARGET Services, ursprünglich 2021 angefordert, abgeschlossen sei und weitere Maßnahmen bis 2027 gemeldet werden sollten. Diese spätere Arbeit sollte nicht automatisch mit der einzelnen verbleibenden Maßnahme gleichgesetzt werden, deren Gegenstand in der öffentlichen Mitteilung nicht angegeben ist. Es zeigt jedoch, warum "Programmberichterstattung beendet" nicht dasselbe ist wie "Governance-Verbesserung beendet".

Spätere Operationen sind der wahre Dauerhaftigkeitstest

Strategiedokumente können zeigen, dass Kontrollen entworfen und zugewiesen wurden. Nur der spätere Betrieb kann zeigen, ob sie nutzbar bleiben. DerTARGET-Jahresbericht 2023verzeichnet, dass der konsolidierte T2-Dienst im Jahr 2023 keine vollständige Aussetzung erlitt, obwohl es kleinere Vorfälle gab. Er berichtet auch über die Einrichtung eines unabhängigen TARGET Services Risikoausschusses Ende 2023, unterstützt durch überarbeitete Risiko- und Kontrollrahmenwerke. Dies ist ein relevanter Nachweis, dass die nach 2020 identifizierte Governance-Schwäche der zweiten Linie eine institutionelle Antwort erhielt.

Ein viel härterer Test ereignete sich am 27. Februar 2025. DerTARGET Services Jahresbericht 2025, veröffentlicht im Jahr 2026, beschreibt einen separaten Hardware- und Speicherfehler, der sowohl T2 als auch T2S für viele Stunden störte. T2 war etwa 10 Stunden nicht verfügbar, T2S etwa 8 Stunden. Kritische Hardware und ihre Redundanz fielen aus. Die erste Diagnose konzentrierte sich auf ein Datenbankproblem, was die Entscheidung zum Regionswechsel verzögerte. Die Dienste kehrten nach 18:00 Uhr zurück, und der Geschäftstag schloss gegen Mitternacht.

Das Ereignis von 2025 kann nicht als Wiederholung desselben Netzwerkfehlers dargestellt werden, und es beweist nicht, dass der Aktionsplan von 2020 insgesamt gescheitert ist. Sein Wert liegt als realer Stresstest. ECONS unterstützte kritische T2-Zahlungen während des späteren Ausfalls, ein Nachweis, dass eine Kontingenzfähigkeit, die im Oktober 2020 nicht verfügbar war, operationell nützlich geworden war. Gleichzeitig erschwerte der gleichzeitige Ausfall von T2 und T2S die Sicherheitenmobilisierung und verzögerte verbundene Prozesse.

Die Überprüfung nach dem Vorfall erzeugte 20 Maßnahmen; der Bericht sagt, die meisten seien bis zum vierten Quartal 2025 abgeschlossen worden, während einige wenige nicht zeitkritische Punkte in Bearbeitung blieben.

Dieses gemischte Ergebnis ist aufschlussreicher als entweder eine Sieges- oder eine Fehlerbehauptung. Ein Kontingenzkanal verarbeitete kritische Zahlungen, aber Diagnose und regionsübergreifende Wiederherstellung verbrauchten wiederum erhebliche Zeit. Das System zeigte verbesserte Fähigkeiten und offenbarte restliche Abhängigkeiten. Dauerhafte Rechenschaftspflicht erfordert, dass beide Fakten sichtbar bleiben.

Die Arbeit war 2026 noch aktiv. DasErgebnis der AMI-Pay-Sitzung vom Mai 2026verzeichnet Konsultationen zu Betriebszeitverlängerungen und zur Nutzung von ECONS nach dem Vorfall von 2025. Das Eurosystem und die nationalen Zentralbanken waren noch dabei zu bestimmen, wie viele Stunden benötigt würden, um die meisten kritischen Zahlungen auf ECONS zu verarbeiten und wann die Vorbereitungen zum Abschluss des Tages dort beginnen sollten. Die Teilnehmer betonten auch die Notwendigkeit, doppelte Anweisungen und nachteilige Auswirkungen auf ihre internen Systeme zu vermeiden. Dies ist kein Beweis für eine ungelöste Maßnahme von 2020. Es ist ein Nachweis, dass Kontingenzabwicklung ein operationelles Ökosystem ist, an dem Betreiber- und Teilnehmerverhalten beteiligt sind, und dass seine Verfahren nach realen Ereignissen weiter verfeinert werden müssen.

Bestätigte Fakten, gestützte Schlussfolgerungen und Unbekannte

Bestätigte Fakten.Die Abwicklungsdienste von TARGET2 wurden am 23. Oktober 2020 gegen 14:40 Uhr nicht mehr verfügbar. Das Informations- und Kontrollmodul, Liquiditätstransfers, die T2S und TIPS betrafen, normale Zahlungsabwicklung und Anweisungen von Nebensystemen waren betroffen. Die regionsgleiche Wiederherstellung stellte den Dienst nicht wieder her, ECONS war während der Anfangsreaktion nicht verfügbar, und das Eurosystem entschied sich gegen 20:30 Uhr für einen regionsübergreifenden Failover. Die vollständige FIN-Verarbeitung wurde gegen 01:20 Uhr wieder aufgenommen. Der Valutatag wurde verlängert, und der Betreiber sagt, dass alle verbleibenden Warteschlangen vor dem Schluss um 03:30 Uhr verarbeitet wurden.

Es ist auch bestätigt, dass ein Konfigurationsparameter einen Softwarefehler in Netzwerkgeräten von Drittanbietern aktivierte, dass der Anbieter den Fehler kannte und dass der Fehler für den Betreiber im relevanten Freigabematerial nicht dokumentiert war. Der Vorfall wurde keinem Cyberangriff zugeschrieben. Öffentliche Berichte verzeichnen abgelehnten Verkehr, verzögerte nachgelagerte Dateien, eingeschränkte Liquiditätstransfers, Abstimmungsarbeiten und verändertes Einlagenverhalten über Nacht.

Die unabhängige Überprüfung dokumentierte 40 Feststellungen zu den Vorfällen von 2020, und das Eurosystem erstellte 155 Abhilfemaßnahmen, von denen eine im Juli 2025 noch auf Umsetzung wartete.

Gestützte Schlussfolgerungen.Das Ausmaß und die Dauer des Ausfalls wurden nicht allein durch den Gerätefehler bestimmt. Schwachstellen in der Änderungsbewertung, repräsentativen Tests, Isolierung gemeinsamer Fehlermodi, Failover-Auslösern, Kontingenzbereitschaft und Teilnehmerkommunikation entfernten oder verzögerten Verteidigungsmechanismen, die unter der Kontrolle des Betreibers standen. Diese Schlussfolgerung wird durch die externe Überprüfung und die direkte Entsprechung zwischen ihren Feststellungen und dem Aktionsplan gestützt.

Es ist auch vernünftig zu folgern, dass die Erhaltung des Valutatags und die Verarbeitung aller Warteschlangen die Abwicklungsendgültigkeits- und Hauptrisikofolgen im Vergleich zu einem nicht wiederhergestellten Tag reduzierten. Die Quellen erlauben keine Quantifizierung dieser Reduzierung. Ebenso stützt die spätere erfolgreiche Nutzung von ECONS im Jahr 2025 die Schlussfolgerung, dass sich die Kontingenzfähigkeit nach 2020 verbessert hat, aber sie isoliert nicht, welche Maßnahme die Verbesserung bewirkte, oder beweist, dass jetzt jedes Szenario abgedeckt ist.

Unbekannte.Die öffentliche Aufzeichnung nennt den Geräteanbieter nicht, legt seinen Vertrag nicht offen und zeigt nicht, ob vertragliche Rechtsbehelfe verfolgt wurden. Sie enthält keine vollständigen Konfigurationsprotokolle, alle internen Entscheidungsaufzeichnungen, teilnehmerbezogene Warteschlangen oder den genauen Grund, warum jede Bank den Verkehr nicht erneut senden konnte. Die gekürzte Überprüfung enthält sensible technische und kundenbezogene Informationen. Diese Grenzen verhindern eine vollständige Rekonstruktion individueller Handlungen und rechtlicher Haftung.

Die gesamtwirtschaftlichen Kosten sind unbekannt. Es gibt keine verifizierte Gesamtsumme von Kundenverlusten, Liquiditätskosten, Personalkosten für Überstunden, Opportunitätskosten, Entschädigungen, Ansprüchen oder Rückforderungen vom Anbieter. Öffentliche Quellen legen nicht fest, ob der Oktoberausfall eine formelle behördliche Verstoßentscheidung, Sanktion oder einen Gerichtsfall auslöste. Sie identifizieren auch nicht den letzten verbleibenden Punkt unter den 155 Maßnahmen in der Mitteilung vom Juli 2025 oder liefern öffentliche Testnachweise für jede abgeschlossene Maßnahme.

Diese Abwesenheiten sollten sichtbar bleiben, anstatt mit Schätzungen gefüllt zu werden.

Ein dauerhafter Rechenschaftstest für Großzahlungsinfrastruktur

Der Vorfall unterstützt einen praktischen Test, der auf TARGET Services und andere systemisch wichtige Zahlungsplattformen angewendet werden kann. Rechenschaftspflicht ist nur dann dauerhaft, wenn die folgenden Behauptungen mit Nachweisen und nicht nur mit Zusicherungen beantwortet werden können.

Erstens: Kann der Betreiber jeden kritischen Dienst auf eigene Infrastruktur und Abhängigkeiten abbilden?Eine aktuelle Konfigurationsdatenbank sollte Geräte, Software, Standorte, Netzwerke, Anbieter, Geschäftsdienste, verantwortliche Eigentümer und Wiederherstellungsverfahren verbinden. Eine Änderung eines Netzwerkparameters muss alle Dienste und Redundanzdomänen offenlegen, die sie beeinflussen kann.

Zweitens: Sind Änderungsentscheidungen proportional zu den möglichen Dienstauswirkungen?Die Klassifizierung sollte grundlegende Netzwerk-, Strom-, Speicher- oder Kühlungsarbeiten nicht allein deshalb als risikoarm einstufen, weil sie routinemäßig erscheinen. Nachweise sollten eine Begründung der Geschäftsauswirkungen, repräsentative Tests, Peer-Reviews, genehmigte Implementierungsfenster, Überwachung, Stoppbedingungen und ein geprobtes Rollback umfassen.

Drittens: Ist die Redundanz unter den maßgeblichen Szenarien unabhängig?Zwei Standorte bieten keine zwei Verteidigungslinien, wenn eine Änderung oder Steuerungsebene beide deaktivieren kann. Tests sollten den Verlust einer aktiven Region, den Verlust von Managementschnittstellen, die Beeinträchtigung verbundener Dienste und den Ausfall des nominellen Kontingenzpfads umfassen. Produktions- und Backup-Konfigurationen sollten funktional gleichwertig sein, wo die Wiederherstellung von der Gleichwertigkeit abhängt.

Viertens: Erzwingt die Krisen-Governance eine Entscheidung vor Ablauf des Wiederherstellungsziels?Eskalationsregeln sollten festlegen, wer regionsgleiche, regionsübergreifende und Kontingenzverarbeitung aufrufen kann, welche Nachweise sie benötigen und den spätesten Entscheidungszeitpunkt. Ein Zwei-Stunden-Wiederherstellungsziel kann nicht von einem Ausschuss erreicht werden, der über zwei Stunden hinaus diagnostizieren darf, ohne einen alternativen Pfad zu wählen.

Fünftens: Können die Teilnehmer auf der Grundlage der Kommunikation handeln?Eine Statusnachricht muss zeitnah, zugänglich und operationell spezifisch sein. Sie sollte angeben, welche Dienste betroffen sind, was die Teilnehmer stoppen oder fortsetzen sollen, ob Nachrichten erneut gesendet werden müssen, welcher Grenzzeit gilt und wann das nächste Update eintrifft. Kritische Gruppen benötigen getestete Kontaktwege über eine Webseite hinaus, von deren Existenz einige Benutzer nichts wissen.

Sechstens: Kann die Kontingenzverarbeitung realistischen kritischen Verkehr bewältigen?ECONS oder jede Nachfolgekapazität sollte mit Zentralbanken, Geschäftsbanken und Nebensystemen unter Verwendung echter Nachrichtenmuster und realistischer Volumina getestet werden. Die Tests sollten die Vermeidung von Duplikaten, Liquidität, Sicherheitenbeschränkungen, den Tagesabschluss und die Rückkehr zum Normalbetrieb abdecken. Konnektivität allein ist nicht ausreichend.

Siebtens: Werden Schäden und Ausnahmen durch die gesamte Zahlungskette gemessen?Betreiberkennzahlen sollten zurückgestellte, abgelehnte, erneut gesendete, duplizierte, verzögerte und endgültig abgewickelte Anweisungen unterscheiden. Sie sollten Nebensystemdateien, Liquiditätstransfers, Abstimmungsfälle und Verzögerungen bei nachgelagerten Begünstigten erfassen, ohne den Zahlungshauptbetrag fälschlicherweise als finanziellen Verlust zu bezeichnen.

Achtens: Hinterfragt eine unabhängige Kontrollfunktion den Abschluss?Managementabschluss, Validierung durch die zweite Linie, Bewertung durch die interne Prüfung und aufsichtlicher Abschluss sind unterschiedliche Phasen. Maßnahmen mit hoher Priorität sollten Verantwortliche, Fristen und Nachweise behalten, bis ein unabhängiger Prüfer den Betrieb bestätigt, nicht nur das Design.

Neuntens: Sind rechtliche Rechtsbehelfe und Teilnehmerrechte sichtbar?Öffentliche Infrastruktur muss keine sensiblen Ansprüche offenlegen, aber sie sollte den anwendbaren Entschädigungsrahmen, die Behandlung aggregierter Ansprüche, soweit rechtlich zulässig, und erklären, ob eine Rechenschaftspflicht des Anbieters oder der Teilnehmer verfolgt wurde. Stillschweigen sollte nicht in die Annahme umgewandelt werden, dass kein Rechtsbehelf verfügbar oder erforderlich war.

Zehntens: Lernt die Institution nach dem nächsten Vorfall erneut?Ein späterer Ausfall sollte mit früheren Kontrollverpflichtungen verglichen werden. Nachweise einer verbesserten Kontingenznutzung verdienen Anerkennung; wiederholte Verzögerungen bei Diagnose oder Failover verdienen Prüfung. Ein abgeschlossenes Programm sollte zu einer aufrechterhaltenen Betriebsbasislinie werden, nicht zu einem Archiv.

Diese Tests vermeiden zwei unproduktive Extreme. Das eine behandelt jeden Ausfall als Beweis dafür, dass Ausgaben für Resilienz gescheitert sind, ein unmöglicher Standard für komplexe Systeme. Das andere akzeptiert Architekturdiagramme, Maßnahmenzahlen und hohe jährliche Verfügbarkeit als Beweis dafür, dass Kontinuität funktioniert.

Die verteidigungsfähige Mitte ist anspruchsvoll, aber messbar: Fehler werden auftreten, und die verantwortliche Institution muss zeigen, dass die Prävention angemessen war, die Wiederherstellung zeitnah, die Schäden kontrolliert, die Entscheidungen rekonstruierbar und dieselben Schwächen nicht unangefochten bestehen bleiben.

Schlussfolgerung

Der TARGET2-Ausfall im Oktober 2020 begann mit einem Softwarefehler eines Drittanbieters, wurde aber zu einem Rechenschaftsereignis, weil mehrere Verteidigungsmechanismen des Betreibens gleichzeitig versagten. Eine Produktionsnetzwerkänderung aktivierte den Fehler. Beide Standorte in der aktiven Region waren exponiert. Regionsgleiche Wiederherstellung und Kontingenzabwicklung waren nicht verfügbar. Der regionsübergreifende Failover erfolgte nach stundenlangen Wiederherstellungsversuchen. Die Kommunikation rüstete nicht jeden Teilnehmer für eine Reaktion aus, und der Geschäftstag musste bis in den Samstagmorgen verlängert werden.

Das Eurosystem verarbeitete letztendlich seine Warteschlangen und bewahrte den Valutatag, beauftragte eine unabhängige Überprüfung, akzeptierte eine systemische Diagnose und verfolgte ein umfangreiches Abhilfeprogramm mit externer Fortschrittsberichterstattung. Dies sind substanzielle Rechenschaftsmaßnahmen. Die spätere Schaffung eines unabhängigen Risikoausschusses und die operationelle Nutzung von ECONS während eines anderen Ausfalls im Jahr 2025 fügen Nachweise hinzu, dass sich einige wichtige Kontrollen geändert haben.

Die Aufzeichnung ist keine Grundlage, um die Resilienz für abgeschlossen zu erklären. Eine von 155 Maßnahmen blieb im Juli 2025 offen, Governance-Maßnahmen wurden nach einem späteren Zeitplan fortgesetzt, und der Vorfall von 2025 offenbarte neue Schwierigkeiten bei Diagnose, Redundanz und gleichzeitigen Dienstabhängigkeiten. Die Aufzeichnung ist auch keine Grundlage, um Verluste, Rechtsverstöße oder individuelle Schuld zu erfinden, die offizielle Beweise nicht feststellen.

TARGET2 machte die Wiederherstellung selbst zum Test. Für gemeinsame Zahlungsinfrastruktur ist Rechenschaftspflicht nicht dadurch erfüllt, dass man die defekte Komponente identifiziert oder die jährliche Verfügbarkeit meldet. Sie ist erfüllt, wenn die Institutionen mit praktischer Kontrolle nachweisen können, dass Änderungen eingedämmt sind, Failover-Entscheidungen die versprochene Wiederherstellungszeit schützen, Kontingenzkanäle mit echten Teilnehmern funktionieren, verzögerte Zahlungen und Liquiditätseffekte ehrlich gemessen werden, die Aufsicht den Betreiber herausfordern kann und Reparaturen den nächsten operationellen Schock überstehen.