SWIFT gpi - von der Pflicht zur Kür

Zum November 2020 verlangt das SWIFT-Release für den Zahlungsverkehr ausnahmsweise mal keine Formatänderungen. Die wurden wegen COVID-19 auf nächstes Jahr verschoben. Aber die Forderung nach der sogenannten „Universal Confirmation“ im Rahmen von SWIFT gpi ist geblieben. Vereinfacht bedeutet das: Alle FIN-Teilnehmer müssen die Gutschrift im MT103-Format auf dem Konto des Begünstigten an SWIFT zurückmelden, und zwar an den Tracker. Auch Ablehnungen müssen so gemeldet werden, die eigentliche Rückgabe entfällt dadurch aber nicht. Also muss der Zahlungsverkehr wieder ein (regulatorisches) MUSS-Projekt stemmen, was weniger Ressourcen für Kundenprojekte bedeutet. Aber muss das so sein? Um diese Frage zu beantworten, wollen wir uns erst einmal ansehen, was SWIFT gpi bedeutet.

Seit 2016 nimmt das Thema SWIFT gpi (global payment innovation) immer breiteren Raum ein. Kern ist eine eineindeutige Referenz, die UETR (unique end-to-end-reference), die der Zahlung am Anfang der Korrespondenzbankkette mitgegeben wird und über alle Stationen beibehalten wird. Damit ist ein Track & Trace“ von Zahlungen möglich, was schon lange im AZV (Auslandszahlungsverkehr) gefordert worden war. Die Informationen werden im Tracker gesammelt. Der Tracker ist eine zentrale Datenbank in der FIN-Wolke bei SWIFT, die die nötigen Informationen bei jeder Zahlung in FIN automatisch mitliest und durch weitere Meldungen der gpi-Banken vervollständigt wird.

Am Anfang gab es die UETR nur innerhalb der CUG (closed user group) der an der Initiative gpi teilnehmenden Banken, und das auch nur für Kundenzahlungen (MT103), der Standard-Service wird auch gCCT (gpi for Corporate Credit Transfer) genannt, der dann bald von gCOV ( gpi for Cover Payments) vervollständigt wurde. Seit 2018 sind alle FIN-Banken verpflichtet, die UETR nach den Kundenzahlungen (MT103) nun auch für Bank-Bank-Zahlungen (MT202/205) – also für alle Zahlungen – zu unterstützen. Erste positive Auswirkungen können vermeldet werden. Mit der UETR ist es nun möglich, Aussagen zu treffen wie z. B. „40 % aller gpi-Zahlungen sind innerhalb von 5 Minuten final“ oder „75 % aller gpi-Zahlungen sind innerhalb von 6 Stunden final“. Vorher gab es nur Beispiele für Zahlungen, die sehr spät (oder gar nicht) oder ohne Verwendungszweck, dafür mit hohen Gebührenabzügen (auch bei OUR) ankamen, was zu vielen Reklamationen mit entsprechenden Nachfragen führte. Eine etwas unerwartete Auswirkung der gpi-Einführung war der drastische Rückgang von Nachforschungsanfragen.

Eine gpi-Bank verpflichtet sich zur möglichst taggleichen Verarbeitung, zum Verzicht auf Gebührenabzug bei OUR, zur ungekürzten und unveränderten Weitergabe des Verwendungszwecks (analog wie bei SEPA) – eigentlich lauter Selbstverständlichkeiten – und natürlich zum (möglichst zeitnahen) Informationsaustausch nicht nur zum Status sondern auch über Gebühren und Kurse mit dem Tracker. Diese Informationen stehen dann der Zahlerbank als gpi-Bank zur Verfügung. Dadurch kann ein weiteres Manko des AZV – die fehlende Gebührentransparenz – abgebaut werden. Diese Vorteile und insbesondere diese Informationen können dann dem Zahler übermittelt werden.

Und dann noch das Thema Rückrufe. Wenn es mal Not tut, dann sollte eine Zahlung entlang der ausführenden Bankenkette auch noch zu stoppen sein. Aber so wie die Zahlung über die Kette schrittweise abgearbeitet wird, so wird auch die Rückrufnachricht je beteiligter Bank abgearbeitet. Hier setzt der gpi-Zusatzservice gSRP (gpi Stop and Recall Payments) an. Der Rückruf wird an den Tracker gemeldet und der nächste Versuch, eine Zahlung mit der betreffenden UETR an FIN zu geben, wird abgelehnt. Die lange Kette wird übersprungen.

Mit der „Universal Confirmation“ wird nun die Transparenz vervollständigt. Damit bekommt die Zahlerbank nicht nur die Info „Zahlung bei der letzten Bank in der FIN-Kette angekommen“, sondern den Status „Zahlung beim Empfänger angekommen“. So eine Quittung war bei der Definition von SEPA Instant Payments von Anfang an integraler Bestandteil, aber das war ja auch fast 50 Jahre nach den ersten SWIFT-Nachrichten.

Die FIN-Banken werden nun zur Meldung „Universal Confirmation“ verpflichtet. Das gilt nur für Kundenzahlungen (MT103), nicht für alle Zahlungseingänge (M202/205). Meldungen müssen auch für TARGET2-Eingänge abgegeben werden, denn die werden ja über FINCopy transportiert. Als „Goodie“ gibt es den (manuellen) Webzugriff auf diesen Tracker, der bisher überhaupt nur gpi-Banken zur Verfügung stand.

Für die Meldung zur „Universal Confirmation“ hat die Bank bis zu 2 Werktage Zeit (eigene Feiertage sind also ausgenommen). Dieses SLA wird auch gemessen und das Wohlverhalten anderen Banken angezeigt, was aber erst ab Mitte 2021 beginnen soll. Der Webzugang zum Tracker wird auch vom Wohlverhalten abhängig gemacht.

Banken mit kleinstem Volumen könnten eine manuelle Meldung im Tracker in Betracht ziehen. Für automatisierte Lösungen sollte z. B. die ZV-Plattform einen der von SWIFT angebotenen Wege (MT199 oder API) unterstützen. Zusätzlich gibt es eine sogenannte CSV-Lösung, bei der aus einem bestimmten CSV-Report im SWIFT-Interface dann entsprechende Meldungen an den Tracker erzeugt werden.

Also muss eine Non-gpi-Bank fast alles das erfüllen, was eine gpi-Bank auch erfüllen muss. Der fehlende Schritt ist nicht mehr groß, der Nutzen für die eigenen Kunden kann enorm sein. Und mit den Möglichkeiten für gpi bei Bank-an-Bank-Zahlungen (MT202/205 – gFIT genannt, das steht für Financial Institution Transfer service, eine Option für gpi-Banken) kann den bankinternen Abteilungen wie Treasury oder Geldhandel auch die Sicherheit „Zahlung ist angekommen“ gegeben werden.

Es kommt aber nicht darauf an, die Statusmeldungen aus dem Tracker für gesendete Zahlungen als Bank zu bekommen, sondern vielmehr darum, dem Kunden einen Mehrwert zu bieten – im besten Fall die Quittung „Zahlung angekommen“ (inkl. der Information zu Gebühren und Umrechnungskurs) zur Verfügung zu stellen. Von der Minimalversion des manuellen Zugriffs in der eigenen (Firmenkunden-)Hotline auf den Tracker, über Self-Service-Angebote im Online-Banking-Portal bis hin zur aktiven Info durch Notification von Statusmeldungen an den Firmenkunden reichen die Servicelevel, die eine Bank bieten kann. Und das geht eigentlich nur, wenn man den Schritt von der „Universal Confirmation“ hin zum gpi-Standard-Service geht und sich für gpi entscheidet. Hieran werden sich Banken mit Firmenkundengeschäft in Zukunft messen lassen müssen.

