EBICS und die Echtzeitbenachrichtigungen - Eine Bestandsaufnahme

 

Mittlerweile ist es schon mehr als zwei Jahre her, dass die Spezifikation „Echtzeitbenachrichtigungen“  auf der EBICS Webseite www.ebics.de veröffentlicht wurde. In einem Blogbeitrag vom Oktober 2019  hatte ich mich bereits dieses Themas angenommen. Doch was ist daraus eigentlich geworden? Und wie hat sich der Einsatz in der Praxis entwickelt?

Tatsächlich wurde die neue Schnittstelle für Echtzeitbenachrichtigungen von einigen Instituten in Deutschland im EBICS-Bankrechner implementiert und ist mittlerweile bei diesen produktiv im Einsatz. Natürlich macht der damit verbundene neue Funktionsumfang nur Sinn, wenn es EBICS-Clients gibt, die diese Schnittstelle nutzen. Unter Umständen wurde in von Banken betriebenen Firmenkundenportalen daher diese Schnittstelle ebenfalls clientseitig implementiert.

Wir erinnern uns. Der Mehrwert dieser neuen Schnittstelle liegt in der potenziell schnelleren Rückmeldung bei SEPA Instant Payments im EBICS-Kanal sowie generell bei der Einsparung von Hoffnungsabfragen zu Downloaddaten. Wo stehen wir damit?

Einige Kreditinstitute in Deutschland haben das Konzept umgesetzt. Jedoch nicht jedes Kreditinstitut ist heute in der Lage, diesen neuen Service anzubieten. Unter Umständen ist es bankseitig für EBICS auch nicht oder noch nicht im Fokus. Neben der neuen Schnittstelle zur Echtzeitbenachrichtigung in Richtung Kunde ist nämlich auch die zeitnahe Bereitstellung der Downloaddaten im Bankrechner eine der Voraussetzungen, um Kunden einen Mehrwert für EBICS bieten zu können. Diese kontinuierliche und zeitnahe Bereitstellung aus den Backendsystemen heraus für den EBICS-Kanal muss dafür bei den Kreditinstituten zur Verfügung stehen.

Kundenseitig ist die Push-Benachrichtigung insbesondere für Firmenkunden von Interesse, bei denen die Aktualität und die Nähe zur Echtzeit zunehmend relevant ist. Diese EBICS-Kunden haben die Echtzeitbenachrichtigung auf der Clientseite zum Teil bereits implementiert. Andere, die z. B. ein geeignetes Firmenkundenportal des Kreditinstituts nutzen, kommen ggf. auch ohne eigenes Zutun in den Genuss des neuen Services. Dennoch verfügt nicht jeder EBICS-Client über die neue Websocket-Schnittstelle zur Echtzeitbenachrichtigung.

Fazit ist, dass die Funktion der Echtzeitbenachrichtigung im Jahr 2022 noch nicht in der Breite bei den EBICS-Kunden angekommen ist. Bisher sind es gerade spezialisierte Firmenkunden und institutionelle EBICS-Kunden, die auf Echtzeitbenachrichtigung im EBICS-Kanal setzen. Für sie stellt die Echtzeit in den Zahlungsverkehrsprozessen einen besonderen Mehrwert dar, für den sich auch die eine oder andere Investition lohnt. Die Kreditinstitute dieser Kunden bieten den passenden Service an.

Wir sehen, dass generell das Thema Echtzeit im Zahlungsverkehr noch Wachstumspotenzial hat. Somit ist davon auszugehen, dass auch das Thema Echtzeitbenachrichtigung in Verbindung mit EBICS noch an Bedeutung gewinnen wird. Bleiben wir also gespannt!

Autor: Michael Lembcke

Weiterlesen

Tipps für einen reibungslosen Übergang zu EBICS 3.0

EBICS 3.0 ist seit November 2021 offiziell bei den Banken eingeführt und kann von Firmenkunden genutzt werden. Daneben ist die letzte Vorgängerversion weiterhin gültig. Eine der Änderungen in EBICS 3.0 betrifft den Wegfall der dreistelligen Auftragsarten bzw. der FileFormat-Parameter in Frankreich für operative Geschäftsvorfälle. Diese werden nun über die sogenannten Business Transaction Formats (BTF) abgebildet. BTFs umfassen jeweils acht Parameter: Service Name, Service Scope, Service Option, Service Message Name, Service Message Name Version, Service Message Name Format, Service Message Name Variant und Service Container.

Innerhalb einer Kundenvereinbarung muss unabhängig von der EBICS-Version die zentrale Vereinbarung für den jeweiligen Geschäftsvorfall berücksichtigt werden können. Die Kompatibilität und Interoperabilität zwischen den Vorgängerversionen sind für EBICS vorgegeben. Wenn zwei elektronische Unterschriften für eine SEPA-Überweisung vereinbart sind, ist es beispielsweise irrelevant, ob Einreichungen hierzu per BTF oder Auftragsart bzw. FileFormat-Parameter erfolgen. Diese Bedingung erfordert ein internes Mapping alter und neuer Geschäftsvorfälle im Bankrechner und ggf. auch in Client-Systemen. Bisher sind für die Standardgeschäftsvorfälle diese Mappings offiziell spezifiziert.

Die dem EBICS vor- und nachgelagerten Verarbeitungen bei den Kreditinstituten und bei den Firmenkunden orientieren sich i. d. R. noch an den bisherigen EBICS-IDs, wie den dreistelligen Auftragsarten und in Frankreich an den bis zu 40-stelligen FileFormat-Parametern. Solange ein Mapping existiert, besteht aber auch keine Notwendigkeit daran etwas zu ändern. Was ist jedoch, wenn für einen Geschäftsvorfall keine Auftragsarten/FileFormat-Parametern mehr spezifiziert sind und die Geschäftsvorfälle ausschließlich mit BTF gelten? Will man seine angrenzenden Verarbeitungsprozesse nicht an die BTF anpassen, kann man natürlich ein Mapping beibehalten. Für die nicht spezifizierten Mappings sollte man dann allerdings individuelle, passende IDs festlegen.

Im Außenverhältnis in der Kunde-Bank-Beziehung sollte man beachten, dass dem Kunden bzw. Client-System die Vorgaben des Bankrechners hinsichtlich Geschäftsvorfällen und Mappings auf verschiedenen Wegen mitgeteilt werden. Dabei kommen zudem die unterschiedlichen Darstellungen aus Sicht des Kunden, Teilnehmers und Zeitpunkts zum Tragen. Ein Teilnehmer nutzt immer eine konkrete EBICS-Version, während die Kundenvereinbarung alle gültigen Versionen abbilden muss. Außerdem spielt der Zeitpunkt der Information eine Rolle. So ist vor der Initialisierung des Teilnehmers dem Kreditinstitut i. d. R. nicht bekannt, welche EBICS-Version dieser nutzen wird.

Das BPD-Blatt (BPD=Bankparameterdaten), das bei der Einrichtung des Teilnehmers auf dem Bankrechner angelegt wird, muss daher die Optionen aller unterstützten EBICS-Versionen inkl. evtl. BTF-Mapping-Vorgaben abbilden. Gleiches gilt zumindest auch für die Auftragsart HKD, mit der die Vereinbarungen auf Kundenebene vom Client abgerufen werden können. Wird bei bestimmten Geschäftsvorfällen in der Kunde-Bank-Beziehung ungeachtet der internen Nutzung kein Mapping mehr angeboten, so sollte die jeweilige Information  das Mapping entsprechend ausschließlich per BTF abbilden. Für die interne Administration und Pflege ist es hilfreich, wenn bei einem internen Mapping die ausschließlich intern genutzten individuellen IDs sichtbar sind (z. B. individuelle Auftragsarten mit eigenem BTF-Mapping), aber sich von den externen IDs unterscheiden.

Zusammenfassend lässt sich sagen, dass die Herausforderung darin besteht, bei der neuen Vielfalt an Informationen den Übergang zu EBICS 3.0 für alle Beteiligten so leicht wie möglich zu machen. Mit der richtigen Konfiguration und unter Beachtung einiger Maßgaben bei der Bedienung, ist der Umstieg auf die neue EBICS-Version allerdings gar nicht so schwierig. Sollten Sie Hilfe beim Umstieg auf EBICS 3.0 benötigen oder Fragen dazu haben, sprechen Sie uns gern an.

Autor: Michael Lembcke

Weiterlesen

