💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

はじめに — 口座情報が銀行の塀を越えるまで

1つのフィンテックアプリで複数銀行の残高を一度に照会し、どの銀行口座へも送金できる体験は、いまや当たり前になりました。しかしこの当たり前の裏側には、標準API、中継機関、認証体系、同意管理、機関間決済という巨大なインフラがあります。

この記事では、韓国のオープンバンキング共同網とマイデータ(本人信用情報管理業)のアーキテクチャを中心に、金融データ開放を支える技術構造を見ていきます。データを提供する金融会社側と、データを利用するフィンテック側の双方の実装観点を扱い、英国オープンバンキング・PSD2・FAPIといったグローバル標準との比較も交えます。

この記事は公開された制度・標準の構造を技術的観点から整理した資料であり、特定機関の内部仕様や法律解釈に関する助言ではありません。実際の事業推進の際は、最新の規制と公式ガイドラインを必ずご確認ください。

韓国オープンバンキングの構造 — 共同網と中継機関

韓国オープンバンキングの最大の特徴は、**中央中継機関(金融決済院)モデル**です。フィンテック企業が銀行ごとに個別契約・個別連携を行う代わりに、金融決済院のオープンバンキング共同業務システムへ一度接続すれば、参加機関全体と通信できます。

[韓国オープンバンキング共同網の構造]

フィンテックアプリ/利用機関金融決済院参加金融会社

┌──────────────┐ 標準API ┌──────────────┐ 対外系 ┌──────────┐

│ サービスサーバー │ ───────────▶ │ オープンバンキング │ ────────▶ │ A 銀行 │

│ (利用機関) │ ◀─────────── │ 中継システム │ ◀──────── │ B 銀行 │

└──────────────┘ 応答/コールバック └──────────────┘ │ C 貯蓄銀行│

│ └──────────┘

├─ 認証(トークン発行/検証)

├─ 取引中継・電文変換

├─ 利用機関管理・課金

└─ 機関間決済

オープンバンキングAPIは大きく照会と振込の2軸に分かれます。

| API分類 | 代表API | 特徴 |

| --- | --- | --- |

| 照会 | 残高照会、取引明細照会、口座実名照会 | 読み取り専用、比較的単純 |

| 振込 | 入金振込、出金振込 | 資金移動、冪等性・照合が必須 |

| 管理 | 口座登録・解約、トークン管理 | 同意・登録のライフサイクル |

このうち最も厄介なのが**出金振込**です。利用機関のリクエストで顧客口座からお金が引き落とされる構造のため、事前の出金同意登録、取引限度額、そして応答タイムアウト時の未確認取引処理(前回の元帳の記事で扱ったUNKNOWN状態と照合)がすべて必要になります。

マイデータのアーキテクチャ — 伝送要求権の技術的実装

マイデータ(本人信用情報管理業)は、個人が自分の信用情報を「ここからあそこへ送れ」と要求できる**個人信用情報の伝送要求権**を技術的に実装した制度です。オープンバンキングが口座中心の照会・振込だとすれば、マイデータは銀行・カード・保険・証券・通信など幅広い業種の情報を標準APIで収集する体系です。

[マイデータの情報フロー]

顧客 ──(伝送要求+統合認証)──▶ マイデータ事業者アプリ

│

│ 標準API (REST, JSON)

▼

┌─────────────┬───────────────┬─────────────┐

│ 銀行(情報提供者) │ カード会社(情報提供者) │ 証券会社(情報提供者) │

└─────────────┴───────────────┴─────────────┘

│

支援: 総合ポータル(支援センター)、認証中継、標準仕様の管理

核心となる構成要素は次の通りです。

- **統合認証**: 顧客が機関ごとにログインせず、統合された本人確認(証明書ベース)で複数の情報提供者への伝送要求を一度に処理します。

- **情報提供API**: 業種別の標準仕様(口座一覧、取引明細、カード請求、保険契約など)で定義されたREST APIです。

- **伝送要求の管理**: 顧客の伝送要求の内容(対象機関、情報範囲、保有期間)を管理し、撤回時に収集を停止するライフサイクルです。

- **定期的伝送**: 顧客が同意した範囲で、事業者が周期的に(例: 日次)情報を更新収集するスケジューリング体系です。

標準API仕様の形 — リクエストとレスポンス

マイデータ・オープンバンキング系の標準APIは、共通して次のような形をしています。実際の仕様のフィールド名はバージョンによって異なるため、構造理解のための簡略化した例としてご覧ください。

トークン発行(OAuth 2.0認可コード方式ベース)はおおよそ次のフローです。

POST /oauth/2.0/token HTTP/1.1

Host: api.provider.example

Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code

&code=AUTH_CODE_FROM_CONSENT_FLOW

&client_id=CLIENT_ID

&client_secret=CLIENT_SECRET

&redirect_uri=https://app.example/callback

{

"token_type": "Bearer",

"access_token": "eyJhbGciOiJSUzI1NiIs...",

"expires_in": 3600,

"refresh_token": "rt_8f14e45fceea167a...",

"scope": "bank.read card.read"

}

口座取引明細照会のリクエスト・レスポンスの簡略化した例です。

GET /v1/accounts/transactions?account_num=110-123-456789&from_date=20260601&to_date=20260613&limit=100 HTTP/1.1

Host: api.provider.example

Authorization: Bearer eyJhbGciOiJSUzI1NiIs...

x-api-tran-id: M2026061300001234567890

