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

Strukturierte Adressen – oder: die Vogel-Strauß-Taktik ist Käse

Die Zeit wird knapp, die nächste große IT-Herausforderung in den ISO-20022-Formaten steht an. Wie schon so oft beginnen die Eidgenossen mit den ersten Regelverschärfungen: Ab November 2022 werden vom Kunden eingereichte ISO-20022-Zahlungen mit unstrukturierten Adressinhalten beim Ultimate Creditor und Ultimate Debtor von den Banken abgelehnt.

Warum nun gerade diese beiden Angaben? Ganz einfach – die in der Masse der Zahlungen eher weniger häufig gefüllten Felder sind Teststrecke und Prüfstand in einem. Eher wenig Transaktionen werden betroffen sein – daher kann man sich dieser Thematik von klein auf und kalkuliert nähern.

„Gar nicht“ geht gar nicht
Für die Anwendungen und deren Entwickler ist das kleinteilige Herangehen allerdings kein gutes Vorgehen. Vieles spricht doch eher für ganz oder gar nicht – Letzteres ist aber keine Option. Dann doch eher, wenn schon strukturierte Adressen, diese bitte überall – also auch beim Creditor, Debtor und den anderen Adressangaben.

Zu kurz gedacht
Wenn Sie jetzt meinen: „Ach, das ist ja die Schweiz, das betrifft mich hier in Deutschland oder Österreich nicht“, dann ist das eine eklatante Fehleinschätzung. Auch im künftigen SWIFT-Zahlungsverkehr sollen ab 2025 ausschließlich nur noch strukturierte Adressen genutzt werden!
Und wer glaubt, dass damit die Kundenschnittstelle, also die korrekte Einlieferung der strukturierten Adressen durch die vielen Kundensysteme, nicht betroffen ist, der übersieht, dass bisher kein System existiert, das eine beliebige, unstrukturiert gelieferte Adresse richtig zerlegen und als strukturierte Adresse weiterverarbeiten kann. Die Vielfalt der internationalen Adressdaten macht dies unmöglich.

Handarbeit ist zumutbar
Also müssen wir jetzt alle ran – Kundenprodukthersteller wie auch Banken selbst. Überall müssen strukturierte Adressen erfasst und über die betroffenen Formate transportiert werden, bis sie dann irgendwann im SWIFT-Netz landen. Erfassungen müssen verändert werden, Datenbankstrukturen angepasst und die inhaltlichen Daten müssen an neuer Stelle im jeweiligen ISO-20022-Format landen. Da wie schon angedeutet eine automatische und fehlerfreie Migration/Wandlung der bisherigen unstrukturierten Adressdaten auf strukturierte Adressdaten nicht möglich ist, müssen wir es unseren Kunden und den Mitarbeitenden in der Bank zumuten, eine menschliche Kontrolle der konvertierten Adressdaten vorzunehmen – ein etwas längeres Projekt also. Für Deutschland wurde dieses schon mal für die neue ISO-Auslandszahlung im ISO-20022-Format pain.001.00.09 festgelegt, ab 2025 dann wirksam.

Zeiträume sind relativ
Wer jetzt noch glaubt, diese Umstellung wird durch ein Wunder irgendwie von selbst passieren, irrt sich: Die Zeit drängt! 3 Jahre sind für die Softwareentwicklung eine denkbar kurze Zeit, und die Arbeiten sind sehr umfangreich. Den Kopf in den Sand stecken, mag bequem erscheinen, führt jedoch schon kurzfristig zum Erblinden. Der frühe Vogel hat Budgets und Order längst vor Augen.

Autor: Michael Schunk


EBICS und die Echtzeitbenachrichtigungen - Eine Bestandsaufnahme

 

Mittlerweile ist es schon mehr als zwei Jahre her, dass die Spezifikation „Echtzeitbenachrichtigungen“  auf der EBICS Webseite www.ebics.de veröffentlicht wurde. In einem Blogbeitrag vom Oktober 2019  hatte ich mich bereits dieses Themas angenommen. Doch was ist daraus eigentlich geworden? Und wie hat sich der Einsatz in der Praxis entwickelt?

