MiCA Compliance Playbook for Product & Tech Teams

Introduction: From Legal Requirements to Engineering Tasks

The Markets in Crypto-Assets Regulation (MiCA) is often perceived as a purely legal matter. However, for Product Managers, Solution Architects, and Tech Leads, MiCA primarily means one thing: specific requirements for systems, processes, and data architecture. MiCA requires not only documentation and policies but also the actual technical implementation of IT governance, operational resilience, incident management, and data protection.

This playbook translates the regulatory requirements from MiCA, ESMA guidelines, and national supervisory expectations into the language of Product and Engineering. It illustrates which backlog items arise, which architecture patterns are needed, and which checklists must be completed before going live. The focus is on Crypto-Asset Service Providers (CASPs) in the DACH region, but the content is relevant for all EU jurisdictions.

Target Audience: Product Managers, CTOs, Solution Architects, Engineering Leads, and Compliance Teams of EU crypto projects preparing for CASP licensing or already operating under MiCA.

Information Status: January 12, 2026

1. MiCA Obligations Translated into Tech Language

MiCA imposes organizational, IT security, and outsourcing requirements that must be directly translated into concrete product and tech tasks. The following mapping table links MiCA articles and ESMA guidelines with typical backlog items for Product/IT teams.

Mapping Table: Standard → Description → Typical Backlog Items

Important Note: This table is intended as a guide and does not claim to be exhaustive. Each project should conduct its own gap analysis and coordinate specific requirements with Legal/Compliance.

2. Architecture Levels under MiCA

A MiCA-compliant architecture can be divided into three main layers, each of which must meet specific regulatory requirements:

2.1 Identity / KYC-Layer

Regulatory Context: CASPs are subject to EU-AML guidelines and the Transfer of Funds Regulation (TFR / "Travel Rule"). KYC processes must not only be carried out initially during onboarding but also updated continuously (Ongoing Monitoring, Periodic Reviews). In addition, KYC data and decision logic must be fully traceable and auditable.

Technical Requirements:

• Integration with AML-Frameworks: Connection to EU-wide/national sanction lists (EU, OFAC, UN), PEP databases, Adverse Media Screening, Risk Scoring Models.

• KYC Data Storage: Secure, encrypted storage of identity documents and verification results; access only according to the need-to-know principle (RBAC).

• KYC Decision Logging: Every KYC decision (Approved/Rejected/Escalated) must be logged with timestamp, decision maker, rationale, and data points used.

• Travel Rule Compliance (TFR): Under the Transfer of Funds Regulation, comprehensive information obligations apply to crypto transfers (Originator/Beneficiary Data, Wallet Addresses); extended requirements from threshold values (e.g., EUR 1,000); the specific requirements result from the respectively valid version of the TFR. This requires technical solutions such as IVMS101 messaging or comparable standards for information exchange between CASPs.

• Data Retention: KYC data must be retained in accordance with national AML laws (typically 5–10 years); at the same time, GDPR requirements must be observed (right to deletion in the event of legitimate interest).

Backlog Items (Examples):

• Integrate KYC-API with Third-Party-Provider (e.g., Jumio, Onfido, Sumsub; mentioned providers serve only as examples; MiCA does not prescribe specific providers)

• Implement Travel Rule Messaging (IVMS101, Notabene, Sygna, or own solution)

• Build KYC-Decision-Audit-Trail (DB-Schema, Logging-Service, Query-Interface for Compliance)

• Implement RBAC for KYC-Data (only Compliance-Team and designated Auditors have Full Access)

2.2 Transaction-Layer

Regulatory Context: MiCA and EU-Market-Abuse-Rules require complete traceability of orders and transactions. CASPs must be able to detect and report suspicious activities (Market Manipulation, Insider Trading, Wash Trading).

Technical Requirements:

• End-to-End Transaction Logging: Every order (placed, modified, cancelled, executed) must be logged with timestamp, user ID, order details, execution details.

• Blockchain Transaction Tracking: For On-Chain-Transactions: complete logs of blockchain TX-Hashes, Sender/Receiver Addresses, Amounts, Confirmations.