{

"rsp_code": "00000",

"rsp_msg": "success",

"search_timestamp": "20260613091500",

"next_page": "",

"trans_list": [

{

"trans_dtime": "20260612143015",

"trans_type": "03",

"trans_class": "出金",

"trans_amt": "50000",

"balance_amt": "1250000",

"trans_memo": "コーヒーショップ決済"

{

"trans_dtime": "20260611090000",

"trans_type": "02",

"trans_class": "入金",

"trans_amt": "3000000",

"balance_amt": "1300000",

"trans_memo": "給与"

}

]

}

仕様を読む際の実務上の注意点です。

- **取引固有番号ヘッダ**: すべてのリクエストに、利用機関が生成する取引トレースIDが入ります。障害追跡と機関間照合の基準点になるため、生成ルール(機関コード+日付+連番)を正確に守る必要があります。

- **金額が文字列**: 標準電文の多くが金額を文字列として扱います。パース時は十進精度型へ変換し、絶対に浮動小数点を経由しません。

- **ページング規約**: next_pageトークン方式と基準日時方式が混在しています。「最終ページ判定」の実装を誤ると取引明細の欠落が発生します。

- **レスポンスコードの二重化**: HTTPステータスコードと本文のrsp_codeは別物です。HTTP 200に業務エラーコードが載ってくるケースを必ず処理しなければなりません。

グローバル比較 — 英国オープンバンキング、PSD2、FAPI

韓国モデルをより深く理解するには、グローバル標準との比較が有効です。

| --- | --- | --- | --- |

技術的に最も参考になるのは**FAPI(Financial-grade API)セキュリティプロファイル**です。OpenID Foundationが定義した金融水準のAPIセキュリティ標準で、通常のOAuth 2.0に対して次を要求します。

- **相互TLS(mTLS)またはDPoPによる送信者拘束トークン**: トークンを窃取しても、クライアント証明書なしでは使用できません。

- **PAR(Pushed Authorization Requests)**: 認可リクエストのパラメータをフロントチャネルのURLではなくバックチャネルで渡し、改ざんを防ぎます。

- **署名付きリクエスト・レスポンス(JAR、JARM)**: 認可リクエストとレスポンス自体をJWTとして署名します。

- **PKCEの必須化、脆弱なフローの禁止**: インプリシットフローのような脆弱なパターンを禁止します。

韓国の標準も証明書ベースの相互認証と電文署名を要求している点で、目指す方向は同じです。新たにシステムを設計するなら、FAPI 2.0 Security Profileをベースラインに据えるのが安全です。

提供側の実装 — APIゲートウェイ、流量制御、課金

銀行のような情報提供者から見ると、オープンバンキング・マイデータは「外部から入ってくる大量の照会トラフィック」です。行内チャネルとは異なる特性を理解する必要があります。

[提供側のリファレンスアーキテクチャ]

中継機関/利用機関

│

▼

┌────────────────────────────────────────────┐

│ APIゲートウェイ │

│ - クライアント認証(mTLS、証明書検証) │

│ - トークン検証、スコープ確認 │

│ - 流量制御(機関別/API別 rate limit) │

│ - 取引ID検証・ロギング │

└────────────────────────────────────────────┘

│

▼

┌────────────────┐ ┌──────────────────┐

│ オープンAPIサービス層 │ ─▶ │ 照会専用データ層 │ ◀─ 勘定系からCDC/バッチ複製

│ (変換・組み立て) │ │ (read replica/キャッシュ)│

└────────────────┘ └──────────────────┘

│ 振込系取引のみ

▼

勘定系 (元帳)

核心となる設計ポイントです。

1. **照会と元帳の分離**: マイデータの定期伝送は深夜時間帯にトラフィックが集中する特性があります。この照会負荷が勘定系の元帳DBを直撃しないよう、照会専用レプリカやキャッシュ層で吸収します。振込系APIだけが勘定系経路を通ります。

2. **流量制御**: 利用機関別・API別の呼び出し上限をゲートウェイで強制します。特定事業者の暴走がサービス全体へ波及しないようにする第一の防衛線です。

3. **課金・統計**: オープンバンキングAPIには件数ベースの手数料体系があるため、課金の根拠となる呼び出し記録を欠損なく蓄積する必要があります。課金データと運用ログは目的が異なるため、分離して設計します。

4. **スキーマのバージョン管理**: 標準仕様の改定時には新旧バージョンの並行期間があります。URLバージョニングと、フィールド追加に寛容なパーサーポリシーが必要です。

利用側の実装 — トークン管理と定期的伝送

フィンテック・マイデータ事業者側の難題は、「数百万ユーザー x 数十機関」のトークンと収集スケジュールを管理することです。

まず**トークン管理**から見ていきます。

- ユーザーと機関のペアごとにアクセストークンとリフレッシュトークンが存在します。トークンの暗号化保存(保存時暗号化+鍵管理)が基本です。

- アクセストークンの期限切れは正常フローなので、401応答時にリフレッシュして1回だけ再試行するパターンを標準化します。

- リフレッシュトークンまで失効・撤回された場合、自動復旧は不可能です。ユーザーに再同意を求める状態へ遷移させ、その状態をUXで明確に見せる必要があります。

**定期的伝送のスケジューリング**は、一種の分散クローリング設計です。

定期伝送収集スケジューラの骨格 (概念例)

def schedule_daily_collection(users, providers, window_start, window_end):

"""機関別の呼び出し上限と時間枠を守りつつ収集タスクを分散する。"""

tasks = []

for user in users:

for p in user.consented_providers:

tasks.append(CollectTask(user_id=user.id, provider=p))

1) 機関別にグループ化 → 機関別の同時実行上限を適用

2) 時間枠内に均等分散(特定の分に集中しないようジッターを付与)

3) 失敗タスクは指数バックオフで再試行、上限超過は次周期へ繰越

for provider, group in group_by_provider(tasks):

limit = provider.rate_limit # 例: 毎秒50件

for i, task in enumerate(group):

task.scheduled_at = spread_with_jitter(

window_start, window_end, i, len(group))

task.max_retries = 3

enqueue(task, concurrency_key=provider.code, limit=limit)

運用で学ぶことになるポイントです。

