金融サービスにおけるデータ主権：複数法域での運用ルール

ほとんどの業界では、支配的な主権フレームワークが1つ存在します。たとえば、ヘルスケアにはHIPAAやGDPR、防衛分野にはサイバーセキュリティ成熟度モデル認証（CMMC）や国際武器取引規則（ITAR）があります。しかし、金融サービスは異なります。ドイツ、米国、シンガポールで事業を展開する銀行は、どの主権体制を適用するかを選ぶのではなく、3つすべてを同時に受け入れる必要があり、それぞれが異なるデータレジデンシー規則、転送制限、クラウドインフラ要件、そして一部の法域では無許可開示に対する刑事責任まで課しています。本記事では、コンプライアンス全体像を整理します。EUのプライバシーフレームワークを基盤とし、オペレーショナルレジリエンス層、ほとんどのプログラムで軽視されがちな各国の銀行秘密保持法、そしてそれらの要件を一度に満たす技術アーキテクチャまでをマッピングします。

エグゼクティブサマリー

主なポイント：複数の法域で事業を展開する金融サービス企業は、市場が増えるごとに複雑化するデータ主権コンプライアンスに直面します。EU顧客データの基準はGDPRが定め、DORAコンプライアンスはクラウドインフラやICTサードパーティ管理を規定します。ドイツ、ルクセンブルク、フランス、スイスの各国銀行秘密保持法は、さらに刑事責任を重ねます。米国（GLBA、PCI DSS）やアジア太平洋（MAS TRM、APRA CPS 234）の並行する規制も追加義務を課します。これらすべてに共通する要件は、適切な法域でのデータレジデンシー、金融機関による暗号鍵の管理、そして監査可能なデータ移動の証明です。

なぜ重要か：コンプライアンス違反は単なる規制罰金にとどまらず、営業ライセンスの喪失、データの強制帰還、銀行秘密保持法域では経営幹部個人の刑事訴追にまで発展する可能性があります。EBA（欧州銀行監督機構）は、DORA導入後の主権要件対応のため、2024～2025年に68%の銀行がベンダー評価を更新したと報告しています。

主なポイント

1. 金融サービスの主権コンプライアンスは加算型であり、選択肢ではありません。EUでの事業は、GDPR、DORA、各国銀行秘密保持法を同時に満たす必要があり、いずれか一つを選ぶことはできません。
2. DORA第30条は主権要件をクラウドやテクノロジーベンダーにも拡張します。ICTプロバイダーが顧客管理型暗号化や地理的データ分離を証明できない場合、金融機関が規制リスクを負うことになります。
3. 米国クラウド法（CLOUD Act）は、EU顧客データを扱う米国本社クラウドプロバイダー利用企業に構造的な矛盾を生じさせます。データセンターの所在地だけでは解決しません。顧客管理型暗号化が必要です。
4. 各国銀行秘密保持法は民事規制ではなく刑事法です。ドイツ、ルクセンブルク、フランス、スイスで顧客金融情報を無断開示すると、経営幹部個人が訴追される可能性があります。「ベンダーの責任」は免責理由になりません。
5. 顧客管理型暗号化は、GDPR、DORA、PCI DSS、銀行秘密保持義務を同時に満たす唯一のアーキテクチャです。プロバイダーが顧客データを復号できなければ、どの政府から命令が出ても開示できません。Kiteworksのプライベートデータネットワークはこの原則に基づいて構築されています。

三層構造の主権スタック

複数法域で事業を展開する金融サービス企業は、3つの主権義務層すべてに同時に従う必要があります。これらの層は相殺されることなく、積み重なります。

ドイツで事業を行う金融機関は、これら3層すべてを同時に満たす必要があります。層1だけをクリアしても層3は満たせません。アーキテクチャは3層すべてに対応する必要があります。

層1：プライバシーフレームワークの基準

GDPR — EUの基準となる規制

GDPRコンプライアンスは、金融機関の本社所在地に関わらず、EU居住者の個人データを処理するすべての金融機関に適用されます。第V章の転送制限が主権に関する重要な条項であり、EU顧客の金融データは、十分性認定、標準契約条項（SCCs）、または拘束的企業準則（BCRs）によってのみEU域外に移転できます。Schrems II判決以降の重要な制約は、SCCsが米国クラウド法（CLOUD Act）を上書きできないことです。契約上の義務では、米国政府によるクラウドプロバイダーへの強制命令を防げません。GDPR第48条はこの矛盾を明示しており、個人データは外国裁判所の命令だけでは非EU当局に移転できません。顧客管理型暗号化を導入していない米国本社クラウドインフラを利用する金融機関は、サーバーの場所に関係なくこの条項と構造的な緊張関係にあります。

