SEPA 2.0: Durch das ISO-20022-Update droht eine 3-fach-Migration

SEPA und der zugrunde liegende ISO-20022 Standard können durchaus als Vorreiter der globalen ISO-20022-Initiativen gesehen werden. Schon frühzeitig stellten sie sich als das Regelwerk für viele unterschiedliche Zahlungsverkehrsformate in der Eurozone dar und bedienten sich dabei eines einheitlichen Formatstandards, um eine grenz- und systemüberschreitende Interoperabilität zu ermöglichen. Trotz einiger lokaler Dialekte hat SEPA über die Jahre - nicht zuletzt durch Angleichungen der nationalen Besonderheiten an eine einheitliche EPC-Vorgabe - eine durchgängige Ende-zu-Ende-Zahlungsverarbeitung ohne Medienbrüche und Konvertierungen ermöglicht. Ende-zu-Ende bezieht sich in diesem Fall nicht nur auf das Interbankenverhältnis, sondern auch auf jenes vom Auftraggeber bis hin zum Empfänger. Ermöglicht wird dies durch die konsequente Nutzung des einheitlichen Datenlexikons (data dictionary) im ISO-20022-Formatstandard, das eine einheitliche Basis für den Datenaustausch darstellt, indem es Datenelemente aus der Kunde-Bank-Nachricht (pain ) in die Interbankenebene (pacs) bis hin zur Bank-Kunde-Sphäre (camt) ohne Konvertierungen transportiert.

Wo sich SEPA weiterentwickelt, z. B. durch die Einführung von Instant Payments, hinkt der für SEPA verwendete ISO-20022-Standard noch immer hinterher: nämlich auf der vom EPC definierten Basis von 2009. Da sich auch dieser ISO-Standard stetig weiterentwickelt, um den aktuellen Entwicklungen Rechnung zu tragen, plant die für die Weiterentwicklung des SEPA Schemes zuständige Arbeitsgruppe des EPC die Migration aller Schemes (SCT, SCT Inst, SDD Core, SDD B2B) auf die Version 2019 des ISO-20022-Standards. So soll der Wechsel in 2020 angekündigt und im Rahmen einer Big-Bang-Umstellung (der Interbanken-Formate) zum November 2022 final gültig werden. Diese Änderung befindet sich derzeit als Major Change Request neben weiteren in einer Öffentlichen Konsultationsphase, um Anmerkungen aus dem Kreis der an der Konsultation teilnehmenden Parteien einzufordern.

Als einer der Gründe, warum dieser CR als wichtig angesehen wird, gilt die zukünftige Unterstützung von Request to Pay, die mit der derzeitigen ISO-Version nicht möglich ist, da zukünftig benötigte Elemente im Format nicht vorhanden sind. Aber auch für andere zukünftige Entwicklungen ist ein aktueller Stand des ISO-Standards erforderlich, insbesondere auch vor dem Hintergrund der TARGET2- und SWIFT-MX-Migrationen, die ebenfalls die Version 2019 des ISO-Standards zugrunde legen.

Gute Nachrichten hierbei: ISO 20022 ist ein in der SEPA-Welt bereits etablierter Standard. Anders als bei der SEPA-Einführung muss hier kein neues Format eingeführt werden und es müssen auch keine Altformate im großen Stil abgelöst werden. Vorhandene Systeme müssen „nur“ angepasst und mit den Änderungen, wie z. B. neuen Datenelementen, umgehen lernen. Dennoch besteht die Herausforderung darin, eine Big-Bang-Migration mit Auswirkungen auf den Interbanken-Zahlungsverkehr sowie Formate an der Kunde-Bank-Schnittstelle zu meistern.

Schlechte Nachrichten: Aufgrund aktueller Entwicklungen fällt nun das SEPA-Umstellungsdatum mit dem Beginn der Umstellungsphase von SWIFT MT auf MX zusammen. Den ursprünglichen Ansatz, das Umstellungsdatum für die SEPA-Umstellung auf 2022 zu legen, hatte man deswegen gewählt, um die drei großen Migrationen – TARGET2, SWIFT MX und SEPA ISO20022 Version 2019 – nicht nahezu zeitgleich durchführen zu müssen und den dafür erforderlichen Aufwand zu entzerren. Sollte nun auch TARGET2, wie erste Forderungen aus dem Markt vermuten lassen, eine Verschiebung der geplanten Big-Bang-Migration um ein Jahr vornehmen, fallen nun doch wieder sämtliche Migrationen zeitlich zusammen, was die betroffenen Finanzdienstleister vor große Herausforderungen stellt und den ursprünglichen Ansatz der Entzerrung zunichtemacht. Die Schuldfrage hierfür ist schnell beantwortet: die globale Corona-Pandemie, die unser Leben und die Wirtschaft derzeit vor harte Prüfungen stellt.

