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

Echtzeitbenachrichtigungen und EBICS - Schluss mit den „Hoffnungsabfragen“ bei Downloads

Wie bereits in meinem Blog-Beitrag im Dezember 2018 vorgestellt, findet auch das Thema Echtzeitüberweisungen (Instant Payments) im Firmenkundengeschäft über das neue Bulk-Format Einzug in die EBICS-Welt. Für die Einreichung von Echtzeitüberweisungen gelten dabei für die EBICS-Transferphase nicht die engen synchronen Zeitregeln des Instant Payments. Die Uhr beginnt erst hinter dem EBICS-Bankrechner zu ticken.

Und wie sieht es mit der Rückrichtung für Instant-Payments-Geschäftsvorfälle im EBICS aus? Immerhin sollte ein Geld-Eingangsbenachrichtigung (Credit Notification), wenn schon nicht in Echtzeit möglich, dennoch möglichst zeitnah dem Zahlungsempfänger zugeführt werden. Im Standard-Rollenverhältnis in der Kunde-Bank-Beziehung holt der EBICS-Client bekanntlich stets die Informationen vom Bankrechner ab. Ein aktiver Versand durch die Bank per EBICS ist hier nicht vorgesehen. Hier hat insbesondere die Wirtschaft die Banken und Die Deutsche Kreditwirtschaft zu einer pragmatischen Lösung einer Push-Möglichkeit gedrängt. Ziel sollte es letztendlich sein, eine Lösung zu entwickeln, die sich ohne Änderungen des EBICS-Protokolls und ohne Veränderung des Rollenverhältnisses umsetzen lässt.

Herausgekommen ist die Idee einer neuen Websocket-basierten Standardschnittstelle, die EBICS-Clients über die Bereitstellung von neuen Informationen für den Download informiert. Hierzu gehört auch die Information über eine neue Bereitstellung einer Credit Notification. Auf diesem neuen Push-Kanal werden somit keine sensiblen Daten übertragen. Die Abholung der relevanten sensiblen Daten erfolgt nach wie vor über den sicheren EBICS-Kanal.

Mittlerweile hat Die Deutsche Kreditwirtschaft diese neue Schnittstelle in der “Spezifikation Echtzeitbenachrichtigungen” spezifiziert und in der Version 1.0 am 18.07.2019 auf der deutschen EBICS-Webseite (www.ebics.de) veröffentlicht.

Nun gilt es, diese Schnittstelle in den EBICS-Clients und in den EBICS-Bankrechnern standardkonform und zeitnah umzusetzen. Bieten sich dadurch doch neue Möglichkeiten zur Optimierung des Firmenkundengeschäftes auch unabhängig vom Instant Payments. So lassen sich z. B. für sämtliche Abholprozesse die häufigen und permanenten “Hoffnungsabfragen” von automatisierten EBICS-Clients einsparen, wie sie u. a. bei Kontoauszugsabrufen durchgeführt werden. Dadurch können sowohl EBICS-Client-Nutzer als auch Bankrechnerbetreiber mit Lastreduzierung rechnen. Das sind doch gute Neuigkeiten, oder?

Autor: Michael Lembcke

Ist das EBICS-Protokoll von der starken Authentifizierung (SCA) im Sinne der PSD2 befreit?

Diese Frage wurde uns wiederholt von französischen und europäischen Finanzinstituten gestellt und es war nicht immer ganz einfach, eine ausreichend formelle Antwort zu geben.
Vor kurzem hat die Banque de France eine offizielle Antwort verfasst, in der sie das EBICS-Protokoll auf die Liste der Verfahren und Protokolle setzt, die gemäß Artikel 17 der delegierten Verordnung (UE) 2018/389 von der starken Authentifizierung befreit sind. Die Verordnung besagt: "Bei juristischen Personen, die elektronische Zahlungsvorgänge über dedizierte Zahlungsprozesse oder -protokolle auslösen, die nur Zahlern zur Verfügung stehen, bei denen es sich nicht um Verbraucher handelt, können Zahlungsdienstleister von der Vorgabe einer starken Kundenauthentifizierung absehen, wenn die zuständigen Behörden der Auffassung sind, dass diese Prozesse oder Protokolle mindestens ein vergleichbares Sicherheitsniveau wie das in der Richtlinie (EU) 2015/2366 vorgesehene gewährleisten." 
 
