DORA für Finanzinfrastruktur-Anbieter: Was Sie tatsächlich bauen müssen

---

Compliance-Teams schreiben Richtlinien. Engineering-Teams bauen Systeme. In den meisten Fintechs produzieren beide separate Dokumente, präsentieren vor separaten Zielgruppen und gleichen sich selten ab. DORA erzwingt den Abgleich.

Der Digital Operational Resilience Act (Verordnung 2022/2554) gilt seit dem 17. Januar 2025. Er betrifft Finanzunternehmen in der gesamten EU, Banken, Zahlungsinstitute, E-Geld-Institute, Wertpapierfirmen. Aber er erreicht auch deren Technologieanbieter. Artikel 15 legt Aufsichtsanforderungen für „kritische IKT-Drittdienstleister" fest. Wenn Sie Infrastruktur bauen, von der regulierte Unternehmen abhängen, sind Sie im Geltungsbereich. Nicht als Nice-to-have. Als regulatorische Erwartung, die Ihre Kunden durchsetzen müssen.

Die meisten Fintechs lesen DORA als Policy-Übung: Risikoregister aktualisieren, einen Abschnitt zur SOC-2-Narrative hinzufügen, das Team schulen. Das verfehlt den Punkt. DORA ist eine Systemspezifikation. Sie definiert architektonische Eigenschaften, die Ihre Technologie aufweisen muss. Richtlinien beschreiben Absicht. Architektur liefert Fähigkeit.

Fünf architektonische Anforderungen, die die meisten Fintechs übersehen

DORA umfasst 64 Artikel in 9 Kapiteln. Nicht alle haben architektonische Implikationen. Fünf schon.

1. Deterministische Systeme (Art. 5-6: IKT-Risikomanagement)

DORA fordert von Finanzunternehmen, „alle IKT-gestützten Geschäftsfunktionen zu identifizieren, zu klassifizieren und angemessen zu dokumentieren" und Systeme aufrechtzuerhalten, die „zuverlässig und resilient" sind. In Engineering-Begriffen: Ihr System muss sich unter allen Bedingungen vorhersagbar verhalten, einschließlich bei Ausfällen.

Was das für die Architektur bedeutet:

• Keine Garbage-Collection-Pausen während Settlement-Fenstern. Ein GC-Stop-the-World-Event während eines Zahlungsbatches ist ein nicht-deterministischer Fehler, den DORAs Risikorahmen zu bewerten und zu mitigieren fordert.
• Auditierbare Codepfade. Ein externer Auditor muss eine spezifische Transaktion von der API-Aufnahme bis zur Ledger-Festschreibung nachverfolgen können. Wenn der Pfad von Laufzeitbedingungen abhängt, die nicht protokolliert werden, ist das System nicht angemessen dokumentiert.
• Statische Ressourcenbudgets. Speicherverbrauch, Thread-Pools, Verbindungslimits, alle beim Start begrenzt und vorhersagbar. Ein Out-of-Memory-Crash bei Spitzenlast ist ein Resilienz-Fehler.

Nichts davon erfordert eine bestimmte Technologie. Es erfordert architektonische Disziplin. Ein System, das in jeder Sprache gebaut wird, kann diese Anforderungen erfüllen, wenn das Team explizit dafür designed.

2. Minimale Angriffsfläche (Art. 9: Schutz und Prävention)

Artikel 9 fordert „Schutz- und Präventionsmaßnahmen" einschließlich „der Sicherheit von Netz- und Informationssystemen". Die wirksamste Schutzmaßnahme in Software ist keine Firewall und keine Verschlüsselungsbibliothek. Es ist ein kleiner Abhängigkeitsbaum.

Jede externe Abhängigkeit ist ein potenzieller Angriffsvektor. Das npm-Ökosystem hat dies wiederholt demonstriert: left-pad (2016), event-stream (2018), ua-parser-js (2021), colors.js (2022). Jeder Vorfall war ein Supply-Chain-Angriff, der Tausende nachgelagerter Projekte betraf.

Der Abhängigkeitsvergleich ist deutlich:

DORA schreibt keine bestimmte Sprache vor. Sie schreibt vor, dass Sie Ihr Supply-Chain-Risiko bewerten können. Wenn Ihre transitive Abhängigkeitsanzahl 5.000 beträgt, können Sie nicht ehrlich behaupten, sie bewertet zu haben. Der Audit-Aufwand übersteigt, was jedes Team dauerhaft leisten kann.

