MiCA CASP + DORA + EU AI Act: Triple Compliance Stack for Crypto Platforms Using AI (2026)

Post #1580 in the sota.io EU Cyber Compliance Series

If you operate a crypto-asset service platform and use AI for trading signals, fraud detection, KYC verification, or portfolio automation, you are operating at the intersection of three major EU regulatory regimes simultaneously. MiCA (Regulation (EU) 2023/1114) governs your CASP authorisation and operational obligations from 30 December 2024. DORA (Regulation (EU) 2022/2554) applies to MiCA-authorised CASPs and mandates ICT risk management and incident reporting from 17 January 2025. The EU AI Act (Regulation (EU) 2024/1689) imposes additional obligations on any AI systems you deploy that qualify as high-risk from 2 August 2026. Understanding how these three regimes interact — and where their obligations overlap, conflict, or compound — is essential for any CASP development team before the August 2026 AI Act deadline.

This is the fourth post in the EU AI Act + DORA Intersection series. Part 1 introduced the dual compliance landscape for FinTech and InsurTech. Part 2 focused on ICT third-party AI vendor governance. Part 3 covered the unified incident reporting playbook. This part addresses the crypto-specific dimension: CASPs as a regulated entity type subject to all three regimes at once.

Is Your CASP Subject to All Three Regimes?

The answer is yes for most authorised CASPs, but the pathways are distinct for each regulation.

MiCA applies if you provide any of the crypto-asset services listed in MiCA Art.59 and are required to obtain CASP authorisation from your national competent authority. MiCA applies from 30 December 2024 across all EU member states.

DORA applies because MiCA CASPs are explicitly included in DORA's scope under Regulation (EU) 2022/2554. DORA Art.2 lists "crypto-asset service providers as defined in Article 3(1) point (15) of Regulation (EU) 2023/1114 and required to be authorised under Article 59 thereof" as in-scope financial entities. DORA obligations have applied since 17 January 2025.

The EU AI Act applies if you develop, deploy, or use AI systems that qualify as high-risk under Annex III, or that trigger transparency obligations under Art.50. The high-risk obligations under Title III become enforceable on 2 August 2026. Prohibited AI practices under Art.5 have been enforceable since 2 August 2025.

The key developer question is therefore not whether these regimes apply, but which AI systems you use trigger which obligations under each.

MiCA and AI: Where Governance Requirements Touch Your AI Systems

MiCA does not regulate AI systems directly. It regulates CASP authorisation, governance, prudential requirements, and operational obligations. However, several MiCA provisions have direct implications for AI-driven CASP operations.

Authorisation and Governance (Art.59, Art.68)

MiCA Art.59 establishes the authorisation obligation. Your authorisation application must demonstrate robust governance arrangements — and if your platform relies on AI for core functions (automated trading, client profiling, order routing), your governance documentation must address how those systems are controlled, overseen, and audited.

MiCA Art.68 requires CASPs to have sound governance arrangements, including a clear organisational structure with well-defined, transparent, and consistent lines of responsibility, and effective processes for identifying, managing, monitoring, and reporting risks. If AI is embedded in your risk management processes, Art.68 governance documentation must explicitly address AI decision-making, override mechanisms, and audit trails. Regulators conducting authorisation reviews increasingly expect AI governance sections in Art.68 submissions.

Prudential Requirements and AI-Driven Losses (Art.67)

MiCA Art.67 establishes prudential requirements — CASPs must hold own funds equivalent to at least one-quarter of their fixed overheads for the preceding year, or maintain professional indemnity insurance. AI system failures that cause financial losses — a malfunctioning trading algorithm, an erroneous fraud detection trigger that blocks legitimate client transactions — can produce liability events that your prudential requirements must cover. Factor AI operational risk into your Art.67 own-funds calculations.

Outsourcing AI Vendors (Art.73)

This is the most operationally significant MiCA provision for AI-using CASPs. MiCA Art.73 governs outsourcing arrangements. It requires that outsourced services do not impair the quality of internal controls, the ability of competent authorities to monitor MiCA compliance, and continuity of CASP services.

If your AI capabilities come from a third-party model vendor — a fraud detection API, a KYC identity verification service, a credit/risk scoring engine — that vendor is an outsourced service provider under Art.73. You must:

• Conduct due diligence on the AI vendor before engagement
• Ensure contractual provisions allow audit rights, data access, and exit procedures
• Maintain ongoing oversight of the AI vendor's performance and continuity
• Be able to substitute the AI vendor without material disruption to services

