Posts mit dem Label SWIFT GPI werden angezeigt. Alle Posts anzeigen
Posts mit dem Label SWIFT GPI werden angezeigt. Alle Posts anzeigen

SWIFT gpi - von der Pflicht zur Kür

Zum November 2020 verlangt das SWIFT-Release für den Zahlungsverkehr ausnahmsweise mal keine Formatänderungen. Die wurden wegen COVID-19 auf nächstes Jahr verschoben. Aber die Forderung nach der sogenannten „Universal Confirmation“ im Rahmen von SWIFT gpi ist geblieben. Vereinfacht bedeutet das: Alle FIN-Teilnehmer müssen die Gutschrift im MT103-Format auf dem Konto des Begünstigten an SWIFT zurückmelden, und zwar an den Tracker. Auch Ablehnungen müssen so gemeldet werden, die eigentliche Rückgabe entfällt dadurch aber nicht. Also muss der Zahlungsverkehr wieder ein (regulatorisches) MUSS-Projekt stemmen, was weniger Ressourcen für Kundenprojekte bedeutet. Aber muss das so sein? Um diese Frage zu beantworten, wollen wir uns erst einmal ansehen, was SWIFT gpi bedeutet.

Seit 2016 nimmt das Thema SWIFT gpi (global payment innovation) immer breiteren Raum ein. Kern ist eine eineindeutige Referenz, die UETR (unique end-to-end-reference), die der Zahlung am Anfang der Korrespondenzbankkette mitgegeben wird und über alle Stationen beibehalten wird. Damit ist ein Track & Trace“ von Zahlungen möglich, was schon lange im AZV (Auslandszahlungsverkehr) gefordert worden war. Die Informationen werden im Tracker gesammelt. Der Tracker ist eine zentrale Datenbank in der FIN-Wolke bei SWIFT, die die nötigen Informationen bei jeder Zahlung in FIN automatisch mitliest und durch weitere Meldungen der gpi-Banken vervollständigt wird.

Am Anfang gab es die UETR nur innerhalb der CUG (closed user group) der an der Initiative gpi teilnehmenden Banken, und das auch nur für Kundenzahlungen (MT103), der Standard-Service wird auch gCCT (gpi for Corporate Credit Transfer) genannt, der dann bald von gCOV ( gpi for Cover Payments) vervollständigt wurde. Seit 2018 sind alle FIN-Banken verpflichtet, die UETR nach den Kundenzahlungen (MT103) nun auch für Bank-Bank-Zahlungen (MT202/205) – also für alle Zahlungen – zu unterstützen. Erste positive Auswirkungen können vermeldet werden. Mit der UETR ist es nun möglich, Aussagen zu treffen wie z. B. „40 % aller gpi-Zahlungen sind innerhalb von 5 Minuten final“ oder „75 % aller gpi-Zahlungen sind innerhalb von 6 Stunden final“. Vorher gab es nur Beispiele für Zahlungen, die sehr spät (oder gar nicht) oder ohne Verwendungszweck, dafür mit hohen Gebührenabzügen (auch bei OUR) ankamen, was zu vielen Reklamationen mit entsprechenden Nachfragen führte. Eine etwas unerwartete Auswirkung der gpi-Einführung war der drastische Rückgang von Nachforschungsanfragen.

Eine gpi-Bank verpflichtet sich zur möglichst taggleichen Verarbeitung, zum Verzicht auf Gebührenabzug bei OUR, zur ungekürzten und unveränderten Weitergabe des Verwendungszwecks (analog wie bei SEPA) – eigentlich lauter Selbstverständlichkeiten – und natürlich zum (möglichst zeitnahen) Informationsaustausch nicht nur zum Status sondern auch über Gebühren und Kurse mit dem Tracker. Diese Informationen stehen dann der Zahlerbank als gpi-Bank zur Verfügung. Dadurch kann ein weiteres Manko des AZV – die fehlende Gebührentransparenz – abgebaut werden. Diese Vorteile und insbesondere diese Informationen können dann dem Zahler übermittelt werden.

