Vergleich der IT-Strategien für Banken: Public Cloud Hyperscaler vs. spezialisierte Anbieter wie FI-TS
Die Frage, ob eine Bank ihre IT-Infrastruktur in die Public Cloud von AWS, Azure oder Google verlagern sollte oder besser auf spezialisierte Anbieter wie FI-TS setzt, bewegt die Branche seit Jahren. Hintergrund sind die hohen regulatorischen Anforderungen (MaRisk, BAIT, DORA), Sicherheitsbedenken und ein wachsendes Bewusstsein für digitale Souveränität.
Die beiden Welten im Überblick
☁️ Hyperscaler (AWS, Azure, Google Cloud)
- Vorteile: Globale Skalierbarkeit, Innovationskraft, agile Entwicklungsmethoden, riesiges Service-Ökosystem
- Nachteile: Komplexe regulatorische Compliance, Transparenzprobleme bei Sub-Auslagerungen, potenzielle Zugriffsrechte durch US-Gesetze (CLOUD Act)
🏦 FI-TS (Finanz Informatik Technologie Service)
- Vorteile: Bankenspezifische Compliance (BaFin-prüffähig), Rechenzentren in Deutschland, tiefe Branchenkenntnis, vereinfachtes Auslagerungsmanagement
- Nachteile: Geringere Skalierungsmöglichkeiten als bei Hyperscalern, potenziell weniger Innovationstempo bei neuesten Services
- Kennzahlen (Stand 01/2021): Rund 1.000 Mitarbeiter, Standorte in Haar, Hannover, Offenbach, Nürnberg und Stuttgart, Umsatz von 400 Mio. Euro
Finance Cloud Native (FCN) – Die Plattform von FI-TS
Das Kernelement des FI-TS-Angebots ist die seit 2018 entwickelte "Financial Cloud Native" (FCN). Sie basiert auf Container-Technologien (wie Docker/Kubernetes), um agile Arbeitsmethoden, DevOps-Prinzipien und die effiziente Skalierung von Microservices zu ermöglichen.
Direktvergleich: Hyperscaler vs. FI-TS
| Kriterium | Hyperscaler (AWS, Azure, GCP) | FI-TS |
|---|---|---|
| Sicherheit & Compliance | Umfangreiche Zertifikate (SOC, PCI-DSS, ISO). Aber: rechtliche Fragen durch CLOUD Act möglich. | Bankenspezifisch ausgelegt, BaFin-prüffähig, Rechenzentren in Deutschland, maßgeschneidert für MaRisk/BAIT. |
| Skalierbarkeit & Agilität | Sehr hoch. Nahezu unbegrenzte Ressourcen, ideal für DevOps und agile Entwicklung. | Begrenzter als bei Hyperscalern – Einschränkungen bei Geschwindigkeit und Flexibilität möglich. |
| Regulatorische Hürden | Hoch (DORA, BaFin). Komplexes Auslagerungsmanagement, Sub-Auslagerungsketten intransparent. | Geringer. FI-TS als „verlängerter Arm" der Bank. Komplexe Verträge mit bekannten Partnern, von der Aufsicht akzeptiert. |
| Vendor Lock-in | Hohes Risiko. Proprietäre APIs und Tools erschweren einen Wechsel. | Geringeres Risiko durch vertraglich abgesicherte Partner und Fokus auf anbieteragnostische Entwicklung. |
| Kosten | Pay-per-Use. Attraktiv für variable Workloads, aber langfristig bei konstanter Last teurer. | Feste, langfristige Verträge. Wirtschaftlich vorteilhaft für konstante, planbare Produktionslasten. |
| Workload-Eignung | Test, Entwicklung, nicht-kritische Anwendungen. Viele Banken trennen strikt. | Produktionsumfeld, kritische Kernbankensysteme (z.B. Kernbanken, Wertpapierabwicklung). |
Praxisbeispiele & Fallstudien
dwpbank: Kritische Workloads auf FI-TS, Tests in AWS
Die Deutsche WertpapierService Bank (dwpbank) modernisiert ihre Mainframe-Systeme auf eine cloudnative Plattform. Für den hochverfügbaren Produktivbetrieb der Kernanwendungen vertraut sie auf die FI-TS Finance Cloud Native (FCN). Für Entwicklung und Testumgebungen nutzt sie punktuell AWS. Dies zeigt, dass selbst große Institute ihre sicherheitsrelevanten Produktivsysteme nicht ohne Weiteres in die Public Cloud verlagern.
Sparkassen-Finanzgruppe: FI-TS als strategisches Rückgrat
Als Teil der Gruppe 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. Diese Positionierung zeigt, wie stark die kulturelle und regulatorische Verwurzelung bei der Wahl des Anbieters wiegt.
Die regulatorische Zwickmühle: MaRisk, BAIT und DORA
Die aufsichtlichen Anforderungen (BaFin, EZB) sind der größte Unterschied zwischen Public Cloud und FI-TS. Mit der DORA-Verordnung (Digital Operational Resilience Act), die seit Januar 2025 in Kraft ist, werden die Anforderungen an Hyperscaler weiter verschärft. Institute, die heute Public Cloud nutzen, müssen die neuen Regelungen vollständig umsetzen.
Wichtiger Hinweis: Mit DORA 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.
Regulatorische Hürden für Public Cloud im Detail:
- Intransparente Sub-Auslagerungsketten: Die Kette Rechenzentrum → Subunternehmer ist kaum vollständig nachvollziehbar.
- CLOUD Act: Die US-Gesetzgebung könnte im Konfliktfall Zugriffe auf deutsche Daten erzwingen.
- Komplexe Prüfung: Vereinbarungen zwischen Bank und Cloud-Anbieter sind für die Aufsicht nur schwer zu prüfen.
FI-TS 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.
Entscheidungshilfe: 5 Schritte zur richtigen Strategie
Die Wahl zwischen Hyperscaler und FI-TS ist keine Entweder-oder-Frage. Ein erfolgreicher Weg führt über eine Hybrid- oder Multi-Cloud-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.
- Produktionsumgebung im FI-TS: Hochrelevante Workloads sollten vorerst bei FI-TS oder in lokalen Rechenzentren verbleiben.
Fazit: Königsweg Hybrid – Die 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.
Die Praxis zeigt, dass eine hybride Strategie der erfolgversprechendste Weg ist: kritische, hochregulierte Workloads verbleiben auf der FI-TS-Plattform, während weniger sensible, innovative Anwendungen die Vorteile der Hyperscaler nutzen.
📊 Die bewährte 80/20-Regel:
- 80% der kritischen Workloads (Kernbanken, Zahlungsverkehr, Wertpapierabwicklung) laufen bei FI-TS.
- 20% (Entwicklungsumgebungen, Analysesysteme, nicht-regulierte Prozesse) nutzen die Agilität der Hyperscaler.
Diese Aufteilung nutzt die Stärken beider Welten – Sicherheit und Compliance von FI-TS, Innovation und Skalierbarkeit von AWS, Azure. Eine klare, gut dokumentierte Übergangs- und Exit-Strategie ist der Schlüssel für eine erfolgreiche Cloud-Transformation im Bankenumfeld.
Best Practice: Eine ausgewogene Hybrid- oder Multi-Cloud-Strategie ist die risikoärmste und zugleich zukunftsweisendste Lösung. Dabei spielen etablierte Anbieter mit spezifischer Finanzexpertise wie FI-TS eine entscheidende Rolle.
Letzte Aktualisierung: 2026-05-30. Dieser Artikel vergleicht objektive technische und regulatorische Aspekte sowie praktische Erfahrungen von Banken mit FI-TS als spezialisiertem Anbieter für Finanzinstitute im deutschen und europäischen Bankenumfeld.