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

Alternative Autorisierungskonzepte für EBICS –Komplementäre Unterschriftsklassen & Co

Was bietet EBICS heute an Autorisierungsmöglichkeiten?

Mit der EBICS-Spezifikation ist auch die Art und der Prozess der Autorisierung für Zahlungseinreichungen geregelt. Dazu sind verschiedene Parameter spezifiziert, die es erlauben, verschiedene Autorisierungsmodelle abzubilden.

Aber reicht das alles aus, um die Marktanforderungen umfassend abzudecken? Offenbar nicht, denn erst jüngst wurden mit EBICS 3.0.2 die optional nutzbaren komplementären Unterschriftsklassen X und Y für ein neues Autorisierungsmodell spezifiziert. Diese Erweiterung kommt mit neuen EBICS-Schemata daher. Müssen neue Wünsche und Anforderungen in diesem Themenbereich zwangsläufig mit Änderungen der EBICS-Spezifikation einhergehen? 

Eigentlich nicht, denn es geht auch anders. Die Grundstruktur in EBICS bilden bekanntlich die Unterschriftsklassen T, E, A und B mit unterschiedlicher Wertigkeit und der Wahlmöglichkeit der Anzahl erforderlicher Elektronischer Unterschriften. In der Kombination mit der Unterschriftsklasse T können Autorisierungen sogar außerhalb von EBICS angewiesen werden. Mit den Funktionen der Verteilten Elektronischen Unterschrift ist zudem eine Entkopplung des Transports und der Autorisierung möglich.

Damit ist der Grundbaukasten für erweiterte Berechtigungsmodelle in EBICS vorhanden. 

Sehr vielfältige und heterogene Anforderungen 

So hat z. B. die Deutsche Kreditwirtschaft (DK) für die Nutzung des SRZ-Verfahrens unter EBICS eine Sonderform eines Autorisierungsmodells mit vorhandenen EBICS-Mitteln spezifiziert. Dieses berücksichtigt die Trennung von Transfers durch einen Dienstleister und die Autorisierung durch den originären Kunden mit Nutzung der bestehenden EBICS-Möglichkeiten; ein weiteres Anwendungsbeispiel gibt es beim Treuhändermodell. Darüber hinaus gibt es immer wieder Marktanforderungen, die sich durchaus ohne Anpassungen des EBICS-Protokolls abbilden lassen. Solche Anforderungen betreffen z. B. Autorisierungsreihenfolgen, die Delegation von Autorisierungen, aber auch Autorisierungen in Gruppenzuordnungen. Diese Modelle lassen sich mit bestehenden EBICS-Mitteln i. d. R. auf dem Bankrechner oder im Kunden-Client umsetzen.

Gerade weil die Vielfalt der Anforderungen potenziell groß und z. T. sehr individuell ist, und um Kompatibilitätsprobleme zu vermeiden, bietet es sich an, diese Konzepte möglichst außerhalb der EBICS-Spezifikation umzusetzen. 

Die Lösung aller Probleme

Ein vielseitig einsetzbares Lösungsmodell bildet das Gruppenkonzept ab. Hierbei werden EBICS-Teilnehmer auf dem Bankrechner in beliebige Gruppen aufgeteilt. Die Gruppen können auch kundenindividuell sein. Die Geschäftsvorfälle, Unterschriftsklassen und Anzahl an Unterschriftsklassen finden unverändert Anwendung. Zur Autorisierung ist wählbar, ob die finale Autorisierung bei Anwendung des Konzepts nur mit Teilnehmern aus verschiedenen Gruppen oder nur aus einer gemeinsamen Gruppe erfolgen soll. Auch eine Gruppenreihenfolge für Sichtbarkeiten beim VEU-Abruf ist möglich. Dem Kunden gegenüber kann das jeweils konfigurierte Modell dann im BPD-Blatt dokumentiert werden. Auf diese Weise lassen sich EBICS-Versions-kompatibel und interoperabel viele Autorisierungsmodelle abbilden, so auch das der Komplementärunterschriften. Wie wäre es denn damit?

Autor: Michael Lembcke

Blogbeitragsserie Stablecoins – Teil 2: Herausforderungen und mögliche Lösungen

In unserem ersten Artikel der Serie „Stablecoins“ haben wir die Hintergründe zum Thema beleuchtet und aufgezeigt, weshalb und von wem Stablecoins aktuell genutzt werden bzw. welche Vorteile sie bieten. Im zweiten Teil werden wir uns einige Probleme und mögliche Lösungen der bestehenden Stablecoins anschauen.

Probleme bestehender Ansätze
Bestehende Stablecoins haben mit mehreren Problemen zu kämpfen, auf die wir im Folgenden eingehen wollen.