Hier ist bereichsübergreifende Zusammenarbeit gefordert, die Leistungen können nicht allein von der ZV-Abteilung oder gar nur von der IT selbst erbracht werden, wie es oft bei „regulatorischen“ Projekten bei einem SWIFT-Release erwartet wird. Mit einer Beratung, die den Gesamtprozess im Blick hat, kann dies gelingen.

Zusammengefasst kann man also feststellen: Von der Pflicht zur Kür ist der Weg gar nicht so weit, die Aussichten auf zusätzliche Services für Firmenkunden und aber auch bankinterne Bereiche ist enorm.


Autor: Mario Reichel

ISO 20022 – trotz Verschiebung aktueller denn je

Die Entscheidung ist gefallen: Am 27.07.2020 hat sich die EZB dem Votum der Europäischen Bankencommunity angeschlossen und einer Verschiebung des Go-Live-Termins für die T2-T2S-Konsolidierung um ein Jahr auf November 2022 zugestimmt. Ebenso wurde auch der Migrationszeitpunkt für das Eurosystem Collateral Management System (ECMS) von November 2022 auf mindestens Juni 2023 verschoben.

Die europäischen Banken hatten sich in der im Mai durchgeführten Umfrage dafür ausgesprochen, die Migration zu verschieben. Gründe hierfür sind neben den Auswirkungen der Corona-Pandemie vor allem die von SWIFT bereits verkündete Verschiebung der ISO-Migration für die Cross-Border Payments (AZV). In vielen Banken laufen beide Migrationsszenarien in einem Projekt zusammen, da eine Trennung zwischen dem Zahlungsverkehr über TARGET2 und dem Auslandszahlungsverkehr schlicht nicht möglich ist. Gerade große Banken, die ein umfangreiches Korrespondenzbankgeschäft betreiben, sahen große Risiken bei einem Auseinanderlaufen der Migrationstermine. Mit dieser Entscheidung wurden nun beide Termine wieder synchronisiert. Auch EBA-Clearing hat sich angeschlossen und ihre Migration auf 2022 verschoben.

Die Erleichterung um die Verschiebung war sicher groß – doch was bedeutet diese Entscheidung jetzt für die Banken und ihre Projekte? Das, was jetzt am allerwenigsten passieren darf, ist, dass sich Banken zurücklehnen und ihre Projekte herunterfahren, da ja jetzt noch ein Jahr länger Zeit ist für die Umsetzung. Das wäre zum derzeitigen Zeitpunkt die schlechteste Lösung. Viele Banken haben den Aufwand, den die TARGET2-Umstellung mit sich bringt, unterschätzt. Vielmehr bietet die Verschiebung jetzt die Gelegenheit, mit voller Kraft in den Projekten weiterzumachen, um die verlorene Zeit aufzuholen. Sich zurückzulehnen und wohlmöglich erst Anfang 2021 dort weiter zu machen, wo man jetzt aufhört, ist keine Option. Auch ist zu beachten, dass die Startphase der User-Tests nur um neun Monate von März 2021 auf Dezember 2021 verschoben wurde. Ein Freisetzen von externen Ressourcen wird dazu führen, dass die Leute, die bisher in den Projekten gearbeitet und sich Wissen angeeignet haben, nicht mehr zur Verfügung stehen werden.

Auch ist zu bedenken, dass die Spezifikationen, die in diesem Jahr bereits zwei neue Anpassungen erfahren haben, weiterhin angepasst werden. Der EZB liegen noch Change Requests vor, die für die Migration im November 2021 nicht im Fokus lagen. Mit der Verschiebung wird sich dies sicher ändern. Es ist zu erwarten, dass mit den neuen UDFS im November weitere Funktionalitäten angeboten werden, die zu bewerten und zu implementieren sind.

