LMAX conference

So I’ve signed myself for the LMAX UCL algo trading conference – see you there !  I’m looking forward to Martin Thompson’s talk, and hoping I can bend his ear on a few server engineering questions over drinks at the end of the afternoon. I’m also keen to know more about the LMAX market design. In the infoq presentation I linked earlier there are some intriguing comments about ensuring low and stable latency for market makers. This makes me wonder what the terms are for market maker participation on the LMAX order books. Do market makers have a different API than market takers ? Do makers get processing priority for placing, pulling and amending orders ? Can maker orders cross with other maker orders, or only market taker orders ?

CLOB stifles innovation ?

Thanks to Matt for the heads up on this article. In pt III Tusar asserts that Trade-At “essentially creates the CLOB [consolidated limit order book]–the thing that everyone agrees would stifle innovation.”  Now my knowledge of algo equity execution is certainly not state of the art. But it’s news to me that there’s a body of opinion that thinks CLOBs stifle innovation. Certainly the advantage of CLOBs is that they aggregate liquidity for a security, and provide a public, visible live price during trading, and a record of open and close prices too. They also tend to come with clearing arrangements. This is exactly the arrangement that the industry has been inching towards for the OTC stuff that was so problematic in 2008, with the introduction of swaps clearing, which should improve transparency.

I suspect that Tusar is talking his own book. Plus ca change !  Of cause major broker dealers like Goldman want “innovation” in the form of multiple dark pools and execution venues, including their own. That leads to fragmented liquidity, which causes opacity and hinders price discovery. Which is good for Goldman, and bad for clients who will need expensive Goldman execution services.

Update: there’s an enlightening discussion of Trade-At here.

Bloomberg Open Symbology

I’ve posted in the past about the irrationality of the naming scheme for Bloomberg ticker symbols. Well, Bloomberg have taken a step in the right direction and launched a site that allows developers to look up ticker symbols. If you’re looking for Rates products you’ll find US Treasuries under the Government top level heading. No EGBs or Gilts yet. And you’ll find IRSs under Currencies, which seems odd to me as a rates person.

F# for single dealer platforms

Matt shares his thoughts on F# for SDP implementation here. I don’t know as much about F# as he does, but I have dabbled with VS2010 and played with OCAML on Ubuntu at home. I’m sure the stateless functional approach will be a big help in structuring asynchrony and concurrency in server processes. So I agree with the general thrust of his argument here.

I would take issue with one of Matt’s statements: “If you think about an SDP, its primarily an integration build”. I have heard the same view espoused by managers who think an SDP build is just a trivial matter of hooking up some vendor servers like Caplin’s Liberator to internal middleware like the TIB, and hey presto, quotes and executions will flow. It’s nowhere near that simple. I prefer to say that building an SDP is like building an ECN. Think of it as building you’re own Bloomberg or TradeWeb.

Bloomberg and TradeWeb cover prices

I got an email query on cover prices for RFQs after my last post, so I went back to some old analysis of RFQs I did in 2006 to check. My code was getting the cover price from ION MarketView’s trading chain for the RFQs that traded with us on Bloomberg and TradeWeb. If the client traded away, with another dealer, or rejected, we would see a cover price of zero. This asymmetry allows a dealer to calculate excess winning margins for RFQs won, but not to see how far off the best price the dealer is for RFQs that trade away.

The excess winning margin is the difference between a winning price and the cover price. If the gap is too great, then maybe the dealer is suffering from a form of the winners curse. The obvious response is to make pricing less aggressive. But the fact that losing dealers in an RFQ don’t see the winning price deters that. In the face of that asymmetry the right solution is probably to have real time feedback between hit ratios and pricing aggression…

Cover price & RFM

