Wie sich EBICS verbessern lässt, Teil 6 – eindeutige Identifikation der handelnden Person

Kann es vorkommen, dass ein Zahlungsverkehrsauftrag, der in EBICS eigentlich von zwei unterschiedlichen Personen autorisiert werden muss, doch nur von einer Person freigegeben wird? Ja, unter bestimmten Umständen ist das möglich. Bei manchen Vertragskonstellationen zwischen dem Kreditinstitut und dem Firmenkunden lässt sich die handelnde Person nicht eindeutig identifizieren. 


Die Falle steckt im EBICS-Datenmodell

Das Berechtigungsmodell des Firmenkunden für die EBICS-Kommunikation orientiert sich am Datenmodell von EBICS. Dieses unterscheidet zwischen dem Kunden und seinem Mitarbeiter als EBICS-Teilnehmer.

Firmenkunden kommunizieren per EBICS mit ihrer Bank über eine unternehmensweit gültige EBICS-Kunden-ID und die Teilnehmer-ID des handelnden Mitarbeiters. Die IDs vergibt die Bank bei der Einrichtung für den Kunden und seinen Mitarbeiter; der Kunde benötigt sie für die Verbindung zum Bankrechner in den Zugängen der EBICS-Clients. Nun ist eben diese Teilnehmer-ID nicht immer eindeutig. Wie kann das sein?

Firmenkunden nutzen verschiedene EBICS-Clients

Größere Firmenkunden setzen auch mal mehrere EBICS-Clients unterschiedlicher Hersteller ein. Dabei nutzt ein Mitarbeiter je nach Funktionsumfang auch verschiedene Clients parallel. Ein Beispiel ist der Mitarbeiter, der mit einem EBICS-PC-Produkt Zahlungen autorisiert und einreicht – und der gleichzeitig Zahlungen, die aus seiner ERP-Lösung für die in Deutschland übliche Verteilte Elektronische Unterschrift direkt zur Bank gesendet worden sind, per EBICS-Mobile-Lösung autorisiert.

Schlüssel und Zertifikate sind häufig nicht wiederverwendbar

Da die teilnehmerbezogenen Schlüssel bzw. Zertifikate je nach Kundensystem und EBICS-Land unterschiedlich abgelegt sind, kann ein Mitarbeiter sie in den meisten Fällen nicht für alle EBICS-Clients übergreifend nutzen. Sprich, das EBICS-PC-Produkt und die EBICS-Mobile-Lösung erfordern jeweils eigene Schlüssel für den Teilnehmer. Daher hat der Mitarbeiter für seinen EBICS-Zugang zur Bank in jedem Client eine andere Teilnehmer-ID, die dann die Verbindung zu seinen jeweiligen Schlüsseln bzw. Zertifikaten sicherstellt.

Da das Datenmodell von EBICS aber den EBICS-Teilnehmer als eindeutige handelnde Person definiert, kann theoretisch eine Person mit mehreren Teilnehmer-IDs Zahlungen freigeben, die eigentlich von mehreren Personen autorisiert werden müssen. Im EBICS-Datenmodell ist die Zuordnung einer Person zu mehreren Teilnehmer-IDs nicht vorgesehen.

Um einen derartigen Missbrauch zu verhindern verfügen EBICS-Bankrechner mittlerweile über zusätzliche individuelle Berechtigungsfunktionen, dennoch ist eine einheitliche Lösung im EBICS-Standard selbst wünschenswert.

Einheitliches Austauschformat für Schlüssel und Zertifikate

Eine Möglichkeit wäre es z. B., im EBICS-Standard das Austauschformat bzw. die Ablage der Schlüssel und Zertifikate einheitlich vorzuschreiben, z. B. einen Software-Token mit der Ablage im PKCS12-Format. In diesem Fall ist die Teilnehmer-ID eindeutig nutzbar, um die handelnde Person zu identifizieren. Schlüssel und Zertifikate können somit in Verbindung mit der Teilnehmer-ID auf mehreren Clients genutzt werden.

