EU AI Act Compliance for CASPs: What to Do Before August 2026
- Apr 27
- 19 min read
Updated: Apr 30
~18 min read – A practitioner's guide to the EU AI Act for MiCA-licensed crypto-asset service providers: classification, requirements, MiCA/DORA overlap, and a compliance checklist.
Jump to:
TL;DR – Does the AI Act Apply to Your CASP?
Yes – but the burden is narrower than you think.
The EU AI Act (Regulation 2024/1689) applies to every entity deploying AI systems that affect EU persons – including MiCA-licensed CASPs, regardless of where you are headquartered.
Most CASP AI is not high-risk. Fraud detection is explicitly excluded. AML/CTF transaction monitoring is not high-risk under the prevailing regulatory interpretation (CSSF, EU AI Office). Chatbots, internal tools, market analytics, and code assistants are minimal risk.
Credit scoring AI is high-risk. If you use AI to assess whether a natural person qualifies for crypto-backed lending, that system falls under Annex III, Point 5(b) – with full compliance obligations including a Fundamental Rights Impact Assessment.
KYC is a grey area. Biometric identification (face-matching) may be high-risk under Annex III, Point 1. Document-only verification without biometrics is likely not.
The deadline is 2 August 2026. The Digital Omnibus proposal could extend this, but it has not been adopted and likely won't be before the deadline hits. Treat August 2026 as binding.
You don't need parallel compliance systems. The AI Act contains six specific provisions allowing CASPs to integrate AI obligations into existing MiCA and DORA frameworks.
Start with the inventory. Catalogue your AI systems, classify them, and determine your provider/deployer status for each. See the [compliance checklist](#eu-ai-act-compliance-checklist-for-casps) below.
The EU AI Act in 60 Seconds
The EU AI Act (Regulation 2024/1689) applies a risk-based framework to AI systems across the EU.
Risk tier | What it means | CASP examples | Obligations |
Prohibited | Banned outright | Social scoring, emotion recognition in the workplace, manipulative subliminal techniques | Cannot be deployed |
High-risk | Full compliance regime | Credit scoring for crypto lending, biometric KYC (potentially) | Risk management, documentation, human oversight, conformity assessment, FRIA |
Limited risk | Transperancy only | Customer service chatbots, AI-generated content | Must disclose that the user is interacting with AI (Art. 50) |
Minimal risk | No specific obligations | Internal search, market analytics, fraud detection, AML/TM (prevailing view), code assistants | AI literacy training only (Art. 4) |
The key date: High-risk system obligations apply from 2 August 2026 – roughly four months from now.
The Digital Omnibus wildcard: The Commission's November 2025 proposal could push the high-risk deadline to December 2027, but it has not been adopted and every major law firm advisory recommends treating August 2026 as binding. The EDPB/EDPS joint opinion cautioned that postponement "undermines legal certainty and fundamental rights protection." Conformity assessment takes 6–12 months – the timeline does not allow for a wait-and-see approach.
For more information, see the EU AI Act official website.
Which Financial Services AI Systems Are High-Risk?
This is the question that determines whether the AI Act creates material compliance work for your CASP or stays in the background.
AI Act and Credit Scoring: Why Crypto Lending AI Is High-Risk
Annex III, Point 5(b) classifies as high-risk: "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 CASP uses AI to assess whether a natural person qualifies for credit – including crypto-backed lending, DeFi lending facilitation through a regulated interface, or any form of automated credit decisioning – that system is high-risk. No ambiguity in the text.
The implications:
Full compliance with Articles 9–15 (risk management, data governance, documentation, logging, transparency, human oversight, accuracy/robustness)
Internal conformity assessment under Annex VI
A Fundamental Rights Impact Assessment (Article 27) – mandatory for credit scoring deployers, must be notified to the market surveillance authority
CE marking and EU database registration (for providers)
Note the explicit carve-out: AI systems whose purpose is detecting financial fraud are excluded from high-risk status. This exclusion is written into the operative text, not just the recitals.
AML/CTF Transaction Monitoring: The Classification Ambiguity
This is the highest-stakes classification question for CASPs – and it does not have a definitive answer yet.
AML transaction monitoring is not explicitly listed as high-risk in Annex III. It is also not named in the fraud detection exclusion. Two competing interpretations exist:
The majority view – supported by the CSSF (Luxembourg's financial regulator) in its second thematic review on AI, the EU AI Office's stakeholder analysis, and multiple compliance analysts – holds that AML/CTF monitoring is not high-risk. The reasoning: AML monitoring is not "evaluating creditworthiness." It is a crime-detection function analogous to fraud detection. Recital 58 reinforces this by stating that AI systems "for the purpose of detecting fraud in the offering of financial services" should not be considered high-risk.
The minority view – advanced by some AML technology vendors – contends that transaction monitoring constitutes high-risk because it involves profiling natural persons. Article 6(3) states that an Annex III system performing profiling is always high-risk. However, this override only engages for systems already within an Annex III category. If AML monitoring does not fall within any Annex III category to begin with, the profiling provision does not apply.
Practical advice: The weight of authoritative interpretation supports "not high-risk." But the position carries residual regulatory risk. The Commission was required to publish classification guidelines by 2 February 2026 under Article 6(5). CASPs should consult those guidelines for definitive clarity once they are published. Until then: treat AML/TM AI as not high-risk, but document your classification rationale – so you can demonstrate to your NCA that you considered the question seriously.
For a deeper look at how transaction monitoring systems work in practice, see our three-layered transaction monitoring approach.
KYC and Identity Verification
If your KYC process uses biometric identification (face-matching against an identity document), it may be high-risk under Annex III, Point 1 (biometric identification systems). If it uses document verification without biometrics – OCR, database checks, PEP/sanctions screening – it is likely not high-risk.
The distinction matters: biometric KYC triggers the full Art. 9–15 AI Act compliance regime. Non-biometric KYC does not. Check with your KYC vendor (Jumio, Veriff, Onfido, etc.) whether their system performs real-time biometric identification as defined by the AI Act.
Note for dual-authorised firms: if you hold both MiCA and MiFID II licences, ESMA's May 2024 Public Statement on AI and Investment Services applies directly to AI used in client-facing services.
One More: AI-Powered HR Tools
Annex III, Point 4(a)–(b) covers AI for recruitment, hiring, performance evaluation, and task allocation. If your CASP uses AI-powered resume screening, candidate scoring, or performance evaluation tools, those systems are high-risk – even though they have nothing to do with crypto. This catches many firms by surprise.
What's NOT High-Risk: The Majority of Your Stack
Most AI tools at a typical CASP fall outside the high-risk classification:
AI use case | Risk classification | Obligations |
Fraud detection | Minimal (explicitly excluded by Annex III, 5(b)) | * |
AML/CTF transaction monitoring | Minimal (prevailing interpretation) | * + document classification rationale |
Customer service chatbot | Limited risk | Disclose AI interaction (Art. 50) |
Internal search / document tools | Minimal | * |
Marketing automation | Minimal | * |
Market analytics / price prediction | Minimal | * |
AI-generated content for clients | Limited risk | Mark as AI-generated (Art. 50(2)–(4)) |
AI-powered code assistants | Minimal | * |
* All minimal-risk systems: AI literacy (Art. 4) only – no further AI Act obligations.
For AI-heavy platforms, classification feeds directly into your regulated operating model.
Classification Decision Tree
For each AI system at your CASP, work through this logic:
Is the system within an Annex III category? (credit scoring, biometric identification, recruitment, etc.)
No → Not high-risk. Check if it requires transparency obligations (Art. 50 for chatbots / AI-generated content). Otherwise, minimal risk – AI literacy only.
Yes → Continue to step 2.
Does the system perform profiling of natural persons? (Article 6(3))
Yes → Always high-risk. No derogations available.
No → Continue to step 3.
Does a derogation apply? (Article 6(3)(a)–(d) – narrow exceptions for systems that perform a purely procedural task, improve the result of a previously completed human activity, detect decision patterns without replacing human assessment, or are merely preparatory to an assessment)
Yes → Not high-risk, but document the derogation assessment and register under Article 49(2).
No → High-risk. Full Art. 9–15 requirements apply.
EU AI Act Compliance Requirements for High-Risk Systems
The ECB found in late 2025 – based on workshops with 13 major banks – that even established financial institutions have an "accountability gap" in their second and third lines of defence for AI oversight. CASPs – typically leaner organisations – face the same gap with fewer internal layers to absorb it.
Here is what the AI Act requires for each high-risk obligation – and what it looks like in practice at a CASP.
Risk Management System (Article 9)
The obligation: A continuous, iterative risk management process that runs throughout the AI system's entire lifecycle – not a one-time assessment. Must identify known and foreseeable risks (9(2)(a)), evaluate risks during intended use and misuse (9(2)(b)), incorporate post-market monitoring data (9(2)(c)), and adopt appropriate risk management measures (9(2)(d)). Testing must use "prior defined metrics and probabilistic thresholds" with specific attention to vulnerable groups.
The bridge to existing frameworks: Article 9(10) explicitly allows integration: "For providers of high-risk AI systems that are subject to requirements regarding internal risk management processes under other relevant provisions of Union law, the aspects provided in paragraphs 1 to 9 may be part of, or combined with, the risk management procedures established pursuant to that law." This means CASPs can build AI risk management into their MiCA and DORA risk frameworks – not as a parallel system.
In practice for a CASP: Extend your existing MiCA Art. 68 risk framework with AI-specific elements: false positive/negative rates for credit scoring, bias analysis in training data (e.g., does the model disproportionately reject applicants from certain jurisdictions?), adversarial manipulation risks, and post-deployment monitoring of model drift. Document risk tolerances and review continuously.
For a deeper dive on building the governance layer that AI Act compliance plugs into, see our guide on post-authorisation operational governance.
Data Governance (Article 10)
The obligation: Training, validation, and testing datasets must be "relevant, sufficiently representative, and to the best extent possible, free of errors and complete" (Art. 10(3)). Must address: design choices, data origins, preparation steps, bias examination, and gap identification.
In practice for a CASP: For credit scoring AI, demonstrate that training data represents the population being assessed – not just a sample from one jurisdiction or demographic. Document data lineage, cleaning steps, and bias assessments. For KYC AI, ensure training data covers diverse identity documents across relevant jurisdictions.
Technical Documentation (Article 11)
The obligation: Annex IV-compliant documentation covering: system architecture, algorithms, training methodology, key design choices, validation and testing results, risk management details, and post-market monitoring plans. Must be drawn up before deployment and kept up to date.
In practice for a CASP: If you operate a credit scoring model, document the model architecture, training data sources and vintage, performance benchmarks (accuracy, false positive rate), known limitations (e.g., reduced reliability for applicants without on-chain history), and monitoring procedures for model drift. Article 18(3) allows you to maintain this within your existing MiCA/DORA documentation – no separate repository needed. SMEs and start-ups can provide simplified documentation under Article 11(1).
Logging and Record-Keeping (Article 12)
The obligation: Automatic recording of events (logs) over the system's lifetime, with traceability appropriate to the intended purpose. Article 19(2) allows integration into existing financial services record-keeping.
In practice for a CASP: Ensure the AI system logs each analysis run, inputs, outputs (risk scores, alerts, decisions), confidence levels, and timestamps. For credit scoring: log each application assessed, the model version, the input data, the score produced, and whether a human reviewed or overrode the result.
Transparency and Information to Deployers (Article 13)
The obligation: The system must be sufficiently transparent for deployers to interpret outputs and use them appropriately. The provider must supply instructions covering: performance characteristics, limitations, known failure conditions, human oversight requirements, and input data descriptions.
In practice for a CASP using third-party AI: Your vendor (Chainalysis, Jumio, or whoever supplies the AI system) must provide you with clear documentation on how scores are generated, known limitations, recommended oversight procedures, and how to interpret outputs. If your vendor cannot supply this, you have a compliance gap.
Human Oversight (Article 14)
The obligation: The system must be designed so natural persons can effectively oversee it. Assigned individuals must be able to: fully understand the system's capacities and limitations, remain aware of automation bias, correctly interpret outputs, override or reverse AI decisions, and intervene or halt the system.
In practice for a CASP: Compliance officers reviewing AI-generated credit decisions must be able to understand why the system scored an applicant a certain way, override false positives/negatives, and halt system operation if anomalies are detected. This requires training on automation bias – the tendency to over-trust AI outputs. This is new work – MiCA governance does not cover it. MiCA gives you the organisational structure; the AI Act adds the human-machine interface design.
Accuracy, Robustness, and Cybersecurity (Article 15)
The obligation: An appropriate level of accuracy, robustness, and cybersecurity throughout the lifecycle. Must address feedback loops in continuously learning systems and resilience against adversarial attacks (data poisoning, model poisoning, adversarial examples).
In practice for a CASP: Define measurable accuracy metrics (precision, recall) for each high-risk system. Implement protection against adversarial attacks – for blockchain analytics, this means addressing mixing services and obfuscation techniques. For credit scoring, address feedback loops where the model's past decisions influence future training data.
Conformity Assessment: What CASPs Actually Need to Do
Most readers expect conformity assessment to be a formal audit by an external body. For financial services AI, it is not.
Internal Self-Assessment Is the Default
Article 43(2) is clear: for high-risk AI systems under Annex III, Points 2–8 (which includes credit scoring at Point 5(b)), the conformity assessment is internal – no notified body, no third-party auditor. The provider conducts self-assessment under Annex VI.
The three steps:
Verify that your quality management system (Article 17) is in place and covers AI-specific elements
Examine your technical documentation (Article 11 / Annex IV) against Articles 9–15
Verify that the design, development, and monitoring process is consistent with the documentation
After passing: draw up an EU Declaration of Conformity (Article 47), affix CE marking (Article 48), register in the EU database (Article 49).
What this means for a CASP: If you are the provider of a high-risk AI system (e.g., you built your own credit scoring model), you conduct this assessment internally. It is a documentation and verification exercise, not an external audit. The underlying quality management system can leverage existing MiCA/DORA governance under Article 17(4).
Provider vs. Deployer: Who Is Responsible for What
Scenario | Provider | Deployer | Who does what |
CASP uses Chainalysis for blockchain analytics | Chainalysis | CASP | Chainalysis handles conformity assessment. CASP follows instructions for use, assigns human oversight, monitors operations, keeps logs for ≥6 months. |
CASP uses Jumio for KYC verification | Jumio | CASP | Same as above |
CASP integrates an LLM API into a high-risk workflow | LLM supplier (GPAI provider) | CASP – but may become provider | If the CASP substantially modifies the system or integrates it into a new high-risk application, the CASP may become the provider of the integrated system. |
CASP builds its own credit scoring model | CASP | CASP | CASP is both provider and deployer. Full Art. 9–15 + conformity assessment obligations. |
What this means for a CASP customising a vendor tool: Article 25(1) triggers provider status when you: put your own name/trademark on the system, make a substantial modification that keeps it high-risk, or change the intended purpose so a non-high-risk system becomes high-risk. Retraining a model with proprietary data or adjusting scoring thresholds could cross the "substantial modification" line. If in doubt, document your assessment and seek clarity from the vendor on the modification boundary.
Fundamental Rights Impact Assessment (Article 27)
Article 27(1) requires a FRIA before deploying a high-risk AI system listed in Annex III, Points 5(b) or 5(c) – regardless of whether the deployer is public or private. Any CASP deploying credit scoring AI must conduct a FRIA.
The FRIA must contain (Article 27(1)(a)–(f)): a description of deployment processes, the period and frequency of use, categories of persons affected, specific risks of harm, human oversight measures, and measures to take if risks materialise.
What this means for a CASP: If you already have a GDPR Data Protection Impact Assessment for your credit scoring system, the FRIA complements it – overlapping elements need not be duplicated (Article 27(4)). But FRIA-specific elements (fundamental rights risk analysis, categories of affected persons, harm mitigation) must still be addressed. The FRIA must be notified to your market surveillance authority (Article 27(3)) – this is an additional reporting obligation with no MiCA or DORA equivalent.
You now know what the AI Act requires for high-risk systems and how conformity assessment works. The next question is how these requirements interact with the frameworks you already comply with.
The Triple Overlap: MiCA, DORA, and the AI Act
Consider a concrete example: your CASP deploys an AI-driven credit scoring system for crypto-backed lending. Here is what hits you simultaneously:
MiCA Article 68 requires sound governance arrangements with clear lines of responsibility. The board must oversee the decision to deploy AI for credit decisions. Policies must exist. Reporting lines must be documented.
DORA requires that the AI system – as an ICT asset – be covered by your ICT risk management framework (Articles 5–16), including incident reporting (Articles 17–19) and third-party risk management if the AI is vendor-supplied (Articles 28–30).
Three frameworks apply to the same system. The practical question: does this mean three parallel compliance tracks, or can you build one integrated system?
MiCA Governance Provides the Skeleton; the AI Act Adds AI-Specific Muscle
MiCA Article 68's governance requirements provide the organisational structure: clear roles, reporting lines, board oversight. The AI Act's Article 9 risk management and Article 14 human oversight add the AI-specific operational layer – bias monitoring, model drift detection, automation bias training, and the ability to override AI decisions.
Article 9(10) explicitly permits integration: AI risk management "may be part of, or combined with, the risk management procedures established pursuant to" existing financial services law. You don't build two risk frameworks – you extend your MiCA one. If you haven't yet obtained your MiCA licence, see our CASP licensing guide for the process and requirements.
But human oversight (Article 14) is additional. MiCA tells you who is responsible. The AI Act tells you what those responsible people must be able to do with the AI system specifically – understand it, interpret it, override it, halt it.
DORA ICT Risk and AI Act Requirements Run in Parallel
BaFin's January 2026 guidance – the most comprehensive NCA treatment to date – explicitly classifies AI systems as ICT assets under DORA, requiring integration into the full DORA lifecycle: development, deployment, operation, and decommissioning.
Where they overlap:
ICT risk management (DORA Art. 5–16) covers the operational resilience of AI systems. The AI Act adds AI-specific risk elements (bias, model drift, adversarial resilience). Article 9(10) permits a single integrated framework.
Incident reporting: DORA handles operational incidents. The AI Act, per Article 73(9), limits its reporting to fundamental rights infringements only where equivalent reporting exists under other EU law. CASPs report AI-related operational incidents under DORA and only fundamental rights incidents under the AI Act.
Third-party risk: For vendor-supplied AI (Chainalysis, Jumio, cloud-hosted models), DORA requires pre-contractual due diligence, contractual provisions (Art. 30), and ongoing accountability. The AI Act adds provider/deployer obligations (Art. 26). These are cumulative – you manage the vendor under both frameworks simultaneously.
Six Burden-Reduction Provisions That Save You From Building Parallel Systems
The AI Act was designed with financial services in mind. Recital 158 explicitly aims "to avoid overlaps" through "limited derogations." Here are the six provisions that reduce the compliance burden for CASPs already subject to MiCA and DORA:
Article | What it allows | What still requires new work |
Art. 17(4) | QMS obligations met by existing FS internal governance | Risk management (Art. 9), post-market monitoring (Art. 72), serious incident reporting (Art. 73) |
Art. 18(3) | Technical documentation kept within existing FS documentation | AI-specific documentation elements (Annex IV) |
Art. 19(2) | Logs kept within existing FS record-keeping | AI-specific logging fields |
Art. 26(5)–(6) | Deployer monitoring via existing internal governance | AI-specific monitoring metrics |
Art. 72(4) | Post-market monitoring integrated with existing FS monitoring | Must achieve "equivalent level of protection" |
Art. 73(9) | Incident reporting limited to fundamental rights infringements where DORA reporting exists | FRIA notification (Art. 27) is separate |
What is net-new – four items that cannot be absorbed into existing frameworks:
AI-specific risk management processes – bias assessment, model drift monitoring, adversarial resilience testing, vulnerable group impact analysis
Human oversight interface design – training on automation bias, the ability to override/halt AI decisions, documentation of oversight procedures
Conformity assessment and CE marking – Annex VI self-assessment, EU Declaration of Conformity, EU database registration
FRIA for credit scoring – fundamental rights analysis, notification to market surveillance authority
The Supervisory Guidance Gap
No EU supervisory body has published guidance specifically addressing CASPs and the AI Act.
The EBA's November 2025 factsheet covers banks and payment institutions under CRR/CRD – not CASPs under MiCA. ESMA's AI guidance (May 2024) covers MiFID II investment firms – not CASPs. No Joint ESA (EBA/ESMA/EIOPA) guidance on AI in financial services has been published. No NCA has issued CASP-specific AI Act guidance.
The AI Board Subgroup on Financial Services and the Commission's guidelines under Article 96(1)(e) are the most likely sources of future clarity – expected in 2026–2027. Until then, CASPs must navigate by analogy from banking and investment firm frameworks. For a broader look at designing AI workflows within compliance constraints, see our AI in Compliance guide.
With the requirements and regulatory overlaps mapped, here's what to do.
EU AI Act Compliance Checklist for CASPs
Eleven steps, in order. For each: what it is, and whether it leverages existing MiCA/DORA infrastructure or requires new work.
If your firm also has undocumented or informal AI usage – LLMs used by staff for drafting, AI tools adopted without governance approval – the AI Act widens your exposure. See our analysis of Shadow AI in regulated firms for why ungoverned AI is a compliance risk multiplier. For a comparison of AI tooling options, see our AI compliance tools FAQ.
Inventory all AI systems. Catalogue every AI system in use – in-house and third-party. Include the vendor name, intended purpose, data inputs, and deployment date. Leverages existing MiCA/DORA asset inventory processes, but requires AI-specific classification fields.
Classify each system. Apply the decision tree above: Is it in Annex III? Does it profile? Does a derogation apply? Document the rationale for each classification. New analysis, but can be documented within existing risk register.
Assign provider/deployer roles. For each system, determine: who is the provider, who is the deployer? If you've customised a vendor tool, assess whether the modification crosses the Article 25(1) threshold. New analysis.
For high-risk systems: build the risk management system. Extend your MiCA Art. 68 governance and DORA ICT risk framework with AI-specific elements under Article 9. If you need to build your MiCA governance foundation first, see our [MiCA compliance checklist](/post/mica-compliance-checklist). Integrates with existing frameworks (Art. 9(10)), but AI-specific elements are new.
Prepare technical documentation. Annex IV-compliant documentation for each high-risk system. Can be maintained within existing FS documentation (Art. 18(3)). AI-specific fields are new.
Design human oversight protocols. Designate competent individuals who can understand, interpret, override, and halt AI decisions. Train them on automation bias. Document the procedures. Net-new work – this is not covered by MiCA governance alone.
Conduct conformity assessment. Internal self-assessment under Annex VI: verify QMS, examine documentation against Art. 9–15, verify process consistency. Issue EU Declaration of Conformity, affix CE marking, register in EU database. No MiCA/DORA equivalent – this is entirely new work.
Complete the FRIA. For credit scoring AI deployments: fundamental rights analysis, categories of affected persons, risk mitigation measures, human oversight description. Notify the market surveillance authority (Art. 27(3)). Complement your existing GDPR DPIA where applicable. Net-new reporting obligation.
Vendor due diligence. For third-party AI tools: verify provider has completed conformity assessment, obtain instructions for use (Art. 13), and contractually require information sharing – Art. 25(4) requires providers to specify "the necessary information, capabilities, technical access and other assistance" to enable your compliance. Monitor for substantial modifications that could shift provider status. Builds on DORA Art. 28–30 third-party risk processes, but AI-specific elements are new.
Train staff on AI literacy. Article 4 has applied since 2 February 2025. Per the Commission's 2025 Q&A, no external certification is required – but organisations should document training undertaken and tailor it to roles. For high-risk system oversight personnel, Article 26 requires "necessary competence, training and authority." Overlaps with ESMA's MiCA Knowledge and Competence guidelines. AI-specific content is new.
Establish board-level AI governance reporting. Integrate AI oversight into existing MiCA Art. 68 governance structures. Board members must understand key AI risk concepts. Report on AI system inventory, classification, risk assessments, and compliance status. Leverages existing governance bodies. The AI-specific reporting agenda is new. BaFin's January 2026 guidance recommends a management-approved AI strategy as the starting point.
What Happens If You Miss the Deadline
Your national financial supervisor is your AI Act enforcer. Article 74(6) designates the "relevant national authority responsible for the financial supervision" of regulated institutions as the market surveillance authority for AI. In practice:
Jurisdiction | AI Act Supervisor |
Germany | BaFin |
Luxembourg | CSSF |
France | AMF / ACPR |
Lithuania | BoL |
The AI Act imposes a three-tier penalty structure:
Violation | Maximum fine |
Prohibited AI practices (Art. 5) | €35 million or 7% of global turnover |
High-risk non-compliance (Art. 16, 22–24, 26) | €15 million or 3% of global turnover |
Misleading information to authorities | €7.5 million or 1% of global turnover |
SME relief: For SMEs and start-ups, each fine is capped at whichever is lower – the fixed amount or the turnover percentage (Art. 99(6)).
No authority has taken formal enforcement action under the AI Act as of early 2026. But supervisory infrastructure is forming – Finland has operational enforcement powers, Spain established its AI authority (AESIA), and the EBA has announced 2026–2027 activities to promote a common supervisory approach through the AI Board Subgroup on Financial Services.
The posture is the same as early MiCA: build before they ask.
Conclusion
The AI Act's impact on CASPs is genuine but significantly narrower than the law firm headlines suggest. Most of your AI stack is minimal risk. The systems most likely to trigger full obligations are credit scoring for crypto lending and – depending on implementation – biometric KYC.
Where obligations do apply, you don't need to build from scratch. Six integration provisions let you extend your MiCA governance and DORA ICT risk frameworks. The work that cannot be absorbed into existing compliance comes down to four elements: AI-specific risk management, human oversight design, conformity assessment with CE marking, and the FRIA for credit scoring deployments.
The AML classification ambiguity deserves close monitoring – Commission guidelines should provide clarity. The Digital Omnibus could shift timelines, but treating it as anything other than a contingency would be imprudent.
For the operational governance layer these AI obligations plug into, see our post-authorisation governance guide.
Start with the inventory. EU AI Act compliance for CASPs begins with knowing what AI you actually run – everything else follows from there.
FAQ
What is the EU AI Act?
The EU AI Act (Regulation 2024/1689) is the EU's horizontal regulation for artificial intelligence. It establishes obligations for AI systems based on a four-tier risk classification: prohibited, high-risk, limited risk, and minimal risk. It entered into force on 1 August 2024, with high-risk system obligations applying from 2 August 2026.
Does the EU AI Act apply to crypto firms?
Yes. CASPs are financial entities regulated under EU law. Article 74(6) explicitly designates national financial supervisors as the AI Act market surveillance authorities for regulated financial institutions – including MiCA-licensed CASPs. The AI Act also has extraterritorial reach: it applies to any entity whose AI systems affect EU persons, regardless of where the company is headquartered.
What are high-risk AI systems under the EU AI Act?
High-risk systems are those listed in Annex III of the AI Act. For financial services, the key categories are: AI for evaluating creditworthiness or establishing credit scores (Annex III, Point 5(b)) and AI for risk assessment and pricing in life and health insurance (Annex III, Point 5(c)). Fraud detection AI is explicitly excluded from high-risk status.
Is AML transaction monitoring high-risk under the AI Act?
Under the prevailing regulatory interpretation – supported by the CSSF, the EU AI Office, and compliance analysts – AML/CTF transaction monitoring is not classified as high-risk. It is a crime-detection function analogous to the explicitly excluded fraud detection. However, this is not definitively settled. Some AML vendors argue it constitutes high-risk profiling under Article 6(3). CASPs should monitor the Commission's classification guidelines under Article 96(1)(e) for definitive clarity.
What must high-risk AI systems include?
High-risk systems must comply with Articles 9–15: a continuous risk management system (Art. 9), data governance practices (Art. 10), technical documentation (Art. 11), automatic logging (Art. 12), transparency to deployers (Art. 13), human oversight mechanisms (Art. 14), and appropriate accuracy, robustness, and cybersecurity (Art. 15). Financial institutions can integrate many of these into existing governance frameworks under six specific burden-reduction provisions.
How do MiCA, DORA, and the AI Act overlap?
They are cumulative but integrable. MiCA Article 68 provides the governance structure; the AI Act adds AI-specific risk management and human oversight. DORA governs ICT risk broadly; the AI Act adds AI-specific testing and monitoring. Article 9(10) permits integration of AI Act risk management into existing financial services frameworks. Six burden-reduction provisions (Articles 17(4), 18(3), 19(2), 26(5)–(6), 72(4), 73(9)) allow CASPs to avoid building parallel compliance systems.
What are the penalties for non-compliance with the EU AI Act?
Three tiers: up to €35 million or 7% of global turnover for prohibited practices; up to €15 million or 3% for high-risk non-compliance; up to €7.5 million or 1% for supplying misleading information. SME relief caps fines at the lower of the fixed amount or turnover percentage.
What should a CASP do before August 2026?
Start with a full AI system inventory. Then classify each system under the Annex III framework. For high-risk systems: build the risk management system, prepare documentation, design human oversight, conduct conformity assessment, and complete the FRIA if deploying credit scoring AI. For all systems: ensure staff AI literacy training (Article 4 – already in force). See the [compliance checklist](#eu-ai-act-compliance-checklist-for-casps) above for the full 11-step process.
Comments