EBICS 3.0 auf der Zielgeraden

Spätestens zum 22. November dieses Jahres ist es so weit. Von diesem Tag an sind deutsche Zahlungsverkehrsdienstleister verpflichtet, ihren Firmenkunden EBICS 3.0, genau genommen EBICS 3.0.1, parallel zur bisherigen Version 2.5 anzubieten. Für die Schweiz hat die SIX ebenfalls eine Empfehlung für die Unterstützung von EBICS 3.0 ab November 2021 abgegeben, und in Frankreich kann EBICS 3.0 bereits seit Januar 2018 offiziell von Finanzdienstleistern angeboten werden.
Die Deutsche Bundesbank hat angekündigt, ab dem 22. November 2021 für eine Übergangszeit von einem Jahr vollständig auf EBICS 3.0 umzustellen. Ähnlich positioniert sich die EBA Clearing bei ihren EBICS Diensten.

Was bedeutet die EBICS-Umstellung nun für alle EBICS-Beteiligten?

Banken und Finanzdienstleister rüsten sich für November 2021. EBICS-3.0-fähige Systeme sind hier bereits in vielen Fällen im Einsatz. Eventuell ist EBICS 3.0 lediglich noch nicht für die Nutzung freigeschaltet.

Für die Übergangszeit von EBICS 2.x auf EBICS 3.0 müssen auf Seiten der Bank- und Firmenkunden die spezifizierten bzw. vereinbarten BTF- und Auftragsarten-Mappings hinterlegt sein. Diese können später einmal entfallen, wenn für neue EBICS Geschäftsvorfälle in Zukunft keine Auftragsarten bzw. FileFormat-Parameter mehr spezifiziert werden. 

Alle Parteien sollten bereits vor der Migration auf EBICS 3.0 den Crypto LifeCycle (siehe Crypto LifeCycle auf www.ebics.de) für EBICS berücksichtigen. Damit verbunden sind Mindestschlüssellängen, Schlüsselverfahren und TLS-Vorgaben, die erfüllt sein müssen. EBICS 2.3 ist durch die darin definierten Schlüsselverfahren automatisch ab dem 22. November hinfällig.
All das setzt aktuelle EBICS-Software voraus. Firmenkunden sollten sich daher frühzeitig um ein EBICS-3.0-Update ihrer EBICS-Clients kümmern, um so auf die EBICS-Umstellung der Banken reagieren zu können. Um eine aufwändige Neuinitialisierung zu vermeiden, sollten bereits vor der bankseitigen Abschaltung von Schlüsselverfahren und -längen sowie EBICS-Versionen clientseitig entsprechende EBICS- und Schlüssel-Updates abgeschlossen sein.  Die Schlüssel-Updates sind u. U. Voraussetzung für die Migration auf EBICS 3.0.

Da für EBICS 3.0 das textbasierte Kundenprotokoll (Auftragsart PTK) nicht mehr spezifiziert ist, kann es sein, dass Banken dieses für EBICS 3.0 nicht mehr anbieten. Sollte das Kundenprotokoll-Monitoring von Firmenkunden noch auf dem PTK basieren, ist für diese eine frühzeitige Umstellung auf das XML-basierte HAC zu empfehlen.

Firmenkunden können sich zudem über ein paar neue Funktionen freuen, die ihnen EBICS 3.0 jetzt bietet. Dazu zählen u.a. die technische Doppeleinreicherkontrolle, die optionale Angabe des Originaldateinamens beim Upload und das VEU-Flag (VEU= Verteilte Elektronische Unterschrift), mit dem der Firmenkunde direkt steuern kann, ob sein eingereichter Auftrag in den VEU-Prozess laufen soll oder direkt zu prüfen ist. 

So viel zu einigen relevanten Punkten, die ich für einen erfolgreichen Zieleinlauf mit auf den Weg geben möchte. Letztlich gilt es, auf die nahende EBICS-Umstellung vorbereitet zu sein und die notwendigen Vorkehrungen zu treffen.

Und wie sieht es bei Ihnen aus? Haben Sie auch schon den Zielspurt zu EBICS 3.0 eingeleitet?

Autor: Michael Lembcke

Weiterlesen

EBICS als SaaS – EBICS in der Cloud

Ob bei Banken, Firmenkunden, Zahlungsdienstleistern oder Internetdienstanbietern: In all diesen Bereichen kommt heute in Europa EBICS zum Einsatz. Warum ist das so? Zum einen ist EBICS auf die im Firmenkundengeschäft üblichen Massenzahlungen ausgerichtet, zum anderen ist EBICS als eBanking-Standard in Europa etabliert. 

 

Ich benötige EBICS-Connectivity – muss ich EBICS selbst betreiben? 

All die EBICS-Markteilnehmer haben eines gemeinsam: Ihr Kerngeschäft liegt i.d.R. eben nicht primär im Betrieb und in der Abwicklung der EBICS-Kommunikation, sondern z. B. im Angebot und Verkauf der Bankprodukte, den Zahlungsverkehrsdienstleistungen und dem Internetgeschäft. Die Kommunikation muss funktionieren, und dabei will man sich auf einen Standard verlassen, um nicht mit jedem Partner eigene Verbindungslösungen aufbauen und unterhalten zu müssen.  
Damit man sich voll auf das Kerngeschäft konzentrieren kann, könnte es interessant sein, über das Konzept „Software as a Service“ für alle Leistungen rund um EBICS nachzudenken. So gibt es auch verschiedene Ansätze, EBICS-Services in der Cloud betreiben zu lassen. Servicenehmer könnten unter Umständen einiges an Kosten einsparen und so von einer höheren Flexibilität profitieren, da sich eine EBICS-Lösung schneller einführen lässt und zudem leichter erweitert oder reduziert werden kann.   
Gerade Banken mit einer kleineren Anzahl von potenziellen EBICS-Kunden scheuen die hohen Initialkosten, um einen EBICS-Bankrechner zu installieren und selbst zu betreiben. Lohnt sich dieser Aufwand und dessen Kosten für die anfänglich wenigen, vielleicht 50 – 100 Firmenkunden?

EBICS in der Cloud

Warum also den Service selbst betreiben? Weshalb nicht einen Dienstleister beauftragen, der das EBICS-Geschäft schon von Anfang an begleitet und damit in all seinen Facetten beherrscht?
Einen kompletten EBICS-Bankrechner als Service günstig einkaufen, das wäre es doch. Am besten dazu dann gleich auch das Web-basierte Firmenkundenportal, damit die Kunden schnell und ohne viel Aufwand in den Genuss des neuen Service kommen. Sowohl die Banken als auch die Firmenkunden können diese Services dann nutzen.

EBICS ist kein Service, bei dem es nur um einen entscheidenden Vorteil im Wettbewerb mit anderen Banken geht. Ein Angebot von EBICS und den entsprechenden Services des Zahlungsverkehrs gehört zum „Must-have“ einer Bank. Also warum sich nicht mit anderen die Initialkosten teilen und einen günstigeren Service in der Cloud nutzen?

EBICS in der Cloud: Vielleicht eine lohnende Handlungsoption. Oder?

Autor: Michael Lembcke

Weiterlesen

Neue Datenformate und die Notwendigkeit eines EBICS-Updates für die Schweiz – Was ist zu beachten?

Mit der SIX-Publikation Swiss Market Practice Guidelines EBICS für EBICS V3.0 vom Juni 2020, die die Empfehlungen für die Umsetzung des EBICS-Standards für den Finanzplatz Schweiz enthält, zieht nun auch die Schweiz nach und passt den Standard an das europäisch harmonisierte Protokoll an. Haupttreiber der Harmonisierung waren die Mitglieder der EBICS-Gesellschaft, namentlich die Finanzplätze Deutschland, Frankreich und die Schweiz (neuestes Mitglied ist Österreich).

Per Definition werden auch in der Schweiz jeweils zwei Versionen von EBICS unterstützt, d. h. in Zukunft die Version 2.5 und die Version 3.0. Somit könnte man auf den ersten Blick meinen, dass seitens der Kunden und Softwarehersteller kein akuter Handlungsbedarf besteht, da die bisherige Version ja noch angeboten wird. Gäbe es in der Schweiz da nicht diesen Absatz 2.2.1 EBICS Timeline im SIX-Dokument mit folgendem Hinweis: „Für die Unterstützung der ISO 20022 Schema-Migration auf die Version 2019 ist die Verwendung von EBICS 3.0 erforderlich.“

