Private-Credit-Manager haben selten zu wenige Deals. Ihnen fehlt die Back-Office-Kapazität, um die Kredite zu bedienen, die sie bereits halten. Genau hier setzt tokenisierte besicherte Kreditvergabe an: ein Finanzierungsmodell, bei dem ein durch reale Sicherheiten gedeckter Kredit, etwa auf Basis von Forderungen, Immobilien, Anlagevermögen oder einer Fondsposition, als digitales Instrument auf einem zugangsbeschränkten gemeinsamen Ledger ausgegeben und verwaltet wird. Kreditkonditionen, Sicherheitenanspruch, Anlegerregister und Tilgungsplan liegen in einem Datensatz statt in einem Bündel getrennter Verträge, Tabellen und Verwahrbestätigungen. Das Modell verändert, wie ein Kredit vergeben, bedient und berichtet wird, nicht seine rechtliche Natur.

Wie die Grafik zeigt, verteilt klassisches Servicing einen Kredit auf vier getrennte Systeme: den Kreditvertrag als unterschriebenes PDF, das Anlegerregister in einer Tabelle, eine separat gehaltene Verwahrbestätigung und einen Tilgungsplan im eigenen Tracker, alle manuell abgeglichen. Tokenisierte Kreditvergabe führt diese vier in einem Datensatz zusammen, der Kreditkonditionen und Sicherheitenanspruch, Anlegerregister und Tilgungsplan trägt. Gleicher Kredit, gleiche rechtliche Substanz.

So funktioniert besicherte Kreditvergabe auf einem gemeinsamen Ledger

1. Vergabe (Origination)

Der Prozess beginnt wie bei jedem besicherten Kredit. Der Emittent definiert die Fazilität (Kreditbetrag, Laufzeit, Zins und Struktur), der Kreditnehmer verpfändet Sicherheiten, und Anleger werden über KYC- und Eignungsprüfungen aufgenommen, bevor sie teilnehmen können. Nichts davon ist neu oder wird wegautomatisiert. Der gemeinsame Ledger greift erst, wenn diese Grundlagen stehen.

2. Rechtlicher Schritt außerhalb des Ledgers (falls erforderlich)

Bestimmte Sicherheiten erfordern weiterhin eine klassische rechtliche Handlung, die kein Ledger ersetzen kann. Ein Grundpfandrecht etwa muss nach geltendem Sachenrecht weiterhin im Grundbuch bestellt und eingetragen werden. Der Ledger hebt diesen Schritt nicht auf, er verzeichnet den entstehenden Anspruch, sobald die Formalität außerhalb des Ledgers abgeschlossen ist.

3. Digitale Ausgabe

Sobald Fazilität und Sicherheit feststehen, wird der Kreditanspruch als digitales Instrument im gemeinsamen Datensatz ausgegeben. Statt nur als Papiervertrag oder als Eintrag im privaten System einer Partei zu bestehen, wird er zu einem nativen Datensatz auf dem Ledger, auf den berechtigte Teilnehmer direkt zugreifen können.

4. Pflege auf dem Ledger

Sicherheitenposition, Anlegerregister und Zahlungswasserfall werden gemeinsam auf einem Datensatz geführt. Weil jede berechtigte Partei aus derselben Quelle liest, entfällt der nachträgliche Abgleich getrennter Datenkopien. Was eine Partei sieht, sehen alle, am selben Ort und zur selben Zeit aktualisiert.

5. Servicing-Wasserfall

Der Servicing-Wasserfall ist die vertraglich festgelegte Reihenfolge, in der Rückzahlungen verwendet werden: zuerst Gebühren, dann Zinsen, dann Kapital. Auf einem gemeinsamen Datensatz wird diese Reihenfolge einmal angewandt und sofort für jeden Halter abgebildet, statt von jeder Partei separat berechnet und anschließend gegeneinander geprüft zu werden.

Worin unterscheiden sich tokenisierte Kredite von einer klassischen Fazilität?

Tokenisierte Kredite unterscheiden sich von einer klassischen Fazilität vor allem operativ, nicht in der rechtlichen Substanz, konkret darin, wie Anlegerregister, Servicing, Sicherheitenüberwachung, Übertragung und Reporting gehandhabt werden. Ein tokenisierter Kredit bleibt eine Forderung mit Kreditnehmer, Zins, Laufzeit und Sicherheit. Was sich ändert: Ausgabe, Übertragung, Servicing und Reporting laufen über einen Datensatz, statt über einen Arrangeur, eine Zahlstelle, ein Register und einen Verwahrer, die jeweils eine eigene Kopie führen.