- **収集時間枠の社会的合意**: 全員が午前0時直後に収集すると、提供者のシステムが同時に叩かれます。標準が定めた定期伝送の時間帯を守り、その中でもジッターを付与します。

- **差分収集**: 毎回全期間を取り直すのではなく、最終収集時点以降のみをリクエストします。ただし提供側の反映遅延(昨日の取引が今日追加される)を考慮し、重なり区間を設けて重複排除します。

- **部分失敗は正常状態**: 20機関のうち1つは常にメンテナンス中か低速です。「全機関の収集完了」を前提にしたUXではなく、機関別の更新時刻を見せるUXが現実的です。

セキュリティ要件 — 伝送区間、証明書、クライアント認証

金融データ開放体系のセキュリティは多層で構成されます。

| 層 | 要求事項 | 実装手段 |

| --- | --- | --- |

| 伝送区間 | 区間暗号化、強いTLS設定 | TLS 1.2以上、最新の暗号スイート |

| クライアント認証 | 機関のアイデンティティの暗号学的証明 | mTLSクライアント証明書、専用線/VPNの併用 |

| メッセージ | 電文の改ざん防止 | 電子署名、取引IDとタイムスタンプの検証 |

| トークン | 窃取トークンの再利用防止 | 送信者拘束(mTLSバインディング)、短い有効期限 |

| 保存 | 収集情報・トークンの保護 | 保存時暗号化、鍵の分離保管、アクセス統制 |

| 運用 | 異常兆候の検知 | 呼び出しパターンの異常検知、証明書期限の監視 |

実務で意外と頻発する事故は、派手なハッキングではなく**証明書の期限切れ**です。機関間mTLS証明書、署名用証明書、TLSサーバー証明書の有効期限を資産台帳として管理し、期限30日前のアラートと交換リハーサルを運用ルーチンに組み込むべきです。

同意管理システムの設計 — 同意はデータである

マイデータの法的基盤は顧客の同意であるため、同意そのものが第一級のデータモデルでなければなりません。

-- 同意(伝送要求)モデルの例

CREATE TABLE consents (

consent_id UUID PRIMARY KEY,

user_id BIGINT NOT NULL,

provider_code VARCHAR(10) NOT NULL, -- 情報提供者

scope_codes TEXT[] NOT NULL, -- 同意した情報範囲

purpose_code VARCHAR(10) NOT NULL, -- 収集・利用目的

granted_at TIMESTAMPTZ NOT NULL,

expires_at TIMESTAMPTZ NOT NULL, -- 同意の有効期間

revoked_at TIMESTAMPTZ, -- 撤回時刻

status VARCHAR(10) NOT NULL -- ACTIVE, EXPIRED, REVOKED

);

-- 同意履歴: すべての状態変化を追記専用で記録

CREATE TABLE consent_events (

event_id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,

consent_id UUID NOT NULL REFERENCES consents(consent_id),

event_type VARCHAR(20) NOT NULL, -- GRANTED, RENEWED, REVOKED ...

event_at TIMESTAMPTZ NOT NULL DEFAULT now(),

channel VARCHAR(20) NOT NULL,

evidence_ref TEXT -- 認証記録などの証跡参照

);

設計原則です。

- **撤回の伝播**: 顧客が同意を撤回したら、(1) 収集スケジュールの停止、(2) トークン失効のリクエスト、(3) 保有期間ポリシーに従ったデータ削除・分離保管、が連鎖的に実行されなければなりません。撤回イベントを発行し、各サブシステムが購読するイベントドリブンな伝播が漏れに強い構造です。

- **証跡の保管**: 「顧客がいつ、どの画面で、何に同意したのか」を再構成できる必要があります。同意時点の規約バージョンと認証記録への参照を併せて残します。

- **期限処理の能動性**: 同意の期限が近づいたらユーザーに更新を案内し、期限切れの同意では1件の呼び出しも出ないよう、収集機の手前で同意状態を強制します。

データ標準化の問題 — 機関別のばらつきと正規化レイヤー

