第２回「全銀システム高度化検討ワーキンググループ」の模様
１．日 時

2023 年８月 25 日（金）10：00 ～ 12：00

２．場 所

ウェブ開催（Webex）

３．議 題(1) API ゲートウェイ開発の進捗状況および次期全銀システムの検討状況(2) アジャイルエリアにおける新機能・新サービス（受取人口座確認機能等）の検討(3) 海外トピック

４．議事内容「(1)API ゲートウェイ開発の進捗状況および次期全銀システムの検討状況」
においては、事務局から、API ゲートウェイ（APIGW）および次期全銀システ
ムに関する足許の状況や今後のスケジュール等について説明。
「(2)アジャイルエリアにおける新機能・新サービス（受取人口座確認機能等）の検討」においては、事務局から、第１回全銀システム高度化検討ワー
キンググループ（全銀高度化 WG）等の意見を踏まえた受取人口座確認機能の目指すべき方向性および考えられる対応方針（案）等について説明後、意見交換を実施。
「(3)海外トピック」においては、事務局から、諸外国の Addressing Service
および Request to Pay（支払リクエスト）の動向等について説明後、意見交換を実施。

(1) API ゲートウェイ開発の進捗状況および次期全銀システムの検討状況
事務局説明概要（全銀ネット 千葉企画部長）

APIGW については、予定どおり、７月末に開発ベンダから API 仕様書（暫定版）を受領。今後、９月中を目途に API 仕様書（正式版）および基本設計書を作成し、基本設計工程を完了予定。

APIGW の利用意向について、加盟銀行および新規参加の意向を有する事業者を対象に９月中にアンケート調査を実施予定。なお、APIGW の早期利用に係るインセンティブについては、今後検討。

次期全銀システムについて、複数のベンダが参加する次世代資金決済システムに関する検討タスクフォース（次世代 TF）およびその下部のワーキンググ

1

ループにおける議論を経て、５月に提案依頼書を策定し、全銀高度化 WG に参加しているベンダに提案を依頼した結果、NTT データから提案書を受領（他ベンダは提案辞退）。現在、提案内容の精査を実施しており、９月の理事会において、構築ベンダを決定予定。提案の概要は以下のとおり。
目次

提案内容（概要）

システム構成 次期全銀システムに求められる機能を分割・再定義・再配置。

安全性

 全銀システムへの品質堅持を前提としたオープン化およびアプリケーション刷新を実現。
 全銀システムの安全性を維持・確保するとともに、持続的に利用可能なオープン系の製品を選定。プロジェクトの特性を踏まえた各種施策を講じることで、確実な開発の進捗と品質を確保。

柔軟性 デファクトスタンダードな製品/技術/言語の採用により、技術者の継続的な確保を実現。
 サブシステム間・機能間を疎結合にし、アプリケーション変更に伴う影響を局所化。
 オープン化と合わせて仮想化基盤を導入。

効率性

 現行システムの知見を活かした機能統合およびスリム化を実現。要件
定義工程等において、未使用の機能・過度な機能の廃止や簡素化に向けた検討をサポート。
 運用・保守において、自動化・省力化に資する枠組みを講じ、高度化・効率化を実現。
 仮想化基盤を採用し、物理サーバを集約化。また、省電力、省資源等に配慮した製品を採用。

セキュリティ

 各領域における統合的・多層的なセキュリティ対策を実施。
 セキュリティ対策とセキュリティ推進体制の維持・確保を実施。

開発スケジュール

 オープン化・アプリケーションの刷新に伴い、結合試験の期間を十分に確保。また、非機能面や運用面の確認を適切に行うため、総合運転の期間も十分に確保（ベンダ側の主体工程である基本設計から総合試
験までは約 36 か月を想定。全銀ネット側の主体工程である要件定義は約６か月、受入試験・総合運転試験は約７か月を想定）。

開発体制

 複数の大規模ミッションクリティカルシステムのマネジメント経験を有するプロジェクトマネージャー、全銀システムの仕様/内為制度を熟知した業務有識者、オープン機器・仮想化技術・OSS 製品仕様に精通した基盤技術者等をアサインし、確実かつ効率的に開発プロジェクトを遂行できる体制を講じる。

