Posts mit dem Label CFONB werden angezeigt. Alle Posts anzeigen
Posts mit dem Label CFONB werden angezeigt. Alle Posts anzeigen

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

EBICS und der mobile Zahlungsverkehr in Frankreich

In der Reihe „EBICS als europäischer Standard für Mobile Payments“ wollen wir heute den Fall Frankreich näher betrachten.
Eine mobile Lösung, die es jedem Nutzer ermöglicht, Transaktionen von unterwegs - gemäß EBICS TS-Protokoll - zu unterschreiben, würde den Bedürfnissen der immer zahlreicher werdenden „Nomaden“ unter den Unterzeichnern entsprechen, die darauf hoffen, dass Mobile Banking mit EBICS endlich Realität wird.


Voraussetzung wäre, dass eine solche Lösung ausreichend flexibel ist, d. h. auf der großen Mehrheit von Mobiltelefonen und Tablets läuft, unabhängig von deren Betriebssystem (zumindest iOS, Android, Windows Mobile), und genauso ein hohes Sicherheitsniveau bietet wie die EBICS TS-Signatursoftware für PCs, die täglich tausendfach verwendet wird.

Natürlich hat bereits der eine oder andere Softwarehersteller mobile Applikationen entwickelt, doch bleiben diese allesamt unbefriedigend und werden wenig genutzt, weil ihnen die nötige Flexibilität und Benutzerfreundlichkeit fehlt. Um den Spezifikationen des CFONB (französisches Komitee für Organisation und Normierung im Bankwesen) aus dem Implementation Guide zu entsprechen, muss jede Unterschrift über ein persönliches Unterschriftszertifikat auf einem physikalischen Träger verfügen, das von einer von der Bank anerkannten Zertifizierungsstelle ausgestellt wird. Und genau da liegt der Hund begraben: Es ist zwar möglich, einen USB-Token an bestimmte Tablets anzuschließen, aber es ist bis heute nicht möglich, ihn an alle mobilen Geräte unabhängig von ihrer Marke anzuschließen. Nimmt man hohe Adapter- und Anschlusstechnikkosten in Kauf, könnte man dennoch ans Ziel kommen. Doch funktionieren all diese Lösungen eher schlecht als recht, zumal sie den Benutzer zwingen, sein Gerät in einen komplizierten Apparat zu verwandeln, was schließlich den letzten Enthusiasten von einem systematischen Gebrauch solcher Lösungen abhalten wird.
Auch ist es weder vernünftig noch angemessen, die Unterzeichner zu zwingen, sich ein zusätzliches Smartphone oder Tablet zuzulegen, bei dem ein Token einigermaßen komplikationslos angeschlossen werden kann, so dass es bei Bedarf sofort genutzt werden könnte.

Eine Lösung bestünde darin, anstelle des physikalischen Trägers als Speichermedium für das Zertifikat ein „flüchtiges“, d. h. einmalig zu verwendendes Zertifikat einzuführen. Neben der hierfür unerlässlichen Zustimmung durch das CFONB würde dies jedoch bedingen, dass das Zertifikat, wann immer es verwendet wird, bei der Zertifizierungsstelle neu registriert werden muss, was dem Vorgang jedwede Flexibilität und damit jedweden Charme nähme.

So bleibt das Problem, dass das Verfahren der verteilten Unterschrift nicht standardisiert ist wie bei unseren Nachbarn jenseits des Rheins, die von der Verteilten Elektronischen Unterschrift (VEU) profitieren. Auch wenn es bedauerlich ist, dass EBICS DS bis heute nicht konkretisiert worden ist, so stellt dies doch keinen Hinderungsgrund dafür dar, einen Service mit äquivalenter Funktionsabdeckung anzubieten, also den reisenden Unterzeichnern zu erlauben Aufträge vor der Ausführung zu bestätigen. Die Verwaltung dieser Gruppen von Unterzeichnern und Unterschriftenmappen erfolgt vorher auf einer vom Unternehmen oder von vertrauenswürdigen Dienstleistern bzw. Betreibern betriebenen Plattform. Sobald alle notwendigen Unterschriften vorliegen (unbedingt im Format EBICS [A005 bzw. A006]), werden der Auftrag und die gespeicherten Unterschriften über EBICS im TS-Profil an den entsprechenden Server weitergeleitet. Mit dieser Lösung könnten umfassendere Unterschriftsrechte als mit dem EBICS-Standard (1+1 bzw. 2) verwaltet werden, womit sie den Ansprüchen der Benutzer potenziell näher kommt.

Marc Dutech