Wie gut informierte Fachleute wissen, soll die ISO-Version 2019 ab 2022 auch in der Kunde-Bank-Schnittstelle eingeführt werden. Per 2024 sollen dann die aktuellen Versionen nicht mehr unterstützt werden. Dies entspricht dem Trend der globalen Migration auf diese neue Version, z. B. in den Vorhaben SEPA-, SWIFT MX- oder der TARGET2-Migration. Nicht zuletzt auch vor dem Hintergrund der geplanten Einführung von Instant Payments in der Schweiz per 2023 ist diese Migration von grosser Wichtigkeit.

Der Finanzplatz Schweiz hat sich also entschieden, den Upgrade der EBICS-Version mit dem Upgrade der ISO-Version zu verknüpfen. Für Kunden und Softwarehersteller ergeben sich vor diesem Hintergrund ein paar Fragen und auch nicht zu unterschätzende Herausforderungen. Die wichtigsten Punkte werden in den nachfolgenden Absätzen beleuchtet, und es werden – wo immer möglich – auch gleich Lösungsansätze aufgezeigt.

EBICS 3.0 spätestens ab November 2021 auch in der Schweiz 

Die EBICS-Kommunikation hat sich in der Schweiz mittlerweile voll etabliert und ist aus dem Finanzsektor nicht mehr wegzudenken. Bisher wird die EBICS-Version 2.5 von der Mehrheit der Finanzinstitute in der Schweiz angeboten.

Wie bereits eingangs erwähnt, wird mit den Empfehlungen für die Umsetzung des EBICS-Standards für den Finanzplatz Schweiz (Version 1.0 vom 01.06.2020 der SIX, www.six-group.com) die neuere EBICS-Version 3.0 in der Schweiz ab November 2021 offiziell für das Firmenkundengeschäft mit Finanzinstituten eingeführt.

Festlegungen der Schweiz für den Umgang mit den neuen Geschäftsvorfällen in EBICS

Mit der Einführung der neuen Version V3.0 soll die Vorgängerversion EBICS 2.5 dann noch bis Ende 2024 offiziell von Finanzinstituten unterstützt werden. Zudem wird für die Entgegennahme der neuen Schweizer ISO20022-Formate in der Version 2019 EBICS 3.0 vorausgesetzt. Dies bedeutet für Firmenkunden, dass jeder, der seine Schweizer ISO-Formate einmal aktualisiert hat, nicht mehr ohne Weiteres noch EBICS 2.5 dafür nutzen kann.

Es ist an der Zeit, zu planen

Diese anstehenden Aktualisierungen erfordern es, rechtzeitig eine Anpassung der Softwarelösungen einzuplanen und vorzunehmen. Hier sind die Finanzinstitute, Firmenkunden und Softwarehersteller gefragt.

Die Aktualisierung der ISO20022-Datenformate auf die Version 2019 ist da nur eine Sache. Nicht zu unterschätzen sind jedoch die Änderungen des EBICS-Protokolls, die mit der Version 3.0 umzusetzen sind. Die wichtigsten Anforderungen sind:

• Das neue Business Transaction Format (BTF) löst die bisherigen Auftragsarten und Fileformat-Parameter ab.
• Der Transport der öffentlichen Schlüssel erfolgt einheitlich jetzt mit Zertifikaten.
• Die kryptografischen Verfahren sind verbessert.
• Der Umgang mit Bankschlüsseln ist verbessert.
• Es gibt zusätzliche Steuerungsparameter zur elektronischen Unterschrift.
• Eine Prüfung auf Doppeleinreichung findet auf Dateiebene statt.
  

Wie also mit diesen neuen Anforderungen umgehen?

Nicht nur die Banken, auch die Softwarehersteller von EBICS-Clients, haben die Aufgabe, ihre Softwarelösungen um EBICS 3.0 zu erweitern, so dass die Firmenkunden frühzeitig Updates durchführen und produktiv setzen können.

Es müssen alle Besonderheiten von EBICS 3.0 im Client berücksichtigt sein, und u. U. muss ein Mischbetrieb von unterschiedlichen EBICS-Versionen je nach Bankzugang und EBICS-Usern möglich sein. Zudem sollten dem Anwender unterstützende Migrationsoptionen für die EBICS-Umstellung angeboten werden, die nach Möglichkeit eine erneute Initialisierung vermeiden (Stichwort Erhöhung von Minimal-Schlüssellängen).

Die EBICS-API – Entkopplung von Fachlichkeit und Technik

Aus eigener Erfahrung wissen wir, dass die Migration auf die Version 3.0 nicht einfach ein Mapping von Auftragsarten zu BTF-Kombinationen darstellt. Es gibt viele weitere Knackpunkte zu lösen, respektive neu zu programmieren. Insbesondere, wenn die Bank, der Softwarehersteller und der Kunde diese Migration möglichst automatisiert durchführen möchten. PPI bietet schon seit Jahren den TRAVIC-EBICS-Kernel, eine API-Lösung für die Integration in eigene EBICS-Clients, an. Dieser ist in Europa bei fast jeder zweiten EBICS-Client-Software der zentrale Baustein für die Abwicklung der EBICS-Kommunikation.

Mit der aktuellsten Version sind natürlich auch die neuen Spezifika rund um EBICS 3.0 bereits implementiert. Richtig angebunden, wickelt die API das eBanking für den Client transparent in all seinen Ausprägungen und Versionen ab. TRAVIC-EBICS-Kernel entlastet somit den Softwarehersteller von eBanking- und Zahlungsverkehrsanwendungen bei der Implementierung des Standardprotokolls und deren Syntax sowie bei Sicherheitsverfahren. Diese Lösung bildet die EBICS-Spezifikation vollständig ab und bietet eine einfach zu integrierende Schnittstelle, die Softwarehersteller als komfortablen und schnell nutzbaren Kommunikationsbaustein in ihre Softwareprodukte einbinden können.

Betrachtet man das Aufwand-/Ertragsverhältnis bei der Integration des TRAVIC-EBICS-Kernels, ist es nicht verwunderlich, dass dieses Produkt so ein Bestseller ist. Softwarehersteller, welche nicht den Kernel einsetzen, können sich jederzeit mit uns in Verbindung setzen und den Erhalt einer Testlizenz anfragen. Der Zeitpunkt dazu war noch nie so gut wie vor der bevorstehenden Umstellung auf EBICS 3.0.

Autoren: Carsten Miehling und Michael Lembcke

Mehr Informationen:
Webseite: EBICS 3.0 | challenge accepted

Flyer: EBICS 3.0 – Was ändert sich?

Weiterlesen

EBICS-Security – Wann ist es Zeit für das Update Ihres Kundensystems?

Mit EBICS sind verschiedene Sicherheitsfunktionen und -vorgaben spezifiziert, die von Kunden und Banken einzuhalten sind. Die Bank muss stets darauf achten, dass die aktuellen Vorgaben in ihrem EBICS-Bankrechner angeboten und unterstützt werden. Aber auch der EBICS-Kunde und der einzelne EBICS-Teilnehmer selbst sind dafür verantwortlich, stets Kundensoftware einzusetzen, die den aktuellen EBICS-Sicherheitsstandards entspricht. Daher sind nicht nur aufgrund von funktionalen Anpassungen, sondern auch aus Sicherheitsgründen regelmäßige Softwareupdates der EBICS-Clientsysteme unerlässlich.

Ist eine bestehende EBICS-Clientsoftware schließlich durch Updates auf den neuesten Stand gebracht, heißt das jedoch nicht, dass diese EBICS-Software dann auch automatisch über die aktuellste EBICS-Version und das neueste Sicherheitsverfahren mit der Bank kommuniziert. Je nach zuvor genutzter EBICS-Version und Clientfunktionalität müssen dazu erst noch die verschiedenen Applikationsschlüssel für Verschlüsselung (E002), Authentifikation (X002) und Autorisierung (A004, A005 oder A006) sowie die neu zu nutzende EBICS-Version aktualisiert und mit dem oder den EBICS-Bankrechnern ausgetauscht werden. Zudem könnte es erforderlich sein, die Internetverschlüsselung (TLS) durch einen neuen Zertifikatsaustausch auf eine neuere und sichere Version zu aktualisieren. Diese Art von Aktualisierungen erfordern i.d.R. aktives Handeln und manuelle Eingriffe des EBICS-Teilnehmers.

Warum sind diese Aktualisierungen wichtig?

