eBAM – Baustein der Digitalisierung

Krisen sind auch ein Katalysator des Fortschritts. Die aktuelle Corona-Krise ist wohl sicherlich deshalb anders als viele davor, weil sie ins Digitale zwingt – von Homeschooling bis Homeoffice werden viele Aktivitäten jetzt mit Hochdruck in vielen Aspekten neu gedacht. Da werden Lücken offenbar, die in einer analogen Welt ohne Kontaktsperren und andere Restriktionen nicht so wahrgenommen werden. Antragsprozesse, Autorisierungen und Freigaben sind ein Teil davon.

Und wenn wir hier im Blog über Cash-Management-Lösungen sprechen, dann gehört für mich das Thema „Kontoverwaltung“ (Bank Account Management) auch dazu. Darunter sind nicht nur der Austausch von Nachrichten an der Kunde-Bank-Schnittstelle zu verstehen, sondern es geht von der Verwaltung von Bank- und Kontostammdaten und deren Zeichnungsberechtigungen (nicht nur die digitalen) sowie alle zugehörigen Dokumente über die Prozesse im gesamten Kontolebenszyklus bis hin zur leidigen Saldenbestätigung. Da spielen alle Anforderungen im Bereich KYC sowie Autorisierungen und digitale Identitäten hinein.

Das Thema könnte schon lange in Richtung eBAM – also Electronic Bank Account Management – in die digitale Welt überführt worden sein. Standardisierung tut hier not – das beginnt schon in der Schreibweise. EBAM oder eBAM oder e-BAM?

Die Zeit ist reif – viele Bausteine sind vorhanden. Einige Hersteller im Bereich Cash Management beziehungsweise Treasury bieten Module insbesondere für die Verwaltung der Daten auf der Firmenkundenseite an. Es gibt schon Erfolgsmeldungen für erste rein digitale Kontoeröffnungsprozesse. Auch zu KYC und dem Bereich der digitalen Identitäten gibt es erfreuliche Entwicklungen. Sogar die Nachrichten an der Kunde-Bank-Schnittstelle in XML nach dem Standard ISO 20022 sind im Prinzip vorhanden. Eine Arbeitsgruppe der CGI-MP (common global implementation – market practice) – eine globale Initiative von Corporates, Banken und Herstellern zur Harmonisierung der Nutzung von ISO 20022 an der Kunde-Bank-Schnittstelle diskutiert die Weiterentwicklung des Standards. Und Standards sind die Grundlage für die Digitalisierung. Das schafft Sicherheit bei Herstellern und Nutzern.

In Deutschland haben wir die lange Tradition des Standards Multi-Banking in der Anlage 3 zum DFÜ-Abkommen gepflegt – Multi-Banking im Sinne von „in einem Standard viele Banken erreichen“. Inzwischen sind hier beispielsweise mit dem Thema Bankentgeltnachrichten (BSB – bank service billing) auch optionale Themen möglich, also nicht jeder muss das Thema unterstützen – aber wenn, dann bitte im Standard. Und für so eine Option zum Thema eBAM möchte ich plädieren. Für EBICS ist es ein Leichtes, die XML-Nachrichten in der Nachrichtengruppe camt (account management) zu transportieren - es müssen halt die (harmonisierten) Standards vereinbart werden. Und mit dem einfachen Use Case der Übersicht von Zeichnungsberechtigungen ist in EBICS mit der Auftragsart HKD schon mal ein Anfang gemacht, aber – siehe oben – eben nicht vollständig.

Natürlich muss der Anteil Kunde-Bank-Kommunikation von eBAM nicht über EBICS realisiert werden, auch SWIFT als Transportweg ist möglich. Selbst APIs eröffnen viele Möglichkeiten. Die Grundlage sollte unabhängig vom Kanal eine Standardisierung der Inhalte (XML im Gleichklang zu json) und der Basisprozesse sein. Und für die Inhalte im Format XML nach ISO 20022 sollte ein weiteres Kapitel in der Anlage 3 zum DFÜ-Abkommen zu schaffen sein.

Auf dieser Grundlage können dann die oben genannten Hersteller ihre Produkte im Sinne „Multi-Banking“ erweitern und Banken neue Services für viele Kunden mit gleichartigen Systemen anbieten, und diese Services passen sehr gut in eine digitale Welt.


Autor: Dr. Mario Reichel

Maschinen bezahlen Maschinen: Wie Maschinenökonomie den Zahlungsverkehr verändert

Die Maschinenökonomie (Internet of Things) wächst rasant. Immer mehr Maschinen und Geräte werden miteinander vernetzt. Im Jahr 2025 sollen es weltweit schon 75 Milliarden Geräte sein. Laut den Zahlen des amerikanischen IoT-Anbieters BizIntellia tragen Lösungen rund um das IoT bis zum Jahr 2030 insgesamt gut 14,2 Billionen Dollar zum weltweiten BIP bei.


