高頻交易實盤中，如何提高按對價(bid-ask)執行限價單(limit order)的成交率？

01-06

最近剛開始上手HFT的Arb實盤交易，結果不是很理想，主要問題在盤口的成交率和斷腿止損上。。。
目前實盤的硬體技術條件是使用CTPmini內網進行交易，ping的數值&<1ms，但是由於是個人賬戶，所以賬戶還是期貨公司的主席。國內500ms的snapshot，考慮到減少滑點，以bid-ask的limit order下單。
假設當前盤口snapshot如下：

bid1 = 100； ask1 = 101
bidsize1 = 20； asksize1 = 5
此時short 1 lot @ bid1 of 100, long 1 lot @ ask1 of 101，(報單後1秒，若不成交則撤單)，但發現這樣子在實盤上的成交率很低，大概只有25%左右的成交率。。。
請問這是為什麼？有什麼辦法可以提高成交率嗎？THX
Question Updated:

感謝糖笨笨的回答和提醒，發現問題沒有完全敘述清晰。
現將問題敘述更加具體化如下～
比如，t時刻盤口是
bid1 = 100； ask1 = 101
bidsize1 = 20； asksize1 = 5
而t+1時刻
bid1 = 100； ask1 = 101

bidsize1 = 15； asksize1 = 10
實際上，單子在t時刻就已經下單了，但是即使在這樣的情況下，還是有有很大的概率無法成交或斷腿。。。
請問這是為什麼？有什麼辦法可以提高成交率嗎？THX
Question Updated:
問題尚未解決，現在再更新些最近的測試數據，求指教～

最近幾個交易日，開始使用C++自帶的stopwatch來計算從報單到收到撤單回報或者成交回報的用時，發現了一個比較有意思的問題。
如果order type是GFD的話（掛單1秒，不成交，再撤單），那麼整個過程的用時會遠大於IOC的情況，之前沒測試過就拍著腦袋得出GFD和IOC差不多的結論，現在想想真是汗顏啊～
比如，GFD情況下，發生不成交撤單或者斷腿時，一共20次，每次的總用時在1028-1405ms之間，平均每次單程報單到達交易撮合機的時間為74ms，最快的一次用時7ms，最慢的則要將近130ms；
相比較，IOC的情況下，每次的總用時在4-24ms之間，單程最快的用時僅僅2ms，最慢的是12ms
收到成交回報的時間和上述撤單回報的時間類似，IOC遠快於GFD，單程平均3-4ms左右，最快單程僅僅2ms。

但即使使用IOC+short bid and long ask來進行報單，成交率依舊徘徊在20%左右。

經歷和樓主類似，也是個人在商品上做這塊。

原來也很長時間在糾結這個問題，後來通過個人大半年的努力有點效果，目前實戰半年多時間小有盈利

下面簡單就三個部分，分享下自己在實際交易中的經驗（主要針對SHFE）

優化交易速度
準確回測
擇時和策略的優化

優化交易速度

再考慮交易速度之前需要明白，在你看到行情並且發單的過程中發生了什麼

我把這個過程簡單分解下：

撮合機對訂單薄切片產生tick
tick數據被發往N個行情前置機（不同交易所N不同，SHFE是12個）
行情前置將tick發往期貨公司櫃檯
期貨公司櫃檯將行情數據轉發到你的交易程序
交易程序處理完策略邏輯，並且發單
訂單到達期貨公司櫃檯
期貨公司櫃檯將訂單轉發到N個交易前置（不同交易所N不同）中的一個
撮合機選中交易前置並且撮合

1-2的延時，對於交易者實在沒什麼可以優化的。不過這塊的時間越長，那麼你根據行情去交易的不確定性就越大，具體時間多少我也不清楚

2-3的延時，優化的辦法就是連接所有行情前置並且優選，在實際的環境中這塊延時在你把交易伺服器託管到交易所機房以後，就已經是總延時中不可忽視的部分了

3-4的延時基本可以消除，具體可以向你的期貨公司詢問急速行情業務

4-5-6的延時，可以做的就是寫好代碼（如果專門為你的交易策略寫一個程序，4-5的延時可以小到1us），做好綁定cpu等等優化，同時還依賴網路設備（我個人去配伺服器的時候，老闆就說過他配的伺服器，匯流排延時就比品牌伺服器要差很多，還有交換機等等其他各個環節，糾結起來因素真是太多）

