Posts mit dem Label Payment Products werden angezeigt. Alle Posts anzeigen
Posts mit dem Label Payment Products werden angezeigt. Alle Posts anzeigen

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

EBICS-Tests mit Kunden im produktiven Bankrechner?

Seit EBICS 2.4 ist es in Frankreich möglich, Geschäftsvorfälle – nicht wie u. a. in Deutschland üblich – über dreistellige Auftragsarten sondern über die bis zu 40-stelligen FileFormat-Parameter auszutauschen. Diese sind bekanntlich jeweils mit den Auftragsarten FUL bzw. FDL einzuleiten. Dabei ist es möglich, ein sogenanntes Test-Flag anzugeben. Darüber kann ein EBICS-Kunde im produktiven Betrieb z. B. beim Senden einer Datei der Bank eine Testeinreichung signalisieren. Vorausgesetzt, es besteht eine bilaterale Vereinbarung über die Nutzung des Test-Flags, kann die Bank den Auftrag annehmen, als Testfall werten und vor der echten Verarbeitung aussteuern. Die Nutzung eines Test-Flags in Produktion ist bei den Banken nicht unumstritten. Eine solche Option wird von deutschen Banken derzeit überwiegend abgelehnt.

Mit der aktuellen EBICS-Version 3.0 und der einheitlichen Nutzung der BTFs anstelle von Auftragsarten und FileFormat-Parametern entfällt das bestehende Test-Flag in der EBICS-Spezifikation. Zudem wurde mit dem EBICS-CR EB-17-01 Element Group Parameter eine verschärfte Prüfung auf die Nutzung von nicht bilateral vereinbarten Angaben in den generischen Parametern des BTFs eingeführt. Unerlaubte Angaben werden nun mit dem EBICS-Returncode 09-0-0-06: EBICS_UNSUPPORTED_REQUEST_FOR_ORDER_INSTANCE abgelehnt.

Als Hilfestellung für die EBICS-3.0-Einführung in Frankreich hat der französische CFONB einen eigenen Migrationsleitfaden erstellt (EBICS 3.0 Aide à la migration BTF & Table de correspondance File Format/BTF). Da in Frankreich das Test-Flag von Banken in der Vergangenheit genutzt wurde und auch weiterhin der Bedarf an einer solchen Option besteht, hat der CFONB für die BTF-Migration die Nutzung des Test-Modus für BTF definiert und als optionale Funktion in den Leitfaden aufgenommen. Somit kann bei bilateraler Vereinbarung zwischen Bank und Kunde auch bei BTF der Parameter TEST für Testfälle genutzt werden. Bei abweichender Parameterangabe erfolgt eine Ablehnung mit dem o. g. Returncode. EBICS-Bankrechner, und EBICS-Clients können diese Funktion optional mit anbieten.

Unabhängig davon gibt es bei EBICS auch die Alternative, für Testeinreichungen eigene speziell für den Test bilateral vereinbarte Geschäftsvorfälle (BTFs) zu nutzen.

Letztendlich bleibt aber festzuhalten, dass bei Nutzung der Testoption in der Produktionsumgebung immer das Risiko besteht, dass Testdateien die Produktion negativ beeinflussen oder gar unerwartet Eingang in die Produktionsdaten finden können.

Sicherer ist da dann doch eine eigene EBICS-Bankrechner-Installation für EBICS-Tests mit Kunden. Warum nicht?


Autor: Michael Lembcke

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

Sie sind Bankkunde und nutzen EBICS: Funktioniert Ihr EBICS-Monitoring auch noch mit EBICS 3.0?

Für das Monitoring der EBICS-Prozesse und -Ergebnisse steht seit EBICS 2.5 den EBICS-Clients neben dem rein textbasierten Kundenprotokoll auch ein XML-basiertes Protokoll für das fachliche EBICS-Monitoring zur Verfügung. Letzteres eignet sich insbesondere für maschinelle Auswertungen. Das textbasierte Protokoll kann durch den EBICS-Client mit der Auftragsart PTK und das XML-basierte Protokoll mit der Auftragsart HAC vom EBICS-Server heruntergeladen werden. Mit EBICS-Version 3.0 ist das textbasierte Protokoll nicht mehr Bestandteil der Spezifikation. Zudem gibt es Änderungen im HAC-Protokoll, die bei der maschinellen Ergebnisauswertung zu berücksichtigen sind. Diese Änderungen wirken sich wegen der erforderlichen übergreifenden Versionsinteroperabilität z. T. auch auf EBICS-Clients niedriger EBICS-Versionen aus, sobald ein EBICS-Bankrechner EBICS Version 3.0 unterstützt.

