オープンバンキング・PSD3・Open Finance 2026 — Plaid・TrueLayer・Tink・Yapily・Belvo・金融決済院・全銀協 徹底ガイド

プロローグ — PSD2の8年、そして2026年に開くPSD3

2018年1月にEUでPSD2(Payment Services Directive 2)が施行されたとき、銀行業界の反応は二つに割れた。「外部の会社がうちの口座データを取りに来るのか?」と「これは結局スタンダードになる」だ。8年が経った2026年、後者が正しかった。EUは2026年からPSD3 + PSR(Payment Services Regulation)を段階施行し、FIDA(Financial Data Access Regulation)が通過してOpen BankingはOpen Financeへと拡張する。

米国ではPlaid・Finicity(Mastercard)・MX・AkoyaがFDX(Financial Data Exchange)標準の上で競う。英国・EUではTrueLayer・Tink(Visa子会社)・Yapily・Salt Edgeが、LatAmはBelvoが、インドはAccount Aggregator(Sahamati)が同じ位置を埋める。韓国は金融決済院のオープンバンキングAPIとマイデータ事業が5年目に入り、日本は全銀協(全国銀行協会)の銀行APIガイドラインが義務化段階に入る。

本稿の目的は一つ — 2026年のオープンバンキング・Open Financeを一気に理解することだ。標準(PSD3・FIDA・FDX・FAPI)、ライセンス(AISP・PISP・PIP)、セキュリティ(SCA・ダイナミックリンク)、インフラ(アグリゲーター)、そして韓国・日本の市場構造まで。

第1章 · 用語整理 — AISP・PISP・CBPII・SCA・FAPI

オープンバンキングは略語が多い。整理するとこうなる。

PSD2時代はRTSとeIDAS証明書が通信の身元を保証した。PSD3はそこにFAPI 2.0とより強い不正防止義務を組み合わせる。

第2章 · PSD2(2018) → PSD3 + PSR(2026) — 何が変わるか

PSD2の最大の限界は二つだった — (1)加盟国別のRTS解釈差で統合市場が成立しなかった、(2)AISP/PISPが銀行APIの品質ばらつきに苦しんだ。PSD3はこれを正面から打開する。

PSD3 + PSR(Payment Services Regulation)の主な変更点:

• 単一市場の統合: PSRがregulation(directiveではない)の形なので加盟国が直接適用。
• API品質義務: 銀行がdedicated interface(スクリーンスクレイピング禁止)を運用、ダウンタイム報告、KPI公示。
• 不正責任の分担: AISP・PISP・銀行間の不正損失分担ルールを明文化。
• AISP/PISPライセンス統合: 単一のPSP(Payment Service Provider)ライセンスへ統合。
• SCA例外の拡大: 小額・定期・trusted beneficiaryなどの例外を整理。
• ダイナミックリンクの強化: 決済金額・受取人が認証トークンに結合される必要。

2026年1月にPSRが第一段適用開始、2027-2028年にPSD3の加盟国転換完了が日程だ。実務上の重要点はAPI SLAとKPI公示だ。銀行が壊れたAPIを放置できなくなる。

第3章 · FIDA — Open BankingからOpen Financeへ

FIDA(Financial Data Access Regulation)は2025年にEU議会を通過し、2026年に施行段階へ入る。核心は金融データ共有の範囲を決済・口座から保険・年金・投資・住宅ローンへと拡張することにある。

PSD3が決済・口座なら、FIDAはそれ以外のすべての金融データだ。義務共有対象:

• 住宅ローン・消費者ローンの残高・返済スケジュール
• 預金・定期預金・MMF
• 保険 — 終身・自動車・住宅・旅行
• 年金 — 私的年金、職場年金
• 投資・証券口座 — 残高・約定・評価
• 暗号資産保有(MiCAと連携)

FIDAの新概念は**FISP(Financial Information Service Provider)だ。AISPが決済・口座だったとすれば、FISPはそれ以外の領域を担う。そしてFIDP(Financial Data Provider)**がデータ提供側だ。

規制面でFIDAはより明確な対価モデルを導入する — FIDPがデータ提供時に合理的な手数料を受け取れる。PSD2が無償だったのとは異なる。これは銀行・保険・年金事業者がAPIを運用するインセンティブを生む。