Das praktische Ergebnis ist ein kürzerer Weg von der Zeichnung zur finanzierten Position und ein sauberer Prüfpfad. Für einen Manager mit vielen Fazilitäten wiegt das schwerer als jedes einzelne Funktionsmerkmal.

Wo passen tokenisierte Kredite ins Portfolio?

Tokenisierte Kredite passen überall dort, wo ein Manager bereits Fremdkapital vergibt, aber eher durch Administration als durch das Dealangebot begrenzt ist. Der Unterschied ist operativer Natur, also Abwicklungsgeschwindigkeit, granulare Sicherheitendaten und Transparenz im Servicing, und nicht ein neuer Platz in der Asset-Allokation. Nehmen wir eine Forderungsfinanzierung: Das Reporting des Kreditnehmers trifft oft in einem anderen Takt ein als der NAV-Zyklus der Anleger, sodass Operations-Teams den Monat mit dem Abgleich beider Quellen verbringen. Auf einem gemeinsamen Datensatz aktualisieren sich Kreditnehmerdaten, Sicherheitendeckung und Anlegerpositionen aus derselben Quelle. Dasselbe Muster gilt für eine Private-Credit-Strategie oder eine Mezzanine-Position im Immobilienbereich, wobei jede ihre Eigenheiten behält: Bei Immobilien bleibt der Grundbuchschritt außerhalb des Ledgers, und Mezzanine bringt eine eigene Nachrangigkeit und einen eigenen Verwertungswasserfall mit.

Wie die Grafik zeigt, liegt der operative Unterschied in drei Punkten: Abwicklungsgeschwindigkeit, granulare Sicherheitendaten und Transparenz im Servicing. Über drei Strategien hinweg löst die Forderungsfinanzierung den Taktversatz, sodass Kreditnehmerdaten, Sicherheitendeckung und Anlegerpositionen aus einem Datensatz kommen; eine Private-Credit-Strategie nutzt dasselbe Muster skaliert; Immobilien-Mezzanine ergänzt zwei Schritte, Grundbuch und eigenen Verwertungswasserfall.

Warum ist tokenisierte Kreditvergabe für Asset-Manager relevant?

Für Vermögens- und Asset-Manager ist die begrenzende Größe in der tokenisierten Kreditvergabe meist die operative Kapazität, nicht die Origination. Im klassischen Aufbau bedeutet jede neue Fazilität eine weitere Registerbeziehung, einen weiteren Abstimmungstakt und einen weiteren Reporting-Strom. Teams bauen Deal für Deal dasselbe administrative Gerüst erneut auf.

Eine wiederverwendbare Ausgabe- und Servicing-Schicht beseitigt diese Wiederholung. Ein Multi-Family-Office kann Kredite und Anleger hinzunehmen, ohne dass der Back-Office-Aufwand linear mitwächst, und Compliance- und Prüfteams erhalten eine einzige verlässliche Quelle. Man denke an einen Manager mit vielen Forderungsfazilitäten: Heute trägt jede ihre eigene Register- und Abstimmungsbeziehung. Auf einem gemeinsamen Datensatz laufen diese zu einem einzigen Workflow zusammen.

Diese Schicht ist ein durchgehender Stack von der Origination bis zum Servicing: Origination und Zulassung, Sicherheiten und Register, automatisiertes Servicing sowie kontrollierte Sekundärübertragung. Jeder Abschnitt des Kreditlebenszyklus hat einen klaren Ort.

Wie sich das auf reale Mandate abbildet, zeigen unsere Seiten zu Private Credit und für Asset-Manager.

Welche Risiken und welchen regulatorischen Rahmen gibt es?

Risiken

1. Klassisches Kredit- und Sicherheitenrisiko

Das sind dieselben Risiken wie bei jedem besicherten Kredit. Einen Kredit auf einen gemeinsamen Datensatz zu legen, senkt weder das Ausfallrisiko noch das Bewertungsrisiko und ersetzt nicht den nötigen Anlegerschutz. Der Ledger verändert die Buchführung, nicht die zugrunde liegende Verpflichtung: Der Kreditnehmer muss weiterhin zurückzahlen, und die Sicherheit muss ihren Wert halten.

