Ablösung von NextGenPSD2 – Berlin Group stellt openFinance API vor
NEWS 02/2024
Die Berlin Group hat die openFinance API veröffentlicht. Wir haben die neuen Veröffentlichungen für Sie analysiert und geben in diesem Artikel sowohl einen kurzen Überblick über die bereits veröffentlichten als auch die angekündigte neuen Services und erläutern, wie Banken, Drittdienstleister und Endkunden davon profitieren werden.
Einführung
Das NextGenPSD2-Framework der Berlin Group hat die Umsetzung der überarbeiteten Zahlungsdienstrichtlinie Payment Service Directive 2 (PSD2) der EU-Kommission erfolgreich standardisiert. Nun wurde Version 2 des API-Frameworks vorgestellt, die neue Dienste und Funktionalitäten, die über den regulatorischen PSD2-Rahmen hinausgehen und damit auf die Zukunft von Open Finance ausgerichtet sind, beinhaltet. Wir haben die neuen Veröffentlichungen der Berlin Group für Sie analysiert und geben in diesem Artikel sowohl einen kurzen Überblick über die bereits veröffentlichten als auch die angekündigten neuen Services und erläutern, wie Banken, Drittdienstleister und Endkunden davon profitieren werden.
Bisherige Veröffentlichungen der Berlin Group
NextGenPSD2 XS2A Framework
2018 hat die Berlin Group das NextGenPSD2 XS2A Framework initiiert und damit einen Standard für die Umsetzung der PSD2-Richtlinie definiert, der die Anforderungen vollumfänglich abdeckt. NextGenPSD2 konzentriert sich in erster Linie auf die Definition der Schnittstellen, die ein Drittanbieter (TPP) verwenden kann, und hier insbesondere auf die technischen Merkmale dieser Schnittstellen und auf ihre Sicherheitsmechanismen.
In Zusammenarbeit mit zahlreichen europäischen Banken hat die Berlin Group einen Mindeststandard an Datenfeldern und Endpunkten erstellt, die alle Banken, die den Standard verwenden, über ihre APIs anbieten müssen. Basierend auf den Anforderungen der PSD2-Richtlinie beinhaltet NextGenPSD2 standardisierte API-Beschreibungen für die regulatorisch erforderlichen Services: Payment Initiation, Account Information und Fund Confirmation. Die Berlin Group überprüft und überarbeitet ihre Standards regelmäßig, um sie zukunftsorientiert an die wandelnden Bedürfnisse und Anforderungen der Branche anzupassen. So wurde auch NextGenPSD2 kontinuierlich aktualisiert. Im Herbst 2023 wurde dann die vollständig überarbeitete Version 2 des Frameworks vorgestellt: die openFinance API.
Version 2.0: openFinance API
Das bisherige NextGenPSD2 XS2A Framework der Berlin Group wurde 2018 initiiert, um damit einen Standard für die Umsetzung der PSD2-Richtlinie zu definieren, der die Anforderungen vollumfänglich abdeckt. Die Spezifikation NextGenPSD2 wurde fort- laufend um innovative Use Cases sowie sogenannte Premiumdienste erweitert und im Zuge dessen zu einer API-Version 2 entwickelt, die besser an den er- weiterten Anwendungsbereich des Frameworks angepasst werden kann.
Mit dem Update kommt auch der neue Name openFinance API. Premiumdienste sind monetarisierte Angebote von Banken oder TPPs, die auf Basis der Daten aus den zusätzlichen optionalen Beschreibungen der openFinance API dem Endkunden zusätzliche Funktionalitäten bieten sollen. So werden auch für die konto- führenden Institute und Kontoinformationsdienstleister erstmals monetäre Anreize geschaffen, die bislang nur mit dem hohen Aufwand für die Umsetzung der PSD2-Schnittstelle belastet wurden.
Die ersten Dienste, die im Rahmen der Definition der openFinance API im Oktober 2023 unter neuer Architektur veröffentlicht wurden, sind die Services, die für die PSD2-Konformität relevant sind. Dazu wurde ein Dokumentenpaket veröffentlicht, das unter anderem die entsprechenden Guidelines zur Implementierung der Endpunkte der verpflichtenden Dienste und einen Guide zur Migration auf Version 2 enthält. Dieser Guide gibt einen Überblick über die neue Dokumentation und über die wichtigsten Implementierungsänderungen beim Wechsel vom NextGenPSD2 API Framework Version 1.3 zum neuen openFinance API Framework Version 2.0.
Zusätzlich zu den genannten regulatorisch notwendigen Services wurden auch erste Premium-Payment- Services veröffentlicht, beispielsweise neue Premium- Initiation-Services und Premium-Account-Information-Services. Tabelle 1 gibt einen Überblick über die bereits veröffentlichten neuen Services und Standardisierungen sowie deren Nutzen für die Banken und Kunden, beschrieben durch mögliche Use Cases:
Die Berlin Group und ihre Rolle für die Open-Finance-Bewegung
Die Berlin Group ist ein Zusammenschluss europäischer Banken, Bankenverbände, Betreiber von Zahlungssystemen und weiteren wirtschaftlichen und staatlichen Akteuren. Sie verfolgt unter anderem das Ziel, offene und unabhängige Standards inner- und außerhalb der Euro-Zone zu definieren, um auf diese Weise die Umsetzung der Anforderungen der Europäischen Kommission, der EZB und des EPC an die Zahlungsdienste im Binnenmarkt zu vereinfachen.
Dabei kommen die entwickelten Standards und APIs (Application Programming Interface, Anwendungsprogrammierschnittstelle) der Berlin Group auf eine Marktabdeckung von rund 80 %. Damit agiert sie als Wegbereiter der Open-Finance-Bewegung, die sowohl für die Endkunden, Drittdienstleister (Third Party Partner, TPP) als auch für die Banken einen echten Mehrwert bietet.
Überblick über die bereits veröffentlichten neuen Services und Standardisierungen sowie deren Nutzen für die Banken und Kunden, beschrieben durch mögliche Use Cases:
| Service | Beschreibung | Use Case/Nutzen |
| Request to Pay + Consent Mechanismus (RTP) | Das RTP-Schema definiert Regeln, Nachrichten und Datensätze für den Austausch einer Zahlungsaufforderung zwischen einem Absender und einem Empfänger. Erweitert wurde das Schema um einen optionalen Consent-Mechanismus.
Durch den Consent-Mechanismus wird gewährleistet, dass eine Zahlungsaufforderung nur gesendet werden kann, wenn der RTP-Empfänger sein Einverständnis zum Empfang von Zahlungsaufforderungen an den Absender erteilt hat. |
Der Consent-Mechanismus erhöht die Sicherheit und verringert demnach auch das Risiko vor betrügerischen Anfragen. Request-to-pay-Anfragen können nach Einrichtung des Consent-Mechanismus ausschließlich von freigegebenen PSP und weiteren TPP gesendet werden und fungieren auf diese Weise als eine Art Whitelabel-Ansatz für den PSU. |
| Extended Payment Initiation Service: Reservation of Funds (ROF) | TPP initialisiert nach Anfrage durch PSU die Reservierung von Geldmitteln beim ASPSP. Nach erfolgreicher Kundenauthentifizierung und Prüfung der Limite und Verfügbarkeit werden die Mittel reserviert. | Durch Reservierung von Funds können Mittel zur Deckung unerwarteter Kosten oder künftiger finanzieller Verpflichtungen zurückgelegt werden. Das schafft Sicherheit und Planbarkeit sowohl für den Endkunden als auch die Banken. |
| Extended Payment Initiation Service: Recurring Payments (RP) | Mit RP können PSU wiederkehrende Zahlungen direkt im Konto ihrer Bank aufsetzen, wobei der PSU Parameter wie Betrag, Häufigkeit und Lauf- zeit im Voraus festlegen kann. Für diese initiale Vereinbarung ist eine einmalige SCA durch den PSU bei der kontoführenden Bank bzw. dem ASPSP erforderlich. Anschließend werden Zahlungen in gewünschten, regelmäßigen Abständen automatisch im Konto des Kunden ausgelöst.
RP hat das Potenzial, sich als eine schnellere, sicherere und kostengünstigere Alternative zur klassischen Lastschrift durchzusetzen und dem Endkunden als auch den Banken etwaige Vorteile zu bieten. |
Im Gegensatz zur Lastschrift werden bei RP die Zahlungen nicht direkt vom Bankkonto eingezogen, sondern direkt im Konto des Kunden verwaltet (maximale Transparenz aus Kundensicht) und ausgelöst. RP können dadurch entweder sofort oder am selben Tag erfolgen, wohingegen die Bearbeitung der Lastschrift mehrere Werktage in Anspruch nehmen kann.
RP sind durch die schnelle Initiierung und Möglichkeit der Anpassung genannter Parameter deutlich flexibler. Beim Lastschriftverfahren sind zwar Änderungen möglich, eine Vorankündigung durch den ASPSP ist jedoch erforderlich und der Prozess ist meist träge. Typische Anwendungsbereiche sind Abonnement-Zahlungen, also jede Art von Streaming-Service, Online-Mitgliedschaften etc., aber auch leistungsgerechte Abrechnungsmodelle. |
| Extended Payment Initiation Service: Multiple Recurring Payments (MRP) | MRP ist ein innovatives Zahlungsmodell, um mehrere wiederkehrende Zahlungen in einer Zahlungsperiode sicher über eine API anzubieten. Als Teil des überarbeiteten openFinance-Frameworks hat die Berlin Group nun eine standardisierte Schnittstelle für MRP definiert und ebnet damit den Weg für ein schlankeres und kosteneffizienteres Zahlungsökosystem.
Im Gegensatz zu den Standard oder Fixed Recurring Payments, wobei eine Zahlungen pro Abrechnungszeitraum der Standard ist, können mit MRP mehrere Transaktionen mit unterschiedlichen Beträgen, bspw. auf der Basis von Faktoren wie Nutzung, Verbrauch oder anderen in der Zahlungsvereinbarung festgelegten Variablen variieren, aber im Rahmen des maximal gesetzten Betrags ausgelöst werden. Genau wie bei RP muss der PSU die Zahlungsvereinbarung einmalig bei dem ASPSP mittels SCA autorisieren. Der Service kann durch etwaige Risiko-, Limit- und Fund-Checks angereichert werden. |
Die resultierende Flexibilität erweitert den Anwendungsbereich von RP, sodass Banken den Kunden direkt über ihre eigenen Banking- Apps oder via TPP innovative Zahlungsmethoden anbieten können, bspw. Dienste mit variablen Preisstrukturen oder nutzungsabhängigen Abrechnungsmodalitäten:
Typische Usage-Based-Pricing-Modelle sind SaaS-Lösungen, wo- bei sich die Beträge bspw. je nach Anzahl der API-Aufrufe richten oder One-Click-Payments, also der Abschluss von Käufen mit einer Aktion ohne weitere Authentifizierung, solange die Beträge die definierte Betragsgrenze pro Periode nicht überschreiten.
„Buy now – pay later“ ist ebenfalls einer der Use Cases für MRP, wo- bei ein Zusammenspiel mit ROF oftmals von Nutzen ist.
Dabei muss dann nicht auf teure Drittdienstanbieter zurückgegriffen werden, sondern die Bank kann den Zahlungsverkehr wieder über sich direkt laufen lassen.
Auch für Personal-Finance-Management-Systeme eignet sich MRP, um bspw. abhängig von verfügbaren Mitteln am Ende einer definierten Periode eine automatische Übertragung von Funds auf einen Savings-Account zu veranlassen. |
| Extended Account Information Ser- vice (XAIS)
|
Die XS2A-Kernschnittstelle unterstützt bereits Kontoinformationsdienste (AIS) für Girokonten und Card Reconciliation Accounts. Der XAIS der überarbeiteten openFinanceAPI erweitert die bislang unterstützten Konten um weitere vier Kontenarten:
• Einzelkartenkonten • Sparkonten • Darlehenskonten • Wertpapierkonten |
Die Erweiterung der unterstützten Kontenarten durch XAIS bedeutet für den Kunden bzw. den PSU in erster Linie mehr Transparenz und einen besseren Überblick über die eigenen Finanzen, wenn die- se konsolidiert über eine Banking-App oder einen TPP zur Verfügung gestellt werden.
Banken und generell ASPSP profitieren von der Bereitstellung dieser konsolidierten Daten zum einen durch die Möglichkeit zur genaueren und umfangreicheren Risikobewertung des Kunden für bspw. die Berechnung eines Kreditrisiko-Scorings. Zum anderen ist die Erweiterung nützlich, um die Betrugsbekämpfung zu verbessern, da u. a. das Risiko von False-positive-Fällen gesenkt werden kann, falls der Kunde zum Beispiel lediglich seine Geldmittel häufig innerhalb seiner Konten verschiebt. |
Legende
PSU – Payment Service User
PSP – Payment-Service-Provider
PIS(P) – Payment-Initiation-Service(-Provider)
AIS(P) – Account-Info-Service(-Provider)
ASPSP – Account-Servicing-PSP
SCA – Strong Customer Authentication
TPP – Drittdienstleister
Angekündigte Premium-Services für die openFinance API
Neben den veröffentlichten Services und Standards wurden auch bereits zukünftig geplante innovative Services von der Berlin Group in Aussicht gestellt. Die openFinance API wird dahin gehend zum Beispiel um einen „Document-Service“ erweitert, der das Versenden wichtiger Dokumente direkt in die Postfächer der Kunden über die API vornehmen und somit den Erhalt oder auch Nichterhalt erfassen kann.
Mit dem geplanten „Premium-Discovery-Service“ wird ein detaillierter Suchdienst beschrieben, der einen umfassenden Überblick über die APIs der Bank mit technischen, betrieblichen und geschäftlichen Parametern bieten kann. Zuletzt wurden „Premium- Fee-Services“ angekündigt, die über spezielle On- boarding-Funktionen verfügen, um Verzeichnisse von Systemen und Gebühreninformationen zu verwalten. Dies bedeutet, dass Gebührenänderungen beispiels- weise einfach und dynamisch über die API verwaltet werden könnten, indem signierte Preislisten durch die Bank oder TPP veröffentlicht werden. Die Verwaltung von Gebühreninformationen führt dabei aber auch zu Mehraufwand für den Dienstleister, der mit der Speicherung und Administration der Daten belastet wird.
Mit ihren veröffentlichten und angekündigten Standardisierungen leistet die Berlin Group ihren Beitrag, den Zahlungsverkehr leichter zugänglich, sicherer und effizienter zu gestalten und damit Banken und TPPs neue Möglichkeiten zu bieten, Nutzen aus der Open- Finance-Bewegung und der Öffnung des Zahlungsverkehrs zu ziehen.
Sicherheit für Banken: PSD3, SPAA und Finance Data Act (FIDA)
Mit der openFinance API schafft die Berlin Group ein weiterführendes standardisiertes Rahmenwerk, das über die regulatorischen Anforderungen der PSD2 hinausgeht und es Bankkunden ermöglicht, neben dem Zugriff über die kontoführende Banking-App auch über TPPs auf ihre Bankkonten zuzugreifen, um innovative Premiumdienste und aggregierte Finanzdaten nutzen zu können.
Durch die Ausweitung des Zugangs auf ein breiteres Angebot an Datenquellen und zusätzlichen Kontotypen können dem Endkunden verbesserte Einblicke und umfangreichere Mehrwerte geboten werden. Ein Interesse, das Banken und TPPs gleichermaßen verfolgen.
Der neue Standard gibt Banken aber auch mehr Sicherheit in der Umsetzung mit Blick auf marktgetriebene Payment-Schemes sowie regulatorische Anforderungen, zum Beispiel durch die PSD3 und den FIDA.
Durch die zugesicherte Unterstützung der Berlin Group können Banken die Kosten der Einführung neuer, marktgetriebener Schemes, wie dem SEPA Payment Account Access (SPAA) Scheme, mit denen Banken schon jetzt erste standardisierte Premiumservices anbieten können, deutlich reduzieren.
Für Banken ein entscheidender Faktor, um den Schritt von der reinen Erfüllung von Compliance-Anforderungen neuer regulatorischer Verpflichtungen hin zu einem Open-Banking- und Open-Finance-Ökosystem unter fairer Verteilung von Kosten und Nutzen zu gehen. Ein solches Ökosystem bildet die Grundvoraussetzung dafür, dass Banken einen Anreiz haben, weitere Investitionen in Innovation, Sicherheit und Qualität der Open-Finance-Schnittstellen zu tätigen, und dass letztlich alle Akteure – Banken, TPPs und Endkunden – profitieren können.
Sie müssen sich anmelden, um einen Kommentar zu schreiben.