Konkrete Empfehlung: Zählen Sie Ihre transitiven Abhängigkeiten. Führen Sie npm ls | wc -l oder das Äquivalent für Ihren Stack aus. Wenn die Zahl übersteigt, was Ihr Sicherheitsteam jährlich prüfen kann, haben Sie eine DORA Art. 9 Exposition.

3. Vollständige Rückverfolgbarkeit (Art. 11-12: Reaktion und Wiederherstellung)

Artikel 11 und 12 fordern „umfassendes IKT-bezogenes Incident Management" mit „Reaktions- und Wiederherstellungsplänen". Das bedeutet nicht, ein Runbook zu haben. Es bedeutet architektonische Rückverfolgbarkeit: die Fähigkeit, die vollständige Historie jeder Operation nach einem Ausfall zu rekonstruieren.

Was Rückverfolgbarkeit erfordert:

• Correlation IDs. Jede zustandsändernde Operation trägt eine eindeutige Kennung, die sich über jeden berührten Service fortpflanzt. Ein Auditor kann eine Zahlung von der Initiierung bis zur Abwicklung, oder zur Kompensation, anhand einer einzigen ID nachverfolgen.
• Journalisierte Ausführung. Jeder Schritt eines mehrstufigen Prozesses wird vor der Ausführung aufgezeichnet. Wenn der Prozess unterbrochen wird (Crash, Timeout, Provider-Ausfall), zeigt das Journal genau, wo er gestoppt hat und was bereits festgeschrieben wurde.
• Deterministische Wiederherstellung. „Wiederherstellung" bedeutet Wiederaufnahme ab dem exakten Unterbrechungspunkt, nicht von Anfang an wiederholen, nicht mit potenziell anderen Seiteneffekten erneut abspielen. Das Journal ist der Wiederherstellungsmechanismus.

Durable-Execution-Engines liefern alle drei Eigenschaften architektonisch. Das Workflow-Journal IST der Audit-Trail. Die Correlation ID IST die Workflow-ID. Wiederherstellung IST Journal-Replay. Man schraubt Rückverfolgbarkeit nicht nachträglich ans System, das Ausführungsmodell produziert sie als Nebenprodukt.

Traditionelle Alternativen, Retry-Queues, Dead-Letter-Queues, Saga-Kompensations-Events, können ähnliche Ergebnisse erzielen, aber Rückverfolgbarkeit muss separat engineered werden. Das Journal ist implizit bei Durable Execution; es ist explizit (und oft unvollständig) in ereignisgesteuerten Architekturen.

4. Drittanbieter-Risikobewertung (Art. 15: IKT-Drittanbieterrisiko)

Artikel 15 fordert von Finanzunternehmen, die Risiken ihrer IKT-Drittanbieter zu bewerten und zu überwachen. Diese Verpflichtung fließt nachgelagert: Ihre Kunden müssen Sie bewerten, und Sie müssen bewertbar sein.

Bewertbar sein bedeutet:

• Veröffentlichtes Abhängigkeitsinventar. Nicht „wir nutzen branchenübliche Tools". Eine konkrete Liste: dies sind unsere Abhängigkeiten, dies sind ihre Versionen, dies ist der transitive Graph.
• Dokumentierte Wiederherstellungsmechanismen. Wenn Ihr Service ausfällt, was passiert mit laufenden Transaktionen? Gehen sie verloren? Werden sie wiederholt? Werden sie dauerhaft in eine Queue gestellt? Die Antwort muss architektonisch sein, nicht aspirativ.
• Incident-Response-Evidenz. Nicht ein Policy-Dokument, das sagt „wir werden innerhalb von 4 Stunden reagieren". Evidenz, dass Ihr System operative Vorfälle erkennt, protokolliert und die Untersuchung ermöglicht. SHA-256-hashverkettete Audit-Logs, die nicht nachträglich verändert werden können, sind ein starkes Signal.

Die stärkste Position: Machen Sie Ihre Bewertung einfach. Veröffentlichen Sie Ihre Abhängigkeitsanzahl. Dokumentieren Sie Ihre Architektur. Zeigen Sie Ihr Audit-Trail-Format. Je schneller das Compliance-Team eines Kunden Sie bewerten kann, desto schneller schließen Sie den Deal.

