Zeit des Umbruchs

Aufgeschoben ist nicht aufgehoben: Die Umstellung auf ISO-20022-konforme Datenformate im Zahlungsverkehr kommt – wenn auch ein Jahr später. Und sie bringt weitere Veränderungen mit sich, nicht zuletzt bei SWIFT. Die dort geplante Transaction Management Platform (TMP) soll internationale Zahlungsflüsse transparenter und schneller machen. Aber sind solche zentralen Systeme auch sicher genug? Gibt es Alternativen? 

Zentrale Datenplattform als Entwicklungsziel

Zahlungsverkehrssysteme gehören zum Kern der Finanzinfrastruktur. Ein Ausfall wie bei TARGET2 im vergangenen Jahr wiegt schwer, die Aufregung darüber ist verständlich. Die Verschiebung der Umstellung auf ISO-20022-konforme XML-Datenformate im europäischen Zahlungsverkehr steht damit zwar nicht im Sachzusammenhang, gibt den Finanzinstituten aber natürlich zeitliche Spielräume. Die können sie brauchen, denn mit der Formatänderung wurden noch weitere Dinge ins Rollen gebracht. So hat SWIFT mit der TMP die Einrichtung einer zentralen Datenplattform für den Auslandszahlungsverkehr, basierend auf dem XML-Standard, angekündigt. 

Durch die zentrale Speicherung sämtlicher Transaktionsdaten können alle am Prozess Beteiligten jederzeit auf die Daten zugreifen. Für SWIFT ist das ein Paradigmenwechsel, weg vom reinen Informationsmittler hin zum vollgültigen Zahlungslogistiker. Die Plattformlösung bietet eine Reihe von Vorteilen:

• Reduktion der Schnittstellen
• keine Datenverluste zwischen den einzelnen Stationen
• hohe Transparenz für alle Beteiligten
• höhere Manipulationssicherheit
• mehr Serviceangebote

Keine Einführung ohne Risiken

Allerdings birgt die Einführung der TMP auch einige Fallstricke. Da ist zunächst ein Ausfall des SWIFT-Netzwerks. Bei der zentralen TMP gingen im Extremfall sämtliche Aufträge eines bestimmten Zeitraums verloren. Bedenken der Banken, sich hier einen Single Point of Failure ins Haus zu holen, sind nicht völlig von der Hand zu weisen. Bei der Vertraulichkeit der Daten ist zu berücksichtigen, dass die Vereinigten Staaten schon direkte Zugriffsrechte auf den Datenbestand des SWIFT-US-Rechenzentrums verlangten. SWIFT baute als Reaktion darauf unter anderem einen Standort in der Schweiz auf.

Gibt es Alternativen zu SWIFT?

Im Prinzip ja – aber die Auswahl hält sich in Grenzen: Mögliche Kandidaten sind Internet-Zahlungsnetzwerke wie etwa Ripple. Erste Großbanken nutzen das System bereits probeweise. Noch nicht marktreif, aber in Zukunft auf jeden Fall eine mögliche Alternative stellen digitale Zentralbankwährungen dar (Central Bank Digital Currencies). Der E-Renminbi in China ist bereits in einigen Provinzen in der Erprobungsphase, die schwedische E-Krone hat unlängst den Testbetrieb begonnen. Die EZB dürfte mit dem digitalen Euro nachziehen.

Eine weitere Überlegung wert sind grenzüberschreitende Echtzeit-Bruttoabwicklungs¬systeme (englisch Real-Time Gross Settlement, RTGS). Allerdings kommen diese nicht eben häufig vor oder aber sind, wie SEPA, auf eine einzelne Währung festgelegt. Schließlich gibt es eigens als Alternative zu SWIFT aufgesetzte Kooperationen wie Support of Trade Exchanges (INSTEX). Dieses europäische System wurde eigens für den Handel mit dem Iran ins Leben gerufen. China ist mit CIPS einen ähnlichen Weg gegangen. Gänzlich anders, aber ebenfalls grundsätzlich auf der Kooperation der beteiligten Banken aufbauend, funktioniert Visa B2B Connect. In Europa ist der Service derzeit in ausgewählten Ländern verfügbar.

Aber selbst eine Lösung von SWIFT mittels einer der – raren – Alternativen befreit die Finanzinstitute nicht von der Verpflichtung, auf ISO-20022-konforme XML-Datenformate umzustellen. Gleichzeitig ist es für Banken ratsam, sich die durch TMP anstehenden Änderungen im Auslandszahlungsverkehr genau anzusehen und zu hinterfragen. In der Roadmap hin zu ISO 20022 ist durch die Verschiebung des Go-live-Termins etwas Zeit gewonnen – diese sollte jetzt sinnvoll genutzt werden!

Autoren: Sabine Aigner, Thomas Ambühler

Weiterlesen

Unterbrechungsfreier Zahlungsverkehr – wer wünscht sich das nicht?

Es gibt Softwaresysteme, die so kritisch sind, dass höchste Ansprüche an die Verfügbarkeit erforderlich sind. Zugegeben: Im Finanzbereich geht es normalerweise nicht gleich um Leben oder Tod. Aber bei Echtzeitbezahlverfahren oder Echtzeit-Autorisierungsprozessen werden immer höhere Anforderungen definiert und insbesondere Wartungsfenster nicht länger akzeptiert. Und dies zu Recht: Führt ein Wartungsfenster dazu, dass man den Kontoauszug eine Stunde später bekommt oder das Portal eine Stunde nicht erreichbar ist, mag das ärgerlich, aber zu verschmerzen sein. Kann der Bankkunde hingegen am Point of Sale plötzlich nicht mehr bezahlen oder seine Zahlung nicht in Echtzeit autorisieren, gewinnt der Ausfall eine dramatische Relevanz.