Hohe Transaktionsgebühren
Soll eine Stablecoins-Transaktion z. B. auf der Blockchain Ethereum durchgeführt werden, so sind die Transaktionsgebühren abhängig von der aktuellen Netzwerkauslastung und der Zeit, die der Sender mitbringt, um die Transaktion bestätigen zu lassen. Die Kosten können dabei zwischen wenigen Cents und mehreren Euro liegen. Zudem wird neben den eigentlichen Stablecoins auch die Blockchainwährung Ether benötigt, um die Transaktionsgebühren zu bezahlen. Bei Ethereum kommt aktuell noch hinzu, dass die Skalierbarkeit nach dem Umstieg des Konsensusmechanismus von Proof-of-Work auf Proof-of-Stake noch nicht gegeben ist. Dies soll erst in künftigen Updates adressiert werden. Daher können derzeit nur wenige Transaktionen pro Sekunde von der Ethereum-Blockchain verarbeitet werden.

Verfügbarkeit von zentralisierten Blockchains
Zentralisierte Blockchains wie die Binance Smart Chain (von der Kryptobörse Binance betrieben) werben mit niedrigen Transaktionsgebühren. Ein Nachteil ist hier das notwendige Vertrauen der Nutzer in die Börse Binance, die die Blockchain betreibt. In der Vergangenheit kam es mehr als einmal vor, dass der Betreiber in Krisenzeiten die eigene Blockchain anhalten musste, um Probleme zu beheben. Grundsätzlich gilt, dass Nutzer beim Anhalten einer Blockchain keine Transaktionen mehr durchführen und somit nicht mehr über ihr Vermögen verfügen können, was einem Einfrieren des Bankkontos bzw. des gesamten Zahlungsverkehrs gleichkommt. 

Art der Emittierung neuer Coins
Wie bereits im ersten Artikel beschrieben, wird zwischen algorithmischen (dezentralen) und gedeckten (zentralen) Stablecoins unterschieden. Beide Verfahren haben aber neben den genannten Vorteilen auch Nachteile. 

Die Wertdeckung von zentralen Stablecoins erfolgt meist manuell, d.h. das Unternehmen hinter dem Stablecoin steuert zentral die Art und den Umfang der Deckung. 

Die Reserven von dezentralen Stablecoins werden i.d.R. algorithmisch gesteuert.

  • Sinkt der Kurs durch Verkaufsdruck, werden die Reserven automatisch erhöht (Minting).
  • Steigt der Kurs durch hohe Nachfrage, werden die Reserven automatisch gesenkt (Burning).

Die meisten algorithmischen Stablecoins sind an Kryptowährungen gekoppelt, deren Supply zentral kontrolliert wird.

Als Supply bezeichnet man in der Kryptoszene die auf dem Markt emittierte Anzahl von Coins. Verschiedene Kryptowährungen sehen für den Supply eine limitierte Anzahl von Coins vor (bei Bitcoin z. B. 21 Mio Bitcoin). Stablecoins hingegen haben aufgrund ihres anderen volkswirtschaftlichen Ansatzes eine solche Grenze nicht. Wenn der Wechselkurs einer Währung konstant bleiben soll, so muss die Geldmenge flexibel sein (z. B. Tether). Wenn die Geldmenge fix ist, so wird der Wechselkurs der Währung schwanken (z. B. Bitcoin).

Diese Art der Deckung wurde im Mai 2022 dem Stablecoin TerraUSD zum Verhängnis. Als der Verkaufsdruck auf den Stablecoin TerraUSD zunahm, musste die zur Deckung hinterlegte Kryptowährung TerraLuna in großen Mengen erzeugt werden, um den Kurs des Stablecoins zu stützen. In der allgemeinen Krisensituation im Mai 2022 brachte das zusätzliche Minting neuer Coins den Kurs der Reservewährung TerraLuna zunehmend unter Druck. Hierdurch wurde eine Abwärtsspirale erzeugt, die zum kompletten Wertverlust von TerraUSD und TerraLuna führte.

Anhand dieses Beispiels lässt sich die wesentliche Schwäche algorithmischer Stablecoins sehr gut erkennen. Wenn viele Nutzer gleichzeitig aus dem Stablecoin austeigen wollen, wird die Abwärtsspirale noch weiter verschärft, da in großen Mengen zusätzliche Reserve-Währungseinheiten geschaffen werden, was zu einem totalen Wertverlust führt.

Neue Möglichkeiten mit Taro

Stablecoins auf der Basis des Bitcoin Lightning Networks sind eine neue Idee. Hier setzt Taro an. Taro (Taproot Asset Representation Overlay) ist ein Protokoll, mit dem neben anderen Assets auch Stablecoins im Bitcoin-Netzwerk erzeugt und durch das Lightning Netzwerk versendet werden können.

