If you're a market maker, you really, really want to be able to do low-latency trading in order to hedge fills before the market moves against you. If market makers can't do this, they will make worse markets - show less size and wider prices, or just get out of the game. How do you do this under continuous batch auctions?
I have an underdeveloped idea that what we really need is limit order types with built-in hedging. "Bid to buy 100 gizmos at 30c each, and for every five gizmos bought, immediately offer to sell 1 widget at $1.20; cancel this order if the best offer for widgets moves below that price" sort of thing. Basically, you're moving the simple reasoning that has to be executed at low latency from the market maker's FPGA to the exchange's matching engine.
Sometimes, you can do this by putting orders in spreads, but only where a spread exists (or can be defined) for the two legs you care about, in the right ratio.
You might also want to do more complicated things, like pulling an order in one product if another product moves a lot, because you think that presages a move in the product you're quoting.
The idea would be, firstly, to make it much easier to make markets without having to invest in low-latency infrastructure, broadening the base of participants who can do it, and secondly, to reduce the negative impact of speed-blunting interventions like continuous batch auctions or speed bumps.
The hedging scenario you describe is one of the hallmarks of combinatorial auctions[0], which let participants enter bids on packages. (Disclaimer, I'm a founder at OneChronos which is applying these auctions to US equities.) So a market maker can express something like: "fill me for any package that includes `x` gizmos AND `k * x` anti-gizmos simultaneously".
The more powerful and general version of this is: "Buy and sell any mix of products, subject to the total package being neutral across these 10 risk factors I care about."
> You might also want to do more complicated things, like pulling an order in one product if another product moves a lot
This is a key problem in US equities or any market with similar fragmentation. The way we're approaching that is to allow those package bids to also include constraints on "current" market conditions at the moment of the auction. A simple one would be "if the momentary spread between asset A and B is greater than X, don't trade."
Putting what amounts to trading bot logic into the orders themselves seems like a bad idea for scalability. Is all order logic visible to all market participants? If so, then everyone has to run their own local market logic resolver to determine actual liquidity. If not, then true market liquidity is now opaque.
If anyone else is faster than you, then true market liquidity is already opaque. Indeed, this is one of the criticisms of HFT - that the liquidity they present is "fake", "ghost", "phantom" liquidity, because it will be pulled at the slightest provocation.
Existing mechanisms which obscure liquidity are iceberg orders, market maker protection [1] [2] [3], and various kinds of non-displayed orders [4] [5] which i confess i am not very familiar with.
I think this illustrates that exchanges are sometimes willing to sacrifice a little transparency in order to encourage more liquidity provision. This is a fundamental axis of market design. At one end are classic lit exchanges, at the other end is OTC dealing, and there are all sorts of shades of grey in between. Which is most appropriate will depend on the specific balance of participants and activity in the market in question.
I have an underdeveloped idea that what we really need is limit order types with built-in hedging. "Bid to buy 100 gizmos at 30c each, and for every five gizmos bought, immediately offer to sell 1 widget at $1.20; cancel this order if the best offer for widgets moves below that price" sort of thing. Basically, you're moving the simple reasoning that has to be executed at low latency from the market maker's FPGA to the exchange's matching engine.
Sometimes, you can do this by putting orders in spreads, but only where a spread exists (or can be defined) for the two legs you care about, in the right ratio.
You might also want to do more complicated things, like pulling an order in one product if another product moves a lot, because you think that presages a move in the product you're quoting.
The idea would be, firstly, to make it much easier to make markets without having to invest in low-latency infrastructure, broadening the base of participants who can do it, and secondly, to reduce the negative impact of speed-blunting interventions like continuous batch auctions or speed bumps.