Der Zahlungsverkehr wird wettbewerbsintensiver, komplexer und globaler. Wir erkennen, dass FinTech-Kooperationen mit Banken durch kluges kombinieren von Bankdienstleistung und Zahlungsverkehr Produkte erschaffen, die weit in die Wertschöpfungsketten von Banken hineinreichen. Warum es für Banken so wichtig ist, jetzt das Thema Zahlungsverkehr neu zu denken.
Mit den charmanten Wallet-Lösungen (PayPal, Apple Pay, Google Pay etc.) haben die Big- und FinTechs ein klares unverkennbares Ziel: Die Daten sowie das Einkaufsverhalten ihrer Nutzer. Durch hervorragende Nutzererfahrungen werden jene Kunden zu Fans werden.
Was bedeutet dies für den Endkunden?
Für den Endverbraucher bieten sich in jedem Fall eine Menge Vorteile. Er kann sich flexibler und selbstbestimmter aussuchen, mit wem, wie und wann Zahlungen durchgeführt werden. Beim Bezahlen kann er die Ware auf Raten oder erst in X Tagen begleichen. Wenn er will, kann er sogar bereits geleistete Zahlungen nachträglich finanzieren, um schnell Liquidität zu gewinnen.
Für den Zahlungsverkehr (Payment) bedeutet dies eine hohe Änderungsdynamik insbesondere durch die Aufsichtsbehörden: TARGET2, PSD2, PEPS-I, Open Banking, Mobile Payment, Blockchain – allein diese Begriffe verdeutlichen, dass der Wandel im Zahlungsverkehr ungebremst weiter voranschreitet.
Die Hälfte der Zahlungen in der Eurozone erfolgt über Karten oder E-Geld (PayPal und ähnliches). Blendet man den B2B-Zahlungsverkehr aus, basiert die Hälfte der Zahlungen nicht auf einheitlichen europäischen oder internationalen Zahlungssystemen, sondern auf einer Vielzahl nationaler und internationaler Systeme. Für die andere Hälfte der Zahlungen ist ISO20022 die Zukunft. Überweisungen und Lastschriften machen die andere Hälfte der insgesamt 90,6 Milliarden bargeldlosen Zahlungen aus, die jährlich in der Eurozone (2018) erfolgen.
Am 22. Juni 2015 hat die Europäische Zentralbank (EZB) den Startschuss für die Markteinführung von TARGET2 im Zahlungsverkehr gegeben – eine Initiative die auf Basis der in 2006 gestarteten TARGET2-Securities (T2S) beruht. Die EZB möchte damit sowohl für den Wertpapierbereich als auch für den Zahlungsverkehr eine einheitliche Plattform mit einheitlichen Infrastrukturkomponenten schaffen.
Das Zahlungssystem der Zentralbanken des Euroraumes, TARGET2, wird in diesem Konsolidierungsprojekt in ein neues Modul T2 überführt. Dabei werden aus technischer Sicht alle in der TARGET2-Plattform genutzten MT-Nachrichten zu einem fest definierten Zeitpunkt (November 2021) durch ihre MX-Äquivalente (ISO-20022-konform) ersetzt.
Gleichzeitig hat SWIFT, der Betreiber des Telekommunikationsnetzes SWIFTnet, beschlossen, den zahlungsverkehrsbezogenen Nachrichtenaustausch zwischen Banken im Zeitraum November 2021 bis November 2025 auf den ISO 20022-Standard umzustellen. Das bedeutet eine vierjährige Koexistenz-Phase für die parallele Verarbeitung der bisherigen MT- und der neuen ISO 20022-Nachrichten im SWIFT-System. Wobei neueste Informationen besagen, dass sich die Termine für SWIFT verschieben werden.
Durch die konsequente Nutzung von ISO 20022-konformen Nachrichten über alle Serviceangebote des Eurosystems hinweg erfolgt die Kommunikation auf Basis des neuesten Standards. Die systematische Nutzung von ISO 20022-konformen Nachrichten folgt einem internationalen Trend.
Mit der Einführung eines zentralen Liquiditätsmanagements (Central Liquidity Management – CLM) erhalten die teilnehmenden Banken einen Überblick über ihre Zentralbankliquidität und können diese flexibel und komfortabel den einzelnen Abwicklungsservices zuordnen. Außerdem ermöglicht die neue Struktur künftig eine Trennung der Abwicklung von Zentralbanktransaktionen vom Individualzahlungsverkehr.
Payment muss genau jetzt neu gedacht werden
Häufig erfolgt die Umsetzung von TARGET2 gemäß dem Motto: „Neues Format? Kein Problem, da bauen wir bei PASS eben einen neuen Konverter!“. Das erinnert stark an den Film mit dem Wettermann Phil Connors „Und täglich grüßt das Murmeltier“.
Bereits bei der Umsetzung von SEPA 2014 stellte sich für die Anbieter von Payment-Systemen die Frage, ob bestehende Module um neue Anforderungen und Formate erweitert werden oder ob man die Chance nutzen sollte, Zahlungsverkehr neu zu konzipieren. Viele haben sich damals dafür entschieden, auf den alten DTA Formaten aufzusetzen und die SEPA-Änderungen zu implementieren. Heute muss man mit den Konsequenzen leben. Bei den jährlichen Anpassungen der SEPA Rule Books stoßen Business-Analysten und Entwickler aufgrund der historischen Architektur auf größere Herausforderungen. Existierende Prozesse mussten verbogen werden. Das Ende vom Lied: Wir sitzen in der Legacy-Falle.
Nun stellt sich nach einigen Jahren wieder die Frage, ob man einen neuen architektonischen Schritt wagen soll oder die aktuellen Systeme nochmals erweitert. Zum Beispiel wieder einen neuen Konverter anbauen, das wäre doch der einfachste Weg!
An dieser Stelle möchte ich laut „Nein!“ rufen, denn die Zukunft spricht ISO20022. Wenn wir uns damit beschäftigen, wie wir DTA und MT in ein ISO20022-Format pressen, können wir uns nicht auf den Zahlungsverkehr der Zukunft konzentrieren. Wir können uns nicht darauf konzentrieren, die oben erwähnten Erfolgsprodukte zu bauen, sodass wir Endverbraucher und Unternehmen begeistern.
Was muss eine zukunftsorientierte Payment Engine mitbringen?
1. Prozesse / Architektur
Eine Payment Engine muss über die SWIFT-, TARGET2- und SEPA-Bereiche einheitliche Prozesse – Validieren, Disponieren, AML Check und Buchen – anbieten. Natürlich dort wo es sinnhaft ist. Die STP Rate sollte durch kluge und vernetzte einzelne Bestandteile die Verarbeitung von Zahlungsdateien kompromisslos automatisieren.
2. Performance, Performance und wieder Performance
Eine Payment Engine sollte auf die Abwicklung von hohem Volumen ausgerichtet sein. Zunehmend stellen wir fest, dass mittelständische Banken durch Kooperationen mit FinTechs vor der Herausforderung stehen, Massenzahlungen abzuwickeln. Dafür muss das System ausgerichtet sein. Vergessen wird meist, dass sich die Nutzungsart der Abwicklung verändert hat. Der Trend wechselt zunehmend von Sammlern auf Einzeltransaktionen (PAIN001 sowie auf RESTful API Calls). Es sind weniger die großen PAIN001-Nachrichten, die als Sammler verarbeitet werden, sondern viele nicht planbare Einzeltransaktionen. Diese müssen mit mehreren Threads vom System abgearbeitet werden.
3. Verfügbarkeit
Eine Payment Engine sollte nicht nur auf skalierbaren Services etabliert sein, sondern auch beliebig viele Microservices bei Bedarf und Ausfall hinzuschalten können. Um relevant zu bleiben, müssen wir uns von TARGET-Feiertagen und -Wochenenden verabschieden. Die neue Software muss 24/7 und 365 Tage im Jahr Zahlungen bestätigen können.
4. Automatisierte Tests
Aufgrund der hohen Änderungsdynamik muss das Thema automatisierte Integrationstests in den Blickpunkt rücken. Das Unit-Tests wichtig sind, steht außer Frage. Aber ein Payment-System muss nachvollziehbare Integrationstests mitbringen. Ziel ist es, die Banken und deren Mitarbeiter stark zu entlasten.
5. Offene Architektur
Eine Payment Engine sollte eine offene Architektur gegenüber zentralen und dezentralen Core-Banking-Systemen besitzen sowie „stand alone“ unabhängig vom genutzten Core-Banking-System oder anderen Drittsystemen betrieben werden können. Durch standardisierte Schnittstellen, kann die Bank schnell und kostengünstig neue Partner, Corporates und FinTechs anbinden. Insofern die Bank es in ihre Plattformstrategie mit aufnimmt, ist eine Möglichkeit des Whitelabeling von hoher Bedeutung.
Frankreich strebt bereits Regelungen zum Thema Bitcoin und Bewertung von Kryptowährungen an. Es wird nicht das einzige Land in Europa sein, das in näherer Zukunft regulatorische Maßnahmen ergreift. Somit muss eine Payment Engine die Möglichkeit mitbringen, in engem Austausch zu verschiedenen Nodes zu stehen.
6. Produkt-Builder
Die Anforderungen, die Partner und FinTechs an Banken stellen, gehen über den reinen Abwickler hinaus. Sie möchten verschiedene Zahlungsverkehrsprodukte von einer Bank erhalten. Partner und FinTechs suchen nach Möglichkeiten, in eine stärkere Kommunikation einzutreten. Die Plattform muss einen Baukasten an Zahlungsoptionen beinhalten, aus dem sich das FinTech oder der Partner ihre Produkte selbst zusammenstellen. Der Produktservice muss von der Bank mit SLAs und KPIs auf einer digitalen Plattform angeboten werden. Wir nehmen verstärkt den Wunsch wahr, dass die Bearbeitung von Aufgaben, die originär in der Verantwortung der Bank lagen, nun von Partnern erledigt werden. Deshalb muss eine Payment Engine neben dem Produkt-Builder auch ein Selfservice-Portal für Partner anbieten.
Wie stellt PASS sich auf?
PASS wählt hier anstatt des Pflichtprogramms die Kür. Vor dem Hintergrund der Bundesbankinitiative TARGET2 haben wir die Möglichkeit genutzt, um dem Markt eine komplett neuentwickelte Payment Engine, PASSmultiPay, zu präsentieren. Wir haben den Fokus darauf gelegt, unsere Kunden mit einer hoch performanten und stabilen Zahlungsverkehrsplattform zu beliefern. Ziel ist es, eine Payment-Plattform zu etablieren, mit welcher die Anwenderbanken vielfältige Nutzungsmodelle und Produkte anbieten können. Vom Endkundengeschäft bis zum White-Labeling sollen die Grenzkosten für eine weitere Kundeneinheit eines Produkttyps wettbewerbsfähig mit anderen großen Zahlungsverkehrsanbietern sein. Dies erreichen wir durch hohe Flexibilität innerhalb der Anwendung und kompromisslose Automation. Neben den externen Clearing-Systemen wie SWIFT und Bundesbank kann PASSmultiPay auch plattforminterne Zahlungen abwickeln. Zwei Korrespondenzbanken können über die Plattform, außerhalb der SWIFT- und SEPA-Infrastruktur, Transaktionen austauschen.
Bild: Shutterstock
