Datenhoheit für Finanzdienstleister: Regeln für den Betrieb in mehreren Rechtsräumen
In den meisten Branchen gilt ein dominierender Souveränitätsrahmen – im Gesundheitswesen sind es HIPAA und DSGVO, in der Verteidigung CMMC und ITAR. Der Finanzsektor ist anders. Eine Bank, die in Deutschland, den USA und Singapur tätig ist, kann sich nicht aussuchen, welches Souveränitätsregime gilt – sie muss alle drei gleichzeitig erfüllen. Jedes bringt eigene Anforderungen an Datenresidenz, Übertragungsbeschränkungen, Cloud-Infrastruktur und in manchen Ländern sogar strafrechtliche Haftung bei unbefugter Offenlegung mit sich. Dieser Beitrag zeigt den vollständigen Compliance-Stack: die grundlegenden Datenschutzrahmen, die Ebene der operationellen Resilienz, die nationalen Bankgeheimnisgesetze, die in vielen Programmen unterschätzt werden, sowie die technische Architektur, die die meisten Anforderungen gleichzeitig erfüllt.
Executive Summary
Kernaussage: Finanzdienstleister, die in mehreren Rechtsräumen tätig sind, stehen vor einer sich aufaddierenden Daten-Souveränitäts-Compliance. Die DSGVO bildet die Basis für EU-Kundendaten. DORA-Compliance regelt Cloud-Infrastruktur und Drittanbieter-ICT-Kontrollen. Nationale Bankgeheimnisgesetze in Deutschland, Luxemburg, Frankreich und der Schweiz fügen strafrechtliche Haftung hinzu. Parallele Regime in den USA (GLBA, PCI DSS) und im asiatisch-pazifischen Raum (MAS TRM, APRA CPS 234) bringen weitere Pflichten. Die verbindende Anforderung: Datenresidenz in der richtigen Jurisdiktion, Kontrolle über Verschlüsselungsschlüssel durch das Finanzinstitut und nachweisbar revisionssichere Datenbewegungen.
Warum das relevant ist: Nichteinhaltung führt nicht nur zu Bußgeldern – es drohen Lizenzentzug, erzwungene Datenrückführung und in Ländern mit Bankgeheimnis strafrechtliche Verfolgung einzelner Führungskräfte. Die EBA berichtete, dass 68 % der Banken ihre Lieferantenbewertungen 2024–2025 gezielt an die Souveränitätsanforderungen nach DORA angepasst haben.
wichtige Erkenntnisse
- Souveränitäts-Compliance im Finanzsektor ist kumulativ, nicht alternativ. Wer in der EU tätig ist, muss DSGVO, DORA und nationales Bankgeheimnis gleichzeitig erfüllen – nicht als Auswahloptionen.
- DORA-Artikel 30 erweitert Souveränitätsanforderungen auf Cloud- und Technologieanbieter. Kann Ihr ICT-Anbieter keine kundengesteuerte Verschlüsselung und geografische Datenisolation nachweisen, trägt das Finanzinstitut das regulatorische Risiko.
- Der CLOUD Act schafft einen strukturellen Konflikt für Unternehmen, die US-basierte Cloud-Anbieter mit EU-Kundendaten nutzen. Der Standort des Rechenzentrums löst das Problem nicht. Kundengesteuerte Verschlüsselung schon.
- Nationale Bankgeheimnisgesetze sind Strafgesetze, keine zivilrechtlichen Regelungen. Unbefugte Offenlegung von Kundendaten in Deutschland, Luxemburg, Frankreich oder der Schweiz kann zur strafrechtlichen Verfolgung einzelner Führungskräfte führen – „der Anbieter war schuld“ ist keine Verteidigung.
- Kundengesteuerte Verschlüsselung ist die einzige Architektur, die DSGVO, DORA, PCI DSS und Bankgeheimnis gleichzeitig erfüllt. Ein Anbieter, der Kundendaten nicht entschlüsseln kann, kann sie auch nicht offenlegen – unabhängig davon, von welcher Regierung die Anordnung kommt. Das Private Data Network von Kiteworks basiert auf diesem Prinzip.
Der Drei-Ebenen-Souveränitäts-Stack
Jedes Finanzinstitut mit Aktivitäten in mehreren Rechtsräumen unterliegt drei sich kumulierenden Souveränitätsebenen. Die Ebenen heben sich nicht gegenseitig auf – sie summieren sich.
| Ebene | Regelungsbereich | Zentrale Rahmenwerke | Besonderes Merkmal |
|---|---|---|---|
| Ebene 1 – Grundlegender Datenschutz | Personenbezogene Finanzdaten der Kunden in jeder Jurisdiktion | DSGVO (EU), GLBA (USA), PDPA/PIPL-Äquivalente (Asien-Pazifik) | Extraterritoriale Wirkung – Anwendung richtet sich nach dem Aufenthaltsort des Kunden, nicht nach dem Sitz des Unternehmens |
| Ebene 2 – Operationelle Resilienz | Cloud-Infrastruktur, ICT-Drittanbieterrisiko, Systemresilienz | DORA (EU), MAS TRM (Singapur), APRA CPS 234 (Australien) | Wird auf Anbieter übertragen – Technologieanbieter werden zu direkten Compliance-Subjekten |
| Ebene 3 – Bankgeheimnis | Vertraulichkeit von Kundendaten | Deutschland §203 StGB/BaFin, Luxemburg CSSF, Frankreich ACPR, Schweiz FINMA | Strafrechtliche Haftung für Einzelpersonen – kein zivilrechtliches Sanktionssystem |
Ein Finanzinstitut in Deutschland muss alle drei Ebenen gleichzeitig erfüllen. Die Erfüllung von Ebene 1 reicht für Ebene 3 nicht aus. Die Architektur muss alle drei adressieren.
Welche Data Compliance Standards sind entscheidend?
Jetzt lesen
Ebene 1: Grundlegende Datenschutzrahmen
DSGVO – Der maßgebliche EU-Standard
DSGVO-Compliance gilt für jedes Finanzinstitut, das personenbezogene Daten von EU-Bürgern verarbeitet – unabhängig vom Firmensitz. Die Übertragungsbeschränkungen in Kapitel V sind für die Souveränität entscheidend: EU-Kundendaten dürfen die EU nur bei Angemessenheitsbeschluss, Standardvertragsklauseln (SCCs) oder verbindlichen Unternehmensregeln verlassen. Die zentrale Einschränkung nach Schrems II: SCCs können den CLOUD Act nicht aushebeln – eine vertragliche Verpflichtung kann eine US-Behördenanordnung gegenüber dem Cloud-Anbieter nicht verhindern. DSGVO-Artikel 48 macht den Konflikt deutlich: Personenbezogene Daten dürfen nicht allein aufgrund einer ausländischen Gerichtsentscheidung an Nicht-EU-Behörden übermittelt werden. Ein Finanzinstitut, das US-basierte Cloud-Infrastruktur ohne kundengesteuerte Verschlüsselung nutzt, steht unabhängig vom Serverstandort im strukturellen Konflikt mit dieser Vorgabe.
GLBA – Das US-Pendant
Der Gramm-Leach-Bliley Act verpflichtet US-Finanzinstitute, Finanzinformationen von Verbrauchern zu schützen und die Weitergabe an Dritte einzuschränken. Die aktualisierte Safeguards Rule (2023) fordert Verschlüsselung während der Übertragung und im ruhenden Zustand, Zugriffskontrollen und Multi-Faktor-Authentifizierung. Für multinationale Unternehmen gilt: GLBA und DSGVO bestehen parallel und stehen nicht im Widerspruch – die Erfüllung des höheren DSGVO-Standards erfüllt in der Regel auch die GLBA-Verschlüsselungsanforderungen. Die Souveränitätsdimension des GLBA ist überwiegend national: Sie regelt, wie US-Kundendaten geschützt werden, nicht, wo sie gespeichert sein müssen.
Asien-Pazifik-Rahmenwerke
Singapurs MAS Technology Risk Management Guidelines verlangen von Finanzinstituten eine Dateninventur, Risikobewertungen von Cloud-Anbietern und angemessene Souveränitätskontrollen für Kundendaten. Australiens APRA CPS 234 fordert Informationssicherheitskontrollen, die sich an der Sensibilität der Daten orientieren. Beide reichen nicht an die extraterritoriale Wirkung der DSGVO heran, fügen aber für im APAC-Raum tätige Unternehmen zusätzliche Anforderungen an Datenresidenz und Lieferantenbewertung hinzu – und überlagern so die EU- und US-Pflichten für Institute, die in allen drei Regionen aktiv sind.
Ebene 2: Operationelle Resilienz und das DORA-Cloud-Mandat
Was DORA für die Souveränität im Finanzsektor verändert hat
DORA-Compliance gilt seit Januar 2025 für alle EU-Finanzunternehmen – Banken, Versicherer, Wertpapierfirmen, Zahlungsdienstleister, Krypto-Anbieter – und die Pflichten werden auf ICT-Drittanbieter übertragen. Artikel 30 ist für die Souveränität entscheidend: Verträge mit ICT-Anbietern müssen Datenstandort, Verschlüsselungsmanagement und Exit-Strategien regeln. Damit wird die Cloud-Architektur zum direkten Compliance-Thema und nicht nur zur Best Practice. Anbieter, die keine kundengesteuerte Verschlüsselung und geografische Datenisolation nachweisen können, werden systematisch aus der EU-Finanzdienstleistungsbeschaffung ausgeschlossen – die EBA-Leitlinien nach DORA führten dazu, dass 68 % der Banken ihre Lieferantenbewertungen 2024–2025 angepasst haben.
Der CLOUD Act / DORA-Strukturkonflikt
DORA verlangt von EU-Finanzinstituten, dass ICT-Anbieter Kontrollen implementieren, die unbefugten Zugriff ausländischer Behörden verhindern. Der CLOUD Act verpflichtet US-basierte Cloud-Anbieter, Kundendaten auf Anordnung der US-Regierung herauszugeben – unabhängig vom Speicherort. Ein Finanzinstitut, das US-Cloud-Infrastruktur ohne kundengesteuerte Verschlüsselung nutzt, ist gleichzeitig nicht DORA-konform und strukturell der DSGVO-Artikel-48-Problematik ausgesetzt. Die einzige Lösung: Kundengesteuerte Verschlüsselung, bei der das Finanzinstitut die Entschlüsselungsschlüssel hält, nicht der Cloud-Anbieter. Eine CLOUD-Act-Anfrage beim Anbieter liefert nur verschlüsselte, unzugängliche Daten – der Anbieter ist technisch nicht in der Lage, die Daten herauszugeben, was DORA explizit fordert.
Ebene 3: Nationale Bankgeheimnisgesetze
Diese Ebene wird in vielen Multi-Jurisdiktions-Compliance-Programmen unterschätzt – dabei sind hier die Konsequenzen am gravierendsten. Bankgeheimnisgesetze sind Strafgesetze, keine zivilrechtlichen Regelungen. Sie gelten unabhängig von der DSGVO: Ein Finanzinstitut kann alle DSGVO-Anforderungen erfüllen und dennoch gegen das Bankgeheimnis verstoßen, wenn Kundendaten durch eine unbefugte Drittpartei – etwa einen Cloud-Anbieter auf ausländische Behördenanordnung – offengelegt werden.
| Jurisdiktion | Rechtsgrundlage | Durchsetzungsbehörde | Zentrale Verpflichtung | Implikation für Cloud-Infrastruktur |
|---|---|---|---|---|
| Deutschland | §203 StGB (Strafgesetzbuch) | BaFin / Bundesanwaltschaft | Verbot der unbefugten Offenlegung von Kundengeheimnissen; strafrechtliche Haftung für Einzelpersonen | Technologieanbieter müssen Kontrollen implementieren, die ausländischen Behördenzugriff technisch verhindern; vertragliche Zusagen reichen nicht aus |
| Luxemburg | Bankengesetz / CSSF-Regelungen | CSSF (Commission de Surveillance du Secteur Financier) | Strafandrohung bei Offenlegung; CSSF verlangt von Anbietern den Nachweis einer Architektur, die unbefugten Zugriff verhindert | Vermögensverwalter und Fondsadministratoren unterliegen besonders strengen Architekturprüfungen aufgrund der Fondsdomizilfunktion Luxemburgs |
| Frankreich | Code Monétaire et Financier | ACPR (Autorité de Contrôle Prudentiel et de Résolution) | Bankgeheimnis mit strafrechtlichen Sanktionen; ACPR verlangt Nachweis von Vertraulichkeitsschutz in Anbieter-Verträgen | ACPR-Leitlinien fordern technische Architektur – nicht nur vertragliche Regelungen – zur Verhinderung grenzüberschreitender Offenlegung |
| Schweiz | Bankengesetz Art. 47 | FINMA | Strafandrohung bis zu 3 Jahren Haft bei Offenlegung; gilt für Bankmitarbeiter und Drittanbieter | FINMA-Outsourcing-Leitlinien verlangen, dass Daten unter Schweizer Jurisdiktion oder gleichwertigem Schutz verbleiben; Schlüsselmanagement durch den Cloud-Anbieter ist ein direkter Compliance-Faktor |
Die Cloud-Implikation ist in allen vier Ländern gleich: Technologieanbieter müssen eine Architektur nachweisen, die unbefugten Zugriff technisch unmöglich macht – nicht nur vertraglich untersagt. SCCs binden nicht die ausländische Behörde, die die Anordnung erlässt. Kundengesteuerte Verschlüsselung schon, da sie die technische Möglichkeit zur Offenlegung beim Anbieter entfernt – unabhängig vom Rechtsweg.
Was Multi-Jurisdiktions-Datensouveränität im Finanzsektor wirklich erfordert
Jurisdiktionsbewusste Datenresidenz. Jede Kategorie von Kundendaten muss in der jeweils passenden Infrastruktur gespeichert werden – EU-Kundendaten in EU-Systemen, Singapur-Daten in MAS-konformer Infrastruktur. Konfigurierbares Geofencing auf Plattformebene macht Datenresidenz für Aufsichtsbehörden nachweisbar – nicht nur in Richtlinien dokumentiert.
Kundengesteuerte Verschlüsselung (BYOK/BYOE). Die einzige Kontrolle, die DSGVO Kapitel V, DORA Artikel 30, den CLOUD-Act-Konflikt und Bankgeheimnisanforderungen gleichzeitig erfüllt. Schlüssel im Besitz des Finanzinstituts – nicht des Technologieanbieters – bedeuten, dass keine Herausgabeanfrage beim Anbieter zu zugänglichen Daten führt. HSM-Unterstützung ermöglicht Schlüsselaufbewahrung in der jeweiligen Jurisdiktion, wo dies gefordert ist.
DORA-konforme ICT-Governance für Drittanbieter. Verträge, die Datenstandort, Schlüsselmanagement und Exit-Strategien wie in Artikel 30 fordern. Drittanbieterrisikomanagement, das die Souveränitätsarchitektur des Anbieters prüft – nicht nur Sicherheitszertifikate – durch regelmäßige Assessments, die den Fortbestand der Kontrollen bestätigen.
Unveränderbare Prüfprotokolle über alle Kanäle hinweg. Das DSGVO-Prinzip der Rechenschaftspflicht, DORA-Anforderungen an Audit-Trails, PCI DSS-Protokollierung und Bankgeheimnis-Nachweis verlangen alle dasselbe: Jeder Datenzugriff, jede Übertragung und grenzüberschreitende Bewegung wird in manipulationssicheren Prüfprotokollen über E-Mail, MFT, SFTP, Filesharing und Web-Formulare erfasst.
Dokumentierte Governance für grenzüberschreitende Übertragungen. Rechtsgrundlage für jede Übertragung (Angemessenheitsbeschluss, SCC, verbindliche Unternehmensregeln). Technische Kontrollen, die Übertragungsbeschränkungen durchsetzen, statt sich nur auf Richtlinien-Compliance zu verlassen. Exportierbare Nachweise aus Audit-Systemen, dass Übertragungen nur über autorisierte Kanäle erfolgten.
Wie Kiteworks die Datensouveränität im Finanzsektor unterstützt
Das Private Data Network von Kiteworks adressiert den Multi-Jurisdiktions-Souveränitäts-Stack im Finanzsektor mit einer Architektur, die speziell für grenzüberschreitende Finanzdaten konzipiert ist.
Jurisdiktionskonfigurierbare Bereitstellung – On-Premises, Private Cloud und regionale Cloud – hält EU-Kundendaten in EU-Infrastruktur, APAC-Daten in APAC-konformen Systemen und US-Kundendaten unter GLBA-konformen Kontrollen. Konfigurierbares Geofencing erzwingt Datenresidenz auf Infrastrukturebene. Kundengesteuerte Verschlüsselung (BYOK/BYOE) mit FIPS 140-3 Level 1-validierter Verschlüsselung, AES-256 im ruhenden Zustand und TLS 1.3 während der Übertragung schließt die CLOUD-Act-Lücke und erfüllt gleichzeitig die DORA-Artikel-30-Anforderung an das Schlüsselmanagement – Kiteworks besitzt keine Entschlüsselungsschlüssel, wodurch technischer Zugriff auf Daten durch ausländische Behörden von vornherein unmöglich ist.
Speziell für DORA: Vorgefertigte Vertragsdokumentation, Spezifikation des Datenstandorts und Schlüsselmanagement-Kontrollen adressieren direkt die Lieferantenbewertungsanforderungen, die 68 % der Banken nach DORA angepasst haben. Das einheitliche, unveränderbare Prüfprotokoll erfasst alle Aktivitäten über E-Mail, Filesharing, MFT, SFTP und Web-Formulare – sichtbar im CISO-Dashboard mit vorkonfigurierten Compliance-Vorlagen für DSGVO, DORA und PCI DSS, exportierbar an SIEM und Audit-Workflows. Kiteworks unterstützt außerdem FINRA– und GLBA-Compliance und ist damit eine einheitliche Plattform für Finanzunternehmen mit mehreren regulatorischen Anforderungen.
Fazit
Multi-Jurisdiktions-Souveränität im Finanzsektor ist ein Kumulativproblem. Die DSGVO bildet die EU-Basis. DORA ergänzt Cloud-Infrastruktur- und ICT-Drittanbieteranforderungen, die auf Anbieter übergehen. Nationale Bankgeheimnisgesetze bringen unabhängige strafrechtliche Haftung. US- und APAC-Rahmenwerke fügen weitere Anforderungen hinzu. Keine dieser Ebenen hebt die anderen auf – sie summieren sich.
Die architektonische Lösung ist einfacher als der regulatorische Stack vermuten lässt. Jurisdiktionsbewusste Datenresidenz, kundengesteuerte Verschlüsselung und unveränderbare Prüfprotokolle erfüllen die Kernanforderungen der meisten Rahmenwerke gleichzeitig – die gleiche Kontrolle, die die CLOUD-Act-Lücke schließt, erfüllt auch DORA Artikel 30, technische Bankgeheimnisanforderungen und DSGVO Kapitel V. Das Private Data Network von Kiteworks macht diese Architektur für grenzüberschreitend tätige Finanzunternehmen praktisch umsetzbar.
Erfahren Sie mehr über Compliance bei Datensouveränität im Finanzsektor: Vereinbaren Sie jetzt eine individuelle Demo.
Häufig gestellte Fragen
Ja. Die DSGVO gilt nach dem Aufenthaltsort der betroffenen Person, nicht nach dem Firmensitz. Wenn Ihre US-Systeme personenbezogene Finanzdaten von EU-Bürgern verarbeiten – Kontodaten, Transaktionshistorie, Investmentpositionen – gilt die DSGVO für diese Verarbeitung. Die Übertragungsbeschränkungen in Kapitel V bedeuten, dass EU-Kundendaten, die in US-Infrastruktur verarbeitet werden, einen gültigen Rechtsmechanismus für die Übertragung benötigen (Angemessenheitsbeschluss, SCCs oder verbindliche Unternehmensregeln). SCCs sind der gängigste Mechanismus, aber nach Schrems II beseitigen sie das CLOUD-Act-Risiko nicht. Kundengesteuerte Verschlüsselung ist die architektonische Ergänzung, die diese Lücke schließt.
Teilweise, aber nicht vollständig. EU-Rechenzentren erfüllen die Anforderungen an die geografische Datenresidenz. Sie lösen jedoch nicht das CLOUD-Act-Problem: Ein US-basierter Anbieter ist gesetzlich verpflichtet, Kundendaten aus EU-Rechenzentren auf Anordnung der US-Regierung herauszugeben – unabhängig vom Serverstandort. DORA Artikel 30 verlangt, dass Verträge das Schlüsselmanagement regeln – wenn der Anbieter die Schlüssel hält, kann eine Herausgabeanfrage zu zugänglichen Daten führen. Kundengesteuerte Verschlüsselung (BYOK/BYOE) mit Schlüsseln im Besitz Ihres Instituts ist die notwendige Ergänzung: Der Anbieter speichert verschlüsselte Daten, die er nicht entschlüsseln kann, sodass die CLOUD-Act-Compliance technisch unmöglich ist – unabhängig von der Rechtsanordnung.
DORA Artikel 30 verlangt, dass Verträge mit ICT-Drittanbietern Folgendes regeln: die geografischen Standorte, an denen Daten verarbeitet und gespeichert werden; Verschlüsselungsstandards und wer die Schlüssel kontrolliert; Prüfungsrechte für das Finanzinstitut und die Aufsichtsbehörden; sowie Exit-Regelungen für Datenportabilität und Unterstützung beim Übergang. Anbieter, die die Verschlüsselungsschlüssel selbst verwalten, können die Anforderungen an das Schlüsselmanagement aus Artikel 30 nicht erfüllen – unabhängig von der Vertragsgestaltung. Es sind sowohl technische Fähigkeiten als auch vertragliche Regelungen erforderlich. Für ein vollständiges Verständnis der Drittanbieterrisikomanagement-Pflichten nach DORA müssen sowohl die vertraglichen als auch die technischen Aspekte adressiert werden.
Beide Länder sehen strafrechtliche Haftung – keine zivilrechtlichen Sanktionen – für unbefugte Offenlegung von Kundendaten vor, und das gilt auch für Drittanbieter, nicht nur für Bankmitarbeiter. Wenn Ihr Cloud-Anbieter von einer ausländischen Behörde zur Offenlegung von Kundendaten gezwungen werden kann und dies geschieht, droht einzelnen Führungskräften strafrechtliche Verantwortung – unabhängig von vertraglichen Regelungen. BaFin und FINMA verlangen von Technologieanbietern den Nachweis einer technischen Architektur, die ausländischen Behördenzugriff verhindert – nicht nur vertragliche Zusagen. Kundengesteuerte Verschlüsselung mit Schlüsselaufbewahrung in der jeweiligen Jurisdiktion (z. B. HSM) ist die Architektur, die beide Aufsichtsbehörden erwarten.
PCI DSS regelt Karteninhaberdaten; die DSGVO regelt personenbezogene Daten im Allgemeinen – meist fallen Karteninhaberdaten auch unter personenbezogene Daten. PCI DSS verlangt Verschlüsselung während der Übertragung und im ruhenden Zustand, strikte Zugriffskontrollen und umfassende Protokollierung. Die DSGVO ergänzt Rechte für Betroffene, Übertragungsbeschränkungen und das Rechenschaftsprinzip. Bei grenzüberschreitender Zahlungsabwicklung in Europa erfüllen die Verschlüsselungsanforderungen von PCI DSS teilweise die technischen Maßnahmen nach DSGVO Artikel 32, während die Übertragungsbeschränkungen der DSGVO für Karteninhaberdaten gelten, die die EU verlassen. Die Praxis: Setzen Sie jeweils den strengeren Standard um und nutzen Sie eine einheitliche Plattform, die Prüfprotokolle für beide Anforderungen liefert.
Weitere Ressourcen
- Blogbeitrag Datensouveränität: Best Practice oder regulatorische Pflicht?
- eBook
Datensouveränität und DSGVO - Blogbeitrag
Vermeiden Sie diese Fallstricke bei der Datensouveränität - Blogbeitrag
Best Practices für Datensouveränität - Blogbeitrag
Datensouveränität und DSGVO [Verständnis von Datensicherheit]