Datenbankdesign für Banking 2026: Kernschemata und Sharding
Ein praxisorientierter Leitfaden zum Datenbankdesign für Kernbankensysteme: Ledger-Schemata, doppelte Buchführung, ACID-Konsistenz, Event Sourcing und Sharding-Strategien für hohe Transaktionsvolumina - mit Blick auf GoBD und BaFin-Anforderungen.
Grundprinzipien des Banking-Datenbankdesigns
Jedes Fintech-Produkt ist nur so zuverlässig wie seine Datenbank. Die Kartenzahlung, die SEPA-Überweisung, die nächtliche Zinsabgrenzung - all das schreibt in eine zentrale Datenbasis und liest aus ihr. Fehler im Datenbankdesign sind keine Performance-Probleme, die man später optimiert; sie sind Korrektheitsprobleme, die sich als Abstimmungsdifferenzen, Regulierungsbefunde oder nicht auffindbares Kundengeld äußern.
Banking-Datenbankdesign basiert auf Prinzipien, die jede Technologiegeneration überdauert haben: von Mainframe-VSAM-Dateien über relationale Datenbanken bis zu den cloud-nativen verteilten Systemen von heute. Die Bezeichnungen ändern sich, die grundlegenden Anforderungen nicht.
Unveränderlichkeit
Gebuchte Transaktionen werden niemals aktualisiert oder gelöscht. Korrekturen erscheinen als neue Stornobuchungen. Das Hauptbuch wächst nur vorwärts.
Doppelte Buchführung
Jede Geldbewegung belastet ein Konto und schreibt einem anderen den gleichen Betrag gut. Die Summe aller Buchungen ist stets null.
Event Sourcing
Der autoritative Datensatz ist das geordnete Ereignisprotokoll, nicht ein veränderbares Saldenfeld. Salden werden durch Wiedergabe dieses Protokolls ermittelt.
Praktisch bedeuten diese Prinzipien: DECIMAL oder NUMERIC für jede Geldspalte (niemals FLOAT), Fremdschlüssel-Constraints auf Datenbankebene statt nur in der Anwendungsschicht, und die Transaktionstabelle von Anfang an als append-only behandeln. Entscheidungen beim Schemaentwurf sind teuer zu revidieren, sobald Produktionsdaten vorhanden sind.
Lassen Sie uns Ihr Projekt besprechen und herausfinden, wie wir Ihr Projekt auf den Weg bringen können. digitales Bankprodukt zusammen
Demo anfordernSchemadesign für Konten, Buchungen und Produkte
Ein minimales, aber vollständiges Banking-Schema benötigt drei Kerndomänen-Entitäten mit klarer Trennung zwischen ihnen. Die genauen Spaltennamen variieren je nach Anbieter oder Team, aber die konzeptionelle Struktur spiegelt wider, wie Produktionssysteme bei Fintechs 2026 aufgebaut sind.
| Entität | Schlüsselspalten | Designhinweise |
|---|---|---|
| Kunde | customer_id, status, KYC-Stufe, created_at | Personenbezogene Daten verschlüsselt gespeichert (AES-256). Eine separate KYC-Ereignistabelle hält AML-Prüfergebnisse mit unveränderlichem Auditprotokoll. |
| Konto | account_id, customer_id, product_id, currency, status, current_balance, available_balance | Salden sind abgeleitete Aggregate, die transaktional aktualisiert werden; für Lesegeschwindigkeit gespeichert. product_id verweist auf den Produktkatalog, keine hardcodierten Geschäftsregeln. |
| Buchungsposten / Hauptbucheintrag | posting_id, account_id, transaction_id, amount (DECIMAL), direction (S/H), value_date, booking_date, status | Append-only. transaction_id gruppiert die zwei Seiten eines Buchungspaares. Salden werden durch Summation der Buchungen abgestimmt. |
| Transaktion | transaction_id, reference, channel, initiated_at, settled_at, narrative | Übergeordneter Datensatz, der ein oder mehrere Buchungspaare verknüpft. Speichert externe Referenzen (SWIFT UETR, SEPA-End-to-End-ID). |
| Produkt | product_id, type, interest_rate_config, fee_config, currency_rules | Produktdefinitionen als Daten - Girokonto, Sparkonto und Kredit unterscheiden sich durch Konfiguration, nicht durch Code. Ermöglicht neue Produkte ohne Schemaänderungen. |
Eine von vielen cloud-nativen Kernen übernommene Praxis ist die Trennung des Hauptbuchs (General Ledger) von der kundenseitigen Kontoschicht. Das Hauptbuch erzwingt die doppelte Buchführung auf Systemebene; die Kontoschicht aggregiert und präsentiert Salden für Kunden und APIs. Berichte laufen gegen ein separates Lesereplikat oder ein Data Warehouse, das per Change Data Capture (CDC) befüllt wird - so wird verhindert, dass Analyseabfragen mit Echtzeit-Transaktionsschreibvorgängen konkurrieren.
Konsistenz, ACID und das Hauptbuch
Banking gehört zu den wenigen Domänen, in denen die vollständige ACID-Garantie - Atomarität, Konsistenz, Isolation, Dauerhaftigkeit - nicht verhandelbar ist. Eine Kontobelastung, die ohne die entsprechende Gutschrift erfolgreich abgeschlossen wird, ist kein Leistungsverlust; es ist fehlendes Geld.
| Eigenschaft | Bedeutung für Banking | Praktische Umsetzung |
|---|---|---|
| Atomarität | Belastung und Gutschrift einer Überweisung werden entweder beide festgeschrieben oder beide zurückgerollt. Kein Teilzustand. | Einzelne Datenbanktransaktion, die beide Buchungszeilen umschließt. Saga-Muster für verteilte Hauptbücher. |
| Konsistenz | Summe aller Sollbuchungen minus Summe aller Habenbuchungen muss nach jeder Transaktion null ergeben. | Datenbank-CHECK-Constraints und Assertion auf Anwendungsebene zum Buchungszeitpunkt. |
| Isolation | Eine Saldoprüfung bei gleichzeitiger Überweisung muss entweder den Vor- oder Nach-Transfer-Zustand sehen, niemals eine Zwischenansicht. | Serializable oder REPEATABLE READ-Isolationsebene; Zeilensperren für Saldoaktualisierungen. |
| Dauerhaftigkeit | Sobald eine Zahlung bestätigt ist, muss sie Serverabsturz oder Stromausfall überstehen. | WAL (Write-Ahead-Log) in PostgreSQL/Oracle; synchrone Replikation auf mindestens eine Standby-Instanz. |
Event Sourcing ergänzt ACID, indem das Buchungsprotokoll als kanonischer Datensatz behandelt wird. Anstatt ein veränderbares Saldenfeld als einzige Wahrheitsquelle zu speichern, speichert das System jedes Ereignis (Belastung, Gutschrift, Gebühr, Zinsabgrenzung) und leitet den aktuellen Saldo durch Summation ab. Dies erzeugt einen natürlichen Auditpfad und vereinfacht die Aufbewahrung nach GoBD (Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form): da jeder Buchungsvorgang unveränderlich protokolliert ist, erfüllt die Datenbank die Unveränderlichkeits- und Nachvollziehbarkeitsanforderungen ohne zusätzliche Infrastruktur.
PostgreSQL ist 2026 die gängigste Open-Source-Engine für dieses Muster: serializable Isolation, Zeilensperren, logische Replikation für CDC, Bereichs- oder Hash-Partitionierung und der NUMERIC-Typ mit beliebiger Präzision. Cloud-verwaltete Varianten (AWS Aurora, Google AlloyDB, Azure Database for PostgreSQL) fügen verwaltetes Failover und Speicher-Autoskalierung auf demselben Wireprotokoll hinzu.
Sharding-Strategien für hohe Transaktionsvolumina
Ein einzelner PostgreSQL-Knoten verarbeitet unter guten Bedingungen grob 10.000-30.000 Transaktionen pro Sekunde. Viele Fintech-Plattformen erreichen diese Grenze innerhalb weniger Jahre nach dem Launch. Wenn vertikales Skalieren (mehr RAM und CPU auf einem Server) seine Kosten- und physische Grenze erreicht, ist der nächste Schritt horizontales Skalieren durch Sharding - Verteilung von Zeilen auf mehrere unabhängige Datenbankknoten, sodass jeder Knoten nur einen Bruchteil der Daten und des Traffics hält.
Eine Shard-Map (auch Routing-Tabelle oder Directory) verfolgt, welche Daten auf welchem Knoten liegen. Jede Abfrage durchläuft eine Routing-Schicht, die die Shard-Map konsultiert und die Anfrage an den richtigen Knoten weiterleitet.
| Strategie | Funktionsweise | Banking-Eignung | Risiken |
|---|---|---|---|
| Hash-basiert | Hash-Funktion auf den Shard-Key (z.B. account_id) leitet an einen festen Shard weiter. Consistent Hashing minimiert Datenbewegungen bei Knotenerweiterung. | Hervorragend für gleichmäßige Schreibverteilung über Konten. | Bereichsabfragen über viele Konten erfordern Fan-out auf alle Shards. |
| Bereichsbasiert | Sequentielle Bereiche des Keys (z.B. Konto-IDs 0-999999 auf Shard 1, 1000000-1999999 auf Shard 2). | Gut für Zeitreihendaten und datumsbasierte Berichte. | Neue Konten oder aktuelle Transaktionen konzentrieren sich auf den neuesten Shard - klassisches Hot-Spot-Problem. |
| Geo-Sharding | Daten nach Kundengeografie geroutet. EU-Kunden auf EU-Shards, Nicht-EU-Kunden auf separaten Shards. | Reduziert Latenz; unterstützt DSGVO-Datenlokalisierungsanforderungen und BaFin-Vorschriften zur Datenhaltung im EWR. | Grenzüberschreitende Überweisungen erfordern shard-übergreifende Koordination. |
| Directory-basiert | Lookup-Tabelle ordnet jeden Key explizit einem Shard zu. Maximale Flexibilität bei der Platzierung. | Nützlich für VIP- oder Unternehmenskonten, die dedizierte Shards benötigen. | Das Directory selbst wird zum kritischen Single Point of Failure, wenn es nicht repliziert wird. |
Lese- und Schreibskalierung, Partitionierungsschlüssel und Hot-Spot-Vermeidung
Die Wahl des Shard-Keys ist die folgenreichste Entscheidung in einer gesplitteten Banking-Architektur. Ein schlechter Shard-Key erzeugt Hot Spots - Shards, die einen unverhältnismäßig großen Anteil des Traffics erhalten, während andere Shards im Leerlauf laufen. Der klassische Fehler ist das Sharding nach einem Feld mit geringer Kardinalität (Währung, Kontostatus, Land) anstatt nach einem Bezeichner mit hoher Kardinalität (Konto-ID, Kunden-ID, Transaktions-ID).
Praktische Richtlinien zur Shard-Key-Auswahl im Banking:
- account_id oder customer_id für Ledger-Daten verwenden - alle Buchungen eines Kontos bleiben auf demselben Shard, was Einzelkonto-Abfragen schnell und shard-intern hält.
- Sequentielle IDs aus einer einzigen Sequence als Shard-Key im Hash-Modus vermeiden - Consistent Hashing kompensiert dies, aber Auto-Increment-Ganzzahlen aus einem Generator konzentrieren Schreibvorgänge momentan. Stattdessen UUIDs v4 oder Snowflake-IDs verwenden.
- Shards vorab aufteilen, wenn die initiale Last bekannt ist - lieber mit mehr Shards als benötigt starten, als später neu zu sharden. Resharding eines Live-Hauptbuchs ohne Downtime ist eine der schwierigsten operativen Aufgaben im Fintech-Engineering.
- Referentielle Integrität auf Anwendungsebene sicherstellen - traditionelle Fremdschlüssel überschreiten keine Shard-Grenzen. Die Anwendung oder ein Saga-Koordinator muss Konsistenz zwischen Buchungen auf verschiedenen Shards für kontoübergreifende Überweisungen erzwingen.
Leseskalierung wird getrennt vom Schreib-Sharding gehandhabt. Lesereplikate auf jedem Shard bedienen Berichte, Saldoabfragen und Kontoauszugserzeugung, ohne mit Schreibtraffic zu konkurrieren. Das CQRS-Muster (Command Query Responsibility Segregation) ist verbreitet: Schreibvorgänge gehen an den gesplitteten OLTP-Cluster; lesende Abfragen für Berichte und Analysen gehen an ein separates Lesemodell oder ein Data Warehouse (BigQuery, Redshift, Snowflake), das via CDC-Pipelines befüllt wird.
Für shard-übergreifende Abfragen (z.B. "Zeige alle Transaktionen über 10.000 EUR über alle Konten für AML-Review") sind die Optionen: Fan-out der Abfrage auf alle Shards und Zusammenführung der Ergebnisse in der Anwendungsschicht, Pflege eines shard-übergreifenden materialisierten Index via Event Streaming, oder Weiterleitung solcher Abfragen an das Data Warehouse. Die meisten Produktionssysteme nutzen alle drei Methoden je nach Abfragetyp und Latenztoleranz.
Backup, Auditpfad und regulatorische Datenhaltung
In Deutschland regeln die GoBD (Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form) die Aufbewahrungspflichten für steuerlich relevante Finanzdaten: zehn Jahre für Handelsbücher und Belege, sechs Jahre für Handels- und Geschäftsbriefe. BaFin-regulierte Institute müssen zudem die MaRisk-Anforderungen an die Datenhaltung und das Auslagerungsmanagement erfüllen. Das Datenbankdesign muss diese Anforderungen von Anfang an berücksichtigen.
| Anforderung | Umsetzungsansatz |
|---|---|
| Unveränderlicher Auditpfad (GoBD) | Append-only-Hauptbuchtabellen. Datenbank-Trigger oder Anwendungslogik verhindern UPDATE/DELETE auf gebuchten Zeilen. Auditereignisse werden in ein separates Append-only-Protokoll geschrieben (eigenes Schema oder Streaming-Sink wie Kafka). |
| Regulatorische Aufbewahrung (6-10 Jahre) | Transaktionstabellen nach Monat oder Quartal partitionieren. Ältere Partitionen werden auf günstigere Cold Storage (Object Store, Archivierungsstufe) verschoben und bleiben über partitionierte Views oder föderierte Abfrage-Engines abfragbar. |
| Backup und Wiederherstellung | Point-in-Time Recovery (PITR) über WAL-Archivierung. Minimum: tägliches Vollbackup und kontinuierliches WAL-Streaming. Quartalsweise Wiederherstellungstests. RTO und RPO im Business-Continuity-Plan dokumentiert. |
| Datenmaskierung und DSGVO | Personenbezogene Daten auf Anwendungsebene verschlüsseln (AES-256) vor dem Schreiben in die DB. Daten in Nicht-Produktionsumgebungen maskieren. Spaltenverschlüsselung für besonders sensible Felder (IBAN, Kartennummern). Recht auf Vergessenwerden über logisches Löschen (Pseudonymisierung) umsetzen. |
| Zugangskontrolle (MaRisk) | Row-Level Security (PostgreSQL RLS) stellt sicher, dass Anwendungsrollen nur auf Daten ihres eigenen Mandanten zugreifen. Separate Nur-Lese-Rollen für Reporting. DBA-Zugriff protokolliert und zeitlich begrenzt. |
Die Unveränderlichkeitsregel vereinfacht auch Compliance-Prüfungen erheblich. Wenn BaFin-Prüfer oder interne Revision fragen "Zeigen Sie alle Transaktionen über Konto X zwischen Datum A und B", ist die Antwort eine einfache Abfrage gegen die Buchungstabelle - keine Rekonstruktion aus Logs, keine Sorge, dass Zeilen bearbeitet wurden. Diese Einfachheit rechtfertigt die Designdisziplin des append-only Hauptbuchs von Anfang an.
Wie Crassula passt
Die White-Label-Banking-Plattform von Crassula ist auf diesen Prinzipien aufgebaut. Das Hauptbuch ist append-only, doppelt buchend und ACID-konform. Kontosalden werden transaktional geführt und gegen das Buchungsprotokoll abgestimmt. Auditpfade werden in einem unveränderlichen Ereignisspeicher gespeichert und stehen für regulatorische Prüfungen auf Anfrage zur Verfügung.
Für Kunden, die neue Banking- oder Zahlungsprodukte auf den deutschen oder europäischen Markt bringen, entfällt mit Crassula die Notwendigkeit, diese Infrastruktur von Grund auf zu entwerfen und aufzubauen. Die Datenschicht, die Abstimmungsmaschine, die Partitionierungs- und Aufbewahrungsrichtlinien nach GoBD und MaRisk sind alle in der Plattform enthalten.
Wenn Sie die Datenbankarchitektur für einen Kernbanking-Aufbau evaluieren oder prüfen, ob eine White-Label-Plattform für Ihre Transaktionsvolumina und Compliance-Anforderungen geeignet ist, steht das Crassula-Team für ein technisches Gespräch zur Verfügung.
FAQ
Beginnen Sie mit dem Hauptbuch als einziger Wahrheitsquelle. Definieren Sie Ihre Kernentitäten - Kunde, Konto, Buchungsposten, Transaktion und Produkt - mit klarer Trennung zwischen ihnen. Verwenden Sie DECIMAL oder NUMERIC für alle Geldspalten. Machen Sie die Buchungstabelle von Anfang an append-only: Korrekturen erscheinen als neue Stornobuchungen, niemals als Updates bestehender Zeilen. Erzwingen Sie ACID-Transaktionen auf Datenbankebene für jede Geldbewegung. Trennen Sie Ihren Schreibpfad (OLTP) vom Reporting-/Analysepfad. Bauen Sie Aufbewahrungspartitionierung nach GoBD von Anfang an ein.
Doppelte Buchführung bedeutet, dass jede Geldbewegung zwei Hauptbucheinträge erzeugt - eine Belastung auf einem Konto und eine Gutschrift auf einem anderen für denselben Betrag. Die Summe aller Einträge ist stets null, was es unmöglich macht, dass Geld unbemerkt erscheint oder verschwindet.
Event Sourcing erweitert dies, indem das geordnete Ereignisprotokoll (jeder Buchungsposten) als autoritativer Datensatz gespeichert wird, mit Salden, die durch Summation ermittelt werden statt als veränderbare Felder. Die Kombination ergibt einen natürlichen Auditpfad, der die GoBD-Unveränderlichkeitsanforderungen erfüllt, und ermöglicht Zeitreisenabfragen sowie regulatorische Berichterstattung ohne zusätzliche Infrastruktur.
Sharding ist horizontale Partitionierung: Verteilung von Zeilen auf mehrere unabhängige Datenbankknoten, sodass jeder Knoten nur einen Bruchteil der Daten hält. Eine Routing-Schicht (Shard-Map) leitet jede Abfrage an den richtigen Knoten weiter.
Im Banking braucht man Sharding, wenn ein einzelner Datenbankknoten den Peak-Schreibdurchsatz nicht mehr verarbeiten kann oder wenn das Datenvolumen einzelne Knoten überfordert. Ein gut abgestimmter PostgreSQL-Knoten verarbeitet grob 10.000-30.000 Transaktionen pro Sekunde. Bei höheren Volumen, oder wenn geografisch verteilte Datenhaltung für DSGVO oder BaFin-Anforderungen notwendig ist, wird Sharding zur Standardlösung.
Der Shard-Key muss hohe Kardinalität aufweisen - genug unterschiedliche Werte, um Daten gleichmäßig über alle Shards zu verteilen. Für ein Banking-Hauptbuch sind account_id oder customer_id die natürliche Wahl: alle Buchungen eines Kontos landen auf demselben Shard, was Einzelkonto-Abfragen schnell macht und keine shard-übergreifenden Joins erfordert.
Vermeiden Sie Sharding nach Feldern mit geringer Kardinalität (Währung, Land, Status) - sie erzeugen Hot Spots. Verwenden Sie keine sequentiellen Auto-Increment-Ganzzahlen als Shard-Key bei hohem Kontoerstellungsvolumen; setzen Sie stattdessen UUIDs v4 oder Snowflake-IDs ein. Planen Sie Ihre Shard-Anzahl großzügig beim Launch - Resharding eines Live-Hauptbuchs ohne Downtime ist eine der schwierigsten operativen Aufgaben.
Innerhalb eines einzelnen Shards erhalten Standard-ACID-Datenbanktransaktionen die Konsistenz. Das schwierige Problem sind shard-übergreifende Transaktionen - beispielsweise eine Überweisung zwischen zwei Konten auf verschiedenen Shards.
Die Standardansätze sind: das Saga-Muster (eine Abfolge lokaler Transaktionen, koordiniert durch einen Saga-Orchestrator oder Choreografie via Ereignisse, mit kompensierenden Transaktionen für Rollbacks), und Two-Phase Commit (2PC) knotenübergreifend (selten bei Hochdurchsatzsystemen wegen Latenz- und Koordinator-Ausfallrisiko). Die meisten Produktions-Fintech-Hauptbücher verwenden Sagas, mit einem Idempotenzschlüssel auf jeder Operation, sodass Wiederholungen nach einem Teilfehler sicher sind.
Weitere Leitfäden
Erstellen Sie eine digitale Bank in nur wenigen Tagen
Demo anfordern