EBICS-Security – Wann ist es Zeit für das Update Ihres Kundensystems?

Mit EBICS sind verschiedene Sicherheitsfunktionen und -vorgaben spezifiziert, die von Kunden und Banken einzuhalten sind. Die Bank muss stets darauf achten, dass die aktuellen Vorgaben in ihrem EBICS-Bankrechner angeboten und unterstützt werden. Aber auch der EBICS-Kunde und der einzelne EBICS-Teilnehmer selbst sind dafür verantwortlich, stets Kundensoftware einzusetzen, die den aktuellen EBICS-Sicherheitsstandards entspricht. Daher sind nicht nur aufgrund von funktionalen Anpassungen, sondern auch aus Sicherheitsgründen regelmäßige Softwareupdates der EBICS-Clientsysteme unerlässlich.

Ist eine bestehende EBICS-Clientsoftware schließlich durch Updates auf den neuesten Stand gebracht, heißt das jedoch nicht, dass diese EBICS-Software dann auch automatisch über die aktuellste EBICS-Version und das neueste Sicherheitsverfahren mit der Bank kommuniziert. Je nach zuvor genutzter EBICS-Version und Clientfunktionalität müssen dazu erst noch die verschiedenen Applikationsschlüssel für Verschlüsselung (E002), Authentifikation (X002) und Autorisierung (A004, A005 oder A006) sowie die neu zu nutzende EBICS-Version aktualisiert und mit dem oder den EBICS-Bankrechnern ausgetauscht werden. Zudem könnte es erforderlich sein, die Internetverschlüsselung (TLS) durch einen neuen Zertifikatsaustausch auf eine neuere und sichere Version zu aktualisieren. Diese Art von Aktualisierungen erfordern i.d.R. aktives Handeln und manuelle Eingriffe des EBICS-Teilnehmers.

Warum sind diese Aktualisierungen wichtig?

Für die EBICS-Kommunikation über das Internet sind eigene Sicherheitsverfahren spezifiziert. Diese werden von der EBICS-Gesellschaft im Laufe der Zeit mit neuen EBICS-Versionen immer wieder aktualisiert und an die aktuellen Sicherheitsbedürfnisse angepasst. Ein Beispiel stellen die Schlüssellängen dar. So sind für die Verschlüsselung (E002), Authentifikation (X002) und Autorisierung (A004, A005 oder A006) in älteren EBICS-Versionen noch Schlüssellängen von 1.024 Bit zulässig. Diese Länge entspricht nicht mehr den aktuellen Sicherheitsanforderungen, denn zu kurze Schlüssel gelten als unsicher. Neuere EBICS-Versionen hingegen lassen derzeit nur Schlüssel mit einer Mindestlänge von 2.048 Bit zu. Ein anderes Beispiel sehen wir bei den genutzten Verfahren und Versionen der TLS-Verschlüsselung. Um Sicherheitsempfehlungen, wie z. B. den Empfehlungen des BSI in Deutschland flexibler folgen zu können, hat die EBICS-Gesellschaft für EBICS 3.0 die entsprechenden Vorgaben in einem eigenen Anhang Transport Layer Security zur Spezifikation ausgelagert. Da rückwirkend die Spezifikation zu EBICS 2.5 nicht angepasst werden konnte, hat die DK (Die Deutsche Kreditwirtschaft) 2019 unter dem Titel Empfehlungen zu EBICS-Sicherheitsverfahren und Schlüssellängen zudem ein eigenes Empfehlungsschreiben zu den in EBICS zu nutzenden Sicherheitsverfahren herausgegeben. Siehe hierzu auch www.ebics.de und www.ebics.org.