第4章 · Plaid — 米国オープンバンキングの標準となった会社

Plaidは2013年にサンフランシスコで始まった。Venmo・Robinhood・Acornsのようなフィンテックの銀行接続インフラとして定着し、2026年現在、米国・カナダ・EUで $50B transactions 規模のデータを処理する(自社開示推定)。

Plaid製品ライン:

• Plaid Link: ユーザーが自分の銀行を選びOAuth/credentialで接続するウィジェット。
• Transactions API: 取引履歴の取得。
• Auth: 口座・ルーティング番号確認。
• Identity: KYC用本人確認。
• Balance: リアルタイム残高。
• Income: 所得検証。
• Assets: 資産レポート(融資審査用)。
• Liabilities: 学生ローン・クレジットカード・住宅ローン残高。
• Investments: 証券口座の保有銘柄・約定。
• Signal: ACH不正リスクスコア。

Plaid LinkのJavaScript使用例(概念コード):

// Plaid Link — クライアント側フロー
const handler = Plaid.create({
  token: linkToken,            // サーバーで事前生成したlink_token
  onSuccess: async (publicToken, metadata) => {
    // クライアントはpublicTokenのみ受け取る。
    // publicTokenをサーバーに送りaccess_tokenと交換。
    await fetch('/api/plaid/exchange-public-token', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ public_token: publicToken })
    })
  },
  onExit: (err, metadata) => {
    if (err) console.error('plaid_exit', err)
  },
  onEvent: (eventName, metadata) => {
    // OPEN, SELECT_INSTITUTION, SUBMIT_CREDENTIALS, HANDOFF, ERROR ...
  }
})
handler.open()

サーバー側のトークン交換:

// サーバー — public_token → access_token 交換
import { Configuration, PlaidApi, PlaidEnvironments } from 'plaid'

const client = new PlaidApi(new Configuration({
  basePath: PlaidEnvironments.production,
  baseOptions: {
    headers: {
      'PLAID-CLIENT-ID': process.env.PLAID_CLIENT_ID,
      'PLAID-SECRET': process.env.PLAID_SECRET,
    },
  },
}))

async function exchange(publicToken) {
  const res = await client.itemPublicTokenExchange({ public_token: publicToken })
  // res.data.access_token — ユーザーのaccess token
  // res.data.item_id — Plaid Item識別子
  return res.data
}

2022年のVisaによるPlaid買収が米国DOJの反トラスト調査で破談になって以降、Plaidは独立路線を歩む。2026年のIPOが間近との報道が多い。

第5章 · TrueLayer・Tink・Yapily — UK/EUアグリゲーターBig 3

英国とEUのオープンバンキングインフラは三社が主導する。

• TrueLayer (2016, ロンドン): PISP決済に強い。eBay・Revolut・著名チャリティまで決済チャネルとして使用。AISP + PISP統合。
• Tink (2012, ストックホルム → 2022 Visa買収): EU全域カバレッジ、PFM(個人財務管理)が出発点。Visa買収後はVisa Directと結合し、決済・清算まで統合。
• Yapily (2017, ロンドン): 「ヘッドレス」AISPを標榜。UIなしでAPIのみを提供し、フィンテック自身がUXを作る。

TrueLayerの決済開始(PISP)フロー例:

// TrueLayer — 決済インテント作成(サーバー)
const res = await fetch('https://api.truelayer.com/payments/v3', {
  method: 'POST',
  headers: {
    'Authorization': `Bearer ${accessToken}`,
    'Idempotency-Key': idempotencyKey,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    amount_in_minor: 1099,
    currency: 'GBP',
    payment_method: { type: 'bank_transfer', provider_selection: { type: 'user_selected' } },
    beneficiary: {
      type: 'merchant_account',
      merchant_account_id: 'acc_xxx',
      account_holder_name: 'Example Ltd'
    },
    user: { id: 'usr_123', name: 'Alice', email: 'alice@example.com' }
  })
})
const payment = await res.json()
// payment.resource_token + リダイレクトURLでユーザー認証 → 決済完了

TinkはVisa子会社になってからVisa Direct・CyberSourceと結合して決済・清算インフラをグローバル化した。AISP単体ではTrueLayerに譲るとしても、Visaの体力に乗って他市場(LatAm・アジア)へ拡大中だ。

