Wie Banken ihre PSD2-Schnittstellen monetarisieren

Immer häufiger finden Studien heraus, dass Open Banking noch in den Kinderschuhen steckt, nicht vom Fleck kommt und dass sich die Banken dadurch einiges an Einnahmen entgehen lassen. Manchmal sind auch die Kunden schuld, weil sie ihre Finanzdaten viel seltener mit anderen teilen möchten als gedacht. Das dürfte sich ändern, wenn die erste wirklich neue Idee kommt – und damit sie kommt, müssen sich die Institute auf eine neue Zielgruppe einstellen: Software-Entwickler.

von Kay Wossidlo und Michael Reikersdorfer, Senacor

Entwickler entscheiden künftig mit darüber, ob eine Idee aufgeht oder nicht. Je leichter die Banken es den Entwicklern machen, und zwar auch denen aus anderen Unternehmen, desto schneller wird es ihnen gelingen, Plattformen aufzubauen und zu betreiben. So sind die ersten Bezahldienste groß geworden.

Stripe lässt sich beispielsweise mit nur sieben Zeilen Code in eine Webseite integrieren.”

Die Maxime: Nicht an Unternehmen verkaufen, sondern an deren Entwickler. Einen ähnlichen Weg hat die Deutsche Bank eingeschlagen und ein Portal ins Leben gerufen, das sich direkt an diese Zielgruppe wendet.

Entwickler als Kunden

Hinter dem Portal steckt eine einfache Logik: Wenn Banken fremde Dienste integrieren oder eigene Dienste anderen anbieten wollen, müssen die dafür notwendigen Schnittstellen (API), über die später die Daten hin und her fließen, möglichst leicht zu handhaben sein. Drei Regeln haben sich bewährt, um dieses Ziel zu erreichen:

1. Entwickler wie Kunden behandeln: Wer eine Plattform für Entwickler aufbauen und betreiben möchte, muss sich um seine neue Community kümmern. Das heißt, schnell auf Rückmeldungen antworten, Ratschläge annehmen und aktiv nachfragen. Statt um eine gute Customer Experience geht es jetzt um eine gute Developer Experience.
2. Dokumentieren, dokumentieren, dokumentieren: Entwickler wollen entwickeln und das geht am besten, wenn sie schnell finden, wonach sie suchen. Vollständig und eingängig beschriebene APIs helfen dabei. Darum gilt, so viel wie möglich und so einfach wie möglich erklären, was eine API tut und wie sie sich nutzen lässt.
3. Eine Sandbox bereitstellen: Entwickeln heißt häufig auch ausprobieren. Das kann die Bank unterstützen, indem sie ihre APIs in einer Sandbox zugänglich macht und das ohne große Hürden. Wer wissen möchte, ob die gebotene API auch wirklich das tut, was sie soll, möchte schnell testen und nicht erst hunderte Formulare ausfüllen.

Wenn es darum geht, mehr als nur einen Dienst anzubinden, fällt der Sandbox zudem eine wichtige Rolle zu. Open Banking bedeutet ja auch, mehr mit den Daten zu machen, über die Banken heute verfügen. Aus diesen Daten lassen sich völlig neue Angebote entwickeln, in einem besonders einfachen Fall beispielsweise eine App mit künstlicher Intelligenz, die alle Ausgaben etwa nach Abos oder Freizeit sortiert. Dafür reichen APIs, die etwa den PSD2-konformen Kontozugriff erlauben, kaum aus. Ein Anbieter, der so eine App entwickeln möchte, ist vielmehr auf vernünftige Testdaten angewiesen. Wegen Regel 1 sollte die Bank solche Daten in hoher Qualität also ebenfalls in der Sandbox bereitstellen.

Von PSD2 zu Open Banking