Um den EBICS-Teilnehmern einen weichen Umstieg auf neuere EBICS-Versionen und Sicherheitsstandards zu ermöglichen, bieten die meisten Banken ihren Kunden jedoch parallel noch die älteren Verfahren an. Leider lässt sich feststellen, dass von Kunden dann aber die Gelegenheit zur EBICS-Aktualisierung in vielen Fällen nicht genutzt wird. Viele verharren auf älteren Systemen und Verfahren. Damit fällt es dann wiederum den Banken, schwer die alten Verfahren abzuschalten.
Am Ende erwartet jeder Beteiligte in der EBICS-Kommunikation, dass ein sicherer Datenaustausch gegeben ist. Einen Schaden möchte niemand erleiden. Also sollte auch jeder dafür Sorge tragen, dass er seinen Teil dazu beträgt. Natürlich ist die EBICS-Sicherheit nicht das Einzige, was Banken und Firmenkunden im Auge halten müssen. Letztendlich müssen heutzutage alle Beteiligten in ihrer Infrastruktur und ihren Softwarelösungen alle erdenklichen Sicherheitsmaßnahmen ergreifen, um Missbrauch und Schaden vorzubeugen.

Also warum noch warten? Gehen wir es an.

Autor: Michael Lembcke

Open Banking: EBICS versus API

Open Banking ist einer der Megatrends, den viele Banken angeblich zu verschlafen drohen. Weil kaum eine PSD2-Schnittstelle marktreif zu sein scheint, hat die Bankenaufsicht jetzt bis Dezember 2020 eine Übergangsfrist eingeräumt. Doch das Problem liegt woanders: Viele Institute verspüren nur wenig Lust, viel Geld in die Hand zu nehmen, um Anbietern von Open-Banking-Schnittstellen das Leben zu erleichtern – zumal etablierte Protokolle wie FinTS und EBICS viel mehr leisten als die „APIisierung“ des Bankgeschäfts bisher hervorgebracht hat.

Beide Protokolle, FinTS und EBICS, umfassen heute schon fast alle Bereiche des Bankings, vom Zahlungsverkehr über den Wertpapierhandel bis hin zum Kreditgeschäft. Insgesamt stehen weit mehr als 200 Prozesse bereit, die sowohl die fachlichen Schnittstellen verbindlich beschreiben als auch die technische Kommunikation der beteiligten Partner untereinander. Seit den 90er-Jahren geben HBCI und FinTS bereits die Richtung für offene Standards in der Kommunikation mit Banken vor. EBICS ist von der Deutschen Kreditwirtschaft (DK), beziehungsweise deren Vorläufer, schon vor mehr als zehn Jahren als verbindlicher Standard für die Kommunikation mit Firmenkunden eingeführt worden. Open Banking ist also seit vielen Jahren bereits Realität in Deutschland.

Keine einheitliche PSD2-Schnittstelle in Sicht

So gut die Idee von Open Banking auch ist. Die auch durch PSD2 forcierte Debatte lässt viele Banken, selbst die willigen, ratlos zurück. Einerseits soll unter anderem durch PSD2 ein Open-Banking-Standard für ganz Europa entstehen. Andererseits hat der Gesetzgeber bewusst offengelassen, wie die Kommunikation genau stattfinden soll und wie sie abzusichern ist. Die Folge: Anbieter von Open-Banking-APIs drängen die Banken dazu, ihre Lösungen zu implementieren und ihre ureigenen Interpretationen von Open Banking zu übernehmen, nur um ja nichts zu verpassen. Hinzu kommt, dass verschiedene Initiativen in den unterschiedlichen Ländern Protokolle zur technischen/fachlichen Nutzung entwickeln, die zu einem Wildwuchs an API-Dialekten führen werden. Länderübergreifende Konzeptionen dagegen sind noch bei weitem nicht in Sicht.

All dies kann sich für die Institute zu einem Fass ohne Boden entwickeln, wenn nicht bald eine einheitliche PSD2-Spezifikation vorliegt, an der sich jede Bank orientieren kann. Solange das nicht passiert, dürften viele Open-Banking-Träumereien unerfüllte Wünsche bleiben. Denn die Öffnung hat per Gesetz kostenlos und frei von Diskriminierung zu erfolgen. Damit Geld verdienen wollen andere. Was also soll die Motivation für eine Bank sein, immer neue API-Dialekte kostenfrei anzubinden, nur damit Drittanbieter ihre Apps leichter unter das Volk mischen können? Damit degradieren sich die Institute selbst zum reinen Serviceanbieter. Viel naheliegender ist doch, auf längst etablierte Standards zurückzugreifen.

EBICS: Open Banking für Firmenkunden

