Datenspeicher im Betrieb: Rechenzentren in Frankfurt und Aufsicht

Das Wichtigste auf einen Blick

Frankfurt am Main als Rechenzentrumsstandort: Bedeutung und Akteure

Frankfurt am Main ist der zentrale Netzwerkknoten Deutschlands. Der DE-CIX als einer der größten Internetknoten der Welt bündelt hier Verbindungen, dazu kommen Standorte großer Colocation-Anbieter wie Equinix, Digital Realty (Interxion), NTT, maincubes und CyrusOne sowie eigene Rechenzentren der Institute.

Für regulierte Häuser zählt die Nähe zur Infrastruktur des Finanzplatzes. Börse, Clearer, Zahlungsverkehrsabwickler und Marktdatenanbieter sitzen oder terminieren in Frankfurt. Wer dort speichert und verarbeitet, spart Wege und Abstimmungsaufwand.

Die Rechenzentrumslandschaft Frankfurt am Main ist nicht homogen. Sie besteht aus Hyperscaler-Regionen, Carrier-neutralen Colocation-Flächen und institutseigenen Räumen. AWS, Microsoft Azure und Google Cloud betreiben eigene Regionen in der Stadt, die Colocation-Anbieter verteilen ihre Campusflächen auf mehrere Stadtteile und das direkt angrenzende Umland – im Stadtgebiet selbst sind Strom- und Flächenkapazitäten knapp. Jede Variante hat eigene Vertrags-, Prüf- und Betriebsmodelle.

Für IT-Verantwortliche bedeutet das: Die Standortentscheidung ist eine Governance-Entscheidung. Sie legt fest, wer physischen Zugriff hat, wer Änderungen freigibt und wie ein Notfall geübt wird.

Latenzen und Ausfallsicherheit: was Finanzinstitute von Datenspeicher im Betrieb erwarten

Latenz ist die Zeit, die ein Datenpaket oder ein Speicherzugriff braucht. Im Handel, bei der Risikoberechnung und in der Betrugserkennung sind Millisekunden geschäftlich relevant.

Deshalb trennen Institute Speicherpfade nach Zweck. Handelsnahe Systeme liegen nah an der Ausführung, Archiv- und Analysesysteme dürfen weiter entfernt stehen. Diese Trennung ist eine Architekturentscheidung, keine Einkaufsfrage.

Ein typisches Beispiel: Innerhalb Frankfurts liegen die Round-Trip-Latenzen zwischen Rechenzentren oft unter 1 Millisekunde. Ein Standort in 25 Kilometern Entfernung im Rhein-Main-Gebiet erreicht je nach Strecke etwa 1 bis 2 Millisekunden.

Frankfurt und London trennen rund 650 Kilometer; dedizierte Glasfaserstrecken erreichen Round-Trip-Latenzen von etwa 8 bis 9 Millisekunden. Diese Werte sind typische Messwerte und keine Zusage für eine einzelne Strecke.

Ausfallsicherheit folgt dem gleichen Muster. Redundanz auf Netzwerk-, Strom- und Speicherebene ist Standard, aber sie muss getestet werden. Ein Failover, der nie geübt wurde, ist eine Annahme, kein Nachweis.

Für Datenspeicher im Betrieb heißt das konkret: Replikation über getrennte Brandabschnitte oder Standorte, definierte RPO- und RTO-Werte und ein dokumentierter Wiederanlauf. Die Werte leitet das Institut aus der Kritikalität des Prozesses ab, nicht aus der Technik.

Beispiel: ein Zahlungssystem mit zwei Standorten

Eine Bank betreibt ihr Kernzahlungssystem in Frankfurt und repliziert synchron in einen zweiten Raum im Rhein-Main-Gebiet. Die Datenbank schreibt erst zurück, wenn beide Seiten bestätigt haben.

Das kostet Latenz, sichert aber den aktuellen Datenstand. Für das Kernzahlungssystem gilt eine typische RPO von null bis fünf Minuten und eine RTO von 30 bis 60 Minuten.

Für das Archiv nutzt dasselbe Haus asynchrone Replikation mit höherem Datenverlustfenster, weil dort ein Wiederaufsetzen aus Sicherungen vertretbar ist. Für das Archiv liegt die typische RPO bei mehreren Stunden, die RTO bei 24 Stunden.

Table: Speicherklassen und ihre Anforderungen

Die Werte sind Beispiele aus der Praxis und ersetzen keine eigene Kritikalitätsanalyse. Institute legen sie in der IT-Strategie fest und lassen sie von der Internen Revision prüfen.

Aufsichtsanforderungen von BaFin und EZB an Datenspeicherung: BAIT, VAIT, KAIT und SREP

