Embedded Finance und BaaS für KMU-Software: Wie vertikales SaaS Zahlungen, Kredite und Kartenherausgabe integriert

Toast – eine Point-of-Sale-Plattform für Restaurants – verdiente im vergangenen Jahr rund 5 Milliarden US-Dollar mit Finanzdienstleistungen. Seine Software-Abonnements, das eigentliche Kernprodukt, brachten 936 Millionen US-Dollar ein. Der Fintech-Anhang ist mittlerweile fünfmal größer als das ursprüngliche SaaS-Zugpferd.

Dasselbe Muster wiederholt sich bei vertikaler Software: Die Händlerlösungen von Shopify machen 73 % des Umsatzes aus. Der IPO-Mix von ServiceTitan bestand zu 71 % aus Abonnements und zu 25 % aus Fintech, aber Analysten, die den neuen Nettoumsatz beobachten, sehen eine Annäherung des Verhältnisses auf 55/45 – Zahlungen wachsen schneller als der Software-Kern. Wenn ein Vertical-SaaS-Unternehmen im Jahr 2026 eine Series-B-Finanzierungsrunde erreicht, lautet die Frage der Investoren nicht mehr, ob Zahlungen integriert werden sollen, sondern welcher Embedded-Finance-Stack verwendet werden soll und wie schnell Kreditvergabe und Kartenherausgabe folgen können.

Dies ist das, was die Branche als Embedded Finance bezeichnet – Finanzprodukte, die innerhalb einer nicht-finanziellen Software angeboten werden – und die technologische Infrastruktur dahinter ist Banking-as-a-Service (BaaS). Die Chance ist real: Die Plattformumsätze in den USA aus Embedded Finance werden prognostiziert von rund 22 Milliarden US-Dollar im Jahr 2021 auf 51 Milliarden US-Dollar im Jahr 2026 zu wachsen, und der BaaS-Markt verzeichnet bis 2031 eine jährliche Wachstumsrate (CAGR) von 17,8 %. Doch neben dieser Chance existiert ein Friedhof aus Unterlassungsverfügungen, eingefrorenen Programmen und versäumten Audits. Die meisten Gründer, die dort landen, bemerkten erst, dass sie ein bankähnliches Geschäft betreiben, als ein Regulator sie darauf hinwies.

Dieser Leitfaden erläutert, was Embedded Finance eigentlich ist, warum Vertical SaaS die natürliche Heimat dafür ist, wie der Stack im Jahr 2026 aussieht, wie man zwischen Anbietern wählt und welche Compliance-Fallen vielversprechende Starts in existenzielle Zwischenfälle verwandeln können.

Was „Embedded Finance“ tatsächlich bedeutet

Embedded Finance ist ein Kürzel für Finanzprodukte – Zahlungen, Einlagenkonten, Debitkarten, Kredite, Versicherungen, Gehaltsabrechnung –, die innerhalb einer Software bereitgestellt werden, die oberflächlich betrachtet kein Finanzprodukt ist. Eine Softwareplattform für das Baugewerbe, die es Bauunternehmern ermöglicht, ACH-Zahlungen von ihren Kunden anzunehmen, das Bargeld auf einem Unterkonto zu halten und einen Sofortvorschuss auf unbezahlte Rechnungen zu erhalten, betreibt Embedded Finance. Ebenso ein Verwaltungssystem für Tierkliniken, das markengebundene Debitkarten an tiermedizinische Fachangestellte für den Kauf von Vorräten ausgibt.

Der technische Motor hinter den meisten dieser Funktionen ist Banking-as-a-Service: Eine regulierte Bank (die „Sponsorenbank“) vermietet ihre Banklizenz, ihren Zugang zu ACH- und Kartennetzwerken sowie ihr FDIC-versichertes Hauptbuch (Ledger) an einen Fintech-Middleware-Anbieter, der diese Funktionen wiederum als saubere APIs bereitstellt, die gewöhnliche Softwareunternehmen aufrufen können. Das Softwareunternehmen besitzt selbst nie eine Banklizenz. Es übernimmt jedoch eine lange Liste operativer und Compliance-Verantwortlichkeiten, die sich beim Lesen des Kleingedruckten stark nach dem Betrieb einer Bank anfühlen.

Drei Produkte dominieren den Embedded-Finance-Stack:

• Eingebettete Zahlungen (Embedded Payments). Annahme von Karten und ACH im Namen der Endkunden der SaaS-Plattform. Dies ist der Einstieg – am einfachsten zu implementieren, am schnellsten umsatzgenerierend und das Fundament für alles Weitere.
• Eingebettete Kreditvergabe (Embedded Lending). Bargeldvorschüsse auf künftige Forderungen, Kreditrahmenprodukte und befristete Darlehen, die unter Verwendung der plattformeigenen Transaktionsdaten geprüft werden. Die Take-Rates und Nettomargen sind hier weitaus höher als im Zahlungsverkehr.
• Herausgegebene Karten und Konten. Markengebundene Debitkarten, virtuelle Karten und FDIC-versicherte Geschäftskonten („Spesenkarten“ für Teams, „Lohnkonten“ für Gig-Worker, Guthabenkarten für Käufer).

Jede dieser Schichten verstärkt die anderen, da jede einzelne einen größeren Teil des Working-Capital-Flusses des Kunden erfasst.

Warum Vertical SaaS einen unfairen Vorteil hat

Eine horizontale Zahlungs-App sieht eine Kreditkartenzahlung isoliert. Eine Vertical-SaaS-Plattform sieht den Vertrag, der zur Zahlung führte, die für den Vertrag geplanten Arbeitsstunden, die Materialrechnung, die bis Freitag bezahlt werden muss, die historische Saisonalität jedes Kunden in derselben Postleitzahl und den Trend des Bankguthabens des Betreibers in Richtung Überziehung.

Dieser Kontext ist der Burggraben. Er verändert drei Dinge gleichzeitig:

1. Die Risikoprüfung (Underwriting) wird günstiger und genauer. Ein SaaS-Unternehmen für das Baugewerbe weiß, welche Bauunternehmer pünktlich bezahlt werden und welche ständig Forderungen mit 90 Tagen Laufzeit in den Büchern haben. Das macht ein Cash-Vorschussprodukt zu einer weitaus sichereren Wette als einen generischen Kleingewerbekredit einer Bank, die nur eine Steuererklärung sieht.
2. Die Vertriebskosten sinken massiv. Der Kunde befindet sich bereits in der App. Es gibt keinen Akquisitions-Funnel für ein neues Finanzprodukt – es gibt lediglich ein Banner auf dem Bildschirm, den der Nutzer ohnehin bereits verwendet. Branchenanalysten schätzen, dass Plattformen, die Finanzprodukte erfolgreich integrieren, den Umsatz pro Kunde verdreifachen bis vervierfachen.
3. Die Kundenbindung (Retention) verstärkt sich. Sobald Gehaltsabrechnung, Zahlungen und ein Kreditrahmen über Ihre Software laufen, werden die Wechselkosten enorm. Die Fintech-Schicht verwandelt ein 99-Dollar-Abonnement pro Monat in ein Finanzdienstleistungskonto mit einem Wert von 5.000 Dollar pro Jahr.

Dies ist der Grund, warum sich das Fintech-Playbook für Vertical SaaS in etwa vier Jahren von einer „experimentellen Nebenwette“ zur „standardmäßigen Annahme für die Series-B-Planung“ entwickelt hat.

Der 2026-Stack: Wer macht was

Die Anbieterlandschaft für Embedded Finance ist dicht gedrängt, und die Kategorien überschneiden sich. Eine vereinfachte Ansicht der Anbieter, die von KMU-Softwareteams im Jahr 2026 am häufigsten in die engere Wahl gezogen werden:

Zahlungsabwicklung und Orchestrierung

• Stripe Connect und Stripe Treasury. Der Standard für Entwickler („developer-first“). Starke APIs, exzellente Dokumentation, breite Abdeckung von der Kartenakzeptanz über verwaltete Guthaben bis hin zu ausgestellten Karten. Ideal für Teams, die einen einzigen Anbieter für den Großteil des Stacks suchen.
• Adyen for Platforms. Volumenbasierte Preise und global stark. Bessere Konditionen ab einem verarbeiteten Zahlungsvolumen von 50 Millionen US-Dollar; langsameres Onboarding und weniger großzügig bei kleineren Programmen.
• Finix und Payabli. „PayFac-as-a-Service“ – sie helfen Plattformen dabei, Zahlungsvermittler (Payment Facilitators) zu werden (oder zumindest wie einer aufzutreten), ohne die gesamte regulatorische Infrastruktur selbst aufbauen zu müssen.

