Digital-Banking-Architektur 2026: Schichten, Muster und Best Practices

Was ist Digital-Banking-Architektur?

Die Digital-Banking-Architektur ist der strukturelle Bauplan des Technologie-Stacks einer Bank. Sie beschreibt, wie die Systemschichten miteinander kommunizieren, wie Daten fließen, wie Dienste verpackt und bereitgestellt werden, und wie das Gesamtsystem unter Last verfügbar bleibt. Sie ist weder eine einzelne Anwendung noch eine Vendorplattform, sondern das übergreifende Design, das bestimmt, ob die Bank neue Produkte in Tagen oder in Quartalen einführen kann.

Das Standardmodell für eine moderne Digitalbank gliedert Funktionen in fünf logische Schichten. Jede Schicht hat eine klar definierte Aufgabe und kommuniziert mit benachbarten Schichten über sauber spezifizierte APIs oder Ereignisströme.

Die Kunst der Architektur liegt darin, jede Schicht auf ihre eigene Aufgabe zu konzentrieren und enge Kopplung über Schichtgrenzen hinweg zu minimieren. Die BaFin BAIT (Bankaufsichtliche Anforderungen an die IT) schreiben explizit eine klare Trennung von Anwendungskomponenten und Datenbeständen vor. Eine Bank, die Geschäftslogik in die Kanalschicht oder direkte Datenbankzugriffe aus dem Frontend zulässt, erfüllt diese Anforderungen nicht - und zahlt bei jeder Produktänderung den Preis dafür.

Schlüsselelemente und Best Practices

Sechs Designprinzipien trennen Banken, die schnell liefern können, von solchen, die es nicht können. Sie sind keine neuen Konzepte, aber 2026 sind sie Grundvoraussetzung für jede Institution, die ein digitales Bankprodukt einführt oder modernisiert.

Diese Prinzipien verstärken sich gegenseitig. API-first erleichtert die Durchsetzung von Fachdomänengrenzen. Event-getriebene Ansätze machen zustandslose Kanäle praktikabel. Cloud-natives Deployment gibt DevSecOps-Pipelines eine konsistente Zielumgebung. Banken, die alle sechs zusammen umsetzen, kürzen ihren Produktionsreleaszyklus typischerweise von quartalsweise auf wöchentlich oder sogar täglich. Deutsche Institute wie die DZ Bank und Deutsche Bank haben auf diesem Weg ihre Produkteinführungszeiten erheblich reduziert.

Mobile-Banking-Architektur im Detail

Mobile Banking hat eigene Architekturanforderungen, die sich von Web- oder Filialbanking unterscheiden. Der Client ist ein Gerät, das die Bank nicht kontrolliert, läuft in einem Netz, das die Bank nicht besitzt, und wird zu Zeiten und an Orten genutzt, die das Filialmodell nie kannte. Die Architektur muss das alles abfangen, ohne den Kunden damit zu belasten.

Native App vs. PWA. Native Apps (Swift für iOS, Kotlin für Android) geben den besten Zugriff auf Gerätefunktionen - Biometrie, Push-Tokens, hardwaregestützten Schlüsselspeicher, NFC für kontaktloses Bezahlen. Progressive Web Apps (PWAs) reduzieren den Distributionsaufwand und funktionieren plattformübergreifend, haben aber eingeschränkten Zugriff auf die Hardware-Sicherheitsschicht. Die meisten Banken mit nennenswertem Mobile-Volumen betreiben native Apps als Hauptkanal und eine PWA für Onboarding-Strecken oder seltenere Nutzerreisen.

Das Backend-for-Frontend-Muster (BFF). Anstatt die Mobile App direkt gegen zehn verschiedene Microservices zu schicken, steht ein BFF-Dienst zwischen App und Backend. Der BFF aggregiert die Daten für jede Ansicht, wendet mobilspezifische Transformationen an und liefert eine einzelne Antwort zurück. Das hält den Mobile-Client schlank und schnell und erlaubt es, Backend-Dienste zu ändern, ohne die App zu aktualisieren.

API-Sicherheit. OAuth 2.0 mit PKCE ist der Standard für mobile Autorisierungsflows. Mutual TLS (mTLS) fügt eine zweite Sicherungsschicht auf dem API-Kanal hinzu, indem die Client-App ein Zertifikat neben dem Bearer-Token präsentieren muss. Certificate Pinning in der App verhindert Man-in-the-Middle-Angriffe durch nicht vertrauenswürdige CAs. Die PSD2-Anforderungen an die Starke Kundenauthentifizierung (SCA) werden typischerweise über Push-Authentifizierung auf das registrierte Gerät umgesetzt - ein Muster, das die BaFin im Rahmen der BAIT-Anforderungen an sichere Authentifizierungsverfahren erwartet.