Die BaFin führt die Aufsicht über Banken, Versicherer und Finanzdienstleister in Deutschland. Für die IT konkretisieren die Rundschreiben 10/2017 (BA) (BAIT), 10/2018 (VA) (VAIT) und 05/2019 (KA) (KAIT) die Anforderungen an IT-Betrieb und Auslagerung. In BAIT, VAIT und KAIT sind vor allem die Kapitel 5 (IT-Betrieb) und 6 (Auslagerung) einschlägig. Flankierend gelten die Mindestanforderungen an das Risikomanagement (MaRisk), insbesondere das Modul AT 7 (Ressourcen) für die IT-Systeme und das Modul AT 9 (Auslagerungen).

Die Rundschreiben und die zugehörigen Erläuterungen stehen auf der Website der BaFin bereit. Ergänzend gelten die Leitlinien der Europäischen Bankenaufsichtsbehörde (EBA) zu Auslagerungen, die Prüf-, Weisungs- und Kündigungsrechte des Instituts vertraglich sichern. Wer die Vorgaben für den Speicherbetrieb sucht, liest die Kapitel 5 und 6 der Rundschreiben 10/2017 (BA), 10/2018 (VA) und 05/2019 (KA).

Ergänzend ordnet die BaFin Themen nach Produkt- und Institutsgruppen. Die Übersicht zu Themen und Finanzprodukten zeigt, wie regulatorische Vorgaben auf Geschäftsmodelle wirken.

Als organisatorische Grundlage gilt für Institute § 25a Abs. 1 KWG. Er verlangt ein angemessenes Risikomanagement und eine ordnungsgemäße Geschäftsorganisation. § 25b KWG konkretisiert die Notfallplanung. Für Versicherer greift § 23 VAG.

Für Institute unter direkter EZB-Aufsicht gilt zusätzlich der EZB-SREP. Der aufsichtliche Überprüfungs- und Bewertungsprozess bewertet operationelle Risiken und IT-Risiken. Die EZB veröffentlicht dazu den SREP-Methodik-Leitfaden und den Leitfaden zu IT- und Cyberrisiken. Rechenzentrumsstrategie und Speicherarchitektur werden damit Teil der jährlichen Aufsichtsbewertung.

In Prüfungen sehen Aufseher typischerweise:

Rechtliche Grundlagen liegen teils außerhalb des Aufsichtsrechts, etwa im Handels- und Haftungsrecht. Für die Dokumentation von Verantwortlichkeiten sind vor allem die MaRisk einschlägig: Sie verlangen in AT 7 (Ressourcen) klare Verantwortlichkeiten für die IT-Systeme und in AT 9 (Auslagerungen) ein Auslagerungsmanagement mit Prüf- und Weisungsrechten.

Anforderungen an Auslagerung und Cloud-Nutzung in der Finanzbranche

Auslagerung ist erlaubt, aber nicht folgenlos. Das Institut bleibt für die Erfüllung der Aufsichtsanforderungen verantwortlich, auch wenn ein Dienstleister die Technik betreibt.

Mit der Verordnung (EU) 2022/2554 über die digitale operationale Resilienz im Finanzsektor (DORA) gilt für den IT-Betrieb ein einheitlicher europäischer Rahmen. Sie verpflichtet Banken, Versicherer und Finanzdienstleister zu IKT-Risikomanagement, zu Meldungen schwerwiegender IKT-Vorfälle und zu einem Register aller vertraglich gebundenen IKT-Drittdienstleister – also auch der Colocation- und Cloud-Anbieter in Frankfurt.

Bei Cloud-Auslagerung von Banken kommt es auf drei Punkte an: Datenklassifizierung, Vertragskontrolle und Exit-Fähigkeit. Wer kritische Daten in eine öffentliche Cloud gibt, braucht eine belastbare Risikoanalyse und klare Rückholmöglichkeiten.

Deutsche und europäische Datenschutzvorgaben wirken dabei mit. Der Bundesbeauftragte für den Datenschutz und die Informationsfreiheit sowie die Landesdatenschutzbeauftragten der Länder prüfen die Verarbeitung personenbezogener Daten, in Hessen also die zuständige Landesaufsicht. Bei Auslagerung in ein Rechenzentrum in Frankfurt gehören Auftragsverarbeitungsvertrag und Löschkonzept deshalb in die Vertragsprüfung.

Technische Mindeststandards setzen viele Häuser über DIN-Normen wie DIN EN ISO/IEC 27001 und über Vorgaben des Bundesamts für Sicherheit in der Informationstechnik. Das IT-Sicherheitsgesetz 2.0 erweitert die Meldepflichten für kritische Infrastrukturen.

