Zum Inhalt springen
Alle Insights KI-Governance & Compliance im Finance-Bereich

MiCA für Stablecoins und Krypto-Zahlungen: Was Engineering-Teams bauen müssen

MiCA übersetzt Regeln für Kryptowerte in konkrete Kontrollen für Emittenten und Zahlungsdienstleister. Hier ist das Monitoring-, Reporting- und Data-Lineage-Engineering, das tatsächlich dahintersteckt.

5 Min. Lesezeit #governance#compliance#stablecoins
Fachleute aus dem Finanzsektor bei der Arbeit an einer KI-Initiative

MiCA (Verordnung (EU) 2023/1114) macht aus den Pflichten rund um Stablecoins und Krypto-Zahlungen Systeme, die du fortlaufend betreiben musst: ein Reserve-Ledger, das täglich gegen die tatsächlich im Umlauf befindlichen Token abgestimmt wird, tagesbezogene Transaktionszähler, die dich rechtlich zur Einstellung der Ausgabe zwingen können, Travel-Rule-Metadaten an jedem Transfer und ein Prüfpfad, mit dem sich jede gemeldete Kennzahl rekonstruieren lässt. Der größte Teil der Compliance-Arbeit ist Data Engineering.

Die Regeln griffen in Stufen. Die Stablecoin-Titel für wertreferenzierte Token und E-Geld-Token gelten seit dem 30. Juni 2024. Das Regime für Dienstleister und die neu gefasste Travel Rule gelten seit dem 30. Dezember 2024. Inzwischen lautet die Frage nicht mehr, ob MiCA auf einen Euro-Stablecoin oder ein Krypto-Zahlungs-Desk anwendbar ist. Sie lautet, ob deine Systeme die Zahlen auf Abruf liefern und belegen können, wie sie berechnet wurden.

Die Reserve ist ein Abstimmungsproblem

Ein EMT-Emittent hält Reserven, die die im Umlauf befindlichen Token vollständig decken, und tauscht zum Nennwert zurück. Ein ART-Emittent unterhält eine Reserve aus Vermögenswerten mit Vorgaben zu Zusammensetzung und Verwahrung. Beide Pflichten laufen in der Praxis auf eine wiederkehrende Engineering-Aufgabe hinaus: die Reserve zu einem Stichtag bewerten, die zu genau diesem Stichtag tatsächlich ausstehenden Token zählen und nachweisen, dass beide Seiten zusammenpassen.

Keine der beiden Seiten lässt sich mühelos festnageln.

  • Die im Umlauf befindlichen Token sind nicht das rohe On-Chain-Supply. Du rechnest verbrannte Token heraus, ziehst ab, was in der Treasury liegt oder gesperrt ist, und aggregierst über jede Chain, auf der du deployt hast. Gebridgtes Supply wird doppelt gezählt, wenn du nicht sorgfältig festlegst, welche Repräsentation maßgeblich ist.
  • Die Reserve-Seite braucht Korrektheit zum Zeitpunkt (Point-in-Time). Ein um 17:00 Uhr ermittelter NAV mit Kursen, die um 17:40 Uhr eintrafen, ist ein Lookahead-Bug im Compliance-Gewand. Die gemeldete Reserve-Kennzahl muss aus den Marktdaten und Verwahrbeständen reproduzierbar sein, die zum Stichtag existierten, nicht aus denen, die später settelten.
  • Die Regeln zu Trennung und Verwahrung bedeuten, dass das Reserve-Ledger gegen externe Verwahrer und Einlagen bei Kreditinstituten abgestimmt werden muss, jeweils mit eigener Auszugsfrequenz und eigener Benennung derselben Position.

Baue das als tägliche Abstimmung mit einem Break-Register auf, nicht als Monatsend-Tabelle. Wenn Umlaufmenge und Reserve-NAV über eine Toleranz hinaus auseinanderlaufen, ist das ein Ereignis, das jemand erklären muss, bevor es zum Rücktauschproblem wird. Die Lineage von einer gemeldeten Reserve-Kennzahl zurück zum Verwahrerauszug und zur Blockhöhe, die das Supply fixierte, ist genau das, woran ein Prüfer ziehen wird.

