Einleitung: Von Legal Requirements zu Engineering Tasks
Die Markets in Crypto-Assets Regulation (MiCA) wird oft als „rein rechtliches" Thema wahrgenommen – doch für Product Manager, Solution Architects und Tech Leads bedeutet MiCA vor allem eines: konkrete Anforderungen an Systeme, Prozesse und Datenarchitektur. MiCA verlangt nicht nur Dokumentation und Policies, sondern die tatsächliche technische Umsetzung von IT-Governance, Operational Resilience, Incident Management und Datenschutz.
Dieser Playbook übersetzt die regulatorischen Anforderungen aus MiCA, ESMA-Guidelines und nationalen Aufsichtserwartungen in die Sprache von Product und Engineering. Er zeigt, welche Backlog Items entstehen, welche Architektur-Patterns benötigt werden und welche Checklisten vor Go-Live abzuarbeiten sind. Der Fokus liegt auf Crypto-Asset Service Providern (CASPs) im DACH-Raum, die Inhalte sind jedoch für alle EU-Jurisdiktionen relevant.
Zielgruppe: Product Managers, CTOs, Solution Architects, Engineering Leads und Compliance-Teams von EU-Krypto-Projekten, die eine CASP-Zulassung vorbereiten oder bereits unter MiCA operieren.
Stand der Informationen: 12. Januar 2026
1. MiCA-Pflichten in Tech-Sprache übersetzt
MiCA stellt organisatorische, IT-Sicherheits- und Outsourcing-Anforderungen, die direkt in konkrete Product- und Tech-Aufgaben übersetzt werden müssen. Die folgende Mapping-Tabelle verknüpft MiCA-Artikel und ESMA-Guidelines mit typischen Backlog Items für Product/IT-Teams.
Mapping-Tabelle: Norm → Beschreibung → Typische Backlog-Items
| Regulatorische Grundlage | Anforderung (Plain Language) | Typische Product/IT To-Dos |
|---|---|---|
| Art. 61, 63 MiCA: Organisational requirements, internal control framework | CASPs müssen effektive Governance-Strukturen, interne Kontrollen und klare Verantwortlichkeiten für Geschäfts- und IT-Risiken etablieren. | • ICT-Policy dokumentieren (Scope, Rollen, Verantwortlichkeiten) • ICT Risk Owner bestimmen (C-Level oder designated function) • Change Management Process definieren (Approval Workflow, Testing, Rollback) • Release Management dokumentieren (Stages, Sign-offs, Post-deployment Checks) • Access Control Policy erstellen (Role-based Access, Least Privilege, Review Cycles) • Segregation of Duties umsetzen (Dev vs. Prod Access, 4-Eyes-Principle für kritische Changes) |
| Art. 66 MiCA: Complaint handling and incident reporting | CASPs müssen wirksame Beschwerde- und Incident-Handling-Prozesse einrichten; wesentliche Incidents sind der zuständigen Aufsicht zu melden. | • Incident Classification definieren (Severity Levels: Critical/High/Medium/Low) • Incident Response Process aufsetzen (Detection → Containment → Eradication → Recovery → Lessons Learned) • Runbooks für häufige Incidents erstellen (z.B. Wallet-Compromise, API-Downtime, DDoS) • Incident Log zentral führen (Timestamp, Description, Impact, Actions Taken, Resolution) • Notification Triggers festlegen (Wann muss NCA informiert werden? Welche Fristen?) • Post-Incident Review etablieren (Root Cause Analysis, Prevention Measures) |
| Art. 68 ff. MiCA: Safekeeping of crypto-assets and funds, operational risk management | CASPs müssen Kundengelder und Crypto-Assets segregiert verwahren, operationelle Risiken managen und technische Sicherheitsstandards einhalten. | • Client Asset Segregation implementieren (separate Wallets/Accounts per Client, kein Co-Mingling) • Cold/Hot Wallet Strategy definieren (Ratio, Threshold für Transfers, Multi-Sig) • Key Management Process dokumentieren (Key Generation, Storage, Rotation, Backup, Recovery) • Reconciliation Process aufsetzen (Daily/Real-time Balance Checks zwischen Ledger und Blockchain) • Security Baseline definieren (Encryption Standards, Network Segmentation, Intrusion Detection) • Backup & Disaster Recovery testen (RPO/RTO, Backup Frequency, Off-site Storage, Restore Drills) |
| ESMA Guidelines (Art. 14(1)(d) MiCA): Maintenance of systems and security access protocols | Emittenten und Personen, die Crypto-Assets zum Handel anbieten, müssen ihre Systeme und Sicherheitsprotokolle gemäß EU-Standards unterhalten. Hinweis: Diese Guidelines betreffen formal primär Issuers, nicht CASPs; nationale Aufsichten wie FMA und AMF haben jedoch signalisiert, dass sie diese Prinzipien analog auch bei CASPs berücksichtigen, da ähnliche IT-Sicherheitsanforderungen gelten. | • Physical Security Protocol dokumentieren (Data Center Access Control, Visitor Logs, CCTV) • Logical Access Control umsetzen (MFA, Password Policy, Session Timeouts, Privileged Access Management) • Cryptographic Key Management Policy erstellen (Algorithm Standards, Key Length, Storage Methods) • Network Security hardening (Firewalls, VPN, Penetration Tests). Die konkreten technischen Maßnahmen (z. B. Zero Trust Architecture, SIEM-Systeme) sind anhand interner Risk Appetite und Marktstandards festzulegen; MiCA schreibt keine spezifischen Technologien vor. • Logging & Monitoring aufsetzen (Centralized Logging, Alert Rules, Log Retention per MiCA/AML) • Vulnerability Management etablieren (Regular Scans, Patch Management, CVE Tracking) |
| MiCA Outsourcing Provisions (Art. 63(6), Recitals) + ESMA Supervisory Briefing on CASP Authorisation | CASPs bleiben für ausgelagerte Funktionen verantwortlich; „wichtige" oder „kritische" Funktionen erfordern strengere Kontrollen. Outsourcing darf CASP nicht zu „Briefkastenfirma" machen. | • Outsourcing Register aufsetzen (Vendor, Service, Criticality, Contract Details, Review Date) • ICT Third-Party Risk Assessment durchführen (Vendor Due Diligence, Financial Stability, Security Certifications) • Contract Clauses prüfen/einfordern (Audit Rights, Data Access for NCA, Sub-Outsourcing Approval, Exit/Reversibility) • Sub-Outsourcing Control implementieren (Visibility über gesamte Lieferkette, Approval Process) • Exit Strategy dokumentieren (Transition Plan bei Vendor-Wechsel, Data Portability, Service Continuity) • Monitoring von Outsourced Services (SLAs, Performance Metrics, Regular Reviews, Escalation Paths) |
| ESMA Guidelines on Knowledge & Competence (Art. 81 MiCA) | Staff, die Kunden über Crypto-Assets informieren oder beraten, müssen nachweisbare Kenntnisse über Funktionsweise, Risiken und regulatorische Anforderungen besitzen. | • Training Program aufsetzen (Initial Training for Client-Facing Staff, MiCA/Tokenomics Basics, Risk Disclosures) • Assessment & Certification process (Internal Tests, External Certifications, Documentation) • Continuing Professional Development (CPD) planen (Annual Refreshers, Updates bei regulatorischen Änderungen) • Documentation for NCA Inspections (Training Records, Assessment Results, Staff Competence Matrix). |
Wichtiger Hinweis: Diese Tabelle ist als Orientierung gedacht und erhebt keinen Anspruch auf Vollständigkeit. Jedes Projekt sollte eine eigene Gap-Analyse durchführen und spezifische Anforderungen mit Legal/Compliance abstimmen.
2. Architecture-Ebenen unter MiCA
Eine MiCA-konforme Architektur lässt sich in drei Haupt-Layer unterteilen, die jeweils spezifische regulatorische Anforderungen erfüllen müssen:
2.1 Identity / KYC-Layer
Regulatorischer Kontext: CASPs unterliegen den EU-AML-Richtlinien und der Transfer of Funds Regulation (TFR / „Travel Rule"). KYC-Prozesse müssen nicht nur initial bei Onboarding erfolgen, sondern laufend aktualisiert werden (Ongoing Monitoring, Periodic Reviews). Zudem müssen KYC-Daten und Entscheidungslogik vollständig nachvollziehbar und auditierbar sein.
Technische Anforderungen:
- Integration mit AML-Frameworks: Anbindung an EU-weite/nationale Sanktionslisten (EU, OFAC, UN), PEP-Datenbanken, Adverse Media Screening, Risk Scoring Models.
- KYC Data Storage: Sichere, verschlüsselte Speicherung von Identitätsdokumenten und Verifikationsergebnissen; Zugriff nur nach Need-to-Know-Prinzip (RBAC).
- KYC Decision Logging: Jede KYC-Entscheidung (Approved/Rejected/Escalated) muss mit Timestamp, Decision Maker, Rationale und verwendeten Data Points geloggt werden.
- Travel Rule Compliance (TFR): Unter der Transfer of Funds Regulation gelten umfassende Informationspflichten für Crypto-Transfers (Originator/Beneficiary Data, Wallet-Adressen); erweiterte Anforderungen ab Schwellenwerten (z. B. 1.000 EUR); die konkreten Anforderungen ergeben sich aus der jeweils gültigen Fassung der TFR. Dies erfordert technische Lösungen wie IVMS101-Messaging oder vergleichbare Standards für den Informationsaustausch zwischen CASPs.
- Data Retention: KYC-Daten müssen gemäß nationalen AML-Gesetzen (typischerweise 5–10 Jahre) aufbewahrt werden; gleichzeitig sind GDPR-Vorgaben zu beachten (Recht auf Löschung bei berechtigtem Interesse).
- KYC-API mit Third-Party-Provider integrieren (z.B. Jumio, Onfido, Sumsub; genannte Provider dienen nur als Beispiele; MiCA schreibt keine bestimmten Anbieter vor)
- Travel Rule Messaging implementieren (IVMS101, Notabene, Sygna, oder eigene Lösung)
- KYC-Decision-Audit-Trail aufbauen (DB-Schema, Logging-Service, Query-Interface für Compliance)
- RBAC für KYC-Daten implementieren (nur Compliance-Team und designated Auditors haben Full Access)
Regulatorischer Kontext: MiCA und EU-Market-Abuse-Regeln verlangen vollständige Nachvollziehbarkeit von Orders und Transaktionen. CASPs müssen in der Lage sein, verdächtige Aktivitäten (Market Manipulation, Insider Trading, Wash Trading) zu erkennen und zu melden.
Technische Anforderungen:
- End-to-End Transaction Logging: Jede Order (placed, modified, cancelled, executed) muss mit Timestamp, User ID, Order Details, Execution Details geloggt werden.
- Blockchain Transaction Tracking: Für On-Chain-Transaktionen: vollständige Logs von Blockchain TX-Hashes, Sender/Receiver Addresses, Amounts, Confirmations.
- Anomaly Detection & Monitoring: Algorithmen oder Regel-basierte Systeme zur Erkennung von:
- Ungewöhnlichen Handelsvolumina oder -mustern
- Wash Trading (Self-Dealing)
- Sudden Price Movements (Pump & Dump Indicators)
- Layering, Spoofing, Frontrunning
- Reconstruction Capability: Die Aufsichtsbehörde muss in der Lage sein, jede Transaktion von Anfang bis Ende zu verfolgen (Order Book Snapshots, Match Engine Logs, Settlement Records).
- Real-Time Alerting: Bei Verdacht auf Market Abuse müssen Compliance-Teams in Echtzeit informiert werden (z.B. via SIEM-Integration oder dediziertes Surveillance-Tool).
- Transaction Logging Service implementieren (High-Volume, Low-Latency, Append-Only Log)
- Anomaly Detection Rules definieren (Thresholds, Alert Triggers, Escalation Workflow)
- Order Book Snapshot Mechanism aufbauen (Periodic Snapshots für Audit/Reconstruction)
- Market Abuse Surveillance Dashboard für Compliance-Team (Real-Time Alerts, Investigation Workflow)
Regulatorischer Kontext: MiCA und AML verlangen strikte Data Retention Policies, während GDPR das Recht auf Löschung und Datenportabilität garantiert. Zudem müssen alle Zugriffe und Änderungen an sensiblen Daten auditierbar sein.
Technische Anforderungen:
- Data Retention Policies:
- MiCA-relevante Daten (Orders, Transactions, Incident Logs, Client Communications): typischerweise 5 Jahre
- AML-Daten (KYC, Transaction Monitoring Logs): konkret durch das jeweilige nationale AML-Recht vorgegeben (typischerweise 5–10 Jahre)
- Automatisierte Löschung nach Ablauf der Retention Period (sofern keine rechtlichen Holds bestehen)
- Encryption at Rest & in Transit: Alle sensiblen Daten (PII, KYC-Dokumente, Private Keys, Transaction Details) müssen verschlüsselt gespeichert und übertragen werden. Die konkreten technischen Standards (z. B. Algorithmus, Key-Länge, Protokollversion wie AES-256, TLS 1.2+) sind anhand aktueller Marktstandards und interner Risk Appetite festzulegen; MiCA schreibt keine spezifischen Algorithmen vor.
- Audit Trail für Data Access: Jeder Zugriff auf sensible Daten (wer, wann, welche Daten, Zweck) muss geloggt werden.
- Backup & Disaster Recovery:
- Regelmäßige Backups (täglich oder häufiger für kritische Systeme)
- Off-Site Storage (geografisch getrennt)
- Recovery Point Objective (RPO) und Recovery Time Objective (RTO) definieren und testen
- Restore Drills durchführen (mindestens jährlich)
- Data Geography & Outsourcing: Bei Cloud-Storage muss klar sein, wo Daten physisch gespeichert sind (EU vs. Non-EU). Bei Non-EU-Storage können zusätzliche Datenschutz- und Aufsichtsanforderungen entstehen.
- Data Retention Policy Engine implementieren (Automated Data Lifecycle Management, Archiving, Deletion)
- Encryption-at-Rest für alle DBs aktivieren (RDS Encryption, Disk Encryption, Key Management via HSM oder Cloud KMS)
- Audit Logging für DB-Zugriffe aufsetzen (DB Audit Logs, Integration mit SIEM, Alerting bei anomalen Access Patterns)
- Backup Strategy testen (RPO/RTO messen, Restore Drill durchführen, Dokumentation aktualisieren)
- Data Geography Mapping erstellen (Welche Daten liegen wo? Compliance-Check mit GDPR/MiCA Outsourcing Rules)
Outsourcing – insbesondere von kritischen IT-Funktionen und Cloud-Services – ist eines der sensiblen Themen unter MiCA. Die Aufsichtsbehörden wollen sicherstellen, dass CASPs nicht zu „Briefkastenfirmen" werden und dass sie jederzeit die Kontrolle über ihre Prozesse und Daten behalten.
3.1 MiCA Outsourcing-Grundsätze
Art. 63(6) MiCA und relevante Recitals stellen klar:
- CASPs bleiben voll verantwortlich für ausgelagerte Funktionen.
- Outsourcing darf die Beaufsichtigungsfähigkeit der NCA nicht beeinträchtigen (d.h. die Aufsicht muss jederzeit Zugang zu Systemen, Daten und Prozessen haben).
- „Wichtige" oder „kritische" Funktionen (z.B. Compliance, Risk Management, Core IT) erfordern besondere Sorgfalt und strengere vertragliche Regelungen.
- Outsourcing darf nicht dazu führen, dass der CASP de facto die operative Steuerung verliert (Letter-Box-Problem).
ESMA hat in ihrem Supervisory Briefing (entwickelt in Zusammenarbeit mit NCAs während der Transitionsphase) folgende Erwartungen formuliert:
- Substance Assessment: NCAs prüfen, ob der CASP „tatsächlich" in der Home Jurisdiction tätig ist oder ob wesentliche Funktionen ausgelagert sind und nur eine „Fassade" verbleibt.
- Depth of Outsourcing: Je mehr Funktionen ausgelagert werden, desto kritischer die Prüfung. CASPs müssen nachweisen, dass sie über eigene ICT Key Staff verfügen, die ausgelagerte Services überwachen und steuern können.
- Monitoring Outsourced Functions: CASPs müssen kontinuierlich die Performance und Compliance der Outsourcing-Partner überwachen (SLAs, KPIs, Regular Audits).
Obwohl diese Guidelines primär für Issuers und Persons seeking admission to trading gelten, enthalten sie wichtige Prinzipien, die auch für CASPs relevant sind:
- ICT Third-Party Risk Management: Identifizierung und Bewertung von IT-Dienstleistern; Kategorisierung nach Kritikalität.
- Sub-Outsourcing Control: Outsourcing-Partner dürfen Leistungen nicht einfach weiter-outsourcen; CASP muss Sub-Outsourcing genehmigen und Visibility über die gesamte Lieferkette haben.
- Contractual Clauses: Verträge müssen enthalten:
- Audit Rights für CASP und NCA
- Data Access für Aufsichtsbehörden
- Change Management: Outsourcing-Partner muss wesentliche Änderungen vorab mitteilen und genehmigen lassen
- Exit/Reversibility: Klare Regelungen, wie Services bei Vertragsende oder -kündigung überführt werden können
Die österreichische FMA hat in ihrer Publikationsreihe „Let's talk about supervision" (Ausgabe 01) speziell das Thema Outsourcing von Kerndienstleistungen bei CASPs behandelt:
- Core Services umfassen Compliance, Risk Management, IT-Operations und Custody-Funktionen.
- Die FMA betont, dass Outsourcing dieser Funktionen nur unter strengen Auflagen möglich ist.
- CASPs müssen nachweisen, dass sie reale Kontrolle über ausgelagerte Core Services behalten – durch eigene Mitarbeiter, die fachlich kompetent sind, durch regelmäßige Audits und durch vertragliche Steuerungsmöglichkeiten.
- Die FMA prüft im Zulassungsverfahren intensiv, ob ein CASP über ausreichend eigene Substance verfügt oder ob ein „Letter-Box"-Risiko besteht.
Die französische AMF hat in ihrer Instruction DOC-2025-05 detaillierte Anforderungen an die Vollständigkeit von CASP-Anträgen formuliert, darunter:
- Documented Outsourcing Policy: Beschreibung der Grundsätze, nach denen Outsourcing-Entscheidungen getroffen werden (z.B. Kritikalitätsbewertung, Vendor Selection Process, Ongoing Monitoring).
- Outsourcing Register: Detaillierte Liste aller ausgelagerten Funktionen mit Angaben zu Vendor, Service, Vertragslaufzeit, Kritikalität.
- Intra-Group Outsourcing: Bei Konzernstrukturen muss klar sein, welche Services von Schwester- oder Muttergesellschaften erbracht werden und wie die Steuerung erfolgt.
- Exit Plans: Für kritische Outsourcings muss ein Ausstiegsplan existieren (Transition zu neuem Provider oder In-House, Data Portability, Service Continuity).
Für Product/Tech-Teams ergeben sich aus diesen Anforderungen konkrete Design-Considerations:
Audit Rights in Cloud Contracts:
- Standard-Cloud-Verträge (z.B. AWS, Azure, GCP) enthalten typischerweise keine direkten Audit-Rechte für Kunden; stattdessen bieten sie Zertifizierungen (SOC2, ISO27001) und Audit-Reports.
- Für MiCA-Zwecke muss geprüft werden, ob diese Zertifizierungen ausreichen oder ob zusätzliche vertragliche Regelungen notwendig sind (z.B. für NCA-Zugang).
- Bei SaaS-Providern sollten vertragliche Audit-Rechte verhandelt werden (mindestens jährliche Audits, Zugang für regulatorische Inspektionen).
- CASPs müssen wissen, wo ihre Daten physisch gespeichert sind (EU vs. Non-EU).
- Bei Non-EU-Storage können zusätzliche Anforderungen entstehen (z.B. Data Processing Agreements, Adequacy Decisions, Standard Contractual Clauses).
- Cloud-Provider bieten typischerweise Region-Selection (z.B. „eu-central-1" für Frankfurt); dies sollte vertraglich festgeschrieben und technisch durchgesetzt werden (z.B. via Infrastructure as Code).
- Cloud-Services sollten so gestaltet sein, dass ein Wechsel zu einem anderen Provider oder In-House-Lösung möglich ist (Data Portability, API-Compatibility, Documentation).
- „Vendor Lock-In" ist aus MiCA-Sicht problematisch, da er die Steuerungsfähigkeit des CASP einschränkt.
- Praktisch: Multi-Cloud-Strategien oder Hybrid-Ansätze können Reversibilität erhöhen, erhöhen aber auch Komplexität.
- Wenn ein Cloud- oder SaaS-Provider selbst Third-Party-Services nutzt (z.B. Sub-Contractors für Data Centers, CDN, Security Tools), muss der CASP darüber informiert sein.
- Dies sollte vertraglich geregelt sein (Notification bei Sub-Outsourcing, Approval-Requirement für kritische Sub-Contractors).
Die folgenden Szenarien basieren auf Anforderungen aus ESMA/FMA/AMF-Materialien und zeigen typische Probleme, die bei unzureichender technischer Umsetzung auftreten können.
Szenario A: Unklare Rollenverteilung CASP vs. Cloud-Provider
Situation: Ein CASP lagert sein gesamtes IT-Operations (Hosting, Monitoring, Security Management, Backup/DR) an einen Cloud-Provider aus. Der CASP hat nur wenige eigene IT-Mitarbeiter, die primär „Business Logic" entwickeln, aber keine tiefe Expertise in Infrastructure, Security oder Incident Response haben. Verträge mit dem Cloud-Provider enthalten keine Audit-Rechte für Aufsichtsbehörden, und Sub-Outsourcing ist nicht geregelt.
Supervisory Concern:
- Der CASP wird de facto zu einer „Letter-Box" – er hat keine reale Kontrolle über seine IT-Systeme.
- Die NCA kann die Systeme nicht inspizieren (fehlende Audit-Rechte).
- Sub-Outsourcing ist unkontrolliert (Provider könnte kritische Funktionen weiter auslagern, ohne dass CASP oder NCA davon wissen).
Remediation To-Dos:
- ICT Key Staff aufbauen: CASP muss eigene IT-Mitarbeiter mit Infrastructure-, Security- und Incident-Response-Expertise einstellen oder schulen.
- Outsourcing Register erstellen: Alle Cloud-Services und deren Kritikalität dokumentieren.
- Verträge nachverhandeln: Audit-Rechte für CASP und NCA einfordern; Sub-Outsourcing-Approval-Pflicht aufnehmen; Exit-Klauseln klären.
- Monitoring & Governance aufsetzen: CASP muss Cloud-Services aktiv überwachen (Performance, Security Incidents, Compliance); nicht einfach „blind vertrauen".
- Documentation for NCA: Nachweisen, dass CASP tatsächlich steuert (z.B. durch regelmäßige Reviews, Audit-Reports, Incident-Logs mit CASP-Involvement).
Situation: Ein CASP loggt alle Transaktionen und Orders (MiCA-Compliance), aber es gibt keine Korrelation, kein Alerting und keine Anomaly Detection. Logs werden in ein Data Lake geschrieben, aber niemand schaut sie an, außer bei manuellen Ad-hoc-Queries. Es gibt keine definierten Alert-Rules, keine SIEM-Integration, keine Runbooks für typische Incidents.
Supervisory Concern:
- Der CASP kann Incidents und Market Abuse nicht zeitnah erkennen.
- Im Falle eines Security Incidents oder Market Manipulation wird das Problem erst Tage oder Wochen später entdeckt.
- Die Aufsichtsbehörde könnte bei einer Inspektion feststellen, dass das „Incident Handling" (Art. 66 MiCA) nur auf dem Papier existiert.
Remediation To-Dos:
- SIEM oder Monitoring-Platform implementieren: Centralized Logging mit Correlation Engine (z.B. Splunk, ELK Stack, Datadog, Azure Sentinel; genannte Lösungen dienen nur als Beispiele, keine spezifische Technologie ist vorgeschrieben).
- Alert Rules definieren: Konkrete Thresholds und Patterns für verschiedene Anomalie-Typen (z.B. „Order Volume > 10x Median innerhalb 5 Minuten", „Failed Login Attempts > 5 in 1 Minute", „Unusual Withdrawal Pattern").
- Incident Response Runbooks erstellen: Für jeden Alert-Typ: Was sind die ersten Schritte? Wer ist zuständig? Welche Eskalationspfade gibt es?
- Real-Time Alerting: Alerts müssen in Echtzeit an On-Call-Teams gehen (PagerDuty, OpsGenie, Slack-Integration).
- Post-Incident Review etablieren: Nach jedem relevanten Incident: Root Cause Analysis, Lessons Learned, Verbesserungsmaßnahmen dokumentieren.
Situation: Ein CASP nutzt mehrere SaaS-Tools (KYC-Provider, Transaction Monitoring Tool, Cloud-Hosting) mit Standard-Terms & Conditions. Diese enthalten keine Audit-Rechte für den CASP oder für Aufsichtsbehörden. Die NCA fordert im Zulassungsverfahren Zugang zu den Systemen, um die Compliance zu prüfen – der CASP kann dies nicht gewährleisten.
Supervisory Concern:
- Die NCA kann die Einhaltung von MiCA-Anforderungen nicht überprüfen (fehlender System-Zugang).
- Dies ist ein fundamentales Problem: Beaufsichtigungsfähigkeit ist eine Grundvoraussetzung für die CASP-Zulassung.
- Der Antrag könnte abgelehnt oder mit Auflagen versehen werden („Verträge nachverhandeln, bevor Zulassung erteilt wird").
Remediation To-Dos:
- Vendor-Verträge prüfen: Alle Outsourcing-Verträge auf Audit-Rechte checken.
- Nachverhandlungen initiieren: Legal/Procurement muss mit Vendors sprechen und Audit-Rechte einfordern (für CASP und für NCA/Auditors).
- Alternative: Zertifizierungen: Wo direkte Audit-Rechte nicht verhandelbar sind (z.B. bei großen Cloud-Providern), prüfen, ob SOC2/ISO27001-Berichte ausreichen und ob die NCA diese akzeptiert.
- Documentation & Communication: Der NCA transparent darlegen, welche Services genutzt werden, welche Audit-Rechte bestehen und welche Kompensationsmaßnahmen ergriffen wurden (z.B. Zertifizierungen, eigene Security-Assessments).
Situation: Ein CASP nutzt einen KYC-Provider, der wiederum einen Sub-Contractor für Dokument-Scanning nutzt. Der Sub-Contractor ist in einem Non-EU-Land ansässig, und der CASP weiß nichts von diesem Sub-Outsourcing. Die Aufsichtsbehörde entdeckt dies bei der Due Diligence und stellt fest, dass sensible KYC-Daten in einem Land ohne Datenschutz-Adequacy-Decision verarbeitet werden.
Supervisory Concern:
- Datenschutz-Verstoß (GDPR).
- Fehlende Kontrolle über die gesamte Dienstleistungskette.
- Potenzielle Risiken für Datensicherheit und Compliance.
Remediation To-Dos:
- Vendor Due Diligence vertiefen: Bei allen kritischen Vendors nachfragen: „Nutzt ihr Sub-Contractors? Wenn ja, welche? Wo sind sie ansässig?"
- Verträge anpassen: Sub-Outsourcing-Approval-Pflicht aufnehmen („Vendor darf ohne vorherige Zustimmung des CASP keine kritischen Funktionen weiter-outsourcen").
- Data Geography Mapping: Dokumentieren, wo entlang der gesamten Kette Daten verarbeitet und gespeichert werden.
- GDPR/MiCA-Compliance prüfen: Bei Non-EU-Sub-Contractors: Adequacy Decision vorhanden? Standard Contractual Clauses abgeschlossen? Data Processing Agreements in Ordnung?
Die folgende Checklist fasst die wichtigsten Product/Tech-Anforderungen zusammen, die vor dem Go-Live eines CASP-Services abgearbeitet sein sollten. Diese Checklist ersetzt nicht die rechtliche und Compliance-Prüfung, sondern ergänzt sie aus technischer Sicht.
5.1 ICT & Security Controls
☐ ICT Policy dokumentiert (Scope, Rollen, Verantwortlichkeiten, Change/Release Management, Access Control) ☐ ICT Risk Owner benannt (C-Level oder designated function, regelmäßige Risk Reviews) ☐ Access Control implementiert (RBAC, Least Privilege, MFA, Privileged Access Management, Quarterly Access Reviews) ☐ Segregation of Duties umgesetzt (Dev/Prod Trennung, 4-Eyes-Principle für kritische Changes) ☐ Key Management Process dokumentiert und getestet (Key Generation, Storage (HSM/KMS), Rotation, Backup, Recovery Drills) ☐ Encryption at Rest & in Transit aktiviert (Verschlüsselung nach aktuellen Marktstandards, Zertifikat-Management) ☐ Logging & Monitoring aufgesetzt (Centralized Logging (z.B. SIEM-System oder vergleichbare Lösung), Alert Rules definiert, Log Retention per MiCA/AML) ☐ Vulnerability Management etabliert (Regular Scans, Patch Management, CVE Tracking, Penetration Testing (mindestens jährlich)) ☐ Network Security gehärtet (Firewalls, Network Segmentation, Intrusion Detection/Prevention, Zero Trust Principles wo sinnvoll)
5.2 Incident Management
☐ Incident Classification definiert (Severity Levels mit klaren Kriterien: Critical/High/Medium/Low) ☐ Incident Response Process dokumentiert (Detection → Containment → Eradication → Recovery → Lessons Learned) ☐ Runbooks für typische Incidents erstellt (Wallet Compromise, API Downtime, DDoS, Data Breach, etc.) ☐ Incident Log zentral geführt (Timestamp, Description, Impact, Actions Taken, Resolution) ☐ Notification Triggers festgelegt (Wann NCA informieren? Welche Fristen? Wer ist verantwortlich?) ☐ Interne SLAs definiert (Response Time, Resolution Time per Severity Level) ☐ Post-Incident Review etabliert (Root Cause Analysis nach jedem relevanten Incident, Prevention Measures, Documentation)
5.3 Outsourcing & Cloud
☐ Outsourcing Register erstellt (Vendor, Service, Criticality, Contract Details, Review Date) ☐ ICT Third-Party Risk Assessment durchgeführt (Vendor Due Diligence: Financial Stability, Security Certifications, References) ☐ Contract Clauses geprüft/verhandelt (Audit Rights für CASP und NCA, Data Access, Sub-Outsourcing Approval, Exit/Reversibility) ☐ Sub-Outsourcing Control implementiert (Visibility über gesamte Lieferkette, Approval Process, Documentation) ☐ Exit Strategy dokumentiert (Transition Plan bei Vendor-Wechsel, Data Portability, Service Continuity) ☐ Monitoring von Outsourced Services aufgesetzt (SLAs, Performance Metrics, Regular Reviews, Escalation Paths) ☐ Data Geography Mapping erstellt (Wo liegen Daten? EU vs. Non-EU? GDPR/MiCA-Compliance geprüft?)
5.4 Data Management & Retention
☐ Data Retention Policy implementiert (MiCA-relevante Daten: 5 Jahre; AML-Daten: 5–10 Jahre je nach nationalem Recht; Automated Lifecycle Management) ☐ Encryption at Rest & in Transit aktiviert (siehe 5.1) ☐ Audit Trail für Data Access aufgesetzt (Logging aller Zugriffe auf sensible Daten, Integration mit SIEM) ☐ Backup & Disaster Recovery getestet (RPO/RTO definiert und gemessen, Off-Site Storage, Restore Drills durchgeführt und dokumentiert) ☐ GDPR-Compliance geprüft (Right to Erasure, Data Portability, Consent Management, Data Processing Agreements mit allen Vendors)
5.5 Transaction & KYC Layer
☐ KYC Process dokumentiert und integriert (Initial KYC, Ongoing Monitoring, Enhanced Due Diligence, Integration mit AML-Frameworks) ☐ KYC Decision Logging implementiert (Timestamp, Decision Maker, Rationale, Data Points) ☐ Travel Rule Compliance umgesetzt (TFR-Messaging für Transfers > 1.000 EUR, IVMS101 oder vergleichbar) ☐ Transaction Logging vollständig (End-to-End Logging aller Orders und Transactions, inkl. Order Book Snapshots, Blockchain TX Tracking) ☐ Anomaly Detection & Market Abuse Surveillance aufgesetzt (Regel-basiert oder ML-basiert, Real-Time Alerting, Investigation Workflow für Compliance) ☐ Reconstruction Capability gewährleistet (Aufsicht kann jede Transaktion von Anfang bis Ende nachvollziehen)
5.6 Knowledge & Competence
☐ Training Program für Client-Facing Staff aufgesetzt (Initial Training: MiCA/Tokenomics Basics, Risk Disclosures, Regulatory Requirements) ☐ Assessment & Certification durchgeführt (Internal Tests, ggf. External Certifications, Documentation) ☐ Continuing Professional Development (CPD) geplant (Annual Refreshers, Updates bei regulatorischen Änderungen) ☐ Documentation für NCA Inspections vorbereitet (Training Records, Assessment Results, Staff Competence Matrix)
5.7 Alignment mit nationalen Erwartungen
☐ FMA (Österreich): CASP-spezifische Aspekte berücksichtigt (z.B. Outsourcing of Core Services (Issue 01), Information Document on Authorisation Procedures) ☐ AMF (Frankreich): DOC-2025-05 Checkliste abgearbeitet (Documented Outsourcing Policy, Outsourcing Register, Intra-Group Arrangements, Exit Plans) ☐ BaFin (Deutschland): Merkblätter und Rundschreiben geprüft ([Quelle erforderlich – BaFin-spezifische Anforderungen bei BaFin direkt erfragen]) ☐ CSSF (Luxemburg): Forms/Templates und Contact Points genutzt ([Quelle erforderlich – CSSF-spezifische Anforderungen bei CSSF direkt erfragen])
5.8 Final Pre-Launch Check
☐ Internal Compliance Sign-Off eingeholt (Legal/Compliance hat alle Tech-Implementierungen geprüft und abgenommen) ☐ External Audit durchgeführt (Optional, aber empfohlen: IT-Security Audit, Penetration Test, Compliance Audit durch externe Experten) ☐ Dry-Run mit NCA-Simulation (Simulation einer Aufsichtsprüfung: Können alle geforderten Informationen/Daten bereitgestellt werden?) ☐ Incident Response Drill durchgeführt (Table-Top Exercise oder Full Simulation eines Critical Incidents) ☐ Documentation vollständig und aktuell (Alle Policies, Prozesse, Runbooks, Architekturdiagramme, Vendor-Contracts dokumentiert und versioniert)
Wichtiger Hinweis: Diese Checklist ist als Orientierung gedacht und erhebt keinen Anspruch auf Vollständigkeit. Sie ersetzt nicht die individuelle Rechts- und Compliance-Beratung. Jedes Projekt sollte mit spezialisierten Legal- und Compliance-Experten zusammenarbeiten und eine maßgeschneiderte Checkliste entwickeln.
Fazit: Von Compliance zu Competitive Advantage
MiCA ist mehr als eine regulatorische Hürde – es ist eine Chance, robuste, sichere und professionelle Systeme aufzubauen, die Vertrauen bei Kunden und Aufsichtsbehörden schaffen. Product- und Tech-Teams, die die MiCA-Anforderungen frühzeitig in ihre Architektur und Prozesse integrieren, vermeiden teure Nachbesserungen und positionieren sich als „Compliance-ready" – ein entscheidender Wettbewerbsvorteil im hart umkämpften EU-Krypto-Markt.
Dieser Playbook bietet einen Einstieg in die technische Umsetzung von MiCA. Für tiefergehende Fragen sollten Product- und Tech-Teams eng mit Legal, Compliance und – wo nötig – mit spezialisierten Beratern zusammenarbeiten. Die Investition in solide Systeme und Prozesse zahlt sich langfristig aus: in schnelleren Zulassungsverfahren, geringeren Aufsichtsrisiken und höherem Kundenvertrauen.
Über NEXORA Unternehmensberatung GmbH
NEXORA ist eine in Wien ansässige Boutique-Beratungsfirma, spezialisiert auf RegTech, FinTech, strategische Beratung und Compliance-Services für österreichische und internationale Kunden. Unser Team unterstützt Krypto-Projekte im DACH-Raum bei der technischen und regulatorischen Umsetzung von MiCA – von der Architektur-Beratung über Outsourcing-Governance bis zur Vorbereitung von Aufsichtsprüfungen.
Beratung benötigt?
Vereinbaren Sie ein kostenloses Erstgespräch mit dem NEXORA-Team.