Die Einführung von EBICS 3.0 stellt Anforderungen an die Implementierungen, da für eine gewisse Übergangszeit parallel EBICS-2.5-Kunden unterstützt werden müssen. Ziel für die Umsetzung muss primär die volle Abdeckung der Anforderungen gemäß der EBICS-Spezifikation Version 3.0 sein, um Schritt für Schritt die gewünschte Harmonisierung erreichen zu können. Dabei sollen sich möglichst geringe Auswirkungen auf die Endkundenverträge ergeben, und der Umstellungsaufwand für Institute und Hersteller soll möglichst gering sein.

Generell sind für das Zusammenspiel folgende Themen relevant:

• einheitlich im Zertifikatsformat
• Versionskompatibilität in einem Vertrag
• nationale BTF-Mappings
• Sonderfall VEU und Signatur-Flag
• Praxisanforderung: Beibehaltung der Schnittstellen
• Kryptografische Anforderungen

Einheitlich im Zertifikatsformat

Mit EBICS 3.0 ist X.509 das einzig zugelassene Zertifikatsformat. Dies bedeutet, dass zumindest die X.509-Syntax im Rahmen des H005-Schemas unterstützt werden muss. Aufgrund des Fehlens einer PKI-Infrastruktur werden für eine Übergangszeit CA-basierte Zertifikate bei einem DK-Profil nicht gegen die ausgebende CA geprüft. Unabhängig davon wird jedoch lokal das Gültigkeitsdatum des Zertifikats gegen das aktuelle Datum geprüft.

Versionskompatibilität in einem Vertrag durch BTF-Mapping

BTF wird zusätzlich zu den bekannten Auftragsarten und Datenformaten eingeführt. Damit ergibt sich für ein Institut die Situation, dass entsprechend den Kundeninstallationen Aufträge mit unterschiedlichen EBICS-Versionen 2.5 und 3.0 eingereicht werden können. Ein Mapping zwischen BTF und Auftragsart ermöglicht es, unter bestimmten Rahmenbedingungen auch für BTF-Aufträge auf der bestehenden, auf der Auftragsart basierenden Berechtigungsstruktur aufzusetzen und so eine Kompatibilität herzustellen.

Sonderfall VEU und Signatur-Flag

Wie in der Abbildung gezeigt, beeinflussen Kundenvertrag, Auftrag und Signatur-Flag, ob ein eingereichter Auftrag mit nicht ausreichender Autorisierung abgelehnt oder an die VEU-Verarbeitung weitergeleitet wird.

Praxisanforderung: Beibehaltung der Schnittstellen

Die Spezifikation von EBICS 3.0 öffnet die Tür zu einer weitgehenden Harmonisierung der europäischen EBICS-Landschaft und erhöht damit auch die Attraktivität für andere Länder, diesen Standard einzuführen.

Umgekehrt muss bei der Einführung von EBICS 3.0 in bestehende Implementierungen darauf geachtet werden, dass Schnittstellen zu Anwendungssystemen erhalten bleiben, um das Ziel einer ressourcenschonenden Migration erreichen zu können.

Berücksichtigung kryptografischer Anforderungen

Wie in den entsprechenden Folgeabschnitten noch beschrieben wird, werden mit EBICS 3.0 einige kryptografische Verfahren nicht mehr unterstützt. Betroffen davon sind das Authentifikationsverfahren X001, das Signaturverfahren A004 und das Verschlüsselungsverfahren E001.

Zudem sollen nur noch RSA-Schlüssel mit mindestens 2.048 Bit zum Einsatz kommen.

Die DK hat für Deutschland auf www.ebics.de eigens das Dokument Krypto LifeCycle EBICS ^[6] veröffentlicht. Dieses Dokument macht Vorgaben für die im EBICS-Verfahren zur Anwendung kommenden kryptografischen Komponenten unter Berücksichtigung der Empfehlungen des Bundesamtes für Sicherheit in der Informationstechnik (BSI). Das Dokument wird entkoppelt von der EBICS- Spezifikation gepflegt.

Nach dieser Beschreibung des Zusammenspiels der unterschiedlichen Versionen berücksichtigen die nächsten Abschnitte nur noch die aktuelle EBICS-Version 3.0.

Der EBICS-Spezifikation ist schon beim ersten Lesen anzumerken, dass sie nicht auf dem Reißbrett entstanden ist, sondern die in der Praxis vorkommenden Szenarien optimal abbildet. Dies liegt auch daran, dass im Vorfeld der Spezifikation bereits Produkte am Markt entstanden sind, die eine Art Proof of Concept darstellten. Allen Produkten war gemeinsam, dass sie Möglichkeiten aufzeigten, den Massenzahlungsverkehr für Firmenkunden auf Internetplattformen abzubilden. Ergänzend setzte jedes Produkt auch eigene Ideen für Anwendungserweiterungen um. So konnten aus diesem Portfolio die optimalen Lösungsansätze den Weg in den EBICS-Standard finden und dort typische Anfängerfehler vermeiden helfen. Auf diese Weise wird auch verständlich, dass bereits bei Einführung von EBICS Probleme wie die Segmentierung großer Nachrichten gelöst waren oder das Konzept für die Verteilte Elektronische Unterschrift bereits in ausgereifter und erprobter Form zur Verfügung stand und nicht erst mit dem ersten Praxiseinsatz ergänzt oder optimiert werden musste.

Bereits seit einigen Jahren gehören browserbasierte Firmenkundenportale zum Basisangebot eines jeden Instituts. Da EBICS ebenfalls auf Internettechnologien aufsetzt, liegt der Schluss nahe, dass diese beiden Welten harmonisch zusammengeführt werden können. Dies ist auch in der Tat der Fall, solange es sich um ein institutseigenes Portal handelt.

Während das TCP/IP-Protokoll sich im Netz um Aufgaben wie z. B. das dynamische Routing bei Ausfall einer Teilstrecke kümmert, kontrolliert HTTP die Session zwischen zwei Partnern. Bei EBICS kommt nur die gesicherte Variante HTTPS zum Einsatz, was z. B. im Browser durch ein Schloss in der unteren Ecke angezeigt wird. Verantwortlich für diese Absicherung ist TLS (Transport Layer Security), welches das bisherige SSL (Secure Socket Layer) ablöst.

Die Ablösung von SSL auf TLS weist auf ein grundsätzliches Problem der Verquickung von Internettechnologien mit Anwendungsstandards hin: Inzwischen sind nämlich laut Aussage des deutschen Bundesamtes für Sicherheit in der Informationstechnik (BSI) die Versionen 1.0 und 1.1 des TLS-Protokolls ebenfalls als obsolet anzusehen und abzulösen. Bisher war man durch die Integration dieser Standards in die EBICS-Spezifikation sehr unflexibel. Mit Einführung von EBICS 3.0 wurden die Sicherheitsverfahren der Transportschicht in ein eigenes Dokument überführt, das nun unabhängig vom fachlichen Standard gepflegt werden kann.

TLS sorgt für eine sichere Übertragung zwischen dem Kundensystem und dem ersten HTTP-Server oder besser Webserver im Institut. Aktuell wird mind. die Version 1.2 empfohlen. Diese Aufgabe erfüllt es auch hinreichend gut und sicher, was jedoch für die EBICS-Standardisierer nicht ausreichend war, wie im übernächsten Abschnitt erläutert wird.

Um die folgenden Abschnitte besser verstehen zu können, wird an dieser Stelle der XML-Standard erläutert. Während die notwendigen Protokollaufgaben bei BCS noch im Dateinamen versteckt werden konnten, wird bei EBICS aufgrund der Fülle der Aufgaben ein separater Protokollumschlag benötigt. Im Rahmen der Internettechnologie ist es sinnvoll, hierfür die Datenbeschreibungssprache XML – Extensible Markup Language – zu verwenden.

Bei EBICS besteht jeder Request bzw. Response aus einem Auftrag analog den definierten Auftragsarten bzw. einem BTF-Container und einem XML-Umschlag. Es handelt sich also um eine Art Hybridsystem, bei dem das Kernstück die bankfachlichen SEPA- oder SWIFT-Formate bleiben, die aber um XML-Strukturen ergänzt werden. Der Overhead, der durch diese Technik verursacht wird, ist minimal, wenn man bedenkt, dass es sich typischerweise um Massenzahlungsverkehr handelt, die Zahlungsverkehrsdatei also ein Vielfaches des XML-Umschlags darstellt.