• Anomaly Detection & Monitoring: Algorithms or rule-based systems for detection of:

• Unusual trading volumes or patterns

• Wash Trading (Self-Dealing)

• Sudden Price Movements (Pump & Dump Indicators)

• Layering, Spoofing, Frontrunning

• Reconstruction Capability: The supervisory authority must be able to track every transaction from start to finish (Order Book Snapshots, Match Engine Logs, Settlement Records).

• Real-Time Alerting: In case of suspected market abuse, compliance teams must be informed in real time (e.g., via SIEM integration or dedicated surveillance tool).

Backlog Items (Examples):

• Implement Transaction Logging Service (High-Volume, Low-Latency, Append-Only Log)

• Define Anomaly Detection Rules (Thresholds, Alert Triggers, Escalation Workflow)

• Build Order Book Snapshot Mechanism (Periodic Snapshots for Audit/Reconstruction)

• Market Abuse Surveillance Dashboard for Compliance-Team (Real-Time Alerts, Investigation Workflow)

2.3 Data-Layer

Regulatory Context: MiCA and AML require strict Data Retention Policies, while GDPR guarantees the right to deletion and data portability. In addition, all accesses and changes to sensitive data must be auditable.

Technical Requirements:

• Data Retention Policies:

• MiCA-relevant data (Orders, Transactions, Incident Logs, Client Communications): typically 5 years

• AML-Data (KYC, Transaction Monitoring Logs): specifically prescribed by the respective national AML law (typically 5–10 years)

• Automated deletion after expiry of the retention period (unless legal holds exist)

• Encryption at Rest & in Transit: All sensitive data (PII, KYC-Documents, Private Keys, Transaction Details) must be stored and transmitted encrypted. The specific technical standards (e.g., algorithm, key length, protocol version such as AES-256, TLS 1.2+) must be determined based on current market standards and internal Risk Appetite; MiCA does not prescribe specific algorithms.

• Audit Trail for Data Access: Every access to sensitive data (who, when, which data, purpose) must be logged.

• Backup & Disaster Recovery:

• Regular Backups (daily or more frequently for critical systems)

• Off-Site Storage (geographically separated)

• Define and test Recovery Point Objective (RPO) and Recovery Time Objective (RTO)

• Perform Restore Drills (at least annually)

• Data Geography & Outsourcing: For Cloud-Storage it must be clear where data is physically stored (EU vs. Non-EU). For Non-EU-Storage additional data protection and supervisory requirements may arise.

Backlog Items (Examples):

• Implement Data Retention Policy Engine (Automated Data Lifecycle Management, Archiving, Deletion)

• Activate Encryption-at-Rest for all DBs (RDS Encryption, Disk Encryption, Key Management via HSM or Cloud KMS)

• Set up Audit Logging for DB-Accesses (DB Audit Logs, Integration with SIEM, Alerting for anomalous Access Patterns)

• Test Backup Strategy (RPO/RTO measure, Restore Drill perform, Documentation update)

• Create Data Geography Mapping (Which data is located where? Compliance-Check with GDPR/MiCA Outsourcing Rules)

3. Supervisory Expectations on Outsourcing & Cloud

Outsourcing – especially of critical IT functions and cloud services – is one of the sensitive topics under MiCA. The supervisory authorities want to ensure that CASPs do not become "letterbox companies" and that they retain control over their processes and data at all times.

3.1 MiCA Outsourcing Principles

Art. 63(6) MiCA and relevant Recitals clarify:

• CASPs remain fully responsible for outsourced functions.

• Outsourcing must not impair the supervisory capability of the NCA (i.e., the supervisory authority must have access to systems, data, and processes at all times).

• "Important" or "critical" functions (e.g., Compliance, Risk Management, Core IT) require special care and stricter contractual arrangements.

• Outsourcing must not lead to the CASP de facto losing operational control (Letter-Box-Problem).

3.2 ESMA Supervisory Briefing on CASP Authorisation

ESMA has formulated the following expectations in its Supervisory Briefing (developed in cooperation with NCAs during the transition phase):

• Substance Assessment: NCAs check whether the CASP is "actually" active in the Home Jurisdiction or whether essential functions are outsourced and only a "facade" remains.

