MiCA trifft Verwahrer: Was ab Juli 2026 konkret gilt
Die MiCA-Verordnung ist seit dem 30. Dezember 2024 anwendbar. Für Krypto-Verwahrer in Deutschland und Österreich bedeutet das aber nicht, dass alles schon scharf ist. Die nationalen Übergangsfristen laufen unterschiedlich: In Deutschland endet die Grandfathering-Periode für bereits unter dem KWG lizenzierte Krypto-Verwahrer am 31. Dezember 2025, in Österreich nach der FMA-Auslegung Mitte 2026. Spätestens am 1. Juli 2026 ist Schluss mit den Übergangsregeln. Ab dann gilt vollständig der MiCA-Rahmen, und jeder Crypto-Asset Service Provider braucht eine CASP-Lizenz nach Titel V.
Für die Verwahrung (Custody of Crypto-Assets on Behalf of Clients) sind drei MiCA-Artikel zentral:
- Artikel 70 definiert die Verwahrpflichten: Trennung von Kundenvermögen, Register-Führung pro Kunde, Haftung bei Verlust, Auslagerungsregeln.
- Artikel 72 regelt Interessenkonflikte: Wer verwahrt, darf nicht ohne Weiteres handeln, was Verflechtungen mit Tradingdesks neu aufstellt.
- Titel VI samt Verweis auf die AMLR verlangt risikobasierte Geldwäscheprävention, abgestimmt mit der neuen EU-AML-Verordnung und der Travel Rule (Transfer of Funds Regulation, Verordnung 2023/1113).
Wichtig: MiCA ersetzt die nationale Aufsicht nicht. BaFin und FMA bleiben zuständige Behörden. Das KWG-Regime für Kryptoverwahrgeschäft (§ 1 Abs. 1a Satz 2 Nr. 6 KWG) wird mit der CASP-Lizenz harmonisiert, aber die operative Aufsicht inklusive Vor-Ort-Prüfungen läuft weiter über die nationalen Behörden. Wer denkt, eine MiCA-Lizenz aus Malta oder Litauen schütze vor BaFin-Anfragen, irrt.
Warum klassisches AML-Screening bei Krypto nicht mehr reicht
Das grundlegende Dilemma: Blockchain-Adressen sind pseudonym, aber jede Transaktion ist transparent und unwiderruflich nachvollziehbar. Klassische AML-Systeme aus dem Bankgeschäft sind auf IBAN und SWIFT zugeschnitten. Sie prüfen Absender und Empfänger gegen Sanktionslisten, monitoren Schwellenwerte, melden bei Auffälligkeiten. Bei On-Chain-Transfers funktioniert das nicht.
Drei Gründe:
Erstens, eine Wallet-Adresse ist kein Kunde. Eine einzelne Person kann hunderte Adressen kontrollieren. Eine einzelne Adresse kann zu einer Börse, einem Mixer oder einem DeFi-Protokoll gehören, hinter dem tausende Nutzer stehen. Wer nur die Adresse screent, screent nichts Verwertbares.
Zweitens, die FATF Travel Rule, in der EU umgesetzt durch die Transfer of Funds Regulation und referenziert in MiCA Artikel 83, verlangt Identifikationsdaten zu Absender und Empfänger bei Krypto-Transfers ab einem Euro. Das ist deutlich strikter als im klassischen Zahlungsverkehr. Wer als Verwahrer eingehende Transfers von externen Wallets erhält, muss wissen, wem diese Wallets gehören.
Drittens, die Risikolandschaft ist dynamisch. Sanktionierte Adressen wechseln. Mixer entstehen und verschwinden. DeFi-Protokolle werden gehackt und gewaschene Coins fließen über Bridges weiter. Ein statisches Regelwerk veraltet innerhalb von Wochen.
Die regulatorische Erwartung lautet daher: Verwahrer müssen Wallets identifizieren und kontinuierlich neu bewerten. Ohne ML-gestützte Tools ist das mit vertretbarem Personalaufwand nicht zu leisten.
KI-Workflow 1: Wallet-Clustering für die Gegenparteien-Identifikation
Wallet-Clustering ist die Disziplin, mehrere Adressen einer gemeinsamen Entität zuzuordnen. Wenn ein Kunde Bitcoin von einer externen Adresse einzahlt, muss der Verwahrer entscheiden: Gehört diese Adresse zu einer regulierten Börse, zu einem privaten Wallet, zu einem sanktionierten Akteur, zu einem Mixer?
Die klassische Heuristik ist Common-Input-Ownership: Wenn zwei Adressen in einer Transaktion gemeinsam als Inputs auftauchen, gehören sie wahrscheinlich derselben Wallet. Diese Heuristik funktioniert bei Bitcoin gut, bei UTXO-basierten Chains generell. Sie scheitert bei Ethereum, bei Account-Modellen, bei CoinJoin-Transaktionen.
Hier setzen Graph Neural Networks an. Eine Blockchain ist ein riesiger gerichteter Graph: Adressen sind Knoten, Transaktionen sind Kanten. GNNs lernen aus markierten Beispielen (bekannte Börsen-Adressen, bekannte Mixer, bekannte Scam-Wallets) Muster, die über die reine Topologie hinausgehen. Transaktionsfrequenz, Zeitmuster, typische Beträge, Verbindungen zu anderen geclusterten Entitäten fließen als Features ein. Das Modell schlägt für eine neue Adresse vor: Diese Wallet gehört mit 87 Prozent Wahrscheinlichkeit zu Binance, oder mit 64 Prozent zu einem nicht-kustodialen Wallet eines Privatnutzers.
Welchen MiCA-Bezug hat das konkret? Artikel 70 Absatz 1 verlangt eine eindeutige Zuordnung verwahrter Vermögenswerte zu Kunden. Die Travel-Rule-Umsetzung verlangt Identifikation der Gegenpartei. Wer ein dokumentiertes Clustering-Verfahren mit nachvollziehbaren Konfidenzwerten betreibt, kann diese Pflicht prüffähig erfüllen.
Ein typisches Integrationsmuster im KYC-Onboarding sieht so aus: Beim ersten Deposit auf eine Kunden-Wallet läuft die Eingangsadresse durch das Clustering-Tool. Erkennt das System eine geclusterte Entität mit ausreichender Konfidenz, geht der Vorgang in den Standardprozess. Liegt die Konfidenz unter dem Schwellwert oder zeigt das Cluster Risikomerkmale, geht der Vorgang in die manuelle Compliance-Prüfung. Schwellwerte sind Modell-Governance-Fragen und gehören dokumentiert.
KI-Workflow 2: Echtzeit-Sanktions-Screening On-Chain
OFAC SDN List, EU-Sanktionsregime, HM Treasury Consolidated List. Diese Listen wachsen und ändern sich wöchentlich. Im klassischen Zahlungsverkehr matcht man Namen und Konten gegen die Listen. On-Chain matcht man Adressen.
Das Problem: Sanktionierte Adressen tauchen selten direkt als Gegenpartei auf. Wer einen Tornado-Cash-Pool nutzt, sendet nicht direkt von der OFAC-gelisteten Tornado-Adresse. Er empfängt von einer frischen Adresse, die zwei oder drei Hops vom sanktionierten Smart Contract entfernt ist. Genau dafür braucht es Exposure-Scoring: Wie weit ist die eingehende Adresse von einer sanktionierten Quelle entfernt, und wie hoch ist der wertmäßige Anteil sanktionierter Mittel im Cluster?
Kommerzielle Tools wie Chainalysis KYT, Elliptic Navigator und TRM Labs liefern hier brauchbare Basisarbeit. Sie pflegen die Listen, bauen die Graphen, liefern API-basierte Risk Scores. Wer als kleinerer Verwahrer schnell live gehen muss, kommt um eine SaaS-Lösung selten herum.
Aber: Die Scoring-Logik dieser Tools ist proprietär. Für die BaFin-Prüfung ist das ein Problem. Wenn der Aufseher fragt, warum eine bestimmte Adresse als „medium risk” eingestuft wurde, reicht „Chainalysis sagt das” nicht. Sie müssen die Methodik erklären können, mindestens auf konzeptioneller Ebene. Und Sie müssen eigene Override-Logiken haben, in denen das Institut bestimmte Anpassungen vornimmt: höhere Schwellwerte für bestimmte Jurisdiktionen, eigene Watchlists, institutsspezifische Risikoappetit-Parameter.
In BaFin-Anfragen tauchen typischerweise diese Punkte auf: Wie häufig werden die Sanktionslisten synchronisiert? Wie wird mit False Positives umgegangen? Wer entscheidet über Freigabe oder Blockade einer Transaktion? Gibt es einen dokumentierten Eskalationspfad? Wer keine sauberen Antworten hat, bekommt Auflagen.
KI-Workflow 3: Kontinuierliches Transaktionsmonitoring und Anomalie-Erkennung
Wallet-Clustering und Sanktions-Screening greifen am Onboarding und beim einzelnen Transfer. Das laufende Monitoring ist eine andere Disziplin. Hier geht es um Muster über Zeit: Verändert sich das Transaktionsverhalten eines Kunden auffällig? Tauchen Verbindungen zu neu gelisteten Risikoadressen auf? Fließen Mittel über Mixer oder Bridges in untypischer Frequenz?
Statische Schwellenwerte versagen hier schnell. „Alarm bei Transfers über 100.000 Euro” fängt das offensichtliche Risiko ab, aber nicht den DeFi-Nutzer, der in 50 Tranchen zu je 1.800 Euro Liquidität aus einem gehackten Protokoll bezieht. ML-basierte Modelle arbeiten verhaltensbasiert: Peer-Group-Analyse (wie verhalten sich Kunden mit ähnlichem Profil?), Velocity-Checks (wie schnell ändert sich das Aktivitätsmuster eines Kunden?), Mixer-Erkennung über typische Transaktionsstrukturen.
Die Integrationsfrage ist hier entscheidend. Ein ML-Modell, das täglich tausende Alerts produziert, ist nutzlos, wenn die Compliance-Abteilung sie nicht abarbeitet. Drei Komponenten sind kritisch:
- API-Anbindung an das Core-System des Verwahrers. Alerts müssen kontextualisiert sein, mit Kundendaten, Transaktionshistorie, vorherigen Bewertungen.
- Alert-Triage mit Priorisierung. Nicht jeder Alert braucht denselben Eskalationspfad. Das Modell soll Konfidenz und Schweregrad mitliefern.
- Human-in-the-Loop. Die finale Entscheidung über Meldungen an die FIU (in Deutschland die Zentralstelle für Finanztransaktionsuntersuchungen, in Österreich die A-FIU) bleibt beim Compliance Officer. Das Modell unterstützt, entscheidet aber nicht.
MiCA Artikel 68 verlangt unter anderem die laufende Dokumentation aller relevanten Vorgänge zur Verwahrung. Für ML-gestützte Monitoring-Systeme heißt das: Jeder Alert, jede Bewertung, jede Aktion muss mit Zeitstempel, Modellversion, Input-Daten und menschlicher Entscheidung im Audit-Trail liegen. BaFin-konform heißt: nachvollziehbar auch in zwei Jahren, auch wenn das Modell zwischenzeitlich dreimal neu trainiert wurde.
Was BaFin schon heute nachfragt
Die Erfahrungen aus aktuellen BaFin-Anfragen an Krypto-Verwahrer lassen sich grob in drei Themenfelder einsortieren. Erstens Methodik der Risikoklassifizierung: Wie kommt ein Score zustande? Welche Datenquellen fließen ein? Wer pflegt die Schwellwerte? Zweitens Modell-Performance: Wie hoch ist die False-Positive-Quote? Wie wird sie gemessen? Welche Konsequenz hat das für die Personalplanung in der Compliance? Drittens Modell-Governance: Wer verantwortet das Modell? Wie oft wird es neu trainiert? Wie werden Drift und Performance-Verschlechterung erkannt?
Die wichtigste Falle ist Explainability. Wenn ein Verwahrer eine Black-Box-Lösung einsetzt, die für jede Wallet einen Risikoscore zwischen 0 und 100 ausspuckt, aber niemand erklären kann, warum diese spezifische Wallet 73 statt 41 erhält, bekommt der Aufseher Zweifel an der gesamten AML-Funktion. Aus meiner Sicht ist das der häufigste Gesprächspunkt in laufenden Prüfungen.
Empfehlung: Setzen Sie XAI-Verfahren wie SHAP oder LIME ein, um für jeden Score zumindest die Top-Feature-Beiträge dokumentieren zu können. Das muss nicht in jedem Kundenfall live laufen. Es reicht, wenn Sie auf Nachfrage für jeden Alert eine Erklärung generieren können, die zeigt, welche Faktoren den Score getrieben haben.
Implementierungs-Roadmap: Von der Pflicht zum Betrieb
Wer heute startet, hat noch ausreichend Zeit für ein sauberes Vorgehen in drei Phasen.
Phase 1, sofort. Gap-Analyse der bestehenden AML-Prozesse gegen MiCA und die nationalen Anforderungen. Welche Workflows existieren, welche Datenquellen sind angebunden, wo ist die Lücke zwischen aktueller Praxis und der Erwartung ab Juli 2026? Dieser Schritt dauert sechs bis acht Wochen und produziert eine priorisierte Maßnahmenliste.
Phase 2, Q3 2025 bis Q1 2026. Tool-Auswahl, Integration in die bestehende KYC- und Transaktionsinfrastruktur, Testbetrieb mit historischen Transaktionen. Hier entscheidet sich, ob Sie eine SaaS-Lösung nehmen, ein eigenes Modell bauen oder eine Mischform fahren. Faustregel: Bei weniger als 50.000 Transaktionen pro Monat lohnt sich ein eigenes Modell selten. Bei kritischen Spezialfällen (etwa wenn Sie viele DeFi-affine institutionelle Kunden haben) brauchen Sie eigene Logik on top des SaaS-Tools.
Phase 3, vor Juli 2026. Go-Live im Produktivbetrieb, Vorlage der Methodik-Dokumentation bei BaFin oder FMA im Rahmen der CASP-Lizenzierung oder laufenden Aufsicht, Aufbau des kontinuierlichen Modell-Monitorings. Spätestens jetzt brauchen Sie einen benannten Verantwortlichen für die KI-Modelle in der AML-Funktion. Diese Rolle wird in Stellenanzeigen noch selten ausgeschrieben, ist aber faktisch Pflicht.
Die Entscheidungsmatrix SaaS versus Eigenbau lässt sich grob so zusammenfassen: SaaS für Sanktions-Screening und Standard-Wallet-Clustering, Eigenbau oder Customizing für institutsspezifisches Verhaltens-Monitoring und für die Erklärbarkeit gegenüber der Aufsicht.
Fazit: KI ist Betriebspflicht, nicht Innovationsspielerei
MiCA verlangt von Krypto-Verwahrern, was im klassischen Bankgeschäft seit Jahren Standard ist: lückenlose Geldwäscheprävention, dokumentierte Risikobewertung, prüffähige Workflows. Die Besonderheit ist die On-Chain-Natur der Vermögenswerte. Ohne ML-gestützte Tools sind die Pflichten nicht erfüllbar, weder personell noch fachlich.
Drei Workflows decken die Kernanforderungen ab: Wallet-Clustering für die Gegenparteien-Identifikation (MiCA Art. 70, Travel Rule), Echtzeit-Sanktions-Screening für die laufende Compliance (EU- und nationale Sanktionsregime), ML-basiertes Transaktionsmonitoring für die kontinuierliche Risikobewertung (MiCA Art. 68, AML-Pflichten). Wer alle drei dokumentiert betreibt, hat eine belastbare Grundlage für CASP-Lizenz und laufende Aufsicht.
Der kritische Punkt ist Erklärbarkeit. BaFin und FMA akzeptieren keine Black Boxes. Wer KI einsetzt, muss erklären können, warum das Modell entscheidet, wie es entscheidet. Wer das nicht kann, bekommt Auflagen oder verliert die Lizenz.
Ich berate Verwahrer und CASP-Antragsteller in DACH bei der Gap-Analyse gegen MiCA, der Tool-Auswahl und der BaFin- beziehungsweise FMA-konformen Dokumentation der KI-Workflows. Wer im Sommer 2026 produktiv sein will, sollte spätestens im ersten Quartal 2025 mit der Vorbereitung beginnen.