最后经过协商，买卖双方同意用现金来结算。清算的价格定在了每股91万日元——这是瑞穗证券敲下乌龙指前一刻的股票价格。这次现金交割又让瑞穗证券雪上加霜，损失扩大到400多亿。

至于当事人田中君，似乎并没有受到太严厉的惩罚。瑞穗证券至今也没有公布当事人的真实姓名，只知道是一名男性证券经纪人。事件发生时，正赶上日本公司要发年终奖。就因为田中君的一个错误操作，一下子把公司一整年的利润都给干掉了，让瑞穗证券所有员工的年终奖都泡了汤。有传闻，田中君成了瑞穗证券里“最讨厌的人排行榜”的No.1。

那些趁火打劫的机构大户也受到了指责。事后查明，共有22家机构在此次乌龙指事件中获利。其中瑞士银行，摩根斯坦利，日兴证券，雷曼兄弟，瑞士信贷，野村证券这六家机构，从这次事件中一共瓜分了168亿，占瑞穗证券损失的40%还多。

尽管这钱来的不太光彩，可毕竟是按照市场规则赚来的，所以金融监管部门只能从道德层面对这些公司进行谴责而已。有人提议，让这些公司把赚到的钱吐出来。这些公司表示：这样做，等于把公司的利润白白送给别人，没法向自己的股东交代啊。

后来在各方的调节下，一部分获利的证券公司同意把钱拿出来，成立一个保护投资者利益的基金，这是后话了。

在这次事件中，东证交易所受到了最多的质疑。首先瑞穗证券在意识到错误挂单后，曾经多次发出取消的指令，但都被交易所的系统所拒绝，这显然不符合系统的交易规则。其次，在瑞穗证券与东证负责人取得了联系的情况下，东证方面仍然放任这笔卖单继续执行，有监管不力之嫌。事后，东证社长鶴島琢夫引咎辞职。

瑞穗证券方面认为，正是由于东证的过错，才让自己蒙受了400亿日元的损失。这个错误理应由东证来买单。东证的观点是：你自己乌龙指敲错了指令，凭啥赖在我身上？对此，瑞穗证券回击：取消交易指令发出之前的那段时间，产生的损失自己认了。但是还没成交的卖单为啥不让人家撤销？

两个公司之间扯来扯去，也没把这个问题谈拢。于是，2006年9月，瑞穗一纸诉状，把东证以及交易系统的开发商——富士通告上法庭。就这样，漫长的诉讼开始了。

（三）法庭诉讼

对于这个案件，事实已经很清楚了：由于交易所的系统bug，在特定的条件下，会发生不能撤单的现象。经过详查得知，这个bug是富士通的技术人员在2000年某次程序修改时，不小心埋进去的。

本来，程序修改后必须经过严格的回归测试，来验证对其他业务流程有没有影响。可是不仅富士通忽略了这个测试，东京证券交易所在系统验收测试(UAT)的时候，也疏忽了这方面的内容。结果，炸弹在这个时间点被引爆了。（下图是包含了bug的cobol代码）

围绕着这个事实，第一个争论点是：东证和富士通，应该为瑞穗证券的损失负责吗？

起初，东证还想耍赖，把错误全部推在富士通身上。东证主张：就算是交易系统的bug导致了瑞穗证券的损失，那也是富士通的错。因为我的系统需求里面，是明确规定了可以撤单的。富士通开发的程序没有符合我的需求，才导致了这样的结果。

对于东证的这个主张，东京地方法院判定：这个系统的主要责任人是东证。富士通只是东证的系统供应商，属于连带责任人。无论是主要责任人还是连带责任人，如果被证明犯有重大过失，都应该做出赔偿。

那么，程序的bug算是“重大过失”吗？这很难说。一个系统里有没有隐藏的bug，是没法从理论上证明的。就算是测试再彻底，也会有测不到的bug流出来。所以在法律上，通常不会把所有因为bug导致的损失都归罪给程序开发商。否则的话，世界上最大的bug生产商——微软，早就赔得连内裤都不剩了。

这就带出了本案第二个争论焦点：什么样的bug才算是“重大过失”？法院给出了判断的标准——这个bug是不是很容易被发现。

于是，控辩双方都找来了由资深程序猿和攻城狮组成的砖家组，在法庭上撕成一团。

穗瑞砖家组：卧槽，这个bug简直太明显了好么？连这个都测不粗来，请问贵司人员的编程，都是音乐老师教的吗？

富士通砖家组：異議あり！这么复杂的条件组合，你特么能一下子就找出bug来啊！你们败吹牛逼了行不行！

双方的砖家团吵来吵去，谁也说服不了谁，干脆，在法官面前开始review起程序代码来了。

而此刻的法官，表情是很镇静的......