Für Software-Hersteller und EBICS-Nutzer gilt daher, dass man sich bei den EBICS-Clients, die bereits über Funktionen der maschinellen Kundenprotokoll-Auswertung verfügen, auf Änderungen einstellen muss. Zunächst sollte für maschinelle Auswertungen in EBICS-Clients der Wechsel vom PTK zum HAC vollzogen werden. Außerdem gilt für diejenigen, die bereits das HAC-Protokoll nutzen, dass mit EBICS 3.0 das finale Ergebnis im HAC-Protokoll anders abgebildet wird.

Bisher informierte das HAC-Ende-Kennzeichen mit den Angaben ORDER_HAC_FINAL_POS und ORDER_HAC_FINAL_NEG direkt darüber, ob das Ergebnis der Einreichung positiv oder negativ war. Mit EBICS 3.0 gibt es lediglich noch ein HAC-Ende-Kennzeichen ORDER_HAC_FINAL, welches den Ausgang der Einreichung ausschließlich in Verbindung mit dem letzten Reason Code ausdrückt. Demnach weist dann beispielsweise der finale Code DS04 darauf hin, dass der Auftrag abgelehnt wurde und DS05, dass der Auftrag erfolgreich eingereicht und an die Banksysteme weitergeleitet wurde. Weitere Reason Codes sind zu berücksichtigen.

Also, damit Ihr EBICS-Monitoring auch weiterhin die korrekten Ergebnisse liefert, empfehle ich auf das HAC-Kundenprotokoll zu setzen und sich auf die Auswertung der Reason Codes zu konzentrieren. So behalten Sie auch zukünftig den Überblick in der EBICS-Kommunikation mit Ihrer Bank.


Michael Lembcke
 

Migration zu EBICS 3.0 in Frankreich

EBICS 3.0 ist in Frankreich am 27. November letzten Jahres in Kraft getreten. Gut zwei Monate sind seitdem vergangen und so ist es an der Zeit zu schauen, wie weit die Migration zur neuen Version fortgeschritten ist.

Gegenstand dieser neuen Version ist die Harmonisierung von EBICS mit den folgenden Zielen:
 
  • eine einheitliche EBICS-Version in allen Ländern, in denen EBICS zum Einsatz kommt
  • eine einheitliche Identifizierung der Geschäftsvorfälle und Formate (auch BTF genannt: Business Transaction Format)
  • ein einheitliches X.509-Format für die Schlüsselablage

Das Datum für das Inkrafttreten betrifft nur die französischen Banken und Kreditinstitute und ist nicht verpflichtend für Firmenkunden. Diese können selbst entscheiden, wann sie migrieren möchten.

Die großen französischen Banken arbeiten seit einigen Monaten an den Migrationsprojekten und die meisten können ihren Kunden den EBICS-3.0-Kanal ab sofort anbieten. Die anderen sind in der letzten Testphase und die Öffnung des EBICS-3.0-Kanals steht unmittelbar bevor.

Die kleineren Banken sind noch nicht so weit. Nur wenige haben mit den Migrationsprojekten begonnen.Es ist deshalb sehr wahrscheinlich, dass diese Institute erst in einigen Monaten, vielleicht sogar erst 2020, den EBICS-3.0-Kanal anbieten können.

Diese Unterschiede in der zeitlichen Umsetzung sollten die Firmenkunden, die demnächst auf EBICS 3.0 migrieren wollen, jedoch nicht bremsen. Denn auch die Banken, die schon auf EBICS 3.0 migriert haben, werden in einer mehr oder weniger langen Übergangsphase noch die Version 2.4.2 unterstützen, die seit der Einführung von EBICS in Frankreich in Kraft ist (in Deutschland wird aktuell die Version 2.5 genutzt). Diese Übergangsphase gibt den Firmenkunden Zeit, ihre Client-Software zu aktualisieren.

Vor allem mangelndes Interesse der Firmenkunden an der neuen Version könnte jedoch dafür sorgen, dass die Übergangsphase sich hinzieht. Um dem entgegenzuwirken, können die Banken ihren Firmenkunden zusätzliche Services anbieten, die mit den Erweiterungen der neuen Version möglich werden. Dazu gehören unter anderem das einfachere Einrichten von Transfers und die verteilte elektronische Unterschrift. Sie ermöglicht es Firmenkunden, Aufträge asynchron nach dem Transfer der Datei zu unterschreiben (in der Version 2.4.2 musste die elektronische Unterschrift zusammen mit der Auftragsdatei geschickt werden), und verhilft ihnen so zu mehr Mobilität.

