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

Schneller und einfacher - Automatisierungsfortschritt beim Einrichten von EBICS-Bankzugängen

Der Zahlungsverkehr mit EBICS verbreitet sich weiter in Europa. Zuletzt hat sich nun auch Österreich zum sicheren Standard für Firmenzahlungsverkehr bekannt. Doch höchste Sicherheit erfordert die Einhaltung des Standards und eine genaue Prüfung beim Einrichten der digitalen Geschäftsbeziehung. Bei der Erstinitialisierung der EBICS-Bankzugänge legen einige Schritte den Ablauf fest: Der EBICS-Client erzeugt bei der Initialisierung eines EBICS-Bankzugangs einen Teilnehmerbankschlüssel, der an den Bankrechner gesendet wird. Zusätzlich wird auf dem Postweg ein vom Teilnehmer unterschriebener Brief mit dem öffentlichen Bankschlüssel zur persönlichen Identifikation an die Bank gesendet und dort geprüft. Ist alles korrekt, gibt die Bank den eingerichteten Bankzugang frei und sendet dem Teilnehmer ein Begrüßungsschreiben, das einen recht langen Hashwert zum Abgleich enthält. Diesen Hashwert gibt der Anwender manuell in der Konfigurationsmaske des EBICS-Clients ein. 

Eine erfolgreiche Schlüsselfreigabe erfordert natürlich, dass der Hashwert fehlerfrei abgetippt wird. Der Papierbrief sichert zwar „getrennte Kanäle“ der Prozesse, wird jedoch von vielen Anwendern als sehr mühsam und zeitaufwändig empfunden. Und der finale Freischaltungsprozess durch die Bank kann einige Tage dauern, bis der Teilnehmer schließlich den EBICS-Bankzugang im EBICS-Client nutzen kann.

Kann man das nicht einfacher und schneller erledigen und den Anwender entlasten?
Banken, die webbasierte Firmenkundenanwendungen betreiben, können das Vertrauen, das ihnen entgegengebracht wird, nutzen. Sie können die ihnen bereits bekannten Hashwerte der unterschiedlichen EBICS-Banken zentral in ihrer Webanwendung speichern und damit für alle ihre Kunden nutzbar machen. Unbekannte oder falsch hinterlegte Hashwerte werden ignoriert und die Freischaltung des Teilnehmers bleibt, wie sie war. 

Die manuelle Eingabe der Hashwerte jeder EBICS-Bankverbindung durch den Anwender könnte damit entfallen. Sobald sich der Anwender an diesem Bankzugang initialisiert und von der Bank freigeschaltet ist, werden die Hashwerte der öffentlichen EBICS-Bankschlüssel automatisch abgeholt und mit den hinterlegten Werten im Hintergrund abgeglichen. Ist diese Prüfung erfolgreich, können die zugeordneten Auftragsarten des Teilnehmers automatisch per HTD abgeholt werden. Der Anwender kann nach Abholung der Auftragsarten den Bankzugang sofort nutzen. Das spart Zeit und schont die Nerven des Anwenders durch den Wegfall der Eingabe des bis zu 32 Zeichen langen Hashwerts.
All das wurde in TRAVIC-Port mit Version 4.6 der PPI AG realisiert und ist bei ersten Betreibern im Einsatz.
 

<!--[if gte mso 9]>

Seit Version 4.6 von TRAVIC-Port laufen die letzten Schritte im Initialisierungsprozess zum Hashwertabgleich bei Nutzung der Zusatzlizenz automatisiert ab.

Die Beschleunigung und Vereinfachung dieser Prozesse kommen bei den Anwendern gut an. Der initialisierte Bankzugang sichert den Firmenzahlungsverkehr nach wie vor mit allen Vorzügen des EBICS-Standards. Und für die Banken bedeutet dies einen weiteren Schritt in der Prozessbeschleunigung durch Automatisierung im Firmenzahlungsverkehr.

Autor: Christian Veith


EBICS als SaaS – EBICS in der Cloud

Ob bei Banken, Firmenkunden, Zahlungsdienstleistern oder Internetdienstanbietern: In all diesen Bereichen kommt heute in Europa EBICS zum Einsatz. Warum ist das so? Zum einen ist EBICS auf die im Firmenkundengeschäft üblichen Massenzahlungen ausgerichtet, zum anderen ist EBICS als eBanking-Standard in Europa etabliert. 

 

Ich benötige EBICS-Connectivity – muss ich EBICS selbst betreiben? 

All die EBICS-Markteilnehmer haben eines gemeinsam: Ihr Kerngeschäft liegt i.d.R. eben nicht primär im Betrieb und in der Abwicklung der EBICS-Kommunikation, sondern z. B. im Angebot und Verkauf der Bankprodukte, den Zahlungsverkehrsdienstleistungen und dem Internetgeschäft. Die Kommunikation muss funktionieren, und dabei will man sich auf einen Standard verlassen, um nicht mit jedem Partner eigene Verbindungslösungen aufbauen und unterhalten zu müssen.  
Damit man sich voll auf das Kerngeschäft konzentrieren kann, könnte es interessant sein, über das Konzept „Software as a Service“ für alle Leistungen rund um EBICS nachzudenken. So gibt es auch verschiedene Ansätze, EBICS-Services in der Cloud betreiben zu lassen. Servicenehmer könnten unter Umständen einiges an Kosten einsparen und so von einer höheren Flexibilität profitieren, da sich eine EBICS-Lösung schneller einführen lässt und zudem leichter erweitert oder reduziert werden kann.   
Gerade Banken mit einer kleineren Anzahl von potenziellen EBICS-Kunden scheuen die hohen Initialkosten, um einen EBICS-Bankrechner zu installieren und selbst zu betreiben. Lohnt sich dieser Aufwand und dessen Kosten für die anfänglich wenigen, vielleicht 50 – 100 Firmenkunden?

EBICS in der Cloud

Warum also den Service selbst betreiben? Weshalb nicht einen Dienstleister beauftragen, der das EBICS-Geschäft schon von Anfang an begleitet und damit in all seinen Facetten beherrscht?
Einen kompletten EBICS-Bankrechner als Service günstig einkaufen, das wäre es doch. Am besten dazu dann gleich auch das Web-basierte Firmenkundenportal, damit die Kunden schnell und ohne viel Aufwand in den Genuss des neuen Service kommen. Sowohl die Banken als auch die Firmenkunden können diese Services dann nutzen.

EBICS ist kein Service, bei dem es nur um einen entscheidenden Vorteil im Wettbewerb mit anderen Banken geht. Ein Angebot von EBICS und den entsprechenden Services des Zahlungsverkehrs gehört zum „Must-have“ einer Bank. Also warum sich nicht mit anderen die Initialkosten teilen und einen günstigeren Service in der Cloud nutzen?

EBICS in der Cloud: Vielleicht eine lohnende Handlungsoption. Oder?

Autor: Michael Lembcke

Neue Datenformate und die Notwendigkeit eines EBICS-Updates für die Schweiz – Was ist zu beachten?

Neue Datenformate und die Notwendigkeit eines EBICS-Updates für die Schweiz – Was ist zu beachten?
Mit der SIX-Publikation Swiss Market Practice Guidelines EBICS für EBICS V3.0 vom Juni 2020, die die Empfehlungen für die Umsetzung des EBICS-Standards für den Finanzplatz Schweiz enthält, zieht nun auch die Schweiz nach und passt den Standard an das europäisch harmonisierte Protokoll an. Haupttreiber der Harmonisierung waren die Mitglieder der EBICS-Gesellschaft, namentlich die Finanzplätze Deutschland, Frankreich und die Schweiz (neuestes Mitglied ist Österreich).

