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

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

日本では銀行法改正による電子決済等代行業の枠組みが同時期に整備され、参照系 API の接続は一定の広がりを見せました。しかし更新系の利用や、API 仕様の相互運用性については課題が残ります。本稿では PSD3 とその関連規則が何を変えようとしているのかを整理し、日本の実装に引き寄せて何を準備すべきかを考えます。

PSD2 が残した宿題

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

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

さらに、口座情報の参照は広がった一方で、支払い開始のユースケースは想定ほど伸びませんでした。既存のカード決済網に対する優位性を打ち出せる場面が限られたことが背景にあります。加盟店から見ると、手数料の低さと引き換えに、返金や不払いへの対応を自前で設計する必要が生じるためです。

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

PSD3 と決済サービス規則が変えようとしているもの

新しい枠組みは、指令に加えて直接適用される規則を組み合わせる構成をとります。指令は加盟国が国内法へ置き換える必要があるため実装差が生じますが、規則は加盟国共通で直接適用されるため、この差を縮める狙いがあります。

内容面では、いくつかの方向がはっきりしています。API の性能・可用性に関する要求を具体化し、専用インターフェースが機能しない場合の扱いを厳格化すること。認証の負担を減らすため、リスクベースでの適用範囲を見直すこと。そして、なりすまし詐欺への対応として、口座名義と振込先名義の照合を求める仕組みを広げることです。

後者は実装への影響が大きい部分です。受取人名の照合は、単純な文字列一致では実用になりません。表記ゆれ、法人格の略記、全角半角、旧姓や屋号といった要素を扱う必要があり、照合結果を三値以上で返す設計が前提になります。完全一致・近似一致・不一致を区別し、近似一致のときに利用者へどう提示するかまでが仕様の一部です。

日本の API 接続の現在地

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

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

// 受取人名照合は真偽値で返さない。近似一致を区別できる形にする。
public enum PayeeMatchResult
{
    Match,          // 完全一致
    CloseMatch,     // 表記ゆれの範囲で一致（利用者に確認を促す）
    NoMatch,        // 不一致
    Unavailable     // 相手方が照合に対応していない
}

public sealed record PayeeVerification(
    PayeeMatchResult Result,
    string? SuggestedName,   // CloseMatch のとき、相手方が保持する名義
    string TraceId);         // 監査証跡として保存する

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

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

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

同意管理も軽視できない領域です。参照の同意には有効期限があり、更新のタイミングで利用者の再認証が必要になります。同意の状態、対象範囲、有効期限を一元管理し、失効前に更新を促す導線を用意しておくと、接続の継続率が変わります。

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

// 同意は「いつ・誰に・何を・いつまで」を必ず揃えて保持する。
// 失効の判定と更新導線の出し分けが、この情報だけで完結するようにしておく。
public sealed record AccountConsent(
    string ConsentId,
    string UserId,
    string InstitutionId,
    IReadOnlyList<string> AccountIds,
    ConsentScope Scope,          // Balances / Transactions / Payments
    DateTimeOffset GrantedAt,
    DateTimeOffset ExpiresAt,
    ConsentStatus Status)        // Active / Expired / Revoked / Suspended
{
    // 期限の一定前から更新を促す。切れてから気づくと再取得の摩擦が大きい。
    public bool NeedsRenewal(DateTimeOffset now, TimeSpan lead)
        => Status == ConsentStatus.Active && ExpiresAt - now <= lead;
}

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

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

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

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

まとめ

PSD3 の方向性は、開放そのものではなく開放された機能の実用性に軸足を移しています。日本の実装に引き寄せると、API 仕様の差異を吸収する正規化レイヤ、同意のライフサイクル管理、受取人名照合のような新しい要件への準備という三点が当面の焦点になります。いずれも規制対応というより、接続を継続的に運用するための基盤設計の問題です。

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

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