Taro Assets werden in der Bitcoin-Blockchain in Form von gehashten Metadaten erzeugt. Da es keine Begrenzung für die Menge an Daten gibt, die durch einen Hash dargestellt werden kann, kann eine Transaktion auf der Blockchain Millionen von Transaktionen darstellen. Taro Nodes können diese durch einen Hash representierten Assets erkennen. Neben Taro gibt es auch das RGB-Protokoll, welches ein ähnliches Ziel verfolgt.

Hierdurch profitieren Stablecoins neben den niedrigen Transaktionsgebühren im Bitcoin Lightning Network (Bruchteile eines Cents) auch von Netzwerkeffekten des Bitcoin-Netzwerks als am stärksten verbreitete Kryptowährung und seiner Uptime von 99,98 %. Das Bitcoin-Netzwerk stellt gleichzeitig sicher, dass Taro Assets nicht doppelt ausgegeben werden können. Nutzer könnten so Stablecoin-Transaktionen zu niedrigen Kosten vornehmen und von der Wertstabilität des USD profitieren. Grenzüberschreitende Zahlungen ohne KYC und Bank sind möglich. Menschen können 24 Stunden am Tag auf ihr Geld zugreifen, ohne dass das Netzwerk angehalten werden kann. 

Die Problematik der Deckung der Stablecoins bleibt weiterhin bestehen. Sowohl algorithmische als auch gedeckte Ansätze haben, wie oben besprochen, einige Probleme.

Im letzten Teil unserer Serie soll es dann um die regulatorischen Aspekte für Stablecoins gehen. Wir laden Sie hierzu herzlich ein.

Autoren: Philipp Uhinck, Benjamin Schreck

Blogbeitragsserie Stablecoins - Teil 1: Hintergründe

Wenn man sich mit dem Thema Kryptowährungen auseinandersetzt, wird man zwangsläufig über das Thema Stablecoins stolpern und schnell kommt die Frage auf, was dahintersteckt. In dieser Blogbeitragsserie wollen wir mit Ihnen gemeinsam eine kurze, aber knackige Reise durch dieses Thema machen.

Ein Stablecoin ist eine zu einer bestimmten Basiswährung stabile Kryptowährung. Der häufigste Anwendungsfall liegt im Bereich Kryptohandel, da das (grenzüberschreitende) Clearing zwischen Kryptobörsen mit Stablecoins schneller abgewickelt werden kann als über die klassischen Zahlungswege. Daneben erfreuen sich Stablecoins in Schwellen- und Entwicklungsländern immer größerer Beliebtheit aufgrund ihrer Wertstabilität im Vergleich zu lokalen Währungen.

Kurz gesagt kann man den Nutzen eines Stablecoins in vier wesentlichen Punkten zusammenfassen:

  • Wertreferenz und Tauschmedium für den Handel
  • Schutz vor Kursschwankungen
  • Erzielung von Zinserträgen im Bereich „Decentralised Finance“
  • Schnelle und grenzenlose Zahlungen

Algorithmische vs. gedeckte Stablecoins
Es wird zwischen zwei verschiedenen Arten von Stablecoins unterschieden: den gedeckten und den algorithmischen Stablecoins.

Bei USD-gedeckten Stablecoins lagert das hinter dem Stablecoin stehende Unternehmen USD in einer Bank ein und emittiert seinen Stablecoin. Eine 1:1-Deckung wird dabei angestrebt. Bei algorithmischen Stablecoins versucht lediglich ein Algorithmus den Wechselkurs zwischen Stablecoin und Basiswert (z. B. USD) konstant zu halten.
Nach dem Kollaps des algorithmischen Stablecoins „TerraUSD“ im Mai 2022 gibt es nur noch einen wirklich bedeutenden algorithmischen Stablecoin: MakerDao‘s „DAI“.

Hinter gedeckten Stablecoins stecken meist Kryptobörsen, die diese Coins emittieren. Die größten Stablecoins sortiert nach Marktkapitalisierung sind Tether, USD Coin und Binance USD. Insgesamt erreichen sie zusammen eine Marktkapitalisierung von rund 130 Mrd. USD (Stand Nov. 2022).

Stablecoins bilden digital den Wert eines zugrundliegenden Assets im Verhältnis 1:1 ab und werden als digitales Geld betrachtet. Ihre Deckung erfolgt häufig mit USD-Bankeinlagen, US-Staatsanleihen oder sonstigen Wertpapieren. Erinnert man sich an den sogenannten Goldstandard, erkennt man hier durchaus gewollte Parallelen.

