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 

SEPA Card Clearing – Was hat das mit EBICS zu tun?

Von der Vereinheitlichung des Zahlungsverkehrs innerhalb der SEPA Single Euro Payment Area sind neben den Geschäftsvorfällen Credit Transfer und Direct Debit in gewisser Weise auch die Kartenzahlungen betroffen. Was dies mit EBICS zu tun hat, verrät der folgende Artikel.

Die Kartenzahlungen wurden bisher in nationalen Formaten ausgetauscht. Am Point-of-Sale unterscheidet man generell zwei Arten:

1. ELV*-Lastschriften, die durch eine manuelle Unterschrift des Kunden autorisiert werden
2. Lastschriften, die durch eine PIN-Eingabe im Kartenlesegerät autorisiert werden
Die ELV-Lastschriften werden als normale SEPA Direct Debits verarbeitet. Die Lastschriften mit PIN-Eingabe am Kartenlesegerät werden nicht automatisch von SEPA geregelt. Es ist jedoch sinnvoll, auch hier die nationalen Formate durch ISO20022-Formate zu ersetzen. Diese ISO-Formate werden im SEPA Card Clearing oder kurz SCC spezifiziert. Dabei unterteilt sich das SCC wie folgt:
  • Firmenkunde-Bank-Geschäft
  • Interbankenzahlungsverkehr
In beiden Regimen sind besondere Anforderungen an den Prozess, den Clearing- und Settlement-Mechanismus sowie die auszutauschenden Datenformate zu berücksichtigen. Das EPC (European Payment Council) hat Vorgaben für das SEPA Card Clearing gemacht. Die Berlin Group (www.berlin-group.org), eine Initiative von Zahlungssystemen und Organisationen aus ganz Europa, hat einheitliche Vorgaben basierend auf dem Standard ISO20022 im Detail spezifiziert. Diese Spezifikation, die derzeit in der Version 2.0 vorliegt, unterstützt gleichfalls die Anforderungen des EPC an das SEPA Card Clearing.

Zu den Vertretern der Berlin Group gehören Teilnehmer aus: Belgien, Bulgarien, Dänemark, Deutschland, Estland, Europa, Finnland, Frankreich, Griechenland, Großbritannien, Irland, Island, Italien, Kroatien, Lettland, Litauen, Luxemburg, Niederlande, Norwegen, Portugal, Schweden, Serbien, Spanien, Türkei und Ungarn. Damit ist die SCC-Spezifikation der Berlin Group eine europaweite Initiative. Man ist derzeit dabei, das SCC umzusetzen. In Deutschland hat der DK (Deutsche Kreditwirtschaft) beschlossen, die Verrechnung von kartenbasierten Umsätzen, die nicht ELV-basiert sind, von den Altformaten auf die Formate und Prozesse des SCC der Berlin Group umzustellen. Von den Umstellungen von Altformaten auf SCC sind Firmenkunden, Kartenherausgeber, Kartenakzeptanten, technische Dienstleister (z. B. Netzbetreiber) sowie Kreditinstitute und Zahlungsverkehrsabwickler betroffen. Vor einer Umstellung sollte das Sizing der IT-Systeme überprüft und ggf. neu ausgelegt werden, da bei SCC – analog zu SEPA – auch wieder höhere Datenvolumina erwartet werden.

Was hat das Ganze nun mit EBICS zu tun? Vom DK wurde die Nutzung von SCC mit EBICS beschlossen. Zum 23. April 2014 wurden im Anhang 2 der EBICS-Spezifikation die Geschäftsvorfälle um die des SCC erweitert. Die EBICS-Erweiterung betrifft den Interbankenverkehr und das Firmenkunde-Bank-Geschäft. Es wurden neue Geschäftsvorfälle für den Datenaustausch in Form neuer Auftragsarten und Formate in die EBICS-Spezifikation aufgenommen. Die Auftragsarten und Formate im Interbankenverkehr sind z. B. für die Deutsche Bundesbank über EBICS für den neuen SCC-Dienst des SEPA-Clearers enthalten. Dabei plant die Deutsche Bundesbank auch hier die Abschaltung des Altformates DTA. Gleichfalls wurden in EBICS Erweiterungen für das europäische SCC im Interbankenzahlungsverkehr aufgenommen. Die EBA-Clearing bietet europaweit im Interbankenverkehr mit diesen Geschäftsvorfällen das STEP2 Card Clearing über EBICS an. Aktuell laufen verbreitet die Tests zum SCC. Die Abnahmetests mit den Clearingstellen EBA-Clearing und Deutsche Bundesbank sollen bis Frühjahr 2015 abgeschlossen sein. Eine vollständige Umstellung von DTA auf SEPA und somit auf das SEPA Card Clearing soll in 2016 erfolgen. Inwieweit dieses auch von Banken in anderen europäischen Ländern von Interesse ist, wird sich zeigen. Die Zusammensetzung der Teilnehmer der Berlin Group ist jedenfalls vielversprechend.

