5 ms·

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 de

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.

ssivark 2y ago
How about along a randomized delay (0-T time) to each order? For T=30s it will largely nullify millisecond latency advantages.
- JumpCrisscross 2y ago
  > 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.
api 2y ago
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.
- mhmmmmmm 2y ago
  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
  - api 2y ago
    Impose a small order fee.
    - usefulcat 2y ago
      That will tend to discriminate against smaller traders, like 'retail' traders.
      - JumpCrisscross 2y ago
        > will tend to discriminate against smaller traders, like 'retail' traders Retail rarely hits an exchange.
      - api 2y ago
        Retail usually has larger fees unless you mean Robin Hood which is monetizing you in other ways.
  - shric 2y ago
    Exchanges have requirements imposed on HFTs to prevent this kind of abuse. This one would be no different.
eterm 2y ago
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.
jjallen 2y ago
You fill the orders proportional to the order quantity for everyone
toast0 2y ago
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.
- Kstarek 2y ago
  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

ssivark 2y ago

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

JumpCrisscross 2y ago
> 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.

api 2y ago

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.

mhmmmmmm 2y ago
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
- api 2y ago
  Impose a small order fee.
  - usefulcat 2y ago
    That will tend to discriminate against smaller traders, like 'retail' traders.
    - JumpCrisscross 2y ago
      > will tend to discriminate against smaller traders, like 'retail' traders Retail rarely hits an exchange.
    - api 2y ago
      Retail usually has larger fees unless you mean Robin Hood which is monetizing you in other ways.
- shric 2y ago
  Exchanges have requirements imposed on HFTs to prevent this kind of abuse. This one would be no different.

eterm 2y ago

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.

jjallen 2y ago

You fill the orders proportional to the order quantity for everyone

toast0 2y ago

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.

Kstarek 2y ago
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