Posts mit dem Label EBICS-Bankrechner werden angezeigt. Alle Posts anzeigen
Posts mit dem Label EBICS-Bankrechner 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

Mehr Komfort für EBICS-Kunden

Wenn es darum geht den Komfort für Firmenkunden zu erhöhen, die das EBICS-Protokoll nutzen, gilt es einige Hürden zu bewältigen. Die erste Herausforderung ist die Konfiguration der Kommunikationsparameter, um einen gewünschten EBICS-Bankrechner zu erreichen, die nächste ist der komplizierte Austausch der EBICS-Schlüssel per INI-Brief und Bankschlüsselfreischaltung.

Wenn wir als Kundenprodukthersteller für die erste Aufgabe, also die Konfiguration der Kommunikationsparameter, von Seiten der EBICS-Gesellschaft eine Hilfestellung bekommen könnten, wären wir schnell in der Lage die zweite Aufgabe, den Prozess zum Austausch der Schlüssel, für die Nutzer des EBICS-Protokolls sehr komfortabel zu gestalten.  

Und dieses Szenario ließe sich schnell umsetzen, indem die EBICS-Gesellschaft eine Liste aller EBICS-Banken, deren technischen Zugang und Host-ID und den zuletzt bekannten Bankschlüssel als Hashwert an die berechtigten, registrierten Hersteller liefert. Dann könnten die Kundenprodukthersteller die bereitgestellten Werte in ihre EBICS-Kundenanwendungen integrieren und die Konfiguration des technischen EBICS-Zugangs für den Nutzer erheblich vereinfachen. Eingabefehler auf Nutzerseite mit langwierigen Supportanfragen gehörten der Vergangenheit an und der Anwender hätte eine Hürde weniger zu nehmen, wenn es um die Nutzung von EBICS geht.

Mit den bereitgestellten Daten der EBICS-Gesellschaft ließe sich auch die Verifikation der Bankschlüssel in Kundenprodukten vereinfachen. Damit würde sich der komplizierte Vorgang der EBICS-Schlüsseleinreichung und die Prüfung der Bankschlüssel auf ein Minimum reduzieren. Ja, es ist denkbar, dass dann Kunden in wenigen Minuten eine Freischaltung bekämen und sofort mit der EBICS-Kommunikation beginnen könnten. Der Aufwand für die Aktivierung des EBICS-Zugangs wäre dann vergleichbar mit der Aktivierung des Online-Bankings für den Privatkunden.
Liebe EBICS-Gesellschaft, wie wäre es mit einer EBICS-Bankenliste? So wie sie die DK in ähnlicher Form schon seit Jahren für FinTS-Bankrechner zur Verfügung stellt?  

Autor: Michael Schunk

EBICS 3.0 – ein Satz an Parametern anstelle der Auftragsart. Was ist bei der Identifikation der Geschäftsvorfälle zu berücksichtigen?

Mit EBICS 3.0 werden die unterschiedlichen Geschäftsvorfälle bekanntlich nicht mehr über Auftragsarten abgebildet, sondern über die neuen BTF-Parameter.
Für die Nutzung von Kundenverträgen mit EBICS-Clients verschiedener EBICS-Versionen in Kombination mit EBICS 3.0 wurden von den nationalen Spezifikationsgremien eigens Mappingregeln entwickelt. Diese orientieren sich i. d. R. an den fünf BTF-Parametern Service Name, Service Scope, Service Option, Service Message Name und Service Container. Wichtig ist, dass die Kombination dieser BTF-Parameter im EBICS-Bankrechner eindeutig sein muss. Dadurch wird sichergestellt, dass eine Auftragsart dem Geschäftsvorfall über BTF zugeordnet werden kann und umgekehrt.

In der Praxis können heute zu einer Auftragsart fachlich identische Aufträge eines bestimmten Formats in verschiedenen Formatversionen erstellt und beim Bankrechner eingereicht werden. Auch wenn es regelmäßig über die Spezifikationsgremien zu Formatanpassungen kommt, hängt die vom Clientsystem genutzte Formatversion auch vom Softwarestand der Clientlösung ab. Da die Formatversion für den Anwender in den Clients transparent sein dürfte, hat er bei der Zusammenstellung seiner Auftragsdatei keinen Einfluss auf die Einreichung in einer bestimmten Formatversion. Zudem akzeptieren Banken heutzutage i. d. R. unterschiedliche Formatversionen eines Geschäftsvorfalls. Letztendlich kann für die bankseitige Verarbeitung die jeweilige Formatversion zumindest bei XML-Formaten auch aus dem Namespace der XML-Datei ausgelesen werden. Bankrechner sind bisher flexibel für verschiedene Formatversionen ausgelegt.

Die weiteren nutzbaren BTF-Parameter in EBICS 3.0 sind Service Message Name Format, Service Message Name Variant und Service Message Name Version. Sollte ein Finanzinstitut auch diese weiteren Parameter in die Auftragsartmappings und Vereinbarungsdetails mit dem Kunden aufnehmen, so sollte einiges beachtet werden. Falls nicht bereits bisher über FileFormat-Parameter intensiver genutzt oder aus verarbeitungstechnischen Gründen notwendig, sollten diese weiteren Parameter bankseitig bei EBICS-Prüfungen eher dosiert berücksichtigt werden.

