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

Zahlungsverkehr 2021: Keine Atempause

Für die europäischen Zahlungsdiensteanbieter neigt sich ein herausforderndes Jahr dem Ende zu. Corona war auch hier das alles bestimmende Thema. Im Individualzahlungsverkehr, verstanden als Interbanken- und Auslandszah-lungsverkehr, ist Corona mitursächlich für die Verschiebung der TARGET2-Konsolidierung und der SWIFT ISO20022 Umstellung. Für den kartengestützten Zahlungsverkehr brachte die Pandemie negative, aber auch positive Effekte: Zum einen führte Corona zu einem massiven Schub an kartenbasierten und hier insbesondere kontaktlosen Transaktionen. Solch eine Entwicklung hätte normalerweise mehrere Jahre gedauert und zudem signifikante Marketinginvestitionen der großen Card-Schemes erfordert. Auf der anderen Seite erlitten viele Marktteilnehmer im Kartengeschäft coronabedingt massive Umsatzeinbrüche – insbesondere diejenigen, die stark im Bereich Gastronomie, Reisen und Events engagiert sind. 

Wer nun denkt, dass es in 2021 für die Zahlungsverkehrsbranche eine Atempause gibt, irrt. Schließlich gehen im kommenden Jahr gleich zwei konkrete Projekte live. Andere Vorhaben müssen schon vorbereitet werden, auch wenn der tatsächliche Marktstart erst 2022 oder später geplant ist. Zusammen mit den ohnehin schon gravierenden strukturellen Marktumbrüchen betrachtet, verdichtet sich der Eindruck, die Branche stehe vor einer Alpenüberquerung unter erschwerten Bedingungen.

Aber der Reihe nach: Unter den konkreten Themen des kommenden Jahres fällt die anstehende Einführung von Request to Pay (RTP) auf. Mit Start dieses Standards im Sommer 2021 wird der Zahlungsverkehr um einen wichtigen Bau-stein ergänzt (Siehe hierzu auch unser Whitepaper Teil 1 und Teil 2) . Viele Unternehmen drängen die Finanzdienstleistungsbranche seit Langem, mit dem Auf- und Ausbau von RTP zügig voranzuschreiten (Lesen Sie hierzu auch den Survey der EBA). Denn mit RTP werden Anwendbarkeitslücken in oder zwischen den existierenden Verfahren geschlossen. Dazu gehört die möglich werdende Verbindung von Rechnungs- und Zahldaten. Dies erleichtert die Abstimmungsprozesse im Rechnungswesen vieler Unternehmen erheblich. Oder die bisher fehlende Möglichkeit, Zahlungen am Point of Sales (POS) ohne Terminalstruktur elektronisch entgegennehmen zu können. Die Einrichtung eines POS wird mit RTP einfacher und mobiler. 

Zur weiteren Durchdringung von Echtzeitüberweisungen gemäß dem SCT Inst Scheme hat der EZB-Rat entschieden, dass alle in TARGET2 erreichbaren Zahlungsdienstleister, welche das SCT Inst Scheme gezeichnet haben, in TIPS (TARGET Instant Payment Settlement) erreichbar sein müssen. Entsprechend muss die Erreichbarkeit in TIPS entweder über eine direkte Teilnahme dort mit eigenem Konto oder über die Reachable-Party-Funktionalität gewährleistet sein. Darüber hinaus sollen alle ACHs (Automated Clearing Houses), welche Instant Payments anbieten, ihre technischen Konten von TARGET2 nach TIPS verlagern. Die Umsetzung der Beschlüsse ist für Ende 2021 vorgesehen.
Immerhin erfordern nicht alle 2021er-Themen von den Zahlungsdiensteanbietern eine derart große Betriebsamkeit: Die Anpassungserfordernisse aus den November-Changes des EPC sind eher überschaubar. Ob man das auch für die DFÜ- und SWIFT-Changes sagen kann, steht noch nicht fest. Es ist aber – zumindest für den reinen Zahlungsverkehr – sehr wahrscheinlich. Größere gesetzliche Fälligkeitsdaten stehen ebenfalls nicht an.

