[dmeeker]

Generally speaking, folks use the CME futures as a leading indicator, so you may have several different trading strategies that trade against the European markets and just use the CME pricing as one of their inputs. In that case, the most bandwidth-efficient play is to send your market data over once from Chicago, replicate it / make it available to all your trading strategies, and let them do their work locally.

[tomalpha]

That might well be true, but if you've only got a few kbits/second of bandwidth even that might be too much.

[dmeeker]

Sure, you're certainly not sending a full feed -- presumably you've got some algo sitting in Chicago that's looking for interesting / potentially profitable price / vol changes and sending them via the fast path, while the remainder of the feed is going via higher-bandwidth but slower paths.

[pbhjpbhj]

You might as well have your decision logic before the communication path, then you can send like buy/sell orders in code using an agreed decryption pad/dictionary. (Akin to Morse's original conception).

[CamTin]

I'm not an algo trader, but you need the data from both ends of the link to determine if there is a trade you want to make, right? One side or the other is going to need prices from both ends in order to make a trading decision, and preferably both, since each side can only make decisions that are relevant to their side of the link, because needing a round trip negates all of the speed advantage you incurred by developing a top secret HF trading link.

Edit: I meant the HF here to refer to the "high frequency" wavelengths in use in the link (in Ham parlance, HF and shortwave are roughly synonymous), but just realized it also could be "high frequency" as in the frequency of trades.