Zahlungsverkehr: 5 Anforderungen an eine Payment Engine

Der Zahlungsverkehr wird immer 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. Die heutigen Marktplayer – darunter die Großbanken sowie der genossenschaftliche und Sparkassenverband – bekommen starke Konkurrenz. Die GAFAM inspirieren mit ihren Produkten (z.B. PayPal, Apple Pay, Google Pay) auch andere IT-Player in das Thema Zahlungsverkehr einzusteigen. Blockchain und Kryptowährungen erfordern neue, innovative, performante und aus Sicht IT Security sichere Paymentlösungen zu entwickeln.  

Was bedeutet dies für den Endkunden?

Für den Endverbraucher bieten sich durch die Umbrüche im Zahlungsverkehr in jedem Fall eine Menge Vorteile. Er kann sich flexibler und selbstbestimmter aussuchen, mit wem, wie und wann Zahlungen mit welcher Währung 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. Die EZB und die zentralen Banken reagieren darauf mit eigenen Initiativen u.a. TARGET2 (T2), PSD2 und PEPS-I.

Die Hälfte der Zahlungen in der Eurozone erfolgt über Karten oder E-Geld (PayPal etc.). 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 knapp die Hälfte der insgesamt 101,6 Milliarden bargeldlosen Zahlungen (Stand: 2020) aus, die jährlich in der Eurozone erfolgen.

Zahlungsverkehr im Umbruch

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 Jahr durch T2 abgelöst. Dabei werden aus technischer Sicht alle in der TARGET2-Plattform genutzten MT-Nachrichten durch ihre MX-Äquivalente (ISO-20022-konform) ersetzt.

Gleichzeitig wird SWIFT, der Betreiber des Telekommunikationsnetzes SWIFTnet, den auf den Zahlungsverkehr bezogenen Nachrichtenaustausch zwischen Banken im Zeitraum November 2022 bis November 2025 auf den ISO-20022-Standard umstellen. Das bedeutet eine dreijährige Koexistenz-Phase für die parallele Verarbeitung der bisherigen MT- und der neuen ISO 20022-Nachrichten im SWIFT-System. 

Payment muss genau heute neu gedacht werden

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 mit dem Zahlungsverkehr in der Legacy-Falle.

Nun stellte sich auch für PASS wieder die Frage, ob man einen neuen architektonischen Schritt wagen soll oder die aktuellen Systeme für den Zahlungsverkehr nochmals erweitert. Zum Beispiel wieder einen neuen Konverter anbauen, das wäre doch der einfachste Weg! Wir haben hierzu „Nein“ gesagt und die Chance ergriffen, eine neue Payment Engine zu entwickeln. Diese folgt dem Grundsatz unserer Full Open Banking Architecture und zeichnet sich somit durch radikale Offenheit auf allen Ebenen aus. 

Was muss eine zukunftsorientierte Payment Engine mitbringen?

1. Open Platform

Eine Payment Engine muss über die SWIFT-, TARGET2-, SEPA-Bereiche sowie Instant Payment einheitliche Prozesse – validieren, disponieren, AML-Check und buchen – anbieten. Die STP-Rate sollte durch kluge und vernetzte einzelne Bestandteile die Verarbeitung von Zahlungsdateien kompromisslos automatisieren.

Außerdem sollte eine Payment Engine 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 Whitelabelings von hoher Bedeutung.

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 muss 24/7 und 365 Tage im Jahr Zahlungen prozessieren und bestätigen können. Insbesondere für Banken, die einen zeitlich längeren Tagesabschluss haben, bedeutet dies neune innovative Lösungen. Im Bereich der Instant-Zahlungen gibt es klare Performance-Vorgaben: Eine Zahlungstransaktion muss in Echtzeit (max. zehn Sekunden) abgewickelt werden, d.h. für den Endkunden, dass er spätestens nach zehn Sekunden eine von ihm ausgelöste Transaktion bei dem Empfänger auf dem Konto sichtbar ist und gleichzeitig sein Saldo auf dem Konto aktualisiert wird.  

4. Automatisierte Tests

Aufgrund der hohen Änderungsdynamik und der Komplexität muss das Thema automatisierte Integrationstests in den Blickpunkt rücken. Das Unit-Tests wichtig sind, steht außer Frage. Aber eine Payment Engine muss nachvollziehbare automatisierte Integrationstests mitbringen. Ziel ist es, die Kunden (u.a. Banken und deren Mitarbeiter) stark zu entlasten und die Tests auf die in ihrem Haus vorhandenen Spezifika abzustellen.

5. Open Product / Open Service

Die Anforderungen, die Partner und FinTechs an Banken stellen, gehen über den reinen Abwickler hinaus. Sie möchten verschiedene Produkte des Zahlungsverkehrs von einer Bank erhalten. Partner und FinTechs suchen nach Möglichkeiten, in eine stärkere Kommunikation einzutreten. Die Payment Engine muss einen Baukasten an Zahlungsoptionen beinhalten, aus dem sich das FinTech oder der Partner seine Produkte selbst zusammenstellen kann. Darüber hinaus muss er leicht eigene Produkte sowie Prozesse ergänzen können. 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.