Posts mit dem Label EBICS werden angezeigt. Alle Posts anzeigen
Posts mit dem Label EBICS werden angezeigt. Alle Posts anzeigen

Benachrichtigung bei SEPA-Instant-Payments-Zahlungseingängen – ein elementarer Baustein der Zahlungsprozesskette

Neben der kurzen Dauer einer finalen Echtzeitüberweisung ist die umgehende Information des Zahlungsempfängers bei Zahlungseingängen ein Kernelement des SCT Inst-Zahlungsablaufs und damit verbundener weiterer Prozessschritte.

Was in der Online-Transaktionsabwicklung zwischen Verbrauchern oder im Händler-Kunden-Verhältnis mittlerweile gut umsetzbar ist, stellt – wie im Blog-Artikel „Echtzeitbenachrichtigungen und EBICS - Schluss mit den „Hoffnungsabfragen“ von Michael Lembcke beschrieben – die beteiligten Akteure im EBICS-Corporate-Umfeld vor Herausforderungen: Zwar haben Umsatz-Notifications mittlerweile Einzug in die ab November 2019 gültige Anlage 3 des DFÜ Abkommens gehalten und sind dort als camt.054-Nachrichten, die mittels der EBICS Auftragsart C5N abgeholt werden können, spezifiziert, allerdings müssen diese aktiv vom Zahlungsempfänger bei der Bank abgeholt werden. Eine aktive Push-Benachrichtigung des Zahlungsempfängers war bislang nicht vorgesehen. Mittlerweile konnte diese funktionale Lücke allerdings geschlossen werden, indem die EBICS-Spezifikation um eine auf dem WebSocket-Protokoll basierende Information vom Bankrechner an den Kunden erweitert worden ist. Somit können Umsatzinformationen dann zeitnah abgeholt werden, sobald der zugrunde liegende Zahlungseingang stattgefunden hat. Erfolglose „Hoffnungsabfragen“ entfallen somit.

Da mit einer direkten Benachrichtigung über den Zahlungseingang auch schnellere und effizientere Gesamtabläufe im Corporate-Umfeld möglich sind, ist es an der Zeit, diese wichtige Funktion genauer zu betrachten.

Ausgangspunkt der Reise in die Instant-Notification-Welt ist die globale Vernetzung der Gesellschaft. Nahezu zu jeder Zeit und an jedem Ort der Welt sind digitale Services verfügbar: zunehmend in Echtzeit – „always on, always instant“. Waren früher prozessbedingte Wartezeiten durch klassische Bezahlvorgänge, die je nach Empfängerland mehrere Tage in Anspruch nehmen konnten, und langsame logistische Prozesse beim Versand der Waren der Standard, ermöglicht die fortschreitende Digitalisierung immer durchgängigere Prozessketten ohne Medienbrüche und Wartezeiten und sorgt für ein hohes Wachstum im Bereich neuer digitaler Angebote.

Einige aufeinander aufbauende Schritte der Kette lassen sich nicht ohne Weiteres in die Instant-Welt überführen, da prozessuale Abhängigkeiten zur nicht digitalen Welt bestehen. Andere Schritte hingegen sind heute schon 24/7/365 verfügbar – teilweise mit Finalität innerhalb weniger Sekunden. Hierzu zählt u.a. der Bestell- und der anschließende Bezahlprozess.

Das Zauberwort hierfür heißt Instant Payments, die eine sofortige Gutschrift des Zahlbetrages beim Empfänger vorsehen und somit auch eine sofortige Leistung nach Bezahlung ermöglichen können. Was in Bezug auf digitale Produkte funktioniert, gestaltet sich im Bereich des Versandhandels schwieriger: Hier ist zwar eine Beschleunigung des Gesamtprozesses durch einen schnellen Zahlungseingang beim Händler möglich, eine direkte Verfügbarkeit der bestellten Ware lässt sich nur schwerlich darstellen und der Kunde tritt über einen, wenn auch verkürzten Zeitraum, in Vorleistung.
Ein Kauf auf Rechnung wäre aus Sicht des Kunden die risikoärmste Variante. Für den Händler/Lieferanten birgt sie jedoch erhöhte Risiken, da dieser in Vorleistung tritt und nicht von einer zeitnahen Begleichung der offenen Forderung ausgegangen werden kann. Vorkasse mittels klassischer Bezahlmethoden inkl. Karten führt lediglich zu einer Umkehr der Risikoposition, jedoch nicht zu einer optimalen Risikoaufteilung zwischen Händler und Käufer. Diesem Umstand kann derzeit nur ein Intermediär begegnen, der als für den Händler und Käufer vertrauenswürdige Instanz die Übergabe der Ware und den Bezahlvorgang zeitgleich abwickelt. Keine Bezahlung – keine Ware und umgekehrt. Klassischer Nachnahmeprozess also.

Welche Rolle spielt hierbei nun die Notification des Zahlungsempfängers? Ohne eine umgehende Benachrichtigung des Begünstigten über den Zahlungseingang sind beschleunigte Abläufe und damit verbunden auch neue innovative Produkte, die auf einer direkten Bezahlung basieren, undenkbar. Nur mittels einer in den Zahlungsprozess integrierten oder unmittelbar daran anschließenden Information an den Begünstigten kann das zugrunde liegende Geschäft abgeschlossen oder zumindest der nächste Schritt in der Prozesskette gegangen werden – sei es mittels eines Online-Prozesses über eine API, die von der Bank hierfür bereitgestellt wird, oder durch die Nutzung des EBICS-Kanals in Verbindung mit einem Push-Service.

Bislang erfolgten Umsatzbenachrichtigungen i.d.R. mittels untertägigen Kontoinformationen (Umsatzinfo MT942) oder im Kontoauszug (MT940), der mit einem Versatz von einem Tag bereitgestellt wurde. Durch die im SCT Inst verankerte verpflichtende umgehende Rückmeldung bei einem Instant-Payments-Zahlungseingang ist erst der vollumfängliche Abschluss des Zahlungsvorgangs möglich. Insbesondere für den Einsatz von Instant Payments am POS ist dies unerlässlich. Lange Wartezeiten bis zum Abschluss der Transaktion würden eine Kundenakzeptanz verhindern. Die Benchmark hierfür ist die Dauer einer Kartenzahlung.

Doch nicht nur am POS ist eine umgehende Benachrichtigung relevant: Bestehende Bezahlverfahren wie z. B. Rechnungsbegleichung mittels Instant Payments im Online-Banking oder auch die klassische Nachnahme an der Haustür profitieren hiervon. Im ersten Fall liegt der Vorteil in einem beschleunigten Gesamtablauf für alle Beteiligten und in letzterem handelt es sich insbesondere um die Substitution klassischer Zahlungsinstrumente wie Bargeld oder Karten.

Aber auch bei der Entwicklung zukünftiger Bezahlverfahren wie z.B. Request to Pay wird die Notification eine tragende Rolle spielen. In diesem Zusammenhang möchte ich gerne auf einen weiteren EBICS-Blog-Artikel meines Kollegen Eric Waller verweisen, der sich mit diesem Thema beschäftigt: „Request to Pay verändert den Zahlungsverkehr – erste Use Cases“.

Autor: René Keller

Formatfehler bei EBICS-Aufträgen – Testservices können helfen

EBICS wurde speziell für den sicheren und performanten Datenaustausch von Dateien beliebiger Größe im Banken-Firmenkundengeschäft konzipiert. Für Zahlungsverkehrsaufträge gilt, dass eine Datei, die zum EBICS- Server hochgeladen wird, inhaltlich stets dem definierten Geschäftsvorfall (Auftragsart, FileFormat-Parameter oder BTF) und den dafür spezifizierten Formatvorgaben entsprechen muss. Bei Zahlungsverkehrseinreichungen sind Sammeldateien mit Einzeltransaktionen, die nach Auftraggeberkonten gruppiert sind, gängige Praxis. Die Protokollierung (HAC und PTK) der serverseitigen EBICS-Vorgänge ist für Zahlungsverkehrsaufträge z. T. formatspezifisch. Die Berechtigungsprüfungen und die Protokollierung erfordern es daher, dass der EBICS-Bankrechner das Einreichungsformat zumindest in den relevanten Stellen kennt und auslesen kann (z. B. Auftraggeberkonto und Betrag). Zum Auslesen der Informationen führt der EBICS-Bankrechner eine Formatprüfung durch. Bereits bei dem ersten erkannten Formatfehler bricht der EBICS-Bankrechner üblicherweise die Prüfung ab. Der Auftrag wird mit Formatfehler abgelehnt und im Kundenprotokoll dokumentiert.

Weshalb wird keine vollständige Prüfung der Datei durchgeführt, und weshalb werden die Fehlerdetails nicht ins Kundenprotokoll geschrieben?