Push-Benachrichtigungen werden über APNs (Apple) und FCM (Google) zugestellt. Die entscheidende Designfrage ist, wo der Push ausgelöst wird: Bei sicherheitskritischen Ereignissen (Login von neuem Gerät, hohe Zahlung, Kartensperrung) muss der Auslöser aus dem Kern kommen, nicht vom Mobile-Client, damit die Benachrichtigung nicht durch eine kompromittierte App unterdrückt werden kann.

Offline-Resilienz. Eine Mobile App muss bei fehlendem Signal sauber funktionieren. Lesedaten (Transaktionen, Kontostand, Kartendetails) können lokal gecacht werden, müssen aber klar als möglicherweise veraltet gekennzeichnet sein. Schreibvorgänge (Zahlungsauslösung, Kartensperrung) müssen in einer Warteschlange landen und dürfen erst bestätigt werden, wenn das Backend sie akzeptiert hat. Einen gecachten Kontostand als Echtzeitstand anzuzeigen ist ein Compliance-Risiko - das GDPR-Prinzip der Datenrichtigkeit (Artikel 5 Abs. 1 lit. d) gilt auch hier.

API-first und Headless Banking

API-first ist eine Designphilosophie: Jede Banking-Funktion wird als API entworfen und veröffentlicht, bevor ein Frontend oder eine Integration gebaut wird. Die API ist das Produkt. Die Mobile App, das Webportal und Drittanbieterintegrationen sind sämtlich Konsumenten derselben API-Oberfläche.

Headless Banking geht einen Schritt weiter. Es entkoppelt die Banking-Engine (Hauptbuch, Zahlungen, Produktregeln, Compliance) vollständig von jeder Kanalschicht. Die Banking-Engine hat keine Meinung darüber, wie das Frontend aussieht, in welcher Sprache es läuft oder ob es eine Verbraucher-App oder ein B2B-Portal ist. Jedes Frontend, das eine API aufrufen kann, kann ein Banking-Frontend sein.

Die EU-Zahlungsdienstrichtlinie PSD2 und die damit verbundenen EBA-Regulatory Technical Standards haben das API-first-Prinzip auf regulatorische Ebene gehoben. Banken, die PSD2-Zugang für autorisierte Drittanbieter (TPPs) bereitstellen müssen, benötigen dafür dokumentierte, sichere APIs nach dem Berlin-Group-NextGenPSD2-Standard. Für Institute, die bereits API-first gebaut hatten, war Compliance ein Konfigurations- und Berechtigungsthema. Für Banken mit eng gekoppelten Systemen erzwang PSD2 eine Architekturkorrektur. In Deutschland betrifft das vor allem mittlere Privatbanken und Genossenschaftsbanken, die ihre API-Schicht nachrüsten mussten.

Sicherheit und Resilienz in der Architektur

Sicherheit und Resilienz sind Architekturmerkmale, keine nachgelagerten Features. Beide müssen von Anfang an eingebaut werden. Sie nachträglich hinzuzufügen erfordert eine Überarbeitung der Teile, die ohne sie gebaut wurden.

Zero-Trust. Das Zero-Trust-Modell geht davon aus, dass kein Netzwerk inhärent vertrauenswürdig ist - nicht einmal das interne Netz innerhalb des Rechenzentrums oder der Cloud-VPC der Bank. Jeder Dienst-zu-Dienst-Aufruf muss authentifiziert und autorisiert werden. Die Dienst-Identität wird über kurzlebige Zertifikate (mTLS) etabliert. Kein Dienst erhält implizites Vertrauen, weil er sich im selben Subnetz befindet. Die BaFin BAIT (Abschnitt AT 7.2) und die darauf aufbauenden MaRisk-Anforderungen fordern eine strikte Netzwerksegmentierung, die das Zero-Trust-Prinzip operationalisiert.

