Posts mit dem Label Consulting werden angezeigt. Alle Posts anzeigen
Posts mit dem Label Consulting werden angezeigt. Alle Posts anzeigen

Request to pay (R2P) verändert den Zahlungsverkehr – technische Herausforderungen

Der letzte Blog-Beitrag zu Request to Pay hat uns gezeigt, wie besinnlich die Weihnachtszeit und wie geordnet die dazugehörigen Einkäufe mit R2P ablaufen könnten. Nun ist es bis zum nächsten Weihnachtsfest ja noch eine Weile hin und so bleibt Zeit, sich mit den Herausforderungen zu beschäftigen, die die Etablierung R2P-basierter Zahlungssysteme mit sich bringen.

Hier sei zunächst die technische Komponente genannt. Die EBA CLEARING hat im vergangenen Dezember Formatspezifikationen veröffentlicht, die sowohl die Zahlungsanforderung (pain.013) als auch die Antwort auf die Zahlungsanforderung (pain.014) beschreiben. Damit ist das Teilstück des Clearings technisch präzisiert, und es steht „nur noch“ die Herausforderung an, die Ein- und Ausgangsschnittstellen des Zahlungsverkehrssystems auf diese Abläufe und Formate vorzubereiten. Das klingt zunächst trivial, stellt jedoch für ein Zahlungsverkehrssystem eine echte Herausforderung dar: Sowohl Hinweg (Zahlungsanforderung) als auch Rückweg (Antwort) auf die Anforderung müssen binnen kürzester Zeit von einem Kundensystem durch das Zahlungssystem, die betreffenden Clearingsysteme und das empfangende bzw. antwortende Kundensystem geroutet werden.

Und natürlich ergibt sich hieraus auch die Frage, wie ein Kunde die Zahlungsanforderung überhaupt zu seiner Bank transportieren soll. Technisch findet hierzu gerade im European Payments Council und in der Deutschen Kreditwirtschaft (DK) eine Diskussion statt, und es wird eine technische Spezifikation für die Kunde-Bank-Schnittstelle erstellt.

Hier kommt dann die fachliche Komponente zum Tragen, in der man existierende Systeme bereits dahingehend konzeptionell überdenken sollte, welches System im Eingang Zahlungsanforderungen entgegennehmen und mit welchem Gegenstück diese beantwortet werden sollen. Woraus sich dann unmittelbare Folgefragen ergeben, wie z. B. die Frage danach, wie der Kunde auswählen kann, ob er per SEPA oder SEPA Instant bezahlen möchte (sofern er diese Auswahl je nach Ausgestaltung der Zahlungsanforderung überhaupt hat). Nicht weniger bedeutend ist die Frage, wie er die Zahlungsanforderung autorisieren soll. Hier eignen sich z. B. die Autorisierung mit einem Mobile-Device und den hierfür etablierten TAN-Systemen oder auch eine Überstellung in die EBICS-Unterschriftsmappe zur Unterzeichnung mit verteilter elektronischer Unterschrift.

Die Information über einen Zahlungseingang aus einer Instant-beglichenen Zahlungsanforderung ist dagegen dank des spezifizierten „Haben-Avis für SEPA-Echtzeitüberweisungen“ mittlerweile recht einfach bereitzustellen.

Im richtigen Zusammenspiel der technischen Möglichkeiten wird R2P dem Instant-Zahlungsverkehr sicher einen immensen Schub verleihen. Die auf dem Weg dorthin beschriebenen Herausforderungen stellen zugegebenermaßen einen nicht unerheblichen Aufwand dar, der sich mit Blick auf die zahlreichen Gestaltungsspielräume jedoch bei richtiger Umsetzung auszahlen wird. Welche Einsatzszenarien und Use Cases sich aus den technischen Möglichkeiten ergeben, haben wir für Sie im Whitepaper „Request to Pay – Vielfältige Einsatzmöglichkeiten“ näher beleuchtet. Außerdem stehen wir Ihnen sowohl für inhaltliche als auch technische Diskussionen gerne zur Verfügung.

Autor: Eric Waller

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

Payments before Christmas – Weihnachtseinkäufe mit Request to Pay?

