Wie Sie die SWIFT MT/MX-Migration in SAP verwalten

Die SWIFT unterstützt nun den Austausch von ISO 20022 XML- oder MX-Nachrichten über das sogenannte FINplus-Netzwerk. Parallel dazu werden die alten Nachrichten im MT-Format weiterhin über das „reguläre“ FIN-Netz ausgetauscht. Der MT-Datenfluss für die Nachrichtenkategorien 1 (Kundenzahlungen), 2 (FI-Überweisungen) und 9 (Kontoauszüge) über das FIN-Netz wird per November 2025 stillgelegt.

Aus diesem Grund müssen Finanzinstitute zwischen März 2023 und November 2025 in der Lage sein, MX-Nachrichten über FINplus zu empfangen und zu verarbeiten sowie wahlweise MX-Nachrichten oder MT-Nachrichten für ausgehende Nachrichten zu senden. Nach diesem Zeitraum werden nur noch MX-Nachrichten zugelassen.

CBPR+ and HVPS+ 

Ein weiterer wichtiger Aspekt der MX-Migration ist die Entwicklung der CBPR+- und HVPS+- Spezifikationen innerhalb des ISO20022-XML-Standards. Diese Spezifikationen schreiben vor, wie eine XML-Nachricht in Bezug auf die Daten- und Feldanforderungen für grenzüberschreitende
Zahlungen (CBPR+) und inländische Großbetragszahlungen (HVPS+) auszusehen hat. Beachten Sie, dass sich HVPS+ auf inländische RTGS-Clearingsysteme bezieht und eine Reihe von Ländern aktuell dabei ist, die inländischen Clearingsysteme nativ ISO20022-XML-konform zu gestalten.

Auswirkungen auf Unternehmen

Zum jetzigen Zeitpunkt dürfte für Unternehmen kein unmittelbarer Änderungsbedarf bestehen. Es ist jedoch ratsam, die Auswirkungen zu bewerten und im Bedarfsfall mit der Planung von Änderungen zu beginnen. Wir schildern einige Beispielfälle, die Sie berücksichtigen sollten:

1. Ein Unternehmen tauscht derzeit beispielsweise MT101/MT103/MT210-Nachrichten über das SWIFT FIN Network mit seiner Hausbank aus, um grenzüberschreitende Zahlungen vorzunehmen, etwa über ein SWIFT Service Bureau oder eine Alliance-Verbindung. Dieser Ablauf wird ab November 2025 nicht mehr funktionieren. Wenn er für Ihr Unternehmen relevant ist, muss er ersetzt werden.
2. Ein anderer Fall ist, dass z.B. ein MT101 mit einer Hausbank als Datei über das FileAct- Netzwerk ausgetauscht wird. Nun hängt es rein von den Möglichkeiten der Hausbank ab, dies auch nach 2025 zu unterstützen; sie könnte einen Dienst anbieten, der ein Remapping Ihrer MT-Nachricht in eine MX-Nachricht vornimmt. Dies muss mit den Hausbanken abgeklärt werden.
3. Der MT940-Nachrichtenfluss von der Hausbank über FIN muss ebenfalls ersetzt werden.
4. Hinsichtlich des MT940-Dateiverkehrs von der Hausbank über FileAct erwarten wir nur geringe Auswirkungen. Wir gehen davon aus, dass die meisten Banken weiterhin das MT940- Format für den Austausch von Dateien unterstützen werden. Wir empfehlen jedoch, bei Ihrer Hausbank nachzufragen, um sicherzugehen.
5. Großbetragszahlungen in japanischen Yen im Zengin-Format – Das RTGS-Clearingsystem BOJ-NET hat die Umstellung auf den ISO20022-XML-Standard bereits abgeschlossen. Erkundigen Sie sich bei Ihrer Hausbank, ab wann das alte Zahlungsformat nicht mehr unterstützt wird, und ergreifen Sie entsprechende Maßnahmen.

Dies waren nur einige Beispiele, die nicht als vollständige Liste betrachtet werden sollten.

Darüber hinaus kann die Umstellung auf den ISO20022-XML-Standard auch einige Vorteile bringen. Wir haben dies in einem bereits veröffentlichten Artikel erörtert.

Auswirkungen auf Ihre SAP-Implementierung

Sie haben also festgestellt, dass die MT/MX-Migration Auswirkungen hat und dass Sie Maßnahmen ergreifen müssen. Wie sieht das in SAP aus?

Zunächst einmal ist es wichtig, dass Ihre Bank Sie bei Ihrer Umstellung unterstützt. In der Regel muss die Bank ihre Systeme so vorbereiten, dass sie ein neues Zahlungsdateiformat von Ihrer Seite empfangen kann. Es hat sich bewährt, die Formatierung der Zahlungsdateien zunächst zu testen und vom Implementierungsmanager der Bank ein Feedback zu erhalten, bevor Sie diese in Betrieb nehmen.