Vorteile gegenüber dem klassischen Zahlungsverkehr
Die Vorteile gegenüber klassischen Zahlungsverkehrssystemen sind, dass Stablecoins weltweit für jeden und rund um die Uhr zugänglich sind. Die Transaktionsgebühren sind gering, grenzüberschreitende Zahlungen schnell und problemlos möglich. Eine Überweisung ist zudem ohne KYC und ohne die Involvierung einer Bank möglich. Alles, was dazu benötigt wird, ist ein Smartphone mit Internetverbindung und eine digitale Wallet der Währung.

Wie am Anfang unseres Artikels schon erwähnt, haben neben Kryptobörsenhändlern immer mehr Menschen aus Schwellen- und Entwicklungsländern ein besonderes Interesse an Stablecoins.

Viele Schwellen- und Entwicklungsländer haben mit hohen zweistelligen Inflationsraten zu kämpfen. Die eigenen staatlichen Währungen verlieren gegenüber dem US-Dollar weiter an Wert. Dies betrifft ebenfalls das Vertrauen der Bürger in den jeweiligen Ländern. In der jüngeren Vergangenheit kam es in vielen dieser Länder zu einem sogenannten „Bank Run“.
Ein Bank Run oder auch Bankensturm genannt entsteht dann, wenn Anleger bei ihren Banken möglichst zeitnah ihre Einlagen abheben wollen. Sind hiervon gleich mehrere oder alle Banken innerhalb einer Marktwirtschaft betroffen, spricht man von einem Bankensturm bzw. einer Bankenpanik.
Die Regierungen waren daher gezwungen, lokale Banken zu schließen. Für die Bürger vor Ort können Stablecoins in einer solchen Situation eine attraktive Alternative zu ihrer Heimatwährung werden, um sich vor finanziellen Unwegsamkeiten zu schützen.

Stablecoins können also in verschiedenen Situationen eine praktische Lösung für Probleme sein, die sich im FIAT-System nicht oder nur schlecht lösen lassen oder in wirtschaftlichen Schieflagen für Bürger evtl. sogar einen Ausweg bilden. Aber wo Licht ist, da ist auch Schatten. Und diese wollen wir mit Ihnen in Teil 2 unserer Serie aufarbeiten.

Autoren: Philipp Uhinck, Benjamin Schreck

Unterbrechungsfreier Zahlungsverkehr – wer wünscht sich das nicht?

Es gibt Softwaresysteme, die so kritisch sind, dass höchste Ansprüche an die Verfügbarkeit erforderlich sind. Zugegeben: Im Finanzbereich geht es normalerweise nicht gleich um Leben oder Tod. Aber bei Echtzeitbezahlverfahren oder Echtzeit-Autorisierungsprozessen werden immer höhere Anforderungen definiert und insbesondere Wartungsfenster nicht länger akzeptiert. Und dies zu Recht: Führt ein Wartungsfenster dazu, dass man den Kontoauszug eine Stunde später bekommt oder das Portal eine Stunde nicht erreichbar ist, mag das ärgerlich, aber zu verschmerzen sein. Kann der Bankkunde hingegen am Point of Sale plötzlich nicht mehr bezahlen oder seine Zahlung nicht in Echtzeit autorisieren, gewinnt der Ausfall eine dramatische Relevanz.

Daher ist mit Einführung von Instant Payments in Europa nach dem Autorisierungsprozess für Kartenzahlungen auch die Echtzeitüberweisung zu einem Einsatzbereich unterbrechungsfreier Systeme geworden.

Kommen wir zunächst zum Begriff der Unterbrechungsfreiheit. Ein unterbrechungsfreier Betrieb wird durch zwei verschiedene Eigenschaften beschrieben:

  1. Vermeidung geplanter Nichtverfügbarkeit
    Das System ist im Normalbetrieb permanent funktionsbereit. Es hat also keine periodischen Zeiten eingeschränkter Funktionalität, wie bei Tagesende oder Reorganisation.
    Das System ist so konstruiert, dass auch Releasewechsel während des Betriebs durchgeführt werden können und keine Downtime verursachen.
     
  2. Reduzierung der ungeplanten Nichtverfügbarkeit
    Das System ist auch bei Fehlerszenarien hoch verfügbar. Es gewährleistet also mit hoher Wahrscheinlichkeit den Betrieb trotz Ausfalls einzelner Komponenten. Diese Ausfallwahrscheinlichkeit wird berechnet oder gemessen als das Verhältnis der Produktionszeit zur Laufzeit, also der Zeit inklusive der Ausfallzeit, beispielsweise 99,99 Prozent. Insbesondere die Robustheit in Überlastszenarien ist hier von Interesse. Obwohl jedes System seine Grenzen hat, ist es eben ein Unterschied, ob jenseits der Belastungsgrenze alles zusammenbricht oder nur die zusätzliche Last nicht im Rahmen der Vorgaben abgearbeitet werden kann.