付加的提案

 RFP 上で指定した「XML 追加開発」や「コア稼動不可時におけるモア即時立ち上げ（モアバック）」のほか、以下の付加的な提案あり。

2

目次

提案内容（概要）✓ サービス開始日の変更（受入試験・総合運転試験の期間を４か月延長。2028 年３月に稼動）✓ 周辺系のクラウドサービス利用（柔軟性・効率性の向上）(2) アジャイルエリアにおける新機能・新サービス（受取人口座確認機能等）の検討
事務局説明概要（全銀ネット 千葉企画部長）


受取人口座確認機能について、前回の全銀高度化 WG では、システムや制度のほか、ガバナンス、スケジュール等に関する意見が寄せられた1。また、次世代 TF において全銀高度化 WG における議論を支持する意見が寄せられた2。
これらの意見を踏まえ、目指すべき方向性を「受取人口座確認機能の利用に係る障害を下げるため、機動的対応が可能な体制への移行」および「全銀システム参加者の受取人口座確認機能の利用を促進するため、低廉なシステムによる簡易で持続的に利用可能な機能の提供」と整理したうえで、ガバナン
ス、制度面およびシステム面における対応方針（案）を以下のとおり整理。
ガバナンス

 受取人口座確認に係るガバナンスは全銀ネットが担う方向とする。
 仮に、統合 ATM スイッチングサービス（統合 ATM）を引き続き利用する場
合、銀行間提携プロセスの煩雑さやコスト硬直化等の解消、透明性やベンダとのコミュニケーション向上の実現に向けて、関係者と協議を進め、全銀高度化 WG・次世代 TF へ進捗を報告する。

制度

 テレ為替における振込時の受取人口座確認機能の利用を必須とし、全銀システムに参加することで、テレ為替利用時の受取人口座確認機能が容易に利用開始できる枠組みとする。
 新ファイル転送については、必要に応じて別途検討する。

システム

 将来的には統一的なシステムで API 接続による受取人口座確認機能の実現・提供を目指す。他方、参加者の APIGW への移行が段階的であることも踏まえ、当面の間、統合 ATM（従来接続方式）を継続する。
 ただし、2025 年 7 月に APIGW が稼動予定であるところ、全銀システムと同様、受取人口座確認機能も API 接続を希望する参加者（APIGW 利用者・新規参加者）向けに、API 接続を実装済のことらの活用または全銀システムアジャイルエリアに新規実装する案（API 接続方式）を検討し、従来の接続方式と併存させる過渡期対応を講じる。過渡期対応はステップ０（ことらによる API 接続方式を提供。従来接続方式とのシステム間連携はな

1
2

議論の詳細は https://www.zengin-net.jp/zengin_net/pdf/230621_wg.pdf を参照。
議論の詳細は https://www.zengin-net.jp/zengin_net/pdf/230726_summary.pdf を参照。
3

し）、ステップ１（ことらあるいは全銀システムアジャイルエリアによるAPI 接続方式を提供し、従来接続方式とシステム間連携させる）を想定。
 過渡期対応の実現および統一的システムへの移行に当たっては、参加者システムへの影響を踏まえる。
対応スケジ

 新規参加者（預金取扱金融機関・資金移動業者）が早期に参加しやすい枠ュール等組みを整備すべく、過渡期対応の実現開始時期は APIGW の稼動時期（2025年）を念頭に置く。
 過渡期対応の実施・提供期間は、APIGW の改修タイミングや、既存参加者の RC から APIGW への移行状況を考慮する。また、統一的なシステムの実現・提供の検討に当たっては過渡期対応で講じた枠組みも考慮する。



