Die Architektur eines Financial Operating Systems

---

Ein typisches Core-Banking-System verarbeitet Konten, Zahlungen, Compliance, Reporting und Produktkonfiguration in einer einzigen Anwendung. Eine Codebasis. Eine Datenbank. Eine Deployment-Einheit. Wenn die Rewards-Engine einen Bug hat, berührt das Deployment, das ihn behebt, auch den Zahlungsverarbeitungspfad. Wenn das Compliance-Team eine neue Screening-Regel braucht, enthält das Release unrelated Änderungen am Gebührenrechner.

Das ist kein hypothetisches Szenario. Es ist die Architektur der meisten Systeme, die in den letzten zwei Jahrzehnten gebaut wurden, und der Grund, warum Banken routinemäßig drei bis fünf Jahre für Core-Transformationsprojekte aufwenden, die häufig ins Stocken geraten, das Budget überschreiten oder ganz eingestellt werden.

Die Alternative ist keine Microservice-Explosion. Es ist eine bewusste Trennung in drei Schichten, jede mit einer eigenen Fehlerdomäne, einer eigenen Änderungshäufigkeit und einer eigenen Korrektheitsanforderung.

Drei Schichten, drei Fehlerdomänen

Die Erkenntnis hinter dem, was ThoughtWorks „Coreless Banking" nennt, ist geradlinig: Nicht alles in einem Bankensystem trägt dasselbe Risiko. Das Ledger darf niemals falsch sein. Die Workflow-Engine darf niemals Zustand verlieren. Die Produktlogik ändert sich jeden Sprint. Alle drei mit derselben Deployment-Kadenz, denselben Technologieentscheidungen und derselben Teststrenge zu behandeln, ist entweder verschwenderisch (Over-Engineering der Produktschicht) oder gefährlich (Under-Engineering des Ledgers).

Anmerkung des Architekten: Die direkte Integration mit Clearinghäusern erfordert exakte Nachrichtenabfolgen. Fernel verwaltet die pacs.008-Originierung und die camt.054-Abwicklung autonom.

Schicht 1: Die Ledger-Engine

Verantwortung: Double-Entry-Invarianten, Saldointegrität, Immutabilität. Dies ist die Buchungsaufzeichnung. Sie beantwortet eine Frage: Was ist der autoritative Zustand jedes Kontos?

Eigenschaften:

• Strikte Serialisierbarkeit. Gleichzeitige Überweisungen auf dasselbe Konto produzieren unabhängig vom Timing dasselbe Ergebnis. Keine Anomalien. Keine Einschränkungen.
• Immutables Append-Only. Kein UPDATE, kein DELETE. Korrekturen sind neue Einträge, die den Originalbeleg referenzieren. Die vollständige Historie bleibt immer erhalten.
• Engine-erzwungene Invarianten. Eine Überweisung, die nicht ausgeglichen ist (Summe der Belastungen ≠ Summe der Gutschriften), wird von der Engine abgelehnt, nicht vom Anwendungscode. Dies eliminiert Geldentstehung und -vernichtung als Bug-Kategorie.

Änderungshäufigkeit: fast nie. Die Ledger-Engine ist Infrastruktur. Man aktualisiert sie für Performance- oder Sicherheits-Patches, nicht für Geschäftslogik-Änderungen.

Fehlerauswirkung: katastrophal. Wenn das Ledger korrumpiert ist, sind die Finanzdaten unzuverlässig. Jedes nachgelagerte System, Reconciliation, Reporting, Compliance, erbt die Korruption.

Schicht 2: Die Orchestrierungs-Engine

Verantwortung: Koordination mehrstufiger Prozesse. Kontoeröffnung (Entität erstellen → Konten provisionieren → IBAN zuweisen → KYC auslösen). Zahlungsausführung (validieren → screenen → belasten → an Clearing-Netzwerk übermitteln → Settlement verfolgen). Das sind keine Einzeloperationen, es sind Workflows, die mehrere Services umspannen und Sekunden, Minuten oder Tage bis zum Abschluss brauchen können.

