取价、回报与分帐-交易系统的「程序化效率与功能完整性」重要性[程序化新手]
在看过众多券商提供的API系统范例后，不禁捏一把冷汗。
由于国内程式交易的趋势来得太快(犹记6年前开始在券商讲授程式交易课程时，那时尚未有API元件)，
自动交易接口系统(API)的发展可说是边打边跑，虽然每一版本会渐趋完善，
但券商迫于彼此间的竞争压力，通常等不到版本完整(Bug Free)，就提供(Release)出来。
这可以从范例程式与说明文件的杂乱(不需从实测中找出错误，从程式码的注解即可窥知)；
不需特别留意，偶而我还能从券商释出的API程式码或文件中找出若干错误。
说「捏把冷汗」是因为，自动交易元件可不是MS Office的Beta测试版(最大损失不过就是编辑时间)，
而是被使用在高槓杆的金融交易，一个闪失，赔的钱由谁负责?
我真心期盼国内程式交易能完全开放，不免担心万一出错可能导致的保守势力反扑。
就像遇到1987年股灾或今年5/6事件时，程式交易就被拿出来做代罪羔羊一样。
这篇文章，我希望从自动交易系统的取价、回报与分帐子功能，可能导致的问题探讨。
这些问题小则导致无法成交(策略失灵)，严重则产生短时间的大量亏损，不可不慎。
这些可能的问题也不仅是我的想像，而是真实发生的案例。
先从「取价」谈起，即时交易时，交易系统会取得最新的委卖卖价，甚至包含上下五档的报价(与需求量)，
设若取价慢个0.几秒，会如何；如果是市价单影响不大，但若是限价单可能就会导致无法成交的状况，
因为在几毫秒的瞬间，盘口跑掉了。
「All About High Frequency Trading」一书的序言中的对话很有趣，如下...
Customer: How much are these?
Merchant: A buck fifty.
Customer: I’ll take some.
Merchant: They’re a buck fifty-one.
Customer: Um, you said a buck fifty.
Merchant: That was before I knew you wanted some.
Customer: You can’t do that.
Merchant: It’s my shop.
Customer: But I need to buy a hundred!
Merchant: A hundred? Then it’s a buck fifty-two.
Customer: You’re ripping me off.
Merchant: Supply and demand, pal. You want ’em or not?
...
以上对话隐喻「人为交易赶不上市场的速度」，但即使用系统交易，也必须系统赶得上市场速度才行。
许多演算法交易策略(例如VWAP与PEG策略)会视状况交叉运用市价与限价单，若取价(取得报价)无法赶上市场速度，
就鸡同鸭讲，不是要承受滑价损失，就是无法顺利成交。总是，交易策略就跑不动了。
曾在另文中提到，期交所的朋友告诉我「国内交易者下无效单的比例高于国外交易者」，或许就是这个原因。
再谈「分帐」系统，
假若同时驱动许多程式交易策略，但无法对个别交易策略的盈亏做精确的分帐管理，
若发生亏损，也只能全部断路，关于，此我在另一篇文章中提及此案例，不再赘述。
最严重的，应该是「回报」系统功能的精确度了，
许多複式部位下单，必须仰赖快速的回报，才能知道接下来该怎麽做。
但曾有期货商，不知何故送出的交易单成交后未及时回报，交易系统以为未成交，
不断送出交易单，很不幸的，这些交易单不但成交，市场还往反方向走，以至于产生单日钜额亏损。
后来我与一位在银行交易黄金的交易员谈及此事，他说他们也曾发生此状况，只是运气好，市场顺势大赚，
可见类似状况屡见不鲜。
有一券商提供的API，下单后提供「等待」与「非等待」两种模式提供选择，后者不等Server回覆下单状况，就下单，
速度为等待模式的3倍多(分别是每秒20笔与每秒6笔)。我认为非等待模式是有风险的。
这一期的台湾期货月刊提到美国期会协会对于未经检核方式的DMA(Direct Market Access)做出规范，即是为此。
总之，对交易来说，策略好坏当然是最重要的；
但谈到程式交易，除了策略，交易系统的「程式效率与功能完整性」同样重要。
有思路，想编写各种指标公式，程序化交易模型，选股公式，预警公式的朋友
可联系技术人员 QQ: 511411198 或微信：cxhjy888 进行 有偿 编写！（不贵！点击查看价格！）
- 上一篇：文华软件启动慢？
- 下一篇：没有了！
相关文章
-
没有相关内容
会员登录/注册