I can't reply to that thread (maybe it's because it was too long ago), but you draw a difference between someone moving a large block (as described in yummyfajitas' post), and someone trading a small size (50 shares). So let's say that someone does want to trade 50 shares, in your example, and breaks up their order into 2 25-share orders. At the point at which a 25-share order is executed on the market, the sheer size of the trade is not very much. It's not likely to signify a market move. At that time, nobody has knowledge that there is a second 25-share order heading to the second market. It is possible that an HFT player sees the first execution and takes out the shares at the second market, but with such a small execution, they are pretty much guaranteed to lose money.
No, that's not the distinction I was drawing. The distinction I was drawing was between the following two scenarios:
(1) Someone wants to move a block of 50 shares, but there are only matching orders in the order book for 25 of those 50 shares. The seller splits his order so that the 25 shares move; then either the other 25 sit there until a matching order appears, or the seller changes his offer price for the other 25 shares so that there's a match.
An HFT in this scenario is no different from any other investor deciding whether or not to match an order in the order book; he just moves faster. And since in this scenario there are no other matching orders in the order book without the HFT, the HFT adds liquidity in this scenario.
(2) Someone wants to move a block of 50 shares. There is no matching order in the order computer in which they place their sell order, but there are matching orders in other computers. The HFT sees those other matching orders before other market players, and matches them. Then he places his own order in the computer where the original 50-share sell order is, and matches it so it executes.
In this scenario, the HFT adds no liquidity; all he does is shift the profit on the trade from other market players to himself, by taking advantage of the latency between different computers on which orders are placed. The trade would have happened anyway once the two computers reconciled their orders.
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.
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.
"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.
> 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.
In response to situation (2), I want to first tighten the language - as it stands, I'm not sure if it's even possible. By computers, I think you mean exchanges (for example, Nasdaq, BATS, etc.) So somebody wants to trade 50 shares there. Let's say they want to buy at $10.00, and there's no sell orders on NASDAQ but 50 shares on the offer at BATS.
1) If you were doing this through a broker, and that was the state of the book, then they would just route your order to BATS (if I'm not mistaken that's a legal requirement for brokers).
2) If you instead placed the order to be on Nasdaq-only, that would lock (have buy and sell orders at the same price) the national book, something which is not allowed due to Reg NMS. So Nasdaq could not display that you want to buy at $10.00 anyway, and (I'm not sure how they implement their stuff) either hide your order or display it at another price.
So I'm not sure how exactly you're framing this situation. If the HFT's computer can see that your order exists, it's because it posted. If it posted, it could not have had the limit price that would've locked the book.
I may be misunderstanding what you mean when you say at the end that the "two computers reconciled their orders" - because nothing like that does happen. If they are computers at the same exchange, then no, that's simply not how matching engines work. If at different exchanges, then there is no reconciling, your order would not have posted at the right price, or your broker would have not tried to get you best execution on your order(which they are bound to doing).
No; as I responded to another post in this subthread, I mean multiple computers belonging to a single exchange, such as NASDAQ. In one of the previous HN threads on this topic, somebody linked to a post that showed the situation I'm talking about; I'll see if I can find it.
