第３回「次世代資金決済システム検討ワーキンググループ」 の模様
１．日 時

2022 年６月 24 日（金）10：00 ～11：55

２．場 所

ウェブ開催（Webex）

３．議 題 (1) 情報処理推進機構（IPA）デジタルアーキテクチャ・デザインセンター（DADC）「仮想的な次世代取引基盤構築に係るグリーンペーパー」等について(2) 全銀システム参加資格拡大および多頻度小口決済の利便性向上の実現に向けた対応状況等について(3) API ゲートウェイに係る費用負担ルールの検討論点等について(4) 次世代資金決済システム構築に係る検討等について(5) 意見交換
４．議事内容「(1) 情報処理推進機構（IPA）デジタルアーキテクチャ・デザインセンター（DADC）『仮想的な次世代取引基盤構築に係るグリーンペーパー』等について」
においては、IPA-DADC から DADC グリーンペーパーの概要について説明した。
「(2) 全銀システム参加資格拡大および多頻度小口決済の利便性向上の実現に向けた対応状況等について」においては、事務局から参加資格拡大に係る業務
方法書等規則の改正方針および実施時期について、株式会社ことらからことら
プロジェクトの進捗状況等について説明した。
「(3) API ゲートウェイに係る費用負担ルールの検討論点等について」においては、これまでの全銀システムにおける費用負担ルールについて整理を行った
うえで、考え得る API ゲートウェイ費用負担ルールおよびそれぞれに関する想定論点を説明。そのうえで、API ゲートウェイ利用見通しアンケートのスケジュールおよび内容等について説明した。
「(4) 次世代資金決済システム構築に係る検討等について」においては、事務局から次世代資金決済システムの検討テーマである基礎的事項・前提事項、業務要件および機能/非機能要求等について説明した。その後、意見交換を実施した。

1

(1) 情報処理推進機構（IPA）デジタルアーキテクチャ・デザインセンター（DADC）『仮想的な次世代取引基盤構築に係るグリーンペーパー』等について
IPA-DADC 説明概要
（IPA-DADC 大久保プロジェクトマネージャー）
・ 契約決済分野のプロジェクトで解決を目指すべき課題は、大きく「取引のデジタル完結」「データ利活用を可能とするデータスペースへの貢献」の２点がある。１点目について、取引フローにおける受発注、請求および決済という各領域の課題をデジタル化により解決することを目標として各種検討を進めている。２点目について、取引に伴う様々なデータを収集し、そうしたデータを事業者間や産業間で連携、共有することでデータの利活用を推進することに取り組んでいる。
・ 決済プロセスにおけるアーキテクチャオプションについては、企業間取引で最も利用される決済手段である振込を念頭に現状の課題を抽出し、取引データのデジタル完結に向けたアーキテクチャオプションを導入する。今年度以降、実証事業を踏まえたアーキテクチャオプションの実効性の精査を予定している。
・ 来期実施予定の実証事業等を踏まえアーキテクチャオプションの実効性を精査するとともに、全銀ネット等関連ステークホルダーと連携しつつ、アーキテクチャの検討を進めるうえで、現在関係各所と調整を図っている。
・ また、当方では現在、企業や業種を跨ぐ円滑なデータ連携を実現するため、デジタル基盤の構築、その標準案および技術仕様の検討を行っており、現在NEDO において次世代取引基盤の構築に係る実証事業を公募しているところである。
(2) 全銀システム参加資格拡大および多頻度小口決済の利便性向上の実現に向けた対応状況等について事務局およびことら説明概要（全銀ネット 千葉企画部長）
・ 全銀システムの参加資格拡大に係る対応について、昨年度のタスクフォースおよびワーキンググループの議論を踏まえ、業務方法書および業務方法書取扱規則の改正内容を検討している。改正方針としては、資金移動業者および加盟銀行を対象に、参加時における財務・体制面の要件およびその後のモニタリング対応を明確にすることを検討している。なお、本改正は、金融庁による認可手続きを経たうえで、早ければ今秋にも施行する予定である。
・ また、内国為替取扱規則等各種規則についても、昨年度のワーキンググルー
プにおける整理に沿って改正の検討を進めている。本改正については、加盟銀行に対する実務影響を考慮し、安定的な移行を念頭に 2023 年 1 月頃の施2行を目標に検討を進めているところである。
・ 多頻度小口決済の利便性向上に係る対応については、ことらの資金清算スキーム実現に係る全銀システム側の仕様変更は問題なく進捗している。全銀システム側の移行および本対応に伴う規則改正はいずれも７月上旬を予定している。
（ことら 川越社長）
・ ことら側の開発について、全銀システムとの総合運転試験が完了し、現在はテスト環境において加盟事業者を対象とした試験を実施する等計画どおり進捗している。来月からは本番環境を利用し、加盟事業者の従業員等に限定した本番試行を開始する予定である。
・ また、ことらが提供するサービスについては、税納付書に記載の QR コード読み取りによる税金納付に対応する等、加盟事業者にとって付加価値のあるサービスとなるよう引き続き検討を進める。
・ ことらにおいては口座名義照会機能も実装しているところ、全銀システムを利用した為替通知の発信に先立ち当該機能を利用することも検討する価値があるのではないか。
質疑応答等
・ 全銀システム参加資格拡大に向け、当庁においても資金移動業者関係の事務ガイドライン改正について検討を進めている。改正内容は、昨年度の制度ワーキンググループにおける報告に沿ったものであり、今後パブリックコメン
トに付したうえで、全銀ネットにおける業務方法書および諸規則の改正と同じタイミングで改正することを想定している。（金融庁 水野課長補佐）
・ ことらによる送金は、銀行振込とは区別してサービス提供されるのか。また、顧客に対し、ことら送金という表現を利用することは必須か。
（Kyash 鷹取社長）⇒ことら送金という表現を推奨はしているものの、ことらは、ネットワークとしての利用も許容しており、当該名称の使用を必須としているものではない。
（ことら 川越社長）
・ ことらが提供する口座名義照会機能については、口座番号に加えて携帯電話番号の利用も想定されているところ、昨今は送金依頼人が受取人の携帯電話番号も知らないケースも相応にあると思われる。その場合の対応はどのようなものがあるか。

3

また、ことら送金は銀行や資金移動業者が提供するアプリの使用が前提となっていると思われるが、非決済事業者が Embedded Finance のような形態で、銀行や資金移動業者との提携により実装することは許容されるか。
おって、ことら送金の対象は、P2P 送金がメインであると思われるところ、個人から法人への送金等、法人決済に対象を広げる予定はあるか。
最後に、ことら送金で Request to Pay の機能を実装する予定はあるか。
（Fintech 協会 沖田代表理事会長）⇒１点目について、メールアドレスによる名義確認のほか、加盟事業者のバリューID も対応している。これら以外の方法は現状検討スコープに入っていないが、当方にご提案いただければ適宜対応を検討する。
２点目について、ことらに加盟できる事業者は預金取扱金融機関や資金移動業者等の為替取引が可能な事業者である。各事業者は、それぞれの契約形態を踏まえてアプリを選択しており、契約形態によっては組込型の利用可能性もあり得るのではないか。
３点目について、現時点で P2P 送金以外への拡大に関する明確なロードマップはない。まずは P2P 送金を確実に開始したうえで、その先の拡大については加盟事業者とも相談しつつ検討を進めたい。
４点目について、Request to Pay の実装に向けた技術的なハードルは高くはないものと思われるところ、法人決済と同様に、利用ニーズ等踏まえて今後検討を進める予定である。（ことら 川越社長）(3) API ゲートウェイに係る費用負担ルールの検討論点等について
事務局説明概要（全銀ネット 安藤大阪グループ長）
・ これまでの全銀システムにおける費用負担ルールにおいては、受益者負担を前提とし、①利用者が特定できるものについては当該利用者が負担、②利用者が特定できない場合は全参加者の共有財産とみなしたうえでシステムの利用割合にもとづいて按分負担することとされている。
・ 上記を踏まえつつ、API ゲートウェイに係る費用負担ルールについては、①利用者のみで按分負担、②一部を利用者で按分負担、一部を全参加者で按分負担、または③全参加者で按分負担等の方法が考えられる。
・ なお、統合 ATM スイッチングサービスのように１件あたりの料金を定めたうえで利用実績により請求する方法については、実現のハードルが高いことに加えて、実現した場合であっても利用者にとって利益となり得るかは未知数である。
・ 加盟銀行および資金移動業者を対象に API ゲートウェイ利用見通しアンケー4トを実施し、その結果を踏まえて API ゲートウェイの構築要否および費用負担ルールについて検討することを想定している。
質疑応答等
・ 資金移動業者を対象にした API ゲートウェイ利用見通しアンケートについて協力依頼をいただいている。当協会として、アンケート対応には協力させていただきたい。資金移動業者の中では、全銀システムへの接続に対する関心には現時点では濃淡があると思われるが、どの程度の事業者が回答対象となるのか。アンケートに当たって、API ゲートウェイの機能、当該ゲートウェイの構築前後で何が資金移動業者にとって変わるのか等の事実認識の説明をしっかりと行ったうえで事業者が誤解せずに回答できるような工夫をお願いしたい。また、加盟銀行ほどの知見がある訳ではないので、基礎的な説明を付していただきたい。（日本資金決済業協会 橋本事務局長）
・ API ゲートウェイ構築等についてはアンケートの回答結果を踏まえて検討するとのことだが、現在 RC により全銀システムに接続している参加者にとっては、API ゲートウェイを第７次全銀システム稼動中に構築する場合には、第８次全銀システムにおいて継続利用できるかどうかが判断の大きなポイントになるかと思料する。
・ RC 接続から API 接続への移行時期を、第８次全銀システムの稼動またはその他任意のタイミングとすることを前提として、費用負担ルールを上記②または③とすることも考えられるのではないか。
・ API ゲートウェイに係る費用を全参加者で一律按分負担とすることで、API ゲートウェイ稼動当初の利用者における費用負担が過大となることも回避できる。また、RC 利用者においても、RC の設置や運用に係る費用が不要となることで費用削減が期待でき、API ゲートウェイ接続に変更する動機づけの一つになると思われる。
・ また、RC と API ゲートウェイの併存期間を設け万一の場合に切り戻しを可能とすることにより、参加者側のシステム対応のリスク低減が図れるのではな
いか。（BIPROGY 日下シニアスペシャリスト）・ API ゲートウェイの費用負担ルールによっては、RC の費用負担ルールが変更されることもあるか。（信金中金 今泉室長）⇒現時点では RC の費用負担ルールの変更は想定していない。RC の費用負担ルールはすでに決定しているところ、変更する場合には相当程度大きな影響が出るものと思われる。そのため、API ゲートウェイの費用負担ルールは RC の費5

