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

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

Keine Angst vor Standardsoftware im Zahlungsverkehr

Wer sich im Wettbewerb absetzen möchte, entwickelt seine Software selbst. Diese Regel setzt sich mehr und mehr in den Unternehmen durch – und immer mehr „Experten“ empfehlen auch den Banken, sich stärker selbst um die eigenen Anwendungen zu kümmern, ja, sich zu einem Tech-Unternehmen zu entwickeln. Spätestens bei der Zahlungsverkehrsplattform gerät diese Philosophie ins Wanken.

Die Aufsicht fordert beispielsweise einen unterbrechungsfreien Betrieb, sofern eine Bank Instant Payments verarbeiten möchte. Welche Herausforderungen das für die Architektur bedeutet, haben wir beim TRAVIC-Payment Hub am eigenen Leib erfahren. Hinzu kommen die zahlreichen Umsysteme, wie Geldwäsche oder Embargo- und Sanktionslisten, von der Leitwegsteuerung ganz zu schweigen. Alles selbst zu machen, bedeutet allein aus Kostengründen für viele Banken, Zahlungsverkehr dann lieber gar nicht zu machen – also auszulagern oder von einem Zentralinstitut innerhalb eines großen Verbunds erledigen zu lassen. Das aber ist keine Option, sofern sich der Zahlungsverkehr zu einem strategisch wichtigen Geschäftsfeld entwickeln soll.

Jahrmarkt-Karussell für Zahlungen

Wir haben uns deshalb gefragt, was genau die „Special Sauce“ ist, die Banken in ihre ZV-Systeme kippen können müssen, um sich vom Wettbewerb zu unterscheiden und Zahlungsverkehr als eigenes Produkt anbieten zu können. Das ist besonders dann relevant, wenn sich ein Institut darum bewirbt, für Firmenkunden den Zahlungsverkehr in einer bestimmten Weltregion abzuwickeln. Und siehe da: In sich gleichen sich zahlreiche Abläufe von Bank zu Bank, sie unterscheiden sich häufig nur darin, in welcher Reihenfolge sie diese durchführen. Dieser Erkenntnis folgend haben wir das Bild von einer ZV-Plattform entworfen, die wie ein Karussell funktioniert. Jede Spezialfunktion soll, wie Kinder auf dem Rummel, überall zusteigen können (vgl. Abb. 1).





Der TRAVIC-Payment Hub erlaubt einer Bank, jede nur denkbare Konfiguration abzubilden. Das gilt sowohl für die Leitwegsteuerung, für die sich nahezu beliebig komplexe Regelwerke festlegen lassen, wie auch für die anzusteuernden Umsysteme. Woher aber weiß der TRAVIC-Payment Hub, was geschehen soll, wenn etwa vom Compliance-System ein bestimmter Status zurückkommt? Normalerweise müssen sich die Umsysteme doch daran orientieren, was das führende System vorgibt – warum sollte eine Bank, nachdem sie sich möglicherweise in der Kernverarbeitung bereits des Monolithen entledigt hat, sich im Zahlungsverkehr gleich den nächsten hinstellen? Die Antwort liefert eine integrierte Workflow-Engine, die über eine eigene Skriptsprache verfügt, um vergleichsweise simpel – und unabhängig vom Hersteller, also auch von uns – die übrigen Systeme anzubinden.

Das „Hub“ in TRAVIC-Payment Hub ist insofern Produktname und Leistungsversprechen zugleich.

Software-Entwicklung Inside-Out

Technisch krempeln wir das, was sich anderenfalls zu „Legacy“ entwickeln würde, nach außen. Die implementierte Skriptsprache ermöglicht einer Bank, die eigene Fachlichkeit in den TRAVIC-Payment Hub einzufügen, ohne dafür den Quellcode der Software selbst aufmachen zu müssen. Weil Technik und Fachlichkeit voneinander getrennt sind, rückt ein wesentlicher Teil der Software-Entwicklung aus der Sphäre des Herstellers in die Sphäre der Anwender. Dadurch bleibt die ZV-Plattform releasefähig, obwohl der TRAVIC-Payment Hub ein möglicherweise komplexes Netz an Umsystemen steuern muss. Zudem kommen die IT-Abteilungen gar nicht erst in die Versuchung, zu nahe an der ZV-Kernverarbeitung zu entwickeln und damit das Risiko einzugehen, Mikado-Effekte zu erzeugen – an einer Stelle etwas zu verändern und an einer anderen plötzlich ein Problem zu provozieren.

In der Praxis sieht das so aus: Der TRAVIC-Payment Hub nimmt von den angeschlossenen Systemen unterschiedliche Status ein. Über die Skriptsprache legen die eigenen IT-Kollegen oder der Integrationspartner fest, was mit Zahlungen in jedem einzelnen Status geschehen soll. Sobald der Workflow fertig beschrieben ist, kompiliert das System den Code, damit der TRAVIC-Payment Hub arbeiten kann. Das geschieht über von der Workflow-Engine erzeugte Tasks, die eine interne Task-Engine abgearbeitet. Hier ein ganz einfaches Beispiel, wie die von PPI für den TRAVIC-Payment Hub entwickelte Skriptsprache mit OUR-Charges umgeht, also feststellt, ob die fälligen Gebühren einer Zahlungen beiliegen und einbehalten werden dürfen oder eine Zahlungsaufforderung zu erstellen ist.


Status CHECKINBOUNDCHRGS {
if payment is inbound and (payment is ourCharges) then {
if payment is ourChargesReceived then {
just set status VALIDATERECEIVCHGS and leave step
}
if payment is correspondentChargeExpected then {
if payment is debitAuthorized then {
just set status CREATEADVICEOFCHGS and leave step
}
just set status CREATECHARGEREQ and leave step
}
}
just set status DONE and leave step
}



TRAVIC-Payment Hub einführen

PPI bildet mit der TRAVIC-Produktfamilie den gesamten Zahlungsverkehrsprozess einer Bank ab, vom Zahlungseingang über das Interbankengeschäft bis hin zum Clearing. TRAVIC-Payment Hub stellt die Kernverarbeitung für den Zahlungsverkehr dar. Unsere Lösung funktioniert als Kunden- und als Clearingbank – auch im Parallelbetrieb – und kann Instant Payments. Zudem lässt sich die Lösung On-Premises betreiben wie auch als ausgelagerte Hochverfügbarkeitslösung gemeinsam mit unseren Infrastrukturpartnern.

Autor: Thomas Riedel

Mehr Informationen:



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

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

EBICS 3.0 – ein Satz an Parametern anstelle der Auftragsart. Was ist bei der Identifikation der Geschäftsvorfälle zu berücksichtigen?

Mit EBICS 3.0 werden die unterschiedlichen Geschäftsvorfälle bekanntlich nicht mehr über Auftragsarten abgebildet, sondern über die neuen BTF-Parameter.
Für die Nutzung von Kundenverträgen mit EBICS-Clients verschiedener EBICS-Versionen in Kombination mit EBICS 3.0 wurden von den nationalen Spezifikationsgremien eigens Mappingregeln entwickelt. Diese orientieren sich i. d. R. an den fünf BTF-Parametern Service Name, Service Scope, Service Option, Service Message Name und Service Container. Wichtig ist, dass die Kombination dieser BTF-Parameter im EBICS-Bankrechner eindeutig sein muss. Dadurch wird sichergestellt, dass eine Auftragsart dem Geschäftsvorfall über BTF zugeordnet werden kann und umgekehrt.

