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 

Portugal im Zeitalter von EBICS

So wie die französischen Banken 2009 und die deutschen Banken 2008 wollen nun auch zahlreiche portugiesische Banken im Finanzverkehr mit Unternehmen auf das EBICS-Protokoll umstellen.

Diese Umstellung hat zwei Hauptgründe:

1. die von Portugal Telecom geplante Abschaltung des X.25-Netzwerks zum 30. Juni 2014,

2. der Umstand, dass einige bisher verwendete Protokolle nicht in der Lage sind, Dateien mit Datensätzen variabler Größe zu übertragen, wie dies bei SEPA-Formaten der Fall ist.
Folglich mussten portugiesische Banken ihren Unternehmenskunden einen alternativen Übertragungskanal anbieten, der gut zugänglich, sicher, kostengünstig und grenzüberschreitend zugleich ist.


Angesichts der positiven Erfahrungen in Deutschland und Frankreich mit der Migration auf EBICS sowie mit dem täglichen Gebrauch des EBICS-Protokolls haben sich die portugiesischen Banken entschlossen, ihr Serviceangebot um den EBICS-Kanal zu erweitern. Einige unter ihnen haben sich dazu für die Lösung TRAVIC-Corporate entschieden, einen Bankserver von PPI.

Dabei fiel die Wahl auf die EBICS-Version 2.4, welche gegenwärtig auch in Frankreich verwendet wird. Betriebsbereit ist bis heute nur das T-Profil.

Die über den EBICS-Kanal vermittelten Daten können unterschiedlichster Art sein: Inlandszahlungen im Format PS2, Überweisungsaufträge im SWIFT-Format MT101, SEPA-Überweisungen (SCT) und SEPA-Lastschriften (SDD), Kontoauszüge, Confirming, Devisenkurse und -notierungen, proprietäre Formate für Schreiben mit abtrennbarem Scheck sowie für das Factoring etc.

Des Weiteren boten einige in Portugal ansässige Hersteller bereits vor mehreren Monaten unternehmensspezifische Softwarelösungen an, die das EBICS-Protokoll unterstützen. Dies gilt insbesondere für MetaCase, den portugiesischen Partner von PPI, der mit Target One ein System zur EBICS-Verwaltung in die von ihm herausgebrachte Verwaltungsplattform implementiert hat. Dass diese Implementierung des EBICS-Protokolls noch erfolgte, bevor portugiesische Banken ihren Kanal öffneten, ist dem Wunsch einiger portugiesischer Unternehmen geschuldet, Finanzdaten mit deutschen und/oder französischen Banken austauschen zu können.

Die von den meisten portugiesischen Banken getroffene Wahl verdeutlicht, wie sehr sich das EBICS-Protokoll für einen großflächigen Einsatz in Europa eignet und so zu einem sicheren, leichteren und kostengünstigen Datenaustausch zwischen Unternehmen und Banken innerhalb des SEPA-Raums beitragen kann.

Marc Dutech 

Vereinheitlichung des Zahlungsverkehrs durch SEPA ist noch Zukunftsmusik



Jetzt haben wir in Europa zwar schon SEPA für den einheitlichen Zahlungsverkehr eingeführt, aber dennoch lassen sich SEPA-Zahlungen nicht einfach elektronisch an jede beliebige Bank in Europa schicken. In Deutschland nutzen Unternehmen die Auftragsart CCT für die Einreichung der SEPA-Überweisung (SEPA Credit Transfer) bei Kreditinstituten. Weshalb sind SEPA-Überweisungen aus beliebigen Euro-Ländern mit dieser Auftragsart nicht ohne weiteres möglich?

Die XML-basierten SEPA-Datenformate wurden mittlerweile flächendeckend in den beteiligten europäischen Ländern eingeführt. Ziel war und ist es, nach der Einführung der einheitlichen Währung jetzt auch die Datenformate und Regularien im Zahlungsverkehr zu vereinheitlichen und so einen einfacheren innereuropäischen elektronischen Zahlungsverkehr zu ermöglichen.