Aber es gibt natürlich noch all die Zahlungsverkehrsvorhaben, die in 2022 und den Folgejahren umgesetzt – und somit in 2021 vorbereitet – werden müssen. Eines der wichtigsten Projekte ist die weltweit anstehende Umstellung des Zahlungsverkehrs auf das ISO-20022-Format.
Im Individualzahlungsverkehr müssen beispielsweise die in 2022 anstehende TARGET2- und die in 2022 beginnende SWIFT-Umstellung vorbereitet werden. In beiden Bereichen stehen neben der reinen Formatumstellung umfangreiche Änderungen in den Abläufen an, wie etwa veränderte Zugangsmechanismen zu den entsprechenden Plattformen. Nach übereinstimmenden Schätzungen geht jedes dieser Projekte über die Dimensionen von SEPA hinaus. 

Im Massenzahlungsverkehr (SEPA) müssen sich Zahlungsdiensteanbieter für die in 2023 anstehende Umstellung der SEPA Schemes auf die (neuere) ISO-Version 2019 fit machen.
Angesichts der mit diesen Umstellungen verbundenen Kosten werden in 2021 Banken – vornehmlich Tier-2-Institute – die Abwicklung des Zahlungsverkehrs zunehmend auslagern oder zumindest Zahlungsverkehrssoftware „As a Ser-vice“ einkaufen. Die entsprechende Nachfrage ist bereits spürbar. Zudem dürften die Stimmen lauter werden, die nach günstigen, zentralen Angeboten für bankenübergreifende Services, wie beispielsweise Sanctions Screening oder KYC, rufen.
Schlussendlich müssen Banken und Finanzdienstleister 2021 Antworten auf anstehende strukturelle Marktumbrüche finden:

• Die Weiterentwicklung der European Payment Initiative (EPI): Gelingt es, eine einheitliche, innovative gesamteuropäische Zahlungslösung als Alternative zu bestehenden internationalen Zahlungslösungen und -systemen zu schaffen?
• Den weiter zunehmenden Druck von EU-Kommission und EU-Parlament auf die Interchange-Gebühren: Wie können Issuer auf eine mögliche „Zero-Interchange“-Regulierung reagieren? Wie sehen zukünftige Ge-schäftsmodelle aus?
• Die sich andeutende Verpflichtung aller Banken durch den EU-Gesetzgeber, Instant Payments anzubieten sowie die stärkere Berück-sichtigung von Verbraucherinteressen in der Rückabwicklung von Instant Payments Zahlungen. Sind die bestehenden Verarbeitungssysteme in der Lage, die zusätzlichen Mengengerüste zu verarbeiten?
• Die deutliche Konsolidierung von Abwicklungsdienstleitern, namentlich die Bildung zweier Konglomerate durch EquensWordline einerseits und NEXI/SIA/Nets andererseits: Was bedeutet das für die Zukunft von kleineren und mittleren Dienstleistern, insbesondere im Acquiring? 
• Die zunehmende Verwischung der Grenzen zwischen kartengestütztem und klassischem Zahlungsverkehr, wie beispielsweise die Aktivitäten von Mastercard (über Vocalink) im Clearing klassischer Bezahlverfahren: Wird es langfristig eine weitere Clearinginfrastruktur im Massenzahlungsverkehr geben? 
• Die anstehende Einführung von digitalem Geld, in Form von digitalem Zentralbankgeld aber auch in Form von Libra: Welche Auswirkungen hat das auf Bargeld oder kartenbasierte Zahlungen? Was bedeutet dies für die Rolle und das Geschäftsmodell von Banken?
• Die Konsequenzen der zunehmenden Verbreitung des Internet of Things (IoT) für den Zahlungsverkehr. Nur mit vollkommen autonomen, unterbrechungsfreien Zahlungsströmen zwischen den verbundenen Geräten können die Potenziale des IoT gehoben werden (Vgl. unsere Studie zum Thema Internet of Payments). Wie können dabei Compliance-anforderungen und IT-Sicherheitsaspekte erfüllt werden? Wie müssen die Verarbeitungssysteme für zusätzliche Milliarden von Transaktionen aufgerüstet werden?

