[kasey_junk]

Your scenario 2 doesn't happen in practice.

The reason is precisely because HFT market makers are fast and sophisticated enough that they want to trade with all small block buyers, so they are resting orders at every trade-able price on every exchange they can.

The speed arbitrage comes from the fact that if they see a level being removed at one exchange it is a demand signal, so they change their own prices on the other exchanges. This is faster and cheaper than going out and sweeping another level (which requires paying the spread).

Essentially, there is no liquidity difference in this case, as all the same liquidity providers are there. They are just pricing their liquidity more accurately.

[pdonis]

> Your scenario 2 doesn't happen in practice.

That seems to be a disputed issue right now; claiming that scenario 2 does happen in practice was, as I understand it, one of the main points of Michael Lewis' latest book on HFT. He may be wrong, but I don't think it's as simple as saying "they're so fast that they don't need to".

An HFT may have orders at every tradeable price at one instant, but what about the next instant when the set of tradeable prices changes? On an exchange with multiple computers executing trades, that is precisely the time when scenario 2 can come into play, and the fact that HFTs are faster than everyone else is precisely what gives them the ability to play scenario 2 in this situation.

> if they see a level being removed at one exchange it is a demand signal, so they change their own prices on the other exchanges

To be clear, my scenario 2 was not talking about matching prices on different exchanges. It was talking about a single exchange that has multiple computers executing trades. Conceptually, the single exchange is supposed to have a single order book, but because there is unavoidably latency between the multiple computers, computer A's current view of the order book may not match computer B's. An HFT that can detect the mismatch faster than the exchange's own computers can, can run scenario 2 in that situation.

[kasey_junk]

"That seems to be a disputed issue right now; claiming that scenario 2 does happen in practice was, as I understand it, one of the main points of Michael Lewis' latest book on HFT."

Let me come right out and say it. Michael Lewis is not "wrong" because he never actually says that scenario 2 happens. The reason he doesn't say that, is that there is no proof that it happens. The reason he couldn't find proof is that it doesn't happen. Any cursory examination of the HFT side of the industry will show that it doesn't happen. He never even does this cursory examination. Go through the book, catalog when he talks to the HFT side. He doesn't do it. The closest he gets is interviewing a developer who is being persecuted by his own buy side firm. Michael Lewis implies that something happens but never actually shows it happening. He does this either due to incompetence, malice, or prejudice.

To prove my point, let's do a thought experiment. Let's say I have 2 HFT systems, each of which are equally fast and are equally good at determining if fills indicate true price movements or blips in the market, and are equally good at evaluating outstanding risk. HFT A's strategy is to quote "small" size in a single market and then when it sees fills it thinks indicate price changes to buy a level in order to raise the price in a particular market. HFT B's strategy is to quote at every level in every market and when it see's fill's that indicate price movements cancel it's order's that are at a bad price.

If their price discovery or risk algorithm are perfect the best case scenario is that HFT A and HFT B are paying the exact same price for the right to trade. If there is any slippage in their price discovery or risk algorithms, HFT B wins as it is not paying for the privilege to trade. QED, algos that don't pay up to jump priority queues do better than algos that do. In the blood thirsty world of HFT market making this inefficiently quickly leads to HFT A going out of business.

As far as your scenario about an exchange that is open to distributed systems attacks, that is akin to asking about a casino that has a secret flaw in their poker shuffling. Yes, that would give an unfair advantage to anyone that found the flaw, but it would also kill their ability to host poker games if it became public knowledge. IE exchanges have a huge incentive to make sure this doesn't happen.

[pdonis]

> there is no proof that it happens...

> algos that don't pay up to jump priority queues do better than algos that do

It looks to me like all of this is addressed at the version of scenario 2 that I was not talking about, the one where the HFT is working across multiple exchanges.

> exchanges have a huge incentive to make sure this doesn't happen

I'm not sure the casino analogy quite holds here, but I'll have to defer any further comment until I can find the article I mentioned somewhere in this subthread, that went into how this scenario would work in more detail.

[MrMan]

Michael Lewis does not know what he is talking about when it comes to this issue, which does not bother him a bit.

kasey_junk seems well-versed.

HFT is like a litmus test for HN. It is a renewable resource.