Michael Lembcke 

Wie steht es mit EBICS in Marokko?

Der Vormarsch von EBICS in Europa ist inzwischen unumstritten. Wie entwickelt sich der Standard jedoch jenseits der Grenzen der Europäischen Union? Ein Kontinent, der sich in meinen Augen besonders für die Verwendung eines modernen, leistungsfähigen und universellen Protokolls für den elektronischen Zahlungsverkehr wie EBICS eignet, ist Afrika. Genauer gesagt denke ich hier zuallererst an Marokko. Warum?


Seit langem schon orientieren sich die marokkanischen Banken und Finanzinstitute an europäischen Praktiken im Bankwesen, insbesondere an denen französischer Banken. So folgten in den neunziger Jahren die marokkanischen Banken den französischen, indem sie sich im elektronischen Zahlungsverkehr zwischen Unternehmen und Banken für das ETEBAC-Protokoll entschieden. Auf diese Weise wurden die marokkanischen Unternehmen in die Lage versetzt, effiziente Cash Management-Lösungen einzusetzen.

Ebenso orientierte man sich bei dem vom marokkanischen Bankensektor verwendeten Austauschformat für Kontoauszüge, Überweisungen und Lastschriftverfahren stark an den CFONB-Formaten.

Momentan wird in Marokko noch immer das ETEBAC-Protokoll verwendet. Allerdings läuft es unter X.28 über private PADs und die Unternehmen müssen asynchrone Analog-Modems verwenden, die kaum noch zu finden sind. Somit wird es nahezu unmöglich, die Anzahl der Unternehmen zu steigern, die den ETEBAC-Kanal verwenden. Mögliche Ersatzlösungen sind:
  • das Internet-Banking, das jedoch für Unternehmen mit Konten bei mehreren Banken bzw. Unternehmen mit erheblichem Transaktionsvolumen ungeeignet ist,
  • SWIFT, was zu wiederkehrenden Zusatzkosten führt, die nicht unerheblich sind,
  • weniger gebräuchliche Protokolle wie PeSIT, die künftigen Anforderungen nicht gerecht werden.
Der durch marokkanisches Gesetz vorgegebene Rechtsrahmen für den Austausch und Schutz digitaler Daten fördert die Verwendung sicherer Datenaustauschprotokolle mit elektronischer(n) Unterschrift(en). Dadurch werden die Banktransaktionen mit den für sie geforderten Sicherheitsfunktionen wie Authentifizierung, Unveränderlichkeit und Integrität, Geheimhaltung, keine Wiederverwendbarkeit der Unterschrift sowie Nichtabstreitbarkeit ausgestattet. Diese Funktionen werden standardmäßig vom EBICS-Protokoll abgedeckt.

Die marokkanischen Banken, die in Afrika eine Vorreiterrolle einnehmen und in 22 Ländern des Kontinents vertreten sind, benötigen zuverlässige und bewährte Systeme zur Finanzdatenübermittlung zwischen den Banken und über Grenzen hinweg, um unter anderem dafür zu sorgen, dass Marokko zum Drehkreuz von Banktransfers wird und ein Maximum an Transaktionen an sich zieht, die auf sichere und moderne Art und Weise durchgeführt werden. Hierfür bietet sich EBICS als das Mittel der Wahl an.

Übrigens erlaubt EBICS nicht nur, das bestehende Angebot von Diensten für Unternehmen auszubauen, es stellt für die marokkanischen Banken auch eine echte Innovationsmöglichkeit dar, um ganz neue Dienste (z. B. e-Invoicing) anzubieten.

