Posts mit dem Label SWIFT werden angezeigt. Alle Posts anzeigen
Posts mit dem Label SWIFT werden angezeigt. Alle Posts anzeigen

Zeit des Umbruchs

Aufgeschoben ist nicht aufgehoben: Die Umstellung auf ISO-20022-konforme Datenformate im Zahlungsverkehr kommt – wenn auch ein Jahr später. Und sie bringt weitere Veränderungen mit sich, nicht zuletzt bei SWIFT. Die dort geplante Transaction Management Platform (TMP) soll internationale Zahlungsflüsse transparenter und schneller machen. Aber sind solche zentralen Systeme auch sicher genug? Gibt es Alternativen? 

Zentrale Datenplattform als Entwicklungsziel

Zahlungsverkehrssysteme gehören zum Kern der Finanzinfrastruktur. Ein Ausfall wie bei TARGET2 im vergangenen Jahr wiegt schwer, die Aufregung darüber ist verständlich. Die Verschiebung der Umstellung auf ISO-20022-konforme XML-Datenformate im europäischen Zahlungsverkehr steht damit zwar nicht im Sachzusammenhang, gibt den Finanzinstituten aber natürlich zeitliche Spielräume. Die können sie brauchen, denn mit der Formatänderung wurden noch weitere Dinge ins Rollen gebracht. So hat SWIFT mit der TMP die Einrichtung einer zentralen Datenplattform für den Auslandszahlungsverkehr, basierend auf dem XML-Standard, angekündigt. 

Durch die zentrale Speicherung sämtlicher Transaktionsdaten können alle am Prozess Beteiligten jederzeit auf die Daten zugreifen. Für SWIFT ist das ein Paradigmenwechsel, weg vom reinen Informationsmittler hin zum vollgültigen Zahlungslogistiker. Die Plattformlösung bietet eine Reihe von Vorteilen:

  • Reduktion der Schnittstellen
  • keine Datenverluste zwischen den einzelnen Stationen
  • hohe Transparenz für alle Beteiligten
  • höhere Manipulationssicherheit
  • mehr Serviceangebote


Keine Einführung ohne Risiken

Allerdings birgt die Einführung der TMP auch einige Fallstricke. Da ist zunächst ein Ausfall des SWIFT-Netzwerks. Bei der zentralen TMP gingen im Extremfall sämtliche Aufträge eines bestimmten Zeitraums verloren. Bedenken der Banken, sich hier einen Single Point of Failure ins Haus zu holen, sind nicht völlig von der Hand zu weisen. Bei der Vertraulichkeit der Daten ist zu berücksichtigen, dass die Vereinigten Staaten schon direkte Zugriffsrechte auf den Datenbestand des SWIFT-US-Rechenzentrums verlangten. SWIFT baute als Reaktion darauf unter anderem einen Standort in der Schweiz auf.

Gibt es Alternativen zu SWIFT?

Im Prinzip ja – aber die Auswahl hält sich in Grenzen: Mögliche Kandidaten sind Internet-Zahlungsnetzwerke wie etwa Ripple. Erste Großbanken nutzen das System bereits probeweise. Noch nicht marktreif, aber in Zukunft auf jeden Fall eine mögliche Alternative stellen digitale Zentralbankwährungen dar (Central Bank Digital Currencies). Der E-Renminbi in China ist bereits in einigen Provinzen in der Erprobungsphase, die schwedische E-Krone hat unlängst den Testbetrieb begonnen. Die EZB dürfte mit dem digitalen Euro nachziehen.

Eine weitere Überlegung wert sind grenzüberschreitende Echtzeit-Bruttoabwicklungs¬systeme (englisch Real-Time Gross Settlement, RTGS). Allerdings kommen diese nicht eben häufig vor oder aber sind, wie SEPA, auf eine einzelne Währung festgelegt. Schließlich gibt es eigens als Alternative zu SWIFT aufgesetzte Kooperationen wie Support of Trade Exchanges (INSTEX). Dieses europäische System wurde eigens für den Handel mit dem Iran ins Leben gerufen. China ist mit CIPS einen ähnlichen Weg gegangen. Gänzlich anders, aber ebenfalls grundsätzlich auf der Kooperation der beteiligten Banken aufbauend, funktioniert Visa B2B Connect. In Europa ist der Service derzeit in ausgewählten Ländern verfügbar.

