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 

Mehr Sicherheit, geringere Kosten: STEP2 Clearing mit EBICS

Seit Ende letzten Jahres bietet die EBA Clearing neben SWIFT auch EBICS als Zugangskanal für STEP2 an. Die Blaupause dafür stammt von der Deutschen Bundesbank, die bereits 2008 ihren SEPA-Clearer über SWIFT und EBICS zugänglich machte. Was sind die Gründe, warum EBA Clearing neben einem SWIFT- auch noch einen EBICS-Zugang anbietet? Der Anstoß dazu kam von einigen Banken und Sparkassen aus Deutschland. Die Motivation waren die Kosten: Bei EBICS fallen keine Transaktionskosten für den Transport an.


Im bilateralen Clearing zwischen den Banken, das in Deutschland auch als "Garagen-Clearing" bekannt ist und extensiv genutzt wurde, fallen für den Transport und das Clearing keine Kosten an. Die jeweils beteiligten Banken tragen die Kosten für den Transport und das Clearing selbst. Bei der Umstellung auf ein zentrales Clearing fallen natürlich Kosten für das Clearing an. Um die Kosten nicht noch weiter in die Höhe zu treiben, sollten die Kosten für den Transport, die jedes Kreditinstitut selbst trägt, so gering wie möglich gehalten werden. Daher fiel die Entscheidung auf EBICS, da bei EBICS – abgesehen von reinen Betriebskosten – keine Transaktionskosten für den Transport anfallen.
Ein zweiter Aspekt wird zudem immer wichtiger: Sicherheit! Im Interbankenzahlungsverkehr liegen die täglichen Geldmengen im Milliardenbereich. Eine Störung des Geldflusses von wenigen Stunden führt bereits zu Verwerfungen, die erhebliche Auswirkungen für die Wirtschaft haben können. Daher wird zunehmend die Frage nach einem Backup-Transportverfahren für das Clearing im Interbankenzahlungsverkehr gestellt. Auch dafür würde sich EBICS hervorragend eignen, beispielsweise EBICS als Backup für SWIFT. EBICS und SWIFT werden bereits bei einigen Banken parallel für das Clearing eingesetzt. Es scheint zudem unwahrscheinlich, dass sich der Regulierer auf Dauer mit einem einzigen Transportverfahren begnügt. In fast allen Bereichen der Bank wurden die Sicherheitsanforderungen deutlich verschärft, zum Beispiel durch die PSD II. Eine zukünftige Verschärfung der Sicherheitsanforderungen im Interbankzahlungsverkehr scheint daher nicht ausgeschlossen zu sein.

Meeting EBICS Working Group: Schweiz sorgt für neuen Schwung bei EBICS

Die Schweizer EBICS-Arbeitsgruppe will noch im September ihre Ideen, insbesondere zu den Auftragsarten, beschreiben. Das ist ein Kernergebnis des Treffens der EBICS Working Group am 28. August. Erstmals seit Bestehen der Deutsch-Französischen EBICS-Kooperation fand es in der Schweiz statt. Hintergrund ist, dass mit der Schweiz ein weiterer Kandidat für die Beteiligung an der EBICS-Gesellschaft in den Startlöchern steht. In Gehdistanz zum Schweizer Antragsteller SIX Interbank Clearing diskutierten die Experten aus den drei Ländern im Hotel Renaissance in Zürich die aktuelle Situation der Schweiz und die geplanten Erweiterungen am neuen elektronischen Zahlungsverkehrsstandard.


Schon der Start der Debatte verlief recht fulminant, stand doch wieder einmal die Frage im Raum, ob die Schweiz eher das Auftragsartenmodell Deutschlands oder die Fileparameter-Variante (FUL/FDL) Frankreichs für die nationale Anwendung verwenden sollte. Albert Apolloner, Leiter der Schweizer EBICS-Arbeitsgruppe stellte in seiner Präsentation die Vor- und Nachteile der jeweiligen Lösung aus Schweizer Sicht dar. Sein Fazit favorisierte die Fileparameter-Variante, welche bereits grundlegende Anforderungen des Schweizer Finanzmarktes abdeckt und als flexibler beurteilt wird. Die deutschen Vertreter verwiesen auf ihre Lösung, mit der jede Transaktionsart einem Issuer, zum Beispiel der Schweiz oder einer größeren Bank, zugeordnet werden kann.

