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 und VEU: Schwächen bei Gehaltszahlungen mit vertraulichen Informationen

Die Verteilte Elektronische Unterschrift (VEU) ist seit vielen Jahren eine wichtige Funktion, um Zahlungen von unterschiedlichen Personen selbst an unterschiedlichen Orten einreichen und freizeichnen zu lassen.
Die im EBICS-Protokoll dafür vorgesehenen Auftragsarten und deren fachlicher Inhalt erlauben eine Freigabe auf Basis der Gesamtdatenlage – über den Dateibegleitbeleg – oder gar auf Basis der inhaltlichen Zahlungsdaten. Dafür liefern EBICS-Server die wichtigsten Informationen für jede der enthaltenen Einzelzahlungen bereits in aufbereiteter Form. Ein Kundensystem, das diese Daten anzeigen soll, muss dazu nicht mal das konkrete Zahlungsformat kennen. Das macht die Software so komfortabel. Ausnahmsweise lässt sich sogar eine komplette Zahlungsdatei übermitteln. Doch gerade bei großen Sammelzahlungen stellt das den gerade beschriebenen Komfort wieder in Frage.
In der Zahlungsverkehrspraxis kommen nicht nur einfache Zahlungen und Lastschriften in die VEU-Mappe, sondern auch Sonderzahlungen mit sehr persönlichen Daten, die besonders zu schützen wären. Dazu gehören etwa Pensionszahlungen, Gehaltszahlungen sowie Bonuszahlungen und Gratifikationen, die nicht für die Allgemeinheit und erst recht nicht für die Einsichtnahme durch die Belegschaft eines Unternehmens bestimmt sind.
Genau an dieser Stelle wird eine Schwäche der EBICS-Spezifikation deutlich: der GVC oder PurposeCode, der festlegt, um was für eine Art Zahlung es sich handelt, fehlt, wenn die Einzelzahlungen übertragen werden. Die von Kunden eingesetzten EBICS-Produkte sind deshalb gar nicht in der Lage, selbst wenn die Unternehmen das wollten, vertrauliche Daten in einem Zahlungsauftrag zu schützen. Der Software fehlt das Kriterium, um zu entscheiden, ob Zahlungsdetails angezeigt oder ausgeblendet werden müssen.
Ohne eine Kennung im konkreten Zahlauftrag ist es nicht möglich, vertrauliche von normalen Zahlungen zu unterscheiden. Damit ist die VEU im Prinzip ungeeignet, um etwa Gehaltszahlungen zu prüfen und per VEU freizugeben, weil nicht auszuschließen ist, dass nicht berechtigte Mitarbeiter einen Blick auf die möglicherweise vertraulichen Informationen werfen.
Die EBICS-Gesellschaft sollte sich deshalb beim XML für den HVT eine Erweiterung überlegen, mit der künftig auch diese wichtigen Informationen für die Art der Zahlung übermittelt werden. Solange dies nicht geschieht, lässt sich die VEU für Gehaltszahlungen nur eingeschränkt nutzen.

Autor: Michael Schunk

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

All goes ISO 20022

Mit dem Titel wird der allgemeine Wechsel auf ISO 20022 im gesamten Zahlungsverkehr sowie im dazugehörigen Reporting bezeichnet. An dieser Stelle hat mein Kollege René Keller über die Pläne von TARGET2 und SWIFT geschrieben, nun auch auf den schon aus SEPA bekannten ISO-20022-Standard im Individual- und Auslandszahlungsverkehr zu setzen. Die dort beschriebenen Änderungen, insbesondere im Interbanken-Zahlungsverkehr, wirken sich nun auch auf die Kunde-Bank-Schnittstelle aus.

So wie sich Corona an vielen anderen Stellen negativ auswirkt, so finden sich die Folgen auch hier in verschobenen Zeitplänen. Die Änderungen kommen – allerdings etwas später. Die Zeit sollte gut genutzt werden, denn es handelt sich hierbei nicht um reine IT-Themen, sondern mit der neuen Sprache verändern sich viele Prozesse im Zahlungsverkehr und im angrenzenden Umfeld grundlegend und die Auswirkungen sind in der gesamten Architektur zu berücksichtigen. Das gilt für Banken und auch für Firmenkunden, die einige Änderungen in den kommenden Releases bewältigen müssen. Die Informationen liegen in den Ankündigungen nun in der Anlage 3 zum DFÜ-Abkommen vor, reichen einige Jahre in die Zukunft, sind aber auch nötig.

An manchen Stellen wird das Argument „die anstehenden Änderungen sind doch gar nicht so massiv, mit SEPA ist uns das XML-Format doch bekannt“ ins Feld geführt. Wenn das bei SEPA verwendete Format „gut bekannt“ ist, dann ist das eine sehr gute Ausgangsbasis, um sich auf die Änderungen vorzubereiten. Es geht aber um weit mehr. Zum einen steht für SEPA ein Release-Sprung an, zum anderen gibt es gerade im Individual- und Auslandszahlungsverkehr eine ganze Reihe von Besonderheiten, die im Massenzahlungsverkehr so gar nicht vorkommen. Darüber hinaus kommt aus regulatorischen Gründen der Wechsel auf strukturierte Adressangaben. In der Summe der Änderungen liegt die Herausforderung.

