全銀ネット有識者会議
2023年 1 月 16 日

全銀ネット調査レポート 2022

2022 年 12 月
一般社団法人全国銀行資金決済ネットワーク

3

【

目

次

】

Ⅰ．はじめに................................................... 1
Ⅱ．調査結果................................................... 2
１．諸外国の動向............................................... 2(1) API 活用の動向.........................................

2(2) 米国・英国における新システム構築の動向等...............

7

２．新技術の検討............................................... 28(1)オープン化の動向と課題..................................

28(2)次期全銀システムに関するベンダープレゼンテーション......

36

Ⅰ．はじめに
全銀ネットは、第４次中期経営計画（2022 年度～2024 年度）における検討事項として、「次期全銀システムの構築に向けた対応」を掲げており、「全銀ネット有識者会議」や「次世代資金決済システムに関する検討タスクフォース」の議論等を踏まえ、デジタル社会に相応しい次期全銀システムのグランドデザインを描き、構築に向けたロードマップを示すとともに、必要な対応を着実に進めることとしている。
これを踏まえ、本年度は、「次世代資金決済システムに関する検討タスクフォース」および下部に設置した「次世代資金決済システム検討ワーキンググループ」、関連する検討部会に お い て 、 次期 全 銀 シス テ ム の 基 本方 針 の 策定 に 向 け 議 論を 行 っ てい る ほ か 、 API（Application Programming Interface）を活用した接続基盤（API ゲートウェイ）の構築に向けた検討を進めている。
本年度のレポートは、次期全銀システムの構築に向けたこれらの検討に資するべく、APIの活用に係る諸外国の動向や、米国・英国における新たなシステムの検討・構築に関する状
況を紹介するとともに、基盤技術を巡る国内の動向や課題等について取りまとめた。
本レポートが次世代資金決済システムに関する検討の一助となれば幸甚である。
企画部 調査広報グループ

1Ⅱ．調査結果
１．諸外国の動向
本章においては、資金決済システムを巡る諸外国の動向について紹介する。
前述のとおり、現在全銀ネットにおいては、API ゲートウェイの構築に向けた検討を進めている。これに関し、諸外国においても API を資金決済システムに活用する動きが見られることから、本章第一節においては、この API の活用例についてまとめている。
また、日本における次期全銀システムの構築と同様、米国・英国においても、それぞれ、
FedNow、NPA という新システムの検討・構築が進められ、両国における決済改革の中心的なトピックとなっている。加えて、両システムの進捗は、リアルタイムペイメントを超えた次なる資金決済システムを模索する動きとして、国際的にも注目されている。両システムの検討・構築における議論は、次期全銀システムの検討にも参考となる点があると考えられるため、本年度は、本章第二節において、FedNow、NPA に関する動向を記載している。
このほか、資金決済システム運営体の中でトピックとして挙がりつつある事項として、二国間のシステム連携がある。この取組みについては、各国により実態や事情が異なる面があるものの、フォローすべき動きと考えられることから、本章の最後に整理している。

(1) API 活用の動向①英国
英国の中央銀行（BOE）は、銀行等の当座預金間の資金移動を行うための RTGS（RealTime Gross Settlement：即時グロス決済）システムを運営している。この RTGS システムには、民間団体（Pay.UK）が運営する資金決済システム等も接続することで、英国内の資金清算を実現させている。現在 BOE は、RTGS システムのリニューアルを進めており、
2023 年春にメッセージ形式を ISO20022 に移行したうえで、2024 年春には、新たなコアシステムに移行することを予定している1。
リニューアルにおいては、広範なアクセスを可能とすることがビジョンの１つとして掲げられ（図表１参照）、これを実現する方策として、API の活用を目指している。また、2022 年４月には、今後のリニューアル方針に関する市中協議2が公表され、当初はシステ
ム内のデータへの照会機能に絞って API を提供することや、支払指図の送信を含めた他の機能における API の活用については今後検討することが提案された（概要等は図表２参BOE 市中協議文書（https://www.bankofengland.co.uk/paper/2022/roadmap-for-real-time-gross-settl
ement-service-beyond-2024）参照。
2 同上。
1

2

照）
。
【図表１：RTGS リニューアルのビジョン】（出典：BOE ウェブサイト）【図表２：市中協議における API 関連部分の概要等】
・ 新 RTGS システムにおいては、API による取引・データ照概要

会を可能とすることを検討。
・ API の活用により、参加者との緊密な連携や広範なアクセスを実現する。
・ （2021 年 10 月）取引データ読み取りを可能とする API 仕

これまでの対応様を公開。参加者からフィードバックを受領。
・ （2022 年６月）RTGS パイロットプラットフォームにおいて、SWIFT API Gateway を利用した最初の API を提供。
・ （2024 年春）以下のデータへのアクセスを実現する API を提供開始。

今後のスケジュール

✓

全ての取引

✓

当座預金データ✓

支払・流動性コントロール

✓

通知・報告

※API の利用は選択制とする予定。ただし、一部機能について
API に限定する可能性あり。

3

・ （2024 年以降）サンドボックス、フィードバックツール等を具備した「RTGS API プラットフォーム」を提供。また、以下を実現する API の提供を検討。
✓

流動性コントロール

✓

データ分析

✓

ネットワークの選択✓

支払指図の送信 等（BOE ウェブサイトをもとに事務局作成）

市中協議においては、特に 2024 年以降に検討・提供を予定している機能（流動性コント
ロール・支払指図の送信）の API 化が、実際にどの程度必要かという点について問いが投げられている。このため、市中協議の結果を踏まえ、今後 API の実際の活用範囲が定まっていくものと考えられる。
②シンガポール
シンガポールにおいては、FAST と呼ばれるリアルタイムペイメントシステムが、2014
年から稼動開始し、シンガポール銀行協会（ABS）等によって運営されている。
FAST の参加者は、当初銀行に限られていたものの、銀行やノンバンク、ABS 等から構成されるワーキング・グループがノンバンクの接続について検討を進め、2020 年 11 月、
以下詳細とともに、ノンバンクの接続を認めることが公表された3。
【図表３：シンガポールの検討結果】
参加資格

・ 「Major Payment Institution」4のライセンスを保有する事業者。
・ 直接接続により、ノンバンクの電子ウォレットと銀行口座、あるいはノその他

ンバンクの電子ウォレット間で送金が可能となる。
・ オーバーレイサービスの PayNow（FAST と連携した携帯電話番号データベース）への参加も可能。
（MAS（Monetary Authority of Singapore：シンガポール金融管理局）
ウェブサイトをもとに事務局作成）

同ワーキング・グループは、このノンバンクの接続とあわせて、API による新たな接続
詳細については、全銀ネット調査レポート 2021（https://www.zengin-net.jp/company/pdf/report_202
1.pdf）参照。
4 「Standard Payment Institution Licence」と異なり、月次の取引量や、顧客のアカウント残高において制限がない一方、資本金等の面で強い規制がかけられているライセンス。
3

4

