Instant Payments: Scheitert die Revolution an einer technologischen Fehlzündung?

Sekunden anstatt Tage: mit Instant Payments rücken Echtzeitzahlungen in greifbare Nähe. Wäre da nicht die technologische Realität.

Die Europäische Zentralbank (EZB) und das European Retail Payments Board (ERPB) treiben die Payment-Revolution mit aller Kraft voran. Polen, Finnland, Großbritannien, Norwegen und Japan setzen z.B. bereits Instant Payments um – und sind Deutschland damit ein ganzes Stück voraus.

Hier werden die Vorgaben für SEPA Instant Payments im besten Fall Ende 2017 gezeichnet und treten ab 2019/2020 verbindlich in Kraft. Wir müssen uns also noch gedulden. Und offen gesagt: Stand heute wäre kaum ein Kernbankensystem in der Lage, diese Herausforderung ohne Weiteres zu stemmen.

Bye, bye Batchverarbeitung

Es sind vor allem zwei technologische Hürden zu meistern: Zum einen muss eine neue Abrechnungsplattform etabliert werden, die Zahlungen in Echtzeit verbucht – und nicht wie heute bei der Bundesbank nur zu einer bestimmten Tageszeit. Zum anderen müssen sich Banken von ihrer Batchverarbeitung am Tagesende verabschieden und ebenfalls in Echtzeit buchen. Nur so kann eine Überweisung dem Zahlungsempfänger innerhalb von Sekunden verbindlich angezeigt werden. Der Erfolg von PayPal beruht übrigens genau auf dieser Eigenschaft. Hier bedient man sich virtueller Konten, um die Zahlung sofort zu bestätigen. Ohne PayPal & Co. ist die Realität für den Kunden heute eine andere: er muss teilweise mehrere Tage warten, bis eine Buchung auf das Zielkonto erfolgt. Auf mich wirkt das, als ob ein Bankmitarbeiter Lochkarten von der einen zur anderen Maschine tragen würde.

In anderen Branchen sind Realzeit-Verarbeitungen längst Alltag. Man stelle sich vor, man müsste mehrere Tage warten, bis der gebuchte Flug bestätigt würde. Und auch der Finanzbranche ist das Thema grundsätzlich nicht fremd: der Hochtransaktionshandel steht in voller Blüte und es wird viel Geld für schnelle Verbindungen zu den Börsensystemen gezahlt. Nur Überweisungen von Privatkunden – die brauchen immer noch Tage. Das ist zum einen althergebrachten Geschäftsprozessen geschuldet, zum anderen beinhaltet eine Softwareumstellung auf Realzeitumgebungen einige Herausforderungen. Gerade ältere Banksysteme sind nicht darauf ausgelegt, Echtzeitverarbeitungen durchzuführen. Mit einer „kleinen Erweiterung“ ist es demnach in den meisten Fällen nicht getan. Benötigt wird eine neue, moderne Architektur.

Auslöser beseitigen anstatt Symptome bekämpfen

So weit, so klar – nur fällt eine neue Architektur bekanntermaßen nicht vom Himmel. Gerade Finanzinstitute, deren Kernbankensysteme auf Altsprachen (z.B. PL/1, COBOL, RPG) basieren, werden eine Menge Zeit und Geld aufbringen müssen, um fit für Instant Payments zu werden. Die Buchungslogik muss von Grund auf modernisiert werden. Gleiches gilt für die gesamte mit der Buchung verbundene Businesslogik: Meldewesen, Anti Money Laundering sowie weitere regulatorische Vorgaben – alles muss zukünftig in Echtzeit durchgeführt werden.

Warum nicht die Chance nutzen und heterogene Legacy-Systeme in Rente schicken? Zumal sich diese oft durch Intransparenz, Redundanz, eine hohe Fehlerintensität und inperformante Entwicklungstechnologien auszeichnen. So kann es in der Konsequenz passieren, dass die Anpassung einer einzigen Funktion an mehr als hundert anderen Stellen vollzogen werden muss. Die klassischen Alternativen: Neuentwicklung oder die Ablösung durch eine Standardsoftware. Eine Neuentwicklung ist sehr kostenintensiv und birgt das Risiko, dass die ausgefeilte Businesslogik verloren geht. Eine Standardsoftware ist eine interessante Option, bei einem hohen Individualisierungsgrad (der bei den meisten Banksystemen Fakt ist) jedoch nicht die eleganteste Lösung. Tiefgreifende Änderungen im Geschäftsalltag kosten im Zweifelsfall viel Nerven und Geld – beispielhaft sei hier das Projekt Magellan der Deutschen Bank genannt.

Die alte Software in neuem Gewand

Eine weitere Möglichkeit, die allerdings oft vergessen wird, ist die (automatisierte) Migration des Altsystems auf eine moderne, objektorientierte Umgebung. Das hat den Vorteil, dass die Programmlogik 1:1 erhalten bleibt. Die Stolpersteine einer Neuentwicklung (Code Freeze, Kosten- und Zeitaufwand oder lückenhafte Dokumentationen) spielen hier kaum eine Rolle. Unter dem Strich wird eine schnellere und effizientere Entwicklung ermöglicht. Und das ist nicht nur im Hinblick auf Instant Payments zentral, sondern auch vor dem Hintergrund wachsender regulatorischer Anforderungen und „digitaler Kundenansprüche“.

 

Bildquelle: Shutterstock

Schreibe einen Kommentar

Ähnliche Artikel