This MiCA Art.73 obligation overlaps directly with DORA's ICT third-party risk requirements — discussed below.

Safekeeping and AI-Assisted Custody (Art.70, Art.75)

MiCA Art.70 requires CASPs to safeguard clients' crypto-assets and funds. Art.75 applies specifically to custody and administration services. If you use AI to automate custody operations — smart contract interaction, key management automation, transaction signing workflows — the AI system is embedded in a regulated safekeeping function. Any AI failure that results in client asset loss triggers Art.70 obligations including reimbursement duties.

Audit trail and explainability requirements are essential here: you must be able to demonstrate to competent authorities exactly what your AI system did with client assets, when, and why.

DORA Obligations for CASP AI Systems

DORA's ICT risk management framework applies to all CASPs' ICT systems — and AI systems qualify as ICT assets under DORA's broad definition. The DORA obligations that most directly affect AI-using CASPs span four areas: governance (Art.5–6); system protection (Art.9) and monitoring for anomalous activity (Art.10); incident reporting (Art.17–19); and ICT third-party risk management (Art.28–31).

ICT Risk Governance: AI Systems as Regulated Assets

DORA Art.5 requires CASPs to have governance and organisation arrangements that include ICT risk management as a management body responsibility. Your board or senior management must understand and approve the ICT risk strategy — including AI risks.

DORA Art.6 requires a documented ICT risk management framework that identifies all functions, assets, and ICT systems supporting business operations. AI models are ICT assets: they must be inventoried, classified by criticality, and subject to the Art.6 risk framework. If your trading AI or fraud detection engine supports critical business functions, it must be classified accordingly and subject to enhanced controls.

DORA Art.9 (protection and prevention) requires CASPs to implement controls to protect ICT systems — including AI models — from unauthorised access, adversarial inputs, and data poisoning. AI-specific protection controls required under Art.9 include input validation, model drift monitoring, adversarial robustness testing, and access controls on model inference endpoints.

DORA Art.10 (detection) requires continuous monitoring for anomalous activity. For AI systems, this includes monitoring for model performance degradation, unexpected output distributions, and inference-time anomalies that could indicate adversarial manipulation or system failure.

Incident Reporting for AI Failures: DORA Art.17–19

When an AI system failure constitutes an ICT-related incident, DORA Art.17 governs the incident management process. DORA Art.18 provides the classification criteria: an incident is "major" based on the number of clients affected, data loss, service downtime, and financial impact thresholds.

DORA Art.19 and the associated RTS establish the reporting timeline for major ICT-related incidents:

• Initial notification: within 4 hours of classifying the incident as major (or by 23:00 on the same business day if classification occurs late in the day)
• Intermediate report: within 72 hours of the initial notification, with root cause analysis and impact assessment
• Final report: within one month of the initial notification, with remediation documentation

An AI system failure that causes significant client-facing disruption — a trading algorithm malfunction, a fraud detection outage blocking client withdrawals, a KYC system failure preventing onboarding — will likely trigger these thresholds. Build AI-specific incident classification playbooks that map AI failure modes to DORA Art.18 criteria.

ICT Third-Party Risk: AI Vendors as Critical Providers (Art.28–31)

DORA Art.28 establishes the general principles for managing ICT third-party risk. For CASPs, AI vendors providing fraud detection, KYC, trading intelligence, or risk-scoring services are ICT third-party service providers subject to Art.28 oversight obligations.

DORA Art.30 specifies the key contractual provisions that must be included in ICT third-party agreements. For AI vendor contracts, these include:

• Full descriptions of services: specify model versions, accuracy SLAs, and update notification requirements
• Data location provisions: specify where training data is processed, stored, and accessed
• Audit and inspection rights: your right to audit the AI vendor, including model validation data
• Exit clauses: procedures for migrating away from the AI vendor without service disruption
• Sub-contracting provisions: disclosure of the AI vendor's own AI infrastructure (model hosting providers, compute providers)

DORA Art.31 authorises ESMA/ESAs to designate critical ICT third-party service providers subject to direct EU-level oversight. If your AI vendor is designated critical, they become subject to direct ESMA supervision — and your contractual obligations automatically expand to accommodate oversight authority access.

This DORA Art.28–31 framework for AI vendors runs in parallel to the MiCA Art.73 outsourcing obligations. The practical requirement is a single AI vendor governance framework that satisfies both simultaneously.

EU AI Act Obligations for CASP AI Systems

