Latency sensitive algorithmic trading strategies

Imported from previous forum

Hi,

We are looking for algorithmic trading strategies which depends on low latency to perform well. Obviously all strategies depend more or less on the latency but we are looking for the most dependent ones.

On a related topic is there a finite (and preferably small :wink: subset of operations that are used as a common basis for all or most of the existing strategies?
For instance filters like moving vwap, thresholds, variance or other real time indicators.

We already made some benchmarks for an “hidden” strategy but we would like to investigate other ones too.

Marc

Marc,

algorithmic trading strategies requiring low latency

Any type of market making including option market making
statistical arbitrage
*pairs, baskets (list trading)
*various index vs. underlying securities
Complex Event Processing
etc.

finite/set of operations fundamental to algo strategies (e.g. filters like moving vwap, thresholds, variance or other real time indicators)

The most elemental operation in any algo strategy is the NOT AND. With a bucket of NOT AND gates you can construct any logic to trade. At the very core of some algo trading you can find programmable logic devices (FPGAs and ASICs, etc) These are dedicated and have no operating system overhead, etc.

At a higher level you can find all sorts of technical trading libraries in open source code - e.g. see: http://ta-lib.org/hdr_dw.html
For more leading edge quantitative strategies see groups like: http://sqa-us.org

Need to remember that this forum and the FIX organization are involved in standards work used to trade algos, not in the actual construction of the algos. Our main concern here is to provide/support industry standard connectivity between algo users (mostly buy-side, hedge funds, etc) and algo providers (sell-side, quant shops, exchanges, ATS, ECN’s, etc.) At FIX we take the view the algo itself (and the dedicated execution infrastructure behind it) is a black box. All we are interested in is exposing the parameters that drive in, plus suggesting screen layouts (in XML) to the trader’s systems to facilitate rendering & entering those parameters.

It’s like a firecracker, with FIX only being in the fuse business. A trader lights the fuse and that message goes down the wire, however the “bang” goes off at the other end.

Rick