Und dann noch das Thema Rückrufe. Wenn es mal Not tut, dann sollte eine Zahlung entlang der ausführenden Bankenkette auch noch zu stoppen sein. Aber so wie die Zahlung über die Kette schrittweise abgearbeitet wird, so wird auch die Rückrufnachricht je beteiligter Bank abgearbeitet. Hier setzt der gpi-Zusatzservice gSRP (gpi Stop and Recall Payments) an. Der Rückruf wird an den Tracker gemeldet und der nächste Versuch, eine Zahlung mit der betreffenden UETR an FIN zu geben, wird abgelehnt. Die lange Kette wird übersprungen.

Mit der „Universal Confirmation“ wird nun die Transparenz vervollständigt. Damit bekommt die Zahlerbank nicht nur die Info „Zahlung bei der letzten Bank in der FIN-Kette angekommen“, sondern den Status „Zahlung beim Empfänger angekommen“. So eine Quittung war bei der Definition von SEPA Instant Payments von Anfang an integraler Bestandteil, aber das war ja auch fast 50 Jahre nach den ersten SWIFT-Nachrichten.

Die FIN-Banken werden nun zur Meldung „Universal Confirmation“ verpflichtet. Das gilt nur für Kundenzahlungen (MT103), nicht für alle Zahlungseingänge (M202/205). Meldungen müssen auch für TARGET2-Eingänge abgegeben werden, denn die werden ja über FINCopy transportiert. Als „Goodie“ gibt es den (manuellen) Webzugriff auf diesen Tracker, der bisher überhaupt nur gpi-Banken zur Verfügung stand.

Für die Meldung zur „Universal Confirmation“ hat die Bank bis zu 2 Werktage Zeit (eigene Feiertage sind also ausgenommen). Dieses SLA wird auch gemessen und das Wohlverhalten anderen Banken angezeigt, was aber erst ab Mitte 2021 beginnen soll. Der Webzugang zum Tracker wird auch vom Wohlverhalten abhängig gemacht.

Banken mit kleinstem Volumen könnten eine manuelle Meldung im Tracker in Betracht ziehen. Für automatisierte Lösungen sollte z. B. die ZV-Plattform einen der von SWIFT angebotenen Wege (MT199 oder API) unterstützen. Zusätzlich gibt es eine sogenannte CSV-Lösung, bei der aus einem bestimmten CSV-Report im SWIFT-Interface dann entsprechende Meldungen an den Tracker erzeugt werden.

Also muss eine Non-gpi-Bank fast alles das erfüllen, was eine gpi-Bank auch erfüllen muss. Der fehlende Schritt ist nicht mehr groß, der Nutzen für die eigenen Kunden kann enorm sein. Und mit den Möglichkeiten für gpi bei Bank-an-Bank-Zahlungen (MT202/205 – gFIT genannt, das steht für Financial Institution Transfer service, eine Option für gpi-Banken) kann den bankinternen Abteilungen wie Treasury oder Geldhandel auch die Sicherheit „Zahlung ist angekommen“ gegeben werden.

Es kommt aber nicht darauf an, die Statusmeldungen aus dem Tracker für gesendete Zahlungen als Bank zu bekommen, sondern vielmehr darum, dem Kunden einen Mehrwert zu bieten – im besten Fall die Quittung „Zahlung angekommen“ (inkl. der Information zu Gebühren und Umrechnungskurs) zur Verfügung zu stellen. Von der Minimalversion des manuellen Zugriffs in der eigenen (Firmenkunden-)Hotline auf den Tracker, über Self-Service-Angebote im Online-Banking-Portal bis hin zur aktiven Info durch Notification von Statusmeldungen an den Firmenkunden reichen die Servicelevel, die eine Bank bieten kann. Und das geht eigentlich nur, wenn man den Schritt von der „Universal Confirmation“ hin zum gpi-Standard-Service geht und sich für gpi entscheidet. Hieran werden sich Banken mit Firmenkundengeschäft in Zukunft messen lassen müssen.

