Halbzeitpfiff – erste Bilanz der EZB zur zweijährigen Analysephase „Digitaler Euro“

Wie bereits in einem vorangegangenen Blogbeitrag berichtet, ist die Europäische Zentralbank (EZB) im Oktober 2021 mit einem zweijährigen Analyseprojekt gestartet, das bewertet, wie der digitale Euro gestaltet werden soll. Als Ergebnis dieser Analysephase wird 2023 entschieden werden, ob und in welcher Form die EZB den digitalen Euro bereitstellt.

Zur Halbzeit der zweijährigen Periode wurde am 29. September 2022 ein Zwischenbericht von der EZB veröffentlicht. Dieser Bericht beleuchtet zahlreiche Fragen und Thesen, mit denen wir uns in der vergangenen Blogserie zum digitalen Euro beschäftigt haben. So greift der EZB-Bericht die erzielten Fortschritte auf und geht auf die grundlegenden Gestaltungsoptionen des digitalen Euros ein, die kürzlich vom EZB-Rat genehmigt wurden. Welche das sind, wollen wir in diesem Beitrag kompakt darlegen:

Online- und offlinefähige Zahlungsausführung
Aktuell fokussiert sich die EZB auf die folgenden zwei Transaktionsoptionen:

  1. Ausführung von Onlinetransaktionen, die von einem Intermediär validiert werden
  2. Ausführung von Offlinetransaktionen im Peer-to-Peer-Kontext, die direkt bzw. ohne Intermediär validiert werden

Datenschutz, Anonymität und Guthabensteuerung
In puncto Verbrauchervertrauen beschreibt der EZB-Rat in seinem Bericht, dass der digitale Euro voraussichtlich ähnliche Datenschutzbestimmungen wie die aktuellen digitalen Zahlungsverfahren aufweisen wird. Zahlungen mit geringem Wert sollen einen höheren Datenschutz erhalten als Zahlungen mit vergleichbaren Höchstbeträgen. Eine vollumfängliche anonyme Zahlungsausführung ohne Betragsgrenzen ist aktuell nicht vorgesehen.
Darüber hinaus wird in Erwägung gezogen, dass Limits zur Guthabensteuerung eingeführt werden. Ziel soll es dabei sein, dass die Haltung des digitalen Euros eingeschränkt wird, um keine alternativen Anlageform für Verbraucher künstlich zu kreieren.

Wichtige Meilensteine im Jahr 2023

  1. Im ersten Quartal 2023 wird die Europäische Kommission einen Vorschlag für eine Verordnung zur Einführung des digitalen Euros erarbeiten.
  2. Bis Ende Oktober 2023 soll der EZB-Rat entscheiden, ob und wie die Entwicklung des digitalen Euros fortgesetzt wird. Die darauffolgende Phase kann sich über drei Folgejahre strecken.

Quelle: EZB
https://www.ecb.europa.eu/paym/digital_euro/investigation/governance/shared/files/ecb.degov220929.en.pdf


Öffentliche Gelder als Katalysator?
Auch wenn die Halbzeitbilanz noch viel Interpretations- und Gestaltungsspielraum lässt, werden erste Tendenzen deutlich. Ähnlich wie im Bericht beschrieben, sehen wir als PPI, dass öffentliches Geld in digitaler Form einen wichtigen Beitrag zum digitalen Zeitalter leisten kann. Der digitale Euro im aktuellen Verbraucherkontext wäre ein erster wichtiger Grundstein. Daher verfolgen wir dieses Thema weiterhin mit großer Begeisterung und werden auch in Zukunft im EBICS-Blog die Entwicklungen zum digitalen Euro genau verfolgen. 

Bis zum nächsten Mal.


Autor: Philipp Schröder

EBICS-Echtzeiteinreichung oder – wer überweist Millionen Euro mit PayPal?

Zugegeben, was die Entwicklung der FinTechs in den letzten Jahren auf den Markt gebracht haben, ist smart, schlank und vor allem schnell. Direktes Feedback auf mobilen Endgeräten unterwegs am Point-of-Sale oder auf dem Sofa beim Onlineshopping ist heute völlig normal, und moderne Shopper möchten dies auch nicht mehr missen.

Aber stellen Sie sich vor, Sie müssen große Geldmengen transferieren oder haben die Verantwortung für fremde Gelder Ihres Unternehmens. Welche Maßstäbe legen Sie hier an die Sicherheit und zuverlässige, transparente Abwicklung Ihrer Zahlungen? Volumina nicht nur in der Geldsumme, sondern auch technische Größen der Dateiverarbeitung bei Massenzahlungen, setzen andere Verfahren voraus, die lange erprobt und mit vertrauten Partnern der Banken etabliert sind. EBICS mit Batchverarbeitung großer Sammeldateien ist der europäische Bankenstandard, auf den alle Zahlungsexperten setzen, und der Schritt für Schritt von mehr europäischen Ländern verbindlich eingeführt wird. Diese etablierten EBICS-Konzepte wurden nun auf Echtzeiteinreichung und Instant-Zahlungen für eine innovative Onlineverarbeitung adaptiert.

Sicherheit schließt Schnelligkeit nicht aus
Die Kommunikation mit Ihren etablierten Banken und der sichere Transfer Ihrer Zahlungsdateien wird jetzt auch mit EBICS als Echtzeiteinreichung bereitgestellt. Basierend auf der mit der EBICS-Echtzeitspezifikation eingeführten WebSocket-Schnittstelle werden erfasste Zahlungen oder hochgeladene Zahlungsdateien mit der Auftragsart WIP (oder entsprechendem BTF mit EBICS 3.0) beim Bankserver eingereicht. Im EBICS-Client erhält der Anwender sofort eine aktive Erfolgsmeldung als Pushnachricht über die Verarbeitung der Zahlung bei der Bank als C5N-Avise. Die Standard-Protokollrückmeldungen des Statusreports pain.002 der Bank werden selbstverständlich zusätzlich bedient. All das ist möglich, wenn alle beteiligten Produkte im durchgängigen Prozess perfekt aufeinander abgestimmt und integriert sind. Auch mobile EBICS-Apps für die Zahlungsfreigabe unterwegs bilden diese Echtzeitprozesse ab.

Sicher auf der Überholspur
Erste Banken gehen mit diesem Feature in Produktion, um Ihren Kunden gewohnte Qualität und Sicherheit bei innovativer Schnelligkeit zur Verfügung zu stellen. Bis in den Buchhaltungen der Unternehmen die großen Geldtransfers vom Sofa aus „smart“ und schnell überwiesen werden, mag zwar nach etwas dauern.

Aber wer weiß, welche Gewohnheiten sich mittlerweile in manchem Homeoffice eingeschlichen haben. Das dezentrale Arbeiten hat auf jeden Fall eine neue Dimension erreicht. Die meisten Firmen bieten nun Homeoffice an, und auch Abteilungsleiter und Prokuristen arbeiten von zu Hause. Freigaben großer Zahlungen mit verteilten Unterschriften werden also genauso von dort in Echtzeit eingereicht und sofort bestätigt.

Das WebSocket-Protokoll bietet darüber hinaus die Zusatzoption, auch Benachrichtigungen von der Bank an die Nutzer der Zahlungsanwendung zu pushen. Neben den einfachen Statusrückmeldungen zu Zahlungen kommuniziert die Bank so zusätzlich in Textnachrichten mit ihren Kunden. Die Nachrichten tauchen auf Wunsch des Anwenders als FlyIn an der Oberfläche auf und werden in einem eigenen Postfach zum Nachlesen und Herunterladen gesammelt.

APIs hin oder her: Smart und schnell bei gewohnten Sicherheitsstandards Ihrer Bank – mit EBICS auch kein Problem!

Autor: Christian Veith


DORA – Digital Operational Resilience Act Teil 2: Ausblick und Ziele

Mit DORA soll den wachsenden Cyberrisiken begegnet werden. Welche Regelungen sind geplant? Wer wird von den Regelungen betroffen sein?

Dieses wollen wir in zwei separaten und aufeinanderfolgenden Blogbeiträgen beleuchten. Im ersten Teil sammeln wir Informationen über Steuerung und Organisation und betrachten die umfangreichen Anforderungen an das IKT-Risikomanagement, die Meldung IKT-bezogener Vorfälle sowie die Risiken durch IKT-Drittanbieter.

Im zweiten Teil geben wir einen Ausblick auf die bevorstehenden Entwicklungen – bis hin zu der Frage, wie US-amerikanische Cloudanbieter dazu motiviert werden können, Niederlassungen in der EU zu erwägen.


Teil 2

Das Europäische Parlament und der Rat werden den offiziellen Verordnungstext, voraussichtlich im Herbst 2022 annehmen und anschließend wird dieser im Amtsblatt der Europäischen Union veröffentlicht. Erwartet wird, dass die DORA-Verordnung Ende 2024 in der gesamten EU gilt. Bereits zum jetzigen Zeitpunkt sollten sich Banken und Finanzdienstleister über die Umsetzung eines angemessenen IKT-Risikomanagements Gedanken machen und geeignete Maßnahmen in Betracht ziehen.

Finanzunternehmen im Zahlungsverkehr haben ein intrinsisches Interesse daran, ihre digitale Betriebsstabilität zu schützen und resilienter gegenüber Cyberangriffe zu machen, weil Betriebsstörungen zu erheblichen Umsatzeinbußen und – damit einhergehend – zu immensen Reputationsschäden führen können. Die Tatsache, dass große Kreditinstitute und Fin- und BigTechs eine große Projektionsfläche für Hackerangriffe darstellen und die exponenziell voranschreitende Digitalisierung immer relevanter wird, untermauern die Erfordernis, EU-Maßnahmen zur Stärkung der digitalen Betriebsstabilität von Finanzunternehmen zu implementieren.

Dadurch, dass Finanzunternehmen in der Regel sehr stark miteinander vernetzt sind, kann schon ein lokal begrenzter Cybervorfall enorme Systemrisiken für den Finanzsektor bergen und die Finanzstabilität gefährden. Die von Finanzunternehmen bereitgestellten Produkte und Dienstleistungen sind oft elementar für das Funktionieren einer Gesellschaft. Die Kosten, die durch einen Cyberangriff entstehen, bedeuten oft sehr hohe Kosten für Gesellschaft und Finanzunternehmen.

Einerseits könnten Finanzunternehmen angesichts von Meldekosten und möglichen Reputationsschäden abgeschreckt sein, Cybervorfälle an die zuständigen Behörden zu melden. Andererseits könnten Meldungen über Cybervorfälle einen erheblichen externen Nutzen dahingehend erzeugen, dass andere Finanzunternehmen Sicherheitslücken erkennen und schließen könnten. Dem Verordnungsvorschlag mangelt es jedoch an der Verhältnismäßigkeit. Das IKT-Risikomanagement von Finanzunternehmen sollte sich lediglich auf kritische Elemente der digitalen Betriebsstabilität konzentrieren. DORA umfasst hingegen alle physischen Komponenten, Infrastrukturen, Räumlichkeiten und Rechenzentren, unabhängig von deren operationellem Risiko. 