In der Praxis können heute zu einer Auftragsart fachlich identische Aufträge eines bestimmten Formats in verschiedenen Formatversionen erstellt und beim Bankrechner eingereicht werden. Auch wenn es regelmäßig über die Spezifikationsgremien zu Formatanpassungen kommt, hängt die vom Clientsystem genutzte Formatversion auch vom Softwarestand der Clientlösung ab. Da die Formatversion für den Anwender in den Clients transparent sein dürfte, hat er bei der Zusammenstellung seiner Auftragsdatei keinen Einfluss auf die Einreichung in einer bestimmten Formatversion. Zudem akzeptieren Banken heutzutage i. d. R. unterschiedliche Formatversionen eines Geschäftsvorfalls. Letztendlich kann für die bankseitige Verarbeitung die jeweilige Formatversion zumindest bei XML-Formaten auch aus dem Namespace der XML-Datei ausgelesen werden. Bankrechner sind bisher flexibel für verschiedene Formatversionen ausgelegt.

Die weiteren nutzbaren BTF-Parameter in EBICS 3.0 sind Service Message Name Format, Service Message Name Variant und Service Message Name Version. Sollte ein Finanzinstitut auch diese weiteren Parameter in die Auftragsartmappings und Vereinbarungsdetails mit dem Kunden aufnehmen, so sollte einiges beachtet werden. Falls nicht bereits bisher über FileFormat-Parameter intensiver genutzt oder aus verarbeitungstechnischen Gründen notwendig, sollten diese weiteren Parameter bankseitig bei EBICS-Prüfungen eher dosiert berücksichtigt werden.

Letztendlich sind diese zusätzlichen Parameterinformationen bereits Inhalt der Auftragsdatei selbst und ohnehin daraus auslesbar. Was ist zu tun bei sich widersprechenden Angaben? Außerdem bedeutet die zusätzliche Pflege im Bankrechner mehr Aufwand bei der Stammdatenpflege. Es müsste ja für jede Formatversion eines Geschäftsvorfalls eine eigene Kundenvereinbarung geben. Erschwerend kommt hinzu, dass diese Formatdetails für den Kunden in der Clientsoftware transparent sind und er diese z. T. nicht steuern kann.

Was würde passieren, wenn z. B. der Bankrechner bei einer Einreichung die Versionen 03 und 04 eines XML-Formats unterstützt, der Kunde aber für die Einreichung eines Formats der Version 03 stattdessen die Version 04 in den BTF einstellt? Bei der Versionsberücksichtigung würde der Auftrag abgelehnt, obwohl das Banksystem die Formatversion verarbeiten könnte. Die tatsächliche Version ist ja am Namespace erkennbar.

Noch komplizierter wird es mit den Auslieferungen. Hier müsste die Auslieferung zum Abholzeitpunkt synchron in der angefragten Version erzeugt und als Datei ausgegeben werden. Gleiches gilt dann auch für historische Abholungen.

Fazit: Man sollte als Finanzinstitut nicht zu restriktiv sein bei den Definitionen der BTF-Vereinbarungen mit dem Kunden. So ist man als Finanzinstitut flexibler und spart sich Mehraufwand in der Vertrags- und Stammdatenpflege.


Autor: Michael Lembcke

XS2A ohne Drittdienstanbieter? Warum nicht!

Im Rahmen der PSD2 wurde europaweit eine Schnittstelle für Drittdienstanbieter (XS2A-API) eingeführt. Die EU als Initiator strebt damit an, den Zugang zu den Bankkonten der Kunden für Dritte zu öffnen und damit den Wettbewerb im Markt zu fördern. Seit dem 14.09.2019 ist die XS2A-API fristgerecht in Europa von den Banken in Produktion genommen worden. Seither orientieren sich die Marktteilnehmer neu, adjustieren die XS2A-API an die Bedürfnisse der Stakeholder und arbeiten intensiv an Diensten sowohl für Verbraucher als auch für Firmen.

Als regulatorisches Must-have ist die XS2A-API für Banken zunächst einmal ein Kostentreiber. Jedoch wurden von Anbeginn Mehrwertdienste angedacht und z. B. von der Berlin Group bereits spezifiziert, um den Banken eine Einnahmequelle zu ermöglichen. Doch den Phantasien hinsichtlich der Einnahmequellen, von denen es im aktuellen API-Hype viele gibt, sind keine Grenzen gesetzt.