Yapilyの差別化はホワイトラベルのビジネスモデルだ。すべてのUIをフィンテックが作り、YapilyはAPIコールのみを受ける。これは規制・ライセンス面でフィンテックに自由度を与える一方、UX設計の負担を移す。

第6章 · Belvo・Salt Edge — LatAmとグローバルカバレッジ

• Belvo (2019, メキシコシティ + マドリード): LatAmオープンバンキングの事実標準。メキシコ・ブラジル・コロンビア・チリ・アルゼンチンの銀行API統合。Konfío・Bitso・Clipのようなフィンテックのインフラ。
• Salt Edge (2013, トロント): 「グローバルカバレッジ」を武器。50+ヶ国、5,000以上の金融機関を接続。単一APIでEU・UK・米国・アジア一部・LatAm・中東を扱う。

Belvoの特殊課題の一つはPIX(ブラジルの即時決済システム)連携だ。PIXは中央銀行直営で、EUのSEPA Instantや韓国オープンバンキングの即時振込に相当する。2026年にブラジルの決済インフラがほぼPIXへ移行した後、BelvoはPIX決済開始をPISP方式で提供する。

// Belvo — ブラジルPIX決済開始の例(概念)
const res = await fetch('https://api.belvo.com/payments/payment-intents/', {
  method: 'POST',
  headers: {
    'Authorization': 'Basic ' + btoa(`${secretId}:${secretPassword}`),
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    amount: '49.90',
    currency: 'BRL',
    description: '注文 #12345',
    payment_method_type: 'pix',
    callback_urls: { success: 'https://example.com/ok', error: 'https://example.com/err' },
    customer: { name: 'Maria Silva', email: 'maria@example.com', document_id: '12345678901' }
  })
})

Salt Edgeは「広さ」が武器だ。5,000機関への一貫したデータモデルのために独自分類体系を運用する。これが取引のカテゴライゼーションを可能にする(住居・食費・交通など自動分類)。

第7章 · Finicity・MX・Akoya — 米国のFDX時代

米国はEUと異なる道を歩んできた。政府主導のPSD2がない代わり、市場主導のFDX(Financial Data Exchange)が標準の役割を果たす。2026年、CFPB(Consumer Financial Protection Bureau)の1033条規則発効で本格的な規制段階に入る。

• Finicity (2000, ユタ → 2020 Mastercard買収): 資産検証・所得検証・住宅ローン引受に強い。Mastercard買収後は決済・与信のシナジー。
• MX (2010, ユタ): 銀行・信用組合向けPFMバックエンド。データクリーニング・分類に強い。
• Akoya (2018, ボストン): Fidelityと米大手8銀行の合弁。コンソーシアム型。「銀行が作ったアグリゲーター」のポジション。

CFPBの1033条(Personal Financial Data Rights Rule)は2024年10月に最終発効した。要点:

• 消費者が自分の金融データへの権利を保有。
• データ保有者(銀行)は消費者やその指定TPPに無料でデータを提供しなければならない。
• FDX標準を事実上認定。
• スクリーンスクレイピングの段階的禁止スケジュール。

{
  "fdx_api_version": "6.0",
  "endpoint": "GET /accounts/{accountId}/transactions",
  "permission_scope": "ACCOUNTS_DETAIL_READ TRANSACTIONS_READ",
  "rate_limits": {
    "per_consumer_per_day": 4,
    "burst": 30
  },
  "auth": "OAuth 2.0 + DPoP",
  "data_format": "FDX Common Schema"
}

米国市場は2026年に大きな整理局面にある。スクリーンスクレイピングが縮小し、OAuth/FDX APIが増える。この流れの中でPlaid・Finicity・MX・Akoyaは各々のポジションを固めようとする。

第8章 · FAPI 2.0 — 金融グレードOAuth標準

OAuth 2.0は良いが金融用途には弱い。OpenID Foundationの**FAPI(Financial-grade API)**は金融向けにOAuthを強化した標準だ。2026年、FAPI 2.0が標準となった。

FAPI 2.0の主な強化点:

