Multi-Tenancy in Banking-SaaS: Architekturmuster und typische Fehler
Ein praxisnaher Leitfaden zur Multi-Tenancy-Architektur für Banking-SaaS-Plattformen: Silo-, Pool- und Bridge-Modelle, DB-Isolierung, Datentrennung, Noisy-Neighbour-Risiken, BaFin-BAIT-, DORA- und DSGVO-Konformität sowie häufige Anti-Patterns - mit Einblick in die Umsetzung bei Crassula.
Was Multi-Tenancy im Banking-SaaS bedeutet
Eine Multi-Tenant-Architektur bedeutet, dass eine einzige laufende Anwendungsinstanz mehrere unabhängige Kunden - Tenants - auf gemeinsamer Infrastruktur bedient. Jeder Tenant erhält seinen eigenen logischen Bereich: eigene Konten, eigene Konfiguration, eigene Daten. Nichts davon gelangt in den Bereich eines anderen Tenants. Der Plattformbetreiber pflegt eine einzige Codebasis statt eine Kopie pro Mandant.
Für gewöhnliche SaaS-Produkte ist Multi-Tenancy eine Standardentscheidung. Für eine Banking-SaaS-Plattform trägt sie ein anderes Gewicht. Die Tenants sind regulierte Unternehmen. Ihre Daten umfassen Transaktionsnachweise, personenbezogene Kundendaten, AML-Befunde und Ledger-Zustände. Eine Datenpanne zwischen Tenants ist kein Support-Ticket - sie ist ein regulatorischer Vorfall mit möglichen Sanktionen, Meldepflichten und Reputationsschäden, die das Geschäft eines Mandanten schließen können.
Warum Banken und E-Geld-Institute SaaS wählen
Schnellerer Markteintritt, geringere Investitionskosten, kein eigenes Infrastrukturteam und Zugang zu einer gepflegten Compliance-Schicht - ohne jedes Mal dieselbe technische Basis neu aufzubauen.
Die Isolierungsanforderung
Aufsichtsbehörden wie die BaFin und EBA-Leitlinien erwarten, dass Mandantendaten logisch oder physisch getrennt sind. Wie Sie das umsetzen, bestimmt alle weiteren Architekturentscheidungen.
Das Abwägungsspektrum
Mehr Isolierung kostet mehr im Betrieb. Mehr Sharing ist kostengünstiger, schränkt aber ein, welche Mandanten Sie bedienen können. Die richtige Wahl liegt je nach Kundenmix irgendwo dazwischen.
Im deutschen Markt ist die BaFin besonders präzise: Die Bankaufsichtlichen Anforderungen an die IT (BAIT), zuletzt aktualisiert und durch DORA ergänzt, verlangen von Instituten, dass ausgelagerte IT-Dienstleistungen - einschließlich Cloud-SaaS - nachweislich kontrolliert, revisionssicher und vom Dienstleister vertraglich abgesichert sind. Wer als SaaS-Anbieter deutsche Banken oder E-Geld-Institute bedient, muss diesen Nachweis ermöglichen.
Lassen Sie uns Ihr Projekt besprechen und herausfinden, wie wir Ihr Projekt auf den Weg bringen können. digitales Bankprodukt zusammen
Demo anfordernTenancy-Modelle: Silo, Pool und Bridge
Es gibt drei grundlegende Modelle. Die meisten Produktivplattformen im Banking landen bei einer Variante des dritten - aber das Verständnis aller drei macht die Abwägungen greifbar.
| Modell | Was es bedeutet | Isolierungsgrad | Betriebskosten | Geeignet für |
|---|---|---|---|---|
| Silo | Jeder Tenant erhält eine dedizierte Datenbank, einen eigenen Compute-Cluster oder einen vollständigen Stack. | Physisch - maximal | Hoch - skaliert linear mit der Mandantenzahl | Vollbanklizenzinhaber, große regulierte Fintechs mit Prüfanforderungen |
| Pool | Alle Tenants teilen dieselbe Datenbank und dasselbe Schema. Eine Tenant-ID-Spalte in jeder Tabelle filtert Zeilen. | Logisch - am niedrigsten | Niedrig - am effizientesten | Risikoarme SaaS-Produkte; für Banking ohne zusätzliche Kontrollen weniger geeignet |
| Bridge | Gemeinsame Anwendungsschicht, aber getrennte Schemata oder dedizierte DB-Cluster je Mandantenklasse. Premium-Tenants erhalten mehr Isolierung. | Gemischt - per Tier konfigurierbar | Mittel - gemeinsamer Overhead, gestaffelte Ressourcenkosten | Die meisten Banking-Plattformen mit gemischtem Kundenstamm |
DB-per-Tenant vs. gemeinsames Schema ist eine verwandte, aber eigenständige Frage. Bei DB-per-Tenant liegen die Daten jedes Mandanten in einer physisch getrennten Datenbank. Tenant-übergreifende Abfragen sind strukturell unmöglich. Migrationen erfordern einen rollierenden Deployment über N Datenbanken. Im gemeinsamen Schema sind alle Tabellen in einer Datenbank, Zeilen tragen eine Tenant-ID, und eine fehlende WHERE-Klausel ist der Unterschied zwischen einer korrekten Abfrage und einer Datenpanne.
Stärken von DB-per-Tenant
- Physische Isolierung erfüllt die meisten BaFin- und Wirtschaftsprüfungsanforderungen ohne zusätzliche Kontrollen
- Mandantendaten können in einer bestimmten Cloud-Region gespeichert werden - wichtig für DSGVO-Datenschutzanforderungen
- Eine Kompromittierung der Datenbank eines Tenants betrifft andere nicht
- Unabhängige Datensicherung und -wiederherstellung pro Mandant
Stärken des gemeinsamen Schemas
- Eine einzige Migration wird überall gleichzeitig eingespielt
- Infrastrukturkosten pro Mandant sinken deutlich bei Skalierung
- Mandanten-übergreifende Analysen (aggregiert, anonymisiert) sind einfacher umsetzbar
- Connection-Pool-Management ist im Betrieb deutlich einfacher
Die meisten reifen Banking-SaaS-Plattformen setzen heute auf einen Bridge-Ansatz: eine gemeinsame Anwendungsschicht, getrennte Schemata oder Datenbanken pro Mandant (oder Mandantenklasse) und ein Metadaten-Register, das jeden eingehenden Request der richtigen Datenquelle zuordnet. Die Anwendungsschicht fragt nie "alle Mandanten" ab - sie löst den Mandantenkontext aus dem Request-Token auf und leitet an genau eine Datenquelle weiter.
Datenisolierung und Sicherheit für regulierte Mandanten
Für eine Banking-Plattform ist Isolierung nicht nur eine Performance-Frage - sie ist eine Compliance-Anforderung. BaFin BAIT, EBA-Leitlinien zu Auslagerungsvereinbarungen, DORA und DSGVO erwarten, dass Daten eines regulierten Instituts nicht von einem anderen gelesen, verändert oder gelöscht werden können. Wie Sie das nachweisen, hängt vom gewählten Isolierungsmodell ab.
Row-Level Security (RLS)
Datenbankrichtlinien, die auf jede Abfrage Mandantenfilter anwenden - unabhängig davon, was die Anwendung sendet. Wenn ein Anwendungsfehler eine Abfrage ohne Tenant-ID-Filter sendet, gibt die Datenbank null Zeilen zurück statt Daten eines anderen Mandanten. RLS ist das Sicherheitsnetz unter einem gemeinsamen Schema.
Bring Your Own Key (BYOK)
Verschlüsselung ruhender Daten mit mandantenspezifischen Schlüsseln. Selbst auf gemeinsamer Infrastruktur können die verschlüsselten Daten eines Mandanten ohne dessen Schlüssel nicht gelesen werden. BYOK wird von regulierten Mandanten und von Aufsichtsbehörden in datenschutzsensiblen Jurisdiktionen zunehmend erwartet - auch im deutschen Bankenmarkt.
Mandantenkontext im IAM
Authentifizierungs-Tokens (JWT, OAuth) betten die Tenant-ID als Claim ein. Das API-Gateway validiert diesen Claim bei jedem Request und propagiert ihn durch die gesamte Aufrufkette. Ein Request ohne gültigen Mandanten-Claim wird abgelehnt, bevor er die Datenschicht erreicht.
Datenhaltung nach DSGVO
Die DSGVO verlangt, dass personenbezogene EU-Daten im EWR verbleiben. Eine Banking-SaaS-Plattform, die deutsche, spanische und französische Kunden bedient, muss nachweisen, dass die Daten jedes Mandanten in der richtigen Jurisdiktion gespeichert und verarbeitet werden. DB-per-Tenant in geografisch fixierten Cloud-Regionen ist die klarste Lösung.
DORA - seit Januar 2025 EU-weit verpflichtend - fügt eine IKT-Drittparteien-Risikodimension hinzu. Wenn Ihre Banking-SaaS-Plattform als kritischer IKT-Drittanbieter eingestuft wird, können die Aufsichtsbehörden Ihrer Mandanten direkte Prüfungen durchführen. Architekturdokumentation, Isolierungskontrollen und Incident-Response-Verfahren werden dabei zu Beweismitteln.
Im deutschen Kontext gilt zudem: BAIT-konforme Auslagerungsverträge müssen dem Anbieter klare Prüf- und Auskunftsrechte der BaFin und des Instituts einräumen. Das bedeutet, die Plattform muss in der Lage sein, mandantenspezifische Protokolle, Zugriffsnachweise und Isolierungsnachweise auf Anfrage zu liefern - nicht erst dann, wenn ein Vorfall eingetreten ist.
Noisy-Neighbour, Skalierung und Kostenabwägungen
Das Noisy-Neighbour-Problem entsteht, wenn der Workload eines Mandanten unverhältnismäßig viele gemeinsame Ressourcen beansprucht und die Performance aller anderen verschlechtert. Auf einer Banking-Plattform kann das Transaktionsverarbeitungsverzögerungen, langsamere Kontostandsabfragen oder API-Timeouts bedeuten - etwa während des Monatsabschluss-Abgleichlaufs eines großen Mandanten.
| Gegenmittel | Wie es funktioniert | Abwägung |
|---|---|---|
| Ressourcen-Quotas | CPU-, Arbeitsspeicher- und IOPS-Limits pro Mandanten-Container oder Datenbankverbindungspool | Begrenzt Peak-Performance für große Mandanten; erfordert Feinjustierung pro Tier |
| Rate Limiting | API-seitiges Request-Throttling pro Mandant, durchgesetzt am Gateway | Schützt gemeinsame Dienste, kann hochvolumige Mandanten ohne dedizierte Kapazität bremsen |
| Mandantenklassen-Routing | Premium-Mandanten werden auf dedizierte Hochleistungscluster geleitet; Standardmandanten teilen kostengünstige Pools | Erhöht Routing-Komplexität; Tier-Grenzen müssen vertraglich klar definiert sein |
| Async-Warteschlangen-Offloading | Batch-Operationen (Abstimmung, Kontoauszugserzeugung) gehen in eine separate Warteschlange, nicht auf den Echtzeit-API-Pfad | Erhöht Latenz bei Batch-Arbeit; Echtzeit-Antworten bleiben geschützt |
| DB-per-Tenant-Isolierung | Abfragen jedes Mandanten laufen gegen seine eigene Datenbank; kein gemeinsamer I/O | Eliminiert Noisy-Neighbour auf Datenbankebene, erhöht aber die Infrastrukturkosten |
Die praktische Erfahrung aus dem Betrieb von Banking-Plattformen: Dimensionieren Sie für den schwersten zu erwartenden Mandanten-Workload - nicht für den Durchschnitt. Ein einziger großer Mandant mit einem Monatsabschluss-Batch kann Datenbankengpässe aufdecken, die bei 10 % Auslastung unsichtbar waren. Kapazitätsplanung auf Basis des P99-Mandanten-Workloads statt des P50 verhindert die meisten Produktionsvorfälle.
Typische Fehler und Anti-Patterns
Die meisten Multi-Tenancy-Fehler im Banking-SaaS fallen in wenige wiederkehrende Muster. Sie früh zu erkennen ist günstiger als sie bei einem Live-Vorfall oder einer Aufsichtsprüfung zu entdecken.
Hinter all diesen Mustern steckt ein Meta-Muster: Isolierung als Nachgedanken zu behandeln. Multi-Tenancy-Designentscheidungen, die im ersten Sprint einer Plattform getroffen werden, sind sehr schwer rückgängig zu machen, sobald echte Mandanten an Bord sind. Die Kosten, Isolierung von Anfang an richtig umzusetzen, belaufen sich auf einige Wochen zusätzlicher Architekturarbeit. Die Kosten, sie nach einem Datenvorfall nachzurüsten, messen sich in Monaten der Remediation und möglichen aufsichtsrechtlichen Maßnahmen.
Wie Crassula Multi-Tenancy umsetzt
Crassula bedient über 150 regulierte Unternehmen - E-Geld-Institute, Zahlungsinstitute und Banklizenzinhaber - auf einer einzigen Plattform. Die Multi-Tenancy-Architektur spiegelt jahrelange Erfahrung mit echten Mandanten durch echte Aufsichtsprüfungen quer durch die EU wider.
Mandantendatentrennung
Die Finanzdaten jedes Crassula-Kunden sind innerhalb der Plattform logisch getrennt, wobei der Mandantenkontext auf jeder Ebene vom API-Gateway bis zur Datenschicht durchgesetzt wird. Mandantenübergreifender Datenzugriff ist strukturell verhindert - nicht nur durch Richtlinien.
Verschlüsselung und Schlüsselverwaltung
Ruhende und übertragene Daten sind verschlüsselt. Für Mandanten mit strengeren Schlüsselverwaltungsanforderungen - einschließlich Kunden in Jurisdiktionen mit BYOK-Erwartungen oder BAIT-Prüfanforderungen - sind mandantenspezifische Verschlüsselungskonfigurationen verfügbar.
DSGVO und Datenhaltung
Crassula verarbeitet Daten DSGVO-konform. Für Mandanten mit spezifischen Datenhaltungsanforderungen unterstützt die Plattform Konfigurationen, die mit den Erwartungen der EU-Aufsichtsbehörden und nationaler Aufseher - einschließlich BaFin-Anforderungen - übereinstimmen.
Audit-Trail
Jede Aktion wird mit Mandantenkontext, Nutzeridentität, Zeitstempel und IP protokolliert. Das Audit-Log ist unveränderbar und deckt den vollständigen Lebenszyklus jedes Finanzdatensatzes ab - erforderlich für AML, aufsichtsrechtliche Meldungen und mandantenseitige Compliance-Überprüfungen.
DORA-Bereitschaft
Als IKT-Dienstleister für regulierte Einheiten pflegt Crassula Dokumentation und Kontrollen, die mit den IKT-Drittparteien-Risikoanforderungen von DORA übereinstimmen und die eigenen DORA-Verpflichtungen der Mandanten unterstützen.
Skalierbar von Grund auf
Die Plattformarchitektur deckt eine breite Palette von Mandantengrößen ab - von frühen Fintechs bis zu etablierten Lizenzinhabern. Die Ressourcenzuteilung skaliert mit den Anforderungen des Kunden, ohne die Performance anderer Mandanten zu beeinträchtigen.
Wenn Sie Banking-SaaS-Plattformen evaluieren und verstehen möchten, wie Isolierung, Verschlüsselung und regulatorische Kontrollen implementiert sind - oder wenn Sie Ihre eigene Multi-Tenant-Architektur entwerfen und Ansätze vergleichen möchten - sprechen Sie mit unserem Team. Wir erläutern die Einzelheiten gerne.
FAQ
Multi-Tenancy bedeutet, dass eine einzige Banking-Plattform mehrere unabhängige Kunden (Mandanten) auf gemeinsamer Infrastruktur bedient - jeder mit eigenen Konten, eigener Konfiguration und eigenen Daten, ohne Überlappung. Für den Plattformbetreiber bedeutet das, eine einzige Codebasis statt eine Kopie pro Mandant zu pflegen. Für Kunden bedeutet es schnelleres Onboarding, niedrigere Kosten und eine kontinuierlich gewartete Compliance- und Sicherheitsschicht. Im Banking ist die entscheidende Anforderung, dass die Mandantendaten-Isolierung auf jeder Ebene durchgesetzt wird: API-Gateway, Anwendungslogik und Datenschicht.
Physische Isolierung (Silo-Modell, DB-per-Tenant) ist bei einer BaFin- oder Wirtschaftsprüferprüfung am besten verteidigbar, da mandantenübergreifender Datenzugriff strukturell unmöglich ist. Sie ist jedoch auch am teuersten im Betrieb. Die meisten regulierten Banking-SaaS-Plattformen setzen auf einen Bridge-Ansatz: gemeinsame Anwendungsinfrastruktur mit getrennten Schemata oder Datenbanken pro Mandant (oder Mandantenklasse) plus Row-Level Security als Datenbankebenen-Backstop. Das richtige Modell hängt von den regulatorischen Verpflichtungen Ihres Kundenstamms ab.
Die wichtigsten Mechanismen sind: (1) separate Datenbanken pro Mandant, sodass Abfragen physisch keine Grenzen überschreiten können; (2) Row-Level Security (RLS) auf Datenbankebene, die bei jeder Abfrage nach Tenant-ID filtert und Anwendungsfehler abfängt, bevor sie zu Datenpannen werden; (3) Tenant-ID in Authentifizierungs-Tokens (JWT Claims), validiert am API-Gateway und durch jeden Service-Aufruf propagiert; (4) mandantenspezifische Verschlüsselungsschlüssel über KMS oder HSM; (5) Netzwerksegmentierung auf Infrastrukturebene. Eine ausgereifte Banking-Plattform kombiniert alle fünf.
Die fünf häufigsten: (1) Mandantenlogik fest im Anwendungscode statt in einem zentralen Mandantenregister - neues Mandant hinzufügen erfordert Codeänderungen; (2) fehlende WHERE-Klauseln in Shared-Schema-Abfragen, die Daten mehrerer Mandanten zurückgeben; (3) Kapazitätsplanung auf Basis des Durchschnittsmandanten, obwohl ein oder zwei große Mandanten die tatsächliche Last dominieren; (4) gemeinsame Verschlüsselungsschlüssel für alle Mandanten - eine Kompromittierung betrifft alle; (5) Audit-Logs ohne Mandantenkontext, was regulatorische Überprüfungen unmöglich macht. Alle diese Muster sind in der Entwurfsphase weit günstiger zu beheben als nach einem Vorfall.
Ja, wenn es korrekt umgesetzt ist. BaFin BAIT, EBA-Leitlinien zu Auslagerungsvereinbarungen, DORA (verpflichtend seit Januar 2025) und die DSGVO verbieten Multi-Tenant-SaaS nicht. Sie verlangen jedoch, dass regulierte Institute Datenisolierung, Vollständigkeit des Audit-Trails, Zugriffskontrollen und operative Belastbarkeit nachweisen können - und dass Auslagerungsverträge der BaFin und dem Institut klare Prüf- und Auskunftsrechte einräumen. Eine gut konzipierte Multi-Tenant-Banking-Plattform erfüllt diese Anforderungen und kann die Nachweisdokumentation liefern, die BaFin-Prüfer erwarten.
Weitere Leitfäden
Erstellen Sie eine digitale Bank in nur wenigen Tagen
Demo anfordern