Am chinesischen Neujahrstag 2021 beginnt das Jahr des Büffels. Die chinesische Astrologie schreibt ihm Geduld und Fleiß zu. Er ist stark und überwindet alle Schwierigkeiten. Die Zahlungsverkehrsbranche kann ihn gut gebrauchen.

Autor: Hubertus von Poser (Head of Consulting Payments)

Weiterlesen

Keine Angst vor Standardsoftware im Zahlungsverkehr

Wer sich im Wettbewerb absetzen möchte, entwickelt seine Software selbst. Diese Regel setzt sich mehr und mehr in den Unternehmen durch – und immer mehr „Experten“ empfehlen auch den Banken, sich stärker selbst um die eigenen Anwendungen zu kümmern, ja, sich zu einem Tech-Unternehmen zu entwickeln. Spätestens bei der Zahlungsverkehrsplattform gerät diese Philosophie ins Wanken.

Die Aufsicht fordert beispielsweise einen unterbrechungsfreien Betrieb, sofern eine Bank Instant Payments verarbeiten möchte. Welche Herausforderungen das für die Architektur bedeutet, haben wir beim TRAVIC-Payment Hub am eigenen Leib erfahren. Hinzu kommen die zahlreichen Umsysteme, wie Geldwäsche oder Embargo- und Sanktionslisten, von der Leitwegsteuerung ganz zu schweigen. Alles selbst zu machen, bedeutet allein aus Kostengründen für viele Banken, Zahlungsverkehr dann lieber gar nicht zu machen – also auszulagern oder von einem Zentralinstitut innerhalb eines großen Verbunds erledigen zu lassen. Das aber ist keine Option, sofern sich der Zahlungsverkehr zu einem strategisch wichtigen Geschäftsfeld entwickeln soll.

Jahrmarkt-Karussell für Zahlungen

Wir haben uns deshalb gefragt, was genau die „Special Sauce“ ist, die Banken in ihre ZV-Systeme kippen können müssen, um sich vom Wettbewerb zu unterscheiden und Zahlungsverkehr als eigenes Produkt anbieten zu können. Das ist besonders dann relevant, wenn sich ein Institut darum bewirbt, für Firmenkunden den Zahlungsverkehr in einer bestimmten Weltregion abzuwickeln. Und siehe da: In sich gleichen sich zahlreiche Abläufe von Bank zu Bank, sie unterscheiden sich häufig nur darin, in welcher Reihenfolge sie diese durchführen. Dieser Erkenntnis folgend haben wir das Bild von einer ZV-Plattform entworfen, die wie ein Karussell funktioniert. Jede Spezialfunktion soll, wie Kinder auf dem Rummel, überall zusteigen können (vgl. Abb. 1).





Der TRAVIC-Payment Hub erlaubt einer Bank, jede nur denkbare Konfiguration abzubilden. Das gilt sowohl für die Leitwegsteuerung, für die sich nahezu beliebig komplexe Regelwerke festlegen lassen, wie auch für die anzusteuernden Umsysteme. Woher aber weiß der TRAVIC-Payment Hub, was geschehen soll, wenn etwa vom Compliance-System ein bestimmter Status zurückkommt? Normalerweise müssen sich die Umsysteme doch daran orientieren, was das führende System vorgibt – warum sollte eine Bank, nachdem sie sich möglicherweise in der Kernverarbeitung bereits des Monolithen entledigt hat, sich im Zahlungsverkehr gleich den nächsten hinstellen? Die Antwort liefert eine integrierte Workflow-Engine, die über eine eigene Skriptsprache verfügt, um vergleichsweise simpel – und unabhängig vom Hersteller, also auch von uns – die übrigen Systeme anzubinden.