• PAR (Pushed Authorization Requests): クライアントが認可パラメータをサーバーに事前pushする。URL長・露出問題の解消。
• mTLS または private_key_jwt: クライアント認証の強化。
• DPoP (Demonstrating Proof-of-Possession): アクセストークンをクライアント鍵にバインド。盗難トークンを無力化。
• RAR (Rich Authorization Requests): 細かな権限(金額・受取人・期間)を明示。
• JARM: 応答をJWSで署名。

全体フローの例:

POST /par HTTP/1.1
Host: as.bank.example
Content-Type: application/x-www-form-urlencoded

response_type=code
&client_id=tpp_acme
&redirect_uri=https%3A%2F%2Ftpp.example%2Fcb
&scope=accounts%20payments
&authorization_details=%5B%7B%22type%22%3A%22payment_initiation%22%2C%22amount%22%3A%7B%22currency%22%3A%22EUR%22%2C%22value%22%3A%2299.99%22%7D%2C%22creditor%22%3A%7B%22iban%22%3A%22DE89370400440532013000%22%7D%7D%5D
&code_challenge=...&code_challenge_method=S256
&state=xyz

応答で request_uri を受け取り認可URLを作る。ユーザーは銀行でSCAを行い、コールバックで code を受け取る。これをトークンエンドポイントにmTLS・DPoPと一緒に提示してaccess_tokenを受け取る。

PSD3はFAPI 2.0を事実上推奨し、2027-2028年にはEUのほぼすべてのASPSPがFAPI 2.0互換の認可サーバーを運用すると見られる。

第9章 · SCA — Strong Customer Authentication 整理

SCAはPSD2のセキュリティ核だ。二つの異なる要素を組み合わせる。

• 知識(knowledge): パスワード、PIN。
• 所有(possession): 携帯電話、トークン。
• 本人性(inherence): 生体。

PSD2のSCAは決済・口座アクセスに義務だ。ただし例外(exemption)がある。

PSD3はTRAの強化とAISP 90日再認証の緩和が核だ。90日ごとに強制SCAが必要だったPSD2 RTSのルールが緩み、モバイルアプリ・資産管理アプリのUXが改善する。

ダイナミックリンク(dynamic linking)はSCAのもう一つの核だ。認証トークンが決済金額・受取人を含まなければならない。これはMITM攻撃での決済改竄を防ぐ。

第10章 · 韓国オープンバンキング — 金融決済院の100+のAPI

韓国のオープンバンキングは2019年12月に全面施行された。金融決済院(KFTC)が中央ハブを運用し、銀行・証券・電子金融業者がAPIを通じてアクセスする。

運用状況(2026年基準推定):

• 参加機関: 銀行19、相互金融、貯蓄銀行、郵便局、カード会社、フィンテック。
• 中核API: 残高照会、取引明細照会、出金振替、入金振替、口座実名、受取人照会など100種ほど。
• 利用量: 1日数億件のコール、累積数十兆ウォン規模の振替。
• 費用: 標準手数料がフィンテック参入を低くする。

金融決済院OpenAPIのOAuthフローは、標準OAuth 2.0 +ダイナミッククライアント登録を基盤とする。ダイナミックリンクとSCAも標準化されている。

GET /v2.0/account/balance/fin_num
  ?bank_tran_id=M202612340U001234567
  &fintech_use_num=199912345678901234
  &tran_dtime=20260525120000
Authorization: Bearer {access_token}

応答例:

{
  "api_tran_id": "f1234567-1234-5678-9abc-1234567890ab",
  "rsp_code": "A0000",
  "rsp_message": "正常",
  "bank_code_std": "088",
  "balance_amt": "1250000",
  "available_amt": "1250000",
  "account_type": "1",
  "product_name": "企業自由預金",
  "bank_tran_id": "M202612340U001234567",
  "bank_tran_date": "20260525",
  "api_tran_dtm": "20260525120000123"
}

オープンバンキング標準のおかげでToss・Kakao Bank・Banksalad・Finnqのような会社が短期間で複数銀行口座統合を実装できた。2026年現在、韓国オープンバンキングはEU PSD2と同等の成熟度だが、ライセンス構造は異なる — EUはAISP/PISP、韓国は電子金融業者 + 本人信用情報管理業(マイデータ)。

第11章 · 韓国マイデータ — 本人信用情報管理業

マイデータは2022年1月に本格スタートした。信用情報法改正で作られた本人信用情報管理業が法的根拠だ。2026年現在、マイデータ事業者は60社超を超える。

