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

Gelebte Digitalisierung – Schlüsseltausch per INI-Briefverfahren

Seit der Einführung von kryptografischem Schlüssel im Onlinebanking, sowohl bei Privatkunden als auch bei Firmenkunden, ist der Prozess des Austauschs der öffentlichen Schlüssel von Bank und Nutzer immer ein langwieriger und komplizierter Prozess – zugegeben: für die Nutzer ist er besonders beschwerlich; für den Rest der Menschheit der Brief mit sieben Siegeln:

Etabliert hat sich dabei das INI-Briefverfahren. Seit mehr als 15 Jahren im Gebrauch, ist es immer wieder der Hemmschuh, der eine Nutzung z. B. von EBICS behindert. Schlüssel erzeugen, diese senden, dann den papierhaften INI-Brief drucken, unterschreiben und an die Bank übergeben, ist für viele kompliziert und langwierig. Auch die Bearbeitung in der Bank selbst, wo ein Mitarbeiter den INI-Brief erhält, dann den zugehörigen Kundenkontakt im EBICS-System aufruft und dort die Kontrollwerte der elektronischen Übertragung mit den Werten auf dem INI-Brief vergleicht oder gar eintippen muss, ist aufwendig. Natürlich muss auch noch die Unterschrift geprüft werden, die auf dem Kontoblatt oder dem Vertrag hinterlegt ist. Klingt so gar nicht nach der Digitalisierung, die heute doch unsere Geschäftsprozesse begleiten soll.

Freigabe der EBICS-Schlüssel vereinfachen
Dabei ginge alles auch sehr viel einfacher, wenn Banken den obigen Prozess von den eigenen Mitarbeitern lösen, ihn komplett digitalisieren und damit an den Nutzer selbst delegieren würden. Der erste Schritt, der umzusetzen ist, ist die zweifelsfreie Erkennung des jeweiligen Nutzers durch Austausch eines gemeinsam vereinbarten Geheimnisses (z. B. TAN) oder – wenn bereits vorhanden – eine aktivierte Onlinesession, die sicherstellt, dass der Nutzer auch die richtige Person ist. Das trifft i.d.R. auf jede angemeldete Onlinebankingsession bereits zu! Wenn wir nun annehmen, dass das Banksystem nach einer erfolgreichen Schlüsseleinreichung den Nutzer online und aktiv, z. B. per Smartphone mit SMS oder App oder über eine Onlinebanking Session erreichen kann, dann wäre es doch auch möglich, dass dieser Nutzer die Richtigkeit seiner Schlüsselübertragung selbst bestätigen kann und somit seine EBICS-Schlüssel innerhalb kürzester Zeit freigeben kann.

Nur er!
Der Nutzer darf dies selbst tun, weil das Banksystem – zum Beispiel durch die Korrektheit der abgefragten TAN – die Identität des Nutzers zur Freigabe ermittelt hat. Der Nutzer vergleicht dann nur noch die Kontrollwerte von INI-Brief und Anzeige im Banksystem und bestätigt die Korrektheit. Vielleicht muss er diese auch noch mal selbst eingeben. Also genau das, was der Mitarbeiter bei der Bank auch tut. Natürlich protokolliert das Banksystem diese Freigabe durch den Nutzer, um später den Nachweis zu haben, dass der Nutzer den Vorgang geprüft hat.

Gelebte Digitalisierung
Der Nutzer des EBICS-Protokolls kann innerhalb weniger Minuten seinen neuen Zugang nutzen. Aufwendiger Ausdruck und Übergaben an die jeweilige Bank werden nicht mehr nötig sein. Die Wartezeit von Tagen wird auf Minuten reduziert. Die Bank spart sich aufwendige und teure manuelle Inhouseprozesse der Schlüsselfreigabe. Übergebene Dokumente – der INI-Brief – müssen nicht mehr archiviert werden. Die digitale Protokollierung des neuen Verfahrens reicht aus und bedarf keiner manuellen Erfassung/Digitalisierung des INI-Briefes mehr. Die Kundenzufriedenheit und die Akzeptanz des EBICS-Verfahrens werden gestärkt, die Banken sparen sich Kosten für Mitarbeiter und manuelle Nachbearbeitung. Gelebte Digitalisierung, eine ganz klare Win-win-Situation!

Autor: Michael Schunk

