LabHub

ブログ

オープンバンキングとマイデータAPIアーキテクチャ — 金融データ開放の技術

2026-06-13 · 29 分で読めます · #finance#open-banking#mydata#api#oauth2#fapi#architecture

한국어English日本語

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

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

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

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

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

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

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

  フィンテックアプリ/利用機関        金融決済院              参加金融会社
  ┌──────────────┐   標準API    ┌──────────────┐   対外系   ┌──────────┐
  │ サービスサーバー │ ───────────▶ │ オープンバンキング │ ────────▶ │  A 銀行   │
  │  (利用機関)    │ ◀─────────── │  中継システム    │ ◀──────── │  B 銀行   │
  └──────────────┘  応答/コールバック └──────────────┘            │  C 貯蓄銀行│
                                       │                      └──────────┘
                                       ├─ 認証(トークン発行/検証)
                                       ├─ 取引中継・電文変換
                                       ├─ 利用機関管理・課金
                                       └─ 機関間決済

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

API分類代表API特徴
照会残高照会、取引明細照会、口座実名照会読み取り専用、比較的単純
振込入金振込、出金振込資金移動、冪等性・照合が必須
管理口座登録・解約、トークン管理同意・登録のライフサイクル

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

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

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

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

   顧客 ──(伝送要求+統合認証)──▶ マイデータ事業者アプリ
                                      │
                                      │ 標準API (REST, JSON)
                                      ▼
            ┌─────────────┬───────────────┬─────────────┐
            │ 銀行(情報提供者) │ カード会社(情報提供者) │ 証券会社(情報提供者) │
            └─────────────┴───────────────┴─────────────┘
                                      │
            支援: 総合ポータル(支援センター)、認証中継、標準仕様の管理

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

標準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": "給与"
    }
  ]
}

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

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

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

観点韓国(オープンバンキング/マイデータ)英国(Open Banking)EU(PSD2)
推進方式中継機関中心の共同網+法定の伝送要求権規制当局主導、標準化機関(OBIE)を設立指令(Directive)ベース、加盟国別に実施
接続構造中央中継ハブを経由機関別APIへの直接接続+ディレクトリ機関別API、標準は市場主導(Berlin Groupなど)
認証標準統合認証+機関別トークンOAuth 2.0+FAPIプロファイル強力な顧客認証(SCA)を要求
対象範囲口座・決済から全業種の信用情報へ拡大決済口座が中心決済口座・決済サービスが中心

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

韓国の標準も証明書ベースの相互認証と電文署名を要求している点で、目指す方向は同じです。新たにシステムを設計するなら、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 数十機関」のトークンと収集スケジュールを管理することです。

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

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

# 定期伝送収集スケジューラの骨格 (概念例)
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)

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

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

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

層要求事項実装手段
伝送区間区間暗号化、強い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                    -- 認証記録などの証跡参照
);

設計原則です。

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

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

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

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

  標準APIレスポンス(機関別の原本)
        │  そのまま保存 (原本の不変保存 — 再処理可能性の確保)
        ▼
  raw_records (機関別スキーマのまま)
        │  正規化: コードマッピング、金額精度の統一、タイムゾーン統一、
        │          重複排除(重なり区間)、加盟店名のクレンジング
        ▼
  canonical_transactions (サービス共通モデル)
        │
        ▼
  サービス機能 (資産照会、消費分析、信用管理 ...)

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

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

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

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

   CLOSED (正常)
     │  失敗率 > 50% (直近100件) または連続タイムアウトN回
     ▼
   OPEN (遮断: 即時失敗応答、キューのタスクは繰越)
     │  クールダウン経過 (例: 60秒)
     ▼
   HALF-OPEN (探索呼び出しを少量許可)
     ├─ 成功継続 ──▶ CLOSEDへ復帰
     └─ 失敗 ──▶ OPENへ再突入 (クールダウン増加)

ビジネス活用と限界

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

可能になったことです。

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

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

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

設計チェックリスト

おわりに

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

参考資料

コメント

まだコメントはありません。

ログインするとコメントできます