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 

“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