Tokenisierte Einlagen oder Stablecoins? Unterschiede für Banken und Unternehmen

Die kurze Antwort lautet: Keines der beiden Instrumente ist pauschal die bessere Form digitalen Geldes. Eine tokenisierte Einlage liegt nahe, wenn Bankkunden in einer regulierten Bankbeziehung zahlen und eine bestehende Einlagenlogik programmierbar machen wollen. Ein regulierter Stablecoin kann besser passen, wenn ein Token über verschiedene Wallets, Plattformen oder Länder hinweg zirkulieren soll. Vor einem technischen Proof of Concept muss geklärt sein, welche Forderung übertragen wird und wie sie am Ende erfüllt wird.

Zuerst den Geldanspruch klären

Die Benutzeroberfläche kann bei beiden Varianten ähnlich aussehen: Eine Wallet zeigt 100 digitale Euro-Einheiten, ein Smart Contract löst eine Zahlung aus und die Übertragung wird auf einem Distributed Ledger protokolliert. Wirtschaftlich sind diese Einheiten trotzdem nicht automatisch dasselbe.

Eine tokenisierte Einlage ist eine digitale Repräsentation von Geschäftsbankengeld. Die Europäische Zentralbank beschreibt sie als Abbildung einer traditionellen Einlage auf DLT, die bei der ausgebenden Bank zum Nennwert einlösbar ist. Der Token bringt damit eine bekannte Bankverbindlichkeit in eine programmierbare Umgebung. Die konkrete rechtliche und bilanzielle Ausgestaltung hängt allerdings vom Modell ab.

Der Begriff Stablecoin bezeichnet breiter einen Krypto-Asset-Token, der einen stabilen Wert anstrebt. Im Euro-Kontext ist besonders der E-Geld-Token nach der EU-Verordnung über Märkte für Kryptowerte, kurz MiCA, relevant: Er referenziert den Wert einer amtlichen Währung. Nach Artikel 48 MiCA gelten E-Geld-Token als E-Geld; öffentlich anbieten oder zum Handel zulassen dürfen sie grundsätzlich Kreditinstitute oder E-Geld-Institute. Nicht jeder weltweit verwendete „Stablecoin“ erfüllt diese europäische Einordnung.

Die erste Projektfrage lautet daher nicht „Welche Blockchain verwenden wir?“, sondern: Gegen wen besteht der Anspruch, wer darf ihn halten und durch welchen Vorgang wird daraus wieder Buchgeld oder Zentralbankgeld?

Die wichtigsten Unterschiede im Überblick

Diese Gegenüberstellung ist eine fachliche Orientierung, keine abschließende rechtliche Klassifikation. Schon bei tokenisierten Einlagen unterscheidet die EZB zwischen übertragbaren „Bearer“-Modellen und nicht übertragbaren Modellen. Vertragswerk, Bilanzierung, Aufsicht und Schutzmechanismen müssen für die konkrete Architektur geprüft werden.

Tokenisierte Einlagen: Bankgeld mit programmierbarer Schnittstelle

Bei einer nicht übertragbaren tokenisierten Einlage bleibt der Kunde in der Logik seiner Bank. Bezahlt er einen Kunden eines anderen Instituts, muss nicht derselbe Token von Wallet A nach Wallet B wandern. Die sendende Bank reduziert den Tokenbestand ihres Kunden, die empfangende Bank erhöht den Bestand ihres Kunden und parallel wird die Verpflichtung zwischen den Banken erfüllt.

Genau hier liegt die oft übersehene zweite Ebene: Ein Kundentoken löst das Interbank-Settlement nicht automatisch. Damit verschiedene Bankgelder zum gleichen Nennwert funktionieren, braucht es eine gemeinsame Abwicklung, belastbare Regeln und einen neutralen Anker. Die EZB erläutert diesen Zusammenhang in ihrer Analyse zu Tokenisierung und einem integrierten digitalen Kapitalmarkt. Nicht übertragbare tokenisierte Einlagen können die Einheitlichkeit des Geldes bewahren, benötigen für Zahlungen zwischen Banken aber eine Settlement-Plattform.

