Produce DORA evidence from your ledger
Clone the Formance Ledger on GitHub, run it locally, and post your first transaction. See how immutable postings, bi-temporal timestamps, and per-rail account paths produce the DORA evidence your compliance team needs.
The Digital Operational Resilience Act (DORA) sets the incident reporting, resilience testing, and third-party risk rules that payment institutions, credit institutions, and other EU-facing regulated entities must meet. The obligations fall on the infrastructure teams running card authorization and settlement finality.
The Barclays outage of 31 January to 2 February 2025 shows what a DORA-scale incident looks like on the ground. An outage broke online payments over three days, and the Treasury Committee wrote to nine banks and building societies asking for outage data. The on-call engineer had to produce affected account counts, payment values, and per-rail failure breakdowns from live systems.
After an outage like that, DORA requires a final report showing what caused the outage, which accounts were affected, and whose money moved in your omnibus account. You can't answer those questions from policy documents. You need the transaction record to support compliance.
This guide covers what infrastructure finance teams need to become DORA compliant.
The DORA Regulation (EU) 2022/2554 sets out five pillars of evidence, and each pillar requires your infrastructure to produce evidence on request. The pillars differ in scope, but each one comes down to output from a running infrastructure.
DORA's ICT (Information and Communication Technology) risk management pillar requires a written framework covering access, change management, and business continuity, plus an inventory of the systems supporting your critical functions.
You classify incidents, file reports on fixed deadlines with your competent authority, and defend the impact figures in the final report.
Every system supporting a critical function has to be tested for resilience yearly, with records to prove the tests were conducted.
Every ICT provider you depend on, from your cloud host to your KYC vendor, has to sit in a register you can hand to your competent authority. You must keep a live record of each contractual arrangement and file the yearly report.
DORA encourages regulated entities to share cyber-threat intelligence with each other so the sector spots attack patterns faster. Participation is voluntary, but once you're in, you must notify your regulator when you join or leave.
Across the first four pillars, systems must produce trustworthy records of what happened, when, and to whose money. Only 8% of respondents to a survey of EU financial entities report full compliance in each category, so most teams cannot produce all the required evidence.
For most regulated entities, the same ledger reconciliation work that proves customer funds are intact also produces an incident report.
DORA incident reporting runs on three deadlines under the joint technical standards. An initial notification is due within 4 hours of classifying an incident as major, and no later than 24 hours from detection. An intermediate report is due within 72 hours of the initial notification, and a final report is due no later than one month after the latest intermediate report.
The EU financial sector reported 3,383 major incidents in 2025, and the reporting clock starts once you classify the incident as major. DORA defines seven categories that make an incident "major" (critical services affected, clients affected, downtime on functions, data losses, economic impact, geographic spread, and reputational impact) but doesn't set the thresholds or metrics.
Map each DORA classification category to a metric your systems emit:
The intermediate and final reports need real impact figures, so you need funds traceability good enough to replay the incident window after the fact. A core ledger such as Formance Ledger produces those figures straight from its own postings, so on-call engineers get the numbers a classification decision needs.
A core ledger supports DORA compliance through three evidence properties: immutability, double-entry, and concurrency safety. They answer the question every DORA incident report must answer: "whose money moved, when, and by how much" from its own record.
Double-entry means every movement of value names a source and a destination, so nothing appears or vanishes without a counterparty.
Double-entry supports DORA compliance by giving an auditor a traceable path. They can follow any balance back through named accounts and see exactly which counterparties were affected during an incident window.
Ledger immutability means postings cannot be altered or deleted once written. Corrections during an incident are recorded as new postings while the earlier state stays visible.
For DORA, that means the final report can show both the original state and the fix without rewriting history, which is what the regulator expects when reconstructing an incident.
Concurrency safety keeps simultaneous postings accurate per asset during high-volume windows, backed by idempotency that prevents duplicate postings on retry.
Concurrency and idempotency matter because retries and parallel writes are common during degraded windows. Without it, your incident-window posting counts and balances are unreliable, and you can't defend the impact figures in the final DORA report.
A transactional language records every money movement in a consistent, machine-readable shape, so the ledger can replay any incident window and show the regulator exactly which postings moved which funds.
Numscript is Formance's purpose-built language for describing financial transactions. It names the source account, destination account, asset, and amount in a single posting, and attaches metadata for event type and transfer ID.
For DORA, that means every posting carries the fields an examiner needs to reconstruct an incident: what moved, from where, to where, and why.
The transaction below moves an inbound €2.4 million TARGET2 settlement from the inbound account (@rail:sepa:target2:inbound) to the main EUR settlement treasury account (@treasury:settlement:eur:main).
Actual movement of funds still depends on a connected bank or payment provider:
// SETTLEMENT_RECLASSIFICATION
// Event: reclassify an inbound EUR 2.4 million TARGET2 settlement to treasury
send [EUR/2 240000000] (
source = @rail:sepa:target2:inbound allowing unbounded overdraft
destination = @treasury:settlement:eur:main
)
set_tx_meta("event_type", "settlement_reclassification")
set_tx_meta("transfer_id", "stl001")
Naming the rail in the source path (@rail:sepa:target2:inbound) keeps the rail identifier inside the posting. When an incident hits one payment rail, you filter postings by the rail prefix and replay the window for that rail alone.
Yearly testing under Article 24(6), threat-led penetration testing for entities scoped in by their competent authority, targeted testing of IT change (where most major incidents originate), and drill records are the four testing implementations you need to evidence resilience and recovery objectives under DORA.
Article 24(6) requires yearly testing of all ICT systems and applications supporting critical or important functions. Each test record needs a timestamped run, a defined scope, and a pass/fail result linked to the system being tested.
Threat-led penetration testing (TLPT) sits above the yearly baseline and applies only to entities named by their competent authority under Articles 26–27. Article 3(17) defines TLPT as an intelligence-led red-team test of critical live production systems that mimics real attackers.
The authority sets the frequency, with a floor of at least every three years and risk-based adjustments above the floor. If no authority has put you in TLPT scope, your job is the yearly Article 24(6) testing.
Resilience testing should target IT change because 38% of major incidents reported by banks in 2025 had IT change as the root cause.
On 19 July 2024, a faulty CrowdStrike Falcon sensor update crashed millions of Windows systems worldwide. Flights were grounded and hospitals disrupted.
The testing DORA asks you to evidence catches change-management regressions before release, which is exactly the failure class the CrowdStrike update was.
A failover drill proves your recovery time objective only if you can show when the drill started, when you cut over to the backup, and when the first transaction landed on it. The ledger timestamps the drill start, the cutover, and the first posting on the secondary.
The gap from drill start to service restoration is your measured recovery time, and it either sits inside your stated target or it doesn't. The interval between the last transaction on the primary and the first on the secondary shows how long the service was actually down.
Managing the Register of Information means treating the register as production data, which means including assigned owners, checked fields on write, and modeling the register as your incident-response dependency graph.
Article 28(3) requires the register to cover every contractual arrangement with ICT third-party service providers, held at entity, sub-consolidated, and consolidated levels. The register must be available to your competent authority on request. You must report new ICT third-party arrangements at least yearly using standardized templates set by Implementing Regulation (EU).
In the supervisory dry run, roughly 1,000 entities submitted registers and only 6.5% passed all 116 data quality checks. Identification codes and subcontracting chains fail most often, along with each service's function records. Assign owners to Register of Information fields and fail an incorrect identification code at write time, before the record hits the register.
On 18 November 2025, the European Supervisory Authorities named providers as critical ICT third-party providers under direct European oversight, including AWS, Microsoft, and Google Cloud. Model the register as the dependency graph your incident response will query when the failing component belongs to a provider.
Formance is DORA-compliant on the vendor side, along with SOC 2 Type II and ISO 27001 certifications, which simplifies the documentation your Register of Information needs to include for the ledger entry.
Your checklist must include five artifacts to meet DORA compliance. Run them against your financial infrastructure to see where you need to improve your systems:
DORA compliance comes down to whether your infrastructure can produce the evidence on request, which comes down to the core ledger. Formance Ledger is open source, built on double-entry accounting, and gives you the immutability, bi-temporality, and per-rail replay the five checklist items depend on.