Basierend auf den ISO20022 XML-Formaten und den Vorgaben des European Payments Council (EPC) wurden jedoch die Umsetzungen in den europäischen Ländern unter Berücksichtigung nationaler Ausprägungen des Zahlungsverkehrs separat ausspezifiziert. Als Ergebnis haben wir heute für die gleichen Geschäftsvorfälle länderspezifisch ausgeprägte SEPA-Formate.
Die Unterschiede beginnen bereits im Namensraum der Formate. Während zum Beispiel Deutschland für SEPA-Überweisungen mit pain.001.002.03 eine eigene Datenformatvariante eingeführt hat, nutzen andere Länder die pain.001.001.03 des EPC. Auch im Namespace des XML werden hier nationale Unterschiede deutlich. Zudem gelten national abweichende Belegungsregeln.
In Deutschland werden die SEPA-Zahlungen mittels EBICS mit den dreistelligen Auftragsarten gekennzeichnet und übertragen (zum Beispiel CCT für SEPA-Überweisung). Bei dem mit der Auftragsart verbundenen Format geht man laut Spezifikation  von der Formatausprägung der Deutschen Kreditwirtschaft (DK) aus. Was ist aber, wenn ein ausländischer Kunde in seinem nationalen Format eine SEPA-Überweisung an eine deutsche Bank schickt? Weder die Auftragsart noch der Namespace im XML liefern dabei einen verlässlichen Hinweis auf die verwendeten Formatbesonderheiten. Die Bank muss aber auf diese Besonderheiten reagieren, wenn sie grenzüberschreitend Zahlungsverkehr abwickeln will. Wie also können Banken die unterschiedlichen Formatausprägungen erkennen und entsprechend bearbeiten?

Mögliche Lösung: Issuer-Kennzeichen für EBICS

Solange keine vollständige Vereinheitlichung der SEPA-Formate, die zwischen Unternehmen und Kreditinstituten ausgetauscht werden, auf europäischer Ebene erfolgt, muss die Lösung an anderer Stelle gefunden werden. Dafür gibt es verschiedene Ansätze. Ein Ansatz fordert die Softwarehersteller heraus, die intelligente Formatparser oder spezielle Stammdatenerweiterungen im Bankrechner entwickeln müssten. Ein anderer und sicher langfristig sinnvollerer Ansatz ist, sich die Vorteile des EBICS-Standards zunutze zu machen.

In Frankreich hat man das Problem bereits gelöst, durch Nutzung der Formatparameter und des mit EBICS übermittelten Country Codes. Aus dem Country Code kann der EBICS-Bankrechner die länderspezifische Formatausprägung ableiten und somit eigene Verarbeitungswege initiieren. In Deutschland ist der Einsatz von Formatparametern allerdings nicht üblich. Daher wird derzeit in Deutschland die Einführung eines Issuer-Kennzeichens für EBICS diskutiert. Dieses würde zu dem Geschäftsvorfall den Herausgeber des Formats und somit die Formatausprägung mitliefern. Ein Bankrechner kann daran erkennen, ob beispielsweise für die angegebene Formatkonstellation Vereinbarungen und Prüfregeln existieren. Wenn sich das französische Modell der Formatparameter mit Country Code nicht in Deutschland einführen lässt, so sollte zumindest das Issuer-Kennzeichen an der Auftragsart bald mit EBICS umgesetzt werden. Eine solche Lösung ist sinnvoll und hoffentlich bald mit EBICS verfügbar. Bis dahin müssen Banken und deren Kunden sich wohl noch mit anderen individuellen Lösungen begnügen.

Auf die Besonderheiten in der Nutzung der dreistelligen EBICS-Auftragsarten in Deutschland und der Formatparameter in Frankreich  werde ich in einem Folgebeitrag eingehen.

Michael Lembcke 
 

EBICS auch in der Schweiz angekommen

Werfen wir zunächst einen Blick zurück zum siebten Petersberger Electronic-Banking-Forum am 10. November 2011: Christian Schwinghammer von SIX Interbank Clearing Schweiz hielt dort einen Vortrag zum Thema „EBICS goes Europe – Wo steht die Schweiz?“. Christian Schwinghammer, seines Zeichens ein großer Kenner des Finanzplatzes Schweiz, war schon damals recht zuversichtlich, dass der Standard sich auch bei den Schweizer Finanzinstituten durchsetzen wird, zumal mit UBS und Credit Suisse bereits zwei Schwergewichte den Kommunikationskanal EBICS im Angebot hatten.