Die Begeisterung für das Thema lässt meistens beim Betrachten der Kosten erheblich nach. Es lohnt daher, architektonische Antworten zu finden und nicht alles nur auf die Infrastruktur zu verlagern. Dennoch wird auch die beste Software nur dann laufen können, wenn die Systemumgebung verfügbar ist. Ich möchte hier nicht näher auf hochverfügbare Infrastruktur, Betriebssysteme, Datenbanksysteme und Message Broker eingehen – all dies ist Grundvoraussetzung für ein unterbrechungsfreies Gesamtsystem. Ich möchte den Fokus auf die Softwarearchitektur legen. Diese kann es ermöglichen, Verfügbarkeitsanforderungen gezielt umzusetzen und dabei die Kosten im Griff zu behalten. 

Da Hochverfügbarkeit teuer ist, müssen zuallererst die kritischen Prozesse identifiziert werden. Es gilt also, die Frage zu beantworten, welche Prozesse wirklich immer funktionieren müssen und welche durchaus auch nachgeholt werden können. Im Echtzeitzahlungsverkehr sind beispielsweise die Sammlerprozesse weniger kritisch als die Einzelzahlungen.

Falls große Komponenten unter die kritischen Prozesse fallen, sollte analysiert werden, ob diese überbrückt werden können. Kann also eine alternative Komponente die kritischen Aufgaben einer großen nicht hochverfügbaren Komponente für die Zeit des Ausfalls ersetzen? Im Zahlungsverkehr kann etwa das Buchungssystem ein derartiges großes, nicht hochverfügbares System sein und die Onlinedisposition der kritische Prozess, den es zu überbrücken gilt.

Zahlungsverkehr als Ganzes ist selbstredend kein zustandsloser Prozess: Geld kann leider immer nur einmal ausgegeben werden, der Kontostand ist also ein relevanter Zustand und eine Bankensoftware muss dies natürlich genau abbilden können. Das führt in unserem Fall immer zum Einsatz von Datenbanken und zum Bedarf einer Persistenz vor und nach jeder relevanten Zustandsänderung. Gerade das Design des Datenbankmodells gibt den Ausschlag darüber, ob wir unser Ziel erreichen oder nicht. Hochverfügbare Prozesse sollen mit stabilen bzw. migrationsfreien Datenstrukturen arbeiten. Nur so kann vermieden werden, dass kritische Prozesse für eine Änderung des Datenbankschemas heruntergefahren werden müssen.

Bleibt das Thema Robustheit. In der Wissenschaft spricht man auch von Resilienz, wenn beschrieben wird, dass Störungen oder Teilausfälle von technischen Systemen nicht dazu führen, dass diese vollständig versagen. Im Zahlungsverkehr können solche Störungen Lastspitzen oberhalb vereinbarter Grenzen sein oder Umsysteme, die nicht so schnell antworten wie vereinbart. Auch Ausfälle bei Geschäftspartnern und damit ausfallende Quittungen in größerer Menge können Ausfälle verursachen. Wir haben in der reaktiven Programmierung ein Paradigma gefunden, das die gewünschte Robustheit durch die Orientierung an Datenflüssen ermöglicht. Eine Überlast kann so auf betroffene Bereiche gekapselt werden und dem störungsfreien Betrieb der restlichen Daten – in unserem Falle Zahlungen – steht nichts im Wege.


Autor: Thomas Riedel

Zahlungsverkehr 2021: Keine Atempause

Für die europäischen Zahlungsdiensteanbieter neigt sich ein herausforderndes Jahr dem Ende zu. Corona war auch hier das alles bestimmende Thema. Im Individualzahlungsverkehr, verstanden als Interbanken- und Auslandszah-lungsverkehr, ist Corona mitursächlich für die Verschiebung der TARGET2-Konsolidierung und der SWIFT ISO20022 Umstellung. Für den kartengestützten Zahlungsverkehr brachte die Pandemie negative, aber auch positive Effekte: Zum einen führte Corona zu einem massiven Schub an kartenbasierten und hier insbesondere kontaktlosen Transaktionen. Solch eine Entwicklung hätte normalerweise mehrere Jahre gedauert und zudem signifikante Marketinginvestitionen der großen Card-Schemes erfordert. Auf der anderen Seite erlitten viele Marktteilnehmer im Kartengeschäft coronabedingt massive Umsatzeinbrüche – insbesondere diejenigen, die stark im Bereich Gastronomie, Reisen und Events engagiert sind. 

