Bank-Event-Sourcing: CRM-Architektur und Audit-Trail

In der Fintech-Landschaft des Jahres 2026 geht es beim Datenmanagement nicht mehr nur um die Speicherung des aktuellen Zustands, sondern um die Fähigkeit, mathematisch zu beweisen, wie dieser Zustand erreicht wurde. Bank-Event-Sourcing stellt den notwendigen Paradigmenwechsel dar, um strenge Compliance-Vorschriften (wie PSD3 und die Weiterentwicklungen von Basel) sowie die Anforderungen an operative Transparenz zu erfüllen. In diesem technischen Leitfaden untersuchen wir, warum die CRUD-Architektur (Create, Read, Update, Delete) für kritische Finanz-CRMs mittlerweile obsolet ist und wie man ein auf unveränderlichen Events basierendes System für die Verwaltung von Hypothekenanträgen implementiert.

Das Problem von CRUD im Finanzsektor

Jahrzehntelang basierte die Softwareentwicklung auf dem CRUD-Modell. In einer klassischen relationalen Datenbank führen wir, wenn ein Hypothekenantrag von “In Bearbeitung” auf “Bewilligt” wechselt, einen UPDATE-Befehl aus, der den vorherigen Wert überschreibt. Obwohl dies speichereffizient ist, bringt dieser Ansatz einen kritischen Informationsverlust mit sich: Die Historie geht verloren.

Im Bankkontext ist das Überschreiben von Daten ein inakzeptables Risiko. Um den Audit-Trail zu gewährleisten, greifen Entwickler oft auf separate Log-Tabellen oder komplexe Datenbank-Trigger zurück. Dieser Ansatz hat jedoch zwei fatale Mängel:

• Diskrepanz: Das Log ist ein Nebeneffekt, nicht die Quelle der Wahrheit (Source of Truth). Wenn das Log fehlschlägt, aber das Update erfolgreich ist, entsteht eine Korruption des Audits.
• Fehlender Kontext: Wir wissen, dass sich die Daten geändert haben, verlieren aber oft das “Warum” (die geschäftliche Absicht).

Event Sourcing: Der Vorgang als Geschichte, nicht als Zustand

Das Bank-Event-Sourcing kehrt dieses Modell um. Anstatt den aktuellen Status eines Hypothekenantrags zu speichern, speichern wir die Sequenz der Ereignisse (Events), die zu diesem Status geführt haben. Die Datenbank enthält keine veränderbare Zeile mehr, sondern ein unveränderliches Append-only Log (Nur-Lese-Protokoll).

Nach den von Experten wie Martin Fowler definierten Prinzipien ist der aktuelle Zustand der Anwendung rein eine mathematische Ableitung: Er ist die Summe aller vergangenen Ereignisse, die sequenziell abgespielt werden.

Domänenmodellierung: Von Objekten zu Events

Stellen wir uns den Lebenszyklus einer Hypothek vor. In einem CRUD-System hätten wir eine Tabelle Antraege. Im Event Sourcing definieren wir präzise Domänen-Events:

• HypothekenantragErstellt (Enthält Kunden-ID, angeforderten Betrag, Datum)
• EinkommensnachweisHochgeladen (Enthält Referenzen zu PDFs, Metadaten)
• BonitaetsscoreBerechnet (Enthält den Score der Kreditauskunftei zum Zeitpunkt der Berechnung)
• ZinssatzFixiert (Enthält den IRS-Satz des Tages)
• BewilligungErteilt (Enthält die ID des Entscheidungsträgers)

Jedes Ereignis ist ein unveränderlicher historischer Fakt. Es kann nicht gelöscht oder geändert, sondern nur durch ein nachfolgendes Ereignis kompensiert werden (z. B. BewilligungStorniert).

Referenzarchitektur: CQRS und Streaming

Die Implementierung eines Bank-Event-Sourcing-Systems erfordert fast immer die Einführung des CQRS-Musters (Command Query Responsibility Segregation). Da das Lesen einer Sequenz von 100 Ereignissen zur Wiederherstellung des Zustands eines Antrags jedes Mal ineffizient ist, wenn ein Sachbearbeiter das Dashboard öffnet, trennen wir das Schreiben vom Lesen.

1. Die Write Side (Command)

Das Herzstück des Systems ist der Event Store. Technologien wie Apache Kafka oder Amazon Kinesis sind hierfür aufgrund ihrer Natur als verteiltes Log und ihrer dauerhaften Persistenz ideal.

Wenn ein CRM-Agent auf “Einkommen genehmigen” klickt, führt das System Folgendes aus:

