Logo
Back to Blog

How Quant Firms Made Billions Exploiting a TCP Loophole (Until the CME Killed It With 3 Microseconds)

Preload 99% of the order, fire the last byte the instant the news drops. The strategy that beat everyone until the CME noticed.

By Coding Jesus-
How Quant Firms Made Billions Exploiting a TCP Loophole (Until the CME Killed It With 3 Microseconds)
cover-photo-tcp-frontloading.png113 KB

How Quant Firms Made Billions Exploiting a TCP Loophole (Until the CME Killed It With 3 Microseconds)

Quant firms spent years cheesing a network protocol you've probably never thought about. Not a fancy algorithm. Not some secret signal. The same transport layer your laptop is using to load this page.

Here's how one version of it worked, and why the CME eventually shut it down.

Trading the news

A lot of quant strategies come down to trading the news. An economic print drops, an earnings number hits, a central bank says something, and the price of the underlying moves. It can go up, down, or stay flat, but on a real event it's usually going to pick a direction. The whole game is reacting before everyone else does.

Most people picture this as "have a faster algorithm." The firms running this particular play weren't really racing on logic. They were racing on bytes.

Preloading the trade

When you send an order to an exchange, it travels over TCP. TCP is the transport protocol that moves data between two machines and guarantees it arrives intact and in order. That guarantee is the important part. The exchange won't act on your order until the full message has landed. If it's missing even one byte, TCP just sits there waiting for the rest. The message is incomplete, so nothing happens.

A quant dev can turn that against the exchange.

Before the news hits, they open two separate TCP connections. One is set up to short the asset, the other to go long. Then they send 99% of each message and stop. Both orders are now parked at the edge of the matching engine, fully formed except for the last sliver of data. The exchange can't act on either one. As far as it's concerned, it's still waiting for you to finish your sentence.

So now both directions are pre-staged. Long is ready. Short is ready. Neither has fired.

One byte beats a full message

Then the number drops.

The dev already knows which way they want to trade. Instead of building and sending a fresh 500-byte order like a normal participant, they send the single byte that completes the message they want. That order fills instantly, because everything else was already sitting there. The other connection, the one pointing the wrong way, just gets abandoned. No order, no loss.

Think about the speed gap. Serializing and shipping one byte is a lot faster than waking up, deciding, building a full payload, and pushing all 500 bytes over the wire. By the time a day trader's order has even reached the exchange, the quant firm has already entered and started exiting against him. The market's moved. And the day trader sits there blaming a candle he saw five seconds ago.

That's the whole trick. The edge wasn't a smarter model. It was refusing to send the full message until the last possible instant.

How the CME shut it down

This one got caught. The CME, one of the largest exchanges in the world, figured out that incomplete-message preloading was handing certain firms an unfair head start. It was never technically illegal. It just exploited the way TCP works.

The fix was almost insulting in how small it was. The CME now detects messages that arrive split across packets and adds a delay before an incomplete message is allowed to reach the matching engine. Per their own documentation, that delay is at least three microseconds.

Three microseconds. A blink takes about 100 milliseconds, so this delay is roughly thirty thousand times shorter than the time it takes you to blink. That sliver was the entire business. The exact thing that made preloading worth doing, shaving microseconds, is the exact thing the CME took back, and the strategy stopped being worth running.

If you want to verify it yourself, the CME documents the safeguard publicly (the relevant message tags are 9553-SplitMsg and 7552-DelayToTime), and they hold a patent describing both the behavior and the countermeasure. Links are at the bottom.

The ones that haven't been caught

This one got patched, but it was only ever a single strategy. Plenty of others are still running quietly, because no exchange has noticed them or bothered to look. That's the part most people never see.

I made a full 60-minute breakdown of this strategy on YouTube if you want the whole thing.

Somewhere right now a desk is running the next version of this, quietly, until an exchange catches on. The whole point is finding it before they do.

Sources and further reading