Tatsächlich wurde die neue Schnittstelle für Echtzeitbenachrichtigungen von einigen Instituten in Deutschland im EBICS-Bankrechner implementiert und ist mittlerweile bei diesen produktiv im Einsatz. Natürlich macht der damit verbundene neue Funktionsumfang nur Sinn, wenn es EBICS-Clients gibt, die diese Schnittstelle nutzen. Unter Umständen wurde in von Banken betriebenen Firmenkundenportalen daher diese Schnittstelle ebenfalls clientseitig implementiert.

Wir erinnern uns. Der Mehrwert dieser neuen Schnittstelle liegt in der potenziell schnelleren Rückmeldung bei SEPA Instant Payments im EBICS-Kanal sowie generell bei der Einsparung von Hoffnungsabfragen zu Downloaddaten. Wo stehen wir damit?

Einige Kreditinstitute in Deutschland haben das Konzept umgesetzt. Jedoch nicht jedes Kreditinstitut ist heute in der Lage, diesen neuen Service anzubieten. Unter Umständen ist es bankseitig für EBICS auch nicht oder noch nicht im Fokus. Neben der neuen Schnittstelle zur Echtzeitbenachrichtigung in Richtung Kunde ist nämlich auch die zeitnahe Bereitstellung der Downloaddaten im Bankrechner eine der Voraussetzungen, um Kunden einen Mehrwert für EBICS bieten zu können. Diese kontinuierliche und zeitnahe Bereitstellung aus den Backendsystemen heraus für den EBICS-Kanal muss dafür bei den Kreditinstituten zur Verfügung stehen.

Kundenseitig ist die Push-Benachrichtigung insbesondere für Firmenkunden von Interesse, bei denen die Aktualität und die Nähe zur Echtzeit zunehmend relevant ist. Diese EBICS-Kunden haben die Echtzeitbenachrichtigung auf der Clientseite zum Teil bereits implementiert. Andere, die z. B. ein geeignetes Firmenkundenportal des Kreditinstituts nutzen, kommen ggf. auch ohne eigenes Zutun in den Genuss des neuen Services. Dennoch verfügt nicht jeder EBICS-Client über die neue Websocket-Schnittstelle zur Echtzeitbenachrichtigung.

Fazit ist, dass die Funktion der Echtzeitbenachrichtigung im Jahr 2022 noch nicht in der Breite bei den EBICS-Kunden angekommen ist. Bisher sind es gerade spezialisierte Firmenkunden und institutionelle EBICS-Kunden, die auf Echtzeitbenachrichtigung im EBICS-Kanal setzen. Für sie stellt die Echtzeit in den Zahlungsverkehrsprozessen einen besonderen Mehrwert dar, für den sich auch die eine oder andere Investition lohnt. Die Kreditinstitute dieser Kunden bieten den passenden Service an.

Wir sehen, dass generell das Thema Echtzeit im Zahlungsverkehr noch Wachstumspotenzial hat. Somit ist davon auszugehen, dass auch das Thema Echtzeitbenachrichtigung in Verbindung mit EBICS noch an Bedeutung gewinnen wird. Bleiben wir also gespannt!

Autor: Michael Lembcke

Der digitale Euro als Innovationsgrundlage für die Wirtschaft

Die Digitalisierung von Wirtschaft und Gesellschaft schreitet mit rasantem Tempo voran. Vor allem das Internet of Things (IoT) verspricht revolutionäre Geschäftsmodelle, bei denen sich die europäische Industrie als Weltmarktführer positionieren kann. Hierbei bezeichnet der Begriff IoT die zunehmende Vernetzung von Maschinen und Geräten. Dabei werden Geräte mit einer digitalen Identität ausgestattet, sodass sie miteinander kommunizieren und ohne menschliche Eingriffe autonom Prozesse ausführen können. Dieser Trend wird in der Zukunft immer mehr an Relevanz gewinnen. 

Um das volle Potenzial der Digitalisierung der Industrie auszuschöpfen, muss der komplette Prozess inklusive Zahlungsverkehr optimiert und auf IoT-Payments abgestimmt werden, sodass auch Zahlungen in Zusammenhang mit diesen neuen Geschäftsmodellen effizient, automatisiert und in Echtzeit abgewickelt werden können. 

Das heutige Zahlungssystem weist im Zusammenhang mit IoT jedoch noch folgende Ineffizienzen auf:

  1. Begrenzte Umsetzbarkeit von Internet of Things (IoT)-Geschäftsmodellen
    Pay-per-Use- und Machine-to-Machine-Zahlungen erfordern menschlichen Eingriff

  2. Keine durchgehende Standardisierung
    Für eine durchgängige automatisierte Verarbeitung fehlen noch geeignete Standards.

  3. Fehlende Automatisierung beim Onboarding
    Mit der Etablierung von autonomen Maschinen ist ein automatisiertes Onboarding notwendig.

  4. Hohe Transaktionskosten
    Besonders grenzüberschreitende Transaktionen und Kleinstbetragszahlungen sind mit hohen Kosten verbunden.

  5. Langsame Settlement-Mechanismen
    Mit Instant Payments sind zwar Echtzeitzahlungen möglich, aber die Verbreitung ist eingeschränkt.

  6. Fehlende Know-your-Object-Prozesse
    Geeignete Compliance-Prozesse zum Erkennen und Prüfen von Maschinenidentitäten müssen noch geschaffen werden.

Zur Minimierung dieser Prozessineffizienzen und Limitationen des Zahlungssystem wäre die Etablierung eines innovativen Geldsystems von großem Vorteil. So sollte die Europäische Zentralbank (EZB) während der zweijährigen Analysephase zum digitalen Euro nicht nur die Auswirkungen auf den Konsumenten berücksichtigen, sondern auch Lösungen für die voranschreitende digitale Transformation der Wirtschaftsprozesse entwickeln. Da es jedoch gegenwärtig unklar ist, welche Ergebnisse während der Analysephase für die Wirtschaft entstehen, hat der Privatsektor bereits begonnen, den Euro zu digitalisieren, sodass (Übergangs-)Technologien für Wirtschaftsprozesse Einzug erhalten. 

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 in diesem Jahr auf diesem Wege regelmäßig über Neuigkeiten zum digitalen Euro informieren.

Autor: Philipp Schröder

Zahlungsverkehr 2022: Jahr der Weichenstellungen

Die Fülle der Aufgaben im Zahlungsverkehr bleibt gewaltig. Für viele Vorhaben wird 2022 ein entscheidendes Jahr. Angesichts schwieriger Rahmenbedingungen – nicht zuletzt durch die anhaltende Pandemie – stellt sich allerdings die Frage, ob alle von ihnen wirklich fahrplanmäßig über die Zielgerade gehen beziehungsweise maßgeblich weiter vorangetrieben werden können.

Zu den bedeutendsten Initiativen im Jahr 2022 zählen sicherlich die großen Projekte im internationalen und Großbetragszahlungsverkehr: der Go-live der TARGET2-Konsolidierung und der Start der SWIFT-Umstellung auf das ISO-20022-Format, beide im November 2022. Belastbare Aufschlüsse, wie weit die Finanzdienstleistungsbranche bei ihren Vorbereitungen für die TARGET2-Umstellung wirklich ist, werden die im Frühjahr Fahrt aufnehmenden Nutzertests und ihre Überwachung durch die Zentralbanken zeigen.

Darüber hinaus zeichnen sich am Horizont des internationalen Zahlungsverkehrs bereits zwei weitere Vorhaben ab: die Abwicklung grenzüberschreitender Zahlungen in Echtzeit sowie die Vereinfachung und Verbesserung internationaler Zahlungen für kleinere Unternehmen und Verbraucher. Treiber hinter dieser Entwicklung sind die G-20-Staaten und der Erfolg alternativer Anbieter wie Wise.

