Reporting & Controls Under MiCA, DORA and the Travel Rule

CASPs in Production: Reporting & Controls Under MiCA, DORA and the Travel Rule. European Master Study 2026

Executive summary

Three months after the MiCA transitional period closed on 1 July 2026, the hard problem for authorised CASPs is no longer the licence. It is producing, on demand, evidence that reporting and controls actually run. Supervisors have moved from authorisation to operational testing: ESMA launched a Common Supervisory Action (CSA) on CASPs' digital operational resilience for custody on 8 July 2026, running H2 2026 to H1 2027 (ESMA).

The five bottlenecks most likely to fail an inspection (Interpretation, built on official and supervisory signals cited in Section 3):

1. Record reconstruction. Order, transaction, wallet and client data sit in separate systems. Few CASPs can replay a client's full order-to-settlement lifecycle within hours, as MiCA Art. 68(9) and RTS (EU) 2025/1140 presuppose.
2. Travel Rule exception handling. Data transmission works on the happy path. Missing-information queues, self-hosted wallet verification and non-compliant counterparty CASPs are handled manually and inconsistently.
3. DORA incident reporting data quality. On 16 September 2026 the ESAs published operational instructions listing recurring errors in major-incident reports (missing final reports, changing incident identifiers, wrong classification criteria).
4. Register of Information (RoI) and DLT dependencies. Nodes, RPC endpoints, MPC/HSM vendors and blockchain analytics providers are often missing or misclassified, while the CSA explicitly tests third-party dependencies.
5. Policy-versus-practice gap. Controls described in authorisation files are not yet evidenced in production: no test logs, no calibrated surveillance, no owner-signed reviews.

What works. A single regulated data spine (one event-sourced record of client, order, transfer, wallet and incident data) feeding every regime's output, plus an evidence register per control. Section 6 sets out the target model and a 30/60/90-day plan.

Watch list. The Commission proposed on 4 December 2025 to move CASP supervision to ESMA (Proposed; trilogue pending). The MiCA review consultation closed 31 August 2026. AMLR applies from 10 July 2027. Each will change who inspects and what data is requested; none removes today's obligations.

Scope note. This is a desk study of public supervisory material, legal texts and project records, at EU level. National specifics sit in separate country top-ups, one per Member State. It is not a survey of CASPs; bottleneck prevalence is inferred and labelled as such.

1. Scope, method and currentness

Currentness check run on 1 October 2026 against EUR-Lex, ESMA, EBA/ESAs and the Commission. National sources are checked in each country top-up. Everything below is "as of" that date.

Member State scope. EU baseline. This master applies to a CASP authorised in any of the 27 Member States. Everything that varies nationally sits in a separate country top-up, one per Member State, read alongside this master: designated MiCA and DORA authorities, reporting channels, AML supervisor and FIU, transitional history, national implementing rules, sanctions and enforcement practice. Host and target-state analysis also sits in the top-ups. No national conclusion transfers from one top-up to another.

Entity classification. The subject is an authorised CASP under MiCA Art. 59/63. It is a financial entity under DORA Art. 2(1)(f), a CASP under TFR Art. 3(15), an obliged entity for AML/CFT, and, where it arranges or executes transactions, subject to MiCA Art. 92 surveillance duties. Each role carries direct obligations.

Evidence classes used. Binding law · Official clarification · Supervisory practice · Market practice/commentary · Interpretation · Assumption · Open question.

MiCA, Reg. (EU) 2023/1114

What it governs: authorisation, conduct, records, custody, market abuse.

Status: applicable since 30 Dec 2024; transitional regimes ended 1 Jul 2026.

RTS (EU) 2025/1140

What it governs: records of services, orders, transactions (Art. 68(10)).

Status: in force 30 Jun 2025 (OJ publication note).

RTS (EU) 2025/416

What it governs: order book records for trading platforms (Art. 76(16)).

Status: in force 3 Apr 2025.

RTS (EU) 2025/299

