Microservices, AWS & CQRS: Das neue Kernbanksystem der Solarisbank – die technischen Hintergründe

Die Solarisbank hat ein neues Kernbanksystem. Mit Microservices auf AWS. Ein hochmoderner, skalierbarer und flexibler Eigenbau. Und migriert wurden die Kunden auch schon – vom PASS-Kernbankensystem auf die Eigenentwicklung, deren Ursprung schon im Jahr 2017 lag. Die Hintergründe.

Gestern meldete die Solarisbank den Vollzug (Pressemitteilung). Nicht nur, dass man erfolgreich das System in der AWS-Cloud in Betrieb genommen habe, sondern auch den letzten Schritt der Migration aller Kunden am vorigen Wochenende. Nicht alles auf einmal, sondern die Migration erfolgte schrittweise in diesem Jahr und wurde am vergangenen Wochenende ohne Downtime abgeschlossen.

Die neue Kernbanksystem-Infrastruktur der Solarisbank ist vollkommen modular aufgebaut, um die sehr spezifischen Anforderungen eines Banking-as-a-Service-Anbieters zu erfüllen. Die Kernkomponenten sind:

• ein selbstgebautes Customer-Account-Subledger-System für Zahlungskonten und Einlagen, welches auch alle Zahlungsverkehrsfunktionalitäten vollständig abbildet
• Mambu als ledger-layer ausschließlich für das Kreditgeschäft, angebunden an die Zahlungsverkehrsfunktionalitäten der eigenen Schicht
• Vergleichsweise mächtige „Prozess-Schichten“ rund um diese Komponenten zur Orchestrierung aller Prozesse in Richtung der Solarisbank-Partner und Endkunden
• Selbst entwickelte „Data Platform“ als zentrales „Scharnier“ aus der Realtime-Welt (siehe vorhergehende Punkte) in die „Reporting-Welt“ (siehe unten)
• SAP als „dünnes“ Hauptbuch (local GAAPs und IFRS)
• WoltersKluwer OneSumX als Meldewesensschicht

Bemerkenswert ist, dass die Entwickler das gesamte System “from scratch” selbst entwickelt und umgesetzt haben. Es gab kein KBS, auf dem aufgesetzt wurde. Damit  gibt es auch keine unbekannten Code-Teile. Auch die Gesamtarchitektur wurde selbst entwickelt. Allerdings will die Solarisbank nicht verraten, wie viele Mannstunden das Projekt verschlungen hat. Zugegeben: Es dürfte auch kaum mehr herauszufinden sein.

Der Betrieb unseres eigenen Kernbankensystems ermöglicht es uns, allen unseren Partnern bessere Service Level Agreements anzubieten und gibt uns die volle Kontrolle über unsere Leistung. Ich bin unglaublich stolz auf das, was unsere Produkt- und Tech-Teams erreicht haben. Die schnelle Umsetzung des Projekts und vor allem die reibungslose Migration verdeutlichen die Professionalität und das tiefe Know-how der Tech-Organisation der Solarisbank.”

Dr. Jörg Howein, CPO der Solarisbank

Warum? Welche Funktionen haben gefehlt, wo musste erweitert werden?

Viele Kernbanksysteme sind sehr „Hauptbuch-lastig“ und bilden nur innerste Kernprozesse ab. Ein digitales Banking braucht aber volle oder zumindest weitgehende Digitalisierung in ganz vielen Prozessen, die weit über die Kernbanksystem-Funktionalitäten hinausgehen, erklärt die Bank auf unsere Nachfrage. Die Solarisbank habe über die letzten Jahre erheblich in diese „Prozess-Schichten“ inkl. aller Orchestrierungen und API-Endpunkte investiert. Aus Sicht der Solarisbank seien diese „Schichten oberhalb des Kernbanksystems“ deutlich wichtiger für den Erfolg im Banking-as-s-Service-Geschäft.  

Performance & Skalierbarkeit sind das Wichtigste

