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

2022 年 11 月 25 日（金）10：00 ～11：40

２．場 所

ウェブ開催（Webex）

３．議 題(1) API ゲートウェイの検討状況等(2) 次世代資金決済システムの検討

４．議事内容「(1) API ゲートウェイの検討状況等」においては、事務局から、全参加者の利用を前提とした API ゲートウェイの要件見直しの検討結果および API ゲートウェイのサービス提供開始時期に係る中間整理を説明。
「(2) 次世代資金決済システムの検討」においては、事務局から、既存取扱業務・提供機能の対応方針案、メンバー等からの要望事項等への対応方針案およびアジャイルエリアにおける新機能・新サービスの対応方針案を説明。
(1) API ゲートウェイの検討状況等
事務局説明概要（全銀ネット 安藤グループ長）
 API ゲートウェイの要件について、全参加者の利用を前提とし、RFP から以下の機能・非機能要件を見直すことを検討部会において検討。
区分項目機能業務開始

内容
・利用者とのテレ為替・新ファイル転送の業務開始/終了について、全銀センタからの開始/終了通報を契機とする仕組みに変更

新ファイル転送・被仕向ファイルの再送信機能を追加
・ファイルアップロード完了の通知方法を API 方式に変更

電文照会

・API ゲートウェイの東阪で送受信状況のログを同期し、電文照会機能に活用

非機能

処理能力

・初期構築時は、片系で 150 万件/時程度の性能まで段階的に確保（テレ為替）

・１利用者当たりの処理能力を RC と同等に引き上げる・システム更改に併せて、片系で 300～400 万件程度の送受信が可能となるように性能を増強

処理能力

・初期構築時は、RFP と同様（片系で 100 万レコード/時程度の性能）（新ファイル転・システム更改に併せて、片系で 150～200 万レコード/時程送）
利用者数度の送受信が可能となるように性能を増強することを想定
・初期構築時は、最大で 200 先程度の利用者を想定しつつ、シ1

ステム増強や更改において拡大可能となるよう拡張性を確保
ライフサイクル・次期全銀システムの利用期間終了（2035 年 11 月予定）までをサービス提供期間とする
・期中に１度のハードウェア更改を見込む

その他

全銀センタ接続・API ゲートウェイと全銀センタ間の接続に係る回線等の費用を見積りに計上



また、RC 利用期間を 2035 年（RC23 シリーズ最終導入行システムライフ到来時）までとすることを前提に、API ゲートウェイのサービス提供時期について、2025 年上期、2025 年下期、2026 年上期および 2026 年下期のいずれが望ましいかについて、①初期利用者の準備期間、②RC 期限までの準備期間、③二重コスト、④参加希望者の意向、⑤既存参加者の意向、⑥次期システムへの影響および⑦次期システムからの影響の観点を踏まえ整理。今後、12 月に実施する加盟銀行および資金移動業者向けアンケート結果等を踏まえ、引き続きサービス提供時期を検討予定。

意見交換 2025 年上期に API ゲートウェイのサービスを開始する場合、2027 年からの

次期全銀システムの稼動に伴い、API ゲートウェイの仕様見直しが必要となる可能性を指摘しているが、個別行のシステムの見直しも生じるのか。
RC 利用期間を 2035 年までにする場合の留意事項はあるか。（全国銀行協会委員会室 寺部上席調査役）⇒ 次期全銀システムの仕様の見直しに伴い API ゲートウェイ仕様書が変更となる場合は、個別行においても変更に沿ったシステムやアプリケーション等の修正が必要。ただし、RC についても次期全銀システムの仕様変更に伴い RC 仕様書が変更となれば、同様の対応が必要であり、API ゲートウェイに移行していた金融機関だけが追加対応が必要となるということではない。
⇒ 次期全銀システムの開発ベンダーが現行ベンダーの NTT データではない場合の RC の取扱い（当該開発ベンダーと NTT データどちらに提供していただくか等）について検討が必要。（全銀ネット 安藤グループ長）(2) 次世代資金決済システムの検討
事務局説明概要（全銀ネット 千葉企画部長）
 現行システムにおける取扱業務・提供機能について、これまでの議論や前回ワーキンググループ以降メンバーから寄せられた意見（安全性確保、コスト2

削減、運用負担軽減、参加者側のシステム面・運用面への影響考慮等）も踏
まえ、各論点の対応方針案を以下のとおり整理。
論点