Das wird sich vor allem dann bemerkbar machen, wenn die X.509-Zertifikate komplett virtuell sind, so dass die mobile Unterschrift wirklich nutzbar ist. Experten arbeiten an diesem Thema und so sollte es in einigen Monaten effiziente Lösungen geben…

Marc Dutech

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

EBICS im „Private Banking“ – Anwendungsfälle ausserhalb des Zahlungsverkehrs

EBICS wird gemeinhin als sicheres Übertragungsprotokoll für den Austausch von Zahlungsverkehrsdateien (Aufträge und Auszüge) angesehen. Insbesondere im Segment der Firmenkunden ist diese Anwendung mit Sicherheit auch die am weitesten verbreitetste. Ich möchte an dieser Stelle einen anderen, in der Schweiz sehr aktuellen Anwenderfall vorstellen: EBICS-Angebote im Private Banking.


Hiesige Privatbanken haben aktuell einen noch schwereren Stand als bisher und geraten von mehreren Seiten unter Druck. Regulierung, Margendruck, besser informierte Kunden, das Aufbrechen der Wertschöpfungskette und die Digitalisierung sind nur einige Themen, welche heute auf der Agenda von Privatbankvorständen anzutreffen sind. Im Bereich Automation beobachten wir in der Schweiz zurzeit eine erwähnenswerte EBICS-Initiative - den Einsatz als Schnittstelle für Börsengeschäfte.

Auf Anregung grösserer institutioneller Anleger und professioneller Vermögensverwalter, welche ihrerseits ebenfalls ein Interesse an mehr Automation haben, werden neuerdings vermehrt EBICS-Transaktionsarten aus dem Ordergeschäft angeboten. Typischerweise sind dies Auftragsarten für das Einliefern und Verarbeiten von Börsenaufträgen (Upload) und Auftragsbestätigungen, Abrechnungen und Depotauszüge (Download). Als Formate kommen die SWIFT (MT5xx) und PDF zum Einsatz. Konkret umgesetzt werden sie als institutsspezifische Auftragsarten (XYZ).

Schaut man sich nun die gesamte Wertschöpfungskette einer Börsentransaktion an, so kann diese im Idealfall voll automatisiert durchgeführt werden. Das Portfoliomanagement-System des Vermögensverwalters erkennt ein Missverhältnis der Anlagestrategie zum Portfolio des Kunden und generiert den Börsenauftrag für die Umschichtung. Mittels der Standards EBICS und SWIFT (z. B. MT502) wird der Auftrag automatisch beim Institut ausgelöst und die Bestätigung abermals über EBICS zurückgemeldet (z. B. MT509). Diese Automation reduziert auf allen Seiten den Aufwand der Abwicklung massiv. Zusätzlich reduziert sich gegenüber den heute noch weit verbreiteten manuellen Prozessen die Fehlerquote in grossem Masse.

Zusammengefasst kann man festhalten, dass innovative Privatbanken EBICS bereits heute anbieten oder in Kürze mit Angeboten im Markt auftreten werden. Da traditionellerweise der Zahlungsverkehr in diesem Geschäft eine nicht so dominante Rolle wie bei Universalbanken einnimmt, verlagert sich der EBICS-Schwerpunkt auf Börsentransaktionen und das Vermögensausweis-Reporting. Da auch Vermögensverwalter und institutionelle Anleger mehr Automation anstreben, entsteht eine Win-Win-Situation. Ideal wäre es, wenn sich die Standardisierungsgremien möglichst schnell auf universelle und einheitliche Auftragsarten (oder neu ab EBICS 3.0 sog. BTF-Spezifikationen) und Formate festlegen könnten.

Carsten Miehling

EBICS 3.0 mit BTF macht den Weg frei

Der europäische Zahlungsverkehr wächst dank SEPA und EBICS zusammen. Mit EBICS 3.0 verschmelzen nun auch die verschiedenen EBICS-Dialekte. Das Konzept dahinter heißt BTF. BTF steht für Business Transaction Format. BTF  vereinheitlicht die Beschreibung der zu transferierenden Formate in Deutschland, Frankreich und der Schweiz. Diese Harmonisierung macht den Weg frei für eine wachsende EBICS-Community.