What it governs: continuity and regularity of services (Art. 68(7)).

Status: in force.

RTS (EU) 2025/885

What it governs: detection and prevention of market abuse (Art. 92).

Status: in force (application date to confirm on EUR-Lex).

DORA, Reg. (EU) 2022/2554

What it governs: ICT risk, incidents, testing, third parties.

Status: applicable since 17 Jan 2025.

RTS 2024/1772, RTS 2025/301, ITS 2025/302

What they govern: incident classification, content, timelines, templates.

Status: applicable.

ITS (EU) 2024/2956

What it governs: Register of Information templates.

Status: applicable; annual submission.

RTS 2024/1773, RTS 2025/532

What they govern: ICT contractual policy; subcontracting of critical functions.

Status: applicable / in force.

TFR, Reg. (EU) 2023/1113 + EBA/GL/2024/11

What they govern: Travel Rule data, missing-information handling.

Status: applicable since 30 Dec 2024.

ESAs Incident Reporting Operational Instructions

What they govern: data-quality expectations for major-incident reports.

Status: Official clarification (staff, non-binding), 16 Sep 2026.

ESMA CSA on CASP custody resilience

What it governs: DORA maturity for custody.

Status: Supervisory practice, H2 2026–H1 2027.

Market Integration and Supervision Package

What it governs: ESMA direct supervision of CASPs.

Status: Proposed, 4 Dec 2025; Parliament ECON draft report 12 Jun 2026.

AMLR, Reg. (EU) 2024/1624

What it governs: single AML rulebook.

Status: in force; applies 10 Jul 2027.

Limitations. This master names authorities only by their EU-law role (MiCA NCA under Art. 93, DORA competent authority under Art. 46, FIU, AML/CFT supervisor). Which body fills each role, and through which channel, is verified in each country top-up against national legislation.

2. The live obligation stack

An authorised CASP runs at least six recurring reporting and control streams at once, each with its own clock, format and recipient. All are Binding law unless marked otherwise.

Records

Core obligation: keep records of all services, activities, orders, transactions; give to clients on request; keep 5 years (up to 7 on NCA request).

Legal source: MiCA Art. 68(9); RTS 2025/1140.

Clock / trigger: continuous; on-demand extraction.

Recipient: home MiCA NCA (Art. 93), conduct/records function where competence is split.

What the inspector asks for: reconstructed client lifecycle, field-level lineage, retention proof.

Order book (trading platforms)

Core obligation: keep order book data in prescribed content and format; make available to NCA.

Legal source: MiCA Art. 76(15)–(16); RTS 2025/416.

Clock / trigger: continuous; on request.

Recipient: home MiCA NCA (Art. 93).

What the inspector asks for: order book extract in RTS format, time-synchronised.

Market abuse

Core obligation: systems to prevent and detect abuse; report suspicious orders/transactions without delay.

Legal source: MiCA Art. 92; RTS 2025/885.

Clock / trigger: event-driven (STOR).

Recipient: home MiCA NCA responsible for market integrity (STORs under Art. 92).

What the inspector asks for: alert logic, calibration evidence, alert-to-STOR audit trail.

ICT incidents

Core obligation: classify; report major incidents: initial ≤4h after classification and ≤24h after awareness; intermediate ≤72h; final ≤1 month after last intermediate.

Legal source: DORA Arts. 17–19; RTS 2024/1772; RTS 2025/301; ITS 2025/302.

Clock / trigger: event-driven.

Recipient: DORA competent authority (Art. 46), through the national reporting channel; some Member States add a national CSIRT notification (see country top-up).

What the inspector asks for: incident register, classification worksheets, submitted versions.

ICT third parties

Core obligation: maintain and submit Register of Information; contractual terms; exit plans.

Legal source: DORA Arts. 28–30; ITS 2024/2956; RTS 2024/1773; RTS 2025/532.

Clock / trigger: annual submission; continuous upkeep.

