All goes ISO 20022

Mit dem Titel wird der allgemeine Wechsel auf ISO 20022 im gesamten Zahlungsverkehr sowie im dazugehörigen Reporting bezeichnet. An dieser Stelle hat mein Kollege René Keller über die Pläne von TARGET2 und SWIFT geschrieben, nun auch auf den schon aus SEPA bekannten ISO-20022-Standard im Individual- und Auslandszahlungsverkehr zu setzen. Die dort beschriebenen Änderungen, insbesondere im Interbanken-Zahlungsverkehr, wirken sich nun auch auf die Kunde-Bank-Schnittstelle aus.

So wie sich Corona an vielen anderen Stellen negativ auswirkt, so finden sich die Folgen auch hier in verschobenen Zeitplänen. Die Änderungen kommen – allerdings etwas später. Die Zeit sollte gut genutzt werden, denn es handelt sich hierbei nicht um reine IT-Themen, sondern mit der neuen Sprache verändern sich viele Prozesse im Zahlungsverkehr und im angrenzenden Umfeld grundlegend und die Auswirkungen sind in der gesamten Architektur zu berücksichtigen. Das gilt für Banken und auch für Firmenkunden, die einige Änderungen in den kommenden Releases bewältigen müssen. Die Informationen liegen in den Ankündigungen nun in der Anlage 3 zum DFÜ-Abkommen vor, reichen einige Jahre in die Zukunft, sind aber auch nötig.

An manchen Stellen wird das Argument „die anstehenden Änderungen sind doch gar nicht so massiv, mit SEPA ist uns das XML-Format doch bekannt“ ins Feld geführt. Wenn das bei SEPA verwendete Format „gut bekannt“ ist, dann ist das eine sehr gute Ausgangsbasis, um sich auf die Änderungen vorzubereiten. Es geht aber um weit mehr. Zum einen steht für SEPA ein Release-Sprung an, zum anderen gibt es gerade im Individual- und Auslandszahlungsverkehr eine ganze Reihe von Besonderheiten, die im Massenzahlungsverkehr so gar nicht vorkommen. Darüber hinaus kommt aus regulatorischen Gründen der Wechsel auf strukturierte Adressangaben. In der Summe der Änderungen liegt die Herausforderung.

camt.053 – Versionsänderung

Mit der Einführung von SEPA und dem europaweiten einheitlichem Format auf der Basis von ISO 20022 wurde auch der Kontoauszug camt.053 neben dem bisher üblichen MT940 eingeführt. Für SEPA-Zahlungen das ideale Format, denn nun konnten Daten aus einem einheitliche Datenlexikon (data dictionary) über pain (Kunde-Bank) und pacs (Interbank) auch als Kontoauszug transportiert werden. Aber neben den Buchungen im Massenzahlungsverkehr gab es auch noch den Individual- sowie den Auslandszahlungsverkehr. Aus diesem Grunde (und verschiedensten anderen) blieben gar nicht so wenige Unternehmen bei dem altbekannten Format.

Die Einführung von ISO 20022 im gesamten Interbanken-Zahlungsverkehr erfolgt nun aber auf einem aktuellen ISO-Release, dem von 2019. SEPA nutzt immer noch das ISO-Release von 2009. Wie bei jedem Standard gibt es auch bei ISO 20022 natürlich diverse Gründe für die Weiterentwicklung des Formats, und die wird es auch weiterhin geben. Es werden neue Felder eingeführt oder Codewörter erweitert werden. Der Kontoauszug, der all die neuen Informationen an den Endkunden ohne Datenverlust weitertragen soll, muss sich also auch dem neuen Standard fügen, und so ist für camt die Umstellung vom camt.053.001.02 auf das neue Release camt.053.001.08 unumgänglich (analog für camt.052 und camt.054). Durch die frühzeitige Information von Firmenkunden ist hier nun auch ausreichend Zeit für oftmals längere ERP-Releasezyklen gegeben. Zumal auch damit zu rechnen ist, dass mit einer Verschiebung der TARGET2-Umstellung auf ISO 20022 auch die Umstellung hier verschoben werden wird.

MT940-Abkündigung

SWIFT wird die MT-Nachrichten der Kategorie 1,2 und 9 zum November 2025 im Interbankenverkehr einstellen. An der Kunde-Bank-Schnittstelle (insb. bei SCORE) soll diese Einschränkung nicht gelten, hier sind die Banken weltweit in ihrem Service nicht gezwungen, MT101 oder gar MT940 abzuschalten. Aber die DK hat dies für unseren „Multibank-Standard“ beschlossen – und das ist gut so. Wer als Bank möchte, darf ja noch MT940 anbieten, aber die Vorteile der neuen Sprache liegen schon auf der Hand: Ganze XML-Strukturen können von pain über pacs zu camt ohne Konvertierung transportiert werden. Da ist die Analogie von Containern in der Logistik schon naheliegend. Und in diese Vorteile hinein sollten alle Firmenkunden hinein„gedrängt“ werden.

DTAZV wird pain.001

Mit der Einführung von pain.001 als Kundenauftrag für eine SEPA-Überweisung war schnell die Frage aufgeworfen: Warum kann man dieses Format nicht auch für Währungszahlungen benutzen? Zur harmonisierten Nutzung dieses globalen Standards hat sich dann alsbald die Initiative CGI-MP (Common Global Implementation – Market Practice) aus Corporates, Banken und Herstellern gefunden, um eine harmonisierte Belegung festzulegen. Die CGI-Version von pain.001 beruht aber wie die SEPA-Version auf dem ISO-Release 2009 – also pain.001.001.03. Die CGI-MP arbeitet an einer neuen Version (ISO-Release 2019) der harmonisierten Belegung. Die neue AZV-Einreichung in der Anlage 3 wird auch nach ISO 2019 erfolgen – somit pain.001.001.09.

Und wie so oft, liegt in dem Wechsel auf „alles in ISO 20022“ auch eine große Chance. Durchgehende Prozesse auf der gleichen Datenbasis, die ohne Konvertierungen bewältigt werden können. Die Basis für eine weitergehende Digitalisierung sind nun einmal Standards, mit „alles in ISO 20022“ ist ein durchgehender Standard gegeben, der auch für angrenzende Prozesse „Exception & Investigation“ (Rückfragen), Avise, Bankentgeltnachrichten (Bank Service Billing camt.086) sowie auch im BAM (Bank Account Management) als eBAM-Nachrichten genutzt wird. Da ist dann wiederum Zahlungsverkehr (inkl. Kontoauszug) nur ein kleiner Ausschnitt im gesamten ISO-Universum.


Autor: Mario Reichel

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: