ISO 20022: Banken in der Konverter-Falle – wie MT richtig auf MX mappen?
Senacor
Banken, die der reinen Lehre bei ISO 20022 folgen, tauschen ihr Kernbanksystem aus und machen ihre gesamte IT-Plattform fit für die neue Payments-Welt. Viele setzen auf einen Konverter, um sich die dafür nötige Zeit zu verschaffen.
Wer hofft, dauerhaft mit einem Konverter auszukommen, züchtet sich dagegen bloß einen weiteren Monolithen heran, der das Institut wie ein Betonklotz im Wasser nach unten zieht.”
von Christiane Neumüller und Robert Wappler, Senacor
Der Zahlungsverkehr gilt als eine der letzten Bastionen, in denen sich für Banken noch Geld verdienen lässt.
Senacor
Nicht zuletzt deshalb hat Thomas Ullrich, Vorstand der genossenschaftlichen DZ Bank, schon vor Jahren erklärt, dass dies für das Institut „ein strategisches Geschäftsfeld“ darstellt. Künftig will die Bank den Zahlungsverkehr wieder selbst stemmen. Kein Wunder, als zweitgrößte Geschäftsbank Deutschlands spielt das Institut eine wichtige Rolle im SEPA-Clearing und im weltweiten Netz der Korrespondenzbanken.
Doch auch für diejenigen, die den Zahlungsverkehr auslagern, gilt: irgendwann müssen die Daten ins Kernbanksystem.”
Mit einem Konverter, der die ab November kommenden Jahres eingehenden MX-Nachrichten in die bisherigen MT-Formate übersetzt (vgl. Abb. 1), tun sich die Institute langfristig allerdings keinen Gefallen, weil sie die digitalen Helfer aufwendig pflegen müssen.
Senacor
Dieses Szenario geht davon aus, dass ein Konverter die eingehenden MX-Nachrichten in das bisherige MT-Format konvertiert und ansonsten alles beim Alten bleibt. Zwar wechseln nach und nach alle einliefernden Clients auf das neue Format, bis nach der Koexistenzphase 2025 nur noch MX-Nachrichten eingehen. Doch das bedeutet auf den ersten Blick nur, mehr Power für den Konverter bereitzustellen. Das führt allerdings zu drei gravierenden Problemen:
- Die Aufsicht verlangt, dass eine Bank für obligatorische AML- und Fraud-Kontrollen mit den Originaldaten arbeitet.
- Erfassen die in XML erzeugten MX-Nachrichtentypen einen größeren Datenraum, der die bisherigen MT-Felder überfordern kann und deshalb Datenverluste nach sich zieht, sobald der Konverter von MX nach MT übersetzt.
- Entwickelt sich der ISO-20022-Standard stetig weiter, so dass die Bank den Konverter wie ein eigenes IT-System behandeln und laufend pflegen muss.
MT-Nachrichten parsen
In der Praxis führt all das dazu, dass die Zahlungsverkehrsdaten parallel in beiden Formaten vorgehalten werden müssen. Zudem gilt ab 2025, dass die Bank keine MT-Nachrichten mehr an andere Institute verschicken darf. Sie muss also von MX nach MT übersetzen und von MT nach MX, sofern sie keine aufwendige Synchronisation zwischen Kernbanksystem und ZV-Plattform aufbauen möchte. Viele Institute unterschätzen dabei, wie schwierig dieses Hin und Her zu programmieren ist. Eine simple Zahlung Bank an Kunde (SWIFT MT103) zu parsen, um an die enthaltenen Informationen heranzukommen, ist keine leichte Übung:
{1:BASIC HEADER}
{2:APPLICATION HEADER}
{3:{108:MT103}}
{4:
:20:ABSENDERREFERENZ
:23B:CRED
:32A:YYMMDDUSD9229,99
:33B:USD9229,99
:50A:AUFTRAGGEBENDER
KUNDE
:52A:KONTONUMMER (BIC Auftraggeberbank)
:53A:KONTONUMMER (BIC Zwischenbank)
:57A:KONTONUMMER (BIC Empfängerbank)
:59:/PARTYIDENTIFIER (optional)
EMPFANGENDER
KUNDE
:70:/RFB/VERWENDUNGSZWECK
:71A:SHA (Gebühren)
-}
Wer es sich besonders leicht machen möchte, kann auch die jeweils nächsten n Zeichen in eigene Variablen schreiben und kommt – wegen der statischen Feldlängen – zu dem gleichen Ergebnis. Vorausgesetzt, der Konverter validiert die ausgelesenen Daten. Ähnlich lässt sich auch mit dem zweiten Block {2: verfahren. Am Ende des Blocks steht jedoch ein optionales, komplexes Feld, das der Parser berücksichtigen muss. Das Problem: In einigen Fällen legt ein anderes Feld fest, ob das zusätzliche Feld da sein soll oder nicht. Das macht das Parsen und Validieren etwas komplizierter. Hinzu kommt, dass bestimmte Kombinationen von Feldern auch verbindlich vorschreiben können, ob ein weiteres existieren muss. Auch diese Regeln von SWIFT muss der Konverter beherrschen.
Block 3 stellt den User Header dar und enthält neben dem Nachrichtentyp bis zu fünf weitere Felder, die alle optional sind und mit einer geschweiften Klammer enden.
Was die Sache so schwer zu verarbeiten macht, sind die unterschiedlichen Feldlängen und die Zeichen, die sie enthalten dürfen.”
Robert Wappler ist Lead Developer bei Senacor (Webseite), entwickelt Zahlungsverkehrssysteme und begleitet eine führende deutsche Direktbank bei der ISO-20022-Migration. Davor arbeitete er an Backends für Fahrzeugtelemetriedaten sowie API-basierte Infotainment-Funktionen bei großen europäischen Automobilherstellern.Der vierte und letzte Block – tatsächlich sind es fünf, einen hängt SWIFT noch an, wenn die MT-Nachricht rausgeht – ist besonders kompliziert, weil er aus bis zu 24 Feldern besteht, von denen sechs verpflichtend und 18 optional sind. Drei dieser optionalen Felder dürfen jedoch mehrere Instanzen aufweisen, sind also möglicherweise verschachtelt. Zudem bestehen für einige Felder unterschiedliche Varianten. Feld 53 beispielsweise liegt in den Varianten A, B oder D vor, die jeweils ähnlich komplex aufgebaut sind wie der Basic Header aus dem ersten Block. Feld 59 erlaubt neben Angaben zum Begünstigten einer Zahlung zusätzlich auch einen optionalen Party-Identifyer, der bis zu 34 Zeichen lang sein darf. An diesem Feld zeigt sich auch, warum der Parser nicht Zeile für Zeile auslesen kann – bis zu drei sind hier erlaubt.
Christiane Neumüller ist Partnerin bei Senacor (Webseite) und verantwortet den Bereich Payments und Karten. Bis Juni 2020 war sie bei SIA als Country-Managerin zuständig für den deutschen Markt und hat zuvor unter anderem die Zahlungsverkehrssysteme der UniCredit-Gruppe in Deutschland betreut.MT auf MX mappen
Was die Bank nicht übersehen darf:
Es gibt mehr als ein Dutzend Regeln allein für MT103, die darüber bestimmen, was die Nachricht enthalten muss.”
Die Regel C1 schreibt etwa vor, dass Feld 36 vorhanden sein muss, wenn Feld 33B vorhanden ist und der enthaltene Currency Code von dem in Feld 32A abweicht. Anderenfalls darf Feld 36 nicht vorkommen. Teilweise schreiben einzelne Regeln auch vor, was in Sequenzen vorkommen darf und was nicht. Eine MT101 folgt beispielsweise mehreren Nebenbedingungen, wie etwa dieser: Falls das Feld 21R in Sequenz A existiert und Feld 28D darauf hinweist, dass mehr als eine Nachricht für diese Anfrage miteinander verkettet sind, muss der Currency Code derselbe sein in allen Feldern 32B der Sequenz B aller verketteten Nachrichten.
Solche Regeln sind häufig normalsprachlich formuliert, also für eine Maschine nicht ohne weiteres lesbar und überprüfbar. Die Bank muss dafür eigene Rules Engines entwickeln, die dem Konverter sagen, was wann zu tun ist. Überdies lassen sich solche Regeln nur schwer testen, weil die damit beschäftigten Personen sich Fälle ausdenken müssen, die genau jene zu testenden Regeln brechen, alle anderen jedoch einhalten. Erst dann, wenn der Parser, ob selbst entwickelt oder eingekauft, alle MT-Nachrichten sicher beherrscht, kann sich die Bank darum kümmern, die MT- auf MX-Nachrichten zu mappen.
Welcher Aufwand dahinter steckt, lässt bereits ein loser Blick auf die ISO 20022 Message Definitions erahnen. Der Katalog allein umfasst 721 verschiedene Nachrichten-Typen, vom Account Management (acmt) über das Terminal Management (catm) bis hin zur Payment Initiation (pain), die eine Zahlung einleitet. Worum es geht, ist also zunächst jede einzelne MT-Nachricht der passenden MX-Nachricht zuzuordnen. SWIFT hat eine Äquivalenztabelle für MT und MX veröffentlicht, die das erleichtern soll. MT101 (Request for Payment Transfer) entspricht demnach pain.001 nach ISO 20022. Der Konverter braucht scheinbar nur die richtigen MT-Felder den passenden XML-Einträgen in der MX-Nachricht zuordnen. Doch SWIFT selbst liefert ein Beispiel, das zeigt, wie dadurch Daten verlorengehen können.
Hier die Absenderinformation aus dem vierten Block einer MT101 im strukturierten Format (:50F) und im freien Format (:50K):
:50F:/BE3000121637141 1/JOHN HECTOR JOSEPH SMITH- 1/MASTERSONS 2/HOOGSTRAAT 6 3/BE/BRUSSELFS 1000
:50K:/BE3000121637141 JOHN HECTOR JOSEPH SMITH- MASTERSONS HOOGSTRAAT 6 BRUSSELFS 1000 BELGIUM ID:111111111111
Das freie Format enthält offenbar eine zusätzliche ID, die im strukturierten Format fehlt. Eine ISO-20022-konforme MX-Nachricht kann diese Information jedoch mitliefern. Bereits vor 15 Jahren enthielt die pain.001 mehr als 100 Einträge, die sich nicht immer eins zu eins den MT-Feldern zuordnen lassen. Dieses Problem verschärft sich noch, weil sich die ISO-Formate im Laufe der Zeit immer weiterentwickeln. Vollständig beschrieben heißt die pain.001, von der eben die Rede war, vielleicht pain.001.001.02 – sie gibt nicht nur den Geschäftsvorfall (pain = Payment Initiation) an, sondern auch, welche Funktionalität (001) sie beschreibt, in welcher Variante (001) sie vorliegt und welche Version (02) sie nutzt. Wenn eine neue Variante oder eine neue Version entsteht, muss die Bank ihren Konverter anpassen.
Erschwerend kommt hinzu, dass die MT-Nachricht nicht automatisch immer genau ein MX-Pendant hat. MT104 codiert beispielsweise sowohl Direct Debit als auch einen Request for Direct Debit. Falls die MT104 ein Direct Debit darstellt, also wirklich Geld fließen soll, dann bildet pacs.008 diesen Geschäftsvorfall ab, weil sofort das Clearing erfolgen kann. Handelt es sich dagegen um ein Request for Direct Debit, muss das Mapping auf pain.008 erfolgen. Auch hier gilt, dass die Bank aufpassen muss, wenn sich daran etwas ändert, auch was die einzelnen Felder selbst angeht. Stand heute sind die meisten MT-Feldlängen MX-kompatibel. Doch das muss nicht so bleiben. Wenn der neue Standard eines Tages alte Zöpfe abschneidet oder neue Felder verwendet, ist das eventuell nicht mehr abwärtskompatibel zum Bestandssystem.
Konverter als Brückentechnologie
Heute schon zeichnet sich ab, dass die Banken in eine Sackgasse laufen, weil mehr und mehr neue Zahl- und Verwahrarten entstehen, wie Wallets für Kryptowährungen. Mit dem digitalen Euro steht dafür sogar schon ein politisch forcierter Anwendungsfall bereit. Dafür will die EU eine eigenständige europäische Zahlungsverkehrsinfrastruktur schaffen.
Der Clou: Digital- und Giralgeld sollen sich gleichwertig nutzen lassen (Interoperabilität).”
Eine Bank, die noch mit Backend-Systemen arbeitet, die auf MT-Nachrichten basieren, steht spätestens dann nackt im Wind. In ISO 20022 lassen sich dafür neue Nachrichtentypen einführen – oder bestehende so erweitern, dass sie sich für diese Zwecke einsetzen lassen. Konverter eignen sich daher nur als Brückentechnologie, um das Kernbanksystem (CBS) abzulösen (vgl. Abb 2).
Senacor
Dieses Vorgehen zielt darauf ab, das existierende Backend inklusive CBS zu ersetzen und idealerweise eine zukunftssichere Cloud-Architektur aufzubauen. Synchronisierungen halten das bestehende System produktiv, während der Konverter die alten Clients umschwenkt auf die neue Architektur (MT zu MX). Nach und nach lassen sich dann die Clients umstellen und direkt an das neue Backend anschließen. Gleichzeitig sorgt der Konverter dafür, dass bereits auf ISO 20022 umgestellte Clients weiterhin mit dem bestehenden Backend kommunizieren können (MX zu MT). Während der Migration gilt:
Je eher das neue System führend wird, desto besser. Das alte dient nur noch als Fallback bis zur späteren Abschaltung.”
Ein weiterer Trend spricht dafür, die Bankplattform insgesamt umzubauen: Daten sammeln und auswerten. Durch ISO 20022 lassen sich die Zahlungsverkehrsdaten anreichern, etwa mit Informationen darüber, was jemand gerade eingekauft hat, die Flugnummer für den nächsten Urlaub oder welche Raumtemperatur sich eine Urlaubsfamilie im Hotel wünscht. Laufen die Zahlungen aber durch einen Konverter, werden diese Informationen abgeschnitten. Das gilt auch für aufsichtsrechtlich relevante Daten. Künftig dürften sich die beteiligten Banken über zusätzliche Datenfelder gegenseitig mitteilen, welche AML-Kriterien anschlagen oder ob eine der beteiligten Personen möglicherweise betrogen worden ist.
Darüber hinaus müssen die Banken Zahlungen immer schneller abwickeln. Inzwischen gilt innerhalb der EU eine Frist von 24 Stunden.
Wenn diese Fristen weiter sinken oder Instant Payments wirklich das neue Normal wird, entwickeln sich klapprige Konverter-Lösungen zu einem existenzbedrohenden Geschäftsrisiko.”
Dann bliebe dem Institut nichts anderes übrig, als den Zahlungsverkehr vollständig auszulagern und sich zu einer Registrierkasse für andere Anbieter machen zu lassen. Übrig bleibt nur das Online-Banking, das für viele Kunden immer mehr an Bedeutung einbüßt, weil sie angehende Super-Apps wie die von Paypal, Klarna oder Square nutzen.
In einer solchen Welt kriegen Banken ihre Kunden weder zu Gesicht, weil sie sowieso kaum mehr in eine Filiale gehen, noch erfahren sie, was ihre Kunden so treiben. Wenn es eine Bank so weit kommen lässt, ist sie überflüssig.”Christiane Neumüller und Robert Wappler, Senacor
Sie finden diesen Artikel im Internet auf der Website:
https://itfm.link/131781
Schreiben Sie einen Kommentar