東日本大震災から3日後の2011年3月14日。この日の午前に最初のトラブルは発生した。テレビ局が東日本大震災の義援金を番組などで呼びかけたところ、みずほ銀行東京中央支店のテレビ局の義援金口座（以下、口座a）に、振り込みが殺到した。
午前10時16分、振り込みによって生じた「取引明細」の件数が上限値を超え、口座aに対する「預金・取引内容照会」ができなくなった。取引明細は通帳の記帳に使う。
みずほ銀は口座aを、格納できる取引明細の上限値が小さい「個人・通帳口」として間違って設定していた（表-1）。
みずほ銀は口座の種類を二つの属性の組み合わせによって区別している。一つは「個人」か「法人」か。もう一つは、取引明細を通帳に記帳する「通帳口」か、記帳しない「リーフ口（ぐち）」かである。
これら二つの属性によって、格納できる取引明細の上限値が変わる。通常、義援金口座のような大量振り込みが予想される口座は、リーフ口として登録する。リーフ口の場合、取引明細が上限値を超えることはない。取引明細を保存しないからだ。
みずほ銀が口座aの開設手続きを実施したのは2005年9月のことである。この際、みずほ銀は口座aを「個人・リーフ口」にしていた。ところが2007年12月、テレビ局から「振り込み明細を通帳で把握したい」との要望を受け、「個人・通帳口」に変更した。
夜間バッチでも上限オーバー
午後3時以降に受け付けた振り込み依頼は、夜間バッチで入金処理する。午後10時7分、口座aの夜間バッチが異常終了した。
実は夜間バッチでも、一つの口座につき何件まで処理できるかを示す上限値の設定があった。口座aは、振り込み処理の前に明細を退避する準備処理で、この上限値をオーバーした。このとき、現場にいたシステム担当者は、このような上限値が勘定系システム「STEPS」に存在することを知らなかった（表-2）。
担当者は異常終了時のエラーメッセージなどから上限値の存在を突きとめ、上限値を拡大した。その後バッチ処理を再実行したが、また異常終了した。先の異常終了によって、一部の振り込みデータが欠落していた（表-3）からだ。
再実行には欠落データの復元が必要だ。結果的に、この復元に8時間を費やした（表-4）。復元作業の過程で、翌朝のオンライン起動に向けたタイムリミットの午前6時までに夜間バッチが完了しないのは確実になった。
みずほ銀のシステム担当役員である萩原忠幸常務執行役員は、15日午前3時30分頃になって初めて、IT・システム統括部から障害の報告を受けた。担当役員が障害発生を知るまで、最初のトラブルから17時間かかった（表-5）。