camt.053 – Versionsänderung

Mit der Einführung von SEPA und dem europaweiten einheitlichem Format auf der Basis von ISO 20022 wurde auch der Kontoauszug camt.053 neben dem bisher üblichen MT940 eingeführt. Für SEPA-Zahlungen das ideale Format, denn nun konnten Daten aus einem einheitliche Datenlexikon (data dictionary) über pain (Kunde-Bank) und pacs (Interbank) auch als Kontoauszug transportiert werden. Aber neben den Buchungen im Massenzahlungsverkehr gab es auch noch den Individual- sowie den Auslandszahlungsverkehr. Aus diesem Grunde (und verschiedensten anderen) blieben gar nicht so wenige Unternehmen bei dem altbekannten Format.

Die Einführung von ISO 20022 im gesamten Interbanken-Zahlungsverkehr erfolgt nun aber auf einem aktuellen ISO-Release, dem von 2019. SEPA nutzt immer noch das ISO-Release von 2009. Wie bei jedem Standard gibt es auch bei ISO 20022 natürlich diverse Gründe für die Weiterentwicklung des Formats, und die wird es auch weiterhin geben. Es werden neue Felder eingeführt oder Codewörter erweitert werden. Der Kontoauszug, der all die neuen Informationen an den Endkunden ohne Datenverlust weitertragen soll, muss sich also auch dem neuen Standard fügen, und so ist für camt die Umstellung vom camt.053.001.02 auf das neue Release camt.053.001.08 unumgänglich (analog für camt.052 und camt.054). Durch die frühzeitige Information von Firmenkunden ist hier nun auch ausreichend Zeit für oftmals längere ERP-Releasezyklen gegeben. Zumal auch damit zu rechnen ist, dass mit einer Verschiebung der TARGET2-Umstellung auf ISO 20022 auch die Umstellung hier verschoben werden wird.

MT940-Abkündigung

SWIFT wird die MT-Nachrichten der Kategorie 1,2 und 9 zum November 2025 im Interbankenverkehr einstellen. An der Kunde-Bank-Schnittstelle (insb. bei SCORE) soll diese Einschränkung nicht gelten, hier sind die Banken weltweit in ihrem Service nicht gezwungen, MT101 oder gar MT940 abzuschalten. Aber die DK hat dies für unseren „Multibank-Standard“ beschlossen – und das ist gut so. Wer als Bank möchte, darf ja noch MT940 anbieten, aber die Vorteile der neuen Sprache liegen schon auf der Hand: Ganze XML-Strukturen können von pain über pacs zu camt ohne Konvertierung transportiert werden. Da ist die Analogie von Containern in der Logistik schon naheliegend. Und in diese Vorteile hinein sollten alle Firmenkunden hinein„gedrängt“ werden.

DTAZV wird pain.001

Mit der Einführung von pain.001 als Kundenauftrag für eine SEPA-Überweisung war schnell die Frage aufgeworfen: Warum kann man dieses Format nicht auch für Währungszahlungen benutzen? Zur harmonisierten Nutzung dieses globalen Standards hat sich dann alsbald die Initiative CGI-MP (Common Global Implementation – Market Practice) aus Corporates, Banken und Herstellern gefunden, um eine harmonisierte Belegung festzulegen. Die CGI-Version von pain.001 beruht aber wie die SEPA-Version auf dem ISO-Release 2009 – also pain.001.001.03. Die CGI-MP arbeitet an einer neuen Version (ISO-Release 2019) der harmonisierten Belegung. Die neue AZV-Einreichung in der Anlage 3 wird auch nach ISO 2019 erfolgen – somit pain.001.001.09.

Und wie so oft, liegt in dem Wechsel auf „alles in ISO 20022“ auch eine große Chance. Durchgehende Prozesse auf der gleichen Datenbasis, die ohne Konvertierungen bewältigt werden können. Die Basis für eine weitergehende Digitalisierung sind nun einmal Standards, mit „alles in ISO 20022“ ist ein durchgehender Standard gegeben, der auch für angrenzende Prozesse „Exception & Investigation“ (Rückfragen), Avise, Bankentgeltnachrichten (Bank Service Billing camt.086) sowie auch im BAM (Bank Account Management) als eBAM-Nachrichten genutzt wird. Da ist dann wiederum Zahlungsverkehr (inkl. Kontoauszug) nur ein kleiner Ausschnitt im gesamten ISO-Universum.


Autor: Mario Reichel

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:



SEPA 2.0: Durch das ISO 20022-Update droht eine 3-fach-Migration