Wer nun denkt, dass es in 2021 für die Zahlungsverkehrsbranche eine Atempause gibt, irrt. Schließlich gehen im kommenden Jahr gleich zwei konkrete Projekte live. Andere Vorhaben müssen schon vorbereitet werden, auch wenn der tatsächliche Marktstart erst 2022 oder später geplant ist. Zusammen mit den ohnehin schon gravierenden strukturellen Marktumbrüchen betrachtet, verdichtet sich der Eindruck, die Branche stehe vor einer Alpenüberquerung unter erschwerten Bedingungen.

Aber der Reihe nach: Unter den konkreten Themen des kommenden Jahres fällt die anstehende Einführung von Request to Pay (RTP) auf. Mit Start dieses Standards im Sommer 2021 wird der Zahlungsverkehr um einen wichtigen Bau-stein ergänzt (Siehe hierzu auch unser Whitepaper Teil 1 und Teil 2) . Viele Unternehmen drängen die Finanzdienstleistungsbranche seit Langem, mit dem Auf- und Ausbau von RTP zügig voranzuschreiten (Lesen Sie hierzu auch den Survey der EBA). Denn mit RTP werden Anwendbarkeitslücken in oder zwischen den existierenden Verfahren geschlossen. Dazu gehört die möglich werdende Verbindung von Rechnungs- und Zahldaten. Dies erleichtert die Abstimmungsprozesse im Rechnungswesen vieler Unternehmen erheblich. Oder die bisher fehlende Möglichkeit, Zahlungen am Point of Sales (POS) ohne Terminalstruktur elektronisch entgegennehmen zu können. Die Einrichtung eines POS wird mit RTP einfacher und mobiler. 

Zur weiteren Durchdringung von Echtzeitüberweisungen gemäß dem SCT Inst Scheme hat der EZB-Rat entschieden, dass alle in TARGET2 erreichbaren Zahlungsdienstleister, welche das SCT Inst Scheme gezeichnet haben, in TIPS (TARGET Instant Payment Settlement) erreichbar sein müssen. Entsprechend muss die Erreichbarkeit in TIPS entweder über eine direkte Teilnahme dort mit eigenem Konto oder über die Reachable-Party-Funktionalität gewährleistet sein. Darüber hinaus sollen alle ACHs (Automated Clearing Houses), welche Instant Payments anbieten, ihre technischen Konten von TARGET2 nach TIPS verlagern. Die Umsetzung der Beschlüsse ist für Ende 2021 vorgesehen.
Immerhin erfordern nicht alle 2021er-Themen von den Zahlungsdiensteanbietern eine derart große Betriebsamkeit: Die Anpassungserfordernisse aus den November-Changes des EPC sind eher überschaubar. Ob man das auch für die DFÜ- und SWIFT-Changes sagen kann, steht noch nicht fest. Es ist aber – zumindest für den reinen Zahlungsverkehr – sehr wahrscheinlich. Größere gesetzliche Fälligkeitsdaten stehen ebenfalls nicht an.

Aber es gibt natürlich noch all die Zahlungsverkehrsvorhaben, die in 2022 und den Folgejahren umgesetzt – und somit in 2021 vorbereitet – werden müssen. Eines der wichtigsten Projekte ist die weltweit anstehende Umstellung des Zahlungsverkehrs auf das ISO-20022-Format.
Im Individualzahlungsverkehr müssen beispielsweise die in 2022 anstehende TARGET2- und die in 2022 beginnende SWIFT-Umstellung vorbereitet werden. In beiden Bereichen stehen neben der reinen Formatumstellung umfangreiche Änderungen in den Abläufen an, wie etwa veränderte Zugangsmechanismen zu den entsprechenden Plattformen. Nach übereinstimmenden Schätzungen geht jedes dieser Projekte über die Dimensionen von SEPA hinaus. 

