期指仿真交易点差策略（自动）的技术可行性

假设期指实盘交易和仿真交易在价差上类似，是否可能做一个全自动的点差交易工具呢？经分析目前期指仿真交易有这样一些情况：
1）点差相当可观，虽然0.1是最小跳动单位，但买卖价差经常可以达到10个TICK（也就是1个大点）以上；
2）按照双边100元佣金计算不到4个TICK即可以跑出成本（做点差肯定可以砍一半以上）；
3）经对IF01今年头两天的交易数据分析，买卖点差的中间值为0.6，有20%的买卖盘口点差在1以上；
4）从交易流水看，55%的逐笔交易价差（绝对值）不等于0，其中间值为0.6；
5）从报价更新频率来看，买卖盘更新频率的中间值为0.954秒，有20%的盘口更新频率慢于2.4秒；
6）从交易频率来看，逐笔交易的频率中间值为1.3秒，有20%的交易间隔在3.4秒以上。
7）每天交易笔数为7000笔左右，报价次数为1万次左右，交易量双边5-10万手。
上面是现货月期指的仿真交易情况，远期的应该点差交易空间还大些。
再看看基础设施方面。
1）在期货公司增设席位上直连交易所报盘机有最快的速度和响应，但中金所的席位费用会不会把多数炒手排斥在这个线路之外还不得而知（其他交易所没有这个情况）；
2）通过期货公司互联网交易网关经柜台软件报盘是一般的交易下单手段（需要拥有金仕达或恒生的交易接口），这里的技术可行性讨论是以此为假设的；
3）以金仕达6（即超级版）为例，市价下单（网通对网通）的响应速度为0到1秒不等，包括下单请求、接单响应、申报交易所响应（推送消息）和成交回报（推送消息），平均的情况还没有充分统计，估计可能在50MS左右；
4）通过交易接口取行情比普通行情软件要快一点（至少人眼可识别）；
5）下单发送、委托状态和成交状态是自动交易的主要技术基础，请求响应（PULL）和主动推送（PUSH）是主要的技术实现手段；
6）金仕达/恒生都有成交回报推送消息，无须发请求，但有可能技术上还不能作到稳定，有时会发现委托交易没有及时自动更新状态（是通过推送技术实现的），需要（手工/程序）刷新一下；
7）金仕达/恒生的委托和成交查询请求可能没有（我不能肯定，希望有朋友指正）按委托单号的查询条件，只有按合约、日期、委托状态等分类查询条件，返回记录不是唯一的，这在交易后时段会返回大量的记录，点差交易基本上无法建立在请求技术的基础上；
8）交易策略计算与行情接收的时间按现有的软硬件条件可以忽略不计，也就是说只需要考虑从发送委托请求到获得成交回报和委托状态（无论采用请求还是推送技术）的占用时间；9）实现上需按双边交易考虑，并考虑到点差交易可能带来的交易频率的加快（点差交易提供了额外的流动性，肯定是上百分比了）。

具体策略先不谈，先请有程序/自动交易经验的朋友或者了解金仕达/恒生互联网协议的朋友谈谈技术上的可行性如何。

 

股指期货的模拟数据不作数.

行情的点差应当以实际的平均手续费为中心,不会是0.1的跳动.

另外股指期货根本不可能和点差交易相比,点差交易的特征是典型的现价交易,必须有成交回报,一般你的经纪商就是点差价格提供者,没有任何中间环节,对着报价打,能报入即成功,股指期货并不能提供这种形式的流动性.事实上交易所还会人为地增加不同层次行情的延时,以便主力能在日常行情盘整时,有足够的赢利.

国内的期货交易内部黑得很,交易所为什么不提供止损单,就是因为这些数据没法保密.
所以中长线单子一大就难保不被盯上.

另外,正常的场外交易者为了确保成交,都要多打几个点位(交易规则有利于这种做法),所以想利用盘口的点差来捕捉,成功的几率接近于零

 

开仓单预挂,那和正常交易差不多,要进行点位判研.