Und vergessen wir nicht zwei weitere Bereiche, in denen EBICS seine Wirkung voll entfalten könnte:
  1. In Europa wird EBICS für den intereuropäischen elektronischen Zahlungsverkehr zwischen den Banken bereits sehr erfolgreich angewandt. Die marokkanischen Finanzinstitutionen könnten nachziehen und hätten somit die Möglichkeit, die Widerstandsfähigkeit und die hohe Verfügbarkeit im bankenübergreifenden Zahlungsverkehr zu verbessern und nebenbei dessen Kosten zu optimieren.
  2. EBICS kann bei Datentransfers für staatliche Digitalisierungsprojekte eingesetzt werden, insbesondere im Zusammenhang mit Sozialdaten, medizinischen und dienststellenübergreifenden Daten.
Ausgehend von obigen Ausführungen erscheint mir das EBICS-Protokoll, das sich – wie der Leser des Blogs mittlerweile hat feststellen können – dank seiner Universalität, seiner einfachen Anwendung, seinem hohen Sicherheitsniveau und der Tatsache, dass mit seiner Verwendung keine wiederkehrenden Kosten verbunden sind, in Europa schnell ausbreitet, eine ideale Alternative für den Business-to-Bank- und Bank-to-Bank-Zahlungsverkehr. Würden zudem die marokkanischen Banken die Anwendung des ISO-20022-Standards in Betracht ziehen, wäre dies ein großer Schritt in Richtung Harmonisierung und Standardisierung des elektronischen Finanzdatenaustauschs, was zu einer Vereinfachung und Optimierung der Transaktionen mit Europa führen würde. Dieser Punkt erscheint mir auch deshalb so wichtig, weil die marokkanische Wirtschaft durch zahlreiche Standortverlagerungen europäischer Unternehmen von der geographischen Nähe Marokkos zum europäischen Kontinent profitiert hat.

Stellt sich schließlich die Frage der Migration nach EBICS. Ist die Migration ein solch komplexes Unterfangen, dass sie sich als ein echtes Hindernis für die Verwendung dieses Protokolls erweisen könnte? Bedenkt man, wie die Migration in Frankreich vonstattenging, ist das meiner Meinung nach nicht der Fall. Die in diesem Zusammenhang nicht nur von den Herstellern für Banken- und Unternehmenssoftware, sondern auch von den in Marokko ansässigen französischen Banken gesammelten Erfahrungen würden eine sanfte Migration ohne große Anfangsschwierigkeiten sicherstellen.

Marc Dutech 

Luzerner Kantonalbank AG bietet Firmenkunden erweiterte Lösungen rund um EBICS und ISO 20022

Raphael Häfliger, Cash Management Services, Luzerner Kantonalbank AG

Die Luzerner Kantonalbank AG (LUKB) bietet in der Schweiz seit 2014 den Kommunikationsstandard EBICS an und hat damit ein umfassendes Angebot für den professionellen Zahlungsverkehr im Markt platziert. Nach der erfolgreichen EBICS-Einführung steht nun der nächste Schritt an: Als erstes Finanzinstitut auf dem Finanzplatz Schweiz wird die LUKB ab Herbst 2015 mit der Pilotphase für die Lancierung der "Verteilten Elektronischen Unterschrift" (VEU) starten. 


Das Konstrukt der VEU entspricht einem immer grösser werdenden Bedürfnis von Schweizer Firmenkunden. Kunden können Zahlungsaufträge mit der VEU an die LUKB übermitteln und je nach Vollmachtskonstrukt von den dafür zuständigen Personen im Unternehmen final freigegeben lassen. Dieser zusätzliche Prozessschritt unterscheidet sich von der in der Schweiz üblichen EBICS-Ausgestaltung, bei welcher die Schnittstelle mit einer Einzelunterschrift fungiert und die Berechtigungen innerhalb des firmeneigenen ERPs geregelt werden. In Deutschland gehört die VEU bereits zum Standard, in der Schweiz hingegen ist dies bislang ein Novum.

