骑士资本的高频交易事故

骑士资本是美国最大的经纪商和做市商之一， 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、业务人员要保持职业谨慎，疑点之处很可能就是风险点，不可忽视。

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

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

Q. E. D.