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

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

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

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

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

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

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

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

Künftiger Zugang zu TARGET2 

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

Nachrichtenformate 

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

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


Zu viel vorgenommen? 

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

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

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

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

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

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

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

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

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

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

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

Autor: Michael Lembcke

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

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

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

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

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

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

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

Autor: Eric Waller

Multibanking – alles in einem Portal

Standards als Grundlage einer vernetzten Prozessautomatisierung

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

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

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

Gastautor: Christian Veith

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

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

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

Bewährter Standard für die Zukunft

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

Aufwand nicht unterschätzen

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

Trügerische Sicherheit

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

ISO ist nicht gleich ISO

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

Viele Einzelprojekte

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

Wie geht es weiter?

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

Wandel als Chance begreifen

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

Gastautoren: Sabine Aigner, Raija Wehrli

EBICS 3.0 – ein Satz an Parametern anstelle der Auftragsart. Was ist bei der Identifikation der Geschäftsvorfälle zu berücksichtigen?

Mit EBICS 3.0 werden die unterschiedlichen Geschäftsvorfälle bekanntlich nicht mehr über Auftragsarten abgebildet, sondern über die neuen BTF-Parameter.
Für die Nutzung von Kundenverträgen mit EBICS-Clients verschiedener EBICS-Versionen in Kombination mit EBICS 3.0 wurden von den nationalen Spezifikationsgremien eigens Mappingregeln entwickelt. Diese orientieren sich i. d. R. an den fünf BTF-Parametern Service Name, Service Scope, Service Option, Service Message Name und Service Container. Wichtig ist, dass die Kombination dieser BTF-Parameter im EBICS-Bankrechner eindeutig sein muss. Dadurch wird sichergestellt, dass eine Auftragsart dem Geschäftsvorfall über BTF zugeordnet werden kann und umgekehrt.

In der Praxis können heute zu einer Auftragsart fachlich identische Aufträge eines bestimmten Formats in verschiedenen Formatversionen erstellt und beim Bankrechner eingereicht werden. Auch wenn es regelmäßig über die Spezifikationsgremien zu Formatanpassungen kommt, hängt die vom Clientsystem genutzte Formatversion auch vom Softwarestand der Clientlösung ab. Da die Formatversion für den Anwender in den Clients transparent sein dürfte, hat er bei der Zusammenstellung seiner Auftragsdatei keinen Einfluss auf die Einreichung in einer bestimmten Formatversion. Zudem akzeptieren Banken heutzutage i. d. R. unterschiedliche Formatversionen eines Geschäftsvorfalls. Letztendlich kann für die bankseitige Verarbeitung die jeweilige Formatversion zumindest bei XML-Formaten auch aus dem Namespace der XML-Datei ausgelesen werden. Bankrechner sind bisher flexibel für verschiedene Formatversionen ausgelegt.

Die weiteren nutzbaren BTF-Parameter in EBICS 3.0 sind Service Message Name Format, Service Message Name Variant und Service Message Name Version. Sollte ein Finanzinstitut auch diese weiteren Parameter in die Auftragsartmappings und Vereinbarungsdetails mit dem Kunden aufnehmen, so sollte einiges beachtet werden. Falls nicht bereits bisher über FileFormat-Parameter intensiver genutzt oder aus verarbeitungstechnischen Gründen notwendig, sollten diese weiteren Parameter bankseitig bei EBICS-Prüfungen eher dosiert berücksichtigt werden.

Letztendlich sind diese zusätzlichen Parameterinformationen bereits Inhalt der Auftragsdatei selbst und ohnehin daraus auslesbar. Was ist zu tun bei sich widersprechenden Angaben? Außerdem bedeutet die zusätzliche Pflege im Bankrechner mehr Aufwand bei der Stammdatenpflege. Es müsste ja für jede Formatversion eines Geschäftsvorfalls eine eigene Kundenvereinbarung geben. Erschwerend kommt hinzu, dass diese Formatdetails für den Kunden in der Clientsoftware transparent sind und er diese z. T. nicht steuern kann.

Was würde passieren, wenn z. B. der Bankrechner bei einer Einreichung die Versionen 03 und 04 eines XML-Formats unterstützt, der Kunde aber für die Einreichung eines Formats der Version 03 stattdessen die Version 04 in den BTF einstellt? Bei der Versionsberücksichtigung würde der Auftrag abgelehnt, obwohl das Banksystem die Formatversion verarbeiten könnte. Die tatsächliche Version ist ja am Namespace erkennbar.

Noch komplizierter wird es mit den Auslieferungen. Hier müsste die Auslieferung zum Abholzeitpunkt synchron in der angefragten Version erzeugt und als Datei ausgegeben werden. Gleiches gilt dann auch für historische Abholungen.

