CTP接口无疑是高频交易最早的试验田，在众多的交易接口中，无论是期货市场的CTP量化交易接口，还是现货和期权市场的类CTP系统，如华鑫的奇点API和中泰的XTP，都有一套非常类似的报单回调规则，相比于迅投QMT、恒生PTrade或掘金量化，由于包含了相当多的交易细节，要复杂很多，非常容易出错。而很多市面上的三方系统由于对CTP的内部细节进行了封装与预处理，所以在上层二次开发就会比使用CTP原生的接口进行高频交易开发容易的多。不过对CTP处理的细节和委托规则，交易所规则越熟悉，就越能在系统层面对高频系统有更加精细的订单控制。
OnRtnOrder（）
-
交易系统返回的报单状态，每次报单状态发生变化时被调用。一次报单过程中会被调用数次：交易系统将报单向交易所提交时，交易所撤销或接受该报单时，该报单成交时。
-
新增处理方式：报单在交易所端校验失败，被交易所拒绝后，CTP 系统同样通过此接口返回报错信息；其中的 OrderStatusMsg 字段包含报错信息。
OnRtnTrade（）
-
如果该报单由交易所进行了撮合成交，交易所再次返回该报单的状态（已成交）。并通过此函数返回该笔成交。
-
报单成交之后，一个报单回报（OnRtnOrder）和一个成交回报（OnRtnTrade）会被发送到客户端，报单回报中报单的状态为"已成交"。但是仍然建议客户端将成交回报作为报单成交的标志，因为 CTP 的交易核心在收到 OnRtnTrade 之后才会更新该报单的状态。如果客户端通过报单回报来判断报单成交与否并立即平仓， 有极小的概率会出现在平仓指令到达 CTP 交易核心时该报单的状态仍未更新，就会导致无法平仓。
在此次的高频订单中，不仅委托的合约比较特殊，回报也相对特殊。
一，如果使用OnRtnOrder()能保证委托和成交有精细的控制，但是无法确定OnRtnTrade()提前返回，也就是说无法保证在OnRtnOrder成交状态更新时，无法保证有真实的成交订单，而此时去在对向委托平仓单，就会出现委托失败-平仓量超过开仓量，如果使用OnOrder()去控制订单行为，就必须在OnRtnTrade()更新完全局的订单列表状态之后再去处理。在这里，回报是在同一个线程里，但是如果是两个线程，就涉及到线程同步的机制，需要使用轮询，信号/量机制来同步多个线程之间的执行流程。
二，如果使用OnRtnTrade()来控制订单的委托。能保证所有订单的成交都是真实的成交状态，但是仍然存在一个问题，就是OnRtnOrder()的OnRtnTrade()的时序返回先后无法保证，而OnRtnTrade()在控制订单的过程中，由于使用了委托状态中的委托价格，所以就必须通过OrderID去匹配，这个时候也是必须强制等待OnRtnOrder()的匹配订单的OrderID的返回，再去进行委托单的控制。
无论是上述哪种情况，其实都会涉及到策略业务逻辑和真实技术业务逻辑场景的匹配问题，这个时候就需要详细验证真实业务逻辑的可能存在的场景，使用更加合理的方案来处理和匹配策略业务逻辑。
使用程序化交易时需要时刻关注报单状态，无论是期货还是股票、可转债，大量撤单会造成天价的期货信息费或股票流量费，期货在前几年的委托申报中还新增了关于委撤比的费用通告，对成交率有更加严格的限制和管控，这点在系统设计上要更加注意，避免超过频次的报撤而采用更加灵活的设计，比如采用补单而非撤单重挂机制。
该套利交易系统将助力团队进行套利策略的规模化运行提供技术支持和平台保障，系统的上线将使得团队CTA投资组合和套利策略能同时并行，有效加大资金利用率，并有效降低整体管理资金的回撤，增加投资组合的夏普率，为团队自营以及客户资产管理创造更稳健的回报。
同时，团队将继续增加研发投入，为自营投研资产管理以及与客户合作的金融策略交易定制化系统提供全面支持；
常清谷量化科技是一家专注于量化交易系统开发和资产管理业务的以科技驱动的量化交易公司，为客户创造价值 是我们永恒的使命！