代表事業者:

• 銀行: 新韓・KB国民・ハナ・ウリィ・NH農協・企業・SCチェイル・DGB・BNK・iM・全北・光州・済州。
• カード: 新韓・サムスン・KB・現代・ロッテ・ウリィ・ハナ・BC・NH。
• フィンテック: Kakao Bank・Toss・Banksalad・Finnq・Payco・Naver Pay・Kakao Pay・NHN Payco。
• 証券: 未来アセット・NH投資・サムスン・KB・キウム・韓投・新韓投資。
• 保険: サムスン・ハンファ・教保・新韓・KB・東洋・未来アセット。

マイデータのデータ範囲はオープンバンキングより広い。

マイデータの統合認証APIはユーザーが一度の認証で複数機関のデータにアクセスできるようにする。統合認証1.0は2022年施行、統合認証2.0が2024年に導入され、OIDC + DID統合が強化された。

POST /oauth/2.0/token
Host: api.mydatakorea.example
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&client_id={組織コード}
&client_secret={シークレット}
&code={認可コード}
&redirect_uri={リダイレクト}
&org_code={情報提供者コード}

マイデータの長所はデータ範囲が広く、ユーザー同意が標準化されている点だ。短所は情報提供機関別にAPI品質・更新周期・機関コードが異なる運用負担だ。金融決済院と信用情報院が協力して標準化を進めている。

第12章 · Kakao Bank・Toss — 韓国マイデータの二つのモデル

韓国マイデータの二大事業者はKakao BankとToss(Viva Republica)だ。同じライセンスだがビジネスモデルが異なる。

• Kakao Bank: インターネット専門銀行が本業 + マイデータ。資産統合・消費分析・信用評価が強み。
• Toss: 総合金融プラットフォーム。マイデータで統合したデータをToss証券・Toss銀行・Tossインシュアランスに活用。

Tossの強みは統合UXだ。ユーザーはToss内で自分の金融ライフ全体を見る。Kakao Bankはメッセンジャーフレンドリーなアプリと26週積立のようなゲーム化商品が強い。

マイデータの次の段階は個人事業主・小規模事業者マイデータだ。売上・仕入・税金・人件費のような事業データを統合してSME金融を加速する。2025-2026年に実証事業が進行中だ。

第13章 · 日本 全銀協API — 義務化に向かう道

日本は2017年の銀行法改正で電子決済等代行業ライセンスを作った。EUのAISP/PISPに相当する。2018-2020年に全銀協(全国銀行協会)が銀行APIガイドラインを発表し、2024-2026年に義務化段階へ入る。

運用構造:

• ASPSP相当の日本の銀行 — 三井住友・MUFG・みずほ・りそな + 地方銀行。
• 電子決済等代行業者: マネーフォワード・freee・Moneytree・Nudge。
• 全銀協がAPI標準・接続規約を運用。

三井住友(SMBC)・MUFG・みずほは各自のAPIを運用するが全銀協ガイドラインに準拠する。標準はOAuth 2.0 + FAPI 1.0が多数で、一部の銀行はFAPI 2.0を準備中だ。

GET /v1/accounts/{accountId}/balance
Host: bankapi.smbc.example
Authorization: Bearer {access_token}
x-fapi-financial-id: ZNG-2026-SMBC
x-fapi-interaction-id: 5a8e2b1c-...

200 OK
{
  "Data": {
    "Account": [{
      "AccountId": "ACC-2026-001234",
      "Currency": "JPY",
      "AvailableBalance": "523450",
      "BookedBalance": "523450"
    }]
  }
}

日本の特殊性はPSP領域と銀行領域の明確な分離だ。PayPay・LINE Pay・楽天Payのような電子決済サービスは銀行APIを通じて自動チャージを行う。ユーザーは銀行残高で直接決済する代わりにPSPウォレットにチャージする。

マネーフォワード・freeeは日本版PFM・会計SaaSの代表格だ。銀行APIを受け取って自営業者・SMEの統合会計を実装する。米国のMint・QuickBooksに近い。

第14章 · 日本 JFSAガイドラインと2026年の方向

日本金融庁(JFSA)は2024年に「オープンバンキング推進」政策を発表した。要点:

