Handels- und Kundendaten gehören in ein bewusst gewähltes Zuhause – nicht in eine Standardlösung vom Anbieter

Das Compliance-Team einer Bank kann in der Regel angeben, in welchem Land das Kernbankensystem betrieben wird. Deutlich weniger Teams können mit Sicherheit sagen, nach welchem Landesrecht tatsächlich auf diese Daten zugegriffen werden darf, sobald ein Cloud-Anbieter mit Hauptsitz im Ausland ins Spiel kommt. Für Finanzinstitute, die Transaktionsdaten, KYC-Unterlagen und Kundenportfolios verwalten, ist diese Lücke zwischen „wo die Daten gespeichert werden“ und „wer rechtlich darauf zugreifen darf“ keineswegs theoretisch. Sie entscheidet darüber, ob ein Souveränitätsanspruch einer Prüfung durch Aufsichtsbehörden standhält – oder eben nicht.

Das Speichern von Handelsdaten in der jeweiligen Region erfüllt lediglich eine Vorgabe zur Datenresidenz. Es sagt jedoch nichts darüber aus, ob der Betreiber dieser Infrastruktur ausländischen Zugriffsrechten unterliegt, die eine Offenlegung unabhängig vom Serverstandort erzwingen könnten. Dieser Artikel erläutert, was Datensouveränität für Finanzinstitute tatsächlich bedeutet – und zwar über den Standort hinaus, den ein Anbieter auf einer Landkarte angibt.

Executive Summary

Finanzinstitute stehen gleichzeitig Souveränitätsfragen aus mehreren Richtungen gegenüber: Datenschutzbehörden, Bankenaufsicht und zunehmend auch Kunden, die wissen wollen, wo ihre Daten gespeichert sind und wer darauf zugreifen kann. Die Angabe eines Speicherorts beantwortet nur die Hälfte dieser Frage. Die entscheidende, oft schwierigere Hälfte betrifft die Zuständigkeit: Welche rechtliche Instanz regelt den Anbieter, der die Daten verarbeitet, und besitzt dieser Anbieter die technische Möglichkeit, im Falle eines Zwangs lesbare Daten bereitzustellen? Für Compliance- und Risikoverantwortliche bedeutet das: Souveränitätsansprüche müssen anhand von Zuständigkeit, Schlüsselverwaltung und Infrastruktur-Isolation bewertet werden – nicht anhand der Adresse eines Rechenzentrums. Nur eine Architektur, die dem Anbieter jegliche Möglichkeit nimmt, einer ausländischen Anordnung nachzukommen – statt sich lediglich vertraglich dazu zu verpflichten, dies nicht zu tun –, erfüllt tatsächlich die Anforderungen, die ein Prüfer an Souveränität stellt.

Wichtige Erkenntnisse

1. Der Standort des Rechenzentrums ist nicht gleichbedeutend mit der rechtlichen Zuständigkeit. Die Heimatjurisdiktion eines Anbieters bestimmt seine gesetzlichen Verpflichtungen – unabhängig davon, wo die Server physisch stehen.
2. Extraterritoriale Zugriffsrechte wirken grenzüberschreitend – unabhängig vom Hosting-Standort. Ein Anbieter, der einer ausländischen Jurisdiktion unterliegt, kann gezwungen werden, Kundendaten herauszugeben, selbst wenn sich das Rechenzentrum vollständig außerhalb des Heimatlandes der Aufsichtsbehörde befindet.
3. Multi-Tenant-Finanzinfrastrukturen bündeln Risiken für viele Institute gleichzeitig. Eine einzige ausgenutzte Schwachstelle in einer geteilten Plattform kann gleichzeitig Daten von direkten Wettbewerbern kompromittieren.
4. Kundeneigene Verschlüsselungsschlüssel machen rechtliche Herausgabeanordnungen wirkungslos. Ein Anbieter, der Kundendaten nicht entschlüsseln kann, kann auch auf Anfrage keine lesbaren Informationen herausgeben – unabhängig davon, wer anfragt.
5. Die Wahl der Bereitstellung, nicht Marketingversprechen, entscheidet über tatsächliche Souveränität. On-Premises, selbst gehostete Cloud-Tenancy oder eine dedizierte Instanz sind Entscheidungen des Instituts – keine Standards, die der Anbieter setzt.

Die rechtliche Realität hinter In-Country-Hosting für Finanzdaten

