3 ms·

Why not just put it on a sliding scale? One dollar per nanosecond or something. I'm not sure if I'm joking or not.

nostrademons 13y ago
That actually would be really interesting, because you're essentially creating an auction on the value of information. It does you no good to get the news a nanosecond after your competitor, because in these markets (with large amounts of leverage available) they've already bought up all the affected securities and arbitraged out the difference. So it behooves you to bid up to your expected profit from having that information, in an attempt to get the information first. The transaction price gives you the dollar value of the information to the highest bidder.
- sliverstorm 13y ago
  Of course, if your systems can execute trades a nanosecond faster than your competitor, you can afford to get the news a nanosecond after them.
  - nostrademons 13y ago
    Right, which is why major hedge funds heavily optimize their code, use C instead of Java to avoid GC delays, and colocate their boxes on the exchange to minimize speed-of-light delays. We already know the premium for executing trades faster via solid IT: it's a lot.
djcapelis 13y ago
You'll notice the contract specifies a +/- 500ms slack time which would be a limiting factor in providing the data to the clients on that specific of a timing bound. Realtime constraints that are that specific can be really hard to do in bulk. You could easily group things into 500ms classes though. But 500ms is kind of an eternity in these types of things and you'll never really have someone thinking that they have a system fast enough to beat someone who started 500ms earlier.
- r00fus 13y ago
  500ms is a long time for an HFT algorithm, from what I understand. If my algo takes the Reuters feed as input (which I imagine to be a good leading indicator for trading) and I have a 500ms lead, it could be the one that bought the stock right before yours did (and enough shares to drive up the price adequately to slurp up all the margin).

That actually would be really interesting, because you're essentially creating an auction on the value of information. It does you no good to get the news a nanosecond after your competitor, because in these markets (with large amounts of leverage available) they've already bought up all the affected securities and arbitraged out the difference. So it behooves you to bid up to your expected profit from having that information, in an attempt to get the information first. The transaction price gives you the dollar value of the information to the highest bidder.

sliverstorm 13y ago
Of course, if your systems can execute trades a nanosecond faster than your competitor, you can afford to get the news a nanosecond after them.
- nostrademons 13y ago
  Right, which is why major hedge funds heavily optimize their code, use C instead of Java to avoid GC delays, and colocate their boxes on the exchange to minimize speed-of-light delays. We already know the premium for executing trades faster via solid IT: it's a lot.

djcapelis 13y ago

You'll notice the contract specifies a +/- 500ms slack time which would be a limiting factor in providing the data to the clients on that specific of a timing bound. Realtime constraints that are that specific can be really hard to do in bulk. You could easily group things into 500ms classes though. But 500ms is kind of an eternity in these types of things and you'll never really have someone thinking that they have a system fast enough to beat someone who started 500ms earlier.

r00fus 13y ago
500ms is a long time for an HFT algorithm, from what I understand. If my algo takes the Reuters feed as input (which I imagine to be a good leading indicator for trading) and I have a 500ms lead, it could be the one that bought the stock right before yours did (and enough shares to drive up the price adequately to slurp up all the margin).