Die neue EBICS 3.0-Spezifikation ist ab dem 27. November 2018 gültig. Termine zur Einführung können in den einzelnen Ländern abweichen. EBICS 3.0 bringt folgende Vereinheitlichungen:
  • einheitliche EBICS-Version in den drei EBICS-Ländern
  • einheitliche Identifikation der Geschäftsprozesse und Formate (BTF)
  • einheitliches X.509-Format für die Schlüsselablage
Damit ist die Kompatibilität der EBICS-Dialekte gewährleistet.

Optionale Features

Bisher wurden nicht alle EBICS-Features in allen Ländern angeboten. Mit EBICS 3.0 können die Banken ihren Kunden alle optionalen EBICS-Features individuell anbieten. Dazu gehören:
  • Zertifikate
    CA-signierte Zertifikate
    selbstsignierte Zertifikate
  • Berechtigungsmodell
    deutsche T-, A-, B- und E-Autorisierungen
    französische T- und TS-Autorisierungen
    Abschaffung der Fax-Autorisierung
  • Verteilte Elektronische Unterschrift (VEU)
    Die Nutzung der VEU ist in Deutschland obligatorisch, ansonsten optional.
Neuerungen

Die EBICS 3.0-Spezifikation enthält Neuerungen, die bei der Einführung berücksichtigt werden müssen:
  • Mapping
    Die Anpassung von Formatparametern und Auftragsarten an BTF-Standards wird durch Zuordnungsübersichten (Mappings) erleichtert. Auf nationaler Ebene sind Zuordnungsübersichten für Auftragsarten und Formatparameter definiert. Die EBICS-Clients müssen diese Zuordnungen umsetzen. In der Übergangszeit kann es zu Mischformen kommen: Bank A unterstützt bereits BTF, während Bank B nur EBICS 2.x anbietet.
  • Erweiterte Steuerung
    Mit BTF kann nun der EBICS-Client den Bankrechner steuern. Bisher steuerte ausschließlich der Bankrechner die Prozesse. Diese Client-Steuerung öffnet ein neues Kapitel in den Prozessabläufen. Der EBICS-Nutzer kann z. B. vorgeben, ob sein Auftrag direkt in die VEU gehen soll oder die Berechtigung zu prüfen ist. Bei Abweichungen zwischen der BTF-Vorgabe und den Rechten auf dem Bankrechner definiert die EBICS-Spezifikation das Verhalten.
  • Einheitliches Protokoll
    Das strategische Kundenprotokoll in der EBICS 3.0-Spezifikation ist das HAC. Damit wird das alte textbasierte Kundenprotokoll PTK vollständig abgelöst. Das HAC-Protokoll ist maschinenlesbar, da es auf XML basiert. In der Übergangszeit werden PTK und HAC bei einem EBICS-Versionsmix parallel existieren. Nach der EBICS 3.0-Spezifikation sollen BTF-Aufträge nicht mehr im alten PTK angezeigt werden. Wer das dennoch möchte, kann das PTK-Format proprietär erweitern.
EBICS 3.0 ebnet den Weg für eine wachsende EBICS-Community

EBICS 3.0 europäisiert die Nutzung von EBICS. Das ist gut. Damit können Banken neue Märkte und Kunden gewinnen. Der Kunde erhält durch die Flexibilisierung mehr Möglichkeiten. EBICS nutzt nun ausschließlich etablierte Standards.

Existierende Schnittstellen und Vertragskonditionen können fast unverändert bleiben. Das BTF kann im Hintergrund konfiguriert werden. Für Bankrechner und EBICS-Clients bleibt die Fachlichkeit im Vordergrund. Die EBICS 3.0-Spezifikation und die Mappingvorgaben unterstützen das.

Die Einführung von EBICS in neuen Märkten und Ländern ist mit EBICS 3.0 wesentlich erleichtert worden. Die Vorteile von EBICS 3.0 sind unübersehbar. Daher ist eine zeitnahe Einführung in den bestehenden EBICS-Ländern zu empfehlen.

Michael Lembcke

EBICS 3.0 in den Startlöchern

Am 19. Mai 2017 fand im Auditorium der Fédération Bancaire Française (Französische Bankenvertretung) ein Themenworkshop des CFONB zur Vorstellung Version 3.0 des EBICS-Protokolls statt.

Mehr als 120 Personen aus unterschiedlichen Bereichen - Banken, Hersteller, Unternehmen, usw. - nahmen an der Veranstaltung teil, im Rahmen derer verschiedene Redner das Grundkonzept dieser neuen Version vorstellten.


