Banking as a Service erklärt: Warum die Compliance- und Ledger-Verantwortung nicht dort liegt, wo Marken sie erwarten

Banking as a Service ist ein Modell, bei dem eine lizenzierte Bank ihre regulierten Funktionen, Einlagenkonten, Kartenausgabe und Zahlungsdienste einer Nichtbank-Marke über APIs zur Verfügung stellt, sodass die Marke Finanzprodukte anbieten kann, ohne selbst über eine Banklizenz zu verfügen. Die Vorteile sind für beide Seiten offensichtlich. Die Marke erschließt eine zusätzliche Einnahmequelle und schafft einen Grund für Kunden, innerhalb ihres Produkts zu bleiben. Die Bank gewinnt Einlagen und Interchange-Einnahmen, ohne eine eigene Funktion zur Kundengewinnung aufbauen zu müssen. Was beide Seiten zu Beginn häufig nicht richtig einkalkulieren, ist die Frage, wer den Ledger führt, wer ihn abstimmt und wer gegenüber einer Aufsichtsbehörde verantwortlich ist, wenn die Daten nicht übereinstimmen. Diese Frage hat sich von einem Vertragsdetail zu einem zentralen Bestandteil des Modells entwickelt.

Wichtige Highlights:

• Marken betrachten Banking as a Service häufig als einfaches Integrationsprojekt und planen Budgets für APIs und Kartenausgabe ein, anstatt die tatsächlichen Anforderungen einer Sponsorbank zu berücksichtigen.
• Diese Lücke wird häufig erst spät sichtbar: Ledger-Abstimmung, Anforderungen an Audit-Trails und Compliance-Verpflichtungen, von denen angenommen wurde, dass sie bei der Bank liegen, müssen letztlich von der Marke selbst umgesetzt und nachweisbar erfüllt werden.
• Definieren Sie die Ledger-Verantwortung und den Abstimmungsrhythmus, bevor Sie eine Sponsorbank auswählen, und gestalten Sie den Audit-Trail so, dass er die Fragen einer Aufsichtsbehörde und nicht nur interne Anforderungen beantwortet. Das Ergebnis ist ein Programm, das der Prüfung durch eine Sponsorbank standhält und später eine zweite Bank integrieren kann, ohne den Ledger neu aufbauen zu müssen.
• Sigma entwickelt Lösungen auf beiden Seiten dieses Technologie-Stacks – von der Core- und Sponsorbank-API-Integration bis zum kundenorientierten Onboarding – und betrachtet das Design der Abstimmungsprozesse als erstes Projektergebnis und nicht als spätere Phase.

Was ist Banking as a Service?

Banking as a Service trennt die regulierte Funktion von der Kundenbeziehung. Drei Parteien sind beteiligt, und Unklarheit darüber, welche Partei welche Verpflichtung trägt, ist eine der häufigsten Ursachen für das Scheitern solcher Programme.

Tabelle 1: Wer übernimmt welche Aufgaben in einem BaaS-Stack?

Entscheidend in dieser Tabelle ist die Vorgabe für die Sponsorbank. Eine Aufsichtsbehörde unterscheidet nicht zwischen Tätigkeiten, die von der Bank selbst durchgeführt wurden, und solchen, die ein Partner unter ihrer Banklizenz ausgeführt hat. Genau das erklärt, warum die Due-Diligence-Prüfung durch Sponsorbanken umfangreicher ist, als Marken erwarten, und warum die Anforderungen seit 2024 weiter gestiegen sind.

Wie unterscheidet sich BaaS von Open Banking und Embedded Finance?

Die drei Begriffe überschneiden sich, sind jedoch nicht austauschbar. Bei Banking as a Service nutzt eine Marke die Banklizenz einer Bank, um regulierte Produkte anzubieten. Open Banking ermöglicht autorisierten Zugriff auf bei einer Bank gespeicherte Daten, sodass ein Drittanbieter Kontoinformationen abrufen oder Zahlungen initiieren kann, ohne selbst ein Bankprodukt anzubieten. Embedded Finance beschreibt dagegen eher das kommerzielle Ergebnis als den zugrunde liegenden Mechanismus: Ein Finanzprodukt wird in ein nichtfinanzielles Kundenerlebnis integriert und kann über Banking as a Service, eine Kreditpartnerschaft oder Open-Banking-Infrastrukturen bereitgestellt werden.