Aber selbst eine Lösung von SWIFT mittels einer der – raren – Alternativen befreit die Finanzinstitute nicht von der Verpflichtung, auf ISO-20022-konforme XML-Datenformate umzustellen. Gleichzeitig ist es für Banken ratsam, sich die durch TMP anstehenden Änderungen im Auslandszahlungsverkehr genau anzusehen und zu hinterfragen. In der Roadmap hin zu ISO 20022 ist durch die Verschiebung des Go-live-Termins etwas Zeit gewonnen – diese sollte jetzt sinnvoll genutzt werden!

Autoren: Sabine Aigner, Thomas Ambühler

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)

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

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

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

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

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

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

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

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

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

Autor: René Keller

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

GPI und EBICS – Wie geht das zusammen?

Ist GPI nicht ein reines SWIFT-Thema? Auf den ersten Blick nun einmal ja. Die Abkürzung kommt von SWIFT und steht für „Global Payments Innovation“. Die Initiative für GPI wurde Ende 2015 schon mit breiter Unterstützung von vielen globalen Banken gestartet.

Die Basis von GPI ist die eineindeutige Referenz, kurz UETR (Unique End-to-End Transaction Reference), die eine Zahlung durch die manchmal lange Korrespondenzbankkette begleitet. So eine Referenz ist zwar ein Ungetüm von 36 Zeichen in der nach einem allgemeingültigen Algorithmus definierten Form xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx, aber das Ungetüm sichert die Eineindeutigkeit ohne zentrale „Vergabestelle“. Wurde die UETR anfänglich nur in einer CUG (Closed User Group) für (Firmen-)Kundenzahlungen in MT103-Nachrichten verwendet, haben inzwischen alle Zahlungen im FIN-Netzwerk so eine Referenz – gleichbleibend vom Anfang bis zum Ende der gesamten Zahlungskette.

Der zweite wesentliche Baustein von GPI ist der sogenannte Tracker. Der Tracker ist eine zentrale Datensammlung bei SWIFT zu allen GPI-Zahlungen. Er stellt den beteiligten Banken umfassende Informationen zum Status einer Zahlung in der Korrespondenzbankkette, zu Gebühren und zu Währungsumrechnungskonditionen bereit. Während der FIN-Transport diese Informationen aus den transportierten Nachrichten selbst herausliest, können non-FIN-Banken den Tracker auch aktiv informieren. In der aktuellen Diskussion ist die sogenannte Confirmation – die Meldung der Gutschrift auf dem Konto des Begünstigten am Ende der Zahlungskette. Auf die Confirmation sollen ab 2020 alle FIN-Banken verpflichtet werden.

Aber warum der ganze Aufwand? Transparenz und Schnelligkeit – die beiden wesentlichen Herausforderungen im Korrespondenzbankgeschäft werden mit GPI angegangen. Durch die umfassende Verwendung von UETR liegen nun Statistiken vor: Durchschnittlich 40 Prozent der GPI-Überweisungen werden den Endbegünstigten innerhalb von fünf Minuten gutgeschrieben, innerhalb von 30 Minuten sind es 50 Prozent, innerhalb von sechs Stunden 75 Prozent und innerhalb von 24 Stunden nahezu alle. So eine Aussage war vor GPI einfach unmöglich. Hingegen kann jeder Treasurer Fälle berichten, bei denen Zahlungen spät oder gar nicht ankamen, mit hohen, unerklärlichen Gebühren, mit unklaren oder sogar ohne Verwendungszweckinformationen.

Neben den technischen Details wie UETR und Tracker gehört zu GPI ein Regelwerk, in dem die möglichst taggleiche Weitergabe einer Zahlung mit vollständigem Verwendungszweck, unter Angabe von abgezogenen Gebühren und Währungsumrechnungsdetails vorgeschrieben ist. Da es ja keine globale Transparenzrichtlinie gibt, muss dies auf multilateralem Vertragswerk begründet durchgesetzt werden. Und das ist auch gut so – Zeit dafür ist es schon lange.

Der (Firmen-)Kunde soll besseren Service im grenzüberschreitenden Zahlungsverkehr bekommen. Neben der Schnelligkeit und Transparenz ist ein weiterer Punkt die Quittung. So etwas gibt es ja eigentlich nur bei einer Barzahlung, im elektronischen Zahlungsverkehr war bisher das Motto: „shoot and forget“. Wenn es keine Beschwerden gibt, ist das Geld wohl angekommen. In den letzten Jahren hat es im SEPA eine beachtliche Entwicklung gegeben, und mit den Instant Payments nach dem Schema SCTinst gibt es auch hier nun eine Quittung. Mit SWIFT GPI ist die Erstellung einer derartigen Quittung ebenfalls möglich, auch wenn dies (noch) eine vollständige FIN-Kette in der Abwicklung voraussetzt. Es ist jedoch noch ein Stück Weg dorthin: Bisher wird an den breiten, erst einmal bankinternen, Umsetzungen gearbeitet. Die Anbindung der Kundensysteme für einen Zugriff auf die Informationen oder gar die Weitergabe von Status und Gebühreninformationen an Kundensysteme befindet sich noch am Anfang. Aber schon die Möglichkeit, im Falle eines Zweifels durch den Zugriff auf eine zentrale Stelle prüfen zu können, wo sich die Zahlung befindet, ist im großen Korrespondenzbanknetz ein erheblicher Fortschritt.

