ISO 20022 im Auslandszahlungsverkehr: Zeit für die Umstellung!

Nahezu alle großen Zahlungsverkehrssysteme sind im Begriff, standardisierte, XML-basierte Datenformate einzuführen. Sie machen sowohl den Auslands- als auch den Individualzahlungsverkehr deutlich schneller und weniger fehleranfällig. Aber die Umstellung ist kein Selbstläufer und viel Zeit bleibt nicht mehr. Was ist zu beachten?

Kartenzahlungen im Urlaub oder Auslandsüberweisungen gelten für uns im Alltag als Selbstverständlichkeit. Hinter allen elektronischen Transaktionen stehen jedoch teils hochkomplexe Prozesse, denn für einen schnellen und reibungslosen Geldtransfer müssen sämtliche involvierten IT-Systeme mit den generierten Daten gleich gut umgehen können. Dazu braucht es Standards wie ISO 20022, der in den kommenden Jahren das Maß der Dinge im Auslands- und Individualzahlungsverkehr sein wird.

Bewährter Standard für die Zukunft

Immer mehr Zahlungsverkehrsräume stellen auf den ISO-Standard um, denn die Vorteile sind immens: Er ist zukunftssicher, erlaubt eine deutlich schnellere Verarbeitung von Zahlungsdaten und macht erhebliche Effizienzsteigerungen möglich. Konvertierungen von einem Datenformat ins andere entfallen. Immer mehr Datensätze lassen sich ohne Interaktionen und Medienbrüche im Sinne eines Straight Through Processings (STP) durchgehend verarbeiten.

Aufwand nicht unterschätzen

Das gibt es aber nicht umsonst – die Umstellung auf ISO 20022 bindet zeitliche und personelle Ressourcen. Aktuell unterschätzen viele Banken den Aufwand. Denn sie müssen nicht nur eventuell vorhandene manuelle Prozesse automatisieren, sondern auch die eigene Software ISO-fit machen. Handelt es sich dabei wie so häufig um gewachsene Legacy-Systeme, wird die Aufbereitung für die Verarbeitung von XML-Datenpaketen ziemlich anspruchsvoll. Und das auch noch unter Zeitdruck: Der Go-live für die Umstellung von TARGET2 auf den XML-Standard ist der 21. November 2021. Für SWIFT beginnt zum gleichen Termin eine vierjährige Koexistenzphase.

Trügerische Sicherheit

Immerhin, europäische Bankhäuser arbeiten bereits mit ISO-basierten Standards, denn SEPA setzt darauf auf. Aber damit ist noch niemand auf der sicheren Seite. Je nach Art der Umsetzung sind am Ende Arbeiten in allen wichtigen Bereichen der Zahlungsverkehrs-IT notwendig, von Stammdaten über E-Banking bis zu Backend-Systemen. Ganz zu schweigen von Auswirkungen auf die zukünftige Architektur des Kernbanksystems.

ISO ist nicht gleich ISO

Wir sollten auch nicht vergessen, dass es sich hier um einen generischen Standard handelt, der nur die Grundlagen für Zahlungsverkehrsnachrichten festlegt. Bei jeder einzelnen Umsetzung wird er zweckmäßig angepasst, kann also bei TARGET2, SWIFT und SEPA durchaus unterschiedlich ausfallen. Von der Beschränkung der zulässigen ISO-Codes, einer Begrenzung von Datentypen, bis hin zum Entfernen nicht benötigter optionaler Elemente der Basisnachricht sind verschiedenste Varianten denkbar. Das macht eine One-Size-fits-all-Lösung für die Migration unrealistisch.

Viele Einzelprojekte

Demzufolge ist es eigentlich falsch, von der ISO-20022-Umstellung zu sprechen – in Wahrheit sind es viele unterschiedliche Projekte. Umso wichtiger ist die frühzeitige Einbindung der IT-Abteilung zur Unterstützung der Fachseite für rechtzeitige Hinweise auf Fallstricke und Probleme sowie nicht zuletzt, um eine frühzeitige Kostenschätzung zu bekommen. Denn die Umstrukturierung des Auslands- beziehungsweise Individualzahlungsverkehrs von TARGET2 auf den XML-Standard dürfte einen sieben- bis achtstelligen Betrag kosten. Die Summe schließt die Vorstudie, die Einführung und die IT-Anpassungen selbst ein. Zusätzlich zu budgetieren sind die Schulungen der involvierten Mitarbeiter und der rechtzeitige Aufbau des notwendigen Know-hows, alternativ die Einbindung externer Partner.

Wie geht es weiter?

Sofern sie noch nicht vorliegt, brauchen Finanzinstitute möglichst schnell eine Roadmap – mit allen im Zuge der Umstellung auf den ISO-Standard notwendigen Arbeiten und Meilensteinen. Basis dafür ist eine ehrliche Bestandsaufnahme des eigenen Ist-Zustandes, darum wird niemand herumkommen. Im Zuge derer darf auch durchaus die Frage gestellt werden, ob die Bereitstellung von Leistungen im Auslandszahlungsverkehr im eigenen Haus zukünftig überhaupt noch ökonomisch Sinn macht oder ob stattdessen die verstärkte Zusammenarbeit mit externen Dienstleistern die bessere Lösung ist.

