MiCA and DORA Meet in the Same Training Room

The dialogue agenda is not a change in law

The Commission’s implementation dialogue (finance.ec.europa.eu) was scheduled for 27 October 2026, covering MiCA simplification and DORA proportionality. As of 28 October 2026, its event page marks it ended but still promises a later summary. The agenda should not be treated as published conclusions or a new legal training requirement.

For a bank developing crypto services, the useful design question is concrete. Can product, support, operations and technical teams handle the same customer-impacting event without losing ownership between departments?

One academy still needs separate legal maps

DORA’s Article 2 (eur-lex.europa.eu) includes credit institutions and MiCA-authorised crypto-asset service providers. Curriculum design should nevertheless start with compliance counsel validating each entity, asset classification, service and applicable provision—not assuming every partner or activity has identical obligations.

MiCA’s Article 71 (eur-lex.europa.eu) requires crypto-asset service providers to maintain complaints procedures and records. MiCA training should translate applicable customer-facing policies into clear product explanations, complaint handling and escalation decisions.

DORA Article 13(6), as explained by EIOPA (eiopa.europa.eu), already requires compulsory ICT security awareness and operational-resilience training for employees and senior management, proportionate to their functions. DORA training therefore needs role-specific depth, not just a technical course assigned to IT.

Four role paths make handoffs testable

A proposed role × activity × evidence map gives each path a distinct task, output and escalation owner.

• Product and support explain service limits and handle complaints; evidence includes a drafted response and a correct handoff to the complaints owner.
• Operations reconcile affected transactions and assess service impact; evidence includes a checked exception log and escalation to the incident lead.
• Security and ICT investigate disruption and recovery options; evidence includes an incident timeline and a handoff to the designated classification owner.
• Compliance and risk assess applicable obligations; evidence includes a reasoned decision and escalation through the approved reporting authority.

One disruption exposes several decision boundaries

Consider a hypothetical custody-service disruption that delays withdrawals while clients complain. Support drafts an accurate update without promising an unconfirmed recovery time. Operations identifies affected transactions. ICT preserves evidence and evaluates recovery options. The designated reporting owner applies approved classification thresholds.

The exercise should produce linked but distinct complaint and incident records. Assessment focuses on missing information, ownership and escalation—not whether everyone remembers the same definitions. This makes crypto compliance training and operational resilience learning meet at the handoff.

Policy versions belong in the evidence trail

MiCA’s continuity rules (eur-lex.europa.eu) require business-continuity policy modifications to reach relevant internal staff. A proposed academy workflow should connect each change to affected lessons, role assignments and reassessment decisions.

The learning record should identify the learner, role, policy version, task response, assessor and remediation. An App-Learning deployment could organise these paths within role-based internal academies with traceable learning progress. Legal interpretation, control ownership and incident reporting would remain with the bank’s designated functions.

A 30-day pilot tests the operating model

1. Days 1–7 — Confirm scope and accountable owners for one crypto service.
2. Days 8–14 — Build four short role paths and agree task-level assessment criteria.
3. Days 15–21 — Run the shared disruption exercise and capture individual decisions.
4. Days 22–30 — Review handoff delays, assessment errors and unresolved ownership, then revise and retest.

The pilot succeeds when the bank can show who recognised the problem, who acted and why the handoff was sound. Shared infrastructure is useful. Shared ambiguity is not.