Die folgende Abbildung zeigt alle in EBICS definierten XML-Schemata. Diese sind – entsprechend dem XML-Namespace-Konzept – unter den zugehörigen Adressen www.ebics.de abgelegt.

Es wird erkennbar, dass die Schemata klar strukturiert sind und die Typ-Definitionen von den fachlichen Protokollschemata getrennt sind.

Eine Besonderheit stellt das erste Schema dar. H000 dient zur Versionsverwaltung und ermöglicht es dem Kundenprodukt, abzufragen, welche Protokollversionen das Institut unterstützt.

Nicht dargestellt ist hier der Namespace S001, der das EBICS-Signaturschema enthält. Die aktuellen Versionen der EBICS-Schemata finden Sie auf den offiziellen Websites ebics.org bzw. ebics.de.

Durch Optimierungen im Kommunikationsbereich wurde den speziellen Eigenschaften des Internets Rechnung getragen.

Bei EBICS besteht die Möglichkeit, die Übertragungsdaten zu komprimieren. Hierfür bedient sich EBICS des lizenzfreien und weit verbreiteten ZIP-Algorithmus.

Große Datenmengen können im EBICS-Protokoll segmentiert werden, um die Kapazitäten der Internetinstanzen auf Institutsseite nicht zu blockieren.

Die optionale Recovery-Fähigkeit dieses Protokolls ermöglicht auch intelligentes Wiederaufsetzen der Transaktion, wenn eine Dateiübertragung abgebrochen ist. Bereits übertragene Segmente müssen also nicht doppelt über die Leitung geschickt werden.

EBICS stellt über  Nonce und  Timestamp auch ein Verfahren bereit, das es ermöglicht, Doppeleinreichungen (Replays) zu erkennen. Hierfür erzeugt ein Kundenprodukt einen zufälligen Wert  Nonce (zu übersetzen als Ad-hoc-Wert) und setzt diesen zusammen mit einem Zeitstempel in den EBICS-Umschlag. Institutsseitig wird eine Liste von bereits vom Teilnehmer verwendeten Werten für  Nonce und  Timestamp vorgehalten, wodurch die Eindeutigkeit eines Auftrags überprüft werden kann.

Ein wesentlicher Aspekt zur Erreichung eines hohen Niveaus an Infrastruktursicherheit ist das durchgängige Konzept für Signatur und Verschlüsselung in EBICS. Kundensignaturen sind bei EBICS Pflicht. Bankensignaturen sind vorgesehen und werden konkret definiert, wenn die rechtlichen Auswirkungen geregelt sind (Stichwort personenbezogene Bankensignatur vs. Firmenstempel). Hinzu kommt noch die zusätzliche Authentifikationssignatur X002.

Auch bei der Verschlüsselung macht EBICS keine halben Sachen: Außer der zwingenden Verschlüsselung mit TLS auf Transportebene ist ebenfalls das EBICS-eigene Verschlüsselungsverfahren E002 verpflichtend, um eine Ende-zu-Ende-Sicherheit zu gewährleisten.

In einem speziellen Initialisierungsschritt, in dem optional Vorabprüfungen durchgeführt werden können, wird unter anderem auch eine Transaktions-ID für die gesamte Transaktion vergeben. Dies ermöglicht die Bildung einer Transaktionsklammer und ist Voraussetzung für die Segmentierung bei der Übertragung großer Datenmengen.

Durch diese Festlegungen wird ein Maß an Sicherheit erreicht, welches einem Betrieb im Internet angemessen ist und dessen Stärke auch in einem entsprechenden Sicherheitskonzept untersucht und belegt wurde.

Mehr Details zu den Protokolleigenschaften selbst befinden sich im Abschnitt EBICS-Abläufe.

EBICS kennt zwei unterschiedliche Signaturen:

• Authentifikationssignaturen zur Identifizierung des Einreichers
• Auftragssignaturen, Elektronische Unterschrift (EU) zur bankfachlichen Autorisierung von Aufträgen

Die beiden Signaturarten unterscheiden sich grundsätzlich, wie die folgende Abbildung zeigt:

Die Authentifikationssignatur dient dazu, den Einreicher eindeutig zu identifizieren. Die Authentifikationssignatur wird im Rahmen des Initialisierungsschrittes sowie in jedem weiteren Transaktionsschritt geprüft, also noch bevor die eigentlichen Auftragsdaten übertragen werden (siehe Abschnitt EBICS-Abläufe).

Teilnehmer, die ausschließlich Aufträge einreichen, können die Unterschriftsklasse T besitzen, wodurch es auch möglich ist, reine „technische Teilnehmer“ einzurichten, die dann nur zur Einreichung von Aufträgen berechtigt sind.

Die Bildung der Authentifikationssignatur entspricht dem gängigen Vorgehen im Transaktionsbereich. Die Aufträge werden um dynamische Informationen wie Session-ID, Timestamp oder Ähnliches ergänzt, um bei gleichen Nutzdaten unterschiedliche und zur speziellen Situation gehörige Signaturen zu erhalten. Kryptologen verwenden hierfür den Begriff Redundanz. Über die gesamte Struktur wird eine kryptografische Prüfsumme, der Hashwert, gebildet. Die wichtigste Eigenschaft des Hashwerts ist es, mit konkret vorgegebenen Daten exakt einen Wert zu erzeugen, der über praktisch keine andere Datenkombination erzeugt werden kann. Es besteht also eine 1:1-Beziehung zwischen Daten und Hashwert.

Über diesen Hashwert wird mithilfe eines Signaturschlüssels eine digitale Signatur gebildet. Um exakt zu sein, muss erwähnt werden, dass die Daten vor der Hashwertbildung nach einem vorgegebenen Algorithmus auf eine bestimmte Mindestlänge aufgefüllt werden (Padding), damit dieser Mechanismus auch bei kleinen Datenmengen funktioniert.

Da dieses Vorgehen im Transaktionsgeschäft gängig ist, wird es auch im W3C-Standard XML-Signature in dieser Weise unterstützt. Daher unterstützt EBICS die Authentifikationssignatur analog XML-Signature als Standard X002 und X001 (veraltet) und ab EBICS 3.0 nur noch X002.

Die Elektronische Unterschrift (EU) eines Auftrags auf Kundenseite (bzw. zukünftig auch auf Institutsseite) erfolgt seit EBICS 2.4 verpflichtend durch die neuen Verfahren A005 und A006. Im Gegensatz zur Signaturbildung bei der Authentifikationssignatur sind hier die Schritte Redundanzbildung und Hashwertbildung vertauscht. Aufgrund der Verwendung des Dateihashwerts als wichtige, direkte Repräsentanz der Originaldaten wird dieser ohne Redundanz direkt über die Auftragsdatei gebildet und ist somit an jeder Stelle direkt überprüfbar.

EBICS forderte aus Gründen der Migrationsfähigkeit die RSA-Signatur nach A004 als Einstieg – ältere Signaturvarianten des DFÜ-Abkommens wurden nicht mehr unterstützt. Bereits A004 war von den Verfahren her auf die aktuelle Signaturkarte der deutschen Kreditwirtschaft mit SECCOS als Betriebssystem zugeschnitten, unterstützte diese Verfahren aber wie gesagt auch über Disketten oder USB-Sticks.

Aus den von SECCOS unterstützten Verfahren wurde bei A004 ein Profil, bestehend aus folgenden Algorithmen unterstützt:

• RSA-Signatur mit Schlüssellängen von 1.024 Bit
• Padding nach ISO9796-2
• Hashwertverfahren RIPEMD160

Heute gängig und seit EBICS 2.4 auch als verpflichtend deklariert, unterstützen die robusteren EU-Verfahren A005 und A006 die folgenden Attribute:

Die Darstellung zeigt, dass sich A005 und A006 lediglich im Padding-Verfahren unterscheiden.

Aus der Darstellung der Sicherheitsverfahren und dem Bezug zum SECCOS-Chipkartenbetriebssystem könnte man ableiten, dass es sich bei diesem Teil der EBICS-Spezifikation eher um eine deutsche Ausprägung handelt. Dies ist aber keineswegs der Fall. Gerade durch die DK-Kartenstrategie, die sich streng an dem jährlich erscheinenden BSI-Krypto-Katalog und damit an der nationalen Ausprägung der EU-Signaturrichtlinie orientiert, ist eine Verwendung internationaler Standards gewährleistet.