The EU AI Act obligations depend entirely on how your CASP AI systems are classified. The classification analysis is more nuanced for crypto platforms than for banks or insurers, because most crypto trading AI does not fall into the Annex III high-risk categories.

Classification Analysis: Which CASP AI Is High-Risk?

EU AI Act Art.6 establishes the high-risk classification rules. For CASPs, the most relevant Annex III categories are:

Point 5(b) — creditworthiness assessment: "AI systems intended to be used to evaluate the creditworthiness of natural persons or establish their credit score, with the exception of AI systems used for the purpose of detecting financial fraud." If your platform offers margin trading, crypto-backed lending, or credit facilities, and uses AI to assess client creditworthiness, that AI system is high-risk under Point 5(b). Pure algorithmic trading signals applied to your own positions are not covered.

Point 1 — biometric systems: If your KYC process uses AI-powered facial recognition or biometric identification, that system may qualify as a remote biometric identification system under Annex III Point 1. Real-time biometric identification in publicly accessible spaces is prohibited under Art.5. Document-liveness-check KYC that is not real-time public-space biometrics may be regulated but not prohibited.

Point 5(a) — insurance and life assurance: Not directly applicable to most CASPs, but applicable to CASPs offering crypto-based insurance products or stable-value protection products with AI-driven eligibility.

Fraud detection AI: Explicitly excluded from Point 5(b) high-risk classification. Standard fraud detection and transaction monitoring AI is not high-risk under the EU AI Act, regardless of its sophistication.

Trading algorithms: Standard automated trading systems and signal generators are not listed in Annex III. They are regulated by MiFID II and MiCA but are not high-risk AI systems under the AI Act.

The practical conclusion for most CASPs: only AI used in margin/lending credit decisions, or AI-powered biometric KYC, triggers AI Act high-risk obligations. Your fraud detection and trading AI are not high-risk — but they are still subject to DORA ICT risk governance as ICT assets.

High-Risk AI Obligations: Art.9, Art.26, Art.73

If your CASP does use high-risk AI (credit scoring for margin facilities, biometric KYC):

Art.9 (risk management system): You must implement and document a continuous risk management system for each high-risk AI system. For credit-scoring AI used in margin lending, this includes regular accuracy and bias assessments, documentation of risk mitigation measures, and a residual risk register.

Art.26 (deployer obligations): As a CASP deploying high-risk AI (rather than developing it), your Art.26 obligations include: ensuring use in accordance with provider instructions, monitoring AI system operation, informing clients where legally required, and maintaining human oversight measures per Art.14.

Art.49 (registration): High-risk AI systems under Annex III must be registered in the EU AI Act database. If you deploy a third-party credit-scoring AI as a CASP, you must register your deployment in the EU database by 2 August 2026.

Art.72 (post-market monitoring): As a deployer, you must establish a post-market monitoring plan for high-risk AI systems, covering performance metrics, bias drift, and integration with your Art.9 risk management system.

Art.73 (incident reporting): Serious incidents involving high-risk AI must be reported to your national market surveillance authority. Under Art.73 and its associated guidance, timelines are: within 2 working days for deaths or serious harm, within 10 working days for other serious incidents, and within 15 working days for malfunctions without immediate harm. These are calendar-independent working-day timelines — entirely different from DORA's calendar-hour timelines (4h/72h/30d).

Art.50 Transparency Obligations

Even if your CASP AI does not trigger high-risk classification, EU AI Act Art.50 may apply. Art.50 requires that persons interacting with AI systems that could be mistaken for humans are informed they are interacting with AI. If your CASP uses a chatbot for client support, AI-generated portfolio summaries, or AI-driven communications, Art.50 disclosure obligations apply from 2 August 2026.

The Triple Compliance Matrix

The following matrix maps the three regulatory regimes against common CASP AI use cases:

Incident Reporting: Unified Playbook for CASP AI Failures

CASPs face the most complex incident reporting landscape because DORA and the EU AI Act impose different timelines, different triggers, and different notification authorities. Build a unified AI incident classification playbook:

Step 1 — Classify the incident type: Is this an ICT-related incident (DORA) or a serious AI system incident (EU AI Act)? Most CASP AI failures are both. An AI fraud detection outage is both an ICT-related incident (DORA) and potentially an AI system malfunction (Art.73 if high-risk).

Step 2 — Apply the shorter clock first: DORA's initial notification clock (4 hours after major classification) is shorter than AI Act's timelines (2/10/15 working days). Start your DORA notification process first while simultaneously initiating AI Act notification procedures.

Step 3 — Dual notification: Notify your DORA competent authority (typically your NCA or ESMA) and your AI Act market surveillance authority. These may be the same authority in some member states, simplifying the process.

Step 4 — Client notification: MiCA Art.71 complaints handling obligations may require client communication when AI failures affect service quality. Coordinate with Art.71 procedures.

Step 5 — Document for all three: Each regulation requires post-incident documentation. DORA requires a final report within one month. The EU AI Act requires incident documentation in your Art.72 post-market monitoring records. MiCA requires records demonstrating operational resilience. Use a unified incident record that satisfies all three simultaneously.

Infrastructure Considerations: Jurisdictional Compliance

For CASPs operating AI under all three regimes, infrastructure jurisdiction matters more than in most regulated sectors.

DORA Art.30 data location: ICT third-party contracts must specify where data is processed. For AI model training and inference, this means specifying EU vs. non-EU data processing locations. If your AI vendor processes CASP client data outside the EU, your Art.30 contractual provisions must address DORA's data governance requirements.

GDPR overlap: CASP client data (KYC, transaction history, biometric data) is personal data subject to GDPR. AI systems that process this data for fraud detection, credit scoring, or profiling are subject to both GDPR Art.22 (automated decision-making), GDPR Art.35 (DPIA requirements), and EU AI Act obligations where applicable.

MiCA Art.73 outsourcing chain: If your AI vendor uses US-headquartered cloud infrastructure, your Art.73 outsourcing assessment must address whether the US CLOUD Act creates access risks for CASP client data. A US-based AI vendor on AWS, Azure, or GCP has no technical mechanism to prevent US government access requests — which creates regulatory exposure under both MiCA governance obligations and GDPR Chapter V transfer restrictions.

Running CASP AI infrastructure on EU-jurisdiction compute (Hetzner, OVHcloud, Scaleway) eliminates the CLOUD Act exposure from your Art.73 and DORA Art.30 compliance documentation.

30-Step Triple Compliance Checklist: MiCA + DORA + EU AI Act

Phase 1: Inventory and Classification (Steps 1–8)

1. Inventory all AI systems in your CASP stack — trading, fraud, KYC, client communication, portfolio, risk management.
2. Apply Annex III analysis to each AI system: does it fall under credit scoring (Point 5(b)) or biometric identification (Point 1)?
3. Classify AI vendors: each third-party AI provider is an ICT third-party (DORA Art.28) and outsourced service (MiCA Art.73).
4. Map DORA coverage: for each AI system, identify which DORA Art.6 ICT risk framework categories it falls under (availability, confidentiality, integrity).
5. Identify high-risk AI systems under EU AI Act — separately from DORA classification.
6. Document the classification rationale for regulators — both your DORA ICT asset register and your EU AI Act system register.
7. Check Art.50 scope: any AI system capable of interacting with clients in a human-like way requires disclosure obligations.
8. Review Art.5 prohibited practices: biometric AI that categorises clients by protected characteristics or uses subliminal manipulation is prohibited from 2 August 2025 — confirm no current systems trigger this.

Phase 2: Governance and Documentation (Steps 9–16)

1. Update Art.68 MiCA governance arrangements to include an AI risk governance section with defined responsibilities.
2. Build an Art.6 DORA ICT asset register including all AI systems with criticality classification.
3. Establish Art.9 EU AI Act risk management systems for each high-risk AI system (if applicable).
4. Prepare Art.26 deployer registers: for high-risk AI systems, document provider instructions received and your deployment controls.
5. Register high-risk AI systems in the EU AI Act database (Art.49) by 2 August 2026.
6. Review Art.73 MiCA outsourcing agreements with all AI vendors — add audit rights, data location provisions, and exit provisions per Art.30 DORA requirements.
7. Conduct Art.29 DORA concentration risk assessment: if multiple CASP functions depend on one AI vendor, document and assess the systemic concentration risk.
8. Prepare Art.67 MiCA prudential requirement analysis: quantify operational risk from AI failures and incorporate in own-funds calculations.

Phase 3: Technical Controls (Steps 17–22)

