Zahlungsverkehr 2021: Keine Atempause

Für die europäischen Zahlungsdiensteanbieter neigt sich ein herausforderndes Jahr dem Ende zu. Corona war auch hier das alles bestimmende Thema. Im Individualzahlungsverkehr, verstanden als Interbanken- und Auslandszah-lungsverkehr, ist Corona mitursächlich für die Verschiebung der TARGET2-Konsolidierung und der SWIFT ISO20022 Umstellung. Für den kartengestützten Zahlungsverkehr brachte die Pandemie negative, aber auch positive Effekte: Zum einen führte Corona zu einem massiven Schub an kartenbasierten und hier insbesondere kontaktlosen Transaktionen. Solch eine Entwicklung hätte normalerweise mehrere Jahre gedauert und zudem signifikante Marketinginvestitionen der großen Card-Schemes erfordert. Auf der anderen Seite erlitten viele Marktteilnehmer im Kartengeschäft coronabedingt massive Umsatzeinbrüche – insbesondere diejenigen, die stark im Bereich Gastronomie, Reisen und Events engagiert sind. 

Wer nun denkt, dass es in 2021 für die Zahlungsverkehrsbranche eine Atempause gibt, irrt. Schließlich gehen im kommenden Jahr gleich zwei konkrete Projekte live. Andere Vorhaben müssen schon vorbereitet werden, auch wenn der tatsächliche Marktstart erst 2022 oder später geplant ist. Zusammen mit den ohnehin schon gravierenden strukturellen Marktumbrüchen betrachtet, verdichtet sich der Eindruck, die Branche stehe vor einer Alpenüberquerung unter erschwerten Bedingungen.

Aber der Reihe nach: Unter den konkreten Themen des kommenden Jahres fällt die anstehende Einführung von Request to Pay (RTP) auf. Mit Start dieses Standards im Sommer 2021 wird der Zahlungsverkehr um einen wichtigen Bau-stein ergänzt (Siehe hierzu auch unser Whitepaper Teil 1 und Teil 2) . Viele Unternehmen drängen die Finanzdienstleistungsbranche seit Langem, mit dem Auf- und Ausbau von RTP zügig voranzuschreiten (Lesen Sie hierzu auch den Survey der EBA). Denn mit RTP werden Anwendbarkeitslücken in oder zwischen den existierenden Verfahren geschlossen. Dazu gehört die möglich werdende Verbindung von Rechnungs- und Zahldaten. Dies erleichtert die Abstimmungsprozesse im Rechnungswesen vieler Unternehmen erheblich. Oder die bisher fehlende Möglichkeit, Zahlungen am Point of Sales (POS) ohne Terminalstruktur elektronisch entgegennehmen zu können. Die Einrichtung eines POS wird mit RTP einfacher und mobiler. 

Zur weiteren Durchdringung von Echtzeitüberweisungen gemäß dem SCT Inst Scheme hat der EZB-Rat entschieden, dass alle in TARGET2 erreichbaren Zahlungsdienstleister, welche das SCT Inst Scheme gezeichnet haben, in TIPS (TARGET Instant Payment Settlement) erreichbar sein müssen. Entsprechend muss die Erreichbarkeit in TIPS entweder über eine direkte Teilnahme dort mit eigenem Konto oder über die Reachable-Party-Funktionalität gewährleistet sein. Darüber hinaus sollen alle ACHs (Automated Clearing Houses), welche Instant Payments anbieten, ihre technischen Konten von TARGET2 nach TIPS verlagern. Die Umsetzung der Beschlüsse ist für Ende 2021 vorgesehen.
Immerhin erfordern nicht alle 2021er-Themen von den Zahlungsdiensteanbietern eine derart große Betriebsamkeit: Die Anpassungserfordernisse aus den November-Changes des EPC sind eher überschaubar. Ob man das auch für die DFÜ- und SWIFT-Changes sagen kann, steht noch nicht fest. Es ist aber – zumindest für den reinen Zahlungsverkehr – sehr wahrscheinlich. Größere gesetzliche Fälligkeitsdaten stehen ebenfalls nicht an.