5. Testbare Resilienz (Art. 24-27: Resilienztests)

Artikel 24 bis 27 fordern „digitale operative Resilienztests" einschließlich, für signifikante Finanzunternehmen, „bedrohungsgeleitete Penetrationstests". Für Infrastrukturanbieter ist die Implikation: Ihr System muss unter Fehlerbedingungen testbar sein.

Das geht über Unit-Tests und Integrationstests hinaus. DORA-ausgerichtete Resilienztests bedeuten:

• Reproduzierbare Fehlerszenarien. Können Sie einen Datenbankausfall, eine Netzwerkpartition, einen Provider-Timeout simulieren und verifizieren, dass sich das System korrekt verhält? Wenn das Fehlerszenario nicht reproduzierbar ist, ist der Test nicht aussagekräftig.
• Deterministische Simulation. Der Goldstandard: Tausende von Fehlerkombinationen (Crashes, Partitionen, Clock-Skew, Disk-Corruption) in eine simulierte Umgebung injizieren und Korrektheit verifizieren. Wenn das System deterministisch ist, produziert jeder Simulationslauf identische Ergebnisse für denselben Seed, was Bugs reproduzierbar und behebbar macht.
• Kontinuierliche Verifikation. Resilienz ist keine vierteljährliche Übung. Das System sollte kontinuierlich unter Fehlerbedingungen als Teil der CI/CD-Pipeline getestet werden. Jedes Release wird gegen dieselben Fehlerszenarien validiert.

Wenige Organisationen erreichen deterministische Simulationstests. Aber die Richtung ist klar: DORA belohnt Architekturen, die inhärent testbar sind, deterministisch, reproduzierbar und zugänglich für automatisierte Fehlerinjektion.

Was „DORA-konform" tatsächlich bedeutet

Ein Technologieanbieter kann nicht „DORA-konform" beanspruchen. DORA gilt für regulierte Finanzunternehmen und deren Aufsicht über IKT-Anbieter. Es gibt keine DORA-Zertifizierung für Softwareprodukte.

Was Sie tun können:

• Architektonische Ausrichtung demonstrieren. Zeigen Sie, dass Ihr Design die oben aufgeführten Artikel adressiert. Ordnen Sie Ihre Architekturentscheidungen spezifischen DORA-Anforderungen zu. Das ist es, was die Compliance-Teams Ihrer Kunden bei der Anbieterbewertung brauchen.
• Ihre Evidenz veröffentlichen. Abhängigkeitsinventar. Wiederherstellungsmechanismen. Audit-Trail-Format. Resilienztest-Methodik. Stellen Sie dies in einem Trust Center oder einer Sicherheitsdokumentationsseite zur Verfügung, nicht hinter einem Verkaufsgespräch.
• Ehrliche Sprache verwenden. „Designed für DORA-Ausrichtung" ist vertretbar. „DORA-konform" ist es nicht. „Architektonisch ausgerichtet an DORA Art. 11-12" ist präzise. „Erfüllt alle DORA-Anforderungen" ist eine Behauptung, die Sie nicht aufstellen können.

Die Ehrlichkeit ist das Vertrauenssignal. Ein Anbieter, der anerkennt, was DORA fordert, und demonstriert, wie seine Architektur es adressiert, ohne zu übertreiben, ist glaubwürdiger als einer, der „DORA-konform" auf eine Landingpage stempelt.

Finanzinfrastruktur ist ein Vertrauensgeschäft. Die Regulierungen existieren, weil Vertrauen verifizierbar sein muss. Bauen Sie Systeme, die konstruktionsbedingt verifizierbar sind. Dokumentieren Sie, was Sie gebaut haben. Lassen Sie die Architektur für sich sprechen.

---

Weiterlesen: Sicherheit & Compliance | Workflows, Durable Execution Engine

---

Quellen:

• DORA, Verordnung (EU) 2022/2554, Art. 5-6 (IKT-Risikomanagement), Art. 9 (Schutz und Prävention), Art. 11-12 (Reaktion und Wiederherstellung), Art. 15 (Drittanbieterrisiko), Art. 24-27 (Resilienztests)
• EUR-Lex: 2022/2554
• npm Supply-Chain-Vorfälle: left-pad (2016), event-stream (2018), ua-parser-js (2021), colors.js (2022)