Banking und Konten (BaaS-Middleware)

• Unit. Der schnellste Weg zu einem Live-Programm für US-SaaS-Unternehmen, die Kundenguthaben halten oder Markenkarten ausgeben möchten. Starkes Produkt, aber eng an einige wenige Partnerbanken (Sponsor Banks) gebunden.
• Treasury Prime. Multi-Bank-API – nützlich, wenn Sie Funktionen auf Bankebene wie FDIC-Pass-Through-Schutz und Echtzeitzahlungen nutzen möchten, ohne sich an einen einzigen Partner zu binden.
• Synctera. Compliance-orientierte Middleware, die versucht, BSA/AML-Tools vom ersten Tag an in das Entwicklererlebnis zu integrieren.
• Column. Eine Bank, die auch ihre eigenen APIs bereitstellt und damit eine Ebene des „Middleware-Sandwichs“ entfernt.

Kartenausgabe (Card Issuing)

• Marqeta, Lithic, Highnote. Infrastruktur für die Kartenausgabe von gebrandeten Debit-, Prepaid- und zunehmend auch Kreditprogrammen. Marqeta ist skalierbar; Lithic spricht Teams an, die eine schlankere, entwicklerfreundliche Oberfläche suchen; Highnote konzentriert sich auf Kredit- und Verbraucherprodukte.

Kreditvergabe und Kapital

• Parafin, Kanmon, Liberis. APIs für Embedded Lending, die das Underwriting anhand der Transaktionsdaten der Plattform durchführen und die Kreditvergabe, den Service und (in einigen Fällen) die Bilanzierung übernehmen.

Ledger (Hauptbuch) und Geldbewegungen

• Modern Treasury. Referenzimplementierung für die Ledger-Infrastruktur innerhalb von Plattformen; wird von Unternehmen wie Gusto und Marqeta genutzt, um ihre eigene Buchhaltung (Books) korrekt zu führen, noch bevor das Geld bei einer Bank eingeht.
• Dwolla, Moov. Programmatische Geldbewegungen mit Fokus auf ACH, die häufig zusammen mit einem Kartenprozessor eingesetzt werden.

Die meisten Live-Programme kombinieren drei oder vier dieser Anbieter – zum Beispiel könnte eine Immobilienverwaltungsplattform Stripe für die Kartenakzeptanz, Unit für die Ertragskonten der Vermieter, Marqeta für Markenkarten für Immobilienverwalter und Parafin für Bargeldvorschüsse auf Mieteinahmen nutzen.

Ein realistischer Sequenzierungsplan

Der häufigste Fehler besteht darin, Zahlungen, Kredite und Karten in einem einzigen großen Release einführen zu wollen. Tun Sie es nicht. Die Komplexität in Bezug auf Compliance, Betrieb und Wirtschaftlichkeit ist auf jeder Ebene grundlegend anders, und die richtige Abfolge ist in fast jedem Fall die gleiche.

Phase 1 – Zahlungen (Monate 0 bis 6). Führen Sie die Kartenakzeptanz für die Kunden Ihrer Kunden ein. Dies ist die Ebene mit dem geringsten Risiko und dem höchsten Volumen. Bauen Sie die Integration so auf, dass die Plattform an jeder Transaktion einen kleinen Anteil verdient (in der Regel 30 bis 100 Basispunkte). Nutzen Sie diese Phase, um Ihr Kunden-Onboarding, die KYB-Prüfungen (Know Your Business) und die Betrugsüberwachung zu festigen.

Phase 2 – Konten und Auszahlungen (Monate 6 bis 12). Sobald die Zahlungen stabil laufen, fügen Sie die Möglichkeit hinzu, dass Kunden Guthaben innerhalb der Plattform halten, ACH-Auszahlungen senden und virtuelle Karten für bestimmte Ausgabenkategorien ausstellen können. Markenkarten für Debit-Zahlungen sind normalerweise das zweite Kartenprodukt, nicht das erste.