Das bedeutet jedoch nicht, dass EBICS die starke Authentifizierung nicht unterstützt - weit gefehlt! Die Gewissheit, dass das EBICS-Protokoll mindestens vergleichbare Sicherheitsniveaus garantiert, wie sie in der Richtlinie vorgesehen sind, ist schon seit langem gegeben. Vor diesem Hintergrund möchte ich Sie dazu einladen, den Artikel EBICS und PSD2 – Wie kommt das zusammen? zu lesen oder erneut zu lesen, der vor einigen Monaten in diesem Blog veröffentlicht wurde.

Autor: Marc Dutech

Verifizierung der Hashwerte der Bankschlüssel beim EBICS-Initialisierungsrequest

EBICS-Transaktionen werden in unterschiedliche Phasen unterteilt: Initialisierung, Datentransfer und Quittierung (letztere ist nur für Downloadtransaktionen vorgesehen).

Im Rahmen der Initialisierung werden u. a. folgende Aspekte geprüft:

  • Auftragsart
  • Authentifikationssignatur
  • Hashwerte der Bankschlüssel
  • teilnehmerbezogene Berechtigungen

Die Transaktion wird mit der Transferphase, in der die eigentlichen Auftragsdaten verschickt werden, nur dann fortgesetzt, wenn die Initialisierung erfolgreich durchlaufen wurde. Die Hashwerte der Bankschlüssel werden bei der Initialisierung geprüft, um sicherzustellen, dass der Client die aktuellen Bankschlüssel verwendet. Bei einer nicht erfolgreichen Prüfung sendet der Server den Returncode EBICS_BANK_PUBKEY_UPDATE_REQUIRED. Für den Client ist dies ein Indiz dafür, dass die neuesten Bankschlüssel mithilfe der Auftragsart HPB abgeholt werden sollten.

Vor der Harmonisierung durch EBICS 3.0 konnten die Bankschlüssel direkt oder in Zertifikate verpackt verwendet werden. Gemäß EBICS-Spezifikation müssen bis EBICS 3.0 in der Transaktionsinitialisierung die Hashwerte der öffentlichen Bankschlüssel angegeben werden – unabhängig davon, ob mit der Bank Zertifikate oder Schlüssel ausgetauscht wurden.

Ab EBICS 3.0 sind Zertifikate beim Schlüsselmanagement verpflichtend. In diesem Zuge wurde festgelegt, dass sowohl bei Uploads als auch bei Downloads in den EBICS-Initialisierungsrequests zukünftig die Hashwerte der Zertifikate angegeben werden müssen.

Die Hersteller von EBICS-Bankrechnern ermöglichen ihren Kunden in der Regel einen weichen Übergang, indem sie sowohl die Angabe der Bankschlüssel als auch die Angabe der Zertifikate im DER-Format erlauben. Das bedeutet, dass Kunden nach der Migration auf EBICS 3.0 keine Abholung per Auftragsart HPB ausführen müssen. Sowohl Schlüssel als auch Zertifikate können entweder in spezifikationskonformer HEX-Darstellung oder in alternativer Base64-Darstellung angegeben werden. Eine Mischung beider Darstellungen in einem Request ist üblicherweise nicht vorgesehen.

