我们（一家证券公司）正在和一家供应商（你们知道的深圳的那家）做CTP的FIX接口，目标是给海外投资者提供股指期货的交易通道，现在有几个问题希望你们能考虑、修改和解决： 1、操作员模式。现在我们要提供交易HUB服务，就会每个帐户起一个session，需要使用该帐户的密码，由于安全的原因，我们就不能把这个密码再给投资者以免将来发生业务纠纷，这样从某种程度上来说也限制了一些投资者自身对系统可能的访问，所以希望有操作员模式； 2、头寸净额轧差业务。海外投资者从某种程度上来说不关心开仓、平仓、平今仓这些中国特色，敞口方向才是主要的，如果你们在后台能把净额轧差的功能做出来，投资者只要管买、卖就结了，如果还要做现有可平/可平今的头寸查询，其实还要产生额外的通讯，如果有网络传输开销的话，还不一定能保证查询结果可靠。如果这些工作CTP在服务端的内存数据库做了，业务效率就会大大提高； 3、市价单。我不理解如果你们愿意在服务端做止盈止损单（不是交易所官方支持，而是你们编程支持），为什么就不能把上期所和中金所的市价单也在服务端一并通过程序模拟来支持呢？ 4、英文报表。API手册已经有英文了，报表是否也可以做？ 我们选择在CTP上做FIX，而没有采用金仕达、根网这些已经有FIX官方解决方案的产品，一个目的是给专业投资者一个更好的选择（我们认为的），希望你们能认真考虑我们的建议。
2、头寸净额轧差业务。海外投资者从某种程度上来说不关心开仓、平仓、平今仓这些中国特色，敞口方向才是主要的，如果你们在后台能把净额轧差的功能做出来，投资者只要管买、卖就结了，如果还要做现有可平/可平今的头寸查询，其实还要产生额外的通讯，如果有网络传输开销的话，还不一定能保证查询结果可靠。如果这些工作CTP在服务端的内存数据库做了，业务效率就会大大提高； 3、市价单。我不理解如果你们愿意在服务端做止盈止损单（不是交易所官方支持，而是你们编程支持），为什么就不能把上期所和中金所的市价单也在服务端一并通过程序模拟来支持呢？ 这两个境内客户也需要。 不过境外客户的情况不好确定，合规方面。。。。
【答】CTP不可能开放任何一个中间层次的接口引入对CTP稳定及可靠序列机制的潜在威胁。而且，任何中间接口的开放都会将期货公司部分或全部的业务数据暴露给第三方的接口使用者；另外，中间层次的接口开放还会造成投资资者交易的不可追踪和留痕，这无论是从安全还是监管层面都是不可接受的。 【答】CTP为保证高效的性能，对交易指令的支持一般会局限于交易所系统提供的范围。任何其他的指令完全可以在终端实现。另外，CTP的接口开放了所有资金及持仓的算法参数接口，终端可以根据回报自行计算登录账号的各项数据，并不需要依赖查询，而且在CTP，查询是受限制的。 【答】同上。对于个性话的东西，最适合的实现方非标准终端厂商莫属。CTP关注的是高可靠、高容量、高速度的开放性后台系统。 【答】你关注的应该是投资者的结算账单吧！目前，真实有效的结算账单是统一由保证金监控中心发布的，终端软件查到的结算账单与法定账单完全相同。估计很长时间内，保证金监控中心都不会提供英文的账单，CTP也不会贸然提供任何没有法律效力的账单。如果国外的客户需要，可以要求终端厂商提供翻译服务，相信CTP很快就会有英文版的标准终端。 我们选择在CTP上做FIX，而没有采用金仕达、根网这些已经有FIX官方解决方案的产品，一个目的是给专业投资者一个更好的选择（我们认为的），希望你们能认真考虑我们的建议。 非常感谢对CTP的支持与关注，回复内容请参考引用中的【答】。
金士达的B2B是一个类似于CTP所说的中间层次的接口，但没有给投资者提供任何的编程接口。所以，从交易接口的业务模式上来看，CTP指向的是最终用户（投资者），也就是B2C，而金士达指向的是第三方供应商/经纪商。 从CTP这个选择来看，中国的期货公司其实就是一个垃圾层次，本身就没有存在的必要。 关于交易指令，稍微夸张地说，如果能对CTP接口做开发，差不多就能直接对交易所官方接口做开发了，因为CTP的技术至少已经体现在中金/上期两个市场上了。我（站在第三方供应商/经纪商的立场）真要自己做这个业务，何必还要再付一笔钱给CTP呢？ 从CTP的API来看，ReqQryInvestorPosition/OnRspQryInvestorPosition，ReqQryInvestorPositionDetail/OnRspQryInvestorPositionDetail仍然是查询/响应机制，而不是订阅/发布机制。除非持仓/资金信息可以像行情信息一样订阅，否则客户端为确保有关状态准确，仍然要做查询。虽然说可以在客户端做计算来自行维护状态，但在异步模式下，如果同时有高密度的委托和撤单业务，则客户端状态是不可靠的。这本来是CTP应该体现其技术价值的所在，现在还是要丢给投资者来操心。 如上分析，CTP是一个定位B2C的产品，对最终用户方便、友好，但绕过了中间层次，终端厂商虽然技术上做翻译没有问题，但不一定有利益驱动。如果CTP英文版出来了，希望斑竹能在此通知一声，谢谢！
CTP倡导的是进一步的专业化的分工，让专业的人做专业的事。CTP的优势在于提供稳定、可靠、高性能的期货柜台交易系统及运行维护服务。个性化的交易终端及个性化的交易数据管理工具（如报表、CRM及数据挖掘等等）则通过开放接口的方式由在以上领域更加专业的第三方厂商完成。期货公司的优势更在于其拥有的各交易所会员资格和丰富的经纪业务管理经验。 柜台交易系统的开发并不仅是揣摩交易所官方接口那么简单。有序、可靠以及高性能是柜台交易系统所必须的，而且对于实时性要求更高的今天，通过高并发的商用数据库解决方案和频繁的后台服务器查询获得的有序、可靠，在时延上是不可接受的。今天的CTP已经是在大容量、高并发及高速接入状态下实现了有序、可靠以及高性能。使用CTP-API的客户端以及程序化交易投资者，则可以更加专心于交易界面的便利性和交易策略的开发，而不用费心解决时序的混乱和数据遗漏的问题。而且以上问题的解决依靠的是CTP有序可靠的回报机制，而不是查询。当然，相比国际上最先进的柜台实时交易系统，CTP还有很长的路要走。我们也希望更多有能力的软件供应商能加入柜台实时交易系统领域与CTP充分竞争，只有这样国内的柜台交易系统才会获得更加长足的发展，在面对将来国际柜台实时交易系统的威胁时，我们也能更加从容些。 综合交易平台培育的柜台交易系统环境，已经有二十多家第三方厂商为综合交易平台的客户免费提供标准终端，而且对客户需求的响应也相当快捷。有越来越多的第三方个人和软件商正在准备成为综合交易平台的标准终端厂商。
如你所说，CTP已经做到了有序、可靠以及高性能。我们的困惑正在于此，举个例子说明。如果我自己想做头寸净额轧差业务，我唯有自身建立一个内存表，通过CTP有序可靠的回报机制（即回调函数推送的消息），维护当前的可开/可平/可平今状态。但如果我现在有多笔（大量）的场内平仓指令，我要下多笔（大量）的撤单撤掉部分或全部场内的平仓单和可能有的一些开仓单，然后差不多同时再下大量的新委托单，我现在没有把握确定这些新单应该是做平仓还是开仓处理，因为在异步模式和压力情况下，我内存表的状态不能保证可靠。在这种情况下，CTP或者你说的国际柜台实时交易系统的价值就体现出来了，因为一来你们够快、二来你们离交易所最近，所以状态比我终端这一侧要更加准确。也就是说这种需要“有序、可靠以及高性能”的应用特征的需求对于国内目前普通的终端开发商来说在技术基础条件上是不具备的。而且说到底，这个头寸净额轧差业务也不是什么“专业化的分工”的事，而是属于基本的柜台业务或者底层的事。 所以，如果我真的也能在技术上做到有序、可靠以及高性能，那我离开发交易所官方接口也不远了，是不是？
但如果这几千手（的大部分）都是一个帐户用一手1个委托分几千个委托下进去呢？如果每个TICK我都要这么干呢？我不是要抬杠，也不是要给交易所找茬，这样做有业务逻辑方面的原因。 上面的净额轧差的例子说的只是一种需要绝对状态控制的情况，我们还有其的例子，只是想说明同时需要“有序、可靠以及高性能”对于部分的CTP接入帐户也是一种完全现实的可能性。
给你说的再明白一点： 1）假设我有1000手头寸，场内没有单子； 2）0秒时下2000张限价单，每张1手，1000张开仓，1000张平仓； 3）按照CTP公布每秒2000笔的性能，假设在1秒时全部通过RTN回调取得回报（全部是挂单，只确认，未成交），我现在没有可平的头寸了； 4）在1秒时，我下700个撤单，撤的全部是平仓指令，再同时下700个方向与被撤指令相同（价格可以相同可以不同）的单子，如果CTP的性能强大到在我客户端程序700个撤单指令发出后而且是700个新单发出前就把700个撤消成功的消息全部推送回来，那我700个新单就可以全部是平仓单，不会占用任何资金，否则我这700张新单中就会有相当一批的单子由于当时可平数量不足而必须做开仓委托。由于CTP的异步处理设计，我想这种情况的发生是很有可能的； 5）我以上的委托/撤单动作，如果有任何成交回报回来或者有任何行情事件更新就会重复发生，所以最低的重现频率就是500ms。 如果这个开平状态维护业务在客户端做，不会有很多（CTP说的20多家现有开发者之中）客户端技术能很好适应的。
CTP也做不到，它还是要等交易所返回在途报单的情况，交易所的处理速度和回报它又控制不了。你如果愿意等CTP返回确认了，再报新单，那就没问题，如果不愿意等，那么，就一定只能在不知道状态的撤单对应头寸上面报开仓单，付出可能锁仓的代价 归根结底是交易所多了这个开平仓的逻辑，跟柜台没关系，CTP因为没有办法完全处理你说的这个问题，所以要去针对这个做改变的可能性基本不存在，还是要终端自己处理。你会高效处理，别人不会，你的优势不就出来了？这个问题是辩证的。
我也知道CTP不能完全解决这个问题，但肯定比客户端这一侧情况要强，因为是CTP的基础技术比一般开发商的好，所以在状态控制相关的业务上更需要依靠它的后台能力，这是用CTP的主要原因，而比金士达快100ms则根本不是。 没错。但我更希望我的技术优势能与交易策略方面结合，而不是用在系统底层上。我更愿意看到有社会分工，有其他人把这件事做完美，而我只付钱就可以得到，没想自己做供应商。 只要有类似CTP这样的高可靠技术，那个限制对于行家来说就是扯淡。