EBICS WebSocket

Die Pflicht zur aktiven Benachrichtigung

Eine der Herausforderungen, die für Banken durch die Instant-Payment-Regulierung entstanden ist, ist die Pflicht der aktiven Benachrichtigung über die Ausführung der Echtzeitzahlung:

Neben dem eigentlichen Gesetzestext hat die EU noch einige Informationen in einem Fragen- und Antwort-Dokument veröffentlicht¹.

Bei den sogenannten DG-FISMA-Fragen² hat mindestens eine Bank explizit wegen EBICS nachgefragt:

Frage 48: Reicht es aus, dem Zahler die Informationen zur Verfügung zu stellen, damit er sie nach eigenem Ermessen abrufen kann (wie es heute bei der Verwendung von EBICS geschieht), oder müssen sie aktiv übermittelt werden?

Als Antwort stellt die EU Folgendes zur Verfügung:

Hinsichtlich der Information des Zahlers darüber, ob der Betrag der Zahlungstransaktion dem Empfänger zur Verfügung gestellt wurde, impliziert Artikel 5a(4), Punkt (e), eine „aktive“ Bereitstellung dieser Information durch den PSP des Zahlers an den Zahler, da vom Zahler nicht erwartet wird, dass er nach dieser Information nach Ablauf von 10 Sekunden sucht, während er einen Kauf am PoS tätigt.

Der Bank, die diese Frage gestellt hat, war die EBICS-Problematik offensichtlich vollkommen bewusst: Bei EBICS initiiert immer der Kunde die Kommunikation und beendet diese sofort wieder, nachdem Daten gesendet oder abgeholt wurden. Es ist auch immer der Kunde, der diese Kommunikation startet und wieder beendet. Die Bank hat dabei nur die Möglichkeit, eine Information zur Verfügung zu stellen, aber kann diese nicht initiativ zum Kunden pushen.

Somit fragt die Bank richtigerweise: Ist es ausreichend, wenn wir dem Kunden die Information über die Ausführung der Echtzeitzahlung nur bereitstellen?

Bisher werden auch Kontoauszüge nur „zur Verfügung gestellt“, ebenso die Verarbeitungsprotokolle PTK, HAC oder pain.002. Ein gut organisierter EBICS-Kunde mit einem professionellen EBICS-Connector hat in den meisten Fällen einen Scheduler im Einsatz, der Kontoauszüge zu einer bestimmten Uhrzeit morgens abruft oder PTK/HAC oder pain.002 eine kurze Zeit nach dem Senden der Zahldatei. Das macht der Kunde aus Eigeninteresse und ohne den aktiven Hinweis der Bank, dass etwas zum Abholen bereitsteht. Ein Hinweis, dass diese Information zur Verfügung steht, ist somit nicht notwendig.

Zusätzlich scheint, dass die DG FISMA auf den konkreten EBICS-Verfahrensfall nicht wirklich eingegangen ist: Die Bank wollte explizit wissen, wie beim Einsatz von EBICS zu verfahren ist. Die Antwort scheint sich jedoch auf eine Kauftransaktion am Point of Sales (PoS) zu beziehen. An der Kasse stehend und bezahlend kann man die Antwort der DGFISMA richtig finden: Man sollte nicht gezwungen sein, nach einer Zahlung eine Banking-App zu öffnen, um zu kontrollieren, ob die Zahlung erfolgt ist, oder nicht. Hierfür bekommt man über eine App eine Push-Nachricht, dass dies erfolgt ist, was im Sinne der IPR ist. EBICS hat jedoch nichts mit dem PoS zu tun.

Unserer Meinung nach sollte ein EBICS-Kunde nicht darüber informiert werden müssen, dass eine Information zur Abholung vorliegt, da er – wie oben bereits erwähnt – einen Scheduler verwenden kann beziehungsweise verwendet, um solche Dateien automatisch abzuholen. Dennoch  fordert  die IPR von EBICS-Banken nun, ihre Kunden über die Ausführung der Echtzeitzahlung aktiv zu benachrichtigen. Das ist allerdings, wie oben bereits beschrieben, über EBICS bereits aus technischen Gründen nicht möglich.