Im Massenzahlungsverkehr (SEPA) müssen sich Zahlungsdienstanbieter in diesem Jahr für die 2023 anstehende Umstellung der SEPA-Schemes auf die neuere ISO-Version fit machen. Zudem müssen sie die konkreten Auswirkungen der EU-Richtlinie gegen Mehrwertsteuerbetrug auf ihren Geschäftsbetrieb einschätzen. Hintergrund: Die EU ergreift massive gesetzliche Maßnahmen zur Eindämmung der Mehrwertsteuerlücke innerhalb der Union und führt dazu eine Art Steuerdatenhaltung im Zahlungsverkehr ein. Die neuen Meldepflichten treffen Finanzdienstleister ab Januar 2024. 


Schicksalsjahr für RTP

Bei den SEPA-Verfahren wird sich das Augenmerk in diesem Jahr darauf richten, ob es gelingt, Request to Pay (RTP) in den Markt zu tragen. Anwendungsszenarien gibt es reichlich. RTP ist unter anderem im E-Commerce, im E-Billing-Prozess und für wiederkehrende Zahlungen, ja sogar am Point of Sale einsetzbar. Dennoch zögern Finanzdienstleister offenbar mit der konkreten Umsetzung. Bislang sind kaum Bestrebungen erkennbar, Produkte auf Basis einer RTP-Nutzung aufzulegen. Mögliche Gründe hierfür sind eine mangelnde Nachfrage, wirtschaftliche oder technische Hürden:
 

  • Kunde-Bank-Schnittstelle: Es gibt aktuell kein zentrales Verzeichnis, welcher Kunde sein Konto bei welchem Institut hat.
  •  RTP-Clearing: Bislang bietet nur EBA CLEARING solche Prozesse, die mit RTP konform sind. Um möglichst viele Zahlungsempfänger und Zahler abzudecken, müssen andere Clearinghäuser nachziehen.
  • Zahlungsablauf: Zum einen ist eine technische Lösung für das Matching gefragt, also für die Zuordnung von Antwortmeldungen an die Bank des Zahlungsempfängers zum ursprünglichen RTP. Zum anderen gilt es zu entscheiden, welche Zahlungsmöglichkeiten angeboten werden sollen.

Beim Zahlungsablauf von RTP beruhen viele Anwendungsfälle auf dem Einsatz von SEPA Instant Payments. 2022 wird Klarheit bringen, ob die EU-Kommission Instant Payments im Rahmen einer Anpassung der SEPA-Verordnung oder der Payment Services Directive (PSD) – zumindest im Hinblick auf Erreichbarkeit – verbindlich für alle Zahlungsinstitute vorschreiben wird. Denn zum Ende des Jahres 2021 hatten nur rund 60 Prozent aller europäischen Zahlungsdienstleister das entsprechende Scheme gezeichnet. Entsprechend erfolgen nur – oder immerhin – gut zehn Prozent aller Überweisungen im SEPA-Raum auf Basis von SEPA Instant Credit Transfer (SCT Inst).


Wenig Dynamik bei EPI zu erwarten

Die Verbreitung von RTP und Instant Payments wird auch für die Verwirklichung der European Payments Initiative (EPI) eine wichtige Rolle spielen. Im Moment ist allerdings fraglich, ob es überhaupt gelingt, eine einheitliche gesamteuropäische Zahlungslösung als Alternative zu bestehenden internationalen Zahlungslösungen und -systemen zu schaffen. In Deutschland scheinen nur noch die Sparkassen-Finanzgruppe und die Deutsche Bank der Initiative zu folgen. Scheitert die EPI, machen sich die Europäer endgültig von US-amerikanischen und wohl auch chinesischen Verfahren abhängig. Es bleibt zu hoffen, dass sowohl die Politik als auch die öffentliche Hand gegenüber der Finanzbranche den Druck, aber auch die Unterstützung noch einmal deutlich erhöhen. Und vielleicht bildet ja auch ein französisch-deutscher Kern den Nukleus für EPI.