Eigenschaften:

• Durable Execution. Jeder Schritt wird vor der Ausführung journalisiert. Wenn der Prozess unterbrochen wird, Crash, Timeout, Provider-Ausfall, spielt die Engine das Journal ab und nimmt am exakten Fehlerpunkt wieder auf. Keine doppelten Seiteneffekte. Keine übersprungenen Schritte.
• Exactly-Once-Semantik. Das Journal garantiert, dass jeder Schritt einmal ausgeführt wird, auch über Neustarts hinweg. Eine Eigenschaft des Ausführungsmodells, nicht anwendungsseitige Idempotenz.
• Eingebauter Audit-Trail. Das Journal IST der Audit-Trail. Jeder Workflow hat eine Correlation ID. Jeder Schritt wird mit Inputs, Outputs und Timing protokolliert. Ein Auditor kann den vollständigen Lebenszyklus jeder Operation anhand einer einzigen Kennung rekonstruieren.

Änderungshäufigkeit: selten. Neue Workflow-Typen werden hinzugefügt, wenn neue Fähigkeiten eingeführt werden (ein neues Zahlungsschema, ein neuer Compliance-Check), aber die Engine selbst ist stabil.

Fehlerauswirkung: eingeschränkt. Wenn die Orchestrierungs-Engine ausfällt, stocken laufende Prozesse, aber die Daten sind sicher. Das Ledger ist nicht betroffen. Wenn die Engine sich erholt, spielt sie vom Journal ab und vervollständigt die gestockten Prozesse.

Schicht 3: Die Domain-Schicht

Verantwortung: alles, was das Produkt zum Produkt macht. Gebührenstrukturen. Compliance-Regeln. KYC-Provider-Integration. Onboarding-Flows. Partner-API-Adapter. Reporting-Templates. Hier differenziert sich das Geschäft.

Eigenschaften:

• Configuration as Code. Produktregeln als versionierte Konfiguration, nicht eingebettet in Anwendungscode. Eine neue Gebührenstruktur ist ein Config-Deployment, kein Code-Release.
• Provider-Abstraktion. KYC-Provider, Zahlungsschema, AML-Screening-Service, alle hinter standardisierten Interfaces. Die Domain-Schicht weiß, dass sie einen KYC-Check braucht; sie weiß nicht (und es ist ihr egal), ob Identomat, Onfido oder ein manueller Prozess ihn erfüllt. Provider-Wechsel ist eine Konfigurationsänderung.
• Häufige Releases. Diese Schicht ändert sich jeden Sprint. Neue Features, angepasste Regeln, neue Integrationen. Die Deployment-Kadenz ist schnell, weil Fehler hier eingedämmt sind.

Änderungshäufigkeit: hoch. Das ist das Produkt. Es entwickelt sich ständig weiter.

Fehlerauswirkung: eingedämmt. Ein Bug in der Reward-Berechnung bricht Rewards. Er korrumpiert nicht das Ledger. Er lähmt keine Zahlungen. Der Blast Radius wird durch die Service-Grenze begrenzt.

Warum „Einfach eine Queue nehmen" bei Finanzprozessen versagt

Der Instinkt bei der Koordination mehrstufiger Prozesse ist, zu einer Message Queue zu greifen. Schritt 1 publiziert ein Event. Schritt 2 abonniert, verarbeitet, publiziert das nächste Event. Kompensation ist ein weiteres Event bei Fehler.

Das funktioniert für Benachrichtigungssysteme, Analytics-Pipelines und Cache-Invalidierung. Es funktioniert nicht gut für Finanzprozesse, aus einem bestimmten Grund: Der „Prozess" ist implizit. Keine einzelne Komponente kennt den aktuellen Zustand des End-to-End-Flows. Debugging erfordert forensische Analyse über mehrere Consumer-Logs hinweg. Und die Koordination selbst, die Reihenfolge der Schritte, die Fehlerbehandlung, die Entscheidung zur Kompensation, ist über unabhängige Consumer verstreut.