Mit EBICS 3.0 wird generell eine Schlüssellänge von mindestens 2.048 Bit vorgegeben. Ebenso sollen noch vorhandene A004-Schlüssel umgestellt werden.

Bevor ein Schlüsselpaar verwendet werden kann, muss erst über ein geeignetes Verfahren die Authentizität der Partner hergestellt werden. Hierfür werden entweder Zertifikate oder aber alternative Verfahren über separate Wege verwendet. Die Unterstützung von Zertifikaten nach X.509 ist in EBICS zwar vorgesehen, aktuell wird in Deutschland jedoch noch das Verfahren mittels Initialisierungsbrief verwendet. Frankreich verfügt zur Einführung des EBICS-Standards bereits über eine geregelte PKI-Infrastruktur. Daher können dort auch Zertifikate im Rahmen der Initialisierung verwendet werden, was durch den Standard seit EBICS 2.5 auch lückenlos unterstützt wird.

Beide Konzepte werden im Folgenden kurz dargestellt, wobei ersichtlich wird, dass die beiden Welten sich derzeit auch noch vermischen können, wie das Fallback-Szenario in Frankreich zeigt.

Die Grundlage für ein zertifikatsbasiertes Verfahren stellt eine geeignete Security Policy dar. Dies bedeutet, es muss geregelt sein, welche Zertifikatsherausgeber bis zu welchem Grad als sicher angenommen werden können. In Frankreich gibt es hierfür klare und publizierte Definitionen für die Nutzung von Zertifikaten in EBICS. Die höchste Stufe stellen dabei die Herausgeber qualifizierter Zertifikate nach der europäischen Signaturrichtlinie dar. Für den reinen Austausch von Zahlungsverkehrsdateien sind in Frankreich aber auch geringere Sicherheitsniveaus ausreichend, wie die folgende Detaillierung zeigen soll.

In Frankreich werden die Unterschriftsklassen T und E eingesetzt. Derzeit wird keine verteilte EU unterstützt. Stattdessen existieren zwei Grundprofile für Einreichung (T) und Autorisierung (E).

Für die Einreichung von Zertifikaten kann ab Version 2.5 die neu geschaffene Auftragsart H3K verwendet werden. Die restlichen Prozesse zur Initialisierung eines Kunden bleiben aus EBICS-Sicht unverändert gültig.

• Einreicherprofil T auf Basis von Zertifikaten bereits ab EBICS 2.4
  Die Initialisierung muss nicht zwingend über eine gelistete Zertifizierungsinstanz (CA) erfolgen. Auch selbstsignierte Zertifikate des Instituts mit INI- Brief sind möglich.
  Falls das Zertifikat jedoch von einer CA ausgestellt ist, muss diese sich auf der Trusted List befinden.
• Autorisierungsprofil TS
  Hierbei werden die Elektronischen Unterschriften für Transport und Signatur verwendet. Das Verfahren entspricht grob dem ETEBAC-5-Standard. Das Zertifikat für den Signaturschlüssel muss in diesem Fall von einer CA herausgegeben und signiert sein und diese muss sich auch in der Trusted List befinden. Die Zertifikate für den Authentifikations- und Verschlüsselungsschlüssel können auch selbstsigniert sein.
  Die Zertifikatsprüfung ist für den Signaturschlüssel verpflichtend vorgeschrieben, für Zertifikate für den Authentifikations- und Verschlüsselungsschlüssel findet die Prüfung gegen die CA statt, wenn die Zertifikate von einer CA ausgestellt wurden.
• INI-Brief als Fallback-Szenario
  Auch bei der Verwendung von Zertifikaten sind INI-Briefe in Frankreich Bestandteil des Initialisierungsprozesses. Unabhängig von der Verwendung von Zertifikaten muss der Kunde zu Beginn in jedem Fall einen INI-Brief schicken.
  Nicht-CA-basierte Zertifikate werden ausschließlich über den INI-Brief freigeschaltet. CA-basierte Zertifikate müssen stets von der CA geprüft werden. Bei erfolgreicher Zertifikatsprüfung durch die CA müssen zusätzlich definierte Zertifikatsangaben mit übermittelten Angaben des Einreichers abgeglichen werden. Stimmen die Angaben nicht überein, kann immer noch – auf Basis der Angaben im INI-Brief – eine manuelle Freischaltung stattfinden.

Das Zertifikat des Kunden wird nach erfolgreicher Prüfung und Freischaltung im Anwendungssystem gespeichert. Auf dieser Basis werden die zukünftigen Sperrabfragen durchgeführt – der Kunde muss das Zertifikat also nur einmal einreichen.

Unabhängig von den in Frankreich üblichen Autorisierungs- und Einreichungsprofilen wird mit EBICS 3.0 generell das Zertifikatsformat für Schlüssel verwendet. Die Nutzung bleibt zunächst jedoch unterschiedlich, sodass der Effekt der Harmonisierung noch nicht sichtbar wird.

Beim INI-Brief-Verfahren erzeugt ein Teilnehmer ein Schlüsselpaar und übermittelt seinen öffentlichen Schlüssel mit der Auftragsart INI (bzw. HIA, wenn es sich um einen öffentlichen Schlüssel für die Authentifikationssignatur oder für die Verschlüsselung handelt) an das Institut. Parallel hierzu wird ein Initialisierungsbrief ausgedruckt, der administrative Daten, den öffentlichen Schlüssel und den zugehörigen Hashwert enthält. Dieser Initialisierungsbrief wird vom Teilnehmer manuell unterschrieben und per Briefpost oder Fax an das Institut geschickt und dort mit den elektronisch übermittelten Daten verglichen. Bei Gleichheit wird der Schlüssel freigeschaltet und kann nun vom Teilnehmer verwendet werden. Das gleiche Verfahren kann in umgekehrter Richtung verwendet werden, wenn zu einem späteren Zeitpunkt die Banksignatur eingeführt wird. Hier hat nun der Teilnehmer die Aufgabe, die elektronisch und postalisch übermittelten Schlüsseldaten zu vergleichen und deren Übereinstimmung zu bestätigen.

Bei EBICS wird eine doppelte Verschlüsselung nach TLS und dem eigenen EBICS-Verfahren aktuell E002 verwendet (E001 ist die veraltete Version), um sowohl die Standardverschlüsselung in HTTPS als auch eine Ende-zu-Ende-Verschlüsselung zu erhalten. Bei E002 wird das vom BSI seit 2009 empfohlene AES-Verfahren eingesetzt.

TLS ist der Nachfolger des SSL. Beide Verschlüsselungsprotokolle besitzen die Eigenschaft, auf einer Transportstrecke sowohl Authentifizierung als auch Verschlüsselung zu gewährleisten. Entsprechende Implementierungen befinden sich kundenseitig z. B. im Internetbrowser und institutsseitig in gängigen       
Webservern.

Beim Aufbau einer TLS-Verbindung werden Zertifikate und unterstützte Verfahren zwischen den Partnern ausgetauscht und darauf basierend eine Session aufgebaut.

EBICS verwendet wie allgemein üblich nur die Serverauthentifizierung aus TLS und unterstützt derzeit keine TLS-Client-Zertifikate. Als Serverzertifikate werden die allgemein von den Instituten verwendeten Internetzertifikate benutzt (die z. B. über VeriSign zertifiziert sind).

Verschlüsselt wird in beiden Richtungen. Als Verfahren werden nur die starken Verschlüsselungsverfahren bzw. Cipher Suites unterstützt. Gültige Cipher Suites sind auf der Website der Deutschen Bundesbank bzw. unter ebics.de abrufbar.

Hier nochmals der Hinweis, dass die Transport Layer Security mit EBICS 3.0 in ein eigenes Dokument ausgelagert wurde.

Bei E001/E002 handelt es sich um ein sogenanntes Hybridverfahren, d. h., es besteht aus asymmetrischen und symmetrischen Algorithmen. Dabei wird grundsätzlich als Basis ein asymmetrischer RSA-Schlüssel als Verschlüsselungsschlüssel verwendet. Die Nachricht selbst wird aus Performance-Gründen symmetrisch verschlüsselt. Als Key wird ein dynamischer Schlüssel verwendet, der – mit dem Verschlüsselungsschlüssel gesichert – ausgetauscht wird.

