Max on broker APIs

Max Dama’s posted a couple of times recently on broker APIs. In his most recent post he drops an intriguing aside when commenting on IB, Wex and Lime: “I haven’t used each of the three’s FIX APIs”

Which prompts the question: why not ?  Why code to a proprietary API rather than an industry standard protocol. I’ve had less than happy experiences with FIX for Fixed Income myself, so my guess at the reasons would be…

• Convenience: going straight to a Java or .Net API is quicker than selecting a FIX implementation and/or protocol implementation like quickfix.org, and then doing an integration.
• Statefullness: AFAIK FIX doesn’t address state like “order submitted”, “order on the book”, “order cancelled” etc. A well sorted API with a good callback interface makes this kind of thing earlier. FIX is just a protocol, leaving you to build this stuff yourself.
• Speed: less infrastructure means less latency.

I wonder whether FIX is more popular with sell side firms offering connectivity than the buy side. It seems from Max’s posts that he’s doing connectivity work for hedge funds building automated trading systems using the broker APIs he mentions. I’d be interested to know more about why those firms choose to use the proprietary APIs…

DynaTracing Caplin Trader

DynaTrace sounds pretty cool – gotta try running our Caplin Trader based GUI through it…

Max Slippage

Excellent article on execution slippage from Max Dama here. He’s writing from a prop trading perspective. Nice diagrams and charts in the piece as Max breaks slippage down into two components: liquidity impact and alpha loss. If we look at the problem from a Euro rates market making perspective we would consider slippage for hedge order execution on Eurex. We’d still have the liqudity impact component Max describes. Instead of alpha loss we’d have market risk for the time we carry an unhedged position. Of course, it’s a matter of market maker discretion how much risk to carry and for how long…