Geht das nur in FIN? Natürlich nicht. Die aktuellen Entwicklungen, z. B. die Migration der Großbetragssysteme (RTGS) wie TARGET2, EURO1 oder CHAPS von MT hin zu Nachrichten in XML nach ISO-20022-Standard, gehen diesen Weg. Die (neueren) ISO-Nachrichtenformate enthalten dedizierte Felder für die UETR, und so wird die Referenz auch außerhalb des FIN-Netzes transportiert. Und erst kürzlich verbreitete SWIFT die Meldung: „SWIFT trials instant cross-border gpi payments through TIPS“[1].

Für eine Anbindung von GPI-Rückmeldungen an Kundensysteme wie TMS oder ERP sind Nachrichten in Form von PSR (payment status report, also pain.002) effizienter als manuelle Prozesse. Aber schon diese Selfservice-Funktionen sind ein bedeutender Schritt hin zu mehr Transparenz. Übrigens sind die Standards zu diesen Rückmeldungen, also Felder (tags) und Codes, in der Harmonisierungsinitiative CGI-MP multibankfähig abgestimmt. In dieser Initiative wirkt PPI nun auch aktiv mit.

Des Weiteren steht auch die Erweiterung an, dass der Kunde seine Referenz in der Zahlung als UETR initiiert – im pain.001.001.03 in besonderen Feldern gemäß der CGI-MP oder auch schon in aktuelleren ISO-Versionen in dedizierten Feldern.

Und genau hier, an der Schnittstelle Kunde-Bank bzw. Bank-Kunde, werden sowohl Kundenzahlungen als auch PSR-Rückmeldungen ja auch oft mit EBICS transportiert. Somit stehen GPI und EBICS nicht im Widerspruch zueinander, sondern ergänzen einander sinnvoll – wie so oft im Zahlungsverkehr.

Autor: Dr. Mario Reichel

[1] Quelle: https://www.swift.com/news-events/press-releases/swift-trials-instant-cross-border-gpi-payments-through-tipshttps://www.swift.com/news-events/press-releases/swift-trials-instant-cross-border-gpi-payments-through-tips

Standardisierung und Automatisierung in der Beziehung mit externen Vermögensverwaltern dank EBICS

Externe Vermögensverwalter (EVV) oder External Asset Manager (EAM) bieten ihren vermögenden Privatkunden oder institutionellen Kunden wie Pensionskassen und Versicherungen verschiedenste Services an (zum Beispiel Steuer- und Immobilienberatung, Handels- und Anlagegeschäfte). Die Kundenkonten liegen meist auf einer oder mehreren Depotbanken. Die Interaktion mit den Finanzinstituten ist dabei oft weder standardisiert noch automatisiert. Die Kommunikation über Briefpost, Telefon, E-Mail und teilweise auch noch Fax dominiert den Geschäftsalltag.

Wenige, grosse Vermögensverwalter verfügen über einen SWIFT-Anschluss und benutzen diesen für die Abwicklung von Treasury- und Fremdwährungsgeschäften (Meldungskategorie 3), Wertschriftengeschäften (Meldungskategorie 5), Edelmetallgeschäften (Meldungskategorie 6) oder Cash-Management-Geschäften (Meldungskategorie 9). Einige haben proprietäre System-zu-System-Verbindungen realisiert, beispielsweise mittels FTP, um Finanzmeldungen auszutauschen. In der Schweiz beobachten wir einen Trend, dass EBICS sich in diesen Fällen als alternative Anbindungsvariante durchsetzen könnte.

Im Rahmen des PPI-Frühstücks im April 2019 in Lausanne hat ein Vertreter von Credit Suisse das Angebot «Private swift Network (PsN)» vorgestellt. Es handelt sich dabei um die Erweiterung des EBICS-Angebots in der Art und Weise, dass ca. 20 neue EBICS-Auftragsarten (Reports für den Download) aus den oben genannten EAM-Anwendungsfällen zur Verfügung stehen. Dank der Kooperation mit führenden Softwareherstellern von Portfolio-Management-Systemen (wie etwa Allocare oder Expersoft) erreicht die Credit Suisse in der Interaktion mit ihren Partnern eine signifikante Steigerung des Standardisierungs- und Automatisierungsgrads. Konkret können die SWIFT-Meldungen der oben genannten Meldungskategorien jetzt auch über EBICS transportiert werden.

