Posts mit dem Label EBICS-Protokoll werden angezeigt. Alle Posts anzeigen
Posts mit dem Label EBICS-Protokoll werden angezeigt. Alle Posts anzeigen

EBICS-Zahlungseingang in Echtzeit – Utopie oder Wirklichkeit!?

Zahlungsverkehr mit FTAM oder EBICS war über 25 Jahre geprägt von Widersprüchen. Jede Form der Kommunikation war eine Einbahnstraße, stets gab es nur eine technische Quittung und man konnte erst sicher sein, dass wirklich alles funktioniert hatte, wenn man zeitversetzt das Kundenprotokoll manuell abgeholt und durchgelesen hatte. Wenn man so will, ist der Vergleich mit einem postalischen Brief im blickdichten Kuvert verschickt und die Antwort dann irgendwann per Brief im Kuvert zurück per Postweg das passende Bild für den Prozess. Auch wenn die Übertragung natürlich sehr viel schneller ausgeführt wurde als der klassische Brief per Post.

Nun, die Zeit schreitet voran, das Bedürfnis nach einer sekundenschnellen und vor allem qualitativ aussagekräftigen Antwort wird heute vorausgesetzt. Auch EBICS muss dieser Forderung langsam (endlich!) Rechnung tragen und neue Mechanismen anbieten.

Dabei darf aber das bisherige Verfahren der wechselseitigen Übertragung von Auftrag und dessen Beantwortung nicht einfach ignoriert oder gar abgeschaltet werden. Bestehende Prozessabfolgen im EBICS haben ihr bewährte Existenzberechtigung, vor allem, wenn es dabei darum geht, sehr große Datenmengen zu übertragen, die auch heute noch mehrere Minuten für eine vollständige Verarbeitung benötigen. Gerade diese Fähigkeit ist die immer noch herausragende Eigenschaft von EBICS.

Trotz allem muss es in Zukunft aber auch im EBICS-Protokoll möglich werden, kleinere Datenmengen schneller und vor allem mit sofortiger fachlicher Antwort versenden zu können.
Um diesen künftigen Anforderungen Rechnung tragen zu können, wurde das EBICS-Protokoll um die EBICS-Echtzeitnachrichten erweitert. Darin wird ein zweiter bidirektionaler Kommunikationskanal zwischen Kundenprodukt und EBICS-Bankrechner aufgebaut. In der aktuellen Spezifikation wird dieser Kanal zunächst nur für Ad-hoc-Meldungen vom Bankrechner zum Kundenprodukt genutzt.

In Zukunft kann dieser nun existierende Kommunikationskanal auch für Einreichungen und eine im Bankenumfeld bankfachliche Sofortverarbeitung eingesetzt werden. Diese kann dann auch die notwendigen Rückmeldungen erzeugen und dem Nutzer sofort – wie im Onlinebanking – eine qualitative Rückmeldung anzeigen.

Derzeit wird dieses Einreichungsformat noch mit speziellen EBICS-Systemen pilotiert und ist im Markt nicht allgemein etabliert.

Aber viel wichtiger als obiges Zukunftsszenario ist die allgemein verfügbare und bereits seit zwei Jahren spezifizierte Form der asynchronen Rückmeldung an Kundensysteme und deren Nutzer, d. h. die Firmenkunden. Diese EBICS-Echtzeitbenachrichtigung ist in der Anlage II der EBICS-Spezifikation dokumentiert und kann von allen Herstellern umgesetzt werden. Sie bietet einzigartige Möglichkeiten Kunden, Firmenkunden, schnell und zeitnah über alle Arten der Änderungen an ihren verschiedenen Konten zu informieren.

Mit dieser neuen Fähigkeit des EBICS-Protokolls ist es künftig möglich, bereits zum Zeitpunkt der Buchung eine Echtzeitnachricht per EBICS an den Kunden und sein Kundensystem zu senden. Dafür stellt die EBICS-Infrastruktur dann eine Schnittstelle zur Verfügung, die in entsprechende Buchungssysteme integriert werden kann oder es wird auch möglich sein, beliebige andere textbasierte Nachrichten aus anderen bankfachlichen Systemen zu nutzen und so die Firmenkunden stets mit neuen Nachrichten zu versorgen. Je nach Leistungsfähigkeit der Kundensysteme können wirklich viele neue interessante Anwendungsformen geboren werden.

Bei Banken, die eine so enge Kopplung zwischen EBICS und ihren Fachanwendungen nicht wünschen oder für die eine Einbindung zu kostenintensiv ist, wird eine weitere Option Interesse wecken.
EBICS-Bankrechner – wie TRAVIC-Corporate – können bei jeder Bereitstellung von Daten eine sofortige Nachricht an das oder die dem Kunden zugeordneten Kundensysteme senden und so signalisieren, dass neue Daten, z. B. ein Kontoeingangsavis, vorliegen.