Aber es gibt natürlich noch all die Zahlungsverkehrsvorhaben, die in 2022 und den Folgejahren umgesetzt – und somit in 2021 vorbereitet – werden müssen. Eines der wichtigsten Projekte ist die weltweit anstehende Umstellung des Zahlungsverkehrs auf das ISO-20022-Format.
Im Individualzahlungsverkehr müssen beispielsweise die in 2022 anstehende TARGET2- und die in 2022 beginnende SWIFT-Umstellung vorbereitet werden. In beiden Bereichen stehen neben der reinen Formatumstellung umfangreiche Änderungen in den Abläufen an, wie etwa veränderte Zugangsmechanismen zu den entsprechenden Plattformen. Nach übereinstimmenden Schätzungen geht jedes dieser Projekte über die Dimensionen von SEPA hinaus. 

Im Massenzahlungsverkehr (SEPA) müssen sich Zahlungsdiensteanbieter für die in 2023 anstehende Umstellung der SEPA Schemes auf die (neuere) ISO-Version 2019 fit machen.
Angesichts der mit diesen Umstellungen verbundenen Kosten werden in 2021 Banken – vornehmlich Tier-2-Institute – die Abwicklung des Zahlungsverkehrs zunehmend auslagern oder zumindest Zahlungsverkehrssoftware „As a Ser-vice“ einkaufen. Die entsprechende Nachfrage ist bereits spürbar. Zudem dürften die Stimmen lauter werden, die nach günstigen, zentralen Angeboten für bankenübergreifende Services, wie beispielsweise Sanctions Screening oder KYC, rufen.
Schlussendlich müssen Banken und Finanzdienstleister 2021 Antworten auf anstehende strukturelle Marktumbrüche finden:

• Die Weiterentwicklung der European Payment Initiative (EPI): Gelingt es, eine einheitliche, innovative gesamteuropäische Zahlungslösung als Alternative zu bestehenden internationalen Zahlungslösungen und -systemen zu schaffen?
• Den weiter zunehmenden Druck von EU-Kommission und EU-Parlament auf die Interchange-Gebühren: Wie können Issuer auf eine mögliche „Zero-Interchange“-Regulierung reagieren? Wie sehen zukünftige Ge-schäftsmodelle aus?
• Die sich andeutende Verpflichtung aller Banken durch den EU-Gesetzgeber, Instant Payments anzubieten sowie die stärkere Berück-sichtigung von Verbraucherinteressen in der Rückabwicklung von Instant Payments Zahlungen. Sind die bestehenden Verarbeitungssysteme in der Lage, die zusätzlichen Mengengerüste zu verarbeiten?
• Die deutliche Konsolidierung von Abwicklungsdienstleitern, namentlich die Bildung zweier Konglomerate durch EquensWordline einerseits und NEXI/SIA/Nets andererseits: Was bedeutet das für die Zukunft von kleineren und mittleren Dienstleistern, insbesondere im Acquiring? 
• Die zunehmende Verwischung der Grenzen zwischen kartengestütztem und klassischem Zahlungsverkehr, wie beispielsweise die Aktivitäten von Mastercard (über Vocalink) im Clearing klassischer Bezahlverfahren: Wird es langfristig eine weitere Clearinginfrastruktur im Massenzahlungsverkehr geben? 
• Die anstehende Einführung von digitalem Geld, in Form von digitalem Zentralbankgeld aber auch in Form von Libra: Welche Auswirkungen hat das auf Bargeld oder kartenbasierte Zahlungen? Was bedeutet dies für die Rolle und das Geschäftsmodell von Banken?
• Die Konsequenzen der zunehmenden Verbreitung des Internet of Things (IoT) für den Zahlungsverkehr. Nur mit vollkommen autonomen, unterbrechungsfreien Zahlungsströmen zwischen den verbundenen Geräten können die Potenziale des IoT gehoben werden (Vgl. unsere Studie zum Thema Internet of Payments). Wie können dabei Compliance-anforderungen und IT-Sicherheitsaspekte erfüllt werden? Wie müssen die Verarbeitungssysteme für zusätzliche Milliarden von Transaktionen aufgerüstet werden?

