EBICS – Chancen der Internationalisierung

Thomas Stosberg, GTB Product Management, Deutsche Bank AG

Die Schweiz ist als drittes Land neben Deutschland und Frankreich der EBICS-Gesellschaft beigetreten und markiert damit den nächsten Schritt zur Internationalisierung von EBICS. Hat EBICS das Potenzial zu einem internationalen Standard und ist dieser im Interesse von Kunden und Banken?


Die verschiedenen Gremien eines Landes, die sich mit der Abwicklung von (nationalem) Zahlungsverkehr beschäftigen, sind bestrebt, im Interesse von Kunden und Banken eine stabile und standardisierte Zahlungsverkehrslösung anzubieten. Die Adaption eines neuen Standards setzt immer eine starke Motivation voraus – meistens resultierend aus Problemen mit der technischen Sicherheit und/oder den Kosten für den Betrieb der bisherigen Lösung; oder anders formuliert: Länder mit einer praktikablen Lösung für alle lokalen Marktteilnehmer werden sich mit hoher Wahrscheinlichkeit nicht mit der Adaption eines neuen Standards auseinandersetzen. Für alle Länder, die sich aber mit einem neuen Standard beschäftigen, könnte EBICS eine geeignete Option sein.

Die Kunden-Sicht

Die Zielkunden von EBICS – Unternehmen jeder Größe, von Kleinstbetrieben bis zu internationalen Konzernen – suchen eine Zahlungsverkehrslösung, die zwei Grundvoraussetzungen erfüllt: zum einen geringe Kosten und zum anderen eine einfache, sichere, revisionskonforme, automatisierte und standardisierte Anbindung der eigenen Infrastruktur an alle Banken (bezogen auf die Bankkommunikation und die genutzten Zahlungsverkehrsformate). Letztere erlaubt eine gleichartige Integration aller Bankpartner mit der Möglichkeit, den Zahlungsverkehr flexibel auf verschiedene Banken zu verteilen und auf technische Probleme im Rahmen einer Notfallplanung reagieren zu können.

EBICS kann diese Anforderungen aus Kundensicht vollständig erfüllen. Bezogen auf die Implementierung in Deutschland kann sogar die vollständige Prozessautomatisierung durch den Einsatz digitaler Signaturen ohne Nutzung von Zertifikaten und einer „Corporate Seal“-Autorisierung erreicht werden.

Die Weiterentwicklung, im deutschen Markt das CGI-MP-XML-Format für die Abwicklung von weltweitem Zahlungsverkehr anzubieten, hat zusätzlich die Grundlage geschaffen, EBICS als globale Bankkommunikation alternativ zu einer SWIFT- bzw. einer Host-to-Host-Anbindung für Kunden zu etablieren.

Die Bank-Sicht

Banken können zukünftig nicht mehr mit proprietären technischen Lösungen am Markt bestehen. Eine bankindividuelle technische Lösung (Bankkommunikation und Zahlungsverkehrsformat) wird von Kunden weder positiv als Alleinstellungsmerkmal und Verkaufsargument wahrgenommen, noch kann sie aus Bankensicht als betriebswirtschaftlich rentable Lösung eingesetzt und gepflegt werden.
Entsprechend wird der Wettbewerb zwischen Banken ausschließlich auf der Grundlage von angebotenen Bankdienstleistungen und deren Preis stattfinden. Die Erwartungshaltung der Kunden ist, dass die zugrundeliegende technische Lösung für Zahlungsverkehr ähnlich standardisiert ist wie Strom aus der Steckdose.

Die Einführung von EBICS in Frankreich hat gezeigt, dass die Auswirkungen eines gemeinsamen Standards auf die eigene Kundenbasis und die Erträge eher gering sind. Dies hängt damit zusammen, dass die Kundenschnittstellen beider Länder unterschiedlich sind und generell Kunden die Auswahl ihrer Bankbeziehungen nicht von den angebotenen Zugangskanälen abhängig machen.
Bezogen auf die Kundenschnittstelle bietet EBICS für Banken die Möglichkeit, einen solchen standardisierten Service für mehrere Länder anzubieten. Daneben kann EBICS auch als Clearing-Zugang für SEPA-Zahlungen verwendet werden.


EBICS als Chance zur Internationalisierung 
      
EBICS ist aus Kundensicht eine attraktive Bankkommunikation. Für Banken bietet sich mit EBICS die Möglichkeit einen standardisierten Zugang für mehrere Länder auf Grundlage einer Infrastruktur anzubieten. Dies ist auch dann zutreffend, wenn eine Bank primär nur in einem Land tätig ist, da man eigene Kunden mit Niederlassungen im SEPA-Raum ohne größere Investitionen unterstützen könnte. Durch die bereits erfolgte Adaption von EBICS in den beiden größten europäischen Ländern und der Schweiz gibt es schon jetzt eine signifikante Anzahl von EBICS-Nutzern außerhalb der Kernmärkte, die sich stetig erhöht und ebenfalls zur offiziellen Etablierung in anderen Ländern und bei weiteren Banken beitragen wird. Eine weitere Verbreitung von EBICS wäre zum Vorteil aller Marktteilnehmer und ist für Länder mit entsprechendem Handlungsdruck die mit Abstand beste Option für die Neugestaltung der Abwicklung des Zahlungsverkehrs.

Thomas Stosberg

Weiterlesen

Wie sich EBICS verbessern lässt, Teil 7 – Automatisches Bankschlüssel-Update: Geht das überhaupt?

Gemäß EBICS-Spezifikation werden Daten stets signiert und verschlüsselt übertragen. Dies gilt für beide Kommunikationsrichtungen: Kunde > Bank und Bank > Kunde. In Deutschland sind die dafür verwendeten Schlüssel theoretisch unbegrenzt gültig. In Frankreich ist zumindest die Gültigkeit der Zertifikate limitiert. Aus Sicherheitsgründen ist es unabdingbar, dass die Schlüssel regelmäßig erneuert werden. Für die Kundenseite bringt EBICS bereits Funktionen für einen automatisierten Schlüsselwechsel eines einmal initialisierten EBICS-Teilnehmers mit. Die automatisierte Erneuerung der Bankschlüssel hingegen gestaltet sich in der Praxis schwieriger. Ein „weicher Schlüsselwechsel“ ist eine Lösung.