Ein Rechenzentrum, das von einem Anbieter mit Hauptsitz im Ausland betrieben wird, unterliegt weiterhin dem Recht des Herkunftslandes des Anbieters – unabhängig davon, in welchem Land die Hardware steht. Für Institute, die grenzüberschreitende Transaktionen, Kundenkonten in mehreren Rechtsräumen und vertrauliche Geschäftsdaten verwalten, entscheidet genau dieser Unterschied, ob ein Souveränitätsanspruch einer Prüfung standhält.

Warum die Adresse eines Rechenzentrums nicht über die rechtliche Reichweite entscheidet

Extraterritoriale Gesetze, wie sie für viele große Cloud- und Technologieanbieter gelten, verpflichten einen Anbieter, Daten herauszugeben, die sich in seinem Besitz, seiner Obhut oder Kontrolle befinden – unabhängig davon, wo diese Daten gespeichert sind. Ein Anbieter mit Hauptsitz in einer Jurisdiktion, der für europäische oder EMEA-Bankkunden ein „regionales“ Rechenzentrum betreibt, bleibt an das Recht seines Heimatlandes gebunden. Das Label „regional“ beschreibt eine Marketing- und Betriebsentscheidung, aber keine Änderung der rechtlichen Exponierung. Ein Einkaufsteam, das sich auf die Bestätigung des Landes des Rechenzentrums beschränkt, prüft die Geografie – nicht die Souveränität.

Wie sich dadurch das Anbieterrisiko für Institute verändert

Für Institute, die regulierte personenbezogene Daten, Zahlungsinformationen oder vertrauliche Geschäftsdaten verarbeiten, verändert sich dadurch die Bedeutung von „konformem Hosting“. Die entscheidende Frage ist, ob irgendeine Behörde – egal wo – den Anbieter zwingen kann, Daten herauszugeben, und ob der Anbieter technisch überhaupt dazu in der Lage wäre. Die Antwort auf „In welchem Land steht das Rechenzentrum?“ greift hier zu kurz.

Warum Multi-Tenant-Finanzinfrastruktur das Risiko für Institute erhöht

Regionale Cloud-Angebote werden oft als Souveränitätslösung präsentiert. In der Praxis teilen sich jedoch die meisten regionalen Deployments großer Multi-Tenant-Plattformen weiterhin Datenbanken, Anwendungsumgebungen, Administrationskonsolen und Supportzugänge mit dem globalen Betrieb des Anbieters.

Geteilte Infrastruktur bedeutet geteiltes Risiko für konkurrierende Institute

Wenn mehrere Institute auf derselben Multi-Tenant-Plattform arbeiten, kann ein einziges kompromittiertes Zugangskonto, eine fehlerhafte Richtlinie oder eine rechtliche Anordnung Auswirkungen haben, die weit über die Daten eines einzelnen Instituts hinausgehen. Multi-Tenancy ist für den Anbieter effizient, da die Betriebskosten auf viele Kunden verteilt werden. Doch genau dort, wo regulierte Institute Risiken reduzieren wollen, werden diese gebündelt. Ein regionales Hosting-Label ändert nichts an dieser Architektur – ein Vorfall auf einer geteilten Plattform kann also auch die Daten von Wettbewerbern auf derselben Infrastruktur betreffen.

Was echte Datensouveränität für Finanzinstitute über den Standort hinaus erfordert

Echte Souveränität basiert auf drei ineinandergreifenden Faktoren: Infrastruktur-Isolation, Schlüsselverwaltung und der Wahl der Jurisdiktion. Der Standort ist ein Aspekt der Jurisdiktionswahl, aber ohne die anderen beiden Faktoren ist er bedeutungslos.

Single-Tenant-Architektur als Grundlage

Single-Tenant-Deployment bedeutet, dass Datenbanken, Dateisysteme, Anwendungsumgebungen und Betriebssysteme eines Instituts nicht mit anderen Kunden geteilt werden. Dadurch entfällt die tenantübergreifende Exponierung, wie sie bei geteilten Banking- und Payment-Plattformen besteht. Das Institut kann gezielt entscheiden, wo die eigene dedizierte Infrastruktur betrieben wird – vollständig On-Premises, selbst gehostet in der eigenen Cloud-Tenancy oder als dedizierte Instanz beim Anbieter. Der Bereitstellungsort ist somit eine bewusste Entscheidung und kein vom Anbieter vorgegebener Standard.