標準APIだからといってデータが均質とは限りません。同じ仕様でも、機関ごとの解釈とデータ品質にばらつきがあります。

- 取引種別コードの細分化レベルが機関ごとに異なります。

- 摘要(メモ)フィールドのフォーマットがバラバラで、加盟店名の抽出品質が異なります。

- 残高・金額の反映時点(リアルタイム vs 前日締め基準)が異なることがあります。

- 同じ取引が機関Aでは1件、機関Bでは承認・売上確定の2件として見えることもあります。

したがって利用側のアーキテクチャには、**原本保存+正規化レイヤー**の2層構造が必要です。

[収集データの正規化パイプライン]

標準APIレスポンス(機関別の原本)

│ そのまま保存 (原本の不変保存 — 再処理可能性の確保)

▼

raw_records (機関別スキーマのまま)

│ 正規化: コードマッピング、金額精度の統一、タイムゾーン統一、

│ 重複排除(重なり区間)、加盟店名のクレンジング

▼

canonical_transactions (サービス共通モデル)

│

▼

サービス機能 (資産照会、消費分析、信用管理 ...)

原本を保存する理由は、正規化ロジックが進化し続けるからです。加盟店名クレンジングのルールを改善したとき、原本があれば全体の再処理が可能ですが、正規化結果しか残していなければ後戻りできません。

障害と品質管理 — 機関別SLAとサーキットブレーカー

数十の機関と連携するシステムでは、「全体障害」より「1機関の部分障害」の方がはるかに頻繁です。

- **機関別ヘルス状態の管理**: 機関単位で成功率・レイテンシをスライディングウィンドウで集計し、しきい値を超えたらその機関への呼び出しだけを遮断(サーキットオープン)します。

- **ハーフオープンでの探索**: 遮断後一定時間が経過したら、少量の探索呼び出しで回復を確認し、段階的に復旧します。

- **タイムアウト予算**: ユーザーリクエスト経路で複数機関を照会する場合、全体の応答予算(例: 3秒)の中で機関別タイムアウトを短く設定し、遅い機関は「更新中」と表示してバックグラウンドで再試行します。

- **メンテナンスカレンダーの反映**: 金融機関は定期メンテナンスの時間帯を機関別に告知します。メンテナンス時刻表を収集機に反映すれば、不要な失敗とアラートを減らせます。

[機関別サーキットブレーカーの状態マシン]

CLOSED (正常)

│ 失敗率 > 50% (直近100件) または連続タイムアウトN回

▼

OPEN (遮断: 即時失敗応答、キューのタスクは繰越)

│ クールダウン経過 (例: 60秒)

▼

HALF-OPEN (探索呼び出しを少量許可)

├─ 成功継続 ──▶ CLOSEDへ復帰

└─ 失敗 ──▶ OPENへ再突入 (クールダウン増加)

ビジネス活用と限界

最後に、このインフラの上で何が可能になり、何が依然として難しいのかを整理します。

可能になったことです。

- 複数機関に散らばった資産の統合照会とリバランス提案

- 取引データに基づく消費分析、サブスクリプション管理、キャッシュフロー予測

- 非金融信用情報の結合によるシンファイラー(thin filer)の信用評価改善

- 口座ベースの簡単送金・収納(オープンバンキング振込API)

依然として難しいことです。

- **リアルタイム性の限界**: 定期伝送の周期と機関別の反映遅延のため、「今この瞬間」の完全なスナップショットは保証されません。

- **データ品質の下限**: 正規化レイヤーがどれほど優れていても、原データの品質を超えることはできません。

- **収益モデル**: 照会API呼び出しにはコストがかかり、データそのものは差別化要素ではなくなりました。差別化はデータの上の分析・体験から生まれます。

- **規制変化への対応**: 仕様改定、認証ポリシーの変化、課金体系の変更が周期的に発生するため、標準の変化に素早く追随する組織能力そのものが競争力です。