Aus der Diskussion entsprang die Idee, alle deutschen Transaktionsarten gemäß der Fileparameterlogik zu übersetzen. Die Clientsoftwarehersteller würden dann ausschließlich diese Logik in ihren Clients implementieren, was insbesondere im Hinblick auf die Ausweitung in neuen Märkten wie die Schweiz, Spanien, Portugal und andere Kandidaten interessant wäre. Um die Aufwände seitens der deutschen Institute zu minimieren (die bekannten dreistelligen Auftragsarten werden aktuell bis weit in die Verarbeitung weitergereicht), könnte man sich ein Mapping in den Bankrechnerprodukten vorstellen. Aus der Transaktionsart AZV würde dann zum Beispiel pain.xxx.azv. In Kombination mit dem Ländercode und dem sogenannten "Name-/Value-Pair" könnten die Anforderungen jedes Landes und sogar weitere Merkmale großer Marktteilnehmer, wie zum Beispiel „es handelt sich um eine Datei in der Ausprägung Credit Suisse“, abgedeckt werden.
Man kann sich vorstellen, dass auf deutscher Seite nicht gerade ein Begeisterungssturm für die Idee ausgelöst wurde. Als zukünftige Vision für eine EBICS-Harmonisierung könnte man sich aber ein solche Migration durchaus vorstellen. In der Umsetzung könnten sicherlich beide Verfahren für einen Übergangszeit als Standard weiterbestehen. Neue Märkte würden zum eigenen Vorteil gleich auf die universellere Variante FUL/FDL setzen.

Im zweiten Teil des Meetings kam das Thema Sicherheit auf den Tisch, bei dem Deutschland und Frankreich ebenfalls andere Wege gehen. Alain Hiltgen (UBS) regte an, im EBICS Implementation Guide die Verwendung von Hardtokens für das Aufbewahren von Schlüsseln und Zertifikaten zu empfehlen.

Nach dem Mittagessen präsentiert Sabine Wenzel (SIZ) den Schweizer Teilnehmern die EBICS-Gesellschaft, die Organisation und die Entscheidungsprozesse für zukünftige Erweiterungen. Gemäß der aktuellen Planung wäre es bis Ende November 2014 möglich, noch Change Requests für das Release 2.6 (wahrscheinliche Inkraftsetzung 2016) einzureichen. Die Schweizer Arbeitsgruppe will sich noch im September treffen und ihre Ideen, insbesondere zu den Auftragsarten, beschreiben. Idealerweise können diese dann bereits beim nächsten Meeting der internationalen EBICS Working Group im November in Paris diskutiert werden.

Fazit: Ein sehr interessantes Forum für alle EBICS-Begeisterten. Es hinterlässt den Eindruck, dass ein neuer Spieler im Team etwas Schwung in die EBICS-Weiterentwicklung bringen könnte. Fortsetzung folgt.

Carsten Miehling 

Das Schlüssel-Birchermüsli

Wie bereits im Blogbeitrag vom 25.07.14 „EBICS auch in der Schweiz angekommen“ erwähnt, gesellt sich nun langsam aber sicher auch der Finanzplatz Schweiz zur EBICS-Gemeinde der beiden großen Nachbarn Deutschland und Frankreich. Bekanntlich interpretieren die Franzosen EBICS etwas anders als die Deutschen und die Schweizer Akteure fragen sich, welche Variante für sie wohl die bessere sei. Bei den Auftragsarten geht die Tendenz aktuell Richtung Frankreich, also FUL/FDL in Verbindung mit den Formatparametern anstelle der vielfältigen Sammlung an Auftragsarten in Deutschland. Komplizierter wird es bei der Anwendung der elektronischen Unterschriften: Wie sollen diese konkret beim Kunden implementiert werden? 