Zwei Zähler, die dich zur Einstellung der Ausgabe zwingen können

MiCA enthält eine Vorschrift, die Engineers gern übersehen, weil sie sich wie Policy liest. Für ARTs (Artikel 23) und für EMTs, die auf eine Nicht-EU-Währung lauten (Artikel 58), gilt: Wird der Token in großem Umfang als Tauschmittel innerhalb eines einzelnen Währungsraums genutzt und übersteigt die durchschnittliche tägliche Transaktionszahl eine Million sowie der durchschnittliche Tageswert 200 Mio. EUR, muss der Emittent die Ausgabe einstellen und einen Plan vorlegen, um die Nutzung wieder zu senken.

Das ist eine harte Grenze, ausgedrückt als laufendes Aggregat, und sie erzwingt echte Designentscheidungen.

  • Du musst Transaktionen klassifizieren. Ein Transfer zwischen zwei eigenen Wallets eines Nutzers oder ein internes Settlement-Leg auf einer Exchange ist nicht dasselbe wie eine Nutzung als Tauschmittel. Liegt der Classifier in die eine oder andere Richtung falsch, reißt du entweder eine gesetzliche Schwelle, von der du meilenweit entfernt warst, oder du übersiehst eine, die du vor Wochen überschritten hast.
  • Du musst Aktivität einem Währungsraum zuordnen, was bedeutet, Gegenparteien und Endpunkte auf Jurisdiktionen abzubilden, die du verteidigen kannst.
  • Du musst tägliche Aggregate mit Point-in-Time-Korrektheit und ohne Leakage über die Tagesgrenze hinweg berechnen und sie dann über das im Artikel genannte Fenster mitteln.

Warte nicht bis zum Quartalsende, um festzustellen, dass du die Linie überschritten hast. Betreibe eine gleitende Schätzung, damit der Trend sichtbar ist, solange noch Zeit zum Handeln bleibt. Dieselbe Disziplin deckt die Signifikanzkriterien in Artikel 43 ab. Die EBA stuft einen ART erst dann als signifikant ein, wenn mindestens drei Kriterien gleichzeitig erfüllt sind, darunter eine Inhaberzahl über zehn Millionen, ein ausgegebener Wert über 5 Mrd. EUR und tägliche Transaktionskennzahlen über den genannten Linien. Sobald ein Token signifikant ist, geht die Aufsicht auf die EBA über. Inhaber aus Adressen zu zählen ist ein eigenes Entity-Resolution-Problem. Eine Person kann viele Adressen kontrollieren, und eine einzige Verwahradresse kann Guthaben für Millionen Nutzer halten. Eine naive Adresszählung ist keine Inhaberzählung, und sie als solche zu melden, ist ein Defekt, den du wieder aufdröseln musst.

Travel Rule und Screening auf dem Zahlungspfad

Die neu gefasste Geldtransferverordnung (Verordnung (EU) 2023/1113) wendet die Travel Rule auf Kryptowert-Transfers zwischen Dienstleistern an. Anders als bei klassischen Überweisungen gibt es keine Bagatellgrenze: Angaben zu Auftraggeber und Begünstigtem begleiten jeden Transfer, so klein er auch ist. Transfers zu und von selbstverwalteten Wallets tragen ab 1.000 EUR zusätzliche Verifizierungspflichten.

Für das Systems-Team bedeutet das ein paar konkrete Builds.

  • Jeder ausgehende Transfer braucht vollständige, validierte Auftraggeber- und Begünstigtendaten, und jeder eingehende Transfer braucht einen Weg, fehlende oder unvollständige Angaben zu erkennen und zu halten, zurückzusenden oder nachzuverfolgen.
  • Sanktions- und PEP-Screening läuft auf Namen und Kennungen, die unsauber, transliteriert und abgekürzt eintreffen. Das ist ein Entity-Matching-Problem mit einem Budget für False Positives. Screenst du zu locker, lässt du eine sanktionierte Gegenpartei durch. Screenst du zu streng, ersäuft deine Queue, das Straight-Through-Processing bricht zusammen, und legitime Zahlungen bleiben liegen.
  • Flows über selbstverwaltete Wallets brauchen Eigentumsnachweise und Adresszuordnung, was On-Chain-Analytics mit eigenen Konfidenzwerten und eigenem Drift ins Spiel bringt, sobald sich die Clustering-Heuristiken ändern.

