金融業界のデータ基盤は、他業種と比べて圧倒的に要求水準が高い領域です。リスク管理のための精緻なデータ集計、不正検知のためのリアルタイム処理、そして規制当局への報告に耐える完全な監査証跡――これら3つを同時に満たす設計が求められます。クラウドの活用が進む一方で、データ所在地・暗号化・権限管理・データリネージといった金融特有の統制要件を外すと即座にコンプライアンス違反に直結します。本記事では、金融データ基盤の設計をリスク管理・不正検知・規制対応の3軸で整理し、監査証跡の担保とクラウド移行の現実解まで掘り下げて解説します。
金融業界のデータ基盤に求められる要件
金融業のデータ基盤に求められる要件は、大きく4つに集約されます。第一に「完全性」――取引データの欠損や重複が一切許されず、日次バッチの網羅性が厳密に検証されること。第二に「追跡可能性」――あらゆる数字について、どのソースからどの変換を経て算出されたかを遡れること。第三に「即時性」――不正検知やリスク監視では秒単位の処理が必要なこと。第四に「監査耐性」――監査法人や規制当局の問い合わせに即日回答できる証跡管理です。
これらの要件は、一般的なクラウドDWH＋BIツールの組み合わせだけでは満たしきれません。データリネージの自動取得、きめ細かいアクセス制御、暗号化ポリシー、バックアップ戦略、災害復旧(DR)設計まで、セキュリティとガバナンスの層を厚く作り込む必要があります。セキュリティ設計とコンプライアンス対応の記事も併せて参照してください。
規制要件とデータ基盤設計
金融業界のデータ基盤は、規制要件を前提に設計します。国内外の主要規制ごとに、データ基盤に影響する要件を整理しました。
| 規制名 | 対象 | 主なデータ要件 | 保持期間 |
|---|---|---|---|
| 金融商品取引法 | 証券、金融商品 | 取引記録、顧客説明記録 | 7年以上 |
| 銀行法 | 預金・貸出 | 取引明細、顧客情報 | 10年以上 |
| 犯罪収益移転防止法 | 全金融機関 | 本人確認記録、疑わしい取引 | 7年 |
| BCBS239 | グローバル銀行 | リスクデータ集計と報告 | 5年以上 |
| 個人情報保護法 | 全業種 | 利用目的管理、開示対応 | 必要期間 |
| FISCガイドライン | 金融機関クラウド利用 | 監査・可用性・暗号化 | – |
これらの要件を踏まえると、データ基盤の設計では「削除しない」「改ざんできない」「追跡できる」という3つの原則が絶対条件となります。具体的には、取引テーブルにはSCD Type2を採用して過去の状態を全て残し、データリネージをdbtやOpenLineage等で自動記録し、オブジェクトストレージのバージョニング機能を有効化して改ざん防止を担保します。保持期間は最長の規制に合わせ、それを超える古いデータはコールドストレージに移して保管コストを最適化するのが標準的な運用です。
リスク管理データの統合
金融のリスク管理では、信用リスク・市場リスク・流動性リスク・オペリスクの4つを統合的に監視します。これらのデータは通常、バラバラのシステムに散在しており、データ基盤での統合が大仕事になります。典型的なアーキテクチャを図示します。
【リスクデータ集約アーキテクチャ】
[勘定系] [証券取引] [為替システム] [外部市場データ]
| | | |
v v v v
+--------------------------------------------------+
| 取込層(CDC/ファイル連携/API) |
| 改ざん検知・ハッシュ記録 |
+---------------------+----------------------------+
|
v
+----------------------+
| Raw Layer (Immutable)|
| パーティション毎スナップ|
+----------+-----------+
|
v
+------------------------+
| 正規化・マッピング層 |
| (商品/顧客/拠点コード)|
+----------+-------------+
|
v
+----------------------+
| リスクファクトマート|
| exposure/valuation |
+---+----------+-------+
| |
+-------+ +-------+
v v
[VaR計算エンジン] [資本適正化]
| |
v v
[リスクダッシュボード] [規制報告生成]
※ Raw Layerは削除・更新禁止。改訂は追記のみ。この構成のRaw Layerは、いわゆる「書き込んだら絶対に変えない(Immutable)」の原則で運用されます。補正や訂正は、新しいバージョンを追記する形で行い、過去のレコードを上書きしないことがポイントです。VaR(Value at Risk)のようなリスク指標を計算するために、正規化済みのポジションデータが必要です。以下はVaR計算用データマートのSQL例です。
-- VaR計算用エクスポージャーマート
CREATE OR REPLACE TABLE mart.risk_exposure_daily AS
SELECT
business_date,
portfolio_id,
instrument_type,
currency,
SUM(notional_amount) AS notional_sum,
SUM(market_value) AS market_value_sum,
COUNT(*) AS position_count
FROM stg.positions_normalized
WHERE status = 'active'
GROUP BY business_date, portfolio_id, instrument_type, currency;不正検知基盤の設計
不正検知は、金融データ基盤で最も鮮度要件が厳しい領域です。クレジットカードの不正利用や口座の不正アクセスは、秒単位で検知できなければ被害が拡大します。一方、マネーロンダリング対策(AML)は日次バッチでも通用する場合があります。用途ごとに処理方式を使い分ける必要があります。
| 観点 | バッチ型不正検知 | リアルタイム不正検知 |
|---|---|---|
| 処理方式 | 日次〜時次バッチ | ストリーミング(Kafka+Flink等) |
| 検知遅延 | 数時間〜1日 | 数十ミリ秒〜数秒 |
| 実装コスト | 低〜中 | 高 |
| 運用負荷 | 低〜中 | 高 |
| 適するユースケース | AML、内部不正監視 | カード取引、オンラインバンキング |
| 検知手法 | ルール＋MLバッチスコアリング | ルール＋インメモリMLモデル |
リアルタイム不正検知の実装では、Kafkaで取引イベントを受け、Flinkやksqlでルールエンジンと機械学習モデルを組み合わせてスコアリングする構成が標準的です。ルールベースで「既知のパターン」をブロックしつつ、MLモデルで「未知のパターン」を検出するハイブリッドアプローチが現実解です。モデルの再学習には過去データが必要になるため、バッチ型のデータ基盤と相互補完する設計になります。不正検知基盤と一般分析基盤は、データは共有するがクエリ経路を分離する「リード/ライトの分離」が有効です。
監査証跡とデータリネージ
金融データ基盤で最も工数がかかるのが、監査証跡とデータリネージの整備です。規制当局や監査法人から「この報告の数字はどこから来たのか」と問われた際、ソースから変換、加工、集計までを完全に辿れる必要があります。これを実現するには、大きく3つの層でリネージを記録します。
まずテーブル/カラムレベルのリネージは、dbtやOpenLineageで自動取得します。dbtはmanifest.jsonから変換の依存関係を可視化でき、どのモデルがどのソースから作られているかを一覧化できます。次にジョブ実行のリネージは、Airflow等のワークフローエンジンが保持するDAGとタスクログから取得します。最後にクエリレベルのリネージは、DWHのクエリ履歴(BigQueryのINFORMATION_SCHEMA.JOBSなど)から抽出し、誰がいつどのテーブルをどう参照したかを記録します。これら3層を統合し、監査官が必要な粒度で即座に追跡できる状態を作ることが、金融データ基盤の「静かな品質要件」と言えます。個人情報保護法対応についても併せて設計すると漏れが減ります。
クラウド移行の課題と対策
近年、金融業界でもクラウドDWHの採用が進んでいます。BigQuery、Snowflake、Databricks、Redshiftなど、主要な選択肢はいずれも金融グレードのセキュリティ認証を取得しています。それでも、オンプレからクラウドへ移行する際にいくつかの壁があります。
最大の課題はFISCガイドラインへの準拠です。金融機関がクラウドを利用する際の安全対策基準が定められており、事前評価・契約管理・監査権の確保・データ所在地の明示といった項目をクリアする必要があります。次にデータの暗号化――顧客自身が管理する鍵(CMEK)を使い、クラウド事業者すら復号できない構成にすることが推奨されます。さらに、監査法人の要求事項(データの不可逆性・アクセスログの網羅性)を満たすための設定もクラウドベンダーごとに事前検証が必要です。これらは設計段階で確認しないと、後から構成変更が極めて高コストになるため、要件定義フェーズで法務・リスク管理部門とともに詰めておくべき事項です。権限管理の記事も参考にしてください。
まとめ
金融業界のデータ基盤は、リスク管理・不正検知・規制対応の3つを土台に設計し、その上に監査証跡とクラウド移行の論点を重ねる多層構造です。規制要件を前提とした「削除しない・改ざんできない・追跡できる」の3原則を守れば、クラウド活用とコンプライアンスの両立は十分可能です。近接領域の設計は製造業データ基盤やエンタープライズのデータ基盤も参考になります。
よくある質問
金融データ基盤でクラウドは使えますか?
使えます。金融庁のガイドラインおよびFISCガイドラインに準拠した上でクラウドDWHを利用する金融機関は増加しています。ただし、データ所在地、暗号化鍵管理、マルチテナント分離、監査権の確保などの確認が必須です。事前評価を法務・リスク管理部門と合同で行ってください。
リアルタイム不正検知にはどのような技術が必要ですか?
ストリーミング処理(Kafka+Flink等)によるリアルタイムスコアリングと、ルールエンジン+MLモデルのハイブリッド検知が標準的なアプローチです。ルールで既知パターン、MLで未知パターンを捕捉する分担設計が効果的です。
金融規制対応で最も工数がかかる部分は?
データリネージの整備です。規制当局への報告データが「どのソースから、どの変換を経て作られたか」を完全に追跡可能にする必要があります。dbtやOpenLineageを使って変換の依存関係を自動記録し、クエリ履歴と統合して監査官が即座に遡れる状態を作ることが重要です。