Wednesday, 15 October 2014
Project Neptune, MTFs, SEFs, the central limit order book for corporate bonds and the loch ness monster
As you will no doubt have read, there is another attempt to invigorate the corporate bond market under the title “Project Neptune”. There are good articles on efinancial news and on Bloomberg
Now, this is of course interesting to anyone involved in Fixed Income trading or portfolio management. “Project Neptune is designed to allow traders to advertise bonds without revealing buyers and sellers, according to [Sassan] Danesh.” (from Bloomberg).
So, this is working it’s way through the world of the FIX Trading Community – a sub-committee “Call for Participation” was sent out on 7th October to “work on a recommended best practises document for the distribution of Axe, Inventory and Runs from the sell-side to the buy-side”.
Now, this topic – the lack of liquidity in the Fixed Income markets is something on which I have written before – I suggest a quick look at:
So, I am in favour of parts of the value proposition of Project Neptune. Specifically, if you have ever tried to build FIX connections to the main players in the Fixed Income eTrading space you pretty soon see that they all have heavily customised/bastardised/ugly/not-really-FIX-at-all workflows. So if something approaching a “this is how to do FIX for Fixed Income” document is created then that will be very helpful. But does anyone think that the main firms in this space that sit between the buy-side and the sell-side will then actually conform to the specification?
An example from the world of FX. There is a very large market participant firm that uses FIX execution reports instead of orders. Just a bizarre workflow. They know that it’s bizarre and many folks have suggested a rethink but they have not done so in the several years that workflow has been in-place.
The Fixed Income world has some similar ugliness. So what will make the intermediary firms suddenly see the light and deliver something more usable? Did the cash bond best practises document have any substantial impact?
My view is that many participants in the institutional Fixed Income asset management world have a structural blindness to the trading process. The traders on the desk know that they are facing a highly illiquid market but some portfolio management staff believe that their ability to pick winners will outweigh any drag on performance from being unable to duck in and out of a position. I’ve been present when there has been a blamestorming session where portfolio management blame trading for not executing and trading blame portfolio management for trying to offload a large position in a highly illiquid name where there is thin or zero secondary market support from the bookrunners. Of course this is not always the case and of course many market participants have a more integrated approach to portfolio management and trading rather than “throwing a problem over the fence for the dealers to resolve”.
There’s a very good report on the AFME website with this quote “there are many hundreds of thousands of fixed income bonds” – page 22.
That’s the key issue here. So many bonds, so little liquidity. Compare the number of bonds to the number of equities and you see one reason for so little liquidity.
On a further note, since from an economic perspective a reason for fixed income investment as an asset class is for fixed term investment, perhaps there needs to be a greater re-think of whether the desire to have “liquidity on demand” is consistent with the desire for fixed term investment. One model that I have considered and would love to spend more time on is the idea of pooling debt instrument into a closed open-ended investment company. So that there is a periodic auction to match up buyers and sellers but on an infrequent basis. I’m pretty sure that a hybrid structure could be created to do this. Just an idea…
So, why does this post include the loch ness monster in the title? Well, just like on-demand liquidity for corporate bonds, many have been looking but no-one has found it…