Wandel als Chance begreifen

Die Umstellung auf ISO 20022 setzt die Finanzdienstleister unbestritten unter Zugzwang, erst recht, wenn wir die nahezu zeitgleiche Konsolidierung von TARGET2 und TARGET2-Securities bedenken. Aber: Die regulatorischen Neuerungen sind auch eine Gelegenheit, um die eigenen Systeme kritisch zu prüfen und auszuloten, wie agil und flexibel sie sich modellieren lassen. Das hilft am Ende auch dabei, die digitale Transformation auf ganzer Linie voranzutreiben – denn Stehenbleiben ist in der digitalen Welt von heute keine Option.

Gastautoren: Sabine Aigner, Raija Wehrli

EBICS 3.0 – ein Satz an Parametern anstelle der Auftragsart. Was ist bei der Identifikation der Geschäftsvorfälle zu berücksichtigen?

Mit EBICS 3.0 werden die unterschiedlichen Geschäftsvorfälle bekanntlich nicht mehr über Auftragsarten abgebildet, sondern über die neuen BTF-Parameter.
Für die Nutzung von Kundenverträgen mit EBICS-Clients verschiedener EBICS-Versionen in Kombination mit EBICS 3.0 wurden von den nationalen Spezifikationsgremien eigens Mappingregeln entwickelt. Diese orientieren sich i. d. R. an den fünf BTF-Parametern Service Name, Service Scope, Service Option, Service Message Name und Service Container. Wichtig ist, dass die Kombination dieser BTF-Parameter im EBICS-Bankrechner eindeutig sein muss. Dadurch wird sichergestellt, dass eine Auftragsart dem Geschäftsvorfall über BTF zugeordnet werden kann und umgekehrt.

In der Praxis können heute zu einer Auftragsart fachlich identische Aufträge eines bestimmten Formats in verschiedenen Formatversionen erstellt und beim Bankrechner eingereicht werden. Auch wenn es regelmäßig über die Spezifikationsgremien zu Formatanpassungen kommt, hängt die vom Clientsystem genutzte Formatversion auch vom Softwarestand der Clientlösung ab. Da die Formatversion für den Anwender in den Clients transparent sein dürfte, hat er bei der Zusammenstellung seiner Auftragsdatei keinen Einfluss auf die Einreichung in einer bestimmten Formatversion. Zudem akzeptieren Banken heutzutage i. d. R. unterschiedliche Formatversionen eines Geschäftsvorfalls. Letztendlich kann für die bankseitige Verarbeitung die jeweilige Formatversion zumindest bei XML-Formaten auch aus dem Namespace der XML-Datei ausgelesen werden. Bankrechner sind bisher flexibel für verschiedene Formatversionen ausgelegt.

Die weiteren nutzbaren BTF-Parameter in EBICS 3.0 sind Service Message Name Format, Service Message Name Variant und Service Message Name Version. Sollte ein Finanzinstitut auch diese weiteren Parameter in die Auftragsartmappings und Vereinbarungsdetails mit dem Kunden aufnehmen, so sollte einiges beachtet werden. Falls nicht bereits bisher über FileFormat-Parameter intensiver genutzt oder aus verarbeitungstechnischen Gründen notwendig, sollten diese weiteren Parameter bankseitig bei EBICS-Prüfungen eher dosiert berücksichtigt werden.

Letztendlich sind diese zusätzlichen Parameterinformationen bereits Inhalt der Auftragsdatei selbst und ohnehin daraus auslesbar. Was ist zu tun bei sich widersprechenden Angaben? Außerdem bedeutet die zusätzliche Pflege im Bankrechner mehr Aufwand bei der Stammdatenpflege. Es müsste ja für jede Formatversion eines Geschäftsvorfalls eine eigene Kundenvereinbarung geben. Erschwerend kommt hinzu, dass diese Formatdetails für den Kunden in der Clientsoftware transparent sind und er diese z. T. nicht steuern kann.

Was würde passieren, wenn z. B. der Bankrechner bei einer Einreichung die Versionen 03 und 04 eines XML-Formats unterstützt, der Kunde aber für die Einreichung eines Formats der Version 03 stattdessen die Version 04 in den BTF einstellt? Bei der Versionsberücksichtigung würde der Auftrag abgelehnt, obwohl das Banksystem die Formatversion verarbeiten könnte. Die tatsächliche Version ist ja am Namespace erkennbar.

Noch komplizierter wird es mit den Auslieferungen. Hier müsste die Auslieferung zum Abholzeitpunkt synchron in der angefragten Version erzeugt und als Datei ausgegeben werden. Gleiches gilt dann auch für historische Abholungen.

Fazit: Man sollte als Finanzinstitut nicht zu restriktiv sein bei den Definitionen der BTF-Vereinbarungen mit dem Kunden. So ist man als Finanzinstitut flexibler und spart sich Mehraufwand in der Vertrags- und Stammdatenpflege.


Autor: Michael Lembcke