DORA verpflichtet Finanzunternehmen, Verträge mit kritischen IKT-Drittanbietern zu kündigen, wenn diese gegen Gesetze, Verordnungen, Richtlinien oder Vertragsbedingungen verstoßen oder wenn sie von einer Finanzaufsichtsbehörde dazu gezwungen werden.

Das dürfte das operationelle Risiko für Finanzunternehmen erhöhen, weil es schwierig sein dürfte, ad hoc geeignete alternative Anbieter zu finden. Stattdessen sollte DORA, die enge Abstimmung der betroffenen Akteure fördern, einen Sanktionsstufenkatalog artikulieren und zumindest Übergangsfristen vorsehen. Ein striktes Vertragskündigungsmandat sollte das letzte Mittel sein.

Die Beschränkung, IT-Lieferverträge mit kritischen IKT-Drittanbietern aus Drittländern abzuschließen, ist ein starker Eingriff in die Vertragsfreiheit der europäischen Finanzunternehmen. Diese Maßnahme könnte der Stärkung der digitalen Betriebsstabilität paradoxerweise zuwiderlaufen, weil sich Finanzunternehmen gezwungen sehen könnten, Verträge mit Anbietern abzuschließen, die einen geringeren Cyberreifegrad aufweisen. Diese Einschränkung hat das Potenzial, die Auswahl und den Zugang zu cybersicheren und innovativeren IKT-Lösungen, Produkten und Dienstleistungen zu begrenzen.

Die Ziele der EU-Kommission, die Abhängigkeit des europäischen Finanzsektors von US-amerikanischen Cloud-Anbietern zu vermindern, sollte nicht in Aktionismus umschlagen. Eine zielgerichtetere Maßnahme wäre es, diese Anbieter durch regulatorische Maßnahmen dazu zu veranlassen, Niederlassungen in der EU zu gründen, damit diese effektiver von den hiesigen Aufsichtsbehörden im Zusammenhang mit operationellen Risiken überwacht werden könnten.

In 2023 obliegt der European Banking Authority (EBA) das Mandat, die regulatorischen Rahmenbedingungen für MiCAR und DORA zu schaffen. Neben der Aufsichtspflicht ist die EBA mit der Aufgabe betraut, Aufsichtsrichtlinien und Verfahren zu entwickeln, sowie Guidelines zu erstellen, die den Informationsaustausch zwischen allen relevanten Parteien sicherstellen sollen. Dazu gehören unter anderem beaufsichtigte Emittenten von Krypto-Assets, die zuständigen nationalen Behörden, die EZB und andere relevante Zentralbanken. Die Zeit hierfür ist knapp bemessen, da alles noch vor dem Anwendungsdatum von MiCAR und DORA passieren muss. Das zu entwickelnde Framework für DORA wird einen aufsichtsrechtlichen Rahmen bilden, um die Überwachung und die Eindämmung von Cyberrisiken und IKT-bezogenen Vorfällen zu gewährleisten. Für die MiCAR-Verordnung hingegen wird die EBA spezifische Anforderungen zur Ausgabe von Krypto-Assets und das Angebot von Kryptodienstleistungen ausarbeiten müssen.

Quelle der Abbildung: EU Digital Operational Resilience Act (DORA) | Compliance | Haufe


Autoren:
Salar Hydary (Bachelor of Laws/ Werkstudent PPI AG, Consulting Payments, Bereich Regulierung Zahlungsverkehr)
Judith Petersen (Senior Manager PPI AG, Consulting Payments, Leitung Bereich Regulierung Zahlungsverkehr)

DORA – Digital Operational Resilience Act: Teil 1: Warum die digitale Betriebsstabilität einheitlich auf EU-Ebene zu bewerten ist

Mit DORA soll den wachsenden Cyberrisiken begegnet werden. Welche Regelungen sind geplant? Wer wird von den Regelungen betroffen sein?
Dieses wollen wir in zwei separaten und aufeinanderfolgenden Blogbeiträgen beleuchten. Im ersten Teil sammeln wir Informationen über Steuerung und Organisation und betrachten die umfangreichen Anforderungen an das IKT-Risikomanagement, die Meldung IKT-bezogener Vorfälle sowie die Risiken durch IKT-Drittanbieter.
Im zweiten Teil geben wir einen Ausblick auf die bevorstehenden Entwicklungen – bis hin zu der Frage, wie US-amerikanische Cloudanbieter dazu motiviert werden können, Niederlassungen in der EU zu erwägen.

Teil 1

Die Europäische Kommission, der Rat der Europäischen Union und das Europäische Parlament, haben am 22. Mai 2022 eine vorläufige Einigung über den Vorschlag zur digitalen Betriebsstabilität (Digital Operational Resilience Act – DORA) erzielt. DORA rückt somit im Rahmen der Strategie zur Digitalisierung des gesamten europäischen Finanzsektors als ein integraler Bestandteil in den Mittelpunkt. Die Europäische Kommission hatte den Legislativvorschlag zu DORA erstmals am 24. September 2020 im Zuge des Digital Finance Package veröffentlicht. Das Triumvirat aus Kommission, Rat und Parlament hat bereits im September 2020 das Digital Finance Package zur Realisierung einer grenzüberschreitenden Digitalisierung verabschiedet.
Das Digital Finance Package umfasst die folgenden Teile:

  • Strategie zur Digitalisierung des Finanzsektors
  • Legislativvorschläge zu Kryptowerten (Markets in Crypto Asset Regulation, Distributed-Ledger-Technology-Pilotregelung und die Transfer of Funds Regulation)
  • Legislativvorschläge zur Betriebsstabilität digitaler Systeme (DORA) des Finanzsektors
  • Strategie für den Massenzahlungsverkehr  

Die europäische Strategie zur digitalen Betriebsstabilität wurde mit den beiden wichtigen Kryptoverordnungen Markets in Crypto Assets Regulation (MiCAR) und der Transfer of Funds Regulation (ToFR) komplettiert. Am 30. Juni 2022 gab die Europäische Union grünes Licht für die MiCAR-Verordnung zur Überwachung der Kryptobranche.
Bereits einen Tag zuvor, am 29. Juni 2022, hatte das Europäische Parlament eine Einigung über die ToFR-Verordnung erzielt.
Mit DORA soll das Ziel verfolgt werden, einerseits die Finanzstabilität, den Verbraucherschutz und die Marktintegrität zu gewährleisten und andererseits, regulatorische Hindernisse im Finanzsektor durch eine Rechtsharmonisierung effektiv zu beseitigen. Außerdem wird ein EU-weites, sektorübergreifendes Framework geschaffen, um die Risiken, die im Zusammenhang mit Informations- und Kommunikationstechnologien (IKT-Risken) auftreten, zu steuern und zu mindern. Von der DORA-Verordnung betroffen sind traditionelle Finanzakteure wie Banken, Versicherungen und Investmentgesellschaften, aber auch Fin- und BigTechs, Krypto-Dienstleister und Handelsplätze. Vom Anwendungskreis ausgenommen sind Kleinstunternehmen, die weniger als 10 Personen beschäftigen und deren Jahresumsatz bzw. Jahresbilanz 2 Mio. EUR nicht überschreitet. (Art. 3 S. 1 Ziff. 50 in Verbindung mit Artikel 2 Absatz 3 des Anhangs der Empfehlung 2003/361/EG).

Steuerung und Organisation
Banken und Finanzdienstleister sollten über interne Governance- und Kontrollrahmen verfügen, die eine wirksame und umsichtige Steuerung aller IKT-Risiken gewährleisten (Art. 4 Abs. 1). Banken und Finanzdienstleister sollten über einen soliden, umfassenden und gut dokumentierten IKT-Risikomanagementrahmen verfügen, welcher es ihnen ermöglicht, IKT-Risiken unmittelbar und effizient anzugehen (Art. 5 Abs. 1). Das Leitungsorgan definiert, genehmigt und überwacht den IKT-Risikomanagementrahmen und ist für dessen Umsetzung rechenschaftspflichtig. Um eine gut funktionierende Governance zu gewährleisten, sollten Gelder für Investitionen in IKT-Ressourcen, einschließlich Schulungsmaßnahmen zu IKT-Risiken für Mitarbeitende, bereitgestellt werden (Art. 4 Abs. 2). 

Anforderungen an das IKT-Risikomanagement
Die in DORA aufgeführten Anforderungen zur Erfüllung eines angemessenen IKT-Risikomanagements verlangen spezifische Funktionen. Der IKT-Risikomanagementrahmen wird mindestens einmal jährlich, sowie beim Auftreten schwerwiegender IKT-bezogener Vorfälle, die sich aus Prüfungen oder Auditverfahren für die digitale Betriebsstabilität ergeben, dokumentiert und überprüft. Das Ziel ist es, potenzielle Bedrohungen frühzeitig zu identifizieren, Erkenntnisse zu gewinnen und eine kontinuierliche Verbesserung des IT-Risikomanagements zu gewährleisten. (Art. 5 Abs. 9 DORA)
Das IKT-Management muss den Schutz und die Prävention vor Cyberangriffen sicherstellen bzw. die Anfälligkeit für Cybervorfälle auf ein Mindestmaß reduzieren, sowie Strategien und Verfahren implementieren, die die "Resilienz, Kontinuität und Verfügbarkeit von IKT-Systemen" und "hohe Standards in Bezug auf Sicherheit, Vertraulichkeit und Integrität von Daten" gewährleisten (Art. 8 Abs. 2).
Banken und Finanzdienstleister sollten eine IKT-Strategie implementieren, die darauf ausgerichtet ist, auf alle IKT-bezogenen Vorfälle, insbesondere Cyberangriffe, unverzüglich, wirksam und angemessen reagieren zu können, sodass Schäden möglichst begrenzt auftreten, die Wiederaufnahme von Tätigkeiten und die Wiederherstellung des Betriebs möglichst gewährleistet werden können (Art. 10 Abs. 2). Die Implementierung von Mechanismen, die sowohl Schwachstellen aufdecken als auch alle IKT-bezogenen Vorfälle aufzeichnen, ist unabdingbar.
Als besonders kundenorientierter und als integer geltender Marktakteur, sollten Banken und Finanzdienstleister über Kommunikationspläne verfügen, die „eine verantwortungsbewusste Offenlegung IKT-bezogener Vorfälle oder erhebliche Anfälligkeiten gegenüber Kunden und anderen Finanzunternehmen, sowie der Öffentlichkeit ermöglichen“ (DORA Art. 13 Abs. 1). 

