EU Open Banking MCP

セルフホスト型の読み取り専用 MCP サーバーです。Enable Banking を介して個人の欧州銀行口座にアクセスし、Cloudflare Workers 上で保護・デプロイされます。

[!IMPORTANT] すべてのデプロイを、プライベートな金融システムとして扱ってください。このリポジトリはオープンソースです。ただし、あなたの Worker、MCP URL、シークレット、セッション ID、口座 ID、金融データはプライベートです。

なぜ作るのか

ChatGPT Finances は、アシスタントが実際の残高と取引について推論できるときに何が可能になるかを示しています。その口座接続は Plaid が提供しており、現在は米国で利用できます。

私は、ヨーロッパの個人口座に対して、これと同じくらい直接的でセルフホスト可能な方法が見つからなかったため、このプロジェクトを構築しました。ヨーロッパには Open Banking がありますが、個人が銀行データにアクセスするには、本番オンボーディングと API が異なる規制プロバイダーを経由する必要があります。Plaid が公開している MCP サーバーは、開発者ツールや本番診断には役立ちますが、個人の残高や取引をパーソナルファイナンス用の MCP ツールとして公開するものではありません。

このプロジェクトはその狭い隙間を埋めます。1 人が 1 つのプライベートな MCP をデプロイし、自分の銀行口座だけを認可し、選択した MCP クライアントが限定的な読み取り専用分析を行えるようにします。これは、ホスト型の金融サービスやマルチユーザー集約サーバーではなく、個人的な使用のためのインフラストラクチャです。

Related MCP server: openbanking-mcp

Enable Banking を選ぶ理由

評価したプロバイダーのうち、Enable Banking がセルフホストの個人デプロイに最もシンプルに適合しました。その restricted-production モードでは、商用契約を結ぶ前に、所有者自身の口座をリンクすることでアプリケーションを有効にすることが明示的に認められており、個人の非営利利用も含まれます。この場合、アプリケーションはリンクされた口座のみを読み取ることができます。Enable Banking の restricted-production アカウントガイドを参照してください。

このモデルは、このプロジェクトのセキュリティ境界と一致しています:

• Enable Banking のダッシュボードが口座のホワイトリストです。

• 銀行の認可フローが、取り消し可能な API 同意を作成します。

• MCP は、その両方の対象となる口座に対して、固定された読み取り操作のみを公開します。

ダッシュボードでのリンク自体は API の認可ではありません。デプロイ後も、/setup は所有者を銀行の同意フローに送り、結果として得られる Enable Banking セッション ID を保存します。ダッシュボードで同じ口座を既にリンク済みであっても、この第 2 のステップは必要です。

アーキテクチャ

flowchart LR
  C[ChatGPT, Codex, or another MCP client] --> A[Cloudflare Access]
  A -->|platform-validated ctx.access| W[Stateless MCP Worker]
  W -->|session IDs only| K[Workers KV]
  W -->|fresh RS256 JWT per call| E[Enable Banking]
  E --> B[Your bank]

• クライアント → MCP: Cloudflare Access Managed OAuth を使用し、デプロイ所有者のみに限定。

• MCP → Enable Banking: Worker シークレットとして保存された秘密鍵から署名される 1 時間有効な RS256 JWT。

• ストレージ: KV には、保護されたセットアップフローを通じて作成された Enable Banking セッション ID のみが保存され хозяйстваされます。

• オンライン口座読み取り: Worker は、接続していするクライアントの IP アドレスと MCP クライアントの User-Agent を、それぞれ Enable Banking の Psu-Ip-Address と Psu-User-Agent ヘッダーとして転送します。これらのリクエスト固有の値は保存もログもされません。これにより、サインインしている所有者がデータを能動的に要求したことを銀行に伝えます。

Worker は残高、取引、口座 UUID、IBAN、認証コード、プロバイダーの応答を保存しません。応答は Cache-Control: no-store を使用します。

ツール

finance_list_accounts は、不透明でセッション固有の accountId を返します。特定の口座を対象とするツールはその ID を受け取り、使用前に有効な Enable Banking セッションとの照合を行います。エイリアスや手入力した口座 UUID は必要ありません。

ページネーションの nextCursor の値にはエンコードされた継続状態が含まれています。不透明ですが公開ではありません。同じ口座とフィルターでそのまま返してください。Worker は使用前に、その埋め込まれたコンテキストを検証します。

すべてのツールは読み取り専用・非破壊的で、冪等です。プロバイダーのコードは interim_available（暫定利用可能）、booked（確定）、professional（プロフェッショナル）などのわかりやすい値に正規化されます。1 つの口座に対する複数の残高は代替的な計測値であり、決して合算しては行けません。金額計算は小数を使った演算を使用し、異なる通貨を組み合わせることはありません。

完全な残高更新を行うには、accountId なしで finance_get_balances を1回呼び出してください。これにより、すべてのアクティブなセッションが自動的に検出されるため、事前の finance_list_accounts 呼び出しは不要です。応答は、他の口座でエラーが発生しにも成功した残高を維持し、安全な口座ごとのエラー報告は個別に行われます。aspsp_rate_limited を返した口座は、すぐに再試行しないでください。

インストール

インストールでは、3 つの独立した信頼関係を確立します。Worker が Enable Banking に対して身元を証明し、銀行が Worker に取り消し可能な同意を付与し、Cloudflare Access が MCP を呼び出せる人を制限します。

1. Cloudflare と Enable Banking の準備

必要なもの:

• workers.dev サブドメインと Zero Trust を備えた Cloudflare アカウント

• Enable Banking の restricted-production アプリケーション

• アプリケーションの UUID と RSA 秘密鍵

Enable Banking アプリを登録する前に Worker 名を選択します。次のコールバック URL を登録し、両方のプレースホルダーを置き換えてください:

https://<worker-name>.<account-subdomain>.workers.dev/callback

production アプリを登録し、RSA 秘密鍵をブラウザ外で生成し、PEM 形式の対応する公開証明書をアップロードします。秘密鍵は保持してください。デプロイフローで Worker シークレットとして保存されますが、コミットしたり共有したりすることは絶対にしないでください。

Enable Banking の Control Panel では、restricted アプリがアクセスできるすべての口座をリンクしてください。ダッシュボードでのリンクは本番用のホワイトリストであり、アプリに対するセッションの認可にはなります。この2段階目の認可は、デプロイ後に /setup を使用して Worker が完了します。Enable Banking の linked-account ガイド を参照してください。

このリポジトリは個人の非商用利用を想定しています。デプロイメントが Enable Banking の現在の利用規約に準拠していることを確認してください。

2. Cloudflare にデプロイする

上記の Cloudflare にデプロイ ボタンを使用してください。Cloudflare のデプロイフローは以下の処理を行います:

1. リポジトリをユーザーの GitHub または GitLab アカウントにコピーします。

2. ENABLE_BANKING_APPLICATION_ID と ENABLE_BANKING_PRIVATE_KEY_PEM を 要求します。

3. SESSION_STORE KV 名前空間をプロビジョニングします。

4. このプロジェクトに必要な Cloudflare Access ポリシーを添付します。

5. Workers Builds を使用して Worker をビルドしデプロイします。

最初の 2 つのシークレットフィールドは、.dev.vars.example から読み取られたマスク済みのプレースホルダー値（すべてゼロの UUID と replace-me 秘密鍵）が初期値です。これらは既存の認証情報ではありません。デプロイ前に、本番の UUID と秘密鍵に置き換えてください。

Cloudflare は Worker が公開可能であるため Access をオプションとして表示しますが、このプロジェクトでは必須です。デプロイページで、Protect with Cloudflare Access を有効にし、 All traffic を選択して、認証ポリシーを追加します。個人デプロ発の場合は、あなた自身の正確な ID のみ（または信頼できるメンバーだけの Cloudflare アカウント）を許可してください。Previews only では本番 Worker は保護されません。

Cloudflare はこの動きについて Deploy to Cloudflare buttons に記載しています。

3. Managed OAuth を有効にする

1. Zero Trust の Access controls → Applications で、デプロイ時に作成された Access アプリを開きます。

2. Advanced settings を開き、Managed OAuth を有効にして保存します。

デプロイ時に Protect with Cloudflare Access を有効化していない場合は、続行する前に Worker レベルの Access を手動で接続してください。Access が接続されるまで、Cloudflare が ctx.access を提供しないため、Worker は 403 access_required でフェイルクローズします。Worker レベルの Access は、Worker が関連するドメイン全体で /、/setup、/callback、/mcp を保護します。Cloudflare の Worker-level Access guide を参照してください。