Recipient: DORA competent authority, which forwards registers to the ESAs.

What the inspector asks for: validated xBRL-CSV RoI, contract mapping, exit tests.

Travel Rule

Core obligation: transmit and verify originator/beneficiary data for every transfer; detect and handle missing data; verify self-hosted wallet ownership above EUR 1,000.

Legal source: TFR Arts. 14, 16, 17; EBA/GL/2024/11.

Clock / trigger: per transfer; counterparty review.

Recipient: national AML/CFT supervisor, on request.

What the inspector asks for: exception queue log, counterparty assessments, wallet-ownership evidence.

AML/CFT

Core obligation: CDD, monitoring, STR filing.

Legal source: national transposition of the AML Directive; AMLR from 10 Jul 2027.

Clock / trigger: event-driven.

Recipient: national FIU (STR); national AML/CFT supervisor (supervision).

What the inspector asks for: case files, scenario tuning, STR timeliness.

Continuity

Core obligation: business continuity plan; timely resumption.

Legal source: MiCA Art. 68(7); RTS 2025/299; DORA Art. 11.

Clock / trigger: annual test minimum.

Recipient: home MiCA NCA (prudential/organisational function where split) and DORA competent authority.

What the inspector asks for: BCP test reports, RTO/RPO evidence.

Safeguarding / custody

Core obligation: segregate client assets and funds; custody policy; liability for loss.

Legal source: MiCA Arts. 70, 75.

Clock / trigger: continuous; reconciliation.

Recipient: home MiCA NCA (prudential/safeguarding function where split).

What the inspector asks for: daily on-chain vs ledger reconciliation, key-management evidence.

The structural problem. These streams describe the same underlying events: one client order produces a record, a surveillance input, possibly a Travel Rule message, an AML monitoring event and, if systems fail, an ICT incident. Most CASPs built one pipeline per obligation during authorisation. Inspection exposes the inconsistencies between them.

3. Findings: where CASPs are breaking in production

Twelve bottlenecks emerge. Ten are rated High, mainly because each would leave a CASP unable to evidence a control it described at authorisation. Prevalence across the market is Interpretation; the supervisory signal behind each is cited.

F1 — Record reconstruction (High)

What breaks in production: orders in the matching engine, transfers in wallet infrastructure, clients in CRM, fees in finance. No shared keys or clocks; a full client replay takes days.

Supervisory signal: Art. 68(9) requires records sufficient for NCA supervision and enforcement; RTS 2025/1140 sets content (Binding law).

F2 — Market abuse surveillance and STORs (High)

What breaks in production: vendor rule sets run on defaults; no calibration record; on-chain and cross-venue activity not linked to orders; alert backlog without disposition rationale.

Supervisory signal: Art. 92; RTS 2025/885; ESMA guidelines on supervisory practices for market abuse under MiCA (Binding law; Official clarification).

F3 — Travel Rule exceptions (High)

What breaks in production: protocol fragmentation between counterparties; non-capable third-country VASPs ("sunrise issue"); manual missing-data queues; inconsistent self-hosted wallet ownership checks.

Supervisory signal: TFR Arts. 14, 16, 17; EBA/GL/2024/11 (Binding law; Official clarification). EBA rejected arguments that MiCA transitional status excused TFR non-compliance.

F4 — Counterparty CASP status after 1 July (High)

What breaks in production: transfers continue with counterparties whose national licence lapsed; Travel Rule counterparty files not refreshed against ESMA register.

Supervisory signal: ESMA statements of 17 Apr and 23 Jun 2026: unauthorised providers must cease and wind down (ESMA) (Official clarification).

F5 — DORA incident report quality (High)

What breaks in production: incident ID changes across report versions; "critical services affected" omitted; home state listed as geographical spread; final reports missing; monetary fields in wrong units.

Supervisory signal: ESAs Operational Instructions, 16 Sep 2026 (project file) (Official clarification, non-binding).

F6 — Crypto-specific incident triggers (High)