Und wie geht es 2022 mit dem digitalen Euro weiter? Das Zukunftsprojekt steht immer noch auf dem Prüfstand. Dabei gilt die Prämisse, dass der digitale Euro das Bargeld nicht ablösen, sondern ergänzen soll. Aus Verbrauchersicht muss die digitale Alternative ein Höchstmaß an Anonymität und Sicherheit bieten. Darüber hinaus sind Bereitstellung, Verfügbarkeit und Interoperabilität von hoher Bedeutung. Nach aktuellem Kenntnisstand will die EZB Geschäftsbanken und Zahlungsdienstanbieter (Payment Service Providers, kurz PSP) in das Vorhaben einbinden. Sie sollen als Vermittler zwischen Zentralbanken und Verbrauchern fungieren.


So oder so: Der digitale Euro wird kommen

Aber digitales Geld muss ja nicht zwangsläufig von einer Zentralbank herausgegeben werden. Auch Finanzinstitute können Lösungen für die sogenannten programmierbaren Zahlungen schaffen. Ein Beispiel hierfür sind eurobasierte Stablecoins – digitale Token, die mit einem bestimmten Geldwert unterlegt sind. Auch bei diesen Verfahren sind 2022 Fortschritte zu erwarten.

Wie auch immer die digitale Währung am Ende aussieht, sie wird kommen. Denn nur dadurch kann die deutsche Industrie von den Potenzialen des Internet of Things (IoT) in vollem Umfang profitieren. Besonders die fortschreitende Automatisierung in der Warenlogistik oder auch die immer beliebteren Asset-as-a-Service-Modelle sind ohne vollständig autonome Zahlungen in Echtzeit dauerhaft kaum vorstellbar.

Angesichts der mit den oben genannten Umstellungen verbundenen Kosten werden Kreditinstitute – vornehmlich Tier-2-Institute – auch 2022  die Abwicklung des Zahlungsverkehrs zunehmend auslagern oder zumindest Zahlungsverkehrssoftware als Software as a Service einkaufen.


Kampf um die Talente

Last, but not least wird sich ein gesamtgesellschaftlicher Trend der vergangenen Jahre weiter verstärken: der Mangel an beziehungsweise der Kampf um Ressourcen. Die Preise für Experten und Dienstleistungen in der IT werden weiter steigen. Denn die Frage ist zunehmend nicht mehr, wer eine Aufgabe übernehmen kann, sondern ob man überhaupt jemanden findet, der sie erledigt. Die Einkaufsabteilungen der Kreditinstitute werden sich zu Headhuntern für externe Ressourcen entwickeln.


Autor: Hubertus von Poser, Head of Consulting Payments, PPI AG


Tipps für einen reibungslosen Übergang zu EBICS 3.0

EBICS 3.0 ist seit November 2021 offiziell bei den Banken eingeführt und kann von Firmenkunden genutzt werden. Daneben ist die letzte Vorgängerversion weiterhin gültig. Eine der Änderungen in EBICS 3.0 betrifft den Wegfall der dreistelligen Auftragsarten bzw. der FileFormat-Parameter in Frankreich für operative Geschäftsvorfälle. Diese werden nun über die sogenannten Business Transaction Formats (BTF) abgebildet. BTFs umfassen jeweils acht Parameter: Service Name, Service Scope, Service Option, Service Message Name, Service Message Name Version, Service Message Name Format, Service Message Name Variant und Service Container.

Innerhalb einer Kundenvereinbarung muss unabhängig von der EBICS-Version die zentrale Vereinbarung für den jeweiligen Geschäftsvorfall berücksichtigt werden können. Die Kompatibilität und Interoperabilität zwischen den Vorgängerversionen sind für EBICS vorgegeben. Wenn zwei elektronische Unterschriften für eine SEPA-Überweisung vereinbart sind, ist es beispielsweise irrelevant, ob Einreichungen hierzu per BTF oder Auftragsart bzw. FileFormat-Parameter erfolgen. Diese Bedingung erfordert ein internes Mapping alter und neuer Geschäftsvorfälle im Bankrechner und ggf. auch in Client-Systemen. Bisher sind für die Standardgeschäftsvorfälle diese Mappings offiziell spezifiziert.