Mit dem Angebot der VEU sieht die LUKB eine Chance, sich als Finanzinstitut flexibel und kundenorientiert zu positionieren. Zur Realisierung einer EBICS-VEU führt die LUKB mit den Kunden den Dialog, um das passende Unterschriftenmodell zu evaluieren. Geplant sind unter anderem folgende Spezifika:
  • kollektiv zu zweit
  • kollektiv zu dritt
  • Gruppen mit A- und B-Unterschriften
  • weitere individuelle Rollen für Debitoren- und/oder Kreditorenbuchhaltung
  • flexible Zuordnung/Ausschluss von einzelnen Auftragsarten
Es gibt jedoch weitere Gründe sich mit der VEU zu beschäftigen. Aufgrund von operationellen Risiken kann es sinnvoll sein, die für die Auftragserteilung zuständigen Personen im EBICS zu identifizieren. Über die weit verbreiteten Corporate Seals, bei welchen nur die Firma selber authentifiziert wird, ist dies nicht möglich. Zudem könnte künftig auch der Druck seitens des Regulators oder auch der Revisionsgesellschaften in dieser Angelegenheit zunehmen.
In der Startphase ist damit zu rechnen, dass insbesondere die Kunden mit europäischen Softwarelösungen das Angebot nutzen. Weiter geht die LUKB davon aus, dass die lokalen Softwarehersteller mittelfristig ebenfalls VEU-Lösungen in ihre Clients integrieren werden.
In der Firmenkunden-Kommunikation geht die LUKB noch einen Schritt weiter und wird ab Dezember 2015 das Format ISO 20022 über EBICS transportieren. Konkret werden die Meldungen pain.001, pain.002, camt.052 und camt.053 implementiert. Camt.054 folgt voraussichtlich im Frühjahr 2016 und vervollständigt damit das ISO-Angebot. Mit diesem Vorhaben wird die LUKB zu den ersten Anbietern einer produktiven Lösung im Projekt "Harmonisierung Zahlungsverkehr Schweiz" gehören. Neben den Schweizer Empfehlungen wird die LUKB auch die ISO- und DK-Schemas (Deutschland) für die Auftragserteilung in ISO 20022 unterstützen. Weitere Schemen wie das französische oder österreichische Format werden je nach Kundenanforderungen individuell geprüft.

Mit den weitreichenden Angeboten rund um die EBICS-VEU und ISO 20022 ist die LUKB im Schweizer Firmenkundenmarkt bestens auf die kommenden Herausforderungen vorbereitet.

www.lukb.ch/harmonisierung-zv
www.lukb.ch/direkt-ebics

Raphael Häfliger

Blog-Serie: Wie sich EBICS verbessern lässt, Teil 5 – Kunden verwalten Konten und Teilnehmer selbst

EBICS bringt von Haus aus nützliche Auftragsarten für die Abfrage von Kunden- und Teilnehmerinformationen mit (welche notabene nicht alle Hersteller konsequent in ihren Produkten anbieten). Gemeint sind hier z. B. die Auftragsarten HKD (Kundendaten abrufen) und HTD (Teilnehmerdaten abrufen). Nach den Wünschen der Schweizer Grossbanken sollte es möglich sein, diese Stammdaten nicht nur abzufragen, sondern selbst zu verwalten und auch zu verändern.



Eine Besonderheit der Schweizer Implementierung ist aktuell die Beschränkung auf die Unterschriftsarten „T“ und „E“. Im ersten Fall erfolgt die notwendige zusätzliche Freigabe über einen separaten Kanal (z. B. Onlinebanking). Im zweiten Fall wird der Auftrag augenblicklich verarbeitet, da der Auftraggeber selbst für die notwendigen Sicherheitsvorkehrungen zu sorgen hat. In der Regel ist die Person, die signiert hat, im Fall „E“ nicht bekannt, sondern lediglich der Kunde respektive die auftraggebende Firma.