Eine praktische Möglichkeit zur Unterscheidung besteht darin, zu fragen, wo sich das Geld des Kunden befindet. Bei Banking as a Serviceliegt es bei der Sponsorbank in einer Kontostruktur, über die die Marke keine Kontrolle hat. Bei Open Bankingbleibt es dort, wo es sich bereits befindet. Bei Embedded Finance hängt die Antwort vollständig davon ab, welcher zugrunde liegende Mechanismus verwendet wird. Deshalb ist der Begriff aus kommerzieller Sicht hilfreich, aus architektonischer Sicht jedoch wenig aussagekräftig.

Wo liegt die Compliance-Verantwortung tatsächlich?

Auf dem Papier liegt diese Verantwortung bei der Sponsorbank. In der Praxis übernehmen jedoch die Plattform und die Marke einen Großteil der Arbeit. Genau dieses Missverhältnis versuchen die Aufsichtsbehörden seit einigen Jahren zu beheben.

Der entscheidende Weckruf kam durch einen realen Ausfall. Ein Middleware-Anbieter, der FinTech-Unternehmen die Integration von Bankdienstleistungen in ihre Anwendungen ermöglichte, brach 2024 zusammen. In diesem Modell hatten die FinTech-Unternehmen die Benutzeroberflächen entwickelt und eigene Ledger geführt, in denen die Guthaben der einzelnen Kunden erfasst wurden. Als eine der Partnerbanken die bei ihr liegenden Einlagen einfror, konnten Kunden nicht mehr auf ihr Geld zugreifen, weil die Aufzeichnungen darüber, wem welches Geld tatsächlich gehörte, vollständig außerhalb der Bank geführt wurden.

Die Aufsichtsbehörden reagierten darauf. Eine US-Bankenaufsichtsbehörde schlug neue Regeln vor, nach denen Banken mit gebündelten Treuhandkonten klare und präzise Aufzeichnungen darüber führen müssen, wem welche Gelder innerhalb dieser Konten gehören – bis hin zum individuellen Saldo. Nach dem Vorschlag müsste die oberste Führungsebene einer Bank jährlich persönlich bestätigen, dass diese Aufzeichnungen ordnungsgemäß funktionieren, und darüber Bericht erstatten. Die Regel befindet sich weiterhin im Konsultationsverfahren.

Für Unternehmen, die ein solches Programm aufbauen, sind zwei Punkte entscheidend. Erstens ist die Regel noch nicht endgültig. Die Architektur sollte daher nicht auf konkrete Dokumentationsanforderungen, sondern auf das zugrunde liegende Prinzip ausgerichtet werden. Zweitens wird dieses Prinzip unabhängig vom endgültigen Ausgang der Regel bestehen bleiben: Sponsorbanken werden weiterhin verlangen, Eigentumsverhältnisse selbst überprüfen zu können, anstatt darauf zu vertrauen, dass der Ledger eines Partners vollständig und korrekt ist.

Die Annahme, an der BaaS-Programme scheitern – und was sie ersetzen sollte

Die Annahme lautet, dass die Sponsorbank den Ledger führt. In der Regel ist das jedoch nicht der Fall. Bei den meisten Programmstrukturen führt die Bank ein gebündeltes Treuhandkonto, während die Plattform oder Marke den Sub-Ledger mit den individuellen Salden verwaltet. Teams erkennen dies häufig erst spät, typischerweise während der Due-Diligence-Prüfung durch die Sponsorbank. Zu diesem Zeitpunkt wurde der Ledger jedoch oft bereits als Anwendungsfunktion und nicht als System of Record entwickelt.

Dieser Unterschied ist keineswegs rein theoretisch. Ein als Anwendungsfunktion entwickelter Ledger aktualisiert Salden. Ein als System of Record konzipierter Ledger schreibt unveränderliche Einträge, sodass jeder Saldo zu jedem früheren Zeitpunkt rekonstruiert und nachvollziehbar erklärt werden kann. Die erste Variante ist einfacher und funktioniert, bis jemand wissen möchte, welchen Saldo ein Kunde an einem bestimmten Datum hatte und warum. Nur die zweite Variante hält einer regulatorischen Prüfung oder einer Insolvenz stand.

Sigmas Projekte in diesem Bereich beginnen daher mit dem Design der Abstimmungsprozesse statt mit der API-Integration, und diese Reihenfolge ist bewusst gewählt. Die erste Frage lautet, welches System für jeden Saldotyp als maßgebliche Datenquelle dient und was geschieht, wenn die Position der Bank und der Sub-Ledger der Plattform voneinander abweichen. In jedem Programm treten Differenzen auf. Entscheidend ist, ob diese automatisch zusammen mit einem Aging-Report erkannt werden oder erst beim Monatsabschluss auffallen, wenn jemand Tabellen manuell miteinander vergleicht. Wird dieser Ausnahmeprozess zuerst konzipiert, bestimmt er die Anforderungen an alle nachfolgenden Komponenten. Deshalb lässt er sich später nicht kostengünstig nachrüsten.

