Request to Pay – kein Problem dank EBICS

Attraktiv für Verbraucher, wichtige Ergänzung des Kaufs am Point-of-Sale (POS) aus Geschäftskundensicht – so fallen derzeit die Bewertungen für Request to Pay (RTP) aus. Die neue Initiative für eine einheitliche Zahlungsaufforderung (EPC014-20) im europäischen Raum wurde im Juni 2020 vom European Payments Council (EPC) definiert.
Mit einer RTP-Lösung können Kunden ihren Einkauf nun auch direkt beim Kundenberater zahlen, ohne extra eine Kasse aufsuchen zu müssen. Das Einkaufserlebnis wird sich dadurch wesentlich verändern. Im Onlinehandel ist RTP im Vergleich zur Lastschrift die für den Anbieter bessere Zahlungsvariante, schließlich kann letztere gegebenenfalls widerrufen werden. Mit der aus dem RTP resultierenden Überweisung entfallen zusätzliche Gebühren, wie sie bei Kreditkarten, PayPal und ähnlichen Lösungen entstehen. Das gilt auch für darüber hinaus gehende Infrastrukturkosten der Prozessoren.

Ein weiterer Vorteil ist es, dass sich mit RTP alle Informationen transportieren lassen, die die folgende Überweisung aus Sicht des Zahlungsempfängers enthalten muss. Zielsetzung dabei ist eine möglichst vollautomatische Kontierung des Zahlungseingangs. Dies wird dadurch erreicht, dass jede der beteiligten Parteien dazu verpflichtet ist, die einmal erhaltenen Daten zur Weiterverarbeitung an die nächste Instanz weiterzureichen. Damit private Konsumenten diese neue Idee flächendeckend nutzen können, müssen aber zunächst entsprechende mobile Anwendungen für Zahlungspflichtige entstehen. Dies wird zweifelsohne passieren – wenn auch noch einige Zeit ins Land gehen dürfte.

Aktuell noch unklar ist in der EPC-Initiative, wie die propagierte universelle Erreichbarkeit des Zahlungspflichtigen einheitlich realisiert werden kann. Das Grundkonzept, dass der RTP-Empfänger beliebig adressiert werden kann, behindert in diesem Fall eine schnelle Umsetzung. Wie so häufig spricht der EPC auch diesmal davon, dass die neuen Service-Provider hier die Initiative ergreifen sollen. Viele Fragen stehen aber noch im Raum. Die Spezifikation lässt die Antworten offen und baut auf Lösungen der noch nicht vorhandenen künftigen Anbieter.

Genau hier liegt für die Banken die Chance zum aktiven Handeln – und zwar jetzt! Die EBA hat bereits einen für Europa einfachen und umfassend funktionierenden Vorschlag gemacht und setzt diesen bereits in Infrastrukturlösungen um. Das Konzept ist simpel und baut auf dem SEPA-Clearing der Europäischen Union auf. Im RTP-Netz der EBA werden die Zahlungspflichtigen eindeutig mit ihrer IBAN identifiziert. Über das ZV-Clearing der EBA lässt sich nun jede Bank des Zahlers identifizieren und erreichen. Damit erhalten die europäischen Banken wieder Kontrolle im Massenzahlungsverkehr und haben eine europaweite Alternative zu den vielen untereinander mobilen, jedoch inkompatiblen nationalen Zahlungsverfahren im Angebot, insbesondere auch PayPal.

Erhält das Finanzinstitut des Zahlers einen RTP, setzt es den Betreffenden von der Zahlungsaufforderung über bereits vorhandene Online-Banking-Kanäle in Kenntnis. Idealerweise geschieht dies direkt mittels der zugehörigen App der Bank auf einem Mobilgerät. Der Zahlungspflichtige kann dann die Ware sofort bezahlen. Hierfür sind jedoch noch Aktualisierungen der Kundensysteme bei Unternehmen und Zahlern notwendig.