Phase 3 – Kredit und Kapital (Jahr zwei). Bargeldvorschüsse auf Forderungen kommen zuerst – sie haben eine kurze Laufzeit, sind einfacher zu prüfen und werden automatisch durch eingehende Zahlungen getilgt. Terminkredite und Kreditlinien folgen später, da sie tiefergehende Prozesse für Kreditprüfung, Inkasso und Abschreibungen erfordern.

Daten von Bain & Company zeigen, dass Plattformen, die diese Abfolge einhalten, deutlich höhere Take-Rates und niedrigere Abschreibungsquoten aufweisen als diejenigen, die Phasen überspringen. Die Versuchung, die Kreditvergabe frühzeitig zu starten, ist groß, da die Unit Economics so viel besser sind als beim Zahlungsverkehr. Aber die operative Reife, die erforderlich ist, um eine Abschreibungsquote von 4 % aufzufangen, ist beträchtlich und im ersten Jahr fast nie vorhanden.

Die Compliance-Falle, über die niemand sprechen möchte

Im Februar 2024 erließ die FDIC Einverständniserklärungen (Consent Orders) gegen zwei Banken wegen Sicherheits- und Soliditätsbedenken im Zusammenhang mit BaaS – primär wegen Verstößen gegen den Bank Secrecy Act und mangelnder Überwachung von Drittanbietern. Die Anordnung gegen die Piermont Bank betraf Programme, die über Treasury Prime und Unit betrieben wurden. Die Sutton Bank, die mit Fintechs wie Robinhood, Square und Upgrade zusammenarbeitet, erhielt ähnliche Bescheide. Weitere Anordnungen folgten im Laufe der Jahre 2024 und 2025. Die FDIC meldete allein im Mai 2025 zwölf Vollstreckungsanordnungen. Das Office of the Comptroller of the Currency (OCC) hat vergleichbare Maßnahmen auf nationaler Ebene ergriffen.

Wenn eine Partnerbank eine solche Anordnung erhält, bekommt die nachgeschaltete Plattform nicht nur einen strengen Brief – oft werden Programme eingefroren, das Onboarding neuer Kunden gestoppt und in einigen Fällen wird es schwierig, bestehende Guthaben zu bewegen. Gründer, die das Gefühl hatten, „nur ein SaaS-Feature“ zu betreiben, stellen plötzlich fest, dass ihre Roadmap die Geisel eines Regulators ist, den sie noch nie getroffen haben.

Einige spezifische Verpflichtungen bringen Softwareunternehmen regelmäßig zum Stolpern:

• KYC und KYB (Know Your Customer / Know Your Business). Jeder Endnutzer, der ein Guthaben hält, eine Karte erhält oder einen Kredit aufnimmt, muss nach dem von der Partnerbank geforderten Standard identifiziert werden – nicht nach dem Standard, den Ihr Produktteam für ausreichend hält.
• Wirtschaftliches Eigentum (Beneficial Ownership) und CIP. Die Regeln des Customer Identification Program (CIP) gelten für Geschäftskunden, und die Vorschrift zur Erfassung von Informationen über wirtschaftliche Eigentümer ab einem Schwellenwert von 25 % Beteiligung wird wortwörtlich durchgesetzt.
• Transaktionsüberwachung und SAR-Meldungen. Meldungen über verdächtige Aktivitäten (Suspicious Activity Reports) sind nicht optional. Die Plattform übernimmt in der Regel die Erstüberwachung; die Partnerbank erstattet die Meldung. Wenn die Überwachung schwach ist, trägt die Bank die regulatorischen Folgen und die Plattform riskiert die Kündigung des Vertrags.
• Marketing und Offenlegung. Was Sie über FDIC-Versicherung, Zinsen und Kreditbedingungen sagen, ist reguliert. Die Angabe „FDIC-versichert“ ohne Sternchen war die Ursache für mehr Unterlassungserklärungen als fast jeder andere Satz.
• Beschwerdemanagement und Reg E. Finanzprodukte für Verbraucher bringen Verpflichtungen zum Verbraucherschutz mit sich, einschließlich spezifischer Fristen für die Bearbeitung angefochtener Transaktionen.

