10～12日に発生した銀行間送金システム「全国銀行データ通信システム（全銀システム）」の障害について、運営する全国銀行資金決済ネットワーク（全銀ネット）は18日に記者会見を実施。同システムと各金融機関のシステムを接続するリレーコンピュータ（RC）で不具合が生じた原因について、内国為替制度運営費（旧銀行間手数料）を計算する際に参照する金融機関名テーブルである「インデックステーブル」が破損していたためだと説明したが、なぜテーブルが破損したのかなど、根本的な原因は不明だとした。現在も銀行間手数料の入力欄に一律0円を入力するという暫定対応のまま運用されており、会見を受けSNS上では「逆に謎深まる」「説明を聞けば聞くほど不穏な空気が漂ってきた」という声とともに、その原因をめぐりさまざまな考察が飛び交う事態となっている。
10金融機関で計506万件の他行宛て振込処理などに影響が出た今回の障害は、RCの更改作業に起因する。全銀ネットの説明によれば、これまで各金融機関側に設置されていた「RC17シリーズ」から、全銀センターに集約して運用する「RC23シリーズ」へ移行する作業を行い、9日までに行ったテストでは不具合は発生しなかったが、10日朝に通信が開始されるとRCで電文の送受信ができないという事象が発生したという。各銀行ごとにリレーコンピュータは2系統（東京の全銀システム接続分と大阪の同システム接続分）あり、障害時に備えて相互に補完し合う設計になっていたものの、ハード面ではなくソフト面の不具合だったため、両方で不具合が発生した。
原因は前述のとおり「インデックステーブル」の破損だ。銀行が顧客から振込などの依頼を受け、振込先の銀行に支払う手数料の金額を入力する方法には、
・金融機関側で電文に金額を入力してRCに送信する
・RCが保有するテーブルを読み込んでRCが電文に金額を入力する
という2つがあり、後者を採用する金融機関で障害が起きた。テーブルはRC内のディスクで構築され、それを同じRC内の主記憶にコピーして展開しているが、今回はディスク内へのテーブル展開処理自体は正常終了していたものの、そのディスク内のテーブルが破損しており、そのまま主記憶にコピーされてしまったという。
ただ、インデックステーブルの読み込みだけが障害の原因かは現段階では不明であり、一部で原因として報じられているメモリ不足についても因果関係は不明だという。また、障害発生を受けてコンピュータを更新前の状態に戻すフォールバックを実施しなかったことに疑問が出ている点については、全銀ネットは会見で「実行しようとすると全金融機関の処理を終了する必要があり、時間も掛かる。今回の状況では取れない選択肢だった」と説明している。
サンプリングして行っていたためテストケースが漏れた？
以上のとおり会見では明確な原因がいまだに特定されていないことが明らかになったわけだが、SNS上ではその障害の原因をめぐりさまざまな考察が飛び交ってる。
＜おおよそ、メモリー不足とはかけ離れた内容＞（原文ママ、以下同）
＜メモリ破壊云々の件、用意していたテーブルのデータ長が誤っており、ロードした際にRCのテーブルを破壊して、結果的にRCのテーブルが破壊され不正となった、のかと想像した。環境構築時に作成したデータが間違いだけでRCの機能が立ち行かなくなるほどのエラーにはならない気がする＞
＜もし「電文長エラー」なら最有力は「桁あふれ」じゃないかな。単純に設定した金額が大きかった、Javaのコンパイルバージョンが変わって暗黙変換の仕様が変わって悪さをしたとか＞
＜インデックステーブル作成段階で壊れてたとなると、不正なデータの処理に問題がありテストが漏れたんでしょうか＞
＜当該ベンダーの某ミドルウェアのバグなんじゃないかという話が某所であって、だとすると原因特定が難航しているのも頷ける＞
＜ISAMを使ったアプリ側で排他処理にバグがあって同時書込みするとindexが壊れる事があります。これかもしれません。ただし、書き込みは成功してるようなので見当違いかもしれません＞
＜電文を処理が参照テーブルってインメモリデータベース（だと思うけど）そこのコピー元のマスタテーブルに問題があった 全パターンの電文を網羅出来ればバグは防げただろうがサンプリングして行っていたためテストケースが漏れた＞