GLBA — 米国の並行規制

グラム・リーチ・ブライリー法（GLBA）は、米国の金融機関に消費者金融情報の保護と第三者共有の制限を義務付けています。2023年改訂のSafeguards Ruleでは、転送中・保存中の暗号化、アクセス制御、多要素認証が必須となりました。複数法域で事業を展開する場合、GLBAとGDPRは根本的な矛盾なく共存し、GDPRのより厳格な基準を満たせばGLBAの暗号化要件も同時に満たされます。GLBAの主権的側面は主に国内向けであり、米国顧客金融データの保護方法を規定しますが、データの所在までは規定しません。

アジア太平洋のフレームワーク

シンガポールのMASテクノロジーリスク管理ガイドラインは、金融機関にデータインベントリの維持、クラウドプロバイダーのリスク評価、顧客データ主権管理の確保を求めています。オーストラリアのAPRA CPS 234は、データの機密性に応じた情報セキュリティ管理を義務付けています。いずれもGDPRの域外適用ほどの強制力はありませんが、APACで事業を行う企業にはレジデンシーやベンダー評価の要件を追加し、EUや米国の義務に重ねて適用されます。

層2：オペレーショナルレジリエンスとDORAクラウド要件

DORAが金融サービス主権にもたらした変化

DORAコンプライアンスは2025年1月に発効し、EUのすべての金融機関—銀行、保険、投資会社、決済事業者、暗号資産サービス提供者—に適用され、義務はICTサードパーティプロバイダーにも及びます。第30条が主権に関する重要条項であり、ICTプロバイダーとの契約にはデータの所在、暗号鍵管理、退出戦略を明記する必要があります。これにより、クラウドプロバイダーのアーキテクチャが直接的な規制コンプライアンス事項となり、単なるベストプラクティスではなくなりました。顧客管理型暗号化や地理的データ分離を証明できないベンダーは、EU金融サービス調達から体系的に排除されつつあり、EBAのDORA後のベンダー評価ガイダンスにより、2024～2025年に68%の銀行が評価を更新しました。

クラウド法（CLOUD Act）／DORAの構造的矛盾

DORAは、EU金融機関に対し、ICTプロバイダーが外国政府による無許可アクセスを防ぐ管理策を実装することを求めています。一方、米国クラウド法（CLOUD Act）は、米国本社クラウドプロバイダーに対し、データの物理的な保管場所に関係なく、米国政府の有効な要請があれば顧客データの提出を義務付けています。顧客管理型暗号化を導入していない米国クラウドインフラを利用する金融機関は、DORAの技術要件に違反し、GDPR第48条の構造的リスクにもさらされます。唯一の解決策は、金融機関が暗号鍵を管理し、クラウドプロバイダーが復号鍵を保持しない顧客管理型暗号化です。プロバイダーに強制命令が出されても、暗号化されたデータしか提供できず、技術的に開示不能となるため、これがDORAの要件に合致します。

層3：各国銀行秘密保持法

この層は、多くの複数法域コンプライアンスプログラムで軽視されがちですが、最も重大な結果をもたらします。銀行秘密保持法は民事規制ではなく刑事法であり、GDPRとは独立して適用されます。金融機関がGDPRのすべてのデータ保護要件を満たしていても、顧客金融データが無許可の第三者（たとえば外国政府の命令に応じたクラウドプロバイダー）にアクセスされた場合、銀行秘密保持違反となります。

クラウドに関する影響は4法域で共通しており、テクノロジーベンダーは、無許可アクセスを技術的に不可能にするアーキテクチャを証明する必要があります。契約上の約束だけでは、強制命令を出す外国政府を拘束できません。顧客管理型暗号化は、プロバイダーが法的手続きに関係なく技術的に開示できなくすることで、これを実現します。

複数法域の金融データ主権が実際に求めるもの

法域対応のデータレジデンシー。顧客金融データの各カテゴリは、該当する法域インフラに保存されなければなりません。EU顧客データはEUシステムに、シンガポール顧客データはMAS準拠インフラに配置する必要があります。プラットフォームレベルでのジオフェンシング設定により、データレジデンシーを単なるポリシー文書ではなく、規制当局に証明可能な形で担保します。