Ebenso wie im B2C-Geschäft lässt sich RTP auch im B2B-Geschäft nutzen. Zumal die Einführung sehr viel einfacher und schneller möglich ist als im Konsumentengeschäft. Mit dem EBICS-Protokoll nutzen schon massenhaft Unternehmen einen Kanal, der sich sehr einfach für RTP erweitern lässt. Häufig reicht schon eine einfache Konfigurationsanpassung in Form von neuen Auftragsarten. So können nun Unternehmen durch Einreichung eines RTP-(pain.013)-Auftrags eine Zahlungsaufforderung an ein anderes Unternehmen versenden. Dieses erhält die Zahlungsaufforderung ebenfalls per EBICS. Als Zieladresse reicht einfach die IBAN, und der Rest läuft europaweit elektronisch – und zwar über die vorhandenen Netze der EBA als zentraler Clearingplattform. Somit ist im Prinzip schon mal jede Firma und jeder Kontoinhaber im SEPA-Raum erreichbar. 

Die zugehörigen Statusrückmeldungen signalisieren dem Rechnungsaussteller in kurzer Zeit, ob der Zahlungspflichtige den gesendeten RTP ablehnt oder akzeptiert. Im letzteren Fall kann die Ware versendet werden. Nicht immer muss die Zahlung sofort initiiert werden, auch Zahlungen zu einem späteren Zeitpunkt werden von der RTP-Spezifikation unterstützt. Beim RTP-Verfahren werden grundsätzlich zwei verschiedene ISO-XML-Formate (pain.013.001.07, pain.014.001.07) genutzt. Bei Bedarf lässt sich auch ein Rückruf implementieren. Alles ist einfach per EBICS transportierbar.
Für eine komfortable Nutzung von RTP können nun die EBICS-Kundensysteme und Firmenkundenportale entsprechende Erfassungs- und Upload-Funktionen umsetzen und die Statusrückmeldungen in ihren Oberflächen anzeigen. Sollte einmal keine Reaktion des RTP-Empfängers erfolgen, lässt sich der Status jederzeit aktiv nachfragen. Oder es kann durch einen Recall (pain.056) ein Rückruf des RTPs initiiert werden.

Da sich die existierenden SEPA-Überweisungen oder Instant Payments im Prozess verwenden lassen, rücken sekundenschnelle Zahlungen und Kontoeingangsmeldungen in den Bereich des Möglichen. Der Vorteil eines RTP gegenüber einer Lastschrift liegt auf der Hand: Es sind keine aufwändigen Mandate sowie deren Lagerung notwendig. Zudem sind solcherart geleistete Zahlungen per se nicht rückrufbar. Für den Händler reduziert RTP damit das Risiko eines Lastschriftwiderrufs, das sonst für einige Wochen existiert.

Für Unternehmen ist jetzt der richtige Zeitpunkt, die Voraussetzungen für RTP zu schaffen. Dann sind sie bereit, wenn die Konsumenten das neue Zahlungsformat jederzeit, mobil und ortsungebunden einsetzen können.

PPI wird in 2021 in den TRAVIC-Produkten die Voraussetzungen für einen europaweiten Erfolg des RTPs schaffen. TRAVIC-Port wird die Erfassung und den Upload von RTP ermöglichen, TRAVIC-Corporate übernimmt die Autorisierung des Einreichers und Validierung des RTP-Auftrages und der TRAVIC-Payment Hub mit TRAVIC-Interbank wird die Weitergabe in das EBA-Netz unterstützen. Banken können durch RTP ihre ehemals zentrale Bedeutung im Zahlungsverkehr, die sie an alternative Verfahren wie PayPal und ähnliche verlorenen haben, wenigstens teilweise wiedererlangen.

Autor: Michael Schunk

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)

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

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

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

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

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

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

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

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

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

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

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

Es ist an der Zeit, zu planen

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

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

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

Wie also mit diesen neuen Anforderungen umgehen?

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

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

Die EBICS-API – Entkopplung von Fachlichkeit und Technik

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

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

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

Autoren: Carsten Miehling und Michael Lembcke

Mehr Informationen:
Webseite: EBICS 3.0 | challenge accepted

Flyer: EBICS 3.0 – Was ändert sich?

EBICS einrichten – einfach Schritt für Schritt

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

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

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




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

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



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

Autor: Christian Veith

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