Kundeneigene Verschlüsselungsschlüssel als rechtlicher Schutz für Kundendaten

Infrastruktur-Isolation löst die operative Seite der Souveränität, aber nicht die rechtliche – dafür ist Schlüsselverwaltung notwendig. Wenn ein Anbieter die Verschlüsselungsschlüssel für Transaktionsdaten eines Kunden hält, kann eine rechtliche Anordnung dem Anbieter sowohl die verschlüsselten Daten als auch die Möglichkeit zur Entschlüsselung abverlangen. Hält das Institut die Schlüssel selbst – typischerweise integriert über ein Hardware Security Module –, erhält die Behörde im Ernstfall nur Chiffretext. Der Anbieter verweigert die Herausgabe nicht – er ist architektonisch gar nicht in der Lage, mehr als unlesbare Daten zu liefern. Genau dieser Unterschied macht aus einer rechtlichen Exponierung ein Nicht-Ereignis für das Institut und seine Kunden.

Souveränität aktiv umsetzen statt voraussetzen

Compliance- und Risikoteams sollten Datensouveränität architektonisch überprüfen – und nicht auf Basis von Marketingversprechen akzeptieren. Das bedeutet: Klären, welcher rechtlichen Jurisdiktion der Anbieter tatsächlich unterliegt – nicht nur, wo das Rechenzentrum steht; prüfen, ob es sich wirklich um eine Single-Tenant-Bereitstellung handelt oder nur um einen abgetrennten Bereich einer geteilten Banking-Plattform; und feststellen, wer die Verschlüsselungsschlüssel tatsächlich hält und unter welchen Bedingungen diese herausgegeben werden könnten. Wer diese drei Fragen konsequent für jeden Anbieter beantwortet, der Kunden- und Transaktionsdaten verarbeitet, macht aus Souveränität eine nachweisbare Eigenschaft – und nicht nur eine Annahme im Vertrag.

Wie eine Data Control Plane Souveränität zur architektonischen Realität macht

Das bedeutet nicht, dass Institute eigene Infrastruktur von Grund auf bauen müssen, um echte Souveränität zu erreichen. Es bedeutet, eine Plattform zu wählen, bei der Jurisdiktion, Isolation und Schlüsselverwaltung architektonisch verankert sind – und nicht nur vertraglich zugesichert werden. Die Governance sensibler Kunden- und Transaktionsdaten wird dabei kontinuierlich durchgesetzt, statt einfach vorausgesetzt. Genau das leistet eine Data Control Plane: Sie bildet eine Governance-Schicht über alle Kanäle, über die Daten bewegt werden – einschließlich E-Mail, Filesharing, APIs und KI-Agents – und steuert, wer sensible Daten von wo, unter welchen Bedingungen senden, teilen oder darauf zugreifen darf.

Die Kiteworks Data Control Plane basiert von Grund auf auf einer Single-Tenant-Architektur – ohne geteilte Datenbanken, Dateisysteme, Anwendungsumgebungen oder Betriebssysteme zwischen Kunden. Institute wählen ihren eigenen Bereitstellungsort – On-Premises, in der eigenen Cloud-Tenancy oder als dedizierte Instanz – und können kundeneigene Verschlüsselungsschlüssel über ein Hardware Security Module integrieren, sodass keine externe Partei, auch nicht Kiteworks, Kundendaten entschlüsseln kann. Darüber hinaus steuern datengetriebene zero-trust Controls jede Sende-, Freigabe- und Zugriffsaktion über alle Kanäle hinweg. Jede Aktion wird revisionssicher in einem unveränderbaren Audit-Log erfasst, der direkt in SIEM– und Security Operations-Tools eingespeist wird – und so genau die Nachweise liefert, die ein Prüfer verlangt, statt nur vertragliche Zusicherungen. Die Data Control Plane ergänzt damit bestehende DSPM-, CSPM- und IAM-Investitionen und deckt gezielt sensible Finanzdaten in Bewegung ab – genau dort, wo diese Tools typischerweise enden.

Institute, die Souveränität nicht länger voraussetzen, sondern nachweisen wollen, können eine individuelle Demo vereinbaren, um zu sehen, wie eine Single-Tenant-Architektur mit kundengesteuerter Schlüsselverwaltung auf ihre regulatorischen Anforderungen und bestehende Technologieumgebung angewendet werden kann.