* Elektronisches Lastschriftverfahren

Michael Lembcke 

Zürcher Kantonalbank entscheidet sich für EBICS

Die Zürcher Kantonalbank hat sich für ihren elektronischen Zahlungsverkehr für eine besonders stabile und multibankfähige Software entschieden. Die größte Schweizer Kantonalbank bietet ihren Firmenkunden zukünftig den internetbasierten Electronic-Banking-Standard EBICS an, den die Schweizer Kreditinstitute als multibankfähigen Standard vereinbart haben. In einer Ausschreibung konnte sich die PPI AG mit dem Electronic-Banking-System TRAVIC-Corporate gegen zahlreiche Wettbewerber durchsetzen.

Nach der Entscheidung der Schweizer Kreditwirtschaft für den besonders sicheren Electronic Banking Internet Communication Standard (EBICS) tritt die Schweiz der europäischen EBICS-Gesellschaft bei, um sich gemeinsam mit Deutschland und Frankreich an dessen Weiterentwicklung zu beteiligen. Derzeit setzt sich EBICS als Zahlungsverkehrsstandard im Firmenkundensegment auch an anderen europäischen Finanzplätzen durch.

Das EBICS-Protokoll wird von Unternehmen als integraler Bestandteil ihrer Zahlungssysteme benutzt, um den elektronischen Zahlungsverkehr abzuwickeln. Typische Transaktionen sind das Erteilen von Zahlungsaufträgen oder das Beziehen von Kontoauszügen, Statusreports und Zahlungsavis. Für die Freigaben lassen sich elektronische Unterschriften verwenden. Als hoch verfügbarer und kostengünstiger Standard kann EBICS auch sehr grosse Datenvolumen sicher und schnell bewältigen.

Für Firmen hat das Verfahren den Vorteil, dass europaweit immer mehr Banken EBICS anbieten, das sich mittlerweile nebst dem einheitlichen europäischen Zahlungsformat SEPA als kongruentes Übertragungsprotokoll durchsetzt.

Bereits Anfang 2014 hatte sich die Luzerner Kantonalbank für TRAVIC-Corporate von PPI entschieden. Weitere Schweizer Großbanken interessieren sich verstärkt für das System des Marktführers für EBICS-Lösungen. Die Zürcher Kantonalbank nutzt das neue Übertragungsprotokoll der PPI AG auf Basis von TRAVIC-Corporate. „Wir arbeiten eng mit der Bank zusammen und sorgen so für eine maßgeschneiderte Integration in die bestehenden Banksysteme“, sagt Michael Lembcke, Produktmanager bei PPI und zuständig für das Integrationsprojekt der Zürcher Kantonalbank und RECON.

„Die Zürcher Kantonalbank wird das System direkt an die zentrale Benutzerverwaltung anbinden, was den Administrationsaufwand reduziert und die Sicherheit der Gesamtsystemlandschaft erhöht“, so Carsten Miehling, Geschäftsleiter bei RECON, dem Vertriebspartner der PPI AG in der Schweiz.

Michael Lembcke 

EBICS ist nicht gleich EBICS – von Auftragsarten und Formatparametern

Auch wenn es eine einheitliche Spezifikation für EBICS gibt: Bei der Einreichung und bankseitigen Berechtigungsprüfung von Zahlungsverkehrsaufträgen wird EBICS  in Europa unterschiedlich genutzt. Zum Beispiel nutzt man in Deutschland ausschließlich die Auftragsarten, in Frankreich Formatparameter. Aber muss der Kunde diese Unterschiede kennen? Wie bereits in meinem letzten Beitrag angekündigt, hier mehr dazu.