Hier ist bereichsübergreifende Zusammenarbeit gefordert, die Leistungen können nicht allein von der ZV-Abteilung oder gar nur von der IT selbst erbracht werden, wie es oft bei „regulatorischen“ Projekten bei einem SWIFT-Release erwartet wird. Mit einer Beratung, die den Gesamtprozess im Blick hat, kann dies gelingen.

Zusammengefasst kann man also feststellen: Von der Pflicht zur Kür ist der Weg gar nicht so weit, die Aussichten auf zusätzliche Services für Firmenkunden und aber auch bankinterne Bereiche ist enorm.


Autor: Mario Reichel

GPI und EBICS – Wie geht das zusammen?

Ist GPI nicht ein reines SWIFT-Thema? Auf den ersten Blick nun einmal ja. Die Abkürzung kommt von SWIFT und steht für „Global Payments Innovation“. Die Initiative für GPI wurde Ende 2015 schon mit breiter Unterstützung von vielen globalen Banken gestartet.

Die Basis von GPI ist die eineindeutige Referenz, kurz UETR (Unique End-to-End Transaction Reference), die eine Zahlung durch die manchmal lange Korrespondenzbankkette begleitet. So eine Referenz ist zwar ein Ungetüm von 36 Zeichen in der nach einem allgemeingültigen Algorithmus definierten Form xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx, aber das Ungetüm sichert die Eineindeutigkeit ohne zentrale „Vergabestelle“. Wurde die UETR anfänglich nur in einer CUG (Closed User Group) für (Firmen-)Kundenzahlungen in MT103-Nachrichten verwendet, haben inzwischen alle Zahlungen im FIN-Netzwerk so eine Referenz – gleichbleibend vom Anfang bis zum Ende der gesamten Zahlungskette.

Der zweite wesentliche Baustein von GPI ist der sogenannte Tracker. Der Tracker ist eine zentrale Datensammlung bei SWIFT zu allen GPI-Zahlungen. Er stellt den beteiligten Banken umfassende Informationen zum Status einer Zahlung in der Korrespondenzbankkette, zu Gebühren und zu Währungsumrechnungskonditionen bereit. Während der FIN-Transport diese Informationen aus den transportierten Nachrichten selbst herausliest, können non-FIN-Banken den Tracker auch aktiv informieren. In der aktuellen Diskussion ist die sogenannte Confirmation – die Meldung der Gutschrift auf dem Konto des Begünstigten am Ende der Zahlungskette. Auf die Confirmation sollen ab 2020 alle FIN-Banken verpflichtet werden.

Aber warum der ganze Aufwand? Transparenz und Schnelligkeit – die beiden wesentlichen Herausforderungen im Korrespondenzbankgeschäft werden mit GPI angegangen. Durch die umfassende Verwendung von UETR liegen nun Statistiken vor: Durchschnittlich 40 Prozent der GPI-Überweisungen werden den Endbegünstigten innerhalb von fünf Minuten gutgeschrieben, innerhalb von 30 Minuten sind es 50 Prozent, innerhalb von sechs Stunden 75 Prozent und innerhalb von 24 Stunden nahezu alle. So eine Aussage war vor GPI einfach unmöglich. Hingegen kann jeder Treasurer Fälle berichten, bei denen Zahlungen spät oder gar nicht ankamen, mit hohen, unerklärlichen Gebühren, mit unklaren oder sogar ohne Verwendungszweckinformationen.

