Regulation (EU) 2022/2554
What DORA requires in terms of logging in the financial sector, and what Logsiegel contributes
Since January 2025, financial entities in the EU have had to demonstrate their digital operational resilience under DORA. Anyone running an AI agent there, in house or through a provider, has to be able to show afterwards what the agent did, and that the trail about it is unaltered.
Who this applies to
Banks, insurers, payment and e-money institutions, investment firms, crypto-asset service providers, trading venues and the other financial entities listed in Art. 2. Through Art. 28 ff. indirectly also their ICT third-party service providers, that is, every provider whose AI service runs inside a financial entity and who owes that client auditability.
What the regulation requires in terms of records
DORA itself states the duties in general terms; the detail on logging sits in the regulatory technical standards (RTS) on the ICT risk management framework:
| Reference | Requirement |
|---|---|
| Art. 9 | Protection and prevention: financial entities continuously monitor and control ICT systems and use tools that safeguard the integrity of data and systems. |
| Art. 10 | Detection: mechanisms to promptly detect anomalous activities, including ICT network performance issues and ICT-related incidents. |
| Art. 17(3) | Incident management: processes to identify, track, log, categorize and classify ICT-related incidents; root cause analysis and documentation. |
| RTS, Del. Reg. (EU) 2024/1774, Art. 12 | Logging: financial entities define which events are to be logged, how long logs are retained, and how log data is protected against unauthorized access and alteration. |
| Art. 28 to 30 | ICT third-party risk: contracts with ICT providers must, among other things, provide for access, inspection and audit rights of the financial entity and the supervisor; the provider must be able to supply the evidence. |
| Art. 19 | Reporting of major ICT-related incidents to the supervisor with an initial notification, intermediate report and final report. Those reports need solid facts about what happened in the system. |
What Logsiegel contributes today
- Unaltered records, verifiable. Every entry is hash-linked to the one before it; at intervals a Merkle root is formed and signed with Ed25519 (a checkpoint). Any later edit, reorder or truncation makes
logsiegel verifyfail. That is the protection of log data against alteration required by Art. 12 of the RTS, in a form an auditor can recompute personally. - Incident reconstruction. After an incident, the trail shows which requests the agent handled at what time with which model, and where errors (
anomaly) occurred. The final report under Art. 19 rests on records whose integrity can be shown. - Receipts for clients and supervisors.
logsiegel receiptbuilds a file for one single action, made of the entry, an inclusion proof and a signed checkpoint. An auditor, customer or court verifies it offline against your published key, without access to your systems and without seeing the rest of the trail. An ICT provider can meet audit rights under Art. 30 this way, without giving the client access to its systems or a view into other tenants. - Retention you can prove. A signed checkpoint shows that at a given moment the trail had a certain length and a certain content. Anyone who truncates it later stands out against every checkpoint or receipt handed out earlier.
- A readable dossier.
logsiegel exportwrites the trail as a Markdown dossier for people who do not want to touch a command line. - Metadata only in the trail. What enters the chain is event metadata and salted hashes; inputs and outputs are kept separately, encrypted per entry. The content of an entry can be deleted by deleting its key (crypto-shredding), without breaking the chain. Even in receipts handed to a supervisor, customer data stays out.
What is in progress planned
- Independent witness that counter-signs checkpoints. For financial entities, the stage at which not even the provider itself can keep a second trail.
- Qualified timestamps under eIDAS for checkpoints, so that times are no longer just a claim by the operator.
- MCP proxy for tool calls by agents (payments, bookings, queries) at the interface.
What Logsiegel does not do
- Real-time detection. Logsiegel is not a SIEM and not a monitoring system; it makes records provable, it does not raise alerts. You meet Art. 10 with your detection systems, and Logsiegel gives them unaltered facts.
- Reporting and incident workflow. Classification, deadlines and reports under Art. 17 to 19 remain your process.
- Resilience testing (Art. 24 ff.) and the register of third-party contracts (Art. 28(3)) are duties of their own.
- Completeness. What is proven is that the recorded material is unaltered, never that everything was recorded. That is an integration question: the adapter has to sit at a point every action must pass (LiteLLM today, MCP proxy in progress).
- Protection against the operator itself. Whoever holds the signing key could rewrite the trail and sign it again. That comes to light precisely when somebody else holds an earlier checkpoint or receipt. So hand your checkpoints out; counter-signing by an independent witness is the next stage of the project.
- Time. Timestamps in the trail are a claim by the operator until they are counter-signed by a witness or by a qualified timestamping service.
- Legal assessment. Whether your system falls under the regulation, which duties apply in detail and whether a receipt is enough in a given case is decided by your legal or compliance review, not by this tool.
How to put it to work
1. Install it and create a trail
The SDK is Python, Apache 2.0, no server and no account. The origin (origin) names the system whose actions are being recorded.
pip install logsiegel
logsiegel init ./trail --origin "acme.example/support-agent"2. Plug the adapter in at the point every action must pass
If your AI traffic runs through LiteLLM, every completion becomes a signable inference entry, and errors are recorded as an anomaly. Human interventions you record explicitly, as an event of their own.
import litellm
from logsiegel.integrations.litellm_logger import LogsiegelLogger
litellm.callbacks = [LogsiegelLogger("/var/lib/logsiegel/prod", store_payload=True)]3. Create checkpoints and hand them out
Create checkpoints regularly (via cron, for instance) and put them outside your own infrastructure: with the auditor, with the customer, in someone else's repository. Only a checkpoint you no longer control alone makes the trail hold up against yourself.
logsiegel checkpoint ./trail
logsiegel verify ./trail4. Hand checkpoints to the client on a regular basis
As an ICT provider you send the financial entity the signed checkpoints, daily for instance. That lets the client check at any time that your trail has only grown since then (consistency proof), without seeing the content.
5. Hand out the receipt when someone asks
Instead of database extracts you hand out a single receipt. The other side verifies it in the browser at logsiegel.com/verifier or on the command line, both offline.
logsiegel receipt ./trail --seq 1284 --out receipt.json
logsiegel verify-receipt receipt.json --pubkey logsiegel.pubMore regulations: EU AI Act GDPR NIS2 / critical infrastructure ISO/IEC 27001 ISO/IEC 42001 GoBD eIDAS Overview
Legal status September 2026. This page is a technical assessment by the project, not legal advice and not a conformity statement. Please check the references against the current text of the law. Corrections welcome via GitHub issue.