What breaks in production: chain halts, RPC outages, failed signing ceremonies, smart-contract exploits and wallet-provider breaches are not mapped to RTS 2024/1772 criteria; clocks start late.

Supervisory signal: DORA Art. 18; RTS 2024/1772 (Binding law); Interpretation on mapping.

F7 — Register of Information completeness (Medium–High)

What breaks in production: free text where codes are required; LEI errors; missing subcontracting chains; DLT providers absent. ESAs 2024 dry run: 6.5% of registers passed all 116 checks (commentary).

Supervisory signal: ITS 2024/2956; EBA validation rules (Binding law; Market commentary on results).

F8 — DLT infrastructure as ICT third party (High)

What breaks in production: node providers, RPC, MPC/HSM, custody tech, analytics, oracles not classified or contracted to Art. 30 standard. Whether a public permissionless network is an "ICT third-party service" remains unsettled.

Supervisory signal: ESMA CSA explicitly tests key management, transaction controls, smart-contract risk and third-party dependencies (ESMA) (Supervisory practice).

F9 — Custody key management evidence (High; Critical for custodians with no tested recovery)

What breaks in production: key ceremonies undocumented or unwitnessed; recovery never tested; quorum changes not logged; reconciliation on-chain vs ledger not daily.

Supervisory signal: MiCA Art. 75; DORA Arts. 9, 11; CSA scope (Binding law; Supervisory practice).

F10 — Outsourcing vs ICT third-party double regime (High)

What breaks in production: MiCA Art. 73 outsourcing and DORA Arts. 28–30 run as two registers with different criticality labels; group entities outside the EU perform core functions.

Supervisory signal: ESMA reminder that CASPs may not outsource certain services to non-EU unauthorised entities, 17 Apr 2026 (ESMA) (Official clarification).

F11 — Multi-authority reporting (Medium)

What breaks in production: the same incident or breach is narrated differently to the MiCA NCA, the DORA competent authority, the FIU and, where national law requires it, a national CSIRT. The risk is highest where MiCA competence is split between a conduct and a prudential authority.

Supervisory signal: MiCA Art. 93 allows Member States to designate more than one competent authority; DORA Art. 46 assigns DORA supervision to existing sectoral authorities (Binding law); Interpretation on practice. National allocation: see country top-up.

F12 — Policy-versus-practice gap (High)

What breaks in production: authorisation-file policies not yet operating: no test logs, no evidence owners, reviews unsigned.

Supervisory signal: shift from licensing to operational testing (CSA); Interpretation.

Two-sided view on the four decisive issues

F1 Record reconstruction. NCA view: records that cannot be produced promptly and consistently are not "sufficient" under Art. 68(9), whatever exists in raw logs. Company view: all data exists and is retained; extraction speed is not a legal requirement. Neutral: the defence holds only if the CASP can show completeness and integrity; manual, multi-day stitching invites a finding on Art. 68(9) and on internal controls.

F3 Travel Rule exceptions. NCA view: executing transfers with missing data, or without a documented risk-based decision, breaches TFR Arts. 16–17. Company view: EBA guidelines allow risk-based execute, reject, return or suspend decisions. Neutral: the discretion exists, but only with a written rationale per case and escalation for repeatedly failing counterparties.

F5/F6 Incident reporting. NCA view: late or inconsistent reports are a reporting failure in their own right. Company view: the ESAs' instructions are staff guidance, not law. Neutral: correct, but the instructions mirror how the templates are validated; ignoring them produces rejected or misread reports.

F8 DLT as ICT third party. NCA view: any external dependency supporting a critical function belongs in the risk framework and, where contracted, in the RoI. Company view: a permissionless network has no contractual counterparty and cannot be registered. Neutral: unsettled. The defensible position is to register contracted providers (node, RPC, custody tech) and treat the network itself as a documented ICT risk with concentration and exit analysis.

4. Where MiCA, DORA and the Travel Rule collide