2. Operative und rechtliche Umsetzung

Über dem Kreditrisiko liegt die Arbeit, das Instrument korrekt auszugeben. Strukturierung, Dokumentation und Ausgabe müssen sauber erfolgen, und Fehler an dieser Stelle schaffen rechtliche Risiken, die nichts mit der Zahlungsfähigkeit des Kreditnehmers zu tun haben.

3. Plattformrisiko

Die Nutzung eines gemeinsamen Ledgers begründet eine Abhängigkeit vom Plattformbetreiber: Geschäftskontinuität, Schlüsselverwahrung und Haftung bei einem Ausfall oder Sicherheitsvorfall. In der Praxis liegen diese Punkte vertraglich und über Service-Level-Vereinbarungen beim Betreiber. Diese Bedingungen sollten auch regeln, was bei Abwicklung oder Lizenzverlust des Betreibers geschieht, etwa über Daten-Escrow und Exit-Rechte, die das Register verfügbar halten. Jeder Punkt, den der Vertrag offenlässt, gehört auf die Due-Diligence-Liste.

Regulatorischer Rahmen

1. Rechtliche Einordnung (der ungeklärte Teil)

Ob ein besicherter Kreditanspruch als Wertpapier, Fondsanteil oder Forderung behandelt wird, ist noch keine gefestigte Praxis. Hinzu kommt die Erlaubnisfrage: Gewerbliche Kreditvergabe ist Kreditgeschäft und erfordert eine Erlaubnis nach § 32 KWG, weshalb Asset-Manager Kredite typischerweise über KAGB-regulierte Kreditfonds vergeben (BaFin-Verwaltungspraxis seit 2015). In einem konkreten Deal wird das in der Regel mit Wertpapierjuristinnen und -juristen geklärt und, wo nötig, im Austausch mit der BaFin, bevor ausgegeben wird.

2. eWpG - Inhaberschuldverschreibungen

Ist der Anspruch als Inhaberschuldverschreibung strukturiert, erlaubt das deutsche eWpG (Gesetz über elektronische Wertpapiere von 2021) die Ausgabe dieser Schuldverschreibung in einem Kryptowertpapierregister. Dort ist der Registereintrag, nicht eine Papierurkunde, der Nachweis der Rechtsinhaberschaft. Fondsanteile fallen schrittweise in den Anwendungsbereich.

3. MiCAR - Kryptowerte

Qualifiziert ein Instrument als Kryptowert statt als Finanzinstrument, greift stattdessen die EU-Verordnung über Märkte für Kryptowerte (MiCAR).

4. Prospektverordnung

Angebote von Instrumenten, die als Wertpapiere gelten, lösen weiterhin die Prospektverordnung aus, sofern keine Ausnahme greift, in Deutschland oft eine leichtere BaFin-Meldung statt gar keiner.

5. Durchsetzung - maßgeblich ist das Register der Sicherheit selbst

Im Verzugsfall zählt das Register der Sicherheit selbst: Ein Grundpfandrecht wird über das Grundbuch verwertet, nicht über den Ledger. Beide Register müssen daher im Verzugsfall abgeglichen werden, und die Verantwortung für eine etwaige Verzögerung gehört in den Plattformvertrag.

So sehen Sie das an Ihren eigenen Fazilitäten

Nichts davon ersetzt Kreditbeurteilung oder rechtliche Strukturierung. Es verändert, wo der Datensatz liegt und wie viel Back-Office-Aufwand jede neue Fazilität hinzufügt. Am klarsten lässt sich diese Abwägung gegen ein Mandat beurteilen, das Sie bereits führen. Wenn Ihr Team Fazilitäten schneller aufnimmt, als Operations sie verarbeiten kann, zeigt ein kurzer Durchgang, wie Origination, Servicing und Reporting auf einem Datensatz zusammenlaufen und wo die Schritte außerhalb des Ledgers und die regulatorischen Schritte für Ihre konkrete Sicherheit weiterhin gelten.

Weiterlesen: Wie Positionen wie diese in ein breiteres Portfolio passen, zeigt unser Beitrag zur Kapitalallokation in Private Markets.

Dieser Artikel dient ausschließlich der allgemeinen Information und stellt keine Rechtsberatung dar.

Zuletzt geprüft von Lukas Wipf, CPO & Mitgründer bei ONINO, am 26. Juni 2026.