Übrigens: Mit EBICS 3.0 wurde das Schlüsselmanagement nicht nur für Bankschlüssel, sondern auch für Teilnehmerschlüssel vereinheitlicht. So ist es jetzt nicht mehr nur in Frankreich (CFONB) verpflichtend, Teilnehmer mit Zertifikaten zu initialisieren, sondern in allen Ländern. Auch hier ermöglichen EBICS-Bankrechner in der Regel einen weichen Übergang: Teilnehmerschlüssel mit einer Mindestlänge von 2.048 Bit können auch für EBICS 3.0 verwendet werden, und für die Schlüsselaktualisierung (Auftragsarten HCA, HCS und PUB) können die neuen Zertifikate üblicherweise mit den Schlüsseln der älteren EBICS-Versionen unterschrieben werden.
CA-basierte Zertifikate finden bisher weiterhin nur in Frankreich Verwendung. Aus Sicht der Bankrechner sollte einer Einführung in anderen Ländern allerdings nichts im Wege stehen.


Autor: Hendrik Chlosta

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

EBICS-Tests mit Kunden im produktiven Bankrechner?

Seit EBICS 2.4 ist es in Frankreich möglich, Geschäftsvorfälle – nicht wie u. a. in Deutschland üblich – über dreistellige Auftragsarten sondern über die bis zu 40-stelligen FileFormat-Parameter auszutauschen. Diese sind bekanntlich jeweils mit den Auftragsarten FUL bzw. FDL einzuleiten. Dabei ist es möglich, ein sogenanntes Test-Flag anzugeben. Darüber kann ein EBICS-Kunde im produktiven Betrieb z. B. beim Senden einer Datei der Bank eine Testeinreichung signalisieren. Vorausgesetzt, es besteht eine bilaterale Vereinbarung über die Nutzung des Test-Flags, kann die Bank den Auftrag annehmen, als Testfall werten und vor der echten Verarbeitung aussteuern. Die Nutzung eines Test-Flags in Produktion ist bei den Banken nicht unumstritten. Eine solche Option wird von deutschen Banken derzeit überwiegend abgelehnt.

Mit der aktuellen EBICS-Version 3.0 und der einheitlichen Nutzung der BTFs anstelle von Auftragsarten und FileFormat-Parametern entfällt das bestehende Test-Flag in der EBICS-Spezifikation. Zudem wurde mit dem EBICS-CR EB-17-01 Element Group Parameter eine verschärfte Prüfung auf die Nutzung von nicht bilateral vereinbarten Angaben in den generischen Parametern des BTFs eingeführt. Unerlaubte Angaben werden nun mit dem EBICS-Returncode 09-0-0-06: EBICS_UNSUPPORTED_REQUEST_FOR_ORDER_INSTANCE abgelehnt.

Als Hilfestellung für die EBICS-3.0-Einführung in Frankreich hat der französische CFONB einen eigenen Migrationsleitfaden erstellt (EBICS 3.0 Aide à la migration BTF & Table de correspondance File Format/BTF). Da in Frankreich das Test-Flag von Banken in der Vergangenheit genutzt wurde und auch weiterhin der Bedarf an einer solchen Option besteht, hat der CFONB für die BTF-Migration die Nutzung des Test-Modus für BTF definiert und als optionale Funktion in den Leitfaden aufgenommen. Somit kann bei bilateraler Vereinbarung zwischen Bank und Kunde auch bei BTF der Parameter TEST für Testfälle genutzt werden. Bei abweichender Parameterangabe erfolgt eine Ablehnung mit dem o. g. Returncode. EBICS-Bankrechner, und EBICS-Clients können diese Funktion optional mit anbieten.

Unabhängig davon gibt es bei EBICS auch die Alternative, für Testeinreichungen eigene speziell für den Test bilateral vereinbarte Geschäftsvorfälle (BTFs) zu nutzen.

Letztendlich bleibt aber festzuhalten, dass bei Nutzung der Testoption in der Produktionsumgebung immer das Risiko besteht, dass Testdateien die Produktion negativ beeinflussen oder gar unerwartet Eingang in die Produktionsdaten finden können.

Sicherer ist da dann doch eine eigene EBICS-Bankrechner-Installation für EBICS-Tests mit Kunden. Warum nicht?


Autor: Michael Lembcke