Die Lösung hierfür kann in einem EBICS-Ableger liegen, den die DK (Deutsche Kreditwirtschaft, ein Zusammenschluss der Spitzenverbände der deutschen Kreditwirtschaft) seit Juli 2020 als neue Anlage 2 in das DFÜ-Abkommen aufgenommen hat: EBICS WebSocket.

EBICS Websocket ist eine Technologie, die im Zusammenhang mit dem EBICS-Standard verwendet wird, um eine direkte und dauerhafte Verbindung zwischen einem Bankkunden und seiner Bank herzustellen.

Normalerweise kommuniziert man bei EBICS über standardisierte HTTP- oder HTTPS-Verbindungen. Mit WebSocket wird diese Kommunikation jedoch in Echtzeit und bidirektional möglich. Das heißt, sowohl der Client des Kunden, als auch der Server der Bank können jederzeit Daten austauschen, ohne ständig neue Verbindungen aufbauen zu müssen. Es ist besonders nützlich, wenn eine kontinuierliche Überwachung oder sofortige Reaktionen erforderlich sind, oder eben für die „aktive Benachrichtigung“.

Notwendige Änderungen für die Nutzung von EBICS WebSocket in der Bank

Um WebSocket nutzen zu können, muss die Bank neben dem EBICS-Server auch einen EBICS-WebSocket-Server einrichten.

Die Web-Security-Services(WSS)-Zugangsdaten müssen in einem definierten JSON-Format erstellt werden. Dann können sie dem EBICS Server bereitgestellt werden. Außerdem muss die Bank die notwendige Anzahl an potenziellen Verbindungen sicherstellen und die entsprechende Bandbreite anbieten. Die Push-Information an den Kunden wird durch JSON-Nachrichten getriggert, wenn neue Daten auf dem EBICS Server verfügbar sind. Zuletzt muss auf dem Bankrechner für Kunde und Teilnehmer die Berechtigung WSS vergeben werden.

Notwendige Änderungen für die Nutzung von EBICS WebSocket für den Kunden

Um EBICS WebSocket nutzen zu können, muss der Kunde ein WebSocket-fähiges Electronic-Banking-Programm nutzen, das die Auftragsart WSS durchführen können muss. Das System muss außerdem die gelieferte JSON-Struktur aus der EBICS Response verstehen und daraus die dauerhafte WebSocket-Verbindung aufbauen können.

Außerdem muss die Software die Push-Nachricht interpretieren und daraus die notwendigen Aktionen, wie zum Beispiel den Download der pain.002-Datei ableiten können.

Aufbau der WebSocket Verbindung³

Der Aufbau der EBICS-WebSocket-Verbindung ist in der folgenden Grafik mit den einzelnen Aktionen nach zeitlichem Ablauf durchnummeriert und für die verschiedenen Sphären in unterschiedlichen Farben dargestellt (blau = EBICS, rot = WebSocket, grün = Zusammenspiel EBICS WebSocket und EBICS in der Kundensphäre):

Ablauf einer Avisierung⁴

Die folgende Grafik zeigt als Beispiel einer Echtzeitbenachrichtigung die Avisierung eines Echtzeitüberweisungseingangs. Auch hier sind die einzelnen Aktionen nach zeitlichem Ablauf durchnummeriert und für die verschiedenen Sphären in unterschiedlichen Farben dargestellt (blau = EBICS, rot = WebSocket, grün = Zusammenspiel WebSocket und EBICS in der Kundensphäre beziehungsweise in der Banksphäre):

Daten der Übertragung

In der Push-Nachricht der Bank an den Kunden werden nicht die eigentlichen Daten, also zum Beispiel die pain.002 oder der camt.054 selbst übertragen, sondern nur die Information, dass eine solche Nachricht zur Abholung zur Verfügung steht. Der eigentliche Transfer der Nachricht erfolgt dann über die traditionelle EBICS-Schnittstelle. Ein gutes Electronic-Banking-System auf Kundenseite kann die Push-Nachricht interpretieren und dann die Datei selbständig abholen.