Die Weihnachtszeit. Nicht ganz so weiß, nicht ganz so besinnlich und nicht ganz so friedlich, wie es in den Geschichten immer heißt – aber auf ihre Art doch ganz reizvoll. Mitunter allerdings ein wenig verwirrend, vor allem wenn ich auf meine Kontoauszüge der vorweihnachtlichen Einkaufsabenteuer schaue.

Die meisten werden es kennen: Das gut gemeinte „…aber dieses Jahr schenken wir uns wirklich nichts!“ hat eine noch geringere Halbwertszeit als die bald darauf zu fassenden Neujahrsvorsätze. Und auch wenn Weihnachten gefühlt im Herbst mit den ersten Lebkuchen in den Regalen beginnt, wird die Zeit für den Einkauf der Präsente dann doch auf kurz vor knapp verschoben. Und so finde auch ich mich dieses Jahr wieder im Shoppingwahn gefangen. Eltern, Schwester, Großeltern, Familie des Partners mit fünf Geschwistern – und die nächste Generation steht auch schon vor der Tür. Die verschiedenen Wunschzettel, Einkaufslisten und Planungen mit meinen Kontoauszügen in Einklang zu bringen, gleicht einer Aufgabe für Sisyphos persönlich.

Meine bevorzugten Onlinekaufhäuser haben ein Lastschriftmandat von mir bekommen, in anderen digitalen Läden funktioniert nur die Zahlung per Kreditkarte, die Konzertkarten bezahle ich mit PayPal und die analog und „offline“ erstandenen Güter bekamen die Händler per Girocard vergütet.
All diese Positionen auf meinem viel zu langen Kontoauszug wiederzuerkennen, erinnert mich daran, dass ich für meine Tante ja noch ein dreitausend Teile Puzzle bestellen muss. Ist das Teeservice für die Oma eigentlich schon bezahlt oder wird das noch abgebucht? Wann wird eigentlich diesen Monat der Betrag meiner Telefonrechnung eingezogen? Das ist doch sonst auch immer so um diese Woche, oder? Und was ist eigentlich der „XY Shop“, und wofür bekam der 90 € von mir?

Wie jedes Jahr habe ich das Gefühl, dass mir der Einkaufswahnsinn durch die Finger gleitet und ich den Überblick verliere. Der zeitliche Versatz von Bestellung und Zahlung sowie die vielen unterschiedlichen Fristen lassen mich mit einem unguten Gefühl im Bauch zurück – gerade in dieser Zeit der unüblichen Abbuchungen von meinem Konto kann schnell etwas durchgehen. Was nützt es mir, dass ich eine per Lastschrift erfolgte Abbuchung zurückfordern kann, wenn ich sie nicht mehr zuordnen kann? Welche Kreditkartenzahlung habe ich wirklich autorisiert?

Es sollte einfacher sein. Es sollte geordneter sein. Es sollte unmittelbarer sein. Nächstes Jahr um diese Zeit?

Ich stelle mir vor, wie ich das neue Radio für meine Mutter bestelle und im Moment der Bestellung in meiner Banking App aufgefordert werde, den genauen Betrag dafür freizugeben. Die kitschigen Weihnachtspullover mit der Rentiernase werden in zwei verschiedenen Größen geordert, anprobiert. Und im Moment der Rücksendung des viel zu großen Exemplars fragt mich mein Onlinebanking, ob ich die Zahlung für den passenden Pulli freigebe.

Es liegen drei Pakete für mich in der Packstation. Um die Klappe öffnen zu können, weise ich nach Aufforderung die Zahlung an. Der XY Shop will schon wieder 90€ von mir? Abgelehnt! Dort habe ich doch gar nichts bestellt. Und meine Telefonrechnung ist im Dezember scheinbar höher als üblich gewesen und darum die Zahlungsaufforderung nicht automatisch bestätigt worden. Ich prüfe den Verbindungsnachweis und autorisiere dann per Hand – stimmt, ich habe mit den Verwandten in England telefoniert.

