Hacker News Reader

Comment by usefulcat | Hacker News Reader

If you're talking about something like having an auction (per security) every N seconds, I don't see how that addresses the underlying issue, which is how to determine order priority.

If you have a bunch of orders at the same price on the same side, and an order comes in from the other side that crosses those orders (or there is an auction and there are orders on the other side which cross), how do you decide which of the resting orders at the same price should be filled first?

The most common way is that the first order to arrive at the exchange at that price gets filled first, and for that reason being fast is inherently advantageous.

View on HN

If you're doing batches to reduce the advantage of being fast, you'd have to treat all orders that come in during a batch tick as simultaneous.

Resting orders from previous batches could have priority, if you want. You'd probably end up doing something with assignment of equal priority orders that looks like option assignment, basically random selection of shares among the pool of orders.

Personally, I'd fill unconditional market orders first, then market all or nothing (if fillable), then sort limit orders by price and from within limit orders of the same price, unconditional first, then all or nothing, then all or nothing + fill or kill.

I don't know if I would assign shares proportional to orders or to shares in orders. Probably shares in orders. Might be gamed, but putting in a really big order because you want to capture a couple shares is risky.

yes you are re-inventing the wheel, the CME has pro-rata markets: e.g Soybeans and Wheat where the matching engine is not FIFO

You could partially fulfil both resting orders, weighted by their (remaining) order size.

You might get "games" around people oversizing orders to try to get more "weight" to their orders, but that would be inefficient behaviour that could in turn be exploited, so people would still be incentivised to keep their orders honest.

How about along a randomized delay (0-T time) to each order? For T=30s it will largely nullify millisecond latency advantages.

> How about along a randomized delay (0-T time) to each order?

This is the sort of good idea that just entrenches the algos. (Former algorithmic derivatives trader.)

For small orders, these delays make no difference. For a big order, however, it could be disastrously embarassing. So now, instead of that fund's trader feeling comfortable directly submitting their trade using off-the-shelf execution algos, they'll route it to an HFT who can chunk it into itty bity orders diarrhea'd through to average out the randomness of those delays.

You fill the orders proportional to the order quantity for everyone

Randomize orders using a cryptographic hash of the order, client info, and all other fields plus a random salt added when the order is submitted.

Sort by hash. Impossible to game unless you can break the hash function.

So now I probabilistically spam a ton of different orders to on average get my desired fill... This just turns it into a "whoever is best at DoS'ing the exchange" game. As the orderbook fills with competitor orders it makes sense for yourself to also spam orders so each of your orders maintains the same probability of being filled

Impose a small order fee.

That will tend to discriminate against smaller traders, like 'retail' traders.

> will tend to discriminate against smaller traders, like 'retail' traders

Retail rarely hits an exchange.

Retail usually has larger fees unless you mean Robin Hood which is monetizing you in other ways.

Exchanges have requirements imposed on HFTs to prevent this kind of abuse. This one would be no different.

Reply on news.ycombinator.com