MiCA and DORA land on the same CASP: what happens next depends on your back office

Second in the Forest MiCA series by Nicolas Devillard, Forest's CRO. When MiCA and DORA supervision hit the same crypto-asset service provider on the same incident, what happens next depends on the back office your compliance team works in.

Since 30 December 2024, every crypto-asset service provider (CASP) authorised under the EU's Markets in Crypto-Assets regulation (MiCA, Regulation (EU) 2023/1114) has been running on two rails at once. MiCA is the EU framework that authorises crypto-asset service providers and supervises how they run their business, from client onboarding to market conduct to complaints handling. Alongside it, the Digital Operational Resilience Act (DORA, Regulation (EU) 2022/2554) supervises the operational resilience of the systems that same business runs on. Same firm, same infrastructure, two regulators asking two different questions about the same case.

The temptation is to treat them as separate compliance programmes with separate teams. Six months in, that is how most CASPs are structured. It is not how the information and communications technology (ICT) incident that lands in your queue tomorrow will look. What happens next, when both rails hit at once, comes down almost entirely to the back office your compliance team works in.

MiCA and DORA supervision: what each regulator actually asks a CASP to prove

The MiCA rail sits on the CASP obligations under Titles V and VI of Regulation (EU) 2023/1114. Authorisation, prudential requirements, market abuse rules, transaction reporting, client-asset segregation, complaints handling. The National Competent Authority (NCA) supervises. The European Banking Authority (EBA) and the European Securities and Markets Authority (ESMA) co-ordinate.

The DORA rail sits on ICT risk-management, incident reporting, threat-led penetration testing, and third-party ICT provider oversight under Regulation (EU) 2022/2554. Same NCA in most member states, but a different reporting channel, different taxonomies, different escalation thresholds.

Both apply to the same CASP simultaneously, and both can trigger on operational events the firm may not have originally classified as reportable. What decides whether your compliance team can actually meet both rails on time is rarely headcount. It is whether the back office they work in every day was designed to hold one rail's worth of evidence, or two.

One KYC outage, two regulatory reports: how MiCA and DORA reporting overlap

Take a routine incident: a know-your-customer (KYC) provider outage during a peak-hours onboarding window. Twenty applications stall. Two customers escalate.

Under MiCA, this touches complaints handling (Article 71 of Regulation (EU) 2023/1114) and, depending on severity, transaction-reporting continuity. Under DORA, this is an ICT-related incident. If it hits the classification thresholds under Article 18 of Regulation (EU) 2022/2554, it is reportable to the NCA within a set clock, with an initial notification, an intermediate report, and a final report.

Same event. Two reports. Two clocks. Two different lenses on the same case timeline.

The question your back office has to answer at 4pm that day is straightforward: which parts of the case are you pulling into which report, and does the trail you paste into the DORA notification match the trail you paste into the MiCA complaint file?

The evidence problem: why two-rail supervision needs one operational record

The two rails need the same evidence trail. For any incident, both regulators want the same set of facts recorded on the case, and they want them recorded once:

• when the provider failed and when service restored

• who owned the case at each step, and under which role

• what the customer saw, and how they were notified

• what the fallback was, when it was invoked, and by whom

• what evidence supports each decision along the way

If those artefacts live in different systems, a customer-support tool for the customer contact, a separate ticketing tool for the ICT incident, a spreadsheet for the MiCA complaint, the firm ends up reconstructing the same story twice, from different sources, under two clocks. Regulators notice. The regulator who reads two versions of the same event asks why one has three timestamps and the other has none.

The firms that will scale under MiCA and DORA together are the ones whose back office builds one operational record per event, tagged for both rails, from the moment the signal fires.

What ESMA and the EBA have published on MiCA and DORA co-ordination

The EBA Guidelines on the classification of major ICT-related incidents (EBA/GL/2024/06) landed in June 2024, and they now shape how CASPs decide what has to escalate under DORA. In parallel, ESMA has been updating its Q&A on MiCA transaction reporting on a rolling quarterly basis. The two authorities co-ordinate on paper, but each one publishes into its own rail and leaves your firm to reconcile them internally. Compliance leads at CASPs end up reading both feeds every month and translating them into a single set of internal controls that their back office actually applies.

