アカウント名:
パスワード:
そういうわけで、UBSの事例はちょっと特殊すぎるのかも知れません
----- Team Slashdot Japan [tripod.co.jp]に参加しよう。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生の大半の問題はスルー力で解決する -- スルー力研究専門家
プログラムのバグ？ (スコア:1)
謝罪記事の方は運用面での手違いと書いてありますが本当はどっちだろう？
単純に毎日定期で動作するプログラムだとして
１０日（土日とか関係あるのか？）だったら処理するというプログラムであれば
今月の１０日は別段普段と変わらない単なる平日だしバグが起きる様な事は
無い様な気がする・・・
なので１０日（実
Re:プログラムのバグ？ (スコア:1, 興味深い)
このときは、売買内容を確認する画面が出たにもかかわらず、惰性的にOKOKと押していってしまったために意味をなさなかったそうです。
運用面の教育っていう話もありますが、システム全体で考えれば、人間がもっともいいかげんで曖昧でミスをおこしやすい、信頼性の低い部品ですの
Re:プログラムのバグ？ (スコア:2, 参考になる)
UBSウォーバーグ証券東京支店の一件 [ubswarburg.co.jp]でしたね
この日上場された電通株を、寄り付き直後に60万円で16株売却する注文を、16円で60万円で売却･･･というミスです
>フェイルセーフっていうか、フールプルーフっていうか、そういうところを徹底的に研究して設計しないとシステムの安全性は高くならないんではないかと
実は、この事件なんですが結構盲点でして･･･。
東証の取引システムには、取引値と異常にかけ離れた注文に対してはセーフシステムが用意されていますし、UBS側のシステムにも同じようなシステムがあったと言われています
ところが、電通株はこの日上場されたばかりの銘柄で、UBSが間違った注文を出した時点では、まだ初値が決まっておらず、異常値をそもそも検出できなかったそうです。
そういうわけで、UBSの事例はちょっと特殊すぎるのかも知れません
Re:プログラムのバグ？ (スコア:3, 参考になる)
失礼、61万円で16株の売り注文を、16円で61万株売却というミスでした。実際に約定した数は少なかったようですが
ちなみにアイワイバンク銀行のシステムは
勘定系アプリケーション 日立
勘定系ハードウェア 日立（メインフレーム）
ATM NEC
対外系 NRI
みたいです
Re:プログラムのバグ？ (スコア:1)
この場合、セーフシステムは働かなかったのでしょうか？それとも、ドイツ証券にはそのようなシステムが無かったのかな？
-----
Team Slashdot Japan [tripod.co.jp]に参加しよう。
Re:プログラムのバグ？ (スコア:3, 参考になる)
#日本でもNTT株のような単位株制度の無い株で、単位を間違えて注文を出したという話はよく聞きます。
大引け前の取引は、注文が最も殺到する時間帯の一つで、バックオフィスも修羅場のような状況でしょう。ちょうどこの時期、日本株全体に先行き不安が囁かれていた時期で、外資系だけでなく多くの証券会社が猛烈な空売りを仕掛けていた時期に符合しますので、ミストレードがおきないとも限らないかと。
とはいえ、証券市場にしろ、銀行にしろ、オペレーションリスクの問題はシステム的に片付けることが難しい問題なので、事故が発生したときの適切な情報開示といった危機管理が重要なのではないかと。
ハードウェアの故障でオンラインがダウンした福岡銀行の基幹系事故の場合、事故調査結果を外部に公開しただけでなく、預金者にも閲覧でいるようWebに掲載した事例などはすばらしい対応だと思います
#そういう意味で、ドイツ銀の事例や某肥満都銀の事例はかなりまずい例かと