Als wichtigster Grund, die VEU in der Schweiz nicht anzuwenden, wird der zu hohe Aufwand für die Administration der VEU-Rechte auf Teilnehmern und Konten angeführt. Da die Kundenstammdaten der Bank oft nicht direkt mit dem EBICS-Produkt verknüpft sind, fallen Doppelerfassungen an, welche bei einer gewissen Anzahl von Kunden und Veränderungen der Berechtigungen ins Gewicht fallen. Gesucht ist ein Mechanismus im Sinne eines Electronic Bank Account Management (eBAM).
Im Standard ISO 20022 sind für diese Zwecke bereits fünfzehn Meldungen modelliert (siehe Meldungskategorie acmt). Die ISO-Meldungen können als Basis dienen, das EBICS-Protokoll so zu erweitern, dass der Kunde die Konten und Teilnehmer zumindest teilweise selbst verwalten kann. Die mehrfache Bestätigung mittels Signaturen auf Kundenseite und ein Vier-Augen-Prinzip auf Bankseite könnten je nach Sicherheitsanforderung entsprechend kombiniert werden. Der Kunde müsste beispielsweise eine heikle Transaktion doppelt prüfen, und die Bank müsste die Transaktion als letzten Schritt manuell freigeben (jedoch nicht mehr selbst komplett erfassen).

Mit einer institutsspezifischen Auftragsart (XYZ) für die Übermittlung von XML-Konto- und Teilnehmerdaten wäre dies bereits heute möglich. Bankseitig würden die Berechtigungen entsprechend geprüft und mittels Schnittstelle zum EBICS-Produkt (z. B. Webservices) automatisiert angewendet. Aus Schweizer Sicht herrscht diesbezüglich aktuell eher etwas Zurückhaltung, hat man doch bereits zahlreiche Schweizer Auftragsarten auf diese Art und Weise eingeführt, die man in naher Zukunft durch ein generelles Konzept auf Basis der französischen Anwendung von FUL/FDL ablösen möchte. Wir würden es begrüssen, wenn diese Anforderung in eine zukünftige Auftragsbeschreibung in EBICS einfliessen könnte. Von mehr Automation würden sowohl der Kunde wie auch die Bank profitieren.

Carsten Miehling 

Blog-Serie: Wie sich EBICS verbessern lässt, Teil 4 – jeder Person die eigenen Kontoauszüge

Ein großer Teil der Daten, die ich als Firmenkunde mit EBICS von einem Bankrechner abhole, hat einen Kontobezug. Wie kann ich aber für diese Daten bereits bei der Abholung steuern, welcher meiner Mitarbeiter welche Kontoauszüge bekommen darf? Dabei kann eine bankrechnerseitige Steuerung helfen.


EBICS regelt die Einreichung und die Abholung von beliebigen Daten per Auftragsarten bzw. Formatparameter. Das mit der Auftragsart verbundene Datenformat entscheidet dabei letztendlich über die Verarbeitungsmöglichkeiten im EBICS-Bankrechner. Die Inhalte der Datenbereitstellung und Abholung selbst sind jedoch nicht durch EBICS geregelt; sie können daher von EBICS-Bankrechner zu EBICS-Bankrechner und von Kreditinstitut zu Kreditinstitut abweichen.

Welcher EBICS-Teilnehmer bekommt welche Kontoinformationen?

Die Daten, die Mitarbeiter als EBICS-Teilnehmer abholen, werden üblicherweise pro Kunde auf dem Bankrechner zum Download bereitgestellt. Jeder EBICS-Teilnehmer des Kunden, der über die passende Auftragsart verfügt, erhält alle Daten, die für den Kunden bereitstehen. Das gilt ebenso für kontobezogene Daten wie Kontoauszüge und Vormerkposten. Bei der EBICS-Abholung wird die Kontoberechtigung des EBICS-Teilnehmers nicht geprüft, bei der Einlieferung von Zahlungsverkehrsaufträgen in der Kunde-Bank-Beziehung dagegen sehr wohl. EBICS selbst sieht zudem keine Kontoangaben in der EBICS-Nachricht vor. Kontobezogene Prüfungen und Verarbeitungen hängen von der Implementierung des Bankrechners ab – und im Wesentlichen auch davon, ob die Kontoangaben der bereitzustellenden Daten vollständig sind und die Konten gefunden werden.