Die deutsche Variante der selbstgenerierten Schlüsselpaare für die Verschlüsselung (E002), Authentisierung (X002) und eben für die Signatur (A005/A006) ist die aktuell in der Schweiz produktiv eingesetzte Variante, wobei das bisher in Deutschland genutzte Konzept der VEU (Verteilte Elektronische Unterschrift) erst in der Planung ist. Dieses erlaubt Unterschriftsmodelle mit mehreren personenbezogenen Signaturen, die mit oder auch nach dem Auftragsversand erstellt und eingereicht werden können. Die Großbanken der Schweiz setzen allerdings aktuell nur die Einzel- und Transportunterschrift ein. Bei der Einzelunterschrift handelt es sich in der Regel um eine sogenannte „Corporate Seal“, d.h. es wird eine Firma identifiziert und nicht die Person, welche tatsächlich den Auftrag freigegeben hat. Die Verwaltung der Nutzung dieser „Corporate Seal“ wird in der Software des Kunden geregelt. Bei der Transportunterschrift erfolgt die Freigabe auf einem separaten Kanal, jedoch nicht wie in Frankreich noch verbreitet manuell mittels Begleitzettel, sondern via Zugriff über Onlinebanking.

Diese Praxis gerät allerdings zunehmend in die Kritik der Rechts- und Sicherheitsabteilungen der Schweizer Finanzinstitute, welche eine eindeutige Authentisierung der Person verlangen, die den Auftrag signiert hat. Die VEU wäre in diesem Fall sicher ein geeignetes Mittel, wobei die Banken aktuell noch die zusätzlichen Prozessaufwände scheuen, welche die Verwaltung der Unterschriftenregeln auf Bankseite mit sich bringen würde.

Als attraktive Kombination wird dabei das Modell TS (Transport and Signature) in Frankreich mit den CA-basierten Zertifikaten für die elektronische Signatur angesehen, da hierbei das Problem der unbeschränkten Gültigkeit der Schlüssel entfällt und die zentrale Sperrung über die CA das Sicherheitsrisiko zu vermindern scheint. Idealerweise wird das Ganze dann noch kombiniert mit einem Hardtoken, welcher nur durch die Person, die den Auftrag erteilt, eingesetzt werden kann. „Wenn schon, denn schon“, ist man versucht zu sagen, aber so sind wir Schweizer eben. Wenn ein Standard solche Funktionalitäten hergibt, warum sollte man sie nicht nutzen? Hinzu kommt, dass es seitens des Regulators auch in die Richtung zu gehen scheint, dass Finanzinstitute in Zukunft nicht einfach mit einem Disclaimer im Vertrag die Risiken beim Einsatz von „Corporate Seals“ von sich weisen können (siehe dazu auch das Dokument der EZB „Assessment Guide for the Security of Internet Payments“).

Einheitliche Rezeptur gewünscht 

Das Problem hierbei ist die Vielfalt der EBICS-Varianten, die sich jetzt ergeben und die Frage, welche Variante dann im Markt von den Teilnehmern - Kunde, Softwarehersteller und Bank - umgesetzt werden soll. Gibt es jetzt CA-basierte Zertifikate und falls ja, für welche Art von Schlüssel? Welche CAs werden bankübergreifend akzeptiert? Welche Qualität sollte so ein Zertifikat aufweisen? Gilt die Anwendung von Hardwaretokens nur für die Signatur (A005/A006) oder auch für die anderen Schlüssel zur Authentisierung und Verschlüsselung? Wäre auch ein Einsatz von Hardtokens ohne CA denkbar, also nur die externe Aufbewahrung der Schlüssel beim signierenden Auftraggeber?

Das Ganze erinnert etwas an unser Birchermüsli, wo es ebenfalls die verschiedensten Varianten und Rezepte gibt. Die EBICS-Gesellschaft verfolgt ja das Ziel, den Standard in Europa zu etablieren. Hier wäre eine einheitliche Rezeptur für das Schlüssel-Birchermüsli sicher ein Pluspunkt, den auch die Anwender schätzen würden. Ansonsten wird es schwierig mit dem länderübergreifenden Standard. Meiner Meinung nach sollte dieser Punkt auf der Agenda der EBICS Working Group einen prominenten Platz einnehmen.

Carsten Miehling