Skip to main content
AlgoVoi provides MiCA and DORA record-keeping evidence: a self-hosted, tamper-evident, offline-verifiable log estate that satisfies MiCA Article 68(9) record-keeping for crypto-asset service providers and DORA ICT-incident and audit logging, under your own keys, with RFC-3161 timestamps and post-quantum signatures that keep the records verifiable across a seven-year retention window. Last updated: 3 August 2026.
Both regulations are already in application. MiCA (Regulation (EU) 2023/1114) has applied to crypto asset service providers since 30 December 2024, and DORA (Regulation (EU) 2022/2554) has applied since 17 January 2025. The record keeping window MiCA opens is five years, extendable to seven at a competent authority’s request, so records written today are still supervisory material in 2032.

​
What MiCA and DORA actually ask you to keep

Four provisions carry most of the weight for an evidence layer.
  • MiCA Article 68(9) (records of services, activities, orders and transactions): a crypto asset service provider must arrange for records to be kept of all crypto asset services, activities, orders and transactions it undertakes. Those records must be sufficient to let competent authorities fulfil their supervisory tasks and take enforcement measures, must be provided to clients on request, and must be kept for five years, extendable to up to seven where the competent authority asks before the five years elapse.
  • MiCA Article 68(8) (data safeguards, routed through DORA): the same article requires systems and procedures to safeguard the availability, authenticity, integrity and confidentiality of data, and it points directly at DORA for the standard. Record keeping and integrity are not two separate programmes in MiCA. They are the same paragraph pair.
  • DORA Article 17(2) (incident records): financial entities shall record all ICT related incidents and significant cyber threats, inside an incident management process that identifies, documents and addresses root causes.
  • DORA logging RTS, Commission Delegated Regulation (EU) 2024/1774 Article 12: logging procedures must identify the events to be logged, set a retention period, protect logging systems and log information against tampering, deletion and unauthorised access at rest, in transit and where relevant in use, synchronise clocks on a documented reliable reference time source, and detect a failure of the logging system itself.
Two more provisions matter if you hold or match client assets. MiCA Article 75(2) requires a custodian to keep a register of positions opened in each client’s name, and MiCA Article 76(15) requires a trading platform operator to keep order data at the disposal of the competent authority for at least five years.

​
The obligation nobody writes down

Read Article 68(9) and Article 12 of the logging RTS together and a requirement appears that neither states on its own: the records have to still be believable in year seven. A record store that the operator can write to is a record store the operator can rewrite. When a competent authority reads your 2026 order records in 2032, the question is not whether the rows exist. It is why anyone should accept that they are what your systems produced at the time, given that your own administrators held write access for six years. The logging RTS is explicit that log information must be protected against tampering and deletion, and it asks for a documented reliable reference time source rather than your own server clock, because a server clock is your assertion about when something happened. Ordinary application logging, database audit tables and log shipping to a managed service do not answer that. Each of them produces records whose integrity rests on trusting whoever operated the system. Cryptographic evidence answers it without asking anyone to trust you.

​
Why the records should stay under your own keys

MiCA Article 68(9) makes the records yours to produce, to hold for five to seven years, and to hand to a client or an authority on request. A third party service that generates and stores those records in its own infrastructure puts a commercial dependency inside a statutory retention window: terms change, vendors are acquired, and a service can retire a data format long before year seven. DORA then adds its own pressure from the other direction, because a logging service is itself an ICT third party arrangement you have to justify. Running the evidence layer inside your own perimeter removes the question. The records are produced where the activity happens, retained under your own policy, and signed under keys you hold. Nothing is generated in someone else’s account and nothing phones home.

​
Mapping each obligation to an artefact

​
Why the signature scheme matters over a seven year window

MiCA’s retention window runs to seven years, and a supervisory or civil dispute can reach back across the whole of it. Records signed today under RSA or ECDSA inherit whatever happens to those schemes in the meantime. The estate signs under Falcon-1024 and ML-DSA-65 from the point of writing, and seals record content under ML-KEM-1024, so a record written in 2026 is still verifiable arithmetic in 2032 with no re signing exercise. Key rotation is itself part of the evidence: the outgoing key authorises its successor and the successor counter signs the rotation entry, so a holder of only the originally published key can walk the chain forward. See post quantum evidence longevity for the full treatment.