Dafür gibt es verschiedene Gründe. Zunächst umfasst die übliche Servicevereinbarung für das E-Banking per EBICS die Einreichung und zügige Verarbeitung von korrekten Dateien. Eine umfangreiche Formatverifikation mit Fehlerprotokoll ist nicht inbegriffen und auch nicht Kernaufgabe eines EBICS-Bankrechners. Zudem sollen die Bankrechnerkapazitäten für die unverzügliche Abarbeitung formatkonformer Aufträge genutzt werden und nicht für die Analyse von ohnehin fehlerhaften Dateien.

Wie aber kann eine Bank ihren Firmenkunden einen Service anbieten, der die Qualität von Zahlungsverkehrsaufträgen in Bezug auf Format und Fachlichkeit steigert, ohne dabei den EBICS-Bankrechner unnötig zu belasten?

Dafür könnten Kunden Testservices wie die ISO-20022-Testplattform nutzen. Im Rahmen der Harmonisierung des Schweizer Zahlungsverkehrs bieten bereits heute Schweizer Banken ihren Kunden eine Testplattform zum Test von Ein- und Auslieferungsformaten des Zahlungsverkehrs an.
Die Testplattform ahmt die spezifische Produktion der Bank nach. Mit der Testplattform können unter anderem XML-basierte Kunde-Bank-Meldungen validiert und die Schnittstelle Bank-an-Kunde simuliert werden.

Eine Erweiterung der ISO-20022-Testplattform um die Prüfung von Zahlungsverkehrsaufträgen auf spezifizierte Formatvorgaben und Fachlichkeit kann die Qualität der Datei noch erheblich verbessern. Durch eine im Voraus durchgeführte umfassende Formatverifikation von Zahlungsverkehrsaufträgen können Fehler mithilfe eines detaillierten Fehlerprotokolls schnell und einfach identifiziert werden.
Dateien, die hinsichtlich Format und Fachlichkeit nicht korrekt sind, können so schon in einer Vorabprüfung durch einen Testservice erkannt und korrigiert werden, bevor sie zum EBICS-Server hochgeladen werden.


Autoren: Aline Wendler und Michael Lembcke

Echtzeitbenachrichtigungen und EBICS - Schluss mit den „Hoffnungsabfragen“ bei Downloads

Wie bereits in meinem Blog-Beitrag im Dezember 2018 vorgestellt, findet auch das Thema Echtzeitüberweisungen (Instant Payments) im Firmenkundengeschäft über das neue Bulk-Format Einzug in die EBICS-Welt. Für die Einreichung von Echtzeitüberweisungen gelten dabei für die EBICS-Transferphase nicht die engen synchronen Zeitregeln des Instant Payments. Die Uhr beginnt erst hinter dem EBICS-Bankrechner zu ticken.

Und wie sieht es mit der Rückrichtung für Instant-Payments-Geschäftsvorfälle im EBICS aus? Immerhin sollte ein Geld-Eingangsbenachrichtigung (Credit Notification), wenn schon nicht in Echtzeit möglich, dennoch möglichst zeitnah dem Zahlungsempfänger zugeführt werden. Im Standard-Rollenverhältnis in der Kunde-Bank-Beziehung holt der EBICS-Client bekanntlich stets die Informationen vom Bankrechner ab. Ein aktiver Versand durch die Bank per EBICS ist hier nicht vorgesehen. Hier hat insbesondere die Wirtschaft die Banken und Die Deutsche Kreditwirtschaft zu einer pragmatischen Lösung einer Push-Möglichkeit gedrängt. Ziel sollte es letztendlich sein, eine Lösung zu entwickeln, die sich ohne Änderungen des EBICS-Protokolls und ohne Veränderung des Rollenverhältnisses umsetzen lässt.

Herausgekommen ist die Idee einer neuen Websocket-basierten Standardschnittstelle, die EBICS-Clients über die Bereitstellung von neuen Informationen für den Download informiert. Hierzu gehört auch die Information über eine neue Bereitstellung einer Credit Notification. Auf diesem neuen Push-Kanal werden somit keine sensiblen Daten übertragen. Die Abholung der relevanten sensiblen Daten erfolgt nach wie vor über den sicheren EBICS-Kanal.

Mittlerweile hat Die Deutsche Kreditwirtschaft diese neue Schnittstelle in der “Spezifikation Echtzeitbenachrichtigungen” spezifiziert und in der Version 1.0 am 18.07.2019 auf der deutschen EBICS-Webseite (www.ebics.de) veröffentlicht.

Nun gilt es, diese Schnittstelle in den EBICS-Clients und in den EBICS-Bankrechnern standardkonform und zeitnah umzusetzen. Bieten sich dadurch doch neue Möglichkeiten zur Optimierung des Firmenkundengeschäftes auch unabhängig vom Instant Payments. So lassen sich z. B. für sämtliche Abholprozesse die häufigen und permanenten “Hoffnungsabfragen” von automatisierten EBICS-Clients einsparen, wie sie u. a. bei Kontoauszugsabrufen durchgeführt werden. Dadurch können sowohl EBICS-Client-Nutzer als auch Bankrechnerbetreiber mit Lastreduzierung rechnen. Das sind doch gute Neuigkeiten, oder?

Autor: Michael Lembcke

Ist das EBICS-Protokoll von der starken Authentifizierung (SCA) im Sinne der PSD2 befreit?

Diese Frage wurde uns wiederholt von französischen und europäischen Finanzinstituten gestellt und es war nicht immer ganz einfach, eine ausreichend formelle Antwort zu geben.
Vor kurzem hat die Banque de France eine offizielle Antwort verfasst, in der sie das EBICS-Protokoll auf die Liste der Verfahren und Protokolle setzt, die gemäß Artikel 17 der delegierten Verordnung (UE) 2018/389 von der starken Authentifizierung befreit sind. Die Verordnung besagt: "Bei juristischen Personen, die elektronische Zahlungsvorgänge über dedizierte Zahlungsprozesse oder -protokolle auslösen, die nur Zahlern zur Verfügung stehen, bei denen es sich nicht um Verbraucher handelt, können Zahlungsdienstleister von der Vorgabe einer starken Kundenauthentifizierung absehen, wenn die zuständigen Behörden der Auffassung sind, dass diese Prozesse oder Protokolle mindestens ein vergleichbares Sicherheitsniveau wie das in der Richtlinie (EU) 2015/2366 vorgesehene gewährleisten." 
 
Das bedeutet jedoch nicht, dass EBICS die starke Authentifizierung nicht unterstützt - weit gefehlt! Die Gewissheit, dass das EBICS-Protokoll mindestens vergleichbare Sicherheitsniveaus garantiert, wie sie in der Richtlinie vorgesehen sind, ist schon seit langem gegeben. Vor diesem Hintergrund möchte ich Sie dazu einladen, den Artikel EBICS und PSD2 – Wie kommt das zusammen? zu lesen oder erneut zu lesen, der vor einigen Monaten in diesem Blog veröffentlicht wurde.

Autor: Marc Dutech

Verifizierung der Hashwerte der Bankschlüssel beim EBICS-Initialisierungsrequest

EBICS-Transaktionen werden in unterschiedliche Phasen unterteilt: Initialisierung, Datentransfer und Quittierung (letztere ist nur für Downloadtransaktionen vorgesehen).

Im Rahmen der Initialisierung werden u. a. folgende Aspekte geprüft:

  • Auftragsart
  • Authentifikationssignatur
  • Hashwerte der Bankschlüssel
  • teilnehmerbezogene Berechtigungen

Die Transaktion wird mit der Transferphase, in der die eigentlichen Auftragsdaten verschickt werden, nur dann fortgesetzt, wenn die Initialisierung erfolgreich durchlaufen wurde. Die Hashwerte der Bankschlüssel werden bei der Initialisierung geprüft, um sicherzustellen, dass der Client die aktuellen Bankschlüssel verwendet. Bei einer nicht erfolgreichen Prüfung sendet der Server den Returncode EBICS_BANK_PUBKEY_UPDATE_REQUIRED. Für den Client ist dies ein Indiz dafür, dass die neuesten Bankschlüssel mithilfe der Auftragsart HPB abgeholt werden sollten.

Vor der Harmonisierung durch EBICS 3.0 konnten die Bankschlüssel direkt oder in Zertifikate verpackt verwendet werden. Gemäß EBICS-Spezifikation müssen bis EBICS 3.0 in der Transaktionsinitialisierung die Hashwerte der öffentlichen Bankschlüssel angegeben werden – unabhängig davon, ob mit der Bank Zertifikate oder Schlüssel ausgetauscht wurden.

Ab EBICS 3.0 sind Zertifikate beim Schlüsselmanagement verpflichtend. In diesem Zuge wurde festgelegt, dass sowohl bei Uploads als auch bei Downloads in den EBICS-Initialisierungsrequests zukünftig die Hashwerte der Zertifikate angegeben werden müssen.

Die Hersteller von EBICS-Bankrechnern ermöglichen ihren Kunden in der Regel einen weichen Übergang, indem sie sowohl die Angabe der Bankschlüssel als auch die Angabe der Zertifikate im DER-Format erlauben. Das bedeutet, dass Kunden nach der Migration auf EBICS 3.0 keine Abholung per Auftragsart HPB ausführen müssen. Sowohl Schlüssel als auch Zertifikate können entweder in spezifikationskonformer HEX-Darstellung oder in alternativer Base64-Darstellung angegeben werden. Eine Mischung beider Darstellungen in einem Request ist üblicherweise nicht vorgesehen.