Einer dieser Standards ist EBICS. Und dieser Standard ist weit verbreitet: Neben Deutschland spricht auch Frankreich EBICS. Zwischen der Deutschen Kreditwirtschaft und ihrem französischen Pendant, dem CFONB, besteht ein Kooperationsabkommen. Diese beiden größten Zahlungsverkehrsmärkte in Euroland decken das Firmenkunden- und das Interbankengeschäft mit EBICS ab. Die Schweiz (SIX) zählt ebenfalls zu den EBICS-Fans. Österreich (STUZZA) überlegt einzusteigen. Statt im API-Sumpf unterzugehen, lohnt es sich zu fragen, wie sich EBICS PSD2-konform ausbauen lässt. Die Antwort: mit einer Fernsignatur (vgl. Abb.1). Ein modernes EBICS-Portal kann aus eingehenden Daten wie dem Code einer PhotoTAN oder einer QR-TAN Hardware-basiert die Signatur erstellen und an den EBICS-Bankrechner senden.
Abb. 1: Wie Fernsignaturen EBICS zu einer PSD2-konformen Open-Banking-Lösung erweitern
EBICS bietet Firmenkunden viele Vorteile. Unternehmen, die über einen EBICS-Client verfügen, können sicheres Multibanking betreiben und auch die Verteilte Elektronische Unterschrift nutzen (VEU). Damit lassen sich Rollen- und Rechtemodelle abbilden (Signaturen T, A, B und E), um etwa zu bestimmen, ob eingereichte Zahlungsaufträge von autorisierten Personen stammen und ob die jeweilige Person über die entsprechenden Berechtigungen verfügt, um diese Zahlungsaufträge freizugeben. Ähnlich wie bei FinTS gilt auch für EBICS: Die nötige Infrastruktur, um Open Banking zu verwirklichen, existiert bereits. Schon allein deshalb lässt sich nachvollziehen, dass viele Institute damit hadern, jetzt zu investieren. Niemand garantiert, dass sie sich für den richtigen API-Anbieter entscheiden oder dass der Gesetzgeber keine neuen Vorschriften erlässt, die bereits getätigte Investitionen obsolet machen.

Linktipps:
•    Erwartung trifft auf Realität: PSD2 Schnittstellen sind weiterhin nicht marktreif
•    Open Banking: Mit FinTS und EBICS gegen den API-Wildwuchs (PSD2/XS2A-Lösung)

Autor: Michael Schunk

T2/T2S-Big Bang: Banken riskieren Ausschluss vom Zahlungsverkehr

Der Zahlungsverkehr läuft für die breite Öffentlichkeit unsichtbar und zuverlässig. Doch das muss nicht so bleiben: Das größte aktuelle Thema, das in der allgemeinen Öffentlichkeit unbekannt ist, ist die TARGET2/TARGET2-Securities-Konsolidierung, und damit einhergehend auch die ISO-20022-Migration und ein neues Kontenmodell. Banken, die damit nicht rechtzeitig fertig werden, drohen sich vom Zahlungsverkehr zu verabschieden – und das spüren dann auch die Kunden.

 Die Umstellung betrifft alle Beteiligten des bisherigen TARGET2-Systems und findet in der Infrastruktur der Banken, der Zentralbanken und der Europäischen Zentralbank (EZB) statt. Weil die Umstellung als Big Bang erfolgt, also zeitgleich für alle Banken in Europa am 21. November 2021, können sich Verzögerungen bei einzelnen Instituten auch volkswirtschaftlich negativ auswirken. Komplikationen in den häufig in die Jahre gekommenen IT-Systemen oder Verzögerungen in der Projektumsetzung führen schlimmstenfalls zu einem Ausschluss aus dem Individualzahlungsverkehr, falls die Umstellung nicht zum Stichtag erfolgen kann.

Die Folgen für Banken bei einer misslungenen T2/T2S-Konsolidierung:

  • Ausschluss vom Individualzahlungsverkehr in Zentralbankgeld 
  • Ausschluss von der Abwicklung der geldpolitischen Geschäfte, dies bedeutet insbesondere: 

  • Offenmarktgeschäfte können nicht in Anspruch genommen werden. 
  • Ständige Fazilitäten können nicht genutzt werden. 
  • Die Mindestreservepflicht kann nicht eingehalten werden. 
