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 

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:

SWIFTEBICS
Topologiesternförmigvermascht
Managementmanagedself-managed
Ausfallzentralselbstheilend
ÜbertragungsartKabelKabel 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 

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 

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