E001 verwendete einen 1.024 Bit langen Verschlüsselungsschlüssel und den Padding-Algorithmus PKCS#1. Spätestens mit Einführung von EBICS 3.0 entfällt die Unterstützung von E001 in den Implementierungen. Mit Einführung von EBICS 3.0 und der Vorgängerversion 2.5 ist EBICS 2.4 obsolet und damit auch die Verfahren E001, X001 und A004.

Mit EBICS 2.4 wurde E002 als Weiterentwicklung eingesetzt. Hier erfolgt der Übergang von Triple-DES auf AES (BSI-Empfehlung ab 2009).

Im DFÜ-Abkommen für Deutschland, durch die Schweizer Implementation Guidelines sowie die Formatstandards des CFONB in Frankreich werden mit EBICS u. a. folgende Anwendungsgebiete durch operative Auftragsarten und FileFormat-Parameter – bzw. ab EBICS 3.0 einheitlich durch die betreffenden BTF-Vorgaben – unterstützt:

• SEPA-Zahlungsverkehr und sonstiger nationaler Zahlungsverkehr
• Auslandszahlungsverkehr
• Wertpapiergeschäft
• Akkreditivgeschäft
• Tageskontoauszugsinformationen sowie sonstige Informationen für gebuchte Umsätze und Kontoumsatzavise (u. a. in den Formaten MT940/MT942 oder camt-XML)

Zusätzlich werden mit EBICS 3.0 folgende neuartige Auftragsarten für BTF eingeführt:

• BTD: Administrative Auftragsart zum Abholen einer Datei, die durch eine BTF-Struktur näher gekennzeichnet ist
• BTU: Administrative Auftragsart zum Senden einer Datei, die durch eine BTF-Struktur näher gekennzeichnet ist

EBICS unterstützt Auftragsarten bzw. FileFormat-Parameter für den SEPA-Zahlungsverkehr Kunde-Bank und Bank-Bank (Bundesbank und Interbank STEP2). Unterstützt werden derzeit für die Kunde-Bank-Schnittstelle die SEPA-Nachrichten:

• SEPA Credit Transfer Initiation
• SEPA Direct Debit Initiation
• Rückgabe vor Settlement (Rejects)

Diese spiegeln sich in entsprechenden EBICS-Auftragsarten wider, wobei folgende Besonderheit zu berücksichtigen ist.

Bei der Umsetzung der SEPA-Nachrichten für die DK wurde festgestellt, dass es sinnvoll ist, neben dem Standard-SEPA-Format erweiterte Formate einzuführen, die je nach Kreditinstitut bzw. Anwendungsfall Verwendung finden können. Im Speziellen handelt es sich hierbei um Sammelaufträge mit mehrfachen Gruppenbildungen wie z. B. Auftraggeberkonten oder Ausführungsdaten, die auf unterschiedliche Art behandelt werden können (als Beispiel wird die Behandlung mehrerer Auftraggeberkonten herangezogen):

• SEPA-Standardformat
  Verwendung des SEPA-Standardformats, wobei als Einschränkung nur Aufträge für ein Auftraggeberkonto möglich sind.
  Für die Abwicklung von Aufträgen mehrerer Auftraggeberkonten müssen bei dieser Option mehrere Aufträge im SEPA-Standardformat eingereicht werden.
• SEPA-Container
  DK-spezifische Protokollerweiterung, um mehrere SEPA-Standardformate für mehrere Auftraggeberkonten im Rahmen einer Auftragsart einreichen zu können
• Erweiterte Grouping-Optionen
  SEPA-Standardformat, bei dem unter Ausnutzung der erweiterten Grouping-Optionen im SEPA-Format selbst die Möglichkeit besteht, Aufträge für mehrere Auftraggeberkonten einzureichen

Diese Aufteilung auf mehrere Ausprägungen ist durch die optimierte Verarbeitungsweise bei den unterschiedlichen IT-Dienstleistern begründet.
In der folgenden Tabelle sind einige der in Deutschland verwendeten SEPA-Auftragsarten nach den unterschiedlichen Ausprägungen aufgelistet:

Um den jeweiligen Geschäftsvorfällen der Deutschen Kreditwirtschaft gerecht zu werden, wurden zusätzlich zu den genannten SEPA-Auftragsarten weitere mit unterschiedlichen Formatausprägungen entwickelt. Dazu gehören vor allem die Auftragsarten zur Abwicklung des nationalen SRZ-Verfahrens.

Der Vollständigkeit halber sei noch erwähnt, dass zur Übermittlung der SEPA-relevanten Daten im Rahmen der SWIFT-Tagesauszüge mittels der Auftragsart STA die SWIFT-Formate MT940 und MT942 angepasst wurden.

Um den Zahlungsverkehr aus SEPA-Aufträgen verlustfrei abbilden zu können, wurden als Entsprechung zu den MT94x-Nachrichten (STA und VMK) sowie den DTAUS-Umsatzinformationen (DTI) neue Abholauftragsarten für die camt-Formate eingeführt (C52, C53 und C54).

Einzelheiten zu den SEPA-Datenformaten und deren Verwendung in Deutschland befinden sich in der Anlage 3 des DFÜ-Abkommens.

Je nach Land werden außerhalb von SEPA unterschiedliche nationale Zahlungsverkehrsformate mit eigens dafür definierten Auftragsarten und FileFormat-Parametern genutzt.

Eine besondere Bedeutung im internationalen elektronischen Zahlungsverkehr spielt heutzutage der freie und offene Standard ISO 20022: Financial Services – Universal financial industry message scheme. Der Standard zielt auf die Vereinfachung und Vereinheitlichung der globalen Kommunikation innerhalb des Finanzsektors. Gegenstand der Standardisierung sind unter anderem Begriffe, Abläufe und Nachrichtenformate. Damit soll ein weltweiter Austausch von Finanzinformationen zwischen Systemen ermöglicht werden. Die Nachrichten werden zwischen Kunde und Bank bzw. Bank und Bank ausgetauscht und sind als XML-Dokumente (Extensible Markup Language) repräsentiert.¹ Dies ist ein Unterschied zu bisherigen Formaten, wie beim DTA-Format.

Hierfür wurde durch ISO 20022 eine große Menge an Nachrichtentypen standardisiert (zu finden unter www.iso20022.org/iso-20022-message-definitions). Für jeden Typ existiert eine formale Spezifikation der verfügbaren Elemente und Strukturen in Form von XML-Schema-Dateien. Zur eindeutigen Identifikation besitzt jeder Typ zudem einen Identifier bzw. Namen. Zudem sind die Nachrichtenbeschreibungen versioniert, sodass abweichende Versionen der zugrundeliegenden Nachrichtenbeschreibung unterschieden werden können. Jeder Nachrichtentyp ist geeignet, einen oder mehrere Geschäftsvorfälle (z. B. Einreichung einer SEPA-Überweisung) zu repräsentieren.

Nachfolgend sind einige relevante Nachrichten für die Kunde-Bank-Kommunikation aufgeführt:

Für die Interbank-Kommunikation stehen ebenfalls entsprechende Nachrichten zur Verfügung (u. a. pacs-Nachrichten). Auch für Instant-Payments-Zahlungen werden ISO-20022-Nachrichten verwendet.

Durch ISO 20022 liegt somit eine einheitliche Beschreibungsform für den Nachrichtenaustausch im Finanzsektor vor. Auf dieser globalen Ebene wird zunächst pro Nachricht die insgesamt mögliche Menge an verfügbaren Elementen beschrieben.

Durch Einschränkungen der allgemeinen Vorgaben und durch zusätzliche Belegungsregeln (technisch und/oder fachlich) können Organisationen eigene Unterausprägungen von ISO-20022-Nachrichten für bestimmte Geltungsbereiche definieren.

Eine Organisation, die solche Konkretisierungen und zusätzlichen Regeln definiert hat, ist die CGI (Common Global Implementation) Group. Sie fokussiert sich auf den Nachrichtenaustausch im globalen und länderübergreifenden Zahlungsverkehr. Zugleich können vielfältige Zahlungsauftragsarten abgebildet werden. Es erfolgt dort keine Spezialisierung auf z. B. SEPA-Zahlungen.²