Nachdem die Geschäftsführung und einige Vertreter der EBICS SCRL (www.ebics.org) eine Übersicht vorgestellt hatten, wurden einige entscheidende Daten aus der Geschichte von EBICS präsentiert. Sie haben daran erinnert, dass der EBICS-Standard nun nicht mehr in den Kinderschuhen steckt und belegten dies damit, dass bereits vor 12 Jahren die Implementierung in Deutschland begann und vor mehr als 7 Jahren EBICS in Frankreich übernommen wurde. Bei den Schweizer Finanzinstituten wurde dieser Weg erst 2015 eingeschlagen. Eine Präsentation zeigte die derzeitige Verbreitung von EBICS, die sich von der Iberischen Halbinsel bis zur Ostsee und von Irland bis nach Italien erstreckt. Abgesehen von Deutschland, Frankreich, der Schweiz und Portugal ist der Verwendungsgrad in den entsprechenden Staaten jedoch sehr unterschiedlich.

Im Anschluss wurden die Gründe für den Erfolg von EBICS in den vier Ländern (zahlreiche Artikel zu diesem Thema finden Sie in diesem Blog) ebenso wie die Hindernisse einer schnellen gesamteuropäischen Ausweitung genannt. Zu diesen gehören insbesondere:
  • die Unterschiede in der Identifikation der Zahlungsströme zwischen deutschen, französischen und Schweizer Varianten
  • die Verwendung der X.509-Zertifikate in Frankreich und des Schlüsselpaares in Deutschland
  • der Einsatz der verteilten elektronischen Unterschrift in Deutschland und in der Schweiz, aber nicht in Frankreich
Auf die Auflistung der Gründe folgte eine Beschreibung der tiefgreifenden Veränderungen, die die Version 3.0 mit sich bringen wird, vor allem hinsichtlich der Harmonisierung durch die Integration des BTF-Konzepts (Business Transaction Format) und der möglichen Generalisierung der verteilten elektronischen Unterschrift. Weitergehende Informationen zu diesen Themen erhält man über die Website der EBICS SCRL.

Der zweite Teil des Workshops bestand aus einer Diskussionsrunde zum Thema: Warum brauchen wir eine einheitliche EBICS-Version?

Für die Akteure aus dem EBICS-Bereich war dies die Möglichkeit folgende Themen anzuschneiden und zu diskutieren:
  • Vorteile von EBICS aber auch Grenzen der 2.x Version aufgrund mangelnder Harmonisierung
  • Erwartungen an die neue Version und Vorteile, die durch die Harmonisierung entstehen
  • Möglichkeiten der geografischen Ausweitung, auch auf andere Kontinente
    Hier wurde insbesondere Afrika angesprochen, da dort bereits einige Banken den EBICS-Service in einigen französischsprachigen Ländern anbieten.
  • Möglichkeiten der Verwendung von EBICS über die Unternehmen-Bank-Beziehung hinaus
    Hier wurde vor allem die Verwendung von EBICS für STEP2 und RT1 (Instant Payments) mit der EBA Clearing angesprochen.
  • Migrationsmodalitäten
  • Aspekte der zukünftigen Weiterentwicklung des diskutierten Protokolls, die auf die Tagesordnung gesetzt werden können, wie die Vereinheitlichung des AC-Zertifikates und die Möglichkeit Zertifikate zu verwenden, die nicht auf physischen Medien gespeichert sind, um so die Industrialisierung der EBICS-Signaturlösungen für Mobilgeräte zu vereinfachen
  • aktuelle Verwendung der verteilten elektronischen Unterschrift in Deutschland und in der Schweiz und Vorteile, die durch ihre Verwendung in Frankreich entstehen könnten
Diese Veranstaltung war somit der offizielle Startschuss für die Version 3.0. Ab November 2018 wird sie verfügbar sein; ab diesem Zeitpunkt müssen alle Banken die neue Version, zusätzlich zu der in den verschiedenen Gemeinschaften gültigen Version 2.x, anbieten.

Für Unternehmen besteht keine Verpflichtung ebenfalls zu diesem Zeitpunkt zu migrieren. Für sie ist eine schlagartige Migration von der 2.x zur 3.0 nicht vorgesehen. Die neuen Gemeinschaften hingegen könnten diese neue Version direkt einsetzen.

Es liegt also viel perspektivische Arbeit vor den Herstellern und Banken. Um ihnen dabei zu helfen, wird im Juli 2017 ein Implementationguide auf Seiten der EBICS SCRL und des CFONB zur Verfügung gestellt.