• Depth of Outsourcing: The more functions are outsourced, the more critical the review. CASPs must prove that they have own ICT Key Staff who can monitor and control outsourced services.

• Monitoring Outsourced Functions: CASPs must continuously monitor the performance and compliance of the outsourcing partners (SLAs, KPIs, Regular Audits).

3.3 ESMA Guidelines on Systems and Security (Art. 14(1)(d) MiCA)

Although these guidelines primarily apply to Issuers and Persons seeking admission to trading, they contain important principles that are also relevant for CASPs:

• ICT Third-Party Risk Management: Identification and assessment of IT service providers; categorization according to criticality.

• Sub-Outsourcing Control: Outsourcing partners must not simply further outsource services; CASP must approve sub-outsourcing and have visibility over the entire supply chain.

• Contractual Clauses: Contracts must include:

• Audit Rights for CASP and NCA

• Data Access for supervisory authorities

• Change Management: Outsourcing partner must notify and approve essential changes in advance

• Exit/Reversibility: Clear regulations on how services can be transferred at the end of the contract or termination

3.4 FMA "Let's talk about supervision" – Outsourcing of Core Services by CASPs (Issue 01)

The Austrian FMA has specifically addressed the topic of outsourcing of core services at CASPs in its publication series "Let's talk about supervision" (Issue 01):

• Core Services include compliance, risk management, IT operations, and custody functions.

• The FMA emphasizes that outsourcing of these functions is only possible under strict conditions.

• CASPs must prove that they retain real control over outsourced core services – through own employees who are technically competent, through regular audits, and through contractual control options.

• The FMA intensively examines in the licensing procedure whether a CASP has sufficient own substance or whether a "Letter-Box" risk exists.

3.5 AMF Instruction DOC-2025-05 (Information Complete for CASP Authorisation)

In its Instruction DOC-2025-05, the French AMF has formulated detailed requirements for the completeness of CASP applications, including:

• Documented Outsourcing Policy: Description of the principles according to which outsourcing decisions are made (e.g. criticality assessment, vendor selection process, ongoing monitoring).

• Outsourcing Register: Detailed list of all outsourced functions with details of vendor, service, contract term, criticality.

• Intra-Group Outsourcing: In the case of group structures, it must be clear which services are provided by sister or parent companies and how they are controlled.

• Exit Plans: For critical outsourcing arrangements, an exit plan must exist (transition to a new provider or in-house, data portability, service continuity).

3.6 Practical Design Considerations for Cloud & SaaS

These requirements result in concrete design considerations for product/tech teams:

Audit Rights in Cloud Contracts:

• Standard cloud contracts (e.g. AWS, Azure, GCP) typically do not include direct audit rights for customers; instead, they offer certifications (SOC2, ISO27001) and audit reports.

• For MiCA purposes, it must be checked whether these certifications are sufficient or whether additional contractual arrangements are necessary (e.g. for NCA access).

• With SaaS providers, contractual audit rights should be negotiated (at least annual audits, access for regulatory inspections).

Data Location & Residency:

• CASPs must know where their data is physically stored (EU vs. Non-EU).

• Additional requirements may arise for non-EU storage (e.g. Data Processing Agreements, Adequacy Decisions, Standard Contractual Clauses).

• Cloud providers typically offer region selection (e.g. "eu-central-1" for Frankfurt); this should be contractually stipulated and technically enforced (e.g. via Infrastructure as Code).

Reversibility / Exit Strategy:

• Cloud services should be designed in such a way that a switch to another provider or in-house solution is possible (data portability, API compatibility, documentation).

• "Vendor lock-in" is problematic from a MiCA perspective, as it restricts the CASP's ability to control.

• In practice: Multi-cloud strategies or hybrid approaches can increase reversibility, but also increase complexity.

Sub-Outsourcing Visibility:

• If a cloud or SaaS provider uses third-party services themselves (e.g. sub-contractors for data centers, CDN, security tools), the CASP must be informed.

• This should be contractually regulated (notification of sub-outsourcing, approval requirement for critical sub-contractors).

4. Typical Problem Scenarios from a Tech Perspective