Eine weitere Organisation mit eigenen Festlegungen für ISO-20022-Nachrichten ist der European Payments Council (EPC).³ So werden vom EPC spezifische Implementation Guidelines veröffentlicht, die die Anwendung für SEPA-Zahlungen mittels ISO 20022 erläutern, wie etwa Überweisungen (ISO-20022- Benennung pain.001).⁴ Die Dokumente beschreiben eine Einschränkung der allgemeinen ISO-20022-Vorgaben, etwa welche Elemente zulässig sind und welche zusätzlichen zahlungsspezifischen Regeln zu beachten sind. So beinhaltet das EPC-Format nur solche Elemente, die für SEPA-Zahlungen erforderlich sind. Die Formatbeschreibung zu u. a. den zulässigen Werten liegt für das EPC-Format nur allgemein in einer textuellen Beschreibung vor.

Auf Länderebene wurden teilweise eigene ISO-20022-Ausprägungen abgestimmt. So wurden etwa für Deutschland durch die DK spezifische Vorgaben festgelegt, wie XML-Nachrichten gemäß ISO 20022 aufgebaut sein müssen und welche Regeln für die transportierten Informationen zu beachten sind. Es werden die verschiedenen Datenformate und Abläufe detailliert beschrieben sowie entsprechende XML-Schema-Dateien veröffentlicht.⁵ Ähnlich gilt dies für den Schweizer Finanzplatz. Die SIX (Swiss Infrastructure and Exchange) hat mit ihren Swiss Payment Standards entsprechende Festlegungen und Umsetzungsempfehlungen veröffentlicht, um die ISO-20022-Nachrichten zu realisieren. Darin enthalten sind konkrete Vorgaben, wie z. B. Überweisungsaufträge ausgetauscht werden können. Ebenso existieren Festlegungen für landeseigene Zahlungsaufträge, wie Schweizer Lastschriften.⁶

Sowohl die Vorgaben der DK als auch diejenigen der SIX übernehmen verschiedene Festlegungen der EPC-Vorgaben, gestalten jedoch landesspezifisch die ISO-20022-Vorgaben aus. Somit stellen die DK- und SIX-Vorgaben Konkretisierungen der EPC-Vorgaben dar. Insbesondere liegen die Formatbeschreibungen teilweise detaillierter als XML-Schema-Bestandteile vor, anders als beim EPC-Format. Es lassen sich dadurch viele Prüfungen direkt anhand des XML-Schemas durchführen (z. B. beim DK-Format). Allen gemein ist jedoch die ISO-20022-Basis in Form der universellen XML-Beschreibung.

Des Weiteren bieten etwa die SIX-Vorgaben den Finanzinstituten einen Rahmen für individuelle Ausgestaltungen, z. B. abhängig vom angebotenen Leistungsportfolio des Institutes.

Darüber hinaus existiert für Frankreich eine durch das CFONB herausgegebene Implementierungsbeschreibung für die dortige ISO-20022-Verwendung von unter anderem pain.001-Zahlungen⁷ (SEPA, Nicht-SEPA usw.) oder pain.008-SEPA-Lastschriften⁸. In den Dokumenten werden die verschiedenen Ausprägungen unterschieden.

Ausgehend von der sehr allgemeinen Beschreibung des ISO-20022-Standards werden die verschiedenen Ausprägungsvarianten somit stets konkreter und spezifischer bzw. restriktiver.

Die ISO-20022-Nachrichten werden mittels EBICS als Upload- bzw. Download-Transaktionen kommuniziert (siehe Abschnitt EBICS-Abläufe). So wird etwa die pain.001-Nachricht (Überweisung) mittels EBICS vom Kundensystem an die Bank gesendet (siehe Abschnitt SEPA-Zahlungsverkehr). Der Abholauftrag für den dazugehörigen pain.002-Statusbericht wird ebenfalls via EBICS erteilt (siehe Abschnitt SEPA-Zahlungsverkehr).

Die pain.002-Nachrichten können je nach Ausprägung des ISO-20022-Standards Positiv- und/oder Negativmeldungen zu Zahlungsaufträgen beinhalten. So ist es einer Bank mit einer pain.002-Nachricht möglich, maschinenlesbar für das verarbeitende Kundensystem auf Fehlergründe für zurückgewiesene Überweisungsaufträge hinzuweisen. Das Kundensystem kann diese Fehler geeignet berücksichtigen. Anhand verschiedener Statuscodes kann über den Status des Gesamtauftrags oder einzelner Teiltransaktionen informiert werden. Insbesondere kann ein Überweisungsauftrag, bestehend aus mehreren einzelnen fehlerhaften und fehlerfreien Transaktionen, partiell verarbeitet werden. Dabei würde die Verarbeitung nur die fehlerfreien Transaktionen berücksichtigen, wohingegen die fehlerhaften Transaktionen ausgesteuert würden und dem Kunden gemeldet werden. Fehlerinformationen und Reaktion sind damit sehr feingranular und maschinengestützt möglich.⁹

¹ Siehe ISO 20022:
www.iso20022.org als Startseite und für Überblicksinformationen z. B. www.iso20022.org/faq.page

² Siehe CGI Group / SWIFT:
www.swift.com/standards/market-practice/common-global-implementation

³ Siehe European Payments Council (EPC):
www.europeanpaymentscouncil.eu

⁴ Siehe European Payments Council (EPC):
www.europeanpaymentscoun- cil.eu/document-library/implementation-guidelines/sepa-credit-transfer-inter-psp-implementation-guidelines

⁵ Siehe DK, SIZ:
www.ebics.de/de/datenformate

⁶ Siehe SIX:
www.six-interbank-clearing.com/de/home/standardization/iso-payments/customer-bank/implementation-guidelines.html

⁷ Siehe CFONB:
www.cfonb.org/index.php/instruments-de-paiement/virement

⁸ Siehe CFONB:
www.cfonb.org/instruments-de-paiement/prelevement

⁹ Zum Beispiel DK-Standard, siehe DK, SIZ:
www.ebics.de/de/datenformate

Einige Beispiele der in Deutschland und der Schweiz genutzten Formate von gebundenen standardisierten Auftragsarten zeigt die folgende Übersicht:

• AZV – AZV-Auftrag im Diskettenformat senden (DTAZV in Deutschland)
• STA – Abholen SWIFT-Tagesauszüge (SWIFT MT940)
• VMK – Abholen kurzfristige Vormerkposten (SWIFT MT942)
• VML – Abholen langfristige Vormerkposten (SWIFT MT942)
• C52 – Abholen Bank-To-Customer Account Report
• C53 – Abholen Bank-To-Customer Statement Report
• C54 – Abholen Bank-To-Customer Debit Credit Notification
• ESR – Abholung von ESR-Informationen (spezifisch in der Schweiz)

Darüber hinaus werden in Europa insbesondere zur Abwicklung von Auslandszahlungen unterschiedliche nationale Formate eingesetzt. Zunehmend gewinnen aber auch hier die ISO 20022 basierten Formate (z. B. ISO Global, CGI) an Bedeutung (siehe Abschnitt ISO 20022).

Diese Auftragsarten kommen bisher vornehmlich in Frankreich zum Einsatz und dienen dem transparenten Dateitransfer beliebiger Formate. Dies bedingt, dass nicht, wie bisher in Deutschland üblich, am Namen der Auftragsart abzulesen ist, welches Format transportiert wird. Vielmehr wird der Auftragsart FUL bzw. FDL ein längerer Formatparameter mitgegeben, der dann eine weitere Steuerung erlaubt. Diese Auftragsarten stehen seit EBICS 2.4 zur Verfügung. Die Auftragsart FUL (File Upload) wird für Einreichungen und die Auftragsart FDL (File Download) wird für Abholungen verwendet. Der Aufbau und die zu verwendenden Formatparameter sind zusammen mit den Auftragsarten als Anhang der EBICS-Spezifikation dokumentiert.

Zusätzlich zu den standardisierten Auftragsarten kann bezüglich der Verwendung in EBICS folgende Klassifizierung vorgenommen werden:

• systembedingte Auftragsarten – speziell für EBICS
  • z. B. Auftragsarten in Zusammenhang mit der VEU
• sonstige unterstützte systembedingte Auftragsarten
  • z. B. HAC, PTK für Abholen von Kundenprotokollen
• reservierte Auftragsarten für den zwischenbetrieblichen Dateiaustausch
  • z. B. FIN für EDIFACT-FINPAY senden
• sonstige in der Spezifikation reservierte Auftragsarten unter Verwendung nicht standardisierter Formate, z. B.:
  • FTB für Senden/Abholen beliebiger Dateien
  • FTD für Senden/Abholen freier Textdateien