Per Definition werden auch in der Schweiz jeweils zwei Versionen von EBICS unterstützt, d. h. in Zukunft die Version 2.5 und die Version 3.0. Somit könnte man auf den ersten Blick meinen, dass seitens der Kunden und Softwarehersteller kein akuter Handlungsbedarf besteht, da die bisherige Version ja noch angeboten wird. Gäbe es in der Schweiz da nicht diesen Absatz 2.2.1 EBICS Timeline im SIX-Dokument mit folgendem Hinweis: „Für die Unterstützung der ISO 20022 Schema-Migration auf die Version 2019 ist die Verwendung von EBICS 3.0 erforderlich.“

Wie gut informierte Fachleute wissen, soll die ISO-Version 2019 ab 2022 auch in der Kunde-Bank-Schnittstelle eingeführt werden. Per 2024 sollen dann die aktuellen Versionen nicht mehr unterstützt werden. Dies entspricht dem Trend der globalen Migration auf diese neue Version, z. B. in den Vorhaben SEPA-, SWIFT MX- oder der TARGET2-Migration. Nicht zuletzt auch vor dem Hintergrund der geplanten Einführung von Instant Payments in der Schweiz per 2023 ist diese Migration von grosser Wichtigkeit.

Der Finanzplatz Schweiz hat sich also entschieden, den Upgrade der EBICS-Version mit dem Upgrade der ISO-Version zu verknüpfen. Für Kunden und Softwarehersteller ergeben sich vor diesem Hintergrund ein paar Fragen und auch nicht zu unterschätzende Herausforderungen. Die wichtigsten Punkte werden in den nachfolgenden Absätzen beleuchtet, und es werden – wo immer möglich – auch gleich Lösungsansätze aufgezeigt.

EBICS 3.0 spätestens ab November 2021 auch in der Schweiz 

Die EBICS-Kommunikation hat sich in der Schweiz mittlerweile voll etabliert und ist aus dem Finanzsektor nicht mehr wegzudenken. Bisher wird die EBICS-Version 2.5 von der Mehrheit der Finanzinstitute in der Schweiz angeboten.

Wie bereits eingangs erwähnt, wird mit den Empfehlungen für die Umsetzung des EBICS-Standards für den Finanzplatz Schweiz (Version 1.0 vom 01.06.2020 der SIX, www.six-group.com) die neuere EBICS-Version 3.0 in der Schweiz ab November 2021 offiziell für das Firmenkundengeschäft mit Finanzinstituten eingeführt.

Festlegungen der Schweiz für den Umgang mit den neuen Geschäftsvorfällen in EBICS

Mit der Einführung der neuen Version V3.0 soll die Vorgängerversion EBICS 2.5 dann noch bis Ende 2024 offiziell von Finanzinstituten unterstützt werden. Zudem wird für die Entgegennahme der neuen Schweizer ISO20022-Formate in der Version 2019 EBICS 3.0 vorausgesetzt. Dies bedeutet für Firmenkunden, dass jeder, der seine Schweizer ISO-Formate einmal aktualisiert hat, nicht mehr ohne Weiteres noch EBICS 2.5 dafür nutzen kann.

Es ist an der Zeit, zu planen

Diese anstehenden Aktualisierungen erfordern es, rechtzeitig eine Anpassung der Softwarelösungen einzuplanen und vorzunehmen. Hier sind die Finanzinstitute, Firmenkunden und Softwarehersteller gefragt.

Die Aktualisierung der ISO20022-Datenformate auf die Version 2019 ist da nur eine Sache. Nicht zu unterschätzen sind jedoch die Änderungen des EBICS-Protokolls, die mit der Version 3.0 umzusetzen sind. Die wichtigsten Anforderungen sind:

  • Das neue Business Transaction Format (BTF) löst die bisherigen Auftragsarten und Fileformat-Parameter ab.
  • Der Transport der öffentlichen Schlüssel erfolgt einheitlich jetzt mit Zertifikaten.
  • Die kryptografischen Verfahren sind verbessert.
  • Der Umgang mit Bankschlüsseln ist verbessert.
  • Es gibt zusätzliche Steuerungsparameter zur elektronischen Unterschrift.
  • Eine Prüfung auf Doppeleinreichung findet auf Dateiebene statt.

Wie also mit diesen neuen Anforderungen umgehen?

Nicht nur die Banken, auch die Softwarehersteller von EBICS-Clients, haben die Aufgabe, ihre Softwarelösungen um EBICS 3.0 zu erweitern, so dass die Firmenkunden frühzeitig Updates durchführen und produktiv setzen können.

Es müssen alle Besonderheiten von EBICS 3.0 im Client berücksichtigt sein, und u. U. muss ein Mischbetrieb von unterschiedlichen EBICS-Versionen je nach Bankzugang und EBICS-Usern möglich sein. Zudem sollten dem Anwender unterstützende Migrationsoptionen für die EBICS-Umstellung angeboten werden, die nach Möglichkeit eine erneute Initialisierung vermeiden (Stichwort Erhöhung von Minimal-Schlüssellängen).

Die EBICS-API – Entkopplung von Fachlichkeit und Technik

Aus eigener Erfahrung wissen wir, dass die Migration auf die Version 3.0 nicht einfach ein Mapping von Auftragsarten zu BTF-Kombinationen darstellt. Es gibt viele weitere Knackpunkte zu lösen, respektive neu zu programmieren. Insbesondere, wenn die Bank, der Softwarehersteller und der Kunde diese Migration möglichst automatisiert durchführen möchten. PPI bietet schon seit Jahren den TRAVIC-EBICS-Kernel, eine API-Lösung für die Integration in eigene EBICS-Clients, an. Dieser ist in Europa bei fast jeder zweiten EBICS-Client-Software der zentrale Baustein für die Abwicklung der EBICS-Kommunikation.

Mit der aktuellsten Version sind natürlich auch die neuen Spezifika rund um EBICS 3.0 bereits implementiert. Richtig angebunden, wickelt die API das eBanking für den Client transparent in all seinen Ausprägungen und Versionen ab. TRAVIC-EBICS-Kernel entlastet somit den Softwarehersteller von eBanking- und Zahlungsverkehrsanwendungen bei der Implementierung des Standardprotokolls und deren Syntax sowie bei Sicherheitsverfahren. Diese Lösung bildet die EBICS-Spezifikation vollständig ab und bietet eine einfach zu integrierende Schnittstelle, die Softwarehersteller als komfortablen und schnell nutzbaren Kommunikationsbaustein in ihre Softwareprodukte einbinden können.

Betrachtet man das Aufwand-/Ertragsverhältnis bei der Integration des TRAVIC-EBICS-Kernels, ist es nicht verwunderlich, dass dieses Produkt so ein Bestseller ist. Softwarehersteller, welche nicht den Kernel einsetzen, können sich jederzeit mit uns in Verbindung setzen und den Erhalt einer Testlizenz anfragen. Der Zeitpunkt dazu war noch nie so gut wie vor der bevorstehenden Umstellung auf EBICS 3.0.

Autoren: Carsten Miehling und Michael Lembcke

Mehr Informationen:
Webseite: EBICS 3.0 | challenge accepted

Flyer: EBICS 3.0 – Was ändert sich?

EBICS einrichten – einfach Schritt für Schritt

Als Standard bietet EBICS maximale Sicherheit für den reibungslosen europäischen Zahlungsverkehr. Dafür muss jedoch auch von allen Beteiligten etwas getan werden. Das Initialisieren und Einrichten von Bankzugängen, Teilnehmern und Rechten ist notwendig und erfordert aufmerksame Konfigurationsschritte. Das hohe Potenzial des Multibankings benötigt wiederholte Schritte, die normalerweise an den unterschiedlichen Stellen verteilt und dezentral ausgeführt werden. Komplexe, vernetzte Anwendungen auf lineare, einfache Abfolgen für den Nichttechniker zu reduzieren ist dabei die Kunst der Konzeption nutzerorientierter Software.
Dass sich dies auch komfortabel, einfach und schnell durchführen lässt, beweist der kompakte Einrichtungsassistent, den PPI für sein Firmenkundenportal TRAVIC-Port entwickelt hat. Die Zielgruppe ist hier der Administrator auf Kundenseite - denn Self-Service ist Trumpf in modernen Kunde-Bank-Beziehungen. Den direkten Zugriff auf essenzielle Administrationsvorgänge zu erlauben, schafft schnelle Prozesse ohne Umwege über den Anbieter.