Betrachten Sie eine SEPA-Überweisung:

1. IBAN und Betrag validieren
2. AML-Screening (externer Provider-Aufruf)
3. Sender-Konto belasten (Ledger-Operation)
4. An Clearing-Netzwerk übermitteln
5. Settlement-Status verfolgen

Schritt 3 belastet das Konto des Senders. Schritt 4 scheitert, das Clearing-Netzwerk lehnt die Zahlung ab. Das System muss die Belastung aus Schritt 3 rückgängig machen.

Mit einem Queue-basierten Ansatz: ein Kompensations-Event publizieren. Ein Consumer nimmt es auf und macht die Belastung rückgängig. Aber was, wenn die Kompensationsnachricht verloren geht? Was, wenn der Consumer crasht, bevor er sie verarbeitet? Was, wenn die Stornierung selbst fehlschlägt? Jeder Fehlermodus erfordert eigene Behandlung, und die Behandlung ist über das System verteilt, ohne zentrale Aufzeichnung des Prozesszustands.

Mit einer Durable-Execution-Engine: Schritt 4 schlägt fehl. Die Engine zeichnet den Fehler im Journal auf. Sie führt die Kompensation (Belastung rückgängig machen) als journalisierten Schritt aus. Wenn die Kompensation unterbrochen wird, wird sie vom Journal wiederholt. Der gesamte Prozess, einschließlich Fehler und Kompensation, ist in einem einzigen Journal mit einer einzigen Correlation ID sichtbar.

Der Unterschied ist operativ: „Wir denken, wir haben es storniert" versus „Das Journal beweist, dass wir es storniert haben, und hier ist die exakte Abfolge der Ereignisse."

Das Write-Gateway-Pattern

Eine Konsequenz dieser Architektur: Alle zustandsändernden Operationen laufen durch die Orchestrierungsschicht. Lesevorgänge umgehen sie.

Der Finance Service (Zig API) hält das Ledger und die Domain-Daten. Er wird nie dem öffentlichen Internet exponiert. Die Orchestration Engine ist der einzige kontrollierte Eintrittspunkt für alle Mutationen.

Lesevorgänge gehen direkt an den Finance-Service. Kein Orchestrierungs-Overhead. Schnell.

Schreibvorgänge gehen durch die Orchestrierungs-Engine. Jede Mutation wird journalisiert. Dauerhaft. Auditierbar. Wenn die Engine ausgefallen ist, werden Schreibvorgänge in eine Queue gestellt, bis sie sich erholt. Datenintegrität wird nie kompromittiert.

Dieses Pattern hat einen Sicherheitsvorteil: Der Finance-Service ist nie dem öffentlichen Internet ausgesetzt. Die Orchestrierungs-Engine ist der einzige kontrollierte Einstiegspunkt für alle Mutationen. Die Angriffsfläche wird durch die Architektur minimiert, nicht nur durch Firewall-Regeln.

Wo Sie sich differenzieren

Die Ledger- und Orchestrierungsschichten sind Infrastruktur. Sie sind notwendig, aber sie sind nicht das, was Ihr Produkt für Kunden wertvoll macht. Kunden wählen Sie wegen:

• Der Gebührenstruktur, die zu ihrem Geschäftsmodell passt (prozentual, gestaffelt, Abo oder hybrid).
• Des Compliance-Flows, der ihren Regulator zufriedenstellt (jurisdiktionsspezifische KYC-Tiefe, CDD-Policies, AML-Screening-Provider).
• Der Integration mit ihren bestehenden Systemen (ERP-Reconciliation, Partnerbank-Konnektivität, Zahlungsschema-Unterstützung).
• Der Onboarding-Erfahrung, die Interessenten in aktive Konten konvertiert.

