Solaris: „Open Banking war die Blaupause, Embedded Finance ist die Mutation“

Schwerpunkt: Tech-Ökosysteme

Millionen flossen in PSD2-Schnitt­stellen, verdient haben andere. Embedded Finance hat Open Banking technisch abgehängt: ein API-Key statt wochenlanger Zertifizierung pro Bank. Die Bank liefert Lizenz und Bilanz und haftet für alles, auch unter DORA. Die Frage ist nicht, ob sie mitspielt, sondern zu welchem Preis.

von Peter Hüftlein, Head of Product – Accounts, Solaris

Technischer und strategischer Vergleich zwischen PSD2-Schnittstellen und proprietären BaaS-APIs. Standardi­sierungs­defizite. Auslagerungsrisiken. Das Dilemma der Banken: Als im September 2019 die technischen Regulierungsstandards (RTS) zur starken Kundenauthentifizierung (SCA) unter der zweiten europäischen Zahlungs­dienste­richt­linie (PSD2) vollständig anwendbar wurden, war die regulatorische Grundlage für Open Banking bereits seit Januar 2018 gelegt.

Die Verpflichtung zur Bereitstellung von Access-to-Account-Schnittstellen (XS2A) für Drittanbieter (TPPs) sollte den europäischen Bankensektor aufbrechen. In den Vorstandsetagen etablierter Institute dominierte die Sorge vor dem Verlust der Kundenschnittstelle. Es folgten millionenschwere Investitionen in regulatorisch erzwungene APIs.

XS2A: Rückblickend erwies sich diese Initiative für die meisten Banken als IT-Kostenfaktor ohne spürbaren Deckungsbeitrag. Viel Open. Wenig Banking.“

Die Blaupause für den Datenaustausch wurde geschaffen. Die tatsächliche kommerzielle Wertschöpfung fand jedoch andernorts statt. Embedded Finance ist die funktionale Mutation von Open Banking. Unkontrolliert. Adaptiv. Marktgetrieben.

Während Open Banking primär auf einen passiven und stark reglementierten Datenlesezugriff und isolierte Zahlungsauslösungen beschränkt blieb, integriert Embedded Finance vollwertige Bilanz- und Transaktionsprodukte direkt in die Wertschöpfungsketten finanzfremder B2B-Plattformen. Von Konten und Firmenkreditkarten bis hin zu revolvierenden Kreditlinien. Der technologische Motor dieser Evolution sind nicht die starren PSD2-Schnittstellen der Hausbanken, sondern hochgradig modulare proprietäre Banking-as-a-Service-APIs (BaaS-APIs).

Technischer Vergleich: Regulierte PSD2 vs. proprietäre BaaS-Infrastruktur

Die strukturellen Unterschiede zwischen den Ansätzen verdeutlichen, warum sich die Marktanteile zugunsten proprietärer Architekturen verschoben haben.

Schnittstellen-Architektur und Datenmodelle: PSD2-Schnittstellen basieren auf fragmentierten Implementierungen konkurrierender Spezifikationen. Die Berlin Group (NextGenPSD2) und STET in Frankreich und das UK Open Banking Framework haben jeweils eigene Standards etabliert. Mit unterschiedlichen Datenmodellen, Authentifizierungsflows und Consent-Management-Ansätzen. Allein in der EU existieren über 4.000 XS2A-Schnittstellen, die trotz nominaler Standardisierung starke Implemen­tierungs­unter­schiede aufweisen.

Aus Sicht vieler Integratoren blieb der reale Nutzen der Standardisierung hinter den Erwartungen zurück, was in vielen Unternehmen zu spürbarer Unzufriedenheit führte.“

OAuth 2.0 mit eIDAS-Zertifikaten bildet zwar das gemeinsame Authentifizierungsgerüst, doch die konkreten Redirect- und Decoupled-Flows variieren je Institut erheblich.

Proprietäre BaaS-APIs setzen dagegen auf konsistente REST- oder GraphQL-Architekturen mit einheitlichen Datenmodellen. Webhooks und ereignisgesteuerte Microservices ersetzen das Polling-Paradigma der XS2A-Welt. Die Integration in Enterprise-Software (ERP-Systeme und Procurement-Plattformen und vertikale SaaS) erfolgt über dokumentierte SDKs mit Sandbox-Umgebungen, die produktionsnahe Testszenarien abbilden. Wo PSD2-Implementierungen oft wochenlange Zertifizierungsprozesse mit jedem einzelnen ASPSP erfordern, genügt bei BaaS-Anbietern typischerweise ein einziger API-Key. Im wahrsten Sinne ein Schlüsselerlebnis.

Funktionsumfang und Prozesstiefe: Die PSD2 deckt im Kern lediglich bestehende Zahlungskonten und rudimentäre Umsatzdaten ab, wie AIS (Account Information Service) und PIS (Payment Initiation Service). Moderne BaaS- und Financial-Platform-APIs bilden hingegen vollständige Bankprozesse von Anfang bis Ende ab. Von automatisierten KYC- und KYB-Strecken (inklusive Video-Ident, PEP/Sanktionsscreening und UBO-Ermittlung), über die Realtime-Kartenemission (Push Provisioning auf Apple/Google Wallets binnen Sekunden) bis hin zur dynamischen Bonitätsprüfung direkt am Point of Sale.

Conversion und User Experience: PSD2-Prozesse leiten Nutzer fast immer zur externen Authentifizierung an ihre Hausbank weiter. Diese Redirect-Flows erzeugen Kontextwechsel, die je nach Institut und Endgerät zu Abbruchraten von 30 bis 50 Prozent führen. Das digitale Äquivalent eines Bankschalterbesuchs, nur ohne kostenlosen Kaffee. BaaS ermöglicht dagegen eine unsichtbare und native Einbettung. Die Transaktion findet dort statt, wo der geschäftliche Kontext entsteht. Im ERP. Auf der Plattform. Im Checkout.

Margendruck. Erlösmodelle. Auslagerungshaftung.

Für Banken, die über BaaS-APIs Finanzprodukte in Plattformen einbetten, ergibt sich ein differenziertes ökonomisches Bild, wenn sie zusätzlich API-basierte Services anbieten.

Verlust des Kundenzugangs und Margenerosion: Banken laufen Gefahr, zum reinen Risikoträger und Commodity-Lieferanten degradiert zu werden. Während Plattformen und vertikale SaaS-Anbieter durch exzellente Schnittstellen die profitablen Kundenbeziehungen monetarisieren, verbleiben bei der Bank oft nur schmale Transaktionsmargen. Bei voller Bilanzbelastung. Die konkreten Revenue-Modelle im BaaS-Ökosystem unterscheiden sich dabei erheblich. Interchange-Sharing bei Kartenprogrammen. Per-Transaction-Fees bei Zahlungsauslösungen.

Wiederkehrende SaaS-Plattformgebühren für API-Zugang und Infrastruktur. Oder Balance-Sheet-Rental, bei dem die Bilanz des lizenzgebenden Instituts gegen eine Risikoprämie genutzt wird. Bilanzvermietung, sozusagen Airbnb für Banklizenzen. Für die produzierende Bank stellt sich die zentrale Frage, welchen Anteil der Gesamtwertschöpfung sie in jedem dieser Modelle tatsächlich vereinnahmt und ob dieser Anteil das regulatorische Risiko rechtfertigt.

Regulatorische Durchgriffshaftung und DORA: Im Software-Engineering lässt sich die Infrastruktur leicht über SDKs einkaufen. Im Bankgeschäft lässt sich die regulatorische Verantwortung nicht outsourcen. Das lizenzgebende Institut ist voll haftbar für Geldwäsche-Prävention (GwG) und Betrugserkennung und operationelle Resilienz. Wenn BaaS-Partner oder technische Enabler Sorgfaltspflichten bei KYC- oder Transaktionsprüfungen vernachlässigen, greift die Aufsicht unmittelbar bei der Bank durch. Diverse Sonderprüfungen und Maßnahmen der Bafin im europäischen Fintech-Sektor haben das eindrücklich belegt.