Daher ist mit Einführung von Instant Payments in Europa nach dem Autorisierungsprozess für Kartenzahlungen auch die Echtzeitüberweisung zu einem Einsatzbereich unterbrechungsfreier Systeme geworden.

Kommen wir zunächst zum Begriff der Unterbrechungsfreiheit. Ein unterbrechungsfreier Betrieb wird durch zwei verschiedene Eigenschaften beschrieben:

1. Vermeidung geplanter Nichtverfügbarkeit
   Das System ist im Normalbetrieb permanent funktionsbereit. Es hat also keine periodischen Zeiten eingeschränkter Funktionalität, wie bei Tagesende oder Reorganisation.
   Das System ist so konstruiert, dass auch Releasewechsel während des Betriebs durchgeführt werden können und keine Downtime verursachen.
    
2. Reduzierung der ungeplanten Nichtverfügbarkeit
   Das System ist auch bei Fehlerszenarien hoch verfügbar. Es gewährleistet also mit hoher Wahrscheinlichkeit den Betrieb trotz Ausfalls einzelner Komponenten. Diese Ausfallwahrscheinlichkeit wird berechnet oder gemessen als das Verhältnis der Produktionszeit zur Laufzeit, also der Zeit inklusive der Ausfallzeit, beispielsweise 99,99 Prozent. Insbesondere die Robustheit in Überlastszenarien ist hier von Interesse. Obwohl jedes System seine Grenzen hat, ist es eben ein Unterschied, ob jenseits der Belastungsgrenze alles zusammenbricht oder nur die zusätzliche Last nicht im Rahmen der Vorgaben abgearbeitet werden kann.

Die Begeisterung für das Thema lässt meistens beim Betrachten der Kosten erheblich nach. Es lohnt daher, architektonische Antworten zu finden und nicht alles nur auf die Infrastruktur zu verlagern. Dennoch wird auch die beste Software nur dann laufen können, wenn die Systemumgebung verfügbar ist. Ich möchte hier nicht näher auf hochverfügbare Infrastruktur, Betriebssysteme, Datenbanksysteme und Message Broker eingehen – all dies ist Grundvoraussetzung für ein unterbrechungsfreies Gesamtsystem. Ich möchte den Fokus auf die Softwarearchitektur legen. Diese kann es ermöglichen, Verfügbarkeitsanforderungen gezielt umzusetzen und dabei die Kosten im Griff zu behalten. 

Da Hochverfügbarkeit teuer ist, müssen zuallererst die kritischen Prozesse identifiziert werden. Es gilt also, die Frage zu beantworten, welche Prozesse wirklich immer funktionieren müssen und welche durchaus auch nachgeholt werden können. Im Echtzeitzahlungsverkehr sind beispielsweise die Sammlerprozesse weniger kritisch als die Einzelzahlungen.

Falls große Komponenten unter die kritischen Prozesse fallen, sollte analysiert werden, ob diese überbrückt werden können. Kann also eine alternative Komponente die kritischen Aufgaben einer großen nicht hochverfügbaren Komponente für die Zeit des Ausfalls ersetzen? Im Zahlungsverkehr kann etwa das Buchungssystem ein derartiges großes, nicht hochverfügbares System sein und die Onlinedisposition der kritische Prozess, den es zu überbrücken gilt.

Zahlungsverkehr als Ganzes ist selbstredend kein zustandsloser Prozess: Geld kann leider immer nur einmal ausgegeben werden, der Kontostand ist also ein relevanter Zustand und eine Bankensoftware muss dies natürlich genau abbilden können. Das führt in unserem Fall immer zum Einsatz von Datenbanken und zum Bedarf einer Persistenz vor und nach jeder relevanten Zustandsänderung. Gerade das Design des Datenbankmodells gibt den Ausschlag darüber, ob wir unser Ziel erreichen oder nicht. Hochverfügbare Prozesse sollen mit stabilen bzw. migrationsfreien Datenstrukturen arbeiten. Nur so kann vermieden werden, dass kritische Prozesse für eine Änderung des Datenbankschemas heruntergefahren werden müssen.

Bleibt das Thema Robustheit. In der Wissenschaft spricht man auch von Resilienz, wenn beschrieben wird, dass Störungen oder Teilausfälle von technischen Systemen nicht dazu führen, dass diese vollständig versagen. Im Zahlungsverkehr können solche Störungen Lastspitzen oberhalb vereinbarter Grenzen sein oder Umsysteme, die nicht so schnell antworten wie vereinbart. Auch Ausfälle bei Geschäftspartnern und damit ausfallende Quittungen in größerer Menge können Ausfälle verursachen. Wir haben in der reaktiven Programmierung ein Paradigma gefunden, das die gewünschte Robustheit durch die Orientierung an Datenflüssen ermöglicht. Eine Überlast kann so auf betroffene Bereiche gekapselt werden und dem störungsfreien Betrieb der restlichen Daten – in unserem Falle Zahlungen – steht nichts im Wege.

Autor: Thomas Riedel

Weiterlesen