揭开 | 骑士资本高频交易事故的秘密

来源：阅微堂

骑士资本是美国最大的经纪商和做市商之一，2011年它处理了超过10%的美国上市股票交易量，在纽交所和纳斯达克交易所零售股票交易业务中排名第一。

2012年8月1日一次致命的交易系统故障中它损失4.4亿美元，接近破产边缘，最终被Getco LLC收购。2013年，美国证监会对其处以1200万美元罚金。

1.事情的经过

主要摘自美国证监会对于该事件的调查报告。

客户的一个交易单过来，Knight并不一定是直接把交易单直接扔到市场上去交易（尤其是这个交易单比较大的情况）。为了客户的利益，根据市场流动性情况和交易情况，经纪商可能需要帮助客户把交易单拆分成小交易单放到市场上去成交。

中国国内不存在这种做法，证券公司在客户交易时只提供一个通道。客户的交易请求通过证券公司的席位「原封不动」地到达交易所。

大型基金公司通常会专门配置独立的股票交易员，投资经理的投资指令由交易员拆分成小交易单，再通过证券公司传递到交易所进行匹配成交。Knight在某些客户交易中承担了国内股票交易员的角色。

Knight使用一个叫做SMARS的系统用来做上面这件事情。调查报告中声称SMARS系统处理了美国上市股票超过1%的交易量。SMARS有一个叫做「Power Peg」的模块，在2003年被停用。但是这个模块从未被删除或者停用，而是一直处于待命状态，只要系统的某一个特殊的参数被设置为「YES」，该模块就会被调用用来交易。

SMARS在将大单拆分成小单分批报送交易所进行成交时，它必须维护一个数：这个大单目前还剩下多少股未处理或在途。每报送一个新小单时，都应该扣减未处理的股票股数。在2005年，Knight移除了Power Peg模块中的这个计数功能。

纽交所将在8月1号启动一个叫Retail Liquidity Program（简称RLP）的项目。（注：这个Retail Liquidity Program的介绍见这里。我没看明白它的作用。）

为配合RLP项目的启动，Knight也更新它的SMARS程序。

程序员完成了一个新的RLP模块，RLP项目客户的交易使用这个RLP模块来执行。这个模块被设计取代之前的「Power Peg」模块。取代后，之前那个特殊的参数被设置为「YES」，意思是使用RLP模块。

但不幸地是，从7月27日Knight开始在它的八台服务器上部署RLP代码时，其中七台机器顺利安装，操作人员失误忘记在第八台服务器上更新程序。8月1日，Knight接收到客户的交易单。前七台服务器一切正常，最后一台机器出现了悲剧。

为了启动RLP模块，前面提到的特殊的参数被设置为「YES」，但这台服务器上并没有RLP模块，只有「Power Peg」模块。「Power Peg」模块在被停用后的第10年被启动了。

前面提到Knight在2005年就删除了这个模块的股份计数功能，也就是说这个模块根本不明白客户的单子已经被报送过到了，从而周而复始地向交易所提交交易单，引发了市场的大幅波动。

其中有75只股票，Knight的交易量超过市场交易量的20%，并直接推高股票价格至少5%；其中37只股票，Knight的交易量超过市场交易量的一半，并直接推高股票价格至少50%。

事后统计显示：这台服务器共接收了212个客户交易单，但它在45分钟内向交易所报出了几百万个小交易单，其中超过400万交易被成交，涉及154只股票，总成交股数超过3.97亿股。停止交易后，Knight持有80只股票共35亿美元的净多头以及74只股票共31.5亿美元的净空头。当天总损失4.5亿美元。

2.风险管理

Knight在整个事件中犯下的错误：

Power Peg模块在停用时并没有从系统中删除，而是保留在系统里成为僵尸程序。

系统没有经过严格的单元测试。理论上而言，留在系统里的模块都应该经过自动测试，确保其安全性。Power Peg模块在其股份计数功能被去掉后理应被测试程序所发现。

操作人员未正常部署代码，属于重大操作风险事件。

业务人员的风险意识严重不足。SMARS系统在当天开盘时曾给97名人员群发了关于「BNET Rejects」的邮件，内容跟「Power Peg」模块相关，但没有任何一个人去关注这封邮件代表的含义。

Knight的风险管理完全是事后管理，缺乏事前控制。虽然Knight对公司的敞口设置了限额，但超过限额时交易系统无任何限制。Knight设置了一个账户，编号为33，该账户用来放置暂时无法与客户订单匹配的交易。

该账户有200万美元的限额，但对该账户的限额没有任何自动化的控制。8月1日，Knight重复报送的交易都累计到了33号账户，该账户很快就出现一个巨大的敞口，超出了限额。但系统并未因为该限额被突破而停止交易，从而导致错误越来越大。

Knight的风险管理工具是「PMON」，是一个事后的风险管理工具。这个工具只能够显示各个账户的持仓，它不会显示账户的限额，也不会提示敞口超限。当交易量较大时，该系统还会有延迟，产生错误的报告。

「PMON」严重依赖于人工实时的监控。当33号账户出现问题时，由于33号账户的敞口有多个来源，业务人员没有快速定位到敞口的来源，也没有意识到问题的严重性（由于交易量太高，「PMON」计算的敞口和损益有延迟和不准确），从而导致系统故障持续45分钟之久。

最后再总结下经验和教训：

1、代码审查很重要。

2、操作风险会造成严重后果，重要操作应有人复核。

3、必须要有前置的风险管理，直接控制住最重大的风险。

4、业务人员要保持职业谨慎，疑点之处很可能就是风险点，不可忽视。

3.资料

1、In the Matter of Knight Capital Americas LLC Respondent.，美国证监会关于Knight的调查报告。

2、高频交易事故解析与启示，作者为何昱。