商業銀行の信頼性は、自己資本の充実に尽きる
BIS自己資本比率規制を持ち出すまでもなく、巨額の預金をリスクのある融資によって利ざやを取る商業銀行は、他人資本である預金に対し必然的に融資リスクに見合う自己資本を充実させなければならない。一方で、銀行は多数の融資や預金の管理に巨大なコンピューターシステム(銀行基幹系システム)に依存し、それらの事故は自己資本が充実していたとしても、深刻な流動性危機をまねきかねない
日本では、2002年のUFJ銀行及びみずほ銀行のシステム事故を契機に注目されるようになったが、欧米では1980年代のいわゆるBank of Newyork事件を契機にシステムが関係するリスクに対して注目が集まるようになった。システムが関係するリスクは、単にシステム事故に止まらず、テロや災害(911事件における銀行本店への被災)に対するシステムのバックアップ体制や、銀行の破綻時における決済処理の問題など多岐にわたり、それらを定量化したリスクとして量ることはかなり難しいことのように思える。しかし、システムリスクは今日BIS自己資本比率規制の改定にあわせリスク要因に加味されるように、金融機関のリスク管理にシステムが与える影響度は確実に上昇している。そして、それは金融機関のみならず一般の事業会社のシステムにも重大な影響を与える、という点を忘れてはならない
今回取り上げるUFJ銀行のシステム事故は、本年の2月25日に発生したシステムトラブルである。本件は、決済事故というシステム上最悪の事故という点でなく、オンラインシステムが一時的にとはいえ(完全にではないが)全面的にダウンしたという点で極めて問題である。そう言った意味で、2002年のUFJ銀行･みずほ銀行のシステム事故以降では、2002年のみずほコーポレート銀行のグローバル･カストディシステムの事故、2003年の三井住友銀行の対外系システム事故以降では最悪の事故であると言える
■UFJ銀行の勘定系システム
銀行基幹系システムにおいて中核的な位置を占めるのが、勘定系システムである。勘定系システムは、預金･為替などの処理を行うアプリケーションシステムであると同時に、預金の取引データである預金原帳を格納するシステムであり、またATM網などの制御を行う制御システムという側面を持ち、さらに情報系システムなど他の基幹系システムと不可分な関係にある
長い間、銀行の基幹系システムは勘定系システムを中核とするスター型システムであったが、1990年代以降の都銀においては勘定系システムと直接他のシステムが接続される形ではなく、ハブシステムと呼ばれる統合システムを介するハブ･アンド･スポーク型システムが採用されるようになった。これは、勘定系のシステム変更が全てのシステムに影響を与える危険性を排除し、勘定系の間との接続インターフェースを規格化･簡略化する意味だ第一にあるが、究極には勘定系の担っていた業務をコンポートメント化･カプセル化し、個々のシステムを一種の分散オブジェクトのように扱うシステムを目指すものである
これに先立って、90年代半ばに稼動した住友銀行の第四次総合オンラインシステムでは、勘定系の中の個々に稼動していたシステムを1台の超大型メインフレームで動かすのではなく、一定数の店ごとに独立したシステムを割当て、ハブで統合する店群システムを採用している。2002年1月に統合したUFJ銀行は、旧三和銀行のシステムをベースにしながら店群システムとハブ･アンド･スポークシステムを採用しており、都銀の中では三井住友銀行と並んで最新のシステムである
■魔の2月25日
2月末は銀行にとって決済処理が特定日に集中しやすい。銀行の決済集中日は、いわゆる五･十日(ごうとうび)の他に給与振替が集中する月末25日以降には、各種料金などの決済集中が重なる。UFJ銀行は、三和銀行時代の高度経済成長期からリテール(個人営業)を強化し「ピープルズバンク」を標榜していた関係から、個人の膨大な決済業務を一手に引き受けており、UFJ誕生後にも三井住友銀行の公金決済業務を受託している
2月は、給与支払や決済が集中する25日以降の日数が4日間しかない。しかも、企業の地方法人税の納付のための資金移動が重なることや、今年は26日が土曜日、27日が日曜日と重なったために、資金決済が25日と28日に劇的に集中する。そのため、2月25日は五･十日、給与振込、地方税資金移動、個人の各種支払い、そして週末の資金決済集中と、決済業務が最悪な形で集中していた
25日朝8時30分、規定どおり全銀協が運用する資金決済メッセージングネットワークである全銀ネットがオンラインになり、UFJ銀行を含んだ各銀行は全銀ネットに大量の電文を送信しはじめた。各銀行とも普段よりも大量のデータを処理した上に、給料日に重なったために朝からインターネットバンキングやATMも混雑している状況だった。8時45分、各銀行のATMが営業時間内稼動を始め、全銀とATM、インターネットバンキング双方が9時30分ごろまで最も処理が集中する時間を迎える。そんな中、8時57分UFJ銀行の勘定系ホストの1台がダウンした
■内国為替決済制度
銀行間の為替決済は、主に決済電文を交換する全銀ネットと、実際の資金移動を行う日銀の当座預金決済システムである全銀ネットの二本立てになっている。前述した通り、全銀ネットは通常8時30分から稼動し、午後4時にオフラインになるが、銀行の標準営業時間である3時以降に受け付けた振込依頼は予約という形で一旦預り、次の営業日の朝に企業などが依頼する大量の振替決済処理と一緒にオンライン処理される
全銀ネットは、単に決済のための電文を交換するだけのネットワークである。例えば、A銀行からB銀行の口座に3万円を振り込む依頼を全銀ネット経由で送信すると、B銀行は指定口座に対して資金を入金するが、A銀行とB銀行の間での資金決済はまだ完了していない。銀行間の資金決済は、A銀行とB銀行の間の他の資金決済処理とまとめて日銀の当座振替で行われる。例えば、A銀行からB銀行に3万円の振込みと6万円の振込み、B銀行からA銀行の間で18万円の振り込み処理が発生したとすれば、A銀行からB銀行への支払いは9万円、B銀行からA銀行への支払いは18万円となるが、実際に日銀ネットではB銀行がA銀行に対して9万円の負けであるので、3つの全銀ネットでのトランザクションは、日銀ネットではB銀行からA銀行に9万円の支払い1回のトランザクションで終了する
問題は、こういった全銀ネットでの決済処理は無制限に行えるものではない点だ。全銀ネットでの電文処理と、日銀ネットでの当座尻決済の間にはタイムラグがあり、この間に金融機関が破綻すれば正常に資金を決済できなくなる決済事故に繋がる。そこで、確実に資金決済が行えるように決済処理では銀行が国債(それも主にFBなど現金に近い性質を持ったもの)で担保を積んで、その担保内で全銀に電文を流すという取り決めがある
UFJ銀行で2月25日朝に起こったのは、この担保の不足である。通常、全銀経由で発信された電文は、他行への振替(出)と他行からの振替(入り)の合計が、積んでいる担保の額を越えなければ良い。UFJ銀行の場合、この担保の額が8000億円だが、この日の朝は膨大な電文処理が追いつかず、出金が入金を超過した状態で担保不足が発生し、さらに入りの額が出金額と正しく相殺されないまま担保が不足する状態になった。全銀との接続は、対外系システムが担当しているが、出金バッチ処理は勘定系が担当しており、対外系システムから担保が不足している警告メッセージが大量に勘定系に送信された。メッセージは、勘定系の管理コンソールに表示されるが、この日は大量のメッセージがコンソールに表示されたために、ログが堆積し、ホストがダウンした
■待機系もダウン
ホストがダウンしたために、ホストはネットワークから切り離され自動的に待機系システムに切り替わった。待機系システムへの切替は、わずか20秒で完了し処理を続行したが、9時9分に別の店群勘定系ホストが、3分後には3台目のホストがダウンし、4つあるUFJ銀行の本番系勘定系ホストのうち正常に作動しているのは1台のみになった
待機系への切替は正常に行われたものの、ダウンの原因になった担保不足は解消されず、待機系システムに対しても大量のエラーメッセージが殺到している状況には変わりなかった。9時27分、待機系で稼動していた2台の店群勘定系ホストが本番系と同じ理由でダウンし、この2台が管理する支店の口座とATMが完全に停止した。正規系システムはダウン直後から再起動作業に入っていたが、起動作業が終了するのは9時45分までかかり、さらにハブを介して勘定系とATM網の間でATMを制御するシステムの再起動作業に時間がかかったために、待機系がダウンした2つの勘定系に制御されていたATMが復帰するのは10時40分までかかった
この間、非常措置として停止されていた全銀ネットの接続は、安全が確認された正午まで停止され、結局4時間あまりにわたってUFJ銀行の決済システムは完全に停止した。被害状況で見ると、ピーク時には3割の店舗の口座が影響を受け、ATMの半数が停止した勘定になる
コンソールにエラーメッセージが殺到したことによるホストダウンはUFJ銀行がはじめてではない。かつて、福岡銀行の勘定系ホストがストレージ障害で大量のエラーメッセージが殺到したのが原因でホストが完全ダウンした事例がある。エラーメッセージが大量に発生しても、ホストからコンソールが論理的に切り離されていればホストそのもののダウンには繋がらないし、エラー発生時に決済バッチ処理を自動的に停止または制御する仕組みがあれば防げた障害であると言える
#福岡銀行の事例は、勘定系のストレージ障害が要因であり、障害原因はIBM製のストレージ制御用のハードウェアに製造欠陥があったのが原因だった。IBM側は全面的に福岡銀行に対して謝罪し、賠償も行っている。この後に、福岡銀行の勘定系システムは広島銀行と共同システム化されたために、現在はこのシステムは使用されていない
結果的に多大な影響を与えたUFJ銀行の決済事故だが、事故原因の公表や顧客に対する説明といった、危機管理の点では評価できる。前述したみずほコーポレート銀行や三井住友銀行の決済事故時には、原因や対策に関して一切公式発表が行われいない