Posts mit dem Label Christian Wenz werden angezeigt. Alle Posts anzeigen
Posts mit dem Label Christian Wenz werden angezeigt. Alle Posts anzeigen

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

XS2A ohne Drittdienstanbieter? Warum nicht!

Im Rahmen der PSD2 wurde europaweit eine Schnittstelle für Drittdienstanbieter (XS2A-API) eingeführt. Die EU als Initiator strebt damit an, den Zugang zu den Bankkonten der Kunden für Dritte zu öffnen und damit den Wettbewerb im Markt zu fördern. Seit dem 14.09.2019 ist die XS2A-API fristgerecht in Europa von den Banken in Produktion genommen worden. Seither orientieren sich die Marktteilnehmer neu, adjustieren die XS2A-API an die Bedürfnisse der Stakeholder und arbeiten intensiv an Diensten sowohl für Verbraucher als auch für Firmen.

Als regulatorisches Must-have ist die XS2A-API für Banken zunächst einmal ein Kostentreiber. Jedoch wurden von Anbeginn Mehrwertdienste angedacht und z. B. von der Berlin Group bereits spezifiziert, um den Banken eine Einnahmequelle zu ermöglichen. Doch den Phantasien hinsichtlich der Einnahmequellen, von denen es im aktuellen API-Hype viele gibt, sind keine Grenzen gesetzt.

Wir reiten also für den Moment die Hype-Welle mit und stellen uns die XS2A-API als alternativen Zugangskanal für Firmen vor. Warum nicht. Aus technischer Sicht sollten die Hürden gering sein. Eine Firma könnte sich wie ein Drittdienstanbieter durch ein eIDAS-Zertifikat ausweisen. Das Zertifikat würde sich nur in den spezifischen Feldern für Drittdienstanbieter unterscheiden. Ähnlich zu EBICS können eingereichte Aufträge oder Anfragen mit einer Signatur versehen werden, an Hand derer der Empfänger die Unversehrtheit der Nachricht prüfen kann. Die Sicherheit auf dem Transportweg wird durch die Verwendung von TLS gewährleistet.

Aus fachlicher Sicht können mit Hilfe des Use Cases „Zahlung initiieren“ sowohl Einzel- als auch Sammelzahlungen ausgeführt werden. Für die Freigabe werden den Verbrauchern die gängigen Autorisierungsverfahren aus dem Online-Banking angeboten (z. B. photoTAN, pushTAN). Für Firmen wäre das wahrscheinlich ungeeignet, sodass eher Corporate Seals zum Einsatz kommen würden, was zu spezifizieren ist. Ebenso die Abfrage von Kontoinformationen (Salden, Transaktionen, Details) ist über die XS2A-API möglich. Die dafür erforderliche Einwilligung (consent) könnte in diesem speziellen Fall, wo zwischen Firma und Bank ein Vertrauensverhältnis besteht, durch eine dauerhaft gültige Einwilligung gelöst werden.

Aus der mittleren Flughöhe gesehen wäre die XS2A-API also eine valide Alternative, die auch bereits in verschiedenen Foren angedacht wird. Hier wird die Idee mit Attributen wie „günstiger, bequemer, echtzeitfähig sowie flexibler bei Anpassungen“ belegt. Jedoch holt uns der Status quo auf den Boden der Tatsachen zurück. Die prägende Spezifikation, die der Berlin Group, lässt den Banken viele Freiräume, die API zu implementieren. In der Bestrebung, alle Banken in Europa über XS2A zu erreichen, stellen diese Freiräume für alle Marktteilnehmer aktuell eine Herausforderung dar. Ein Zustand, der für Firmen nicht einladend ist, noch nicht. Jedoch ist der Grundstein für eine Alternative gelegt.


Autor: Christian Wenz