在看過眾多券商提供的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)做出規范，即是為此。
?
總之，對交易來說，策略好壞當然是最重要的；
?
但談到程式交易，除了策略，交易系統的「程式效率與功能完整性」同樣重要。
打印本文
關閉窗口