Das „Hub“ in TRAVIC-Payment Hub ist insofern Produktname und Leistungsversprechen zugleich.

Software-Entwicklung Inside-Out

Technisch krempeln wir das, was sich anderenfalls zu „Legacy“ entwickeln würde, nach außen. Die implementierte Skriptsprache ermöglicht einer Bank, die eigene Fachlichkeit in den TRAVIC-Payment Hub einzufügen, ohne dafür den Quellcode der Software selbst aufmachen zu müssen. Weil Technik und Fachlichkeit voneinander getrennt sind, rückt ein wesentlicher Teil der Software-Entwicklung aus der Sphäre des Herstellers in die Sphäre der Anwender. Dadurch bleibt die ZV-Plattform releasefähig, obwohl der TRAVIC-Payment Hub ein möglicherweise komplexes Netz an Umsystemen steuern muss. Zudem kommen die IT-Abteilungen gar nicht erst in die Versuchung, zu nahe an der ZV-Kernverarbeitung zu entwickeln und damit das Risiko einzugehen, Mikado-Effekte zu erzeugen – an einer Stelle etwas zu verändern und an einer anderen plötzlich ein Problem zu provozieren.

In der Praxis sieht das so aus: Der TRAVIC-Payment Hub nimmt von den angeschlossenen Systemen unterschiedliche Status ein. Über die Skriptsprache legen die eigenen IT-Kollegen oder der Integrationspartner fest, was mit Zahlungen in jedem einzelnen Status geschehen soll. Sobald der Workflow fertig beschrieben ist, kompiliert das System den Code, damit der TRAVIC-Payment Hub arbeiten kann. Das geschieht über von der Workflow-Engine erzeugte Tasks, die eine interne Task-Engine abgearbeitet. Hier ein ganz einfaches Beispiel, wie die von PPI für den TRAVIC-Payment Hub entwickelte Skriptsprache mit OUR-Charges umgeht, also feststellt, ob die fälligen Gebühren einer Zahlungen beiliegen und einbehalten werden dürfen oder eine Zahlungsaufforderung zu erstellen ist.


Status CHECKINBOUNDCHRGS {
if payment is inbound and (payment is ourCharges) then {
if payment is ourChargesReceived then {
just set status VALIDATERECEIVCHGS and leave step
}
if payment is correspondentChargeExpected then {
if payment is debitAuthorized then {
just set status CREATEADVICEOFCHGS and leave step
}
just set status CREATECHARGEREQ and leave step
}
}
just set status DONE and leave step
}



TRAVIC-Payment Hub einführen

PPI bildet mit der TRAVIC-Produktfamilie den gesamten Zahlungsverkehrsprozess einer Bank ab, vom Zahlungseingang über das Interbankengeschäft bis hin zum Clearing. TRAVIC-Payment Hub stellt die Kernverarbeitung für den Zahlungsverkehr dar. Unsere Lösung funktioniert als Kunden- und als Clearingbank – auch im Parallelbetrieb – und kann Instant Payments. Zudem lässt sich die Lösung On-Premises betreiben wie auch als ausgelagerte Hochverfügbarkeitslösung gemeinsam mit unseren Infrastrukturpartnern.

Autor: Thomas Riedel

Mehr Informationen:

• Standardsoftware wie eine Individuallösung nutzen?, Fachbeitrag von Thomas Riedel und Mathias Seeliger, erschienen im IT-Finanzmagazin
• TRAVIC-Payment Hub für Instant Payments
• TRAVIC-Payment Hub für Individualzahlungsverkehr

Weiterlesen