Kontoberechtigung für Abholungen

In bestimmten Fällen sollte ein EBICS-Teilnehmer lediglich Informationen zu bestimmten Konten bekommen. Eine naheliegende Lösung wäre es, die Daten statt pro Kunde pro Teilnehmer bereitzustellen. Da die Daten allerdings auf den Firmenkunden bezogen sind, führt dies bei mehreren Teilnehmern pro Kunde zu redundanten Daten und somit einem erhöhten Datenvolumen. Vorzuziehen ist daher, die Daten wie üblich je Kunde abzulegen und die Abholung über die Kontoberechtigung am Teilnehmer zu steuern (sofern es sich um kontenbezogene Daten handelt). So bekommt der Teilnehmer stets genau die Daten aller Konten, für die er berechtigt ist.
Sinnvoll wäre zusätzlich eine EBICS-Erweiterung, die es erlaubt, im EBICS-Request ein oder gar mehreren Konten anzugeben – ähnlich der Angabe eines Zeitraums beim historischen Abruf. Mit dieser EBICS-Funktion könnte ein EBICS-Teilnehmer optional auch Daten von bestimmten Konten abrufen. Für den Teilnehmer ist es nicht immer wichtig, dass die Kontoinformationen aller Konten aktuell sind. Eine entsprechende EBICS-Erweiterung ermöglicht eine gezieltere Abholung und bietet dem Kunden letztendlich mehr Flexibilität im Kontenabruf.

Michael Lembcke 

EBICS – auf dem Weg zum europäischen Marktstandard

Axel Weiß, Chairman of Board of Directors EBICS

Für Firmenkunden ist es in Deutschland schon seit 1995 möglich, Zahlungsverkehr mit einem Standardprodukt und einer Elektronischen Signatur mit jedem Kreditinstitut sicher abzuwickeln.

Bereits im Jahre 2003 wurde die Erweiterung des DFÜ-Abkommens um eine internetbasierte Variante initiiert. Diese Variante des DFÜ-Verfahrens wurde als EBICS "Electronic Banking Internet Communication Standard" bezeichnet. Mit dieser Erweiterung erfüllte die deutsche Kreditwirtschaft die Forderung von Kunden und Instituten nach internetbasierten Lösungen im Electronic Banking.


Ziel dieser Erweiterung war es, den einheitlichen und multibankfähigen Bankenstandard "DFÜ mit Kunden" für Übertragungsmöglichkeiten im Internet auszubauen und die damit verbundenen Anwendungsmöglichkeiten zu erweitern. Hierfür werden den aktuellen Sicherheitsanforderungen entsprechende Sicherungsmechanismen wie HTTPS mit einer zusätzlichen starken Authentifizierung für die Kommunikationssicherheit eingesetzt.

EBICS zeichnet sich durch folgende Eigenschaften aus:
  • ein Standard für alle Kreditinstitute und Kunden, d. h. Firmenkunden erreichen mit einer Software jedes Kreditinstitut, das EBICS anbietet
  • offener Standard, d. h. Firmenkunden können Standardprodukte oder  individuelle Software einsetzen
  • moderne Technologie, lizenzfreie internationale Standards wie XML, HTTPS, TLS, ZIP
  • höchste Sicherheitsstandards, z. B. Verschlüsselung auf Transportebene und Ende-zu-Ende
  • ein Transportmittel für alle Geschäftsprozesse wie Lastschriften, Überweisungen, Kontoauszüge, Cash-Management, Wertpapierorder und vieles mehr
  • Einbeziehung von Dienstleistern durch mehrstufiges Unterschriftskonzept
  • standortunabhängige Freigabe von Aufträgen
  • Preis und Leistung bestimmen den Wettbewerb, nicht die Technik und die mit einem Wechsel der Bankverbindung verbundenen Umstellungsaufwände