Zugegeben: Wer einen neuen EBICS-Benutzer anlegen möchte, muss ziemlich häufig klicken, aber eben Schritt für Schritt zielgerichtet geführt. Das gilt auch für die PPI-Produktwelt, namentlich TRAVIC-Port. Das System benötigt von jedem einzelnen Benutzer eine Kennung, die Stammdaten sowie das Startpasswort und ein für die spätere Anmeldung verwendetes Sicherheitsmedium. Jeder Benutzer nimmt zudem verschiedene Rollen ein, verfügt über unterschiedliche Berechtigungen und häufig mehr als eine Bankverbindung. Da TRAVIC-Port multibankenfähig ist, müssen auch die jeweiligen Bankzugänge angelegt werden. Häufig übernimmt auch die Hauptbank für ihre EBICS-Firmenkunden diese Aufgabe – und das bedeutet meist lange Telefonate, in denen der Bankmitarbeiter all diese Informationen abfragt.

Der Anwender des Portals findet einen neuen Eintrag direkt auf der Startseite (vgl. Abb. 1) Über diesen Link springt er direkt in den Einrichtungsassistenten und macht sich den Einstieg in die sichere EBICS-Welt deutlich einfacher. Über Dialoge fragt ein Assistent alle nötigen Daten ab, um einen neuen EBICS-Benutzer anzulegen.




Der Assistent sorgt auch dafür, dass die Daten jeweils an den richtigen Stellen eingetragen werden. Das ist deshalb besonders komfortabel, weil das System etwa die Abholautomaten über einen anderen Menüpunkt einrichtet als Bankzugänge und Benutzer. Was logisch Sinn ergibt, erfordert jedoch das Wechseln in vielen Reitern und Menüpunkten und damit insgesamt mehr Zeit. Dialoge im Einrichtungsassistenten verhindern, dass wichtige Daten fehlen und ermöglichen so, auch auf einen Blick zu erkennen, welche Informationen überhaupt erforderlich sind. Zuerst gilt es beispielsweise, einen neuen Bankzugang einzurichten – ob das die Bank oder ein Administrator auf Kundenseite macht, ist übrigens egal. Der Dialog fragt alle zugehörigen Informationen ab und zeigt an, wie viel Arbeit noch vor einem liegt. Bei einem neuen Bankzugang kommen immerhin sieben Dialoge zusammen (vgl. Abb. 2).

Sind alle Bankzugänge eingerichtet, folgen üblicherweise die einzelnen Benutzer. Eine kleine Kanzlei möchte etwa für die Inhaberin, zwei angestellte Anwälte und eine Assistentin Kontoberechtigungen einrichten – und zwar individuell verschiedene. Die Chefin möchte natürlich über alle Rechte verfügen, Transaktionen ohne Limit beauftragen und freigeben können und etwa über eine verteilte elektronische Unterschrift für ihre Kollegen Freigaben erteilen. Die beiden angestellten Anwälte dürfen dagegen nur Transaktionen bis zu einer gewissen Höhe alleine freigeben – und die Assistentin darf zwar Zahlungen erfassen, aber nicht freigeben. Alle vier wiederum sollen die Kontoauszüge sehen können, die vom EBICS-Bankrechner abgeholt werden. All das erleichtert ein Dialog, der neue Kollegen für einen bereits erstellten Firmenkunden anlegen kann (vgl. Abb. 3).



Der Start und das Arbeiten mit EBICS im Zahlungsverkehr lässt sich also sehr gut vereinfachen, ohne auf Sicherheit und die Einhaltung von Standards zu verzichten. Der Einrichtungsassistent ist in der Praxis erprobt und bei namhaften Großkunden im Einsatz. Wenn Sie mehr über dieses Feature in TRAVIC-Port wissen möchten, sprechen Sie uns gern an. Wir machen EBICS gemeinsam einfacher.

Autor: Christian Veith

Weniger Stress durch einen „EBICS-Self-Service“?


In meinem letzten EBICS-Blog habe ich über die Schmerzen geschrieben, die EBICS-Neukunden bei der Initialisierung haben (und wie man sie lindern könnte). Es kommt erschwerend hinzu, dass Neukunden diesen Schmerz nicht nur ein Mal haben – das gleiche Prozedere wird für jeden einzelnen Teilnehmer von EBICS wiederholt.

Muss das sein? Wie wäre es, wenn man dem ersten angemeldeten EBICS-Nutzer, sozusagen dem User 0, das Recht einräumt, weitere Teilnehmer anzulegen – und sie dabei auch gleich zu authentifizieren? Wie würde so etwas aussehen?

Stellen wir uns also eine neue administrative EBICS-Auftragsart vor, der wir z. B. mal den Namen HUC (EBICS User Create) geben. HUC wäre ein Upload, die enthaltene EBICS-Nachricht würde die notwendigen Stammdaten des neuen EBICS-Nutzers sowie seine drei Zertifikate enthalten. Unterschrieben wird die Nachricht vom User 0. Mit den Daten und der Unterschrift kann der EBICS-Server den Teilnehmer unmittelbar einrichten, es entfallen INI- und HIA-Auftrag, Briefe und Wartezeiten. Wir bekommen ohne jeden Initialisierungsschmerz einen weiteren gebrauchsfertigen Teilnehmer. Indizien für ein kundenseitiges Bedürfnis nach einem solchen „EBICS-Self-Service“ sind vorhanden: Immerhin gibt es mit EBAM Bemühungen, einen ganz ähnlichen Dienst für Konten voranzubringen.

Wenn es so einfach wäre, hätte man das doch vermutlich schon längst gemacht. Zwei Fragen springen einem förmlich ins Gesicht:

1. Wie kontrolliere ich einen so mächtigen EBICS-Teilnehmer wie den User 0?

2. Was sind eigentlich die notwendigen Stammdaten?

Die erste Frage ist überraschend einfach zu beantworten: Denn wenn EBICS in einer Sache wirklich gut ist, dann im Prüfen von Berechtigungen. Um einen übermächtigen User 0 zu verhindern, richtet man ganz am Anfang dann doch noch einen User 1 ein, und legt fest, dass ein HUC-Auftrag mehrere Unterschriften benötigt. Und schon hat man ein Vier-Augen-Prinzip und kann durch die bekannten Mechanismen der E-, A- und B-Unterschriften sehr feingranular konfigurieren, wer mit wem zusammen weitere Mitarbeiter einrichten darf.

Die weitaus schwierige Frage ist: Was sind die notwendigen Stammdaten? Die meisten werden sich darauf einigen können, dass ein Name wohl notwendig ist, aber dann wird es schon schwierig. Will ich Adresse, Telefonnummer und die E-Mail des Benutzers wissen? Brauche ich die womöglich sogar zwingend? Oder möchte ich mich aufgrund der DSGVO lieber gar nicht mit unnötigen persönlichen Daten belasten? Bislang kann das jede Bank für sich entscheiden, aber HUC würde da einen Standard für alle setzen. Und niemandem ist damit geholfen, wenn ein Standard im Wesentlichen aus einer Unmenge an optionalen Feldern besteht. Hier wären die Banken gefordert, sich auf einen sinnvollen Satz an Daten verbindlich zu einigen.