対応方針案・次期全銀システムにおいても、現行と同等の安全性・可用性の確保・持続可能なシステムとするため、メインフレームを前提としたシステムからオープン化を志向しているところ、オープン化に伴うセンタの構成製品選定に当たり、製品の実績や確実かつ継続的な保守を受けられることを重視。特定のベンダーに依存しないことも留意
・コア／モアタイムシステムの構成は参加者への影響も踏まえ、現状維持
・柔軟性・効率性向上のため、機能特性に応じた集約化・再配置を行う
・機能間連携は疎結合化を前提として、重複感のない最適な機能配置を志向 等

運用時間帯
接続方法（RC）
テレ為替処理・現行と同様の運用時間帯を維持 等
・次期全銀システム稼動時は RC と API ゲートウェイを並存。将来は API ゲートウェイに一本化 等
・基本的な処理スキームは現行の処理を踏襲。ただし、拡張性・柔軟性確保のため、可能な限りシンプルな設計を志向

等

・取扱いがない種目（例：先日付振込・貸付信託収益配当金）は廃
テレ為替の取扱種目

止する方向のほか、利用件数・金額が少ない種目（例：振込・貸付信託収益配当金等）は要件定義工程での参加者の利用実態を踏まえ廃止要否を検討し、スリム化を図る 等

新ファイル転送処理・処理方法は現行のかたちを踏襲。
・参加者の業務効率化・運用負担軽減の観点から、テレ為替と新ファイル転送にセットできる情報の統一化・制度化について検討 等
・取扱いがない種目（例：文書為替・国庫金、貸付信託収益配当金

新ファイル転振込）は廃止する方向のほか、利用件数・金額が少ない種目（例：送の取扱種目一括支払システム取引明細等）は要件定義工程での参加者の利用実態を踏まえ廃止要否を検討し、スリム化を図る 等
・次期全銀システム稼動時は現行と同様としつつ、将来を見据えた使用可能文字あるべき姿の検討が必要。
・参加者システム側で保有する顧客情報や運用等への影響も考慮

決済処理概要・現状の枠組み（１億円以上は即時グロス決済、１億円未満は時点ネット決済）を維持 等
・情報系の高度化や担保管理・仕向超過額管理の API 化等により、仕向超過額管理処理

仕向超過限度額の運用性向上（即時引上げ等）を志向
・加盟銀行の担保負担軽減の観点を踏まえ、仕向超過額管理テーブルの設定等詳細について要件定義工程で検討 等

3

論点

対応方針案

管理・還元資料

・柔軟な分析・集計を可能とする方向性を志向
・将来のデータ利活用の進展も見据えつつ、具体的な帳票要件・内容を要件定義工程で整理 等

金融機関店舗・加盟銀行の煩雑な登録手続きの解消や、一部手作業を行っている

情報処理処理の自動化を含めた負担軽減を志向 等

担保管理・「仕向超過額管理処理」との連携による運用性向上を志向 等
・テレ為替・新ファイル転送業務との結合度を下げることで、情報情報系システム系システムの機能をスリム化し、データ参照の業務に特化・機能重複の排除や参加者側の運用柔軟化の実現を志向
・情報系システムの BCP への活用可能性の観点も念頭に置く 等

メンバー等から寄せられた業務・機能・非機能等に係る要望事項等への対応
方針案を以下のとおり整理。
業務・機能

テレ為替

要望事項等

対応方針案

入金ステータスを・実装する場合、RC から API ゲートウェイへの移確認可能とする仕行が進展したタイミングで、API ゲートウェイ更組み改時に併せて対応することが効率的か異例処理が生じな・取引の仕向・被仕向間の照会に係るコミュニケーい仕組みの構築

ション・ワークフローをシステム化することが考えられるか

繁忙日における電文滞留の解消

新ファイ
ル転送

・繁忙日におけるコアタイム時間の拡大等による対応を志向

参加者の利用ニー・新ファイル転送の利用を選択しない参加者に対ズ・実態を踏まえして、全銀システムでの編集処理後に、テレ為替た利用選択制の導でシングル電文として電文送信を行うことが考

入

えられるか
・ただし、相対交換ファイルは件数が多く、上記と同様の方式を採用することは困難であるため、対応を別途検討することが必要

仕向超過限度額抵触

・情報系の高度化や担保管理・限度額管理の API 化