Fazit: Man sollte als Finanzinstitut nicht zu restriktiv sein bei den Definitionen der BTF-Vereinbarungen mit dem Kunden. So ist man als Finanzinstitut flexibler und spart sich Mehraufwand in der Vertrags- und Stammdatenpflege.


Autor: Michael Lembcke

Payments before Christmas – Weihnachtseinkäufe mit Request to Pay?

Die Weihnachtszeit. Nicht ganz so weiß, nicht ganz so besinnlich und nicht ganz so friedlich, wie es in den Geschichten immer heißt – aber auf ihre Art doch ganz reizvoll. Mitunter allerdings ein wenig verwirrend, vor allem wenn ich auf meine Kontoauszüge der vorweihnachtlichen Einkaufsabenteuer schaue.

Die meisten werden es kennen: Das gut gemeinte „…aber dieses Jahr schenken wir uns wirklich nichts!“ hat eine noch geringere Halbwertszeit als die bald darauf zu fassenden Neujahrsvorsätze. Und auch wenn Weihnachten gefühlt im Herbst mit den ersten Lebkuchen in den Regalen beginnt, wird die Zeit für den Einkauf der Präsente dann doch auf kurz vor knapp verschoben. Und so finde auch ich mich dieses Jahr wieder im Shoppingwahn gefangen. Eltern, Schwester, Großeltern, Familie des Partners mit fünf Geschwistern – und die nächste Generation steht auch schon vor der Tür. Die verschiedenen Wunschzettel, Einkaufslisten und Planungen mit meinen Kontoauszügen in Einklang zu bringen, gleicht einer Aufgabe für Sisyphos persönlich.

Meine bevorzugten Onlinekaufhäuser haben ein Lastschriftmandat von mir bekommen, in anderen digitalen Läden funktioniert nur die Zahlung per Kreditkarte, die Konzertkarten bezahle ich mit PayPal und die analog und „offline“ erstandenen Güter bekamen die Händler per Girocard vergütet.
All diese Positionen auf meinem viel zu langen Kontoauszug wiederzuerkennen, erinnert mich daran, dass ich für meine Tante ja noch ein dreitausend Teile Puzzle bestellen muss. Ist das Teeservice für die Oma eigentlich schon bezahlt oder wird das noch abgebucht? Wann wird eigentlich diesen Monat der Betrag meiner Telefonrechnung eingezogen? Das ist doch sonst auch immer so um diese Woche, oder? Und was ist eigentlich der „XY Shop“, und wofür bekam der 90 € von mir?

Wie jedes Jahr habe ich das Gefühl, dass mir der Einkaufswahnsinn durch die Finger gleitet und ich den Überblick verliere. Der zeitliche Versatz von Bestellung und Zahlung sowie die vielen unterschiedlichen Fristen lassen mich mit einem unguten Gefühl im Bauch zurück – gerade in dieser Zeit der unüblichen Abbuchungen von meinem Konto kann schnell etwas durchgehen. Was nützt es mir, dass ich eine per Lastschrift erfolgte Abbuchung zurückfordern kann, wenn ich sie nicht mehr zuordnen kann? Welche Kreditkartenzahlung habe ich wirklich autorisiert?

Es sollte einfacher sein. Es sollte geordneter sein. Es sollte unmittelbarer sein. Nächstes Jahr um diese Zeit?

Ich stelle mir vor, wie ich das neue Radio für meine Mutter bestelle und im Moment der Bestellung in meiner Banking App aufgefordert werde, den genauen Betrag dafür freizugeben. Die kitschigen Weihnachtspullover mit der Rentiernase werden in zwei verschiedenen Größen geordert, anprobiert. Und im Moment der Rücksendung des viel zu großen Exemplars fragt mich mein Onlinebanking, ob ich die Zahlung für den passenden Pulli freigebe.

Es liegen drei Pakete für mich in der Packstation. Um die Klappe öffnen zu können, weise ich nach Aufforderung die Zahlung an. Der XY Shop will schon wieder 90€ von mir? Abgelehnt! Dort habe ich doch gar nichts bestellt. Und meine Telefonrechnung ist im Dezember scheinbar höher als üblich gewesen und darum die Zahlungsaufforderung nicht automatisch bestätigt worden. Ich prüfe den Verbindungsnachweis und autorisiere dann per Hand – stimmt, ich habe mit den Verwandten in England telefoniert.

Die Aufforderung zur Zahlung, der Request-to-Pay. Ob meine nächste Weihnachtszeit besinnlicher oder friedlicher dadurch wird, wer weiß. Aber mehr Kontrolle über meine Zahlungen zu bekommen, bevor diese tatsächlich stattgefunden haben, und mir so meine Verwirrung beim Blick auf das Konto zu nehmen, das klingt doch fast so schön wie weiße Weihnacht.

Autor: Anuschka Clasen