• optionale EBICS-Auftragsarten
  • z. B. HVT für VEU-Transaktionsdetails abrufen

BTF steht für Business Transaction Format. BTF vereinheitlicht mit Einführung von EBICS 3.0 die Beschreibung der zu transferierenden Formate in Deutschland, Frankreich und der Schweiz. Statt mit Auftragsarten bzw. Formatparametern wird in der Kommunikation mit dem Bankrechner mit BTF eine Struktur ausgetauscht, die einen Geschäftsvorfall identifiziert.

Um die Kompatibilität zu älteren EBICS-Versionen zu gewährleisten, sind Anpassungen von Formatparametern und Auftragsarten an BTF-Standards durch Zuordnungsübersichten (Mappings) erleichtert. Auf nationaler Ebene sind Zuordnungsübersichten für Auftragsarten und Formatparameter definiert. Die EBICS-Clients müssen diese Zuordnungen berücksichtigen. In der Übergangszeit kann es zu Mischformen von unterstützten EBICS-Versionen kommen:

• clientseitig
  Bank A unterstützt z. B. bereits BTF, während Bank B nur EBICS 2.x anbietet. Die Bankzugänge in einem EBICS-Client sollten auf die jeweilige Version des Bankrechners ausgerichtet sein.
• serverseitig
  Die Mitarbeiter eines Kunden nutzen EBICS-Clients mit unterschiedlichen Versionen. Während der Einreicher mit einer älteren Version per Auftragsart einen Auftrag einreicht, unterschreibt ein weiterer Mitarbeiter mit einem EBICS-3.0-Client den Auftrag in der VEU per BTF.

Die Verteilte Elektronische Unterschrift (VEU) ist die wohl bedeutendste Anwendungsfunktion in EBICS. Getrieben von vorhandenen Marktprodukten fand diese Erweiterung Eingang in die EBICS-Spezifikation.

Durch die Verteilte Elektronische Unterschrift wird es möglich, dass die Einreichung eines Auftrags – der ggf. bereits mit einer ersten Unterschrift versehen ist – von der eigentlichen Freigabe getrennt werden kann. Eine Signaturdatei kann zeitlich und örtlich getrennt vom Auftrag eingereicht werden. Die Verbindung zwischen beiden Dateien wird über eine Auftragsnummer bzw. Auftrags-ID hergestellt.

Das Verfahren läuft folgendermaßen ab:

• Ein Teilnehmer reicht einen Auftrag z. B. mit der Auftragsart CCT ein und fügt ggf. eine eigene bankfachliche EU mit der Unterschriftsklasse A hinzu.
• Institutsseitig wird der Auftrag geprüft und festgestellt, ob noch weitere Signaturen erforderlich sind. In diesem Fall wird der Auftrag samt Hashwert im Institut zwischengespeichert.
• Ein zweiter Teilnehmer möchte nun den Auftrag freigeben und hat auf alternativem Weg die benötigten Daten wie Auftragsnummer und Hashwert erhalten (Die Bereitstellung der Auftragsnummer und des Hashwerts liegt außerhalb von EBICS und ist nicht Bestandteil der institutsseitigen Server-Komponenten).
  Er hat nun folgende Möglichkeiten:
  • Er fragt mit Auftragsart HVU oder HVZ die für ihn zur Unterschrift vorliegenden Aufträge ab und erhält eine Übersicht geliefert, die unter anderem die Auftragsart, geleistete und fehlende Signaturen und die Länge des unkomprimierten Auftrags enthält.
  • Über die Auftragsart HVD kann er sich zu den Aufträgen einzeln noch weitere Details wie Begleitzettelinformationen und den Hashwert über die Aufträge übertragen lassen.
    Dieser Schritt entfällt, wenn die Übersicht mit der Auftragsart HVZ abgeholt wurde, da HVZ bereits alle erforderlichen Detailinformationen liefert.
  • Mit der optionalen Auftragsart HVT liefert das Institut auf Anfragen des Teilnehmers Informationen wie z. B. Einzeltransaktionen des Auftrags, Verwendungszwecke bis hin zum gesamten Auftrag.
• Nach Analyse der vorliegenden Aufträge hat der Teilnehmer nun eine der folgenden Möglichkeiten:
  • Signatur mit Auftragsart HVE
  • Stornierung mittels HVS

Die folgende Abbildung, die der Darstellung in der Spezifikation für die EBICS-Anbindung ^[1] nachempfunden ist, gibt einen verständlichen Überblick über die doch etwas komplexen Zusammenhänge:

Während die VEU in Deutschland gut verbreitet genutzt wird, ist sie in Frankreich und der Schweiz bisher nicht üblich, soll mit EBICS 3.0 aber ebenfalls eingeführt werden.

In Frankreich ist es üblich, die Signaturen mit dem Auftrag zu schicken. Bei EBICS-Profil TS wird bei einem Auftrag abhängig von der Anzahl der Signaturen folgendermaßen reagiert:

• Eine Signatur am Auftrag: Der Auftrag ist mit einer Signatur vollständig autorisiert und wird ausgeführt.
• Zwei Signaturen am Auftrag: Im Anwendungssystem wird entschieden, ob die zweite Signatur benötigt wird und ob der Auftrag ausreichend autorisiert ist. Dort wird auch entschieden, ob der Auftrag z. B. auch ausgeführt wird, falls einer der beiden Unterzeichner keine Berechtigung besitzt.
• Eine Signatur am Auftrag, zweite Signatur abhängig vom Limit: Im Anwendungssystem wird entschieden, ob der Auftrag ausreichend autorisiert ist oder ob abhängig vom Limit eine zweite Signatur notwendig ist.

Mit Einführung von EBICS 3.0 kann es während der Migrationsphase zu Mischverträgen aus Auftragsarten und BTF kommen. Um auf bestehenden Berechtigungsmodellen aufsetzen zu können, müssen bestimmte Rahmenbedingungen für BTF-Aufträge (hier BTU für die Einreichung) eingehalten werden wie z. B.:

• BTU muss nicht mit dem des Auftrags übereinstimmen, aber an derselben Auftragsart konfiguriert sein.
• BTU wird für die Abfrage der Unterschriftenmappe verwendet.
• Leere Felder im BTF-Filter sind laut Spezifikation Wildcards: Es werden alle passenden Aufträge aus der Unterschriftenmappe geliefert (Es ist nicht möglich, mit einem leeren Feld ein bestimmtes BTU zu adressieren).
• BTU aus dem HVx wird in Exits nicht zusätzlich zum Auftrags-BTU gemeldet.

Obwohl in der EBICS-Spezifikation nirgends der Begriff Portal explizit auftaucht, ergibt sich durch die Verwendung der Authentifikationssignatur die Möglichkeit der Einbindung von Dritten bei der Einreichung von Aufträgen. Dabei geht EBICS nicht so weit wie FinTS, wo Portalbetreiber oder Intermediäre mit einer eigenen Rolle versehen sind – die Trennung von Einreicher (Technischer Teilnehmer) und Auftraggeber(n) lässt jedoch die Abbildung einfacher Portalszenarien zu. Durch die Verwendung der Unterschriftsklasse T wird diese Transportinstanz auch mit dazu passenden Regeln versehen.

Bereits in den vorangegangenen Abschnitten war die Rede davon, dass bestimmte Funktionen wie z. B. Recovery oder die Detailabfrage bei VEU optionalen Charakter haben. Einige spezielle Funktionen aus diesem Portfolio sollen jetzt kurz vorgestellt werden.

Wie im Abschnitt EBICS-Abläufe detaillierter beschrieben, läuft eine EBICS-Transaktion in zwei Schritten ab. Im ersten Schritt wird mithilfe einer kurzen Nachricht, der Initialisierung, die Vorbereitung für einen – unter Umständen recht umfangreichen – Filetransfer getroffen.

In diesem Schritt ist es nun optional möglich, bei Upload-Transaktionen in bestimmtem Umfang Vorabprüfungen durchzuführen und einen unberechtigten Transfer gar nicht erst zuzulassen. Folgende Details können im Rahmen der Vorabprüfung verifiziert werden:

• Kontoberechtigungsprüfung
• Limitprüfung
• EU-Verifikation auf Basis des mitgelieferten Hashwerts der Datei