Ich stelle EBICS häufig in verschiedenen Ländern in Europa und darüber hinaus vor und glaube, dass die Harmonisierung die Werbetätigkeit für dieses Produkt wesentlich erleichtern wird. Ich bin überzeugt davon, dass sie der Schlüssel zum Erfolg ist, damit schließlich der erste Buchstabe von EBICS „European“ bedeutet.

Was wäre, wenn aufgrund der Entwicklungen, die derzeit geprüft werden, der nächste Schritt das Worldwide EBICS wäre?...

Marc Dutech

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

Wie sich EBICS verbessern lässt, Teil 9 – EBICS ist für den Dateitransfer beliebig großer Dateien geeignet. – Ja, aber …

Auch mit SEPA ändert sich das Datenverhalten im Zahlungsverkehr weiterhin. Neue Prozesse führen dazu, dass Dateien im Austausch zwischen Kunden und Banken sowie im bilateralen Austausch immer größer werden. Insbesondere in der Kunde-Bank-Beziehung spielt die Downloadfunktion für Datenabholungen (z. B. Kontoauszüge) über EBICS eine wichtige Rolle. Und zumindest hier scheint es noch Optimierungsbedarf zu geben. Bei besonders großen Dateien wird es mit dem erfolgreichen Download aus verschiedenen Gründen schwierig.


Um das Problem genauer zu beschreiben, muss man zunächst etwas tiefer in das EBICS-Protokoll einsteigen. Datenabholungen (Downloads) über EBICS erfolgen segmentweise immer für alle zur Clientanfrage passenden Daten. Ein EBICS-Client legt beim Empfang einer Anfrage alle Daten für eine Abholung immer in genau einer physischen Datei ab.

Im Downloadprozess von EBICS ermittelt der EBICS-Server nach Empfang eines Abholauftrages zunächst die Anzahl der Segmente, in denen die zu übertragende Datei an den Client übergeben wird. Diese Angabe wird mit dem ersten Segment an den Client zurückgegeben. Sie ist in EBICS verpflichtend. Anschließend ruft der Client jedes Folgesegment sequentiell nacheinander ab und legt die Datei bei sich an.

Bereits der Vorgang zum Zusammenstellen des ersten Segments mit der Gesamtanzahl auf dem EBICS-Server kann je nach Dateigröße und Auslieferungsart (z. B. ZIP-Archiv) längere Zeit beanspruchen. Es muss erst die vollständige Datei komprimiert und verschlüsselt erzeugt werden, damit in der ersten EBICS-Response die korrekte Anzahl an Segmenten an den EBICS-Client mitgeliefert werden kann. Bis der Client in der Initialisierungsphase eine Rückmeldung über die Segmentanzahl bekommt, kann es somit bei großen Datenmengen in der EBICS-Verbindung zu Timeout-Situationen und damit zu Abbrüchen kommen.

Hier liegt das Problem. Daher muss es zukünftig möglich sein, die EBICS-Response auf die EBICS-Initialisierungsanfrage zu beschleunigen.

Die Anzahl der Segmente, die mit dem ersten Segment an den Client zurückgegeben wird, muss heute für den Start der Übertragung nach Möglichkeit korrekt sein. Laut EBICS-Spezifikation 2.5 (siehe Abschnitt 7.2 Umsetzung in den EBICS-Nachrichten, Seite 159) sollte sich der EBICS-Client bei falscher Angabe der Segmentanzahl jedoch tolerant verhalten. In einem solchen Fall müsste der EBICS-Client die laufende Transaktion ordnungsgemäß mit der Quittungsphase fortsetzen, auch wenn der EBICS-Server weniger Segmente liefert, als er in der initialen EBICS-Response angegeben hat. Damit der EBICS-Server bei großen Dateien schneller zu einer Rückmeldung an den Client kommt und ein Timeout vermieden wird, sollte es möglich sein, eine geschätzte Segmentanzahl zu ermitteln und zurückzugeben.

Grundsätzlich wäre eine Erweiterung der EBICS-Spezifikation mit folgenden zwei Teillösungen wünschenswert.

Der EBICS-Client initiiert einen Download mit unbestimmter Größe zur Vermeidung von Timeouts bei großen Datenmengen