Ein übertragbares Modell verändert die Lage. Der Halter kann die Forderung gegen die ausgebende Bank weitergeben, ohne dass jeder Empfänger dort bereits ein Konto hält. Dadurch gewinnt der Token Reichweite, kann aber auch einen eigenen Marktpreis entwickeln. Der genaue Anspruch, Zulassungskriterien für Wallets und die Konvertierung am Rand des Netzwerks werden dann umso wichtiger.

Für Unternehmen ist eine tokenisierte Einlage besonders interessant, wenn sie eng mit Treasury, ERP, Lieferbedingungen oder tokenisierten Vermögenswerten verbunden werden soll. Eine Zahlung könnte nach geprüfter Warenannahme ausgelöst werden. Ein Wertpapiergeschäft könnte Geld- und Asset-Seite atomar koppeln. Der praktische Nutzen entsteht jedoch erst, wenn Kernbank, Berechtigungen, Limits, Buchhaltung und Ausnahmen ebenso funktionieren wie der Smart Contract.

Stablecoins: Reichweite verlangt klare Rücktauschwege

Stablecoins sind häufig so gestaltet, dass sie außerhalb einer einzelnen Bankbeziehung zwischen Wallets und Plattformen übertragen werden können. Das macht sie für Digital-Asset-Märkte, internationale Zahlungen oder Anwendungen mit mehreren technischen Betreibern attraktiv. Die Reichweite ist aber nur dann belastbar, wenn Ausgabe, Reserve, Einlösung und operative Verantwortung nachvollziehbar geregelt sind.

Für E-Geld-Token legt MiCA wesentliche Eckpunkte fest. Die Europäische Bankenaufsichtsbehörde hält fest, dass jeder Halter einen E-Geld-Token grundsätzlich jederzeit zum Nennwert in der entsprechenden Fiatwährung einlösen kann. Die EBA hat außerdem Leitlinien für geordnete Rücktauschpläne im Krisenfall veröffentlicht. Neben dem normalen Mint-und-Burn-Prozess muss ein Projektteam daher auch Stress, Ausfall und eine geordnete Abwicklung modellieren.

„Reguliert“ bedeutet dennoch nicht, dass alle Umsetzungsfragen erledigt sind. Wer führt die Wallet-Prüfung durch? Welche Transaktionen werden blockiert? Wie werden eingefrorene oder verlorene Schlüssel behandelt? Welche Börsen, Verwahrer und Zahlungsdienstleister sind eingebunden? Wie schnell fließt Geld beim Rücktausch tatsächlich auf ein Bankkonto? Diese Fragen bestimmen, ob ein Stablecoin im Betrieb als verlässliches Zahlungsmittel oder nur als zusätzlicher Abstimmungspunkt wirkt.

Programmierbarkeit ist kein Alleinstellungsmerkmal

Stablecoins werden oft mit 24/7-Verfügbarkeit, bedingten Zahlungen und atomarem Settlement verbunden. Diese Funktionen entstehen vor allem durch die technische Plattform und den angeschlossenen Prozess. Sie sind nicht zwangsläufig an eine bestimmte Geldform gebunden.

Die umfassende Zahlungsverkehrsstrategie des Eurosystems ordnet tokenisierte Einlagen und regulierte Stablecoins deshalb als ergänzende private Settlement Assets ein. Die EZB sieht bei passend gestalteten Stablecoins mögliche Vorteile für Programmierbarkeit, atomare Abwicklung und grenzüberschreitende Reichweite. Zugleich hält sie tokenisierte Einlagen für geeignet, viele derselben funktionalen Vorteile bereitzustellen.

Damit verschiebt sich die Entscheidung vom Funktionsversprechen zur Architektur. Ein Smart Contract kann in beiden Fällen eine Zahlung an Bedingungen knüpfen. Der Unterschied zeigt sich bei den Parteien und Systemen, die vor, während und nach der On-Chain-Transaktion Verantwortung tragen.

Sechs Kriterien für die Auswahl