上記の対応方針（案）を踏まえ、アジャイルエリアにおける受取人口座確認機能の実現に向けた対応として、以下６点について討議したい。
① 将来的に API 接続を前提とした統一的なシステムに一本化していく方針でよいか。
② 資金移動業者等の早期参加ニーズと既存参加者の継続利用ニーズの双方を実現するため、過渡期対応としては、API 接続方式と従来接続方式の選択制とする方針でよいか。
③ 過渡期対応につき、段階的に対応を講じていく方針でよいか。
④ 過渡期対応における API 接続方式の実現方法として、ことらを活用する案、または全銀システムアジャイルエリアに実装する案が考えられるところ、いずれの案が望ましいか。また、他に考えられる案はあるか。
⑤ 対応スケジュールと、過渡期対応の実施期間への意見。
⑥ その他関係者に求められる対応や考慮すべき事項。

意見交換（三菱 UFJ 銀行齊藤上席調査役）①について、RC が APIGW にシフトした後の将来像からすれば、API 接続を前提とした統一的なシステムへの一本化の議論はあり得るが、API 接続にシフトすれば機能が飛躍的に向上するというものでもないため、APIGW やそのルートを活用した口座確認がどのような仕組みかが提示されない現時点において統一的システムに一本化する方針を決定することはできないのではないか。API 接続方式と従来接続方式の選択制が講じられるのであれば、当面システムを併存させつつ、現実解を探っていく方向に落ち着くのではないか。
②について、第 1 回全銀高度化 WG で各参加者から発言があったとおり、既存参加者は既存のルートの継続利用、新規参加者は簡便かつ接続負荷の低いルートでの利用を望んでいることから、API 接続方式と従来接続方式の選択4







制が実現できるのであればよい案と考えられる。なお、選択制を採用する場合においても、受取人口座確認に関するガバナンスは全銀ネットに担ってほしい。また、集団契約方式への移行案は、既存の仕組みを全銀システムのサービス利用契約に巻き込むことと併せて、検討いただきたい。そのうえで、ガバナンス改善が実現した場合においても、真に API 接続方式が必要なのかは、関係者、特に新規参加者の意見をよく聞いていただきたい。
③について、段階的に対応を講じていく方針に異存はないが、API 接続方式と従来接続方式の連携が可能であることが肝。この案を採用するのであれば、コスト面、機能面、機能提供者全員の同意の面から、確実にかつ現実的に実現できることを事前に確認すべき。
④について、両案をコスト面、機能面等の観点から比較のうえ検討していくべきと考える。また、他に考えられる案として、統合 ATM に API 接続方式を新たに設けていただく案も考え得る。
⑥について、選択制の案を採用するには、システム間連携の実現是非が重要であり、これは NTT データやことら、統合 ATM 利用者組織、全銀ネット等の関係者の総意が重要。そのなかでも NTT データの意向は極めて重要であり、方針決定に向けて、次回の全銀高度化 WG までに、関係者全員と現実解の実現に向けたすり合わせを十分に実施していく必要がある。

（明治大学 小早川教授）
過渡期対応として、API 接続方式と従来接続方式の選択制とすることは避けられないが、いつまで選択制を残すかどうかは、長期的な視点で考えていくべき。
次世代 TF や全銀高度化 WG の議論を受け、受取人口座確認機能を提供している NTT データから同機能の将来像についてプレゼンテーションを行ってほしい。
⇒（NTT データ 竹村部長）関係者や事務局と相談したうえで、プレゼンテーションを実施するかどうか検討したい。
（福岡銀行 東主任調査役）
①について、受取人口座確認の統一的なシステムをどのように実現するか、各関係者間でしっかりと議論しながら検討してほしい。また、統一的なシステムへの移行は金融機関側のシステムにも影響が及ぶため、早めに情報やスケジュール等を提示してほしい。
②について、API 接続方式と従来接続方式の選択制であれば、すでに統合 ATMを利用している既存参加者にとって負担もなく、新規参加者のニーズを満たせると思うため賛成。

5



テレ為替における振込時の受取人口座確認機能の利用を必須化する方針について、ATM やインターネットバンキングにおける必須化に異存はない一方、窓口受付のものも必須化するとなると、大量に受け付けた場合に、処理に時間がかかり、顧客を待たせることや、営業店の事務負担の増加が懸念される。
また、総合振込や給与振込等の一括振込においても必須化する場合、処理ス
ピードによっては、顧客からのデータ提出時期を早めてもらう必要がある。
こうした点についても整理してほしい。

（三井住友銀行