用負担ルールと切り離して検討を進めていきたい。なお、資金移動業者に対するアンケートの回答の対象範囲は、特に限定しない。
（全銀ネット 安藤大阪グループ長）
・ API ゲートウェイに係る費用負担ルールについて３つの方針を想定として提示いただいたが、論点が分かりやすく整理されていると感じる。API ゲートウェイの先行利用者における費用負担が過大となると、API ゲートウェイの利用が広がらない悪循環に陥る可能性がある。既存の RC への課題意識も背景に、新規参加者・既存参加者双方において、API ゲートウェイに対する期待は非常に大きいと感じている。イノベーションが好循環となるような仕組みを検討いただきたい。（Fintech 協会 沖田代表理事会長）(4) 次世代資金決済システム構築に係る検討等について
事務局説明概要（全銀ネット 千葉企画部長）
 次世代資金決済システムの検討テーマ②基礎的事項・前提事項について、第２回 WG においては、参加者接続方法として API 接続を導入する場合には、加盟銀行の業務全体を踏まえた議論が必要等の意見が寄せられた。また、基盤技術については、メインフレーム/オープンシステムの２つの区分で整理を進めたうえで、クラウドの利用は将来的な計画を踏まえた検討が必要等のコメントがあった。
※このほか、RC 接続と API 接続のメリット・デメリット、今後の基盤技術として考えられるメインフレーム・オープンシステム・クラウドのメリット・デメリットを整理。また、次世代資金決済システムの検討テーマ③「業務要件の整理」以降で検討すべき業務要件の観点および業務要件に対応した機能/非機能要求を整理したうえで、次回の WG で予定しているベンダープレゼンテーションを含む今後の検討において追加的に検討すべき観点について意見を募集した。
(5) 意見交換〇 将来の全銀システムのあるべき姿・求められる役割と、あるべき姿等を実現するための基礎的事項・前提事項の内容等
・ 接続方法や基盤技術については、これまでの WG や寄せられた意見等において、具体的な内容についても議論されているとの認識。これに加えて、次回
6