Übrigens: Mit EBICS 3.0 wurde das Schlüsselmanagement nicht nur für Bankschlüssel, sondern auch für Teilnehmerschlüssel vereinheitlicht. So ist es jetzt nicht mehr nur in Frankreich (CFONB) verpflichtend, Teilnehmer mit Zertifikaten zu initialisieren, sondern in allen Ländern. Auch hier ermöglichen EBICS-Bankrechner in der Regel einen weichen Übergang: Teilnehmerschlüssel mit einer Mindestlänge von 2.048 Bit können auch für EBICS 3.0 verwendet werden, und für die Schlüsselaktualisierung (Auftragsarten HCA, HCS und PUB) können die neuen Zertifikate üblicherweise mit den Schlüsseln der älteren EBICS-Versionen unterschrieben werden.
CA-basierte Zertifikate finden bisher weiterhin nur in Frankreich Verwendung. Aus Sicht der Bankrechner sollte einer Einführung in anderen Ländern allerdings nichts im Wege stehen.


Autor: Hendrik Chlosta

GPI und EBICS – Wie geht das zusammen?

Ist GPI nicht ein reines SWIFT-Thema? Auf den ersten Blick nun einmal ja. Die Abkürzung kommt von SWIFT und steht für „Global Payments Innovation“. Die Initiative für GPI wurde Ende 2015 schon mit breiter Unterstützung von vielen globalen Banken gestartet.

Die Basis von GPI ist die eineindeutige Referenz, kurz UETR (Unique End-to-End Transaction Reference), die eine Zahlung durch die manchmal lange Korrespondenzbankkette begleitet. So eine Referenz ist zwar ein Ungetüm von 36 Zeichen in der nach einem allgemeingültigen Algorithmus definierten Form xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx, aber das Ungetüm sichert die Eineindeutigkeit ohne zentrale „Vergabestelle“. Wurde die UETR anfänglich nur in einer CUG (Closed User Group) für (Firmen-)Kundenzahlungen in MT103-Nachrichten verwendet, haben inzwischen alle Zahlungen im FIN-Netzwerk so eine Referenz – gleichbleibend vom Anfang bis zum Ende der gesamten Zahlungskette.

Der zweite wesentliche Baustein von GPI ist der sogenannte Tracker. Der Tracker ist eine zentrale Datensammlung bei SWIFT zu allen GPI-Zahlungen. Er stellt den beteiligten Banken umfassende Informationen zum Status einer Zahlung in der Korrespondenzbankkette, zu Gebühren und zu Währungsumrechnungskonditionen bereit. Während der FIN-Transport diese Informationen aus den transportierten Nachrichten selbst herausliest, können non-FIN-Banken den Tracker auch aktiv informieren. In der aktuellen Diskussion ist die sogenannte Confirmation – die Meldung der Gutschrift auf dem Konto des Begünstigten am Ende der Zahlungskette. Auf die Confirmation sollen ab 2020 alle FIN-Banken verpflichtet werden.

Aber warum der ganze Aufwand? Transparenz und Schnelligkeit – die beiden wesentlichen Herausforderungen im Korrespondenzbankgeschäft werden mit GPI angegangen. Durch die umfassende Verwendung von UETR liegen nun Statistiken vor: Durchschnittlich 40 Prozent der GPI-Überweisungen werden den Endbegünstigten innerhalb von fünf Minuten gutgeschrieben, innerhalb von 30 Minuten sind es 50 Prozent, innerhalb von sechs Stunden 75 Prozent und innerhalb von 24 Stunden nahezu alle. So eine Aussage war vor GPI einfach unmöglich. Hingegen kann jeder Treasurer Fälle berichten, bei denen Zahlungen spät oder gar nicht ankamen, mit hohen, unerklärlichen Gebühren, mit unklaren oder sogar ohne Verwendungszweckinformationen.

Neben den technischen Details wie UETR und Tracker gehört zu GPI ein Regelwerk, in dem die möglichst taggleiche Weitergabe einer Zahlung mit vollständigem Verwendungszweck, unter Angabe von abgezogenen Gebühren und Währungsumrechnungsdetails vorgeschrieben ist. Da es ja keine globale Transparenzrichtlinie gibt, muss dies auf multilateralem Vertragswerk begründet durchgesetzt werden. Und das ist auch gut so – Zeit dafür ist es schon lange.

Der (Firmen-)Kunde soll besseren Service im grenzüberschreitenden Zahlungsverkehr bekommen. Neben der Schnelligkeit und Transparenz ist ein weiterer Punkt die Quittung. So etwas gibt es ja eigentlich nur bei einer Barzahlung, im elektronischen Zahlungsverkehr war bisher das Motto: „shoot and forget“. Wenn es keine Beschwerden gibt, ist das Geld wohl angekommen. In den letzten Jahren hat es im SEPA eine beachtliche Entwicklung gegeben, und mit den Instant Payments nach dem Schema SCTinst gibt es auch hier nun eine Quittung. Mit SWIFT GPI ist die Erstellung einer derartigen Quittung ebenfalls möglich, auch wenn dies (noch) eine vollständige FIN-Kette in der Abwicklung voraussetzt. Es ist jedoch noch ein Stück Weg dorthin: Bisher wird an den breiten, erst einmal bankinternen, Umsetzungen gearbeitet. Die Anbindung der Kundensysteme für einen Zugriff auf die Informationen oder gar die Weitergabe von Status und Gebühreninformationen an Kundensysteme befindet sich noch am Anfang. Aber schon die Möglichkeit, im Falle eines Zweifels durch den Zugriff auf eine zentrale Stelle prüfen zu können, wo sich die Zahlung befindet, ist im großen Korrespondenzbanknetz ein erheblicher Fortschritt.

Geht das nur in FIN? Natürlich nicht. Die aktuellen Entwicklungen, z. B. die Migration der Großbetragssysteme (RTGS) wie TARGET2, EURO1 oder CHAPS von MT hin zu Nachrichten in XML nach ISO-20022-Standard, gehen diesen Weg. Die (neueren) ISO-Nachrichtenformate enthalten dedizierte Felder für die UETR, und so wird die Referenz auch außerhalb des FIN-Netzes transportiert. Und erst kürzlich verbreitete SWIFT die Meldung: „SWIFT trials instant cross-border gpi payments through TIPS“[1].

Für eine Anbindung von GPI-Rückmeldungen an Kundensysteme wie TMS oder ERP sind Nachrichten in Form von PSR (payment status report, also pain.002) effizienter als manuelle Prozesse. Aber schon diese Selfservice-Funktionen sind ein bedeutender Schritt hin zu mehr Transparenz. Übrigens sind die Standards zu diesen Rückmeldungen, also Felder (tags) und Codes, in der Harmonisierungsinitiative CGI-MP multibankfähig abgestimmt. In dieser Initiative wirkt PPI nun auch aktiv mit.

Des Weiteren steht auch die Erweiterung an, dass der Kunde seine Referenz in der Zahlung als UETR initiiert – im pain.001.001.03 in besonderen Feldern gemäß der CGI-MP oder auch schon in aktuelleren ISO-Versionen in dedizierten Feldern.

Und genau hier, an der Schnittstelle Kunde-Bank bzw. Bank-Kunde, werden sowohl Kundenzahlungen als auch PSR-Rückmeldungen ja auch oft mit EBICS transportiert. Somit stehen GPI und EBICS nicht im Widerspruch zueinander, sondern ergänzen einander sinnvoll – wie so oft im Zahlungsverkehr.

Autor: Dr. Mario Reichel

[1] Quelle: https://www.swift.com/news-events/press-releases/swift-trials-instant-cross-border-gpi-payments-through-tipshttps://www.swift.com/news-events/press-releases/swift-trials-instant-cross-border-gpi-payments-through-tips

Standardisierung und Automatisierung in der Beziehung mit externen Vermögensverwaltern dank EBICS

Externe Vermögensverwalter (EVV) oder External Asset Manager (EAM) bieten ihren vermögenden Privatkunden oder institutionellen Kunden wie Pensionskassen und Versicherungen verschiedenste Services an (zum Beispiel Steuer- und Immobilienberatung, Handels- und Anlagegeschäfte). Die Kundenkonten liegen meist auf einer oder mehreren Depotbanken. Die Interaktion mit den Finanzinstituten ist dabei oft weder standardisiert noch automatisiert. Die Kommunikation über Briefpost, Telefon, E-Mail und teilweise auch noch Fax dominiert den Geschäftsalltag.