Laufzeit, Kündigungsfrist und Datenrückgabe sind Verhandlungspunkte; feste Marktstandards gibt es nicht. Ein Auslagerungsvertrag ohne Subunternehmer-Transparenz und ohne Exit-Plan ist kein tragfähiges Modell. Die Aufsicht fragt danach, nicht nach der Marke des Anbieters.

Ein Exit-Plan muss mehr enthalten als die Absicht zu wechseln. DORA verlangt eine dokumentierte Ausstiegsstrategie je kritischem Dienstleister: Vertragslaufzeit und Kündigungsfristen, Formate und Wege der Datenrückgabe, Unterstützungspflichten des Anbieters während der Übergangsphase sowie eine regelmäßige Prüfung, ob der Ausstieg tatsächlich machbar ist. Auch BAIT, VAIT und KAIT verlangen ein Exit-Management als Teil des Auslagerungsmanagements.

Checkliste für die Auslagerungsentscheidung

Standortfaktoren: Strom, Kühlung und Konnektivität in Frankfurt

Frankfurt am Main hat einen Vorteil, der sich nicht kopieren lässt: Konnektivität. Der DE-CIX und zahlreiche Carrier machen kurze Wege zwischen Instituten, Börse und Netzbetreibern möglich.

Dieser Vorteil hat eine Kehrseite. Strom- und Flächenkapazitäten in der Stadt und im Umland sind begrenzt. Neue Großprojekte brauchen Genehmigungen, Netzanschlüsse und Zeit.

Ein zweiter regulatorischer Faden betrifft die Anlagen selbst. Das Energieeffizienzgesetz (EnEfG) verpflichtet Betreiber von Rechenzentren, sich bei der Bundesnetzagentur zu registrieren und Angaben zu Energieverbrauch, Strommix und Effizienzkennzahlen zu melden. Institute, die eigene Rechenzentren oder große Colocation-Flächen nutzen, sollten diese Meldepflichten bei der Standortwahl und in der Nachweisführung mitdenken.

Die installierte IT-Leistung der Frankfurter Rechenzentren wird auf rund 500 Megawatt geschätzt. Für große Abnehmer lagen die Strompreise in Deutschland 2024 je nach Beschaffung und Netzentgelten typischerweise zwischen 15 und 25 Cent je Kilowattstunde. Genehmigungsverfahren für neue Großprojekte dauern in Frankfurt und Hessen häufig zwei bis vier Jahre.

Kühlung ist der zweite Kostenblock. Effiziente Kühlung senkt den Strombedarf und damit den CO2-Ausstoß, den viele Institute in ihrer Nachhaltigkeitsberichterstattung abbilden.

Für die Standortwahl folgt daraus ein Abwägen: maximale Nähe für latenzkritische Systeme, Ausweichstandorte im Rhein-Main-Gebiet oder in anderen Bundesländern für Ausfallsicherheit. Hessen, Bayern und Nordrhein-Westfalen bieten unterschiedliche Bedingungen bei Strompreis, Fläche und Anbindung.

Der Bundesnetzagentur kommt dabei eine Rolle zu, wenn es um Netzentgelte und Anschlussfragen geht. Wer plant, sollte diese Faktoren früh in die Standortanalyse aufnehmen und nicht erst bei der Vertragsverhandlung.

Prüfpfade und Nachweise für regulierte Institute

Ein Prüfpfad ist die lückenlose Kette von der Anforderung über die Umsetzung bis zum Nachweis. Für Datenspeicher im Betrieb beginnt er bei der Kritikalitätsanalyse und endet bei Testprotokollen.

Institute sollten Nachweise nach Typ trennen. Architektur- und Vertragsdokumente belegen die Planung, Betriebsprotokolle und Monitoringdaten belegen die Wirksamkeit, Auditberichte belegen die unabhängige Prüfung.

Wichtig ist die Aktualität. Ein Zertifikat von vor drei Jahren sagt nichts über den heutigen Betrieb. Änderungen an Speicher-, Netzwerk- und Standortarchitektur müssen den Prüfpfad aktualisieren.

Externe Prüfer müssen zur eigenen Architektur passen. Wenn ein Nachweis akkreditiert sein muss, ist die Deutsche Akkreditierungsstelle die zuständige Stelle in Deutschland; viele Institute lassen die Wirksamkeit ihrer Speicher- und Wiederanlaufprozesse zusätzlich von der Internen Revision bewerten. Entscheidend bleibt, dass sich jeder Nachweis auf den konkreten Standort und das konkrete System bezieht.

Am Ende zählt die einfache Frage der Aufsicht: Können Sie zeigen, dass Ihr Datenspeicher im Betrieb auch unter Last und im Störfall die Anforderungen erfüllt? Wer das mit Dokumenten und Tests belegt, hat den Prüfpfad geschlossen.

Häufige Fragen