IoT bestimmt künftig also einen immer größeren Teil unseres Lebens und unserer Gesellschaft. Damit stellt sich auch die Frage, wie sich IoT auf das Bezahlen auswirkt und welche Potenziale darin stecken, wenn auch Machine-to-Machine-Payments (M2M-Payments) integriert wird.

Wie laufen IoT und Zahlungsverkehr zusammen? Maschinen erhalten die Möglichkeit, neben Identitäten und Informationen auch Werte zu übertragen. Sie bezahlen andere Maschinen autonom, ohne dass ein Mensch den Vorgang autorisieren muss. Laufen diese Geschäftsvorfälle jedoch nicht unterbrechungsfrei ab, müssten die Maschinen also beispielsweise auf eine manuelle Aktion wie eine Zahlungsbestätigung warten, drohen Stillstand oder sogar der Abbruch – beides wäre zu vermeiden, damit sich die Potenziale von M2M-Payments vollständig heben lassen.

M2M-Payments sind auch nicht nur visionäre Zukunftsmusik. Zum Beispiel wird in der Automobilindustrie bereits an konkreten Lösungen gearbeitet. Einige Unternehmen bauen bereits entsprechende Ökosysteme auf. Die Idee: Automobile führen eigene Wallets mit elektronischem Geld, die ohne menschliche Intervention Tankvorgänge oder Mautgebühren bezahlen.

Um diese Auswirkungen, Herausforderungen und Chancen zu analysieren, haben wir eine Studie zum Thema „Maschinen bezahlen Maschinen“ erstellt, die insbesondere folgende Fragestellungen beleuchtet:
  1. Welche Voraussetzungen müssen erfüllt sein, um M2M-Payments umsetzen zu können?
  2. Wo liegen die Herausforderungen bei der Umsetzung von M2M-Payments?
  3. Wie stark steigen die Transaktionszahlen im Zahlungsverkehr, wenn M2M-Payments umgesetzt werden?
  4. Welche Zahlverfahren eignen sich am besten für die Umsetzung von M2M-Payments?
  5. Welche Auswirkungen haben M2M-Payments auf Zahlungsdienstleister?
  6. Wie sollten Zahlungsdienstleister auf M2M-Payments reagieren?

Damit M2M-Payments Realität werden können, müssen die Maschinen jeweils eine eigene Maschinenidentität mit individuellen Merkmalen erhalten, die die jeweilige Maschine von anderen Maschinen unterscheidet. Eine sichere Maschinenidentität kann nicht manipuliert, gefälscht oder missbraucht werden. Sie geben der Maschine eine unverwechselbare, sichere Identität, mit der sie sich in der vernetzten Produktion anderen Maschinen, Instanzen und Akteuren gegenüber ausweisen kann.

Auch ist der gegenwärtige Rechtsrahmen auf die Autonomie von Maschinen nicht vorbereitet und bedarf daher der Fortentwicklung. Es bedarf klarer Zuordnungsregeln für Handlungen autonomer Systeme ebenso wie spezifischer Zuweisungen der durch den Einsatz autonomer Systeme geschaffenen Risiken. Nicht zuletzt bedarf es neuer Haftungssysteme, die den Besonderheiten autonomer Maschinen gerecht werden.

Bei der praktischen Implementierung sehen wir folgende Handlungsfelder, deren Lösung besonders herausfordernd sein wird:
  1. Abbildung der Identifikation von Maschinen-Zahlungen
  2. Compliance-Prüfungen in Bezug auf eine Maschine (KYO statt KYC)
  3. Verarbeitung von Rückinformationen (inklusive Störungen im Ablauf)
  4. Berücksichtigung eines komplexeren und umfangreicheren Reportings
  5. höhere Sicherheit von Maschinen und Schnittstellen
  6. konsequente Umsetzung von digitalem Onboarding und digitalen Prozessen
Viele Untersuchungen gehen davon aus, dass durch M2M-Payments die Anzahl an Transaktionen stark steigen wird. Auch wir gehen von einem deutlichen Anstieg aus. Unter Berücksichtigung von Kompensationseffekten rechnen wir bis 2027 in Deutschland mit ca. 12 Milliarden und in der EU mit ca. 50 Milliarden zusätzlichen Transaktionen durch Maschinen, die sich gegenseitig bezahlen.


Nicht alle heute gängigen elektronischen Bezahlverfahren eigenen sich gleichermaßen für M2M-Payments. Digitales Geld (Stable Coin, „Unbacked“ Coins und E-Währungen) und E-Geld bieten sich aus unserer Sicht am ehesten an für M2M-Payments.