SEPA und der zugrunde liegende ISO-20022 Standard können durchaus als Vorreiter der globalen ISO-20022-Initiativen gesehen werden. Schon frühzeitig stellten sie sich als das Regelwerk für viele unterschiedliche Zahlungsverkehrsformate in der Eurozone dar und bedienten sich dabei eines einheitlichen Formatstandards, um eine grenz- und systemüberschreitende Interoperabilität zu ermöglichen. Trotz einiger lokaler Dialekte hat SEPA über die Jahre - nicht zuletzt durch Angleichungen der nationalen Besonderheiten an eine einheitliche EPC-Vorgabe - eine durchgängige Ende-zu-Ende-Zahlungsverarbeitung ohne Medienbrüche und Konvertierungen ermöglicht. Ende-zu-Ende bezieht sich in diesem Fall nicht nur auf das Interbankenverhältnis, sondern auch auf jenes vom Auftraggeber bis hin zum Empfänger. Ermöglicht wird dies durch die konsequente Nutzung des einheitlichen Datenlexikons (data dictionary) im ISO-20022-Formatstandard, das eine einheitliche Basis für den Datenaustausch darstellt, indem es Datenelemente aus der Kunde-Bank-Nachricht (pain ) in die Interbankenebene (pacs) bis hin zur Bank-Kunde-Sphäre (camt) ohne Konvertierungen transportiert.

Wo sich SEPA weiterentwickelt, z. B. durch die Einführung von Instant Payments, hinkt der für SEPA verwendete ISO-20022-Standard noch immer hinterher: nämlich auf der vom EPC definierten Basis von 2009. Da sich auch dieser ISO-Standard stetig weiterentwickelt, um den aktuellen Entwicklungen Rechnung zu tragen, plant die für die Weiterentwicklung des SEPA Schemes zuständige Arbeitsgruppe des EPC die Migration aller Schemes (SCT, SCT Inst, SDD Core, SDD B2B) auf die Version 2019 des ISO-20022-Standards. So soll der Wechsel in 2020 angekündigt und im Rahmen einer Big-Bang-Umstellung (der Interbanken-Formate) zum November 2022 final gültig werden. Diese Änderung befindet sich derzeit als Major Change Request neben weiteren in einer Öffentlichen Konsultationsphase, um Anmerkungen aus dem Kreis der an der Konsultation teilnehmenden Parteien einzufordern.

Als einer der Gründe, warum dieser CR als wichtig angesehen wird, gilt die zukünftige Unterstützung von Request to Pay, die mit der derzeitigen ISO-Version nicht möglich ist, da zukünftig benötigte Elemente im Format nicht vorhanden sind. Aber auch für andere zukünftige Entwicklungen ist ein aktueller Stand des ISO-Standards erforderlich, insbesondere auch vor dem Hintergrund der TARGET2- und SWIFT-MX-Migrationen, die ebenfalls die Version 2019 des ISO-Standards zugrunde legen.

Gute Nachrichten hierbei: ISO 20022 ist ein in der SEPA-Welt bereits etablierter Standard. Anders als bei der SEPA-Einführung muss hier kein neues Format eingeführt werden und es müssen auch keine Altformate im großen Stil abgelöst werden. Vorhandene Systeme müssen „nur“ angepasst und mit den Änderungen, wie z. B. neuen Datenelementen, umgehen lernen. Dennoch besteht die Herausforderung darin, eine Big-Bang-Migration mit Auswirkungen auf den Interbanken-Zahlungsverkehr sowie Formate an der Kunde-Bank-Schnittstelle zu meistern.

Schlechte Nachrichten: Aufgrund aktueller Entwicklungen fällt nun das SEPA-Umstellungsdatum mit dem Beginn der Umstellungsphase von SWIFT MT auf MX zusammen. Den ursprünglichen Ansatz, das Umstellungsdatum für die SEPA-Umstellung auf 2022 zu legen, hatte man deswegen gewählt, um die drei großen Migrationen – TARGET2, SWIFT MX und SEPA ISO20022 Version 2019 – nicht nahezu zeitgleich durchführen zu müssen und den dafür erforderlichen Aufwand zu entzerren. Sollte nun auch TARGET2, wie erste Forderungen aus dem Markt vermuten lassen, eine Verschiebung der geplanten Big-Bang-Migration um ein Jahr vornehmen, fallen nun doch wieder sämtliche Migrationen zeitlich zusammen, was die betroffenen Finanzdienstleister vor große Herausforderungen stellt und den ursprünglichen Ansatz der Entzerrung zunichtemacht. Die Schuldfrage hierfür ist schnell beantwortet: die globale Corona-Pandemie, die unser Leben und die Wirtschaft derzeit vor harte Prüfungen stellt.

Banken und Kreditinstitute sind in dieser Situation aufgefordert, die weitere Entwicklung im Auge zu behalten und sich auf die anstehenden Änderungen einzustellen. Wir werden die weitere Entwicklung ebenfalls eng begleiten und nach Abschluss der Marktkonsultation weiter über die SEPA-ISO-Änderungen berichten.

Autor: René Keller

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