Für die EBICS-Kommunikation über das Internet sind eigene Sicherheitsverfahren spezifiziert. Diese werden von der EBICS-Gesellschaft im Laufe der Zeit mit neuen EBICS-Versionen immer wieder aktualisiert und an die aktuellen Sicherheitsbedürfnisse angepasst. Ein Beispiel stellen die Schlüssellängen dar. So sind für die Verschlüsselung (E002), Authentifikation (X002) und Autorisierung (A004, A005 oder A006) in älteren EBICS-Versionen noch Schlüssellängen von 1.024 Bit zulässig. Diese Länge entspricht nicht mehr den aktuellen Sicherheitsanforderungen, denn zu kurze Schlüssel gelten als unsicher. Neuere EBICS-Versionen hingegen lassen derzeit nur Schlüssel mit einer Mindestlänge von 2.048 Bit zu. Ein anderes Beispiel sehen wir bei den genutzten Verfahren und Versionen der TLS-Verschlüsselung. Um Sicherheitsempfehlungen, wie z. B. den Empfehlungen des BSI in Deutschland flexibler folgen zu können, hat die EBICS-Gesellschaft für EBICS 3.0 die entsprechenden Vorgaben in einem eigenen Anhang Transport Layer Security zur Spezifikation ausgelagert. Da rückwirkend die Spezifikation zu EBICS 2.5 nicht angepasst werden konnte, hat die DK (Die Deutsche Kreditwirtschaft) 2019 unter dem Titel Empfehlungen zu EBICS-Sicherheitsverfahren und Schlüssellängen zudem ein eigenes Empfehlungsschreiben zu den in EBICS zu nutzenden Sicherheitsverfahren herausgegeben. Siehe hierzu auch www.ebics.de und www.ebics.org.

Um den EBICS-Teilnehmern einen weichen Umstieg auf neuere EBICS-Versionen und Sicherheitsstandards zu ermöglichen, bieten die meisten Banken ihren Kunden jedoch parallel noch die älteren Verfahren an. Leider lässt sich feststellen, dass von Kunden dann aber die Gelegenheit zur EBICS-Aktualisierung in vielen Fällen nicht genutzt wird. Viele verharren auf älteren Systemen und Verfahren. Damit fällt es dann wiederum den Banken, schwer die alten Verfahren abzuschalten.
Am Ende erwartet jeder Beteiligte in der EBICS-Kommunikation, dass ein sicherer Datenaustausch gegeben ist. Einen Schaden möchte niemand erleiden. Also sollte auch jeder dafür Sorge tragen, dass er seinen Teil dazu beträgt. Natürlich ist die EBICS-Sicherheit nicht das Einzige, was Banken und Firmenkunden im Auge halten müssen. Letztendlich müssen heutzutage alle Beteiligten in ihrer Infrastruktur und ihren Softwarelösungen alle erdenklichen Sicherheitsmaßnahmen ergreifen, um Missbrauch und Schaden vorzubeugen.

Also warum noch warten? Gehen wir es an.

Autor: Michael Lembcke

Weiterlesen

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

Weiterlesen

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

Weiterlesen

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

Weiterlesen

Sie sind Bankkunde und nutzen EBICS: Funktioniert Ihr EBICS-Monitoring auch noch mit EBICS 3.0?

Für das Monitoring der EBICS-Prozesse und -Ergebnisse steht seit EBICS 2.5 den EBICS-Clients neben dem rein textbasierten Kundenprotokoll auch ein XML-basiertes Protokoll für das fachliche EBICS-Monitoring zur Verfügung. Letzteres eignet sich insbesondere für maschinelle Auswertungen. Das textbasierte Protokoll kann durch den EBICS-Client mit der Auftragsart PTK und das XML-basierte Protokoll mit der Auftragsart HAC vom EBICS-Server heruntergeladen werden. Mit EBICS-Version 3.0 ist das textbasierte Protokoll nicht mehr Bestandteil der Spezifikation. Zudem gibt es Änderungen im HAC-Protokoll, die bei der maschinellen Ergebnisauswertung zu berücksichtigen sind. Diese Änderungen wirken sich wegen der erforderlichen übergreifenden Versionsinteroperabilität z. T. auch auf EBICS-Clients niedriger EBICS-Versionen aus, sobald ein EBICS-Bankrechner EBICS Version 3.0 unterstützt.

Für Software-Hersteller und EBICS-Nutzer gilt daher, dass man sich bei den EBICS-Clients, die bereits über Funktionen der maschinellen Kundenprotokoll-Auswertung verfügen, auf Änderungen einstellen muss. Zunächst sollte für maschinelle Auswertungen in EBICS-Clients der Wechsel vom PTK zum HAC vollzogen werden. Außerdem gilt für diejenigen, die bereits das HAC-Protokoll nutzen, dass mit EBICS 3.0 das finale Ergebnis im HAC-Protokoll anders abgebildet wird.

Bisher informierte das HAC-Ende-Kennzeichen mit den Angaben ORDER_HAC_FINAL_POS und ORDER_HAC_FINAL_NEG direkt darüber, ob das Ergebnis der Einreichung positiv oder negativ war. Mit EBICS 3.0 gibt es lediglich noch ein HAC-Ende-Kennzeichen ORDER_HAC_FINAL, welches den Ausgang der Einreichung ausschließlich in Verbindung mit dem letzten Reason Code ausdrückt. Demnach weist dann beispielsweise der finale Code DS04 darauf hin, dass der Auftrag abgelehnt wurde und DS05, dass der Auftrag erfolgreich eingereicht und an die Banksysteme weitergeleitet wurde. Weitere Reason Codes sind zu berücksichtigen.

Also, damit Ihr EBICS-Monitoring auch weiterhin die korrekten Ergebnisse liefert, empfehle ich auf das HAC-Kundenprotokoll zu setzen und sich auf die Auswertung der Reason Codes zu konzentrieren. So behalten Sie auch zukünftig den Überblick in der EBICS-Kommunikation mit Ihrer Bank.

Michael Lembcke

 

Weiterlesen

Wie sich EBICS verbessern lässt Teil 10 – Gezielte EBICS-Downloads mit Datum und Uhrzeit

Im Zahlungsverkehr und insbesondere mit der Einführung neuer Verfahren, wie etwa den Instant Payments, wird es für den Bankenkunden immer wichtiger, auch untertägig über die Zahlungsbewegungen auf dem Laufenden gehalten zu werden. Diese Entwicklung stellt im Firmenkundengeschäft auch den EBICS-Standard vor neue Herausforderungen zumal diese Informationen üblicherweise von den EBICS-Kunden aktiv vom Bankrechner abgerufen werden müssen. Insbesondere, wenn Firmenkunden mehrere EBICS-Clients nutzen, ist die heute gängige sog. historische Abholung mit Datumsangabe die geeignete Download-Methode. Da jedoch die historische Abholung durch EBICS lediglich tagesgenau spezifiziert ist, werden die Daten in der Praxis untertägig in großem Umfang mehrfach abgeholt. Zudem hängen fachliche Zeitstempel für EBICS vom Bereitstellungsformat ab und sind damit bestenfalls tagesgenau und schlimmstenfalls auf dem Bankrechner einfach nicht vorhanden. Den abholenden Clients steht daher dann die Aufgabe zu, die redundant abgeholten Daten automatisiert zu filtern. Dieses Verhalten führt derzeit zu einer deutlichen Mehrbelastung aller beteiligten Systeme sowohl auf Seiten der Kunden, als auch auf Seiten der Banken.

Folgende Verbesserung in EBICS könnte bei entsprechender Spezifikation Abhilfe schaffen und gezielte zeitgesteuerte Abholungen erlauben.

Sinnvoll wäre es, wenn der EBICS-Server per Spezifikation eine zusätzliche Variante der historischen Abholung unterstützen würde. Im Gegensatz zur bisherigen standardisierten historischen EBICS-Abholung würde nun bei Start- und Endzeitpunkt jeweils auch die Uhrzeit berücksichtigt. Außerdem sollten sich die angegebenen Zeitpunkte immer auf den Bereitstellungszeitpunkt beziehen. Damit könnte dann der EBICS-Server alle Datensätze liefern, die innerhalb des angegebenen Zeitraums bereitgestellt wurden. Zur flexibleren Handhabung sollte es auch zulässig sein, bei Abholanfragen nur jeweils einen der beiden Zeitpunkte anzugeben. Ansonsten verhält sich die Abholung auch hinsichtlich der Quittungsphase wie die bisherige Standardabholung.