1. Teilnehmerkreis: Bleibt der Anwendungsfall innerhalb einer Bank oder eines bekannten Bankenkonsortiums? Oder müssen externe Wallets, Börsen, Lieferanten und internationale Partner teilnehmen?
2. Anspruch und Rücktausch: Wer schuldet dem Halter welchen Betrag? Wie funktioniert die Einlösung im Normalbetrieb, bei Betriebsstörungen und bei Ausfall eines Beteiligten?
3. Settlement: Wann ist die Verpflichtung rechtlich und operativ endgültig erfüllt? Bei Zahlungen zwischen Banken ist zu klären, wie Zentralbankgeld oder eine andere finale Abwicklung eingebunden wird.
4. Interoperabilität: Welche DLT-Netzwerke, Kernbankensysteme, Wallets und ISO-20022-Nachrichten müssen zusammenarbeiten? Eine Bridge allein löst weder fachliche Semantik noch Haftung.
5. Compliance und Datenschutz: Wo finden Identitätsprüfung, Sanktionskontrolle, Transaktionsmonitoring und Freigabe statt? Welche Daten dürfen auf dem Ledger stehen und welche nur als Referenz?
6. Betriebsmodell: Wer verantwortet Schlüssel, Rollen, Limits, Softwareänderungen, Notfallverfahren, Abstimmung und Support? Ein Pilot ohne späteren Betreiber testet nur einen Ausschnitt.

Die Kriterien lassen sich in einer Entscheidungsunterlage mit Muss-Anforderungen, offenen Annahmen und nachweisbaren Testfällen festhalten. Das verhindert, dass eine frühe Plattformwahl die fachliche Lösung vorgibt.

Zwei unterschiedliche Einsatzbilder

Programmierbare B2B-Zahlung im Bankenumfeld

Ein Industrieunternehmen möchte Zahlungen an Lieferanten automatisch mit bestätigten Lieferereignissen verbinden. Die beteiligten Unternehmen arbeiten mit wenigen bekannten Banken, Beträge sind hoch und die Buchung soll nahtlos in Treasury und ERP fließen. Hier kann eine tokenisierte Einlagenlösung naheliegen: Die Bankbeziehung, Limits und Compliance-Prozesse bleiben zentral, während die Zahlung auf einer gemeinsamen Plattform programmierbar wird.

Der schwierige Teil liegt nicht im Auslösen des Smart Contracts. Entscheidend sind die Abstimmung zwischen den Banken, die endgültige Erfüllung, Korrekturprozesse und die Verbuchung in den bestehenden Systemen.

Plattformübergreifende Zahlung mit vielen Wallets

Eine Digital-Asset-Plattform möchte Euro-Liquidität über mehrere zugelassene Wallets und Handelsplätze bewegen. Teilnehmer sollen nicht bei derselben Bank kontoführend sein. Ein MiCA-konformer E-Geld-Token kann hier die erforderliche Übertragbarkeit bieten. Dafür müssen Emittent, Reserve- und Rücktauschprozesse, Verwahrung, Transaktionskontrollen sowie die Liquidität an den Ein- und Ausstiegsstellen belastbar sein.

Beide Beispiele können technisch DLT und Smart Contracts verwenden. Die passende Geldform ergibt sich aus Reichweite, Anspruch und Settlement – nicht aus der Zahl der Blockchain-Funktionen.

Was Project Agorá praktisch gezeigt hat

Die Bank für Internationalen Zahlungsausgleich, kurz BIS, testet mit Zentralbanken und Finanzinstituten in Project Agorá einen anderen Schwerpunkt als ein frei zirkulierendes Stablecoin-Modell: tokenisierte Geschäftsbankeinlagen und tokenisierte Zentralbankreserven auf einer gemeinsamen programmierbaren Plattform für grenzüberschreitende Wholesale-Zahlungen.