Meldung IKT-bezogener Vorfälle
DORA verlangt von Banken und Finanzdienstleistern die Einführung von Managementverfahren zur Überwachung, Ermittlung, Klassifizierung, Verfolgung, Protokollierung und Meldung schwerwiegender IKT-bezogener Vorfälle an die zuständigen Behörden (Art. 15 Abs. 1).
Adressaten der Meldungen schwerwiegender IKT-Vorfälle sind die zuständigen nationalen Behörden. Banken und Finanzdienstleister müssen anderen Institutionen oder Ämtern – beispielsweise den European Supervisory Authorities (ESA), der Europäischen Zentralbank (EZB) oder den gemäß der Richtlinie über die Sicherheit von Netz- und Informationssystemen (NIS-Richtlinie) benannten zentralen Anlaufstellen, sachdienliche Einzelheiten zu den Vorfällen mitteilen. Schwerwiegende IKT-bezogene Vorfälle sind durch die Behörden auf Unionsebene zentralisiert zu melden. Finanzunternehmen werden verpflichtet, Erst-, Zwischen- und Abschlussberichte vorzulegen. Sollte ein IKT-bezogener Vorfall Auswirkungen auf die finanziellen Interessen von Dienstnutzern und Kunden des jeweiligen Finanzunternehmens haben, sollten diese unverzüglich darüber unterrichtet werden (Art. 17 Abs. 2).

Eine wesentliche Aufgabe der ESA ist es, jährlich einen umfassenden Bericht in anonymisierter Form zu veröffentlichen, der Auskunft über die Meldungen zuständiger Behörden zu schwerwiegenden IKT-bezogenen Vorfällen gibt. Dies betrifft die Mindestanzahl schwerwiegender Vorfälle, ihre Art, die Auswirkungen auf die Geschäftstätigkeit von Finanzunternehmen oder Kunden, sowie die Kosten (Art. 20 Abs. 2). Darüber hinaus verpflichtet der Verordnungsentwurf Finanzinstitute sicherzustellen, dass Verträge über die Nutzung von IKT-Diensten gekündigt werden, wenn IKT-Drittanbieter gegen geltende Gesetze, Verordnungen oder Vertragsbedingungen verstoßen (Art. 25 Abs. 8). 

Prüfung der digitalen Betriebsstabilität
Das IKT-Risikomanagement von Banken und Finanzdienstleistern muss regelmäßig auf die Abwehrbereitschaft und die Aufdeckung von Schwachstellen, Mängeln oder Lücken sowie auf die umgehende Umsetzung von Korrekturmaßnahmen geprüft werden. IKT-Systeme müssen regelmäßig auf Herz und Nieren geprüft werden. Eine solche Überprüfung muss mindestens einmal jährlich durchgeführt und entsprechend dokumentiert werden. Die Durchführung von Präventions-, Erkennungs-, Reaktions- und Wiederherstellungstests sind unabdingbar, um alle Schwachstellen, Mängel oder Lücken umfassend zu beheben (Art. 21 Abs. 5).

Als wichtigste Instrumente für die Prüfung der digitalen Betriebsstabilität sind folgende zu benennen (Art. 22):

  • Bewertungen und Überprüfungen der Anfälligkeit
  • Analysen von Open-Source-Software
  • Bewertungen der Netzsicherheit
  • Lückenanalysen
  • Analysen der physischen Sicherheit
  • Überprüfungen der physischen Sicherheit
  • Fragebögen und Scansoftwarelösungen
  • Quellcodeprüfungen, soweit durchführbar
  • szenariobasierte Tests
  • Kompatibilitätstests
  • Leistungstests
  • End-to-End-Tests
  • bedrohungsgesteuerte Penetrationstests


Wie anspruchsvoll die Belastbarkeitstests sein müssen, hängt maßgeblich von der Größe des Geschäfts- und Risikoprofils eines jeden Finanzunternehmens ab.
Besonders hohe Anforderungen für die Prüfungen der digitalen Betriebsstabilität gelten für bedeutende Institute im Zahlungsverkehr, zum Beispiel große Kreditinstitute, große Zahlungsinstitute und große E-Geld-Institute. Dies gilt auch für Teilsektoren, die eine zentrale Rolle im Zahlungsverkehr, im Bankenwesen, im Clearing und in der Abrechnung spielen. 

Risiken durch IKT-Drittanbieter
Einen besonderen Fokus legt DORA auf die EU-Aufsicht über sogenannte IKT-Drittanbieter und das damit einhergehende IKT-Drittrisiko. Die Auslagerung von digitalen Funktionen spielt heutzutage eine wichtige Rolle in der IKT-Strategie von Finanzunternehmen. Hier kommen die IKT-Drittanbieter ins Spiel. Sie offerieren den Finanzunternehmen die Bereitstellung von Speicherplatz oder Rechnerleistung (Infrastructure as a Service) bis hin zur Bereitstellung von Softwareapplikationen (Platform as a Service).
Auslagerungen können nur dann funktionieren, wenn die Finanzinstitute die Untervergabeprozesse vollwertig überwachen und kontrollieren können. Finanzunternehmen, die IKT-Dienstleistungen von IKT-Drittanbietern in Anspruch nehmen, sind dafür verantwortlich, dass sich diese an die DORA-Verordnung halten (Art. 25 Abs. 1). Stellt ein Finanzunternehmen indes fest, dass der IKT-Drittanbieter bei der Erbringung von IT-Dienstleistungen gegen geltende Gesetze, Verordnungen oder Vertragsbedingungen verstößt, muss diesem gekündigt werden (Art. 25 Abs. 8). Die Finanzunternehmen müssen Ausstiegsstrategien einrichten, um mit Ausfällen von IKT-Drittanbieter umgehen zu können. Die Vertragskündigung darf der Einhaltung regulatorischer Anforderungen nicht zuwiderlaufen oder die angebotenen Dienstleistungen qualitativ beeinträchtigen (Art. 25 Abs. 9).
Zusammenfassend kann man konstatieren, dass DORA darauf abzielt, dass ein EU-Aufsichtsrahmen für "kritische" IKT-Drittanbieter geschaffen werden soll (Art. 28 Abs. 1). DORA räumt dem Finanzunternehmen das Recht ein, die zu erbringenden Leistungen des IKT-Drittanbieters vollumfänglich zu überwachen (Art. 27 Abs. 2). Dabei können die zuständigen Finanzaufsichtsbehörden die Finanzunternehmen zwingen, ihre Verträge mit IKT-Drittanbietern vorübergehend teilweise oder vollständig auszusetzen, bis die Risiken beseitigt sind. Behörden können von Finanzunternehmen erforderlichenfalls verlangen, die einschlägigen vertraglichen Vereinbarungen, die mit kritischen IKT-Drittanbietern geschlossen wurden, ganz oder teilweise zu kündigen (Art. 37 Abs. 3).
Vor Vertragsschluss mit einem IKT-Drittanbieter müssen Banken und Finanzdienstleister prüfen, ob der jeweilige IT-Lieferant als kritischer Anbieter einzustufen ist oder ob dieser wichtige digitale Funktionen abdeckt. Banken und Finanzdienstleister sollten überprüfen, ob ihr IKT-Drittanbieter ersetzbar ist oder ob mehrere Verträge mit diesem abgeschlossen werden (Art. 25 Abs. 5). Die Beurteilung dieser Kriterien ist insofern wichtig, als dass Finanzunternehmen keine vertraglichen Beziehungen zu kritischen IKT-Drittanbietern unterhalten dürfen, die ihren Sitz außerhalb der EU haben und somit nicht in der EU niedergelassen sind (Art. 28 Abs. 9).

Quelle der Abbildung: EU Digital Operational Resilience Act (DORA) | Compliance | Haufe


Autoren:
Salar Hydary (Bachelor of Laws/ Werkstudent PPI AG, Consulting Payments, Bereich Regulierung Zahlungsverkehr)
Judith Petersen (Senior Manager PPI AG, Consulting Payments, Leitung Bereich Regulierung Zahlungsverkehr)

SEPA 2.0 ist in vollem Gange – Umstellung auf neue Formatspezifikationen startet!

Seit November 2021 gelten neue Formatspezifikationen der Deutschen Kreditwirtschaft. Die Änderungen haben bisher keine allzu großen Auswirkungen auf Banken und deren Kunden. Im November 2023 ändert sich dies allerdings schlagartig!

Die SEPA-Formate für Überweisungen und Lastschriften ändern sich umfassend, und sowohl alle zahlungsverkehrsverarbeitenden Dienstleister als auch deren Endkunden müssen sich auf die anstehenden Änderungen vorbereiten und Vorbereitungen treffen.

Denn SEPA 2.0 wird de facto alle Komponenten und alle Systeme betreffen, so dass eine frühzeitige Beschäftigung mit dem Thema und all seinen Abhängigkeiten von großer Bedeutung für eine reibungslose Verarbeitung und unterbrechungsfreie Weiterverarbeitung von Zahlungen ist. 

 
Das EPC hat im Juni diesen Jahres Implementation Guidelines veröffentlicht, die neben den entsprechenden Spezifikationen weiteren Aufschluss über die bevorstehenden Änderungen geben. Die Verwendung strukturierter Adressdaten ist ein wesentliches Thema der bevorstehenden Anpassungen. Konnten Adressen bis dato unstrukturiert durch Angabe des Namens und der Adresse eingereicht und weiterverarbeitet werden, so müssen Adressen mit SEPA 2.0 strukturiert angegeben werden. Es gibt zukünftig eigene Felder für den Namen, die Straße und Hausnummer, die PLZ und den ISO-Ländercode. Neben der Verwendung strukturierter Adressdaten haben Anpassungen einzelner Felder, wie z. B. das Batch-Booking-Kennzeichen, weitreichende Folgen. Per neuer Defaulteinstellung true des Batch-Booking-Kennzeichens wird zukünftig eine Sammelbuchung ausgeführt. Nur wenn eine entsprechende Vereinbarung für Einzelbuchungen mit dem Kunden vorliegt, wird im Falle einer Belegung mit false jede Transaktion einzeln auf dem Kontoauszug des Zahlers (Auftraggebers) dargestellt.

Die bevorstehenden Änderungen haben somit nicht nur Auswirkungen auf die Zahlungsdatei und Zahlungssysteme an sich, sondern betreffen ebenso Umsysteme, wie z. B. Stammdatensysteme. Viele Banken, die auf Konverterlösungen oder ältere SEPA-Formatversionen setzen, haben nun die Chance, ihre Systeme ganzheitlich zu betrachten und im Rahmen eines Projektes eine reibungslose Weiterverarbeitung von Zahlungen sicherzustellen. Bei diesem Vorgehen empfiehlt es sich, auf Mappingtabellen zurückzugreifen, welche die Analysen, Auswertungen und Umsetzungsempfehlungen einfacher und zielgerichteter machen. So können für jedes Institut eigene Regeln und Mechanismen etabliert werden.

Bereits die TARGET2/T2S-Konsolidierung hat gezeigt, dass die Umstellung vom MT- auf das MX-Format nicht zu unterschätzen ist und entsprechende Projekte durchaus mehr Zeit beanspruchen, als viele Institute gedacht hatten. Eine Verschiebung des Termins durch den EZB-Rat kam vielen Banken entgegen. Eine Verschiebung und neue Übergangsszenarien, die über die Szenarien der Implementation Guidelines hinausgehen, darf allerdings bei der Umstellung auf SEPA 2.0 nicht vorausgesetzt werden. Wer nicht auf einen frühzeitigen Start setzt, nimmt ein enormes Risiko in Kauf.