Wie schwer das sein kann, kann man in EBICS selber sehen – an den Auftragsarten HKD und HDT. Dafür gedacht, dass ein Kundensystem sich bei der Bank Informationen zum Kunden, seinen Teilnehmern und deren Berechtigungen abholen kann, führen diese beiden Auftragsarten ein Schattendasein, weil es nicht möglich war, die historisch gewachsen Berechtigungsmodelle der verschiedenen Banken unter einen Hut zu bringen. Viele Banken verstehen sogar ganz im Gegenteil ihre besonderen Freiheitsgrade bei der Rechtevergabe als ein Alleinstellungsmerkmal. Das verträgt sich nicht mit einer Standardisierung.

Darum scheint es auch so, als wären die uneinheitlichen Rechtemodelle der vorzeitige und sichere Tod eines EBCIS-Self-Service. Es scheint aber eben nur so. In Wirklichkeit braucht die Bank die vielen Möglichkeiten der Rechtevergabe, um allen ihren Kunden gerecht zu werden, der einzelne Kunde braucht sie eher nicht, oder zumindest nicht alle gleichzeitig: Wie viele Rollen gibt es schon bei einem typischen Firmenkunden? Da gibt es diejenigen, die Aufträge einreichen, aber nicht autorisieren dürfen, diejenigen mit beschränkter oder umfangreicher Zeichnungsvollmacht für dieses oder jenes Konto und dann noch die, die neue Teilnehmer einrichten dürfen. In Summe etwa eine Handvoll Rollen, die man beim Aufsetzen der EBICS-Vereinbarung gleich mit anlegt und bei denen man sich mit dem kompletten Arsenal der Berechtigungskonfiguration der Bank austoben kann. Die Rolle bekommt dann einen Namen, mit der der Kunde etwas anfangen kann (z. B. Prokurist) und die er dann in seinem HUC-Request für den neuen Prokuristen einfach angeben kann.

So ein Rollenmodell hat noch mehr Vorteile. Man kann die Rolle den neuen Gegebenheiten der Firma (ein Konto ist dazugekommen) anpassen, ohne die Berechtigungen aller Teilnehmer anschauen zu müssen. Man kann die Rollen auch neu verteilen. Und man bekommt leichter einen Überblick, wer eigentlich welche Rolle und damit welche Berechtigung hat.

Während die Definition der Rollen zwangsläufig Handarbeit bleiben wird, kann die Zuordnung der Rollen im EBICS-Self-Service erfolgen. Für den fehlt neben der Neuanlange dann noch die Möglichkeit zum Lesen, Ändern und Löschen des Teilnehmers, also das R, das U und das D aus CRUD. Die zugehörigen Auftragsarten könnte man dann ja HUR, HUU und HUD nennen. Dann hätte man einen schönen ersten Wurf für den EBICS-Self-Service.

Und der Initialisierungsschmerz löst sich fast vollständig in Luft auf.


Autor: Curd Reinert

EBICS: Aller Anfang ist schwer

Es liegt in der Natur der Sache, dass der erste Kontakt, den Neukunden mit EBICS haben, in der Regel die Initialisierung ist. Das ist etwas unglücklich, denn damit werden sie gleich zu Anfang ihrer EBICS-Erfahrung mit dem wahrscheinlich umständlichsten und am wenigsten intuitiven Teil konfrontiert. Und wenn Neukunden erfolgreich mit ihrer eigenen Netzwerktechnik, Proxies, Firewalls und dem TLS gekämpft haben, die Daten aus dem BPD-Blatt brav und richtig in die Anwendung übernommen haben, diese sie hoffentlich möglichst einfach und intuitiv durch das Versenden der zwei Initialisierungsnachrichten geleitet hat, dann werden sie überrascht feststellen, dass sie keineswegs jetzt endlich EBICS nutzen können. Stattdessen müssen sie erstmal einen mehrseitigen INI-Brief ausdrucken, unterschreiben und an ihre Bank schicken. Und warten. Warten, bis der Brief angekommen ist, und ein Bankmitarbeiter die 192 Hexziffern der Hashwerte der drei EBICS-Schlüssel in den Bankrechner eingegeben hat. Womöglich noch nach dem Vier-Augen-Prinzip.

Ist das passiert – und es gibt in der Regel keinen Hinweis, ob und wann das passiert sein könnte – dann können die Neukunden endlich mit EBICS starten. Fast. Vorher müssen sie erst noch die Bankschlüssel abgeholt und deren Hashwerte bestätigt haben, die sie mit denen auf dem BPD-Blatt hoffentlich sorgfältig vergleichen.

Nach dem Trauma der Erstinitialisierung ist der Rest nahezu ein Spaziergang. Die eigenen Schlüssel erneuern sich in vielen Anwendungen auf Knopfdruck. Neue Bankschlüssel können mittlerweile mit den alten unterschrieben und automatsch akzeptiert werden. Richtig unangenehm wird es nur, wenn man – aus welchen Gründen auch immer – gezwungen wird, sich vollständig neu zu initialisieren.

Frankreich, du hast es (ein bisschen) besser

Französische EBICS-Kunden, die diesen Blog lesen, werden sich vielleicht verwundert fragen, wovon ich hier eigentlich schreibe. Netzwerk und TLS sind in Frankreich zwar auch nicht einfacher zu handhaben als anderswo, und das BPD-Blatt muss auch abgetippt werden, aber zumindest der eigentliche EBICS-Schlüsselaustausch ist dank CA-basierter Zertifikate so einfach wie man es sich nur wünschen kann: Der Teilnehmer sendet seine Schlüssel als Zertifikate, die die Bank aufgrund der Unterschrift der ausstellenden Certificate Authority direkt validieren und freigeben kann. Der EBICS-Client kann darum unmittelbar anschließend die Bankschlüssel als Zertifikate abholen. Und wenn diese Zertifikate auch von einer CA ausgestellt wurden und der Client dieser CA vertraut, dann steht der Aufnahme einer EBICS-Kommunikation nichts mehr im Weg.

Diese scheinbare Mühelosigkeit täuscht natürlich ein wenig, denn die Zertifikate fallen ja auch nicht vom Himmel. Der Zertifizierungsprozess ist nicht wirklich simpler als die EBICS-Initialisierung, denn auch hier müssen eine Person und ihre digitale Identität sicher zusammengebracht werden. Der Vorteil ist vor allem, dass der Prozess nicht als Teil von EBICS angesehen und darum nicht dem Protokoll angelastet wird. Und man kann natürlich ein Zertifikat für viele Zwecke benutzen – die EBICS-Initialisierung dagegen gilt immer nur für diesen einen Teilnehmer bei dieser einen Bank.

Das Zertifikate noch andere Probleme mit sich bringen, wie regelmäßige Kosten bei der Erneuerung, das Problem, sich möglichst global auf eine Liste vertrauenswürdiger CAs zu einigen, und interessante Ausfallszenarien, wenn es nur einen allgemein anerkannten Anbieter für die Onlineprüfung von Zertifikaten gibt, will ich hier nur am Rande erwähnen.

Es bleibt also schmerzhaft, aber wir sind der Meinung, dass das nicht so bleiben muss. Uns sind in einem Brainstorming zwei Ideen gekommen, die wir hier vorstellen wollen – auch auf die Gefahr hin, dass sie sich als völlig praxisfern erweisen.

Option 1: Von Angesicht zu Angesicht