Wenige, grosse Vermögensverwalter verfügen über einen SWIFT-Anschluss und benutzen diesen für die Abwicklung von Treasury- und Fremdwährungsgeschäften (Meldungskategorie 3), Wertschriftengeschäften (Meldungskategorie 5), Edelmetallgeschäften (Meldungskategorie 6) oder Cash-Management-Geschäften (Meldungskategorie 9). Einige haben proprietäre System-zu-System-Verbindungen realisiert, beispielsweise mittels FTP, um Finanzmeldungen auszutauschen. In der Schweiz beobachten wir einen Trend, dass EBICS sich in diesen Fällen als alternative Anbindungsvariante durchsetzen könnte.

Im Rahmen des PPI-Frühstücks im April 2019 in Lausanne hat ein Vertreter von Credit Suisse das Angebot «Private swift Network (PsN)» vorgestellt. Es handelt sich dabei um die Erweiterung des EBICS-Angebots in der Art und Weise, dass ca. 20 neue EBICS-Auftragsarten (Reports für den Download) aus den oben genannten EAM-Anwendungsfällen zur Verfügung stehen. Dank der Kooperation mit führenden Softwareherstellern von Portfolio-Management-Systemen (wie etwa Allocare oder Expersoft) erreicht die Credit Suisse in der Interaktion mit ihren Partnern eine signifikante Steigerung des Standardisierungs- und Automatisierungsgrads. Konkret können die SWIFT-Meldungen der oben genannten Meldungskategorien jetzt auch über EBICS transportiert werden.

Da das EBICS-Protokoll flexibel bezüglich des transportierten Inhalts ist, bietet Credit Suisse darüber hinaus auch weitere Formate wie beispielsweise CSV oder XML für Rapportierung der Transaktionen und Vermögenswerte an, inklusive Stammdaten der entsprechenden Kundendepots. Von dem neuen Angebot profitieren alle Akteure: Vermögensverwalter können vermehrt Banken kostengünstig via EBICS anbinden und ihre Prozesse automatisieren, Softwarehersteller ihren Funktionsumfang sinnvoll erweitern und Banken ihre Attraktivität für EAM steigern. Über alle Stellen und Prozesse gesehen sinkt auch die Fehlerrate und es steigt die Umsetzungsgeschwindigkeit durch den Wegfall von manuellen Eingriffen.

Schweizer Banken, welche aktuell Projekte in diesem Umfeld umsetzen, planen bereits die nächsten Ausbaustufen im EBICS-Angebot. So sollen in Zukunft nicht nur die Reporting-Funktionen (EBICS-Download), sondern auch die Auftragsfunktionen (EBICS-Upload) angeboten werden. Insbesondere Aufträge im Handel (SWIFT-Meldungskategorie 5) sind gut geeignet für die Einreichung via EBICS. Konkret sollen Börsenaufträge (etwa SWIFT MT502) mittels einer eigener Auftragsart vom Vermögensverwalter an die Bank übermittelt werden. Analog der bekannten Zahlungsauftragsschnittstellen werden bankseitig die Börsenorderschnittstellen angebunden. In diesem Kontext ist auch der Einsatz einer VEU denkbar.

Fazit:
Erste Banken in der Schweiz weiten ihr EBICS-Angebot über die Anwendungsfälle des Zahlungsverkehrs hinaus aus. Das Angebot von Credit Suisse für mittlere und grössere Vermögensverwalter setzt im Markt der EAM-Kundschaft ein Zeichen und wird wohl Nachahmer auf den Plan rufen. Softwarehersteller von Portfolio-Management-Systemen lernen langsam aber sicher das EBICS-Protokoll kennen und erweitern ihre Connectivity-Möglichkeiten um diese Anbindungsvariante. Der Phantasie, welche Formate und Standards in Zukunft über EBICS transportiert werden, sind keine Grenzen gesetzt. Es ist davon auszugehen, dass EBICS auch in anderen Domänen ausserhalb des Zahlungsverkehrs für ein bestimmtes Kundensegment eine echte Alternative zur Kommunikation über das SWIFT-Netz darstellt.

Carsten Miehling

Wie sich EBICS verbessern lässt Teil 10 – Gezielte EBICS-Downloads mit Datum und Uhrzeit

Im Zahlungsverkehr und insbesondere mit der Einführung neuer Verfahren, wie etwa den Instant Payments, wird es für den Bankenkunden immer wichtiger, auch untertägig über die Zahlungsbewegungen auf dem Laufenden gehalten zu werden. Diese Entwicklung stellt im Firmenkundengeschäft auch den EBICS-Standard vor neue Herausforderungen zumal diese Informationen üblicherweise von den EBICS-Kunden aktiv vom Bankrechner abgerufen werden müssen. Insbesondere, wenn Firmenkunden mehrere EBICS-Clients nutzen, ist die heute gängige sog. historische Abholung mit Datumsangabe die geeignete Download-Methode. Da jedoch die historische Abholung durch EBICS lediglich tagesgenau spezifiziert ist, werden die Daten in der Praxis untertägig in großem Umfang mehrfach abgeholt. Zudem hängen fachliche Zeitstempel für EBICS vom Bereitstellungsformat ab und sind damit bestenfalls tagesgenau und schlimmstenfalls auf dem Bankrechner einfach nicht vorhanden. Den abholenden Clients steht daher dann die Aufgabe zu, die redundant abgeholten Daten automatisiert zu filtern. Dieses Verhalten führt derzeit zu einer deutlichen Mehrbelastung aller beteiligten Systeme sowohl auf Seiten der Kunden, als auch auf Seiten der Banken.

Folgende Verbesserung in EBICS könnte bei entsprechender Spezifikation Abhilfe schaffen und gezielte zeitgesteuerte Abholungen erlauben.

Sinnvoll wäre es, wenn der EBICS-Server per Spezifikation eine zusätzliche Variante der historischen Abholung unterstützen würde. Im Gegensatz zur bisherigen standardisierten historischen EBICS-Abholung würde nun bei Start- und Endzeitpunkt jeweils auch die Uhrzeit berücksichtigt. Außerdem sollten sich die angegebenen Zeitpunkte immer auf den Bereitstellungszeitpunkt beziehen. Damit könnte dann der EBICS-Server alle Datensätze liefern, die innerhalb des angegebenen Zeitraums bereitgestellt wurden. Zur flexibleren Handhabung sollte es auch zulässig sein, bei Abholanfragen nur jeweils einen der beiden Zeitpunkte anzugeben. Ansonsten verhält sich die Abholung auch hinsichtlich der Quittungsphase wie die bisherige Standardabholung.

Ich denke, eine solche Lösung einheitlich für alle EBICS Nutzer im EBICS-Standard zu spezifizieren, könnte den Abholprozess für EBICS verfeinern, die Rechnerauslastung reduzieren und insbesondere im Hinblick auf die wachsende Bedeutung von Aktualität deutlich verbessern. Bisher bereits eingesetzte proprietäre Lösungen in den EBICS-Produkten wären überflüssig.

Michael Lembcke

EBICS und die API-Diskussionen – Ein Statusupdate aus der Schweiz

Seitdem SIX Interbank Clearing (SIC) als Repräsentant des Finanzplatzes Schweiz im Frühling 2015 als offizielles Mitglied in die EBICS SCRL aufgenommen wurde, hat sich im Bereich der Firmenkundenschnittstellen bei Banken (Neudeutsch auch „Corporate Communication Interfaces“) einiges getan. Und aktuell rumort es ebenfalls wieder auf dem Gebiet der elektronischen Schnittstellen, sodass es sich lohnt, in diesem Blog wieder einmal einen Blick auf die aktuelle Situation in diesem Bereich in der Eidgenossenschaft zu werfen.

Natürlich soll hier auch die Rede von APIs (Application Programming Interfaces) sein, denn in manchen Geschäftsleitungs-Etagen bei Banken erscheinen diese drei Buchstaben als der große Heilsbringer in der Digitalisierungsstrategie. Haben also APIs, insbesondere für die Abfrage von Kontoinformationen oder die Beauftragung von Zahlung das Potential, die altgedienten Dateitransferprotokolle wie EBICS obsolet zu machen? Insbesondere vor dem Hintergrund, dass gerade neue Startups und FinTechs diese schlanken APIs dem doch etwas aufwändig zu implementierenden EBICS bevorzugen?

Um diese Frage für die Schweiz beantworten zu können, benötigt der mit dem Finanzplatz Schweiz weniger vertraute Leser aktuelle Hintergrund-Informationen. Zunächst einmal ist festzuhalten, dass die Schweiz als Nicht-EU-Mitglied in keiner Weise an die PSD2 (Payment Service Direktive) gebunden ist. Womit ein großer Treiber, die Pflicht eine API anzubieten, für Banken erstmal wegfällt. Des Weiteren gibt es in der Schweiz auch keine standardisierte Schnittstelle fürs Onlinebanking à la FinTS wie in Deutschland. Nichtsdestotrotz ist die frohe Botschaft der Europäischen Union natürlich auch in der Schweiz vernommen worden.