口（API payment gateway）についても検討を行い、ノンバンクの接続が開始する 2021
年２月には、API payment gateway の開発を完了させた5。実際に FAST には、GPay
Network や Wise 等、現在６社のノンバンクが接続しており、複数のノンバンクが API
payment gateway を活用しているものと考えられる6。また、API payment gateway は、銀行も利用可能とされていることから、今後 API により接続する銀行も現れてくるものと考えられる。
この API payment gateway に関し、FAST のシステム管理等を行うベンダーである
Banking Computer Services の Lawrence Chan 理事長は、「我々はシンガポールの産業を強化するための大規模な決済に係る国家プロジェクトを、金融界とともに推進してきた。API payment gateway の成功は、FAST や PayNow にとって重要な意味を持つ。」7とのコメントを残しており、ノンバンクが資金決済システムに参加するに当たり、API 接続が重要な要素であったことがうかがえる。
③インド
インド準備銀行・インド銀行協会が設立したインド決済公社（NPCI）は、インド国内
におけるリアルタイムペイメントの促進のため、2006 年から UPI と呼ばれる決済インフラを稼動させている。
図表４のとおり、UPI は、スマートフォンアプリやインターネットバンキング、ATM等様々なチャネルにおいて利用できる資金決済システムである。また、個人や企業の送金のみならず、店頭決済においても利用されていることから、稼動開始以降、取引件数は急速に拡大している（図表５参照）。
【図表４：UPI の対象チャネル】（出典：NPCI ホワイトペーパー）MAS ウェブサイト（https://www.mas.gov.sg/news/media-releases/2020/non-bank-financial-institutio
ns-to-have-access-to-fast-and-paynow）参照。
6 ABS ウェブサイト（https://www.abs.org.sg/docs/library/fast-fact-sheet.pdf）参照。
7 MAS ウェブサイト（https://www.mas.gov.sg/news/media-releases/2020/non-bank-financial-institutio
ns-to-have-access-to-fast-and-paynow）参照。
55【図表５：UPI における取引件数の推移】（出典：NPCI ホワイトペーパー）

UPI は、銀行のみならず、銀行と提携した Third Party Application Providers も接続して送金することができ、Google Pay や Amazon Pay 等がこの形態で接続している。
また、UPI へのメッセージ送信と UPI 内部でのクリアリングの仕組みは、図表６のとおり、特徴的なかたちがとられており、Third Party Application Providers のサービス（アプリ等）を利用して依頼人が送金すると、依頼人が UPI に登録している銀行と、受取人が UPI に登録している銀行の間で、クリアリングが行われる。
【図表６：UPI の仕組み】（出典：NPCI ホワイトペーパー（一部事務局が追記））

6

この UPI におけるメッセージの送受信は、全て API で行うこととされており、これにより、Third Party Application Providers の接続や、Third Party Application Providers
による新たなサービスの開発が容易になっていると NPCI はコメントしている。日本を含む諸外国とはややスキームが異なる決済システムではあるものの、国家的に API を活用しながら、銀行界を巻き込み、Google Pay や Amazon Pay といった新たなサービスとの競争やイノベーションを促進している様子がうかがえる。
以上が諸外国の決済システムにおける API の活用に関する動向である。シンガポールのように、すでに資金決済システムにおける電文の送受信に直接 API を活用している動
きや、英国のように段階的に API の活用範囲を広げていく動きからは、資金決済システ
ムにおける API の活用が徐々にスタンダードとなる可能性もある。なお、このほかにも、
資金決済システムとは直接関係がないものの、資金決済システムの運営体が、決済事業者と銀行との間の接続に関する API（送金等関係）について標準仕様を定め、サンドボック
スを用意するといった取組みが豪州等において見られる。
全銀ネットにおいては、第７次全銀システム稼動中（～2027 年）に API ゲートウェイを構築する方針としているところ、要件定義に向けて、引き続き、これらの国や他の国における動向をフォローしていく。

(2) 米国・英国における新システム構築の動向等①米国 FedNow の動向
米国においては、大手銀行が主体の資金決済インフラ運営体（TCH）が運営する決済システムと、中央銀行（Fed）が運営する資金決済システムの双方が稼動している。リア
ルタイムペイメントシステムについても、2018 年に TCH が 24/7 リアルタイムペイメン
トシステム（RTP）を導入し、その利用促進に努めている一方で、Fed はより広範な銀行の参加を主な目的とし、2019 年以降独自のシステム（FedNow）の構築を進めている。
FedNow の詳細は図表７のとおりであり8、RTGS をベースとしていることのほか、支払リクエスト専用の電文や送金上限機能が具備されている点が全銀システムとは異なる特徴となっている。

詳細については、全銀ネット調査レポート 2021（https://www.zengin-net.jp/company/pdf/report_202
1.pdf）参照。
87

【図表７：FedNow の概要】
・ RTGS をベースとした資金決済システム。
基本事項

・ Fed に口座を保有できる機関が参加可能であり、ノンバンクは直接接続不可。
・ 各機関が取引上限や取引条件をセットする機能を具備（不正取引抑制等への活用が視野）。
・ 支払リクエスト専用の電文送受信可能（FedNow 参加者の支払
リクエストに関するサービス開発を容易にし、顧客の利便性向

関連機能上につなげるもの）。
・ 流動性確保のため、参加者の中銀口座間での資金移動を可能とする機能（FedNow LMT）を具備。FedNow そのものに参加していない機関も利用でき、民間の資金決済業者も、ジョイント
アカウントを利用したセトルメントや流動性確保に活用可能。
（Fed ウェブサイトをもとに事務局作成）

稼動開始時期については当初 2023 年中とされていたところ、2022 年８月、Fed はさらにその時期を絞り、2023 年中ごろに稼動開始することを公表した9。間近にせまった稼
動開始に向け、現在は詳細なルール検討や利用促進活動が行われており、本項においては、
その一部について紹介する。
a. FedNow の手数料等の一部公表
2022 年１月、Fed は FedNow の手数料に係る方針を公表した。詳細は今後提示するとしているものの、図表８のとおり、送金や支払リクエスト等に関し具体的な金額が示されている。
【図表８：FedNow における手数料等の概要】
参加（月額）費用送金
支払リクエスト
送金上限

・ 各 routing transit number （RTN）（送金を受け取るための登録番号）ごとに、月額 25 ドル。
・ 1 件当たり 0.045 ドルを送金側が負担。
・ 1 件当たり 0.01 ドルをリクエスト側が負担。ただし、リク
エストに応じた送金に係る費用も含まれる。
・ 50 万ドル。初期値として 10 万ドルを設定しているものの、各金融機関において、引き上げや引き下げが可能。
（Fed ウェブサイトをもとに事務局作成）

Fed ウェブサイト（https://www.federalreserve.gov/newsevents/pressreleases/other20220829a.htm）
参照。
9

8

前述の RTP（大手銀行が運営する TCH のリアルタイムペイメントシステム）の手数
料は、送金 1 件あたり 0.045 ドル、支払リクエスト 1 件当たり 0.01 ドル（リクエストに応じた送金に係る費用を含む）であり10、上記の FedNow の手数料は RTP と同額とされている。このことからは、中央銀行と民間のリアルタイムペイメントシステム間で不平等な競争環境が生まれないよう配慮されていることがうかがえる。
なお、RTP においては、支払リクエストの利用促進のため、リクエストに応じた支払いが完了した場合、リクエストを送信した金融機関は、リクエストに応じた金融機関に、インセンティブとして 0.1 ドルを支払うこととしている。FedNow においても特徴的なインセンティブが用意されるかは、今後注目される。
b. FedNow Explorer の開設
2021 年 10 月、FedNow の利用促進等を目的に、FedNow Explorer という特設ウェブ
サイトが開設された。ウェブサイトにおいては、FedNow の概要や、これまでに公表された資料が掲載されており、関係者別（金融機関、決済事業者、顧客）の情報提供が可能な仕組みも用意されている11。
【図表９：FedNow Explorer のトップページ等】（出典：FedNow Explorer）

また、
2022 年３月には、FedNow に関連したサービスを提供する予定の企業を紹介し、金融機関との連携を促進させることを目的とした特設サイト（Showcase Theater）も、
FedNow Explorer に開設された（図表 10 参照）。現在、Showcase Theater には、銀行のコア業務に係るシステムプロバイダー、請求書発行事業者、決済事業者、モバイルやオンラインバンキングのプラットフォームプロバイダー等、様々なサービス提供企業が掲載されている。FedNow の関係者からは、Showcase Theater への掲載を希望する企業がTCH ウェブサイト（https://mc-e3a82812-8e7a-44d9-956f-8910-cdn-endpoint.azureedge.net/-/media/
New/TCH/Documents/Payment-Systems/RTP_Pricing_01-01-2021.pdf?rev=92439cfb40c84015ad629f1f
26fdcb3d&hash=BAD5289DCC2EE4DB49B05E3A522D6618）参照。
11 FedNow Explorer 参照（https://explore.fednow.org/）
10