Der mögliche Umfang der Vorabprüfung hängt davon ab, welche dieser Prüfungen konkret vom Institut unterstützt werden und welche Informationen das Kundenprodukt liefert bzw. liefern kann. Es handelt sich hierbei also nicht um die Abwehr von Angriffen, sondern um eine Funktionalität zur Erhöhung der Betriebssicherheit und der Optimierung von Ressourcenbedarf, da nicht korrekte Datei-Uploads gar nicht erst gestartet werden.

Das folgende Set von Auftragsarten ermöglicht es dem Kundenprodukt, Informationen über die getroffenen Vereinbarungen vom Institut abzuholen:

• HAA    abrufbare Auftragsarten abholen
• HPD    Bankparameter abholen
• HKD    Kunden- und Teilnehmerdaten des Kunden abholen
• HTD    Kunden- und Teilnehmerdaten des Teilnehmers abholen

Über diese optionalen Auftragsarten kann ein Teilnehmer sein Kundenprodukt korrekt für den Zugang vorbereiten bzw. kann das Kundenprodukt lokal eine zum Teilnehmer passende Umgebung einrichten, indem es z. B. nur die unterstützten Auftragsarten anzeigt.

Bei der Übermittlung wird außer den eigentlichen Zugangsparametern wie URL und Institutsname auch übertragen, welche optionalen Funktionen wie z. B. Vorabprüfung oder Recovery vom Institut unterstützt werden.

Die Kunden- und Teilnehmerdaten informieren über folgende Details der Geschäftsvereinbarungen:

• Kundeninformationen, z. B. Adressdaten
• Kontoinformationen, z. B. Kontonummern und Währungen
• zugelassene Auftragsarten
• Teilnehmerattribute, z. B. Teilnehmer-ID und Unterschriftsklasse

Mit diesen sehr detaillierten Informationen kann ein Kundenprodukt eine vollautomatische Konfiguration der lokalen Umgebung durchführen. Durch ebenfalls enthaltene Statusinformationen ist auch im Fehlerfall eine gezielte Analyse möglich.

Es zeigt sich, dass auch Firmenkunden für ihre Geschäftsmodelle immer häufiger zeitnahe Benachrichtigungen über Zahlungseingänge in Echtzeit benötigen. Dieser Trend ist nicht zuletzt auch den Instant-Payments-Prozessen zu verdanken. Bei der EBICS-Kommunikation geht die Initiative stets vom Firmenkunden (EBICS-Client) aus. Der EBICS-Server einer Bank reagiert nur auf eingehende Anfragen (Inbound), initiiert jedoch selbst keinen Austausch. Wie soll jedoch eine Information zeitnah von der Bank an den Kunden übermittelt werden? Dazu hat sich die DK auf die Umsetzung einer Schnittstelle für Echtzeitbenachrichtigungen verständigt, über die unter Beibehaltung des EBICS-Rollenmodells ein Abholprozess des Kundensystems bankseitig angestoßen werden kann (siehe Anlage 2: Spezifikation „Echtzeitbenachrichtigungen“ ^[9]). Für die ausgehende Kommunikation (Outbound) von der Bank zum Firmenkunden wird dazu ein Pushdienst auf Basis von WebSocket genutzt, der als zentrale Komponente für das aktive Senden von Benachrichtigungen an EBICS-Kunden und -Teilnehmer fungiert.

Eine weitere Form des EBICS-Einsatzes ist die Verwendung im Interbank-Betrieb zum Austausch des Massenzahlungsverkehrs (SEPA-Zahlungen) sowie für Instant-Payments-Zahlungen.

In Deutschland werden im bilateralen Clearing die früher oft herstellerbasierten Lösungen zunehmend durch den offenen Standard EBICS abgelöst.
Ein Szenario im Interbankenverkehr ist die Anbindung der Institute an die Bundesbank. Die Bundesbank bietet hierzu mit SEPA nur noch zwei Schnittstellen an:

• EBICS mit SEPA pacs messages
• SWIFT FileAct

Die Bundesbank hat eigene Auftragsarten in EBICS eingebracht und Formatfestlegungen (z. B. für PTKs) getroffen.

Ein weiteres Szenario im Interbankenverkehr für SEPA-Zahlungen ist die Anbindung von Banken an STEP2 der EBA CLEARING. Diesen Zugang bietet die 39 EBA CLEARING den angeschlossenen Banken seit Ende 2013 alternativ zum SWIFT-Zugang auch über EBICS (ab EBICS 2.5) an. Auch die EBA CLEARING hat für den Datenaustausch per EBICS eigene Auftragsarten in EBICS eingebracht und Formate spezifiziert.

Für den direkten bilateralen Austausch zwischen Banken gibt es keine Vorgaben in der EBICS-Spezifikation. Grundsätzlich treffen die Partner ihre Vereinbarungen bilateral. Diese Vereinbarungen betreffen neben dem Umgang mit Rückläufern (R-Transaktionen) auch geschäftspolitische Fragen wie den Haftungsübergang oder spezifische SLAs (z. B. maximale Dateigrößen).

Für Auftragsarten und technische Regelungen werden üblicherweise die Regelungen der EBA CLEARING für die STEP2-Anbindung übernommen.

Instant Payments, auch als ‘immediate’ oder ‘real-time’ Payments bezeichnet, stellen den nächsten Schritt bei der Harmonisierung von Zahlungen innerhalb des SEPA-Raums dar, mit dem Ziel, Europas Wettbewerbsfähigkeit und Wirtschaftswachstum zu unterstützen. Nachdem die Umstellung auf SEPA-Überweisungen und –Lastschriften nahezu vollzogen ist und die Digitalisierung der gesamten Wirtschaft zu neuen Erwartungen bei Kunden und Händlern führt, werden Instant Payments den Schwerpunkt des European Payment Council (EPC) für die nächsten Jahre darstellen.

Herzstück ist ein neues SEPA Instant Credit Transfer (SCT Inst) Schema. Dieses bietet durch spezielle Belegung des Standard-SEPA-Überweisungsschemas eine starke Verbindung zum bestehenden SEPA-Zahlungsverkehr und den bereits etablierten Prozessen und Implementierungen. Obwohl das Schema selbst nur Euro unterstützt, können Belastungs- und Zielkonten natürlich auch in anderen Währungen geführt sein.

Die EBA CLEARING bietet auf Basis der SCT Inst einen Instant-Payments-Service (RT1) seit November 2017 auf europäischer Ebene an. Die EZB plant ab Herbst 2018 den Target Instant Payments Service (TIPS). Daneben sind noch lokale Verfahren in einzelnen Ländern produktiv.

Eine Haupteigenschaft von Instant Payments ist die Zeitdauer zwischen dem Übertragen eines validierten SCT-Inst-Auftrags von der Bank des Auftraggebers bis zur Rückmeldung der Bank des Begünstigten. Diese Zeitdauer darf im Normalfall 10 Sekunden nicht überschreiten. Tritt in einem Ausnahmefall ein Timeout auf, so sind im Rulebook Regelungen für Statusabfragen getroffen. In jedem Fall wird bis zu einer negativen Rückmeldung durch die Bank des Begünstigten davon ausgegangen, dass die Zahlung erfolgreich durchgeführt werden wird. Dabei wird vorausgesetzt, dass alle beteiligten Systeme eine 24/7/365-Verfügbarkeit besitzen.

Eine einzelne Instant-Payments-Zahlung ist aus Sicherheitsgründen auf 15.000 Euro limitiert, es können bilateral höhere Beträge vereinbart werden. SEPA Instant Payments ist innerhalb der 34 Länder des SEPA-Raums gegeben. Die Unterstützung von SCT Inst ist derzeit für Banken nicht verpflichtend. Für das Zustandekommen einer Instant-Payments-Zahlung ist die Unterstützung dieser Funktion bei der Bank des Begünstigten Voraussetzung.

Als Zugangskanal zum RT1-Service bietet die EBA CLEARING sowohl das SiaNet als auch EBICS (ab EBICS 2.5) an. Analog zur Step2-Anbindung stellt die EBA CLEARING einen Implementation Guide für die Anbindung über EBICS zur Verfügung. Die Instant-Payments-Messages werden hierbei einschrittig via EBICS, die dateibasierten Reports analog dem STEP2 via EBICS übertragen. Für die einschrittige, nachrichtenbasierte Nutzung von EBICS 3.0 im RT1-Service wurde eigens eine Spezifikation in Form eines Deltadokumentes erstellt (siehe Use of EBICS for the Clearing & Settlement of Instant Payment Transactions (Delta - Concept) ^[8]) und auf der EBICS-Webseite (www.ebics.de bzw. www.ebics.org) veröffentlicht.