Da das EBICS-Protokoll flexibel bezüglich des transportierten Inhalts ist, bietet Credit Suisse darüber hinaus auch weitere Formate wie beispielsweise CSV oder XML für Rapportierung der Transaktionen und Vermögenswerte an, inklusive Stammdaten der entsprechenden Kundendepots. Von dem neuen Angebot profitieren alle Akteure: Vermögensverwalter können vermehrt Banken kostengünstig via EBICS anbinden und ihre Prozesse automatisieren, Softwarehersteller ihren Funktionsumfang sinnvoll erweitern und Banken ihre Attraktivität für EAM steigern. Über alle Stellen und Prozesse gesehen sinkt auch die Fehlerrate und es steigt die Umsetzungsgeschwindigkeit durch den Wegfall von manuellen Eingriffen.

Schweizer Banken, welche aktuell Projekte in diesem Umfeld umsetzen, planen bereits die nächsten Ausbaustufen im EBICS-Angebot. So sollen in Zukunft nicht nur die Reporting-Funktionen (EBICS-Download), sondern auch die Auftragsfunktionen (EBICS-Upload) angeboten werden. Insbesondere Aufträge im Handel (SWIFT-Meldungskategorie 5) sind gut geeignet für die Einreichung via EBICS. Konkret sollen Börsenaufträge (etwa SWIFT MT502) mittels einer eigener Auftragsart vom Vermögensverwalter an die Bank übermittelt werden. Analog der bekannten Zahlungsauftragsschnittstellen werden bankseitig die Börsenorderschnittstellen angebunden. In diesem Kontext ist auch der Einsatz einer VEU denkbar.

Fazit:
Erste Banken in der Schweiz weiten ihr EBICS-Angebot über die Anwendungsfälle des Zahlungsverkehrs hinaus aus. Das Angebot von Credit Suisse für mittlere und grössere Vermögensverwalter setzt im Markt der EAM-Kundschaft ein Zeichen und wird wohl Nachahmer auf den Plan rufen. Softwarehersteller von Portfolio-Management-Systemen lernen langsam aber sicher das EBICS-Protokoll kennen und erweitern ihre Connectivity-Möglichkeiten um diese Anbindungsvariante. Der Phantasie, welche Formate und Standards in Zukunft über EBICS transportiert werden, sind keine Grenzen gesetzt. Es ist davon auszugehen, dass EBICS auch in anderen Domänen ausserhalb des Zahlungsverkehrs für ein bestimmtes Kundensegment eine echte Alternative zur Kommunikation über das SWIFT-Netz darstellt.

Carsten Miehling

Hacker-Angriffe auf den SWIFT-Zahlungsverkehr

81 Millionen US-Dollar – diese Riesensumme haben Kriminelle von der Zentralbank Bangladesch gestohlen. Nicht bei einem filmreifen Überfall, sondern ganz still mit einem Hacker-Angriff. Die Diebe veranlassten mehr als 30 Überweisungen vom Konto der Bangladesh Bank bei der New Yorker Federal Reserve Bank (Fed) auf philippinische Konten. Dieser und weitere Fälle zeigen: Der Interbanken-Zahlungsverkehr ist ein lohnendes Angriffsziel. Und die Sicherheit des internationalen Finanznetzes SWIFT ist verletzlich. Der Aufwand, dort einzudringen, ist sicherlich groß, aber die zu erwartende Beute noch größer. Angesichts solch professioneller Attacken steht die Sicherheit des Zahlungsverkehrs erneut ganz oben auf der Agenda.


Die Bangladesh Bank wurde im Februar 2016 auf zwei Ebenen angegriffen. Offensichtlich waren die IT-Sicherheitseinrichtungen mangelhaft: Die Zentralbank verfügt angeblich über keine Firewall und nur über veraltete Netzwerktechnik. Durch diese Tür gelangten die Diebe in das Banknetz und dort an die Zugangsdaten für Überweisungen. Im SWIFT-Client Alliance Access konnten sie sich damit als Auftraggeber der Transaktionen autorisieren. Für die Fed traten die Urheber als Zentralbank von Bangladesch auf.

