“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 

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 

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 

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 

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 

Blog-Serie: Wie sich EBICS verbessern lässt, Teil 1 – Kundenauftragsreferenz

Mit dieser Blog-Serie möchte ich eine Reihe starten, in der über mögliche und wünschenswerte Erweiterungen von EBICS nachgedacht wird. Die Vorschläge haben einen konkreten fachlichen oder technischen Hintergrund, aus dem sich die Lösungsvariante ableitet. Beginnen möchte ich die Blog-Serie mit der Kundenauftragsreferenz.

Von Kunden wurde die Möglichkeit nachgefragt, einem Auftrag eine Referenz mitzugeben, zum Beispiel einen Dateinamen oder eine beliebige ID. Wichtig ist dabei die Eindeutigkeit der Referenz. Somit kann der Kunde gezielt den Auftragsstatus über die Referenz abfragen, egal ob der Auftrag noch in Bearbeitung ist oder schon vor Tagen abgearbeitet wurde. Des Weiteren kann über diese Referenz auch eine Doppeleinreichungskontrolle erfolgen.

An dieser Stelle sollte klar sein, dass die existierende 4-stellige Order-ID nicht das richtige Mittel ist, um die oben genannten Anforderungen abzudecken. Die Order-ID wird seit der EBICS-Version 2.5 vom EBICS-Server vergeben und ist nicht eindeutig.

Die Anforderungen können durch die Einführung einer Kundenauftragsreferenz (Customer Order Reference) abgedeckt werden, die den EBICS-Standard erweitern würde. Konkret könnte dies so umgesetzt werden:
  • Eine individuelle Kundenauftragsreferenz mit einer Länge von zum Beispiel 512 Zeichen wird eingeführt. Die Kundenauftragsreferenz kann vom Kunden frei vergeben werden. Sie kann zum Beispiel der Dateiname, eine beliebige ID oder eine Kombination aus beidem sein. Die Kundenauftragsreferenz muss im Protokoll (PTK/HAC) aufgeführt werden.
  • Die Kundenauftragsreferenz wird innerhalb von zum Beispiel 90 Tagen im EBICS-Server der Bank pro Kunde auf Eindeutigkeit geprüft. Wird ein Auftrag mit einer Kundenauftragsreferenz eingereicht, für die bereits ein erfolgreicher Upload erfolgte, wird der neue Auftrag abgelehnt. Erfolgt hingegen ein zweiter Upload mit der gleichen Kundenauftragsreferenz während der erste Upload noch läuft, wird der erst (ältere) Upload fehlerhaft beendet. Damit kann die Kundenauftragsreferenz auch verwendet werden, wenn ein Transfer hängen bleibt. Die Ablehnung wird in jedem Fall im PTK/HAC vermerkt.
  • Wenn die PTK/HAC-Einträge des EBICS-Servers der Bank durch Einträge zum Beispiel aus dem Clearing ergänzt werden, so sollten die ergänzenden PTK/HAC-Einträge ebenfalls die entsprechende Kundenauftragsreferenz enthalten, soweit sie sich auf eine Einreichung beziehen.
Als Abfragen wären folgende Aufträge denkbar:
  • Der Kunde kann das PTK/HAC gezielt für eine oder mehrere Kundenauftragsreferenzen abrufen. Dabei wird dem Kunden das bis zu dem Zeitpunkt fertige PTK/HAC zurückgegeben. Der Abholstatus von PTK bzw. HAC bleibt dabei unverändert.
  • Alle bereits eingereichten Kundenauftragsreferenzen können abgefragt werden. Dabei kann der Zeitraum analog zur historischen Abholung eingegrenzt werden. Diese wäre eine Servicefunktion für die Kundenauftragsreferenzen.