高橋部長代理）①について賛同するものの、受取人口座確認機能に障害が発生した際に口座確認ができないとなると、大量の入金不能が生じることが想定されることから、BCP の観点も踏まえて検討を進めてほしい。例えば、ことらと全銀システムでそれぞれ口座確認のシステムを運営して、一本化しないことも一案。

②についても異論はない一方、API 接続方式としてことらを利用する場合、ことらと統合 ATM の口座確認機能の差異を踏まえて検討を進めてほしい。
③についても異論はないが、既存参加行におけるシステム開発負担を考慮すべき。
④について、ことらを活用する案に異論はない一方、検討を進めるなかで、



別の案が出てくるのであれば、それもあわせて検討すべき。
⑥について、受取人口座確認は振込に欠かせない機能であり、障害発生時の原因特定や復旧に時間を要するとなると、内為制度に支障が生じかねないことから、クラウドではなく、オンプレミスによる構築が望ましい。また、提示された対応方針（案）にテレ為替における受取人口座確認の必須化し、新ファイル転送については必要に応じて別途検討する、とあるが、新ファイル転送やテレ為替といった機能によって、口座確認を必須とするか、しないか、を決めていくのではなく、例えば、過去に振込実績のある口座については、口座確認不要といったように、例外条件を設けることで検討を進めていくのはどうか。給与振込は、テレ為替でも新ファイル転送でも可能。

（京葉銀行 菅生次長）

すでに統合 ATM を利用している既存参加者にとっては従来接続方式の方が負担が少ない一方、新規参加者にとっては、API 接続方式の方が接続しやすいため、２つの方式を選択制とする方針に異論はない。
受取人口座確認の必須化について、総合振込や給与振込まで対象とする場合、エラーが出る等の想定外のことが発生した場合に、事務負担が増えてしまう点も加味したうえで検討してほしい。


既存参加者の現在の業務や事務に大きな変更が生じないようにすることや、6

コスト負担をいかに抑えるかということが重要。
（みずほ銀行 小出調査役）

提示された対応方針（案）の方向性に違和感はない。今後の議論においては、システム面について、目指すべき方向性の２軸をもとに、統合 ATM、ことら、全銀システムアジャイルエリアの３つの対応案を比較検討していくことが必要。システム移行リスクや既存参加者のスイッチングコストを踏まえると、すでに多くの金融機関が利用している統合 ATM を活用するかたちで各種課題への対応が可能かどうかを明確にしていく必要がある。NTT データや統合ATM 利用者組織と連携して、課題整理をしたうえで議論してほしい。
スケジュールや過渡期対応については、統一的なシステムのあるべき姿を踏まえたうえで、バックキャストで考えていく必要がある。

（PwC あらた有限責任監査法人 根間シニアマネージャー）

受取人口座確認機能の方針については同意。同機能は協調領域であると考えられることから、いかに協調して効率的に進められるかという点が重要であり、システムや手続きを一本化することは非常に意義があると考えられる。
アジャイルエリア全体の開発に関し、データ蓄積や活用の観点を踏まえて検討を進めてほしい。AML／CFT については、現在、別システムが構築されているところであると認識しているが、決済システムでもある程度歯止めを利かせるような機能があるとよいのではないか。
次 期 全 銀 シ ス テ ム の 開 発 を 進 め る な か で 、 SBOM （ Software Bill ofMaterials：ソフトウェア部品表）も含めた検討が重要。オープン化に当たり、オープンソースソフトウェアを適用するなかで、そのソフトウェアがどのようなコンポーネントでできていて、どのコンポーネントに脆弱性が見つかったかということがタイムリーに自社システムで分かるような仕組みになっていないと、脆弱性が低減されない。これに対応するものが SBOM であり、経済産業省において SBOM の導入手引きが公開されるなど、国としてもSBOM の導入を期待している。今後、APIGW を通じてインターネット経由で全銀システムにアクセスできるようになるため、SBOM の導入は一考の価値があるのではないか。

（ワイズ・ペイメンツ・ジャパン 勢井取締役）

過渡期対応スキームが実現すれば、資金移動業者にとって全銀システムへの参入障壁はかなり下がる。