1. Implement Art.9 DORA protection controls for AI systems: input validation, access controls on model endpoints, adversarial robustness testing.
2. Establish Art.10 DORA detection monitoring for each AI system: model drift detection, anomaly monitoring, performance degradation alerting.
3. Implement Art.11 DORA response and recovery procedures for AI system failures — including manual fallback procedures for AI-dependent critical functions.
4. Build Art.14 AI Act human oversight mechanisms for high-risk AI systems: model output review workflows, override capabilities, suspension procedures.
5. Establish Art.72 AI Act post-market monitoring for high-risk AI: performance tracking, bias auditing, distribution shift monitoring.
6. Implement Art.12 AI Act record-keeping: automatic logs of high-risk AI system outputs with timestamps, inputs (where legally permissible), and decision audit trails.

Phase 4: Incident Response (Steps 23–27)

1. Build a unified AI incident classification decision tree mapping AI failures to DORA Art.18 major incident criteria and EU AI Act Art.73 serious incident criteria.
2. Establish dual notification workflows: DORA 4-hour initial notification and EU AI Act 2/10/15 working-day notification, running in parallel.
3. Designate incident reporting contacts for each authority: DORA NCA/ESMA contact, AI Act market surveillance authority contact, MiCA NCA contact.
4. Run an AI-specific incident simulation that tests both DORA and AI Act notification timelines simultaneously — validate that your team can meet the 4-hour DORA clock while also initiating AI Act procedures.
5. Document Art.71 MiCA client communications procedures for AI failures affecting client-facing services.

Phase 5: Audit Readiness (Steps 28–30)

1. Conduct a pre-August 2026 AI Act readiness audit: review all high-risk AI systems against Art.9–16 and Art.26 requirements.
2. Prepare DORA TLPT (threat-led penetration testing) documentation per Art.26 if your CASP qualifies as significant — include AI systems as in-scope TLPT targets.
3. Establish annual review cycle: schedule annual reviews of the triple compliance matrix as MiCA supervisory practice develops, DORA RTS are updated, and EU AI Act guidance from ESMA and the EU AI Office evolves.

Infrastructure for Triple-Compliant CASP AI

Running MiCA + DORA + EU AI Act compliance simultaneously is operationally complex. The infrastructure layer simplifies or complicates that complexity.

EU-jurisdiction compute: Deploying AI inference and model serving on EU-jurisdiction providers (Hetzner Germany, OVHcloud France, Scaleway) eliminates US CLOUD Act exposure from your MiCA Art.73 outsourcing documentation, DORA Art.30 data location provisions, and GDPR Chapter V transfer analysis simultaneously.

Audit trail infrastructure: DORA's Art.11 recovery and Art.19 incident reporting, EU AI Act's Art.12 record-keeping, and MiCA's Art.68 governance documentation all require comprehensive audit trails. A single audit trail infrastructure on EU-jurisdiction object storage satisfies all three simultaneously.

Containerised AI serving: Running AI model inference in containerised deployments with explicit versioning enables the model version documentation required by EU AI Act Art.11, the ICT asset inventory required by DORA Art.6, and the service continuity documentation required by MiCA Art.73.

sota.io provides EU-jurisdiction managed infrastructure (Hetzner Germany, no US parent, CLOUD Act-free) with git-based deployment for containerised AI workloads — designed for the intersection of MiCA, DORA, and EU AI Act compliance requirements.

Key Deadlines for CASP AI Compliance

For most CASPs, MiCA and DORA compliance is already ongoing. The 2 August 2026 AI Act deadline for high-risk AI is the remaining hard deadline — and only CASPs with margin lending credit-scoring AI or biometric KYC AI face high-risk obligations. All other CASPs face Art.50 transparency obligations (for client-facing AI) and DORA ICT governance obligations for AI systems as ICT assets.

Conclusion

MiCA, DORA, and the EU AI Act create a compliance stack for crypto platforms that is more complex than any single sector has faced before. The key insight for CASP developers is that the regimes operate at different layers: MiCA governs CASP authorisation and service conduct; DORA governs ICT resilience and incident reporting; and the EU AI Act governs AI system classification, documentation, and incident reporting for qualifying systems. Most CASP AI (fraud detection, trading algorithms, portfolio automation) is subject to DORA as ICT assets but does not trigger EU AI Act high-risk obligations. Only CASP AI used in credit scoring for margin facilities or biometric KYC triggers the full AI Act high-risk stack.

Build your compliance program in layers: DORA ICT risk governance for all AI systems, followed by EU AI Act high-risk obligations for those that qualify, within the MiCA governance framework that wraps both.

The next and final post in this series (Part 5) will deliver the complete intersection compliance checklist covering all dual-regulated entity types.

sota.io publishes practical EU compliance guides for developers. For further reading: EU AI Act Art.73 incident reporting timeline guide and the DORA incident reporting operations series.