Weshalb Banken ihre EBICS-Schlüssel ungern wechseln

Das EBICS-Kundensystem kann die öffentlichen Bankschlüssel zur Authentifikation (Identifikation der Bank) und Verschlüsselung der Datei-Einreichungen mit der Auftragsart HPB bei der Bank herunterladen. Falls das Kundensystem ungültige oder nicht mehr aktuelle Bankschlüssel nutzt, erhält es gemäß der EBICS-Spezifikation den negativen Return-Code EBICS_BANK_PUBKEY_UPDATE_REQUIRED.

Dies zieht folgende Probleme nach sich:

• Sobald der EBICS-Client den Return-Code EBICS_BANK_PUBKEY_UPDATE_REQUIRED erhält, sollte er die aktuellen Bankschlüssel per HPB abholen. Dieser Prozess wird von EBICS-Clients nicht immer hinreichend unterstützt.
• Nach einer erneuten Abholung der Bankschlüssel müssen Schlüssel, die nicht CA- und zertifikatsbasiert sind, im EBICS-Client manuell per Hashwert-Eingabe freigeschaltet werden.
• EBICS-Clients sind häufig automatisiert im Einsatz. Die Notwendigkeit, bei der Erneuerung der Bankschlüssel manuell eingreifen zu müssen, z. B. erneute Schlüsselabholung oder Schlüsselfreischaltung, wird meistens nicht oder zu spät erkannt. Störungen sind somit vorprogrammiert.

Aus diesen Gründen schrecken Betreiber von EBICS-Bankrechnern vor einem Wechsel der Bankschlüssel zurück. Die folgenden Maßnahmen können Abhilfe schaffen.

Der Weg zum unbeschwerten Bankschlüssel-Wechsel

Um Bankschlüssel und ‑zertifikate ohne Probleme regelmäßig erneuern zu können, sollte zunächst ein „weicher Schlüsselwechsel“ ermöglicht werden. Das heißt, nicht alle Kunden müssen von einem auf den anderen Tag ihre Bankschlüssel aktualisieren.

Ein solcher weicher Schlüsselwechsel ist möglich, wenn der EBICS-Bankrechner mit alten und neuen Bankschlüssel-Paaren parallel arbeiten kann. EBICS-Clients, die einen Wechsel erkennen und die Aktualisierung (ggf. auch automatisch) durchführen, nutzen den neuen Schlüssel, die anderen Clients weiter den alten. Im letzteren Fall kann die Bank die betreffenden Kunden ansprechen.

Als weitere Maßnahme muss der EBICS-CR EB-14-12 auf Client- und Serverseite umgesetzt werden. Der CR ist für die nächste EBICS-Spezifikation beschlossen und sieht u. a. vor, dass bei der Bankschlüssel-Abholung die neuen Bankschlüssel mit dem alten Bank-Authentifikationsschlüssel signiert sind (siehe www.ebics.org). Lediglich bei der ersten Bankschlüssel-Abholung ist dann noch eine manuelle Freischaltung im EBICS-Client erforderlich. Bei jedem weiteren HPB-Auftrag wird die Signatur geprüft, und die Bankschlüssel werden somit nach erfolgreicher Prüfung im EBICS-Client automatisch freigeschaltet.

Mit diesem Funktionsumfang ist es möglich, die Bankschlüssel vollautomatisiert zu erneuern.

Michael Lembcke 

Weiterlesen

SIBOS 2015: Zahlungsverkehr in Bewegung

Auf der SIBOS in Singapur spielt traditionell SWIFT die Hauptrolle und EBICS eine Nebenrolle. Dennoch war das Interesse am Einsatz und der zukünftigen Entwicklung von EBICS groß. Mehr als 8.000 Besucher kamen zur Ausstellung ins Sands Expo and Convention Centre. Damit war die SIBOS in Singapur die größte in Asien und die zweitgrößte insgesamt. Die beherrschenden Themen zeigen: Es kommen weitere große Veränderungen auf den Zahlungsverkehr zu.

EBICS BTF


Mit dem Beitritt der Schweiz zur EBICS-Gesellschaft hat die Verbreitung von EBICS weiter Fahrt aufgenommen. Bisher sind zwei EBICS-Dialekte gebräuchlich: in Deutschland und in Frankreich. Die Schweizer werden einen weiteren Dialekt hinzufügen. Damit EBICS sich für weitere Länder öffnet, steht eine Vereinheitlichung an: EBICS BTF.

Hinter EBICS BTF steht der Wille aller drei Länder, einen einheitlichen EBICS-Standard zu entwickeln. Die Arbeiten dazu laufen auf Hochtouren. Mehr Informationen zu EBICS BTF lesen Sie bald in diesem Blog.

Digitalisierung


Der Zahlungsverkehr ist in einigen Ländern hochautomatisiert. Die Prozesse im Zahlungsverkehr sind fast vollständig digitalisiert, beziehen ein oder mehrere Partner ein und reichen weit über die eigenen Systemgrenzen hinaus. Typische Beispiele sind SWIFT oder EBICS, mit denen man strukturiert Informationen zwischen Partnern austauschen kann.

Andere Bereiche im Bankwesen können von der Erfahrung des Zahlungsverkehrs profitieren. Der hohe Grad der Digitalisierung lässt sich beispielsweise auf Kredite, Avale oder dokumentäres Geschäft übertragen. Dies scheint der Trend für die nächsten Jahre zu sein.

Backup der Zahlungsverkehrsströme


Die Geldmengen im Zahlungsverkehr sind astronomisch. TARGET 2 setzt fast eine Billarde Euro pro Jahr um – eine Eins mit fünfzehn Nullen! Es ist klar, diese Räder dürfen im Zahlungsverkehr nicht still stehen.