6-7的延時，主要由網路主機設備，櫃檯軟體（硬體櫃檯）和託管的機位決定，還有就是使用次席，免得被人干擾（我個人交易雖然也是次席，但是開盤的時候發單都有失敗的情況，因為這個交易席位其他人發單頻率過高）

7-8的延時，理論上可以讓期貨公司配置N個席位，每個席位連接不同的交易前置，然後每個席位同時發單，但是實際上不大可能，很多期貨公司都只有一個席位

從個人經歷來看推薦的優化的優先順序應該是

進比較好的機房
然後解決2-4
然後做做4-5

當然除了4-5，這些優化主要還是通過你的櫃檯服務商去做，每個環節的優化都需要付出代價，你在做這些的時候需要考慮到

機房和2-4 比較重要，4-5成本較低（重要性並不高）所以推薦，對於條件更好的可以在其他環節繼續優化

那麼在你付出上面交易速度優化的代價以後，能不能做到對於盤口對價的訂單，所見即所得呢？

很遺憾，不行！我個人鼓搗了半年就解決的東西，顯然沒有這種神奇的效果，哈哈。

從理論上講，只有1-2延時很小，然後你把2-8的延時全部做到全市場最好，才能保證所見即所得，不然成交總是隨機的

但是就我個人經驗來看，「進比較好的機房","解決2-4" 對成交率有很好的改善，是可以保證的

準確回測

搞清楚了交易速度優化上能達到的效果後，再來談回測就更清楚了

回測上主要還是考慮上面樓主提到的GFD掛單（因為我個人交易只是持倉時間較短，並沒有頻繁發單的機會，所以不會出現撤單超限的情況），然後根據情況撤單

在這種情況下，回測的時候延遲1個tick對價撮合和實盤的成交情況是很接近的（這一點我實盤對比過），沒延時的回測效果就不用考慮了（原因可以參考上面的交易速度的優化）

所以你需要的是一個允許延遲一個tick撮合併且支持多合約的回測引擎

如果在這種情況下，你的回測仍然能保證交易次數足夠，資金不虧損並且有小盈利，那麼就值得一試

擇時和策略的優化

明白上面的兩點內容，完成優化，用很簡單的方法就可以寫成盈利的策略了嗎?

這個至少我個人不能完成！

所以必須在細節上做各種努力，可以做的是

大時間段的擇時

策略執行等方面的優化

因為個人做的也別人看不上的微薄利潤，並沒有多高的壁壘，講得太多就真的有點擔心策略失效了，所以這方面就不多談了

結語

當時是腦洞大開，從一個非業內人士去轉戰量化交易做高速套利

折騰了大半年雖然有盈利，但是容量真的很小，看來研究的性價比也不是很高

無奈搞出感情了，後面就決定一直延這個方向研究下去了

目前在用決策樹研究市場高頻波動，決策樹挖掘結果很容易可視化，所以可以把有交易邏輯的交易信號（也就是決策樹分支）生成文本描述，既可以人為過濾，也能提高對市場的理解。（主要就是機器學習的標準流程，難點在寫特徵，定義不同的分類標籤，對分布不均勻的數據重新採樣等等細節）

後面打算把不同分類標籤的信號（比如短期盤口特性的，方向性的，波動類的）做一個信號集，利用個人的理解和模糊推理系統（FIS）整合

思路又是個人腦洞大開，有大神看到思路問題希望多多指點。。

然後希望在python，機器學習，交易等等方向能和大家多多交流！

瀉藥，以前我也想過做這種交易，而且還真做了一段時間，結果和你差不多。

究其原因，用簡單的tick或者K線的last price回測出來的兩個合約之間的套利交易機會，本來就不曾存在過。

兩個合約如果相關性夠高，那麼必然大方向上last price會走的很緊，然後由於bid-ask的存在，某一個時間切片時的last會有偏差，那麼回測的時候用last來算就會出來一根非常漂亮（45度往上）的曲線，但是現實中其實不曾存在過那樣的偏差。

要做這種回測，最殘酷的方法就是用tick數據下的bid - ask對價作為你的策略成交價，如果這樣回測時還能有賺錢的曲線，才值得去實盤裡做。

