Electronic Trading Architect | Strategic Advisor

Electronic trading systems architect | 20yr production HFT. Trading systems

[Electronic Trading Architect | Strategic Advisor @sisSoftware]

My last book is a collection of all the articles I've been writing in the past year.
Rearranged for easy reading.

All printed in a book and in one place.
Stays next to my desktop for reference.
(online articles remain fully for free, so having this book is not necessary for reading them)

The book:
The Electronic Trading Stack: Collected Field Notes on Architecture, Latency, and Execution Quality in High-Frequency and Institutional Trading

Find it on Amazon now!!

[Electronic Trading Architect | Strategic Advisor @sisSoftware]

Before you rewrite a C# FIX decoder in C++, look at one loop.

From my book: "Almost all of the gap lives in one loop, the CheckSum byte sum". "The byte-sum loop is 88% of the gap against MSVC 14.44 and 80% against 14.51."

"MSVC auto-vectorizes the CheckSum byte sum. RyuJIT does not, because .NET has no auto-vectorizer and the JIT team said so in 2020."

The JIT team on auto-vectorization, that year: "it is unlikely to happen in the near or even mid-term future".

Time your C# and C++ decoders with checksum validation off.

More in chapter 51 of my book, The Electronic Trading Stack.

[Electronic Trading Architect | Strategic Advisor @sisSoftware]

@visualhft

[Electronic Trading Architect | Strategic Advisor @sisSoftware]

Is your venue's limit a count per window or a rate per second?

From my book: "It gets written into a config file early, usually by whoever last read a venue manual, and it stops being questioned."

On CME's unlabelled order threshold: "Read 500 as a count and the session sustains roughly 167 messages per second. Read it as a rate and the same session sustains 500, which is 1,500 messages across the same window."

Which reading did your config take, and who checked?

More in chapter 24 of my book, The Electronic Trading Stack.

[路克0xLUKE777crypt @0xLUKE777crypt]

做市實戰筆記 #6：互相激發下的訂單流強度
AS 跟 GLFT 通常把限價單成交率轉換成訂單，一旦庫存偏了，報價就往減倉方向移動，看起來很完美。
但研究發現，當一筆有影響力的市價買單進來，後面可能拖著一串同方向的買單接踵而至

然而經典設定通常沒有把剛剛發生的市價單，當成接下來市價單會變密的直接原因。
Hawkes 過程補充說明事件發生後，會暫時提高後續事件的到達強度，如果沒有新的激發，多出來的強度再逐漸衰減，整個系統要穩定，衰減必須夠快，不能只有激發沒有消退。

Cartea、Jaimungal、Ricci 在 2018 年的論文，把這套結構接到訂單簿上，買賣市價單會成群到達，訂單簿形狀與短期價格漂移也跟著變。
自我激發是同側成群，互相激發則是兩側會影響彼此，買單進來，賣單的強度也可能跟著上升。

這裡有一個很重要的區分，市價單變多，不等於你的掛單一定更容易成交。論文把你自己的成交率拆成兩部分，市價單的到達強度，乘上這筆單進來後能不能打到你所在報價位置的條件機率，後者還受到訂單簿形狀影響。

一筆有影響力的市價單進來，可能讓後續市價單更密，但同時其他做市商也會補單、改價，讓原本那個價格位置更不容易被打到，一個往上，一個往下，最後成交率增加還是減少，不能只看到達強度。

這也是為什麼強度不能直接當成毒性。買賣兩側一起變密，可能只是短暫的交易活動增加

所以我想把兩個問題分開

第一個是這張限價單還安不安全，要不要撤掉、後退，或停止加倉

第二個是公允價有沒有真的改變，是否值得重新決定下一張單的中心價格，強度升高可以是第一個問題的警訊，但不直接回答第二個問題。

這也接回上一篇的報價過期問題。
就算判斷某一側正在成群到達，從看到事件到撤單真正生效還有一段延遲，舊報價可能已經被吃掉，預測到了卻來不及撤，和完全沒預測到，最終都可能是一次有毒成交。

我的 bot 先不把這個強度當成方向預測，而是把近期成群事件當作風控輸入，同側成交突然變密時，優先檢查正在暴露的掛單，對可能繼續增加風險的方向減少尺寸，必要時停止新增庫存。

公開資料裡看到的成交筆數，未必等於獨立市價單的數量，同一張主動單可能拆成很多筆成交，把每筆都當成一次獨立激發，強度就會被算得過高。

如下面這兩張圖在講同一件事：你在公開行情裡數到的「成交筆數」，常常不是「來了幾張獨立的市價單」。

左圖看的是，Binance 會把同一張主動單、同一個價位、短時間內打到的多筆成交，先包成一筆彙總成交。但 43.7% 的彙總裡其實都不止一筆，而且這些「一包多筆」就佔了全部原始成交的 78.4%。如果你把裡面每一筆都當成一次獨立事件，後面的到達強度會被算高。

右圖每個點是某一秒有多少成交，全體每秒大約是 1.75 倍，最忙的那 1% 秒更到 2.54 倍。流量越擠，這個落差越大，也正好是最容易把「一張單被拆成很多筆成交」誤看成「單在自我激發、愈來愈密」的時候。

強度告訴我，接下來可能有更多單要來，但那些單會不會打到我、成交後價格會往哪走，需要依照數據分析訂單簿

來源：Cartea, Jaimungal, Ricci (2018), Algorithmic Trading, Stochastic Control, and Mutually Exciting Processes, SIAM Review, 60(3), 673–703。Hawkes (1971), Spectra of Some Self-Exciting and Mutually Exciting Point Processes, Biometrika, 58(1), 83–90。

