Cloud vs. FI-TS: Der Richtungsstreit im deutschen Bankenumfeld
1. Zwei Welten treffen aufeinander
Auf der einen Seite stehen die Hyperscaler: Amazon Web Services (AWS), Microsoft Azure und Google Cloud. Sie locken mit globaler Skalierbarkeit, Innovation und agilen Entwicklungsmethoden. Auf der anderen Seite ist FI-TS (Finanz Informatik Technologie Service) als etablierter, spezialisierter Anbieter für die Finanzwirtschaft positioniert, der als Tochterunternehmen der Finanz Informatik und Teil der Sparkassen-Finanzgruppe agiert und private und öffentliche Banken, Versicherungen und Finanzdienstleister mit standardisierten IT-Dienstleistungen unterstützt. Der IT-Dienstleister beschäftigt rund 1.000 Mitarbeiter - in Haar bei München sowie den Standorten Hannover, Offenbach, Nürnberg und Stuttgart und erzielt einen Umsatz von 400 Millionen Euro (01/2021).
Vertreter einer hybriden Strategie sehen beide Welten nicht als Gegensatz, sondern als Ergänzung: „Wir setzen auf ein Hybrid Cloud Modell: AWS nutzen wir für Test und Entwicklung, im Produktionsumfeld setzen wir auf FI-TS. Hier nutzen wir die Cloud-Infrastruktur, die die FI-TS aufgebaut hat, sie wird Financial Cloud Native genannt“.
2. FI-TS: Der „eingebaute“ Cloud-Anbieter der deutschen Banken? („Die Spezialisten aus Haar“)
Die Finanz Informatik Technologie Service (FI-TS) ist kein unbekannter Newcomer, sondern ein etablierter IT-Partner der Finanzwirtschaft. Sie ging aus der Sparkassen-Organisation hervor und ist daher tief in den regulatorischen und sicherheitstechnischen Anforderungen der Branche verwurzelt. FI-TS bezeichnet sich selbst als größter IT-Dienstleister für Landesbanken und unterstützt Institute mit einer integrierenden IT Service-Plattform vom klassischen Rechenzentrumsbetrieb bis hin zu Public Cloud-Produkten, Compliance und Beratung. Das Motto lautet: „Your Bridge to Digitalization“.
2.1 Finance Cloud Native (FCN) – Die eigene Cloud-Plattform
Kernelement des Angebots ist die „Financial Cloud Native“ (FCN), die seit 2018 kontinuierlich weiterentwickelt wird. Die FCN setzt auf Container-Technologien, um agile Arbeitsmethoden und DevOps-Prinzipien zu fördern und Microservices effizient skalieren zu können. FI-TS Finance Cloud Public Integration, als dritte Säule einer 3-Säulen-Strategie, beinhaltet zusätzlich die Integration der großen Public-Cloud-Anbieter in das digitale FI-TS Ökosystem. FI-TS ermöglicht Kunden einen bedarfsgerechten Einsatz von Cloud-Technologien und berücksichtigt dabei die aktuellen aufsichtsrechtlichen Anforderungen der Finanzwirtschaft.
2.2 Zielgruppe und Referenzen
Zum Kundenkreis von FI-TS zählen große Namen der Branche, darunter: LBBW, BayernLB, Helaba, DekaBank, Versicherungskammer Bayern, Provinzial Nord-West, Deutsche Kreditbank, quirin bank sowie die dwpbank. Das Unternehmen bedient damit vor allem Institute, die Wert auf regulatorische Konformität und hohe Sicherheitsstandards legen. Die dwpbank hat FI-TS als Single-Sourcing-Provider für ihre gesamte IT-Infrastruktur ausgewählt.
3. Direktvergleich: Hyperscaler vs. FI-TS
| Kriterium | Hyperscaler (AWS, Azure, GCP) | FI-TS |
|---|---|---|
| Sicherheit & Compliance | Umfangreiche Zertifikate (SOC, PCI-DSS, ISO). Aber: Hintergrund der Mutterkonzerne kann rechtliche Fragen aufwerfen (z.B. CLOUD Act). Möglichkeit der Dateneingrenzung auf EU/Deutschland mittels Azure . | ➜Bankenspezifisch ausgelegt, BaFin-prüffähig. Rechenzentren in Deutschland, maßgeschneidert für MaRisk/BAIT. „IT made for banking and insurance“. |
| Skalierbarkeit & Agilität | ➜Sehr hoch. Nahezu unbegrenzte Ressourcen und Services, ideal für moderne DevOps-Pipelines. Entwickler schätzen die hohe Benutzerfreundlichkeit und API-Dichte. | Begrenzter als bei Hyperscalern – es kann zu Einschränkungen bei Geschwindigkeit und Flexibilität kommen, besonders wenn es um die neuesten, innovativen Services geht. |
| Regulatorische Herausforderungen | Hürden durch BaFin/EU (DORA), komplexes Auslagerungsmanagement notwendig, Sub-Auslagerungsketten oft intransparent. | ➜Geringer. FI-TS als „verlängerter Arm“ der Bank. Komplexe Auslagerungsverträge mit bekannten Partnern, die die Aufsicht akzeptiert, da Teil der Sparkassen-Finanzgruppe. |
| Vendor-Lock-in & Unabhängigkeit | ➜Hohes Risiko. Proprietäre APIs und Tools können den Wechsel erschweren und sehr teuer machen. Anbieterunabhängigkeit ist nur mit strategischem Aufwand möglich. | Geringeres Risiko durch bekannte und vertraglich abgesicherte Partner. Auch FI-TS versucht, eine möglichst große Anbieterunabhängigkeit zu gewährleisten, und zwingt zur agnostischen Entwicklung. |
| Kosten | Pay-per-Use, sehr attraktiv für variable Workloads (Entwicklung, Test). Langfristig und bei konstanter Auslastung können die Kosten jedoch höher sein als bei dedizierten On-Premises-Lösungen. | Meist fixe, langfristige Verträge. Wirtschaftlich gesehen vorteilhaft für konstante, planbare Produktionslasten. Größere Institute können Skaleneffekte besser nutzen. |
| Eignung für Workloads | ➜Test, Entwicklung, nicht-kritische Anwendungen (viele Banken trennen strikt: kritische Workloads bleiben on-premises). | ➜Produktionsumfeld, kritische Kernbankensysteme (z.B. Kernbanken, Wertpapierabwicklung). Für viele Institute aktuell die erste Wahl für sicherheitsrelevante Produktivlasten. |
4. Fallstudien aus der Praxis: Wie Banken die Entscheidung treffen
4.1 dwpbank: Kritische Workloads auf FI-TS, Tests in AWS
Die Deutsche WertpapierService Bank (dwpbank) führt ein ambitioniertes Transformationsprogramm durch – die Ablösung ihrer Mainframe-Komponenten und die Modernisierung auf eine cloudnative Plattform. Für den hochverfügbaren Produktivbetrieb der Kernanwendungen vertraut die dwpbank auf die FI-TS Finance Cloud Native (FCN). Für Entwicklung und Testumgebungen nutzt sie dagegen punktuell AWS. Die strikte Trennung unterstreicht, dass selbst große, technologisch affine Institute ihre sicherheitsrelevanten Produktivsysteme nicht ohne Weiteres in die Public Cloud verlagern.
4.2 Sparkassen-Finanzgruppe: Auf dem Weg zu FI-TS als strategischem Rückgrat
Als Teil der Sparkassen-Finanzgruppe fungiert FI-TS hier als natürlicher, bevorzugter IT-Partner. Die Institute können auf eine standardisierte, compliance-geprüfte Plattform zugreifen, ohne jede Auslagerungsbeziehung neu verhandeln zu müssen. Die große Integrationsdichte und der Verbundcharakter fördern Skaleneffekte. Diese Positionierung zeigt, wie stark die kulturelle und regulatorische Verwurzelung bei der Wahl des Anbieters wiegt.
5. Die regulatorische Zwickmühle: MaRisk, BAIT und DORA
Die aufsichtlichen Anforderungen sind der größte Unterschied zwischen Public Cloud und FI-TS. Die BaFin und die EZB haben ein komplexes Netzwerk an Regeln geknüpft, die bei Auslagerungen kritischer Funktionen an externe Dienstleister beachtet werden müssen. Mit den DORA-Vorgaben entfällt der bisherige Auslagerungsbegriff gemäß MaRisk bzw. BAIT – DORA unterscheidet nicht mehr nach wesentlichen bzw. nicht wesentlichen Auslagerungen, sondern fasst den Begriff des IKT-Dienstleisters deutlich weiter. Die BaFin-MaRisk (AT 9) verlangt eine Risikoanalyse, einen detaillierten Auslagerungsvertrag und die jederzeitige Kontrollmöglichkeit für die Bank. Bei einer Public-Cloud-Migration mit einem Hyperscaler ist dieses Auslagerungsmanagement extrem aufwendig, weil:
- die Sub-Auslagerungskette (Rechenzentrum → Subunternehmer) kaum vollständig transparent gemacht wird.
- die US-amerikanische Gesetzgebung (CLOUD Act) im Konfliktfall Zugriffe auf deutsche Daten erzwingen könnte.
- die komplexen Vereinbarungen zwischen Bank und Cloud-Anbieter nur schwer von der Aufsicht geprüft werden können.
FI-TS hingegen genießt einen Vertrauensvorsprung: Der Anbieter ist bekannt, seine Rechenzentren sind in Deutschland, seine Prozesse sind BaFin-geprüft und die vertraglichen Beziehungen sind langjährig etabliert. Dies erleichtert einer Bank den Nachweis der aufsichtsrechtlichen Anforderungen erheblich.
6. Entscheidungshilfe: 5 Schritte zur richtigen Strategie
- Workload klassifizieren: Was ist kritisch (Kernbankensystem) und was ist weniger kritisch (Entwicklung, Test, Reporting)?
- Regulatorische Analyse: Kann die aufsichtliche Anforderung an die IT (BAIT, MaRisk, DORA) mit dem gewählten Cloud-Modell erfüllt werden? Ist eine Vorabanzeige oder Genehmigung erforderlich?
- Risikobewertung für Auslagerung: Wie sieht der Auslagerungsvertrag aus? Sind Sub-Auslagerungen transparent? Kann die Bank die jederzeitige Kontrolle ausüben?
- Test- und Entwicklungs-Cloud im Hyperscaler: Für agile, nicht-produktive Workloads eignen sich Hyperscaler ideal. Erste Erfahrungen können gesammelt, Kompetenzen aufgebaut werden.
- Produktionsumgebung im FI-TS: Hochrelevante Workloads sollten vorerst bei FI-TS oder in lokalen Rechenzentren verbleiben, bis die regulatorischen und sicherheitstechnischen Bedenken bei Hyperscalern vollständig ausgeräumt sind.
7. Fazit: Königsweg Hybrid – 80/20-Regel als strategische Leitplanke
Die Auseinandersetzung „Cloud vs. FI-TS“ ist für die große Masse der deutschen Banken bis heute zugunsten des spezialisierten Anbieters entschieden – zumindest im Produktivbetrieb ihrer sicherheitsrelevanten Workloads. Hyperscaler beherrschen das Test- und Entwicklungsumfeld, FI-TS den produktiven Kern. Die Praxis zeigt jedoch, dass eine hybride Strategie der erfolgversprechendste Weg ist: kritische, hochregulierte Workloads verbleiben auf der FI-TS-Plattform (oder on-premises), während weniger sensible, innovative Anwendungen die Vorteile der Hyperscaler nutzen.
Folgende 80/20-Regel bewährt sich in vielen Instituten: 80 Prozent der kritischen Workloads (Kernbanken, Zahlungsverkehr, Wertpapierabwicklung) laufen bei FI-TS, während 20 Prozent (Entwicklungsumgebungen, Analysesysteme, nicht-regulierte Prozesse) die Agilität der Hyperscaler ausschöpfen. Diese Aufteilung nutzt die Stärken beider Welten – Sicherheit und Compliance von FI-TS, Innovation und Skalierbarkeit von AWS, Azure. Der regulatorische Druck (DORA, BaFin) wird diese Verteilung langfristig beeinflussen. Eine klare, gut dokumentierte Übergangs- und Exit-Strategie ist der Schlüssel für eine erfolgreiche Cloud-Transformation im Bankenumfeld.