DORA for Infrastructure Providers: What It Actually Requires
DORA is not a compliance checkbox. It is a systems specification with architectural implications for determinism, traceability, and resilience.
DORA for Financial Infrastructure Providers: What You Actually Need to Build
Compliance teams write policies. Engineering teams build systems. In most fintechs, the two produce separate documents, present to separate audiences, and rarely reconcile. DORA forces the reconciliation.
The Digital Operational Resilience Act (Regulation 2022/2554) has been in force since January 17, 2025. It applies to financial entities across the EU, banks, payment institutions, e-money institutions, investment firms. But it also reaches their technology providers. Article 15 establishes oversight requirements for "critical ICT third-party service providers." If you build infrastructure that regulated entities depend on, you are in scope. Not as a nice-to-have. As a regulatory expectation your clients must enforce.
Most fintechs read DORA as a policy exercise: update the risk register, add a section to the SOC 2 narrative, train the team. That misses the point. DORA is a systems specification. It defines architectural properties that your technology must exhibit. Policies describe intent. Architecture delivers capability.
Five Architectural Requirements Most Fintechs Miss
DORA spans 64 articles across 9 chapters. Not all of them have architectural implications. Five do.
1. Deterministic Systems (Art. 5-6: ICT Risk Management)
DORA requires financial entities to "identify, classify, and adequately document all ICT-supported business functions" and maintain systems that are "reliable and resilient." In engineering terms: your system must behave predictably under all conditions, including failure.
What this means for architecture:
- No garbage collection pauses during settlement windows. A GC stop-the-world event during a payment batch is a non-deterministic failure that DORA's risk framework requires you to assess and mitigate.
- Auditable code paths. An external auditor must be able to trace a specific transaction from API ingestion to ledger commitment. If the path depends on runtime conditions that are not logged, the system is not adequately documented.
- Static resource budgets. Memory usage, thread pools, connection limits, all bounded and predictable at startup. An out-of-memory crash during peak load is a resilience failure.
None of these require a specific technology. They require architectural discipline. A system built in any language can satisfy these requirements, if the team designs for them explicitly.
2. Minimal Attack Surface (Art. 9: Protection & Prevention)
Article 9 requires "protection and prevention measures" including "the security of network and information systems." The most effective protection measure in software is not a firewall or an encryption library. It is a small dependency tree.
Every external dependency is a potential attack vector. The npm ecosystem has demonstrated this repeatedly: left-pad (2016), event-stream (2018), ua-parser-js (2021), colors.js (2022). Each incident was a supply chain attack that affected thousands of downstream projects.
The dependency comparison is stark:
| Stack | External deps | Transitive deps | Audit effort |
|---|---|---|---|
| Typical Node.js service | 80-200 | 1,000-5,000+ | Very high, practically impossible to audit every package |
| Go service | 20-50 | 50-150 | Moderate, manageable with tooling |
| Rust service | 15-40 | 50-120 | Moderate, cargo-audit covers known CVEs |
| Zig service | 5-15 | 15-30 | Low, each dependency can be individually reviewed |
DORA does not mandate a specific language. It mandates that you can assess your supply chain risk. If your transitive dependency count is 5,000, you cannot honestly claim to have assessed it. The audit effort exceeds what any team can sustain.
Concrete recommendation: count your transitive dependencies. Run npm ls | wc -l or the equivalent for your stack. If the number exceeds what your security team can review annually, you have a DORA Art. 9 exposure.
3. Full Traceability (Art. 11-12: Response & Recovery)
Articles 11 and 12 require "strict ICT-related incident management" with "response and recovery plans." This is not about having a runbook. It is about architectural traceability: the ability to reconstruct the complete history of any operation after a failure.
What traceability requires:
- Correlation IDs. Every state-changing operation carries a unique identifier that propagates across every service it touches. An auditor can trace a payment from initiation to settlement, or to compensation, from a single ID.
- Journaled execution. Every step of a multi-step process is recorded before execution. If the process is interrupted (crash, timeout, provider outage), the journal tells you exactly where it stopped and what has already been committed.
- Deterministic recovery. "Recovery" means resuming from the exact point of interruption, not retrying from the beginning, not replaying with potentially different side effects. The journal is the recovery mechanism.
Durable execution engines provide all three properties architecturally. The workflow journal IS the audit trail. The correlation ID IS the workflow ID. Recovery IS journal replay. You don't bolt traceability onto the system after the fact, the execution model produces it as a byproduct.
Traditional alternatives, retry queues, dead-letter queues, saga compensation events, can achieve similar outcomes, but traceability must be engineered separately. The journal is implicit in durable execution; it is explicit (and often incomplete) in event-driven architectures.
4. Third-Party Risk Assessment (Art. 15: ICT Third-Party Risk)
Article 15 requires financial entities to assess and monitor the risks posed by their ICT third-party providers. This obligation flows downstream: your clients must assess you, and you must be assessable.
Being assessable means:
- Published dependency inventory. Not "we use industry-standard tools." A concrete list: these are our dependencies, these are their versions, this is the transitive graph.
- Documented recovery mechanisms. If your service goes down, what happens to in-flight transactions? Are they lost? Retried? Durably queued? The answer must be architectural, not aspirational.
- Incident response evidence. Not a policy document that says "we will respond within 4 hours." Evidence that your system detects, logs, and enables investigation of operational incidents. SHA-256 hash-chained audit logs that cannot be retroactively modified are a strong signal.
The strongest position: make your assessment easy. Publish your dependency count. Document your architecture. Show your audit trail format. The faster a client's compliance team can assess you, the faster you close the deal.
5. Testable Resilience (Art. 24-27: Resilience Testing)
Articles 24 through 27 require "digital operational resilience testing" including, for significant financial entities, "threat-led penetration testing." For infrastructure providers, the implication is: your system must be testable under failure conditions.
This goes beyond unit tests and integration tests. DORA-aligned resilience testing means:
- Reproducible failure scenarios. Can you simulate a database failure, a network partition, a provider timeout, and verify that the system behaves correctly? If the failure scenario is not reproducible, the test is not meaningful.
- Deterministic simulation. The gold standard: inject thousands of fault combinations (crashes, partitions, clock skew, disk corruption) into a simulated environment and verify correctness. If the system is deterministic, every simulation run produces identical results for the same seed, making bugs reproducible and fixable.
- Continuous verification. Resilience is not a quarterly exercise. The system should be continuously tested under fault conditions as part of the CI/CD pipeline. Every release is validated against the same failure scenarios.
Few organizations achieve deterministic simulation testing. But the direction is clear: DORA rewards architectures that are inherently testable, deterministic, reproducible, and amenable to automated fault injection.
What "DORA-Compliant" Actually Means
A technology provider cannot claim "DORA-compliant." DORA applies to regulated financial entities and their oversight of ICT providers. There is no DORA certification for software products.
What you can do:
- Demonstrate architectural alignment. Show that your design addresses the articles listed above. Map your architecture decisions to specific DORA requirements. This is what your clients' compliance teams need during vendor assessment.
- Publish your evidence. Dependency inventory. Recovery mechanisms. Audit trail format. Resilience testing methodology. Make this available in a trust center or security documentation page, not behind a sales call.
- Use honest language. "Designed for DORA alignment" is defensible. "DORA-compliant" is not. "Architecturally aligned with DORA Art. 11-12" is precise. "Meets all DORA requirements" is a claim you cannot make.
The honesty is the trust signal. A provider that acknowledges what DORA requires and demonstrates how their architecture addresses it, without overclaiming, is more credible than one that stamps "DORA-compliant" on a landing page.
Financial infrastructure is a trust business. The regulations exist because trust must be verifiable. Build systems that are verifiable by construction. Document what you have built. Let the architecture speak for itself.
Read more: Security & Compliance | Workflows, Durable Execution Engine
Sources:
- DORA, Regulation (EU) 2022/2554, Art. 5-6 (ICT Risk Management), Art. 9 (Protection & Prevention), Art. 11-12 (Response & Recovery), Art. 15 (Third-Party Risk), Art. 24-27 (Resilience Testing)
- EUR-Lex: 2022/2554
- npm supply chain incidents: left-pad (2016), event-stream (2018), ua-parser-js (2021), colors.js (2022)