Sollte für den Massenzahlungsverkehr ein an TARGET2 angeschlossenes Nebensystem wie der SEPA-Clearer verwendet werden, wäre die Bank auch von den entsprechenden Clearingwegen ausgeschlossen und könnte keine Zahlungen mehr abwickeln.

Die Konsequenzen sind also dramatisch und gefährden praktisch die Funktionsfähigkeit der Bank selbst. Als einzige Handlungsalternative bleibt nur noch, sich über ein anderes Institut direkt anbinden zu lassen. Dies müsste aber auch frühzeitig entschieden und geplant werden und kann nicht erst kurz vor November 2021 erfolgen. Schlägt auch das fehl, ist die Zukunft der Bank gefährdet. Sich auf eine etwaige Verschiebung der Umstellung zu verlassen oder darauf zu spekulieren, wäre fahrlässig.

Die große Herausforderung bei der TARGET2-Konsolidierung ist aber nicht nur die Umstellung der Kontenstruktur, sondern auch die technische Vereinheitlichung des Zugangs der bestehenden Systeme TIPS und T2S mit TARGET2 sowie die bevorstehende Umstellung der Nachrichtenformate.

Künftiger Zugang zu TARGET2 

Die Anbindung an TARGET2 ändert sich. Bisher wurde der FIN-Copy-Service von SWIFT (sog. Y-Copy-Modus) genutzt. In Zukunft wird es eine eigene dezidierte Kommunikationsarchitektur geben, die durch die EZB bereitgestellt wird und mit dem Eurosystem Single Market Infrastructure Gateway (ESMIG) als zentralem Zugang zu allen TARGET2-Services funktioniert. Für diesen Zugang wird als neuer Teilnehmer zukünftig ein Network Service Provider (NSP) benötigt, der mit ESMIG kommuniziert.

Nachrichtenformate 

Die Zukunft spricht ISO 20022, so auch TARGET2. Bisher nutzt TARGET2 noch MT-Nachrichten in der Kommunikation. Die MT-Nachrichten werden von ISO-20022-Nachrichten in XML abgelöst (MX), die deutlich umfangreicher sein werden und mehr Informationen aufnehmen können. Die MX-Nachrichten werden nicht in einem Like-for-like-Ansatz eingeführt, bei dem man noch relativ einfach MT-Nachrichten in MX-Nachrichten transformieren könnte, sondern es wird die Mächtigkeit der neuen Formate von Beginn an ausgenutzt.

Dadurch und auch durch die komplette Umstellung der Infrastruktur, ist eine parallele Nutzung oder eine Übergangslösung mit beiden Formaten nicht möglich.


Zu viel vorgenommen? 

Neue Nachrichtenformate, neue Anbindungswege, neue Akteure und neue Prozesse – und alles europaweit zu einem Stichtag. Kann das gut gehen?

Aufgrund der Brisanz des Themas erfolgt ein detailliertes Reporting über die Zentralbanken mit einem strengen Zeitplan. Die Projektmeilensteine sind zentral von der EZB vorgegeben, und die Zielerreichung wird regelmäßig abgefragt. Für die Umsetzung ist jede Bank selbst verantwortlich. Aktuell haben sieben teilnehmende Märkte (darunter Deutschland) Gelb gemeldet, 18 Grün. Das wirkt auf den ersten Blick, als sei noch alles in Ordnung – doch Banken, die einerseits die Tragweite und andererseits den Aufwand unterschätzen, um rechtzeitig compliant zu sein, dürften schneller als ihnen lieb ist von Gelb nach Rot rutschen.

Damit es nicht langweilig bleibt, erfolgt zusätzlich zur TARGET2-Konsolierung auch bei SWIFT eine Umstellung der MT-Formate auf MX-Formate. Hier jedoch mit einer 4-jährigen Übergangszeit, in der Banken beide Varianten nutzen können. Aufgrund der thematischen Nähe bietet sich an, dies zusammen mit TARGET2 anzugehen.

Das Aufgabenheft ist gut gefüllt und wird die Kapazitäten der Institute die nächsten Jahre binden. Das muss auch in die Köpfe der Vorstände hinein. Wir haben es hier nicht nur mit einer „Pflichtübung“ zu tun, sondern mit der Zukunftsfähigkeit jedes einzelnen Instituts.

