みずほ銀行は2011年5月20日、同行が3月に起こしたシステム障害に関する調査報告書を公開した。報告書は、夜間バッチ処理においてオペレーションミスが多重に発生したことや、システムの処理上限を1988年のシステム稼働以来見直さなかったこと、コンテンジェンシープラン（トラブル発生時の行動計画）に不備があったことなどが、長期の障害を招いたと指摘している。

　調査報告書は、弁護士などからなる第三者の「システム障害特別調査委員会」がまとめた。みずほ銀行では本調査を受けて、近日中にも再発防止策や経営体制の刷新などを発表する予定。

　同行のシステム障害は、3月14日に東日本大震災の義援金口座に大量振り込みがあったことをきっかけとして、24日まで続いた。大規模な為替処理の遅延が起きたほか、ATMや営業店の業務もたびたび停止した。遅延した為替処理は、仕向為替（顧客からの送金/振り込み依頼を他の銀行に対して実施すること）が合計120万件、被仕向為替（他の銀行からの送金/振り込み依頼を受けること）が合計101万件である。

　調査報告書では障害が発生した原因を、(1)システム機能の問題、(2)システムリスク管理の問題、(3)緊急時の社内体制の問題、(4)経営管理と監査の問題－－に分けて指摘している。

　(1)のシステム機能に関しては、義援金の大量振り込みによって夜間バッチが異常終了した問題と、夜間バッチが未完了のままオンラインを開始したことで全面復旧に時間がかかった問題の二つを取り上げている。

　今回の障害では、義援金の大量振り込みによって1口座当たりの処理上限がオーバーし、それによって夜間バッチ処理が異常終了した。トラブルが発生した口座は二つあり、それぞれ異なるシステム上の処理上限をオーバーした。

　また同行の勘定系システム「STEPS」は、日中のオンラインと夜間バッチを、それぞれ同じハードウエアで交互に行っている。今回の障害では、夜間バッチが未完了の状態でシステムの日付を強制的に切り替え、翌朝のオンラインを開始した。しかし強制的に日付を処理したことで、未完了の夜間バッチを手動で処理しなければならなくなり、全面復旧に時間がかかった。

　(2)のシステムリスク管理に関しては、普段からのシステムリスク点検に不備があった問題と、新しいサービスを導入する際のリスク評価に不備があった問題の二つを取り上げている。

　同行のSTEPSは、旧第一勧業銀行が1988年に稼働したものだが、処理上限はシステム稼働以来見直していなかった。また今回の障害の発端となった義援金口座の一つは、携帯電話を使用した送金サービスに関する口座だった。新しいサービスを導入する際に、データ量の処理上限に関するテストを漏らしていたことが、処理上限オーバーにつながった。

　(3)の社内体制に関しては、部署間で情報の共有が適切に行われていなかった問題や、コンテンジェンシープランで想定すべき事象が不足していた問題、復旧対応の手順書が実効性を伴っていなかった問題を挙げている。

　(4)の経営管理と監査に関しては、STEPSの仕組みを熟知した運用担当者が現場に不足していた問題や、STEPSに対するシステム監査が不十分だった問題、持株会社であるみずほフィナンシャルグループが、情報システム子会社であるみずほ情報総研に対する監査を全く行っていなかった問題などを挙げている。

[みずほ銀行システム障害特別調査委員会の調査報告書(PDF)]