Warum aber sollten die Institute ihre Geheimnisse lüften und andere Anbieter auf ihre Daten und IT-Systeme zugreifen lassen? Vielen Instituten fällt das schwer, weil es doch viel besser wäre, wenn Kunden auf die eigene Plattform kommen, statt die von anderen zu nutzen. APIs oder – wenn die Kunden einverstanden sind – den Zugriff auf Finanzdaten zu verkaufen, gehört schließlich nicht zum Geschäftsmodell. Darum war jeder extern eingerichtete Zugang ein eigenes IT-Projekt, etwa um direkt am Point of Sale im Handel Kredite anzubieten. Was früher individuell gemacht wurde, lässt sich in der API-Welt generisch abbilden, so dass Unternehmen sich die von ihnen gewünschten Dienste quasi selbst zusammenstecken können.

Der Bank eröffnen sich auf diese Weise sehr leicht neue Vertriebswege, die sich zudem fast von alleine skalieren. Jedes neue FinTech und jedes neue Start-Up erhöht die eigene Reichweite. Dabei können die Banken mit dem weitermachen, was sie sich mit ihren PSD2-Schnittstellen bereits mühsam erarbeitet haben. Auch heute noch nehmen viele Institute PSD2 als notwendige Pflichtübung war. Laut der „Digital Outlook 2025“-Studie von Lünendonk (hier herunterladen) steht die Regulatorik mit 93 Prozent immer noch an erster Stelle der aktuellen Herausforderungen, mit denen sich die Banken konfrontiert sehen. Beispiel PSD2: Plötzlich durften Drittanbieter Zahlungen auf den Konten von Bankkunden auslösen, weshalb die Institute ihre Zahlungsverkehrsprozesse von außen zugänglich machen mussten.

Doch das war noch nicht alles. Weil die Sicherheit nicht zu kurz kommen durfte, mussten die Institute außerdem dafür sorgen, dass nur zertifizierte Drittanbieter zugreifen und dafür, wenn sie es richtig machen wollten, eine API-Management-Software anschaffen. Hinzu kamen die vom Gesetzgeber geforderten Hilfe-Hotlines, falls die technische Schnittstelle streikt. Anders ausgedrückt:

PSD2 stellt bezogen auf den Zahlungsverkehr eine Blaupause für Open Banking dar – und zwar im Sinne von Partnerschaften auf Augenhöhe.”

Die gesetzlich vorgeschriebene PSD2-Schnittstelle muss sich dafür zu einer neuen Produktgattung für die Banken entwickeln, die sich monetarisieren lässt und aus der weitere APIs entstehen (vgl. Abb. 1).

Wege zum Geld

Wer APIs entwickelt und vermarktet, wandelt sich von einer reinen Produktbank zu einem API-Provider, der – anders als der API-Consumer, der die APIs von API-Providern nutzt – das mit PSD2 eingeübte Verfahren ständig wiederholt und neue Schnittstellen veröffentlicht, damit andere sie nutzen können. 34 Prozent der Institute planen, diese Strategie bis 2025 zu verfolgen. Die entscheidende Frage lautet dann: wie und woran verdient die Bank? Insgesamt ergeben sich vereinfacht dargestellt vier Wege zum Geld:

1. Indirektes Retailgeschäft: Weil wohl weder Verbraucher noch Drittanbieter für den API-Aufruf bezahlen wollen, verdient die Bank eher indirekt, indem sie Drittanbieter eigene Produkte verkaufen lässt. Beispiel: Eine digitale Antragsstrecke für Kredite, die in einem Onlineshop eingebunden ist.
2. Direktes Retailgeschäft: Verbraucher nutzen in diesem Modell einen von der Bank bereitgestellten Dienst, der in einem anderen Produkt steckt, etwa eine Freigabe über eine eingebundene Signierungs-API. Wegen der B2B2C-Konstellation kommt möglicherweise ein Aggregator ins Spiel.
3. Indirektes Firmenkundengeschäft: Firmenkunden nutzen einen Dienst, der das von der Bank entwickelte Angebot enthält. Die Abrechnung erfolgt beispielsweise über die Kontoführungsgebühr.
4. Direktes Firmenkundengeschäft: Firmenkunden binden über eine API einen von ihrer Bank bereitgestellten Dienst in die eigenen IT-Systeme ein. Das passiert heute häufig bereits im Cash Management, um Kontobewegungen möglichst automatisiert abzugleichen.