Autoren: Swaantje Anneke Völkel, Thomas Ambühler

EBICS für das Clearing und Settlement von SEPA-Instant-Payments – das neue Delta-Dokument als Meilenstein

Bereits seit Januar 2008 wird das EBICS-Transferprotokoll mit der SEPA-Einführung auch im Interbankenverkehr für das bilaterale Clearing und Settlement sowie den Austausch von SEPA-Zahlungen mit der Deutschen Bundesbank eingesetzt. Über die Jahre hat sich die Anzahl der Institute in Europa, die EBICS nutzen, weiter erhöht. So ist es auch nicht verwunderlich, dass auch die EBA CLEARING seit November 2013 EBICS als alternativen Zugang für das sog. „Garagenclearing“ und STEP2 anbietet.

Die Einführung der SEPA-Instant-Payments war nach der SEPA-Umstellung der nächste Schritt auf dem Weg zur Standardisierung im europäischen Zahlungsverkehr. Aufgrund des Echtzeitansatzes stellt dieses neue Zahlverfahren jedoch die Nutzbarkeit unter EBICS vor eine besondere Herausforderung. Während in der herkömmlichen EBICS-Nutzung bisher der dateibasierte Datenaustausch im Vordergrund stand, fordert das SEPA-Instant-Payments-Verfahren auch im Interbankenverkehr einen nachrichtenbasierten Ansatz auf Transaktionsbasis. So startete die EBA CLEARING mit RT1 auf Basis von SEPA-Instant-Payments erfolgreich im November 2017.

Zur Unterstützung von EBICS für den Austausch und das Clearing von SEPA-Instant-Payments wurde nun im Oktober 2019 von der EBICS-Gesellschaft auch offiziell ein Delta-Dokument zur EBICS-Spezifikation veröffentlicht (siehe Use of EBICS for the Clearing & Settlement of Instant Payment Transactions, www.ebics.org). Dieses beschreibt die zu berücksichtigenden Modifikationen zur Abwicklung von Instant Payments unter EBICS 3.0. Um den neuen Anforderungen an das Echtzeitverhalten gerecht zu werden, wurde das neue Schema ebics_inst_request_H005.xsd aufgenommen. Für die administrativen Geschäftsvorfälle des Instant-Payments ist jedoch weiterhin das dateibasierte EBICS-Verhalten und somit das Standardschema erforderlich. Für die Nutzung von SEPA-Instant-Payments unter EBICS muss das neue Schema dem übergeordneten Schema hinzugefügt werden.

Im Kunde-Bank-Verhältnis sowie im Interbankenverkehr außerhalb von Instant-Payments ändert sich bei der Nutzung von EBICS nichts.

Das Delta-Dokument Use of EBICS for the Clearing & Settlement of Instant Payment Transactions ist sehr zu begrüßen. EBICS wird in der Praxis vielfältig genutzt, und viele weitere Szenarien sind denkbar. Um die übergreifende und einheitliche Nutzung von EBICS zu gewährleisten, sind Standards und ihre Einhaltung unerlässlich. Dennoch muss flexibel auf Herausforderungen des Marktes reagiert werden können. Dieses Dokument erfüllt beide Ziele gleichermaßen. Ein weiterer Meilenstein auf dem Weg zur Standardisierung des Zahlungsverkehrs in Europa ist gesetzt.

Autor: Michael Lembcke

Request to pay (R2P) verändert den Zahlungsverkehr – technische Herausforderungen

Der letzte Blog-Beitrag zu Request to Pay hat uns gezeigt, wie besinnlich die Weihnachtszeit und wie geordnet die dazugehörigen Einkäufe mit R2P ablaufen könnten. Nun ist es bis zum nächsten Weihnachtsfest ja noch eine Weile hin und so bleibt Zeit, sich mit den Herausforderungen zu beschäftigen, die die Etablierung R2P-basierter Zahlungssysteme mit sich bringen.

