Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Jump Trading, Virtu and the 'hidden optical fibre cable' under an Ohio field

ft.com

Post reply on HN
Print view View original

21–30 of 77 posts

Re: Jump Trading, Virtu and the 'hidden optical fibre cable' under an Ohio field

#21

Post by ssivark »

usefulcat wrote: post #19
biomcgary wrote: post #12

Other than seemingly perverse incentives, is there a good reason not to quantize trading time?

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 o…

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

Re: Jump Trading, Virtu and the 'hidden optical fibre cable' under an Ohio field

#22

Post by usefulcat »

mikewarot wrote: post #13
biomcgary wrote: post #12

Other than seemingly perverse incentives, is there a good reason not to quantize trading time?

I've argued in the past that we should have batch settlements every 30 seconds, instead of in real time. We don't really need microsecond based skimming/front running.

If there are multiple orders at the same price on the same side, how should we determine which ones are filled first?

Or put another way, how should we determine which orders are least likely to get filled?

Re: Jump Trading, Virtu and the 'hidden optical fibre cable' under an Ohio field

#23

Post by infecto »

mikewarot wrote: post #13
biomcgary wrote: post #12

Other than seemingly perverse incentives, is there a good reason not to quantize trading time?

I've argued in the past that we should have batch settlements every 30 seconds, instead of in real time. We don't really need microsecond based skimming/front running.

Why not 1 minute then?

You have ignored the whole issue of how are you then ordering those contracts in 30second batches?

Re: Jump Trading, Virtu and the 'hidden optical fibre cable' under an Ohio field

#24

Post by infecto »

biomcgary wrote: post #12

Other than seemingly perverse incentives, is there a good reason not to quantize trading time?

There are cases to be made that you get tighter spreads.

The larger the time interval the larger the risk on pricing. If I am selling and it’s a large time to trade I am going to probably want to sell it for a higher price. The same goes on the bid.

Re: Jump Trading, Virtu and the 'hidden optical fibre cable' under an Ohio field

#25

Post by hcks »

usefulcat wrote: post #22
mikewarot wrote: post #13

Earlier quoted context omitted.

I've argued in the past that we should have batch settlements every 30 seconds, instead of in real time. We don't really need microsecond based skimming/front running.

If there are multiple orders at the same price on the same side, how should we determine which ones are filled first? Or put another way, how should we determine which orders are least likely to get filled?

Well either volume weighted or randomised then

Re: Jump Trading, Virtu and the 'hidden optical fibre cable' under an Ohio field

#27

Post by anonymoushn »

biomcgary wrote: post #12

Other than seemingly perverse incentives, is there a good reason not to quantize trading time?

The non-terrible version of this proposal is called Frequent Batch Auctions. I've read the paper and it seems like a decent idea to me.

I have heard that some real-life venues have implemented the terrible version of this proposal instead though.

Re: Jump Trading, Virtu and the 'hidden optical fibre cable' under an Ohio field

#28

Post by anonymoushn »

harry8 wrote: post #16
mikewarot wrote: post #13

Earlier quoted context omitted.

I've argued in the past that we should have batch settlements every 30 seconds, instead of in real time. We don't really need microsecond based skimming/front running.

so now the race is to get the order in (or out) @ 29.999999985 seconds or 15nS before the batch deadline. Interesting twist on the game. Unlikely to change who wins it, could it be worse for retail punters? We need to kill "front running" as a criticism of low-latency algo trding with fire. It's garbage. Front running is highly illegal and is where a broker knows a client is going to do a big trade due to inside info…

Batching can greatly lower the returns to speed, which would be sufficient to get participants to invest less in speed. It doesn't need to reduce the returns to speed to 0, and indeed reducing the returns to speed to 0 is sort of an incoherent idea to begin with.

Re: Jump Trading, Virtu and the 'hidden optical fibre cable' under an Ohio field

#29

Post by mhmmmmmm »

Loughla wrote: post #15
mikewarot wrote: post #13

Earlier quoted context omitted.

I've argued in the past that we should have batch settlements every 30 seconds, instead of in real time. We don't really need microsecond based skimming/front running.

I've read the arguments that the microsecond trading serves a purpose that benefits all of us, but I fail to see how, even with the explanations. I'm with you. Every 30 seconds. Cap the power of connection speed in trading. Trading should be based on the value of the item being traded, not on how short the fiber run is.

CLOB's force market participants to compete on pricing (which is only indirectly related to latency, since you can quote tighter if you know your orders won't get picked off by other, faster, traders) Taiwan used to have Batching style auction and it ultimately led to worse prices: https://focus.world-exchanges.org/articles/citadel-trading-a... > Our analysis of the TWSE’s transition clearly demonstrates that continuous trading results in better liquidity provision, lower bid-ask spreads, more stable prices and enhanced price discovery, as well as higher trading volumes.
Post reply on HN