• 銀行APIの標準化・品質KPI公示。
• 電子決済等代行業者のセキュリティ・運用基準の強化。
• データポータビリティ権の承認。
• 保険・証券・年金分野への拡張 — EU FIDAに近い方向性。

JFSAは2025年に「金融データ活用基本方針」を発表しOpen Financeへの拡張を明示した。日本の特異点は個人情報保護委員会とJFSAの二元ガバナンスだ。個人情報保護法(2022年改正)がデータ保護のベースラインを敷き、JFSAが金融特化規制を加える。

業界動向:

• 三井住友(SMBC): SMBC Cloud Sign + API。AI信用評価を自社構築。
• MUFG: GO-NET・MUFGコインなどデジタル戦略。APIは標準化。
• みずほ: J-Coin Pay + 銀行API。
• りそな: データ分析・法人API強化。
• 楽天銀行: インターネット銀行、楽天経済圏連動。
• PayPay銀行(旧ジャパンネット銀行): PayPay連動。

第15章 · 米国1033条施行 — オープンバンキングが法律になる

米国には政府主導のPSD2がなかった。しかしCFPB 1033条(Personal Financial Data Rights Rule)が2024年10月に最終確定し、事実上の米国版PSD2となった。

主な義務:

• データ保有者は消費者やその委任TPPに1年分の取引・残高・基本口座情報を無料で提供。
• データ形式はFDX標準を事実上認定。
• スクリーンスクレイピングは段階的禁止。
• データ利用に対する消費者同意の要求。
• データのsecondary use制限。

施行日程は資産規模別に段階適用だ。大手銀行は2026年4月、中堅は2026年10月、小規模は2027年など。

これにより米国のオープンバンキング生態系はPSD2-EUと似た標準化曲線に入る。Plaid・Finicity・MX・AkoyaはそれぞれFDX互換API事業者となり、スクリーンスクレイピング依存が低下する。

第16章 · セキュリティ・不正 — ダイナミックリンクとtoken binding

オープンバンキングのセキュリティの二大柱はダイナミックリンクとトークンバインディングだ。

ダイナミックリンク: 決済認証トークンが金額・受取人を含む必要がある。MITM攻撃での決済改竄を防ぐ。

トークンバインディング: access_tokenがクライアント鍵・デバイスに結びついている必要がある。DPoP・mTLSがこれを実装する。

# DPoPヘッダー — トークンをクライアント鍵にバインド
POST /payments HTTP/1.1
Host: as.bank.example
Authorization: DPoP eyJraWQiOiJ...access_token...
DPoP: eyJ0eXAiOiJkcG9wK2p3dCIs...signed_proof...

DPoPはクライアントの公開鍵にaccess_tokenを結びつけ、リクエストごとにクライアントが秘密鍵で署名したproof JWTを追加する。access_tokenが盗まれても秘密鍵がなければ使えない。

不正検知の追加シグナル:

• デバイスフィンガープリント・IP地理・セッション挙動。
• behaviour biometrics(タイピングパターン、マウス挙動)。
• 取引グラフ — Plaid Signal・TrueLayer Trustのような製品がACH・決済の不正リスクをスコア化。

PSD3 + PSRの責任分担ルールは、不正損失が発生したときのTPP・ASPSP・消費者の責任を明確化する。PSD2時代の曖昧さがしばしば紛争を生んだ。

第17章 · データカテゴライゼーション — 取引を意味に変える

オープンバンキングデータの価値はrawにはない。取引を「スターバックスコーヒー」「家賃」「交通費」のように分類してこそユーザーにとっての意味になる。カテゴライゼーションはすべてのアグリゲーター・PFMアプリの中核IPだ。

標準分類体系:

カテゴライゼーションの方法:

# 取引分類 — ルール + ML ハイブリッド(概念コード)
import re
from typing import Dict

RULES = [
    (r"スターバックス|STARBUCKS", "食費/カフェ"),
    (r"UBER|GO TAXI", "交通/タクシー"),
    (r"NETFLIX|ネットフリックス", "エンタメ/OTT"),
    (r"イオン|IO N|セブン", "食費/食料品"),
]

def rule_categorize(memo: str) -> str | None:
    for pattern, cat in RULES:
        if re.search(pattern, memo, re.IGNORECASE):
            return cat
    return None