Neben der Kunde-Bank-Kommunikation wird EBICS in Deutschland und zunehmend auch in anderen Ländern der EU für den sicheren und sehr kostengünstigen Austausch von Zahlungstransaktionen zwischen den Banken eingesetzt. Nicht zuletzt die Bereitstellung eines Auflieferungskanals für EBICS-Transaktionen bei der EBA Clearing führte zu einer signifikanten Steigerung der über EBICS im Interbankenbereich ausgetauschten Transaktionen, sodass mittlerweile rund fünf Prozent aller von der EBA Clearing verarbeiteten SEPA-Transaktionen über die EBICS-Kommunikation abgewickelt werden. Neben dem Einsatz im bilateralen Clearing von Zahlungen wird EBICS zunehmend auch als Backup-Lösung neben den bereits bestehenden Kommunikationskanälen, wie z. B. SWIFT sie anbietet, genutzt.

Die im Jahr 2003 gewählte englische Bezeichnung „EBICS“ unterstrich bereits damals den Anspruch, mit diesem Kommunikationsstandard nicht nur auf nationaler Ebene, sondern vielmehr auch auf europäischer Ebene eine sowohl für Banken als auch für deren Kunden interessante Alternative zu bestehenden Verfahren anzubieten.

In Deutschland bestand bereits seit 1. Januar 2008 die bankseitige Verpflichtung zur Unterstützung von EBICS. Der alte Standard FTAM wurde hier mittlerweile vollständig durch EBICS ersetzt.
Im Jahr 2008 wurde ein Kooperationsabkommen zwischen Deutschland und Frankreich hinsichtlich EBICS geschlossen. Die französische Kreditwirtschaft hatte im Vorfeld nach einer umfangreichen make-or-buy-Analyse erkannt, dass EBICS die Anforderung der französischen Banken und deren Kunden am umfassendsten abdeckt und somit das größte Potenzial für eine Ablösung des bis dahin verwendeten ETEBAC-Kommunikationsstandards besaß. Schnell kristallisierte sich für die beteiligten Banken und Verbände heraus, dass eine rechtssichere Verwendung von EBICS durch alle Nutzer am besten durch Gründung einer gemeinsamen EBICS-Gesellschaft sichergestellt werden kann. Der Zweck der EBICS-Gesellschaft liegt dabei vor allem in der Weiterentwicklung und Pflege des EBICS-Standards und dem Halten der Markenrechte.

Nach intensiven Verhandlungen zwischen der deutschen und der französischen Kreditwirtschaft konnte im Juni 2010 die EBICS-Gesellschaft gegründet werden. Bei der Gestaltung der nach belgischem Recht gegründeten EBICS SCRL wurde streng darauf geachtet, dass die Gesellschaft nicht profitorientiert ist und sehr schlank, d.h. zu minimalen laufenden Kosten, aufgesetzt wird. Zudem wurde dafür gesorgt, dass die Gesellschaft offen für den Zugang anderer an EBICS interessierter Kreditwirtschaften ist.

Mit der Gründung der Gesellschaft wurde somit die Basis für den europaweiten Einsatz und damit der Weiterentwicklung des EBICS-Verfahrens hin zu einem europäischen Marktstandard geschaffen. Im April dieses Jahres erfolgte mit der Beitrittserklärung der SIX Interbank Clearing als Vertreter der Schweizer Kreditwirtschaft ein weiterer wichtiger Schritt in Richtung Europäisierung von EBICS.
Erklärtes Ziel ist es nunmehr, auch Kreditwirtschaften in anderen EU-Ländern von den Vorteilen einer Nutzung und vor allem Mitgestaltung von EBICS zu überzeugen – die Türen für eine Beteiligung an der EBICS-Gesellschaft stehen weit offen.

Axel Weiß

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