[Electronic Trading Architect | Strategic Advisor @sisSoftware]

Your breaker can fire on time and you can still lose money.

The SNB, 15 January 2015: "The Swiss National Bank (SNB) is discontinuing the minimum exchange rate of CHF 1.20 per euro. At the same time, it is lowering the interest rate on sight deposit account balances that exceed a given exemption threshold by 0.5 percentage points, to -0.75%."

From my book: "A circuit breaker governs what you quote going forward. It does not govern what you already own."

If your breaker was tested without your position limits, test them together.

More in chapter 28 of my book, The Electronic Trading Stack.

[Electronic Trading Architect | Strategic Advisor @sisSoftware]

Where are you in the queue on a crypto venue?

Moallemi and Yuan, on Bank of America: "the value difference between an order placed at the very front of the queue and an order placed in a queue length of average was about 0.26 ticks on 8/9/2013 and 0.21 ticks on 8/20/2013, which is comparable to the bid-ask spread."

Coinbase: "The full channel provides real-time updates on orders and trades." From my book: "most crypto exchanges don't provide L3" is accurate, but "none do" is not.

Which of your venues sends an order ID?

More in chapter 22 of my book, The Electronic Trading Stack.

[VisualHFT @visualhft]

The second high was higher, yet CVD there was 49K shares lower than at the first.
On AMZN, between the two highs, 105K shares hit the bid and 56K lifted the offer. In VisualHFT Terminal, CVD (Cumulative Volume Delta) goes negative; price shows only the higher high.

#visualhft

[Electronic Trading Architect | Strategic Advisor @sisSoftware]

Your total volume may earn a tier no single venue gives you.

From my book: "The fund is paying retail-adjacent fees on institutional volume because the volume is diluted across venues that each calculate tiers independently."

Binance: "VIP 2 ≥ 5,000,000 USD and ≥ 25 BNB 0.080% / 0.100%". "VIP 3 ≥ 20,000,000 USD and ≥ 100 BNB 0.040% / 0.060%".

"The fee-tier leak is invisible in most fund reporting because dashboards track total fees paid, not fee-tier delta."

Make each venue's distance to its next tier a line on your fee report.

More in chapter 5 of my book, The Electronic Trading Stack.

[Electronic Trading Architect | Strategic Advisor @sisSoftware]

@pauld44 @confinedape @CMEGroup LOL

[Electronic Trading Architect | Strategic Advisor @sisSoftware]

@JamesHirschorn yeahp, it does

[Electronic Trading Architect | Strategic Advisor @sisSoftware]

Paper published

Order Book Imbalance and the Direction of the Next Mid-Price Change: Evidence from Nasdaq TotalView-ITCH

This has been published with NASDAQ market data, but applies to most of the markets (market agnostic)

#nasdaq #research #marketdata

[Electronic Trading Architect | Strategic Advisor @sisSoftware]

A sudden step in your cross-venue latency may be the venue's clock moving.

"customers have depended on the Amazon Time Sync Service to provide one millisecond clock accuracy".

AWS, on its older clock. Its newer one is "designed to deliver clock accuracy in the low double-digit microsecond range".

Once your own clock is tighter than that, alarm on any step in measured offset above the normal one-way jitter on that path.

More in chapter 11 of my book, The Electronic Trading Stack.

[Electronic Trading Architect | Strategic Advisor @sisSoftware]

@visualhft

[confinedape @confinedape]

The free @CMEGroup trading sim page may be interesting to people wanting to tap into futures trading.
I usually don't recommend sim trading, but this offers tools and an environment that teaches more than just buying and selling (incl. real options chains & L2 data, risk tools).

[Electronic Trading Architect | Strategic Advisor @sisSoftware]

Your trading system's primary venue goes down at 3 AM on Sunday.

My book asks: "how long until orders route to secondary venues?"

If it is "when the on-call engineer acknowledges the alert," your architecture is operator-dependent. If it is "the next order automatically routes to the secondary venue," it is deterministic.

"A system designed for 99.5% uptime was acceptable when markets closed. That uptime target allows 43.8 hours of annual downtime".

More in chapter 3 of my book, The Electronic Trading Stack.

[Electronic Trading Architect | Strategic Advisor @sisSoftware]

The same reject message can mean slow down or stop.

Euronext, on throttling: "In FIX, clients receive Reject (3) messages". Breach the limit badly and you "won't be allowed to reconnect for 3 seconds".

The FIX 4.2 dictionary says a Reject "indicates a serious error that may be the result of faulty logic in either the sending or receiving application".

Coinbase Exchange: "Your FIX 5 session is disconnected if your messages exceed 200 messages per second".

Send your handler a Reject (3) with tag 373=26. Does it back off or stop?

More in chapter 24 of my book, The Electronic Trading Stack.

[Electronic Trading Architect | Strategic Advisor @sisSoftware]

Databento reports OPRA's 99th percentile falling from 543.5 to 57.5 microseconds.

On the same page, Databento says "the OPRA SIP's median latency has been mostly unchanged around 19.5 to 20.5 microseconds".

The median stayed near 20 microseconds while the 99th percentile fell by about 89 percent. Does your report show it?

From my book, on desks I have seen: "that blind spot runs low single-digit basis points on burst days".

More in chapter 41 of my book, The Electronic Trading Stack.

[Electronic Trading Architect | Strategic Advisor @sisSoftware]

😂🤣😂

[Electronic Trading Architect | Strategic Advisor @sisSoftware]

Exchange feed drops one packet: the venue fix is discarding your order book, pulling a 5,000-level snapshot, and buffering deltas.

Takes 80ms to >1s. Quoting through is fail-open.

The buffer timeout that survives volatility without thrashing is the number worth comparing.

#hft