All das lebt in der Domain-Schicht. Es ändert sich häufig. Es wird konfiguriert, nicht hart codiert. Ein neuer Markteintritt erfordert neue Jurisdiktionsprofile und Compliance-Policies, kein neues Ledger und keine neue Workflow-Engine.

Die Architektur ermöglicht dies: Die Infrastrukturschichten liefern Korrektheitsgarantien und operationelle Resilienz. Die Domain-Schicht liefert Produktflexibilität. Beide entwickeln sich unabhängig voneinander.

Regulatorische Ausrichtung by Design

Die Drei-Schichten-Architektur ordnet sich direkt spezifischen regulatorischen Anforderungen zu. Compliance ist eine Eigenschaft des Designs, keine nachträglich hinzugefügte Schicht.

Jede regulatorische Anforderung wird von der dafür designten Schicht erfüllt. Das Ledger behandelt die Buchungsintegrität (PSD2, HGB). Die Orchestrierungs-Engine behandelt Rückverfolgbarkeit und Wiederherstellung (DORA Art. 11-12). Die Domain-Schicht behandelt Compliance-Logik (AMLD). Keine einzelne Schicht trägt die gesamte regulatorische Last.

Drei Fragen zur Bewertung jeder Finanzplattform

Wenn Sie eine Core-Banking-Plattform evaluieren, ob Sie eine bauen, kaufen oder eine bestehende modernisieren, offenbaren drei Fragen, ob die Architektur solide ist:

1. Kann ein Bug in Ihrer Produktlogik Ihr Ledger korrumpieren?

Wenn Ledger und Domain-Schicht eine Datenbank teilen, oder wenn der Anwendungscode für die Durchsetzung der Double-Entry-Invarianten verantwortlich ist, lautet die Antwort ja. Ein einzelnes ungeschütztes UPDATE, eine fehlende WHERE-Klausel in einem Refund-Handler, eine Race Condition in einem Gebührenrechner, jedes davon kann die Finanzdaten stillschweigend korrumpieren. Wenn die Schichten isoliert sind und das Ledger seine eigenen Invarianten erzwingt, lautet die Antwort nein.

2. Wenn Ihre Orchestrierungs-Engine mitten in einer Zahlung neu startet, was passiert mit der Zahlung?

Wenn die Antwort „das hängt von der Retry-Logik des Consumers ab" oder „wir müssten die Dead-Letter-Queue prüfen" ist, haben Sie keine Durable Execution. Wenn die Antwort „die Engine spielt das Journal ab und nimmt bei Schritt 4 wieder auf" ist, haben Sie sie.

3. Können Sie Ihren KYC-Provider wechseln, ohne Ihren Onboarding-Code zu ändern?

Wenn die API des Providers direkt aus Ihrem Onboarding-Flow aufgerufen wird, sind Provider und Flow gekoppelt. Ein Provider-Wechsel ist eine Code-Änderung, ein Testzyklus und ein Deployment. Wenn der Onboarding-Flow ein Provider-Interface aufruft und die Konfiguration bestimmt, welche Implementierung es erfüllt, ist der Wechsel eine Config-Änderung.

Das sind keine Fangfragen. Sie haben binäre Antworten. Und sie sagen die Betriebskosten des Systems über die nächsten fünf Jahre genauer voraus als jede Feature-Vergleichsmatrix.

---

Weiterlesen: Das Ledger | Workflows, Durable Execution | Warum Double-Entry unverzichtbar ist

---

Quellen:

• ThoughtWorks, „Kill your core: The banking revolution you didn't see coming"
• ThoughtWorks, „Cloud-native composable banking" (AWS Whitepaper)
• DORA, Verordnung (EU) 2022/2554, Art. 11-12 (IKT-Rückverfolgbarkeit und Wiederherstellung)
• Stripe (Temporal), Wise (Saga → Temporal Migration), N26 (Kafka+Sagas), Revolut (Temporal), Industrie-Adoption von Durable Execution für zahlungskritische Pfade