The following scenarios are based on requirements from ESMA/FMA/AMF materials and show typical problems that can occur with inadequate technical implementation.

Scenario A: Unclear distribution of roles CASP vs. cloud provider

Situation: A CASP outsources its entire IT operations (hosting, monitoring, security management, backup/DR) to a cloud provider. The CASP has only a few of its own IT employees who primarily develop "business logic" but have no in-depth expertise in infrastructure, security or incident response. Contracts with the cloud provider do not include audit rights for supervisory authorities, and sub-outsourcing is not regulated.

Supervisory Concern:

• The CASP de facto becomes a "letter box" – it has no real control over its IT systems.

• The NCA cannot inspect the systems (lack of audit rights).

• Sub-outsourcing is uncontrolled (provider could outsource critical functions without the CASP or NCA knowing).

What does that mean specifically for Product/Tech?

Remediation To-Dos:

• Build up ICT Key Staff: CASP must hire or train its own IT staff with infrastructure, security and incident response expertise.

• Create outsourcing register: Document all cloud services and their criticality.

• Renegotiate contracts: Demand audit rights for CASP and NCA; include sub-outsourcing approval obligation; clarify exit clauses.

• Set up monitoring & governance: CASP must actively monitor cloud services (performance, security incidents, compliance); not simply "trust blindly".

• Documentation for NCA: Prove that CASP actually controls (e.g. through regular reviews, audit reports, incident logs with CASP involvement).

Scenario B: Insufficient Monitoring & Alerting

Situation: A CASP logs all transactions and orders (MiCA compliance), but there is no correlation, no alerting and no anomaly detection. Logs are written to a data lake, but nobody looks at them except for manual ad-hoc queries. There are no defined alert rules, no SIEM integration, no runbooks for typical incidents.

Supervisory Concern:

• The CASP cannot detect incidents and market abuse in a timely manner.

• In the event of a security incident or market manipulation, the problem is only discovered days or weeks later.

• The supervisory authority could determine during an inspection that the "incident handling" (Art. 66 MiCA) only exists on paper.

What does that mean specifically for Product/Tech?

Remediation To-Dos:

• Implement SIEM or monitoring platform: Centralized logging with correlation engine (e.g. Splunk, ELK Stack, Datadog, Azure Sentinel; the solutions mentioned are only examples, no specific technology is prescribed).

• Define alert rules: Concrete thresholds and patterns for different anomaly types (e.g. "Order Volume > 10x Median within 5 minutes", "Failed Login Attempts > 5 in 1 Minute", "Unusual Withdrawal Pattern").

• Create incident response runbooks: For each alert type: What are the first steps? Who is responsible? What escalation paths are there?

• Real-Time Alerting: Alerts must go to on-call teams in real time (PagerDuty, OpsGenie, Slack integration).

• Establish post-incident review: After each relevant incident: Document root cause analysis, lessons learned, improvement measures.

Scenario C: Missing Audit Rights in Cloud Contracts

Situation: A CASP uses several SaaS tools (KYC provider, transaction monitoring tool, cloud hosting) with standard terms & conditions. These do not include audit rights for the CASP or for supervisory authorities. In the approval process, the NCA requests access to the systems in order to check compliance – the CASP cannot guarantee this.

Supervisory Concern:

• The NCA cannot verify compliance with MiCA requirements (lack of system access).

• This is a fundamental problem: Supervisory capacity is a basic requirement for CASP approval.

• The application could be rejected or subject to conditions ("renegotiate contracts before approval is granted").

What does that mean specifically for Product/Tech?

Remediation To-Dos:

• Check vendor contracts: Check all outsourcing contracts for audit rights.

• Initiate renegotiations: Legal/Procurement must speak with vendors and demand audit rights (for CASP and for NCA/auditors).

• Alternative: Certifications: Where direct audit rights are not negotiable (e.g. with large cloud providers), check whether SOC2/ISO27001 reports are sufficient and whether the NCA accepts them.

• Documentation & Communication: Clearly explain to the NCA which services are used, which audit rights exist and which compensatory measures have been taken (e.g. certifications, own security assessments).

Scenario D: Unclear Sub-Outsourcing Chain