Duplicated effort is concentrated in five overlaps; one data event usually feeds three regimes. Each overlap below shows where one control can serve several obligations.

Data integrity and records

MiCA source: Art. 68(8)–(9); RTS 2025/1140. DORA source: Arts. 9, 12. Other regime: TFR Art. 26 (5-year retention).

Overlap type: DORA operationalises MiCA.

Operational control: single immutable event store; retention schedule per regime.

Technology capability: append-only, hash-chained ledger; time sync.

Evidence: integrity checks, replay test results. Status: applicable.

Outsourcing vs ICT third parties

MiCA source: Art. 73. DORA source: Arts. 28–30; RTS 2024/1773; RTS 2025/532. Other regime: national outsourcing rules where applicable.

Overlap type: overlap, different criticality tests.

Operational control: one supplier inventory, dual classification (MiCA outsourced function / DORA critical-or-important).

Technology capability: supplier master data with LEI, function mapping.

Evidence: RoI, contracts mapped to Art. 30. Status: applicable.

Incident reporting

MiCA source: Art. 68(7) continuity; NCA notifications. DORA source: Arts. 17–19; RTS 2024/1772; RTS 2025/301. Other regime: GDPR Art. 33 (72h); NIS2 where applicable.

Overlap type: parallel clocks.

Operational control: one incident record, regime-specific outputs.

Technology capability: classification engine; versioned report builder.

Evidence: submitted versions, timestamps. Status: applicable; ESAs instructions 16 Sep 2026.

Continuity and BCP

MiCA source: Art. 68(7); RTS 2025/299. DORA source: Arts. 11–12. Other regime: none.

Overlap type: DORA operationalises MiCA.

Operational control: single BCP; crypto scenarios (chain halt, key loss).

Technology capability: failover, signing-quorum recovery.

Evidence: test reports with RTO/RPO achieved. Status: applicable.

Custody and keys

MiCA source: Art. 75 (custody policy, liability). DORA source: Arts. 9 (protection), 11. Other regime: none.

Overlap type: MiCA-specific, DORA-supported.

Operational control: key ceremony, quorum change, recovery procedures.

Technology capability: HSM/MPC, policy engine, signing logs.

Evidence: ceremony minutes, recovery test, daily reconciliation. Status: CSA H2 2026–H1 2027.

Market surveillance

MiCA source: Art. 92; RTS 2025/885. DORA source: Art. 9 (data availability). Other regime: MAR not applicable to crypto-assets outside its scope.

Overlap type: MiCA-only.

Operational control: calibrated scenarios linked to order and on-chain data.

Technology capability: surveillance engine on the shared event store.

Evidence: calibration log, alert dispositions, STORs. Status: applicable.

Travel Rule and on-chain analytics

MiCA source: Art. 68 records. DORA source: Art. 28 (provider risk). Other regime: TFR Arts. 14–17; EBA/GL/2024/11.

Overlap type: analytics vendors are ICT third parties.

Operational control: exception workflow; counterparty due diligence.

Technology capability: Travel Rule gateway; analytics API.

Evidence: exception log, vendor in RoI. Status: applicable.

Governance

MiCA source: Art. 68(1)–(6). DORA source: Art. 5 (management body accountable). Other regime: none.

Overlap type: overlap.

Operational control: board-approved ICT risk framework and compliance plan.

Technology capability: dashboard for board KRIs.

Evidence: board minutes, training records. Status: applicable.

Unsettled point. Whether a public permissionless DLT network is an ICT third-party service under DORA Art. 3(21) has no official answer as of 1 October 2026. Treat contracted access layers as ICT third parties and the network as an ICT risk (Interpretation).

Supervisory allocation. Whether the MiCA NCA and the DORA competent authority are the same body differs by Member State. Where they differ, or where MiCA competence itself is split, a CASP faces two supervisors on overlapping topics (Section 5 and the country top-ups).

5. National divergence: what changes by Member State

