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.
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.
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?
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.
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
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.