Bevor wir uns etwas vertiefter mit den zurzeit heiß diskutierten API-Initiativen beschäftigen, soll noch einmal die EBICS-Verbreitung gewürdigt werden. In den letzten gut fünf Jahren hat sich das Protokoll nach dem Vorbild der deutschen Implementierung bei allen größeren Instituten als Standardangebot für den elektronischen Austausch von Daten mit Firmenkunden durchgesetzt. Die Protokolleigenschaften, sehr große Volumina transferieren zu können sowie neuerdings auch der Einsatz der VEU (Verteilte Elektronische Unterschrift), werden von mittleren und größeren Firmenkunden sehr geschätzt. Auch alle namhaften Schweizer Softwareanbieter mit Lösungen im Electronic Banking haben EBICS im Angebot.

Soweit so gut, könnte man meinen. Wie eingangs erwähnt, ist hierzulande die API-Diskussion ebenfalls in vollem Gange und wir beobachten momentan drei erwähnenswerte Initiativen, welche nachfolgend kurz vorgestellt werden. Um es an dieser Stelle vorweg zu nehmen, aus Sicht des Autors sind diese Initiativen kein Ersatz für EBICS, sondern ergänzen ein Schnittstellen-Angebot eines Finanzinstitutes für ein bestimmtes Kundensegment (in der Regel kleinere Firmenkunden, die über eine Cloud-Lösung mit der Bank Informationen in beide Richtungen austauschen).

Sehr vielversprechend erscheint momentan „Corporate API“, die Initiative von SIX und den Schweizer Banken. Unter diesem Namen entwickelt die SIX zusammen mit Vertretern der Banken und Software-Hersteller nicht nur einen frei verfügbaren Standard, sondern gleich noch die passende Plattform dazu. Diese Plattform erlaubt eine sehr einfache Teilnahme an einem neu entstehenden Öko-System, das Services weit über den PSD2-Rahmen (AIS, PIS) hinaus anbieten wird.

Als Formate werden bei der „Corporate API“ JSON und ISO20022 XML angeboten. Die JSON-Variante wird dabei sehr einfach und rasch zu implementieren sein und zielt auf SW-Anbieter, welche nicht die Komplexität der ISO20022-Meldungen benötigen. Die ISO20022 XML-Variante unterstützt das gesamte Spektrum der aus der Migration ZV CH bekannten Möglichkeiten. Bereits gegen Ende 2018 werden erste Tests mit Pilot-Banken und -herstellern durchgeführt werden.

Ein weiteres Projekt läuft unter dem Namen „Common API“. Das Common API der SFTI (Swiss Fintech Innovations) lehnt sich stärker an PSD2 bzw. die Implementierung der BerlinGroup an. Gegenüber der Corporate API-Variante formuliert die Spezifikation der SFTI das API allgemeiner und überlässt die Wahl der Zielgruppe dem Service Provider. Gemäß Informationen der SFTI sind bei der Entwicklung dieses Standards die großen Bankapplikations-Anbieter mit an Bord. SIX hat den Entwicklungsprozess der SFTI-Spezifikation von Anfang an begleitet und wird zukünftig die Ergebnisse der SFTI-Arbeitsgruppe weiterführen. Gut möglich also, dass aus zumindest in Teilen die Standards kompatibel ausfallen werden.

Die Situation für Softwarehersteller ist somit in der Schweiz nicht gerade einfach, da einerseits mit EBICS ein etabliertes produktives Protokoll zur Verfügung steht und neue Initiativen in den Startlöchern stehen. Je nach Kundensegment und Geschäftsmodell stellt sich für Lösungsanbieter die Frage, eine oder allenfalls auch gleich mehrere Implementierungen anzubieten. Kommt hinzu, dass einige Banken bereits proprietäre Interfaces publiziert haben (etwa die Hypothekarbank Lenzburg, welche als sehr innovative Fintech-Bank auftritt). Weitet man das Einsatzgebiet auf Europa aus, dann kommen noch bereits bekannte Initiativen wie „Berlin Group“, „STET“ oder „Open Banking“ dazu. Typischerweise hat der Finanzplatz Schweiz keinen existierenden Standard übernommen, da hierzulande das „Swiss Finish“ immer noch hoch im Kurs ist.

Carsten Miehling



Gleichberechtigung für EBICS – Anwendungsfall Instant Payments Bulk

Auch wenn es auf den ersten Blick merkwürdig erscheint: In Deutschland werden derzeit auch für die Kunde-Bank-Beziehung Instant-Payments-Anwendungsfälle für das dateibasierte EBICS-Transferprotokoll diskutiert und spezifiziert. Die Anwendungsfälle konzentrieren sich in diesem Fall auf das Firmenkundengeschäft. Insbesondere größere Firmenkunden haben die Anforderung, Sammeleinreichungen an die Banken übermitteln zu können. Daher hat man sich hierzu in der DK etwa für die SEPA-Credit-Transfer-Einreichung auf die spezielle Form der Sammeleinreichung von Instant Payments (Instant Payments Bulk) verständigt, basierend auf dem XML-Format ISO pain.001. Auch für die Rückrichtung der Zahlungsinformationen in der Zahlungskette – vom Empfänger beziehungsweise den Banken – werden entsprechende Geschäftsvorfälle und Formate (etwa Payment Status im Format pain.002) festgelegt. Die so spezifizierten Geschäftsvorfälle und Formatvorgaben werden in Deutschland voraussichtlich ab November 2019 offiziell gültig sein und können von Banken optional angeboten werden.

Was ist die Besonderheit von Instant Payments Bulk? 

Der Unterschied zu reinen Instant-Payments-Prozessen, die beispielsweise am „Point of Sale“ synchron ausgeführt werden, liegt im Fall Instant Payments Bulk über EBICS darin, dass die Einreichung selbst hier nicht als „instant“ gilt. Vielmehr handelt es sich um eine Einreichung zur Ausführung als Instant Payments (SCTINST). Die ausführende Bank des Einreichers zerlegt die Sammeldatei in die einzelnen Transaktionen und führt die Zahlungen als SCTINST aus, sofern der Zahlungsempfänger auf diesem Wege erreichbar ist. Erst ab diesem Zeitpunkt gelten die Bedingungen für die SCTINST. Die Daten der Rückrichtung werden dann von der Bank des Einreichers wieder auf dem EBICS-Kanal an den Einreicher zurückgeliefert. Das bedeutet konkret in diesem Fall für den Standardweg, dass die Daten von der Bank zur Abholung im EBICS-Bankrechner bereitgestellt werden. Im Firmenkundengeschäft nimmt die Bank in der für EBICS definierten Beziehung zwischen Kunde und Bank bekanntlich ausschließlich die passive Rolle ein. Eine aktive Benachrichtigung an den Sender über EBICS ist daher im Firmenkundengeschäft derzeit nicht vorgesehen.

Instant Payments Bulk weil es dringend ist? 

Firmenkunden wollen mit den neuen Geschäftsvorfällen Zahlungen gesammelt und gleichzeitig kurzfristiger einreichen. Auf diese Weise kann mit dem Geld bis zur Einreichung länger gearbeitet werden. Zudem sind die Zahlungen dann sofort garantiert und ausgeführt. Hierbei ist wie für die Empfangsseite auch für den Rückweg eine unverzügliche Benachrichtigung gewünscht. Da im EBICS-Rollenmodell derzeit eine aktive Benachrichtigung des Kunden durch die Bank nicht vorgesehen ist, werden dafür derzeit in Deutschland verschiedene Schnittstellen (APIs) und Verfahren (etwa E-Mail-Push) diskutiert. Dabei ist es eigentlich doch relativ einfach: Warum nicht das bilaterale EBICS nutzen, wie es heute bereits im Interbankenverkehr etabliert ist. Beide Parteien, Kunde und Bank, haben dabei gleichberechtigte Sende- und Empfangsrollen. Es bedarf lediglich der Erweiterung der EBICS-Kundenanwendungen um vereinfachte EBICS-Server-Funktionen. Die Firmenkunden, die Instant-Payments-Bulk-Zahlungen einreichen, könnten dann Daten aus diesen Prozessen auch aktiv empfangen. Solche Anwendungen sind sogar bereits am Markt verfügbar. Die neuen Geschäftsvorfälle sind somit vollständig über den bestehenden Standard und mit den bestehenden Lösungen umsetzbar. Zeit- und aufwandsträchtige Diskussionen über zusätzliche Schnittstellen, Protokolle und Vereinbarungen können entfallen.

Michael Lembcke

10 Jahre EBICS – Eine Erfolgsgeschichte