The obligations in Section 2 are European; the authorities, channels and national add-ons that receive them are not. This master fixes the obligations; each country top-up fixes the recipients and national rules.

EU-wide picture. ESMA's register held roughly 359–362 CASP entries in late September 2026, led by Germany (95), France (36) and the Netherlands (29), per third-party trackers of the register (CASP Tracker); confirm against the ESMA CSV before citing (Market commentary).

MiCA competent authority model

What varies: MiCA Art. 93 lets each Member State designate one or more competent authorities. Some use a single authority; others split conduct and records from prudential, governance and safeguarding.

Why it matters: a split model doubles the supervisory audience for the same control and drives finding F11.

DORA competent authority and reporting channel

What varies: DORA Art. 46 assigns supervision to existing sectoral authorities. National portals, file formats and Register of Information submission windows differ; some states add a parallel notification to a national CSIRT.

Why it matters: incident clocks run from the same events, but the submission route and format are national.

AML/CFT supervisor and FIU

What varies: the AML supervisor for CASPs, the FIU, and national requirements beyond EU law (until AMLR applies from 10 Jul 2027).

Why it matters: Travel Rule and STR evidence is requested by a different authority from the MiCA NCA in many states.

Transitional history

What varies: Art. 143(3) periods ranged from none to 18 months; all ended by 1 Jul 2026 at the latest. Legacy VASP registers and client migrations differ by state.

Why it matters: migrated client files and legacy KYC are a recurring inspection target in the first post-transition year.

National implementing law, powers and sanctions

What varies: additional supervisory powers, criminal sanctions for unauthorised provision, accounting and audit requirements for CASPs.

Why it matters: the consequence of a finding differs materially between Member States.

Language, disclosure and financial promotion

What varies: language requirements for white papers, disclosures and marketing; national financial promotion and consumer rules.

Why it matters: host-state marketing is a frequent source of perimeter and conduct findings.

Enforcement practice

What varies: public warnings, non-compliant listings, inspection intensity and published sanctions.

Why it matters: sets the realistic supervisory posture in each state.

Country top-up structure

Every top-up follows the same eight sections so the 27 can be compared and maintained together:

1. Authorities map (MiCA NCA, DORA authority, AML supervisor, FIU, other).
2. Reporting channels: what goes where, in which format.
3. National implementing law and supervisory provisions.
4. Transitional history and authorised CASPs.
5. Divergence from this master.
6. Enforcement and supervisory signals.
7. Open questions to verify.
8. Sources and as-of date.

6. Practical solutions

The fix is architectural before it is procedural: one regulated data spine, one evidence register, and regime-specific outputs generated from both. Policies written without that spine reproduce the gap in F12.

6.1 Target operating model

1. Regulated data spine. Every client, order, trade, transfer, wallet event, key operation and incident is written once to an append-only, time-synchronised, hash-chained event store with stable identifiers (client ID, order ID, transfer ID, incident ID, LEI of each provider).
2. Regime outputs as views. Records extracts (RTS 2025/1140), order book files (RTS 2025/416), surveillance feeds (Art. 92), Travel Rule messages, AML monitoring inputs and DORA incident templates are generated from the same events, so numbers reconcile by construction.
3. Evidence register. Each control is recorded as Requirement → Control → Technical implementation → Policy → Owner → Evidence → Test frequency → Status → Residual risk. Status "Implemented" requires a dated test artefact, not a policy.
4. Exception workbenches. Travel Rule missing data, surveillance alerts and incident classification each get a queue with mandatory rationale, timers aligned to legal clocks, and escalation.
5. Supplier master. One inventory serving MiCA Art. 73 and DORA Arts. 28–30, validated monthly against EBA RoI rules, with DLT providers included.

6.2 Solutions mapped to findings

F1 Records

Solution: event-sourced spine; quarterly "inspector replay" of 10 random clients end to end.

Proof it works: replay completed within one business day; zero unexplained breaks.

F2 Surveillance