Der Bankrechner liefert in seiner Response zusammen mit dem ersten Segment eine Segmentanzahl der zu erwartenden Daten zurück. Wenn es sich um Daten mit der Möglichkeit einer schnellen Zusammenstellung handelt, kann der Bankrechner die Segmentanzahl wie bisher genau liefern. Handelt es sich jedoch um eine größere Datenmenge mit ggf. längerer Aufbereitungszeit (z. B. ZIP), darf auch eine ungefähre Segmentanzahl zurückgeliefert werden.
In jedem Fall muss sich der EBICS-Client so verhalten, dass er so lange Segmente abruft, bis er die Ende-Nachricht bekommt.

Um nun bei Abholungen Timeouts während der Sammel-/Aufbereitungsphase des EBICS-Bankrechners zu vermeiden, sollte der Bankrechner beim Abruf eines Folgesegments auch einen Wert zurückgeben dürfen, der aussagt, dass er mit der Datenzusammenstellung noch nicht fertig ist. Der EBICS-Client kann das gewünschte Segment wiederholt anfragen, bis er es bekommt.

Optionale Begrenzung der abzuholenden Datenmenge durch den EBICS-Client, um zu große Dateien zu vermeiden

Der Download von großen Datenmengen kann aber auch durch Bedingungen problematisch sein, die nicht im Einflussbereich des EBICS-Servers bzw. dessen Betreibers liegen. Ursachen können in der Systemauslegung des Clients oder in der Infrastruktur liegen. In solchen Fällen kann es u. U. helfen, wenn die abzurufende Datenmenge kundenseitig über die heutigen Möglichkeiten hinausgehend (historischer Abruf) weiter eingeschränkt werden kann.

Zum Beispiel wäre es wünschenswert, wenn der EBICS-Client einen Download unter Angabe einer maximalen Größe initiieren kann. Denkbar ist ein neuer optionaler Parameter für die Größe der Abholdaten. Beim Download liefert der EBICS-Bankrechner dann immer vollständige Datenblöcke (z. B. Kontoauszug) und davon mindestens einen. Die Größenbegrenzung sollte stets als Richtwert interpretiert werden, den der Bankrechner auch überschreiten darf. Damit gäbe es auch clientseitig neben der historischen Abholung eine weitere Möglichkeit, die Größe der Abholdaten selbst zu steuern.

Mit diesen beiden Erweiterungen ist EBICS auch zukünftig für die wachsenden Datenmengen gerüstet.

Michael Lembcke

Softwarehersteller und Finanzinstitut fördern EBICS in der Schweiz

Seit 2013 bieten Schweizer Grossbanken ihren Firmenkunden den Kommunikationsstandard EBICS an. Die Schweiz ist seit Mai 2015 offizielles Mitglied der EBICS-Gesellschaft, welche sich zum Ziel gesetzt hat, den Standard in ganz Europa und darüber hinaus zu verbreiten und zu unterhalten. Um EBICS definitiv zum Durchbruch zu verhelfen, bilden der führende EBICS-Hersteller und die Schweizer Grossbank Credit Suisse eine Arbeitsgemeinschaft zur Förderung von EBICS in der Schweiz (AFES). Schweizer Softwarehersteller profitieren von einer Aktion, welche ihnen den Einstieg in EBICS erleichtert.


Zahlungsaufträge aufgeben oder elektronische Kontoauszüge beziehen sind typische EBICS-Transaktionen. Insbesondere im Multibanking ist EBICS sehr beliebt, da Firmen mit nur einer Identifikation verschiedene Banken ansteuern können. In den letzten Jahren sind vermehrt auch mittelgrosse und kleinere Banken in der Schweiz auf den EBICS-Zug aufgesprungen, und die proprietären Schnittstellen verschwinden langsam aber sicher vom Markt. Kürzlich aufgedeckte Internet-Betrugsfälle bei Firmen beflügeln den Standard zusätzlich, denn der EBICS-Mechanismus der verteilten elektronischen Unterschrift (VEU) reduziert das Risiko einer Attacke deutlich.

Die Initiative AFES bietet interessierten Herstellern den bewährten EBICS Kernel von PPI – eine Software-Library, wahlweise in Java- oder C-Code – als Startpaket zu sehr günstigen Konditionen an. Sobald das Wartungsmodell und ein Onboarding-Paket (wahlweise mit Zugang zu einem EBICS-Testserver) vereinbart sind, kann es direkt losgehen. Credit Suisse übernimmt dabei die Rolle des Vermittlers und stellt seine Infrastruktur für Trainings zur Verfügung. So entsteht für alle Akteure eine Win-Situation, und der Finanzplatz Schweiz profitiert von der erwarteten Vereinheitlichung der Corporate-Banking-Schnittstellen.