Ein wichtiger Schritt in Richtung Einheit

Ab Ende 2023 erweitert sich der Nutzerkreis des Electronic Banking Internet Communication Standard (EBICS): Im November kommenden Jahres beginnt in Österreich die Migration der Zahlungsverkehrssysteme vom bisher genutzten proprietären Multi Bank Standard (MBS). Für die Unternehmen in der Alpenrepublik bedeutet die Umstellung zunächst einmal Arbeit, hat aber am Ende klare Vorteile. Denn mit EBICS existiert ein nahtloser Anschluss an den größten europäischen Zahlungsverkehrsraum rund um Deutschland und Frankreich. Außerdem lassen die Banken ihre Kunden beim Umstieg natürlich nicht allein. Zunächst allerdings müssen die Institute selbst ihre Hausaufgaben machen. Über Zeitplan, Vorteile und Vorgehensweisen sprechen in einem gemeinsamen Interview Thomas Bargehr, Produktmanager Banking Solutions and Payment Services, Hypo Vorarlberg Bank AG, und Michael Lembcke, Leading Product Manager, PPI AG.

 

  1. Herr Bargehr, im Juli 2020 hat die österreichische Kreditwirtschaft ihren Beitritt zur EBICS-Gesellschaft erklärt, seitdem läuft die Einführung bei den Banken. Wie weit ist Ihr Haus, wie sieht der weitere Fahrplan aus?
    Aktuell stimmen wir in der PSA (Payment Service Austria) die Anforderungen an automatische Migrationsschnittstellen ab. Über diese sollen die Daten und Autorisierungsmethoden aus den Altprogrammen und den MBS-Stammdaten transportiert werden. Damit ist ein benutzerfreundlicher Wechsel von MBS zu EBICS möglich. Die Migration selbst soll nach dem nationalen Projektplan ab November 2023 folgen. Ab dem Zeitpunkt müssen dann auch alle Geschäftskunden auf EBICS wechseln.

  2. Herr Lembcke, deutsche Banken nutzen EBICS schon geraume Zeit, von Problemen ist nichts zu hören. Welche Vorteile hat dieser Standard für die Kreditinstitute, verglichen mit MBS?
    Für Firmenkunden ist vor allem eine länderübergreifende Multibankfähigkeit wichtig. Zu viele unterschiedliche nationale Standards oder Verfahren verursachen Mehraufwand und stören die Abläufe. Eine Vereinheitlichung fördert zudem eine mögliche Prozessautomatisierung im Sinne eines Straight-Through-Processing (STP). Auf der Architekturebene ermöglicht EBICS eine innovative, zeitgemäße Auslegung von Zahlungsverkehrssystemen.

  3. Herr Bargehr, die Weiterentwicklung des MBS ist eingestellt, die Unternehmenskunden müssen also irgendwann zu EBICS wechseln. Das verursacht bei Ihren Unternehmenskunden Arbeit, womit ist das zu rechtfertigen?
    Der Zahlungsverkehr und damit einhergehend die von der Kundensoftware zu unterstützenden Formate sind seit der Euro-Einführung einem ständigen Wandel unterworfen. Dass sich alle paar Jahre etwas ändert, sind die Unternehmen also schon gewohnt. Die Hersteller von Enterprise-Ressource-Planing-Software begleiten diese Entwicklungen in der Regel rechtzeitig und qualitativ sehr gut. Gleiches gilt natürlich auch für unser eigenes Haus, das sich immer als verlässlicher Partner an der Seite der Kunden versteht.
     
  4.  Herr Lembcke, die PPI AG ist Marktführer von EBICS-Lösungen und hat den Standard von Anfang an begleitet. Wie läuft aus der Sicht eines Zahlungsverkehrsberaters die Einführung in Österreich?
    Bislang sind keine signifikanten Probleme erkennbar. Die Herausforderung liegt allenfalls darin, den Übergang für alle Beteiligten so reibungslos wie möglich zu gestalten. Da sind wir natürlich auch als Hersteller von EBICS-Software gefragt, Lösungen zu liefern. Natürlich gab es mit MBS in Österreich auch bisher schon einen funktionierenden eBanking-Standard. Aber zukünftig haben die Institute und Firmenkunden in Österreich einen europäischen Multibank-Standard, der auf State-of-the-Art Architekturen beruht und den Zahlungsverkehr im Land langfristig zukunftsfest macht.

  5. Herr Bargehr, eine solche Migration von Datenverarbeitungsstandards ist keineswegs eine triviale Angelegenheit. Wie stellen Sie sicher, dass nichts schiefgeht und es keine Downtimes gibt?
    Wir erheben bereits weit vor Migrationsbeginn den aktuellen Status des Kunden und stellen so frühzeitig besondere Anforderungen hinsichtlich Technik und Betreuung fest. Entsprechend begleiten wir die Unternehmen dann bis zum Wechsel. Schlüssel zum Erfolg sind eine saubere Übertragung der Kundenzugänge auf den EBICS-Server, ein kurzer und zugleich handhabbarer Übergangszeitraum sowie ein qualitativ hochwertiger Kundenservice.

  6. Herr Lembcke, die PPI AG hat zahlreiche Migrationsprojekte in Richtung EBICS begleitet. Welche Vorgehensweise empfehlen Sie einem Finanzinstitut?
    Hier gibt es keine One-Size-Fits-All-Lösung. Das Vorgehen hängt stark von der Strategie und der Kundenstruktur des einzelnen Instituts ab. So ist durchaus eine Big-Bang-Migration denkbar, bei der alle Kunden auf einmal umgezogen werden. Schrittweise Migrationsszenarien haben aber genauso ihre Berechtigung, auch wenn dabei natürlich ein Parallelbetrieb von EBICS und MBS notwendig wird. Wichtig ist der Austausch mit den eigenen Unternehmenskunden, deren Migrationsplanungen abgefragt werden sollten. Für Downtimes gibt es jedenfalls keine Veranlassung, eine Migration im laufenden Betrieb ist absolut machbar.
     
  7. Herr Bargehr, EBICS kennt durchaus regionale Unterschiede, so hat beispielsweise Frankreich auf einige lokale Anpassungen bestanden. Gibt es auch in Österreich Abweichungen vom EBICS-Normalfall?
    Auch wenn EBICS in Österreich noch kein Standard ist, betreiben die meisten Banken aufgrund der Marktanforderungen bereits heute entsprechende Server und Clients. Dabei gehen sie aber unterschiedlich vor: Manche kaufen sich Lösungen von der Stange und betreiben diese ohne weitere Anpassungen an nationale Besonderheiten. Andere dagegen – hier zählt die Hypo Vorarlberg dazu – analysieren eben jene lokalen Anforderungen und berücksichtigen sie bei der Auslegung ihrer Kundensysteme. Für uns hat die PPI die jeweiligen Sonderfälle in die Zahlungsverkehrslösungen eingebaut. Daher sind wir seit 2017 bereits vollständig EBICS-ready.
     
  8. Herr Lembcke, hat EBICS 3.0 das Potenzial, die Diskussion um die Notwendigkeit zusätzlicher, PSD2-konformer APIs zu beenden?
    Das ist letztlich eine Diskussion, bei der es kein Ergebnis im Sinne eines Entscheides geben kann. Denn genauso wie EBICS ein etablierter, von allen Instituten beherrschter Standard ist, sind APIs aufgrund ihrer Anzahl ebenfalls ein fester Bestandteil der IT-Landschaft. Beides wird noch länger nebeneinander existieren.
     
  9. Herr Bargehr, welchen Weg wird die Hypo Vorarlberg Bank gehen? Bieten Sie zusätzliche Schnittstellen an oder setzen Sie erstmal voll auf EBICS?
    Kleinstkunden können wie gewohnt weiter unser Onlinebanking nutzen. Kleine und mittelständische Unternehmen sowie Großkunden werden bei uns aber künftig ausschließlich mit EBICS arbeiten. Wir nehmen die EBICS-Migration zum Anlass, nach und nach alte Zahlungsverkehrs- und Banking-Systeme abzuschalten und damit Doppelgleisigkeiten zu vermeiden.
     
  10. Herr Lembcke, im europäischen Zahlungsverkehr tut sich derzeit ohnehin einiges, als Beispiele lassen sich die SWIFT-Umstellung oder Request to Pay (RTP) nennen. Wie ist EBICS hier einzuordnen?
    Der Standard erfüllt alle wichtigen Voraussetzungen, um die absehbaren Veränderungen im europäischen Zahlungsverkehr miteinander zu harmonisieren. Schon deswegen sollte alles getan werden, EBICS in weiteren Ländern offiziell einzuführen. Dabei ist auch auf eine Vereinheitlichung der Nutzungsweise zu achten, um die Akzeptanz zu erhöhen. Die Einsatzbereiche sind bereits jetzt vielfältig. SEPA Instant Payments lässt sich beispielsweise mit EBICS abwickeln, im Interbankenaustausch wird RTP unterstützt. Für die Teilnahme am Zahlungsverkehr der Zukunft ist EBICS die Eintrittskarte!