Mit der EBICS-Auftragsart gibt ein Client an, welchen Geschäftsvorfall er auf dem Bankrechner einreichen möchte. Ist die Auftragsart auf dem Bankrechner bekannt und ist der Einreicher hierzu berechtigt, wird eine für diese Auftragsart spezifizierte Formatverarbeitung durchgeführt.
Bei den dreistelligen Auftragsarten wird in EBICS grundsätzlich zwischen der Initiierung von Uploads und Downloads unterschieden. Zudem kann es sich um operative oder administrative Auftragsarten handeln. Unter administrativ sind diejenigen zu verstehen, die das  EBICS-Protokoll selbst steuern, zum Beispiel HIA und INI für den Schlüsselaustausch oder HVU zum Abruf der VEU-Übersicht. Die operativen Auftragsarten hingegen kennzeichnen den fachlichen Inhalt eines Dateitransfers, etwa CCT für Zahlungen im Format des SEPA Credit Transfer. Auf diesem Wege wird bei operativen Auftragsarten die Art der formatspezifischen Verarbeitung bestimmt.

Mit EBICS ist eine Liste der zu nutzenden operativen Auftragsarten spezifiziert sowie die damit zu verwendenden Geschäftsvorfälle und Formate. Diese operativen Auftragsarten werden derzeit vorrangig in Deutschland genutzt.

In Frankreich nutzt man für operative Aufträge unabhängig vom Dateninhalt generell genau eine Auftragsart für Uploads (FUL) und eine Auftragsart für Downloads (FDL). Um dem Bankrechner dann aber Hinweise auf das enthaltene Format mitzugeben, wird vom Client der Auftragsart noch ein bis zu 40-stelliger Formatparameter mitgegeben. Dessen Aufbau ist ebenfalls mit EBICS spezifiziert.

Wie gut verstehen sich Bankrechner und Client?

Sowohl für die deutsche als auch für die französische Art der Auftragsarten-Nutzung lassen sich bankseitige formatspezifische Berechtigungsprüfungen hinterlegen. Dabei ermöglichen einerseits die Formatparameter eher eine detailliertere Vereinbarung zwischen Kunde und Bank über die Art der auszutauschenden Inhalte (zum Beispiel SEPA-Version, Länderausprägung), andererseits sind die Auftragsarten für einen Kunden gegebenenfalls einfacher zu handhaben, da dieser sich um die Formatdetails im EBICS keine Gedanken machen muss. Wichtig ist aber, dass EBICS-Bankrechner und Client sich verstehen. Dazu muss der Kunde sehr wohl wissen, was sein Gegenüber, der Bankrechner, versteht.

Beide Arten des Austausches von operativen Daten zwischen EBICS-Client und EBICS-Bankrechner haben ihre Vor- und Nachteile. Letztendlich entscheidet der Firmenkunde, und  der hat möglicherweise Konten bei mehreren Kreditinstituten in unterschiedlichen Ländern. Dieser Kunde fordert ein einheitliches Vorgehen. Der Erfolg von EBICS entscheidet sich daher gleichfalls in der Einheitlichkeit der Nutzung beziehungsweise in der  Interoperabilität der Nutzungsvarianten von EBICS. Hier sind die Spezifizierer gefragt. Wie der Beitrag von Carsten Miehling vom 9.9.2014 zeigt, ist hier der Prozess bereits in Bewegung.

Michael Lembcke 

Serverseitige Erneuerung der EBICS-Zertifikate

Was die französische Version des EBICS-Protokolls anbelangt, so wurden die EBICS-Server überwiegend Ende 2009 sowie im Laufe des Jahres 2010 in Betrieb genommen. Viele von ihnen verwenden selbstsignierte X.509-Zertifikate mit einer Laufzeit von fünf Jahren, weshalb einige Institute bereits mit deren Erneuerung begonnen haben bzw. sich andere darauf vorbereiten.



Auf Kundenseite sieht das EBICS-Protokoll bei der Zertifikatserneuerung entsprechende EBICS-Nachrichten (PUB-, HCA- und HCS-Nachrichten) mit einer entsprechenden client- und serverseitigen Verarbeitung vor, so dass manuelle Eingriffe prinzipiell entfallen (signierte Nachrichten, die keiner zusätzlichen Validierung bedürfen). Bei der serverseitigen Erneuerung der Bankzertifikate verhält es sich jedoch anders: Lediglich die HPB-Nachricht ist dafür derzeit in EBICS verfügbar. Die Validierung der Bankzertifikate umfasst einen manuellen Schritt, nämlich den Abgleich des entsprechenden Hash-Werts. Ein weiterer beträchtlicher Unterschied liegt in der Tragweite des Vorgangs, der sich auf mehrere Tausend Kundenzugänge gleichzeitig auswirken kann.