Auch das Zielbild von SWIFT ist noch nicht klar definiert. Bisher ist bekannt, dass eine Transaction Management Plattform gebaut werden soll, die als zentraler „Hub“ den Auslandszahlungsverkehr bewältigen soll. Hierzu gibt es noch keine öffentlich bekannten Spezifikationen. Zudem werden derzeit auch neue ISO-Nachrichtentypen definiert, beispielsweise für Gebühren und Schecks, die zusätzlich zu betrachten und umzusetzen sind. Somit ist in der bevorstehenden ISO-Migration weiterhin viel Bewegung und Unsicherheit vorhanden. Darf man sich da nicht sogar die Frage stellen, ob es bei SWIFT nicht sogar zu einer weiteren Verschiebung kommen wird? Wie sähe dann eine Reaktion der EZB aus? Kann es auch bei TARGET2 noch zu einer weiteren Verschiebung kommen oder würde man dann ein Auseinanderlaufen der Migrationstermine in Kauf nehmen? Wie geht man mit Änderungen bei bereits harmonisierten Nachrichtenformaten, etwa pacs.004, um?

Doch damit nicht genug, sorgt auch die Entscheidung der EZB bezüglich Instant Payments für Aufsehen. Basierend auf Diskussionen mit Marktteilnehmern der AMI-Pay hat der EZB-Rat beschlossen, dass zum einen alle in TARGET2 erreichbaren PSPs, welche das SCT-Inst Scheme (also Instant Payments) gezeichnet haben, in TIPS erreichbar sein müssen. Zum anderen sollen alle ACHs, die Instant Payments anbieten, ihre technischen Konten von TARGET2 nach TIPS verlagern. Die Umsetzung ist für Ende 2021 vorgesehen. Damit wird seitens der EZB TIPS quasi verpflichtend für die Teilnehmer gemacht, die heute bereits am Verfahren Instant Payments teilnehmen. Das hat insoweit Bedeutung, da ein Großteil der Banken heute das RT1-Verfahren der EBA nutzen.

Auch wurde bislang nur die Entscheidung getroffen und verkündet. Weitergehende Beschreibungen wie beispielsweise technische Details sind noch offen und werden irgendwann später veröffentlicht. Dazu muss man sich auch die Frage stellen, wie ein zukünftiges Preismodell aussieht, insbesondere falls Gebühren für cross-ACH-Transaktionen erhoben werden. Wie kann ein Transaktionsentgelt aussehen und welche Auswirkung hat das auf die Preisgestaltung der Clearinghäuser? Ebenso stellt sich die Frage, ob für das Settlement der Positionen etwa von RT1 ein erhöhtes Settlementrisiko besteht, da mit TIPS ein weiterer Teilnehmer in der Kette einzubinden ist.

Damit nicht genug, stellt auch SEPA - nach den kürzlich veröffentlichten Plänen des EPC - in 2023 auf die neue ISO-Version 2019 um. Der derzeitige Abstand von einem Jahr zur Migration von TARGET2 und SWIFT mag lange erscheinen, aber auch hier müssen im Vorfeld die Spezifikationen gelesen werden, Fachkonzeptionen erstellt und Systeme vorbereitet werden. Trotz der jetzt bekannten Verschiebung auf 2023 ist auch diese Migration nicht zu unterschätzen und wir empfehlen, sich mit diesem Thema so früh wie möglich zu beschäftigen.

Wie man sieht, kommen in den nächsten drei Jahren sehr viele Themen rund um ISO 20022 auf die Banken zu und jede Bank ist gut beraten, die gewonnene Zeit durch die Verschiebung für eine Neupriorisierung zu nutzen. Hierfür ist ein sehr spezifisches Know-how gefragt, und man sollte sich nicht kurzfristigen Budgetüberlegungen hingeben und Ressourcen freistellen, die dann 2021 wieder dringend benötigt werden.

Autoren: Sabine Aigner, Thomas Ambühler

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: