Colin Lambert: It’s often said that fixed income markets can simply leverage the technology developed in FX, is it as simple as that?

Steve Toland: There are quite a few similarities with FX, the APIs do the same thing in delivering market data and orders, and a lot of the post-trade work is the same, but the level of fragmentation in fixed income is much greater, because not only do you have venue fragmentation, you also have asset fragmentation.

The range of instruments traded is very broad, for example, corporate bonds, sovereigns, coupons, covered bonds, swaps, repos, interest rate futures, and from a technology perspective you find yourself dealing with people at the banks across all of these asset classes – and they all want slightly different things because the market nuances are different. So there is this spread across these assets at the bank level, but then you have further fragmentation at the platform level, where they are all offering the same wide range of products.

There are more than 130 venues for trading cash bonds alone, add in the swaps platforms and those servicing other markets, there could easily be 200+ e-venues. 

Of course not all players are trading on all of these, but as an example, in FX there are maybe 90 venues but the main concentration is around a smaller number – in fixed income there is the need to be specialised because of the dedicated nature of the venues, which means a long tail, and that exacerbates the fragmentation.

CL: Is there a standardised workflow across these platforms?

ST: No. There are different workflows for different asset classes. The RFQ protocol is more prevalent in fixed income than FX, where just about everyone has access to a streaming price. In fixed income customers are still mainly trading RFQ, because this is the mechanism used on the main platforms – and of course there are different RFQs, different APIs for each product. 

As an example there are 19 different APIs for Tradeweb alone. Then there are different protocols across the three main geographical regions, so while the RFQ process is still broadly the same, there are subtleties that make it burdensome to code to an API. Ultimately there are something like 132 different combinations of RFQ models that need supporting, so the devil is in the detail and just adds to the complexity.

CL: Is it likely to remain this way? What, if anything, can change things?

ST: I don’t think fragmentation is going to go away, but there are solutions that can help ease the burden. The driver of change is regulation. All of these instruments are covered by MiFID II so need an audit trail for all orders and to prove best execution – this means, pretty much, the death of the phone in fixed income markets. 

Once the market embraces full automation it will at least start to understand the main issues to be solved. Some firms were thinking of using one provider, which reduces the complexity and the burden, but they then have to ask themselves are they doing the best job for the customer? 

On the customer side it is just as big a challenge because they still have very manual processes, there is little automation at many buy side firms in fixed income. They are, though, now starting to look hard at automation both for market data connectivity but also for how they trade – we increasingly see asset managers start to embrace the changed market structure.

That’s not to say it will be easy for them. Its not quite the same in FX when it comes to the buy side needing things like co-location and low latency, but in some fixed income products – if they are trading Treasuries or interest rate futures for example, they do require those services, it’s vital for them. The problem in fixed income for these firms is that while you have some people trading these products in a very quick and efficient market environment, the person sitting next to them is trading corporate bonds, in which they don’t need a high performance system because the product is lightly traded and probably only updates a few times a day.

CL: What’s the solution?

ST: Recognising the different needs can save valuable infrastructure development dollars by building a lot of the products that are lightly traded in a slower environment, on the cloud. They don’t need co-location, don’t need to be fast, there is no need to be latency sensitive – it’s a different engineering problem, do we need 36,000 updates on something that trades a couple of times a day? It just clogs up the pipes.

So the need is to prioritise higher volume market data where performance is really important, but recognise that the broader market doesn’t need to be as quick. It is about understanding that fixed income is really a lot of different markets under one banner.

CL: It looks like a data management issue as well…

ST: That’s a big part of it – there has been an explosion in the amount of market data needing to be processed. Throw in the post-trade regulatory reporting requirements and you have a very high demand for efficient data processing.

CL: Isn’t this what AI is for?

ST: AI and machine learning are still at an early stage but there is no doubt the vast datasets around will lend themselves to these processes. For now though firms face the challenge of not only handling the abundance of data but also using it as part of their decision making process. On one hand they don’t have the technology capability to handle the volumes, and on the other there are still problems in developing meaningful interpretations of the data because there is so much ‘noise’.

CL: So what is TransFICC’s value proposition when it comes to these challenges?

ST: We translate the APIs from all of those venues into a single API, this enables you to connect and trade on multiple fixed income trading venues. We translate the various trading venue API’s into the format used by TransFICC, to allow for a single, easy, integration. This also means that connecting to a new venue is just a simple configuration change. 

We also manage changes to APIs, when trading venues perform an upgrade. It’s a hosted service so hardware and venue connectivity issues are taken care of. The technology has been developed to be scalable and fast, so clients can keep pace with price updates and not get beaten up by high frequency traders.

Essentially what we are doing is building template code, which we give clients to point at the venue and get the data.

On the post-trade side, we have normalised price and order timestamps to the microsecond level to help provide an audit trail for best execution.

CL: So it’s about easing the pain of fragmentation you mentioned earlier?

ST: Absolutely. There is a question of whether the fragmentation continues at the current pace, but either way it is here to stay at some level and so we have established ourselves as an efficiency player. 

There is massive pressure to cut costs at the major dealers especially, for example there are the Basel II requirements where they can’t hold a lot of bonds on their books. That changes the structure of the market – it leads to more all-to-all trading venues in fixed income, which are being established. The problem is, these venues are struggling with poor liquidity – we think we can help them.

CL: How?

ST:  We provide easy access to these liquidity pools, meaning traders can have a broader liquidity picture and can thus trade on more venues – including those new players that are struggling. 

We are trying to solve the back end messaging connectivity problem by building a hosted utility service, which we think is a sensible business model. This means banks can then focus precious development resources on getting the pricing right while we do the connectivity work behind the scenes. Building it themselves doesn’t really make sense.  

We start by solving this issue but further down the road we can leverage this work to solve the buy side’s specific issues – for instance, Bloomberg and Tradeweb have different APIs for the buy side. This is really complicated and painful work for a bank or asset manager but to us it is just a nuance and it’s our responsibility to deliver a pain free solution. 

CL: This does sound complex, but it does also sound familiar to someone from the FX markets, how much have you leveraged from the FX space?

ST: A lot of out technology is utility and is open source, which was how it was done at LMAX Exchange in FX, which I consider to be the best. What we have done is build in specific nuances from the fixed income world.

Fixed income as an asset class is anything from two-to-10 years behind FX in terms of the market structure but it is catching up quickly, helped it has to be said by a lot of people moving in from FX. These people see they can buy and utilise components from FX and so I think in four years or so, fixed income will look similar in terms of the tech infrastructure to FX. 

Again, I would say that a chunk of it is likely to be cloud based because the cost savings that are available are massive.

CL: What are the nuances you need to build out for clients trading in those slower, less active markets you mention?

ST: We have built a GUI so clients can see Market data order books in real time and also see RFQ workflows. It is primarily designed as a test tool for developers and they can place orders on CLOB venues from the GUI as long as all required fields are filled. 

Banks can also receive RFQ’s from customers on the system. The difficultly here is that RFQs for different asset classes or venues are similar but differ in subtle ways. Our value add is to normalise these different workflows and ease integration for the bank or asset manager.

We also download all available instruments from a venue each time we log on, enabling the selection of required instruments and how they want to view market data, for example Full depth or Top of Book. Coding to each venue individually can take eight weeks or more in some institutions, we enable them to on-board new venues in minutes.

We have also built a performance monitoring tool so banks don’t need to built it themselves to meet the demands of the regulators. As banks build Algorithmic Order Execution functionality they need to be able to stress test their applications. We are also mocking up venue test environments to make it easier for banks to build out their own testing tools.

CL: You mentioned earlier the efficiency play – is this the classic, Fintech doing it cheaper, model?

ST: The incumbent in this space is ION Trading, which has about 70% of the sell side banks and by building out this connectivity, we have set ourselves up to compete in this space – it’s kind of a David versus Goliath!

We think we can provide the service cheaper and more efficiently for the big banks, and this could be important at a time of cost cutting by these institutions. The cost of operating in FI markets is significant and needs trimming, so yes, we see ourselves very much as helping deliver that efficiency and cost effectiveness.

We are focusing on the sell side banks and major asset managers because they are confronting this problem head on, but further down the line there will be opportunities with more buy side firms. A lot of the work we are doing now will be able to be replicated but of course there will be small bespoke pieces of work that need to be done. As I said earlier, this is nothing if not a complex space. 

Colin Lambert

Share This

Share on facebook
Facebook
Share on google
Google+
Share on twitter
Twitter
Share on linkedin
LinkedIn
Share on reddit
Reddit

Related Posts in