This ongoing translation is where a lot of the real compliance work sits. It is the reason a compliance officer at a CASP finds themselves asking "under which regulation are we recording this?" during incident review, and the reason the back office needs to know the answer for them, well before any export leaves the building.

The compliance back-office pattern that clears both MiCA and DORA reporting

The pattern that seems to be holding up in year one comes down to four decisions, ideally locked in early rather than retrofitted after the first joint inspection.

The first is to open one incident record per event, from the moment the signal fires. Not one per rail. Timestamps, actors, decisions, and provider responses all live on that single record from the start, whether the incident eventually goes to a MiCA export, a DORA export, or both.

The second is to build two report views on top of that record. A MiCA view that surfaces the fields Article 71 and the transaction-reporting rules require, and a DORA view that surfaces the fields Article 18 and the EBA guidelines require. The underlying facts are the same in both cases; only the framing changes.

The third is to handle provider swaps at the case level, not in a separate register. When a screening vendor returns an error and the workflow falls back to a second provider, that swap gets logged on the same case, with the reasoning attached. The DORA third-party register then updates from that trace, rather than from a spreadsheet someone maintains by hand.

The fourth is to keep case ownership with a named human. AI agents can triage the signal, draft the incident notification, and pre-fill the classification, but the decision to escalate belongs to a person with a defined role in your permission model. The back office is where that person works, and it is where the audit picks up their signature later.

How a shared compliance back-office turns two-rail supervision into one workflow

A dedicated compliance suite adds a tool to the stack and moves case data into someone else's cloud. Under DORA (Articles 28 to 30 of Regulation (EU) 2022/2554), that is a new critical ICT provider to assess, contract with, and plan an exit from. Your regulator will ask about that too.

We have built Forest as a back office your team runs the case in, on the database you already have and on your infrastructure, so that one record per event feeds both a MiCA-shaped export and a DORA-shaped export from the same underlying trace, without asking engineering to write a new join every quarter. One record per event, one audit trail, two report views.

Your team decides when to escalate. Your AI agents pre-fill the incident classification, draft the customer response, and stage the notification for a reviewer to sign off. Forest logs each step and each provider call along the way, so that the audit trail your NCA reads later is the same trail your ICT auditor reads. In practice, what happens next after an incident stops depending on which team happens to notice it first.

We are working with CASPs today who are running MiCA and DORA in parallel, and the intention has never been to add another compliance product to their stack. The intention is that the same team you already have can cover both rails from one shared operational back office.

What NCAs are expected to do in H2 2026: cross-rail inspections and third-party registers

Two developments are worth paying attention to over the rest of the year.

The first is the rise of cross-rail joint inspections. NCAs have signalled that where a firm's MiCA and DORA obligations are both in scope, they will co-ordinate their reviews rather than run them separately. In practice, that means the same case history has to hold up under two different sets of questions on the same day. Firms with a clean single-record trail in their back office will spend far less time reconstructing what happened, and far more time discussing what to improve.

The second is the third-party ICT provider register. Under Article 28 of Regulation (EU) 2022/2554, every CASP is required to maintain a register of its contractual arrangements with ICT third-party providers. That register overlaps materially with the outsourcing disclosures required under Article 73 of MiCA, so firms that treat the two as separate deliverables end up duplicating work their back office should already be doing once, from the same source of truth.

The two rails are here, the regulators expect firms to hold both simultaneously, and what happens next at your CASP depends squarely on the back office you have built to hold them.

If you'd like to see how this could work on your own stack (your database, your compliance panel), book time with one of our experts.

Forest is the operational infrastructure for regulated fintechs. Compliance, ops, and support teams work on your systems alongside your AI agents, under one permission model and one audit trail. On your own infrastructure. Learn more at forest.app.