Situation: A CASP uses a KYC provider who in turn uses a sub-contractor for document scanning. The sub-contractor is based in a non-EU country, and the CASP knows nothing about this sub-outsourcing. The supervisory authority discovers this during due diligence and determines that sensitive KYC data is being processed in a country without a data protection adequacy decision.

Supervisory Concern:

• Data protection breach (GDPR).

• Lack of control over the entire service chain.

• Potential risks for data security and compliance.

What does that mean specifically for Product/Tech?

Remediation To-Dos:

• Deepen vendor due diligence: Ask all critical vendors: "Do you use sub-contractors? If so, which ones? Where are they based?"

• Adapt contracts: Include sub-outsourcing approval obligation ("Vendor may not further outsource critical functions without the prior consent of the CASP").

• Data Geography Mapping: Document where data is processed and stored along the entire chain.

• Check GDPR/MiCA compliance: For non-EU sub-contractors: Adequacy Decision available? Standard Contractual Clauses concluded? Data Processing Agreements in order?

5. Go-Live Checklist under MiCA

The following checklist summarizes the most important product/tech requirements that should be completed before the go-live of a CASP service. This checklist does not replace the legal and compliance review, but supplements it from a technical perspective.

5.1 ICT & Security Controls

☐ ICT Policy documented (Scope, Roles, Responsibilities, Change/Release Management, Access Control) ☐ ICT Risk Owner appointed (C-Level or designated function, regular Risk Reviews) ☐ Access Control implemented (RBAC, Least Privilege, MFA, Privileged Access Management, Quarterly Access Reviews) ☐ Segregation of Duties implemented (Dev/Prod separation, 4-eyes-principle for critical changes) ☐ Key Management Process documented and tested (Key Generation, Storage (HSM/KMS), Rotation, Backup, Recovery Drills) ☐ Encryption at Rest & in Transit activated (Encryption according to current market standards, certificate management) ☐ Logging & Monitoring set up (Centralized Logging (e.g. SIEM system or comparable solution), Alert Rules defined, Log Retention per MiCA/AML) ☐ Vulnerability Management established (Regular Scans, Patch Management, CVE Tracking, Penetration Testing (at least annually)) ☐ Network Security hardened (Firewalls, Network Segmentation, Intrusion Detection/Prevention, Zero Trust Principles where appropriate)

5.2 Incident Management

☐ Incident Classification defined (Severity Levels with clear criteria: Critical/High/Medium/Low) ☐ Incident Response Process documented (Detection → Containment → Eradication → Recovery → Lessons Learned) ☐ Runbooks for typical incidents created (Wallet Compromise, API Downtime, DDoS, Data Breach, etc.) ☐ Incident Log centrally maintained (Timestamp, Description, Impact, Actions Taken, Resolution) ☐ Notification Triggers defined (When to inform NCA? What deadlines? Who is responsible?) ☐ Internal SLAs defined (Response Time, Resolution Time per Severity Level) ☐ Post-Incident Review established (Root Cause Analysis after each relevant incident, Prevention Measures, Documentation)

5.3 Outsourcing & Cloud

☐ Outsourcing Register created (Vendor, Service, Criticality, Contract Details, Review Date) ☐ ICT Third-Party Risk Assessment performed (Vendor Due Diligence: Financial Stability, Security Certifications, References) ☐ Contract Clauses checked/negotiated (Audit Rights for CASP and NCA, Data Access, Sub-Outsourcing Approval, Exit/Reversibility) ☐ Sub-Outsourcing Control implemented (Visibility over entire supply chain, Approval Process, Documentation) ☐ Exit Strategy documented (Transition Plan for Vendor Change, Data Portability, Service Continuity) ☐ Monitoring of Outsourced Services set up (SLAs, Performance Metrics, Regular Reviews, Escalation Paths) ☐ Data Geography Mapping created (Where is data located? EU vs. Non-EU? GDPR/MiCA compliance checked?)

5.4 Data Management & Retention