Eine nützliche Faustregel: Wenn eine Funktion eine Lizenz erfordern würde, wenn Sie sie selbst anbieten würden, dann behandelt das Compliance-Team Ihrer Partnerbank sie auch so – selbst wenn Ihr Produktmanager das anders sieht.

Die Wahl zwischen Build, Buy oder Partner

Es gibt drei legitime Wege, und die richtige Antwort hängt vom Kapital, der regulatorischen Risikobereitschaft und der Bedeutung von Finanzdienstleistungen für die langfristige Roadmap ab.

Reines Partner-/Empfehlungsmodell. Die Plattform verweist Kunden an einen Finanzdienstleister und erhält eine Pauschalgebühr oder eine kleine Umsatzbeteiligung. Geringstes Risiko, geringstes Aufwärtspotenzial, schnellste Markteinführung. Richtig für SaaS-Unternehmen, bei denen Finanzen eher ein Zusatz- als ein Kernprodukt sind.

Eingebettet über BaaS-Middleware. Die Plattform tritt gegenüber ihren Kunden wie ein Finanzdienstleister auf, aber die regulierte Tätigkeit liegt bei einer Partnerbank und einem Middleware-Partner. Die meisten vertikalen SaaS-Programme befinden sich hier. Die Take Rates sind real, der Compliance-Aufwand ist erheblich, und die Unit Economics funktionieren bereits bei moderater Skalierung.

Banklizenz, Zulassung oder direkter PayFac. Eine kleine Anzahl von Plattformen erwirbt schließlich eine Geldtransferlizenz, wird zum registrierten Zahlungsabwickler (Payment Facilitator) oder strebt eine Banklizenz an. Dies ist teuer, langsam und nur sinnvoll, wenn das Programm Finanzdienstleistungsumsätze im zweistelligen Millionenbereich generiert und die Einsparungen durch den Wegfall der Middleware die regulatorischen Kosten übersteigen.

Ein einfacher Test: Wenn Ihr aktueller oder geplanter Umsatz mit Finanzdienstleistungen unter 5 Millionen US-Dollar pro Jahr liegt, wählen Sie einen Partner oder nutzen Sie Middleware. Zwischen 5 und 50 Millionen US-Dollar gewinnt fast immer die Middleware. Über 50 Millionen US-Dollar sollten Sie zumindest modellieren, was es kosten würde, mehr Teile des Stacks intern abzubilden.

Das Zahlenspiel: Wie realistische Kennzahlen aussehen

Die Wirtschaftlichkeit unterscheidet sich je nach Produkt stark. Verwenden Sie bei der Erstellung eines Finanzplans diese groben Benchmarks für 2026 als Ausgangspunkt und passen Sie sie an Ihre Branche an:

• Kartenakzeptanz: 30 bis 100 Basispunkte des verarbeiteten Volumens für die Plattform, nachdem die Partnerbank und die Middleware ihren Anteil erhalten haben.
• ACH: Beträge im einstelligen Cent-Bereich bis hin zu niedrigen festen Gebühren in Dollar, plus kleine prozentuale Take Rates bei wertschöpfenden Transaktionsflüssen.
• Ausgegebene Debit-/Bezahlkarten: Interchange-Split, der der Plattform in der Regel 50 bis 100 Basispunkte des Umsatzes einbringt, abzüglich der Kosten für die Kartenproduktion und das Programmmanagement.
• Barvorschüsse auf Forderungen: Effektive Jahreszinssätze im Bereich von 30 bis 60 %, mit Abschreibungen von 2 bis 6 % für ein gut geprüftes Portfolio. Die Nettomargen nach Kapitalkosten können 8 bis 15 % des Neugeschäftsvolumens betragen.
• Terminkredite: Niedrigere effektive Jahreszinssätze, längere Laufzeit, höhere Betriebskosten. Die Marge hängt stark von den Kapitalkosten und dem Inkassowesen ab.

Speziell für eingebettete B2B-ACH-Zahlungen prognostizieren Branchenberichte, dass Plattformen bis 2026 rund 4 Milliarden US-Dollar an Nettoumsätzen aus Mehrwertdiensten erzielen werden, und das Volumen eingebetteter Karten wird weitere rund 800 Millionen US-Dollar an Plattformumsatz beisteuern. Diese Zahlen summieren sich, weil derjenige sie vereinnahmt, der die Kundenbeziehung und den Transaktionskontext besitzt – nicht die Bank, der die technische Infrastruktur gehört.