Behandle Screening-Schwellen als getunten Parameter mit einem Eval-Set dahinter, nicht als Vendor-Default, den du geerbt hast. Du willst ein gelabeltes Set früherer Alerts, um Precision und Recall zu messen, bevor du eine Schwelle verschiebst, denn jede Verschiebung tauscht Queue-Volumen gegen Escape-Risiko.

Was der Prüfpfad rekonstruieren können muss

MiCA-Emittenten melden zuständigen Behörden zu Inhabern, Reservezusammensetzung und Transaktionsaktivität, und CASPs unterliegen eigenen Aufbewahrungs- und Meldepflichten. Die bindende Bedingung ist die Rekonstruktion. Sechs Monate nachdem du eine Kennzahl gemeldet hast, solltest du sie exakt reproduzieren können: gleiche Inputs, gleicher Stichtag, gleicher Code-Pfad, gleiches Ergebnis.

Das ist eine Lineage-Anforderung, und sie ist unerbittlich in einer Welt aus Chain-Reorganisationen, korrigierten Verwahrerauszügen und verspätet eintreffenden Kursdaten. Versioniere die Inputs. Friere die Berechnung ein. Erhalte die Abbildung von einer gemeldeten Zahl auf die Ereignisse, die sie erzeugten, damit du, wenn die Reserve-Kennzahl in deiner Quartalsmeldung von der in deinem Whitepaper abweicht, präzise sagen kannst, warum, statt zu raten. Das Whitepaper selbst ist eine Behauptung darüber, wie der Token funktioniert und wie die Reserve zusammengesetzt ist, und die Realität muss dazu weiter passen, während sich die Reserve umschichtet.

Nichts davon ist exotische Infrastruktur. Es läuft auf eine ehrlich durchgeführte tägliche Abstimmung hinaus und auf eine Lineage, die du von jeder gemeldeten Zahl rückwärts abschreiten kannst. Die Firmen, die mit MiCA kämpfen, haben diese Zahlen meist als Reports behandelt, die man auf Anfrage erzeugt, dabei sind es Invarianten, die das System an jedem Tag halten muss.

Häufige Fragen

Welche MiCA-Kategorie gilt für einen Euro-Stablecoin?

Ein Token, der auf eine einzelne amtliche Währung wie den Euro Bezug nimmt, ist ein E-Geld-Token (EMT) nach MiCA Titel IV. Sein Emittent muss ein zugelassenes Kreditinstitut oder E-Geld-Institut sein und jederzeit zum Nennwert zurücktauschen.

Welche Tagesschwellen können einen Emittenten zwingen, die Ausgabe einzustellen?

Bei wertreferenzierten Token (Artikel 23) und bei EMTs, die auf eine Nicht-EU-Währung lauten (Artikel 58), muss der Emittent die Ausgabe einstellen und seiner zuständigen Behörde einen Plan vorlegen, wenn die durchschnittliche tägliche Nutzung als Tauschmittel innerhalb eines einzelnen Währungsraums 1 Million Transaktionen und 200 Mio. EUR übersteigt.

Gibt es bei der Krypto-Travel-Rule eine Bagatellgrenze wie bei Überweisungen?

Nein. Nach der Verordnung (EU) 2023/1113 begleiten die Angaben zu Auftraggeber und Begünstigtem jeden Kryptowert-Transfer zwischen Dienstleistern, unabhängig vom Betrag. Die Grenze von 1.000 EUR löst lediglich eine zusätzliche Verifizierung bei Transfers zu oder von selbstverwalteten Wallets aus.

Arbeiten Sie an etwas Ähnlichem?

Erzählen Sie uns von Ihren Daten und dem Workflow drumherum, und Sie bekommen eine ehrliche Einschätzung.

30-minütiges Erstgespräch buchen