の本 WG で予定しているベンダーからのプレゼンテーションによって、より具体的な内容がイメージしやすくなるのではないか。
・ API ゲートウェイと RC を併存させるか完全に切り替えるかという点は重要な論点であり、費用負担ルールの検討における前提に関わってくるものと思料する。
・ また、次回本 WG で予定しているベンダープレゼンテーションについて、APIゲートウェイの利用により加盟銀行および資金移動業者が得られるメリットを提示していただけると、検討の一助になるのではないか。（三菱 UFJ 銀行石田調査役）

・ 接続方法を既存の RC 接続から API 接続に変更することにより、接続の容易性に関する課題が解消されることは事実である。一方で、接続方法の変更だ
けではより効果的な機能の利用というメリットの享受にはつながらず、例えば全銀フォーマット自体を変更することで初めてメリットが得られるのではないか。ただし、全銀フォーマットを変更した場合、加盟銀行の勘定系システムにおける為替機能を変更する必要があるなど、大きな影響が生じる可能性がある点には留意が必要である。
・ こうした点を踏まえ、全体のグランドデザインとしてゴールの設定およびゴールに至る方法に関する検討が必要である。例えば、最初は RC 接続から API接続へと接続方法のみを変更し、その後全銀フォーマットの変更にも対応するなど、二段階で変更を加えることも考えられるのではないか。その際には、過渡期における遷移方式やその時間軸についても併せて考える必要がある。
（日本アイ・ビー・エム 川口部長）
・ オープンな技術をどこまで採用するかという点も一つのポイントであり、現在の潮流では、API によるシステム間の結合が事実上標準的になっており不可避の認識である。
・ 一方で、二つの接続方式を長期間併存させた場合、最終的にはコスト増加にもつながりかねないことから、API 接続の追加時期に加えて、RC 接続の最終的な廃止時期も考慮すべき重要な事項である。（アマゾンウェブサービスジ
ャパン 松久本部長）
・ 先般日本銀行から公表された「（日銀レビュー）決済システムにおけるプログラマビリティの実現」1において、決済システムにおけるプログラマビリティの実現に関する記載があった。その内容を参考に全銀システムにおける1

https://www.boj.or.jp/research/wps_rev/rev_2022/rev22j12.htm/
7

API 接続について改めて考えてみると、為替電文の送受信等の全銀システムにおけるコアな部分に接続するための API と、ミッションクリティカルではないアジャイルな部分に対する API による開放は異なる方法でもよいのではないかと思料する。
・ 本 WG における議論では、第７次全銀システムから継続して第８次全銀シス
テムにおいてもミッションクリティカルエリアになると思われる部分を APIにより開放する方法に議論が集中しがちだが、アジャイル部分に対してもAPI を用いた開放方法を議論することも良いのではないか。
・ アジャイル部分の機能に係る議論を深めることで、全銀システムにおける新たな機能提供のあり方について、コストや時間軸も含めて検討を進めることができるのではないか。（全国銀行協会 委員会室 山本調査役）
・ 今後必要とされる付加価値機能は時代によって変化することから、ニーズに迅速に対応できるようアジャイル部分とコア部分と切り離して実現することに同意する。
・ 一方で、求められる付加価値機能として多様な候補が挙げられているところ、これらに対して柔軟に対応するためには具体的にどのような環境準備をすればよいのかという点について、次回 WG で予定しているベンダーからのプレゼンテーションでお示しいただきたい。（みずほ銀行

小出調査役）・ API ゲートウェイの開発にあたっては、全銀システムだけではなく加盟銀行における開発費用負担も含めた全体のバランスを考慮していただきたい。
・ また、API ゲートウェイに係るアンケートにおいては、全体の費用見合いの参加意思や希望する接続時期について回答が求められているところ、API ゲートウェイの利用検討には費用以外の事項も考慮する必要がある。（京葉銀行 菅生課長代理）
・ ヨーロッパを中心とした、プログラマビリティに関するこれまでの議論を踏まえると、目標がプログラマブル・ペイメントなのかプログラマブル・マネーなのかによって、グランドデザインは大きく変わる認識である。仮にプログラマブル・マネーの実現を目標とするのであれば、例えば、以前検討がなされた全銀トークンのような案も俎上にのせるのか、との論点になりうる。
そこまでを検討の視野に入れるのか、そうではなく CBDC とのすみ分けを前提に、あくまでプログラマブル・ペイメントを検討の視野とするのかについては、検討の余地があるのではないか。
・ 本 WG 冒頭の IPA-DADC のプレゼンテーションにおいて、決済プロセスにおけるアーキテクチャオプションとして全銀システムにおけるデータ規格を8