Zu Beginn des Jahres 2008 war es endlich soweit: Jeder Firmenkunde in Deutschland konnte ab diesem Zeitpunkt sicher sein, dass er mit einem einheitlichen und sicheren Verfahren im Electronic Banking alle Banken und Sparkassen über das Internet erreichen konnte, um Überweisungen, Lastschriften und andere Aufträge zu senden und Kontoinformationen abzuholen. Die für Firmenkunden überaus wichtige Multibankfähigkeit wurde durch das DFÜ-Abkommen der Deutschen Kreditwirtschaft (DK) garantiert, das alle Kreditinstitute in Deutschland ab dem 1. Januar 2008 verpflichtete, ein neues einheitliches Verfahren namens EBICS (Electronic Banking Internet Communication Standard) im Datenaustausch mit Firmenkunden zu unterstützen.Auch wenn bereits damals abzusehen war, dass EBICS erfolgreich sein würde, war doch nicht mit der Erfolgsgeschichte zu rechnen, die EBICS seitdem geschrieben hat. EBICS ist inzwischen ein europäischer Standard für den sicheren Datenaustausch, nicht nur im Electronic Banking mit Firmenkunden, sondern auch im Interbankenzahlungsverkehr und hat das Zeug, auch für aktuelle Entwicklungen wie Instant Payments zum Standard zu werden. Doch davon später mehr.

Die Vorgeschichte: Der Weg zu EBICS

Genaugenommen ist EBICS älter als 10 Jahre, denn die eigentliche Geburtsstunde von EBICS ist der 18. Juli 2003. An diesem Tag stellte die SIZ GmbH auf einer Sondersitzung des damaligen ZKA (Zentraler Kredit Ausschuss = alter Name der DK) ein internetbasiertes Electronic-Banking-Verfahren namens WOP vor mit dem Ziel, entweder dieses Verfahren oder zumindest die Designgrundlagen dieses Verfahrens zur Basis eines neuen, multibankfähigen Internetstandards für die gesamte Deutsche Kreditwirtschaft zu machen. Das DFÜ-Abkommen des ZKA garantierte seit 1995 im Firmenkundengeschäft ein multibankfähiges Verfahren, BCS-FTAM. Doch dieses Filetransferverfahren basierte auf dem OSI-Standard FTAM für X.25- und ISDN-Verbindungen und war im Internetzeitalter längst nicht mehr „state of the art“. Trotz einiger Versuche war es seitdem nicht gelungen, einen gemeinsamen IP-basierten Standard zu etablieren. Es gab herstellerspezifische (z. B. MultiWeb, MCFT) und verbandsinterne Lösungsansätze (BCS-FTP), denen jedoch das Entscheidende fehlte: die Multibankfähigkeit. An diesem 18. Juli 2003 nun schien die Zeit reif für einen neuen Standard. Spontan bildete sich auf der Sondersitzung eine Arbeitsgruppe der DK mit dem Auftrag, einen gemeinsamen IP-basierten multibankfähigen Kommunikations- und Sicherheitsstandard zu entwickeln. Auf den Designgrundlagen von WOP entstand EBICS. Das von der Arbeitsgruppe erstellte Grobkonzept war die Basis für die EBICS-Spezifikation, die in der Version 1.0 bereits Mitte 2005 vorgelegt werden konnte.

EBICS war keine Revolution, sondern basierte von Beginn an auf einem evolutionären Konzept. Die Elemente von BCS-FTAM, die sich seit über 10 Jahren bewährt hatten, wurden beibehalten, und nur die Elemente, die nicht mehr dem aktuellen Stand der Technik entsprachen, wurden neu konzipiert. So wurde das Konzept der Auftragsarten und damit die Anwendungsneutralität ebenso beibehalten wie die Autorisierung von Zahlungsdaten durch Elektronische Unterschriften (EU). Neu an EBICS war vor allem, dass die X.25- bzw. ISDN-basierte Kommunikation von BCS-FTAM durch ein modernes, auf Internetstandards basierendes XML-Kommunikationsprotokoll ersetzt wurde. Des Weiteren wurde die EU durch das Konzept der Verteilten Elektronischen Unterschrift (VEU) erweitert, die es Firmenkunden ermöglicht, Aufträge, die z. B. automatisiert aus der Buchhaltung an die Bank übertragen werden, unabhängig von Zeit und Ort mittels EU zu autorisieren und dabei auch mobile Endgeräte zu nutzen.

Die SIZ GmbH hat die Entwicklung von EBICS im Jahre 2003 angestoßen und seitdem kontinuierlich begleitet. 2005 wurde das SIZ die Leitstelle der Deutschen Kreditwirtschaft für EBICS (Anlage 1 des DFÜ-Abkommens) und für die Datenformate im Electronic Banking und Zahlungsverkehr (Anlage 3 des DFÜ-Abkommens).

Die Sparkassen-Finanzgruppe war 2006 die erste Institutsgruppe in Deutschland, die EBICS flächendeckend unterstützte. 2007 folgten dann die genossenschaftlichen und öffentlichen Institute sowie Großbanken und andere Privatbanken.

EBICS: Der sichere Tunnel in unsicheren Netzen

Grundlage für die Entwicklung von EBICS war vor allem ein detailliertes Sicherheitskonzept. Da Daten im Electronic Banking und Zahlungsverkehr besonders geschützt werden müssen, wurden aus den möglichen Bedrohungen Sicherheitsanforderungen und Sicherheitsmaßnahmen für EBICS abgeleitet, die durch verschiedene kryptografische Maßnahmen die Vertraulichkeit, Integrität und Authentizität der Daten in potenziell unsicheren Netzen (z. B. Internet) garantieren. Dabei werden die Vertraulichkeit und die Integrität der Daten durch ein EBICS-spezifisches Verschlüsselungsverfahren gewährleistet, das zusätzlich zur TLS-Verschlüsselung auf der Transportebene eine End2End-Verschlüsselung der sensitiven Daten im Electronic Banking bietet. Die Authentizität der Kommunikation wird durch die Authentifikationssignatur eines jedes Datenpakets hergestellt. Die Autorisierung von Zahlungen erfolgt schließlich durch Elektronische Unterschriften, wobei je nach vertraglicher Vereinbarung zwischen Kunde und Bank verschiedene Berechtigungsmodelle zum Zuge kommen können (Einzel- und Mehrfachunterschriften, EU-Klassen, Limite etc.). Das Sicherheitskonzept wird seitdem regelmäßig überprüft und EBICS bei Bedarf weiterentwickelt, um das Verfahren an neue oder geänderte Bedrohungslagen und/oder technische Standards anzupassen. EBICS hat sich im Laufe der Jahre als ein überaus sicherer Standard bewährt: Bis zum heutigen Tag sind keine erfolgreichen Angriffe auf EBICS bekannt geworden.

Die wegweisenden Features von EBICS zur sicheren Übertragung sensitiver Daten:


2008: Die Einführung in Deutschland

Am 1. Januar 2008 war es dann soweit: Durch das DFÜ-Abkommen der Deutschen Kreditwirtschaft hatten sich alle Banken und Sparkassen in Deutschland verpflichtet, EBICS auf der Bankseite ab diesem Datum zu unterstützen. EBICS wurde von den Firmenkunden schneller als erwartet angenommen: Bereits im ersten Jahr migrierte ein Großteil der Firmenkunden von BCS-FTAM auf EBICS. Zu groß waren offenbar die Vorteile des neuen Verfahrens. Zu dem rasanten Erfolg von EBICS trug vor allem bei, dass die Übertragungsgeschwindigkeit des IP-basierten EBICS um ein Vielfaches höher war als bei FTAM, dass die Verwendung von Internetstandards die Einbindung in Firmen- und Banknetzwerke wesentlich vereinfachte und dass EBICS neue Features wie die Verteilte Elektronische Unterschrift bot. Entscheidend war aber, dass die für Firmenkunden zentrale Multibankfähigkeit durch das DFÜ-Abkommen der DK von Beginn an garantiert war. Erleichtert wurde der Umstieg dadurch, dass im Verfahren bereits Migrationsszenarien implementiert waren, die es ermöglichten, die Schlüssel für die Elektronische Unterschrift nahezu auf „Knopfdruck“ von BCS-FTAM auf EBICS umzustellen.

EBICS avanciert zum Interbank-Verfahren

Dass EBICS ein sehr sicheres Verfahren ist und gerade zur sicheren und schnellen Übertragung großer Datenmengen konzipiert ist, sprach sich schnell herum. So war es nicht verwunderlich, dass EBICS auch zum Kommunikationsstandard im Interbanken-Zahlungsverkehr avancierte. Vorreiter war hier die Deutsche Bundesbank, die bereits im Jahr 2008 EBICS als Kommunikationsverfahren für den SEPA-Clearer im Rahmen des EMZ einführte. Mittlerweile ist EBICS zum sicheren Austausch zwischen Banken und Clearinghäusern nicht mehr wegzudenken. Neben der Bundesbank setzt auch die EBA-Clearing im STEP2-Zahlungssystem auf EBICS und nicht zuletzt ist EBICS im sogenannten bilateralen Garagenclearing zwischen Banken seit vielen Jahren etabliert.
Auch für die Auslieferung von Daten durch Service-Rechenzentren wurde EBICS sehr schnell eingeführt. Im Jahr 2009 wurde hierzu die entsprechende Richtlinie der DK im Hinblick auf die EBICS-Unterstützung verabschiedet.

EBICS wird zum internationalen Standard