Die Sicherheitslücke erlaubte es den Angreifern laut BAE Systems auch, eine eigens programmierte Schadsoftware im SWIFT-Alliance-Server zu installieren. Diese Software manipulierte die Bestätigungsnachrichten des SWIFT-Netzes und schaltete den Zugriffsschutz für die Datenbank aus. Die ausgeführten Transaktionen wurden nicht korrekt protokolliert, um die Spuren zu verwischen.
Der Hacker-Angriff hebelte die Sicherheitsmechanismen von SWIFT komplett aus und eröffnete den Dieben nahezu unbegrenzte Möglichkeiten. Die Gesamtsumme der angeforderten Transaktionen belief sich gar auf 951 Millionen US-Dollar. Ein ungewöhnlicher Tippfehler in einer Nachricht ließ eine beteiligte Bank in Bangladesch nachfragen, ob die Überweisung so gewünscht sei. Nur dadurch fiel der gesamte Betrug überhaupt auf. Da waren die 81 Millionen aber bereits überwiesen und in philippinischen Kasinos und Privathänden verschwunden. In der Folge mussten Atjur Rahman, der Chef der Zentralbank Bangladesch, und seine Stellvertreter im März 2016 zurücktreten.

SWIFT selbst hat eingeräumt, dass in den letzten Monaten mehrfach betrügerische Nachrichten über das Netz gesendet worden sind. Im Mai 2016 war eine Geschäftsbank von einem ähnlichen Betrugsfall betroffen: Kriminelle sind in die IT-Systeme eingedrungen, haben Nutzerdaten abgegriffen und Nachrichten manipuliert. Nun sollen Updates die Sicherheitslücken in der SWIFT-Software schließen.

Auch wenn SWIFT betont, der Angriff stelle nicht die Sicherheit des Netzes infrage, sondern die des Zugangssystems, zeigt der Fall das Dilemma geschlossener internationaler Netze. Auch mit hohem technischem Aufwand lassen sie sich nicht absolut abschotten. Außer der Software des Netzbetreibers können auch die umgebenden Banksysteme eine Schwachstelle sein. Ganz zu schweigen von kriminellen Mitarbeitern, die beim Betrug mithelfen. Und sind die Angreifer erstmal drinnen, steht ihnen die ganze Welt offen. Das schafft Anreize. Ein Verfahren wie EBICS nutzt das offene Internet und verfolgt ein Sicherheitskonzept, das stark auf Schlüsseln für die Kryptografie und Authentifizierung basiert. Das kann eine Alternative zum geschlossenen Netz sein.

Angesichts der potenziell sehr großen Schäden muss der Interbanken- und Firmenkunden-Zahlungs­verkehr umfassend geschützt werden. Es ist zu erwarten, dass Cyber-Attacken wie die hier beschriebene zunehmen. Letztlich müssen die Sicherheitsmechanismen des Verfahrens, der Bank-IT und für das Personal lückenlos ineinander greifen.

Michael Lembcke 

EBICS auf der iberischen Halbinsel

2014 haben die meisten portugiesischen Banken einen EBICS-Kanal eröffnet, der auf der Version 2.4.2 des Protokolls basiert. Tatsächlich eingesetzt wird bis dato allerdings nur das T-Profil, obwohl viele Unternehmen persönliche Signaturen verwenden möchten. Dies lässt darauf schließen, dass das TS-Profil in Kürze bereitgestellt wird.

Bis heute bieten nur sehr wenige spanische Banken ihren Firmenkunden die Möglichkeit, ihren Zahlungsverkehr über das EBICS-Protokoll abzuwickeln. Die Nachfrage danach nimmt jedoch immer stärker zu. Das beweist auch die hohe Teilnehmerzahl an einer Veranstaltung, die der Spanische Verband der Unternehmensfinanzierer (ASSET) am 20. Januar 2016 organisiert hat.
Einer der Gründe für das steigende Interesse liegt darin, dass bei den spanischen Unternehmen, wie bei den übrigen europäischen Unternehmen auch, der Bedarf wächst, Transaktionen mit Banken außerhalb der iberischen Halbinsel haben durchzuführen.

Die Veranstaltung, die von Gerardo de la Mata, Direktor von ASSET und Leiter des Ausschusses Zahlungsverkehr, geleitet wurde, beinhaltete verschiedene Vorträge, die den anwesenden Unternehmen, Banken und Herstellern den Nutzen von EBICS näherbrachten. Hierfür haben die Redner verschiedene und einander ergänzende Themen aufgegriffen, wie z. B.:
  • Axel Weiß, EBICS-Chairman, sprach zunächst über die Entstehung von EBICS und stellte anschließend dessen wichtigste Eigenschaften und Vorteile vor, bevor er die Arbeitsweise von EBICS SCRL erläuterte.
  • Thomas Stosberg, Deutsche Bank, referierte insbesondere die Gründe für die Einführung von EBICS und gab einen Überblick über die bisherigen Erfahrungen und die zukünftigen Weiterentwicklungen im Rahmen von BTF[1].
  • Mein Vortrag beleuchtete bestimmte Aspekte, z. B. die Sicherheit und die Anwendungsfälle in Frankreich und Deutschland – sowohl beim Zahlungsverkehr zwischen Unternehmen und Banken als auch im Interbankenverkehr. Außerdem habe ich dargelegt, wie EBICS in Frankreich implementiert worden und wie die Migration abgelaufen ist.