FinTS (Financial Transaction Services, vormals HBCI – Homebanking Computer Interface) ist ebenfalls ein DK-Standard, der jedoch seinen Schwerpunkt auf Onlinebanking mit Privat- und Gewerbekunden setzt. FinTS bildet in seiner klassischen Form Dialoge zwischen Kunde und Institut ab und verarbeitet nachrichtenorientierte Einzeltransaktionen. Funktionalitäten wie Bank- oder User-Parameterdaten sind in FinTS vergleichbar zu EBICS enthalten.

In seiner neuesten Version 4.1 setzt auch FinTS konsequent auf Internetstandards wie HTTP oder XML. Auch die Kommunikationsverfahren wurden um dialogfreie, sogenannte Datagramme und die Bank-Kunde-Kommunikation erweitert.

FinTS unterstützt im Sicherheitsbereich ebenfalls elektronische Signaturen, alternativ aber auch das PIN/TAN-Verfahren in unterschiedlichen Ausprägungen.    

Wie in EBICS werden auch von FinTS die gängigen Finanzdatenformate wie SEPA, camt, DTAZV und SWIFT unterstützt – sie werden dort als Geschäftsvorfälle bezeichnet. Auch Instant Payments ist in FinTS enthalten. Die DK sorgt mittlerweile auch dafür, dass Versionen und Inhalte dieser Formate von beiden Standards in gleicher Weise genutzt werden. Zusätzlich verfügt FinTS aber über die Möglichkeit, zahlreiche eigene Geschäftsvorfälle zu definieren, die von Daueraufträgen über Termingeld bis zu freien Mitteilungen an das Institut reichen. Diese Geschäftsvorfälle schaffen (wenigstens) einen nationalen Standard überall dort, wo eine internationale Definition fehlt.

Im Bereich der gewerblichen Kunden steht dem Kunden in FinTS, außer den zu EBICS identischen Geschäftsvorfällen z. B. für Sammler oder Kontoumsätze, eine eigene Implementierung der Verteilten Elektronischen Unterschrift (VEU) zur Verfügung. Was dem Standard momentan fehlt, sind all die Möglichkeiten des Massenzahlungsverkehrs wie Segmentierung oder Recovery.

Zusammenfassend muss man FinTS als Ergänzung zu EBICS positionieren. Dies gilt überall dort, wo Gewerbe- oder Firmenkunden als gemeinsame Zielgruppe betrachtet werden müssen, da sie in beiden Welten ihre Finanzgeschäfte tätigen. So wird ein Unternehmen sowohl Massenzahlungen durchführen als auch im Anlagen- oder Wertpapiergeschäft tätig sein. Bei einigen Geschäftsarten wird es sogar ausschlaggebend sein, wo ein Geschäft getätigt wird, in der Buchhaltungsabteilung oder von einem Geschäftsführer unterwegs.

Moderne Kundenprodukte haben sich bereits auf diese Situation eingestellt und bieten mit EBICS und FinTS bereits zwei Kommunikationsverfahren an.

Zur tieferen Betrachtung von FinTS empfiehlt sich die Lektüre des FinTS-Kompendiums, das unter fints.org zum Download bereitsteht.

Im Zusammenspiel von EBICS und SWIFT sind folgende Strukturen zu nennen:

• klassische FIN-Formate im internationalen Zahlungsverkehr
• XML- und ISO-Aktivitäten von SWIFT
• SWIFTNet als eigener Kommunikationsstandard
• SWIFT FileAct als eigener Filetransfer-Standard

Zu den klassischen FIN-Formaten, wie z. B. MT940, lässt sich nicht viel bemerken. Sie sind stabil, nur noch gesetzlichen Änderungen unterworfen und werden in den beiden relevanten deutschen Standards EBICS und FinTS in gleicher Weise in das jeweilige Protokoll eingepackt. Dadurch ergibt sich auch eine gewisse Unabhängigkeit von SWIFT, da nur mit Referenzierungen gearbeitet wird.

Die Tatsache, dass mit SWIFT XML auch eine XML-basierte Version der Formate zur Verfügung steht, ändert nichts an der klaren Aufgabentrennung zwischen den Standards. Bedeutender ist hierbei, dass SWIFT bei der Erzeugung der XML-Formate sehr abstrakt vorgegangen ist und quasi ein Reverse Engineering der bestehenden Welt durchgeführt hat. Es wurden nämlich in jahrelanger Kleinarbeit mittels UML Prozessmodelle für den internationalen Zahlungsverkehr angefertigt, die heute nur als Ableitungen die FIN- und XML-Formate erzeugen. Durch diesen methodischen Ansatz hat sich SWIFT auch in der Konkurrenz internationaler Zahlungsverkehrsstandards nach vorne geschoben und hat es geschafft, die Kernkomponenten dieser Modelle als ISO-Standard 20022 zu positionieren.

Während die ISO-Bestrebungen von SWIFT die weitere Entwicklung der Zahlungsverkehrsformate sehr stark beeinflussen dürften, ist das zugehörige Transportprotokoll, das die Grundlage für SWIFTNet bietet, eher von untergeordneter Bedeutung und als proprietäre Entwicklung zu sehen. Sicherlich hat SWIFTNet einen stabilen Verbreitungsgrad im Interbankengeschäft – in der Kunde-Bank-Beziehung spielt es jedoch so gut wie keine Rolle.

Dadurch lässt sich der SWIFT-Standard in seiner bedeutenden Rolle als Instanz zur Herausgabe und Pflege von Zahlungsverkehrsformaten einordnen. Seine Positionierung zu EBICS ist damit auch eindeutig beschrieben und dürfte für die nächsten Jahre auch stabil bleiben.

Mit dem Einbeziehen Frankreichs in die SEPA-Gesellschaft hat sich auch der Einfluss von SWIFT verstärkt, da dieser Standard in Frankreich eine große Rolle spielt. Auch SWIFT FileAct ist als Filetransferprotokoll vermehrt anzutreffen. Trotzdem gilt, dass es sich bei SWIFT (siehe swift.com) und EBICS um ein harmonisches Nebeneinander handelt.

Der französische Herstellerstandard PeSIT kann als Komplementärstandard zu EBICS insbesondere im Interbankenverkehr, z. T. aber auch für große Unternehmen betrachtet werden. Auch mit PeSIT können Massenzahlungen eingereicht und Umsatzdaten ausgeliefert werden. Firmenkunden in Frankreich setzen oft Produkte ein, die neben EBICS auch ein PeSIT-IP-Modul besitzen.

Die auf FTP basierenden Filetransfer-Verfahren werden in Europa auch im Zahlungsverkehr vereinzelt eingesetzt. Anders als die bisher diskutierten Verfahren, regeln sie allerdings nur den Transport, nicht jedoch irgendeine Art von fachlicher Verarbeitung. Auch die Sicherheit der Verfahren hält heutigen Anforderungen an den Zahlungsverkehr nicht Stand. Durch die breite Verfügbarkeit als Systemsoftware kommt SFTP oder FTPS oft beim allgemeinen Filetransfer zum Einsatz.

Dieser Beschreibung von Standards lässt sich entnehmen, dass es – auch im internationalen Bereich – derzeit keine vergleichbaren Industriestandards gibt.

Daraus wird erkennbar, dass EBICS in Zukunft der bestimmende Standard im Massenzahlungsverkehr in Europa und darüber hinaus sein wird. Dies wird dadurch erhärtet, dass außer den bisherigen Partnern der EBICS-Gesellschaft (Deutschland, Frankreich und Schweiz) auch in anderen Ländern wie Österreich, Spanien, Italien, Portugal und Irland zunehmend EBICS seitens der Banken unterstützt wird. Diese Entwicklung wird durch Einführung von EBICS 3.0 und der damit verbundenen Harmonisierung noch erleichtert.

Als weiterer Motivator für die Einführung von EBICS in weiteren EU-Staaten kann Instant Payments dienen, da hier eine europaweit einheitliche Verarbeitung für alle Beteiligten Vorteile bringen wird.

Der abschließende Abschnitt zeigt nun, wie eine beispielhafte EBICS-Implementierung und Migration auf Basis einer konkreten Produktfamilie aussehen kann.