大システム障害が起こった経緯
第一に、当日臨時に行われていた定期性預金の集中処理で取り引きのINDEXファイル（取り消しや障害等に備え、取り引きを実施順にナンバリングするデータベース）がオーバーフローして、それ以降の定期性預金がすべてエラーとなる事態が起きた。この時点では定期性預金コンポーネント（システムの定期性預金部分）の障害だった。
第二に、当日は日曜日で、営業店窓口での定期性預金取引はできないが、銀行ATMやダイレクト（顧客がインターネットバンキングで直接アクセスする取引形態）からは定期性預金の取り引きを受け付けるべきところ、取り引きのINDEXファイルがオーバーフローした結果、銀行ATMやダイレクトからの定期性預金取引がすべてエラーになった。
第三に、そのようなエラーが累積し、取引メイン（どの商品サービスを、どのような順番で処理していくかを制御するシステムの司令塔）と呼ばれるシステム（MINORI）の中枢部で防衛機能が作動し、ATMやダイレクト取引を司る処理区画でシステムのダウンが順次起きた。この段階で、銀行システムの中枢部の障害に発展した。なお、処理区画はATMが60区画、ダイレクトが39区画に分かれており、システムが区画を割り当てていた。
第四に、システムのダウンが発生した区画でATMの取り引きが発生した場合、ATMの防衛機能により、定期性預金取引に限らず、通帳やキャッシュカードの取り込みが発生した。また同様にシステムのダウンが生じた区画にダイレクト取引が発生すると、ダイレクト取引でも取り引きがエラーとなった。この段階で、自行ATMチャネルやダイレクトチャネルの障害にまで発展した。取引メインで、全面的なダウンを避けるためにダウンを局所化させる設計だったが、顧客が区画を選択できるわけではないため、ATM側では、むしろ混乱を招く結果となった。