Unsere erste Idee geht davon aus, dass der zukünftige EBICS-Nutzer bei seinem Bankberater sitzt, um sich von diesem für EBICS freischalten zu lassen. Während also der Bankberater die notwendigen Daten wie Name und Adresse, Kunden- und Teilnehmer-ID in das System einpflegt, reicht er an einer Stelle seine Tastatur an den Teilnehmer, der ein frei gewähltes Einmalpasswort eintippt – wie üblich zwei Mal, um Vertipper auszuschließen. Das Passwort muss der Teilnehmer sich merken, bis er sich an seinem EBICS-Client anmeldet, und dann bei der Einrichtung des Bankzugangs wieder eingeben. Mit Hilfe des Passworts wird dann ein symmetrischer Schlüssel generiert, mit dem die Initialisierungsnachricht – die alle drei EBICS-Schlüssel enthält – verschlüsselt wird. Da der Bankrechner das Passwort kennt, kann er denselben symmetrischen Schlüssel generieren, und die Kommunikation ist gegen Abhören, Manipulation und sogar Man-in-the-Middle-Attacken gesichert. Deswegen kann der Server auch direkt in der Antwort die Bankschlüssel zurückgeben. Das Initialisierungspasswort wird nicht weiter benötigt (und darf auch nicht für spätere Wiederinitialisierungen wiederverwendet werden).

Das Ergebnis: eine einzige EBICS-Nachricht, nach der der Teilnehmer vollständig initialisiert und bereit für EBICS ist. Auf der Bankseite entfallen nach der Einrichtung die manuellen Schritte, der Kunde muss keinen Brief schicken und – vor allem – nicht warten!

Zwei mögliche Probleme fallen uns dabei ein:

  1. Ein Angreifer, der sowohl die Bank als auch den Teilnehmer gut genug kennt, könnte Kunden-ID und Teilnehmer-ID sowie das Passwort, das der Kunde sich ausgedacht hat, erraten und sich selber vor dem legitimen Teilnehmer anmelden. Dagegen kann z. B. eine PIN, die bei der Einrichtung des Teilnehmers generiert wird und diesem mitgegeben wird, sowie eine Sperre nach n Fehlversuchen schützen.
  2. Die Fehler, die der Server zurückmeldet, wenn jemand den Schlüssel wild rät, könnten Orakelattacken ermöglichen. Auch hier sollte es helfen, wenn nach n Fehlversuchen der Teilnehmer komplett gesperrt wird.

Das ließe sich also lösen.

Option 2: Total digital

Die Option 1 ist ja noch ein bisschen im Bisherigen verhaftet: Der Kunde bekommt ein Blatt Papier, die Daten daraus tippt er in seine Anwendung … Warum eigentlich? Warum nicht dem Kunden stattdessen die Daten digital geben? Z.B. als USB-Stick, der vom Bankberater direkt bespielt und dem Kunden überreicht wird, der ihn anschließend gerne behalten darf, natürlich mit Werbeaufdruck der Bank. Auf dem USB-Stick wäre dann eine Datei, die alles das enthält, was man für die Einrichtung braucht:

  • die URL
  • die IDs
  • einen symmetrischen Schlüssel, mit dem ich analog zur Option 1 die initiale Kommunikation absichere

Hier muss natürlich keine Rücksicht darauf genommen werden, was ein Mensch sich merken kann oder abtippen will, der Schlüssel kann beliebig lang gewählt werden. Der Angriff über das Erraten des Schlüssels fällt damit weg. Das größte Risiko ist noch, dass der Kunde den USB-Stick auf dem Weg nach Hause verliert. Aber dagegen kann auch wieder eine Passwortsicherung der Datei helfen.

Wenn er aber heile mit dem Stick zu Hause ankommt, importiert er die Datei in seine EBICS-Anwendung. Diese erkennt das Format und kann damit sofort und autonom den kompletten Bankzugang einrichten – wie bei Option 1 beschrieben.

Wenn mein System jetzt keinen USB-Eingang hat? Dann ist es entweder ein Smartphone, auf dem ich mich z. B. für eine Signatur-App anmelden will. In dem Fall kann es zwar vielleicht nicht so viel mit USB, aber jede Menge mit QR-Codes anfangen. Also gibt man ihm die Daten eben auf diesem Weg. Vielleicht ist es aber auch Firmenpolitik, dass keine USB-Sticks verwendet werden dürfen, nicht einmal aus so einer vertrauenswürdigen Quelle wie meiner Bank. Dann könnte man natürlich auf den Gedanken kommen, sich die Datei einfach per Mail zuzusenden. Und wenn man den Gedanken erst mal hatte, fragt man sich, ob es denn überhaupt einen USB-Stick braucht. Und die Antwort ist vermutlich nein, wenn (a) die Datei mit einem ausreichend guten Passwort kryptographisch einwandfrei gesichert wird und (b) das Passwort nicht in derselben Mail steht, sondern auf einem anderen, sicheren Weg übermittelt wird. Das sollte zu schaffen sein.

Der Weg zum Ziel

Die Initialisierung lässt sich vereinfachen. Damit diese Vereinfachung aber was nützt, reicht es nicht, wenn nur eine Bank sie umsetzt oder – noch absurder – nur ein Kundensystem(-hersteller). Nur wenn so eine Änderung Teil der EBICS-Spezifikation wird, kann sie den Kunden und den Banken das Leben erleichtern. Dann aber ganz erheblich: Für den Kunden wird das Einrichten eines Bankzugangs vom Ärgernis zu einer Nebensächlichkeit, und die Banken können sich das Abtippen von Hashwerten sparen. Man hat ja schon von Büros in Callcentern gehört, in denen die Mitarbeiter nichts anderes machen.

Wenn die Initialisierung so sehr vereinfacht wird, ist es vielleicht auch gar kein Problem mehr, dass sie ja für jeden EBICS-Teilnehmer einzeln durchgeführt werden muss. Aber auch hier haben wir uns Gedanken zur Vereinfachung gemacht, die ich in einem späteren Blog-Post vorstellen möchte.


Autor: Curd Reinert

PSD2: Sammlerzahlungen via EBICS absichern

Sammlerzahlungen abzusichern, war schon immer ein Thema. Die frühen Versuche, dafür einen einfachen Schutz vor Manipulation zu etablieren, waren eher halbherzig und haben deshalb auch nie zu einer verlässlichen Absicherung geführt. Beispielsweise wurde zunächst die Summe aller Empfänger-Kontonummern gebildet, um zu verhindern, dass Kriminelle nachträglich die Zahlungen verändern. Als dann die IBAN kam, war es aber selbst mit dieser äußerst simplen Methode vorbei – allein wegen der mathematischen Herausforderungen haben die Banken schließlich ganz darauf verzichtet.

Übrig geblieben sind bis heute allein die Anzahl der enthaltenen Zahlungen und die Gesamtsumme. Dass solche Werte einen wirksamen Schutz darstellen, behauptet erst gar keiner.

Vielversprechender war schon eher, über PSD2 und RTS für mehr Sicherheit bei Zahlungen zu sorgen. Doch für die gerade bei Firmenkunden geläufigen Sammelzahlungen war das noch nicht der Durchbruch. Der Grund: Empfänger, Konto und Betrag anzuzeigen und den Auftraggeber etwa via Dynamic Linking mit allen enthaltenen Daten prüfen zu lassen, ist bei Gehaltszahlungen in einem Unternehmen mit mehr als 10.000 Mitarbeiten kaum sinnvoll zu bewerkstelligen. Allein organisatorisch ist dies schon ein Ding der Unmöglichkeit und technisch kaum auf den etablierten Kanälen zu lösen.

Also wie nun sicherstellen, dass die einmal erzeugte Zahlungsdatei auch unverändert bei der Bank zur Ausführung angekommen ist?

EBICS!

EBICS ist im europäischen Firmenkundenzahlungsverkehr seit Jahren Standard – verfügbar in allen großen Ländern mit hohen ZV-Transaktionszahlen, wie Deutschland, Frankreich Österreich und der Schweiz. Weitere Länder werden folgen.