Lesen Sie unsere Erfolgsgeschichte: Skalierung der Kreditverarbeitung und Förderung des Wachstums durch eine Microservices-Architektur

Der zweite Arbeitsbereich ist die Sponsorbank API-Integration, wobei die größte Herausforderung selten in der technischen Komplexität liegt. Vielmehr arbeiten Bank-APIs häufig batchbasiert, während das Produkt der Marke in Echtzeit funktioniert. Die Plattformebene muss daher eine konsistente Sicht über zwei Systeme gewährleisten, die mit unterschiedlichen Verarbeitungszyklen arbeiten. Sigmas Arbeit in diesem Bereich steht in engem Zusammenhang mit der Integrationsorchestrierung, die das Unternehmen auch außerhalb von BaaS umgesetzt hat. Bei einem Projekt für einen US-amerikanischen Anbieter von Kundenfinanzierungen mit einem Netzwerk von mehr als 7.500 Händlern entwickelte und erweiterte Sigma ein Händlerportal, das Integrationen mit Transunion, Experian, Spectrum, FSSI, Rubex, Lyons Commercial Data und mehreren Zahlungsanbietern erforderte. Gleichzeitig wurde eine schrittweise Migration von einer monolithischen Architektur zu Microservices durchgeführt, ohne den laufenden Betrieb zu unterbrechen. Besonders relevant für BaaS ist dabei die schrittweise Migration unter Live-Traffic, da ein bereits gestartetes BaaS-Programm nicht einfach pausiert werden kann, um die Architektur neu aufzubauen.

Erfahren Sie, wie eine Händlerfinanzierungsplattform ohne Unterbrechung des laufenden Betriebs auf Microservices migriert wurde.

Der dritte Arbeitsbereich umfasst Onboarding und Identitätsmanagement. Sigmas BaaS- und Neobank-Enablement umfasst die API-basierte Ausgabe von Debit-, Kredit- und virtuellen Karten mit Ausgabenkontrollen und PCI-konformer Integration von Zahlungsinfrastrukturen sowie KYC die Integration von Anti-Money-Laundering-Prozessen mit automatisierter Identitätsprüfung, globalem Watchlist- und Sanktionsscreening sowie Risikobewertung von Transaktionen. Dies sind die Komponenten, nach denen eine Sponsorbank direkt fragt, und sie erwartet dafür belastbare Nachweise statt lediglich beschreibender Antworten.

Das Servicing ist der Bereich, den die meisten Programme unterschätzen. Eröffnete Konten müssen dauerhaft betreut werden, und dabei entstehen Reklamationen, Anpassungen und Korrekturen, die einen Ledger deutlich stärker beanspruchen als die eigentliche Kontoeröffnung.

Was während des gesamten Prozesses bei der Bank verbleibt, ist das Compliance-Programm selbst: die Risikobereitschaft, die Entscheidung über die Aufnahme eines Partners und die Beziehung zur Aufsichtsbehörde. Sigma entwickelt die Systeme, die die für diese Entscheidungen erforderlichen Nachweise liefern. Die Verwechslung dieser Verantwortlichkeiten ist eine der häufigsten Ursachen für einen falsch definierten Projektumfang in diesem Bereich.

Sollten Sie selbst entwickeln oder mit einem Partner zusammenarbeiten?

Entscheidend ist, ob Finanzdienstleistungen eine eigene Produktlinie oder lediglich eine Funktion darstellen sollen. Eine Marke, die ein einzelnes Kartenprodukt zur Steigerung der Kundenbindung einführt, sollte mit einer etablierten Plattform zusammenarbeiten und deren Rahmenbedingungen akzeptieren.

A company whose economics depend on the financial product, where interchange or net interest income is a primary revenue line, will eventually need control of the ledger and should plan for that from the outset rather than migrating later under duress.

Fazit

Banking as a Service funktioniert durch die Trennung der regulierten Funktion von der Kundenbeziehung. Eine Sponsorbank hält die Banklizenz und die Einlagen, eine Plattformebene stellt APIs und den Ledger bereit und die Marke verantwortet die Kundenbeziehung und die Benutzeroberfläche. Unklarheit darüber, welche Partei welche Verpflichtung trägt, ist eine der häufigsten Ursachen für das Scheitern solcher Programme. Dabei sind die Vorgaben der Sponsorbank entscheidend, da ihre Aufsichtsbehörde nicht zwischen Tätigkeiten unterscheidet, die die Bank selbst ausgeführt hat, und solchen, die andere Parteien unter ihrer Banklizenz durchgeführt haben.

