極點宏觀｜Financial Cloud Cloud · AWS Re:cap
AWS Re:cap 14: AWS 上的 Tick-to-trade 延遲交易平台
他們使用 disruptor、aeron、FPGA、verilog、VHLs、linux kernel preempt-pt patches、yugabytedb、raft consensus protocols、AWS Cluster Placement Groups (CPGs)、FIX protocol、Liquidnet SmartDark 與 Barracuda Algorithm、5/20 EMA Crossover Strategy、Amazon Time Sync Service、Hardware Packet Timestamping、MiFID II、FIX Adapted for STreaming (FAST)、Simple Binary Encoding (SBE)、amazon Cluster Placement Groups (CPGs)。
Coinbase：使用 Aeron Cluster 建構高韌性、雲端原生的交易基礎設施，以低延遲處理大量交易。
EDX Markets (EDXM)：在交易平台中運用 Aeron Cluster，實現容錯與超低延遲。
IMMIX：採用 Aeron Cluster 建構高效能數位資產交易系統與定序器。
滙豐銀行：整合 Aeron 以強化電子交易系統。
Man Group：在低延遲外匯交易系統中使用 Aeron，快速處理報價串流。
SIX Interbank Clearing Ltd：其瑞士即時支付平台已部署 Aeron clusters。
BLOX Markets：這家即將推出、聚焦散戶的美國股票交易平台正在整合 Aeron 系統。
Chicago Mercantile Exchange (CME)：贊助 Aeron 開放原始碼開發專案，用於內部訊息傳遞。
Kepler Cheverton (Kcx) 與 Adaptive 合作，以 Aeron 建構事件驅動的股票交易平台。
經紀服務領導者 DriveWealth 採用 Aeron 重構交易架構，達成交易所等級效能。
Talos 在數位資產生態平台中運用 Aeron transport protocol，實現高效能交易與訊息序列化處理。
買方與賣方
買方參與者：
● 機構投資人
● 數位資產基金
● 散戶交易者
● 自營交易公司
● 為投資組合取得數位資產
● 專注於策略開發、研究與交易執行，以創造報酬
賣方公司：
● 造市商與經紀商
● 促成交易執行與訂單路由
數位資產交易所：
● 提供資產掛牌與交易的平台
● 與賣方公司共同構成核心交易基礎設施
● 確保流動性、撮合訂單，並提供必要金融服務
● 主要透過手續費與買賣價差創造營收
Tick-to-trade 效能
● 高頻、低延遲交易 (HFT) 正在中心化數位資產交易中快速興起。
● 數十年來，HFT 一直是股票、商品、外匯及包含期貨在內之衍生性商品市場的關鍵金融市場基礎設施。
● 核心功能是為市場參與者提升流動性、降低交易成本，並提高價格效率與價格發現能力。
● HFT 平台的關鍵技術成功指標：延遲 (Latency)、抖動 (Jitter)
● 數位資產市場中的 HFT 公司力求達成低兩位數微秒的 tick-to-trade 效能，以維持競爭力。
造市
● HFT 公司有義務在委託簿兩側向市場報價
● 買價 Bid（MM 買進，交易對手賣出）
● 賣價 Ask（MM 賣出，交易對手買進）
MM 策略的核心功能：
● 賺取價差（買價與賣價之差）
● 管理風險並提供最佳（最快）執行
提供流動性，但也承擔暫時性庫存風險：
● MM 必須執行極大量訂單，才能為市場提供流動性並從價差獲利。
● HFT 公司利用數位資產於多個交易場所間的短暫價差獲利。
● 成功有賴最佳化執行與微秒級速度，因為延遲可能使套利機會消失。
Jitter 對 HFT 的重要性
可預測的執行：
● HFT 演算法依賴一致且可預測的效能，在精確時點與價格執行交易。不可預測的延遲（高 jitter）可能使交易晚於預期執行，錯過最佳價位並可能造成損失。
套利機會：
● Jitter 可能延誤不同交易所間的價格發現，使僅存在數微秒的短暫套利機會消失。
風險管理：
● 一致的延遲能改善即時風險管理與監控。高 jitter 會引入變異，使壓力下的系統行為更難預測，也更難有效管理風險。
演算法完整性：
● 設計為在特定時限內反應的演算法可能因非預期延遲而受干擾，進而產生非預期交易結果。
降低 Jitter 的技術
硬體最佳化：
● 在關鍵處理路徑使用具確定性的硬體，例如現場可程式化閘陣列 (FPGA)。
● 採用專為低 jitter 效能設計的網路介面卡 (NIC)。
作業系統 (OS) 與核心調校：
● 使用即時作業系統 (RTOS) 或特別調校的 Linux 核心（例如 PREEMPT-RT patches），優先處理交易程序並減少非確定性中斷。
● 採用將執行緒固定至專用 CPU 核心等技術，並減少 context switching，以避免 CPU cache miss 與資源競爭。
網路架構：
● 使用 kernel bypass，將資料直接從網路硬體移至 user-space 應用程式，避開通用且非確定性的 Linux 網路堆疊。
● 將伺服器放在交易所共置設施，縮短實體距離並減少網路路徑變異。
軟體設計：
● 使用高效率資料結構與設計模式（如 disruptor pattern），最佳化訊息流並減少不必要的記憶體配置。
● 最佳化序列化／反序列化程序，以有效處理大量資料。
LMAX Exchange Disruptor Pattern：
● 高效能、低延遲的執行緒間訊息系統。
● 使用 Ring Buffer 高效率傳遞事件／工作。
● 常見於高頻交易 (HFT)。
核心概念與運作方式：
Ring Buffer：
● 記憶體中的環狀固定大小陣列。
● 保存事件／訊息。
生產者：
● 使用序號取得 buffer 中的槽位。
● 寫入資料並提交。
消費者（批次處理器）：
● 處理 buffer 中的事件。
● 在相依性圖中運作。
● 彼此通知新資料。
Mechanical Sympathy：
● 善用 CPU caches (L1, L2, L3)。
● 讓資料保持連續且可預測。
● 減少昂貴的記憶體擷取。
無鎖定／競爭：
● 使用序號與 barriers，而非 locks。
● 防止執行緒彼此阻塞。
避免 False Sharing：
● 填補資料，確保變數不共用 cache lines。
● 避免不必要的 cache invalidations。
最佳化：
CPU Cache 使用：
● 善用 CPU caches (L1, L2, L3)。
● 讓資料保持連續且可預測。
避免鎖定：
● 使用序號與 barriers，而非 locks。
● 防止執行緒彼此阻塞。
避免 False Sharing：
● 填補資料，確保變數不共用 cache lines。
交易用途：
速度：
● 對微秒延遲至關重要的 HFT 不可或缺。
吞吐量：
● 處理龐大的市場資料與訂單流。
可擴充性：
● 讓複雜處理管線可跨多個 CPU 核心擴充。
工作導向管線：
● 適合將訂單處理拆成循序且可平行化的工作。
優點：
低延遲：
● 階段間處理可達奈秒等級。
高吞吐量：
● 處理的事件遠多於傳統 queue-based 系統。
可預測效能：
● 避免 locks 與 garbage collection pauses 的不可預測性。
現場可程式化閘陣列 (Field-Programmable Gate Array, FPGA)
● 是一種彈性的積體電路 (IC)。
● 製造後仍可程式化。
● 可建立自訂數位電路。
● 提供硬體層級客製化。
● 適用於高效能運算、訊號處理與快速原型開發。
● 不同於固定功能晶片。
● 使用可重構邏輯區塊、互連與記憶體。
● 平行實作各種功能。
● 實現硬體加速與低延遲效能。
● 適用於電信、汽車 (ADAS)、航太與資料中心。
硬體描述語言 (HDLs)：
● 工程師使用 Verilog 或 VHDL。
● 描述所需數位電路。
邏輯合成、佈局與繞線：
● 軟體轉譯 HDL 程式碼。
● 建立設定檔 (bitstream)。
● 將設計映射至 FPGA 內部資源。
可程式化資源：
● 晶片包含 Lookup Tables (LUTs)、Flip-Flops、Multiplexers。
● 可程式化互連。
● 可形成任何數位電路。
平行處理：
● 各項操作在硬體中同時進行。
● 提供高吞吐量與低延遲。
● 適用於複雜工作。
數位資產市場的公平且平等存取：
● 確保所有參與者擁有相同的交易與資訊存取機會。
● 在成熟市場（股票與衍生性商品），監管機關以嚴格揭露與平等存取要求加以規範。
技術實作：
● 藉由縮小延遲差異達成。
● 確保所有參與者在定義的容許範圍（微秒至毫秒）內，獲得相近回應時間。
● 使參與者能可靠參與價格發現、流動性提供與交易執行。
AWS 的貢獻：
● 許多交易場所基於雲端平台建構，以追求可擴充性，而非精密效能調校。
● 持續改善平台以支援交易所與交易公司。
● 強化能力，提升公平與平等。
架構：
● 中心化數位資產交易所在 AWS 上最佳化基礎設施，以達低延遲效能。
● 讓造市商 (MM) 每秒執行數千筆交易。
● AWS 提供運算放置與網路拓撲最佳化，以降低延遲與 jitter。
● 參考架構呈現典型 CEX 交易處理 hot path，供 MM 以延遲最佳化方式存取。
交易接收與處理流程：
提交訂單：
● 訂單提交至 Exchange Gateway。
轉送訂單：
● 訂單轉送至 Fair Order Sequencer。
批次處理與時間戳記：
● Sequencer 執行批次處理，並將帶時間戳記的訂單傳給 matching engine。
執行確認：
● Matching engine 傳送執行確認。
市場資料更新：
● 市場資料更新傳送至 distribution server。
● 更新再傳至 market data gateway。
HFT Feed Handler：
● 市場資料傳送至 HFT feed handler。
● Feed handler 將市場資料傳給 trading strategy engine。
交易策略引擎：
● 產生提供或取得流動性的訊號。
● 訊號傳送至 order management system (OMS)。
訂單管理系統 (OMS)：
● OMS 傳送訂單並接收執行確認。
● 執行通知傳送至 OMS。
資料複寫：
● 資料複寫至次要 Availability Zone 或 AWS Region。
● 確保主要 Availability Zone 受損時仍持續運作。
高可用性與災難復原：
● 各交易場所採取的方式不同。
● 範圍從同步容錯移轉，到僅對訂單層進行部分容錯移轉，以供部位管理與調節。
延遲最佳化方法：
● 跨這些層級最佳化，確保交易與即時工作負載的端對端延遲盡可能低。
關鍵延遲：
● Order-to-Ack Latency：代表訂單交易的完整流程。
● Tick-to-Order Latency：衡量接收價格變化、轉換成交易訊號及調整部位的速度。
成功指標：
● 價格發現、策略及訂單執行的延遲與 jitter。
● 目標：低兩位數微秒的 tick-to-trade 效能。
最佳化類別：
網路：
● 底層網路造成的延遲。
● 包含 AWS 路由、執行個體放置與連線選擇。
運算：
● Amazon EC2 執行個體類型造成的延遲。
● 包含執行個體選擇、核心與 OS 調校，以及 Elastic Network Adapter (ENA) 效能最佳化。
應用程式：
● 業務邏輯與 user-space 處理造成的延遲。
● 著重高效率流量處理、CPU／記憶體使用，以及減少資源競爭。
系統：
● 全系統程序造成的延遲。
● 包含資料分發、計時服務與整體架構效率。
CEX 與 MM Hot Paths：
CEX Hot Path：
● 著重訂單輸入、在委託簿上執行及市場資料分發。
● 包含訂單輸入、餘額檢查、撮合、確認與市場事件發布。
● 目標：提供最佳執行與定價體驗以吸引流動性。
MM Hot Path：
● 著重 tick-to-trade 延遲。
● 涉及接收市場資料、評估交易機會及下單。
● 目標：維持最新市場觀點，並避免風險與機會成本。
造市商的「Hot Paths」：
● 技術系統中對延遲敏感的資料與執行路徑。
● 針對速度與效率最佳化，以維持競爭優勢並管理風險。
關鍵元件：
市場資料擷取：
● 快速接收並處理外部市場資料。
● 判定資產目前的公允價格。
定價與機會評估：
● 計算最佳買價與賣價並決定數量。
● 管理庫存風險並降低方向性曝險。
訂單輸入與執行：
● 用於快速送出限價單的低延遲系統。
內部通訊與餘額檢查：
● 內部系統間快速通訊。
● 確保訂單有效，且公司曝險在可接受範圍內。
避險：
● 快速執行抵銷交易以對沖部位。
● 管理從客戶交易取得的庫存。
市場事件分發：
● 迅速發布內部市場事件與確認。
● 分發給相關內部系統與外部客戶。
最佳化技術：
Cluster Placement Groups (CPGs)：
● 用於縮短元件間的實體網路距離。
● 將 CEX 與 MM 工作負載放入 CPG，使執行個體集中放置於一個 Availability Zone 的同一個 network spine。
優點：
● 與 CPG 外的執行個體相比，UDP 往返延遲的 P50 平均降低 37%，P90 平均降低 39%。
延遲來源：
● 從網路延伸進執行個體，經過網路卡、核心、作業系統及應用程式層。
延遲最佳化的取捨：
● 使用 Cluster Placement Groups (CPGs)：
● 將網路延遲降至最低。
● 與完整韌性的 Multi-AZ 架構不相容。
將 Matching Engines 視為狀態機：
● 通常建模為確定性狀態機。
● 相同的輸入事件序列會產生相同且可預測的狀態。
● 對維持 CEX 委託簿與金融系統一致性至關重要。
● 核心執行採單執行緒，以避免非確定性並確保線性處理。
用於高可用性與可擴充性的分散式狀態機：
● 跨數個執行個體實作，以提供高可用性與可擴充性。
● 跨多個節點複寫邏輯，即使部分節點失效仍能維持運作。
● 將工作負載分散至多個 replicas 以水平擴充。
● 透過健全的 consensus protocols（例如 Raft）維持一致性。
訊息傳遞、一致性與低延遲：
● 結合 consensus protocols 與 messaging protocols，達成最低延遲與一致性。
● 客戶可設計自訂 messaging layers，或使用 Aeron、Chronicle 等成熟方案。
● [https://github.com/aeron-io/aeron](https://github.com/aeron-io/aeron)
● Messaging layers 已針對低延遲、高吞吐量通訊最佳化。
● 能以最小延遲負擔，確定性地複寫狀態機輸入。
Aeron：超低延遲訊息中介軟體
超低延遲
● 微秒範圍延遲：設計用於提供微秒範圍的延遲，對高頻交易至關重要。
● 可預測效能：確保在不同負載下仍具一致效能。
高吞吐量
● 每秒數百萬則訊息：能可靠處理大量訊息。
● 可擴充架構：支援擴充以滿足大型交易系統需求。
可靠性與韌性
● 24/7 可用性：專為持續運作而建，具備確保高可用性的功能。
● 容錯：包含自動容錯移轉與復原機制。
成本效益
● 開放原始碼：可免費使用，降低授權成本。
● 高效率資源運用：降低硬體與營運成本。
主要功能與元件
Aeron Transport：
● 核心功能：高效能、低延遲訊息傳輸。
● 通訊協定：使用 UDP（單播與多播）及 Inter-Process Communication (IPC)。
● 支援的 API：Java、C/C++ 與 .NET。
Aeron Archive：
● 用途：訊息錄製與重播擴充功能。
● 能力：以完整訊息速率將串流持久化至磁碟，確保資料復原及服務無縫重新連線且不遺失訊息。
Aeron Cluster：
● 框架：用於建構容錯分散式服務。
● Consensus Algorithm：使用 Raft algorithm。
● 功能：自動容錯移轉與強資料一致性，適合交易所及交易工作流程。
Agrona 與 Simple Binary Encoding (SBE)：
● Agrona：提供高效能資料結構。
● SBE：提供精簡、低負擔的二進位訊息格式，縮小訊息並減少 CPU cycles。
對交易公司的優點
超低延遲：
● 效能：在雲端環境提供低於 100 微秒的延遲，在實體硬體上則低於 20 微秒。
● 對高頻交易至關重要。
高吞吐量：
● 容量：能可靠處理每秒數百萬則訊息。
可靠性與韌性：
● 可用性：確保 24/7 可用。
● 功能：自動容錯移轉、即時復原及健全的資料遺失處理機制。
成本效益：
● 降低成本：降低硬體與營運成本，避免 vendor lock-in。
經實證的採用：
● 使用者：全球主要金融機構與平台，包括 Coinbase、Man Group 及 SIX Interbank Clearing。
● 應用：支援即時交易與支付系統。
Aeron 系統的主要元件：
Media Driver：
● 功能：管理 buffer 處理、network I/O 與資料傳輸的核心引擎。
● 部署：可作為應用程式內的 embedded thread 執行，或作為獨立程序執行。
● 優點：將 garbage collection pauses 等事件對延遲的影響降至最低。
Aeron Client：
● 介面：供開發人員使用、面向應用程式的 API。
● 操作：Client 建立 Publications（傳送訊息）及 Subscriptions（接收訊息）。
Channels 與 Streams：
● Channel：定義通訊路徑。
● Stream ID：整數識別碼，用於在同一 channel 上多工處理不同邏輯訊息流。
Log Buffers：
● 儲存：訊息寫入一系列稱為 log buffers 的 memory-mapped files。
● 設計：允許直接記憶體存取 (off-heap)，避開 JVM garbage collection，以提供可預測的低延遲存取。
實際使用案例
● Coinbase：使用 Aeron Cluster 建構高韌性、雲端原生的交易基礎設施，以低延遲處理大量交易。
● EDX Markets (EDXM)：在交易平台中運用 Aeron Cluster，提供容錯與超低延遲。
● IMMIX：採用 Aeron Cluster 建構高效能數位資產交易系統與定序器。
● HSBC：整合 Aeron 以強化電子交易系統。
● Man Group：在低延遲外匯交易系統中使用 Aeron，快速處理報價串流。
● SIX Interbank Clearing Ltd：在瑞士即時支付平台部署 Aeron clusters。
● BLOX Markets：這家即將推出、聚焦散戶的美國股票交易平台正在整合 Aeron 系統。
● Chicago Mercantile Exchange (CME)：贊助 Aeron 開放原始碼開發專案，用於內部訊息傳遞。
● Kepler Cheverton (Kcx) 與 Adaptive 合作，以 Aeron 建構事件驅動的股票交易平台。
● 經紀服務領導者 DriveWealth 採用 Aeron 重構交易基礎設施，達成交易所等級效能。
● Talos 在數位資產生態平台中運用 Aeron transport protocol，進行高效能交易與訊息序列化處理。
訊息流與機制
Publication：
● 方法：Publisher client 使用 offer() method，將訊息寫入 shared memory 的 log buffer。
● 操作：非阻塞；傳回狀態碼，指出成功或已施加 backpressure。
Media Driver 動作：
● 功能：持續讀取 publisher 的 log buffer，並透過設定的 channel（UDP 或 IPC）將資料傳送至適當目的地。
Subscription 與 Polling：
● 方法：Subscriber client 呼叫 poll() method，從其關聯的 log buffer 讀取訊息。
● 模型：Polling model 讓應用程式控制處理資料的時機，避免 interrupt-driven callbacks，以維持可預測延遲。
可靠性：
● 層級：Aeron 在 UDP 上實作自己的 reliability layer。
● 機制：偵測訊息遺失，並使用 Negative Acknowledgements (NAKs) 要求重傳遺失片段，以最低負擔確保可靠且依序傳送。
Lock-Free Design：
● 技術：所有內部操作皆為 lock-free，使用 log buffers 中的 atomic tail updates 等技術。
● 優點：避免執行緒競爭並將吞吐量最大化。
Atomic tail updates
網路通訊協定：
● Atomic tail updates 對高效能網路與資料庫系統至關重要。
● 它們能有效管理 ring buffers 或 logs 等資料結構。
● 以原子方式更新 tail pointer，可確保並行互動不造成資料毀損。
系統升級：
● 在某些 Linux distributions（atomic distros）中，atomic updates 涉及以單一交易升級整個 OS image。
● 只有更新成功時，系統才會開機進入新 image，以確保完整性。
● 這是運用 atomicity 原則的全系統更新。
Raft Consensus Algorithm：
● 一種分散式系統演算法，確保伺服器對資料狀態達成共識；透過 leader election、log replication 與節點角色（Follower、Candidate、Leader）強調易理解性。
● Leader Election：若未偵測到 Leader，節點會從 Follower 轉為 Candidate，啟動選舉以選出新 Leader。
● Log Replication：Leader 記錄 client requests 並傳給 Followers。多數節點確認後，該項目即提交，確保所有節點對操作順序達成共識。
節點狀態：
● Follower：接受 Leader 的命令與 heartbeats。
● Candidate：在選舉期間爭取領導權。
● Leader：協調 replication 與 client requests。
簡化工作流程：
● 開始：所有節點均以 Followers 身分啟動，並設定隨機 election timeout。
● 選舉：Follower 逾時後成為 Candidate、增加 term，並請求投票。
● 投票：若 Followers 在目前 term 尚未投票，且 Candidate 的 log 為最新，便投票給該 Candidate。
● Leader：取得多數票的 Candidate 成為 Leader 並傳送 heartbeats。
● Replication：Clients 將 requests 傳給 Leader，由 Leader 記錄並複寫至 Followers。
● Commit：多數 Followers 記錄該項目後，Leader 提交並套用至其 state machine，同時指示 Followers 執行相同操作。
主要優點：
● 易理解性：比 Paxos 等較舊協定更容易實作與理解。
● 強一致性：確保所有節點以相同順序看到操作 (linearizability)。
● 容錯：選出新 leaders 以處理伺服器故障。
應用：
● 資料庫：CockroachDB、YugabyteDB。
● 叢集管理器：HashiCorp Consul。
● 訊息佇列：採用 KRaft 的 Apache Kafka。
用於高可用性與災難復原的 Multi-AZ 部署：
● Consensus 與 messaging solutions 在單一 Availability Zone 內提供高可用性，並跨多個 Availability Zones 或 Regions 提供災難復原。
● 透過將 log replication 至次要目標或持久化儲存層達成。
● 使用 Amazon S3、Amazon FSx 等儲存服務，以及 Amazon Aurora、Amazon Aurora DSQL 等分散式資料庫。
● Raft log replication modes 各異：完全同步、近同步或非同步。
● 複寫資料包含完整系統互動歷史，因此適用於稽核與合規。
CPGs 與 Amazon EC2 容量履行考量：
● 使用 CPGs 最佳化放置並共置 EC2 執行個體。
● 管理其與容量履行之間的取捨。
● CPGs 在單一 Availability Zone network spine 下形成實際部署邊界，縮小可用的 Amazon EC2 容量集區。
● 影響隨 Availability Zone 大小而異：大型 Regions 與 Availability Zones 中較輕微，小型者則更顯著。
● 使用 On-Demand Capacity Reservations 保留 Amazon EC2 容量，以管理風險。
● 優點包括降低延遲，以及透過 shared CPGs 提高容量保障。
CEX 與 MM 網路邊界延遲：
● 對尋求與數位資產交易所進行低延遲共置的 HFT 至關重要。
● 客戶無法控制這些邊界；延遲與 jitter 取決於放置和網路設計。
使用 CPGs 最佳化延遲：
● Cluster Placement Groups (CPGs) 是延遲最佳化放置的基礎。
● Shared CPGs 將共置延伸至不同 AWS accounts。
● 符合 Region 內的雲端共置原則。
連線模式：
● 數位資產交易所提供各種連線模式，其延遲特性從 50–200 微秒到超過一毫秒不等。
最佳連線：
● HFT 客戶以連至交易所的最低延遲路徑為目標，避開 CDNs 與 load balancers。
● 理想情況是透過 VPC peering connection，使用公有或私有 IP 直接連至 EC2 order gateways 上的交易所 endpoints。
● 最佳化通訊協定選擇，優先選用 FIX 而非 REST 或 WebSockets，以降低通訊協定造成的延遲。
延遲監控：
● HFT 使用分層測試監控 CEX endpoints 的延遲：
● 基本 HTTP/TCP pings。
● 端對端延遲。
● 市場事件與訂單執行的應用程式層級監控。
● 由於 CEX endpoints 與 HFT instances 可能在 Availability Zone 內移動，需持續最佳化放置，在延遲、可用性及執行個體選擇間取得平衡。
金融資訊交換 (Financial Information eXchange, FIX) Protocol
核心概念與機制
● 結構化訊息：FIX protocol 使用 tag-value pair 格式的結構化訊息。
● Tag-Value Pairs：每個資料欄位由唯一整數 tag 及其配對 value 識別。
主要運作層：
● Session Layer：管理雙方連線，使用 heartbeats、gap fills 等機制，確保可靠訊息傳送、排序及中斷復原。
● Application Layer：定義新訂單、執行報告、取消訂單及交易分配等業務訊息內容。
廣泛採用與使用案例
● 起源：最初於 1992 年開發，用於 Salomon Brothers 與 Fidelity Investments 間的美國股票交易。
● 支援的資產類別：已擴展至支援幾乎所有資產類別，包括固定收益、外匯 (FX)、衍生性商品、商品及數位資產／加密貨幣。
主要使用案例：
● 訂單路由與執行：在市場參與者間無縫傳送訂單與執行報告。
● 市場資料傳播：分發即時報價、交易量與市場深度資訊。
● 交易後處理：處理交易分配、確認與交割明細，簡化後台作業與監管申報。
● 演算法與高頻交易 (HFT)：其結構化、低延遲特性適合自動交易策略；Simple Binary Encoding (SBE) 與 FIX Adapted for STreaming (FAST) 等最佳化二進位編碼可滿足極致效能需求。
FIX Protocol 的運作方式
● 訊息式標準：以一系列 tag-value pairs 建構，兼顧互通性與效率。
訊息結構：Tag-Value Pairs：
● 整數 Tag：FIX 訊息中的每一筆資料均以整數 tag 表示。
● 等號：後接等號。
● 資料值：接著是資料值（例如 35=D 表示 New Order Single）。
FIX 訊息的元件：
● Header：包含 BeginString、MsgType、SenderCompID、TargetCompID 等 session-level fields。
● Body：包含 Symbol、OrderQty、Price、Side 等核心 application-level business data。
● Trailer：包含用於驗證訊息完整性的 CheckSum。
運作層
Session Layer：
● 管理兩個交易對手間可靠且持續的連線。
主要機制：
● Heartbeats：定期傳送訊息以確認連線仍有效。
● Sequence Numbers：每則訊息使用唯一且遞增的數字，以偵測遺漏訊息。
● Resend Request：若偵測到 sequence gap，接收方可要求以「gap fill」補上遺漏訊息。
Application Layer：
● 定義訊息的實際業務內容。
● 規定有效的訂單類型、執行報告、交易確認與市場資料請求。
範例：New Order - Single (35=D)
● 以 $150.00 買進 100 股 Apple (AAPL)。
● 8=FIX.4.2|9=100|35=D|34=10|49=BUYER|56=SELLER|52=20251211-10:00:00.000|11=ORD1001|21=1|38=100|40=2|54=1|55=AAPL|44=150.00|10=000|
● 8=FIX.4.2：FIX 版本（例如 4.2）。
● 9=100：Body Length（訊息 body 的字元數）。
● 35=D：Message Type（D = New Order - Single）。
● 34=10：Sequence Number（session 中的第 10 則訊息）。
● 49=BUYER：Sender ID（您的公司）。
● 56=SELLER：Target ID（Broker/Exchange）。
● 52=20251211-10:00:00.000：Timestamp。
● 11=ORD1001：ClOrdID (Client Order ID)。
● 21=1：HandlInst（1 = 自動執行、私有、無 broker 介入）。
● 38=100：OrderQty（數量：100 股）。
● 40=2：OrdType（2 = Limit Order）。
● 54=1：Side（1 = Buy）。
● 55=AAPL：Symbol (Apple Inc.)。
● 44=150.00：Price（限價：$150.00）。
● 10=000：Checksum（用於訊息完整性）。
Simple Binary Encoding (SBE)
● 一種專門的開放標準二進位通訊協定，廣泛用於電子交易與高頻交易 (HFT) 環境。
● 為關鍵任務交易訊息達成極高處理速度及可預測（確定性）延遲。
交易為何使用 SBE
● 在交易中，每一微秒都至關重要。
● XML 或 JSON 等傳統資料格式太慢且太龐大。
● FIX Trading Community 開發 SBE，以滿足在編碼與解碼過程中將 CPU 效率最大化並將延遲最小化的通訊協定需求。
● SBE 最佳化從訂單建立到送達交易所的交易訊息路徑。
主要原則
固定偏移二進位配置
● SBE 的核心概念。
● 為交易訊息中的每個欄位指定精確的記憶體位置 (offset)。
● 對交易的影響：直接記憶體存取可避免複雜 parsing logic，縮短處理時間並使延遲高度可預測。
CPU 最佳化（Cache Friendly）
● 設計為對現代電腦處理器「cache-friendly」。
● 對交易的影響：固定 offset 設計將 conditional branching 降至最低，使 CPU 內部預測機制有效運作。
簡潔性與程式碼產生
● 使用結構化、機器可讀的 XML schema 定義訊息配置。
● 工具會自動產生必要程式碼（Java、C++、C# 等），以讀寫這些特定交易訊息。
● 對交易的影響：程式碼產生可排除人為錯誤，確保傳送方與接收方以完全相同且高效率的方式解讀二進位資料。
交易中的 SBE 與 FAST 比較
SBE（訂單輸入）
● 傳送實際訂單至交易所時通常優先採用。
● 無狀態特性與確定性延遲，使其適合關鍵、點對點的訂單提交通訊。
FAST（市場資料）
● 主要用於接收市場資料（價格、報價）。
● 優勢是大量壓縮重複資料串流 (delta encoding)，非常適合有效率地廣播數百萬筆價格更新。
FIX Adapted for STreaming (FAST)
● 在交易環境中主要用於市場資料分發，通常不用於傳送交易訂單（訂單輸入）。
目的與使用案例
● FAST 由 FIX Trading Community 設計，專門最佳化交易所傳至交易公司的大量即時市場資料 feeds。
● 大量資料：交易所每秒產生數百萬筆價格更新、報價及市場深度訊息。使用傳統文字式 FIX 格式傳送會消耗過多頻寬並造成延遲。
● 壓縮效率：FAST 是強大的壓縮演算法，透過移除重複資料及使用 template-based system，大幅縮小訊息。
● 分發 (Fan-out)：針對一對多通訊（一個交易所將資料傳給許多訂閱者）高度最佳化，因此非常適合交易作業的「市場資料」端。
FAST 如何處理交易資料
● FAST 使用「stateful」方法，接收方會記住同一 session 中先前訊息的值。
● 類比：若委託簿更新時，僅特定股票價格改變，而幣別、交易所及時間不變，FAST 只傳送新的價格值。
● 優點：大幅降低頻寬使用與整體網路延遲，確保交易者盡快收到價格更新，以做出明智決策。
FAST 與訂單輸入（SBE 為何不同）
● FAST 最佳化資料接收，但通常不是傳送交易訂單（訂單輸入）的主要通訊協定。
● 訂單輸入需要可預測性：傳送交易訂單是點對點且極關鍵的互動，確定性延遲至關重要。接收交易所需要每筆訂單完整且可立即解析，不能依賴前一則訊息的狀態。
● 訂單偏好 SBE：Simple Binary Encoding (SBE) 常用於訂單輸入，因為固定偏移二進位配置允許立即、無條件解析，較 FAST 的 stateful compression 提供更可預測的超低延遲。
市場資料與多播：
CEX Matching Engine：
● 持續更新委託簿，產生動態市場活動檢視。
市場資料轉換：
● 原始委託簿狀態透過彙總與標準化轉換為市場資料。
● 交易所擷取各層級（Level 1、Level 2、Level 3）的最佳買價、賣價等關鍵指標。
● Level 1 Data：提供最佳買價（買方願付的最高價格）與最佳賣價／要價（賣方願接受的最低價格）的即時資訊，通常也包括最近成交價與成交量。
● Level 2 Data：顯示不同價格層級的多個買價與賣價（委託簿），提供更深入的市場檢視。此市場深度 (DOM) 資訊有助交易者衡量整體供需。
● Level 3 Data：通常僅供造市商與交易所會員使用。包含 Level 1 與 Level 2 的所有資訊，以及直接與委託簿互動及執行交易的能力。
市價單：
● 市場資料會針對市價單產生；市價單會立即與最佳可用買價或賣價撮合。
AWS Transit Gateway 上的 Multicast：
● 需要在 VPC 內或 VPC 之間複寫並模擬 multicast 傳送。
● 較小型 CEX 可使用 shared transit gateways，向 MM 分發市場資料。
● Transit Gateway 雖方便，但並非為高頻、低延遲交易設計，且對大型 CEX 有擴充限制。
市場資料分發：
傳統市場：
● 透過最佳化、實體範圍受限的共置網路，使用 UDP multicast 向 HFT MM 分發市場資料。
雲端託管的 CEX：
● 主要使用 TCP unicast WebSocket APIs 分發即時市場資料。
REST APIs：
● 用於隨選或定期擷取資料（例如歷史交易、K 線資料）。
● 適合投資組合追蹤器等非即時應用。
● Polling REST endpoints 會產生較高延遲與更嚴格的速率限制。
FIX Gateways：
● 部分 CEX 透過 FIX gateways，為機構 MM 提供即時市場資料。
● 提供訊息標準化與較低延遲存取。
● FIX endpoints 通常託管於專供特定機構 MM、避險基金及自營交易公司的雲端基礎設施。
精準時間與公平、平等的訂單處理：
公平且平等存取的重要性：
● 對數位資產交易所至關重要，且範圍超越網路基礎設施，延伸至應用程式元件。
● MiFID II 等監管架構在傳統市場中強制公平，數位資產交易所也遵循類似原則。
公平訂單與市場事件定序：
● 在交易撮合前後皆至關重要。
● 精準計時是公平訂單定序的核心，讓 CEX 能對分散式元件間的訊息加上時間戳記。
HFT MM 的精準時間：
● 能更準確地處理事件與產生訊號。
● 為策略執行與風險控制提供資訊。
過去的雲端計時服務：
● 精準度僅達數百微秒或毫秒，不足以支援要求低個位數微秒精準度的 HFT 策略。
MiFID II (Markets in Financial Instruments Directive II)
● 是 2018 年生效的歐盟法規。
● 旨在建立更公平、透明且有效率的金融市場。
● 提升歐洲各地的投資人保障與競爭。
● 涵蓋更多金融工具，並收緊行為、透明度及申報規定。
主要面向：
● 向客戶詳細揭露成本／費用
● 更嚴格的適合度評估，包括永續性偏好
● 客戶交易的最佳執行義務
● 加強向監管機關申報交易，以進行市場監視
● OTFs (Organised Trading Facilities) 等新交易場所的規則，以及既有場所的更嚴格規定
主要目標
● 投資人保護：確保客戶獲得最佳結果（最佳執行）與適合其需求的產品，並取得清楚的成本／風險資訊。
● 透明度：要求向監管機關 (ESMA) 與客戶詳細申報交易活動（價格、交易量）。
● 市場效率：促進競爭、減少不透明交易（例如 dark pools），並建立全歐盟一致規則。
核心要求與變更
● 成本與費用：公司必須預先向客戶揭露所有成本（費用、佣金）。
● 最佳執行：公司必須採取所有措施，為客戶交易取得最佳可能結果（價格、速度、成本）。
● 產品治理：要求製造商與經銷商辨識每項產品的「目標市場」。
● 交易場所：建立新場所 (OTFs)，並對既有場所施加更嚴格規定。
● 資料申報：增加向監管機關 (ESMA) 申報交易，以監視市場濫用。
適用對象
● 投資公司
● 銀行
● 資產管理公司
● 交易場所（包括新的 OTFs）
● 金融產品製造商與經銷商
Organised Trading Facility (OTF)
● 是用於債券、結構型產品、排放配額與衍生性商品的歐洲金融交易場所。
● 作為多邊系統，讓買賣意向相遇並形成契約。
● OTF 營運者對執行具有裁量權，可進行 matched principal trading。
● 依 MiFID II 規則，為非流動性金融工具建立透明度。
主要特性：
● 產品重點：主要是債券、結構型金融產品、排放配額與衍生性商品（MiFID II instruments）等非股票工具。
● 多邊系統：匯集多個第三方買賣意向，類似其他交易場所。
● 裁量執行：OTF 營運者可自行決定交易執行方式，不同於 Multilateral Trading Facilities (MTFs) 的非裁量規則。
● Matched Principal Trading：營運者可作為主體撮合買賣訂單，但須符合嚴格條件，尤其是流動性較低的主權債務。
● 監管架構：依 MiFID II/MiFIR 建立，須經授權，並受嚴格市場濫用規則與透明度要求約束。
與 MTFs (Multilateral Trading Facilities) 的差異：
● 裁量權：OTFs 允許營運者裁量；MTFs 為非裁量。
● 產品：OTFs 著重固定收益與衍生性商品；MTFs 可交易股票及其他工具。
● Principal Trading：OTFs 允許有限的 matched principal trading，而 MTFs 通常禁止。
Multilateral Trading Facilities (MTFs)
● 是受監管的電子平台，提供傳統證券交易所以外的選擇。
● 依歐洲 MiFID II 等規則連結買賣雙方。
● 促成各種資產（股票、債券、衍生性商品）交易，通常用於流動性較低或店頭市場 (OTC) 產品。
● 為市場營運者與銀行提供有效率、非裁量的交易。
● 與傳統交易所相比，對金融工具的審查較不嚴格。
MTFs 的主要特性：
● 電子化與多邊：匯集多個第三方對金融工具的買賣意向。
● 替代場所：作為非交易所場所，常用於特殊或 OTC 產品，提高市場流動性。
● 營運者經營：由市場營運者或投資公司營運，不一定由證券交易所本身營運。
● MiFID 架構：受 MiFID II 等歐洲指令監管，確保透明與公平。
● 資產類別：可交易股票、債券與衍生性商品，但有特定規則（例如不可自營交易）。
與受監管市場的差異：
● 掛牌程序：MTF 上的金融工具不一定須接受傳統交易所（受監管市場）要求的廣泛審查與持續義務。
● 裁量權：MTFs 依非裁量規則撮合交易；Organised Trading Facilities (OTFs) 則允許對非股票工具行使裁量。
範例：
● Liquidnet Europe
● Currenex MTF
● UBS MTF
Currenex MTF
● Currenex MTF (Multilateral Trading Facility) 是 State Street 的機構外匯交易電子平台。
● 提供窄幅價差與來自 60 多家銀行的深度流動性。
● 提供匿名的 all-to-all ECN 存取。
● 讓專業人士使用多種訂單類型、演算法與低延遲 API 連線執行交易。
● 以純 ECN (No Dealing Desk) 系統運作。
● 著重為大型參與者提供高效率且具成本效益的外匯與金屬交易。
Liquidnet
● 是技術驅動的代理執行專業機構，也是 TP ICAP Group 的子公司。
● 將機構投資人連接至大型全球流動性池，主要用於股票、固定收益與衍生性商品的大宗交易。
核心服務與功能：
● 大宗交易：促成機構投資人間的大型匿名交易，降低市場衝擊成本並保護交易資訊。
● 全球網路：連結六大洲 57 個市場、超過 1,000 家資產管理公司，合計管理數兆規模資產。
技術與平台：
● Dark Pools：以 Alternative Trading System (ATS) 或 Multilateral Trading Facility (MTF) 運作，使用私人交易場域。
● 演算法交易：提供「Barracuda」與「SmartDark」等進階演算法，在內外部場所尋找流動性，同時盡量減少市場足跡。
● OMS/EMS 整合：設計為與會員既有 Order Management Systems (OMS) 及 Execution Management Systems (EMS) 無縫整合。
資產類別：
● 固定收益：提供次級市場交易方案，以及初級債券市場的創新電子工作流程，包括與承銷銀行的連線。
● 上市衍生性商品：擴展至 US Equity Options，以強化多資產能力。
非裁量規則
● 是不容個人判斷或選擇，並要求特定行動或結果的準則或要求。
● 常見於金融（交易須經客戶核准）、法律（強制支出／行動）及交易系統（如 5/20 crossover 的固定買賣觸發條件）。
● 在投資中，意指經紀商每筆交易都必須取得客戶同意；相對地，裁量帳戶由顧問決定。
● 非裁量意指遵循嚴格通訊協定，而非行使個人裁量。
主要面向：
● 強制遵循：規則必須精確遵守，例如食品或住房等必需品的非裁量支出。
● 明確觸發條件：通常包含客觀標準，例如交易系統演算法（如 5 日均線向上穿越 20 日均線）。
● 客戶控制（投資）：在金融領域，客戶保有「最終決定權」並核准每筆交易，經紀商則負責接單。
與裁量規則的對比：
● 非裁量：嚴格遵守預定規則或客戶指示（例如「XYZ 達到 $50 時買進 100 股」）。
● 裁量：允許顧問運用判斷做決策（例如「管理我的投資組合以追求成長」）。
外匯交易中的 No Dealing Desk (NDD) 系統
● 客戶訂單直接傳給外部流動性提供者，不經內部介入，也沒有「dealing desk」擔任交易對手。
● 確保透明度，並消除經紀商與交易者之間潛在的利益衝突。
NDD 系統的運作方式：
● NDD 經紀商扮演橋梁，使用自動化系統從流動性提供者網路找出最佳可用價格。
主要透過兩種機制運作：
● Straight-Through Processing (STP)：客戶訂單直接路由至流動性提供者，經紀商在價差上增加小額固定加價作為佣金。
● Electronic Communication Network (ECN)：交易者訂單直接與分散式市場中的其他參與者（包括銀行、其他經紀商及個別交易者）撮合。ECN 經紀商通常每筆交易收取固定佣金，同時提供市場的原始浮動價差。
優點與缺點：
● 基礎：No Dealing Desk (NDD)
● 經紀商角色：促成交易，不採取相反部位。
● 利益衝突：經紀商從交易量／佣金而非客戶損失獲利，因此無潛在利益衝突。
● 訂單執行：依真實市場價格自動即時執行，不重新報價。
● 定價：依實際市場狀況而定的浮動價差。
● 透明度：因直接市場存取與即時定價而具有高透明度。
● 潛在缺點：高波動期間價差可能擴大；可能涉及佣金或整體成本略高；也可能發生滑價。
產品與經紀商：
● 交易者通常使用特定平台進行 NDD 交易，數家信譽良好的經紀商提供此系統。
NDD 經紀商：
● FP Markets：以持續偏低的 RAW spreads（通常為零 pips）及快速執行速度廣受好評。
● Pepperstone：以優異的 MT4 交易工具及 Razor account 的競爭性價差聞名。
● IC Markets：因提供市場上極低的平均 RAW spreads 而突出（EUR/USD 最低可達 0.02 pips）。
● FxPro：提供具有 RAW spreads 的 cTrader 平台，以簡潔介面與進階圖表工具聞名。
Liquidnet Barracuda Algorithm
● 尋找流動性的交易演算法
● 結合 dark aggregation 與 lit trading
● 以高參與率及最低市場衝擊為目標
Barracuda Algorithm 的運作方式
● 使用 opportunistic logic 取得流動性
Dark Aggregation
● 核心元件：dark aggregator
● 在 dark pools 尋找大型匿名流動性區塊
● 執行交易但不揭露訂單大小或意圖
● 降低價格衝擊
Lit Trading
● 補足 dark aggregation
● 有利時在公開證券交易所交易
● 運用 opportunistic logic 尋找最佳執行機會
結果與優點
高參與率
● 在市場交易量中達成顯著參與率（例如 lit market volumes 的 65.5%）
市場衝擊成本節省
● 節省市場衝擊成本
● 據報大宗執行節省 10.0 bps
效能指標
● 比 10% POV (Percentage of Volume trading) 交易成本模型優異 17.4 bps
● 比 Interval VWAP (Volume Weighted Average Price) VWAP 優異 4.8 bps
結論
● 有效率地執行大額訂單
● 將對市場價格的干擾降至最低
Liquidnet SmartDark Algorithm
● 專為機構交易者設計
● 在 dark pools 有效率地執行大型股票訂單
● 將市場衝擊降至最低並提升價格穩定性
SmartDark Algorithm 的運作方式
● 在 Liquidnet Dark 交易環境中運作
● 尋找大型、不顯示的流動性區塊
優先路由
● 使用優先路由系統
● 評估「yield and quality metrics」
● 智慧決定將訂單的各部分送至何處
● 優先選擇執行量較佳且價格穩定的場所
尋找流動性策略
● 主動尋找並存取廣泛的 dark venues
● 運用內部 block crossing 機會
● 避免被動等待撮合
最大化曝險
● 結合目標策略與最大流動性曝險
● 讓交易者存取高品質場所
降低市場衝擊
● 在 dark pools 匿名執行大額交易
● 防止更廣泛的公開市場看見大額訂單規模
● 避免在 lit exchanges 發生的顯著價格波動
5/20 EMA Crossover Strategy
● 使用 5 期 EMA 穿越 20 期 EMA，找出短期趨勢變化
● 5 EMA 向上穿越 20 EMA 時為多頭訊號（買進）
● 5 EMA 向下穿越 20 EMA 時為空頭訊號（賣出）
● 適合有趨勢且快速波動的市場
● 需要確認（例如 RSI、成交量）以避免假訊號
運作方式
● 5 EMA（快線）：對近期價格變化快速反應
● 20 EMA（慢線）：提供更廣泛、平滑的短期趨勢檢視
進場訊號
● 多頭（買進）：5 EMA 向上穿越 20 EMA
● 空頭（賣出）：5 EMA 向下穿越 20 EMA
實作步驟
● 辨識趨勢：使用較高時間週期（日線／週線）查看整體市場方向
● 繪製 EMA：在圖表加入 5 期及 20 期 EMA
● 等待交叉：在所選時間週期尋找 5 EMA 穿越 20 EMA
● 確認：使用 RSI、成交量或 K 線型態等其他工具驗證訊號
● 設定停損與目標：多單將停損設於波段低點下方，空單則設於波段高點上方；使用風險／報酬比（例如 1:2、1:3）獲利了結
最適合
● 動能交易：掌握快速、劇烈的走勢
● 趨勢市場：在方向明確的市場中效果最佳
● 活躍交易者：適合較短時間週期（15min、1hr、5min）的當沖或波段交易
主要考量
● 假訊號：5 EMA 反應快速，會產生許多訊號，其中很多是假的 (whipsaws)
● 確認是關鍵：絕不可只依賴交叉；務必尋求其他指標確認
Amazon Time Sync Service：
● 於 2023 年底改善，使用 PTP 與 PTP hardware clock 達成低於 100 微秒（通常低於 50 微秒）的時間精準度。
● 由每個 Availability Zone 中的專用計時網路與 GPS-disciplined clocks 支援。
Hardware Packet Timestamping：
● 於 2025 年 6 月推出，在硬體層級為每個輸入網路封包附加 64-bit、奈秒精準度的時間戳記。
● 運用 AWS Nitro System 的 reference clock，避開軟體造成的延遲。
● 提供封包抵達 Nitro NIC 時的奈秒級可視性
強化執行與監控能力：
● 改善 AWS 上數位資產交易所與 HFT MM 的執行及監控能力。
提升公平性與精確量測：
● 讓 CEX 能實作更高的公平性。
● 讓 HFT 能精確量測往返與單向延遲。