MiCAR, Stablecoins und die Compliance-Schicht: Was die Kernbankeninfrastruktur bis H2 2026 bewältigen muss
MiCAR schreibt Reserveanforderungen, Rückkaufverpflichtungen und Transaktionsüberwachungspflichten für Stablecoin-Emittenten und Krypto-Asset-Service-Provider vor. Das sind keine Handelsplatzregeln. Es sind Compliance-Architektur-Anforderungen, die direkt auf die Kernbankeninfrastruktur treffen, und die meisten für Fiat-Einlagen gebauten Compliance-Module sind strukturell nicht gerüstet, sie zu erfüllen.
Das Qivalis-Konsortium (37 europäische Banken in 15 Ländern, geleitet von Sir Howard Davies) zielt auf H2 2026 für einen MiCAR-konformen Euro-Stablecoin ab. Nur 0,2 % der globalen Stablecoins sind heute euro-denominiert. Wenn sich das ändert, landet die Compliance-Arbeitslast bei den Institutionen, die den Token emittieren und verwalten. Die Infrastrukturentscheidung lautet nicht, ob man MiCAR einhält. Sie lautet, ob die Compliance-Architektur MiCARs Anforderungen ohne vollständigen Neubau erfüllen kann.
Was MiCAR tatsächlich verlangt
MiCAR (Verordnung EU 2023/1114, voll durchsetzbar seit Juni 2024) führt zwei relevante regulatorische Kategorien für Kernbanken ein:
E-Money Tokens (EMTs) sind Tokens, die einen stabilen Wert durch Bezug zu einer einzelnen offiziellen Währung aufrechterhalten. Ein euro-denominiertes Stablecoin, der von einer Bank emittiert wird, ist ein EMT. Der Emittent muss 100% Reserve-Deckung in hochliquiden Vermögenswerten halten, sie in einem segregierten Konto getrennt von Betriebsmitteln führen und jeden Token jederzeit zum Nennwert innerhalb eines Geschäftstags einlösen.
Asset-Referenced Tokens (ARTs) beziehen sich auf einen Korb von Vermögenswerten: Währungen, Rohstoffe oder andere Tokens. Die Reserveanforderung beträgt mindestens 2 % des durchschnittlichen ausstehenden Emissionsvolumens, ebenfalls segregiert.
Für beide Tokentypen verlangt MiCAR eine kontinuierliche Transaktionsüberwachung unter denselben AML-Verpflichtungen wie Fiat-Instrumente. Artikel 83 erstreckt AMLD5/6-Verpflichtungen explizit auf Krypto-Asset-Service-Provider und Emittenten. Ein Euro-Stablecoin-Emittent muss Tokentransaktionen gegen Sanktionslisten prüfen, CDD auf Token-Inhaber anwenden und Audit-Trails für Token-Bewegungen führen, nach denselben rechtlichen Standards wie für SEPA-Credit-Transfers.
Die Compliance-Arbeitslast ist nicht additiv. Sie ist strukturell neu.
Wo bestehende Compliance-Module versagen
Die meisten Kernbanken-Compliance-Architekturen operieren mit einer klaren Trennung: Fiat-CDD wird von einer Pipeline bearbeitet (Identitätsverifizierung, AML-Screening, CDD-Policie-Evaluation), und jede Krypto-Exposure durchläuft einen separaten, oft manuell betriebenen Prozess. Diese Trennung ergab Sinn, als Krypto-Aktivität marginal war und Token-Instrumente nicht rechtlich Einlagen gleichgestellt waren.
Unter MiCAR erzeugt die Trennung drei konkrete Fehlermodi.
Fragmentierte CDD-Datensätze. Wenn ein Kunde sowohl eine Euro-Sichteinlage als auch einen Euro-Stablecoin bei derselben Institution hält, ist er ein Kunde mit einem Risikoprofil. Ein einheitlicher CDD-Datensatz muss beide Exposures abdecken. Separate Compliance-Pipelines für Fiat und Token-Instrumente produzieren separate Risikobewertungen, separate Dokumentenspeicher und separate Audit-Trails für dieselbe juristische Person. Sie erzeugen den Anschein zweier unterschiedlicher Compliance-Subjekte, wenn Regulatoren die Aufzeichnungen prüfen.
Inkonsistente Transaktionsüberwachung. Eine AML-Regel, die EUR 10.000 Bartransaktionen markiert, muss denselben Schwellenwert auf EUR 10.000 Token-Transfers anwenden. Wenn das Fiat-Überwachungssystem und das Token-Überwachungssystem keine gemeinsame Schwellenwertkonfiguration und keine gemeinsamen Watchlist-Abonnements teilen, wird eine Transaktion, die in einem System ein Flag auslösen würde, im anderen durchgereicht. Bei regulatorischer Prüfung ist diese Inkonsistenz ein materieller Befund, keine technische Fußnote.
Reserve-Segregation ohne Ledger-Durchsetzung. MiCAR verlangt, dass Reserve-Vermögenswerte, die EMTs decken, in Konten gehalten werden, die rechtlich und operativ getrennt sind von den eigenen Mitteln des Emittenten. Dies ist dieselbe Verpflichtung wie EMD2-Safeguarding für E-Money, aber auf tokenisierte Verbindlichkeiten angewendet. Ein Compliance-Modul, das die Reserve-Bilanz als Reporting-Feld erfasst, statt Segregation als Ledger-Constraint durchzusetzen, kann keine Vermischung verhindern. Eine bei Monatsende entdeckte Vermischung ist bereits ein Regulierungsverstoß.
Die Unified Compliance Architecture
MiCAR ohne Neubau der Compliance-Stack zu erfüllen, erfordert ein Modell, in dem tokenisierte und Fiat-Instrumente durch dieselben Compliance-Primitive fließen, mit tokenspezifischen Parametern auf der Policy-Ebene, nicht hartcodiert in separaten Code-Pfaden.
Einheitliche CDD-Datensätze. Der CDD-Datensatz eines Kunden ist eine Entität, keine Transaktion. Er deckt alle Instrumente ab, die der Kunde bei der Institution hält, unabhängig davon, ob diese Fiat-Salden, Token-Bestände oder Verwahrpositionen sind. Wenn ein neuer Instrumententyp hinzugefügt wird, wie ein neues Stablecoin-Produkt oder ein neuer ART, werden die CDD-Anforderungen durch Nachschlagen der anwendbaren Policy für den Instrumententyp und das Risikoniveau des Kunden aufgelöst. Kein neuer Code-Pfad. Ein neuer Policy-Datensatz.
Geteilter AML-Pipeline. Transaktionsüberwachung gilt unabhängig vom Instrumententyp. Die AML-Screening-Engine empfängt ein normalisiertes Transaktionsereignis (Betrag, Währung oder Token-Identifier, Gegenpartei, Richtung, Zeitstempel) und bewertet es gegen dieselbe Sanktionsliste, PEP-Datenbank und Schwellenwertkonfiguration, die für Fiat-Transaktionen gilt. Der Token-Identifier ist ein Parameter, kein Branch in der Überwachungslogik.
Ledger-erzwungene Reserve-Segregation. Das Reservekonto, das eine Stablecoin-Emission deckt, muss ein erstklassiger Kontentyp im Ledger sein, mit derselben strukturellen Isolation, die EMD2-Safeguarding-Konten erhalten. Überweisungen vom Reservekonto auf Betriebskonten werden blockiert, sofern sie nicht durch einen autorisierten Workflow passieren: denselben durable, gejournaltem Workflow, der die Gebührenextraktion aus E-Money-Safeguarding-Konten regelt. Compliance wird durch die Ledger-Architektur erzwungen, nicht durch eine Reporting-Query, die die Bilanz im Nachhinein prüft.
Das Rückkaufsrecht als Ledger-Constraint
MiCAR Artikel 48 gewährt Token-Inhabern das Recht, jeden EMT jederzeit zum Nennwert einzulösen. Der Emittent muss den Rückkauf innerhalb eines Geschäftstags ausführen. Das ist keine vertragliche Option. Es ist eine regulatorische Verpflichtung mit einer 24-Stunden-Settlement-Frist.
Für Kernbankeninfrastruktur bedeutet Rückkauf auf Verlangen, dass das Ledger einen Token-zu-Fiat-Swap ausführen kann (Verringerung des Token-Saldos des Kunden, Erhöhung seiner Sichteinlage oder Initiierung einer Fiat-Überweisung) innerhalb eines Geschäftstags für jedes Token-Volumen zu jeder Zeit. Das Reservekonto muss ausreichend liquide Vermögenswerte halten, um den Rückkauf ohne Verzögerung zu decken.
Das erzeugt eine Liquiditätsmanagement-Anforderung, die in die Reserve-Architektur zurückwirkt. Die Reserve muss nicht nur existieren und segregiert sein. Sie muss für den Rückkauf sofort verfügbar sein. Eine Institution, die EMT-Reserven in 30-Tage-Instrumenten anlegt, erfüllt zwar die "niedriges Risiko"-Anforderung von MiCAR Art. 36(1)(b), kann aber die 24-Stunden-Rückkaufsfrist nicht einhalten. Die Liquiditätsbegrenzung ist ebenso strikt wie die Reserveanforderung.
Aus Sicht der Workflow-Architektur ist EMT-Rückkauf ein mehrstufiger Vorgang: Token-Saldo validieren, Reserve-Deckung verifizieren, Token-Konto des Kunden belasten und Fiat-Konto gutschreiben, Reserve-Bilanz aktualisieren, Kundenbestätigung senden und Audit-Record produzieren. Alle Schritte müssen innerhalb eines Geschäftstags abschließen. Wenn ein Schritt fehlschlägt, muss der Workflow sauber kompensieren: der Token-Saldo wird nicht belastet, wenn die Fiat-Gutschrift nicht ausführbar ist. Eine Durable-Execution-Engine mit Exactly-Once-Garantien bietet diese Eigenschaft strukturell.
Deutschland, Italien und der Kill-Switch-Vorschlag
Deutschland und Italien haben gemeinsam einen EU-"Kill-Switch"-Mechanismus für nicht konforme globale Stablecoins vorgeschlagen: die Fähigkeit europäischer Regulatoren, spezifische Tokentypen zu blockieren oder einzuschränken, die systemische Risiken darstellen oder MiCAR-Verpflichtungen verletzen. Dieser Vorschlag, Mitte 2026 unter Prüfung, hat direkte architektonische Implikationen.
Ein Kill-Switch erfordert, dass die Compliance-Schicht in Echtzeit auf eine Policy-Entscheidung handeln kann: Blockieren neuer Token-Emissionen, Blockieren von Rückkäufen von spezifischen Adressen oder Blockieren von Transfers über definierte Schwellen, ohne manuellen Eingriff in jede Transaktion. Die Compliance-Engine muss in der Lage sein, ein Policy-Update (eine neue Beschränkung auf einen spezifischen Token oder eine Token-Kategorie) zu empfangen und es sofort auf alle nachfolgenden Transaktionen anzuwenden.
Das ist genau die Anforderung, die hartcodierte Compliance-Logik nicht erfüllen kann. Wenn die Beschränkungslogik im Anwendungscode eingebettet ist, erfordert die Anwendung einer neuen Beschränkung ein Deployment. In einem regulatorischen Umfeld, in dem ein Kill-Switch innerhalb von Stunden aktivieren muss, ist ein Deployment-Zyklus keine tragbare Reaktionszeit. Konfigurationsgetriebene Compliance-Policy, bei der eine neue Beschränkung ein neuer Policy-Datensatz auf der Evaluationsebene ist, handhabt dies ohne Code-Änderung.
Trade-offs
Die Vereinheitlichung von Fiat- und Token-Compliance durch eine geteilte Architektur hat Kosten.
Datenmodell-Komplexität. Ein CDD-Datensatz, der mehrere Instrumententypen abdeckt, erfordert ein abstrakteres Datenmodell als einer, der nur Fiat-Konten abdeckt. Der Instrumententyp-Parameter muss explizit sein in der gesamten Compliance-Pipeline: Screening-Queries, Risikoscoring-Regeln, Audit-Record-Format und Reporting-Templates müssen alle auf Instrumententyp parametrisiert sein, statt Fiat anzunehmen.
Regulatorische Unsicherheit. MiCARs technische Standards sind noch nicht vollständig festgelegt. Die EBA und ESMA erlassen noch regulatorische technische Standards (RTS), die Reserve-Zusammensetzung, Rückkaufsverfahren und AML-Verpflichtungen für spezifische Token-Kategorien präzisieren. Eine für den aktuellen MiCAR-Text gebaute Compliance-Architektur muss für Policy-Änderung entworfen sein: die Regeln werden verfeinert, und die Implementierung muss diese Verfeinerungen durch Konfiguration absorbieren, nicht durch Code-Rewrites.
Reserve-Management-Overhead. Segregierte Reservekonten erfordern eigene Reconciliation, eigenes Liquiditätsmonitoring und eigene regulatorische Berichterstattung. Für Institutionen, die noch nie EMT-Reserven verwaltet haben, ist das neuer operativer Umfang.
Fernel Context
Fernels Compliance-Engine modelliert CDD-Policies als versionierte Datensätze mit vier Dimensionen: Jurisdiktion, Risikoniveau, Prüftyp und Tiefe. Dasselbe Policy-Modell gilt unabhängig vom Instrumententyp: die CDD-Anforderungen eines Euro-Stablecoin-Inhabers werden durch dieselbe Policy-Evaluation-Logik aufgelöst wie die eines Fiat-Kontoinhabers. AML-Screening akzeptiert ein normalisiertes Transaktionsereignis und wendet geteilte Schwellenwertkonfiguration an. Das Ledger erzwingt Reserve-Segregation durch explizite Kontentyp-Constraints: Überweisungen von Reservekonten auf Betriebskonten werden blockiert, sofern sie nicht durch autorisierte durable Workflows passieren. Policy-Änderungen treten durch Record-Updates in Kraft, nicht durch Deployments.
Weiterlesen: Compliance-Infrastruktur | Automatisierung der Kundenkennung | Safeguarding-Architektur für E-Money-Institute
Quellen:
- MiCAR, Verordnung (EU) 2023/1114, Art. 36 (Reserveanforderungen für EMTs), Art. 48 (Rückkaufsrechte), Art. 83 (AML-Verpflichtungen für CASPs)
- Qivalis-Konsortium öffentliche Ankündigung: 37 europäische Banken, 15 Länder, Sir Howard Davies als Chairman, H2 2026 Ziel-Launch
- Cambridge Centre for Alternative Finance, Tokenized RWA Data Q1 2026: 27,5 Milliarden USD on-chain, nur 0,2 % des globalen Stablecoin-Wertes euro-denominiert
- EBA, MiCAR Implementierungsleitlinien und Entwurf regulatorischer technischer Standards (2024-2025)
- EMD2, Richtlinie 2009/110/EG, Art. 7-10 (Safeguarding), zum Vergleich mit MiCAR-Reserveverpflichtungen
- AMLD5, Richtlinie 2018/843, wie durch MiCAR Art. 83 auf CASPs erstreckt