Auf der Eingangsseite ist es ratsam, zunächst eine Reihe von produktiven Kontoauszügen, z.B. im neuen Format CAMT.053, anzufordern, die in Ihrem Testsystem analysiert und geladen werden können. Dies bildet eine gute Grundlage für das Verständnis der erforderlichen Änderungen in der Buchungslogik für Kontoauszüge im SAP-System.

ZAHLUNGEN 

Im Allgemeinen gibt es zwei Möglichkeiten, Zahlungsdateien in SAP zu erzeugen. Der klassische Weg führt über einen Zahlweg, der mit einem Format der Payment Medium Workbench (PMW) und einem Datenträgeraustauschbaum (DTA) verknüpft ist. Dieser Zahlweg wird dann mit Ihren offenen Posten verknüpft, die mit dem Zahlungslauf bearbeitet werden können. Der Zahllauf gibt dann die Dateien aus, die in Ihrem DTA-Baum festgelegt sind.

In diesem Szenario geht es darum, einfach einen neuen Zahlweg einzurichten und ihn mit einer gewünschten PMW/DME-Nachricht wie pain.001.001.03 zu verknüpfen. Diese werden seit Langem im SAP-Standard ausgeliefert, sowohl in ECC als auch in S/4. Um länder- oder bankenspezifische Datenanforderungen zu erfüllen, kann es nötig sein, kleinere Mapping-Korrekturen vorzunehmen. In den meisten Fällen kann dies mit einem Funktions-Consultant unter Verwendung der DTA-Konfiguration erreicht werden. Sobald der Zahlweg vollständig konfiguriert ist, kann er z.B. mit Ihren Kunden- und Lieferantenstammsätzen oder Ihren Treasury-Geschäftspartnern verknüpft werden.

Die neue Methode zur Erstellung von Zahlungsdateien erfolgt über das Modul Advanced Payment Management (SAP APM). SAP APM ist ein Modul, das das Konzept der Zentralisierung von Zahlungen für Ihre gesamte Gruppe in einer so genannten Payment Factory ermöglicht. APM ist ein Modul, das nur in S/4 verfügbar ist und von der SAP AG als neuer Weg zur Implementierung von Payment Factories vorangetrieben wird.

An dieser Stelle geht es darum, das neue Ausgabeformat mit dem jeweiligen Szenario oder „Zahlungsweg“ zu verknüpfen.

KONTOAUSZÜGE

Klassische MT940-Bankauszüge werden von SAP mit ABAP-Logik gelesen. Der Code interpretiert die in der Datei gespeicherten Informationen und speichert Teile davon in internen Datenbanktabellen. Die gespeicherten internen Daten werden dann ein zweites Mal interpretiert, damit bestimmt wird, wie die Buchung und der Ausgleich offener Posten erfolgen sollen.

Die Verarbeitung von CAMT.053 funktioniert ein wenig anders, indem die Daten aus der Datei durch eine sogenannte XSLT-Transformation interpretiert werden. Diese XSLT-Transformation ist ein konfigurierbares Mapping, bei dem ein CAMT.053-Feld auf ein internes Datenbanktabellenfeld abgebildet wird. SAP verfügt über ein Standard-XSLT-Transformationspaket, das für die meisten Anwendungsfälle recht gut geeignet ist. Allerdings können bestimmte nützliche Informationen in der CAMT.053 von SAP ignoriert werden. Eine Anpassung der XSLT-Transformation kann hinzugefügt werden, um sicherzustellen, dass die Daten aufgegriffen und für die weitere Interpretation durch das System verfügbar gemacht werden.

Eine weitere Tatsache, die zu beachten ist, ist der Unterschied in den Bank Transaction Codes (BTC) zwischen MT940 und CAMT.053. Es könnte eine unterschiedliche Granularität geben, zudem ist die Namenskonvention unterschiedlich. Die BTC-Codes sind das auptunterscheidungsmerkmal in SAP zur Steuerung der Buchungslogik.

SAP Incoming File Mapping Engine (IFME)

SAP hat weiterhin ein Modul namens Incoming File Mapping Engine (IFME) entwickelt. Es dient als "Remapper" eines Ausgabeformats in ein anderes Ausgabeformat. Wenn Ihre derzeitige Zahlungsmethode beispielsweise einen MT101 ausgibt, kann der Remapper die Informationen aus
dem MT101 übernehmen und sie in einer XML-Datei pain.001 speichern.

Obwohl es einige Randszenarien für diese Lösung geben mag, empfehlen wir einen solchen Ansatz nicht, da MT101 im Allgemeinen in Bezug auf die Datenstruktur und den Inhalt schwächer ist als XML. Ein Mapping in ein anderes Format wird die Probleme, die MT101 im Allgemeinen hat, nicht lösen. Besser ist es, das entsprechende Format direkt aus den internen SAP-Daten zu generieren, um ein Maximum an Reichhaltigkeit und Struktur zu gewährleisten. Dies sollte jedoch nur als letzter Ausweg in Betracht gezogen werden oder wenn die Lösung nur vorübergehend ist.