Within the last few years, there has been a clear trend towards greater ‘electronification’ and more automated trading in the Fixed Income markets. Some of the reasons for this:
- On the buy side, traders and asset managers increasingly looking for new ways to generate alpha as part of their strategy to enhance performance and in doing so, they are seeking greater access to liquidity, improved price discovery and subsequently more automation and more low-touch electronic trading, to streamline their workflow
- Sell-side banks are under increased competitive pressure from non-bank liquidity providers, some of whom are able to provide streaming prices directly to their clients, which puts banks under immense pressure to respond
- From a regulatory perspective, there is a constantly growing demand for more timely, accurate and comprehensive data around quotes, orders and trades. There is also the need for firms to provide – and prove – best execution
However, along with this trend towards greater automation, there are also a number of challenges.
First of all, Fixed Income liquidity is highly fragmented, much more so than equities or exchange-traded derivatives. Also, there is no centralized venue for bond issuance and secondary trading. There are vastly more instruments, some of which only trade sporadically. And there is little standardization in pricing mechanisms, which can lead to a lack of reliable market data for anything other than the most liquid Treasuries.
CLOB versus RFQ
“On-the-run” Treasuries, i.e. the most recently issued US Treasury bonds or notes, are generally traded electronically via a central limit order book (CLOB), similar to equities. However, this type of trading is the exception rather than the rule in Fixed Income markets. Far more common is the request-for-quote (RFQ) model, which can either be fully electronic, voice-based or executed via a range of instant messaging platforms.
The problem with the RFQ model of course, aside from a higher degree of information leakage, is that it does not deliver the continuous firm prices that asset managers need to develop low-touch algorithmic trading strategies.
Competing with ELPs
In recent years, a number of non-bank electronic liquidity providers (ELPs) have picked up the mantle of market-making in the Fixed Income markets. These ELPs tend to fall into two groups:
- High-frequency trading (HFT) firms, who are generally able to provide continuous two-way prices for the more liquid markets such as US Treasuries
- ETF issuers, who can provide streaming prices for the bonds that are included in their ETFs, even if those bonds are illiquid
ELPs however, due to balance sheet constraints, can generally only price trades in smaller sizes. For large-in-scale (LIS) or block trades, clients still rely on the RFQ model, conducting those trades high-touch with bank dealers rather than low-touch algorithmically.
A hybrid approach
So what can banks do to make this whole process be more automated for themselves and their clients? The key is to take a hybrid approach to implement technology, utilize data and establish connectivity to clients, counterparties and markets.
ELPs have gained an advantage by using technology in innovative ways to capture market share, by building auto-quoting and streaming price systems for example and banks are now following in their footsteps. Where banks can gain an advantage is by adopting these models and extending them to enable their clients to trade electronically in larger size or in illiquid instruments. In order to do this, they will need access to data from a variety of sources, ideally in a standardized, normalized format. And direct connectivity is needed to underpin that.
At Vela, we regularly talk about the build-AND-buy approach, because we see the best recipe for success in this evolving market, is for banks to focus their internal development on their “secret sauce” components, such as auto-quoting, auto-hedging, market-making and pricing software, to work with specialist vendors such as Vela for things like market access gateways and data normalization, and to use commodity hardware and software for the more standardized connectivity components.