Bereits Ende 2006 wurde die französische Bankwirtschaft (CFONB) bei ihrer Suche nach einem neuen, sicheren und IP-basierten Kommunikationsverfahren auf EBICS aufmerksam. Ähnlich wie in Deutschland stand man auch in Frankreich vor der Situation, einen in die Jahre gekommenen Standard (ETEBAC) durch ein zukunftweisendes Verfahren abzulösen. Nach einer intensiven Evaluation verschiedener Alternativen erwies sich EBICS als das geeignete Verfahren und es kam ab 2008 zu einer Kooperation zwischen der französischen und deutschen Kreditwirtschaft. Im Sommer 2010 wurde dann in Brüssel die europäische EBICS-Gesellschaft nach belgischem Recht, die EBICS SCRL, gegründet. Inzwischen ist EBICS in Frankreich flächendeckend eingeführt und genauso erfolgreich wie in Deutschland. Mit der Gründung der EBICS-Gesellschaft wurde das SIZ zum offiziellen technischen Büro der Gesellschaft (europäische EBICS-Leitstelle) und koordiniert seitdem die EBICS-Workinggroup, also das Gremium der Gesellschaft, das für die Weiterentwicklung von EBICS zuständig ist.

Mit der Einführung von EBICS in Frankreich etablierten sich allerdings unterschiedliche „Dialekte“ in den beiden Ländern. Ganz pragmatisch im Vorgehen akzeptierte man, dass es aufgrund unterschiedlicher Anforderungen in den beiden Ländern auch unterschiedliche Ausprägungen des EBICS-Standards gab. Dies betraf vor allem die Darstellung von fachlichen Geschäftsvorfällen, die in Deutschland durch die bekannten dreistelligen Auftragsartenkürzel erfolgt, während in Frankreich Formatparameter zur Kennzeichnung genutzt werden. Daneben gab es weitere Unterschiede, so z. B. dass in Frankreich die verwendeten kryptografischen Schlüssel im X.509-Standard genutzt werden, während in Deutschland weiterhin ein aus BCS-FTAM stammendes proprietäres Format verwendet wird. In beiden Ländern wurde zwar im Kern EBICS „gesprochen“, aber bei der länderübergreifenden Kompatibilität hakte es doch, man sprach und spricht unterschiedliche „Mundarten“.

So richtig deutlich wurde dieses Manko, als 2015 mit der Schweiz ein weiteres Land Mitglied der EBICS-Gesellschaft wurde. Die Schweiz stand vor dem Dilemma, welchem „Dialekt“ sie denn nun folgen oder ob sie gar eine dritte, schweizerische „Mundart“ sprechen sollte.

Es war offensichtlich, dass unterschiedliche EBICS-Dialekte für die gewünschte Verbreitung des Standards in Europa nicht förderlich sind. Die Lösung konnte nur in einer Harmonisierung von EBICS liegen, die in der neuen EBICS V3.0 endlich angegangen wurde. Vor allem wurde durch die Einführung von BTFs (Business Transaction and Formats) eine zukunftsfähige, flexible und vor allem einheitliche Kennzeichnung von Geschäftsvorfällen für EBICS eingeführt. Zudem konnten weitere wichtige Harmonisierungen im EBICS-Standard erreicht werden, die EBICS zu einem einheitlichen internationalen Standard machen. Denn im elektronischen Zahlungsverkehr ist es wichtig, dass sich Partner erreichen, verstehen und vertrauen können. Für das Verstehen sorgen vor allem gemeinsame SEPA-Datenformate und die EBICS-einheitliche Kennzeichnung durch BTFs, für das Erreichen und das Vertrauen sorgt EBICS als gemeinsamer Kommunikations- und Sicherheitsstandard. EBICS V3.0 ist verabschiedet und kann ab Herbst 2018 eingeführt werden. In Deutschland wird EBICS V3.0 durch das DFÜ-Abkommen der DK ab 2021 verpflichtend für alle Institute der Deutschen Kreditwirtschaft.

10 Jahre EBICS: Rückblick und Ausblick

Heute gilt es zurückzublicken auf 10 Jahre EBICS in Deutschland. Was als Versuch begann, unterschiedliche, inkompatible  Entwicklungen im Electronic Banking in Deutschland einzufangen und die Multibankfähigkeit für Firmenkunden auch im Internetzeitalter zu gewährleisten, entwickelte sich zu einer Erfolgsgeschichte, die die nationalen Grenzen längst überwunden hat. Als offener Standard zum sicheren Austausch von Dateien ist EBICS weltweit bekannt und wird auch in Ländern genutzt, die (noch) nicht Mitglied in der EBICS-Gesellschaft sind. EBICS ist mittlerweile nicht nur ein Kunde-Bank-Verfahren, sondern ein etablierter Standard im Interbankenzahlungsverkehr und wird voraussichtlich auch eine wichtige Rolle sowohl in der Einreichung als auch im Clearing von Instant Payments spielen.

Doch was sind die Gründe für diesen lang anhaltenden Erfolg? Mir scheinen hier vor allem folgende Punkte ausschlaggebend:
  • Die Anwendungsneutralität von EBICS
    EBICS ist anwendungsneutral und kann die unterschiedlichsten Daten übertragen, da weder Formate noch bankfachliche Festlegungen in das Übertragungsprotokoll modelliert wurden. Darum kann EBICS so leicht in unterschiedlichen Ländern  und in unterschiedlichen Anwendungsszenarien eingesetzt werden.
  • Die Sicherheitsfeatures von EBICS
    Indem EBICS voneinander unabhängige kryptografische Verfahren für die Vertraulichkeit der Daten, für die Authentizität der Partner und der Kommunikation und für die Autorisierung von Aufträgen kombiniert, bietet es einen sicheren Tunnel in unsicheren Netzen.
  • Die Multibankfähigkeit
    Sowohl in Deutschland als auch in Frankreich ist EBICS ein multibankfähiges Verfahren. In Deutschland wird die Multibankfähigkeit durch das DFÜ-Abkommen der DK garantiert.
  • Die Anpassungsfähigkeit von EBICS
    Als offener Standard lässt sich EBICS durch seine Architektur an unterschiedliche Anforderungen anpassen und wird durch die EBICS-Gesellschaft kontinuierlich weiterentwickelt.
EBICS hat viel Vergangenheit hinter sich, sogar noch mehr als die 10 Jahre seit der verpflichtenden Einführung in Deutschland. Doch die Geschichte ist noch lange nicht zu Ende: Als offenem und sicherem Kommunikationsstandard steht EBICS die Zukunft offen. Die Erfahrung, dass die grundlegenden Designentscheidungen auch heute noch tragen und dass die Flexibilität des Verfahrens es ermöglicht, EBICS an neue Anforderungen anzupassen, stimmt zuversichtlich, dass EBICS weiterhin ein wichtiger Baustein im elektronischen Zahlungsverkehr in Europa sein wird.

Dieter Schweisfurth

Leiter Electronic Banking
SIZ GmbH

EBA CLEARING führt EBICS als zusätzliches Übertragungsprotokoll für ihr Instant-Payment-System ein

Teilnehmer am EBA-Clearingservice können ab November 2017 sowohl SIANet als auch EBICS für die Verbindung zur neuen paneuropäischen Infrastruktur für Echtzeitzahlungen nutzen. Weitere Alternativen könnten später folgen.

EBA CLEARING hat angekündigt, dass zukünftige Teilnehmer an ihrer paneuropäischen Instant-Payment-Infrastrukturlösung neben SIANet auch den Electronic Banking Internet Communication Standard (EBICS) zum Austausch von Zahlungsverkehrsnachrichten mit der Plattform nutzen können. Das Unternehmen bietet das zusätzliche Übertragungsprotokoll EBICS mit der Einführung des Dienstes im November 2017 an. Ab Juni 2017 steht EBICS für die Testumgebung zur Verfügung.
Lesen Sie hier die Pressemitteilung der EBA CLEARING vom 09. März 2017: Pressemitteilung EBA CLEARING

Michael Lembcke

Migration Zahlungsverkehr Schweiz: echte End-to-End-Tests mit EBICS

Auf dem Finanzplatz Schweiz arbeiten die Banken mit Hochdruck an den Umsetzungsprojekten für die Harmonisierung des Schweizer Zahlungsverkehrs nach ISO 20022. Softwarehersteller und Firmenkunden fordern Testmöglichkeiten für die neuen Zahlungsformate. Gesucht ist ein End-to-End-Testszenario, das die produktive Verarbeitung seitens der Bank bestmöglich abbildet. In der Schweiz können die wenigsten Banken solche Tests anbieten. Dabei kann EBICS helfen.


Die SIX Interbank Clearing, verantwortlich für die Publikation der Schweizer Implementierung, bietet eine sogenannte Validierungsplattform an. Dort können die jeweiligen Meldungen (pain und camt) bezüglich Syntax und einfachen Business-Regeln validiert werden. In der Regel ist dies die erste Anlaufstelle für Tests in der neuen ISO-Welt. Für Hersteller und Kunden reicht diese Prüfung jedoch nicht aus, um anschliessend die produktiven Zahlungsläufe mit ihrer Bank umzustellen.