Defence-in-Depth. Sicherheitskontrollen existieren auf jeder Schicht: Netzwerk (WAF, DDoS-Schutz, Netzwerkrichtlinien), Identität (MFA, OAuth 2.0, mTLS), Anwendung (Eingabevalidierung, Output-Encoding, OWASP API Security Top 10), Daten (Verschlüsselung im Ruhezustand mit AES-256, in der Übertragung mit TLS 1.3, Schlüsselmanagement über HSMs oder Cloud-KMS). Wenn eine Kontrolle versagt, fängt die nächste den Angreifer ab.

Chaos Engineering. Resilienz wird durch kontrollierten Ausfall bewiesen. Chaos-Engineering-Tools unterbrechen gezielt Instanzen, fügen Netzwerklatenzen ein oder verwerfen Pakete in Vorproduktionsumgebungen oder in sorgfältig abgegrenzten Produktionsexperimenten. Unter dem Digital Operational Resilience Act (DORA), der seit Januar 2025 für alle EU-Finanzinstitute gilt, müssen Threat-Led Penetration Tests (TLPT) durchgeführt und operative Resilienz nachgewiesen werden. Für deutsche Institute konkretisiert die BaFin die DORA-Anforderungen in ihrer BAIT-Orientierungshilfe.

Datenschutz und Datenminimierung. Auf Architekturebene erfordert die DSGVO (Art. 25 - Datenschutz durch Technik) eine Privacy-by-Design-Haltung: Daten werden nur dort gespeichert, wo sie benötigt werden, nur so lange wie nötig aufbewahrt und über eine Policy-gesteuerte Datenschicht zugänglich gemacht. Für Banken in Deutschland bedeutet das, Kundendaten standardmäßig in europäischen Rechenzentren zu halten und alle Datentransfers in Drittländer explizit zu dokumentieren und abzusichern.

Von der Architektur zur Umsetzung

Architekturdiagramme sind nicht das Produkt. Das Produkt ist ein laufendes System, das echten Kunden dient. Die Lücke zwischen Architekturblueprint und Produktionssystem zu schließen erfordert, drei Domänen zu verbinden: das Core-Banking-System, die Microservices-Schicht und die Cloud-Infrastruktur.

Das Core-Banking-System ist das Hauptbuch und die Produkt-Engine - die Teile der Architektur, die den regulierten Zustand halten. Die Wahl des richtigen Kerns bestimmt, was in den Schichten darüber möglich ist. Ein Kern mit einer reichhaltigen, dokumentierten API (Mambu, Thought Machine Vault, Tuum, 10x Banking) lässt Sie die Erlebnis- und Integrationsschichten frei gestalten. Ein Legacy-Kern mit Batch-File-Schnittstellen schränkt alles darüber ein. Details zu Anbietern und Bereitstellungsmodellen finden Sie in unserem Core-Banking-Leitfaden.

Die Microservices-Schicht beherbergt die differenzierenden Fähigkeiten der Bank - Dienste, die nicht im Kern enthalten sind, aber das Produkterlebnis definieren: Onboarding-Strecken, Transaktionskategorisierung, Ausgabenanalysen, Rewards, Limitverwaltung, Benachrichtigungen. Diese Dienste sitzen zwischen Kern und Kanälen und sind der Ort, wo API-first- und Event-driven-Prinzipien die meiste Arbeit leisten. Weitere Architekturmuster und Abwägungen finden Sie in unserem Banking-Microservices-Leitfaden.

Die Cloud-Infrastruktur ist das Fundament, auf dem alles läuft. Cloud-natives Deployment (Container, Kubernetes, verwaltete Datenbanken, cloud-natives Event-Streaming) gibt der Architektur die Elastizität, Observabilität und Deployment-Geschwindigkeit, die die Designprinzipien voraussetzen. Regulatorische Anforderungen an Datensouveränität - insbesondere die DSGVO-Datenhaltungspflichten und die DORA-Anforderungen an Drittanbieterrisiko-Management - beeinflussen die Cloud-Strategie deutscher Institute erheblich. Weitere Details finden Sie in unserem Cloud-Banking-Leitfaden.

Crassula ist die Implementierungsschicht: die Orchestrierungs- und Produktplattform, die Konten, Karten, Zahlungen, KYC, Frontends und Backoffice in einem einzigen gebrandeten Produkt bündelt. Sie bringen die Lizenz (Bank, E-Geld-Institut, Zahlungsinstitut) mit oder verbinden sich mit einem unserer BaaS-Partner; Crassula liefert die Architektur. Die typische Zeit vom Vertragsabschluss bis zum Livegang liegt bei 4-12 Wochen. Sprechen Sie mit unserem Team, um Ihren Launch zu planen.

FAQ