?

曾經在論壇中介紹一本談高頻交易的好書(All About High-Frequency Trading)，并整理其中第三章提到高頻交易手法的一部分，該書有六章，其中第三章、第四章與第五章都很精彩，今天就來分享第四章的部分內容，并提出個人的看法。

?

首先作者提到高頻交易(High Frequency Trading; HFT)系統建得不好，比沒有HFT來得更糟，將注定成為鯊魚的晚餐。關于這點，我非常同意，HFT不是一般交易人玩得起的(但從HFT策略得到些許靈感，可以用到目前的交易中)，因此幾次婉拒期貨邀請我對一般交易人談高頻交易(券商的目是希望與API推廣產生連結)，看完以下的分析后，網友就會明白。我不想讓一般投資人認為這是人人可參與的金錢游戲，基于市場特性(請參考分析高頻交易策略的章節)，即使法人也只有少數贏家，那其他人怎麼辦?簡單的說，「不要入局」。

?

我有位學生目前服務于某期貨商，他的工作是運用所有可能的資訊技術(在接下來的一系列探討高頻交易系統資訊技術中會談到這些技術)，希望建立一個完成交易流程的最快速通道(從交易所取得報價、驅動策略、下單、回報等)，比較基準是資訊商提供的Solution與目前公司內部的現有Solution，我認為走高頻交易，這個努力方向是對的。

?

以下我依據該書的探討架構，列出重點，并在每單元提出我的看法，提供討論。

?

1. 公司HFT系統應該採取外購或自建(Buy or Build)?

?

關于HFT系統的建置，第一個思考的決策是，外購或自建(也就是所謂的In House Solution)?

?

如果是外購，那麼花一大筆錢把軟硬體(順便連顧問服務)回來運作，就沒有以下的麻煩事...

?

雖然市面上有許多可以購置的高頻交易系統(例如提供造市功能的ORC、áctant與RTS系統，提供HFT中的Quoting Engine、Electronic Eyes、Auto Hedgers等功能)，也確實有許多金融業者成功的使用這些套裝軟體賺到錢。

?

但作者建議HFT系統的關鍵部分一定要自建(雖然成本高很多)。為何呢?(這點我非常同意)

?

首先，HFT通常是多數競爭者競逐少數的機會(回顧高頻交易策略的內容就知道了)，如果使用同樣的賽車競速，那麼勝負只在于賽車手的操縱手法間，問題是HFT運作過程是沒有人為介入的，而無駕駛人參與的賽車勝負，就取決于賽車的整體性能；賽車的每個單元與互動結構設計，成了勝負關鍵，只要是決勝的關鍵單元都必須自建。

其次，將同樣的軟體賣給不同的人，是軟體業的生存方式；軟體供應商面對眾多客戶，不可能立即反應HFT客戶的需求；軟體開發商有其時程，通常會等到需求累積到一定程度，將足夠釋出新版本的需求功能寫進去并完全除錯后，再出貨。因此，客戶拿到的不會是第一手功能的軟體。

?

如果這家軟體公司也作HFT業務，可能就會把還沒做到Bug-Free的未出貨系統，拿來用一用，用以測試系統，但也可能把HFT系統的市場獲利機會吃掉一部分了，也說不定軟體公司發現賣軟體的獲利不如自己玩，那麼這軟體就不會問市了。過去也有軟體公司是因此轉型的，TS公司不就對賣TS軟體興趣缺缺嗎?其實賣軟體是件辛苦事(特別是臺灣的軟體業，沒有全球市場就更辛苦了)，交易軟體真的有用，何必賣呢?。

?

但，倒也不是HFT系統上上下下，都要自己來，軟體基礎建設部分就不需要(如作業系統、程式開發環境、資料庫、硬體結構等等)；那麼界限何在? ?(來源 m.kzuj.com.cn )

?

需要自建的關鍵就是后續要討論的HFT軟體的關鍵部分(就像要改裝賽車，也不需要自建或改造所有的零件一樣)。

?

2. 使用因應快速改變的系統開發方法

?

由于金融市場高度競爭與變化快速，HFT策略的生命週期通常很短，也因此HFT系統必須隨時因應改變。為此，HFT必須做到模組化，并設法降低系統間的藕合程度，這些是軟體工程探討的課題。關于軟體工程的說明補充于后。

?

HFT系統的開發，沒有規畫的「編碼修正模式」(一邊編碼一邊偵錯)當然不可取，「階段模式」或「瀑布模式」可能無法因應需求快速轉變，「漸增模式」與「雛型模式」是可行的作法。以期系統隨著市場改變演變。許多系統開發者執著于創意的發想與系統完成創意的喜悅，卻不愿花時間在詳盡的偵錯與系統文件的撰寫。凡此都造成系統后續發展或團隊開發的困擾。?(來源 m.kzuj.com.cn )

?

3. 功能分佈與負載平衡

HFT系統龐大，可分成許多不同的子系統(有些負責取得報價、有些負責監控機會、有些負責定價)，這些子系統若放在同一個主機處理肯定負荷不了，應該將系統分散在不同主機中平衡負載并協同運作，至于功能分佈如何可以最佳化，可以進行測試。

?

?