Die Fragen der Zuhörer betrafen im Wesentlichen den Punkt, ob man sich für eines der aktuell in Spanien verwendeten Protokolle (Editran, SWIFT) oder EBICS entscheiden solle. Hierfür gibt es vernünftige Entscheidungskriterien.

Es stimmt, dass in Spanien Editran im großen Umfang eingesetzt wird. Jedoch wird es von Banken und Unternehmen außerhalb Spaniens nur selten bzw. überhaupt nicht unterstützt. Deshalb entspricht Editran nicht den Bedürfnissen von Unternehmen und Banken, die grenzüberschreitenden Zahlungsverkehr abwickeln müssen.

Dafür müssen ein oder mehrere Protokolle verwendet werden, die den grenzüberschreitenden Datenaustausch unterstützen. Je nach Kontext ist die parellele Verwendung von EBICS und SWIFT durchaus vorstellbar, wie beispielsweise in Frankreich. EBICS könnte für die Kommunikation mit der wachsenden Anzahl von Banken, die Standorte in mehreren Staaten Europas haben, verwendet werden und SWIFT für die Kommunikation mit den anderen Banken.

Die Kosten für die Nutzung sind ebenfalls ein wichtiges Entscheidungskriterium. Unternehmen könnten (sollten) die Kosten durch den Einsatz des preisgünstigsten Standards optimieren.
Ein Thema, das ebenfalls auf reges Interesse der Teilnehmer stieß, war die verteilte elektronische Unterschrift (VEU) mit EBICS, insbesondere über das Handy, deren Einsatz in Deutschland bereits gang und gäbe ist. Daran ist nichts erstaunlich. Viel erstaunlicher ist hingegen die Tatsache, dass die VEU in Frankreich noch keine breite Anwendung findet.

Eine ähnliche Veranstaltung wird am 24. Februar in Barcelona stattfinden. Dafür haben sich bereits jetzt schon zahlreiche Teilnehmer angemeldet. Dies ist ein weiterer Beleg dafür, dass die Finanzindustrie unbedingt ein standardisiertes, universelles und effizientes Austauschverfahren wie EBICS benötigt (falls es solch eines Beweises überhaupt noch bedarf).

[1] Business Transactions & Formats

Marc Dutech 

Hochverfügbarer Zahlungsverkehr mit EBICS und SWIFT

Der europäische Interbanken-Zahlungsverkehr bewegt täglich mehrere Billionen Euro. Dieses gigantische Volumen wird bilateral und über nationale sowie europäische Clearer abgewickelt, beispielsweise TARGET2, STEP2 und SEPA-Clearer. Für die Wirtschaft und für unser gesamtes Leben ist ein ungehinderter Geldfluss essenziell. Deshalb sind die beteiligten IT-Systeme hoch sicherheitskritisch. Nur die redundante Nutzung der beiden Transportprotokolle EBICS und SWIFT stellt den erforderlichen hochverfügbaren Transport sicher.


Erstaunlicherweise sind die notwendigen Redundanzen im Gesamtprozess nicht konsequent umgesetzt. Hochverfügbarkeit wird meistens über redundante In-House-Systeme gewährleistet. Ein wesentlicher Schwachpunkt bei einen Systemausfall – der Single Point of Failure – bleibt jedoch bestehen: das elektronische Transportverfahren; auch dieses muss für den Störfall redundant ausgelegt sein.

SWIFT und EBICS sind die beiden gebräuchlichsten Transportprotokolle im internationalen Zahlungsverkehr. Sie garantieren hohe Übertragungssicherheit und großen Durchsatz – beides Voraussetzungen für eine Dual-Transport-Strategie. Zudem müssen die Systeme unabhängig voneinander sein. Dies ist nur mit einer Dual-Vendor-Strategie gewährleistet. Der Schlüssel zur Hochverfügbarkeit ist also die Kombination aus Dual-Vendor-Strategie und Dual-Transport-Strategie.
Die Dual-Vendor-Strategie wird bereits in hoch sicherheitskritischen Szenarien eingesetzt, um die Ausfallsicherheit zu erhöhen. Damit kann das System eines Herstellers nicht mehr der Single Point of Failure sein.

