SpreadServe and TransFICC

August 11, 2017

Earlier in the summer I did a POC integration of SpreadServe with TransFICC. For those unfamiliar, TransFICC has an ex-LMAX founding team, and is a new entrant in the ECN gateway space. Technically their key differentiators are cloud hosting and high performance engineering techniques. For Transficc clients the only thing running on premises is the Java API, which puts the same orthogonalised interface on all the usual fixed income ECNs, and connects to the cloud hosted gateway processes.

It’s been a while since I built anything non trivial in Java, so I was pleasantly surprised by how improved the Java ecosystem has become. Gradle has transformed dependency and package management. And the single threaded async approach popular in the Python and C++ worlds has finally made it to Java with Netty. You can find the code on GitHub here.

 

Recently I’ve been rediscovering the fact that threading is hard. I’ve been extending the SpreadServe Addin to support Tiingo‘s IEX market data feed. Real live ticking market data is usually only found inside investment banks, brokers and big hedge funds as it takes a lot of cash and infrastructure to connect to exchanges directly or to subscribe via Reuters. Even newer internet contenders like xignite are very expensive too. Tiingo’s IEX feed provides live ticking equity top of book data at an unprecedented price point. That is an exciting new development that I want to support in SSAddin. Coding it up has renewed my appreciation of how tricky multithreaded code can be. The SSAddin is implemented in C# packaged as an XLL using ExcelDNA. As with any Excel XLL, the worksheet functions it defines are executed on the main Excel thread. If they are long running, then they’ll block the GUI. So the worksheet functions pass off their work to a background thread. This means that SSAddin can do quandl and tiingo historical data queries without blocking the main Excel thread. Query results are cached, and there’s a set of worksheet functions to pull results out of the cache. So far so good. However, adding subscriptions to Tiingo’s IEX market data adds more complexity. In .net callbacks for web socket events are dispatched on pool threads. Ticking data is pushed back into Excel via RTD. So lots of lock statements are necessary to coordinate access to the queue for passing work from the Excel thread to the background thread, and for coordinating access to subscription management data structures and the RTDServer between the background thread and the pool threads that dispatch the socket callbacks. All good fun which has prompted a few thoughts. Firstly, threading is hard! Secondly, I must get round to learning Rust and understanding the borrow checker. Thirdly, thanks heavens for lock reentrancy in .net!

I’ve been heads down working on SpreadServe recently, so haven’t paid so much attention to the etrading topics that I used to blog about so much. Thanks to an update from mdavey, I’ve been catching up on the excellent, thought provoking content that jgreco has been posting on his plans for a new US Treasury trading venue, organised as a limit order book, with buy and sell side trading on an equal footing. I enjoyed the post on internalization and adverse selection. His points about single dealer platforms are well founded too, though my own experience in rates trading is that it’s difficult to get client flow on to SDPs as by their very nature they can’t offer multi dealer RFQs, which are critical for real money clients that must prove best execution for regulatory reasons. Of course, if the inter dealer prices from BrokerTec, eSpeed and EuroMTS were public in the same way as equity prices from major exchanges are public, then more solutions to the best execution problem would be possible. As jgreco rightly points out, transparency is key.

Now I want to raise a few questions prompted by jgreco’s posts, both pure tech, and market microstructure…

  • Java? Really? I wonder if it’s inspired by LMAX’s Java exchange implementation, their custom collections and Disruptor. I would have expected C++, but then I’m an old school C++er.
  • Is that really the workflow ? That must be a tier 2 or 3 bank. All my experience has been at tier 1 orgs where all pricing and RFQ handling is automated. If a trader quotes a price by voice, it’s a price made by the bank’s own pricing engines. Those engines will be coded in C++, driven by Eurex futures or UST on the runs, and showing ticking prices on the trader desktop. Mind you, obfuscation techniques were used to frustrate step 2: copy and paste quote. After you’ve spent a fortune building a rates etrading infrastructure, you don’t want everyone backing out your curve from your Bloomberg pages.
  • Will DirectMatch have decimal pricing, or are you going to perpetuate that antiquated 1/32nd stuff?
  • How will you handle settlement/credit risk? Will each trade result in two, with counterparties facing off with a clearing house?
  • How do you shift liquidity? When liquidity is concentrated at a single venue, it’s difficult to move. The only case I know of is German Govt Futures moving from Liffe to Eurex. I guess UST liquidity is fragmented across D2D and D2C venues, so it’s not concentrated all in one place, improving DirectMatch’s chances of capturing some of the flow.

Invisible Engines

June 4, 2014

I first read Invisible Engines back in 2007. I still rate it highly now, and I’m pleased to see you can download the whole book as a PDF from the MIT site. It’s topic is the economic and technical aspects of software platforms. Anyone who’s followed the fortunes of IBM, Microsoft, Apple and Sun, and their respective software and hardware platforms should get a lot from this book. I had high expectations when I originally read it, and I wasn’t disappointed. Looking at the download again today, I can see it’s stood the test of time. The book goes well beyond operating systems as platforms and has excellent material on gaming consoles and the three way tension between mobile handsets, their OSes and network operators. It came out in 2006, so pre dates the rise of social software platforms. But the principles it elucidates on multi sided markets and APIs are obviously applicable to Facebook, Google and Twitter. And in the financial sector they apply equally to industry giants like Bloomberg who are a classic multi sided play. Bloomberg as a platform derives revenue from clients paying $1000/month for a terminal. The other sides of its market are dealers contributing quotes and liquidity to Bloomberg as an ECN, and software developers using Bloomberg APIs.

LMAX conference

January 28, 2011

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 ?

September 14, 2010

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

April 12, 2010

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.

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.

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

September 22, 2009

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 ?