Ich denke, eine solche Lösung einheitlich für alle EBICS Nutzer im EBICS-Standard zu spezifizieren, könnte den Abholprozess für EBICS verfeinern, die Rechnerauslastung reduzieren und insbesondere im Hinblick auf die wachsende Bedeutung von Aktualität deutlich verbessern. Bisher bereits eingesetzte proprietäre Lösungen in den EBICS-Produkten wären überflüssig.

Michael Lembcke

Weiterlesen

Gleichberechtigung für EBICS – Anwendungsfall Instant Payments Bulk

Auch wenn es auf den ersten Blick merkwürdig erscheint: In Deutschland werden derzeit auch für die Kunde-Bank-Beziehung Instant-Payments-Anwendungsfälle für das dateibasierte EBICS-Transferprotokoll diskutiert und spezifiziert. Die Anwendungsfälle konzentrieren sich in diesem Fall auf das Firmenkundengeschäft. Insbesondere größere Firmenkunden haben die Anforderung, Sammeleinreichungen an die Banken übermitteln zu können. Daher hat man sich hierzu in der DK etwa für die SEPA-Credit-Transfer-Einreichung auf die spezielle Form der Sammeleinreichung von Instant Payments (Instant Payments Bulk) verständigt, basierend auf dem XML-Format ISO pain.001. Auch für die Rückrichtung der Zahlungsinformationen in der Zahlungskette – vom Empfänger beziehungsweise den Banken – werden entsprechende Geschäftsvorfälle und Formate (etwa Payment Status im Format pain.002) festgelegt. Die so spezifizierten Geschäftsvorfälle und Formatvorgaben werden in Deutschland voraussichtlich ab November 2019 offiziell gültig sein und können von Banken optional angeboten werden.

Was ist die Besonderheit von Instant Payments Bulk? 

Der Unterschied zu reinen Instant-Payments-Prozessen, die beispielsweise am „Point of Sale“ synchron ausgeführt werden, liegt im Fall Instant Payments Bulk über EBICS darin, dass die Einreichung selbst hier nicht als „instant“ gilt. Vielmehr handelt es sich um eine Einreichung zur Ausführung als Instant Payments (SCTINST). Die ausführende Bank des Einreichers zerlegt die Sammeldatei in die einzelnen Transaktionen und führt die Zahlungen als SCTINST aus, sofern der Zahlungsempfänger auf diesem Wege erreichbar ist. Erst ab diesem Zeitpunkt gelten die Bedingungen für die SCTINST. Die Daten der Rückrichtung werden dann von der Bank des Einreichers wieder auf dem EBICS-Kanal an den Einreicher zurückgeliefert. Das bedeutet konkret in diesem Fall für den Standardweg, dass die Daten von der Bank zur Abholung im EBICS-Bankrechner bereitgestellt werden. Im Firmenkundengeschäft nimmt die Bank in der für EBICS definierten Beziehung zwischen Kunde und Bank bekanntlich ausschließlich die passive Rolle ein. Eine aktive Benachrichtigung an den Sender über EBICS ist daher im Firmenkundengeschäft derzeit nicht vorgesehen.

Instant Payments Bulk weil es dringend ist? 

Firmenkunden wollen mit den neuen Geschäftsvorfällen Zahlungen gesammelt und gleichzeitig kurzfristiger einreichen. Auf diese Weise kann mit dem Geld bis zur Einreichung länger gearbeitet werden. Zudem sind die Zahlungen dann sofort garantiert und ausgeführt. Hierbei ist wie für die Empfangsseite auch für den Rückweg eine unverzügliche Benachrichtigung gewünscht. Da im EBICS-Rollenmodell derzeit eine aktive Benachrichtigung des Kunden durch die Bank nicht vorgesehen ist, werden dafür derzeit in Deutschland verschiedene Schnittstellen (APIs) und Verfahren (etwa E-Mail-Push) diskutiert. Dabei ist es eigentlich doch relativ einfach: Warum nicht das bilaterale EBICS nutzen, wie es heute bereits im Interbankenverkehr etabliert ist. Beide Parteien, Kunde und Bank, haben dabei gleichberechtigte Sende- und Empfangsrollen. Es bedarf lediglich der Erweiterung der EBICS-Kundenanwendungen um vereinfachte EBICS-Server-Funktionen. Die Firmenkunden, die Instant-Payments-Bulk-Zahlungen einreichen, könnten dann Daten aus diesen Prozessen auch aktiv empfangen. Solche Anwendungen sind sogar bereits am Markt verfügbar. Die neuen Geschäftsvorfälle sind somit vollständig über den bestehenden Standard und mit den bestehenden Lösungen umsetzbar. Zeit- und aufwandsträchtige Diskussionen über zusätzliche Schnittstellen, Protokolle und Vereinbarungen können entfallen.

Michael Lembcke

Weiterlesen

EBICS 3.0 mit BTF macht den Weg frei

Der europäische Zahlungsverkehr wächst dank SEPA und EBICS zusammen. Mit EBICS 3.0 verschmelzen nun auch die verschiedenen EBICS-Dialekte. Das Konzept dahinter heißt BTF. BTF steht für Business Transaction Format. BTF  vereinheitlicht die Beschreibung der zu transferierenden Formate in Deutschland, Frankreich und der Schweiz. Diese Harmonisierung macht den Weg frei für eine wachsende EBICS-Community.


Die neue EBICS 3.0-Spezifikation ist ab dem 27. November 2018 gültig. Termine zur Einführung können in den einzelnen Ländern abweichen. EBICS 3.0 bringt folgende Vereinheitlichungen:

• einheitliche EBICS-Version in den drei EBICS-Ländern
• einheitliche Identifikation der Geschäftsprozesse und Formate (BTF)
• einheitliches X.509-Format für die Schlüsselablage

Damit ist die Kompatibilität der EBICS-Dialekte gewährleistet.

Optionale Features

Bisher wurden nicht alle EBICS-Features in allen Ländern angeboten. Mit EBICS 3.0 können die Banken ihren Kunden alle optionalen EBICS-Features individuell anbieten. Dazu gehören:

• Zertifikate
  CA-signierte Zertifikate
  selbstsignierte Zertifikate
• Berechtigungsmodell
  deutsche T-, A-, B- und E-Autorisierungen
  französische T- und TS-Autorisierungen
  Abschaffung der Fax-Autorisierung
• Verteilte Elektronische Unterschrift (VEU)
  Die Nutzung der VEU ist in Deutschland obligatorisch, ansonsten optional.

Neuerungen

Die EBICS 3.0-Spezifikation enthält Neuerungen, die bei der Einführung berücksichtigt werden müssen:

• Mapping
  Die Anpassung von Formatparametern und Auftragsarten an BTF-Standards wird durch Zuordnungsübersichten (Mappings) erleichtert. Auf nationaler Ebene sind Zuordnungsübersichten für Auftragsarten und Formatparameter definiert. Die EBICS-Clients müssen diese Zuordnungen umsetzen. In der Übergangszeit kann es zu Mischformen kommen: Bank A unterstützt bereits BTF, während Bank B nur EBICS 2.x anbietet.

• Erweiterte Steuerung
  Mit BTF kann nun der EBICS-Client den Bankrechner steuern. Bisher steuerte ausschließlich der Bankrechner die Prozesse. Diese Client-Steuerung öffnet ein neues Kapitel in den Prozessabläufen. Der EBICS-Nutzer kann z. B. vorgeben, ob sein Auftrag direkt in die VEU gehen soll oder die Berechtigung zu prüfen ist. Bei Abweichungen zwischen der BTF-Vorgabe und den Rechten auf dem Bankrechner definiert die EBICS-Spezifikation das Verhalten.

• Einheitliches Protokoll
  Das strategische Kundenprotokoll in der EBICS 3.0-Spezifikation ist das HAC. Damit wird das alte textbasierte Kundenprotokoll PTK vollständig abgelöst. Das HAC-Protokoll ist maschinenlesbar, da es auf XML basiert. In der Übergangszeit werden PTK und HAC bei einem EBICS-Versionsmix parallel existieren. Nach der EBICS 3.0-Spezifikation sollen BTF-Aufträge nicht mehr im alten PTK angezeigt werden. Wer das dennoch möchte, kann das PTK-Format proprietär erweitern.

EBICS 3.0 ebnet den Weg für eine wachsende EBICS-Community