Wie so oft will aber auch in diesem Fall gut Ding Weile haben. Die oftmals angekündigte Annährung zwischen der EBICS-Gesellschaft und den Schweizer Vertretern wurde ein ums andere Mal verschoben und kam nur harzig in die Gänge. Seitens der Bankmanager trat das Thema EBICS angesichts der intensiven Steuerdebatten mit Europa (Abgeltungssteuer) und den USA (FATCA) in den Hintergrund.

Nichtsdestotrotz konnte die EBICS-Arbeitsgruppe mit Vertretern der Schweizer Großbanken Anfang 2012 eine erste Version des „Implementation Guides EBICS“ zum Review versenden.

Schweizer Alleingang bei Implementierungsrichtlinien

Die Schweizer Implementierungsrichtlinien wurden damals unabhängig von der EBICS-Arbeitsgruppe erstellt, was in der Folge für Diskussionsstoff gesorgt hat und auch noch weiter sorgen wird. So bediente sich die Arbeitsgruppe für die Schweizer EBICS-Auftragsarten nach deutschem Vorbild bei den frei verfügbaren dreistelligen Auftragsarten. Konkret wurde dem Schweizer Datenträger-Austauschverfahren beispielsweise die Auftragsart „XKD“ zugewiesen. Weil sich UBS und Credit Suisse mehrheitlich an der deutschen Implementierung orientiert haben und die dreistelligen Auftragsarten bereits bei den Kunden im Einsatz sind, ist dieses Modell „de facto“ als Standard für die Schweiz gesetzt.

Trotzdem erscheint vielen Schweizern das französische „FUL/FDL“-Modell als flexiblere und architektonisch elegantere Variante. Ihr haftet nicht die deutsche Historie der dreistelligen Auftragsarten an, die schon im Vorgängerprotokoll FTAM verwendet wurden. Zudem scheint bei einer weiteren Ausweitung von EBICS auf zusätzliche Länder in Europa und der Welt der Vorrat an dreistelligen Kombinationen zur Neige zu gehen. Eine Umstellung auf das französische Modell wäre allerdings mit enormem Aufwand verbunden.

Obwohl in diesem Punkt also noch Uneinigkeit herrscht, scheint EBICS definitiv in der Schweiz angekommen zu sein. Die Einführung bei den Kantonalbanken von Luzern im Herbst dieses Jahres und Zürich Anfang nächsten Jahres wird der Verbreitung in der Schweiz den notwendigen Schub verleihen. Dem Vernehmen nach stehen bereits weitere Kantonalbanken in den Startlöchern und evaluieren EBICS-Lösungen für ihre Kunden. Auch in Bezug auf den Beitritt zur EBICS-Gesellschaft ist die Alpenrepublik einen grossen Schritt weiter gekommen: Es liegen konkrete Angebote zum Beitritt in die Gesellschaft vor und ein erstes Dreiländer-Treffen der EBICS-Arbeitsgruppe ist im August in Zürich geplant.

Es wird spannend zu beobachten sein, wie sich die „Ménage-à-trois“ in der Praxis bewähren wird. Den Schweizern könnte hier eine wichtige Rolle zukommen, sind sie doch bekannt für ihr diplomatisches Geschick und ihre Mehrsprachigkeit. Gerüchten zufolge war die Beziehung der deutschen und französischen Akteure in der Vergangenheit nicht immer nur harmonisch. Die Verwendung der bereits erwähnten frei verfügbaren Auftragsarten in der Schweiz ist unter anderem auch ein Auslöser für einen konkreten Change Request zu Händen der EBICS-Gesellschaft (EB-14-DK-int04 OrderType with issuer). Die Verwendung eines „Issuer Codes” zur jeweiligen Auftragsart soll die Verwendung von gleichen Auftragsarten in einer anderen Community erleichtern. Die Schweizer Auftragsart für einen Auftrag im Format pain.001 (CCT) könnte somit zum Beispiel eindeutig von derjenigen in Frankreich und Deutschland unterschieden werden, indem ein „Issuer Code“ für die Schweiz angefügt werden würde.