止损单进不了场,止赢平仓单可以预先进场,也是在诱导交易者犯错误.

另外若是平仓单优先成交,主力还是有方法处理

 

YZWYQ说的是策略可行性问题了。事实上对此我不知道答案，也正是因为是仿真交易，因此才想通过实践来求证。
这个市场上目前没有人（也就是YZWYQ说的经纪商）来做点差提供者（MARKET MAKER），我也就是想了解是否可行，即我先双向挂单，等其他交易者来点我的价。我的目标就是做可盈利的买卖价差。至少在国外电子期货交易上，这个吃点差策略是大有人在干的。
本来一个流动性好的市场，1个TICK就应该跑出手续费，还有可观的钱挣（如美国的期货大部分是12.5元1个TICK，扣除2元佣金就点差交易者可以有10.5元盈利），所以会有做市商的生存空间，而且市场基本上能够维持买卖价差大部分时候也在1个TICK上。但我们的期指设计是想交易所赚钱的，搞了一个1个TICK的交易所手续费，经纪商再加码后，就需要3个以上TICK才跑的了来回费用。如果国内期指交易也非常活跃，以至于市场自己就可以维持1个TICK的买卖价差，那么这种机制可以说就已经消灭了国内期指做市商的生存空间。
但是从观察上来看，沪深300价差很大（甚至比新加坡A50还大），或者说咱们的期指流动性还比较差，也许有空间。
另外，点差策略的有效性无法通过历史数据检验来证实（因为你是交易第一发起人），实践是唯一的求证手段。

 

已经发现的一些技术难点总结一下：
1）高频率的策略要求高可靠的基础设施。普通频率的策略执行中如果发生意外（无论是策略自身还是下单接口的BUG），至少还可以手工查询状态、撤单和平盘。高频率的系统会把各个环节的薄弱点在短时间内充分暴露，1个99%可靠度的系统在10分钟之内（每分钟平均有10笔新单、撤单和查询动作毫不希奇）发生故障几乎是必然的。高频系统追求的是薄利的累计，但手工保障的效率低下，不仅是令人生烦，而且可能在快市面前轻易吞噬前面辛苦得来的积累；
2）限价单带来的部分成交现实会将系统的处理负荷成倍增加，这是模拟交易和BACKTESTING 永远不会面对的一个问题。一个5手的单子放到场内，可能在2分钟之内就由于部分成交而拆成了5个需要分别处理的交易，例如可能需要分别生成5个平仓指令或撤单指令（改价时），所以要做好准备你的系统能力 X 基准下单数量的处理设计；
3）目前的网关机推送行情、委托状态、成交结果、撤单状态、交易所状态等消息，但不推送持仓、可平、可用资金等数据，需要发起查询或自己计算。但在高频率的交易策略中，不能保证每个时刻上述数据都是计算准确的（如有连续部分成交回报发生时），发起查询有一个时滞，不仅可能会影响策略的效率，也可能增加系统的负荷和出错几率；
4）目前的网关机只建立接收方（即期货公司方）的消息索引机制，没有配合提供发送方（交易员）的消息索引机制及两者间的对应关系。如果消息发送方能够确保得到消息接收方每一个响应，这到也不是问题。但在高频系统下，网关机往往会遗漏对一部分请求的响应，这样就需要发送方来猜测一些推送消息（如委托状态和成交结果）与自己哪一些请求是对应关系。这个问题具体地说就是委托单号在客户机和服务器间对应关系没有建立的问题；
5）期货行情变化很快，会增加大量的干扰信号，需要在系统中设置大量的过滤器。例如在期指仿真交易中，会发现有的1毫秒（不是1秒）中发生多达4次的报价变化，如果你的系统是基于报价事件算法的，就可能产生4笔改价（4笔新单+4笔撤单）信号，而1个毫秒内基本无法做到4笔改价（如果网关当时不太挤，可能完成1笔改价）；
6）单向实现的困难。现有的通讯协议不公开，不能获得完整的技术资料支持；网关服务器一些设计结构上的问题（如不能精确定点查询）；网关服务器的一些BUG（如可能没有考虑在一个TCP包内有多个请求消息时的分别处理，只处理了第一个消息）。

 

