滑價是什麼?該怎麼計算?

撇除掉諸如穩定供電、機器效能等議題，雲端主機與IDC機房的價值幾乎來自於”滑價是否能減少”，但是滑價該怎麼計算，才能如實的呈現呢?

我們從常見的程式交易架構會造成滑價的原因說起，程式交易的主要運作順序是
1. 收報價
2. 訊號處理
3. 出文字檔orDLL將訊號交予下單機
4. 下單機下單
檢查滑價則是在訊號處理後所產生的點位，與實際下單成交的點位做對比，有可能滑的更好，也有可能滑的更差

但是我們滑價的造成並不單單只是因為”4″的快慢影響而以，而是1~4的運作順序，”每個環節”，都有可能對滑價造成影響。

舉個我們曾經遇過的案例，有客戶於中國工作，將自己的交易機一併帶到中國，連回來台灣下單，結果就是連報價都晚了5秒，幾乎是在平行時空交易，最後放棄了這種無法掌握的交易，改採用我們的雲端方案。

話說回來，假設投組的最大口數 = 實際下單的最大口數，那滑價的計算將是十分容易，因為每一個策略的進出一定可以對上實際成交的價格，但對於大多數交易人來說，有50支、100支策略實屬正常，有使用管理架構的老道交易員，策略數可能高達上千支，但我們的財力可能無法容許我們打到上千口。

因此，對於大多數交易員來說，會採用比例單的方式執行，但是在使用比例單的情況下，我們又要怎麼確認是哪一支策略的進/出，會有實質的成交?

多數人為了簡單形式，通常會直接將績效*執行比例，來當作理論的損益，再用實際的損益比對，估算滑價，但實際上這樣執行不會有問題嗎?因為實際的口數不可能存在0.5, 1.3, 2.7這一類的口數，下單機的運作原理通常也是走四捨五入、四捨六入五成雙一類的方式來下單。

我們舉個比較誇張的例子，如果今天的投組總口數加總 = 2，比例執行40%，那當投組口數為+1口時，執行比例 = +1*40% = 0.4口，但我們不管是下哪個商品，都不存在0.4口，要嘛打0口，要嘛打1口，如果一律都用無條件進位，那原始投組無論是打1口還是2口，比例還原後都是1口，試想，單純用投組原始績效*執行比例，一定是不合適的，實際可參考下圖

如果我們單純用理想的比例單與實際損益情形做滑價對比，那一定是剪不斷，理還亂。

因此我們應該要記錄的，應該是比例單四捨五入之後，會下單的位置，與實際下單的位置來做對比，才能取得正確的滑價分析。

不過我們要怎麼取得四捨五入後，實際上程式會有訊號的點位呢?大致上有兩種做法

1. 透過將所有的策略匯入portfolio trader後，執行分析，再將所有成交明細匯出，操作excel來判斷點位，但PT在交易上有他的問題存在，我們不細說。
2. 透過在每個策略上加上特定的文字檔輸出訊號，將每支策略的交易情形輸出到文字檔後，自行針對交易情形進行排序後，再做分析，將實際成交點位輸出，再進行滑價比對。

我們針對第二種方式特別開發了一支工具，讓使用者可以快速的進行滑價計算，我們將在下一篇對我們的工具進行詳細的介紹。