Mit der Einführung einer Kundenauftragsreferenz, der individuellen Abfrage nach bestimmten Kundenauftragsreferenzen und der daraus resultierenden Doppeleinreichungskontrolle hätte man ein starkes Instrument geschaffen. Der Kunde könnte einzelne Einreichungen recherchieren und hätte die Möglichkeit, eine effektive Doppeleinreichungskontrolle zu etablieren. Die Bank würde die Recherchemöglichkeiten für den Kunden erweitern und könnte damit Anfragen bei der Bank reduzieren. Eine Doppeleinreichungskontrolle wäre sogar an den Kunden delegiert. Somit wäre die Einführung einer Kundenauftragsreferenz eine Win-Win-Situation für die Banken und für die Kunden. Was wollen wir mehr?

Michael Lembcke 

Startschwierigkeiten beim Onboarding von Schweizer EBICS-Kunden

In früheren Blogbeiträgen haben wir bereits über den Start von EBICS in der Schweiz berichtet. Erste Kreditinstitute bieten inzwischen den multibankfähigen Standard an, weitere befinden sich noch in der Angebotsplanung. Der Fokus richtet sich daher nun langsam auf die Firmenkundschaft, die die neuen Schnittstellen nutzen möchte, genauer gesagt auf die dort einzusetzende EBICS-Client-Software.

Die erste Umfrage Anfang dieses Jahres in der Schweizer Softwarehersteller-Gemeinde zum Support von EBICS in ihren Client-Produkten war durchweg positiv. Die Mehrzahl der Anbieter hat EBICS als Protokoll bereits implementiert und kann produktive Verbindungen mit den beiden Großbanken vorweisen. Um dem Kunden das Aufschalten einer neuen Schnittstelle zu vereinfachen, bieten einige der Softwarelösungen sogenannte EBICS-Profile für das jeweilige Institut in ihren Installationsprogrammen an. Der Kunde entscheidet vor der Initialisierung, mit welcher Bank er sich verbinden will und das Programm belegt automatisch Institut-spezifisch die wichtigsten Verbindungs- und Konfigurationsparameter (Version, EU-Verfahren, Hostname, Zertifikat-Aussteller, unterstützte Auftragsarten, URL, etc.).

Möchte nun der Kunde eine weitere Bank anbinden, welche EBICS neu anbietet, benötigt er oftmals eine neue Softwareversion des Herstellers, welche gemäß dem soeben beschriebenen Verfahren die neue Institut-spezifische Konfiguration enthält. Das an sich kundenfreundliche Setup verkehrt sich hier auf einmal ins Gegenteil, denn wer möchte nur wegen einer neuen Bankverbindung gleich die gesamte Software updaten? Gewünscht wäre an dieser Stelle ein konfigurativer Ansatz, bei welchem ich als Kunde die relevanten EBICS-Parameter für die neue Verbindung selbst erfassen kann.
Wenn der Hersteller dann für solche Updates noch Releasegebühren verlangt, wird man den Eindruck nicht los, dass hier auf Kosten des Kunden für ein eigentlich triviales Problem gerne Kasse gemacht wird. Es liegt jetzt wohl an den Banken, sich einen Überblick über die jeweiligen Lösungen zu verschaffen und dieses dann in der Kundenberatung entsprechend einfließen zu lassen, wenn es um die Frage geht, welche EBICS-Software am besten für den Anschluss an das eigene Institut geeignet ist.

Für Schweizer Hersteller, welche noch kein EBICS-Protokoll installiert haben, hier zum Abschluss noch ein Tipp: Die Konfiguration einer neuen EBICS-Verbindung sollte kein „Hexenwerk“ sein, wenn von Anfang an darauf geachtet wird, dass diese z.B. über einen Dialog vom Kunden selbst wahrgenommen werden kann. Für die Einbindung des EBICS-Protokolls sei an dieser Stelle auch noch auf den EBICS-Kernel von PPI verwiesen (siehe Softwarebausteine auf der PPI-Homepage), der den gesamten Umfang von EBICS in Form einer Software-Library zur Verfügung stellt.

Carsten Miehling