Die dem EBICS vor- und nachgelagerten Verarbeitungen bei den Kreditinstituten und bei den Firmenkunden orientieren sich i. d. R. noch an den bisherigen EBICS-IDs, wie den dreistelligen Auftragsarten und in Frankreich an den bis zu 40-stelligen FileFormat-Parametern. Solange ein Mapping existiert, besteht aber auch keine Notwendigkeit daran etwas zu ändern. Was ist jedoch, wenn für einen Geschäftsvorfall keine Auftragsarten/FileFormat-Parametern mehr spezifiziert sind und die Geschäftsvorfälle ausschließlich mit BTF gelten? Will man seine angrenzenden Verarbeitungsprozesse nicht an die BTF anpassen, kann man natürlich ein Mapping beibehalten. Für die nicht spezifizierten Mappings sollte man dann allerdings individuelle, passende IDs festlegen.

Im Außenverhältnis in der Kunde-Bank-Beziehung sollte man beachten, dass dem Kunden bzw. Client-System die Vorgaben des Bankrechners hinsichtlich Geschäftsvorfällen und Mappings auf verschiedenen Wegen mitgeteilt werden. Dabei kommen zudem die unterschiedlichen Darstellungen aus Sicht des Kunden, Teilnehmers und Zeitpunkts zum Tragen. Ein Teilnehmer nutzt immer eine konkrete EBICS-Version, während die Kundenvereinbarung alle gültigen Versionen abbilden muss. Außerdem spielt der Zeitpunkt der Information eine Rolle. So ist vor der Initialisierung des Teilnehmers dem Kreditinstitut i. d. R. nicht bekannt, welche EBICS-Version dieser nutzen wird.

Das BPD-Blatt (BPD=Bankparameterdaten), das bei der Einrichtung des Teilnehmers auf dem Bankrechner angelegt wird, muss daher die Optionen aller unterstützten EBICS-Versionen inkl. evtl. BTF-Mapping-Vorgaben abbilden. Gleiches gilt zumindest auch für die Auftragsart HKD, mit der die Vereinbarungen auf Kundenebene vom Client abgerufen werden können. Wird bei bestimmten Geschäftsvorfällen in der Kunde-Bank-Beziehung ungeachtet der internen Nutzung kein Mapping mehr angeboten, so sollte die jeweilige Information  das Mapping entsprechend ausschließlich per BTF abbilden. Für die interne Administration und Pflege ist es hilfreich, wenn bei einem internen Mapping die ausschließlich intern genutzten individuellen IDs sichtbar sind (z. B. individuelle Auftragsarten mit eigenem BTF-Mapping), aber sich von den externen IDs unterscheiden.

Zusammenfassend lässt sich sagen, dass die Herausforderung darin besteht, bei der neuen Vielfalt an Informationen den Übergang zu EBICS 3.0 für alle Beteiligten so leicht wie möglich zu machen. Mit der richtigen Konfiguration und unter Beachtung einiger Maßgaben bei der Bedienung, ist der Umstieg auf die neue EBICS-Version allerdings gar nicht so schwierig. Sollten Sie Hilfe beim Umstieg auf EBICS 3.0 benötigen oder Fragen dazu haben, sprechen Sie uns gern an.

Autor: Michael Lembcke


API - ein Türöffner für Bankanwendungen

Die Abkürzung API ist zurzeit allgegenwärtig. Die drei Buchstaben stehen für Application Programming Interface, also eine Programmierschnittstelle für Anwendungen. Mit allen APIs ist die Hoffnung verbunden, möglichst einfach und schnell über eine standardisierte Schnittstelle viele bankfachliche Anwendungsfälle umsetzen zu können. Die Zahl der dafür genutzten Anwendungsfälle wächst stetig. Eine Vielzahl von Stellen treibt diese Entwicklung voran, so dass APIs den Bankenmarkt grundlegend verändern könnten.