テスト戦略 — テストベッドと機関シミュレーター

連携テストにも戦略が必要です。

- **公式テストベッドの活用**: 中継機関と標準運営主体が提供するテスト環境で、認証・電文規格の適合性を先に検証します。本番証明書とテスト証明書の分離管理に注意します。

- **機関シミュレーターの内製**: すべての統合テストを外部テストベッドに依存すると、CIが遅く不安定になります。標準仕様どおりに応答するモック(mock)サーバーを作り、遅延・タイムアウト・業務エラーコード・異形レスポンス(空配列、欠落フィールド)のシナリオを注入できるようにします。

- **契約テスト**: 仕様改定時に既存パーサーが壊れないか、レスポンススキーマの変化を契約(contract)テストで捕捉します。「フィールド追加には寛容に、フィールドの意味変化には敏感に」が原則です。

- **カオスシナリオ**: 1機関の全面障害、全機関の遅延2倍、トークンの大量失効といったシナリオで、サーキットブレーカーとキューの繰越が設計どおりに動作するかを定期的に検証します。

設計チェックリスト

- [ ] 取引トレースIDの生成ルールが標準に正確に従い、全区間でロギングされているか

- [ ] 金額のパースが浮動小数点を経由していないか

- [ ] HTTPステータスと業務応答コードの二重処理(200+エラーコード)が実装されているか

- [ ] ページング終了判定と重なり区間の重複排除が検証されているか

- [ ] トークンが暗号化保存され、401リフレッシュ再試行パターンが標準化されているか

- [ ] リフレッシュ不能状態が再同意リクエストのUXへつながっているか

- [ ] 同意モデルが履歴・証跡・期限・撤回を第一級として扱っているか

- [ ] 撤回時に収集停止、トークン失効、データ処理(削除・分離保管)が伝播するか

- [ ] 原本保存+正規化レイヤーの2層構造になっているか

- [ ] 機関別rate limit、サーキットブレーカー、メンテナンスカレンダーが収集機に反映されているか

- [ ] 定期伝送が時間枠内のジッター分散で設計されているか

- [ ] mTLS・署名・TLS証明書の期限が資産として管理されアラートがあるか

- [ ] 提供者の場合: 照会負荷が元帳DBと分離されているか

- [ ] 提供者の場合: 課金根拠となる呼び出し記録が欠損なく蓄積されているか

おわりに

オープンバンキングとマイデータは「APIをいくつか連携するだけ」に見えますが、実際には認証・同意・標準化・障害管理・決済が噛み合った分散システムの設計問題です。特に同意管理と機関別の品質ばらつきは、開始前には過小評価され、運用後には最も多くの時間を奪っていく領域です。この記事の構造 — 中継モデルの理解、FAPI水準のセキュリティベースライン、原本保存と正規化の分離、機関単位の障害隔離 — を出発点にすれば、データ開放時代のシステムを一段と堅牢に設計できるはずです。

参考資料

- 韓国金融決済院(KFTC): https://www.kftc.or.kr/

- オープンバンキング共同業務(金融決済院運営): https://www.openbanking.or.kr/

- マイデータ総合ポータル: https://www.mydatacenter.or.kr/

- 韓国金融委員会(FSC): https://www.fsc.go.kr/

- 韓国金融監督院(FSS): https://www.fss.or.kr/

- 韓国金融保安院: https://www.fsec.or.kr/

- UK Open Banking: https://www.openbanking.org.uk/

- OpenID Foundation — FAPI Working Group: https://openid.net/wg/fapi/

- FAPI 2.0 Security Profile: https://openid.net/specs/fapi-security-profile-2_0.html

- OAuth 2.0 (RFC 6749): https://datatracker.ietf.org/doc/html/rfc6749

- OAuth 2.0 mTLS (RFC 8705): https://datatracker.ietf.org/doc/html/rfc8705

- EU PSD2 (Directive 2015/2366): https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32015L2366