Die Aufforderung zur Zahlung, der Request-to-Pay. Ob meine nächste Weihnachtszeit besinnlicher oder friedlicher dadurch wird, wer weiß. Aber mehr Kontrolle über meine Zahlungen zu bekommen, bevor diese tatsächlich stattgefunden haben, und mir so meine Verwirrung beim Blick auf das Konto zu nehmen, das klingt doch fast so schön wie weiße Weihnacht.

Autor: Anuschka Clasen

Benachrichtigung bei SEPA-Instant-Payments-Zahlungseingängen – ein elementarer Baustein der Zahlungsprozesskette

Neben der kurzen Dauer einer finalen Echtzeitüberweisung ist die umgehende Information des Zahlungsempfängers bei Zahlungseingängen ein Kernelement des SCT Inst-Zahlungsablaufs und damit verbundener weiterer Prozessschritte.

Was in der Online-Transaktionsabwicklung zwischen Verbrauchern oder im Händler-Kunden-Verhältnis mittlerweile gut umsetzbar ist, stellt – wie im Blog-Artikel „Echtzeitbenachrichtigungen und EBICS - Schluss mit den „Hoffnungsabfragen“ von Michael Lembcke beschrieben – die beteiligten Akteure im EBICS-Corporate-Umfeld vor Herausforderungen: Zwar haben Umsatz-Notifications mittlerweile Einzug in die ab November 2019 gültige Anlage 3 des DFÜ Abkommens gehalten und sind dort als camt.054-Nachrichten, die mittels der EBICS Auftragsart C5N abgeholt werden können, spezifiziert, allerdings müssen diese aktiv vom Zahlungsempfänger bei der Bank abgeholt werden. Eine aktive Push-Benachrichtigung des Zahlungsempfängers war bislang nicht vorgesehen. Mittlerweile konnte diese funktionale Lücke allerdings geschlossen werden, indem die EBICS-Spezifikation um eine auf dem WebSocket-Protokoll basierende Information vom Bankrechner an den Kunden erweitert worden ist. Somit können Umsatzinformationen dann zeitnah abgeholt werden, sobald der zugrunde liegende Zahlungseingang stattgefunden hat. Erfolglose „Hoffnungsabfragen“ entfallen somit.

Da mit einer direkten Benachrichtigung über den Zahlungseingang auch schnellere und effizientere Gesamtabläufe im Corporate-Umfeld möglich sind, ist es an der Zeit, diese wichtige Funktion genauer zu betrachten.

Ausgangspunkt der Reise in die Instant-Notification-Welt ist die globale Vernetzung der Gesellschaft. Nahezu zu jeder Zeit und an jedem Ort der Welt sind digitale Services verfügbar: zunehmend in Echtzeit – „always on, always instant“. Waren früher prozessbedingte Wartezeiten durch klassische Bezahlvorgänge, die je nach Empfängerland mehrere Tage in Anspruch nehmen konnten, und langsame logistische Prozesse beim Versand der Waren der Standard, ermöglicht die fortschreitende Digitalisierung immer durchgängigere Prozessketten ohne Medienbrüche und Wartezeiten und sorgt für ein hohes Wachstum im Bereich neuer digitaler Angebote.

Einige aufeinander aufbauende Schritte der Kette lassen sich nicht ohne Weiteres in die Instant-Welt überführen, da prozessuale Abhängigkeiten zur nicht digitalen Welt bestehen. Andere Schritte hingegen sind heute schon 24/7/365 verfügbar – teilweise mit Finalität innerhalb weniger Sekunden. Hierzu zählt u.a. der Bestell- und der anschließende Bezahlprozess.