# ルールで取れなければMLモデルへフォールバック
def hybrid_categorize(tx: Dict, ml_model) -> str:
    cat = rule_categorize(tx.get("memo", ""))
    if cat:
        return cat
    return ml_model.predict([tx])[0]

規制面でカテゴライゼーションは信用評価・マーケティング・政府給付資格判定にも影響するので、米国・EU・韓国いずれも精度・バイアスのモニタリングを求める。

第18章 · インド Account Aggregator — もう一つのモデル

インドは別の道を歩んだ。インド準備銀行(RBI)が2016年に作った**Account Aggregator(AA)**体系が標準だ。NBFC-AAという新ライセンスを作り、データ仲介者の役割を分離した。

特徴:

• 同意管理(consent manager)中心モデル。
• FIP(Financial Information Provider) — 銀行・証券・年金などデータ提供側。
• FIU(Financial Information User) — データ利用側。
• AA — 同意・ルーティング・暗号化の仲介。データを見ない。
• ReBIT(Reserve Bank IT)が標準運用。Sahamatiが業界団体。

AAモデルはEUと異なる。AAがデータを見ず、単にルーティングする。データはFIPからFIUへ直接流れる。AAは同意の完全性・監査ログ・暗号化の保証に集中する。

このモデルは韓国マイデータの一部設計にも影響した。韓国が本人信用情報管理業者にデータ統合・表示を許容する点が違いだ。

第19章 · Open Finance — 保険・年金・投資への拡張

PSD2が決済・口座だったとすれば、Open Financeはそれ以外のすべての金融だ。FIDAがEUのスタートで、韓国・日本・米国も似た流れだ。

拡張のシグナル:

• 保険: 終身・自動車・住宅の保障・請求データを他保険会社・比較マーケットが受け取る。
• 年金: 職場年金・私的年金の残高・拠出・予想受給額。
• 投資: 証券口座の保有・約定・評価・手数料。
• 住宅ローン: 残高・金利・返済スケジュール。借換比較を加速。
• 暗号資産: MiCA・VASP規制と連動。

技術標準はPSD2/PSD3と同じくOAuth 2.0 + FAPI 2.0 + JSON APIだ。データモデルだけが分野別に新たに定義される。EBA・EIOPAが標準化ガイドを発表中だ。

韓国ではマイデータが初めからOpen Financeに近かった — 保険・証券・通信・公共が第一段階に含まれた。日本は銀行APIから始めて段階的に保険・証券へ拡張する。

第20章 · TPPライセンス — どこでどう取得するか

オープンバンキング・Open Financeを事業化するにはTPPライセンスが必要だ。国別に整理する。

EUで最も多く使われる道はリトアニア・アイルランド・ルクセンブルクのような小国でライセンスを取得し、EUパスポーティングを活用することだ。BrexitでUKは別途登録が必要。

韓国はマイデータライセンスが申請だけでは難しい。自己資本5億ウォン以上、セキュリティシステム・監視・人員・財務健全性の要件がある。日本はシステム運用・財務監査・情報保護基準が厳しいが、資本要件は相対的に軽い。

第21章 · インフラ比較 — 自社構築 vs アグリゲーター

フィンテックがオープンバンキングを導入するとき二つの道がある。直接ASPSP接続 vs アグリゲーター利用。

ほとんどのスタートアップはアグリゲーターで始めて、規模が大きくなれば核心市場のみ直接接続するハイブリッドに行く。例: Wealthsimpleはカナダ・米国の大手銀行は直接、小規模機関はPlaid。

第22章 · 実践例 — 総合資産ダッシュボードを作る

総合資産ダッシュボードはオープンバンキング・マイデータの代表活用処だ。一画面で複数銀行・証券・カード・保険の資産をまとめる。

設計フロー:

1. ユーザー登録・OAuth同意(複数機関)。
2. access_token・refresh_tokenを安全に保管(KMS)。
3. 周期的同期(<2초 API call の応答を得るためにキャッシュ・プル結合)。
4. 正規化 — 通貨・残高・資産クラスを標準化。
5. 表示 — 残高・時系列・資産配分・目標。