Autorin: Rebecca Stannull



Gelebte Digitalisierung – Schlüsseltausch per INI-Briefverfahren

Seit der Einführung von kryptografischem Schlüssel im Onlinebanking, sowohl bei Privatkunden als auch bei Firmenkunden, ist der Prozess des Austauschs der öffentlichen Schlüssel von Bank und Nutzer immer ein langwieriger und komplizierter Prozess – zugegeben: für die Nutzer ist er besonders beschwerlich; für den Rest der Menschheit der Brief mit sieben Siegeln:

Etabliert hat sich dabei das INI-Briefverfahren. Seit mehr als 15 Jahren im Gebrauch, ist es immer wieder der Hemmschuh, der eine Nutzung z. B. von EBICS behindert. Schlüssel erzeugen, diese senden, dann den papierhaften INI-Brief drucken, unterschreiben und an die Bank übergeben, ist für viele kompliziert und langwierig. Auch die Bearbeitung in der Bank selbst, wo ein Mitarbeiter den INI-Brief erhält, dann den zugehörigen Kundenkontakt im EBICS-System aufruft und dort die Kontrollwerte der elektronischen Übertragung mit den Werten auf dem INI-Brief vergleicht oder gar eintippen muss, ist aufwendig. Natürlich muss auch noch die Unterschrift geprüft werden, die auf dem Kontoblatt oder dem Vertrag hinterlegt ist. Klingt so gar nicht nach der Digitalisierung, die heute doch unsere Geschäftsprozesse begleiten soll.

Freigabe der EBICS-Schlüssel vereinfachen
Dabei ginge alles auch sehr viel einfacher, wenn Banken den obigen Prozess von den eigenen Mitarbeitern lösen, ihn komplett digitalisieren und damit an den Nutzer selbst delegieren würden. Der erste Schritt, der umzusetzen ist, ist die zweifelsfreie Erkennung des jeweiligen Nutzers durch Austausch eines gemeinsam vereinbarten Geheimnisses (z. B. TAN) oder – wenn bereits vorhanden – eine aktivierte Onlinesession, die sicherstellt, dass der Nutzer auch die richtige Person ist. Das trifft i.d.R. auf jede angemeldete Onlinebankingsession bereits zu! Wenn wir nun annehmen, dass das Banksystem nach einer erfolgreichen Schlüsseleinreichung den Nutzer online und aktiv, z. B. per Smartphone mit SMS oder App oder über eine Onlinebanking Session erreichen kann, dann wäre es doch auch möglich, dass dieser Nutzer die Richtigkeit seiner Schlüsselübertragung selbst bestätigen kann und somit seine EBICS-Schlüssel innerhalb kürzester Zeit freigeben kann.

Nur er!
Der Nutzer darf dies selbst tun, weil das Banksystem – zum Beispiel durch die Korrektheit der abgefragten TAN – die Identität des Nutzers zur Freigabe ermittelt hat. Der Nutzer vergleicht dann nur noch die Kontrollwerte von INI-Brief und Anzeige im Banksystem und bestätigt die Korrektheit. Vielleicht muss er diese auch noch mal selbst eingeben. Also genau das, was der Mitarbeiter bei der Bank auch tut. Natürlich protokolliert das Banksystem diese Freigabe durch den Nutzer, um später den Nachweis zu haben, dass der Nutzer den Vorgang geprüft hat.

Gelebte Digitalisierung
Der Nutzer des EBICS-Protokolls kann innerhalb weniger Minuten seinen neuen Zugang nutzen. Aufwendiger Ausdruck und Übergaben an die jeweilige Bank werden nicht mehr nötig sein. Die Wartezeit von Tagen wird auf Minuten reduziert. Die Bank spart sich aufwendige und teure manuelle Inhouseprozesse der Schlüsselfreigabe. Übergebene Dokumente – der INI-Brief – müssen nicht mehr archiviert werden. Die digitale Protokollierung des neuen Verfahrens reicht aus und bedarf keiner manuellen Erfassung/Digitalisierung des INI-Briefes mehr. Die Kundenzufriedenheit und die Akzeptanz des EBICS-Verfahrens werden gestärkt, die Banken sparen sich Kosten für Mitarbeiter und manuelle Nachbearbeitung. Gelebte Digitalisierung, eine ganz klare Win-win-Situation!

Autor: Michael Schunk

Wie hängen CESOP und Mehrwertsteuerrecht mit grenzüberschreitendem Zahlungsverkehr zusammen?

Hand aufs Herz, wenn wir in unserer Branche das Wort Steuerrecht hören, gehen wir nicht davon aus, dass jetzt irgendetwas Relevantes im Zusammenhang mit dem Zahlungsverkehr kommt. Natürlich werden für die Begleichung steuerlicher Verbindlichkeiten von allen Parteien Zahlungswege genutzt, was diese aber noch lange nicht zum Regulierungsgegenstand des Steuerrechts werden lässt. Die schlechte Nachricht ist allerdings, dass wir in Zukunft beim Thema Mehrwertsteuerrichtlinie der EU immer etwas genauer hinschauen müssen.

Überforderung als Hintergrund 

Im Zuge des Aktionsplans zur Schaffung eines einheitlichen Raums der Mehrwertsteuer trifft die EU-Kommission zwangsläufig auf das Thema Mehrwertsteuerhinterziehung. Insbesondere die zunehmende Nutzung des elektronischen Geschäftsverkehrs für den grenzüberschreitenden Verkauf von Gegenständen und Dienstleistungen in den Mitgliedsstaaten verstärkt diese Situation. 

Die Ermittlungsbehörden kämpfen mit einer defizitären Informationslage und eingeschränkten Informationsbeschaffungsmöglichkeiten. Die erforderlichen Informationen befinden sich oft im Besitz von Dritten (wie z. B. Zahlungsverkehrsdienstleistern), die meist in einem anderen Staat ansässig sind. Hinzu kommen ungenügende Verwaltungskapazitäten, die mit dem erforderlichen hohen Datenvolumen zur Aufdeckung des Mehrwertsteuerbetrugs überfordert sind. Dies betrifft sowohl den Austausch als auch die Verarbeitung entsprechender Datenmengen. 