Solution: calibrate scenarios to own order flow; link on-chain deposits/withdrawals to order activity; documented alert disposition.

Proof it works: calibration report, below-the-line testing, STOR decision log.

F3 Travel Rule

Solution: multi-protocol gateway; risk-based missing-data playbook per EBA/GL/2024/11; one default self-hosted wallet ownership method.

Proof it works: exception ageing report; counterparty scorecards; escalations for repeat failures.

F4 Counterparties

Solution: weekly match of counterparty VASPs against ESMA register and non-compliant list; auto-flag lapsed entities.

Proof it works: match log; blocked or restricted counterparties with rationale.

F5–F6 Incidents

Solution: crypto incident taxonomy mapped to RTS 2024/1772 criteria; immutable incident ID; template pre-validation against ESAs instructions; one-month final-report timer.

Proof it works: tabletop with timed submissions; version history per incident.

F7 RoI

Solution: monthly validation against EBA rules, not annual scramble; LEI and code-list checks at supplier onboarding.

Proof it works: clean validation run; ESA acceptance.

F8 DLT dependencies

Solution: classify node/RPC/custody/analytics providers; contracts to Art. 30 standard; network-level risk and exit analysis.

Proof it works: updated RoI; exit test for primary RPC/node provider.

F9 Custody

Solution: witnessed key ceremonies; annual recovery test; daily on-chain vs ledger reconciliation.

Proof it works: ceremony minutes; recovery test report; reconciliation breaks log.

F10 Double regime

Solution: single supplier inventory with dual classification; check no core service outsourced to non-EU unauthorised group entity.

Proof it works: board-approved mapping; legal opinion on group arrangements.

F11 Multi-authority

Solution: authority-specific views from one incident and breach record; single narrative owner.

Proof it works: consistent filings across all receiving authorities.

F12 Policy gap

Solution: evidence register; owner attestation each quarter.

Proof it works: register with dated artefacts for every "Implemented" control.

6.3 Management action plan

Immediate (2 weeks) — Owner: Compliance + Head of Operations

Run inspector replay on 3 clients; refresh counterparty VASP list against ESMA register; check last 12 months of incident reports against ESAs instructions.

30 days — Owner: CRO / CISO

Evidence register for top 40 controls; crypto incident taxonomy; RoI validation run including DLT providers.

60 days — Owner: MLRO / Head of Trading / CTO

Travel Rule exception playbook live; surveillance calibration review; key-recovery test scheduled.

90 days — Owner: CTO + Management body

Event-sourced data spine for records and surveillance in production; CSA-style custody self-assessment signed by management body.

Long term — Owner: Management body

Prepare for possible ESMA direct supervision (MISP) and AMLR (10 Jul 2027): harmonised data dictionary, EU-level reporting readiness.

7. Self-diagnostic: 20 questions an inspector will ask

A CASP that cannot answer at least 16 with a document, log or system extract on the day should expect findings. Answers must be evidence, not descriptions.

Records and reporting

1. Produce the full lifecycle of client X's last 20 orders, from instruction to on-chain settlement, with timestamps. How long did it take?
2. Which fields of RTS 2025/1140 do you not capture today, and why?
3. Show the retention schedule and a deletion log proving records under 5 years were not removed.
4. (Trading platforms) Export one day of order book data in RTS 2025/416 format.

Market abuse

5. When were surveillance thresholds last calibrated, against what data, and who approved?
6. Show three closed alerts with the disposition rationale, and every STOR filed this year.
7. How do you link on-chain deposits and withdrawals to order-book behaviour?

Travel Rule and AML

8. How many transfers had missing or incomplete originator/beneficiary data last month, and what happened to each?
9. Which counterparty VASPs repeatedly fail to send data, and what action did you take?
10. Which counterparties lost their authorisation basis on 1 July 2026, and when did you stop or restrict transfers?
11. Show the self-hosted wallet ownership verification for three transfers above EUR 1,000.

DORA incidents