// 総合資産ダッシュボード — 同期ジョブ(概念コード)
async function syncAllAccounts(userId) {
  const userTokens = await tokenStore.list({ userId })
  // 並列コール (Plaid + マイデータ + 銀行API)
  const results = await Promise.allSettled(
    userTokens.map(async (t) => {
      switch (t.provider) {
        case 'plaid':
          return await plaid.balances(t.accessToken)
        case 'kr_mydata':
          return await krMydata.accounts(t.accessToken, t.orgCode)
        case 'jp_smbc':
          return await jpSmbc.accounts(t.accessToken)
        case 'truelayer':
          return await truelayer.accounts(t.accessToken)
      }
    })
  )
  // 結果を標準モデルへ変換
  return normalize(results)
}

運用イシュー:

• トークン期限(通常90日)。PSD3でAISP 90日再認証が緩和されUX改善。
• 複数機関合算時の通貨換算 — 為替ソースの信頼性。
• 取引分類・重複除去 — カード決済と銀行出金が重複に見える可能性。
• ダウンタイム処理 — 一部の機関が応答できなくても画面が壊れないように。

第23章 · 総合比較 — US/EU/KR/JP 規制マトリクス

第24章 · 運用チェックリスト — TPP・フィンテックがローンチする前に

最後に実務チェックリスト。

1. ライセンス: 運用国のTPPライセンス(またはEUパスポーティング活用)。
2. eIDAS証明書: QSeal/QWAC発行 — Buypass、Globalsign、Sectigoなど。
3. サンドボックス通過: 各ASPSPのサンドボックスでconformance。
4. FAPI 2.0互換: PAR + DPoP + mTLSまたはprivate_key_jwt。
5. SCA UX: ダイナミックリンクと90日再認証のスムーズな流れ。
6. モニタリング: API可用性・遅延・エラー分布。
7. トークンセキュリティ: KMS・HSMベースの秘密鍵保管。
8. データ最小化: 同意範囲内の最小データのみ保管。
9. カテゴライゼーション品質: 分類精度とバイアスのモニタリング。
10. 不正検知: device fingerprint・behaviour・graphの結合。
11. 規制報告: 不正損失・ダウンタイム・苦情の報告書式。
12. 消費者権利: 同意撤回・データ削除の自動化フロー。
13. 災害復旧: ASPSPダウン・自社ダウンへのfallback。
14. ベンダーガバナンス: アグリゲーター・KMS・認可サーバーのSLA・テスト結果。

この14項目が2026年の標準だ。核心はオープンバンキングの中核価値(接続・同意・標準化)がフィンテックのスピード・技術と結合することだ。PSD3・FIDA・1033条・マイデータ・全銀協が作る規制格子の上で、Plaid・TrueLayer・Tink・Yapily・Belvo・Salt Edge・Finicity・MX・Akoya・金融決済院・マネーフォワードがインフラを作る。ユーザーは一度の同意で自分の金融ライフ全体を見る。

References

• Plaid — https://plaid.com/
• TrueLayer — https://truelayer.com/
• Tink (Visa) — https://tink.com/
• Yapily — https://www.yapily.com/
• Belvo — https://belvo.com/
• Salt Edge — https://www.saltedge.com/
• Finicity (Mastercard) — https://www.finicity.com/
• MX — https://www.mx.com/
• Akoya — https://akoya.com/
• 金融決済院 (KFTC) オープンバンキング — https://www.kftc.or.kr/
• マイデータ総合ポータル(韓国) — https://www.mydatacenter.or.kr/
• 韓国信用情報院 — https://www.kcredit.or.kr/
• 金融委員会(韓国) — https://www.fsc.go.kr/
• 金融監督院(韓国) — https://www.fss.or.kr/
• 全国銀行協会(全銀協) — https://www.zenginkyo.or.jp/
• 金融庁(JFSA) — https://www.fsa.go.jp/
• EBA Open Banking — https://www.eba.europa.eu/
• EIOPA — https://www.eiopa.europa.eu/
• ESMA — https://www.esma.europa.eu/
• CFPB 1033 Rule — https://www.consumerfinance.gov/rules-policy/final-rules/personal-financial-data-rights/
• FDX (Financial Data Exchange) — https://financialdataexchange.org/
• OpenID FAPI 2.0 — https://openid.net/specs/fapi-2_0-security-profile.html
• Sahamati (India AA) — https://sahamati.org.in/
• マネーフォワード — https://moneyforward.com/
• freee — https://www.freee.co.jp/