构建程序化交易的“黑箱”之前，深刻理解其风险所在必不可缺

刀尖上的舞蹈

技术风险

简单来说，技术风险是指包括了交易策略的算法风险、技术平台、交易实现、软硬件、网络链路等所有因技术原因导致程序化交易的系统未能产生及完成正确的交易指令的风险。

在程序化高频交易中，技术风险的破坏力十分惊人，无论是1987年北美股灾中饱受诟病的程序化交易，还是2012年导致骑士资本最终破产的SMARS系统，抑或是新鲜出炉的8·16光大证券乌龙指事件、纳斯达克闪电崩盘事件，以及程序化交易过程中的技术风险都被业内外人士广为宣扬。

在我们熟知的案例中，除了少量明确的“肥手指”差错外，绝大多数被曝光的程序化交易事故最终都被归咎于系统故障。以骑士资本为例，2012年7月27日，一名负责更新骑士资本数据中心的人员在升级8台生产服务器上的高频交易SMARS时遗漏了其中的一台，导致了骑士资本在8月1日纽交所开市之后不到一个小时的交易时间里损失了4.6亿美元。之后，这家成立于1995年，市场交易份额曾经占据纽交所17.3%，占纳斯达克市场16.9%，日内交易总量曾占全美金融证券市场的10%，以稳健与专业而著称的证券大鳄陷入经营危机，五个月之后便被GETCO公司兼并。

技术风险的杀伤力是如此惊人，以至于市场惊呼程序化交易为“IT魔鬼”。然而，事实上技术风险是诸多此类事件的表征，真正将盒子中的“魔鬼”唤醒的正是程序化交易的实施者。

膨胀的自我

程序化交易的本质是一种投资的模式，它对策略思想与交易技术的依赖是同等的，能够更快速地完成交易以及更全面实时地进行监控是投资者乐于采用程序化方式的主要原因。借助程序化交易的翅膀，许多人第一次感受到交易能力被倍数级放大的震撼，就好像飞机的诞生放飞了人们对天空的向往一样，计算机强大的数据计算与分析能力不仅让可同时监控与运行的模型数量限制变成理论上的无穷大，更能够打破学科之间的隔阂，衍生出众多新的盈利模式。

通过对大量的历史数据的回测，许多人惊奇地发现似乎市场中已经没有他们不能去的地方了，无非是改改参数，调优指标。面对着由历史数据回测得来的利润曲线，仿佛市场一下子变成ATM机，快速扩张似乎已不再是遥远的梦想。可惜，每个人心中都有一个魔鬼，不断地诱惑你做出不好的选择。越是曾经在程序化交易中尝到甜头的人，就越容易在收盈率曲线面前迷失自我。

先不论每一种量化交易的模型都有明显的规模上限，仅依靠模型就贸然涉足不熟悉的投资市场本身就是一件很要命的事情。由于程序化交易的历史回测陷阱与过度优化，在模型测试中信心爆棚最终实盘中铩羽而归的投资人不在少数。因为模型是固化的交易思路，而市场则是永恒变化的。风光无限的长期资本公司最终清盘告诉我们的不仅是黑天鹅，还有对市场的敬畏之心。

程序化交易的策略来自于设计者的交易理念和实现路径，是设计者交易经验的体现，因此设计者自我膨胀的风险才是各种交易系统中最大的风险。有人拿着交易账单得意忘形，有人为模型错过一波行情扼腕叹息，更有许多人打着创新引进的旗号行简单模仿之实，这些行为本身就与量化交易的客观、反情绪化格格不入，这样的程序化系统从起点就存在着瑕疵。此外，还有一些程序化系统设计人员过于相信“黑箱”观点，须知黑与白是相对的，对于系统的终端使用者来说程序化交易是个黑箱，但对于设计开发人员而言它必须是个白箱，即便是一些模式识别的策略也必须有道可循，可复盘，可验证，否则真的只能一黑到底了。

总之，程序化交易系统的竞争本质仍将是人与人之间的竞争，程序化是交易实现的一种方式，主观交易过程中对人的要求将同样适用。

运维风险

在发展初期，即便是专业投资机构的程序化交易系统都往往由量化交易研究员直接编写，随着系统的复杂化，IT部门全面介入系统构建，从开发部署至日常运维都离不开多部门的合作。参与者数量大幅增加使系统的风险点分布在多个环节中，特别是大量自主开发的交易系统上线之后，有针对性的运维管理体系对交易风险的防范是举足轻重的。机构投资者的程序化交易不再是仅仅启动或关闭系统那么简单，可惜的是，许多从事程序化交易的投资人对此并不在意。

前文已经说过，骑士资本高频交易系统SMARS软件系统进行升级的疏忽被认定是错单交易的罪魁祸首，但真正发出错误指令是其中一个叫PowerPeg的模块，这是一个用于分发订单一个本该在2003年就被弃用的模块。而不幸的是在2003年以及2005年的两次升级中，这个模块都没有按操作规范被及时删除，恰恰2012年的这次系统升级中有一个变量的运行标志位与PowerPeg一致，当SMARS启动之后被激活的不是新升级的RLP模块，而是那个已经沉睡了近十年的PowerPeg。如果数年前的开发人员严格按照操作流程进行升级，如果2012年的系统管理人员对SMARS升级工作进行二次验证，如果有其他技术人员被授权检查升级情况，覆没骑士的潘多拉盒子就不会被打开。

很多从事量化交易的投资人过于相信自己的经验和细心程度，对在系统构建初期就将运维体系建设全面考量进去并不认同，认为只要抓住投资模型本身的盈利能力，其他事项都可以放在一边，这从根本上就违背了程序化交易的系统性原则，他们对建立并执行代码开发规范、模型命名与通信规范、日常运维规范嗤之以鼻，甚至在产生错单之后也仅认为是一时疏忽，无需小题大做，殊不知当黑天鹅降临的时候，市场是没有义务为失败者提供重生机会的。

再看一个例子，8·16光大证券乌龙指事件中，程序化交易系统在2013年8月16日11时05分08秒之后的2秒内，瞬间重复生成26082笔预期外的市价委托订单，并且直接发送至交易所，累计申报买入234亿元，实际成交72.7亿元。从事后公开的资料可知，光大证券自营部门的交易指令有开盘限额、止损限额等多种风控措施，交易资金实盘限额2亿元，当日操作限额8000万元等一系列风控要求，而这些环节似乎都失效，甚至公司的监控系统对234亿的巨额头寸没有来得及做出反应。

8·16光大证券乌龙指事件之后，很多机构都暗暗吸取了教训，严格限制市价指令的使用，谨慎启用事后风控的机制，但如果不建立完善的运维保障体系，即便不栽在市价指令上，也很可能在别的环节出问题。特别是由于信息技术的飞速发展，程序化交易运维需要解决的难题只会更多，比如FPGA技术的应用，将软件写入硬件以提高运算速度，这就要求运维系统对交易的监控能力要高于生产系统。

要像对待交易策略一样来理解系统交易的风险，谨记：小心驶得万年船。