> ## Documentation Index
> Fetch the complete documentation index at: https://docs.algovoi.co.uk/llms.txt
> Use this file to discover all available pages before exploring further.
# MiCA and DORA Record Keeping Evidence
> MiCA Article 68(9) and DORA logging evidence: self hosted, tamper evident, offline verifiable records under your own keys, with RFC 3161 timestamps.
**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
| Provision | What the text asks for | The artefact that produces the evidence |
| ------------------------- | -------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| MiCA Art. 68(9) | Records of all services, activities, orders and transactions, sufficient for supervision and enforcement | The [verifiable audit log](/audit-log) records any business event (a payment decision, an admin action, a config change, a compliance verdict) as a content addressed, Falcon-1024 signed entry linked to the one before it |
| MiCA Art. 68(9) | Kept five years, extendable to seven | [Records Vault](/records-vault) holds records write once with retention schedules, and a legal or e discovery hold overrides routine disposal so a record inside an extended window cannot be swept away |
| MiCA Art. 68(9) | Provided to clients on request | The [.epi evidence export](/epi-evidence-export) and the sealed `.acv` container hand a record set to a client, auditor or authority as one portable file they open and verify offline, with no AlgoVoi software on their side |
| MiCA Art. 68(8) | Availability, authenticity, integrity and confidentiality of data | Records are sealed at rest under ML-KEM-1024 while the evidence chain around them stays readable and verifiable from the published public key alone, as described in [post quantum evidence longevity](/post-quantum-evidence-longevity) |
| MiCA Art. 76(15) | Order data at the disposal of the competent authority for at least five years | The same write once preservation layer, plus a sealed container addressed to the authority so the handover is a single verifiable artefact rather than a database export |
| DORA Art. 17(2) | Record all ICT related incidents and significant cyber threats | Incidents append to the same signed chain as everything else, so an entry cannot be altered, inserted, removed, reordered or back dated after the fact |
| CDR 2024/1774 Art. 12 | Protect log information against tampering, deletion and unauthorised access | Each entry is hash linked and Falcon-1024 signed, so any alteration breaks verification at exactly that entry and is detectable by anyone holding the public key |
| CDR 2024/1774 Art. 12 | A documented reliable reference time source | RFC 3161 trusted timestamps bind each record's hash to an independent authority's clock, and an air gapped deployment falls back to a signed record with no external call ([Records Vault](/records-vault)) |
| CDR 2024/1774 Art. 12 | A stated retention period per class of event | The [Retention App](/retention-app) maintains a strictly append only chain per issuer, derives the sequence position from the chain head rather than the caller, and exports the chain as a signed evidence pack |
| DORA Art. 9(4)(e) | All changes to ICT systems recorded in a controlled manner | Config and administrative changes are appendable events on the same chain, and the console writes its own operator actions to a signed audit chain |
| DORA Art. 10(1) and 10(3) | Detection, and monitoring of user activity and ICT anomalies | Optional live forwarding of the signed chain to your SIEM (RFC 5424 syslog, CEF or webhook), each record carrying the entry sequence and SHA-256 so it ties back to the chain. The evidence estate sits alongside your monitoring, it does not replace it |
## 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](/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.
```bash theme={null}
pip install pqcrypto rfc8785
python verify_evidence_pack.py
```
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](/conformance-vectors).
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](/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](/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](/bring-your-own-keys), and the signed output is unchanged
either way, so verification stays identical.
See the [Compliance Suite deployment guide](/vcs-deployment-guide) for the full
walk through.
## See also
* [Verifiable Compliance Suite](/verifiable-compliance-suite), the estate this page maps onto.
* [Retention App](/retention-app), per issuer append only retention chains with signed, offline verifiable evidence packs.
* [Verifiable audit log](/audit-log), the tamper evident event chain.
* [Records Vault](/records-vault), RFC 3161 timestamping, read access logging and legal holds.
* [EU AI Act record keeping](/eu-ai-act-recordkeeping), the same evidence estate mapped to Articles 12, 19 and 26.
* [MiCA, Regulation (EU) 2023/1114](https://eur-lex.europa.eu/eli/reg/2023/1114/oj/eng) and [DORA, Regulation (EU) 2022/2554](https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng), the primary texts.
* [Commission Delegated Regulation (EU) 2024/1774](https://eur-lex.europa.eu/eli/reg_del/2024/1774/oj/eng), the DORA ICT risk management technical standards containing the logging article.
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.