Die Initiatoren erhoffen sich eine schnellere Verbreitung des Standards in der Schweiz. Dies kommt allen zu Gute, auch ausländischen Finanzinstituten in Europa, welche bereits EBICS als Schnittstelle anbieten. Die Erfahrung hat gezeigt, dass Standardisierung die Basis für mehr Wettbewerb ist und die Bankkunden letztendlich am meisten davon profitieren. Dies zeigen auch die aktuellen Diskussionen in Europa, wonach Banken zunehmend zu offenen Schnittstellen verpflichtet werden sollen. EBICS ist in diesem Zusammenhang sicher ein wichtiger Baustein, und sicher werden weitere Softwarehersteller und Banken gemeinsame Initiativen starten.

Mehr Informationen zur Initiative: www.ebics-initiative.ch.

Carsten Miehling

Instant Payments auf der Sibos

Dieses Jahr gastierte die Sibos in dem beschaulichen Genf. Der Flughafen lag direkt nebenan und man konnte die Flugzeuge mit voller Geschwindigkeit starten sehen. Und genauso hob auch Instant Payments ab. Es war eines der beherrschenden Themen auf der Sibos. Die Vorbereitungen für die Einführung laufen auf Hochtouren.


Instant Payments ist wahrscheinlich eine disruptive Technologie, die Volumina von anderen Zahlungsverkehrsmitteln abschöpfen wird. Dazu gehören der Massenzahlungsverkehr, der heute beispielsweise über EBICS läuft, aber auch Kartenzahlungen – Debitkarten- und Kreditkartenzahlungen am POS. Des Weiteren wird erwartet, dass vermehrt Zahlungen im Internet über Instant Payments abgewickelt werden. Ein Angriff auf PayPal und Co?

Was im ersten Moment harmlos aussieht, kann die Welt des Zahlungsverkehrs umkrempeln. „The New Normal“ wurde Instant Payments auf der Sibos genannt, obwohl es noch nicht einmal in Europa richtig abgehoben ist. Dies zeigt aber deutlich, was für ein Potenzial in Instant Payments vermutet wird. Die „neuen“ Player von gestern, wie z. B. PayPal und Co., könnten die Verlierer von morgen werden.

Die bisherigen Instant-Payments-Lösungen sind rein nationale Lösungen. Natürlich werden sich die wesentlichen Volumina im Zahlungsverkehr mit Instant Payments rund um den Kirchturm abspielen. Aber das muss nicht so bleiben. Mit einem Instant Payments, das europaweit funktioniert, könnten schnell neue Services entstehen. Dabei werden die Banken eine größere Rolle spielen als beim Bezahlen mit Kreditkarte oder über PayPal. Sie würden dabei ihren Anspruch, im Zahlungsverkehr führend zu sein, verteidigen und vielleicht sogar wieder Boden gutmachen können.

Die Grenzen von 15.000 € pro Instant-Payments-Transaktion werden schnell erhöht. Man munkelt von mittleren 6-stelligen Beträgen. Europäische Bankgruppen stehen in den Startlöchern, um dieses Limit innerhalb ihrer Gruppe von Beginn an aufzubrechen. Dies könnte auch für Firmenkunden interessant sein. Industriegüter, Dienstleistungen und Waren werden heute noch recht altmodisch bezahlt und damit teuer und langwierig. Mit Instant Payments könnte sich das ändern. Natürlich darf eine Zahlung per Instant Payments einige Sekunden länger oder sogar einige Minuten dauern, wenn beispielsweise der Betrag Millionen überschreitet und wenn Embargo-Prüfungen, AML und Settlement synchron ablaufen. Auch hier könnten sich wieder fundamentale, disruptive Änderungen ergeben.

Instant Payments ist übrigens nicht durch die PSD II initiiert. Was für eine vergebene Chance. Die EZB hat hier die Feder geführt und den Schritt hin zu einem europäischen Instant Payments nicht gewagt. Die Interoperabilität mit nationalen Instant-Payments-Lösungen ist derzeit noch unklar. Vielleicht schafft die PSD III, die schon in der PSD II angekündigt ist, den passenden rechtlichen Rahmen. Derzeit ist noch alles freiwillig und die Auswirkungen – auch auf den Massenzahlungsverkehr mit EBICS – sind noch nicht klar. Fest steht, dass die Europäisierung von Instant Payments Chancen bietet. Und die sollten wir nutzen.

Michael Lembcke