顧客管理型暗号化（BYOK/BYOE）。GDPR第V章、DORA第30条、クラウド法の矛盾、銀行秘密保持義務を同時に満たす唯一の管理策です。金融機関が鍵を保持し、テクノロジープロバイダーが保持しないことで、プロバイダーへの強制要請があってもデータはアクセス不能です。HSM対応により、法域内での鍵管理も可能です。

DORA準拠のサードパーティICTガバナンス。第30条の要件通り、データの所在、暗号鍵管理、退出戦略を契約で明記します。ベンダーの主権アーキテクチャをセキュリティ認証だけでなく、定期的な評価で管理策が維持されていることを確認するサードパーティリスク管理が必要です。

全チャネル横断の改ざん不可な監査ログ。GDPRの説明責任原則、DORAの監査証跡要件、PCI DSSのログ要件、銀行秘密保持の証明性はすべて、メール、MFT、SFTP、ファイル共有、Webフォームなど、すべてのデータアクセス・転送・越境移動を改ざん不可な監査ログで記録することを求めています。

越境転送ガバナンスの文書化。すべての転送について法的根拠（十分性認定、SCC、拘束的企業準則）を明確化し、ポリシー順守だけでなく技術的管理策で転送制限を担保します。監査システムからエクスポート可能な証拠により、転送が許可されたチャネル内でのみ行われたことを証明します。

Kiteworksによる金融サービス向けデータ主権サポート

Kiteworksのプライベートデータネットワークは、複数法域の金融主権スタックに対応したアーキテクチャで、越境金融データ運用のために設計されています。

法域ごとに設定可能な導入形態（オンプレミス、プライベートクラウド、リージョナルクラウド）により、EU顧客データはEUインフラ、APACデータはAPAC準拠システム、米国顧客データはGLBA準拠管理下に保持されます。インフラレベルでのジオフェンシングにより、レジデンシーを強制します。顧客管理型暗号化（BYOK/BYOE）は、FIPS 140-3レベル1認証暗号化、保存時のAES-256、転送時のTLS 1.3を採用し、クラウド法のギャップを解消しつつ、DORA第30条の暗号鍵管理要件も同時に満たします。Kiteworksは復号鍵を保持せず、外国政府のアクセス要求にも技術的に対応できない設計です。

DORA対応としては、事前設定済みの契約文書、データ所在指定、暗号鍵管理コントロールにより、DORA後に68%の銀行が更新したベンダー評価要件に直接対応します。統合された改ざん不可の監査ログは、メール、ファイル共有、MFT、SFTP、Webフォームのすべての活動を記録し、CISOダッシュボードでGDPR、DORA、PCI DSS向けの事前設定済みコンプライアンステンプレートとして可視化、SIEMや監査ワークフローへのエクスポートも可能です。KiteworksはFINRAやGLBAコンプライアンスにも対応し、複数規制体制下で事業を行う金融企業向けの統合プラットフォームとなります。

まとめ

複数法域の金融サービス主権は、積み重ね型の課題です。GDPRがEUの基準を定め、DORAがクラウドインフラやサードパーティICT要件を追加し、各国銀行秘密保持法が両者とは独立して刑事責任を課します。米国やアジア太平洋のフレームワークもさらに要件を追加します。いずれも相殺されることなく、積み重なります。

アーキテクチャ上の解決策は、規制スタックが示唆するよりもシンプルです。法域対応のデータレジデンシー、顧客管理型暗号化、改ざん不可な監査証跡が、多くのフレームワークの主要要件を同時に満たします。クラウド法のギャップを解消する管理策が、DORA第30条や銀行秘密保持の技術要件、GDPR第V章も同時に満たすのです。Kiteworksのプライベートデータネットワークは、越境事業を行う金融企業にとって、このアーキテクチャを現実的に運用可能にします。

金融サービス向けデータ主権コンプライアンスの詳細については、カスタムデモを今すぐご予約ください。

追加リソース 

• ブログ記事  データ主権：ベストプラクティスか規制要件か？
• eBook 
  データ主権とGDPR
• ブログ記事 
  データ主権で陥りやすい落とし穴
• ブログ記事 
  データ主権のベストプラクティス
• ブログ記事 
  データ主権とGDPR【データセキュリティの理解】