Um diesen Eingriff im Umgang mit Zertifikaten in EBICS zu erleichtern, sind eine Reihe von Vorkehrungen und Vorsichtsmaßnahmen erforderlich.

Aus unseren Erfahrungen in der Entwicklung und Implementierung von EBICS-Software auf Kunden- wie auf Bankseite konnten wir für die Zertifikatserneuerungen einige Erkenntnisse ableiten. Wir möchten daher denjenigen, die sich mit der EBICS-Server-Administration befassen, folgende Empfehlungen geben:

- Erkundigen Sie sich bei Ihrem Software-Anbieter, nach welchem Verfahren die Zertifikate generiert und aktualisiert werden.

- Meiden Sie bei der Auswahl von Datum und Uhrzeit solche Zeiträume, in denen üblicherweise hohe Belastungen herrschen (Monatsende, Cut-off-Zeiten etc.) oder nur wenige Mitarbeiter auf Kundenseite verfügbar sind (am späten Abend, nachts, in den Schulferien etc.). Da das Ablaufdatum der Zertifikatsgültigkeit vorhersehbar ist, können vorbereitende Maßnahmen schon im Vorfeld ergriffen werden, um sich einen zeitlichen Spielraum zu verschaffen.

- Informieren Sie die Kunden langfristig im Voraus über Datum und Uhrzeit für den Wechsel der Bankzertifikate. Es ist sinnvoll, einige Tage vor dem Termin ein Erinnerungsschreiben zu versenden. Nachfolgend einige Punkte, die ein solches Schreiben unserer Ansicht nach enthalten sollte:
  • Dem Kunden die Kontaktaufnahme mit seinem Softwareanbieter nahelegen, damit der Kunde sicherstellt, dass seine Software die Erneuerung der Bankzertifikate unterstützt und er eine Ablaufbeschreibung der Zertifikatserneuerung erhält, sofern er noch keine besitzt. Wir haben ermittelt, dass zwei verschiedene Kundenprodukte diesen Vorgang nicht zulassen. In beiden Fällen waren die Kunden gezwungen, ihre Zugänge vollständig neu anzulegen.
  • Den Kunden bitten, das Schreiben vom Softwarehersteller ggf. an den Dienstleister weiterzuleiten, dem er einen DFÜ-Zugang übertragen hat. Denn der vorgenannte Punkt gilt für den Dienstleister gleichermaßen.
  • Den Hash-Wert des neuen Bankzertifikats angeben, damit der Kunde den Hash angleichen kann. Die übliche Darstellung als Matrix aus 4 Zeilen zu je 8 Bytes lässt sich durch eine lineare Darstellung (die 32 Bytes in derselben Zeile ohne Trennzeichen) ergänzen, um das Kopieren und Einfügen in die Software des Kunden zu vereinfachen.
  • Den Kunden darauf hinweisen, dass, sofern er seine Einstellungen nicht rechtzeitig aktualisiert, der erste Transfer unter Ausgabe eines Fehlercodes mit dem Wert 091008 und der Kennzeichnung EBICS_BANK_PUBKEY_UPDATE_REQUIRED fehlschlägt. Vor einem erneuten Anstoßen der fehlgeschlagenen Transfers muss er zunächst die neuen Bankzertifikate einspielen.
  • Dem Kunden empfehlen, sich mit dem echten Zertifikatswechsel vorab vertraut zu machen, indem er das aktuelle Bankzertifikat wiederholt abholt (HPB). So lässt sich der Zertifikatswechsel der Bank mit der Client-Software jederzeit simulieren.
Die aktuellen Möglichkeiten zur Erneuerung der EBICS-Bankzertifikate gewährleisten derzeit keinen reibungslosen Ablauf. Ich bin mir sicher, dass es der EBICS-Gesellschaft so wie im Falle der Order-ID gelingt, in der nächsten Zeit Abhilfe zu schaffen und den Standard so weiterzuentwickeln, dass auch dieses Problem gelöst ist.

Marc Dutech