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

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 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

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

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

Migration zu EBICS 3.0 in Frankreich

EBICS 3.0 ist in Frankreich am 27. November letzten Jahres in Kraft getreten. Gut zwei Monate sind seitdem vergangen und so ist es an der Zeit zu schauen, wie weit die Migration zur neuen Version fortgeschritten ist.

Gegenstand dieser neuen Version ist die Harmonisierung von EBICS mit den folgenden Zielen:
 

• eine einheitliche EBICS-Version in allen Ländern, in denen EBICS zum Einsatz kommt
• eine einheitliche Identifizierung der Geschäftsvorfälle und Formate (auch BTF genannt: Business Transaction Format)
• ein einheitliches X.509-Format für die Schlüsselablage

Das Datum für das Inkrafttreten betrifft nur die französischen Banken und Kreditinstitute und ist nicht verpflichtend für Firmenkunden. Diese können selbst entscheiden, wann sie migrieren möchten.

Die großen französischen Banken arbeiten seit einigen Monaten an den Migrationsprojekten und die meisten können ihren Kunden den EBICS-3.0-Kanal ab sofort anbieten. Die anderen sind in der letzten Testphase und die Öffnung des EBICS-3.0-Kanals steht unmittelbar bevor.

Die kleineren Banken sind noch nicht so weit. Nur wenige haben mit den Migrationsprojekten begonnen.Es ist deshalb sehr wahrscheinlich, dass diese Institute erst in einigen Monaten, vielleicht sogar erst 2020, den EBICS-3.0-Kanal anbieten können.

Diese Unterschiede in der zeitlichen Umsetzung sollten die Firmenkunden, die demnächst auf EBICS 3.0 migrieren wollen, jedoch nicht bremsen. Denn auch die Banken, die schon auf EBICS 3.0 migriert haben, werden in einer mehr oder weniger langen Übergangsphase noch die Version 2.4.2 unterstützen, die seit der Einführung von EBICS in Frankreich in Kraft ist (in Deutschland wird aktuell die Version 2.5 genutzt). Diese Übergangsphase gibt den Firmenkunden Zeit, ihre Client-Software zu aktualisieren.

Vor allem mangelndes Interesse der Firmenkunden an der neuen Version könnte jedoch dafür sorgen, dass die Übergangsphase sich hinzieht. Um dem entgegenzuwirken, können die Banken ihren Firmenkunden zusätzliche Services anbieten, die mit den Erweiterungen der neuen Version möglich werden. Dazu gehören unter anderem das einfachere Einrichten von Transfers und die verteilte elektronische Unterschrift. Sie ermöglicht es Firmenkunden, Aufträge asynchron nach dem Transfer der Datei zu unterschreiben (in der Version 2.4.2 musste die elektronische Unterschrift zusammen mit der Auftragsdatei geschickt werden), und verhilft ihnen so zu mehr Mobilität.

Das wird sich vor allem dann bemerkbar machen, wenn die X.509-Zertifikate komplett virtuell sind, so dass die mobile Unterschrift wirklich nutzbar ist. Experten arbeiten an diesem Thema und so sollte es in einigen Monaten effiziente Lösungen geben…

Marc Dutech

Weiterlesen

EBICS 3.0 in den Startlöchern

Am 19. Mai 2017 fand im Auditorium der Fédération Bancaire Française (Französische Bankenvertretung) ein Themenworkshop des CFONB zur Vorstellung Version 3.0 des EBICS-Protokolls statt.

Mehr als 120 Personen aus unterschiedlichen Bereichen - Banken, Hersteller, Unternehmen, usw. - nahmen an der Veranstaltung teil, im Rahmen derer verschiedene Redner das Grundkonzept dieser neuen Version vorstellten.


Nachdem die Geschäftsführung und einige Vertreter der EBICS SCRL (www.ebics.org) eine Übersicht vorgestellt hatten, wurden einige entscheidende Daten aus der Geschichte von EBICS präsentiert. Sie haben daran erinnert, dass der EBICS-Standard nun nicht mehr in den Kinderschuhen steckt und belegten dies damit, dass bereits vor 12 Jahren die Implementierung in Deutschland begann und vor mehr als 7 Jahren EBICS in Frankreich übernommen wurde. Bei den Schweizer Finanzinstituten wurde dieser Weg erst 2015 eingeschlagen. Eine Präsentation zeigte die derzeitige Verbreitung von EBICS, die sich von der Iberischen Halbinsel bis zur Ostsee und von Irland bis nach Italien erstreckt. Abgesehen von Deutschland, Frankreich, der Schweiz und Portugal ist der Verwendungsgrad in den entsprechenden Staaten jedoch sehr unterschiedlich.