Daher wird der Ruf nach einem Backup für den Transport der Zahlungsströme immer lauter. EBICS bietet sich quasi als natürlicher Partner von SWIFT an. Es kursieren die ersten Gerüchte, dass Empfehlungen – noch werden es nur Empfehlungen sein – ausgesprochen werden, den digitalen Geldtransport durch ein zweites Verfahren abzusichern.

Regulatorische Veränderungen


In der Vergangenheit haben die regulatorischen Anforderungen den Zahlungsverkehr dominiert. Die besten Beispiele sind SEPA und ISO 20022. Nach unserer Einschätzung werden in den nächsten zwei Jahren ca. 30 neue Trends und Vorhaben im Zahlungsverkehr kommen – die meisten davon durch den Regulator getrieben. Die Auswirkungen auf die IT reichen von den Einlieferungssystemen über das Clearing bis zum Kernbanksystem. Insgesamt sind alle Systeme im Zahlungsverkehr betroffen. Es wird also nicht langweilig.

Michael Lembcke 

Weiterlesen

Migration Zahlungsverkehr Schweiz: echte End-to-End-Tests mit EBICS

Auf dem Finanzplatz Schweiz arbeiten die Banken mit Hochdruck an den Umsetzungsprojekten für die Harmonisierung des Schweizer Zahlungsverkehrs nach ISO 20022. Softwarehersteller und Firmenkunden fordern Testmöglichkeiten für die neuen Zahlungsformate. Gesucht ist ein End-to-End-Testszenario, das die produktive Verarbeitung seitens der Bank bestmöglich abbildet. In der Schweiz können die wenigsten Banken solche Tests anbieten. Dabei kann EBICS helfen.


Die SIX Interbank Clearing, verantwortlich für die Publikation der Schweizer Implementierung, bietet eine sogenannte Validierungsplattform an. Dort können die jeweiligen Meldungen (pain und camt) bezüglich Syntax und einfachen Business-Regeln validiert werden. In der Regel ist dies die erste Anlaufstelle für Tests in der neuen ISO-Welt. Für Hersteller und Kunden reicht diese Prüfung jedoch nicht aus, um anschliessend die produktiven Zahlungsläufe mit ihrer Bank umzustellen.

Taugliche End-to-End-Tests umfassen die Aufträge als Buchungen in die elektronischen Kontoauszüge (z. B. MT940 oder camt.053) und Avisierungen (z. B. MT942 oder camt.052) inklusive Saldo-Nachführung sowie ein Fehlerverhalten, welches der Produktion entspricht (Ausweisung entsprechender Status-Rapporte und Storno-Buchungen). „Die Schwierigkeit von Tests ist oft die Avisierung, welche aufgrund der eingelieferten Daten sich entsprechend verhält“, weiß Christoph Schenker von der PostFinance. „Die Testplattplattform http://isotest.postfinance.ch bietet alle Möglichkeiten, welche der Softwarehersteller für Ein- und Auslieferungen benötigt, um seine Software für den Kunden ‚ISO-ready‘ zu machen.“

Gerade den Fehlerfall möchte der Kunde vor der Einführung simulieren, um seine internen Prozesse der Ausnahmebehandlung zu testen. Typischerweise sind dies Fehler wie „ungenügende Deckung“, „falsches Begünstigtenkonto“ und ähnliche Ausnahmefälle, welche in der Folge im produktiven Betrieb auftreten können.

Fasst man End-to-End etwas weiter, wäre es für den Firmenkunden ideal, wenn er direkt aus seiner ERP-Software mittels EBICS einen Zahlungslauf an eine Testinfrastruktur senden und wiederum mittels EBICS die dazugehörigen Downloads ausführen kann. Nur dann ist ein echter „proof of the pudding“ möglich. Simuliert werden müssen insbesondere die Rückmeldungen bei Fehlern und die Verarbeitung realer Dateigrössen – d. h. ein produktiver Kreditorenlauf mit einigen hundert Zahlungen oder mehr, nicht nur eine Testzahlung. So ist die nötige Sicherheit für einen Produktionsstart gegeben. Die direkte Anbindung einer Testplattform über EBICS ermöglicht es, Testzyklen zu automatisieren und via EBICS-Protokoll grosse Dateien zu übermitteln. Dies ist mit einer Testplattform, welche nur über eine manuelle Web-Upload-Schnittstelle verfügt, nur schwer möglich.

Innovative Schweizer Banken sehen in der Kombination von ISO 20022 und EBICS das ideale Tandem, um ihre Kunden in der Harmonisierung des Zahlungsverkehrs zu unterstützen. Institute, welche zusätzlich eine echte End-to-End-Testmöglichkeit anbieten können, bieten ihren Kunden einen echten Mehrwert. „SAP unterstützt den Credit Transfer mit ISO 20022 schon seit mehreren Jahren. Gute Testplattformen und direkte Ansprechpartner bei Finanzinstituten unterstützen die weitere Umsetzung von ISO20022-Meldungen in der Schweiz“, sagt Rainer Hofmeister vom Hersteller SAP.

Carsten Miehling

Weiterlesen

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 

Weiterlesen

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 

Weiterlesen

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

Weiterlesen

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 

Weiterlesen

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 

Weiterlesen

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ß

Weiterlesen

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 

Weiterlesen

Hochverfügbarer Zahlungsverkehr mit EBICS und SWIFT

Der europäische Interbanken-Zahlungsverkehr bewegt täglich mehrere Billionen Euro. Dieses gigantische Volumen wird bilateral und über nationale sowie europäische Clearer abgewickelt, beispielsweise TARGET2, STEP2 und SEPA-Clearer. Für die Wirtschaft und für unser gesamtes Leben ist ein ungehinderter Geldfluss essenziell. Deshalb sind die beteiligten IT-Systeme hoch sicherheitskritisch. Nur die redundante Nutzung der beiden Transportprotokolle EBICS und SWIFT stellt den erforderlichen hochverfügbaren Transport sicher.


Erstaunlicherweise sind die notwendigen Redundanzen im Gesamtprozess nicht konsequent umgesetzt. Hochverfügbarkeit wird meistens über redundante In-House-Systeme gewährleistet. Ein wesentlicher Schwachpunkt bei einen Systemausfall – der Single Point of Failure – bleibt jedoch bestehen: das elektronische Transportverfahren; auch dieses muss für den Störfall redundant ausgelegt sein.