☐ Data Retention Policy implemented (MiCA-relevant data: 5 years; AML data: 5–10 years depending on national law; Automated Lifecycle Management) ☐ Encryption at Rest & in Transit activated (see 5.1) ☐ Audit Trail for Data Access set up (Logging of all access to sensitive data, integration with SIEM) ☐ Backup & Disaster Recovery tested (RPO/RTO defined and measured, Off-Site Storage, Restore Drills performed and documented) ☐ GDPR-Compliance checked (Right to Erasure, Data Portability, Consent Management, Data Processing Agreements with all Vendors)

5.5 Transaction & KYC Layer

☐ KYC Process documented and integrated (Initial KYC, Ongoing Monitoring, Enhanced Due Diligence, Integration with AML-Frameworks) ☐ KYC Decision Logging implemented (Timestamp, Decision Maker, Rationale, Data Points) ☐ Travel Rule Compliance implemented (TFR-Messaging for Transfers > 1,000 EUR, IVMS101 or comparable) ☐ Transaction Logging complete (End-to-End Logging of all Orders and Transactions, incl. Order Book Snapshots, Blockchain TX Tracking) ☐ Anomaly Detection & Market Abuse Surveillance set up (Rule-based or ML-based, Real-Time Alerting, Investigation Workflow for Compliance) ☐ Reconstruction Capability guaranteed (Supervisory authority can trace every transaction from start to finish)

5.6 Knowledge & Competence

☐ Training Program for Client-Facing Staff set up (Initial Training: MiCA/Tokenomics Basics, Risk Disclosures, Regulatory Requirements) ☐ Assessment & Certification performed (Internal Tests, possibly External Certifications, Documentation) ☐ Continuing Professional Development (CPD) planned (Annual Refreshers, Updates for regulatory changes) ☐ Documentation for NCA Inspections prepared (Training Records, Assessment Results, Staff Competence Matrix)

5.7 Alignment with national expectations

☐ FMA (Austria): CASP-specific aspects considered (e.g. Outsourcing of Core Services (Issue 01), Information Document on Authorisation Procedures) ☐ AMF (France): DOC-2025-05 checklist completed (Documented Outsourcing Policy, Outsourcing Register, Intra-Group Arrangements, Exit Plans) ☐ BaFin (Germany): Fact sheets and circulars checked ([Source required – BaFin-specific requirements should be requested directly from BaFin]) ☐ CSSF (Luxembourg): Forms/Templates and Contact Points used ([Source required – CSSF-specific requirements should be requested directly from CSSF])

5.8 Final Pre-Launch Check

☐ Internal Compliance Sign-Off obtained (Legal/Compliance has checked and approved all tech implementations) ☐ External Audit performed (Optional, but recommended: IT security audit, penetration test, compliance audit by external experts) ☐ Dry-Run with NCA-Simulation (Simulation of a supervisory audit: Can all required information/data be provided?) ☐ Incident Response Drill performed (Table-Top Exercise or Full Simulation of a Critical Incident) ☐ Documentation complete and up-to-date (All Policies, Processes, Runbooks, Architecture Diagrams, Vendor Contracts documented and versioned)

Important note: This checklist is intended as a guide and does not claim to be exhaustive. It does not replace individual legal and compliance advice. Each project should work with specialized legal and compliance experts and develop a customized checklist.

Conclusion: From Compliance to Competitive Advantage

MiCA is more than a regulatory hurdle – it is an opportunity to build robust, secure and professional systems that create trust with customers and regulators. Product and tech teams that integrate MiCA requirements into their architecture and processes early on avoid expensive rework and position themselves as "compliance-ready" – a decisive competitive advantage in the highly competitive EU crypto market.

This playbook provides an introduction to the technical implementation of MiCA. For more in-depth questions, product and tech teams should work closely with legal, compliance and – where necessary – with specialized consultants. Investing in solid systems and processes pays off in the long term: in faster approval processes, lower supervisory risks and greater customer trust.

About NEXORA Unternehmensberatung GmbH

NEXORA is a Vienna-based boutique consulting firm specializing in RegTech, FinTech, strategic consulting, and compliance services for Austrian and international clients. Our team supports crypto projects in the DACH region with the technical and regulatory implementation of MiCA – from architecture consulting and outsourcing governance to the preparation of supervisory audits.