Letztendlich sind diese zusätzlichen Parameterinformationen bereits Inhalt der Auftragsdatei selbst und ohnehin daraus auslesbar. Was ist zu tun bei sich widersprechenden Angaben? Außerdem bedeutet die zusätzliche Pflege im Bankrechner mehr Aufwand bei der Stammdatenpflege. Es müsste ja für jede Formatversion eines Geschäftsvorfalls eine eigene Kundenvereinbarung geben. Erschwerend kommt hinzu, dass diese Formatdetails für den Kunden in der Clientsoftware transparent sind und er diese z. T. nicht steuern kann.

Was würde passieren, wenn z. B. der Bankrechner bei einer Einreichung die Versionen 03 und 04 eines XML-Formats unterstützt, der Kunde aber für die Einreichung eines Formats der Version 03 stattdessen die Version 04 in den BTF einstellt? Bei der Versionsberücksichtigung würde der Auftrag abgelehnt, obwohl das Banksystem die Formatversion verarbeiten könnte. Die tatsächliche Version ist ja am Namespace erkennbar.

Noch komplizierter wird es mit den Auslieferungen. Hier müsste die Auslieferung zum Abholzeitpunkt synchron in der angefragten Version erzeugt und als Datei ausgegeben werden. Gleiches gilt dann auch für historische Abholungen.

Fazit: Man sollte als Finanzinstitut nicht zu restriktiv sein bei den Definitionen der BTF-Vereinbarungen mit dem Kunden. So ist man als Finanzinstitut flexibler und spart sich Mehraufwand in der Vertrags- und Stammdatenpflege.


Autor: Michael Lembcke

Formatfehler bei EBICS-Aufträgen – Testservices können helfen

EBICS wurde speziell für den sicheren und performanten Datenaustausch von Dateien beliebiger Größe im Banken-Firmenkundengeschäft konzipiert. Für Zahlungsverkehrsaufträge gilt, dass eine Datei, die zum EBICS- Server hochgeladen wird, inhaltlich stets dem definierten Geschäftsvorfall (Auftragsart, FileFormat-Parameter oder BTF) und den dafür spezifizierten Formatvorgaben entsprechen muss. Bei Zahlungsverkehrseinreichungen sind Sammeldateien mit Einzeltransaktionen, die nach Auftraggeberkonten gruppiert sind, gängige Praxis. Die Protokollierung (HAC und PTK) der serverseitigen EBICS-Vorgänge ist für Zahlungsverkehrsaufträge z. T. formatspezifisch. Die Berechtigungsprüfungen und die Protokollierung erfordern es daher, dass der EBICS-Bankrechner das Einreichungsformat zumindest in den relevanten Stellen kennt und auslesen kann (z. B. Auftraggeberkonto und Betrag). Zum Auslesen der Informationen führt der EBICS-Bankrechner eine Formatprüfung durch. Bereits bei dem ersten erkannten Formatfehler bricht der EBICS-Bankrechner üblicherweise die Prüfung ab. Der Auftrag wird mit Formatfehler abgelehnt und im Kundenprotokoll dokumentiert.

Weshalb wird keine vollständige Prüfung der Datei durchgeführt, und weshalb werden die Fehlerdetails nicht ins Kundenprotokoll geschrieben?

Dafür gibt es verschiedene Gründe. Zunächst umfasst die übliche Servicevereinbarung für das E-Banking per EBICS die Einreichung und zügige Verarbeitung von korrekten Dateien. Eine umfangreiche Formatverifikation mit Fehlerprotokoll ist nicht inbegriffen und auch nicht Kernaufgabe eines EBICS-Bankrechners. Zudem sollen die Bankrechnerkapazitäten für die unverzügliche Abarbeitung formatkonformer Aufträge genutzt werden und nicht für die Analyse von ohnehin fehlerhaften Dateien.

Wie aber kann eine Bank ihren Firmenkunden einen Service anbieten, der die Qualität von Zahlungsverkehrsaufträgen in Bezug auf Format und Fachlichkeit steigert, ohne dabei den EBICS-Bankrechner unnötig zu belasten?

Dafür könnten Kunden Testservices wie die ISO-20022-Testplattform nutzen. Im Rahmen der Harmonisierung des Schweizer Zahlungsverkehrs bieten bereits heute Schweizer Banken ihren Kunden eine Testplattform zum Test von Ein- und Auslieferungsformaten des Zahlungsverkehrs an.
Die Testplattform ahmt die spezifische Produktion der Bank nach. Mit der Testplattform können unter anderem XML-basierte Kunde-Bank-Meldungen validiert und die Schnittstelle Bank-an-Kunde simuliert werden.

Eine Erweiterung der ISO-20022-Testplattform um die Prüfung von Zahlungsverkehrsaufträgen auf spezifizierte Formatvorgaben und Fachlichkeit kann die Qualität der Datei noch erheblich verbessern. Durch eine im Voraus durchgeführte umfassende Formatverifikation von Zahlungsverkehrsaufträgen können Fehler mithilfe eines detaillierten Fehlerprotokolls schnell und einfach identifiziert werden.
Dateien, die hinsichtlich Format und Fachlichkeit nicht korrekt sind, können so schon in einer Vorabprüfung durch einen Testservice erkannt und korrigiert werden, bevor sie zum EBICS-Server hochgeladen werden.


Autoren: Aline Wendler und Michael Lembcke

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