Also warum definiert die EBICS-Gesellschaft nicht einen allgemeinen und verpflichtenden Prüfstandard, der auf internationalen Hashwertverfahren (z. B. SHA-256) basiert und legt das Regelwerk dazu fest? Das Prinzip: Alle Anwendungen, die ZV-Sammlerdateien erzeugen, generieren dabei auch immer gleich den dazu passenden Hashwert und geben diesen zusammen mit der Zahlungsdatei an die Bank. Dort lässt sich dieser Kontrollwert erneut berechnen, sobald die ZV-Datei ankommt, und dem Kunden vor Freigabe zur Prüfung vorlegen. Fertig.

Einfach und sehr effektiv, weil der identische Hashwert garantiert, dass zwischen der Erstellung der Sammlerdatei und vor der Verarbeitung des Sammlers bei der Bank keine Manipulation stattgefunden hat.

Wenn wir bei der Definition des zu nutzenden Hashwertverfahrens seitens der EBICS-Gesellschaft dann auch noch an den armen Endkunden denken, könnte man statt des 32-Doppelwert-Vergleichs einen Algorithmus finden, der aus dem Hashwert eine Nummer mit 8-10 Stellen – ähnlich einer TAN – macht. Mit diesen Werten können die Kunden und Nutzer heute bereits umgehen. Kontrollwerte zu vergleichen, kostet dabei nur minimal mehr Zeit und ist einfach zu machen.

Diese Definition einfach dem Markt zu überlassen, ist übrigens keine gute Idee. Wenn jeder beteiligte Akteur sein eigenes Süppchen kocht, entsteht eine Vielzahl unterschiedlicher Verfahren, die Kunden eher verwirren als für zusätzliche Sicherheit zu sorgen.

Deshalb gehört es zu den Aufgaben der EBICS Gesellschaft, an dieser Stelle für eine verbindliche Lösung zu sorgen und dadurch endlich auch der PSD2 bei Sammlerzahlungen zu genügen.

Autor: Michael Schunk

eBAM – Baustein der Digitalisierung

Krisen sind auch ein Katalysator des Fortschritts. Die aktuelle Corona-Krise ist wohl sicherlich deshalb anders als viele davor, weil sie ins Digitale zwingt – von Homeschooling bis Homeoffice werden viele Aktivitäten jetzt mit Hochdruck in vielen Aspekten neu gedacht. Da werden Lücken offenbar, die in einer analogen Welt ohne Kontaktsperren und andere Restriktionen nicht so wahrgenommen werden. Antragsprozesse, Autorisierungen und Freigaben sind ein Teil davon.

Und wenn wir hier im Blog über Cash-Management-Lösungen sprechen, dann gehört für mich das Thema „Kontoverwaltung“ (Bank Account Management) auch dazu. Darunter sind nicht nur der Austausch von Nachrichten an der Kunde-Bank-Schnittstelle zu verstehen, sondern es geht von der Verwaltung von Bank- und Kontostammdaten und deren Zeichnungsberechtigungen (nicht nur die digitalen) sowie alle zugehörigen Dokumente über die Prozesse im gesamten Kontolebenszyklus bis hin zur leidigen Saldenbestätigung. Da spielen alle Anforderungen im Bereich KYC sowie Autorisierungen und digitale Identitäten hinein.

Das Thema könnte schon lange in Richtung eBAM – also Electronic Bank Account Management – in die digitale Welt überführt worden sein. Standardisierung tut hier not – das beginnt schon in der Schreibweise. EBAM oder eBAM oder e-BAM?

Die Zeit ist reif – viele Bausteine sind vorhanden. Einige Hersteller im Bereich Cash Management beziehungsweise Treasury bieten Module insbesondere für die Verwaltung der Daten auf der Firmenkundenseite an. Es gibt schon Erfolgsmeldungen für erste rein digitale Kontoeröffnungsprozesse. Auch zu KYC und dem Bereich der digitalen Identitäten gibt es erfreuliche Entwicklungen. Sogar die Nachrichten an der Kunde-Bank-Schnittstelle in XML nach dem Standard ISO 20022 sind im Prinzip vorhanden. Eine Arbeitsgruppe der CGI-MP (common global implementation – market practice) – eine globale Initiative von Corporates, Banken und Herstellern zur Harmonisierung der Nutzung von ISO 20022 an der Kunde-Bank-Schnittstelle diskutiert die Weiterentwicklung des Standards. Und Standards sind die Grundlage für die Digitalisierung. Das schafft Sicherheit bei Herstellern und Nutzern.

In Deutschland haben wir die lange Tradition des Standards Multi-Banking in der Anlage 3 zum DFÜ-Abkommen gepflegt – Multi-Banking im Sinne von „in einem Standard viele Banken erreichen“. Inzwischen sind hier beispielsweise mit dem Thema Bankentgeltnachrichten (BSB – bank service billing) auch optionale Themen möglich, also nicht jeder muss das Thema unterstützen – aber wenn, dann bitte im Standard. Und für so eine Option zum Thema eBAM möchte ich plädieren. Für EBICS ist es ein Leichtes, die XML-Nachrichten in der Nachrichtengruppe camt (account management) zu transportieren - es müssen halt die (harmonisierten) Standards vereinbart werden. Und mit dem einfachen Use Case der Übersicht von Zeichnungsberechtigungen ist in EBICS mit der Auftragsart HKD schon mal ein Anfang gemacht, aber – siehe oben – eben nicht vollständig.

Natürlich muss der Anteil Kunde-Bank-Kommunikation von eBAM nicht über EBICS realisiert werden, auch SWIFT als Transportweg ist möglich. Selbst APIs eröffnen viele Möglichkeiten. Die Grundlage sollte unabhängig vom Kanal eine Standardisierung der Inhalte (XML im Gleichklang zu json) und der Basisprozesse sein. Und für die Inhalte im Format XML nach ISO 20022 sollte ein weiteres Kapitel in der Anlage 3 zum DFÜ-Abkommen zu schaffen sein.

Auf dieser Grundlage können dann die oben genannten Hersteller ihre Produkte im Sinne „Multi-Banking“ erweitern und Banken neue Services für viele Kunden mit gleichartigen Systemen anbieten, und diese Services passen sehr gut in eine digitale Welt.


Autor: Dr. Mario Reichel

EBICS-Security – Wann ist es Zeit für das Update Ihres Kundensystems?

Mit EBICS sind verschiedene Sicherheitsfunktionen und -vorgaben spezifiziert, die von Kunden und Banken einzuhalten sind. Die Bank muss stets darauf achten, dass die aktuellen Vorgaben in ihrem EBICS-Bankrechner angeboten und unterstützt werden. Aber auch der EBICS-Kunde und der einzelne EBICS-Teilnehmer selbst sind dafür verantwortlich, stets Kundensoftware einzusetzen, die den aktuellen EBICS-Sicherheitsstandards entspricht. Daher sind nicht nur aufgrund von funktionalen Anpassungen, sondern auch aus Sicherheitsgründen regelmäßige Softwareupdates der EBICS-Clientsysteme unerlässlich.

Ist eine bestehende EBICS-Clientsoftware schließlich durch Updates auf den neuesten Stand gebracht, heißt das jedoch nicht, dass diese EBICS-Software dann auch automatisch über die aktuellste EBICS-Version und das neueste Sicherheitsverfahren mit der Bank kommuniziert. Je nach zuvor genutzter EBICS-Version und Clientfunktionalität müssen dazu erst noch die verschiedenen Applikationsschlüssel für Verschlüsselung (E002), Authentifikation (X002) und Autorisierung (A004, A005 oder A006) sowie die neu zu nutzende EBICS-Version aktualisiert und mit dem oder den EBICS-Bankrechnern ausgetauscht werden. Zudem könnte es erforderlich sein, die Internetverschlüsselung (TLS) durch einen neuen Zertifikatsaustausch auf eine neuere und sichere Version zu aktualisieren. Diese Art von Aktualisierungen erfordern i.d.R. aktives Handeln und manuelle Eingriffe des EBICS-Teilnehmers.