Vermeiden Sie diese fünf Fehler

Muster, die in Post-Mortem-Analysen gescheiterter oder problembehafteter Programme immer wieder auftauchen:

1. Entwicklung beginnen, bevor die Compliance besetzt ist. Die erste Einstellung für ein Embedded-Finance-Programm ist kein Ingenieur oder Produktmanager. Es ist jemand mit echter BSA/AML-Erfahrung, idealerweise mit bestehenden Beziehungen zu Partnerbanken.
2. Die Partnerbank als Lieferanten statt als Aufsichtsbehörde behandeln. Das Compliance-Team Ihrer Partnerbank hat faktisch ein Vetorecht über Ihre Roadmap. Beziehen Sie sie frühzeitig ein, auch wenn Sie es nicht müssen.
3. KYB für „kleine“ Kunden überspringen. Es gibt keine Ausnahme für „klein“. Es gibt keine Ausnahme für „wir kennen diesen Kunden“. Die Regeln gelten für jeden Kontoinhaber.
4. Unterschätzung der Kapitalkosten für die Kreditvergabe. Die Nettozinsmarge bei Barvorschüssen sieht in einer Tabelle fantastisch aus, bis man die Kosten für eine Kreditlinie, Abschreibungen, Servicekosten und die periodische Wertberichtigung eines Portfolios, das sich schlecht entwickelt hat, hinzurechnet.
5. Das Marketing der Rechtsabteilung vorauseilen lassen. Die meisten Durchsetzungsmaßnahmen im Bereich der Finanzdienstleistungen für Verbraucher lassen sich auf eine einzige Anzeige, eine einzige Webseite oder einen einzigen In-App-Banner zurückführen. Marketingtexte für Finanzprodukte benötigen einen Überprüfungsprozess und eine Dokumentation.

Wo Plain-Text Accounting ins Spiel kommt

Embedded Finance schafft ein technisches Problem, über das fast niemand spricht, bis es zu spät ist: die Explosion des Hauptbuchs. Jedes Kundenguthaben, jede Kartenzahlung, jede Auszahlung, jede Kreditauszahlung, jede Rückzahlung und jede Rückbelastung ist nun ein Buchungsereignis in Ihrem System, nicht nur in dem der Bank. Sie müssen Ihre Bücher mit dem Kontoauszug der Partnerbank, der Abrechnungsdatei Ihres Kartenprozessors und dem Bericht eines Kreditdienstleisters abgleichen – oft täglich.

Anbieter wie Modern Treasury existieren genau deshalb, weil traditionelle Hauptbücher mit der Geschwindigkeit der Geldbewegungen nicht mithalten können. Für die interne Unternehmensfinanzierung – Ihre eigenen Bücher, die der CFO zertifizieren muss – gilt dasselbe Prinzip: Transparenz im Hauptbuch, Prüfpfade und die Fähigkeit, Abgleiche gegen externe Quellen zu skripten, sind wichtiger, sobald Finanzdienstleistungen über Ihre Plattform fließen, als sie es jemals in einem reinen SaaS-Abonnementmodell waren.

Halten Sie Ihre eigenen Bücher so transparent wie Ihr Produkt

Embedded Finance verwandelt ein Softwareunternehmen in ein Unternehmen, das Geld bewegt – und das buchhalterische Rückgrat Ihres Geschäfts muss mindestens so gut sein wie das Finanzprodukt, das Sie an Ihre Kunden ausliefern. Beancount.io bietet Plain-Text-Buchhaltung mit Versionskontrolle, die vollständig transparent, skriptbar und für die Art von hochfrequenten Kontenabstimmungen ausgelegt ist, die fintech-orientierte SaaS-Unternehmen benötigen. Es gibt keine Blackboxen und keinen Anbieter-Lock-in – Ihre Bücher befinden sich in einer Textdatei, die Sie Zeile für Zeile prüfen können. Starten Sie kostenlos und erfahren Sie, warum Entwickler und Finanzteams auf Plain-Text-Buchhaltung umsteigen, wenn ihr Financial Stack komplexer wird.