Verschärfend kommt seit Januar 2025 der Digital Operational Resilience Act (DORA) hinzu. Trotz der Einprägsamkeit des Namens setzt die Verordnung extrem hohe Maßstäbe an die operative IT-Resilienz und fordert Banken und andere Finanzdienstleister heraus. DORA etabliert verbindliche Anforderungen an das ICT-Dritt­parteien­risiko­management und die Überwachung kritischer IKT-Dienstleister.

Für BaaS-Konstellationen ist das hochrelevant. Wenn der technische Enabler als kritischer Drittdienstleister eingestuft wird, unterliegt er einer direkten, aufsichtlichen Überwachung durch die ESAs. Die Bank muss detaillierte Register aller Vertragsbeziehungen führen und Exit-Strategien vorhalten und regelmäßige Penetration-Tests nachweisen. Das BaaS-Modell wird dadurch nicht unmöglich. Aber die Governance-Anforderungen steigen signifikant.

Risiko im Banking ist eine Frage der Infrastruktur: Die Marktentwicklung der letzten Jahre hat gezeigt, dass das BaaS-Modell fragil sein kann. Der Wirecard-Kollaps und eine Serie von Bafin-Sonderprüfungen bei BaaS-Enablern sind allen noch im Gedächtnis. Das hat offengelegt, was passiert, wenn Compliance nicht im Kern der Architektur verankert ist, sondern als nachgelagerter Layer behandelt wird. Für die lizenzgebende Bank materialisiert sich das Risiko in jedem Fall. Reputationsschäden und aufsichtliche Maßnahmen und im Extremfall der Entzug der Lizenz treffen nicht den Distributor, sondern den Risikoträger.

PSD3. PSR. FIDA. Die Zukunft der Plattform-Banken.

Die europäische Bankenaufsicht hat das Scheitern der PSD2-Standardisierung erkannt. Mit dem Entwurf zur PSD3 und der Zahlungs­dienste­verordnung (PSR) und dem FIDA-Framework (Financial Data Access) versucht die EU, die Grundlagen für echtes Open Finance zu schaffen.

Der regulierungstechnisch relevante Unterschied: Die Aufspaltung in PSD3 (Richtlinie mit nationaler Umsetzungspflicht) und PSR (Verordnung mit direkter Anwendbarkeit in allen Mitgliedstaaten) ist ein bewusster Schritt zur Vermeidung der Fragmentierung, die PSD2 so massiv geschwächt hat. Aufgrund von PSR müssen die EU-Mitgliedstaaten einheitliche Regeln für Zahlungsdienste direkt und ohne Spielräume umsetzen. FIDA wiederum zielt auf standardisierte Datenzugänge jenseits des Zahlungsverkehrs wie Wertpapierdepots, Kreditverträge, Versicherungspolicen und Pensionsansprüche.

Für die Architektur des europäischen Finanzmarktes ist die Lage jedoch eindeutig. Während der Gesetzgeber noch über technische Standards für FIDA berät, hat der Markt durch proprietäre BaaS-Infrastrukturen längst Fakten geschaffen.

Erfolgreiche Banken werden künftig eine von zwei Rollen einnehmen müssen. Entweder akzeptieren sie ihre Rolle als hochgradig automatisierte Produktfabrik, die Skaleneffekte über standardisierte API-Kanäle erzielt und regulatorische Governance als Kernkompetenz begreift. Oder sie transformieren ihre eigenen Frontends zu Plattformen, die fremde Finanz- und Softwarebausteine modular integrieren.

Das Standardisierungsdefizit von Embedded Finance wird letztlich nicht durch verspätete Regulierungsinitiativen gelöst werden, sondern durch den Markterfolg jener Akteure, die offene Plattformarchitekturen mit banktauglicher Compliance und lückenloser Auditierbarkeit verbinden. Denn die entscheidende Lektion aus der bisherigen BaaS-Marktbereinigung lautet: technische Skalierbarkeit ohne regulatorische Substanz ist kein nachhaltiges Geschäftsmodell. Nicht für den Enabler. Nicht für die Bank. Ob diese Mutation am Ende gutartig oder bösartig ausfällt, entscheidet die Compliance-DNA. Peter Hüftlein, Solaris/dk