Im Massenzahlungsverkehr (SEPA) müssen sich Zahlungsdiensteanbieter für die in 2023 anstehende Umstellung der SEPA Schemes auf die (neuere) ISO-Version 2019 fit machen.
Angesichts der mit diesen Umstellungen verbundenen Kosten werden in 2021 Banken – vornehmlich Tier-2-Institute – die Abwicklung des Zahlungsverkehrs zunehmend auslagern oder zumindest Zahlungsverkehrssoftware „As a Ser-vice“ einkaufen. Die entsprechende Nachfrage ist bereits spürbar. Zudem dürften die Stimmen lauter werden, die nach günstigen, zentralen Angeboten für bankenübergreifende Services, wie beispielsweise Sanctions Screening oder KYC, rufen.
Schlussendlich müssen Banken und Finanzdienstleister 2021 Antworten auf anstehende strukturelle Marktumbrüche finden:

  • Die Weiterentwicklung der European Payment Initiative (EPI): Gelingt es, eine einheitliche, innovative gesamteuropäische Zahlungslösung als Alternative zu bestehenden internationalen Zahlungslösungen und -systemen zu schaffen?
  • Den weiter zunehmenden Druck von EU-Kommission und EU-Parlament auf die Interchange-Gebühren: Wie können Issuer auf eine mögliche „Zero-Interchange“-Regulierung reagieren? Wie sehen zukünftige Ge-schäftsmodelle aus?
  • Die sich andeutende Verpflichtung aller Banken durch den EU-Gesetzgeber, Instant Payments anzubieten sowie die stärkere Berück-sichtigung von Verbraucherinteressen in der Rückabwicklung von Instant Payments Zahlungen. Sind die bestehenden Verarbeitungssysteme in der Lage, die zusätzlichen Mengengerüste zu verarbeiten?
  • Die deutliche Konsolidierung von Abwicklungsdienstleitern, namentlich die Bildung zweier Konglomerate durch EquensWordline einerseits und NEXI/SIA/Nets andererseits: Was bedeutet das für die Zukunft von kleineren und mittleren Dienstleistern, insbesondere im Acquiring? 
  • Die zunehmende Verwischung der Grenzen zwischen kartengestütztem und klassischem Zahlungsverkehr, wie beispielsweise die Aktivitäten von Mastercard (über Vocalink) im Clearing klassischer Bezahlverfahren: Wird es langfristig eine weitere Clearinginfrastruktur im Massenzahlungsverkehr geben? 
  • Die anstehende Einführung von digitalem Geld, in Form von digitalem Zentralbankgeld aber auch in Form von Libra: Welche Auswirkungen hat das auf Bargeld oder kartenbasierte Zahlungen? Was bedeutet dies für die Rolle und das Geschäftsmodell von Banken?
  • Die Konsequenzen der zunehmenden Verbreitung des Internet of Things (IoT) für den Zahlungsverkehr. Nur mit vollkommen autonomen, unterbrechungsfreien Zahlungsströmen zwischen den verbundenen Geräten können die Potenziale des IoT gehoben werden (Vgl. unsere Studie zum Thema Internet of Payments). Wie können dabei Compliance-anforderungen und IT-Sicherheitsaspekte erfüllt werden? Wie müssen die Verarbeitungssysteme für zusätzliche Milliarden von Transaktionen aufgerüstet werden?

Am chinesischen Neujahrstag 2021 beginnt das Jahr des Büffels. Die chinesische Astrologie schreibt ihm Geduld und Fleiß zu. Er ist stark und überwindet alle Schwierigkeiten. Die Zahlungsverkehrsbranche kann ihn gut gebrauchen.

Autor: Hubertus von Poser (Head of Consulting Payments)

Keine Angst vor Standardsoftware im Zahlungsverkehr

Wer sich im Wettbewerb absetzen möchte, entwickelt seine Software selbst. Diese Regel setzt sich mehr und mehr in den Unternehmen durch – und immer mehr „Experten“ empfehlen auch den Banken, sich stärker selbst um die eigenen Anwendungen zu kümmern, ja, sich zu einem Tech-Unternehmen zu entwickeln. Spätestens bei der Zahlungsverkehrsplattform gerät diese Philosophie ins Wanken.

Die Aufsicht fordert beispielsweise einen unterbrechungsfreien Betrieb, sofern eine Bank Instant Payments verarbeiten möchte. Welche Herausforderungen das für die Architektur bedeutet, haben wir beim TRAVIC-Payment Hub am eigenen Leib erfahren. Hinzu kommen die zahlreichen Umsysteme, wie Geldwäsche oder Embargo- und Sanktionslisten, von der Leitwegsteuerung ganz zu schweigen. Alles selbst zu machen, bedeutet allein aus Kostengründen für viele Banken, Zahlungsverkehr dann lieber gar nicht zu machen – also auszulagern oder von einem Zentralinstitut innerhalb eines großen Verbunds erledigen zu lassen. Das aber ist keine Option, sofern sich der Zahlungsverkehr zu einem strategisch wichtigen Geschäftsfeld entwickeln soll.

Jahrmarkt-Karussell für Zahlungen