ことらを利用した API 接続方式の場合、受取人口座確認の対象口座は個人のみとなってしまうところ、法人まで対象範囲を拡大できないか。

7⇒（ことら 川越社長）現在、被仕向機関において口座確認範囲の制御を行っているため、被仕向機関が対応できるかどうかによるが、このタイミングで法人まで対象範囲を広げることは難しいのではないか。現在、ことらにおける名義応答は CAFIS で行っているところ、CAFIS から API に切り替えるタイミングで個人に限定しているものを法人に拡大することが現実的。
（農林中央金庫 森光部長代理）
①について、一本化の検討を行うことに異論はないが、統一的なシステムの

内容が固まっていない現時点で決め打ちすることはできないと思料。統一的なシステムよりも、過渡期対応スキームに優位性がある場合は、同スキームを恒久措置とすることも考えられるため、慎重に検討を進めてほしい。
②・③については、各参加者の事情に配慮している方針と考えられるため、異論なし。
④について、第１回全銀高度化 WG において、統合 ATM に API 接続方式を設けることも可能という説明が NTT データからあったことから、統合 ATM への実装も選択肢としてあり得ると思料。
⑤について、過渡期対応スキーム実現に当たり参加者にシステム改修が求められる場合、当業態におけるシステム基盤の更改のスケジュールも加味したうえで期間を検討してほしい。また、既存参加行として、過渡期対応に多くの人員やコストを割けないことから、統合 ATM やことら等のセンター側のシステム改修で過渡期対応スキームを構築できるようにしてほしい。
統一的なシステムへの移行については、全参加者が全銀システムへの接続をRC から APIGW に移行した後に、一斉に移行すると理解している。大規模なシステム改修が必要となると思われることから、早めに仕様開示をしてほしい。

（あおぞら銀行 有徳担当部長）
②・③について、金融機関によって受取人口座確認機能への方針や負担できるシステム対応コストが異なるため、１つのシステムに片寄せしないで、複数のシステムに機能実装して併用することが現実的という第１回全銀高度化 WG のコメントを踏まえた方針であることから異存なし。

そのほかの論点については、それぞれのシステムの詳細、コスト、事務負担等を踏まえないと決定しにくいため、現時点での判断は難しい。
（西日本シティ銀行
小野主任調査役）

既存参加者にとって、統合 ATM でも統一的なシステムでも享受できる受取人

8口座確認の結果に差異はないなか、統合 ATM から統一的なシステムへの移行に当たり、既存参加者にそれ相応のシステム負担・コスト負担がかかるのであれば、納得が得られるストーリーを描き、丁寧に説明していくことが必要。
（Fintech 協会 落合常務理事）
①～③について異論なし。
④の API 接続方式の実現方法のあり方について、コストも重要である一方、選択した実現方法と、統合 ATM の受取人口座確認機能の業務範囲の差異等API 接続先が提供できる機能についても検討が必要。
⑤について、最終的には統一的なシステム（API 接続方式）への移行を目指すところ、移行に向けたスケジュールやコスト負担を早めに示し、少しずつ対応を進めることが重要。なお、コスト負担について、足許１～２年だけでなく、長期的な目線でも考えて分析を行うことにより、個別の参加者の移行も合理的な前倒しを図ることが有益。
アジャイルエリアの検討においては、コスト面だけではなく、情報の標準化やデータ収集、付加価値の発揮といった観点も重要であることから、今後の検討に当たってはこうした観点も含めてほしい。

（全銀ネット 千葉企画部長）

本日いただいた意見を踏まえ、さらに解像度を上げていくべく、NTT データや統合 ATM 利用者組織等の関係者と議論を行っていく。
(3)海外トピック
事務局説明概要（全銀ネット 尾室グループ長）