9

多く、FedNow が米国内に変革をもたらしつつある旨コメントされている12。
【図表 10：Showcase Theater の内容】

（出典：FedNow Explorer）

c. 支払リクエストの利用促進
前述のとおり、FedNow においては支払リクエスト専用のメッセージが送受信可能であり、Fed はこの支払リクエストの利用促進にも力を入れている。支払リクエストは、図表 11 のとおり、受取人側の金融機関が支払人側の金融機関にメッセージを送信し、支払人側の金融機関は支払人に確認のうえ、リクエストに応じて送金するというものである。
また、FedNow における支払リクエストの項目等は図表 12 のとおりであり、必須項目である支払人（受取人）情報やリクエスト金額等の基本情報のほか、支払人における支払金額修正機能や期日前支払機能など、サービスによって使い分けが可能な任意の項目・機能も用意されている。

Fed ウェブサイト（https://www.frbservices.org/news/press-releases/030822-fednow-service-provider-showcase-launch）参照。
1210【図表 11：支払リクエストの仕組み】（出典：Fed ウェブセミナー）【図表 12：支払リクエスト入力項目等】

必須項目

任意項目・機能

支払人情報および受取人情報

リクエスト金額



支払期日



支払可能期限（期限後は支払リクエストに応じた送金不可）



支払金額修正機能（支払人によって支払金額が修正できる機能）



支払期日前支払機能



その他情報（140 文字以内の情報（ハイパーリンク可））（FedNow ウェブサイトをもとに事務局作成）

2022 年５月には、FedNow の幅広い関係者（金融機関やサービス提供事業者等）が参加しているコミュニティ（FedNow Community）において、支払リクエストの活用に関するウェブセミナーが開催された13。セミナーにおいては、支払リクエストのユースケー
ス（企業や個人、E コマースや定期的な送金等）や、顧客のメリットについて紹介が行われたほか、支払リクエストを利用した場合の削減コストについても、具体的な金額を明示のうえ強調された（図表 13・14 参照）。

Fed ウェブサイト（https://www.frbservices.org/financial-services/fednow/community/news/083122-e
cosystem-rfp-webinar）参照。
1311

【図表 13：セミナーにおける説明内容抜粋①（支払リクエストの用途等）】（出典：Fed ウェブセミナー）【図表 14：セミナーにおける説明内容抜粋②（削減コスト）】（出典：Fed ウェブセミナー（コメントは事務局が追加））

このほか、セミナーの中では、以下のような QA のやりとりもあり、支払リクエストに関し、今後メールアドレスや電話番号を活用したサービスを開始するという旨の発言も
あった。

12

【図表 15：セミナーにおける QA】
Q
リクエストされた人以外の人が、代わりに支払いを行うことA

の、将来的には検討事項となり得る。

はできるのか。
支払リクエストの送信者は支払人の銀行等をどのように特定するのか。

他の人が支払うことは現在想定していないもの

支払リクエストの送信者が、支払人から銀行等を聞いたうえで、電文を作成する必要がある。



ただし、メールアドレスや電話番号のデータベースを活用し、支払人の銀行を特定できるようにする環境構築について現在検討を進めているところである。
（ウェブサイトをもとに事務局作成）

前述のとおり、支払リクエストは相手の金融機関との連携によって成立するものである。このため、１つの金融機関だけでは支払リクエストを機能させることはできず、支払リクエストの成功には、複数の参加金融機関を巻き込んだサービスの提供が求められ、Fed が支払リクエストの利用促進に力を入れていることには、この難しさが関係していると考えられる。英国において、金融界が構築した支払リクエストのスキームが活用されていないとの報告（詳細は後述参照）もあり、Fed がどのようにしてこの難しさを克服していくか、今後注目される。
以上が FedNow の動向である。FedNow の検討が開始した頃には、すでに多くの金融機関が参加している民間のリアルペイメントシステム（RTP：大手行中心で運営されている TCH が運営）が稼動している中、2023 年の稼動は遅いという声や、実際にどの程度の金融機関が参加するかは不透明だとの声も聞こえていた。一方、来年に稼動開始が迫った現在において、上記のように多くの関連事業者が自社のサービスについてウェブサイ
ト上で紹介していることを踏まえると、米国内における期待は高まっているものとも考えられる。なお、別途行われている FedNow のパイロットプログラムには、100 を超える金融機関等が参加している。
稼動開始が間近となった新システムにおける Fed の利用促進活動等については、参加資格を資金移動業者に拡大した全銀ネットにとっても興味深い取り組みであり、引き続き注視していきたい。
②英国 NPA の動向
英国においては、民間団体の Pay.UK が小口決済システム（FPS）や、バルクシステム（Bacs）を運営している。2018 年に Pay.UK が FPS と Bacs を統合した新たなシステム
である NPA の調達プロセスを開始して以降、NPA は英国内における決済改革の１つと13

して検討が進められた。NPA の基本方針は図表 16 のとおりであり、強固で拡張性のあるシステムや、ISO20022 の採用等を目指している14。
【図表 16：NPA の基本方針】（出典：NPA ウェブサイト（コメントは事務局が追加））

また、NPA の主要なオーバーレイサービスとして、口座確認機能（CoP）や支払リク
エストがある（図表 17 参照）。NPA は、コアなシステム部分とこれらのオーバーレイサ
ービス全体を含めたアーキテクチャーの総称として呼ばれるようになっているものの、これらのオーバーレイサービスに係る取組みは、NPA の構築プロセスとは別途進められており、すでに現行システムをベースに一部開発が進められている。

Pay.UK ウェブサイト参照（https://www.wearepay.uk/programmes/new-payments-architecture-prog
ramme/）。
1414

【図表 17：NPA の全体像】（出典：NPA ウェブサイト（コメントは事務局が追加））

しかしながら、NPA の構築は必ずしも予定どおりに進んでいない。新型コロナウイルスの影響により、2020 年６月に調達プロセスが一時停止されたことに加え、移行リスク
高く、調達が複雑化することを理由に、FPS と Bacs の統合は見送られ、まず初めに FPSを更改し、その後 Bacs との統合について、その要否を含めて検討するとされた15。また、
NPA のベンダー選定プロセスに関して、リスク低減等の観点から、現行ベンダー（Vocalink）に絞って調達したいと申し入れた Pay.UK に対し、当局（PSR）は、Vocalinkに絞って調達を行うメリットが競争的な調達を行う場合のメリットを上回るかどうかが明確ではないとして、Pay.UK の申し入れを退けており、当局と民間において意見の相違が明らかとなっている16。
このように生みの苦しみを味わっている NPA であるが、昨年から今年にかけては、調達プロセスの再開を含めて徐々に進捗も見られている。以下では、最近の動きについて紹介する。
a. NPA に係る規制のフレームワーク
英国の決済システム規制当局（PSR）は、NPA に関わる規制についても強く関与して詳細については、全銀ネット調査レポート 2021（https://www.zengin-net.jp/company/pdf/report_202
1.pdf）参照。
16 同上。
15

15

おり、2020 年５月に実施した市中協議を踏まえ、2021 年 12 月には、NPA に係る規制のフレームワーク（ガバナンスやコスト負担等に関する規制の方針）を公表した17。本文書の中において、PSR は、Pay.UK と NPA CIS（NPA の主要なインフラ部分）を構築するシステムベンダーに対し、主に、以下図表 18 の内容を求めることとされている。
【図表 18：NPA に係る規制方針】（独占リスク）・ システムベンダーは、コストやサービスを改善する強いインセンティ
ブがないため、コストの高止まりや、サービスの品質低下のつながる恐れがある。
（水平的競争リスク）
対応すべき
リスク