Hier sei zunächst die technische Komponente genannt. Die EBA CLEARING hat im vergangenen Dezember Formatspezifikationen veröffentlicht, die sowohl die Zahlungsanforderung (pain.013) als auch die Antwort auf die Zahlungsanforderung (pain.014) beschreiben. Damit ist das Teilstück des Clearings technisch präzisiert, und es steht „nur noch“ die Herausforderung an, die Ein- und Ausgangsschnittstellen des Zahlungsverkehrssystems auf diese Abläufe und Formate vorzubereiten. Das klingt zunächst trivial, stellt jedoch für ein Zahlungsverkehrssystem eine echte Herausforderung dar: Sowohl Hinweg (Zahlungsanforderung) als auch Rückweg (Antwort) auf die Anforderung müssen binnen kürzester Zeit von einem Kundensystem durch das Zahlungssystem, die betreffenden Clearingsysteme und das empfangende bzw. antwortende Kundensystem geroutet werden.

Und natürlich ergibt sich hieraus auch die Frage, wie ein Kunde die Zahlungsanforderung überhaupt zu seiner Bank transportieren soll. Technisch findet hierzu gerade im European Payments Council und in der Deutschen Kreditwirtschaft (DK) eine Diskussion statt, und es wird eine technische Spezifikation für die Kunde-Bank-Schnittstelle erstellt.

Hier kommt dann die fachliche Komponente zum Tragen, in der man existierende Systeme bereits dahingehend konzeptionell überdenken sollte, welches System im Eingang Zahlungsanforderungen entgegennehmen und mit welchem Gegenstück diese beantwortet werden sollen. Woraus sich dann unmittelbare Folgefragen ergeben, wie z. B. die Frage danach, wie der Kunde auswählen kann, ob er per SEPA oder SEPA Instant bezahlen möchte (sofern er diese Auswahl je nach Ausgestaltung der Zahlungsanforderung überhaupt hat). Nicht weniger bedeutend ist die Frage, wie er die Zahlungsanforderung autorisieren soll. Hier eignen sich z. B. die Autorisierung mit einem Mobile-Device und den hierfür etablierten TAN-Systemen oder auch eine Überstellung in die EBICS-Unterschriftsmappe zur Unterzeichnung mit verteilter elektronischer Unterschrift.

Die Information über einen Zahlungseingang aus einer Instant-beglichenen Zahlungsanforderung ist dagegen dank des spezifizierten „Haben-Avis für SEPA-Echtzeitüberweisungen“ mittlerweile recht einfach bereitzustellen.

Im richtigen Zusammenspiel der technischen Möglichkeiten wird R2P dem Instant-Zahlungsverkehr sicher einen immensen Schub verleihen. Die auf dem Weg dorthin beschriebenen Herausforderungen stellen zugegebenermaßen einen nicht unerheblichen Aufwand dar, der sich mit Blick auf die zahlreichen Gestaltungsspielräume jedoch bei richtiger Umsetzung auszahlen wird. Welche Einsatzszenarien und Use Cases sich aus den technischen Möglichkeiten ergeben, haben wir für Sie im Whitepaper „Request to Pay – Vielfältige Einsatzmöglichkeiten“ näher beleuchtet. Außerdem stehen wir Ihnen sowohl für inhaltliche als auch technische Diskussionen gerne zur Verfügung.

Autor: Eric Waller

Multibanking – alles in einem Portal

Standards als Grundlage einer vernetzten Prozessautomatisierung

Daten sind das Öl des 21. Jahrhunderts. Dies wird seit Jahren auf allen Digitalkonferenzen gepredigt. Je mehr Daten ein Anbieter von einem Kunden hat, desto besser lässt sich der Kunde clustern und in Zielgruppensegmente einordnen. Dieses Wissen über die Bedürfnisse des Kunden erlaubt es, interessante Zusatzangebote für ihn zu schaffen.

Wenn sich im Rahmen der Digitalisierung die Zugangskanäle zunehmend auf das Internet verlagern, wird die „digitale Bankfiliale“, wie z. B. das webbasierte Firmenkundenportal TRAVIC-Port, zum entscheidenden Kontakt zwischen Bank und Firmenkunde. Gelingt es dem Betreiber am digitalen Point of Sale alle Bankkonten des Kunden auch anderer Banken zu aggregieren und hinter seinem eigenen Portal zu bündeln, hat er die besten Voraussetzungen für einen ganzheitlichen Überblick über den Zahlungsverkehr des Kunden. Je mehr Konten hier gebündelt werden, desto bessere Serviceangebote kann der Betreiber für seine Kunden kreieren.