系统主要的压力在维护网络通信的可靠性上，而不在通信数据的处理上。前者如是否会丢包、是否会出现不可预测的掉线，因为高频系统对这些东西极其过敏。后者如可以同时处理的消息或证券数量。对于后者，我觉得在主流硬件平台上应付国内六个交易所的全部实时数据，C#毫无问题。我用的平台有人测试过，每秒的消息处理量在15-20万个之间。对于前者，由于C#不是底层工具，有些活不好做，也许无法做。例如，金士达服务器可能会忽略封在一个TCP包里的除第一个以后的其他消息，我就不知道怎样才能在一个TCP包里只封一个消息。

我说的压力是关键数据的处理可靠性，因为交易不能有意外。一个报价数据包丢了没关系，但一个成交回报包往往就意味着一系列事件触发的开始。故障恢复/例外处理这些东西及其实现效率是高频交易的IT技术核心。在程序运行的每个时刻，所有的交易/头寸状态都必须能够追踪和把握，不仅不允许有例外而且必须实现的有效率。所有的交易前端都有查询功能（所有的单子），但如果你的某个单子状态不清，而这个单子又在下午发生，那你就可能惨了。我用金士达自己提供的交易前端（原生C++程序）在非交易时间测试，仅仅600个单子，响应时间超过6秒钟。

高频交易可能有多少个消息要处理，可以简单估算如下：
假设20%高价差时机是做点差交易的目标，如果单边开仓，则市场上10%的最优报价由你发起。按照日均1万笔报价计，你发出的单子就是1千笔，按70%的成交率计算，你的成交数量就是700笔。市场的平均成交量约为6手，做点差交易针对对手为散单，所以可以假设自己的头寸限额小于这个数，例如为4手。这4手由于部分成交会拆开，假设平均拆为2手一单。则你的交易消息数据量为：
1）1000笔报价 X 2单， 每单报价相关的消息有：报价请求1个+报价响应1个+报单状态推送2个+撤单请求1个+撤单响应1个+撤单状态推送1个，合计14000个；
2）700笔成交 X 2单，每单成交相关的消息有：成交推送1个，合计1400个；
3）主动成交查询，由于存在成交状态消息推送遗漏的例外情况以及成交穿破限价却没有成交的情况（交易所规则），所以部分单子需要做主动查询，假设平均每50笔出现1次，则主动查询的次数为14 X 2次，虽然查询次数不多，但由于每一次查询返回的数据都是所有的成交，所以消息处理量是很大的，即（1个主动查询请求+平均每次350个返回消息）X 2 X 14，合计约10000个。
以上三项加起来约25000个消息，是不可以出错的！如果只有2个消息出错，你的系统可靠性就在99.99%以上了。但这2个出错就意味着你当天的交易会中断2次至少。

高频交易是电子期货交易的一大特点，在德国有人可以做到市场份额的30%以上，在韩国也有人能做到7%。没有什么不可能发生的，即使在中国。

 

要通过期货公司的网关和柜台，接入等级比期货公司低。直连交易所也许以后有期货公司愿意协助时能实现。

另外，技术解决不了/不好的问题实际上可以引入业务逻辑来处理。例如假如服务器返回一张单子与我方台子上任何一张未获得响应的单子都不能实现自动匹配，那我就可以把这张单子作为一个错单来处理：未成交的就撤消，已成交的就市价平盘。这种错单处理机制是现实世界中每个期货公司都有的制度。这样的东西一般不会做到下单接口里。

 

真的了不起啊。祝早日成功。

 

技术可行性的问题已经解决。说一下策略可行性方面的发现吧。今天在IF0706上用4手开口头寸做了3700多手单子，占市场份额约14%，在单边佣金120元（无平今仓半价优惠）的情况下，支付佣金44万余元，最终亏损26万余元。假如佣金能够作到60元并能够有平今仓半价的条件，当天可以实现7万元的利润（44-26-44/4），保证金约为100万元。