Die EU-Kommission spricht von einem dreistelligen Milliardenverlust von Steuereinnahmen (https://op.europa.eu/en/publication-detail/-/publication/bd27de7e-5323-11ec-91ac-01aa75ed71a1/language-en/). Um dieser Situation aus Sicht des europäischen Gesetzgebers entgegenzuwirken, wurden die bisher bestehenden Regelungen am 18.02.2020 entsprechend ergänzt.

Verordnung (EU) 2020/283 des Rates vom 18. Februar 2020 zur Änderung der Verordnung (EU) Nr. 904/2010 im Hinblick auf die Stärkung der Zusammenarbeit der Verwaltungsbehörden bei der Betrugsbekämpfung.

  • Festlegung der Zusammenarbeit von nationalen Steuerbehörden, um Mehrwertsteuerbetrug aufzudecken und die Einhaltung der Mehrwertsteuerpflicht zu gewährleisten.

Richtlinie (EU) 2020/284 des Rates vom 18. Februar 2020 zur Änderung der Richtlinie 2006/112/EG im Hinblick auf die Einführung bestimmter Anforderungen für Zahlungsverkehrsdienstleister.
Änderungen der Mehrwertsteuerrichtlinie:

  • Zahlungsverkehrsdienstleister werden verpflichtet, Aufzeichnungen über grenzüberschreitende Zahlungen im Zusammenhang mit dem elektronischen Handel zu führen.
  • Daten müssen den nationalen Steuerbehörden zur Verfügung gestellt werden. Dabei sind strenge Auflagen (unter anderem für den Datenschutz) zu berücksichtigen.

Richtlinie (EU) 2020/285 des Rates vom 18. Februar 2020 zur Änderung der Richtlinie 2006/112/EG über das gemeinsame Mehrwertsteuersystem in Bezug auf die Sonderregelung für Kleinunternehmen und der Verordnung (EU) Nr. 904/2010 in Bezug auf die Zusammenarbeit der Verwaltungsbehörden und den Informationsaustausch zur Überwachung der ordnungsgemäßen Anwendung der Sonderregelung für Kleinunternehmen.
Neben weiteren Regelungen zur Zusammenarbeit der Verwaltungsbehörden erfolgten neue EU-weite Sonderregelungen für Kleinunternehmen:

  • Kleinunternehmen mit Sitz in anderen Mitgliedsstaaten (MS) dürfen künftig von der Kleinunternehmerregelung profitieren.
  • Dies gilt, sofern ihr Jahresumsatz nicht maximal 85.000 Euro (Grenze wird durch MS festgelegt) überschreitet.
  • Sofern bestimmte Voraussetzungen zutreffen, können dies sogar bis zu 100.000 Euro sein, sofern dieser Umsatz EU-weit erzielt wurde.

 

Die RL 2020/284/EU wird ab dem 01.01.2024 Zahlungsverkehrsdienstleister in die Pflicht nehmen, ihre Informationslage mit den Steuerbehörden zu teilen, d. h. die Informationslage aus Behördensicht zu verbessern. Dazu schreibt sie eine zentrale Meldung bestimmter Zahlungsverkehrsdaten durch Zahlungsverkehrsdienstleister vor, die Behörden im Verdachtsfall dazu nutzen sollen, ihre Ermittlung ohne Hindernisse durchzuführen.

CESOP – Zahlungsverkehrsdaten in der Vorratsdatenspeicherung
 

Das Stichwort für die Speicherung dieser gelieferten Daten ist CESOP (Central Electronic System of Payment Information). Ein zentrales System der EU, welches unter der Aufsicht von EUROFISC steht. Es soll die angelieferten Daten nicht nur aufnehmen, sondern auch durchsuchbar machen, intelligent nach redundanten Datensätzen suchen, Zusammenhänge sichtbar machen etc.

Zugriff werden nur die Steuerbehörden der Mitgliedsstaaten bekommen. Natürlich alles im Einklang mit sonstigen Rechten. Das Allgemeininteresse zur Schadensvermeidung durch Steuerhinterziehung in Milliardenhöhe überwiegt hier das Recht des Einzelnen auf Datenvertraulichkeit.  

Welche Zahlungen müssen von wem gemeldet werden? 

Immer wenn Zahlungsverkehrsdienstleister Zahlungsdienste für mehr als 25 grenzüberschreitende Zahlungen innerhalb eines Kalenderquartals an denselben Zahlungsempfänger unabhängig von der Höhe des Transaktionsbetrags leisten, sind diese zu melden. Die Daten sind min. drei Kalenderjahre aufzubewahren.


Europäische Zahlungsdienstleister

Erfolgt die Zahlung an einen Zahlungsempfänger in der EU, so liegt die Aufzeichnungspflicht beim Zahlungsdienstleister des Zahlungsempfängers.

Erfolgt die Zahlung von einem Zahler in der EU an einen Zahlungsempfänger in einem Nicht-EU-Land, so liegt die Aufzeichnungspflicht beim Zahlungsdienstleister des Zahlers.




Anliefern, aber wie? 

Der inzwischen hoffentlich geneigte Leser wird sich sicherlich nun fragen: „Okay, eine neue Meldepflicht. Aber wie bekommen wir die Daten jetzt in CESOP?“. Die gute und die schlechte Nachricht ist, dass Sie als Zahlungsverkehrsdienstleister das gar nicht machen müssen, denn CESOP wird über die nationalen Behörden „gefüttert“. Hier ist auch schon klar, wie die Schnittstelle und das Format zur Anlieferung und das Datenformat aussehen. Unklar hingegen ist, und das ist jetzt die schlechte Nachricht, wie Zahlungsverkehrsdienstleister ihrerseits die Informationen an die nationalen Behörden übergeben müssen, nachdem sie diese aus ihren Systemen zusammengestellt haben (wenn sie diesen Stand heute überhaupt schon haben). 

Richtlinien bedürfen der Umsetzung durch den nationalen Gesetzgeber. Sie unterscheiden sich also in ihrer Wirkungsweise (mittelbar) von Verordnungen. Diese gelten unmittelbar und müssen direkt angewendet werden. Der deutsche Gesetzgeber hat sich bisher noch nicht mit den Änderungen der Mehrwertsteuerrichtlinie beschäftigt; hat also noch gar nicht mit der Umsetzung begonnen. Immerhin hat er noch bis zum 31.12.2023 (zur Erinnerung; ab dem 01.01.2024 soll es losgehen) Zeit und wartet momentan noch die weiteren Entwicklungen auf EU-Ebene ab (was nicht unbedingt verkehrt sein muss). 

Im Zuge der Umsetzung steht es dem deutschen Gesetzgeber aber frei, ob er sich zu einer 1:1 Umsetzung entschließt oder eben auch strengere Regelungen trifft. Auch eine Abweichung vom Wortlaut der Richtlinie wäre legitim. Die Feinheiten könnten hier also noch in der Umsetzung durch den deutschen Gesetzgeber liegen.

Fazit
Das europäische Mehrwertsteuerrecht hat jetzt sehr wohl einen Bezug zum Zahlungsverkehr und nimmt Zahlungsverkehrsdienstleister in die Pflicht zur Informationsbeschaffung für die Steuerbehörden der Mitgliedsstaaten. 

Unklar bleibt weiterhin die Gesetzeslage auf nationaler Ebene und die Art und Weise der Umsetzung. Auch ist noch nicht klar, auf welchem technischen Weg die Informationen an die verantwortliche nationale Behörde übergeben werden. Das heißt allerdings nicht, dass die Zahlungsverkehrsdienstleister nun die Hände in den Schoß legen können, denn Datenaggregierung, Orchestrierung und die Umsetzung zum Reporting sind nicht zu unterschätzen.

Autor: Benjamin Schreck

Save the date – ibi Webinar am 22.09.2022:
„Die EU kämpft gegen den Mehrwertsteuerbetrug – Die neue EU-Richtlinie soll es richten!“
Hier geht es zur Anmeldung

Project Possible im Cross-Border-Zahlungsverkehr

Haben Sie schon mal versucht, Ihr 11.000 Teilnehmer großes und internationales Netzwerk zu überzeugen, gemeinsam den Mount Everest zu besteigen? Ein unmögliches Projekt – sagen Sie. Ehrlich gesagt würde es bei den meisten von uns wohl bereits am Netzwerk scheitern. Doch die Society for Worldwide Interbank Financial Telecommunication (SWIFT) hat es geschafft, sich seit ihrer Gründung 1973 ein entsprechend großes Netzwerk aufzubauen und das Project (Im)Possible gestartet – nur dass nicht tatsächlich der Mount Everest bestiegen wird, sondern die Messageschnittstelle im internationalen Zahlungsverkehr erneuert.

Showdown im November 2022

Wer heutzutage also in die Zahlungsverkehrsbüros weltweiter Banken schaut, dem begegnet das Project (Im)Possible überall. Lassen Sie mich kurz zusammenfassen, worum es geht:
 
SWIFT ändert ab 2022 die derzeitige Kommunikationsbasis. Während heute im internationalen Zahlungsverkehr mittels MT-Transaktionen gemäß ISO 15022 kommuniziert wird, findet ab 2022 eine Umstellung auf MX-Transaktionen statt. Die MX-Transaktionen wurden durch eine internationale Arbeitsgruppe Cross-Border-Payments and Reporting (CBPR+) definiert und basieren auf der ISO-20022-Norm. Daher wird auch gerne von CBPR+-Transaktionen oder MX-Transaktionen gesprochen. Im Scope sind die Transaktionsformate aus den Bereichen Payments, Reporting und Investigation. In der "alten MT-Welt" entspricht das den Kategorien MT1xx, MT2xx und MT9xx.  

Die neuen Transaktionen werden ebenfalls über eine neue Schnittstelle versendet. Der InterAct-(FIN+)-Kanal wird ab November 2022 für den Zahlungsverkehr geöffnet. Ein kompletter Wechsel vom FIN- auf den InterAct-(FIN+)-Kanal wird mit November 2025 forciert. SWIFT bezeichnet die Zeitspanne zwischen November 2022 und November 2025 als Koexistenzphase und spricht von einer "User driven"-Migration. Jede Bank im SWIFT-Netzwerk darf selbst entscheiden, wann sie auf MX im Ausgang umstellt. Im Eingang muss jedoch ab November 2022 mit MX-Transaktionen gerechnet werden.
 
Ein vermeintlich kleines Migrationsprojekt, welches sich zu einer der größten Herausforderungen im Zahlungsverkehr in den letzten Jahren entwickelt hat. Alte Hostsysteme, die Verarbeitung neuer Datenfelder, die Abstimmung mit Partnerbanken und die sich ständig ändernden Bedingungen bringen immer wieder neue Herausforderungen und Fragen mit sich, die gelöst werden wollen:
 
Wann soll ich als Bank nun genau umstellen? Was passiert mit Rich-Data-Elementen? Soll ich alle Subelemente abspeichern oder kann ich auf die Garnishment Remittance vielleicht doch verzichten? Was passiert genau zwischen November 2022 und November 2025? Was braucht es im November 2022 mindestens?
 
Mit November 2022 hat SWIFT den frühestmöglichen Go-live-Startpunkt gesetzt. Drei Monate bleiben also den First-Mover-Banken noch Zeit, die letzten dringenden Fragen zu beantworten, die letzten Defects zu fixen und die letzten Kunden zu informieren. Die First-Mover-Banken, welche gemäß Aussage von SWIFT mehr als 50% des gesamten Cross-Border-Transaktionsvolumens ausmachen, stehen bereit und doch gibt es immer noch Änderungen und Empfehlungen, die einen Go-live in Frage stellen könnten.

Zu spät, um umzudrehen

Die Verschiebung des Transaction Managers von SWIFT auf Ende Q1 2023 anstatt November 2022 gehört zu einem der großen Schreckmomente. Der Transaction Manager wurde lange als „heilsbringende SWIFT-Applikation“ präsentiert, die mittels der Sicherung einer sogenannten Golden Copy für einen Truncation-freien Transaktionsaustausch über die gesamte Zahlungskette hinweg sorgen sollte. Ganz gleich ob informationsstarke MX-Transaktionen oder rudimentäre MT-Transaktionen verschickt bzw. weiterverarbeitet werden, der Transaction Manager sollte die Transaktionen jeweils mit der ursprünglich verschicken Datenvielfalt erweitern und damit die konsequente Weiterreichung aller Informationen sicherstellen. Nun kommt mit der Verzögerung die Angst auf, dass wichtige Informationen verloren gehen.
 
Um das Problem in den Griff zu bekommen, publizierte die PMPG (Payment Market Practice Group) im Juli die Empfehlung, bis November 2023 auf Rich Data zu verzichten (https://www.swift.com/swift-resource/251867/download). Mit Rich Data sind jene Informationen gemeint, die neu mit den MX-Transaktionen mitgegeben werden. Zu Recht kann ich mich als Bank nun fragen, ob es überhaupt Sinn ergibt, das Projekt fortzusetzen, wenn weiterhin eine solche Unsicherheit herrscht.
 
Doch es ist zu spät, um umzudrehen. Das Projektbudget ist gesprochen, die Entwicklungsteams sind mitten in der Entwicklung, die ersten Releases wurden bereits durchgeführt, der interne Go-live-Plan steht, die Kommunikationskampagnen laufen heiß und die Projekttimeline für die nächsten Monate ist bereits gefüllt. Wie agil sich eine Bank auch aufstellen möchte, ein Migrationsprojekt, welches vom E-Banking, über die Kernverarbeitung bis hin zur Kontoabstimmung die gesamte Bank beschäftigt, lässt sich nicht einfach stoppen.

Wir haben das Basecamp erreicht – der Aufstieg folgt erst noch

SWIFT treibt mit regulatorischer und marktgetriebener Härte seine Teilnehmer den Mount Everest hinauf und wie es auf jeder Wanderung üblich ist, sind einige weiter vorne und einige liegen etwas zurück. Fest steht, dass eine Reihe von Banken ab November 2022 MX-Transaktionen versenden wird. Doch haben sie damit schon den angestrebten Gipfel erreicht? Wirft man einen Blick auf das Erreichte und den angedachten Scope seitens SWIFT, so kann nur von der Erreichung des Basecamps gesprochen werden – der Aufstieg folgt erst noch. Überwachung der Produktion, Mehraufwand im Betrieb, Umstellung der Reportingmeldungen, Umstellung der Investigation-Meldungen, Verarbeitung der Rich-Data-Elements und etwaigen Änderungen und Vorschläge seitens SWIFT, dürften das Project (Im)Possible weiterhin bei vielen Banken als festen Bestandteil der Projektagenda belassen.
 
Abschließend muss festgehalten werden: Die SWIFT-Community krempelt den Cross-Border-Zahlungsverkehr derzeitig gewaltig um und baut mit der Migration auf den ISO 20022 eine Basis auf, die den Zahlungsverkehr langfristig verbessern und optimieren dürfte. Auch wenn die vollmundig versprochenen Vorteile von strukturierten und granular aufgebauten Daten, einer höheren Datenqualität, besseren Analysemöglichkeiten und internationaler Interoperabilität noch nicht mit 2022 oder 2023 eintreten werden, so wird die Basis für mehr geschaffen. Wir dürfen gespannt sein, was in den nächsten Jahren im internationalen Zahlungsverkehr noch passiert.
 
Wo stehen Sie derzeitig mit Ihrem SWIFT-MX-Migrationsprojekt und wie sehen Sie die aktuelle Situation? Lassen Sie es uns wissen oder schenken Sie uns einen Kommentar.
 

Autor: Florian Stade

Werden Banken bei der Implementierung des digitalen Euros eine Rolle spielen?

Die zweijährige Analysephase der Europäischen Zentralbank (EZB) zum digitalen Euro ist noch nicht beendet und viele Fragen sind aktuell noch unbeantwortet. Bei manchen Themen, wie zum Beispiel dem Umsetzungsmodell bzw. der Rollenverteilung, gibt es jedoch bereits erste Tendenzen.

Unter Berücksichtigung der Grundvoraussetzung einer digitalen Zentralbankwährung (CBDC) wie beispielsweise bargeldähnliche Sicherheit, Schutz der Privatsphäre, nutzerfreundliche Peer-to-Peer-Zahlungen und einer flächendeckenden Verbreitung werden aktuell verschiedene Umsetzungsszenarien diskutiert.

In diesem Artikel werden wir auf zwei verbreitete Umsetzungsszenarien eingehen:

1. Direkter CBDC
Bei dem direkten Ansatz würde die Europäische Zentralbank den digitalen Euro in Eigenregie entwickeln und die Schnittstelle zu den Nutzern darstellen.

Folglich ist die EZB dafür verantwortlich, die Infrastruktur aufzubauen, das System zu betreiben, das Kundenonboarding durchzuführen und die Zahlungen abzuwickeln.
All diesen Themen stehen enorme Aufwände aufseiten der EZB gegenüber, da neben der Entwicklung von Back- und Frontend auch die anschließende Administration und Verwaltung auf die EZB wartet. Kunden müssen beispielsweise durch Prozesse wie KYC- und AML-Prüfungen geführt werden. Offen bleibt darüber hinaus, ob Nutzer in diesem Modell ein separates Konto bei der EZB für die Zahlungsaktivitäten erhalten.

Neben den Faktoren Aufwand und Zeit wird zusätzlich noch das aktuell bestehende Ökosystem untergraben, da weder Geschäftsbanken noch Finanzdienstleister als Distributoren an der Kunde-Bank-Schnittstelle agieren werden.

Weitaus wahrscheinlicher ist daher das Szenario des indirekten CBDC:

2. Indirekter CBDC
 
Der digitale Euro wird in diesem Modell von der EZB emittiert und über geprüfte Intermediäre, z. B. Banken und Zahlungsdienstleister an den Endkonsumenten verteilt. Die Distribution wird ähnlich dem aktuellen Bargeldsystem aussehen, nur eben in digitaler Form. Der Nutzer hat folglich keinen direkten Kontakt zur Zentralbank, jedoch einen direkten Rechtsanspruch gegenüber dieser.

Das Modell würde das bestehende Ökosystem stärken, indem die Rolle der Intermediäre gesichert wird und diese in die Bereitstellung des digitalen Euros eingebunden sind.
Neben der Verwaltung werden die Intermediäre auf etablierte Prozesse (u. a. KYC- und AML-Prüfungen), Onboardingmechanismen und Frontend-Entwicklungen aufbauen können.
In diesem Modell ist darüber hinaus zu berücksichtigen, dass die Weiterentwicklung von Mehrwertdiensten im Zusammenhang mit bestehenden Anwendungsfällen der Banken und dem digitalen Euro entstehen können. Die Innovationsfähigkeit wird gesteigert und Konsumenten können auf eine optimierte User Experience hoffen.

Aus den benannten Gründen gehen wir aktuell davon aus, dass die Geschäftsbanken in die Verteilung des digitalen Euros eingebunden werden, um etablierte Prozesse zu nutzen und den direkten Kundenkontakt zu stärken. Offen bleibt allerdings die Frage, ob neben klassischen Geschäftsbanken auch andere Anbieter die Rolle eines Intermediär einnehmen können.

Wir von PPI verfolgen dieses Thema mit großer Begeisterung und sehen die Innovationsfähigkeit des Zahlungssystems als unabdingbar für die Wirtschaft. Um Sie über aktuelle Entwicklungen auf dem Laufenden zu halten, werden wir Sie auf diesem Wege regelmäßig über Neuigkeiten zum digitalen Euro informieren.

Übrigens: Am 20. September findet der dritte Teil unserer Webinar-Reihe zum Thema digitaler Euro statt. Auf dieser Seite können Sie sich für das Webinar anmelden. Sollten Sie Teil 1 und/oder Teil 2 der Webinar-Reihe verpasst haben, können Sie sich die Aufzeichnungen dort auch noch einmal ansehen.

Autor: Philipp Schröder

Ein wichtiger Schritt in Richtung Einheit

Ab Ende 2023 erweitert sich der Nutzerkreis des Electronic Banking Internet Communication Standard (EBICS): Im November kommenden Jahres beginnt in Österreich die Migration der Zahlungsverkehrssysteme vom bisher genutzten proprietären Multi Bank Standard (MBS). Für die Unternehmen in der Alpenrepublik bedeutet die Umstellung zunächst einmal Arbeit, hat aber am Ende klare Vorteile. Denn mit EBICS existiert ein nahtloser Anschluss an den größten europäischen Zahlungsverkehrsraum rund um Deutschland und Frankreich. Außerdem lassen die Banken ihre Kunden beim Umstieg natürlich nicht allein. Zunächst allerdings müssen die Institute selbst ihre Hausaufgaben machen. Über Zeitplan, Vorteile und Vorgehensweisen sprechen in einem gemeinsamen Interview Thomas Bargehr, Produktmanager Banking Solutions and Payment Services, Hypo Vorarlberg Bank AG, und Michael Lembcke, Leading Product Manager, PPI AG.

 

  1. Herr Bargehr, im Juli 2020 hat die österreichische Kreditwirtschaft ihren Beitritt zur EBICS-Gesellschaft erklärt, seitdem läuft die Einführung bei den Banken. Wie weit ist Ihr Haus, wie sieht der weitere Fahrplan aus?
    Aktuell stimmen wir in der PSA (Payment Service Austria) die Anforderungen an automatische Migrationsschnittstellen ab. Über diese sollen die Daten und Autorisierungsmethoden aus den Altprogrammen und den MBS-Stammdaten transportiert werden. Damit ist ein benutzerfreundlicher Wechsel von MBS zu EBICS möglich. Die Migration selbst soll nach dem nationalen Projektplan ab November 2023 folgen. Ab dem Zeitpunkt müssen dann auch alle Geschäftskunden auf EBICS wechseln.

  2. Herr Lembcke, deutsche Banken nutzen EBICS schon geraume Zeit, von Problemen ist nichts zu hören. Welche Vorteile hat dieser Standard für die Kreditinstitute, verglichen mit MBS?
    Für Firmenkunden ist vor allem eine länderübergreifende Multibankfähigkeit wichtig. Zu viele unterschiedliche nationale Standards oder Verfahren verursachen Mehraufwand und stören die Abläufe. Eine Vereinheitlichung fördert zudem eine mögliche Prozessautomatisierung im Sinne eines Straight-Through-Processing (STP). Auf der Architekturebene ermöglicht EBICS eine innovative, zeitgemäße Auslegung von Zahlungsverkehrssystemen.

  3. Herr Bargehr, die Weiterentwicklung des MBS ist eingestellt, die Unternehmenskunden müssen also irgendwann zu EBICS wechseln. Das verursacht bei Ihren Unternehmenskunden Arbeit, womit ist das zu rechtfertigen?
    Der Zahlungsverkehr und damit einhergehend die von der Kundensoftware zu unterstützenden Formate sind seit der Euro-Einführung einem ständigen Wandel unterworfen. Dass sich alle paar Jahre etwas ändert, sind die Unternehmen also schon gewohnt. Die Hersteller von Enterprise-Ressource-Planing-Software begleiten diese Entwicklungen in der Regel rechtzeitig und qualitativ sehr gut. Gleiches gilt natürlich auch für unser eigenes Haus, das sich immer als verlässlicher Partner an der Seite der Kunden versteht.
     
  4.  Herr Lembcke, die PPI AG ist Marktführer von EBICS-Lösungen und hat den Standard von Anfang an begleitet. Wie läuft aus der Sicht eines Zahlungsverkehrsberaters die Einführung in Österreich?
    Bislang sind keine signifikanten Probleme erkennbar. Die Herausforderung liegt allenfalls darin, den Übergang für alle Beteiligten so reibungslos wie möglich zu gestalten. Da sind wir natürlich auch als Hersteller von EBICS-Software gefragt, Lösungen zu liefern. Natürlich gab es mit MBS in Österreich auch bisher schon einen funktionierenden eBanking-Standard. Aber zukünftig haben die Institute und Firmenkunden in Österreich einen europäischen Multibank-Standard, der auf State-of-the-Art Architekturen beruht und den Zahlungsverkehr im Land langfristig zukunftsfest macht.

  5. Herr Bargehr, eine solche Migration von Datenverarbeitungsstandards ist keineswegs eine triviale Angelegenheit. Wie stellen Sie sicher, dass nichts schiefgeht und es keine Downtimes gibt?
    Wir erheben bereits weit vor Migrationsbeginn den aktuellen Status des Kunden und stellen so frühzeitig besondere Anforderungen hinsichtlich Technik und Betreuung fest. Entsprechend begleiten wir die Unternehmen dann bis zum Wechsel. Schlüssel zum Erfolg sind eine saubere Übertragung der Kundenzugänge auf den EBICS-Server, ein kurzer und zugleich handhabbarer Übergangszeitraum sowie ein qualitativ hochwertiger Kundenservice.

  6. Herr Lembcke, die PPI AG hat zahlreiche Migrationsprojekte in Richtung EBICS begleitet. Welche Vorgehensweise empfehlen Sie einem Finanzinstitut?
    Hier gibt es keine One-Size-Fits-All-Lösung. Das Vorgehen hängt stark von der Strategie und der Kundenstruktur des einzelnen Instituts ab. So ist durchaus eine Big-Bang-Migration denkbar, bei der alle Kunden auf einmal umgezogen werden. Schrittweise Migrationsszenarien haben aber genauso ihre Berechtigung, auch wenn dabei natürlich ein Parallelbetrieb von EBICS und MBS notwendig wird. Wichtig ist der Austausch mit den eigenen Unternehmenskunden, deren Migrationsplanungen abgefragt werden sollten. Für Downtimes gibt es jedenfalls keine Veranlassung, eine Migration im laufenden Betrieb ist absolut machbar.
     
  7. Herr Bargehr, EBICS kennt durchaus regionale Unterschiede, so hat beispielsweise Frankreich auf einige lokale Anpassungen bestanden. Gibt es auch in Österreich Abweichungen vom EBICS-Normalfall?
    Auch wenn EBICS in Österreich noch kein Standard ist, betreiben die meisten Banken aufgrund der Marktanforderungen bereits heute entsprechende Server und Clients. Dabei gehen sie aber unterschiedlich vor: Manche kaufen sich Lösungen von der Stange und betreiben diese ohne weitere Anpassungen an nationale Besonderheiten. Andere dagegen – hier zählt die Hypo Vorarlberg dazu – analysieren eben jene lokalen Anforderungen und berücksichtigen sie bei der Auslegung ihrer Kundensysteme. Für uns hat die PPI die jeweiligen Sonderfälle in die Zahlungsverkehrslösungen eingebaut. Daher sind wir seit 2017 bereits vollständig EBICS-ready.
     
  8. Herr Lembcke, hat EBICS 3.0 das Potenzial, die Diskussion um die Notwendigkeit zusätzlicher, PSD2-konformer APIs zu beenden?
    Das ist letztlich eine Diskussion, bei der es kein Ergebnis im Sinne eines Entscheides geben kann. Denn genauso wie EBICS ein etablierter, von allen Instituten beherrschter Standard ist, sind APIs aufgrund ihrer Anzahl ebenfalls ein fester Bestandteil der IT-Landschaft. Beides wird noch länger nebeneinander existieren.
     
  9. Herr Bargehr, welchen Weg wird die Hypo Vorarlberg Bank gehen? Bieten Sie zusätzliche Schnittstellen an oder setzen Sie erstmal voll auf EBICS?
    Kleinstkunden können wie gewohnt weiter unser Onlinebanking nutzen. Kleine und mittelständische Unternehmen sowie Großkunden werden bei uns aber künftig ausschließlich mit EBICS arbeiten. Wir nehmen die EBICS-Migration zum Anlass, nach und nach alte Zahlungsverkehrs- und Banking-Systeme abzuschalten und damit Doppelgleisigkeiten zu vermeiden.
     
  10. Herr Lembcke, im europäischen Zahlungsverkehr tut sich derzeit ohnehin einiges, als Beispiele lassen sich die SWIFT-Umstellung oder Request to Pay (RTP) nennen. Wie ist EBICS hier einzuordnen?
    Der Standard erfüllt alle wichtigen Voraussetzungen, um die absehbaren Veränderungen im europäischen Zahlungsverkehr miteinander zu harmonisieren. Schon deswegen sollte alles getan werden, EBICS in weiteren Ländern offiziell einzuführen. Dabei ist auch auf eine Vereinheitlichung der Nutzungsweise zu achten, um die Akzeptanz zu erhöhen. Die Einsatzbereiche sind bereits jetzt vielfältig. SEPA Instant Payments lässt sich beispielsweise mit EBICS abwickeln, im Interbankenaustausch wird RTP unterstützt. Für die Teilnahme am Zahlungsverkehr der Zukunft ist EBICS die Eintrittskarte!

Die europäische Retail Payments Strategy – ein Zwischenstand

Im heutigen Beitrag gehen wir in einem kurzen Interview auf die Entwicklung der European Payments Strategy ein. Was gibt es an Bewegung, Neuerungen und Ausblicken? Dazu haben wir als Expertin auf diesem Gebiet unsere Kollegin Swaantje zum Gespräch eingeladen.

EBICS-Blog:
Hallo Swaantje! Schön, dass du dir die Zeit nimmst. Magst du eingangs kurz etwas zu dir sagen?

Swaantje:
Hallo! Ja, gern. Ich bin Swaantje Völkel, Managing Consultant im Consulting Payments-Bereich für die PPI AG in Hamburg und widme mich den Anpassungen, die auf europäischer Ebene initiiert werden. So auch der EU Digital Finance Strategy und im Konkreten der EU Retail Payments Strategy.

EBICS-Blog:
Worin liegt hier die größte Herausforderung?

Swaantje:
Nun, das Wichtigste vorneweg – eine Strategy ist kein Gesetz, sondern nur eine Art Absichtserklärung, ein Rahmenplan für die Zukunft, für zukünftige Ereignisse. Es gibt keine verpflichtenden Vorgaben und auch keine Termine, es ist ein Wachstumsprozess, wobei Beobachtungsgabe, Interpretation, Erfahrung und Urteilsvermögen gefragt sind.

EBICS-Blog:
Der Wunsch nach Autonomie ist stark, aber das Fleisch ist schwach?

Swaantje:
Die EU Retail Payments Strategy ist Teil der EU Digital Finance Strategy. Beide werden unter anderem durch die Open Strategic Autonomy der EU vorangetrieben, und sollen diese unterstützen. Ja, richtig – der Fokus liegt deutlich auf der Förderung der Open Strategic Autonomy der EU. Die EU Retail Payments Strategy beschreibt 17 Maßnahmen mit unterschiedlicher Größe und Gewichtung. Ein Hauptthema ist die Überprüfung der PSD2, hier setzen wir bei PPI an.

EBICS-Blog:
Bedeutet das, dass es hier konkreter wird und man sich auf Änderungen einstellen kann?

Swaantje:
In der Tat. Dort wird es langsam konkreter: In zwei aktuellen Konsultationen wird aktuell um Feedback zu den Zielen der PSD2 gebeten, einschließlich der Frage, wie erfolgreich die PSD2 bei der Erreichung ihrer Ziele war. Außerdem geht es um Meinungen zur Durchsetzung der PSD2 durch die nationalen Regulierungsbehörden und zu etwaigen Änderungsvorschlägen, die nach Ansicht der Befragten an der Richtlinie vorgenommen werden sollten. Auch wird gefragt, ob der Anwendungsbereich, die Maßnahmen und die Verfahren der PSD2 angemessen sind, wobei ein zukunftsorientierter Ansatz verfolgt wird. Die Antworten auf diese Konsultationen sollen jetzt im Sommer eingereicht werden.

EBICS-Blog:
Gerade die Aufwandsschätzung ist doch entscheidend – lässt sich hier eine Vermutung formulieren?

Swaantje:
Die PSD2 hat sehr große Veränderungen durch die Einführung des Kontenzugriffs durch Third Party Provider und neue Anforderungen an die starke Kundenauthentifizierung mit sich gebracht. Nach der Überprüfung und Änderung der PSD2 erwarten wir Änderungen, aber keine ganz so gravierenden. Aber es können schon große und wichtige Änderungen dabei sein – nur nicht so große wie bei der initialen Einführung der PSD2. Unterm Strich kommt viel Arbeit auf uns zu – denn kleine Änderungen können große Auswirkungen haben und umgekehrt, daher halte ich mich mit Vorhersagen zurück.
 
EBICS-Blog:
Ist das hilfreich, so unprognostizierbar anzusetzen?

Swaantje:
Darin liegt doch eine wertvolle Kreativphase, die uns bisher immer nützliche Erkenntnisse geliefert hat. Ich verweise auf die schwierige Wegfindung beim letzten Mal. Insgeheim hoffen wir aber, dass der Weg zur PSD3 nicht ganz so lang wird wie damals. Insbesondere die permanente Lobbyarbeit, die einerseits für Fortschritte bei der Strategie sorgt, leider auch viele konkurrierende Wünsche aufzeigt, abwägt und versucht unter einen Hut zu bringen, fördert Verzögerungen. Das ist kein beschleunigender Aspekt.

EBICS-Blog:
Dann Hand aufs Herz – wann klappt es mit dem Entwurf einer PSD3?

Swaantje:
2023! (lacht)

Paukenschlag zur TRAVIC-Usergroup 2022 - Payments-as-a-Service im Doppelpack

Die TRAVIC-Usergroup hat nach dreijähriger Zwangspause endlich wieder live stattgefunden. Dabei wurden Neuerungen rund um die TRAVIC-Suite und produktbezogene Workshops auf das Parkett gebracht und in einem gemeinschaftlichen Rahmen auf Bedürfnisse und Fragestellungen im Deep Dive eingegangen. Aber: Das war noch nicht alles – die mit Spannung erwarteten Guest Speaker Alexander Merkel (Deutsche Bundesbank) und Nico Frommholz (Hamburg Commercial Bank) ließen aufhorchen: Herr Merkel skizzierte den Status quo und wagte einen Blick über den Tellerrand, indem er beleuchtete, welche Erwartungen, Chancen und Risiken es bei dem Thema „Crypto Currencies / Digitaler Euro“ im Auge zu behalten gilt. Herr Frommholz, seines Zeichens Director Head of Payment Operations, hat das Schwerpunktthema Payments-as-a-Service mit dem Vortrag "SEPA ist live" eröffnet – ein Thema, das PPI AG verstärkt in den Fokus nimmt und zusätzlich zu EBICS, mit aller Kraft um- und antreibt.

Mit dem Go-live der HCOB gelingt es PPI AG, nachweislich eine bedeutungsvolle Lücke am Payments-as-a-Service-Markt zu besetzen. Aber es kommt noch besser: Die britische Internet-Direktbank Revolut setzt für ihre Expansion in den EU-Raum auf die Datenaustauschlösung TRAVIC-Interbank und auch auf das Payment-as-a-Service-Modell – cloudbasiert und von der PPI AG. Die 2015 in London gegründete Neobank Revolut zählt aktuell rund 18 Millionen Privatkunden, die die Finanz-App des Unternehmens nutzen. Im Januar 2022 startete Revolut in Deutschland und neun weiteren europäischen Ländern ihr Bankdienstleistungsangebot. Für die offensive Erschließung des EU-Marktes benötigt Revolut als Nicht-EU-Bank eine Verbindung zur European Banking Authority (EBA) sowie den technischen Anschluss an das EBA Clearing – insbesondere an das Echtzeitzahlungssystem RT1 für SEPA Instant Payments und die STEP2-Plattform für den regulären SEPA-Zahlungsverkehr. Realisiert wird dieser Anschluss durch die Datenaustauschlösung TRAVIC-Interbank sowie das Payments-as-a-Service-Modell.

Das Hamburger Beratungs- und Softwarehaus PPI AG wird so zum Rundum-Dienstleister im europäischen Zahlungsverkehrsgeschäft. Die Payments-as-a-Service-Lösung erweitert die Sparten Consulting und Softwareprodukte um ein Komplettangebot und rundet damit das Leistungsportfolio des Hamburger Unternehmens ab. Somit zählt PPI mit seinen Teams an spezialisierten Beratern und seiner TRAVIC-Suite zu den europäischen Marktführern im Zahlungsverkehr. „Wir sind nun in der Lage, Payments-as-a-Service in der gesamten Bandbreite der Zahlungsabwicklung für Banken anzubieten. Diese können dadurch ihre IT-Abteilungen entlasten, ihre Ressourcen effizient einsetzen und damit ihre Wettbewerbsfähigkeit verbessern“, befand Dr. Thorsten Völkel, Vorstandsvorsitzender der PPI AG. Ein Prachtexempel dafür, dass die TRAVIC-Suite nicht nur die zentrale Softwarelösung dafür ist, sondern vor allem die Zukunft bildet, für eine standardisierte, mehrmandantenfähige, moderne und gehostete Zahlungsverkehrsplattform für den europäischen Bankenmarkt! Mit diesen Leistungen ermöglicht die PPI AG Banken und Versicherungen den Betrieb ganzer Wertschöpfungsketten als Software-as-a-Service. Das modulare Portfolio reicht von der Bereitstellung und dem Betrieb der IT-Infrastruktur bis hin zu vielfältigen Services und begeistert nicht nur auf Grund seiner Internationalität, seiner technischen Komplexität, sondern vor allem auch auf der Compliance- und Legal-Ebene.

Anhand dieser Erfolgsmeldungen sieht man klar, was uns verbindet: die Leidenschaft für exzellente Payments-Software und -Beratungsleistung. Wir sind überglücklich, mit der Usergroup 2022 diesem Streben Ausdruck verliehen zu haben. Wie wir alle gelernt haben, ist es eine Selbstverständlichkeit gewesen, Fakten und Lösungen zu Fragestellungen in digitalen Meetings und Calls auszutauschen. Aber gerade die gegenseitige und gemeinschaftliche Inspiration, von der die Weiterentwicklung der TRAVIC-Produkte seit jeher profitiert, die durch den lebendigen, lebhaften und leibhaftigen Austausch von Angesicht zu Angesicht geprägt ist, vermissten wir. Umso größer war die Freude, an diese symbiotischen Schwingungen wieder feierlich anknüpfen zu können und zwei Tage lang die geschätzte PPI-Kundschaft mit einem prall gefüllten und abwechslungsreichen Programm zu beehren: von der Vorstellung neuer TRAVIC-Produkt-Releases, über Use Cases und jüngste Erfahrungsschätze, bis hin zu vertiefenden Diskussionen mit den Kunden im Rahmen der produktspezifischen Workshops.

Autor: Andreas Löwe

 

Prüfung von EBICS-Zertifikaten in Frankreich ohne vertrauenswürdige Drittanbieter

Elektronisches Zertifikat und Anwendungen
Das elektronische Zertifikat ist ein wesentliches Element beim Aufbau von geschützten Bereichen. Es ermöglicht seinem Inhaber, sich zu authentifizieren (Authentifizierungszertifikat), eine Unterschrift zu leisten (Signaturzertifikat), eine sichere Verbindung herzustellen, usw. Für die Funktionen zur Zugangs- und Unterschriftskontrolle verwenden die Anwendungen ein Zertifikat für die Authentifizierung des Inhabers und für die Kontrolle der Informationsintegrität. Es gibt heute zahlreiche Zertifikatsaussteller (Bankensektor, Verwaltung, Unternehmen ...).

Die Anwendungen für die Digitalisierung von Datenströmen sind vielfältig und betreffen alle Wirtschaftsbereiche. Sie setzen die Einrichtung von geschützten Bereichen voraus, in denen es möglich sein muss, die verschiedenen Akteure technisch zu identifizieren und zu authentifizieren sowie die Qualität der Transaktionen und ihrer Aussteller zu überprüfen.
 
Eine Anwendung muss in der Regel Zertifikate von verschiedenen Zertifizierungsstellen akzeptieren können, denn in einer globalen Welt wäre es zu kostspielig und gleichermaßen zu restriktiv, von einem Inhaber ein Zertifikat pro Anwendung zu verlangen.

EBICS und signierte Zertifikate
Um mit Finanzinstituten zu kommunizieren, müssen EBICS-Teilnehmer mit einem T- oder TS-Profil X.509-Zertifikate verwenden. Wenn der Teilnehmer von einer Zertifizierungsstelle (CA) signierte Zertifikate verwendet, müssen diese beim Download der Schlüssel und beispielsweise bei Aufträgen der Auftragsart FUL validiert werden. Die Auftragsarten für die Einreichung und Änderung von Zertifikaten (INI, HIA, H3K, PUB, HCA und HCS) unterstützen sowohl ein einzelnes Zertifikat, als auch Zertifikatsketten.

Validierung des CA-basierten Zertifikats
Die Validierung des CA-basierten Zertifikats kann extern oder intern (für EBICS TS) durchgeführt werden. Ab sofort ist es möglich, intern eingereichte Zertifikate in TRAVIC-Corporate zu prüfen. Dazu werden die Anmerkungen der Sperrliste mithilfe von Zertifikatssperrlisten (Certificate Revocation Lists, CRL) überprüft. Die Zertifikatssperrlisten müssen aus dem Internet heruntergeladen werden. Um die SWIFT-Zertifikatssperrlisten herunterzuladen, ist in der Regel ein Client-Zertifikat für die TLS-Kommunikation erforderlich.

Schnittstelle zur Prüfung interner Zertifikate von TRAVIC-Corporate für EBICS TS

Neben anderen Parametern umfasst die Providerschnittstelle von TRAVIC-Corporate die Prüfung von Zertifikaten, eine Caching-Strategie, die Speicherung von Non-Repudiation-Dateien und die Vorabprüfung von EU-Berechtigungen (EBICS TS) gemäß den CFONB-Spezifikationen. Der Provider kann über den Namen seiner Klasse angegeben und aktiviert werden.

Die Zertifikate werden gegen einen in TRAVIC-Corporate gespeicherten Truststore geprüft. Die gesamte Zertifikatskette wird jeweils bis zum gültigen Root-Zertifikat geprüft. Es werden keine externen Dienste zur Prüfung von Zertifikaten verwendet.

Als Komponenten von TRAVIC-Corporate steuern ein Job-Server und ein Parser diese Verarbeitung. Der Zahlungsauftrag wird freigegeben, wenn das Signaturprofil des EBICS-Teilnehmers mit dem Signaturprofil übereinstimmt, das auf der Ebene der Auftragsart des Kunden konfiguriert wurde.

Das Finanzinstitut kann sich somit vollständig auf seine TRAVIC-Corporate-Lösung verlassen, ohne auf Dritte zurückgreifen zu müssen, wodurch die Systemarchitektur vereinfacht und Kosten gesenkt werden.

Zaher Mahfouz


Quellen: PPI TRAVIC-Corporate, CFONB, X.509-Standards

ISO-Migration im AZV - ein Weckruf

Weltweit werden die Zahlungssysteme auf ISO-20022-Standard UNIFI (universal financial industry message scheme) umgestellt. Im Euroraum begann dieser Prozess mit der SEPA-Einführung 2007. Im kommenden November ist es auch im Individual- und Auslandszahlungsverkehr soweit. Die Finanzwelt verspricht sich viel von der Umstellung. In einer Umfrage von msgGillardon und Unifits haben 99 % der befragten Experten die ISO-Migration sehr oder eher positiv gesehen. Und tatsächlich bietet der neue Standard viele Vorteile, wenn er denn erst einmal möglichst flächendeckend unterstützt wird.

Das Thema ist also alles andere als neu, und doch ist der Weg dahin schwierig und die Einführung musste gleich mehrfach verschoben werden. Dabei setzt das Eurosystem der europäischen Zentralbank auf einen Big-Bang-Ansatz, während SWIFT für den weltweiten Zahlungsverkehr über das SWIFT-Netzwerk eine dreijährige Koexistenzphase von MT- und MX-Formaten vorsieht. Obwohl die Big-Bang-Umstellung wie das schwierigere Projekt wirkt, da alle Banken Europas mit TARGET2 oder EBA Euro1 Anschluss zeitgleich und ohne jede zeitliche Toleranz umstellen müssen, hat auch die Koexistenzphase von MT und MX ihre Tücken.

Die TARGET-MX-Migration ist zunächst viel mehr als nur eine Formatumstellung. So wird zeitgleich der technische Zugang auf ESMIG (Eurosystem Single Market Infrastructure Gateway) umgestellt. Es werden ein ISO-basierter Recall-Prozess sowie ein zentrales Liquiditätsmanagement (CLM) mit neuen Liquiditätskonten (MCA/DCA) eingeführt. Die EZB hat den Banken einen Testzeitraum von rund einem Jahr verordnet und überwacht den Umstieg laufend – bei nicht wenigen Banken stehen die eigenen TGT-MX-Projekte auf gelb oder rot. Der sichere Betrieb des Großbetragszahlungsverkehrs in Europa scheint bei einigen Instituten gefährdet zu sein.
 
Dieser Weckruf bezieht sich jedoch auf die Umstellung im Auslandszahlungsverkehr. Die SWIFT-Initiative CBPR+ (Cross-Border Payments and Reporting Plus) versucht durch die 3-jährige Übergangszeit einen weichen Übergang zu ermöglichen. Jede Bank soll im eigenen Tempo dem Ziel der ISO-Migration nachkommen können. In der Folge wird an vielen Stellen konvertiert anstatt den ISO Datenhaushalt end-to-end zu verarbeiten. Einige Banken senden und empfangen weiterhin MT-Nachrichten für die Zahlungen, andere bereits die ISO-Formate. Darüber hinaus ist die Migration je Nachrichtentyp sowieso zeitlich gestaffelt.

Bei genauer Betrachtung zeigt sich, dass der Übergangszeitraum sowohl für Banken, die noch nicht auf ISO umgestellt haben, als auch für Banken, die eigentlich ISO-ready sind, gewaltige Probleme erwarten lässt:

Banken, die nur MT verarbeiten können, riskieren langsamere Prozesse durch Konvertierungen, müssen zum Beispiel aus Compliancegründen in Übergangslösungen investieren, da in einigen Prozessen doch die Original-ISO-Formate abgeholt und geprüft werden müssen. Das größte Übel: der drohende Datenverlust, bei Adressen beispielsweise…

Andere Probleme kommen auf alle SWIFT-Teilnehmer zu: Die MT/MX-Übergangszeit führt zu einer Vielzahl neuer Szenarien und Use Cases wegen der möglichen Formate in Nachrichten einer Transaktion – Avis in MT, Deckung in MX, Gebührenforderung in MT, Recall in MX etc. Die Transaktionsüberwachung wird erschwert, unterschiedliches Mapping in beteiligten Banken kann zu Fehlinterpretationen führen.

Ein besonders kritisches Szenario möchte ich kurz darstellen: Eine im ISO-Format beauftragte Zahlung wird über eine längere Kette von Korrespondenzbanken, von denen eine nur MT-Format senden kann, ausgeführt. Der MT-Korrespondent empfängt die konvertierte ISO-Zahlung und ist zwar verpflichtet, das Original-ISO-Format abzuholen, kann die abgeschnittenen Daten im MT-Format jedoch nicht weitergeben. Der SWIFT Transaction Monitor enthält noch keine Golden Copy der Originalzahlung, und damit kann die Empfängerbank nun die verlorenen Daten weder aus der MT-Nachricht noch von SWIFT herauslesen oder abfragen. In diesem Szenario werden die Informationen also nicht vollständig vom Auftraggeber an den Empfänger transportiert, obwohl sowohl die Bank des Auftraggebers als auch die Bank des Empfängers bereits mit den ISO-Formaten umgehen können.

Meine Empfehlung ist daher, trotz des akuten Fachkräftemangels die verbliebene Zeit zu nutzen und die AZV-Umstellung mit all seinen vielen Szenarien (die in dieser Ausprägung wirklich neu sind) zu testen. Im Idealfall testen Sie insbesondere mit Ihren Korrespondenten gemeinsam und überprüfen, ob das Mapping von bilateral vereinbarten MT-Belegungen auch in der ISO-Welt noch zusammenpasst.
Schließlich sollten alle Banken, die als Transaktionsbanken agieren, zügig ohne Konvertierung den ISO Datenhaushalt end-to-end verarbeiten können.

Dem internationalen Zahlungsverkehr droht sonst eine dreijährige Zerreißprobe.

Thomas Riedel