Betrachten wir die Dual-Transport-Strategie mit SWIFT und EBICS: Die Netzwerktopologien beider Transportprotokolle sind komplementär:

SWIFTEBICS
Topologiesternförmigvermascht
Managementmanagedself-managed
Ausfallzentralselbstheilend
ÜbertragungsartKabelKabel und Satellit

Bei EBICS werden Störungen durch Selbstheilung behoben, d. h. die Daten werden automatisch umgeleitet. Dagegen wird bei SWIFT das sternförmige Netz zentral verwaltet. Diese Komplementarität ist bei Störungen von Vorteil, da sie einen Single Point of Failure inhärent ausschließt. SWIFT und EBICS sind durch die Dual-Vendor-Strategie unabhängig voneinander und daher prädestiniert für eine Dual-Transport-Strategie.

Im Störungsfall bei EBICS kann die Bank oder das Clearing-Unternehmen den technischen Übertragungsweg beeinflussen. Falls die terrestrischen Leitungen ausfallen, kann auf Funk oder extraterrestrische Systeme – also Satelliten – umgeschaltet werden. Per Satellit ist der gesamte besiedelte Erdball zu erreichen. Dies ist ein Vorteil von EBICS gegenüber Managed Networks wie SWIFT.

Aber wie sieht es in der Praxis aus? Angesichts der Risiken im Interbanken-Zahlungsverkehr ist die Kombination aus Dual-Transport-Strategie mit EBICS und SWIFT und Dual-Vendor-Strategie nur angemessen. Daher ist es auch nicht verwunderlich, dass Services wie STEP2 der EBA Clearing und SEPA-Clearer der Deutschen Bundesbank sowohl EBICS als auch SWIFT anbieten und zudem die Dual-Vendor-Strategie einsetzen. Ein Wechsel zwischen den beiden Transportprotokollen ist in kurzer Zeit untertägig möglich. Deutsche Banken und eine französische Bank nutzen derzeit schon EBICS und SWIFT, um Schäden durch Ausfälle zu minimieren. Weitere europäische und auch amerikanische Banken werden sicherlich folgen.

Erstaunlich ist nur, dass der Regulator dieses Feld noch nicht betreten hat. Die Auswirkungen eines Störfalls wären unabsehbar.

Michael Lembcke 

EBICS-Event stößt in Luxemburg auf großes Interesse

Der EBICS-Standard ist dabei, sich in Europa weiter zu verbreiten. Mit Interesse schauen Fachleute daher auch auf den Finanzplatz Luxemburg. Am 28. Januar 2015 versammelten sich dort Zahlungsverkehrsexperten aus dem Fachbereich und der IT der Luxemburgischen Banken, um mehr über EBICS zu erfahren. Zu dem Event mit dem Titel „EBICS – A New Communication Protocol for Payment Activities“ hatte die Luxemburgische Bankenvereinigung ABBL geladen.


Im Mittelpunkt stand die Frage, ob EBICS für Luxemburg von Interesse sein könnte. Die Agenda war auf diese Fragestellung ausgerichtet, vertreten waren folgende Sprecher und Themen:
  • Welcome, Serge Wagener, Banque et Caisse d’Epargne de l’Etat
  • EBICS at a Glance - Security, Use and Implementations, Hermann Fürstenau, PPI AG
  • EBICS - a chance to harmonise customer-to-bank communication standards for electronic banking in Europe, Axel Weiß, EBICS Chairman
  • EBICS Strategy of Deutsche Bank, Thomas Stosberg, Deutsche Bank
  • STEP2 and EBICS, Katja Heyder, EBA Clearing
EBICS wurde dabei unter den Gesichtspunkten Kunde-Bank- und Interbank-Kommunikation beleuchtet, mit besonderem Fokus auf der sicheren Datenübertragung mit EBICS über das Internet. Zu den relevanten Themen für die luxemburgischen Experten zählten auch die Verteilte Elektronische Unterschrift sowie die Unterschiede zwischen der französischen und der deutschen EBICS-Ausprägung.

Der STEP2-Zugang über EBICS zur europäischen Zahlungsverkehrsdrehscheibe war ebenfalls von besonderem Interesse für die Luxemburgische Banken-Community, weil sich dadurch die Kosten reduzieren lassen und ein Backup die Ausfallsicherheit erhöht. Die möglichen Einsatzszenarien für STEP2 und EBICS müssen individuell für jede Bank einzeln betrachtet werden. Wenn ein Backup allerdings unter regulatorischen Maßgaben gefordert werden sollte – was derzeit möglich erscheint – ist EBICS die beste Lösung. Bereits heute schon operieren einige Banken aus Sicherheitsgründen mit zwei unterschiedlichen Infrastrukturen: SWIFT und EBICS. Die komplementären Netz-Topologien von EBICS und SWIFT eignen sich hervorragend als gegenseitiges Backup. Aber auch die Kosten sind häufig ein ausschlaggebender Grund für die Nutzung von EBICS.