Das Schlagwort „Multibanking“ steht für diese Funktionalität einer Bündelung des optimalen Zahlungsverkehrs eines Kunden. Beide Seiten - Kunde und Bank - profitieren von dieser Zusammenfassung unter einem Dach. Auch der Kunde erhält einen umfangreichen Überblick seiner Transaktionen. Die Aggregation bezieht sich sowohl auf die Einreichung aller Zahlungsarten, als auch auf die Abholung der Kontoinformationen aller konnektierten Konten. Das Multibanking in einem Portal ermöglicht dem Anwender eine einheitliche, komfortable Benutzeroberfläche für verschiedene Zahlungsverkehrsanbieter unter einem sicheren Zugang - und damit mehr Komfort für seine internen Prozesse. Der Nutzen dieser reibungslosen Automatisierung des multiplen Zahlungsverkehrs steht und fällt jedoch mit der Schnelligkeit der Abwicklung und sauberen Implementierung der Bankserver verschiedener Anbieter. Ein hoher Grad an vernetzten Transaktionen in beide Richtungen erfordert einheitliche Schnittstellen und eine saubere Einhaltung der verabschiedeten Spezifikationen. Die EBICS-basierte Kommunikation von TRAVIC-Port stellt hierbei das sicherste, internetbasierte, technische Protokoll für den SEPA-Raum zur Verfügung. Allzu großzügige Anpassungen und Abweichungen von der Spezifikation verhindern reibungslose Prozesse auf Seiten der Anbieter und stehen der Vision einer hohen, lückenlosen Zusammenfassung des Zahlungsverkehrs entgegen. Hier sollten sowohl die Auftraggeber der Portalanbieter, als auch die Auftragnehmer und Software-Häuser an einem Strang ziehen. Im Gegensatz dazu ermöglichen APIs mit proprietären Schnittstellen die individuelle Anpassung an die technische Umgebung der Bank. Jede Abweichung von Standards verzögert jedoch die reibungslose Integration des komplexen Datenverkehrs. Unpräzise Auslegungen der Spezifikation verringern den Grad an Automatisierung und Durchsatz jeder Anbindung. Je mehr Lücken im komplexen Netzwerk der Multibankanbindungen, desto geringer der Kundennutzen und die Qualität der Auswertung.

Gastautor: Christian Veith

ISO 20022 im Auslandszahlungsverkehr: Zeit für die Umstellung!

Nahezu alle großen Zahlungsverkehrssysteme sind im Begriff, standardisierte, XML-basierte Datenformate einzuführen. Sie machen sowohl den Auslands- als auch den Individualzahlungsverkehr deutlich schneller und weniger fehleranfällig. Aber die Umstellung ist kein Selbstläufer und viel Zeit bleibt nicht mehr. Was ist zu beachten?

Kartenzahlungen im Urlaub oder Auslandsüberweisungen gelten für uns im Alltag als Selbstverständlichkeit. Hinter allen elektronischen Transaktionen stehen jedoch teils hochkomplexe Prozesse, denn für einen schnellen und reibungslosen Geldtransfer müssen sämtliche involvierten IT-Systeme mit den generierten Daten gleich gut umgehen können. Dazu braucht es Standards wie ISO 20022, der in den kommenden Jahren das Maß der Dinge im Auslands- und Individualzahlungsverkehr sein wird.

Bewährter Standard für die Zukunft

Immer mehr Zahlungsverkehrsräume stellen auf den ISO-Standard um, denn die Vorteile sind immens: Er ist zukunftssicher, erlaubt eine deutlich schnellere Verarbeitung von Zahlungsdaten und macht erhebliche Effizienzsteigerungen möglich. Konvertierungen von einem Datenformat ins andere entfallen. Immer mehr Datensätze lassen sich ohne Interaktionen und Medienbrüche im Sinne eines Straight Through Processings (STP) durchgehend verarbeiten.

Aufwand nicht unterschätzen

Das gibt es aber nicht umsonst – die Umstellung auf ISO 20022 bindet zeitliche und personelle Ressourcen. Aktuell unterschätzen viele Banken den Aufwand. Denn sie müssen nicht nur eventuell vorhandene manuelle Prozesse automatisieren, sondern auch die eigene Software ISO-fit machen. Handelt es sich dabei wie so häufig um gewachsene Legacy-Systeme, wird die Aufbereitung für die Verarbeitung von XML-Datenpaketen ziemlich anspruchsvoll. Und das auch noch unter Zeitdruck: Der Go-live für die Umstellung von TARGET2 auf den XML-Standard ist der 21. November 2021. Für SWIFT beginnt zum gleichen Termin eine vierjährige Koexistenzphase.

Trügerische Sicherheit

Immerhin, europäische Bankhäuser arbeiten bereits mit ISO-basierten Standards, denn SEPA setzt darauf auf. Aber damit ist noch niemand auf der sicheren Seite. Je nach Art der Umsetzung sind am Ende Arbeiten in allen wichtigen Bereichen der Zahlungsverkehrs-IT notwendig, von Stammdaten über E-Banking bis zu Backend-Systemen. Ganz zu schweigen von Auswirkungen auf die zukünftige Architektur des Kernbanksystems.

ISO ist nicht gleich ISO

Wir sollten auch nicht vergessen, dass es sich hier um einen generischen Standard handelt, der nur die Grundlagen für Zahlungsverkehrsnachrichten festlegt. Bei jeder einzelnen Umsetzung wird er zweckmäßig angepasst, kann also bei TARGET2, SWIFT und SEPA durchaus unterschiedlich ausfallen. Von der Beschränkung der zulässigen ISO-Codes, einer Begrenzung von Datentypen, bis hin zum Entfernen nicht benötigter optionaler Elemente der Basisnachricht sind verschiedenste Varianten denkbar. Das macht eine One-Size-fits-all-Lösung für die Migration unrealistisch.

Viele Einzelprojekte

Demzufolge ist es eigentlich falsch, von der ISO-20022-Umstellung zu sprechen – in Wahrheit sind es viele unterschiedliche Projekte. Umso wichtiger ist die frühzeitige Einbindung der IT-Abteilung zur Unterstützung der Fachseite für rechtzeitige Hinweise auf Fallstricke und Probleme sowie nicht zuletzt, um eine frühzeitige Kostenschätzung zu bekommen. Denn die Umstrukturierung des Auslands- beziehungsweise Individualzahlungsverkehrs von TARGET2 auf den XML-Standard dürfte einen sieben- bis achtstelligen Betrag kosten. Die Summe schließt die Vorstudie, die Einführung und die IT-Anpassungen selbst ein. Zusätzlich zu budgetieren sind die Schulungen der involvierten Mitarbeiter und der rechtzeitige Aufbau des notwendigen Know-hows, alternativ die Einbindung externer Partner.

Wie geht es weiter?

Sofern sie noch nicht vorliegt, brauchen Finanzinstitute möglichst schnell eine Roadmap – mit allen im Zuge der Umstellung auf den ISO-Standard notwendigen Arbeiten und Meilensteinen. Basis dafür ist eine ehrliche Bestandsaufnahme des eigenen Ist-Zustandes, darum wird niemand herumkommen. Im Zuge derer darf auch durchaus die Frage gestellt werden, ob die Bereitstellung von Leistungen im Auslandszahlungsverkehr im eigenen Haus zukünftig überhaupt noch ökonomisch Sinn macht oder ob stattdessen die verstärkte Zusammenarbeit mit externen Dienstleistern die bessere Lösung ist.

Wandel als Chance begreifen

Die Umstellung auf ISO 20022 setzt die Finanzdienstleister unbestritten unter Zugzwang, erst recht, wenn wir die nahezu zeitgleiche Konsolidierung von TARGET2 und TARGET2-Securities bedenken. Aber: Die regulatorischen Neuerungen sind auch eine Gelegenheit, um die eigenen Systeme kritisch zu prüfen und auszuloten, wie agil und flexibel sie sich modellieren lassen. Das hilft am Ende auch dabei, die digitale Transformation auf ganzer Linie voranzutreiben – denn Stehenbleiben ist in der digitalen Welt von heute keine Option.

Gastautoren: Sabine Aigner, Raija Wehrli