SWIFT und EBICS sind die beiden gebräuchlichsten Transportprotokolle im internationalen Zahlungsverkehr. Sie garantieren hohe Übertragungssicherheit und großen Durchsatz – beides Voraussetzungen für eine Dual-Transport-Strategie. Zudem müssen die Systeme unabhängig voneinander sein. Dies ist nur mit einer Dual-Vendor-Strategie gewährleistet. Der Schlüssel zur Hochverfügbarkeit ist also die Kombination aus Dual-Vendor-Strategie und Dual-Transport-Strategie.
Die Dual-Vendor-Strategie wird bereits in hoch sicherheitskritischen Szenarien eingesetzt, um die Ausfallsicherheit zu erhöhen. Damit kann das System eines Herstellers nicht mehr der Single Point of Failure sein.

Betrachten wir die Dual-Transport-Strategie mit SWIFT und EBICS: Die Netzwerktopologien beider Transportprotokolle sind komplementär:

	SWIFT	EBICS
Topologie	sternförmig	vermascht
Management	managed	self-managed
Ausfall	zentral	selbstheilend
Übertragungsart	Kabel	Kabel und Satellit

Bei EBICS werden Störungen durch Selbstheilung behoben, d. h. die Daten werden automatisch umgeleitet. Dagegen wird bei SWIFT das sternförmige Netz zentral verwaltet. Diese Komplementarität ist bei Störungen von Vorteil, da sie einen Single Point of Failure inhärent ausschließt. SWIFT und EBICS sind durch die Dual-Vendor-Strategie unabhängig voneinander und daher prädestiniert für eine Dual-Transport-Strategie.

Im Störungsfall bei EBICS kann die Bank oder das Clearing-Unternehmen den technischen Übertragungsweg beeinflussen. Falls die terrestrischen Leitungen ausfallen, kann auf Funk oder extraterrestrische Systeme – also Satelliten – umgeschaltet werden. Per Satellit ist der gesamte besiedelte Erdball zu erreichen. Dies ist ein Vorteil von EBICS gegenüber Managed Networks wie SWIFT.

Aber wie sieht es in der Praxis aus? Angesichts der Risiken im Interbanken-Zahlungsverkehr ist die Kombination aus Dual-Transport-Strategie mit EBICS und SWIFT und Dual-Vendor-Strategie nur angemessen. Daher ist es auch nicht verwunderlich, dass Services wie STEP2 der EBA Clearing und SEPA-Clearer der Deutschen Bundesbank sowohl EBICS als auch SWIFT anbieten und zudem die Dual-Vendor-Strategie einsetzen. Ein Wechsel zwischen den beiden Transportprotokollen ist in kurzer Zeit untertägig möglich. Deutsche Banken und eine französische Bank nutzen derzeit schon EBICS und SWIFT, um Schäden durch Ausfälle zu minimieren. Weitere europäische und auch amerikanische Banken werden sicherlich folgen.

Erstaunlich ist nur, dass der Regulator dieses Feld noch nicht betreten hat. Die Auswirkungen eines Störfalls wären unabsehbar.

Michael Lembcke 

Weiterlesen

EBICS als europäischer Standard für Mobile Payments?

Angesichts der aktuellen Entwicklungen beim Thema Mobile Payments verliert man leicht den Überblick. Neue Lösungsanbieter schiessen fast täglich aus dem Boden, und die technischen Standards wuchern vielfältig. Die Banken laufen Gefahr, in einem wachsenden Geschäftsfeld abgehängt zu werden. Könnte ein europäischer Standard wie EBICS da helfen?


Für mobile Zahlungen gelten dieselben Regeln wie für den transaktionsbasierten EBICS-Zahlungsverkehr: Es geht um sichere Kommunikation, eindeutige Authentisierung und die Vertraulichkeit von Auftrags- und Stammdaten. Bei Mobile Payments heißt das dann „Secure Element“ (SD-Karte, SIM, HCE, etc.), und es ist die Rede von den verschiedenen Übertragungstechniken (QR-Code, Barcode, NFC, BLE etc.). Nichts scheint aktuell geregelt zu sein, zumal verschiedenste Akteure in den Markt eintreten: von den grossen Kreditkarten-Anbietern über Hardware-Produzenten (Apple, Samsung) bis hin zu spezialisierten Dienstleistern wollen im Moment alle den Banken den Zahlungsverkehr streitig machen. Für Banken ist die Aufgabe sehr anspruchsvoll, denn nicht alle Institute werden auf alle Pferde gleichzeitig setzen können.
Für einheitliche und sichere Transaktionen im Zahlungsverkehr bräuchten App-Entwickler und Kunden ein Standardprotokoll wie EBICS oder FinTS. Solche Standards sind im übrigen Payments-Umfeld gut etabliert, und mit dem Format ISO 20022 und SEPA als Regelwerk wären ca. 400 Millionen europäische Kontoinhaber sofort erreichbar. Erste Umsetzungen von Standards für mobile Zahlungen finden sich z. B. in der Lösung Jiffy von SIA Italien, die komplett auf SEPA setzt.
Für Konsumenten und Banken hätte dies zudem den Vorteil, dass keine Dritten an den Transaktionsgebühren partizipieren, wie das insbesondere bei Kreditkartenzahlungen – und zusätzlich bei ApplePay – der Fall ist. Die Institute bekämen die Kontrolle über den Markt zurück. Organisationen wie das European Payments Council (EPC) könnten den Standard in Europa einführen und weiterentwickeln.

Vielleicht ist es etwas gewagt, EBICS als Standard für Mobile Payments zu bezeichnen, da EBICS in erster Linie für die asynchrone Verarbeitung entwickelt worden ist. Meine Blog-Kollegen haben jedoch schon auf entsprechende Erweiterungspotenziale von EBICS hingewiesen: Die Interaktionen müssten in Echtzeit ablaufen. Pro Einzeltransaktion wäre eine synchrone Rückmeldung erforderlich. Wenn dann in naher Zukunft noch das Realtime-Clearing in ganz Europa etabliert sein wird, ergibt das Ganze vielleicht Sinn. Auf Rückmeldungen bin ich gespannt.