Am chinesischen Neujahrstag 2021 beginnt das Jahr des Büffels. Die chinesische Astrologie schreibt ihm Geduld und Fleiß zu. Er ist stark und überwindet alle Schwierigkeiten. Die Zahlungsverkehrsbranche kann ihn gut gebrauchen.

Autor: Hubertus von Poser (Head of Consulting Payments)

Weiterlesen

Request to Pay (RTP): Mehrwert für das Kundenerlebnis im E-Commerce?

Tag für Tag stöbern zahlreiche Kunden in Online-Shops und fügen unterschiedlichste Artikel ihren Warenkörben hinzu, um sie im besten Fall zu kaufen und somit zu bezahlen. Dabei ist der letzte Schritt der Customer Journey, der Checkout-Prozess, ein sehr sensibler Punkt im Online-Shopping. Der kaufwillige Kunde erwartet an diesem Punkt für ihn passende, möglichst einfache und intuitive Zahlungsmöglichkeiten. Daher gehört es zu den wichtigsten Aufgaben des Onlinehändlers, dem Kunden stets eine Vielfalt an Zahlungsmöglichkeiten anzubieten.

Laut einer Studie vom EHI waren die Zahlarten Kauf auf Rechnung, Paypal sowie Lastschrift die größten Umsatztreiber am deutschen E-Commerce-Markt im Jahr 2019. So betrug ihr Anteil insgesamt knapp drei Viertel des Umsatzes (Kauf auf Rechnung 32,8 %, Paypal 20,2 %, Lastschrift 18,3 %) (Quelle: https://www.ehi.org/de/studien/online-payment-2020/). Bei der Zahlart Kauf auf Rechnung versendet der Onlinehändler vor Bezahlung die bestellte Ware zusammen mit einer Rechnung an den Kunden. Der Kunde kann schnell auschecken und wird lediglich aufgefordert, die Rechnung innerhalb eines bestimmten Zahlungsziels an den Onlinehändler zu begleichen. Zudem kann er bis zum Zahlungsziel flexibel entscheiden, ob er die Ware wirklich behält und bezahlt. Auch die Zahlart Paypal punktet mit ihrem schnellen Checkout-Prozess. Der Kunde muss sich nur mit seiner registrierten E-Mail-Adresse anmelden und kann seinen Kauf abschließen. Die dritte Zahlart Lastschrift ist ein altbekanntes, gern genutztes Verfahren. Der Kunde erteilt dem Onlinehändler die Einwilligung, dass dieser den Rechnungsbetrag von seinem Bankkonto abbuchen darf. Weitere Schritte sind nicht erforderlich. 

Warum also sind genau diese Zahlarten so beliebt? Alle drei haben ähnliche Charakteristika: Sie überzeugen mit einer intuitiven Handhabung, der Möglichkeit eines schnellen Checkout-Prozesses, einer Zahlungsübersicht sowie einer breiten Händlerakzeptanz.

Jedoch endet der Prozess der genannten Zahlungsarten im Status quo mit dem Abschluss der Bezahlung. Zusätzliche Informationen wie Rechnungsstellung, Garantiescheine und Versandinformation (Trackingnummer) werden dem Kunden zeitversetzt über das Händlerportal oder in der E-Mail-Kommunikation zur Verfügung gestellt.

Schlussendlich fehlt es im heutigen Online-Shopping-Prozess oftmals an einer konsolidierten Sicht über die Zahlungsdetails zur bestellten Ware, der Rechnung, der Garantie sowie der Versandinformationen.

Kann Request to Pay das fehlende Puzzlestück für eine erfolgreiche User Experience im E-Commerce sein?

Mit einem Blick auf den konzipierten Request-to-Pay-Prozess lassen sich die Möglichkeiten eines ganzheitlichen Bestellprozesses im Banking-Ökosystem ableiten. Folgender Prozess kann mittels RTP angestoßen werden: 

Abbildung: RTP-Prozess (Quelle: Eigene Darstellung)

Nachdem der Kunde seine Bestellung im Onlineshop des Händlers bestätigt hat, wird eine elektronische Zahlungsaufforderung als RTP-Datensatz durch den Händler initiiert. Dieser wird automatisch zur Bank des Kunden und anschließend zum Kunden (Zahlungspflichtiger) gesendet. Dem RTP-Datensatz können initial Zahlungsinformationen wie beispielsweise Rechnungen und Versandinformationen beigefügt werden oder über einen Link am Datensatz dem Kunden zu einem nachgelagerten Zeitpunkt verfügbar gemacht werden.
Dabei bietet das RTP-Verfahren dem Kunden (nach Erhalt der Zahlungsaufforderung) flexible Handlungsmöglichkeiten, um seine Zahlung abzuschließen:

• Jetzt akzeptieren und jetzt bezahlen 
• z. B. Kauf eines Filmes in einer Online-Videothek, der direkt konsumiert werden soll
• Jetzt akzeptieren und später bezahlen 
• z. B. Kauf von Schuhen, die erst anprobiert werden sollen
• Später akzeptieren und später bezahlen 
•  z. B. Warenversand vor Zahlungsangabe. Erste Händler pilotieren derzeit den Versand der Ware (z. B. Bekleidung) an den Kunden, ohne dass dieser auch nur eine Zahlungsangabe tätigen muss. Erst nach einer gewissen Zeit fragt der Händler mit einer Zahlungsaufforderung Daten und Bezahlung an.

Sofern der Kunde die Zahlungsaufforderung nach Erhalt akzeptiert und direkt mit einem (Instant-)Payments-Auftrag bezahlt, sendet die Bank des Kunden eine direkte Zahlungsbestätigung an die Händlerbank. Von der Händlerbank erhält der Händler (Zahlungsempfänger) wiederum die Eingangsbestätigung. Damit ist der Prozess von der Zahlungsaufforderung bis hin zur Zahlung abgeschlossen.
Dieser „reine“ Zahlungsprozess bietet für den Konsumenten erstmal keinen erheblichen Mehrwert im Vergleich zu den drei oben genannten Zahlungsarten. Wird jedoch der Zahlungsprozess in der Banking-App um Zahlungsinformationen wie Rechnungen, Garantieschein und Versandinformationen ergänzt, wird das Banking-Ökosystem zum zentralen Archiv von Online-Bestellungen und schafft ein neues Kundenerlebnis.

Soll der Request-to-Pay-Prozess zu einem erfolgreichen Zahlungsprozess im E-Commerce werden, müssen darüber hinaus folgende Faktoren ineinandergreifen:

1. Flächendeckende (Händler-)Akzeptanz von elektronischer Zahlungsaufforderung und Zahlung
2. Einbindung des gesamten Prozesses in das vorhandene Banking-Ökosystem (Banking-App)
3. Schaffung von Optionen für Teilzahlung sowie Zahlung zu einem späteren Zeitpunkt
4. Möglichkeit der Rückabwicklung bei z. B. Stornierung oder Paketverlus
5. Erweiterung der Zahlungstransaktion um die Übersicht der Einkäufe unterstützt durch z. B. Rechnungshistorie, Versandnummern und Garantiescheinen

Unter Berücksichtigung dieser Faktoren und im Zusammenhang mit Instant Payments kann Request to Pay das heute fehlende Puzzlestück für eine erfolgreiche User Experience im E-Commerce sein. Dabei gilt: Für eine erfolgreiche Implementierung wird eine ganzheitliche und kundenzentrierte Betrachtung vorausgesetzt.

Autor: Philipp Schröder

Weiterlesen

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

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

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

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

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

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

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

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

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

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

Es ist an der Zeit, zu planen

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

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

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

Wie also mit diesen neuen Anforderungen umgehen?

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

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

Die EBICS-API – Entkopplung von Fachlichkeit und Technik

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

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

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

Autoren: Carsten Miehling und Michael Lembcke

Mehr Informationen:
Webseite: EBICS 3.0 | challenge accepted

Flyer: EBICS 3.0 – Was ändert sich?

Weiterlesen

EBICS einrichten – einfach Schritt für Schritt

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

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

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

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

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

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

Autor: Christian Veith

Weiterlesen

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

Weiterlesen

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

Weiterlesen

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

Weiterlesen

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

Weiterlesen

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

Weiterlesen

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

Weiterlesen