Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'll take this on.

HFT replaces "expensive humans" with specialist computers that try to site right next to the trading servers, so they can take advantage of the speed of light.

So may I suggest a simpler alternative: Run a trading system with three chunks of time: "get orders", "serve orders", "rest". These intervals could he an hour or 15 seconds. But these way a phone on the otherside of the planet could put in a trade along with the speed of light computers, and not be at a disadvantage.

All HFT is doing is licking the cream off the top of the market -- and not providing any value that a more fair computerized trading system would provide.



Everyone will wait until just before the closing of the window, before submitting their orders, so that they trade with the most information available.

Those with fast connections will have more market information at the point that they place their order.

e.g. I phone in an order to buy gold at $1,200 one minute before the window close. The gold price rises to $1,300. A fast-connection trader then offers $1,201 and buys all the cheap gold, leaving my order unfilled.


I thought it was implicit -- the orders are secret.


Your simpler alternative is known as a batch auction. It exists already in the electronic trading space and typically they have the reputation for being more gamed, not less that traditional order book exchanges.

There was a pretty popular paper out of U of Chicago that showed that a monopoly exchange using batch auctions was "better" for most market participants. That paper did not take into account a few major points that seem (at least to me) relevant.

- The monopoly auction would need to be across all exchanges globally to prevent venue arbitrage. That is not only would you need to unify all of the US equity markets with all of the US futures/options/derivatives markets you would need to do that globally. No German commodities, no Japanese equities, etc. That seems...unlikely. Without a unified monopoly exchange there still exists a speed advantage for colocation.

- The paper did not include execution costs, either in the form of technology drag or fees. On a monopoly exchange that seems important.

Finally, when thinking about batch auctions (or any exchange algorithm for that matter) you need to account for tie breakers. That is, assuming you are still doing price priority (highest buy price wins, lowest sell price wins) then what happens when at the end of your auction there are more buyers or sellers at a given price than can be filled? Some options:

- price/time - this is the traditional matching rules. The order that has been in the order book longest wins. It obviously creates races.

- pro rata - this is another form of matching that currently exists that gives precedence to larger orders, generally by filling a percentage of your order based on the percentage of the total orders at a price it represents. This does not have as many race conditions (though cancel speeds continue to be super important in these markets, maybe less so in a batch auction version). But it gives significant advantages to big market participants or those who are willing to game their risk metrics. In those marketplaces the liquidity is dramatically over reported (a common complaint of HFT) and small order market participants typically must pay the bid/ask spread to get filled. In effect, you can't trade unless you are willing to pay the big boys in these markets.

- random - this is a common idea, and is theoretically more fair (in the mathematical sense) but think about what it would mean. If you put an order in 6 months ago and watched as the price worked its way towards your position, you would have no better chance of getting filled at that order price than someone who just added an order at the last second. This in fact encourages races, not discourages them! Further, it is trivially gamed. It would provide incentives for market participants to flood the auction with small 1 lot orders, again inflating "real" liquidity, in order to increase their chances of getting filled.

All of these still have advantages for participants who are faster, especially on the cancel side. I believe it is a fundamental part of the markets, that spending more resources on monitoring them provides an advantage. There may be other matching algorithms, but these are the ones commonly proposed.

There is a much simpler way to make latency less important than to go to batch auctions or monopoly exchanges. It is to allow for massive decimal places in pricing. That is instead of going down to the penny, go down to the 1/10000 of a penny. That doesn't allow humans any advantage, but it makes the machines compete on what we want them to compete on, price. Note, that full time computerized trading in this format is still at an advantage to phone based humans.

As an aside, a couple of specific points to your comment:

> HFT replaces "expensive humans" with specialist computers that try to site right next to the trading servers

Those computers are dramatically cheaper than the humans they replaced, who were also colocated with the exchange at much higher prices. The savings are passed onto you the consumer as HFT is an extremely low margin business at this point.

> All HFT is doing is licking the cream off the top of the market

This makes me think you have a incorrect (though common) view of how HFT works. You seem to be of the opinion that HFT is stepping into trades that would already happen, ie you are going to trade with another party and the HFT uses their nefarious speed to take money from the both of you. That is not so. The other party is the HFT. Don't think of them as scalping your trade, think of them as adjusting their own prices.

Rather than subverting the price discovery mechanism the market is so famous for, HFT is the price discovery mechanism and it is a far more efficient one than any of the other options we've come up with yet.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: