Compliance mapping
DORA and AI agents: the audit trail an examiner asks for
For platform and security leads at EU financial entities running AI agents that touch payments or operations. DORA (Regulation (EU) 2022/2554) has applied since 17 January 2025. This page maps three DORA expectations (ICT risk management, traceability and logging of critical operations, incident evidence) to concrete artifacts Cosignet produces, and it is candid about what using Cosignet changes in your third-party register.
Scope. Cosignet provides verifiable approval evidence only; it does not determine legal applicability, certify compliance, replace regulated controls, or substitute for legal, compliance, or audit advice.
Framing, stated plainly: Cosignet is not a "DORA certified" product (no such certification exists for a component like this). Cosignet provides verifiable evidence in support of your own compliance program, and does not by itself satisfy any DORA obligation. Your obligations remain yours.
What DORA asks of you
DORA is directly applicable EU law, no national transposition needed. The parts that bear on an AI agent taking a consequential action:
- ICT risk management (Chapter II). Identify, protect, and control the ICT systems that support critical or important functions, including the tools that let software initiate high-impact actions.
- Traceability and logging of critical operations. Maintain records that let you reconstruct who or what authorized a critical operation, and when, in a way that resists after-the-fact alteration.
- ICT-related incident management and reporting (Chapter III). When something goes wrong, produce evidence of what was authorized and by whom, quickly and credibly.
- ICT third-party risk (Chapter V) and the register of information. Track the third-party ICT providers supporting important functions. This one cuts both ways for Cosignet, see the candid section below.
Primary source: Regulation (EU) 2022/2554 on EUR-Lex. Confirm the specific articles that apply to your entity type with your own counsel.
What an auditor or examiner actually requests
In an ICT traceability or incident review, the recurring questions are concrete:
- "Show me that a human authorized this specific transfer, on this date, at this amount, to this payee."
- "Prove the record has not been edited since it was created."
- "Can you demonstrate that without asking me to trust your database or your word?"
- "Reconstruct the authorization trail for the incident window."
What Cosignet provides, per requirement
| DORA expectation | What the auditor requests | Cosignet artifact |
|---|---|---|
| Authorization control over critical operations | Evidence a human approved the exact action before it ran | A WebAuthn (passkey) signature over nonce ‖ SHA-256(payload), so the signed decision is bound to the exact action. Changing any field invalidates the signature. |
| Traceability and tamper-evident logging | Proof the record was not altered after the fact | Each approval is a leaf in an append-only Merkle transparency log (RFC 6962 style) with an Ed25519-signed tree head, anchored into Bitcoin via OpenTimestamps. An inclusion proof shows the record is committed under a published root. |
| Incident evidence, produced credibly | Reconstruct the authorization trail, independently checkable | An exportable evidence pack (JSON decision record, signature, inclusion proof, OTS proof, open-source verifier, README) that verifies offline, without a Cosignet account. |
| Independence from the vendor | Verification that does not rely on trusting Cosignet | Open-source Node and Python verifiers check the full chain; the tree-head public key is published at /public/log/key and Bitcoin anchoring is trust-minimized. |
One worked example (hypothetical)
The following scenario is illustrative and hypothetical. It is not a customer case study and does not describe a real transaction. An operations agent proposes a EUR 250,000 vendor payment. Before the transfer executes, Cosignet requires a named human to approve the exact payload (amount, payee, reference) with a passkey. The approval is recorded as a signed, tamper-evident log entry. Nine months later, an examiner asks you to prove that authorization. You export the evidence pack and the examiner verifies it on an air-gapped laptop. The verifier confirms the signature is bound to that exact payload and that the record is included under a published, Bitcoin-anchored root. Here is the shape of the verification bundle behind that pack (credential, assertion, and full proof array elided for brevity):
{
"entry": {
"id": "0fac28e5-b8ca-4766-ba5f-36e074076f98",
"confirmation_id": "…",
"payload_hash": "sha256:…",
"credential_id": "…",
"signed_at": "2026-06-23T…Z",
"leaf_hash": "…",
"leaf_index": 4
},
"proof": [ "…", "…", "…", "…" ],
"sth": {
"root": "…",
"tree_size": 10,
"timestamp": "…",
"signature": "…",
"alg": "Ed25519"
},
"ots": { "status": "bitcoin", "proof": "…" },
"sth_public_key": "hwP8lFDpS2MpbZ-M5-jciuUqQ-vKK9yRqm3gEQa4Elg"
}
This is a real, live bundle shape. The linked entry is a genuine approval of a different action, shown here to demonstrate the format, not the EUR 250,000 payment in the story above. See the full record and verify it yourself at /verify, or read the step-by-step walkthrough on the for auditors page.
Candid: Cosignet becomes an ICT third-party provider in your register
This objection comes up in every DORA conversation, so we raise it first. If you use Cosignet to support a critical or important function, Cosignet is an ICT third-party service provider that belongs in your register of information, with the usual due diligence, concentration-risk, and exit considerations. We do not pretend otherwise. What we can do is make that assessment easy:
- Exit path and data export. Your evidence packs are self-contained and verify without us. If you leave Cosignet, the proofs you already exported keep working, they do not depend on our servers staying up.
- Failure modes are documented and fail-closed. No signature means no approval, so an outage blocks the action rather than waving it through. Read Availability and failure modes.
- Sub-processors and data handling are disclosed on the security page and privacy policy.
Confirm the exact DORA article references for your entity type and the register-of-information fields with your own counsel before relying on them.
Related reading
- PSD2 dynamic linking and agent payments: the SCA construction, generalized.
- Agent-initiated payments and treasury operations.
- Agent deployment approval workflow.
- All compliance mappings.
Put auditor-reviewable evidence in front of your riskiest agent actions
Free to start, no credit card. Founding customers get direct founder access.
Informational, not legal advice. This page explains how Cosignet evidence artifacts can support your DORA compliance program. It is not a legal opinion, and Cosignet is not a certified DORA solution or a substitute for your own controls, counsel, or auditor. Verify all regulatory references against the primary sources linked above.