Carsten Miehling 

Weiterlesen

Warum Banken alte EBICS-Versionen abschalten sollten

Haben Sie noch den Überblick über die verfügbaren EBICS-Versionen? Auf welchem Stand ist Ihr EBICS-Client? Welche Versionen lässt der Bankrechner zu? Dieser Artikel gibt einen Überblick und erklärt, was ein Wildwuchs an Versionen für die Nutzer zur Folge hat.


EBICS wird in Deutschland seit dem 1. Januar 2008 mit der Version 2.3 offiziell eingesetzt. Davor wurden bereits EBICS-Leistungen ab der Version 2.0 von einigen Kreditinstituten angeboten. Die erste gemeinsam mit Frankreich entwickelte Version ist die Version 2.4, die in der finalen Fassung 2.4.2 seit dem 16. Februar 2010 gültig ist. Die aktuelle verfügbare EBICS-Version ist die Version 2.5 vom 16. Mai 2011, die vorrangig in Deutschland und der Schweiz von den Kreditinstituten angeboten wird. Eine neue Version 2.6 ist voraussichtlich für 2016 derzeit in Vorbereitung. Zählt man nun alle veröffentlichten Versionen zusammen, so kommt man auf insgesamt 6 (ohne die zukünftige 2.6), zu denen es passende Bankrechner- und Kundensystem-Implementierungen gab und gibt.

Kunde und Bank benötigen eine gemeinsame EBICS-Version

Das EBICS-Protokoll basiert auf XML-Strukturen. Eine neue EBICS-Version ist neben den inhaltlichen Änderungen und Neuerungen im Wesentlichen durch eine neue XML-Schema-Version gekennzeichnet. Ein EBICS-Kundensystem kann mittels der Auftragsart HEV auf Basis der neutralen Schema-Version H000 die vom jeweiligen Bankrechner unterstützen Versionen abfragen und dann im positiven Fall die Kommunikation mit der aktuellsten gemeinsamen Version fortführen. Ein EBICS-Bankrechner und ein EBICS-Kundensystem können demnach nur dann fehlerfrei miteinander kommunizieren, wenn sich beide auf Basis der gleichen EBICS-Version austauschen. Wäre die Vielfalt der zulässigen Versionen zu groß, würde das Risiko steigen, dass die Kommunikationspartner nicht über eine gemeinsame Version verfügen. Ein Datenaustausch wäre nicht möglich.
Ein EBICS-Bankrechner, der immer alle möglichen EBICS-Versionen unterstützt, wäre mindestens wartungsaufwendig. Außerdem würden sämtliche Verbesserungen, die nur neuere Versionen beinhalten, durch die Nutzung alter Versionen unterlaufen, darunter auch wichtige Sicherheitsfunktionen. Daher hat man sich bei der EBICS-Spezifikation darauf verständigt, bankseitig immer nur die aktuelle und die vorherige EBICS-Version zwingend zu unterstützen.

Updates werden verschlafen – das birgt Risiken

In der Praxis kann das anders aussehen. Kunden versäumen es, zum Teil auch aus Unkenntnis, ihr EBICS-System auf die aktuelle Version zu aktualisieren. Banken versäumen es, die Kunden darauf hinzuweisen und lassen weiterhin auch ältere EBICS-Versionen zu. Der Überblick geht verloren und das beschriebene Risiko nimmt zu.

Daher empfehlen wir den Kreditinstituten, neben den eigenen auch die von ihren Firmenkunden genutzten EBICS-Versionen im Auge zu behalten und ggf. Kunden rechtzeitig zu Updates zu raten. Alte Versionen sollten von den Kreditinstituten bewusst nicht mehr unterstützt und sogar abgeschaltet werden. Firmenkunden selbst sollten von sich aus die Versionen ihrer EBICS-Software auf dem aktuellen Stand halten und regelmäßige Updates einplanen.

Wichtig dabei ist, den Überblick über die genutzten EBICS-Versionen zu behalten und Risiken durch regelmäßige Updates zu reduzieren. Denn im nächsten Jahr wird es voraussichtlich heißen: „EBICS 2.6 gilt“.

Michael Lembcke 

Weiterlesen

“EBICS as a Service” – Ein Betriebsmodell für mittlere und kleinere Finanzinstitute

Dass sich EBICS als Protokoll im Transaction Banking in der Schweiz durchsetzen wird, ist eigentlich unbestritten. Großbanken und größere Kantonalbanken bieten es bereits an oder sind dabei, eine EBICS-Schnittstelle für Ihre Firmenkunden zu implementieren. Der nächste Schritt wäre eine gemeinsam nutzbare „EBICS as a Service“-Plattform, für die sich jedoch noch ein Anbieter finden muss. 


Die Vorteile einer sicheren, standardisierten und kostengünstigen Punkt-zu-Punkt-Kommunikation sind offensichtlich, so dass das Thema inzwischen auch auf der Agenda von kleineren und mittleren Finanzinstituten auftaucht. Je nach Institut und der anvisierten Anzahl Kunden, welche über EBICS angebunden werden sollen, erscheint manchem Management der Initialaufwand für die Beschaffung, die Installation und den Betrieb eines EBICS-Produktes als sehr hoch.