EBICS und die Echtzeitbenachrichtigungen - Eine Bestandsaufnahme

 

Mittlerweile ist es schon mehr als zwei Jahre her, dass die Spezifikation „Echtzeitbenachrichtigungen“  auf der EBICS Webseite www.ebics.de veröffentlicht wurde. In einem Blogbeitrag vom Oktober 2019  hatte ich mich bereits dieses Themas angenommen. Doch was ist daraus eigentlich geworden? Und wie hat sich der Einsatz in der Praxis entwickelt?

Tatsächlich wurde die neue Schnittstelle für Echtzeitbenachrichtigungen von einigen Instituten in Deutschland im EBICS-Bankrechner implementiert und ist mittlerweile bei diesen produktiv im Einsatz. Natürlich macht der damit verbundene neue Funktionsumfang nur Sinn, wenn es EBICS-Clients gibt, die diese Schnittstelle nutzen. Unter Umständen wurde in von Banken betriebenen Firmenkundenportalen daher diese Schnittstelle ebenfalls clientseitig implementiert.

Wir erinnern uns. Der Mehrwert dieser neuen Schnittstelle liegt in der potenziell schnelleren Rückmeldung bei SEPA Instant Payments im EBICS-Kanal sowie generell bei der Einsparung von Hoffnungsabfragen zu Downloaddaten. Wo stehen wir damit?