Managed OAuth は、MCP クライアントが使用する protected-resource と authorization-server の discovery メタデータを公開します。Cloudflare は Worker 呼び出しの前にリクエストを検証します。このプロジェクトは、 Cloudflare の JWT 検証を重複して行いません。

4. 銀行を認可する

1. https://<your-worker>.workers.dev/setup を開きます。

2. 国を選択し、ログインが個人用かビジネス用かを選択して、Enable Banking の現在利用可能な銀行リストから銀行を選択します。

3. 銀行でアクセス承認します。コールバックは state を検証し、ワンタイムコードを交換して、えられるセッション ID のみを KV に保存します。

4. 銀行のログインごとに繰り返します。1 回の認可で複数の口座が公開されることがあります。

同意が期限切れ・取り消しになった場合は、/setup に戻り、非アクティブなセッションを削除してから銀行を再接続してください。接続を削除すると、Enable Banking にも同意の閉鎖が要求されます。再認可時には新しいセッション ID と口座 ID を Enable Banking が生成します。MCP が自動的に再発見します。

5. MCP クライアントを接続する

次の MCP URL を使用します:

https://<your-worker>.workers.dev/mcp

検証

モデルを接続する前に確認してください:

• 認証されていないリクエストが Access で拒否されること。

• /setup がこのデプロイで作成されたセッションのみを列挙すること。

• MCP の tools/list が上記 5 つのツールのみを公開すること。

• finance_listAccounts が不透明な口座 ID を返し、IBAN を含まないこと。

• 少量の残高と取引リクエストが成功すること。

• 全口座の残高リクエストが、1 つの口座にエラーがあっても成功した口座の結果を返すこと。

• Cloudflare のログに金融データ、シークレット、認可コード、セッション ID が含まれないこと。

意図的に /health エンドポイントはありません。Cloudflare Workers には不要であり、/mcp と保護されたセットアップページが実質的なアプリの健全性チェックです。

セキュリティ特性

• 上流オリジンの修正: リクエストは https://api.enablebanking.com にのみ送信できます。

• プロバイダーの操作を修正: セットアップは口座認可の開始・完了・クローズを実行でき、MCP ツールは文書化された読み取りコールのみを実行します。

• ユーザーがトリガーした口座読み取りでは、制限付きの Psu-Ip-Address と Psu-User-Agent の値を 受信した Cloudflare リクエストから導出して転送します。セッション検出と認可リクエストは これらのヘッダーを受け取りません。

• 口座の強制: 指定されたすべての口座 ID は、アクティブな保存済みセッションに属している必要があります。

• セットアップとコールバックのルートは Worker レベルの Access の背後にあり、origin/state を検証します。

• 認可コードは直ちに交換され、永続化されることはありません。

• KV はセッション ID のみを保存し、保存時に Cloudflare によって暗号化されます。

• 入力、日付、ページ数、結果、上流のレスポンス、タイムアウトはすべて制限付きです。

• プロバイダーの失敗時には、正規化された操作、HTTP ステータス、許可リストに登録されたプロバイダーエラーコード、 および制限付きの Retry-After 値のみをログに記録します — 識別子、リクエストヘッダー、プロバイダーの本文、金融データは決して記録しません。

• 支払い、汎用 HTTP ツール、金融データの永続化、レスポンスキャッシュ、CORS、機密ログは一切行いません。

脅威モデルと開示ポリシーについては、SECURITY.md を参照してください。

開発

bun run typecheck
bun run test
bun run check

テストは Cloudflare Workers ランタイムで実行され、設定、Access のフェイルクローズド動作、セットアップ認可、セッション検出、口座の強制、MCP ツールスキーマ、Enable Banking JWT の構築、正規化、制限付きレスポンスをカバーしています。

プロバイダーのスコープ

Enable Banking は最初のプロバイダーモジュールです。今後のプロバイダーは、汎用的なプロバイダーの HTTP 操作を MCP ツールに漏らすのではなく、同じ狭く正規化した金融インターフェースを公開する必要があります。コントリビューションは MCP から読み取り専用であることを維持し、識別子の検証とレスポンスの正規化のテストを含める必要があります。