Im Anschluss wurden die Gründe für den Erfolg von EBICS in den vier Ländern (zahlreiche Artikel zu diesem Thema finden Sie in diesem Blog) ebenso wie die Hindernisse einer schnellen gesamteuropäischen Ausweitung genannt. Zu diesen gehören insbesondere:

• die Unterschiede in der Identifikation der Zahlungsströme zwischen deutschen, französischen und Schweizer Varianten
• die Verwendung der X.509-Zertifikate in Frankreich und des Schlüsselpaares in Deutschland
• der Einsatz der verteilten elektronischen Unterschrift in Deutschland und in der Schweiz, aber nicht in Frankreich

Auf die Auflistung der Gründe folgte eine Beschreibung der tiefgreifenden Veränderungen, die die Version 3.0 mit sich bringen wird, vor allem hinsichtlich der Harmonisierung durch die Integration des BTF-Konzepts (Business Transaction Format) und der möglichen Generalisierung der verteilten elektronischen Unterschrift. Weitergehende Informationen zu diesen Themen erhält man über die Website der EBICS SCRL.

Der zweite Teil des Workshops bestand aus einer Diskussionsrunde zum Thema: Warum brauchen wir eine einheitliche EBICS-Version?

Für die Akteure aus dem EBICS-Bereich war dies die Möglichkeit folgende Themen anzuschneiden und zu diskutieren:

• Vorteile von EBICS aber auch Grenzen der 2.x Version aufgrund mangelnder Harmonisierung
• Erwartungen an die neue Version und Vorteile, die durch die Harmonisierung entstehen
• Möglichkeiten der geografischen Ausweitung, auch auf andere Kontinente
  Hier wurde insbesondere Afrika angesprochen, da dort bereits einige Banken den EBICS-Service in einigen französischsprachigen Ländern anbieten.
• Möglichkeiten der Verwendung von EBICS über die Unternehmen-Bank-Beziehung hinaus
  Hier wurde vor allem die Verwendung von EBICS für STEP2 und RT1 (Instant Payments) mit der EBA Clearing angesprochen.
• Migrationsmodalitäten
• Aspekte der zukünftigen Weiterentwicklung des diskutierten Protokolls, die auf die Tagesordnung gesetzt werden können, wie die Vereinheitlichung des AC-Zertifikates und die Möglichkeit Zertifikate zu verwenden, die nicht auf physischen Medien gespeichert sind, um so die Industrialisierung der EBICS-Signaturlösungen für Mobilgeräte zu vereinfachen
• aktuelle Verwendung der verteilten elektronischen Unterschrift in Deutschland und in der Schweiz und Vorteile, die durch ihre Verwendung in Frankreich entstehen könnten

Diese Veranstaltung war somit der offizielle Startschuss für die Version 3.0. Ab November 2018 wird sie verfügbar sein; ab diesem Zeitpunkt müssen alle Banken die neue Version, zusätzlich zu der in den verschiedenen Gemeinschaften gültigen Version 2.x, anbieten.

Für Unternehmen besteht keine Verpflichtung ebenfalls zu diesem Zeitpunkt zu migrieren. Für sie ist eine schlagartige Migration von der 2.x zur 3.0 nicht vorgesehen. Die neuen Gemeinschaften hingegen könnten diese neue Version direkt einsetzen.

Es liegt also viel perspektivische Arbeit vor den Herstellern und Banken. Um ihnen dabei zu helfen, wird im Juli 2017 ein Implementationguide auf Seiten der EBICS SCRL und des CFONB zur Verfügung gestellt.

Ich stelle EBICS häufig in verschiedenen Ländern in Europa und darüber hinaus vor und glaube, dass die Harmonisierung die Werbetätigkeit für dieses Produkt wesentlich erleichtern wird. Ich bin überzeugt davon, dass sie der Schlüssel zum Erfolg ist, damit schließlich der erste Buchstabe von EBICS „European“ bedeutet.

Was wäre, wenn aufgrund der Entwicklungen, die derzeit geprüft werden, der nächste Schritt das Worldwide EBICS wäre?...

Marc Dutech

Weiterlesen