Fairerweise muss man diesen Bedenken auch als Produktanbieter Rechnung tragen, denn die Umsetzung eines EBICS-Projektes resultiert in einem fünf- bis sechsstelligen Betrag – für manch kleinere Bank ein bedeutender Posten im Budget. Insbesondere in der Schweiz, wo es rund hundert Institute in diesem Segment gibt, wie zum Beispiel kleinere Kantonal- oder Privatbanken, stellt sich die Frage: Warum bietet noch kein Anbieter „EBICS as a Service“ im hiesigen Markt an? Die Vorteile der gemeinsamen Nutzung einer EBICS-Plattform liegen eigentlich auf der Hand und es gäbe auch prädestinierte Anbieter im Markt, welche so ein Angebot auf die Beine stellen könnten.
Analog der Outsourcing-Services für den Betrieb von Banken-Plattformen könnte ein mandantenfähiges EBICS-Modell implementiert werden. Bereits ab einer geringen Anzahl Bankteilnehmer rechnet sich der Business Case und es entsteht eine Win-Win-Situation für alle Akteure. Der Anbieter der Lösung kann mit einem erweiterten Service-Angebot auftreten und amortisiert bei steigender Verbreitung und Nutzung des Standards die Investition in Kürze. Kunden, in dem Fall Banken, können zu geringen Investitions- und reduzierten Betriebskosten ihren Firmenkunden diesen Zugang anbieten und somit in Bezug auf die Anschlussmöglichkeiten zu den Großbanken aufschließen.

Was braucht es jetzt noch? Natürlich ein entsprechendes Produkt, welches auf den Mandanten-Betrieb ausgelegt und bezüglich Operating-Funktionalitäten auf den Betrieb im Rechenzentrum optimiert ist. Des Weiteren einen innovativen Anbieter für Banken-IT-Lösungen, welcher hier als erster in die Bresche zu springen bereit ist. Kandidaten gäbe es in der Schweiz wie gesagt einige, angefangen bei den Betreibern von Avaloq- oder Finnova-Lösungen über klassische Rechenzentren bis hin zu Insourcing-Lösungen größerer Institute.

Wir sind gespannt, wer sich diese Option im Schweizer Markt sichern wird.

Carsten Miehling 

Weiterlesen

EBICS-Event stößt in Luxemburg auf großes Interesse

Der EBICS-Standard ist dabei, sich in Europa weiter zu verbreiten. Mit Interesse schauen Fachleute daher auch auf den Finanzplatz Luxemburg. Am 28. Januar 2015 versammelten sich dort Zahlungsverkehrsexperten aus dem Fachbereich und der IT der Luxemburgischen Banken, um mehr über EBICS zu erfahren. Zu dem Event mit dem Titel „EBICS – A New Communication Protocol for Payment Activities“ hatte die Luxemburgische Bankenvereinigung ABBL geladen.


Im Mittelpunkt stand die Frage, ob EBICS für Luxemburg von Interesse sein könnte. Die Agenda war auf diese Fragestellung ausgerichtet, vertreten waren folgende Sprecher und Themen:

• Welcome, Serge Wagener, Banque et Caisse d’Epargne de l’Etat
• EBICS at a Glance - Security, Use and Implementations, Hermann Fürstenau, PPI AG
• EBICS - a chance to harmonise customer-to-bank communication standards for electronic banking in Europe, Axel Weiß, EBICS Chairman
• EBICS Strategy of Deutsche Bank, Thomas Stosberg, Deutsche Bank
• STEP2 and EBICS, Katja Heyder, EBA Clearing

EBICS wurde dabei unter den Gesichtspunkten Kunde-Bank- und Interbank-Kommunikation beleuchtet, mit besonderem Fokus auf der sicheren Datenübertragung mit EBICS über das Internet. Zu den relevanten Themen für die luxemburgischen Experten zählten auch die Verteilte Elektronische Unterschrift sowie die Unterschiede zwischen der französischen und der deutschen EBICS-Ausprägung.

Der STEP2-Zugang über EBICS zur europäischen Zahlungsverkehrsdrehscheibe war ebenfalls von besonderem Interesse für die Luxemburgische Banken-Community, weil sich dadurch die Kosten reduzieren lassen und ein Backup die Ausfallsicherheit erhöht. Die möglichen Einsatzszenarien für STEP2 und EBICS müssen individuell für jede Bank einzeln betrachtet werden. Wenn ein Backup allerdings unter regulatorischen Maßgaben gefordert werden sollte – was derzeit möglich erscheint – ist EBICS die beste Lösung. Bereits heute schon operieren einige Banken aus Sicherheitsgründen mit zwei unterschiedlichen Infrastrukturen: SWIFT und EBICS. Die komplementären Netz-Topologien von EBICS und SWIFT eignen sich hervorragend als gegenseitiges Backup. Aber auch die Kosten sind häufig ein ausschlaggebender Grund für die Nutzung von EBICS.

Eine wesentliche Motivation für die Luxemburgischen Banken ist natürlich, dass Deutschland und Frankreich einen gemeinsamen EBICS-Standard entwickelt haben. Darüber hinaus wird der EBICS-Standard von einer schlanken EBICS-Gesellschaft mit Sitz in Brüssel weiterentwickelt und weiter verbreitet. Die Schweiz ist dabei, in die EBICS-Gesellschaft aufgenommen zu werden. Vielleicht könnte ja Luxemburg als 4. Mitglied folgen.

Die Idee eines "Global EBICS" ist für einige Banken von strategischer Bedeutung, was auch während der Diskussion in Luxemburg deutlich wurde. "Global EBICS" – oder kurz GBICS – geht mit einem einheitlichen ISO20022-Format à la CGI (Common Global Implementation) einher. CGI dient dabei als einheitlicher Formatstandard und GBICS als einheitlicher Transportstandard und das weltweit. Spannend war in diesem Zusammenhang die Frage nach einem weltweiten Konkurrenzstandard zu EBICS: Gibt es einen vergleichbaren Standard wie EBICS in der Welt, beispielweise in Asien oder Amerika? Diese Frage muss klar mit nein beantwortet werden. Es scheint, wenn überhaupt, nur nationale Standards zu geben, die größtenteils schon sehr betagt sind. Das technische und fachliche Handwerkszeug, was EBICS mitbringt, ist außer Frage hervorragend. Damit hat EBICS – oder besser gesagt GBICS – wirklich das Potential, zu einem weltweiten Standard aufzusteigen.

Michael Lembcke 

Weiterlesen

Die Rolle von EBICS beim Datenaustausch über SEPAmail™ zwischen Banken und Unternehmen