・ システムベンダーが他の資金決済システムと関わりがある場合、当該システムに対して不平等な優位性を与えようとし、NPA の価値を害する可能性がある。
（垂直的競争リスク）
・ システムベンダーが他のオーバーレイサービスと関わりがある場合、当該オーバーレイサービスは、他のオーバーレイサービスよりも、不平等な優位性を持つ。


NPA CIS（NPA の主要なインフラ部分）の主要な窓口および意思決定機関となること。



NPA CIS の利用料を定めること。また、利用料は、PSR が認めた方針に沿ったかたちで決定すること。


Pay.UK

競争とイノベーションを促進するかたちで、NPA CIS に関するルールを定めること。



NPA CIS のベンダーが、NPA CIS に関連しない目的により、NPA に係る情報やデータを利用したり、他者（関連会社を含む）に開示したりしないようにすること。

規制方針


競争とイノベーションの促進のため、情報やデータを、適宜適切な方法で市場関係者が利用できるようにすること。



NPA CIS のベンダーが、他の決済システムやオーバーレイ
サービスに深い関わりがある場合、NPA CIS の部分につい

NPA CIS
ベンダーては、他のビジネスと切り離して運営すること。


NPA CIS のベンダーおよび関連会社が提供する、NPA CIS
以外のサービスが、NPA CIS の構築に対して不当に影響しないようにすること。
（PSR 市中協議をもとに事務局作成）

PSR 市中協議文書（https://www.psr.org.uk/media/yexfxxyn/psr-ps21-3-npa-regulatory-framework-p
olicy-statement-dec21.pdf）参照。
17

16

この方針からは、NPA が競争的に運営され、他のサービスを不当に制限しないようにしたい PSR の姿勢がうかがえる。また、利用料に関しては、上記のほか、①インフラに要したコストを効率的に反映すること、②NPA の参加促進に資するものとすること、③顧客へのサービスにおける競争を歪めないこと、④透明で予測可能なものにすること、⑤
市場環境の変化を踏まえたものにすること、といった詳細があわせて示されており、現在参加者が Vocalink に対して直接支払っている現行システム（FPS 等）のコストを、戦略的に Pay.UK に決定させたい意向が反映されている。
なお、概ね上表の内容と同じ方針が示された市中協議に対しては、28 の関係者からコメントが寄せられており、多くは PSR の方針に賛同するものであった。一方で、一部の機関からは、指摘されているリスクは理論的であり実際には起こりにくいことや、PSR の介入は特定されたリスクに応じたものにすべきこと、詳細なルールではなく実現したい
環境を設定すべきであること、といった意見も提示されている。
この方針にもとづき、PSR は、Pay.UK とともにベンダー選定を進めることとされている。
b. NPA の RFP
2022 年５月、Pay.UK は、NPA に係る RFP（Request for Proposal）を実施したところ、ベンダーから応募があったことを公表した18。詳細については明らかではないものの、David Pitt 最高経営責任者は本件に関し、「ベンダーからの回答を得ることは、NPA プロ
グラムにとって重要なマイルストーンであり、この 12 カ月に及ぶ我々のチームの労力のたまものである。応募があったベンダーとともに、英国の産業界の未来を創るために適切な技術的ソリューションを見つける新たなフェーズに入った。」とコメントしており、停滞していた調達プロセスが再び動き出したことがうかがえる。
ただし、前述のとおり、NPA において FPS と BACS の統合は見送られ、当初は FPSを更改するとされたことを踏まえると、今回の RFP は、FPS の更改に絞ったものと推察される。
なお、今後のスケジュールについては、図表 19 のとおりとされており、2024 年中の稼動開始・移行完了を目指し、対応が進められている。

Pay.UK ウェブサイト（https://newseventsinsights.wearepay.uk/media-centre/press-releases/pay-uk-moves-to-the-next-phase-of-delivery-for-the-new-payments-architecture-programme/）参照。
1817

【図表 19：NPA に係る今後のスケジュール】（出典：NPA ウェブサイト（コメントは事務局が追加））

c. オーバーレイサービス
前述のとおり、NPA のオーバーレイサービスとして位置づけられている受取人口座確
認と支払リクエストについては、すでに現行のシステムをベースに開発が進められている。
英国の受取人口座確認は Pay.UK によって標準ルールが策定されており、また、2019
年以降、大規模銀行６行は、当局（PSR）によって大口および小口のリアルタイムペイメ
ントシステム（CHAPS および FPS）における同機能の利用が義務化されている。
【図表 20：英国の CoP の機能イメージ】（出典：PSR ウェブサイト（コメントは事務局が追加））

PSR は、受取人口座確認を導入した金融機関に対する独自の分析を行っており、①受取人口座確認は振込に係る詐欺を減少させる効果があること、②受取人口座確認を実施している金融機関の口座の不正利用が減少していること、③受取人口座確認によって誤18

振込の件数が減少していること、を報告している19。また、この結果をもとに、PSR は、受取人口座確認の義務対象を２つのグループに分け、時期をずらして拡大することを提案する市中協議を 2022 年５月に開始した（図表 21 参照）20。
【図表 21：市中協議における受取人口座確認の対象】
義務化時期

対象等


振込に関する詐欺の防止の面で影響度が大き
い約 50 の金融機関等。

第１グループ2023 年６月



当該金融機関が対象となることにより、FPSの受取人口座確認のカバー率（取引量ベース）
は 92％から 99％に拡大。

第２グループ2024 年６月



その他全て（350 以上）の金融機関。
（PSR 市中協議をもとに事務局作成）【図表 22：受取人口座確認に係るこれまでの推移】（出典：PSR 市中協議（コメントは事務局が追加））

市中協議の結果次第ではあるものの、英国においては、受取人口座確認が全ての金融機関において必須となることが予想され、受取人口座確認が当たり前のように利用できる
わが国に近い状況に近づくものと考えられる。

PSR 市中協議（https://www.psr.org.uk/media/gc1bfva1/psr-cp22-2-requirements-for-further-particip
ation-in-cop_may-2022.pdf）参照。
20 同上。
1919

一方の支払リクエストについては、2020 年５月、Pay.UK によって、既存の資金決済システムを前提としたフレームワークが策定されている21。このフレームワークは、米国のような資金決済システムを通じて送受信する専用メッセージとは異なり、資金決済シ
ステムのオーバーレイサービスとして、支払リクエストを導入する場合のメッセージ標
準やルールを定めたものである。これに関し、前述の Fed のように Pay.UK は利用促進に努めており22、支払リクエストの利便性等を伝える専用のウェブサイトも開設されている（図表 23 参照）。
【図表 23：支払リクエスト専用ウェブサイト】（出典：Request to pay ウェブサイト）

Pay.UK ウェブサイト（https://www.wearepay.uk/what-we-do/overlay-services/request-to-pay/）参照。
22 Request to Pay ウェブサイト（https://www.requesttopay.co.uk/）参照。
2120

【図表 24：支払リクエストの概要】（出典：Pay.UK ウェブサイト（コメントは事務局が追加））

しかしながら、PSR パネル（PSR におかれた独立のアドバイザリー会議）が 2022 年４月に公表した、決済における課題等を整理したレポート23の中においては、上記フレー
ムワークが活用されていない旨（図表 25 参照）が指摘されており、銀行界による支払リ
クエストの推進は想定以上に難航しているようである。

PSR パネルレポート（https://www.psr.org.uk/media/x3tjjuj1/psr-panel-dpi-report-may22.pdf）参
照。
23

21

【図表 25：PSR パネルレポートの概要（支払リクエスト関連個所）】


Pay.UK のフレームワークの普及は遅く、フレームワークを利用してサービスを提供している銀行等はいない。

支払リクエストが普及するには、広範な銀行等を巻き込んでサービスを展開する必要があり、広範な銀行の利用なしには、企現状業も利用しない。一方、企業側の強いニーズがないことを背景に、銀行側もサービスの展開に消極的な姿勢を見せている。


なお、支払リクエストに関連したサービスが、Pay.UK のフレームワークに依存しないかたちで一部誕生している。


今後の方向性Pay.UK のフレームワークの利用を義務化することは１つの方法であるが、義務化することにより、市場における支払リクエ
ストの競争を制限するリスクは冒すべきではない。
（ウェブサイトをもとに事務局作成）

Pay.UK による積極的な利用促進活動にも関わらず、支払リクエストのフレームワーク
が普及していない様子からは、資金決済システムを活用した統一的な支払リクエストについて、真に顧客や企業が受け入れられるものになるのか、そもそもニーズがあるのか、不明確な状況と言える。ただし、Pay.UK のフレームワークは途に就いたばかりであり、
今後ユースケースを検討すべきとの声も一部あることから、米国の動向とあわせて、注意
深く見守っていくものの、一種の支払リクエストともいえる口座振替がすでに定着しているわが国においては、より慎重にニーズを見極める必要があると考える。
以上が NPA を取り巻く現在の動向であり、様々な課題はありながらも、FPS のリニューアルに向けて最終局面に入りつつある。PSR から示された方針をどのように Pay.UKが具体化し、競争とイノベーションを促進する NPA が創り上げられていくのか、今後の動向に注目したい。
③二国間連携の動向
諸外国における資金決済システムに係る動きとして、徐々に注目され始めているのが、二国間の決済システムの連携である。こうした連携は、G20 のクロスボーダー送金改善に向けたロードマップ等に沿うかたちで進められており、送金から着金までに数日要す
る現在の国際送金を改善し、より早く着金させることを目指している。
二国間の連携では、特にシンガポールの PayNow に関連した取組みと、米国の TCH と
欧州の EBA CLEARING の連携に係る取組みの、２つの動きが進捗を見せており、以下
では、これら２つの動きについて整理する。

22

a.シンガポール PayNow の二国間連携
二国間連携の中で、比較的早く取組みが見られていたのは、シンガポールの携帯電話番
号 送 金 の デ ー タ ベ ー ス で あ る PayNow と 、 タ イ に お け る 同 種 の サ ー ビ ス で あ る
PromptPay の連携である。
PayNow は、前述のリアルタイムペイメントシステム（FAST）にリンクさせたサービスであり、顧客は振込相手の携帯電話番号を入力することで、FAST を通じた送金ができる。2018 年にシンガポール金融管理局（MAS）とタイ中央銀行（BOT）の間で合意されて以降、双方の国の銀行の顧客に対して、携帯電話番号で送金ができるようにすることを目的として協議が進められ、2021 年４月、図表 26 のかたちで PayNow と PromptPayの接続が開始した24。
【図表 26：PayNow－PromptPay 連携の概要】（シンガポール）・ DBS Bank・ Oversea-Chinese Banking Corporation
・ United Overseas Bank
※PayNow に参加する 12 の銀行のうち３の銀行が参加。
参加銀行

（タイ）
・ Bangkok Bank・ Kasikornbank
・ Krung Thai Bank・ Siam Commercial Bank
※Prompt Pay に参加する 21 の銀行のうち４の銀行が参加。

送金上限
手数料

・ シンガポールとタイ間の送金上限金額は１日当たり 1,000 シンガポ
ールドルまたは 25,000 バーツ（≒85,000 円）。
・ 送金時に、銀行ごとに送金手数料および両替手数料を提示。
（ABS ウェブサイトをもとに事務局作成）

ABS ウェブサイト（https://www.abs.org.sg/docs/library/paynow-and-thailand-s-promptpay-complet
e-the-world-s-first-faster-payment-systems-linkagee2a5aa9f299c69658b7dff00006ed795.pdf）参照。
2423

【図表 27：シンガポールからタイに送金する場合のシステム上のイメージ】（出典：NETS（Network for Electronic Transfers）資料（コメントは事務局が追加））

PayNow と PromptPay の連携において、実際の銀行間の資金移動は、図表 28 のとおり、コルレス銀行を利用したかたちで行われている25。このため、FAST といった自国内の資金決済システム同士が直接接続しているわけではなく、国をまたぐ銀行間の資金移動には、リアルタイムペイメントシステムとは異なる仕組みが利用されているものと考えられる。すなわち、シンガポール国内において、携帯電話番号のデータベース（PayNow）とリアルタイムペイメントシステム（FAST）は連携して提供されているものの、国際送金においては、新たな仕組みが裏側で構築され、あくまでデータベース同士が連携しているものと言える。

NETS 資料（https://www.bancaditalia.it/media/agenda/convegni-2021/Cross-border_Lau.pdf?langu
age_id=1）参照。
2524

【図表 28：PayNow－PromptPay 連携における銀行間の取り決め】（出典：NETS 資料（コメントは事務局が追加））

なお、PayNow に関し、2021 年９月、MAS はマレーシアの携帯電話番号送金サービ
スである DuitNow や、前述のインドの UPI との連携に向けて協議することを発表しており、上記の枠組みを利用したシンガポールと他国との二国間連携が進んでいくことが展望される。
b. IXB プロジェクト
二国間連携に関して注目されているもう１つの大きな動きは、米国の資金決済システム運営体である TCH と汎欧州の資金決済システムの運営体である EBA CLEARING の連携である。
2021 年 10 月、TCH と EBA CLEARING は、Immediate Cross-Border Payments（IXB）と呼ばれるプロジェクトにおいて、SWIFT とともに国際送金のリアルタイムペ
イメント化を目的とした実証実験を、以下のとおり実施した26。

TCH ウェブサイト（https://www.theclearinghouse.org/payment-systems/articles/2021/10/10112021_cross-border-ixb）参照。
2625

【図表 29：IXB における実証実験の概要】
・ TCH、EBA CLEARING それぞれのリアルタイムペイメントシステ
ム（RTP および RT1）を活用し、米ドルとユーロを交換するかたち
概要で送金。
・ これにより、新たなネットワークへの接続なしに、あらゆる規模の金融機関が国際送金サービスを利用できる。
（以下 11 の銀行）

参加銀行

Bank of America、BBVA Group、Citi、Crédit Agricole、Deutsche Bank、
HSBC、ING、Intesa Sanpaolo Bank、J.P. Morgan、PNC Bank、
SOCIETE GENERALE（ウェブサイトをもとに事務局作成）

さらに、TCH と EBA CLEARING、SWIFT は、2022 年４月、この実証実験のスキームと、SWIFT Go（少額の迅速な国際送金を実現する SWIFT のサービス）を活用したパイロ
ットサービスを年内に 24 行で開始することを公表した27。RTP や RT1 といった国内の資金決済システムと、SWIFT Go をどのように組み合わせ、国際送金を実現しているのか具体像は明らかではないものの、一例として、SWIFT Go を利用していない銀行は、RTP や
RT1 を活用しつつ、SWIFT Go を利用している銀行を中継させ、国際送金を実現するスキームが考えられる。
参加銀行からは「我々の顧客は、より早い送金や、送金に伴う手数料の透明性を求めている。IXB はコラボレーションにより実現したサービスであり、顧客ニーズに応えている。」（Raouf Soussi Laghmich ペイメント戦略部長、BBVA）「我々は、顧客を第一に考え、ビジネスに対して、シンプルさ、スピード、セキュリティを提供している。今回の変革により、より早く、よりフリクションの少ない国際送金が実現でき、顧客に対して、より利便性の高い支払から受取までの決済環境を提供できる。」（Ulrike Guigui 副社長、Wells Fargo）とのコメントがなされていることからも、一定の顧客ニーズがあると考えられる。一方、ともに民間の銀行によって運営されている TCH および EBA CLEARING は、中央銀行による他の決済システム（米国の FedNow や欧州の TIPS）と競争関係にあり、これらの取組み
は、競争によるプレッシャーから生じている可能性もある。
なお、今後の予定として、2023 年にはフルサービスを開始すること、また、米ドルとユーロ以外の通貨への対応も視野に検討を進めることとされており、シンガポール同様、他国にも同様のスキームを拡大していこうとする姿勢が見受けられる。
以上が、二国間連携において見られる大きな２つの動きである。その詳細については一部
TCH ウェブサイト（https://www.theclearinghouse.org/payment-systems/articles/2022/04/ebacl_tch_
swift_cross_border_ixb_04-28-2022）参照。
27

26

明らかではないものの、国をまたぐ国際送金の実現に当たっては、二国間の資金決済システ
ムを直接接続しているのではなく、SWIFT 等の既存のシステムや制度等を利用しているのが実情と推測される。
国際送金については、二国間連携のほかにも、国際決済銀行（BIS）による Project Nexus（各国の資金決済システムを連携するプロジェクト）や、北欧における P27 といった、二国間に留まらない複数国のシステムをつなぐ取組みも見られているものの、二国間連携に比べて各国の調整が複雑となり、進捗が遅いことが指摘されている。また、英国のように、これらの取組みに対して大きく関与せず静観している国もあり、各国それぞれの事情を踏まえた対応が採られている。
今後、これらの動きがどのように収斂していくのか、引き続き、動向をフォローしたい。

27

２．新技術の検討
現行の第７次全銀システムの更改期限を５年後（2027 年）に控え、全銀ネットは、次世
代資金決済システムに関する検討タスクフォース（次世代 TF）やその下部に設置した次世代資金決済システム検討ワーキンググループ（次世代 WG）、関連する検討部会において、次期全銀システムの方針について検討を進めている。
現在、これらの検討においては、基盤技術のオープン化についても議論が行われている。
全銀システムが利用しているメインフレームの販売および保守の終了が提供ベンダーから公表されたこともあり、より汎用的なシステムであるオープンシステムを基盤技術として採用できないか検討しようとするものであり、次期全銀システムの構築に向けて避けられない論点の１つとなっている。これを踏まえ、本章第一節においては、今後のオープン化に係る検討の参考とするため、現状のメインフレームにおける課題や、オープン化に関する動向を整理している。
また、第４回の次世代 WG においては、システムベンダー５社（NTT データ、日本
IBM、日立製作所、BIPROGY および富士通）から、次期全銀システムの今後の方向性についてプレゼンテーションが行われた。それぞれのプレゼンテーション内容については、
次期全銀システムを検討するうえで有益な情報が多く、本章第二節においては、プレゼン
テーションにおいて示された提案について、参考として紹介している。

(1)オープン化の動向と課題①メインフレームとオープンシステム
メインフレームの定義は必ずしも一様ではないものの、特定のベンダーによって造られた特定の業務に特化した独自システムを指すことが多い。そして、特定の業務に特化されていることにより、障害が少なく業務を安定的に遂行しやすいこと、高い処理性能を実現できること、構築ベンダーによるサポートが充実していることといったメリットがあるとされている。このため、1960 年以降、銀行のシステムを含む多くのシステムに採用され、特に日本においては多くの企業がメインフレームを活用してきた。そして、1973 年に稼動開始
した全銀システムも、図表 30 のとおり、いわゆる周辺機能はオープンシステムにより提供されているものの、主要な業務機能であるテレ為替や担保管理に関する部分は、メインフレームにより構築されている。

28

【図表 30：現行システムの構成】（出典：次世代 WG 資料）

その一方で 1990 年代以降、これまでメインフレームが担ってきたシステムを、オープンシステムが代替するようになる。オープンシステムは、メインフレームに比べて汎用的であるために、開発技術者を獲得しやすく、低コストで運用できるメリットがある。当初
オープンシステムは、処理性能等の面でメインフレームを代替することは困難と考えられていたものの、IT 技術の進展に伴い性能が向上したことにより、オープンシステムを活用する企業が徐々に増えてきている。実際に、図表 31 のとおり、国内のメインフレーム市
場は、クラウドコンピューティングの進展等28もあり、出荷台数および出荷金額ともに減少している29。全銀システムのメインフレームを提供しているベンダーも、こうした市場動向を受けて撤退を判断したものと推察される。

クラウド技術の動向については、全銀ネット調査レポート 2020（https://www.zengin-net.jp/company/
pdf/report_2020.pdf）参照。
29 情報・産業システム部会（JEITA）「サーバ出荷実績」参照。
2829

【図表 31：国内メインフレーム市場の推移】（JETRA「サーバ出荷実績」より事務局作成）

メインフレーム市場規模の縮小は、製品価格上昇や保守体制縮小等のリスクを伴うこともあり、現在、メインフレームを利用している企業は、基盤技術の再検討が急務となっており、全銀システムも例外ではない。
また、全銀システムにおけるメインフレーム上のアプリケーションは主に COBOL というプログラム言語で構成されているところ、COBOL を扱える人材や今後 COBOL を習得したいという人材も減少傾向にある（図表 32・33 参照）。したがって、COBOL を前提としたシステムを維持することも、全銀システムの高コスト化や保守性の低下につながるおそれがある。
以上から、全銀システムを効率的で持続可能なシステムとするためにも、次期システム
において採用する基盤技術の見極めが重要となる。

30

【図表 32：COBOL を業務上使用したことのある人材】（IT 人材白書 2012 より事務局作成）【図表 33：IT 企業 IT 技術者が現在利用している／今後チャレンジしたい開発言語】（出典：IT 人材白書 2016）②オープン化の事例
COBOL 言語を利用したメインフレームからオープン化を実現した代表的な例として、
損害保険ジャパン社の「SOMPO-MIRAI」がある。
同社は、保険商品の契約や保険料の収納・精算、支払い、事故の管理など保険業務全般に関わる基幹システムについて、1980 年代にメインフレームで構築したシステムを利用し続けていた。しかしながら、「利用年数の経過とともに複雑化が進み、お客さまや代理店、社員から寄せられた声を反映した新商品・サービスの開発に時間を要する」30「改修を繰り返したために機能の重複やブラックボックス化が進み、保守性が次第に低下」31と30

損保ジャパン株式会社等「基幹システムの刷新（第１期）完了 ～オープン系技術を採用し、デジタル化対応への機動性を実現～ ～商品・サービスの品質向上やスピーディーな提供を実現～」https://www.so
mpo-japan.co.jp/-/media/SJNK/files/news/2021/20210601_2.pdf?la=ja-JP
31 日経クロステック「損保ジャパンが 8 年と 2000 億円を投じた基幹刷新の全容、DX の「崖」越える力に」https://xtech.nikkei.com/atcl/nxt/column/18/01725/071500005/

31

いった課題が生じていた。
これらの課題を克服するため、2021 年３月から新たに稼動させたシステムが SOMPOMIRAI であり、オープンシステムを利用しつつシンプルな構造に作り替えたとしている（図表 34・35 参照）。また、SOMPO-MIRAI は、「機動性・柔軟性・接続性」を重視した設計技術を取り込んで構築したことにより、他のデジタル技術（ブロックチェーン等）との連携を容易にし、ビジネスモデルの急激な変化にも対応した新しい保険商品やサービスなどの開発も検討できるようになったとされている。
【図表 34：旧システムと新システム】（出典：損保ジャパンリリース）【図表 35：SOMPO－MIRAI の特徴】

（出典：損保ジャパンウェブサイト）

このシステム改修プロジェクトは、「新しい損保会社をもう１つつくるのに匹敵するほど大きなプロジェクト」と言われており、損害保険ジャパンウェブサイトにおいても、
1,500 億円以上のコストと、70,000 人月を超える規模であったことが示されている（図表36 参照）。また、一部報道においては、「ピーク時にはシステム側だけで 2000 人超の技術者が参画し、構想の着手から稼働までは８年がかり」「国内屈指の巨大プロジェクト」と
32

されている32。
【図表 36：SOMPO-MIRAI の規模】

（出典：損害保険ジャパンウェブサイト）

このような大規模なプロジェクトを進める決断に至った背景について、同社は、「現行システムのことを熟知した人材がいなくなるタイミング、いわゆる『2025 年の崖』をどう乗り超えるか、という社会全体の問題に対する答えの一つが本プロジェクトの取り組み」
33としている。
「2025 年の崖」とは、経済産業省の「DX レポート」34において提示されたものであり、2025 年には、レガシーシステムを支えるエンジニアが退職したり、レガシーシステムが利用するアプリケーションのサポート期間が終了したりすることにより、レガシーシステムの運用が困難となり、大きな経済的損失につながるというものである（図表37 参照）。すなわち、「2025 年の崖」はメインフレームが持つ前述の課題そのものと考えられるところ、損害保険ジャパンは、将来的に大きなリスクが生じる前に、課題に対処したものであり、全銀システムの更改に向けて参考になる事例である。

日経クロステック「損保ジャパンが 8 年と 2000 億円を投じた基幹刷新の全容、DX の「崖」越える力に」https://xtech.nikkei.com/atcl/nxt/column/18/01725/071500005/
33 損保ジャパンウェブサイト（https://www.sompo-sys.com/recruit/future/project.html）参照。
34 経済産業省「DX レポート～IT システム「2025 年の崖」の克服と DX の本格的な展開～」https://www.meti.go.jp/shingikai/mono_info_service/digital_transformation/pdf/20180907_03.pdf
3233

【図表 37：2025 年の壁】

（出典：経済産業省「DX レポート」）③全銀システムのオープン化の検討に係る今後の対応
他方で、メインフレームからオープンシステムへの切り替えには少なからずリスクが伴う。実際にオープン化に伴って、不具合が生じたと考えられる事例も見られることから、特に全銀システムのようなミッション・クリティカルなシステムにおいては、仮にオープン化を図るのであれば、適切かつ慎重にリスクを管理していくことが必要である。
オープン化に当たっては、大きく分けて、①システム全体の効率化や柔軟性・拡張性を志向しアーキテクチャーを刷新する「リビルド」、②業務プログラムの品質を維持しながら基盤部分のみをオープン化する「リホスト」という２つの手法がある。また、全業務を一度に移行する「一括移行」のほか、リスク低減のため開発規模を一定以下に収める「段階移行」
も選択肢として考えうる（図表 38 参照）。限定的なオープン化や段階的な移行は、リスク低減の観点からは有効と考えられるものの、管理が複雑となることに加え、メインフレームがもつ課題が残存し続ける、といったデメリットもある（図表 39 参照）。このため、オープン化に向けては、メインフレーム維持のタイムリミットに加え、各種法のリスク・コスト等を総合的に評価したうえで、採るべきステップを決定する必要がある。特に現行アプリケーシ
ョンを刷新する「リビルド」を採用する場合には、オープン・アーキテクチャー上で全銀シ
ステムの機能が再現できるのか、性能要求を満たすことができるのか、必要な業務継続性は確保できるのか、といった基本的な観点について、事前に検証することが望ましく、当該事前検証が開発全体のリスク軽減にも大きく寄与すると考えられる。
34

全銀ネットの次世代 TF および次世代 WG には、現行のシステムベンダーに加えて、複数のシステムベンダーが参画している。引き続き、これらのベンダーにもご協力いただきながら予断を持たずに検討を重ね、あるべき姿、最適な手法を探っていく。
【図表 38：リホストとリビルド】
リホスト

リビルド

業務プログラム

現行踏襲

刷新

アーキテクチャー

現行踏襲

刷新

OS／ミドルウェア

刷新

刷新

ハードウェア

刷新

刷新

方式概要

メインフレーム上の既存業務プ

オープン基盤への移行と合わ

ログラムは変更せず、オープン

せ、新規言語で業務プログラム

基盤へ移行。

を再設計・製造。

業務プログラムの品質を維持しシステム全体の効率化や柔軟ながら、基盤部分のみオープン性・拡張性の獲得を志向し、ア化。

ーキテクチャーを刷新。

特徴【図表 39：段階移行と一括移行のリスク比較】
段階移行
開発リスク

移行リスク

一括移行

開発規模を一定以下に収めるこシステム全体を対象とするたとで、開発リスクの低減が可

め、段階移行に比べ開発リスク能。

が高くなる。

部分的に切り出し可能な範囲のメインフレームの維持リスクが見極めが必要。また、全業務の解消。

移行完了までメインフレームの維持リスクが残存。

35

(2)次期全銀システムに関するベンダープレゼンテーション
前述のとおり、本年度の次世代 WG においては、次期全銀システムの基本方針の取りまとめに向けて議論を行っており、第４回の次世代 WG においては、システムベンダー５社（NTT データ、日本 IBM、日立製作所、BIPROGY および富士通）から、次期全銀シス
テムの今後の方向性についてプレゼンテーションを実施してもらった。各ベンダーからの提案は、前節のオープン化に関するものや、今後の検討の進め方を含めて参考となるものが多く、本節においてはその内容の一部を紹介する。
なお、各ベンダーからの提案内容は、次世代 WG における検討の参考として提示されたものであり、仮に各ベンダーが次期全銀システムを受注した場合、それぞれの提案に沿ってシステムを構築するわけではない。
① ベンダープレゼンテーションの概要
各ベンダーからのプレゼンテーションの概要は下記のとおりである。
a. NTT データ
・ 次期全銀システムのグランドデザイン策定には、技術動向（メインフレーム・オープ
ン・クラウド、エンジニア）を踏まえた基盤技術の採用、利用者ごとの機能選択、機能増減（付加価値機能追加／不要機能削除）、インターフェース（RC／API、テレ為替／新ファイル転送）の柔軟性向上が求められている。ただし、全銀システムの変更は既存加盟銀行に与える影響も大きいことから、現時点における利用者ごとのニーズの違いも踏まえ、変更時における長期のロードマップ、メリットの明確化、安全性やコストに関する十分な考慮が必要。
・ 接続方法は、システム連携のデファクトとなっている API に向かう方向性と認識（図表 40 参照）。既存加盟銀行へ与える影響に鑑み、次期全銀システム時点では参加者ごとの状況に合わせて選択できるかたち（参加者内システム間連携の API 化に合わせた対応等）が望ましく、現行インターフェース（RC 使用、コア・モア等）の維持と APIの併存が必要。
・ 基盤技術は、全銀システムの持続性の観点、保守性・柔軟性・拡張性確保の観点から、次期全銀システムのタイミングでのオープン化が必要。
・ 業務要件／機能・非機能要求は、参加者・ニーズの多様化を踏まえた「インターフェースと業務機能の分離」や「機能分割・配置の最適化（疎結合化）」による柔軟性向上が必要。
・ 以上を踏まえた今後のロードマップのイメージは図表 41 のとおり。

36

【図表 40：API 活用の仮説】（出典：NTT データ資料）【図表 41：ロードマップ案】（出典：NTT データ資料）

b. 日本 IBM・ 金融機関の全体システムとして、２つのタイプ（機敏性重視と高可用性重視）のシス
テムを融合し、進化する多様なフロントチャネルのサービスにも対応可能なアーキテ
クチャーが求められる（図表 42 参照）なか、次期全銀システムとして、これまでのミッションクリティカルなビジネスサービスレイヤーに加え、アジャイルを可能とする
デジタルサービスレイヤーを中心に新しいテクノロジーを取り込むことを可能とした、ハイブリッドアーキテクチャーを提言（図表 43 参照）。
・ 接続方法は、デジタルサービスエリアを中心に API 連携を前提とした基盤構築を行
い、決済を中心とした API エコノミーを実現。
・ 基盤技術は、ミッションクリティカルエリアでは、安定稼動を維持しつつ、最新の開発手法、クラウドネイティブ技術を活用したモダナイゼーション（仮想 RC 接続、コ
ア・モア統合等）を段階的に実施。また、アジャイルエリアを中心とした付加価値サ37

ービスをドライバーに、API 接続へのシフト化を加速。
・ その他、データサービス／AI サービスを活用した付加価値の提供も重要。
【図表 42：次世代全銀アーキテクチャーに求められること】（出典：日本 IBM 資料）【図表 43：次世代アーキテクチャー案】（出典：日本 IBM 資料）

c. 日立製作所
・ 次期全銀システムのグランドデザインを検討するうえで、「業務機能と基盤をどう組み合わせて最適化を図るか」がポイント。こうしたなか、ミッションクリティカル領域、基幹システム領域、非基幹システム領域の３領域を定義したうえで、各領域に合う基盤を整理し、業務機能をマッピングするアプローチを提案（図表 44 参照）。
・ 次期全銀システムは将来像へ向けた過渡期と位置づけ、RC 接続から API 接続への段階的な移行を見据えた構成とすることが必要と考えられることから、接続方法については、次期全銀システムでは RC 接続を継続しつつ、API への移行を誘導。
38

・ 基盤技術は、ホストのオープン化、パブリッククラウド化への移行を見据えた構成とすべき。一方で、オープン化への一斉移行のリスクを軽減するため、次期全銀システ
ムでは、モアタイムシステムをオープン化し、段階的な移行を検討（図表 45）。
・ その他、新規追加機能については、オープン／パブリッククラウド化の利用を前提とし、外部連携によるサービス利用も視野に入れて検討。パブリッククラウド化は、柔軟なリソースの追加・削減やコスト低減等のメリットがある。
【図表 44：今後の検討ステップ】（出典：日立製作所資料）【図表 45：次期全銀システムの構成案】（出典：日立製作所資料）

39

d. BIPROGY・ 接続方法は、次期全銀システムでは新たな決済手段・チャネルへの迅速な対応を可能とする API 接続を実現。
・ 基盤技術は、安全性・可用性の継承が求められるミッションクリティカルエリアと、拡張性が求められるアジャイルエリアに応じたオープンなものを選定。そのなかで、アジャイルエリアについては、クラウド化も検討（全体像は図表 46 参照）。
・ その他、参加者にとって利用しやすい試験環境の構築が必要。
・ 実現に当たっての検討事項として、API で取り扱うメッセージ形式、全参加者 API 接
続時の処理性能、API ゲートウェイ／全銀センタ間、オンプレミス／クラウド間のメッセージ連携・データ連携方式および新ファイル転送業務の取扱いがある。
【図表 46：次期全銀システムの構成案】（出典： BIPROGY 資料）

e. 富士通・ 次期全銀システムにおいては、現状のメインフレームを中心としたシステム構成から、用途に応じた分散型システムへの変化が必要。こうしたなか、全ての機能が一枚岩的に絡み合っているモノリシックな構造から、業務単位、機能単位に分割された部
品・API 化への移行を目指すべき（図表 47 参照）。
・ 基盤技術は、ミッションクリティカルエリアは堅牢性確保の観点からオンプレミスをベースとし、アジャイルエリアは俊敏性・柔軟性・回復性の確保の観点からクラウド
ベースとする（図表 48 参照）。
・ 業務／機能配置の考え方として、オンプレミスでは、堅牢性確保が必須となる機能、
既存 OS やミドルウェアを使用する業務／機能および既存 COBOL 資産を流用する業
務／機能を配置し、クラウドでは、他システムとの連携（繋がりやすさ、広げやすさ）、更新頻度が高い業務／機能、日付や時間帯によって業務量の増減が発生する業務
40

／機能およびデータ管理／トランザクション管理が「互いに疎」となっている機能を配置することを検討。
【図表 47：次期全銀システムに求められる機能】（出典：富士通資料）【図表 48：次期全銀システムのプラットフォーム案】（出典：富士通資料）

②

提案の整理
各ベンダーから提案された次期全銀システムの接続方法および基盤技術、グランドデザ

インの内容を整理すると図表 49 のとおりとなる。接続方式についてはシステム連携のデファクトスタンダードである API に移行する方向性、基盤技術については各機能の特性を踏まえてオープン化あるいはクラウド化を目指すべきという方向性、グランドデザインについてはミッションクリティカルエリアとアジャイルエリアを分けて適正に機能を配置す
る方向性などが共通して示されている。

41

【図表 49：各ベンダーからの提案内容】

NTT データ

接続方法

基盤技術

・システム連携のデファ

・保守性・柔軟性・拡張性

クトは API。中長期的な確保の観点から次期全・機能分割・配置最適化

負担軽減を想定

銀システムのタイミン（疎結合化）による柔軟

・次期システムは、現行

グでオープン化を目指

性の実現

仕様との両立すべき・メインフレームの安定

日本 IBM・アジャイルゾーンを中稼動を前提としつつ、心とした付加価値サー

クラウドネイティブ技

ビスをドライバーに、術（コンテナ化等）も活

API 接続へのシフト化用したモダナイゼーシ

を加速すべきョンを段階的に実施すべき・次期システムは将来像へ向けた過渡期と位置
日立製作所

づけ、RC 接続を継続しつつ、API 接続への段階的な移行を見据えた構成とすべき・新たな決済手段・チャ
BIPROGY

ネルへの迅速な対応を可能とする API 接続化を実現すべき・モノリシックな構造か
富士通

ら部品・API 化（業務単
位・機能単位に分割）への移行を目指すべき・リスク軽減の観点からミッションクリティカ
ルエリアでは段階的にオープン化を目指しつ
つ、他のエリアではオー
プン化・パブリッククラ
ウド化を目指すべき・ミッションクリティカ
ルエリアと、アジャイ
ルエリアに応じたオー
プンな基盤を選定すべき

グランドデザイン・ミッションクリティカ
ルゾーンとアジャイル
ゾーンを分けて検討
・付加価値としてのデー
タ連携・利活用も重要な
観点

・各エリアが担う役割を定義し、それぞれのエリアで採用する基盤の特性を考慮のうえ、各エリ
アに業務/機能を配置す
るアプローチが必要

・新たな決済手段・チャ
ネルに迅速に対応するためのアジャイルエリ
アの実装
・利用しやすい試験環境の構築

・堅牢性確保の観点から・メインフレームを中心

ミッションクリティカとしたシステム構成か

ルエリアはオンプレ

ら用途に応じた分散型

を、柔軟性確保の観点システムへの移行

からアジャイルエリア

・プラットフォームの特はクラウド化を目指す

性にあわせた、業務/機べき能の配置を検討（各ベンダー資料より事務局作成）

42

次世代 WG および次世代 TF においては、これらの提案内容や前節におけるオープン化に係る留意点等を踏まえ、次期全銀システムについて検討を進めている。決済システムを取り巻く環境や技術は過去に例をみないほど変化・進歩が激しいことも踏まえ、次期全銀システム稼動時に実現を目指すべきもののほか、システム全体の柔軟性を確保したうえ
で、次期全銀システム稼動以降の対応を検討すべきものもあると考えられる。次期全銀シ
ステムの基本方針取りまとめに向けて、短期・中長期という時間軸も意識しつつ、引き続き関係者の協力を得ながら検討を深めていく。
以43上