Open Banking und Embedded Finance sind miteinander verwandt, unterscheiden sich jedoch deutlich. Am einfachsten lassen sie sich anhand der Frage unterscheiden, wo sich das Geld des Kunden befindet. Ein viel beachteter Zusammenbruch im Jahr 2024 zeigte, welche Folgen es haben kann, wenn die Aufzeichnungen über die Eigentumsverhältnisse außerhalb der Bank geführt werden, bei der die Gelder tatsächlich liegen. Eine anschließend vorgeschlagene Regelung zur Aufzeichnungspflicht würde versicherte Institute verpflichten, die wirtschaftlichen Eigentümer und Salden gebündelter Konten eigenständig bestimmen zu können. Der Vorschlag ist noch nicht endgültig, doch das zugrunde liegende Prinzip dürfte bestehen bleiben.

Die praktische Konsequenz ist, dass ein Ledger als System of Record mit unveränderlichen Einträgen aufgebaut werden muss und nicht lediglich als Anwendungsfunktion, die Salden aktualisiert. Das Design der Abstimmungsprozesse – einschließlich der Frage, wie Differenzen erkannt und über die Zeit nachverfolgt werden – sollte das erste Projektergebnis und keine spätere Phase sein, da dieser Ausnahmeprozess alle nachfolgenden Komponenten beeinflusst. Darauf bauen die Sponsorbank-API-Integration, Onboarding und Identitätsmanagement sowie das Servicing auf.

Die Entscheidung zwischen Eigenentwicklung und Partnerschaft hängt davon ab, ob Finanzdienstleistungen als eigene Produktlinie oder lediglich als Funktion angeboten werden sollen. Programme, die diese Fragen vor der Auswahl einer Sponsorbank beantworten, bestehen die Due-Diligence-Prüfung in der Regel erfolgreicher. Programme, die sie erst danach klären, müssen häufig Teile ihrer Lösung neu entwickeln.

Bauen Sie den Ledger von Anfang an richtig auf – entscheiden Sie sich für Sigmas Finanzsoftware-Entwicklungsservices, um ein BaaS-Programm zu starten, das die Due-Diligence-Prüfung besteht, anstatt anschließend neu aufgebaut werden zu müssen.

Häufig gestellte Fragen

Was ist Banking as a Service?

Banking as a Service ist ein Modell, bei dem eine lizenzierte Bank einer Nichtbank-Marke regulierte Funktionen über APIs zur Verfügung stellt. Die Marke bietet Einlagenkonten, Karten oder Zahlungsdienste unter ihrem eigenen Namen an, während die Bank die Banklizenz und Einlagen hält sowie die Beziehung zu den Aufsichtsbehörden verantwortet.

Wie unterscheidet sich BaaS von Open Banking?

Banking as a Service ermöglicht einer Marke, mithilfe der Lizenz einer Bank ein reguliertes Produkt anzubieten. Open Banking ermöglicht dagegen autorisierten Zugriff auf bereits bei einer Bank gespeicherte Daten, sodass ein Drittanbieter Salden abrufen oder Zahlungen initiieren kann, ohne selbst ein Bankprodukt anzubieten.

Benötigt man für BaaS eine Banklizenz?

Nein. Gerade der Verzicht auf eine eigene Banklizenz ist ein zentraler Bestandteil des Modells. Die Sponsorbank stellt die Banklizenz bereit und die Marke operiert darunter. Im Gegenzug übernimmt die Marke jedoch Verpflichtungen aus dem Vertrag mit der Bank, darunter Aufzeichnungspflichten, Identitätsprüfung und die Mitwirkung bei regulatorischen Prüfungen.

Welche Aufgaben übernimmt ein BaaS-Anbieter?

Ein BaaS-Anbieter agiert zwischen Bank und Marke und stellt APIs, den Sub-Ledger zur Erfassung individueller Salden, die Abstimmung mit den Positionen der Bank sowie in der Regel Compliance-Tools bereit. Die größte technische Herausforderung besteht darin, eine konsistente Sicht über Systeme hinweg aufrechtzuerhalten, die häufig mit unterschiedlichen Verarbeitungszyklen arbeiten.

Wer trägt die Compliance-Verantwortung?

Aus Sicht der Aufsichtsbehörden trägt die Sponsorbank die Verantwortung, da der Inhaber der Banklizenz für alle darunter ausgeführten Aktivitäten verantwortlich gemacht wird. Operativ liegt jedoch ein großer Teil der Arbeit bei der Plattform und der Marke. Genau diese Lücke zwischen formaler und praktischer Verantwortung steht im Mittelpunkt aktueller regulatorischer Entwicklungen.