​
An authority can check it without calling us

The point of an evidence artefact is that the recipient does not have to take your word for it, or ours. Every deployment emits a self contained evidence pack: the signed chains, the public key, and a standalone verifier. The verifier’s whole trust base is two public libraries, pqcrypto for Falcon-1024 verification and rfc8785 for RFC 8785 (JCS) canonicalisation. No AlgoVoi code participates in the check, no service is called, and no network is required.
The canonical bytes a signature covers reproduce byte identically across eight independent RFC 8785 implementations (Python, Node.js, Ruby, PHP, Go, Rust, Java and .NET), so the exact preimage is reconstructible in your own stack. See the open conformance corpus. Encrypted record content is included in the pack but stays unreadable, because its ML-KEM key is never in the pack. A recipient confirms when a record existed, that its chain is unbroken, and who read it, without being handed the contents.

​
What this is not

Honest scoping, because MiCA and DORA are both far wider than an evidence layer.
  • It is not compliance. The estate produces tamper evident records that support your obligations. It does not make anyone compliant, and it is not a substitute for authorisation, for your ICT risk management framework, or for advice from your counsel.
  • It is not your DORA register of information. DORA Article 28(3) requires a maintained register of contractual arrangements with ICT third party service providers. That is a contracts and vendor management artefact. The estate does not build or hold it.
  • It is not your MiCA register of positions. Article 75(2) puts the custody register in your books. The estate makes the movement history around it tamper evident, it does not keep the register.
  • It is not incident reporting. DORA Article 19 reporting timelines and templates are a process obligation. The estate gives that process a record it can prove, nothing more.
  • It is not an AML or travel rule programme. Obligations under other instruments have their own scope; Sanctions Monitor and the Travel Rule module ship in the same bundle but are separate products with separate claims.
  • Tamper evident, not hard WORM, except where you enable S3 Object Lock in compliance mode, in which case we say so.

​
Getting the evidence layer in place

The Verifiable Compliance Suite ships every component above today as a self hosted, air gap capable estate, on one perpetual licence. A deployment scoped only to MiCA and DORA record keeping is small: the audit chain, the Retention App on your payment and order events, and Records Vault where the five to seven year window applies. Keys can stay in your own HSM, AWS KMS, HashiCorp Vault or PKCS#11 module under bring your own keys, and the signed output is unchanged either way, so verification stays identical. See the Compliance Suite deployment guide for the full walk through.

​
Frequently asked questions

​
What records must a crypto-asset service provider keep under MiCA?

MiCA Article 68(9) requires a crypto-asset service provider to keep records of all its crypto-asset services, activities, orders and transactions, in a form that lets the competent authority reconstruct each transaction and check compliance. In practice that means a complete, ordered, tamper-evident history of the events, not just the current state of a database.

​
How long must MiCA and DORA records be retained?

MiCA record-keeping runs to a five to seven year window depending on the record and the competent authority’s direction. DORA requires ICT-related incident records and the underlying logs to be retained and protected against tampering and deletion for as long as they are needed for supervisory and post-incident purposes. AlgoVoi holds each record write-once under an enforced retention schedule, with legal holds that override routine disposal.

​
What does DORA require for logging and record-keeping?

DORA Article 17(2), with the technical standard in Commission Delegated Regulation (EU) 2024/1774 Article 12, requires financial entities to log ICT-related events, protect that log information against tampering and deletion, and bind it to a reliable time source. AlgoVoi meets this with a hash-chained, post-quantum-signed audit log and RFC 3161 timestamps, so an entry cannot be altered, inserted, removed or back-dated without breaking verification at that exact point.

​
Can MiCA and DORA records stay under our own keys and infrastructure?

Yes. The evidence estate is self-hosted and air-gap capable, so records are produced where the activity happens and retained under your own policy. Keys can stay in your own HSM, AWS KMS, HashiCorp Vault or a PKCS#11 module, and the signed output verifies identically either way, offline, with no AlgoVoi account or network call in the verification path.

​
See also

This page is technical documentation, not legal advice. Obligations vary by entity type, by the crypto asset services you are authorised for, and by your DORA classification; confirm your position with counsel.