Sehr stolz sind die Entwickler-Teams auf die Architektur und damit Performance und Skalierbarkeit des „inneren Kernes“ des Customer-Account-Ledgers inkl. der Payment-Engine. Besonders schick: Es handelt sich um eine Event-Sourcing basierte Architektur, die sich für die Datenbank-Abfragen die Vorteile von CQRS-Prinzipien (Command-Query-Responsibility-Segregation) zu eigen macht. Damit schafft sich die Bank höchste Skalierbarkeit und „integrierte Audit-logs“ in einer nativen Cloud-Architektur.

Qualitätssicherung erfolgt weitestgehend durch automatisierte Tests (auf Unit, Integrations und End-to-End-Ebene) auf mehreren Umgebungen vor der Produktionsumgebung. Grundsätzlich stellt moderne Softwareentwicklung, wenn durch grundlegende Automatisierungen insbesondere in CI/CD-Prozessen verankert und auf Microservices aufgebaut, auf mehreren Ebenen hervorragende Möglichkeiten zur Qualitätssicherung zur Verfügung.

Erste Ideen für das neue Kernbanksystem wurden bereits 2017 diskutiert, aber das eigentliche Projekt mit entsprechenden Ressourcen dann 2018 gestartet. Programmiert wurde es sukzessive über die letzten zwei Jahre. Eine wichtige für den Erfolg entscheidende Vorgehensweise war der „langsame und systematische Start“ dieses Projektes basierend auf konkreten Erfahrungen aus dem Produktionsbetrieb eines Banking-as-a-Service-Anbieters.

Knackpunkt DSGVO vs. US-Cloud-Act und FISA

Ein schwelendes Problem aller Cloud-Nutzer von AWS, Cloudflare über Google bis Microsoft & Co. ist die Frage des Datenschutzes – seit dem scheitern des Privacy-Shields (endgültig im Juli 2020, Wikipedia). Die Solarisbank gibt sich in dem Punkt enorme Mühe, es (so gut es geht) regulierungskonform zu lösen: Vertragspartner der Bank ist die AWS EU-Tochtergesellschaft Amazon Web Services EMEA SARL mit der vertraglich vereinbart sei, dass alle Daten nur in der EU verarbeitet werden. Alle Daten sind selbstverständlich verschlüsselt. Zudem gibt es weitergehende vertragliche Vereinbarungen mit AWS – insb. sich gegen Datenherausgaben basierend auf dem US Cloud Act rechtlich zu wehren. Ferner verweist die Bank auf das AWS-GDPR-Addendum sowie dessen Erweiterung. Amazon informiert außerdem transparent über alle Anfragen auf Basis des Cloud Act was zur Bewertung der faktischen Risikosituation herangezogen werden sollte. Hauptstandort ist Frankfurt, dort betreibt AWS drei Rechenzentren mit eingebautem Failover.

Von PASS zur Eigenentwicklung

Die Solarisbank hatte seit Gründung das Kernbankensystem von PASS im Einsatz. Mit dem System war die Bank durchaus sehr zufrieden, da es vor allem in der Anfangszeit sehr geholfen habe, moderne APIs zur Integration von Finanzdienstleistungen entwickeln zu können. Dennoch hat sich das Entwickler-Team schon 2017 mit der Frage auseinandergesetzt, inwiefern der Aufbau eines eigenen Kernbankensystems sinnvoll ist. Zum einen ging es um die Abhängigkeit von einem tiefintegrierten Anbieter und natürlich auch um die Frage, wie kann die Bank ihre Plattform international skalieren bei möglichst geringen Grenzkosten. Deshalb hat die Bank schließlich mit der aufwändigen Entwicklungsarbeit begonnen. Die Migration war also eine Frage der Zeit – keine der Zufriedenheit, wie der Sprecher der Bank betont. Einen weiterführenden Blog-Beitrag zu dem Thema gibt es hier von Tristan Holl, der die Gründe und Reise sehr gut beschreibt.aj