交易

Tick 數據的完整性是否因供應商而異?

  • May 28, 2021

我的公司目前正在尋找各種供應商來購買歷史報價數據。

這個問題的目的不是詢問最佳供應商的意見,而純粹是詢問供應商的報價數據完整性是否存在實質性差異。

所以每個人都在同一個頁面上,讓我們將完整性定義為衡量有多少刻度是“正常”的,即在實際使用中需要清理或丟棄。

假設您為供應商的完整報價數據庫支付費用,無論供應商如何,所有數據最終是否基本相同(假設他們都從相同的來源匯總數據),或者不同的匯總方法會導致(統計上顯著) 不同級別的準確度?

如果您匯總到例如最接近的微秒,這種精度差異會被消除嗎?

如果您願意,您可以提供具體範例,但該問題更多地是為了回答是否有人在查看報價數據供應商時是否應該評估數據的基本質量以及價格和 API 功能。

除了價格和 API 功能之外,查看報價數據供應商的人是否應該評估數據的基本質量。

**當然,您應該評估數據的質量。**即使到今天(2021 年),仍有大量數據完整性問題從供應商傳遞給您,並對您的案例產生重大影響。

您可以將它們概括為 4 類問題:

  • 丟包和會話重啟問題
  • 解析器錯誤
  • 有損正規化
  • 時間戳問題

丟包和會話重啟問題

$$ … $$無論供應商如何,最終所有數據是否都基本相同(可能他們都是從相同的來源匯總數據)

儘管從相同的原始飼料採購,但它們並不相同。

許多現代場所通過 UDP 傳輸實現其原始提要,這本質上是有損的。即使供應商通過交叉連接直接從僅 1 跳遠的場地接收數據,您的供應商也可能會失去數據並存在其他供應商數據中不存在的間隙。在我知道的一家信譽良好的投資銀行中,他們使用這些舊式交換機和低規格英特爾 NIC 來收集原始數據,並且失去了大約 10^-6 個數據包——供應商也可能發生同樣的情況。

同樣,大多數場所在數據中心的市場數據網關上都有分佈式設計,其中數據失去可能發生在數據訂閱者子集的工具通道子集上,降低這種風險的唯一方法是擁有冗餘交叉連接到單獨的網關 - 但大多數供應商會在這裡削減成本,因為額外的連接費用可能每月超過一萬。

供應商之間還有不同的備份和恢復機制。根據供應商的系統恢復和切換到輔助網關的速度,您還可以看到不同的數據。

一些現代場所通過 TCP 傳輸實現其數據饋送,這意味著您的連接是有狀態的,並且您可能必須在會話重新啟動時重新啟動連接,並且在訂閱時,您會獲得目前狀態的轉儲。一個供應商的重新連接機制可能與另一個供應商不同,導致他們在會話重新啟動後的很長一段時間內擁有“後期數據”。

解析器錯誤

這不太可能體現在供應商如何解析標準欄位(例如價格、時間)或消息類型,但更有可能體現在供應商如何解析不太常見的欄位或消息類型(例如參考數據或工具定義消息) 、綜合摘要消息、匹配引擎狀態消息等)

例如,一些供應商可能會提供帶有未考慮匹配引擎狀態的增強 BBO 的“報價數據”,並且在拍賣期間(例如在東京或 SIX Swiss 中發現的那些),您可能會看到倒置的 BBO。

有損正規化

"

$$ … $$有錯誤是供應商的工作要過濾掉”

“如果供應商正在過濾任何記錄,請避開供應商。”

我對使用“未過濾數據”一詞猶豫不決,因為“未過濾”沒有正式的定義——它純粹是一種廣告結構。有原始數據或標準化數據。大多數人使用來自供應商的標準化數據,因為它比直接從某個場所訂閱更方便。

一旦您的供應商對超過 1 個場所的數據進行規範化,他們就必須過濾掉一些東西,因為根據定義,他們試圖在兩種不同的線路格式之間找到共同點。這只是在您的典型工作流程中是否體現的問題。這與您接下來的兩個問題有關:

不同的聚合方法會導致(統計顯著)不同的準確度水平嗎?

如果您匯總到例如最接近的微秒,這種精度差異會被消除嗎?

不,它不會被洗掉。這是一個極端情況,供應商可能會通過有損標準化對您產生重大影響,即使他們為您提供了每個序列號。

在某些場所,交易印刷品與與交易相關的訂單刪除分開發布。在實踐中,訂單刪除可以說是交易列印後的 100 微秒。在其他情況下,與交易相關的交易列印和訂單刪除被定義為一個原子事件。

提供來自兩個場所的圖書匯總快照(例如最佳出價和報價)的供應商必須決定他們將遵循哪種約定。他們是要表明 BBO 深度在交易時發生了變化,還是在書籍更新時發生了變化?

當供應商因為缺乏技術能力而重新規範化數據時,這通常會更糟。即,他們不是直接獲取和解析數據,而是將來自其他提供商(例如 Exegy、OnixS、Redline、MayStreet、Vela、Activ)的提要解析器或規範化數據(例如 Bloomberg B-PIPE 或 Refinitiv Tick History)的數據貼上白標籤.

時間戳問題

一些供應商將丟棄原始提要提供的所有本機時間戳並嵌入他們自己的。有些人將只保留原始提要提供的兩個或多個時間戳中的一個。

您會發現供應商偏離的另一個天真的問題是如何處理閏秒校正。


PS:對我們在Databento的項目大喊大叫,其中 - 為了全面披露 - 我是工程師之一。正如您從以上所有內容中看到的那樣,沒有解決所有潛在數據質量問題的標準方法。相反,我們如何看待這些實現細節和規範化是一個更全面的概念:數據需要具有適合被動模擬的質量。即您應該能夠回測下被動訂單的策略並獲得足夠準確的模擬填充和事件排序以生產您的策略。

我們用來實現此目的的一些技巧可能也適用於各種數據供應商:

  • 將數據擷取完全 CPU 解除安裝到 FPGA,以減輕時間戳和封包遺失的不確定性。
  • PTP 時間同步,用於時間戳的亞微秒精度。
  • 編寫我們自己的提要解析器,以便我們對任何有損標準化都具有透明度。
  • 直接訂閱來自市場的原始多播饋送並管理我們自己的 colo 以減少第三方提供商傳遞的錯誤。

引用自:https://quant.stackexchange.com/questions/64255