Die PSD2 als ein Kristallisationskeim für APIs in den letzten Jahren hat dazu geführt, dass verschiedene Initiativen in Europa eine Access-to-Account-API spezifiziert haben. Die wichtigsten dieser Initiativen sind sicherlich „The Berlin Group“, „STET“  und „PolishAPI“. Aber auch außerhalb von Europa hat die PSD2 ausgestrahlt. In der Schweiz wurde das „OpenBankingProject“ (https://www.openbankingproject.ch/en/) ins Leben gerufen, welches sich mit der SwissNextGenAPI an die API der Berlin Group anlehnt. Im Vereinigten Königreich ist die „Open Banking“-Initiative  entstanden. Alle Initiativen und deren APIs setzen auf die PSD2, und alle eint der Wunsch nach einer hohen Effizienzgewinnung.


Die Realität dämpft diese Hoffnung etwas. Natürlich gibt es die oben beschriebenen Standardisierungsinititiativen. Aber erstens gibt es nicht die eine Spezifikation, zweitens sind Banken nicht verpflichtet, sich an diese zu halten, und drittens lassen die Spezifikationen Freiraum in der Implementierung (Stichwort Implementor Options). Möchte nun ein Marktteilnehmer, ob Bank oder Drittdienstleister, die Access-To-Account-API der Banken nutzen, steht er vor einer Herausforderung. PPI hat diese Herausforderung angenommen und mit dem Produkt TRAVIC-Payment-Client-API eine Bibliothek geschaffen, die die skizzierte Heterogenität hinter einer einzigen Schnittstelle verbirgt. Durch Verwendung von TRAVIC-Payment-Client-API können während der Anbindung der Access-to-Account-Schnittstellen der Banken Risiken minimiert und die Entwicklungszeit verkürzt werden. Das Produkt ist bei der Atruvia AG produktiv im Einsatz. Mehr darüber und wie z. B. die Atruvia AG davon profitiert hat, lesen Sie hier.


Aus Sicht von PPI ist das Thema API im Kontext Payments nicht mehr wegzudenken. Punktuell durch die PSD2 angetrieben, wurden erste Schritte bankseitig gemacht. Aber es ist abzusehen, dass es nicht dabei bleiben wird. Die Berlin Group hat längst das openFinance API Framework spezifiziert, das die Anwendungsfälle der Access-to-Account Schnittstelle erweitert. Und, soweit bekannt, sind für 2022 weitere Erweiterungen an der Spezifikation geplant. Diese Mehrwertdienste, die natürlich über APIs bereitgestellt werden, werden in einem zunehmenden Umfang auf den Entwicklerportalen der großen Banken angeboten. Einige dieser APIs richten sich nicht mehr nur an Drittdienstleister, sondern auch direkt an Unternehmen. Damit wird deutlich, dass das Thema API nicht auf PSD2-relevante Use-Cases beschränkt ist, sondern sich zunehmend als eigenständiger Kanal für unterschiedliche Stakeholder etablieren wird. Folglich wird es voraussichtlich über kurz oder lang neben EBICS, FinTS und Access-to-Account weitere APIs geben. 


Nicht nur die Berlin Group ist in Sachen API unterwegs. Das European Payments Council (EPC) hat eine Arbeitsgruppe auf europäischer Ebene ins Leben gerufen, die ein Rulebook für den Zugriff auf SEPA Zahlungsverkehrskonten über APIs erarbeiten soll (https://www.europeanpaymentscouncil.eu/news-insights/news/call-candidates-sepa-payment-account-access-multi-stakeholder-group-spaa-msg), an der PPI teilnimmt. Außerdem hat das EPC in der kürzlich veröffentlichen Ankündigung zum „SEPA Request to Pay scheme rulebook 2.0“ sogar angekündigt, dass der Austausch von SRTP-Nachrichten über APIs in Zukunft verpflichtend sein wird. 


Viel Bewegung im Markt, aber eines wird dabei deutlich: Die Liste bestehender und zukünftiger Initiativen rund um APIs ist lang, und eine Reihe von Innovationen ist in diesem Umfeld denkbar. PPI hat mit dem Produkt TRAVIC-Payment-Client-API den ersten Schritt gemacht und bietet dieses insbesondere auch As-a-Service an. Darüber hinaus konzipiert PPI weitere Angebote rund um das Thema API.

Autor: Christian Wenz