Warum sind diese Aktualisierungen wichtig?

Für die EBICS-Kommunikation über das Internet sind eigene Sicherheitsverfahren spezifiziert. Diese werden von der EBICS-Gesellschaft im Laufe der Zeit mit neuen EBICS-Versionen immer wieder aktualisiert und an die aktuellen Sicherheitsbedürfnisse angepasst. Ein Beispiel stellen die Schlüssellängen dar. So sind für die Verschlüsselung (E002), Authentifikation (X002) und Autorisierung (A004, A005 oder A006) in älteren EBICS-Versionen noch Schlüssellängen von 1.024 Bit zulässig. Diese Länge entspricht nicht mehr den aktuellen Sicherheitsanforderungen, denn zu kurze Schlüssel gelten als unsicher. Neuere EBICS-Versionen hingegen lassen derzeit nur Schlüssel mit einer Mindestlänge von 2.048 Bit zu. Ein anderes Beispiel sehen wir bei den genutzten Verfahren und Versionen der TLS-Verschlüsselung. Um Sicherheitsempfehlungen, wie z. B. den Empfehlungen des BSI in Deutschland flexibler folgen zu können, hat die EBICS-Gesellschaft für EBICS 3.0 die entsprechenden Vorgaben in einem eigenen Anhang Transport Layer Security zur Spezifikation ausgelagert. Da rückwirkend die Spezifikation zu EBICS 2.5 nicht angepasst werden konnte, hat die DK (Die Deutsche Kreditwirtschaft) 2019 unter dem Titel Empfehlungen zu EBICS-Sicherheitsverfahren und Schlüssellängen zudem ein eigenes Empfehlungsschreiben zu den in EBICS zu nutzenden Sicherheitsverfahren herausgegeben. Siehe hierzu auch www.ebics.de und www.ebics.org.

Um den EBICS-Teilnehmern einen weichen Umstieg auf neuere EBICS-Versionen und Sicherheitsstandards zu ermöglichen, bieten die meisten Banken ihren Kunden jedoch parallel noch die älteren Verfahren an. Leider lässt sich feststellen, dass von Kunden dann aber die Gelegenheit zur EBICS-Aktualisierung in vielen Fällen nicht genutzt wird. Viele verharren auf älteren Systemen und Verfahren. Damit fällt es dann wiederum den Banken, schwer die alten Verfahren abzuschalten.
Am Ende erwartet jeder Beteiligte in der EBICS-Kommunikation, dass ein sicherer Datenaustausch gegeben ist. Einen Schaden möchte niemand erleiden. Also sollte auch jeder dafür Sorge tragen, dass er seinen Teil dazu beträgt. Natürlich ist die EBICS-Sicherheit nicht das Einzige, was Banken und Firmenkunden im Auge halten müssen. Letztendlich müssen heutzutage alle Beteiligten in ihrer Infrastruktur und ihren Softwarelösungen alle erdenklichen Sicherheitsmaßnahmen ergreifen, um Missbrauch und Schaden vorzubeugen.

Also warum noch warten? Gehen wir es an.

Autor: Michael Lembcke

Open Banking: EBICS versus API

Open Banking ist einer der Megatrends, den viele Banken angeblich zu verschlafen drohen. Weil kaum eine PSD2-Schnittstelle marktreif zu sein scheint, hat die Bankenaufsicht jetzt bis Dezember 2020 eine Übergangsfrist eingeräumt. Doch das Problem liegt woanders: Viele Institute verspüren nur wenig Lust, viel Geld in die Hand zu nehmen, um Anbietern von Open-Banking-Schnittstellen das Leben zu erleichtern – zumal etablierte Protokolle wie FinTS und EBICS viel mehr leisten als die „APIisierung“ des Bankgeschäfts bisher hervorgebracht hat.

Beide Protokolle, FinTS und EBICS, umfassen heute schon fast alle Bereiche des Bankings, vom Zahlungsverkehr über den Wertpapierhandel bis hin zum Kreditgeschäft. Insgesamt stehen weit mehr als 200 Prozesse bereit, die sowohl die fachlichen Schnittstellen verbindlich beschreiben als auch die technische Kommunikation der beteiligten Partner untereinander. Seit den 90er-Jahren geben HBCI und FinTS bereits die Richtung für offene Standards in der Kommunikation mit Banken vor. EBICS ist von der Deutschen Kreditwirtschaft (DK), beziehungsweise deren Vorläufer, schon vor mehr als zehn Jahren als verbindlicher Standard für die Kommunikation mit Firmenkunden eingeführt worden. Open Banking ist also seit vielen Jahren bereits Realität in Deutschland.

Keine einheitliche PSD2-Schnittstelle in Sicht

So gut die Idee von Open Banking auch ist. Die auch durch PSD2 forcierte Debatte lässt viele Banken, selbst die willigen, ratlos zurück. Einerseits soll unter anderem durch PSD2 ein Open-Banking-Standard für ganz Europa entstehen. Andererseits hat der Gesetzgeber bewusst offengelassen, wie die Kommunikation genau stattfinden soll und wie sie abzusichern ist. Die Folge: Anbieter von Open-Banking-APIs drängen die Banken dazu, ihre Lösungen zu implementieren und ihre ureigenen Interpretationen von Open Banking zu übernehmen, nur um ja nichts zu verpassen. Hinzu kommt, dass verschiedene Initiativen in den unterschiedlichen Ländern Protokolle zur technischen/fachlichen Nutzung entwickeln, die zu einem Wildwuchs an API-Dialekten führen werden. Länderübergreifende Konzeptionen dagegen sind noch bei weitem nicht in Sicht.

All dies kann sich für die Institute zu einem Fass ohne Boden entwickeln, wenn nicht bald eine einheitliche PSD2-Spezifikation vorliegt, an der sich jede Bank orientieren kann. Solange das nicht passiert, dürften viele Open-Banking-Träumereien unerfüllte Wünsche bleiben. Denn die Öffnung hat per Gesetz kostenlos und frei von Diskriminierung zu erfolgen. Damit Geld verdienen wollen andere. Was also soll die Motivation für eine Bank sein, immer neue API-Dialekte kostenfrei anzubinden, nur damit Drittanbieter ihre Apps leichter unter das Volk mischen können? Damit degradieren sich die Institute selbst zum reinen Serviceanbieter. Viel naheliegender ist doch, auf längst etablierte Standards zurückzugreifen.

EBICS: Open Banking für Firmenkunden

Einer dieser Standards ist EBICS. Und dieser Standard ist weit verbreitet: Neben Deutschland spricht auch Frankreich EBICS. Zwischen der Deutschen Kreditwirtschaft und ihrem französischen Pendant, dem CFONB, besteht ein Kooperationsabkommen. Diese beiden größten Zahlungsverkehrsmärkte in Euroland decken das Firmenkunden- und das Interbankengeschäft mit EBICS ab. Die Schweiz (SIX) zählt ebenfalls zu den EBICS-Fans. Österreich (STUZZA) überlegt einzusteigen. Statt im API-Sumpf unterzugehen, lohnt es sich zu fragen, wie sich EBICS PSD2-konform ausbauen lässt. Die Antwort: mit einer Fernsignatur (vgl. Abb.1). Ein modernes EBICS-Portal kann aus eingehenden Daten wie dem Code einer PhotoTAN oder einer QR-TAN Hardware-basiert die Signatur erstellen und an den EBICS-Bankrechner senden.
Abb. 1: Wie Fernsignaturen EBICS zu einer PSD2-konformen Open-Banking-Lösung erweitern
EBICS bietet Firmenkunden viele Vorteile. Unternehmen, die über einen EBICS-Client verfügen, können sicheres Multibanking betreiben und auch die Verteilte Elektronische Unterschrift nutzen (VEU). Damit lassen sich Rollen- und Rechtemodelle abbilden (Signaturen T, A, B und E), um etwa zu bestimmen, ob eingereichte Zahlungsaufträge von autorisierten Personen stammen und ob die jeweilige Person über die entsprechenden Berechtigungen verfügt, um diese Zahlungsaufträge freizugeben. Ähnlich wie bei FinTS gilt auch für EBICS: Die nötige Infrastruktur, um Open Banking zu verwirklichen, existiert bereits. Schon allein deshalb lässt sich nachvollziehen, dass viele Institute damit hadern, jetzt zu investieren. Niemand garantiert, dass sie sich für den richtigen API-Anbieter entscheiden oder dass der Gesetzgeber keine neuen Vorschriften erlässt, die bereits getätigte Investitionen obsolet machen.