另外國內的撤單是有次數限制的，所以歐美用TT那種spreading algo來獲取目標執行價的方案並不可行。

除了自己系統速度慢會造成成交率低以外，也有另一個可能是系統依賴的信息來源本身就遲滯了。。。

你報的limit價是對手價還是非對手價？非對手價25%，如果是40ms後到達交易所的（實際考慮對摺，因為這個時間是一個往返時間），這個基本是一個合理概率吧（一來前面本來有單放在你前面，二來你的單，本來就屬於再放到別人後面的）；你問的問題還是不夠全面，別人也不知道怎麼回合（能允許的滑點幅度，能容忍的不能成交程度，tick與tick之間的預估流動性【相對於掛單量有個比較】），你先完善一下問題吧

適當降低閥值

如果是隨機一個snapshot不應該只有這麼低的成交率

有可能是因為你讀取到的是毛刺行情？你想要處理的這個snapshot有太多人想要買了。

比如行情平穩在100bid 101 ask 突然有一個tick打到105bid 106ask 做套利的人紛紛去搶105bid的單子於是你掛105賣就不容易成交了

成交率和你的策略有相關性的

知足吧，這種套利機會大家都盯著呢，高阿爾法的單子一出來搶的人一堆，做得早的早用上核武器了，拿來輪得到你來搶，我下市價單平均滑點能在1.5以上，而正常情況對價下單其實最多滑0.5，還是量大的情況下，所以簡單策略除了拼速度別無辦法。不過你說ioc平均會快一些，這個倒是挺有意思。

就某些簡單套利策略的競爭程度，即使做了足夠的速度優化，25%也是一個常見的對手價ioc成交率。

如果按照ask1買 bid1賣肯定不會這麼低成交率，要麼就是你程序有問題，要麼就是延遲。如果想在ask1賣 bid1買就得埋單

看到你用&<1ms描述，題主是在用windows嗎？

25%。目前國內經紀商提供的免費的ctp基本上也就只能這樣了。

要優化訂單到達交易所的時間是需要成本的，問題就看誰來承擔這個成本。

假設你命中率提高到40%，每年多花100萬，划算么？這個要你自己算。

當然目前國內還是有不差錢的經紀商願意賠錢賺吆喝。但這畢竟不是長久之計……

要提高成交率，就必須要搶到好的queue position.

那麼理論上就有兩種方法：

一，插隊，變成做市商，在bid ask spread 里報價

二，減小latency，行情一變，你就馬上排在best price隊伍最前面

當然了，不在意spread和rebate的話可以matket order

IOC 的單子不會進入order book ，你可以用fok 指令試試，對手價的limit price 不適合搶單，你回測的時候就該把滑點設置成買賣各一跳

不知道題主搞得怎麼樣了= = 我最近也遇到HFT fill rate的問題，闊以私信聊聊嘛

" 比如，t時刻盤口是

bid1 = 100； ask1 = 101

bidsize1 = 20； asksize1 = 5

而t+1時刻

bid1 = 100； ask1 = 101

bidsize1 = 15； asksize1 = 10

實際上，單子在t時刻就已經下單了，但是即使在這樣的情況下，還是有有很大的概率無法成交或斷腿。。。 "

你文中說的是對同一合約低賣高買，先不說為什麼這麼做，我可以肯定地告訴你，你描述的這種現象不會發生，也就是說，在T+1時，買賣價還沒變的情況下，你不會出現成交不了的情況。

CTPmini看是哪個交易所, 也就上期所有點優勢, 不如飛馬快, 當然還要更快的行情和交易系統, 櫃檯等等.

你問的25%成功率應該是你抓取的那些時刻, 而不是任意時刻, 說白了, 你看中的tick基本上別人也覺得好, 看誰更快而已...

兩邊都cross spread? 你這樣不就完全貢獻fee了嗎？

根據提供tick信息表示你沒有成交，是是因為你的單掛別人的後面，也就是說你接收行情速度和發單速度延時太大。毫秒級別搶單太困難，在同等水平接收行情情況下，50微秒以下才能提高成交率。

即使是CTP主席，按道理拿對手價也應該成交率很高甚至100%，是不是行情本身就有延遲？請問題主的行情是接的誰的？

做的國債期貨嗎？除了提高自身系統性能外，改善下下單策略，先後單？像夏普率高的這種套利搶的都是差不多的單子