Blog

Home Insights Two decades is too old for a post-trade system
Share on:

Two decades is too old for a post-trade system

Blog

Posted in: Institutional Capital Markets
Published: 19/10/2021

GBST’s Head of Capital Markets, Denis Orrock, talks to The Network Forum about legacy post-trade systems, what they have in common with flip phones from 2001, and why implementing a modern, cloud-based middle and back-office platform makes sense, just like using a smart phone in 2021 does.

 

Who remembers the mobile phone they used 20 years ago? It certainly was not a smart phone. It may have been adept at making calls and sending a few over-priced SMS messages, but it was worlds apart from the multi-functional device we have all become accustomed to.  

Smart phones are now an indispensable part of life and the form factors of 20 years ago are a distant memory. Integration with cloud services, AI assistance, and today’s desktop-quality apps make the use of mobile phones a predictable and seamless experience. In business, similar advances are also evident. Computing speeds have multiplied by 100 and the rate of data transmission has increased by 50. The cloud delivered tectonic changes in software delivery with modern business applications now predominately delivered via a web browser. 

In financial services, trading volumes are higher, settlement is faster, and retail investors and institutions all expect fully automated, reliable settlement, and asset servicing. 

So why are so many banks and custodians still using post-trade systems designed 20 or 30 years ago? And why do banks continue to operate regional or asset class-specific post-trade systems – even while trading, risk, and ERP systems have been modernised and consolidated to provide global, firm-wide coverage? 

The answer can be provided in one statement: Continually increasing complexity. 

Continually increasing complexity

Post-trade systems are notoriously complex, connecting to dozens of systems both within and outside of a bank. They are the books of business and records that nobody wants to touch in case they break. They are programmed to deal with grey zones such as market idiosyncrasies, differing settlement regimes, variable messaging standards, data quality issues, and more. Most of these systems were designed when the markets moved to electronic settlement around three decades ago, and while they have been progressively upgraded to cater for market changes, they remain fundamentally on the same technology base.  

Compounding the issue, many banks have separate post-trade systems for equities, fixed income, and derivatives, with even more variation on a regional basis. The outcome is strangled business growth due to high operational and change costs, data ‘fog’, system failure risk, and an inability to take advantage of contemporary technologies such as cloud and AI. 

If using your phone and laptop from 2001 in 2021 does not make sense, then using a legacy back-office platform should not either. Implementing a modern, cloud-optimised back-office system with the flexibility to cater seamlessly and efficiently to growing market needs and changing regulations is an achievable goal for every firm.  

Modern systems should cater to multiple asset classes and operate across numerous markets. Take a system that processes equities and fixed income, for example. Connectivity into different clearing houses and central securities depositaries (CSDs) is required, along with support for each asset class’s messaging and regulatory mandates. Compliance or operational restrictions may require the fixed income and equities operations teams to be separate, or the efficiency provided by a single operations team may be preferable. Regardless, a system should cater for either. An extension into middle-office processing or new business lines should also be possible in the same cloud-based system that scales automatically to meet increased usage demand. Post-trade exceptions across any market or asset class should be managed in the same system, with quality of life, business, and regulatory changes updating in real-time, allowing the organisation’s users to modify processing rules to cater for these changes. 

Change management 

Implementing a new system can be challenging and is frequently underestimated. Risk management is key. Commencing with a small market or problem area to ensure a system can grow into adjacent markets or asset classes is sensible and minimises the deployment risk.  

A market trigger such as a new clearing house, CSD system, or messaging implementation provides the perfect window to consider system change. The correct system configuration from the outset will help avoid costly modifications down the track. This could include a review of the entities transacting and clearing in each market and the definition of how business activity is fed to downstream systems for accounting and analysis. 

Once the need for change is identified, the implementation of the new system can be managed by the vendor so that the organisation can focus on ensuring an optimal system foundation is provided for near-term and future usage. 

Consider how the system will support business growth in areas such as broking, stock lending, agency flow, and principal book trading. Decide whether it will make sense to include affiliate or external custody services in the same system. Although outside the post-trade environment, the firm’s trading system environment is also important to review. If multiple trading systems are used globally, having a stand-alone middle-office allocations engine may ensure continued flexibility in the trading room, while providing a consolidated, organisation-wide view of trade-day activity. 

The proof

Deploying a modern, post-trade system is not unprecedented. GBST’s recent Syn~ implementations have enabled clients from disruptive start-ups to tier-1 global investment banks to seamlessly consolidate middle and back-office operations across multiple geographies, entities, and asset classes for improved ROI. So, is it time to upgrade that flip phone? 

 

Read the full article in The Network Forum Journal (pages 16-17).

© GBST 2021. All rights reserved. Website design by