EBICS 3.0 europäisiert die Nutzung von EBICS. Das ist gut. Damit können Banken neue Märkte und Kunden gewinnen. Der Kunde erhält durch die Flexibilisierung mehr Möglichkeiten. EBICS nutzt nun ausschließlich etablierte Standards.

Existierende Schnittstellen und Vertragskonditionen können fast unverändert bleiben. Das BTF kann im Hintergrund konfiguriert werden. Für Bankrechner und EBICS-Clients bleibt die Fachlichkeit im Vordergrund. Die EBICS 3.0-Spezifikation und die Mappingvorgaben unterstützen das.

Die Einführung von EBICS in neuen Märkten und Ländern ist mit EBICS 3.0 wesentlich erleichtert worden. Die Vorteile von EBICS 3.0 sind unübersehbar. Daher ist eine zeitnahe Einführung in den bestehenden EBICS-Ländern zu empfehlen.

Michael Lembcke

Weiterlesen

EBA CLEARING führt EBICS als zusätzliches Übertragungsprotokoll für ihr Instant-Payment-System ein

Teilnehmer am EBA-Clearingservice können ab November 2017 sowohl SIANet als auch EBICS für die Verbindung zur neuen paneuropäischen Infrastruktur für Echtzeitzahlungen nutzen. Weitere Alternativen könnten später folgen.

EBA CLEARING hat angekündigt, dass zukünftige Teilnehmer an ihrer paneuropäischen Instant-Payment-Infrastrukturlösung neben SIANet auch den Electronic Banking Internet Communication Standard (EBICS) zum Austausch von Zahlungsverkehrsnachrichten mit der Plattform nutzen können. Das Unternehmen bietet das zusätzliche Übertragungsprotokoll EBICS mit der Einführung des Dienstes im November 2017 an. Ab Juni 2017 steht EBICS für die Testumgebung zur Verfügung.
Lesen Sie hier die Pressemitteilung der EBA CLEARING vom 09. März 2017: Pressemitteilung EBA CLEARING

Michael Lembcke

Weiterlesen

Wie sich EBICS verbessern lässt, Teil 9 – EBICS ist für den Dateitransfer beliebig großer Dateien geeignet. – Ja, aber …

Auch mit SEPA ändert sich das Datenverhalten im Zahlungsverkehr weiterhin. Neue Prozesse führen dazu, dass Dateien im Austausch zwischen Kunden und Banken sowie im bilateralen Austausch immer größer werden. Insbesondere in der Kunde-Bank-Beziehung spielt die Downloadfunktion für Datenabholungen (z. B. Kontoauszüge) über EBICS eine wichtige Rolle. Und zumindest hier scheint es noch Optimierungsbedarf zu geben. Bei besonders großen Dateien wird es mit dem erfolgreichen Download aus verschiedenen Gründen schwierig.


Um das Problem genauer zu beschreiben, muss man zunächst etwas tiefer in das EBICS-Protokoll einsteigen. Datenabholungen (Downloads) über EBICS erfolgen segmentweise immer für alle zur Clientanfrage passenden Daten. Ein EBICS-Client legt beim Empfang einer Anfrage alle Daten für eine Abholung immer in genau einer physischen Datei ab.

Im Downloadprozess von EBICS ermittelt der EBICS-Server nach Empfang eines Abholauftrages zunächst die Anzahl der Segmente, in denen die zu übertragende Datei an den Client übergeben wird. Diese Angabe wird mit dem ersten Segment an den Client zurückgegeben. Sie ist in EBICS verpflichtend. Anschließend ruft der Client jedes Folgesegment sequentiell nacheinander ab und legt die Datei bei sich an.

Bereits der Vorgang zum Zusammenstellen des ersten Segments mit der Gesamtanzahl auf dem EBICS-Server kann je nach Dateigröße und Auslieferungsart (z. B. ZIP-Archiv) längere Zeit beanspruchen. Es muss erst die vollständige Datei komprimiert und verschlüsselt erzeugt werden, damit in der ersten EBICS-Response die korrekte Anzahl an Segmenten an den EBICS-Client mitgeliefert werden kann. Bis der Client in der Initialisierungsphase eine Rückmeldung über die Segmentanzahl bekommt, kann es somit bei großen Datenmengen in der EBICS-Verbindung zu Timeout-Situationen und damit zu Abbrüchen kommen.

Hier liegt das Problem. Daher muss es zukünftig möglich sein, die EBICS-Response auf die EBICS-Initialisierungsanfrage zu beschleunigen.

Die Anzahl der Segmente, die mit dem ersten Segment an den Client zurückgegeben wird, muss heute für den Start der Übertragung nach Möglichkeit korrekt sein. Laut EBICS-Spezifikation 2.5 (siehe Abschnitt 7.2 Umsetzung in den EBICS-Nachrichten, Seite 159) sollte sich der EBICS-Client bei falscher Angabe der Segmentanzahl jedoch tolerant verhalten. In einem solchen Fall müsste der EBICS-Client die laufende Transaktion ordnungsgemäß mit der Quittungsphase fortsetzen, auch wenn der EBICS-Server weniger Segmente liefert, als er in der initialen EBICS-Response angegeben hat. Damit der EBICS-Server bei großen Dateien schneller zu einer Rückmeldung an den Client kommt und ein Timeout vermieden wird, sollte es möglich sein, eine geschätzte Segmentanzahl zu ermitteln und zurückzugeben.

Grundsätzlich wäre eine Erweiterung der EBICS-Spezifikation mit folgenden zwei Teillösungen wünschenswert.

Der EBICS-Client initiiert einen Download mit unbestimmter Größe zur Vermeidung von Timeouts bei großen Datenmengen

Der Bankrechner liefert in seiner Response zusammen mit dem ersten Segment eine Segmentanzahl der zu erwartenden Daten zurück. Wenn es sich um Daten mit der Möglichkeit einer schnellen Zusammenstellung handelt, kann der Bankrechner die Segmentanzahl wie bisher genau liefern. Handelt es sich jedoch um eine größere Datenmenge mit ggf. längerer Aufbereitungszeit (z. B. ZIP), darf auch eine ungefähre Segmentanzahl zurückgeliefert werden.
In jedem Fall muss sich der EBICS-Client so verhalten, dass er so lange Segmente abruft, bis er die Ende-Nachricht bekommt.

Um nun bei Abholungen Timeouts während der Sammel-/Aufbereitungsphase des EBICS-Bankrechners zu vermeiden, sollte der Bankrechner beim Abruf eines Folgesegments auch einen Wert zurückgeben dürfen, der aussagt, dass er mit der Datenzusammenstellung noch nicht fertig ist. Der EBICS-Client kann das gewünschte Segment wiederholt anfragen, bis er es bekommt.

Optionale Begrenzung der abzuholenden Datenmenge durch den EBICS-Client, um zu große Dateien zu vermeiden

Der Download von großen Datenmengen kann aber auch durch Bedingungen problematisch sein, die nicht im Einflussbereich des EBICS-Servers bzw. dessen Betreibers liegen. Ursachen können in der Systemauslegung des Clients oder in der Infrastruktur liegen. In solchen Fällen kann es u. U. helfen, wenn die abzurufende Datenmenge kundenseitig über die heutigen Möglichkeiten hinausgehend (historischer Abruf) weiter eingeschränkt werden kann.

Zum Beispiel wäre es wünschenswert, wenn der EBICS-Client einen Download unter Angabe einer maximalen Größe initiieren kann. Denkbar ist ein neuer optionaler Parameter für die Größe der Abholdaten. Beim Download liefert der EBICS-Bankrechner dann immer vollständige Datenblöcke (z. B. Kontoauszug) und davon mindestens einen. Die Größenbegrenzung sollte stets als Richtwert interpretiert werden, den der Bankrechner auch überschreiten darf. Damit gäbe es auch clientseitig neben der historischen Abholung eine weitere Möglichkeit, die Größe der Abholdaten selbst zu steuern.

Mit diesen beiden Erweiterungen ist EBICS auch zukünftig für die wachsenden Datenmengen gerüstet.

Michael Lembcke

Weiterlesen

Instant Payments auf der Sibos

Dieses Jahr gastierte die Sibos in dem beschaulichen Genf. Der Flughafen lag direkt nebenan und man konnte die Flugzeuge mit voller Geschwindigkeit starten sehen. Und genauso hob auch Instant Payments ab. Es war eines der beherrschenden Themen auf der Sibos. Die Vorbereitungen für die Einführung laufen auf Hochtouren.