Wir haben uns deshalb gefragt, was genau die „Special Sauce“ ist, die Banken in ihre ZV-Systeme kippen können müssen, um sich vom Wettbewerb zu unterscheiden und Zahlungsverkehr als eigenes Produkt anbieten zu können. Das ist besonders dann relevant, wenn sich ein Institut darum bewirbt, für Firmenkunden den Zahlungsverkehr in einer bestimmten Weltregion abzuwickeln. Und siehe da: In sich gleichen sich zahlreiche Abläufe von Bank zu Bank, sie unterscheiden sich häufig nur darin, in welcher Reihenfolge sie diese durchführen. Dieser Erkenntnis folgend haben wir das Bild von einer ZV-Plattform entworfen, die wie ein Karussell funktioniert. Jede Spezialfunktion soll, wie Kinder auf dem Rummel, überall zusteigen können (vgl. Abb. 1).





Der TRAVIC-Payment Hub erlaubt einer Bank, jede nur denkbare Konfiguration abzubilden. Das gilt sowohl für die Leitwegsteuerung, für die sich nahezu beliebig komplexe Regelwerke festlegen lassen, wie auch für die anzusteuernden Umsysteme. Woher aber weiß der TRAVIC-Payment Hub, was geschehen soll, wenn etwa vom Compliance-System ein bestimmter Status zurückkommt? Normalerweise müssen sich die Umsysteme doch daran orientieren, was das führende System vorgibt – warum sollte eine Bank, nachdem sie sich möglicherweise in der Kernverarbeitung bereits des Monolithen entledigt hat, sich im Zahlungsverkehr gleich den nächsten hinstellen? Die Antwort liefert eine integrierte Workflow-Engine, die über eine eigene Skriptsprache verfügt, um vergleichsweise simpel – und unabhängig vom Hersteller, also auch von uns – die übrigen Systeme anzubinden.

Das „Hub“ in TRAVIC-Payment Hub ist insofern Produktname und Leistungsversprechen zugleich.

Software-Entwicklung Inside-Out

Technisch krempeln wir das, was sich anderenfalls zu „Legacy“ entwickeln würde, nach außen. Die implementierte Skriptsprache ermöglicht einer Bank, die eigene Fachlichkeit in den TRAVIC-Payment Hub einzufügen, ohne dafür den Quellcode der Software selbst aufmachen zu müssen. Weil Technik und Fachlichkeit voneinander getrennt sind, rückt ein wesentlicher Teil der Software-Entwicklung aus der Sphäre des Herstellers in die Sphäre der Anwender. Dadurch bleibt die ZV-Plattform releasefähig, obwohl der TRAVIC-Payment Hub ein möglicherweise komplexes Netz an Umsystemen steuern muss. Zudem kommen die IT-Abteilungen gar nicht erst in die Versuchung, zu nahe an der ZV-Kernverarbeitung zu entwickeln und damit das Risiko einzugehen, Mikado-Effekte zu erzeugen – an einer Stelle etwas zu verändern und an einer anderen plötzlich ein Problem zu provozieren.

In der Praxis sieht das so aus: Der TRAVIC-Payment Hub nimmt von den angeschlossenen Systemen unterschiedliche Status ein. Über die Skriptsprache legen die eigenen IT-Kollegen oder der Integrationspartner fest, was mit Zahlungen in jedem einzelnen Status geschehen soll. Sobald der Workflow fertig beschrieben ist, kompiliert das System den Code, damit der TRAVIC-Payment Hub arbeiten kann. Das geschieht über von der Workflow-Engine erzeugte Tasks, die eine interne Task-Engine abgearbeitet. Hier ein ganz einfaches Beispiel, wie die von PPI für den TRAVIC-Payment Hub entwickelte Skriptsprache mit OUR-Charges umgeht, also feststellt, ob die fälligen Gebühren einer Zahlungen beiliegen und einbehalten werden dürfen oder eine Zahlungsaufforderung zu erstellen ist.


Status CHECKINBOUNDCHRGS {
if payment is inbound and (payment is ourCharges) then {
if payment is ourChargesReceived then {
just set status VALIDATERECEIVCHGS and leave step
}
if payment is correspondentChargeExpected then {
if payment is debitAuthorized then {
just set status CREATEADVICEOFCHGS and leave step
}
just set status CREATECHARGEREQ and leave step
}
}
just set status DONE and leave step
}



TRAVIC-Payment Hub einführen

PPI bildet mit der TRAVIC-Produktfamilie den gesamten Zahlungsverkehrsprozess einer Bank ab, vom Zahlungseingang über das Interbankengeschäft bis hin zum Clearing. TRAVIC-Payment Hub stellt die Kernverarbeitung für den Zahlungsverkehr dar. Unsere Lösung funktioniert als Kunden- und als Clearingbank – auch im Parallelbetrieb – und kann Instant Payments. Zudem lässt sich die Lösung On-Premises betreiben wie auch als ausgelagerte Hochverfügbarkeitslösung gemeinsam mit unseren Infrastrukturpartnern.

Autor: Thomas Riedel

Mehr Informationen: