目的
2023-10-10より11銀行(三菱 UFJ
銀行、りそな銀行、埼玉りそな銀行、関西みらい銀行、山口銀行、北九州銀行、三菱 UFJ
信託銀行、日本カストディ銀行、JP モルガン・チェース銀行、もみじ銀行、商工組合中央
金庫10)において、他行宛の振込取引ができない事象が発生した。
この資料は2023/10/11段階での情報をまとめたものとする
障害発生箇所
十月の三連休中に全銀システムと各銀行を結ぶ中継コンピューター(RC)についてRC17からRC23への切り替えを行った。
この切り替えはソフトウェアの更新だけでなく、ハードウェア、並びに接続先の銀行(14行)について対応が必要であった。
その後、14行中、11行でRC中の銀行間手数料を処理するプログラムで問題が発生して他行宛の振込取引ができない状況となった。
なお、問題の発生しない3行については銀行館手数料の計算を自行のシステムで行い銀交換手数料を0で送信していた。
原因
現時点で障害の発生した箇所はわかっているが、なぜ問題が発生したかを究明できていない。
なお、銀行間手数料についてはRC17の段階で存在した処理である。
銀行館手数料のプログラムについては、どのようなプログラミング言語で構築については不明。(後ほど回答があるはず COBOLかC)
暫定対策
10/10の時点で問題の発生箇所はわかっており、プログラム修正を行ったが不具合の回収をしたが、テストで失敗したため適用を見送った
10/11では銀行間手数料を0として送信し、付替電文で銀行間手数料を対応する
なぜ切り戻さないか?
全銀だけの問題でなく、RC23にバージョンアップした14行でも対応が必要であり、切り戻しのリスクが高いと判断してプログラム修正をしている。
冗長化が機能していない?
同じソフトウェアが入っているから二系あっても機能しない。
片方RC17のままにしたらどうかという質問が、記者からあったが、バージョン違いを混在させるのは構成が複雑になりすぎてリスクが余計高くなるから、その選択肢はかなり厳しいと思われる。
著者の疑問
- 原因がわからないということは類似不具合が別の箇所に存在している可能性がある。この点についてどう考えるか?
- 別の電文で対応するということは、想定より多くの電文を投げると理解する。この場合の通信量増加によるリスクは存在しないのか?
参考
全国銀行データ通信システムの不具合について(その4)
https://www.zengin-net.jp/announcement/pdf/announcement_20231011_2.pdf
【全銀ネット有識者会議】事務局説明資料
https://www.zengin-net.jp/zengin_net/pdf/230116_paper2.pdf)
次期全銀システム基本方針
https://www.zengin-net.jp/announcement/pdf/20230316_basicpolicy_8Z.pdf
全銀ネットが簡素化したパッチを適用へ、2日で500万件超の送金に影響
https://xtech.nikkei.com/atcl/nxt/news/18/16084/
【ノーカット】発生から30時間超 「全銀ネット」がシステム障害受け会見 復旧のめどは? 三菱UFJ銀行・りそな銀行などで他銀行あての振り込み取引に遅延(2023/10/11)ANN/テレ朝