12. Show your incident register and the classification worksheet for your last three incidents, including those that were not major.
13. Which crypto events (chain halt, RPC outage, failed signing, exploit) are mapped to which RTS 2024/1772 criteria?
14. For your last major incident, show every report version with timestamps against the 4h/24h/72h/1-month clocks.

Third parties and custody

15. Show the RoI validation result and list every node, RPC, MPC/HSM and analytics provider in it.
16. Which functions are outsourced under MiCA Art. 73, and are any performed by a non-EU group entity?
17. Show the exit plan and last exit or failover test for your primary blockchain access provider.
18. Show minutes of the last key ceremony and the last full key-recovery test.
19. Show today's on-chain vs internal ledger reconciliation and the breaks log for the past month.

Governance

20. Show board minutes approving the ICT risk framework and the last ICT risk report the management body received.

8. Reporting systems built by us, run under your licence

Work with Blockwyse.

Blockwyse designs and delivers a comprehensive reporting system that produces the records, reports and evidence required by today’s regulatory frameworks. Your teams run it under your licence, in your name and with your controls. We build, we don’t operate or file on your behalf.

Technology, not legal advice. We translate regulatory requirements into data models, workflows and controls, then engineer them into production. Your compliance team and counsel confirm the regulatory interpretation, we ensure the system can evidence it.

Sources consulted (2 October 2026)

• ESMA statement on end of transitional periods, 17 Apr 2026
• ESMA public statement on wind-down, 23 Jun 2026
• ESMA CSA on CASP custody resilience, 8 Jul 2026
• ESMA digital innovation supervisory priority, 23 Sep 2026
• ESAs, DORA Incident Reporting – Operational Instructions, 16 Sep 2026 (project file)
• Commission MiCA review consultation, 20 May 2026
• ECB opinion on the market integration package
• ECON draft reports on MISP, 12 Jun 2026 (commentary)
• RTS 2025/1140 OJ publication note
• RTS 2025/416 and 2025/417 OJ publication note
• RoI 2026 validation commentary
• CASP register tracker

Legal notice

Educational and informational purposes only. This study is published by Blockwyse for general educational and informational purposes. It describes regulatory frameworks, supervisory developments and technology practices as understood at the date shown. It is not tailored to any person, firm or situation.

No legal, financial, tax or accounting advice. Nothing in this study constitutes legal advice, financial or investment advice, tax advice, accounting or audit advice, or any other professional advice. It must not be relied on as a substitute for advice from qualified professionals who know your specific circumstances.

What Blockwyse is. Blockwyse is a technology company that designs and builds software systems. Blockwyse is not a law firm, a tax adviser, an accountant or auditor, a financial or investment adviser, or a crypto-asset service provider. Reading this study does not create a lawyer–client, adviser–client or any other professional relationship.

Interpretations and accuracy. Statements are labelled by source type. Statements labelled "Interpretation", "Assumption" or "Open question" are Blockwyse's own reasoned views or unverified points, not statements of law. Laws, technical standards, guidance and supervisory practice change frequently and may be applied differently by competent authorities and courts in each Member State. Information is stated as of 1 October 2026 and may be incomplete, out of date or wrong. Third-party sources are cited for reference; Blockwyse does not verify or endorse them.

Your regulatory position remains yours. Each firm remains solely responsible for its own regulatory, legal, tax and accounting compliance, including all reporting and filing obligations. Any decision should be taken with your own compliance function and independent legal, tax and accounting advisers.

No offer of regulated services. Section 8 describes Blockwyse's technology services. Nothing in this study is an offer, solicitation or recommendation to buy, sell or hold any crypto-asset or financial instrument, or an offer of any regulated service.

Limitation of liability. To the fullest extent permitted by applicable law, Blockwyse accepts no liability for any loss or damage arising from the use of, or reliance on, this study or its contents.

References. References to ESMA, the EBA, the ESAs, the European Commission or any national authority do not imply their endorsement of this study or of Blockwyse.