Etablierte Bezahlverfahren haben in der Regel mehr oder weniger hohe Transaktionsgebühren. Kryptogeld und E-Geld-Lösungen ermöglichen dagegen kostengünstige Transaktionen auch von kleinsten Beträgen und machen diese für den Einsatz im IoT attraktiv. Denn damit besteht die Möglichkeit, auch Dienstleistungen von nur geringem Wert, auch unter einem Cent, wirtschaftlich abzurechnen, wie beispielsweise die Nutzung einer Glühbirne im Smart Home. E-Geld-Lösungen und Kryptogeld lassen sich dazu auch unabhängig von klassischen Finanzdienstleistern integrieren.


Bliebe noch die Frage, wie sich die Zahlungsdienstleister künftig positionieren sollten. Das Internet of Things wird den Trend zur Differenzierung von Spezialanbietern mit einem datenbasierten Geschäftsmodell und Infrastrukturanbieter noch verstärken.

Spezialanbieter können die Daten, deren Volumen durch das IoT weiter steigen wird, zum eigenen Wettbewerbsvorteil nutzen und zusätzliche Geschäftspotenziale oder gänzlich neue Geschäftsmodelle entwickeln. Beispielsweise lassen sich auf Basis detaillierter Verbrauchsdaten passgenaue zusätzliche Dienstleistungen für Kunden anbieten. Dies hängt aber davon ab, ob es den Zahlungsdienstleistern gelingt, sich „auf“ den Maschinen zu platzieren oder zumindest als Datenaggregator zu fungieren, der die entsprechenden Nutzungsdaten zu Zahldaten bündelt und diese transferiert.

Im Hinblick auf die Positionierung als Datenaggregator oder -drehscheibe könnten Zahlungsdienstleister auch für das nötige Vertrauen zwischen den beteiligten Personen, Unternehmen und Maschinen sorgen und dabei beispielsweise als eine Art Clearingstelle für sichere digitale Identitäten und valide Daten fungieren.

Zusammengefasst bedeutet das, dass die klassischen Zahlungsdienstleister erhebliche Herausforderungen meistern müssen. Die funktionalen und vor allem die technischen Anforderungen an die Infrastruktur von Zahlungsdienstleistern werden massive Veränderungen mit sich bringen. Sie müssen folgende Voraussetzungen erfüllen:
  • vollkommen unterbrechungsfreie Verfügbarkeit, wodurch die Bedeutung von 24/7/365-Betriebsmodellen und die Abwicklung von Geschäften in Echtzeit zunimmt
  • Downtimes für das Einspielen neuer Releases sind nicht mehr möglich.
  • Möglichkeit, sehr hohe Lasten durch Milliarden zusätzlicher Transaktionen verarbeiten zu können
  • Möglichkeit, maschinelle von nichtmaschinellen Zahlungen unterscheiden zu können, da diese nach unterschiedlichen Regeln ablaufen werden
  • Möglichkeit der vollständigen Digitalisierung und des maschinellen Onboardings
  • zukünftige Einhaltung von KYO für Maschinen, was derzeit noch nicht geregelt ist, in Kombination mit KYC, Abbildung in den entsprechenden Systemen und insbesondere auch organisatorische Regelung
  • Möglichkeit, nicht nur Zahlungen auslösen zu können, sondern auch Rückinformationen aus System- und Prozessstörungen entsprechend zu verarbeiten. Anhand der Rückmeldungen müssen die Maschinen in Echtzeit die richtigen „Schlüsse“ ziehen können und ggfs. Alternativen auswählen.
Darüber hinaus müssen die Zahlungsdienstleister entscheiden wie sie sich positionieren wollen und Vertriebsstrukturen anpassen, da Ökosysteme im IoT an Bedeutung gewinnen werden. Wie das Bezahlen von Maschine zu Maschine die Zahlungsverkehrslandschaft verändert und wie Zahlungsdienstleister jetzt reagieren müssen, erläutert PPI in der aktuellen Studie "Internet of Payments". Sie können die Studie kostenfrei anfordern unter www.ppi.de/studie-iop. Wir freuen uns auf einen anregenden Austausch über die neue Zahlungsverkehrswelt und stehen Ihnen für Fragen und Anmerkungen gerne zur Verfügung.

Autor: Michael Titsch

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

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

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

Warum sind diese Aktualisierungen wichtig?

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

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

Also warum noch warten? Gehen wir es an.

Autor: Michael Lembcke

Open Banking: EBICS versus API

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

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

Keine einheitliche PSD2-Schnittstelle in Sicht

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

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

EBICS: Open Banking für Firmenkunden

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

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

Autor: Michael Schunk

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

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

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

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

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

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

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

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

Künftiger Zugang zu TARGET2 

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

Nachrichtenformate 

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

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


Zu viel vorgenommen? 

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

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

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

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

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

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

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

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

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

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

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

Autor: Michael Lembcke

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

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

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

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

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

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

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

Autor: Eric Waller