Neben den technischen Details wie UETR und Tracker gehört zu GPI ein Regelwerk, in dem die möglichst taggleiche Weitergabe einer Zahlung mit vollständigem Verwendungszweck, unter Angabe von abgezogenen Gebühren und Währungsumrechnungsdetails vorgeschrieben ist. Da es ja keine globale Transparenzrichtlinie gibt, muss dies auf multilateralem Vertragswerk begründet durchgesetzt werden. Und das ist auch gut so – Zeit dafür ist es schon lange.

Der (Firmen-)Kunde soll besseren Service im grenzüberschreitenden Zahlungsverkehr bekommen. Neben der Schnelligkeit und Transparenz ist ein weiterer Punkt die Quittung. So etwas gibt es ja eigentlich nur bei einer Barzahlung, im elektronischen Zahlungsverkehr war bisher das Motto: „shoot and forget“. Wenn es keine Beschwerden gibt, ist das Geld wohl angekommen. In den letzten Jahren hat es im SEPA eine beachtliche Entwicklung gegeben, und mit den Instant Payments nach dem Schema SCTinst gibt es auch hier nun eine Quittung. Mit SWIFT GPI ist die Erstellung einer derartigen Quittung ebenfalls möglich, auch wenn dies (noch) eine vollständige FIN-Kette in der Abwicklung voraussetzt. Es ist jedoch noch ein Stück Weg dorthin: Bisher wird an den breiten, erst einmal bankinternen, Umsetzungen gearbeitet. Die Anbindung der Kundensysteme für einen Zugriff auf die Informationen oder gar die Weitergabe von Status und Gebühreninformationen an Kundensysteme befindet sich noch am Anfang. Aber schon die Möglichkeit, im Falle eines Zweifels durch den Zugriff auf eine zentrale Stelle prüfen zu können, wo sich die Zahlung befindet, ist im großen Korrespondenzbanknetz ein erheblicher Fortschritt.

Geht das nur in FIN? Natürlich nicht. Die aktuellen Entwicklungen, z. B. die Migration der Großbetragssysteme (RTGS) wie TARGET2, EURO1 oder CHAPS von MT hin zu Nachrichten in XML nach ISO-20022-Standard, gehen diesen Weg. Die (neueren) ISO-Nachrichtenformate enthalten dedizierte Felder für die UETR, und so wird die Referenz auch außerhalb des FIN-Netzes transportiert. Und erst kürzlich verbreitete SWIFT die Meldung: „SWIFT trials instant cross-border gpi payments through TIPS“[1].

Für eine Anbindung von GPI-Rückmeldungen an Kundensysteme wie TMS oder ERP sind Nachrichten in Form von PSR (payment status report, also pain.002) effizienter als manuelle Prozesse. Aber schon diese Selfservice-Funktionen sind ein bedeutender Schritt hin zu mehr Transparenz. Übrigens sind die Standards zu diesen Rückmeldungen, also Felder (tags) und Codes, in der Harmonisierungsinitiative CGI-MP multibankfähig abgestimmt. In dieser Initiative wirkt PPI nun auch aktiv mit.

Des Weiteren steht auch die Erweiterung an, dass der Kunde seine Referenz in der Zahlung als UETR initiiert – im pain.001.001.03 in besonderen Feldern gemäß der CGI-MP oder auch schon in aktuelleren ISO-Versionen in dedizierten Feldern.

Und genau hier, an der Schnittstelle Kunde-Bank bzw. Bank-Kunde, werden sowohl Kundenzahlungen als auch PSR-Rückmeldungen ja auch oft mit EBICS transportiert. Somit stehen GPI und EBICS nicht im Widerspruch zueinander, sondern ergänzen einander sinnvoll – wie so oft im Zahlungsverkehr.

Autor: Dr. Mario Reichel

[1] Quelle: https://www.swift.com/news-events/press-releases/swift-trials-instant-cross-border-gpi-payments-through-tipshttps://www.swift.com/news-events/press-releases/swift-trials-instant-cross-border-gpi-payments-through-tips