Banken und Kreditinstitute sind in dieser Situation aufgefordert, die weitere Entwicklung im Auge zu behalten und sich auf die anstehenden Änderungen einzustellen. Wir werden die weitere Entwicklung ebenfalls eng begleiten und nach Abschluss der Marktkonsultation weiter über die SEPA-ISO-Änderungen berichten.

Autor: René Keller

PSD2: Sammlerzahlungen via EBICS absichern

Sammlerzahlungen abzusichern, war schon immer ein Thema. Die frühen Versuche, dafür einen einfachen Schutz vor Manipulation zu etablieren, waren eher halbherzig und haben deshalb auch nie zu einer verlässlichen Absicherung geführt. Beispielsweise wurde zunächst die Summe aller Empfänger-Kontonummern gebildet, um zu verhindern, dass Kriminelle nachträglich die Zahlungen verändern. Als dann die IBAN kam, war es aber selbst mit dieser äußerst simplen Methode vorbei – allein wegen der mathematischen Herausforderungen haben die Banken schließlich ganz darauf verzichtet.

Übrig geblieben sind bis heute allein die Anzahl der enthaltenen Zahlungen und die Gesamtsumme. Dass solche Werte einen wirksamen Schutz darstellen, behauptet erst gar keiner.

Vielversprechender war schon eher, über PSD2 und RTS für mehr Sicherheit bei Zahlungen zu sorgen. Doch für die gerade bei Firmenkunden geläufigen Sammelzahlungen war das noch nicht der Durchbruch. Der Grund: Empfänger, Konto und Betrag anzuzeigen und den Auftraggeber etwa via Dynamic Linking mit allen enthaltenen Daten prüfen zu lassen, ist bei Gehaltszahlungen in einem Unternehmen mit mehr als 10.000 Mitarbeiten kaum sinnvoll zu bewerkstelligen. Allein organisatorisch ist dies schon ein Ding der Unmöglichkeit und technisch kaum auf den etablierten Kanälen zu lösen.

Also wie nun sicherstellen, dass die einmal erzeugte Zahlungsdatei auch unverändert bei der Bank zur Ausführung angekommen ist?

EBICS!

EBICS ist im europäischen Firmenkundenzahlungsverkehr seit Jahren Standard – verfügbar in allen großen Ländern mit hohen ZV-Transaktionszahlen, wie Deutschland, Frankreich Österreich und der Schweiz. Weitere Länder werden folgen.

Also warum definiert die EBICS-Gesellschaft nicht einen allgemeinen und verpflichtenden Prüfstandard, der auf internationalen Hashwertverfahren (z. B. SHA-256) basiert und legt das Regelwerk dazu fest? Das Prinzip: Alle Anwendungen, die ZV-Sammlerdateien erzeugen, generieren dabei auch immer gleich den dazu passenden Hashwert und geben diesen zusammen mit der Zahlungsdatei an die Bank. Dort lässt sich dieser Kontrollwert erneut berechnen, sobald die ZV-Datei ankommt, und dem Kunden vor Freigabe zur Prüfung vorlegen. Fertig.

Einfach und sehr effektiv, weil der identische Hashwert garantiert, dass zwischen der Erstellung der Sammlerdatei und vor der Verarbeitung des Sammlers bei der Bank keine Manipulation stattgefunden hat.

Wenn wir bei der Definition des zu nutzenden Hashwertverfahrens seitens der EBICS-Gesellschaft dann auch noch an den armen Endkunden denken, könnte man statt des 32-Doppelwert-Vergleichs einen Algorithmus finden, der aus dem Hashwert eine Nummer mit 8-10 Stellen – ähnlich einer TAN – macht. Mit diesen Werten können die Kunden und Nutzer heute bereits umgehen. Kontrollwerte zu vergleichen, kostet dabei nur minimal mehr Zeit und ist einfach zu machen.

Diese Definition einfach dem Markt zu überlassen, ist übrigens keine gute Idee. Wenn jeder beteiligte Akteur sein eigenes Süppchen kocht, entsteht eine Vielzahl unterschiedlicher Verfahren, die Kunden eher verwirren als für zusätzliche Sicherheit zu sorgen.

Deshalb gehört es zu den Aufgaben der EBICS Gesellschaft, an dieser Stelle für eine verbindliche Lösung zu sorgen und dadurch endlich auch der PSD2 bei Sammlerzahlungen zu genügen.

Autor: Michael Schunk