SWIFT ISO 20022: Lösungen zur „Coexistence Phase“
Die Zeit drängt: ISO 20022 wird zum De-Facto-Standard des internationalen Zahlungsverkehrs. In seiner Migration Consultant Study zu ISO 20022 vom April 2018 stellt SWIFT unmissverständlich dar, dass ab Ende 2021 Cross-Border und High Value Payments auf ISO 20022 (MX) migriert werden:
„The major switch to ISO 20022 will begin at the end of 2021.” *
(* Am 12. März 2020 hat SWIFT seinen Mitgliedern mitgeteilt, dass die Einführung des neuen Formats um ein Jahr auf Ende 2022 verschoben wird. In der Rubrik "News und Infos" finden Sie weitere Details zu dieser Entscheidung. Lesen Sie dazu auch unsere aktuelle Situationsanalyse.)
Für eine Koexistenzphase von 4 Jahren können MT- und MX-Nachrichten weiter über SWIFT abgewickelt werden. Jedoch muss der SWIFT-Teilnehmer ISO 20022 Nachrichten annehmen und verarbeiten können. Korrespondenzbanken können aus Compliance Gründen auch gehalten sein, eingehende ISO 20022-Nachrichten im gleichen Format weiterzugeben.
Der vorliegende Beitrag beschäftigt sich mit der Frage, inwieweit ISO 20022 während der Koexistenzphase und darüber hinaus so in den Backoffice-Systemen der Institute umgesetzt werden kann, dass diese die Vorteile des neuen Standards nutzen und gleichwohl Aufwände und Projektrisiken unter Kontrolle halten und Sunk Costs vermeiden können. Der Fokus liegt dabei auf größeren Instituten mit komplexen, historisch gewachsenen Systemlandschaften, deren Zahlungsverkehr nicht durch einfache Standard-Applikationen abgebildet werden kann.
Chancen
Institute, die am Zahlungsverkehr über die etablierten Clearingsysteme und SWIFT teilnehmen wollen, haben keine andere Wahl, als sich auf ISO 20022 als neuen Standard einzustellen. Vielfach wird das Thema daher wie ein quasi-regulatorisches Projekt behandelt, welches in „Mindestsprunghöhe“ umzusetzen ist.
Diese Herangehensweise ist in Zeiten eines nie gekannten Margen- und Kostendrucks in der Finanzindustrie nachvollziehbar, lässt aber die Bedeutung von ISO 20022 für die digitale Strategie der Institute außer Betracht. Der auf XML-Strukturen basierende ISO 20022-Standard erlaubt einen sehr viel breiteren und differenzierteren Austausch von Informationen zwischen den Stakeholdern des Zahlungsverkehrs als die bisherigen SWIFT-FIN-Message Types. Diese neue strukturierte Granularität der Zahlungsverkehrs-Daten erweitert die Möglichkeiten automatisierter Verarbeitungen erheblich. Zu den erwarteten Verbesserungen zählen:
- Höhere STP-Raten im Processing
- Verbesserte Effizienz und Qualität der Compliance-Prüfungen, insbesonderein Bezug auf KYC, Sanction / PEP und Anti-Fraud
- Erweiterte Kundenservices genauere Datenanalysen und neue, datengetriebene Geschäftsmodelle und Cross-Selling-Strategien.
- Genuine Integration in SWIFT GPI
Herausforderungen
Moderne Standards in Legacy-Umgebungen
Aus Sicht des Business sprechen also durchaus gute Gründe dafür, die Verarbeitung des Cross-Border-Zahlungsverkehrs möglichst rasch End-to-End auf ISO 20022 umzustellen.
Dem steht allerdings die Komplexität der vorhandenen Zahlungsverkehrs-Applikationslandschaft und ihrer Umsysteme (Kunde und Konto, Compliance, Anti-Fraud, Rechnungswesen, Meldewesen…) entgegen. Diese sind in vielen großen Instituten geprägt von monolithischen, häufig Mainframe-basierten Legacy-Anwendungen. Eine vollständige Umstellung aller beteiligten Legacy-Applikationen auf eine MX-basierte Verarbeitung ist ein aufwändiges und komplexes Vorhaben. Dabei dürfte sich vielfach die Frage stellen, inwieweit hohe Investitionen in Legacy-Infrastrukturen, die auf veralteten Technologien wie COBOL basieren, überhaupt sinnvoll sind.
In diesem Dilemma setzen viele Institute darauf, MT-basierte Legacy-Applikationen weitgehend unverändert zu lassen. MX-Nachrichten werden durch vorgeschaltete Applikationen in MTs konvertiert und so für die vorhandenen Legacy-Applikationen verarbeitbar.
Eine solche MX-MT-Konvertierung begegnet allerdings der Herausforderung, dass die prozessuale Logik der Nachrichtentypen in der MT-Welt eine andere ist als unter ISO 20022 und dass selbst dort, wo ein MX-Nachrichtentyp einem korrespondierenden MT gegenübersteht, die Struktur der Datenfelder keine bijektive Abbildung von MX auf MT erlaubt.
Keine bijektive Abbildung von MX auf MT
„If an ISO 20022 instruction is converted to MT for x-border leg, there is the risk of data being dropped or truncated.” *
Dieser Satz beschreibt das eigentliche Kernproblem des Übergangs von ISO 15022 auf ISO 20022. Der Informationsgehalt der eingehenden MX-Nachricht ist im Zweifel nicht abbildbar auf das korrespondierende MT-Format.
Eingehende ISO 20022 (MX)-Transaktionen können nicht über ein mehr oder minder statisches Mappingverfahren in intern zu vereinbarende MT-Formate überführt werden. Der wesentliche Grund hierfür ist, dass ISO 20022 Nachrichten sehr granular strukturiert werden können, während das alte MT-Format statische Feldattribute erzwingt. Dies führt im Zweifel zu nicht konsistent bzw. korrekt abgebildeten Nachrichteninhalten. Die Implikation für die Compliance und die Abwicklungssicherheit sind evident.
* SWIFT ISO 20022 Migration Consultation Study S. 8
Nachrichtentypen im Ein- und Ausgang
Erschwerend kommt hinzu, dass Institute in Korrespondenzbeziehungen und in der Kommunikation mit den Clearingsystemen unter Umständen gezwungen sein können, eine im ISO 20022-Format erhaltene Nachricht auch als solche weiterzugeben. Bei einer zwischenzeitlichen Konvertierung in MT, die notwendig ist, damit die Nachricht in der Legacy-Infrastruktur verarbeitet werden kann, gehen Informationen verloren, die für die Erzeugung der ausgehenden MX-Nachricht wieder benötigt werden.
Will man für eine Übergangszeit die fachliche Verarbeitung von Cross-Border-Payments auf MT-Basis fortführen, muss eine vorgeschaltete Applikation die prozessuale Logik der ISO 20022-Welt abbilden.
Für alle Transaktionen, die nicht in einer geschlossenen Benutzergruppe abgewickelt werden, sondern in die SWIFT Community zeigen, gilt es nun eine Strategie der Interoperabilität zu entwickeln.
Translator- und Conversion-Ansätze
SWIFT selbst offeriert über eine Central Translation Platform eine Übersetzung von ISO 20022 in MT-Formate und vice versa. Die Plattform ist als Cloud Service und On-Premise-Lösung verfügbar. Interessanterweise wird dieser Vorschlag nicht als „Committment“ beschrieben. Der bei einer Konversion mittels SWIFT Translator drohende Datenverlust oder eine Verfälschung wird als Problem beschrieben, ohne jedoch für die Backoffice-Strukturen der Institute eine Lösung anzubieten. Insbesondere auch die Rekonversion aus einer MT-Domäne in eine ISO 20022- Nachricht bleibt offen.
Der SWIFT-Translator-Ansatz sieht daher weiterhin vor, die eingehende ISO 20022 MX-Nachricht zum einen – soweit konsistent darstellbar – zu übersetzen, zum anderen aber die original ISO 20022 MX-Nachricht zu erhalten und diese für weitere Backoffice Verarbeitungen und insbesondere die regulatorisch geforderten Compliance-Prüfungen bereitzuhalten. Die Integration der beiden nicht zwingend konsistenten Nachrichtentypen in die meist komplexen Verarbeitungsprozesse muss daher gleichwohl in den Backoffice-Systemen erfolgen. SWIFT selbst weist darauf hin, dass für eine Nutzung der Vorteile von ISO 20022 eine grundlegende Anpassung des Datenmodells, der Systeme und der Prozesse der beteiligten Institute erforderlich ist.
Grundlagen zur Lösungsarchitektur
Betrachtet man die bei Cross-Border Geschäftsprozessen relevanten Message Types MT1xx, MT2xx in Verbindung mit ISO 20022, ist deren Abbildung in das jeweilige andere Format ohne Datenverslust bzw. Datenverfälschung im Zweifel nicht darstellbar. Die Abbildung eines pacs.008 in ein z.B. MT103 ist nicht konsistent gewährleistet.
Deshalb muss diese eingehende pacs.008 in einem ersten Schritt in einer Realtime-Umgebung gespeichert werden. Nur so kann eine spätere auf Korrektheit und Compliance ausgerichtete Abwicklung und Prüfung der Transkation sichergestellt werden. Danach folgt ein standardisiertes Mapping, welches die Informationen der MX-Nachrichten bestmöglich in die MT-Struktur übersetzt.
Zur Sicherstellung von Compliance Anforderungen (z.B. Embargo, AML, etc.) und zur Vermeidung eines Informationsverlustes insbesondere bei der Weiterleitung von Nachrichten in Korrespondenzbeziehungen können die erweiterten ISO 20022 Informationen über eine Datenbank bereitgestellt werden. Die gewählte Syntax und Semantik der ISO 20022-Nachrichten ist flexibel und gleichzeitig Use Case- bezogen interpretierbar.
Das zu Grunde liegende Datenmodell sollte sich dabei an den typischen Anforderungen des Payment Processing orientieren. So sind alle fachlichen Informationen im ISO 20022- und im MT-Format verfügbar und können von allen in den End-to-end-Prozess heute und zukünftig eingebundenen Applikationen flexibel genutzt werden.
DPS verfolgt diesen Ansatz in einer eigenen Produktlinie mit dem Ziel, Zahlungsverkehrsprozesse in heterogenen Applikationslandschaften zu orchestrieren und so über die SWIFT-Koexistenzphase hinaus eine kontrollierte Transformation der Altsysteme in das ISO 20022-Zeitalter zu ermöglichen.
DPS Services
DPS bietet umfassende Consulting- und Projektleistungen in Bezug auf alle relevanten fachlichen und technischen Aspekte des Zahlungsverkehrs an. Aufgrund der langjährigen Erfahrung in der Abwicklung hoch-skalierter Payment Projekte, verfügen die Spezialistinnen und Spezialisten der DPS Engineering über ausgeprägte Erfahrung in der
- Modellierung
- Entwicklung
- Integration und
- Test
von Payment Transaktionen.
Der Erfahrungsschatz reicht von der Herstellung einer vollständigen SEPA-Plattform für einen großen Third Party Payment Provider bis hin zur Entwicklung des kompletten Auslandszahlungsverkehrs für die deutsche Sparkassenorganisation.
Ergänzend bietet DPS auf Wunsch Application Management Services an, um die produktionssichere und effiziente Betreuung betroffener Applikationen während der Koexistenz-Phase der ISO 20022 Migration und darüber hinaus zu gewährleisten.
HANDLUNGSOPTION 1:
VOLLSTÄNDIGE UMSTELLUNG DER VERARBEITUNG AUF ISO 20022
+ Umfassende Nutzung des erweiterten Informations- und Funktionsuniversums (einschließlich SWIFT GPI)
+ Nachhaltige Lösung über die Koexistenzphase hinaus
- Hohe Anpassungsaufwände in allen relevanten Payment-Applikationen und vielen Umsystemen, die in sehr kurzer Frist bewältigt werden müssen.
- Risiko von Sunk Costs durch Investitionen in technologisch veraltete Legacy-Applikationen
HANDLUNGSOPTION 2:
KONVERSION VON MX AUF MT UND VICE VERSA
+ Geringerer Anpassungsaufwand in den Payment-Applikationen und Umsystemen
+ Geringere Projektrisiken bis zum Beginn der Koexistenzphase
+ Vermeidung von Sunk Costs
- Keine signifikante Nutzung der Chancen von ISO 20022
- Risiko von Qualitätsverschlechterungen durch Informationsverlust im Abwicklungsprozess