Instant Payments ist wahrscheinlich eine disruptive Technologie, die Volumina von anderen Zahlungsverkehrsmitteln abschöpfen wird. Dazu gehören der Massenzahlungsverkehr, der heute beispielsweise über EBICS läuft, aber auch Kartenzahlungen – Debitkarten- und Kreditkartenzahlungen am POS. Des Weiteren wird erwartet, dass vermehrt Zahlungen im Internet über Instant Payments abgewickelt werden. Ein Angriff auf PayPal und Co?

Was im ersten Moment harmlos aussieht, kann die Welt des Zahlungsverkehrs umkrempeln. „The New Normal“ wurde Instant Payments auf der Sibos genannt, obwohl es noch nicht einmal in Europa richtig abgehoben ist. Dies zeigt aber deutlich, was für ein Potenzial in Instant Payments vermutet wird. Die „neuen“ Player von gestern, wie z. B. PayPal und Co., könnten die Verlierer von morgen werden.

Die bisherigen Instant-Payments-Lösungen sind rein nationale Lösungen. Natürlich werden sich die wesentlichen Volumina im Zahlungsverkehr mit Instant Payments rund um den Kirchturm abspielen. Aber das muss nicht so bleiben. Mit einem Instant Payments, das europaweit funktioniert, könnten schnell neue Services entstehen. Dabei werden die Banken eine größere Rolle spielen als beim Bezahlen mit Kreditkarte oder über PayPal. Sie würden dabei ihren Anspruch, im Zahlungsverkehr führend zu sein, verteidigen und vielleicht sogar wieder Boden gutmachen können.

Die Grenzen von 15.000 € pro Instant-Payments-Transaktion werden schnell erhöht. Man munkelt von mittleren 6-stelligen Beträgen. Europäische Bankgruppen stehen in den Startlöchern, um dieses Limit innerhalb ihrer Gruppe von Beginn an aufzubrechen. Dies könnte auch für Firmenkunden interessant sein. Industriegüter, Dienstleistungen und Waren werden heute noch recht altmodisch bezahlt und damit teuer und langwierig. Mit Instant Payments könnte sich das ändern. Natürlich darf eine Zahlung per Instant Payments einige Sekunden länger oder sogar einige Minuten dauern, wenn beispielsweise der Betrag Millionen überschreitet und wenn Embargo-Prüfungen, AML und Settlement synchron ablaufen. Auch hier könnten sich wieder fundamentale, disruptive Änderungen ergeben.

Instant Payments ist übrigens nicht durch die PSD II initiiert. Was für eine vergebene Chance. Die EZB hat hier die Feder geführt und den Schritt hin zu einem europäischen Instant Payments nicht gewagt. Die Interoperabilität mit nationalen Instant-Payments-Lösungen ist derzeit noch unklar. Vielleicht schafft die PSD III, die schon in der PSD II angekündigt ist, den passenden rechtlichen Rahmen. Derzeit ist noch alles freiwillig und die Auswirkungen – auch auf den Massenzahlungsverkehr mit EBICS – sind noch nicht klar. Fest steht, dass die Europäisierung von Instant Payments Chancen bietet. Und die sollten wir nutzen.

Michael Lembcke

Weiterlesen

EBICS und PSD2 – Wie kommt das zusammen?

Die Zahlungsdiensterichtlinie PSD (Payment Services Directive) des Europäischen Parlaments ist die rechtliche Grundlage für den EU-weiten einheitlichen Binnenmarkt im Zahlungsverkehr. Die aktuelle Version PSD2 wurde am 23.12.2015 im Amtsblatt der Europäischen Union veröffentlicht und muss bis zum 13.01.2018 in nationales Recht umgesetzt sein. Welche Auswirkungen hat die PSD2 auf EBICS?


Ziele der PSD2 sind insbesondere:

• strengere Sicherheitsanforderungen an den elektronischen Zahlungsverkehr
• Schutz der Finanzdaten von Verbrauchern
• Öffnung des Markts für Zahlungsverkehrsdienstleister, insbesondere bei den Diensten für Verbraucher und Unternehmen
• Stärkung der Verbraucherrechte, z. B. bei der Haftung für nicht autorisierte Zahlungen und Erstattungen bei Lastschriften in Euro
• Untersagung der Berechnung von Aufschlägen, unabhängig vom Zahlungsinstrument

Strengere Sicherheitsanforderungen an den elektronischen Zahlungsverkehr fordern, dass der Zugriff auf Kundenkonten sicher ist. Die Identifikation eines Zahlungsdienst-Nutzers oder einer Transaktion erfordert eine starke Authentifizierung. EBICS erfüllt diese Voraussetzungen mit den asymmetrischen benutzerbezogenen Schlüsselverfahren. Der praktischen Umsetzung einer starken Authentifizierung steht somit nichts entgegen.

Die drei Grundpfeiler einer starken Authentifizierung sind bekanntlich Besitz, Inhärenz und Wissen. Mindestens zwei dieser Kriterien sind den Nutzern beim Zugang zur EBICS-Autorisierung anzubieten. Beispielsweise ermöglicht eine Chipkarte (Besitz) als EBICS-Schlüsselmedium über einen Chipkartenleser per PIN-Eingabe (Wissen) eine Autorisierung. Dies muss in der Schnittstelle zum Nutzer also client-seitig umgesetzt sein.

Neben den EBICS-Mitteln zur eindeutigen Identifikation und Authentifizierung der Person kann die Bank zusätzliche verstärkende Prüfungen vorsehen (Inhärenz), z. B. ob in der Kommunikation die zuvor vereinbarten IP-Adressen genutzt werden. Eine nicht passende IP-Adresse verhindert bei ansonsten passender Authentifizierung den Zugang.

Die geforderte Dynamik in der Authentifizierung bildet EBICS durch das elektronische Signaturverfahren ab, denn die Signatur wird stets über den Hashwert der Originaldatei und einen Timestamp gebildet.

Zudem ermöglicht es die EBICS-Funktion der Verteilten Elektronischen Unterschrift (VEU), auf Seiten der Zahlungsdienst-Nutzer die Infrastrukturen für Zahlungseinreichungen und Autorisierungen zu trennen. So kann z. B. die Einreichung über einen Automaten per EBICS unautorisiert erfolgen und die vorgeschriebenen Autorisierungen nachträglich per Mobile-App, EBICS-Portal oder mit sonstigen EBICS-Clients, also räumlich und zeitlich getrennt. Außerdem können die Autorisierungsbedingungen vorschreiben, dass mehrere Personen beteiligt sind. Dies bieten heutige EBICS-Lösungen wie EBICS-Portale, EBICS-Browserlösungen, EBICS-Mobile-Clients sowie sonstige EBICS-Clients bereits. Es gilt, diese Techniken für die PSD2 konsequent anzubieten und zu nutzen.

Den Zahlungsverkehrsmarkt für Zahlungsverkehrsdienstleister zu öffnen, bedeutet, dass Banken den Anwendungen von Drittanbietern den Zugang zu Kundendaten geben müssen – wenn der Kunde dem zustimmt. Um diese Anforderung umzusetzen, sind Schnittstellen gefragt. Eine nutzbare Schnittstelle bietet der EBICS-Standard selbst. Sofern der Drittanbieter sich die Informationen nicht direkt über den Standard-EBICS-Zugang beschaffen kann, sind u. a. schnelle und flexible APIs gefragt, die die geforderten Daten bedarfsgerecht austauschen. Dabei sind Einheitlichkeit und Mehrfachnutzbarkeit wünschenswert.

In der Praxis werden Nutzeraktivitäten und insbesondere Autorisierungen in E-Banking- und ZV-Anwendungen bereits aufgezeichnet. Die mit der PSD2 angestrebte Stärkung der Verbraucherrechte fordert allerdings von den Dienstleistern und Banken, die Zahlungsverkehrsabläufe und Autorisierungen im Nutzerkontext nachvollziehbar und nachweisbar möglichst vollständig zu protokollieren und aufzubewahren. Dies gilt im Kontext von EBICS für Banken, aber auch für Diensteanbieter, die z. B. EBICS-Client-Anwendungen betreiben.

