オープンバンキングの「次」を読む──PSD3と日本のAPI戦略

オープンバンキングの論点は「API を開放するかどうか」から「開放された API が実用に耐えるかどうか」へ移りました。欧州の第二次決済サービス指令（PSD2）が接続の義務を作った一方で、実装品質のばらつきと認証フローの摩擦が普及の足かせになったという評価が定着したためです。

本稿では、欧州ですでに施行済みの義務と、まだ確定していない部分を切り分けたうえで、日本の実装に引き寄せて何を準備すべきかを整理します。参照した一次資料は末尾に列挙しています。

何が確定し、何がまだなのか

PSD3 の話題では将来の要件が語られがちですが、実務でまず押さえるべきは適用時期です。欧州委員会が公開している政策の年表を追うと、確定した義務と検討中の枠組みははっきり分かれています。

要点は二つです。ひとつは、即時送金規則（規則 (EU) 2024/886）によって受取人照合が 2025年10月9日から義務化済みであること。もうひとつは、PSD2 を見直す PSD3 と決済サービス規則（PSR）が 2025年11月27日に政治合意へ達した段階で、発効はこの先だということです。

この切り分けは設計の優先順位に直結します。照合はすでに動いている要件で、対応の可否ではなく品質が問われます。PSD3 側は条文が固まる前に大枠へ備える段階です。

受取人照合は真偽値では表現できない

受取人照合をブール値の一致判定として実装すると、規則の要求を満たせません。条文は結果を三つに分け、それぞれで利用者への提示内容を変えるよう求めています。

不一致のときは、そのまま承認すると受取人以外の口座へ送金されうる旨を利用者へ知らせます。ほぼ一致のときは、相手方が保持している名義そのものを利用者へ提示し、進めるかどうかの判断を委ねます。この「ほぼ一致」の扱いが実装上もっとも重い部分です。

照合対象には表記ゆれ、法人格の略記、全角と半角、旧姓や屋号が混ざります。どこまでを「ほぼ一致」と見なすかは閾値の設計であり、緩めれば警告が形骸化し、厳しくすれば正当な送金に警告が出て利用者が慣れてしまいます。加えて、相手方が照合に対応していない場合という第四の状態も扱いが要ります。

実装では、判定結果と提示した内容、利用者の選択を監査証跡として残す設計にしておきます。事後に問題が起きたとき、何を見せたうえで誰が進めたのかを示せることが、責任分界の前提になります。

PSD2 が残した宿題

PSD3 が何を直そうとしているかは、PSD2 の限界を見ると分かります。もっとも大きいのは、API の可用性と性能に関する要求が事実上の努力目標にとどまり、接続する側から見た品質が保証されなかったことです。応答が遅い、障害時のフォールバックが機能しない、テスト環境が本番と乖離しているといった問題が個別に発生し、接続側は銀行ごとの差異を吸収するコストを負い続けました。

認証フローも摩擦の源でした。強力な顧客認証を素直に実装すると、事業者のアプリから銀行アプリへ遷移して戻る導線が挟まり、離脱が増えます。セキュリティ要件と利用体験の両立が主要な争点になったのはこのためです。

フォールバック手段の扱いも尾を引きました。専用インターフェースが使えない場合に画面スクレイピングへ戻る余地を残したことで、銀行側には API を高品質に保つ動機が働きにくく、接続側には二重の実装が残りました。新しい枠組みが API の品質要求を具体化する方向へ進んでいるのは、この経験があるためです。

日本の現在地

国内では銀行法改正で電子決済等代行業の枠組みが整備され、登録制が始まりました。金融庁が公開する登録一覧によれば、2026年6月30日時点の登録業者は125社です。最も古い登録は2018年9月で、制度開始から8年近くが経過しています。

内訳を見ると、関東財務局管内が107社と全体の大半を占めます。事業者の集中は珍しくありませんが、接続先となる金融機関は全国に分散しているため、地域金融機関との接続をどう標準化するかが実務上の課題として残ります。

全国銀行協会が API 接続のチェックリストと標準的な仕様の考え方を示し、多くの金融機関がこれを参照しています。契約と安全対策基準の枠組みは整った一方、個々の API 仕様には金融機関ごとの差があり、接続側の統合コストは残っています。

更新系 API の利用が限定的にとどまる点も共通の課題です。振込指図を API 経由で行う構成は、事故時の責任分界や不正時の補償の設計が重く、参照系と比べて導入判断のハードルが高くなります。ここは技術というより契約と運用設計の問題として整理する必要があります。

接続する側が備えるべき実装

金融機関ごとの差異を上位に漏らさない構成が要になります。各行の API を正規化レイヤで受け止め、業務ロジックは共通のドメインモデルだけを見るようにします。差異は接続アダプタに閉じ込め、仕様変更の影響範囲を限定します。

可用性の設計も欠かせません。金融機関側のメンテナンス時間帯は行ごとに異なり、深夜帯に集中します。同期的な呼び出しで完結させず、リトライとサーキットブレーカ、利用者への状態通知を組み込んでおくと、障害時の運用が破綻しません。

同意管理は、参照の同意に有効期限があるという性質から設計します。「いつ・誰に・何を・いつまで」を必ず揃えて保持し、失効の判定と更新導線の出し分けがその情報だけで完結するようにしておきます。期限が切れてから気づくと、再取得の摩擦が大きくなります。

同意の粒度も設計事項です。口座単位、データ種別単位、期間単位のどこまで細かく持つかで、利用者への説明のしやすさと実装の複雑さが変わります。細かくしすぎると利用者が理解できず、粗くしすぎると必要以上の権限を求めることになります。実務では、利用者が理解できる単位で提示し、内部ではより細かい粒度で記録する二層構造が扱いやすくなります。

取り消し時の挙動も先に決めます。取り消し後に保持済みのデータをどう扱うか、実行中の処理を止めるかは、規約と実装の両方で整合させる必要があります。

相互運用性をどう確保するか

欧州では Berlin Group をはじめとする業界標準が実装差の吸収に一定の役割を果たしました。日本でも、標準仕様に寄せる動きと金融機関固有の拡張を許す現実との折り合いが問われ続けています。接続側の設計としては、標準に準拠しつつ拡張フィールドを型安全に扱える余地を残すのが現実的です。

あわせて、口座情報や取引明細のデータモデルを ISO 20022 の語彙に寄せておくと、決済系との接続で変換の手間が減ります。オープンバンキング API と決済ネットワークを別々のデータモデルで扱うと、突合のたびにマッピングが要ります。

まとめ

欧州で確定しているのは受取人照合の義務であり、PSD3 と PSR はまだ政治合意の段階です。この切り分けを踏まえると、当面の焦点は三つに絞れます。照合結果を三値以上で扱う実装、API 仕様の差異を吸収する正規化レイヤ、そして同意のライフサイクル管理です。

いずれも規制対応というより、接続を継続的に運用するための基盤設計の問題です。日本では登録業者が125社まで増えた一方、更新系の利用と地域金融機関との標準化には課題が残ります。

金融テクノロジー総合研究所では、金融機関・フィンテック事業者双方の立場で API 接続基盤の設計と実装を受託しています。既存システムへの接続方式の検討段階からご相談いただけます。お問い合わせよりご連絡ください。

参考資料

• European Commission, Payment services（政策の年表。適用時期と PSD3・PSR の政治合意はこの記載による）
• Regulation (EU) 2024/886（即時送金規則。受取人照合の三値と提示義務の条文）
• 金融庁「免許・許可・登録等を受けている事業者一覧」（電子決済等代行業者登録一覧。本文の125社は2026年6月30日現在の計数）
• 一般社団法人全国銀行協会「全国銀行協会」（オープンAPIのあり方と接続チェックリスト）
• Berlin Group（欧州の API 実装標準 NextGenPSD2）

FTL の技術スタックと受託開発の進め方は FTLの技術とは？ にまとめています。