Addressing Service についてはデータベースを構築する例（英国、EU、豪州、シンガポール、日本）と、共通アプリを構築する例（スウェーデン、米国）が見られるなか、それぞれの普及度合いは各国により異なる。
シンガポールにおいては、2017 年に PayNow という携帯電話番号等送金サービス（口座番号と携帯電話番号等の変換データベース）の運用を開始。PayNowは銀行アプリに組み込まれており、銀行は通常の振込と PayNow による送金のいずれかの方法で送金が可能。
英国では、銀行界により、2014 年から携帯電話番号と口座番号を紐づけるデータベースである Paym が開始したが、利用者数は増加せず、2023 年５月にサービス終了。
米国では、大手銀行が主体となり、口座番号に紐づいた携帯電話番号やメールアドレスで送金が可能な Zelle を開始。Zelle は独立したアプリでサービ

9





スを展開しているが、機能を各銀行のアプリに組み込むことも可能。
豪州では、決済システム運営体（NPPA）が口座番号に対応した Pay ID のデータベースの運用を 2018 年から開始。受取人が Pay ID を取得している場合、依頼人は口座番号に変えて Pay ID により送金が可能。顧客は口座ごとに複数の Pay ID を取得することが可能。
欧州では、欧州中央銀行が汎欧州のリアルタイムペイメントシステム（TIPS）で利用できる Proxy データベース基盤（MPL）を提供。TIPS の参加者は、MPLに口座番号と携帯電話番号等の Proxy データをマッピングするデータベースを構築し利用できる。



スウェーデンでは、銀行界によって Swish を開発。人口の 80％以上が利用。
Swish 開発前にも、主要行によって①携帯端末の接触を通じた個人間送金サービス、②キャッシュカードを利用した店頭支払いサービス等、様々な試みが行われていたが、いずれも普及には至らなかった。

Request to Pay（支払リクエスト）については、決済システムにおける専用メッセージとして用意する例（米国）、銀行界によって標準を定める例（英国）、共通アプリで提供する例（北欧）等、定義や対応は様々。銀行界により導入された統一的な標準や専用メッセージについては、普及に課題があることも指摘されており、各国とも利用促進に努めている状況。

英国では、決済システム運営体（Pay.UK）が 2020 年５月に支払リクエストに係るフレームワークを策定。Pay.UK はユースケースの検討を含む利用促進に努めているものの、広範な銀行を巻き込んだサービスの展開にハードルがあることや、企業側のニーズが見られないことから銀行側はサービスの展開に消極的な姿勢を見せていることが指摘されている。
米国では、民間の決済システム運営体（TCH）がもつリアルタイムペイメントシステムにおいて、支払リクエスト専用メッセージが搭載。また、中央銀行（FRB）によるリアルタイムペイメントシステム（FedNow）においても、支払リクエスト専用メッセージが搭載。FRB は、2022 年 12 月に設置したワ

ーキンググループにおいて活用方法について議論を継続中。
欧州では、民間決済システム運営体（EBA CLEARING）が、2021 年に支払リクエストに係るメッセージを送信しあえるアプリの提供を 27 の銀行（11 か国）のサポートとともに開始。また、2023 年６月には、主要行７行と支払リクエストに係る PoC を実施することを公表。

意見交換（明治大学 小早川教授）
Addressing Service の普及度合いが低い国では、導入の際に、ユーザー利便性を十分に突き詰められていなかったのではないかと思料。ことら送金が10すでにある日本で Addressing Service を導入する場合は、利用者利便性を踏まえたうえで、海外で提供されているレベル以上のサービス（生体認証の活用等）にしなければ普及は難しいのではないか。
（ことら 川越社長）
Addressing Service の各国事情がばらばらである要因について、個人情報に対する意識の国民性が異なっていることや、不正送金の増加といった環境変化も挙げられると思料なお、英国で Paym が普及しなかった理由は、Paym稼動よりかなり前に、FPS の口座番号による無料送金が幅広く普及していたことが主要因と聞いている。日本における検討に当たっては、送金に関する国民の考え方を踏まえたうえで、環境に合ったサービスを考えていくことが必要。
（Fintech 協会 落合常務理事）
Addressing Service や支払リクエストの検討に当たっては、全銀ネットという準公共のプレーヤーが、民間プレーヤーでも提供できるサービスをそのタイミングにおいて提供する意義があるのかを見極めることが重要。民間との競合の可能性をしっかりと分析しながら検討を進めるべき。
以11上