by Lisa Taikitsadaporn and Martin Koopman | Q1 2004 |
What is STP in fixed income?
Using the web interface provided by your fixed income ATS is not STP. Even if it can communicate electronically with your systems, it is only one small piece of the puzzle. An ATS’s web interface may provide your traders with the means to execute a trade with the broker/dealer and have that confirmed trade information pop up on the web GUI, but that’s not STP. Why not? Because your traders (or their support staff) will still have to manually re-key that confirmed trade information into their trading application/blotter system so that post-trade processing can occur. However, with a little bit of integration work, that manual re-keying can be eliminated. How? Have the ATS send the trade information electronically into your system so the traders can view it on their application/blotter. That transfer of trade information from the ATS into your system can be done using FIX. Unless there is an error in the trade information, your post-trade workflow can begin with your traders sending the block allocations to the broker dealer electronically using FIX. The broker dealer in turn can confirm the block using FIX. This is the start of fixed income STP, albeit a small step. By removing the need to re-enter trade data, FIX is a tool that aids in any firm’s STP initiative. The front-office automation provided by FIX reduces errors in the trade information needed for middle and back-office operations.
What are the challenges of implementing FIX for fixed income?
Scoping the project
The decision of ‘where to start’ is the first challenge you are likely to face. Which aspect of the trade life cycle you decide to FIX-enable first, as your ‘getting to know FIX project’, will depend on what your firm is ready to do. In the past one to two years, we’ve seen two main approaches: go after the area of trading operations where there is the most‘pain’, or experiment with a small step that does not cause too much disruption. Which approach you take will depend largely on how you’ve sold the idea to your traders and your firm’s tolerance to change. Some of the first implementations of FIX in the fixed income space started with receiving FIX Execution Report messages as trade confirmations from ATSs. By taking in FIX Execution Report messages you’ve enabled the possibility for two things to happen: 1) eliminate the need for traders to re-key trade confirmations into your trading system, or 2) add the ability to match your counterparty’s view of the trade with your trader’s view of the trade. Whether you gain one, or both, of these results depends on your internal architecture and trading system capabilities. This is a manageable first step to get your feet wet with FIX. The next logical step could be streamlining block allocation and confirmation or sending FIX orders. Eliminating the need to use means such as fax, phone or email to confirm trades and communicate allocations eliminates re-keying errors on both the buy and sell sides. The main objective is to take incremental steps that show results as to what FIX can do to lead you to reduce trade errors and breaks in your downstream operations.
Security identification
As you continue along this journey, other challenges will surface, some of which you may have anticipated, others you may not have thought of. One of the first issues you are most likely to run into is security identification – a big challenge with fixed income trading in general. Liquid securities, such as Treasuries and agencies, are easily identified through ‘live’ CUSIPs. The challenge lies with primary issues for securities such as TBAs, CPs and corporates that may not have ‘live’ CUSIPs even when the issue is initially being traded. How do you know that you and your counterparty are talking about the same security if there is no ‘live’ CUSIP? You’ll need several identifying parameters in order to help you ‘match’. Possible data includes the issuer’s six-digit CUSIP that could be used as a preliminary identifier, descriptive information on the security, such as maturity date, coupon rate, issuer’s name, security type, etc. Even then, this isn’t perfect. Your traders are likely to have to be involved to confirm that it is the correct security when your system is not able to ascertain an exact ‘match’. Security identification, especially for primary issues, in fixed income is a topic unto itself, but it will affect your electronic trading efforts today. This is a problem that will require co-ordinated industry efforts to address.
Real-time trading environment
Further along this road, you will notice that you are increasingly dealing with a real-time trading environment. A real-time trading environment requires you to think differently about how your architecture is designed in order to deliver real-time trade information to your traders. It means a real-time messaging environment, a real-time trading blotter that can handle state management of orders and allocations, an infrastructure that can support this, software solutions with more business rules and intelligence ‘built in’, and additional levels of systems and trading operations support. However, you need not be alone on your journey. Real-time trading environments have been a reality on the equity side for many years now. It is an opportunity to learn from your colleagues on the equity side of the business and to talk seriously about leveraging some of the common infrastructure, a cost containment move, that can be shared across your firm.