担保管理・ 時でもエラーになら等により、仕向超過限度額管理の運用性（即時引仕向超過ない仕組みの導入

限度額管仕向超過限度額抵理

触時に係る対応の上げ）を向上させる対応が現実的か

負担軽減

4業務・機能要望事項等

対応方針案

翌２営業日以降の仕向超過限度額の柔軟性向上
全銀システムの接その他

続先数の増加・今後の長期的な接続先数の増加を想定したうえで、上限見直しの要否を要件定義工程で検討

アジャイルエリアにおける新機能・新サービスの対応方針案は以下のとおり。
機能対応方針案

口座確認・稼動時に実装する方向

Addressing Service

・将来の環境変化や利用者ニーズの変化等を見据え、システム上考慮。稼動要否はニー

Request to Pay

ズの高まり等を踏まえて適宜判断

実現の選択肢
全銀システムの一機能として実装または外部連携により実現

意見交換 コアタイムシステム・モアタイムシステムの構成について、両システムを統合せずに、現状と同様に２つのシステムに分けることについて、参加者への影響や両システムを分けて開発した経緯（コアタイムシステムに可能な限り影響が出ないようにモアタイムシステムを開発する）を踏まえると賛成。一方、システムを分けたままとする場合は、モアタイムシステムにおける取扱可能種目の拡大等、両システムの差分の埋め合わせを行い、利用者から両システムの差分を意識させないようなシームレスな設計を検討すべきと考えるが、ベンダー各社の見解を伺いたい。（明治大学 小早川教授）⇒ システムや参加者への影響のほか、メンテナンスの観点（両システムを統合すると、メンテナンス時にシステムがすべて止まる）等を踏まえると、両システムを分ける現在の形態を継続するメリットは大きい。なお、ご指摘の両システムの提供機能の差分の埋め合わせのほか、仮想化等の新技術を駆使したリソースの効率化を図ることで、より最適なシステムを目指していく余地はあるものと思料。（NTT データ 清水課長）⇒ 銀行ではコアタイム・モアタイムの切り替えのタイミングにおいて負担があるため、そこを意識させないようなシームレスな仕組みが望ましいというのは指摘のとおり。（日本アイ・ビー・エム 金井部長）⇒ コアタイムシステムが万が一停止した時に、モアタイムシステムを速やかに立ち上げるといった BCP 面の強化策も検討していることからも、両システムの構成について現状維持が望ましいと思料。
（全銀ネット5千葉企画部長）
BCP やメンテナンスの観点から、交互に運用できる同一のシステムを２つ保有することが望ましいと言える。この点について、コアタイムシステムとモアタイムシステムが分離している現在の形態を活かすかたちで、検討が行われているということでよいか。（PwC あらた有限責任監査法人 根間シニアマネージャー）⇒ ご指摘のとおり、現在のシステム形態を活かしながら、将来的には２系統交互に運用できるシステムに近づけていくことが望ましいと考える。
一方、接続インタフェースとして、参加者システム側で、コアタイムシステムとモアタイムシステムを識別している現状を踏まえると、次期全銀システムにおいては、両システムの区分を踏襲する方針が望ましいと思料。なお、API ゲートウェイの構築において、新たな API 仕様を策定していく中で、参加者側が両システムの区分を意識しない仕組みを採用することは考えられる。（NTT データ 清水課長）



次期全銀システムにおける現行システムからの抜本的な変更点やチャレンジとなる事項は何か。（全国銀行協会 委員会室 寺部上席調査役）⇒ 環境変化に迅速に対応するためのミッションクリティカルエリアとアジャイルエリアのエリア分け、効率化の観点からの機能配置の見直し、アジャイルエリア実装機能について外部連携の検討、RC から API ゲートウェ
イへの移行等が挙げられる。また、将来の環境変化を見据え、オープン化を志向していることも変更点として挙げられる。
（全銀ネット 千葉企画部長）

DX やデジタル化を推進するに当たり、各処理をデータで完結させることが重要であることから、参加者ニーズ等を踏まえ、データ処理が円滑に進む方針を整理してほしい。
全銀システムへの参加を検討している資金移動業者にとって、次期全銀システムに実装される機能等は参加決定の重要なファクターになることから、次期全銀システムの検討内容やロードマップ等を可能な限り早いタイミングで公表してほしい。（Fintech 協会 落合常務理事）
以6上