WebSocket für Echtzeit-Geldeingänge

Aktuell ist EBICS WebSocket nicht sehr verbreitet, weder auf Banken- noch auf Kundenseite. Mit den Echtzeitzahlungen wird sich das möglicherweise ändern. Neben der neuen Verpflichtung der Bank, den Kunden über den Erfolg oder Misserfolg der Echtzeitzahlung zu informieren, kommt womöglich der initiale Grund für die Aufnahme dieses Standards ins DFÜ-Abkommen in den Fokus: Die Benachrichtigung, dass ein Echtzeitzahlungseingang stattgefunden hat.

Firmenkunden hatten bisher nur die Möglichkeit, regelmäßig camt.054 abzuholen, in der Hoffnung, dass mittlerweile eine Info eingegangen ist. Das hat grundsätzliche unnötigen Traffic auf die Leitungen gebracht. Mit der WebSocket-Lösung gibt es eine Push-Nachricht, die dann den Abruf der camt.054-Nachricht triggert. Die EBICS-Kommunikation wird also nur aufgebaut, wenn sichergestellt ist, dass auch etwas zum Abholen vorhanden ist.

Die Verpflichtung der aktiven Benachrichtigung in der IPR

Auch wenn WebSocket noch nicht weit verbreitet ist, ist es aus Bankensicht ausreichend, wenn die „Aktive Benachrichtigung“ im Sinne der IPR darüber angeboten wird. Die Banken müssen nicht sicherstellen, dass alle Kunden WebSocket nutzen. Das Angebot, diese Informationen aktiv über WebSocket zur Verfügung zu stellen ist ausreichend. Andere akzeptable Benachrichtigungsformen könnten auch ein Hinweis über E-Mail oder eine Internetbanking-Plattform die Push-Nachrichten senden kann, oder auch ein SMS-Service sein. Darüber hinaus müsste vorab definiert werden, wer alles diese Nachrichten beim Kunden erhalten soll.

Keine Möglichkeit der aktiven Benachrichtigung über die Ausführung der Echtzeitzahlungen anzubieten, könnte grundsätzlich riskant sein, weil es ein klarer Verstoß gegen die Instant-Payment-Regulierung ist.

Auch hier wurde den Banken vorgegeben, den Service der aktiven Benachrichtigung für den Kontoinhaber kostenfrei anzubieten, während die Implementierung der oben genannten Infrastruktur für die Bank nicht unerhebliche Kosten und zusätzlichen Administrationsaufwand verursacht.

Weitere Herausforderungen

Es gibt weitere Herausforderungen, die hier nicht abschließend geklärt werden können. Aber vielleicht werden diese im Laufe der Zeit von den Bankverbänden oder von Gerichten entschieden:

• Muss die Bank sicherstellen, dass die Push-Nachricht auch wirklich beim Kunden ankommt? Beispielsweise könnte der Kunde nur solche Nachrichten erhalten, wenn auch sein E-Banking-Account auf seinem digitalen Endgerät geöffnet ist.
• Ist es ausreichend, wenn ein Nutzer beim Kunden diese Push-Nachricht erhält beziehungsweise dafür administriert ist? Was ist aber, wenn dieser Nutzer abwesend ist und daher aktuell nicht arbeitet?

Fazit

Ein EBICS-Kunde benötigt in der Praxis keine aktive Benachrichtigung über die Ausführung der Echtzeitzahlung, da ein Scheduler hier regelmäßig kontrollieren kann, ob entsprechende Daten vorliegen. Es ist fraglich, ob dafür viele Kunden in EBICS WebSocket investieren werden.

Anders sieht es hingegen mit einer Push-Nachricht für Geldeingänge aus. Da hier keine Aktivität des Kunden vorausging – nach einer Zahlung weiß man ja, dass nach einer gewissen Zeit ein Payment Status Report kommen sollte -, ist hier die Information sinnvoller. Doch auch hier könnte man einen Scheduler einsetzen, der alle 15 Minuten bei der Bank „nachfragt“.

Banken und Softwareanbieter sollten daher jetzt in EBICS WebSocket investieren, um langfristig IPR-konform agieren zu können.