ISO20022 に対応させる案が提示されていたが、決済全体のフローを考えた場合、川上にあたる企業側の対応が進むことで初めて川下にも波及するものであり、川下にあたる決済領域のみ ISO 対応を進めても川上には波及しないのではないか。その意味では、ISO 対応を検討するのであれば、全銀システムという決済領域だけではなく、受発注領域も含めた決済フロー全体のデザインを意識する必要があるのではないか。（明治大学 小早川教授）⇒プログラマビリティについては、これまでの議論において、全ての機能を全銀システムで実現するのではなく他のシステムとの連携により実現する方法が提示されている。個人的な感覚ではあるが、プログラマブル・マネーよりも決済を軸に議論を進める方が望ましいと感じている。
また、電文フォーマットの変更は多方面に多大な影響を及ぼすことから、例えば海外の状況や実際のビジネスにおける課題等について本 WG メンバーから募るとともに、今後広く共有させていただきたい。
（全銀ネット千葉企画部長）〇 将来の全銀システムの役割や決済を取り巻く環境変化等を踏まえた次期全銀システムの必要機能（業務要件、機能/非機能要求）
・ 次期全銀システムにおける業務要件について、現行システムで利用頻度が低い機能については見直しを検討していただきたい。
・ また、全体としては API 接続が望ましいのは理解するが、個別行としては、費用やシステム対応に係る負担の大きさも加味すると、現在運用しているシステムを安全・確実かつコストを抑えつつ維持するためには RC 接続が望ましいというのが正直なところである。
・ ただし、全銀システムの度重なる更改によりシステムが積み上がり、複雑なシステム構成となっていること、また、それに伴い人材確保の観点からも事務システムに課題が生じていることも事実である。現状維持のシステムが良いというものでもなく、棚卸等を行い不要な機能を廃止することで、コスト削減・構造の簡素化を図っていただきたい。
・ そうした点では本 WG における議論は大変有意義である一方で、既存の加盟銀行においては現行システムの維持も重要な観点である。先の議論でゴールをどこに置くかという話もあったが、最終的に目指すゴールを共有していた
だいたうえで、上記の内容も踏まえつつ、例えば第８次全銀システムではどこまで対応するか等について加盟銀行が納得できるようなかたちにしていただきたい。（福岡銀行 樋口氏）
⇒第８次全銀システムで全ての対応が完了することが理想ではあるが、コスト9やリスク等のハードルの高さを踏まえると、第８次全銀システム稼動までの期間、期中、それ以後の将来的な対応というステップで検討を進めることになるのではないか。（全銀ネット 千葉企画部長）
・ 新ファイル転送を利用して発信される為替データは当初の想定より非常に少なくなっているのではないか。例えば総合振込を新ファイル転送ではなくテレ為替で発信する金融機関も相当数存在しているものと思われる。次期全銀システムを検討しているこの機会に新ファイル転送の必要性を改めて検討すべきではないか。
・ テレ為替に機能を一本化した場合は、サーバがダウンした際の対応について検討が必要であろうが、テレ為替サーバの運用体制を強化するという方法も考え得る。（全国銀行協会 委員会室 山本調査役）⇒新ファイル転送についてはその必要性に加えて、システムの規模についても検討が必要ではないか。現在の新ファイル転送の処理能力はテレ為替とほぼ同程度である認識であり、重厚すぎる印象である。
（三菱 UFJ 銀行 石田調査役）⇒昨年度の検討においても、資金移動業者における新ファイル転送業務への対応要否に係る議論もあったところ、基本的には全業務に対応いただくこととした。他方で、新ファイル転送の対応を必須とすることで、それに応じた社内・行内体制の構築等、付随的な対応が種々生じているものと思われる。新ファイ
ル転送についての見直しは参加者の運用負担の軽減やシステムのスリム化にも資する可能性があり、今後の検討事項の一つとしたい。
（全銀ネット 千葉企画部長）
以10上