Bei Tests mit realen Werten im Juli 2026 führten 28 Finanzinstitute und Zentralbanken Transaktionen in sechs Währungen durch. Der BIS-Bericht nennt Firmen- und Interbankzahlungen, Payment versus Payment und konzerninterne Banktransfers. Die Plattform interagierte dabei über etablierte ISO-20022-Nachrichten mit RTGS- und Kernbankensystemen. Das ist für Projektteams ein wichtiger Hinweis: Auch eine neue DLT-Infrastruktur muss mit vorhandenen Zahlungs- und Buchungssystemen zusammenarbeiten.

Agorá belegt noch kein fertiges Marktprodukt. Die BIS bezeichnet das Vorhaben weiterhin als Testumgebung und untersucht neben Technik auch Governance, Settlement Finality, Geldwäscheprävention und Datenschutz. Gerade diese Einschränkung macht das Beispiel nützlich: Reale Werte erfordern Runbooks, Maker-Checker-Freigaben, Fallback-Verfahren und klare Rollen – nicht nur ausführbaren Code.

Zentralbankgeld bleibt eine eigene Ebene

Tokenisierte Einlagen, Stablecoins und tokenisiertes Zentralbankgeld sollten nicht in einen Topf geworfen werden. Zentralbankgeld ist die Verbindlichkeit einer Zentralbank und dient im Interbankenverkehr als neutraler finaler Settlement-Anker. Private Geldformen können darüber konvertierbar gehalten und Verpflichtungen zwischen Instituten erfüllt werden.

Die BIS betont in ihrem Konzept eines tokenisierten Finanzsystems die Verbindung von Zentralbankreserven, Geschäftsbankengeld und tokenisierten Vermögenswerten. Die EZB verfolgt in Europa mit Pontes und Appia ebenfalls das Ziel, DLT-Märkte an Zentralbankgeld und gemeinsame Infrastruktur anzubinden.

Für ein einzelnes Unternehmen bedeutet das nicht, selbst Zentralbankinfrastruktur auswählen zu müssen. Es sollte aber verlangen, dass die beteiligten Banken und Plattformbetreiber den finalen Settlement-Pfad nachvollziehbar erklären können.

Was ein belastbarer Pilot nachweisen sollte

Ein sinnvoll begrenzter Pilot beginnt mit einem konkreten Geschäftsvorgang und dokumentiert den vollständigen Lebenszyklus. Mindestens folgende Nachweise gehören dazu:

• Ausgabe und Rücktausch einschließlich Buchung im führenden System,
• eindeutige Rollen und Berechtigungen für Unternehmen, Bank, Emittent und Betreiber,
• Settlement und Statusübergänge bei einer erfolgreichen Transaktion,
• Ablehnung, Storno, technische Unterbrechung und Wiederaufnahme,
• Abgleich zwischen Ledger, Kernbank, Treasury und Buchhaltung,
• Schlüsselverlust, Sperre sowie Wechsel eines Verwahrers oder Wallet-Anbieters,
• messbare Kriterien für Bearbeitungszeit, Abstimmungsaufwand und Liquiditätsbindung.

Erst danach lässt sich beurteilen, ob die Tokenisierung den bestehenden Ablauf tatsächlich verbessert. Wenn Rücktausch, Ausnahmebehandlung und Systemabgleich überwiegend manuell bleiben, verschiebt das Projekt Komplexität lediglich an den Rand der Plattform.

Die Entscheidung liegt im Prozess, nicht im Token

Tokenisierte Einlagen passen häufig zu Anwendungen, die eine bestehende Bankbeziehung und bankinterne Kontrollen in eine programmierbare Umgebung erweitern. Regulatorisch passende Stablecoins können ihre Stärke ausspielen, wenn Geld über einen breiteren Kreis von Wallets und Plattformen zirkulieren soll. Beide Varianten brauchen klare Ansprüche, robuste Rücktauschwege, verlässliche Compliance und eine Verbindung zur übrigen Finanzinfrastruktur.

Für Banken und Unternehmen ist deshalb eine technologieoffene Voranalyse sinnvoll. Sie beschreibt Parteien, Geldfluss, Settlement, Ausnahmefälle und Systemgrenzen. Erst auf dieser Grundlage sollte entschieden werden, welche Geldform und welche DLT-Architektur den Prozess tragen.