SEPAmail™ wurde auf Initiative französischer Großbanken (BPCE, CM-CIC, Société Générale, BNP Paribas, Crédit Agricole) konzipiert, um Unternehmen den elektronischen Austausch nicht buchungsrelevanter Zahlungsdokumente wie Rechnungen, Anweisungen, Avise usw. zu erleichtern. Mit dieser Secure-Messaging-Lösung für den Interbankenaustausch lassen sich die herkömmlichen Zahlungsvorgänge (Überweisung, Abbuchung usw.) um neue kundenorientierte Zahlungsdienste ergänzen.


Dazu gehören:

• Begleichung elektronischer Rechnungen
• Erhöhung der Zuverlässigkeit von IBAN-Daten und Bekämpfung von IBAN-Betrug

Alle weiteren Informationen über SEPAmail™ finden Sie unter www.sepamail.eu.
Entsprechend dem 4-Corner-Modell, auf dem die SEPAmail™-Norm basiert, gliedert sich der Austausch in zwei Typen:

• den Austausch von Nachrichten im Interbankenverkehr (gemäß der SEPAmail™-Terminologie über „Briefe“ bzw. „Missives“): Webservice oder S/MIME
• den Austausch von Dateien zwischen Banken und Firmenkunden

Als Kanal für den Dateiaustausch hat sich PPI France sehr früh für SEPAmail™ interessiert und seit Dezember 2012 an einem Test mitgewirkt, um die Eignung von EBICS für die Zwei-Wege-Übertragung von SEPAmail™-Daten zu bestätigen.
Der Test bestand aus folgenden Schritten:

• einen Brief sowie einen Briefstapel mit Auftragseinreichungen über die Auftragsart FUL übertragen,
• einen Brief sowie einen Briefstapel mit Bestätigungen über die Bearbeitung einer eingereichten Datei vom Typ pain.002 über die Auftragsart PSR abrufen
• einen Briefstapel mit Transaktionsauszügen über die Auftragsart FDL herunterladen

Nachdem sowohl das Kundensystem als auch der Bankserver entsprechend konfiguriert waren (TRAVIC-Software), hat der erfolgreiche Datenaustauschs bestätigt, dass Banken und Kunden ihre EBICS-Systeme gleichermaßen für den Austausch über SEPAmail™ nutzen können.
Dank dieses Tests können wir einige Empfehlungen geben. Hierzu gehören insbesondere:

• ein Dokument zur vereinfachten Benennung der Dateien
• ein Leitfaden über die gemeinsame Umsetzung von SEPAmail™ und EBICS für Banken, Unternehmen und Dienstleister

Einige zuverlässige Dienstleister und Betreiber haben übrigens schnell erkannt, wie wichtig es ist, eine SEPAmail™-Lösung anzubieten, die den EBICS-Kanal unterstützt. Der Hersteller GFI bietet seinen Bank- und Unternehmenskunden die erste vollständig normkonforme Lösung an.
„Die Strategie unseres Angebots beruht auf drei Grundprinzipien: 

• Einfachheit: minimale Auswirkung auf das Informationssystem unserer Kunden
• Effizienz: beschleunigte Markteinführung
• Kostenkontrolle: die Erstinvestitionen der Kunden möglichst gering halten, um den Aufbau eines Geschäftspartnernetzes zu erleichtern

Vor diesem Hintergrund hat sich uns die Verwendung des EBICS-Kanals förmlich aufgedrängt. Dieser Kanal gewährleistet das notwendige Maß an Schutz und Rückverfolgbarkeit beim Austausch über SEPAmail™, und das Verfahren ist unseren Kunden aus dem Datenverkehr zwischen Banken und Firmenkunden vertraut “, erklärt uns Lionel Chemla, der Angebotsleiter für SEPAmail™ bei GFI.

Und so, wie sich EBICS außer in Deutschland und Frankreich auch in Portugal, in der Schweiz, in Österreich und demnächst in weiteren europäischen Staaten verbreitet, wird in Zukunft zweifellos auch SEPAmail™ auf der Grundlage der ISO-Norm 20022 das Interesse von europäischen Unternehmen außerhalb Frankreichs wecken...

Marc Dutech 

Weiterlesen

Blog-Serie: Wie sich EBICS verbessern lässt, Teil 3 – EBICS jetzt auch online

Ist es wirklich so, dass die Anforderungen von Firmenkunden im eBanking ausschließlich auf den dateibasierten Datenaustausch abzielen? Oder sind hier nicht auch Online-Geschäftsvorfälle gefragt? Warum sonst nutzen insbesondere kleinere Firmenkunden häufig eBanking-Lösungen aus dem Anwendungsumfeld für Privatkunden?


Das EBICS-Protokoll hat sich historisch gesehen aus dem Filetransfer heraus entwickelt und ist hervorragend für den sicheren und performanten Austausch großer Dateien zwischen Firmenkunden und Banken sowie im Interbankenverkehr geeignet. Die auszutauschenden Dateien sind je nach Geschäftsvorfall mit Auftragsarten oder Formatparametern gekennzeichnet. Diese steuern dann den jeweiligen Prozess.

Beim Einreichen von Daten über EBICS wird die Datenverbindung bei erfolgreicher Teilnehmer-Authentifizierung ausschließlich für die Dauer der Datenübertragung offen gehalten. Die eigentliche Verarbeitung erfolgt üblicherweise offline. Die Verarbeitungsergebnisse müssen anschließend über einen separaten Geschäftsvorfall heruntergeladen werden (PTK/HAC). Ebenso werden auf dem Bankrechner abzuholende Daten, zum Beispiel Umsatzinformationen, regelmäßig offline für Abholungen bereitgestellt. Diese Daten können dann als Datei über EBICS abgeholt werden.
Für die Online-Erfassung von Zahlungsverkehrsaufträgen und deren Autorisierung sowie die Online-Abfrage von Kontoinformationen ist der EBICS-Standard derzeit nicht ausgelegt. Diese Funktionen werden von proprietären Web-Portalen im Privatkundengeschäft sowie von nationalen Standards unterstützt, in Deutschland etwa HBCI/FinTS. Möchte ein Firmenkunde heute unter Berücksichtigung der verfügbaren Standards und Verfahren die Vorzüge von Online-Geschäftsvorfällen und EBICS gleichermaßen nutzen, so muss er unter Umständen unterschiedliche Lösungen mit verschiedenen Zugängen einsetzen.

