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