Taugliche End-to-End-Tests umfassen die Aufträge als Buchungen in die elektronischen Kontoauszüge (z. B. MT940 oder camt.053) und Avisierungen (z. B. MT942 oder camt.052) inklusive Saldo-Nachführung sowie ein Fehlerverhalten, welches der Produktion entspricht (Ausweisung entsprechender Status-Rapporte und Storno-Buchungen). „Die Schwierigkeit von Tests ist oft die Avisierung, welche aufgrund der eingelieferten Daten sich entsprechend verhält“, weiß Christoph Schenker von der PostFinance. „Die Testplattplattform http://isotest.postfinance.ch bietet alle Möglichkeiten, welche der Softwarehersteller für Ein- und Auslieferungen benötigt, um seine Software für den Kunden ‚ISO-ready‘ zu machen.“

Gerade den Fehlerfall möchte der Kunde vor der Einführung simulieren, um seine internen Prozesse der Ausnahmebehandlung zu testen. Typischerweise sind dies Fehler wie „ungenügende Deckung“, „falsches Begünstigtenkonto“ und ähnliche Ausnahmefälle, welche in der Folge im produktiven Betrieb auftreten können.

Fasst man End-to-End etwas weiter, wäre es für den Firmenkunden ideal, wenn er direkt aus seiner ERP-Software mittels EBICS einen Zahlungslauf an eine Testinfrastruktur senden und wiederum mittels EBICS die dazugehörigen Downloads ausführen kann. Nur dann ist ein echter „proof of the pudding“ möglich. Simuliert werden müssen insbesondere die Rückmeldungen bei Fehlern und die Verarbeitung realer Dateigrössen – d. h. ein produktiver Kreditorenlauf mit einigen hundert Zahlungen oder mehr, nicht nur eine Testzahlung. So ist die nötige Sicherheit für einen Produktionsstart gegeben. Die direkte Anbindung einer Testplattform über EBICS ermöglicht es, Testzyklen zu automatisieren und via EBICS-Protokoll grosse Dateien zu übermitteln. Dies ist mit einer Testplattform, welche nur über eine manuelle Web-Upload-Schnittstelle verfügt, nur schwer möglich.

Innovative Schweizer Banken sehen in der Kombination von ISO 20022 und EBICS das ideale Tandem, um ihre Kunden in der Harmonisierung des Zahlungsverkehrs zu unterstützen. Institute, welche zusätzlich eine echte End-to-End-Testmöglichkeit anbieten können, bieten ihren Kunden einen echten Mehrwert. „SAP unterstützt den Credit Transfer mit ISO 20022 schon seit mehreren Jahren. Gute Testplattformen und direkte Ansprechpartner bei Finanzinstituten unterstützen die weitere Umsetzung von ISO20022-Meldungen in der Schweiz“, sagt Rainer Hofmeister vom Hersteller SAP.

Carsten Miehling

Wie steht es mit EBICS in Marokko?

Der Vormarsch von EBICS in Europa ist inzwischen unumstritten. Wie entwickelt sich der Standard jedoch jenseits der Grenzen der Europäischen Union? Ein Kontinent, der sich in meinen Augen besonders für die Verwendung eines modernen, leistungsfähigen und universellen Protokolls für den elektronischen Zahlungsverkehr wie EBICS eignet, ist Afrika. Genauer gesagt denke ich hier zuallererst an Marokko. Warum?


Seit langem schon orientieren sich die marokkanischen Banken und Finanzinstitute an europäischen Praktiken im Bankwesen, insbesondere an denen französischer Banken. So folgten in den neunziger Jahren die marokkanischen Banken den französischen, indem sie sich im elektronischen Zahlungsverkehr zwischen Unternehmen und Banken für das ETEBAC-Protokoll entschieden. Auf diese Weise wurden die marokkanischen Unternehmen in die Lage versetzt, effiziente Cash Management-Lösungen einzusetzen.

Ebenso orientierte man sich bei dem vom marokkanischen Bankensektor verwendeten Austauschformat für Kontoauszüge, Überweisungen und Lastschriftverfahren stark an den CFONB-Formaten.

Momentan wird in Marokko noch immer das ETEBAC-Protokoll verwendet. Allerdings läuft es unter X.28 über private PADs und die Unternehmen müssen asynchrone Analog-Modems verwenden, die kaum noch zu finden sind. Somit wird es nahezu unmöglich, die Anzahl der Unternehmen zu steigern, die den ETEBAC-Kanal verwenden. Mögliche Ersatzlösungen sind:
  • das Internet-Banking, das jedoch für Unternehmen mit Konten bei mehreren Banken bzw. Unternehmen mit erheblichem Transaktionsvolumen ungeeignet ist,
  • SWIFT, was zu wiederkehrenden Zusatzkosten führt, die nicht unerheblich sind,
  • weniger gebräuchliche Protokolle wie PeSIT, die künftigen Anforderungen nicht gerecht werden.
Der durch marokkanisches Gesetz vorgegebene Rechtsrahmen für den Austausch und Schutz digitaler Daten fördert die Verwendung sicherer Datenaustauschprotokolle mit elektronischer(n) Unterschrift(en). Dadurch werden die Banktransaktionen mit den für sie geforderten Sicherheitsfunktionen wie Authentifizierung, Unveränderlichkeit und Integrität, Geheimhaltung, keine Wiederverwendbarkeit der Unterschrift sowie Nichtabstreitbarkeit ausgestattet. Diese Funktionen werden standardmäßig vom EBICS-Protokoll abgedeckt.

Die marokkanischen Banken, die in Afrika eine Vorreiterrolle einnehmen und in 22 Ländern des Kontinents vertreten sind, benötigen zuverlässige und bewährte Systeme zur Finanzdatenübermittlung zwischen den Banken und über Grenzen hinweg, um unter anderem dafür zu sorgen, dass Marokko zum Drehkreuz von Banktransfers wird und ein Maximum an Transaktionen an sich zieht, die auf sichere und moderne Art und Weise durchgeführt werden. Hierfür bietet sich EBICS als das Mittel der Wahl an.

Übrigens erlaubt EBICS nicht nur, das bestehende Angebot von Diensten für Unternehmen auszubauen, es stellt für die marokkanischen Banken auch eine echte Innovationsmöglichkeit dar, um ganz neue Dienste (z. B. e-Invoicing) anzubieten.

Und vergessen wir nicht zwei weitere Bereiche, in denen EBICS seine Wirkung voll entfalten könnte:
  1. In Europa wird EBICS für den intereuropäischen elektronischen Zahlungsverkehr zwischen den Banken bereits sehr erfolgreich angewandt. Die marokkanischen Finanzinstitutionen könnten nachziehen und hätten somit die Möglichkeit, die Widerstandsfähigkeit und die hohe Verfügbarkeit im bankenübergreifenden Zahlungsverkehr zu verbessern und nebenbei dessen Kosten zu optimieren.
  2. EBICS kann bei Datentransfers für staatliche Digitalisierungsprojekte eingesetzt werden, insbesondere im Zusammenhang mit Sozialdaten, medizinischen und dienststellenübergreifenden Daten.
Ausgehend von obigen Ausführungen erscheint mir das EBICS-Protokoll, das sich – wie der Leser des Blogs mittlerweile hat feststellen können – dank seiner Universalität, seiner einfachen Anwendung, seinem hohen Sicherheitsniveau und der Tatsache, dass mit seiner Verwendung keine wiederkehrenden Kosten verbunden sind, in Europa schnell ausbreitet, eine ideale Alternative für den Business-to-Bank- und Bank-to-Bank-Zahlungsverkehr. Würden zudem die marokkanischen Banken die Anwendung des ISO-20022-Standards in Betracht ziehen, wäre dies ein großer Schritt in Richtung Harmonisierung und Standardisierung des elektronischen Finanzdatenaustauschs, was zu einer Vereinfachung und Optimierung der Transaktionen mit Europa führen würde. Dieser Punkt erscheint mir auch deshalb so wichtig, weil die marokkanische Wirtschaft durch zahlreiche Standortverlagerungen europäischer Unternehmen von der geographischen Nähe Marokkos zum europäischen Kontinent profitiert hat.

Stellt sich schließlich die Frage der Migration nach EBICS. Ist die Migration ein solch komplexes Unterfangen, dass sie sich als ein echtes Hindernis für die Verwendung dieses Protokolls erweisen könnte? Bedenkt man, wie die Migration in Frankreich vonstattenging, ist das meiner Meinung nach nicht der Fall. Die in diesem Zusammenhang nicht nur von den Herstellern für Banken- und Unternehmenssoftware, sondern auch von den in Marokko ansässigen französischen Banken gesammelten Erfahrungen würden eine sanfte Migration ohne große Anfangsschwierigkeiten sicherstellen.

Marc Dutech 

EBICS ist nicht gleich EBICS – von Auftragsarten und Formatparametern

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


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

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

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

Wie gut verstehen sich Bankrechner und Client?

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

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

Michael Lembcke 

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