Linktipps:
•    Erwartung trifft auf Realität: PSD2 Schnittstellen sind weiterhin nicht marktreif
•    Open Banking: Mit FinTS und EBICS gegen den API-Wildwuchs (PSD2/XS2A-Lösung)

Autor: Michael Schunk

EBICS für das Clearing und Settlement von SEPA-Instant-Payments – das neue Delta-Dokument als Meilenstein

Bereits seit Januar 2008 wird das EBICS-Transferprotokoll mit der SEPA-Einführung auch im Interbankenverkehr für das bilaterale Clearing und Settlement sowie den Austausch von SEPA-Zahlungen mit der Deutschen Bundesbank eingesetzt. Über die Jahre hat sich die Anzahl der Institute in Europa, die EBICS nutzen, weiter erhöht. So ist es auch nicht verwunderlich, dass auch die EBA CLEARING seit November 2013 EBICS als alternativen Zugang für das sog. „Garagenclearing“ und STEP2 anbietet.

Die Einführung der SEPA-Instant-Payments war nach der SEPA-Umstellung der nächste Schritt auf dem Weg zur Standardisierung im europäischen Zahlungsverkehr. Aufgrund des Echtzeitansatzes stellt dieses neue Zahlverfahren jedoch die Nutzbarkeit unter EBICS vor eine besondere Herausforderung. Während in der herkömmlichen EBICS-Nutzung bisher der dateibasierte Datenaustausch im Vordergrund stand, fordert das SEPA-Instant-Payments-Verfahren auch im Interbankenverkehr einen nachrichtenbasierten Ansatz auf Transaktionsbasis. So startete die EBA CLEARING mit RT1 auf Basis von SEPA-Instant-Payments erfolgreich im November 2017.

Zur Unterstützung von EBICS für den Austausch und das Clearing von SEPA-Instant-Payments wurde nun im Oktober 2019 von der EBICS-Gesellschaft auch offiziell ein Delta-Dokument zur EBICS-Spezifikation veröffentlicht (siehe Use of EBICS for the Clearing & Settlement of Instant Payment Transactions, www.ebics.org). Dieses beschreibt die zu berücksichtigenden Modifikationen zur Abwicklung von Instant Payments unter EBICS 3.0. Um den neuen Anforderungen an das Echtzeitverhalten gerecht zu werden, wurde das neue Schema ebics_inst_request_H005.xsd aufgenommen. Für die administrativen Geschäftsvorfälle des Instant-Payments ist jedoch weiterhin das dateibasierte EBICS-Verhalten und somit das Standardschema erforderlich. Für die Nutzung von SEPA-Instant-Payments unter EBICS muss das neue Schema dem übergeordneten Schema hinzugefügt werden.

Im Kunde-Bank-Verhältnis sowie im Interbankenverkehr außerhalb von Instant-Payments ändert sich bei der Nutzung von EBICS nichts.

Das Delta-Dokument Use of EBICS for the Clearing & Settlement of Instant Payment Transactions ist sehr zu begrüßen. EBICS wird in der Praxis vielfältig genutzt, und viele weitere Szenarien sind denkbar. Um die übergreifende und einheitliche Nutzung von EBICS zu gewährleisten, sind Standards und ihre Einhaltung unerlässlich. Dennoch muss flexibel auf Herausforderungen des Marktes reagiert werden können. Dieses Dokument erfüllt beide Ziele gleichermaßen. Ein weiterer Meilenstein auf dem Weg zur Standardisierung des Zahlungsverkehrs in Europa ist gesetzt.

Autor: Michael Lembcke

Multibanking – alles in einem Portal

Standards als Grundlage einer vernetzten Prozessautomatisierung

Daten sind das Öl des 21. Jahrhunderts. Dies wird seit Jahren auf allen Digitalkonferenzen gepredigt. Je mehr Daten ein Anbieter von einem Kunden hat, desto besser lässt sich der Kunde clustern und in Zielgruppensegmente einordnen. Dieses Wissen über die Bedürfnisse des Kunden erlaubt es, interessante Zusatzangebote für ihn zu schaffen.

Wenn sich im Rahmen der Digitalisierung die Zugangskanäle zunehmend auf das Internet verlagern, wird die „digitale Bankfiliale“, wie z. B. das webbasierte Firmenkundenportal TRAVIC-Port, zum entscheidenden Kontakt zwischen Bank und Firmenkunde. Gelingt es dem Betreiber am digitalen Point of Sale alle Bankkonten des Kunden auch anderer Banken zu aggregieren und hinter seinem eigenen Portal zu bündeln, hat er die besten Voraussetzungen für einen ganzheitlichen Überblick über den Zahlungsverkehr des Kunden. Je mehr Konten hier gebündelt werden, desto bessere Serviceangebote kann der Betreiber für seine Kunden kreieren.

Das Schlagwort „Multibanking“ steht für diese Funktionalität einer Bündelung des optimalen Zahlungsverkehrs eines Kunden. Beide Seiten - Kunde und Bank - profitieren von dieser Zusammenfassung unter einem Dach. Auch der Kunde erhält einen umfangreichen Überblick seiner Transaktionen. Die Aggregation bezieht sich sowohl auf die Einreichung aller Zahlungsarten, als auch auf die Abholung der Kontoinformationen aller konnektierten Konten. Das Multibanking in einem Portal ermöglicht dem Anwender eine einheitliche, komfortable Benutzeroberfläche für verschiedene Zahlungsverkehrsanbieter unter einem sicheren Zugang - und damit mehr Komfort für seine internen Prozesse. Der Nutzen dieser reibungslosen Automatisierung des multiplen Zahlungsverkehrs steht und fällt jedoch mit der Schnelligkeit der Abwicklung und sauberen Implementierung der Bankserver verschiedener Anbieter. Ein hoher Grad an vernetzten Transaktionen in beide Richtungen erfordert einheitliche Schnittstellen und eine saubere Einhaltung der verabschiedeten Spezifikationen. Die EBICS-basierte Kommunikation von TRAVIC-Port stellt hierbei das sicherste, internetbasierte, technische Protokoll für den SEPA-Raum zur Verfügung. Allzu großzügige Anpassungen und Abweichungen von der Spezifikation verhindern reibungslose Prozesse auf Seiten der Anbieter und stehen der Vision einer hohen, lückenlosen Zusammenfassung des Zahlungsverkehrs entgegen. Hier sollten sowohl die Auftraggeber der Portalanbieter, als auch die Auftragnehmer und Software-Häuser an einem Strang ziehen. Im Gegensatz dazu ermöglichen APIs mit proprietären Schnittstellen die individuelle Anpassung an die technische Umgebung der Bank. Jede Abweichung von Standards verzögert jedoch die reibungslose Integration des komplexen Datenverkehrs. Unpräzise Auslegungen der Spezifikation verringern den Grad an Automatisierung und Durchsatz jeder Anbindung. Je mehr Lücken im komplexen Netzwerk der Multibankanbindungen, desto geringer der Kundennutzen und die Qualität der Auswertung.

Gastautor: Christian Veith