1. Validierung des Befehls gegen den aktuellen Zustand (im Speicher rekonstruiert).
2. Generierung des Events EinkommenVerifiziert.
3. Schreiben des Events in ein Kafka-Topic (z. B. hypotheken-events-v1).

2. Die Read Side (Query) – Die Projektionen

Um die Daten im CRM anzuzeigen, verwenden wir “Consumer”, die das Kafka-Topic abhören und für das Lesen optimierte Datenbanken (Projektionen) aktualisieren. Wir können verschiedene Projektionen für denselben Datenstrom haben:

• Operative Projektion (SQL/NoSQL): Eine Tabelle AktiveAntraege in PostgreSQL oder MongoDB, die den aktuellen Status für die Benutzeroberfläche des Agenten enthält.
• Analytische Projektion (Elasticsearch): Ein Index, der es dem Marketingteam ermöglicht, nach “allen Anträgen, die im letzten Monat wegen unzureichendem Einkommen abgelehnt wurden” zu suchen.
• Audit-Projektion (Cold Storage): Archivierung auf S3/Glacier für langfristige Compliance.

Kritische Vorteile für Fintech

Nativer Audit-Trail und “By Design”

Beim Event Sourcing ist der Audit-Trail keine Zusatzfunktion: Er ist die Datenbank selbst. Es ist nicht möglich, den Status zu ändern, ohne eine unlöschbare Spur zu hinterlassen. Dies erfüllt nativ die Anforderungen an die Nichtabstreitbarkeit, die von Aufsichtsbehörden gefordert werden.

Time-Travel-Debugging

Dies ist vielleicht die mächtigste Funktion für Entwickler und Prüfer. Stellen Sie sich vor, ein Kunde ficht einen vor sechs Monaten angewandten Zinssatz an. In einem CRUD-System würden Sie nur den aktuellen Zinssatz sehen. Mit Event Sourcing können Sie:

1. Die ID des Antrags nehmen.
2. Die Ereignisse von 0 bis zum genauen Datum der Anfechtung abspielen (z. B. 11.01.2025, 14:30 Uhr).
3. Exakt den Systemzustand, die Eingabedaten und die Geschäftsregeln sehen, die in diesem genauen Moment aktiv waren.

Dies ermöglicht die Beantwortung von Fragen wie: “Warum hat das System den Antrag an diesem Tag abgelehnt?”, indem der genaue Kontext rekonstruiert wird, einschließlich eventueller Bugs, die im Code zu diesem vergangenen Zeitpunkt vorhanden waren.

Technische Implementierung: Snippet eines Events

So könnte ein strukturiertes JSON-Event für ein Bankensystem aussehen:

{
  "eventId": "550e8400-e29b-41d4-a716-446655440000",
  "eventType": "RiskAssessmentCompleted",
  "aggregateId": "HYPOTHEK-2026-8899",
  "timestamp": "2026-01-11T10:15:30Z",
  "version": 1,
  "metadata": {
    "userId": "agent_mueller",
    "ipAddress": "192.168.1.50",
    "correlationId": "req-123-abc"
  },
  "payload": {
    "riskScore": "LOW",
    "maxLTV": 0.80,
    "interestRateSpread": 1.25,
    "rulesVersion": "v2025.12"
  }
}

Beachten Sie das Feld rulesVersion im Payload: Auch die Version der verwendeten Geschäftsregeln zu historisieren, ist entscheidend, um automatische Entscheidungen bei einem Audit zu rechtfertigen.

Herausforderungen und abschließende Überlegungen

Die Einführung von Bank-Event-Sourcing</strong ist nicht ohne Kosten. Die architektonische Komplexität steigt und erfordert ein sorgfältiges Management von:

• Schema Evolution: Wie geht man mit Events um, die vor 5 Jahren mit einer anderen Struktur als der heutigen erstellt wurden? (Lösung: Upcasters).
• Snapshotting: Bei Anträgen mit Tausenden von Events ist das Abspielen von Null an langsam. Man erstellt periodische “Snapshots” des Zustands, um das Laden zu beschleunigen.
• DSGVO und Recht auf Vergessenwerden: Daten in einem unveränderlichen Log zu löschen, ist komplex. Oft greift man auf die Technik des “Crypto-Shredding” zurück (Verschlüsselung sensibler Daten und Löschung des Entschlüsselungsschlüssels).

Trotz dieser Herausforderungen überwiegen für moderne Core-Banking-Systeme und Finanz-CRMs die Vorteile in Bezug auf Sicherheit, Rückverfolgbarkeit und Resilienz bei weitem die Implementierungskosten. Der Wechsel zum Event-Modell bedeutet, keine Daten mehr zu verlieren und mit dem Aufbau eines historischen Informationsvermögens von unschätzbarem Wert zu beginnen.

Häufig gestellte Fragen