Wir reiten also für den Moment die Hype-Welle mit und stellen uns die XS2A-API als alternativen Zugangskanal für Firmen vor. Warum nicht. Aus technischer Sicht sollten die Hürden gering sein. Eine Firma könnte sich wie ein Drittdienstanbieter durch ein eIDAS-Zertifikat ausweisen. Das Zertifikat würde sich nur in den spezifischen Feldern für Drittdienstanbieter unterscheiden. Ähnlich zu EBICS können eingereichte Aufträge oder Anfragen mit einer Signatur versehen werden, an Hand derer der Empfänger die Unversehrtheit der Nachricht prüfen kann. Die Sicherheit auf dem Transportweg wird durch die Verwendung von TLS gewährleistet.

Aus fachlicher Sicht können mit Hilfe des Use Cases „Zahlung initiieren“ sowohl Einzel- als auch Sammelzahlungen ausgeführt werden. Für die Freigabe werden den Verbrauchern die gängigen Autorisierungsverfahren aus dem Online-Banking angeboten (z. B. photoTAN, pushTAN). Für Firmen wäre das wahrscheinlich ungeeignet, sodass eher Corporate Seals zum Einsatz kommen würden, was zu spezifizieren ist. Ebenso die Abfrage von Kontoinformationen (Salden, Transaktionen, Details) ist über die XS2A-API möglich. Die dafür erforderliche Einwilligung (consent) könnte in diesem speziellen Fall, wo zwischen Firma und Bank ein Vertrauensverhältnis besteht, durch eine dauerhaft gültige Einwilligung gelöst werden.

Aus der mittleren Flughöhe gesehen wäre die XS2A-API also eine valide Alternative, die auch bereits in verschiedenen Foren angedacht wird. Hier wird die Idee mit Attributen wie „günstiger, bequemer, echtzeitfähig sowie flexibler bei Anpassungen“ belegt. Jedoch holt uns der Status quo auf den Boden der Tatsachen zurück. Die prägende Spezifikation, die der Berlin Group, lässt den Banken viele Freiräume, die API zu implementieren. In der Bestrebung, alle Banken in Europa über XS2A zu erreichen, stellen diese Freiräume für alle Marktteilnehmer aktuell eine Herausforderung dar. Ein Zustand, der für Firmen nicht einladend ist, noch nicht. Jedoch ist der Grundstein für eine Alternative gelegt.


Autor: Christian Wenz

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

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

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

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

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

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

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


Autoren: Aline Wendler und Michael Lembcke

Moderatorenbeitrag: Erweiterung PPI EBICS-Blog – all about Payments!

Liebe Leserinnen und Leser,

wir freuen uns, Sie heute über die Erweiterung unseres EBICS-Blogs zu informieren.

Im PPI EBICS-Blog "All about Payments" möchten wir Sie zukünftig noch umfassender über Trends und aktuelle Themen rund um den Zahlungsverkehr in den Bereichen EBICS, SEPA, SWIFT sowie Regulierung und Digitalisierung auf dem Laufenden halten.

Ab sofort wird der EBICS-Blog von zwei Autorenteams und im 2-wöchigen Rhythmus für Sie bespielt. Unser Ziel: Ihnen über die Sichtweisen und Erfahrungen unserer Produkt- sowie Consulting-Experten aus Kundenprojekten, Studien und Whitepapern im Hinblick auf aktuelle und zukünftige Anforderungen im Zahlungsverkehrsmarkt aus erster Hand zu berichten.

Wir freuen uns auf Ihr Feedback und wünschen Ihnen weiterhin viel Spaß beim Lesen!

Ihr PPI Autoren-Team

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

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

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

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

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

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

Autor: Michael Lembcke

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

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

Autor: Marc Dutech

Verifizierung der Hashwerte der Bankschlüssel beim EBICS-Initialisierungsrequest

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

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

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

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

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

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

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

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


Autor: Hendrik Chlosta

EBICS-Tests mit Kunden im produktiven Bankrechner?

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

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

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

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

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

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


Autor: Michael Lembcke

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

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

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

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

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

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

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

Carsten Miehling

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

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

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

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

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


Michael Lembcke