Eine wesentliche Motivation für die Luxemburgischen Banken ist natürlich, dass Deutschland und Frankreich einen gemeinsamen EBICS-Standard entwickelt haben. Darüber hinaus wird der EBICS-Standard von einer schlanken EBICS-Gesellschaft mit Sitz in Brüssel weiterentwickelt und weiter verbreitet. Die Schweiz ist dabei, in die EBICS-Gesellschaft aufgenommen zu werden. Vielleicht könnte ja Luxemburg als 4. Mitglied folgen.

Die Idee eines "Global EBICS" ist für einige Banken von strategischer Bedeutung, was auch während der Diskussion in Luxemburg deutlich wurde. "Global EBICS" – oder kurz GBICS – geht mit einem einheitlichen ISO20022-Format à la CGI (Common Global Implementation) einher. CGI dient dabei als einheitlicher Formatstandard und GBICS als einheitlicher Transportstandard und das weltweit. Spannend war in diesem Zusammenhang die Frage nach einem weltweiten Konkurrenzstandard zu EBICS: Gibt es einen vergleichbaren Standard wie EBICS in der Welt, beispielweise in Asien oder Amerika? Diese Frage muss klar mit nein beantwortet werden. Es scheint, wenn überhaupt, nur nationale Standards zu geben, die größtenteils schon sehr betagt sind. Das technische und fachliche Handwerkszeug, was EBICS mitbringt, ist außer Frage hervorragend. Damit hat EBICS – oder besser gesagt GBICS – wirklich das Potential, zu einem weltweiten Standard aufzusteigen.

Michael Lembcke 

Mehr Sicherheit, geringere Kosten: STEP2 Clearing mit EBICS

Seit Ende letzten Jahres bietet die EBA Clearing neben SWIFT auch EBICS als Zugangskanal für STEP2 an. Die Blaupause dafür stammt von der Deutschen Bundesbank, die bereits 2008 ihren SEPA-Clearer über SWIFT und EBICS zugänglich machte. Was sind die Gründe, warum EBA Clearing neben einem SWIFT- auch noch einen EBICS-Zugang anbietet? Der Anstoß dazu kam von einigen Banken und Sparkassen aus Deutschland. Die Motivation waren die Kosten: Bei EBICS fallen keine Transaktionskosten für den Transport an.


Im bilateralen Clearing zwischen den Banken, das in Deutschland auch als "Garagen-Clearing" bekannt ist und extensiv genutzt wurde, fallen für den Transport und das Clearing keine Kosten an. Die jeweils beteiligten Banken tragen die Kosten für den Transport und das Clearing selbst. Bei der Umstellung auf ein zentrales Clearing fallen natürlich Kosten für das Clearing an. Um die Kosten nicht noch weiter in die Höhe zu treiben, sollten die Kosten für den Transport, die jedes Kreditinstitut selbst trägt, so gering wie möglich gehalten werden. Daher fiel die Entscheidung auf EBICS, da bei EBICS – abgesehen von reinen Betriebskosten – keine Transaktionskosten für den Transport anfallen.
Ein zweiter Aspekt wird zudem immer wichtiger: Sicherheit! Im Interbankenzahlungsverkehr liegen die täglichen Geldmengen im Milliardenbereich. Eine Störung des Geldflusses von wenigen Stunden führt bereits zu Verwerfungen, die erhebliche Auswirkungen für die Wirtschaft haben können. Daher wird zunehmend die Frage nach einem Backup-Transportverfahren für das Clearing im Interbankenzahlungsverkehr gestellt. Auch dafür würde sich EBICS hervorragend eignen, beispielsweise EBICS als Backup für SWIFT. EBICS und SWIFT werden bereits bei einigen Banken parallel für das Clearing eingesetzt. Es scheint zudem unwahrscheinlich, dass sich der Regulierer auf Dauer mit einem einzigen Transportverfahren begnügt. In fast allen Bereichen der Bank wurden die Sicherheitsanforderungen deutlich verschärft, zum Beispiel durch die PSD II. Eine zukünftige Verschärfung der Sicherheitsanforderungen im Interbankzahlungsverkehr scheint daher nicht ausgeschlossen zu sein.