Einige Kreditinstitute in Deutschland haben das Konzept umgesetzt. Jedoch nicht jedes Kreditinstitut ist heute in der Lage, diesen neuen Service anzubieten. Unter Umständen ist es bankseitig für EBICS auch nicht oder noch nicht im Fokus. Neben der neuen Schnittstelle zur Echtzeitbenachrichtigung in Richtung Kunde ist nämlich auch die zeitnahe Bereitstellung der Downloaddaten im Bankrechner eine der Voraussetzungen, um Kunden einen Mehrwert für EBICS bieten zu können. Diese kontinuierliche und zeitnahe Bereitstellung aus den Backendsystemen heraus für den EBICS-Kanal muss dafür bei den Kreditinstituten zur Verfügung stehen.

Kundenseitig ist die Push-Benachrichtigung insbesondere für Firmenkunden von Interesse, bei denen die Aktualität und die Nähe zur Echtzeit zunehmend relevant ist. Diese EBICS-Kunden haben die Echtzeitbenachrichtigung auf der Clientseite zum Teil bereits implementiert. Andere, die z. B. ein geeignetes Firmenkundenportal des Kreditinstituts nutzen, kommen ggf. auch ohne eigenes Zutun in den Genuss des neuen Services. Dennoch verfügt nicht jeder EBICS-Client über die neue Websocket-Schnittstelle zur Echtzeitbenachrichtigung.

Fazit ist, dass die Funktion der Echtzeitbenachrichtigung im Jahr 2022 noch nicht in der Breite bei den EBICS-Kunden angekommen ist. Bisher sind es gerade spezialisierte Firmenkunden und institutionelle EBICS-Kunden, die auf Echtzeitbenachrichtigung im EBICS-Kanal setzen. Für sie stellt die Echtzeit in den Zahlungsverkehrsprozessen einen besonderen Mehrwert dar, für den sich auch die eine oder andere Investition lohnt. Die Kreditinstitute dieser Kunden bieten den passenden Service an.

Wir sehen, dass generell das Thema Echtzeit im Zahlungsverkehr noch Wachstumspotenzial hat. Somit ist davon auszugehen, dass auch das Thema Echtzeitbenachrichtigung in Verbindung mit EBICS noch an Bedeutung gewinnen wird. Bleiben wir also gespannt!

Autor: Michael Lembcke

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