Welche dieser Varianten sich für eine Bank eignen, hängt auch davon ab, ob sich die via API bereitgestellten Angebote um ein Produkt oder den Kunden selbst drehen. Nahe am Produkt orientierte Dienste, die etwa mit Zahlungsverkehr, Wertpapierhandel oder Krediten verbunden sind, eignen sich vor allem für den Weiterverkauf durch Dritte, also als Zusatzprodukt, das die Partner ergänzend in ihre Ökosysteme einbauen. Kundengezogene Dienste, wie Rating, KYC-Prozesse oder Signierungen, eignen sich, um von Drittanbietern entwickelte Dienste erst zu ermöglichen oder so stark aufzuwerten, dass Verbraucher darin einen Mehrwert sehen.

API-Management-Plattformen bauen

Strategisch bedeutet das, eine Plattform aufzubauen mit Diensten, die andere für ihre eigenen Angebote nutzen möchten. Das Produkt sind die API beziehungsweise das SDK (Software Development Kit), mit denen sich einzelne Funktionen wie eine Kontoabfrage oder komplette API-Bündel abrufen lassen. Daran schließt sich die Frage an, wer bezahlt: ein Partner für die API oder das DSK – oder ein Kunde, der das vermittelte Produkt nutzt. Als besonders lukrativ gelten Dienste für Firmenkunden. Das zeichnet sich bereits im Zahlungsverkehr ab, lässt sich aber auf alles übertragen, was die IT-Abläufe dieser Kunden verbessert und dadurch einen Mehrwert verspricht. Banken müssen sich deshalb darum kümmern, noch besser als bisher die Geschäftsmodelle und Abläufe ihrer Kunden zu verstehen, um zu punkten.

Ein wesentlicher Knackpunkt dabei stellt die Due Diligence beim Onboarding neuer Third Party Provider dar, die das API-Portal nutzen möchten. Von der Sandbox bis zum Produkt darf es nicht zu lange dauern, damit eine Bank als API-Provider attraktiv für API-Consumer bleibt.

Effizient zu entwickeln und agil zu liefern, müssen viele Banken erst noch lernen, da die bisherigen Strukturen häufig noch anders arbeiten.”

Das gilt auch für die Compliance, die gerade Startups oder FinTechs, die eine Bank als API-Kunde gewinnen möchte, mit einem auf Konzerne abgestellten Regelwerk eher abschreckt. Komfortabel und schnell sollte das laufen, im Zweifel auch durch das eine oder andere geschäftliche Risiko mehr für die Bank.

Technisch gilt es, eine API-Management-Plattform aufzubauen, die zwischen der Bank-IT und den Drittanbietern makelt (vgl. Abb. 2) und aus einzelnen Modulen besteht (SCS, Self-Contained Systems). API Store und API Consumer Management verwalten beispielsweise die Abonnements und Verträge sowie die Authentifizierung von Drittanbietern. Gateways routen die API-Aufrufe und validieren Drittanbieter. Eine Service Registry meldet zur Laufzeit neue Microservices an, die verschiedene Aufgaben wahrnehmen. Rollen und Rechte für interne Nutzer verwaltet das Repository Access Management. Ein API Repository erlaubt, APIs zu modellieren und zu veröffentlichen, während der Manager API Produkte definiert und das API-Staging übernimmt, also vom Entwicklungsstatus in Produktion gibt. Billing ist klar.

Agil und interdisziplinär

Was auf den ersten Blick wie eine „simple“ IT-Fingerübung aussieht, wirkt sich auch auf die Organisation als solche aus. Künftig arbeiten interdisziplinäre Teams agil zusammen, die für ihre jeweiligen Anwendungsfälle APIs entwickeln.

Ähnlich wie in der Software-Entwicklung gilt dabei: fail fast, fail cheap. Je mehr Raum die Kollegen bekommen, um ihre Ideen zu testen, desto eher kommt etwas dabei heraus, das sich weiterzuverfolgen lohnt.”

Abseits von Konzernstrukturen selbst einen Third Party Provider auszugründen und so zu lernen, wie sich agil Produkte entwickeln lassen, kann sich ebenfalls auszahlen.Kay Wossidlo und Michael Reikersdorfer, Senacor