Zusammengefasst hat die PSD2 zunächst keinen direkten Einfluss auf die EBICS-Spezifikation selbst. Allerdings müssen EBICS-Nutzer die PSD2 im Nutzungskontext berücksichtigen. Die Anforderungen der PSD2 sind also für den Betrieb und die Nutzung von EBICS-Lösungen frühzeitig zu definieren und umzusetzen. Die Zeit läuft.

Michael Lembcke

Weiterlesen

Hacker-Angriffe auf den SWIFT-Zahlungsverkehr

81 Millionen US-Dollar – diese Riesensumme haben Kriminelle von der Zentralbank Bangladesch gestohlen. Nicht bei einem filmreifen Überfall, sondern ganz still mit einem Hacker-Angriff. Die Diebe veranlassten mehr als 30 Überweisungen vom Konto der Bangladesh Bank bei der New Yorker Federal Reserve Bank (Fed) auf philippinische Konten. Dieser und weitere Fälle zeigen: Der Interbanken-Zahlungsverkehr ist ein lohnendes Angriffsziel. Und die Sicherheit des internationalen Finanznetzes SWIFT ist verletzlich. Der Aufwand, dort einzudringen, ist sicherlich groß, aber die zu erwartende Beute noch größer. Angesichts solch professioneller Attacken steht die Sicherheit des Zahlungsverkehrs erneut ganz oben auf der Agenda.


Die Bangladesh Bank wurde im Februar 2016 auf zwei Ebenen angegriffen. Offensichtlich waren die IT-Sicherheitseinrichtungen mangelhaft: Die Zentralbank verfügt angeblich über keine Firewall und nur über veraltete Netzwerktechnik. Durch diese Tür gelangten die Diebe in das Banknetz und dort an die Zugangsdaten für Überweisungen. Im SWIFT-Client Alliance Access konnten sie sich damit als Auftraggeber der Transaktionen autorisieren. Für die Fed traten die Urheber als Zentralbank von Bangladesch auf.

Die Sicherheitslücke erlaubte es den Angreifern laut BAE Systems auch, eine eigens programmierte Schadsoftware im SWIFT-Alliance-Server zu installieren. Diese Software manipulierte die Bestätigungsnachrichten des SWIFT-Netzes und schaltete den Zugriffsschutz für die Datenbank aus. Die ausgeführten Transaktionen wurden nicht korrekt protokolliert, um die Spuren zu verwischen.
Der Hacker-Angriff hebelte die Sicherheitsmechanismen von SWIFT komplett aus und eröffnete den Dieben nahezu unbegrenzte Möglichkeiten. Die Gesamtsumme der angeforderten Transaktionen belief sich gar auf 951 Millionen US-Dollar. Ein ungewöhnlicher Tippfehler in einer Nachricht ließ eine beteiligte Bank in Bangladesch nachfragen, ob die Überweisung so gewünscht sei. Nur dadurch fiel der gesamte Betrug überhaupt auf. Da waren die 81 Millionen aber bereits überwiesen und in philippinischen Kasinos und Privathänden verschwunden. In der Folge mussten Atjur Rahman, der Chef der Zentralbank Bangladesch, und seine Stellvertreter im März 2016 zurücktreten.

SWIFT selbst hat eingeräumt, dass in den letzten Monaten mehrfach betrügerische Nachrichten über das Netz gesendet worden sind. Im Mai 2016 war eine Geschäftsbank von einem ähnlichen Betrugsfall betroffen: Kriminelle sind in die IT-Systeme eingedrungen, haben Nutzerdaten abgegriffen und Nachrichten manipuliert. Nun sollen Updates die Sicherheitslücken in der SWIFT-Software schließen.

Auch wenn SWIFT betont, der Angriff stelle nicht die Sicherheit des Netzes infrage, sondern die des Zugangssystems, zeigt der Fall das Dilemma geschlossener internationaler Netze. Auch mit hohem technischem Aufwand lassen sie sich nicht absolut abschotten. Außer der Software des Netzbetreibers können auch die umgebenden Banksysteme eine Schwachstelle sein. Ganz zu schweigen von kriminellen Mitarbeitern, die beim Betrug mithelfen. Und sind die Angreifer erstmal drinnen, steht ihnen die ganze Welt offen. Das schafft Anreize. Ein Verfahren wie EBICS nutzt das offene Internet und verfolgt ein Sicherheitskonzept, das stark auf Schlüsseln für die Kryptografie und Authentifizierung basiert. Das kann eine Alternative zum geschlossenen Netz sein.

Angesichts der potenziell sehr großen Schäden muss der Interbanken- und Firmenkunden-Zahlungs­verkehr umfassend geschützt werden. Es ist zu erwarten, dass Cyber-Attacken wie die hier beschriebene zunehmen. Letztlich müssen die Sicherheitsmechanismen des Verfahrens, der Bank-IT und für das Personal lückenlos ineinander greifen.

Michael Lembcke 

Weiterlesen

Wie sich EBICS verbessern lässt, Teil 8 – Doppeleinreichungen mit EBICS-Mitteln verhindern: Was geht da?

Schnell ist es passiert. Die Zahlungsverkehrsaufträge wurden per EBICS versehentlich doppelt zur Bank übertragen. Keiner hat es bemerkt. Gleich mehrere solcher Fehlerfälle fallen einem da ein:

1. In der Zahlungserfassung wird eine Zahlung doppelt erfasst und gesendet.
2. Die Datei mit den Zahlungsaufträgen wird erneut und damit doppelt übertragen.
3. Die Zahlungsdatei wird aus technischen Gründen doppelt übertragen, da der Übertragungsstatus des ersten Transfers unklar war.

Wesentlich für eine Doppeleinreichung ist, dass ein Kunde eine Zahlung bzw. Datei mit identischen Angaben in einem festgelegten Zeitraum erneut bei der Bank einreicht. Aber ist eine identische Einreichung stets eine generell abzulehnende Doppeleinreichung? Nein, denn manche Zahlungen werden vom Einreicher bewusst mehrfach ausgestellt und übertragen.


Wie also kann die Bankseite echte Doppeleinreichungen sicher erkennen und einen Schaden für den Kunden abwenden?

Es ist möglich, zumindest offensichtliche Doppeleinreichungen bereits bei der Einreichung im EBICS-Bankrechner zu erkennen und abzulehnen.

Im Fall der technischen Doppeleinreichungen (siehe 3.) erkennt das EBICS-Protokoll bis zur EBICS-Version 2.4, wenn ein Kunde eine vom EBICS-Client vergebene Order-ID in einem definierten Zeitraum erneut verwendet. Ab EBICS V2.5 vergibt der EBICS-Bankrechner bereits beim Aufbau der Kommunikation eine eindeutige Order-ID. Ein Doppeleffekt wie bei EBICS V2.4 kann somit nicht auftreten.

Der Fall, dass eine Datei oder ein Auftrag aber versehentlich mit einem neuen Transfervorgang und somit einer neuen Order-ID noch einmal gesendet wird (siehe 2.), kann mit den bestehenden EBICS-Mitteln auf dem EBICS-Bankrechner derzeit nicht ausgeschlossen werden. Um dafür eine effektive Doppeleinreichungsprüfung auf Dateiebene zu ermöglichen, soll mit der nächsten EBICS-Version der EBICS-CR EB-14-08 DoubleUploadControl umgesetzt werden.

Dieser CR verpflichtet den EBICS-Client, einen Hashwert über die Zahlungsdatei an den EBICS-Bankrechner zu übermitteln. Der Client erstellt diesen Hashwert ohnehin für die Signaturerzeugung. Der EBICS-Bankrechner muss prüfen, ob der Hashwert im betreffenden Zeitraum schon mal vorgekommen ist, und den Auftrag bei Doppeleinreichung ablehnen.

Eine weitergehende Doppeleinreichungsprüfung, z. B. auf Einzeltransaktionsebene (Fall 1.) ist schon komplizierter und muss nach wie vor außerhalb von EBICS gelöst werden. Ggf. muss ein Bankmitarbeiter in Rücksprache mit dem Kunden ermitteln, ob die doppelte Einreichung nicht doch gewollt ist.

Mit dem geplanten EBICS-CR EB-14-08 DoubleUploadControl wird EBICS um eine weitere sinnvolle Funktion ergänzt und verbessert. Dies ist auch erforderlich. Versehentliche Doppeleinreichungen können so frühzeitig verhindert werden. Allerdings kommt damit kein Allheilmittel. Die Bankanwendungen können auf weitergehende Doppelprüfungen nach wie vor nicht verzichten.

Michael Lembcke 

Weiterlesen