Daher wäre es sinnvoll, den EBICS-Standard um die relevanten Online-Prozesse zu erweitern, zum Beispiel:

• Auskunft über Kontensalden: Über das EBICS-Protokoll könnte eine Online-Auskunft über aktuelle Kontensalden geliefert werden. Dabei wird in EBICS die Verbindung zur Abfrage offen gehalten. Hiermit verfügt der Firmenkunde stets zeitnah über den aktuellen Kontenstand.
• Auskunft über Status- und Verarbeitungsergebnissen zu Einreichungsaufträgen: Der Kunde benötigt einen Status des jeweils eingereichten Auftrages. In Verbindung mit einer neu einzuführenden Kundenauftragsreferenz (siehe Blogbeitrag vom 18.12.2014) macht eine Online-Einzelabfrage zum Auftragsstatus den Auswertungsprozess für den Firmenkunden erheblich einfacher und klarer. Gegebenenfalls erübrigt sich dann auch so mancher Anruf zur Statusauskunft bei der Bank.

Natürlich gäbe es noch weitere Einsatzmöglichkeiten. Wichtig ist aber, dass es hier nicht um eine Konkurrenz zu anderen Standards oder Verfahren im Privatkundensektor geht. Vielmehr sollte es das Ziel sein, den EBICS-Standard auf die eBanking-Bedürfnisse der Banken und der Firmenkunden anzupassen und so EBICS zukunftssicher weiterzuentwickeln.

Michael Lembcke 

Weiterlesen

Blog-Serie: Wie sich EBICS verbessern lässt, Teil 2 – mit EBICS und der VEU Autorisierungen delegieren

Mit diesem Artikel setzen wir unsere im Dezember begonnene Serie über mögliche Verbesserungen in EBICS fort. Dieser Artikel widmet sich nun folgendem Problem: Wenn man heute per EBICS einen Zahlungsverkehrsauftrag einreicht, hat der Einreicher im Standardfunktionsumfang keine Möglichkeit mehr, auf die weitere Autorisierung Einfluss zu nehmen. In manchen Fällen ergibt sich aber erst mit der Einreichung, wer für die weitere Autorisierung in Frage kommt und man möchte die Autorisierung situativ delegieren.

Im aktuell spezifizierten Funktionsumfang von EBICS sind Bankrechner-seitig unterschiedliche Berechtigungsmodelle für die Einreichung und Autorisierung von Auftragsdateien durch Firmenkunden anwendbar. Diese Modelle beruhen in der Praxis stets auf den Unterschriftsklassen E, A, B und T, der Anzahl erforderlicher Unterschriften sowie der personenbezogenen Berechtigung für eine physische Datei. Darüber hinaus haben die Kreditinstitute und Softwarehersteller die Berechtigungsmodelle im Laufe der Zeit so erweitert, dass sie sich für verschiedene Einsatzszenarien eignen. Beispiele für solche Erweiterungen sind:

• Berechtigungen bezogen auf eine Person und einen Auftrag in Kombination mit Unterschriftsklassen,  Auftragsarten (also bestimmten Geschäftsvorfällen) und Konten.
• Verschiedene Limit-Konzepte, zum Beispiel über Beträge, Anzahl der Transaktionen, für Zeitfenster, geltend für Personen, Konten und/oder Kunden sowie nach Unterschriftsklassen gestaffelte.
• Gruppenkonzepte in Verbindung mit Unterschriftsklassen, zum Beispiel  zur Berechtigung der Autorisierung von Personen ausschließlich verschiedener oder ausschließlich gleicher Gruppen.
• Proprietäre Unterschriftsklassen, die eigene Wertungen für eine Autorisierung berücksichtigen.
• Verfahren für Service-Rechenzentren (SRZ-Verfahren), in denen die Prozesse der Einreichung und Autorisierung auf Kundenebene getrennt ablaufen.

All diese Modelle sind als relativ statisch anzusehen. Das heißt, wenn ein EBICS-Kunde einen Auftrag einreicht, kann er nur bedingt beeinflussen, wie die Bank den Geschäftsvorfall abwickelt. Es gelten stets die bankseitig eingerichteten Stammdaten als Grundlage für die Berechtigungsprüfung, Formatprüfung und Autorisierung. In den Fällen, in denen eine eindeutige Herleitung der Berechtigungen im EBICS-Umfeld bankseitig möglich ist,  mag dies sinnvoll und auch gewollt sein. Allerdings können im EBICS-Prozess Einreichungs-Aufträge, die vom Sachverhalt her unterschiedliche Behandlungen erfordern, nicht in verschiedener Weise abgewickelt werden. Bei gleichförmigen SEPA-Einreichungen mit der Auftragsart CCT zugunsten eines bestimmten Kontos wären zum Beispiel stets alle für dieses Konto und diese Auftragsart im Bankrechner zur verteilten elektronischen Unterschrift (VEU) berechtigen Personen zur Autorisierung berechtigt.

Wäre es nicht sinnvoll, wenn man als Kunde bei Bedarf mit der Einreichung in EBICS bereits die Personen benennen könnte, an die man die Autorisierung delegieren möchte? Diese Personen müssen natürlich bankseitig grundsätzlich über die entsprechende Basis-Berechtigung verfügen. Der Vorteil wäre, dass die nicht benannten Personen mit der ansonsten gleichen Basis-Berechtigung den Auftrag nicht zur VEU gestellt bekommen und somit auch nicht einsehen können. Dieses Modell ist zum Beispiel für Fälle geeignet, in denen über ein bestimmtes Konto sowohl beliebige Zahlungen, als auch Gehälter oder Gagen-ähnliche Zahlungen abgewickelt werden und die Zahlungen gleichzeitig über keine besondere Kennzeichnung verfügen. Solche Kennzeichnungen sind ohnehin weitestgehend format- und länderspezifisch. Mit einer entsprechenden Erweiterung des EBICS-Standards wäre somit eine formatunabhängige Lösung umsetzbar.

Michael Lembcke 

Weiterlesen