Das Zauberwort hierfür heißt Instant Payments, die eine sofortige Gutschrift des Zahlbetrages beim Empfänger vorsehen und somit auch eine sofortige Leistung nach Bezahlung ermöglichen können. Was in Bezug auf digitale Produkte funktioniert, gestaltet sich im Bereich des Versandhandels schwieriger: Hier ist zwar eine Beschleunigung des Gesamtprozesses durch einen schnellen Zahlungseingang beim Händler möglich, eine direkte Verfügbarkeit der bestellten Ware lässt sich nur schwerlich darstellen und der Kunde tritt über einen, wenn auch verkürzten Zeitraum, in Vorleistung.
Ein Kauf auf Rechnung wäre aus Sicht des Kunden die risikoärmste Variante. Für den Händler/Lieferanten birgt sie jedoch erhöhte Risiken, da dieser in Vorleistung tritt und nicht von einer zeitnahen Begleichung der offenen Forderung ausgegangen werden kann. Vorkasse mittels klassischer Bezahlmethoden inkl. Karten führt lediglich zu einer Umkehr der Risikoposition, jedoch nicht zu einer optimalen Risikoaufteilung zwischen Händler und Käufer. Diesem Umstand kann derzeit nur ein Intermediär begegnen, der als für den Händler und Käufer vertrauenswürdige Instanz die Übergabe der Ware und den Bezahlvorgang zeitgleich abwickelt. Keine Bezahlung – keine Ware und umgekehrt. Klassischer Nachnahmeprozess also.

Welche Rolle spielt hierbei nun die Notification des Zahlungsempfängers? Ohne eine umgehende Benachrichtigung des Begünstigten über den Zahlungseingang sind beschleunigte Abläufe und damit verbunden auch neue innovative Produkte, die auf einer direkten Bezahlung basieren, undenkbar. Nur mittels einer in den Zahlungsprozess integrierten oder unmittelbar daran anschließenden Information an den Begünstigten kann das zugrunde liegende Geschäft abgeschlossen oder zumindest der nächste Schritt in der Prozesskette gegangen werden – sei es mittels eines Online-Prozesses über eine API, die von der Bank hierfür bereitgestellt wird, oder durch die Nutzung des EBICS-Kanals in Verbindung mit einem Push-Service.

Bislang erfolgten Umsatzbenachrichtigungen i.d.R. mittels untertägigen Kontoinformationen (Umsatzinfo MT942) oder im Kontoauszug (MT940), der mit einem Versatz von einem Tag bereitgestellt wurde. Durch die im SCT Inst verankerte verpflichtende umgehende Rückmeldung bei einem Instant-Payments-Zahlungseingang ist erst der vollumfängliche Abschluss des Zahlungsvorgangs möglich. Insbesondere für den Einsatz von Instant Payments am POS ist dies unerlässlich. Lange Wartezeiten bis zum Abschluss der Transaktion würden eine Kundenakzeptanz verhindern. Die Benchmark hierfür ist die Dauer einer Kartenzahlung.

Doch nicht nur am POS ist eine umgehende Benachrichtigung relevant: Bestehende Bezahlverfahren wie z. B. Rechnungsbegleichung mittels Instant Payments im Online-Banking oder auch die klassische Nachnahme an der Haustür profitieren hiervon. Im ersten Fall liegt der Vorteil in einem beschleunigten Gesamtablauf für alle Beteiligten und in letzterem handelt es sich insbesondere um die Substitution klassischer Zahlungsinstrumente wie Bargeld oder Karten.

Aber auch bei der Entwicklung zukünftiger Bezahlverfahren wie z.B. Request to Pay wird die Notification eine tragende Rolle spielen. In diesem Zusammenhang möchte ich gerne auf einen weiteren EBICS-Blog-Artikel meines Kollegen Eric Waller verweisen, der sich mit diesem Thema beschäftigt: „Request to Pay verändert den Zahlungsverkehr – erste Use Cases“.

Autor: René Keller

Request to Pay verändert den Zahlungsverkehr – erste Use Cases

Die Zahlungsanforderung oder fachlich Request to Pay (R2P) ist ein neues Zahlungsinstrument, das den Zahlungsverkehr nachhaltig verändern wird. Ich habe im Whitepaper „Request to Pay komplettiert den elektronischen Zahlungsverkehr“ bereits den Zusammenhang zwischen elektronischen Rechnungen, Instant Payments und dem eben bisher fehlenden Zahlungsinstrument Request to Pay hergestellt.