Neat doc here from TradeWeb on protocols for CDS execution. From it you can imply the definition of “cover price”: the next best price that didn’t execute. As you can see in the doc, or in a TradeWeb or Bloomberg terminal, a client can see competitive quotes from up to 5 dealers. But while an RFQ is in flight, the dealers can’t see each others quotes. When the RFQ ends with an execution, as opposed to a client rejection, then the winning dealer gets to see the cover price – the price they beat. But the losing dealers don’t get to see the winning price, so there’s a fundamental asymmetry there.

So what are the reasons for that asymmetry ?  That’s an interesting question. I’m guessing that it’s motivated by restricting the amount of information that dealers have about each others pricing. Dealers are paranoid about other dealers figuring out their pricing. Another motivation is to keep the dealer pricing keen. If dealers could see each others prices, then they would slack off on aggressive prices, making them only just good enough to win a trade. In the face of those two powerful motivations, I do wonder why ECNs show the cover price to the winning dealer at all.

The RFM model outlined in the TradeWeb doc is interesting too. The RFQ and RFS models operated by Bloomberg and TradeWeb for fixed income trading require the client to declare whether they’re buying or selling up front. RFM is a break with that. If it were applied to the rates markets I wonder whether it would lead to keener pricing or not ?

Goodbye Bloomberg

I’ve written several times before about Bloomberg, and why they’re such a blot on the etrading landscape. Now we’re in a recession and Bloomberg’s clients all want to cut back on those grand a month terminals. More and more I hear folk say “why pay a grand a month for an email account ?”

Bloomberg’s difficulties should be opportunities for those involved in proprietary single dealer channels. The advantages of single dealer channels for dealers are obvious. And they can be attractive to clients too – they’re free to clients, and can carry innovative offerings that the multi dealer ECNs aren’t nimble enough for. But what they lack, by their very nature, is the direct real time price competition of the multi dealer RFQ.

Could there be some form of mitigation for this handicap ?  Two avenues seem possible. Firstly the moribund LiquidityHub consortium. The tech infrastructure is in place for composite prices for a whole range of rate products. The consortium could agree to allow members to republish LQH composite price on their single dealer channels. Secondly, vendor driven aggregation. Single dealer channels are now common enough that vendors have sprung up to service the sector: Caplin & Lightstreamer for instance. The vendors themselves could perform the price aggregation in portals. Dealers could reuse vendor supplied aggregate or composite prices to make single dealer channel tickets MiFID compliant for the buy side by enriching them with the portal prices.

The Eurex Flipper

Good write up on Paul Rotter – the Eurex Flipper – here. It gives me hope to think that one expert human trader can repeatedly find and exploit inefficiencies in such a fast moving liquid order driven market as Eurex.

This paper is a very accessible treatment of finding the optimal price point for limit order submission.

Building with Caplin

So, let’s imagine you’re building a brand new single dealer channel for your bank with Caplin Trader from Caplin Systems. You picked Caplin because it’s the clear leader in the streaming comet server space, and you want to deliver your etrading app into the browser so it’s zero install on the client desktop. There are other vendors with viable offerings that compete with Caplin’s Liberator as comet servers – Lightstreamer is the clear number two. There are interesting new vendors entering the sector like Kaazing, and there are open source products too. But none of them is as mature or as widely deployed in live production etrading apps as Caplin Liberator.

A server to stream live ticking prices to a browser is just one part of the puzzle of building a web 2.0 etrading app. You need to build the GUI in the browser, and you need an execution system that will handle RFQ/RFS. Unlike the other vendors Caplin provide this in the shape of the Caplin Trader GUI and the Trading Data Source. The GUI is based on the JavaScript widget kit from SoCentric, and the Trading Data Source provides configurable state machines that keep GUI and server side state in lock step during the lifetime of an RFQ ticket.

Hardware accelerated messaging

Marc asked for hardware accelerated messaging ideas. Here’s one: how about using SCRAMNet to eliminate IP networking and achieve sub microsecond latency ?  You’d need all of your exchange connectivity, pricing and order management processes on boxes in the same machine room linked by a SCRAM fibre loop. But it would go mighty quick. SCRAM pricing is surprisingly reasonable too…