What are MiCA Article 68(9) record-keeping requirements and how do I meet them?

MiCA Article 68(9) requires a crypto-asset service provider operating a trading platform to keep records of its services, activities, orders and transactions, sufficient for competent authorities to supervise and enforce, and to retain them for five years (extendable to seven at an authority's request). You meet it with records that are complete, retained for that window, and provably unaltered. AlgoVoi's self-hosted Verifiable Audit Log and Verifiable Compliance Suite give you tamper-evident, post-quantum records you can verify offline.

Last updated 21 August 2026

What the Article asks for

MiCA (Regulation (EU) 2023/1114) has applied to crypto-asset service providers since 30 December 2024. Article 68 governs operating a trading platform for crypto-assets, and paragraph 9 sets the record-keeping duty: the provider must keep records of all crypto-asset services, activities, orders and transactions, sufficient for competent authorities to fulfil their supervisory tasks and take enforcement measures, provide them to clients on request, and retain them for five years, extendable to seven where the authority asks before the five years elapse. Records written today are still supervisory material in 2032.

Article 68(8) sits in the same pair: it requires systems and procedures that safeguard the availability, authenticity, integrity and confidentiality of that data, and points to DORA for the standard. Record-keeping and integrity are one programme, not two. To be useful to an authority the records must be complete, time-ordered, retained for the window, and provably unaltered: a log a provider can quietly edit does not support supervision.

What a supervisable record needs

• Completeness: every order and transaction event captured automatically.
• Independent time order: entries anchored so sequence and timing cannot be back-dated.
• Tamper-evidence: any edit, deletion, or reordering is detectable by the authority, not just attested by the operator.
• Retention and export: kept for the required period and producible in a form the authority can verify.

How to meet it with AlgoVoi

Record each service, order and transaction event in the self-hosted Verifiable Audit Log as a Falcon-1024-signed, hash-chained entry, timestamped and retained under enforced policy across the five-to-seven-year window. It ships inside the Verifiable Compliance Suite, runs on your own infrastructure under your own keys, and everything is verifiable offline. For the full regulatory mapping (including MiCA Article 68(8) routed through DORA), see the docs: MiCA and DORA evidence.

Verify it, the way an auditor would

The whole point is that someone else can check the record. Verification runs offline against the exported receipts and the log's public key, with no call back to AlgoVoi and no trust in whoever holds the log:

from algovoi_audit_log import verify_chain

# `receipts` are the exported, signed log entries; `public_key`
# is the log's Falcon-1024 public key. No network, no vendor.
result = verify_chain(receipts, public_key)
assert result.valid   # fails the moment any entry is altered,
                      # inserted, removed, reordered, or back-dated

A competent authority can run the same check against the same exported receipts and reach the same verdict. That reproducibility is what turns "we kept logs" into evidence.

Do it with AlgoVoi

The self-hosted Verifiable Audit Log produces the tamper-evident record. It ships standalone and inside the Verifiable Compliance Suite, runs entirely on your own infrastructure, and is air-gap capable (no PyPI). Anyone you hand an exported record to can verify it offline, no licence and no AlgoVoi account needed.

• Get the log: Suite Store (Verifiable Audit Log, or the full Compliance Suite)
• Related answer: DORA ICT incident log retention
• Related answer: EU AI Act Article 12 record-keeping
• Product: Regulatory evidence · Evidence Auditor

Start with the docs: docs.algovoi.co.uk/audit-log