In diesem Blogbeitrag möchte ich mich nun einigen ersten von zahlreichen Use Cases widmen, die durch Request to Pay einfach an ein bestehendes Bankkonto adressiert werden können:

  • Request to Pay bei bereits versandter Warenrechnung: Ein einfacher Use Case ist, dass die Rechnung bereits klassisch auf dem bisherigen Weg versandt wurde und zusätzlich im Anschluss ein Request to Pay versandt wird. Dieser Use Case zielt in erster Linie darauf ab, die Zahlung der fälligen Rechnung durch den Zahlungspflichtigen zu beschleunigen, indem ihm die Erfassung der Rechnungsdaten erspart bleibt. Der Request to Pay zu der ihm bereits vorliegenden Rechnung wird ihm in seinem Online- oder Mobile-Banking präsentiert und Empfängerdaten, Zahlungsbetrag und Verwendungszweck sind bereits ausgefüllt. Der Zahlungspflichtige braucht nur noch die Ausführung zu bestätigen und mit seinen Credentials zu signieren.
  • Request to Pay in Kombination mit einer Warenrechnung: Der zuvor beschriebene Use Case ist natürlich auch dahingehend vorstellbar, dass sowohl eine elektronische Rechnung als auch der zugehörige Request to Pay dem Zahlungspflichtigen gemeinsam in seinem Online- oder Mobile-Banking präsentiert werden. So wird zusätzlich der konventionelle Postversand eingespart und der Zahlungspflichtige kann seine Rechnung digital sichten und komfortabel zahlen. Gleichzeitig bietet diese Variante auch die Möglichkeit, die Rechnung in einem Bankingarchiv digital abzulegen und jederzeit einer Zahlung wieder digital zuzuordnen.
  • Request to Pay im Zug-um-Zug-Geschäft: Natürlich kann Request to Pay nicht nur bei räumlicher Trennung der Beteiligten eingesetzt werden. Es ist daher auch vorstellbar, den bisherigen Nachnahmeprozess mit Barzahlung zu digitalisieren. Der Paketbote adressiert hierbei eine Request-to-Pay-Nachricht an den Paketempfänger, dieser prüft die Warenlieferung und löst einen Instant-Payments-Auftrag als Antwort auf den Request aus. Der Paketbote wiederum erhält eine sogenannte Notification über den Eingang der Zahlung und gibt die Ware frei.
  • Request to Pay im stationären Handel: Ähnlich wie im zuvor geschilderten Fall ist es auch denkbar, Request to Pay in Kombination mit Instant Payments und Notification im stationären Handel einzusetzen. In diesem Fall wird nicht die Rechnung, sondern der Einkaufsbeleg gemeinsam mit der Request-to-Pay-Nachricht transportiert und kann gemeinsam mit der Buchung in einem digitalen Archiv am Konto abgelegt werden. Das Kassenpersonal gibt den Einkauf natürlich auch hier erst dann frei, wenn die Notification eingetroffen ist.
So sind Zahlungsanforderungen in zahlreichen Branchen einsetzbar und daher wird aus meiner Sicht das neue Zahlungsinstrument Request to Pay den Zahlungsverkehr in seiner bisherigen Form nachhaltig verändern. Ich  werde an dieser Stelle regelmäßig über neue Entwicklungen und natürlich weitere Use Cases berichten.    

Autor: Eric Waller

Moderatorenbeitrag: Erweiterung PPI EBICS-Blog – all about Payments!

Liebe Leserinnen und Leser,

wir freuen uns, Sie heute über die Erweiterung unseres EBICS-Blogs zu informieren.

Im PPI EBICS-Blog "All about Payments" möchten wir Sie zukünftig noch umfassender über Trends und aktuelle Themen rund um den Zahlungsverkehr in den Bereichen EBICS, SEPA, SWIFT sowie Regulierung und Digitalisierung auf dem Laufenden halten.

Ab sofort wird der EBICS-Blog von zwei Autorenteams und im 2-wöchigen Rhythmus für Sie bespielt. Unser Ziel: Ihnen über die Sichtweisen und Erfahrungen unserer Produkt- sowie Consulting-Experten aus Kundenprojekten, Studien und Whitepapern im Hinblick auf aktuelle und zukünftige Anforderungen im Zahlungsverkehrsmarkt aus erster Hand zu berichten.

Wir freuen uns auf Ihr Feedback und wünschen Ihnen weiterhin viel Spaß beim Lesen!

Ihr PPI Autoren-Team

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