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