Diese Form der Benachrichtigung wird besonders im Rahmen der Instant-Payments-Zahlungen bei Firmenkunden Interesse hervorrufen. Künftig werden – reguliert – immer mehr Zahlungen auf Instant Payments basieren und somit schnell ausgeführt werden. Das bedeutet, dass auch der Zahlungseingang beim Firmenkunden sofort anzuzeigen ist, damit die Ware oder Dienstleitung schnell geliefert bzw. geleistet werden kann.

EBICS-Echtzeitbenachrichtungen sind da der elementar wichtigste Bestandteil einer Instant-Payments-Lösung über die gesamte Strecke.

Diese Nachrichten sind auch so strukturiert aufgebaut, dass Kundensysteme – wie z. B. TRAVIC-Port – daraus intern Aktionen ableiten können. Automatisierte Abholungen der von der Bank bereitgestellten Daten werden möglich.

Und wenn sich die EBICS-Echtzeitbenachrichtigungen im Markt mehr und mehr durchsetzen, werden sich die vielen Hoffnungsabfragen der Kunden – 80 bis 90% der Kontoauszugsabfragen von Kunden werden mit „no data“ beantwortet – nicht mehr stattfinden. Die Kunden werden sich auf diesen neuen Mechanismus verlassen. Das bedeutet für die Betreiber von EBICS-Bankrechnern, dass diese nur noch Verbrauchskosten verursachen, wenn tatsächlich Daten vorliegen. Dies ist ein wichtiger Einspareffekt für Banken, der bedeutet, dass ihre Serversysteme kleiner ausfallen dürfen und tatsächlich viel weniger frequentiert werden.

Das ganze Szenario kann aber nur Fahrt aufnehmen, wenn Banken anfangen, diesen Service anzubieten; ein Warten auf die Kundenprodukthersteller wird nicht funktionieren, da diese stets erst dann Änderungen in ihre Produkte einbauen, wenn es tatsächlich auch Lieferanten – sprich EBICS-Bankrechner – gibt.

Mein Appell an die EBICS-Banken: Starten Sie den neuen Service, um die nächste Generation des EBICS-Protokolls für sich selbst und vor allem zum Vorteil Ihrer Kunden zu nutzen.

Autor: Michael Schunk

EBICS und VEU: Schwächen bei Gehaltszahlungen mit vertraulichen Informationen

Die Verteilte Elektronische Unterschrift (VEU) ist seit vielen Jahren eine wichtige Funktion, um Zahlungen von unterschiedlichen Personen selbst an unterschiedlichen Orten einreichen und freizeichnen zu lassen.
Die im EBICS-Protokoll dafür vorgesehenen Auftragsarten und deren fachlicher Inhalt erlauben eine Freigabe auf Basis der Gesamtdatenlage – über den Dateibegleitbeleg – oder gar auf Basis der inhaltlichen Zahlungsdaten. Dafür liefern EBICS-Server die wichtigsten Informationen für jede der enthaltenen Einzelzahlungen bereits in aufbereiteter Form. Ein Kundensystem, das diese Daten anzeigen soll, muss dazu nicht mal das konkrete Zahlungsformat kennen. Das macht die Software so komfortabel. Ausnahmsweise lässt sich sogar eine komplette Zahlungsdatei übermitteln. Doch gerade bei großen Sammelzahlungen stellt das den gerade beschriebenen Komfort wieder in Frage.
In der Zahlungsverkehrspraxis kommen nicht nur einfache Zahlungen und Lastschriften in die VEU-Mappe, sondern auch Sonderzahlungen mit sehr persönlichen Daten, die besonders zu schützen wären. Dazu gehören etwa Pensionszahlungen, Gehaltszahlungen sowie Bonuszahlungen und Gratifikationen, die nicht für die Allgemeinheit und erst recht nicht für die Einsichtnahme durch die Belegschaft eines Unternehmens bestimmt sind.
Genau an dieser Stelle wird eine Schwäche der EBICS-Spezifikation deutlich: der GVC oder PurposeCode, der festlegt, um was für eine Art Zahlung es sich handelt, fehlt, wenn die Einzelzahlungen übertragen werden. Die von Kunden eingesetzten EBICS-Produkte sind deshalb gar nicht in der Lage, selbst wenn die Unternehmen das wollten, vertrauliche Daten in einem Zahlungsauftrag zu schützen. Der Software fehlt das Kriterium, um zu entscheiden, ob Zahlungsdetails angezeigt oder ausgeblendet werden müssen.
Ohne eine Kennung im konkreten Zahlauftrag ist es nicht möglich, vertrauliche von normalen Zahlungen zu unterscheiden. Damit ist die VEU im Prinzip ungeeignet, um etwa Gehaltszahlungen zu prüfen und per VEU freizugeben, weil nicht auszuschließen ist, dass nicht berechtigte Mitarbeiter einen Blick auf die möglicherweise vertraulichen Informationen werfen.
Die EBICS-Gesellschaft sollte sich deshalb beim XML für den HVT eine Erweiterung überlegen, mit der künftig auch diese wichtigen Informationen für die Art der Zahlung übermittelt werden. Solange dies nicht geschieht, lässt sich die VEU für Gehaltszahlungen nur eingeschränkt nutzen.

Autor: Michael Schunk

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