多くのヨーロッパの銀行は、PSD3を遠い未来のマイルストーンのように語り続けていますが、政治的合意は2025年11月に成立し、法務チームはすでに2026年を移行計画の中心に置いています。業界はもはやこれを「後で確定するもの」として扱う余裕を失っています。その一因は、PSD3は本質的にPSD2にいくつかの追加層を重ねたものであるという誤信です。いわばPSD2.0のように考えられていますが、そうではありません。新しいパッケージである第三次支払いサービス指令（PSD3）と直接適用される支払いサービス規則（PSR）は、許可の管理方法、認証の証明方法、第三者アクセスの管理方法において基準を引き上げています。また、アカウント間送金、デジタルウォレット、より広範なデータ共有モデルが、銀行がPSD2向けに構築したインフラに対してより重い要求を突きつけるタイミングでもあります。私たちのヨーロッパの機関との協働を通じて、さまざまなアプローチを目の当たりにしています。ある銀行は最終的なテキストを待って意思決定を行っています。一方で、すでにPSD3が制御されたアップグレードになるのか、破壊的なレトロフィットになるのかを決定するコンポーネントを再構築し始めている銀行もあります。その違いは規制の解釈ではなく、アーキテクチャにあります。**銀行が依然として露出している部分**多くの銀行は、PSD3を政策解釈の観点から捉え続けていますが、実際のプレッシャーはその下にあるシステムにあります。PSD2の下で構築された多くのシステムは、期限を満たすために急いで組み立てられたものであり、多くの銀行はその直後にそれらのコンポーネントを強化し直すことはありませんでした。一例が同意管理です。多くの銀行は、PSD2の導入時に取り付けられたチャネル固有の同意ストアやダッシュボードに依存しています。これらの設定は、PSD3が期待する詳細レベルでの許可管理や、それらを安全に取り消すこと、証明することを難しくしています。 認証も同じ場所にあります。強力な顧客認証（SCA）が行われたことを証明するだけでは不十分であり、銀行は取引承認時の認証コンテキストと承認者の状態を示す必要があります。詐欺対策もさらなる圧力を加えています。リアルタイムでリスク評価を行い、その結果を後から再構築するのではなく、即時に示す必要があります。監視ツールが断片化している場合や、取引データが切り離されたシステムにまたがっている場合は特に困難です。BPCのSmartVista Fraud Managementのようなプラットフォームは、オンライン取引監視と中央集権的なデータ管理、AI/MLサポートを組み合わせており、銀行に必要なアーキテクチャの一例です。活動をリアルタイムで評価し、その決定過程を示すことができる必要があります。APIのパフォーマンスも重要です。PSRはインターフェースの稼働状況、エラー処理の一貫性、チャネル間でのデータ配信の信頼性に重きを置いています。第三者アクセスやオンボーディングも同様に、定期的なチェックや手動ステップから、継続的な検証とアクセス権管理の明確なモデルへとシフトする必要があります。PSD2の後にこれらの基盤を強化した機関は、今やPSD3への適応においてはるかに少ない混乱で済んでいます。一方、PSD2の構築をそのまま放置した銀行は、より困難な道のりを強いられています。**PSD2が残したもの**PSD2は、今やPSD3の難易度を決定づける一連の技術的決定を残しました。多くの機関は、締め切りに間に合わせるために急いで構築しました：異なるチャネル用の個別の許可ダッシュボード、製品間に散在する認証ロジック、低ボリューム向けに調整されたAPIゲートウェイ、第三者の確認やオンボーディングのための手動ステップ。これらの選択は当面の問題を解決しましたが、今やPSD3の作業の中心にあります。他の機関は、PSD2を利用して基盤を整えました。許可を一箇所にまとめ、認証を共有サービスとして扱い、より信頼性の高いAPIに投資し、より明確なアクセス制御を導入しました。これらはPSD3を念頭に置いて行ったわけではありませんが、システムを壊すことなく適応できる余裕を与えています。PSD3とPSRは、これら二つの道の違いを明らかにします。新しい枠組みは、銀行に対してリアルタイムで誰が何にアクセスしているのか、どの許可の下で、どの程度の保証を持っているのかを把握することを求めています。APIは一貫して動作し、取引時に詐欺チェックが証明され、アクセス権が継続的に検証されることを期待しています。これらの期待は、PSD2の土台の築き方次第で大きく異なります。PSD2の下で行われた作業が、PSD3の破壊的な度合いを決める要素となっています。**先送りできない決定**すでにいくつかのアーキテクチャ的な決定が出ており、最終的なテキストを待つことはそれらを容易にしません。許可は一つの場所に集約すべきです。PSD2の時に作られた散在する同意ストアは、詳細管理やアクセスの安全な取り消し、承認時点の状態の証明を難しくしています。認証は、単なる製品レベルのステップではなく、一つのサービスとして機能すべきです。PSD3は、銀行に対して承認の全体的なコンテキストを示すことを求めており、単にSCAイベントが発生したことだけでは不十分です。アクセス権は、間隔を空けて確認するのではなく、継続的に検証される必要があります。誰が何をできるかを時間とともに管理するよりクリーンな方法も求められます。APIも運用インフラとして扱われ、PSRが求める信頼性と一貫性を備える必要があります。これが、銀行が一時的な修正を超え、規制の変化をよりスムーズに吸収できるモジュール型プラットフォームに目を向け始めている理由です。既存の金融機関にとって、将来に備えたインフラは、現行のコンプライアンスと同じくらい重要です。BPC SmartVistaのようなモジュール式、クラウドネイティブのアーキテクチャは、PSD3への適応をより実用的にし、次の規制変化による高額な再構築のリスクを低減します。銀行は、移行を容易にし、要件の進化に対応し、システム全体を再構築せずに適応できるプラットフォームを必要としています。これらの選択は、PSD3が管理可能なアップグレードとして受け入れられるか、コストのかかる再構築になるかを大きく左右します。早めに動くことで、銀行は自分たちの条件で適応する余裕を持てます。最終的なテキストを待つと、行動の時間枠が狭まるリスクがあります。
PSD3対応は将来の問題ではありません。今，現在の問題です。
多くのヨーロッパの銀行は、PSD3を遠い未来のマイルストーンのように語り続けていますが、政治的合意は2025年11月に成立し、法務チームはすでに2026年を移行計画の中心に置いています。業界はもはやこれを「後で確定するもの」として扱う余裕を失っています。
その一因は、PSD3は本質的にPSD2にいくつかの追加層を重ねたものであるという誤信です。いわばPSD2.0のように考えられていますが、そうではありません。新しいパッケージである第三次支払いサービス指令（PSD3）と直接適用される支払いサービス規則（PSR）は、許可の管理方法、認証の証明方法、第三者アクセスの管理方法において基準を引き上げています。
また、アカウント間送金、デジタルウォレット、より広範なデータ共有モデルが、銀行がPSD2向けに構築したインフラに対してより重い要求を突きつけるタイミングでもあります。
私たちのヨーロッパの機関との協働を通じて、さまざまなアプローチを目の当たりにしています。ある銀行は最終的なテキストを待って意思決定を行っています。一方で、すでにPSD3が制御されたアップグレードになるのか、破壊的なレトロフィットになるのかを決定するコンポーネントを再構築し始めている銀行もあります。その違いは規制の解釈ではなく、アーキテクチャにあります。
銀行が依然として露出している部分
多くの銀行は、PSD3を政策解釈の観点から捉え続けていますが、実際のプレッシャーはその下にあるシステムにあります。PSD2の下で構築された多くのシステムは、期限を満たすために急いで組み立てられたものであり、多くの銀行はその直後にそれらのコンポーネントを強化し直すことはありませんでした。
一例が同意管理です。多くの銀行は、PSD2の導入時に取り付けられたチャネル固有の同意ストアやダッシュボードに依存しています。これらの設定は、PSD3が期待する詳細レベルでの許可管理や、それらを安全に取り消すこと、証明することを難しくしています。
認証も同じ場所にあります。強力な顧客認証（SCA）が行われたことを証明するだけでは不十分であり、銀行は取引承認時の認証コンテキストと承認者の状態を示す必要があります。
詐欺対策もさらなる圧力を加えています。リアルタイムでリスク評価を行い、その結果を後から再構築するのではなく、即時に示す必要があります。監視ツールが断片化している場合や、取引データが切り離されたシステムにまたがっている場合は特に困難です。BPCのSmartVista Fraud Managementのようなプラットフォームは、オンライン取引監視と中央集権的なデータ管理、AI/MLサポートを組み合わせており、銀行に必要なアーキテクチャの一例です。活動をリアルタイムで評価し、その決定過程を示すことができる必要があります。APIのパフォーマンスも重要です。PSRはインターフェースの稼働状況、エラー処理の一貫性、チャネル間でのデータ配信の信頼性に重きを置いています。第三者アクセスやオンボーディングも同様に、定期的なチェックや手動ステップから、継続的な検証とアクセス権管理の明確なモデルへとシフトする必要があります。
PSD2の後にこれらの基盤を強化した機関は、今やPSD3への適応においてはるかに少ない混乱で済んでいます。一方、PSD2の構築をそのまま放置した銀行は、より困難な道のりを強いられています。
PSD2が残したもの
PSD2は、今やPSD3の難易度を決定づける一連の技術的決定を残しました。多くの機関は、締め切りに間に合わせるために急いで構築しました：異なるチャネル用の個別の許可ダッシュボード、製品間に散在する認証ロジック、低ボリューム向けに調整されたAPIゲートウェイ、第三者の確認やオンボーディングのための手動ステップ。これらの選択は当面の問題を解決しましたが、今やPSD3の作業の中心にあります。
他の機関は、PSD2を利用して基盤を整えました。許可を一箇所にまとめ、認証を共有サービスとして扱い、より信頼性の高いAPIに投資し、より明確なアクセス制御を導入しました。これらはPSD3を念頭に置いて行ったわけではありませんが、システムを壊すことなく適応できる余裕を与えています。
PSD3とPSRは、これら二つの道の違いを明らかにします。新しい枠組みは、銀行に対してリアルタイムで誰が何にアクセスしているのか、どの許可の下で、どの程度の保証を持っているのかを把握することを求めています。APIは一貫して動作し、取引時に詐欺チェックが証明され、アクセス権が継続的に検証されることを期待しています。これらの期待は、PSD2の土台の築き方次第で大きく異なります。
PSD2の下で行われた作業が、PSD3の破壊的な度合いを決める要素となっています。
先送りできない決定
すでにいくつかのアーキテクチャ的な決定が出ており、最終的なテキストを待つことはそれらを容易にしません。許可は一つの場所に集約すべきです。PSD2の時に作られた散在する同意ストアは、詳細管理やアクセスの安全な取り消し、承認時点の状態の証明を難しくしています。
認証は、単なる製品レベルのステップではなく、一つのサービスとして機能すべきです。PSD3は、銀行に対して承認の全体的なコンテキストを示すことを求めており、単にSCAイベントが発生したことだけでは不十分です。
アクセス権は、間隔を空けて確認するのではなく、継続的に検証される必要があります。誰が何をできるかを時間とともに管理するよりクリーンな方法も求められます。APIも運用インフラとして扱われ、PSRが求める信頼性と一貫性を備える必要があります。
これが、銀行が一時的な修正を超え、規制の変化をよりスムーズに吸収できるモジュール型プラットフォームに目を向け始めている理由です。既存の金融機関にとって、将来に備えたインフラは、現行のコンプライアンスと同じくらい重要です。BPC SmartVistaのようなモジュール式、クラウドネイティブのアーキテクチャは、PSD3への適応をより実用的にし、次の規制変化による高額な再構築のリスクを低減します。銀行は、移行を容易にし、要件の進化に対応し、システム全体を再構築せずに適応できるプラットフォームを必要としています。
これらの選択は、PSD3が管理可能なアップグレードとして受け入れられるか、コストのかかる再構築になるかを大きく左右します。早めに動くことで、銀行は自分たちの条件で適応する余裕を持てます。最終的なテキストを待つと、行動の時間枠が狭まるリスクがあります。