风控对于程序化交易业务的重要性不言而喻。本文将着重讨论在高频交易业务中常见的风险,并介绍一些常用的风险控制措施。

对于高频交易程序的开发团队而言,风控的起点是对任何将要投入使用的接口库进行充分的测试,尽可能保证自身用到的各种接口函数的调用和返回是符合预期的,不会发生意料之外的情况。任何接口库都有众多接口函数,其中的结构体和数据成员更是种类繁多,任何从事高频交易业务的团队在接触到一个新的接口库或是库版本升级时,如果接口提供商提供了文档,就应当详细阅读API文档并对接口本身进行充分的功能测试,保证开发者完全理解接口的调用和返回逻辑,在开发过程中需要严格依据这些逻辑进行细节上的控制。

真格量化委托对象的属性的不同数据类型

mark

以CTP API为例,CTP的期货行情库中,如果某个合约上没有买单或者没有卖单,则推送的行情中买一价或是卖一价是一个未初始化的极大数,这种情形下直接用价格数值本身来更新交易信号是存在风险的,但通过价格数值本身并不能简单地识别出这种情形,正确的做法是在任何行情到来时,首先检查买一量和卖一量,只有两者都是正整数时,该行情提供的买一价和卖一价才是有效的,否则该行情提供的价格数值应该被认为无效,不能用于更新交易信号,此类不符合开发者正常认知的逻辑在任何接口库中因为涨跌停、网络问题等各种因素都会不可避免地存在,因此对接口进行测试是非常必要的。

在保证接口库的稳定性和对其逻辑的充分正确认知的基础上,高频交易风控的下一个层次是保证自身的逻辑能够应对瞬息万变的市场上发生的各种情况。我们认为,多数情况下,风控逻辑的完备是一个只能接近而不可能完全达到的目标,无论是交易策略的设计者还是交易程序的开发者,都不可能保证自己的设计策略和程序可以在任何市场条件下都是无懈可击的。但是在实践中有一些基本的原则,能够高效地控制住交易程序的行为,即使发生意料之外的市场状况,也能够让程序通过内部的风险控制措施最大限度地将风险降低到可以容忍的限度之内。


下边我们例举一些高频交易中的风控措施:

\1. 为交易程序的参数设置可接受的数值范围,并在程序初始化时对参数进行检查:这一机制通常被称作启动参数检查(例如在真格量化的OnMarketQuotationInitialEx行情初始化部分进行参数检查),由于任何交易程序都不可避免地需要由人类交易员手工输入或预先设定某些交易参数,而且对于某些复杂的策略而言,策略参数可能非常多(一个极端的例子是期权做市商策略,交易策略对于每个期权都需要设定数十个参数,而一个标的品种上需要交易的期权合约可能多大数百个),因此即使存在一些帮助交易员设定参数的自动化工具,需要手工输入或程序自动更改的参数个数仍然是很多的,在长期的交易中,即使非常谨慎的交易员也难免在填写参数时发生失误,而这样的失误对于交易程序来说很可能使致命的。因此为程序的启动参数设置特定的范围,并在上线之前进行严格的测试是防范此类操作风险的必不可少的前提。

mark


\2. 控制未成交的委托单数量:在程序化交易领域出现过的许多意外事件,有相当比例的案例都是由于委托单数量失控所导致的。设计不当的交易程序中某些考虑不够周全的逻辑可能会导致程序在短时间内由同样的逻辑触发大量的报单,而实际上在下一个委托单发出之前,上一个委托单并没有结束,这导致大量的同方向委托单同时不可控地暴露在外,一旦市场行情向不利方向变化,交易策略会瞬间出现计划之外的持仓和风险。因此在构建程序化交易系统时,一个基本原则就是必须控制暴露在外的待成交的委托单数量,交易程序内部需要在任何时刻准确地知道由程序报出的在外的未成交委托单个数不多于一个具体的数值。要实现这一点,在CTP中通常采取的一个办法是构建“委托单位置”这一结构,一个“委托单位置”对应一个可能暴露在外的委托单,在程序中设置固定个数的“委托单位置”,一旦程序调用了报单函数,则将一个空闲的“委托单位置”设置为被在外报单占据的状态,对应一个本地委托单编号(类 FTD 协议基本都会在委托回报中设计一个本地委托单编号字段,在 CTP 接口中该字段称为 OrderRef,由用户程序在报单时填写,所有的该委托单对应的回报中都会按照用户填写值原样返回一个相同的 OrderRef,让用户程序能够使用该字段找到对应的本地委托单,用户在一次连接中需要保证委托单的 OrderRef 按报单时序递增),如果没有空闲位置可用则不能报新委托单;委托单位置的释放必须等到交易程序通过报单回报确认该位置上的委托单已经处于结束状态(全部成交、已经撤销或因报单错误被柜台或交易所打回),否则不可释放该委托单位置进而允许新的委托单占据该位置,通过正确地应用这一结构,程序就可以保证在任何时刻,暴露在外的委托单数量不会超过自身预先设定的最大值。

在真格量化中可以通过定时查委托或监听委托状态回报来统计未成交的委托单数量,并根据一些标准,比如委托后未成交的时间来撤销不需要的委托单。

mark


\3. 实时计算盈亏,并为亏损设置阈值,在亏损超限时撤回所有委托单并停止报单:这一机制通常被称为“亏损限额开关”,设置此类风控逻辑的主要原因是,对于正常运行的高频交易策略而言,通常从统计上必须有正的期望收益,否则日内交易非常频繁,即使某种异常(例如参数设置错误)在每次交易中造成很小的亏损,如果效应持续一整天,造成的亏损也可能是可观的,而在一个高度自动化的交易环境中,交易员并不一定能高频率地顾及各个策略的盈亏,因此需要设定亏损限额以自动在亏损还较小时停止交易程序,防止此类异常造成更多的亏损(而实际上在高频交易系统的风控原则中,除了对亏损设定限额,还有许多种类似的超限停止报单逻辑,例如在期权做市系统中的“希腊值限额”等,这些原则存在的理由也是类似的)。

mark


\4. 设计应急风控机制:此处的应急风控机制与交易策略无关,是指在出现了意外的技术环境问题时用于应急处置的一些措施。高频交易系统除了交易策略本身比较复杂,作为交易通道的柜台系统,包括其软硬件设施的运维也有诸多可能出现问题的地方,在一些事实案例中,甚至交易所自身的系统也是可能发生问题的,因此对于一个完备的高频交易风控方案而言,仅仅考虑策略本身的风控措施是不够的,还需要考虑柜台系统(包括交易所系统)出现问题时如何应对风险。最常用的应急风控机制是灾备柜台,高频交易系统需要保证除正常运行连接的交易柜台之外,还有至少一套柜台系统能够接收交易策略发出的所有委托回报,如果用于正常交易的柜台出现软硬件问题导致与交易所断开连接(交易程序在探测到此种问题时应尝试撤销所有委托之后主动关闭),至少保证还有一套柜台(目前国内期货公司的主席位通常承担了这一角色)能够将交易程序暴露在外的委托单撤回,以尽可能降低暴露在外的风险(对于期权交易这类会同时有大量委托单暴露在外的交易系统而言,这种应急措施尤为必要)。

mark