Front-to-back and back-to-front

After years of de-coupling capital markets infrastructure, the need for closer and more consistent integration for the full trade lifecycle is helping drive greater efficiency, improved control and reduced total cost of ownership.

by | March 23, 2022 | Broadridge Financial Solutions

In 2021, Broadridge Financial Solutions announced their acquisition of Itiviti, representing a major development in the growing trend by software vendors to provide full front, middle and back-office solutions for capital markets firms.

Broadridge’s traditional strength lay in post-trade systems, where it is a global market leader; the firm clears and settles trades in over 70 markets and delivers more than $7 trillion fixed income and equity securities trades per day.

Itiviti developed its market leading position in a very different area of capital markets IT, the provision low latency systems to the front office, managing orders, execution, and connectivity to trading platforms and exchanges.

The Itiviti acquisition provides Broadridge with a front-to-back capability in securities and ETD trading that complements its existing front-to-back capabilities in securities finance and in FX trading. Where does this trend come from and what are the benefits?

A little bit of history

Computers played no role in capital markets until the 1960s when they first started being introduced to help manage the mountains of paper generated in securities settlement. Only in the 1970s did computers start appearing at brokers and banks, as well as at exchanges and securities depositories.

The software which began to be used at those institutions typically performed a range of functions including trade, accounting, and settlement. Many of these ‘front-ish’ to ’back-ish’ systems were not actively used by the front office who would write paper ‘deal tickets’ for input by support staff. Though the practice of paper deal tickets lingered into the 2000s, an increasing number of new systems were used by the front office for trade capture.

During the course of the 90s, the needs of traders across a whole range of asset classes grew beyond what these systems could provide. Markets expanded and grew faster. Trading strategies and product grew more complex. Separate front office orientated trading systems emerged which combined trade capture with position management, risk management and P&L calculation (See Figure 1).

Figure 1: Evolution of capital markets infrastructure

Moving further into the 1990s and 2000s, capital markets trading become progressively more electronic as exchanges moved online and the over-the-counter products such as FX were increasingly traded on electronic trading platforms.

Electronic trading created the need to connect existing trading systems to the new platforms. It created the opportunity to automate and speed up more of the trading process particularly in areas such as auto-hedging and order management. These new layers of functionality, which needed to be optimised speed created additional layers of functionality that needed to be integrated.

The problems of disjointed infrastructure

While each layer of functionality added major value, it also added to complexity and operational risk. Each layer of system infrastructure will typically have its own data model, creating the need for translation as data is communicated between systems.

Systems in the upper, faster layers of infrastructure also typically have less data regarding trades than systems further down in the processing chain, creating the need for data enrichment.

Typically, systems communicate by generating and sending the relevant data for each trade and event in messages, which allows data to be shared in near real time. Unfortunately, even the process of creating, communicating and consuming messages introduces multiple potential sources of failure (see Figure 2). This creates the need for reconciliations and teams of people to analyse and fix breaks.

Figure 2: Potential failures in messaging

In the worst-case implementations of trading infrastructure, full connectivity is not built between all systems and for all products. Some parts of the overall system may allow the capture of a trade while other systems involved in processing may not have the full functionality needed to process the data they receive.

This can lead to the unfortunately common picture illustrated in Figure 3, where processing gaps are commonly filled by multiple teams across multiple business functions using manual or semi-manual (typically using Excel or Microsoft Access) to fill the gaps.

Figure 3: People fill the gaps

Advantages of a full trade life cycle solution

The desire to avoid processing gaps and the resulting costs and risks, has popularised the concept of a new breed of complete front, middle and back-office systems. Unlike their historic ancestors, these have considerably more trading tools and connectively to the world of electronic trading at the front as well as post-trade connectivity to CSDs, payment infrastructure, central counterparties and custodians at the back.

Some front-to-back systems were designed from the outset to provide front office and post-trade functionality. In other cases, vendors have started with a post-trade orientated system and added additional trading functionality.

Alternatively, businesses acquired a front office orientated system which had post-trade functionality added. Another approach is to seek a vendor who provides both front and back office orientated systems but has built a standard interface between them which can be provided out of the box. All these approaches can significantly reduce the complexity, cost, and risks of trading infrastructure.

However, the special engineering challenges of building low latency systems at the front of the stack to manage electronic trading mean it typically does not make sense to build a single box solution which processes everything from exchange connectively down to settlements.

Focussing on higher business value

An integrated full trade life cycle platform, where each component is designed on ’first principle’ basis (what is a contract, what is a trade, what is settlement, …etc), frees its users from dealing with system mismatches. It means traders spend more time working with market information, as they spend less time working with their system.

It is the requirement to move onto exception-based processing, where most of the activity is Straight-Through-Processing (STP), as information is shared and integrated along the stack. Operations can handle business processes rather than systems, with common definitions, and data left in appropriate systems. The flow of information between Front, Middle and Back Office becomes more efficient, as one language is used.

More importantly, the ability of the organisation to innovate, reacting to a changing environment, increases: most innovations are really a combination, or recombination, of existing parameters, reusing fundamental elements, which are based on first principle. A full front, middle and back-office system designed on this basis supports adjusting the combinations at the right level, for example innovation on settlement, or execution, without causing disruption to the other levels.

Collateral trading

One of the most inherently “front-to-back” areas is collateral trading, an area which includes repo, stock lending and collateral optimisation. Collateral optimisation grew out of the middle office function of collateral management, and stock lending from the operational function of covering settlement failures by borrowing stocks, an activity which required an accurate view of settled positions.

Collateralised trading today requires a consolidated view of the sources of securities, notably internal inventory, but also collateral placed with CCPs, tri-parties, bilateral counterparties as well as securities lent or repo-ed.  These are collectively known as ‘sinks’. Various strategies and optimisation techniques can be employed to determine how to use sources to meet the needs of the ‘sinks’ in a way which achieves a firm’s trading objectives.  All the while working within the constraints imposed by risk, liquidity, leverage, and capital.

It also requires an understanding of the market through data on the availability of securities and the repo rates, or lending fees associated with different securities. Finally, any optimised trading solution requires execution capabilities, particularly to trade through electronic markets.

Having a system which handles the optimisation and execution process in a largely automated manner allows traders to focus on the parameters of their trading model rather than to generate the maximum P&L on the booking trades and manually reviewing positions.

A good technical model for this is shown in Figure 4 where specific systems manage electronic trading, trade capture (including manual trade capture), collateral management, and post-trade functionality such as settlements. This model can be further improved if the infrastructure is specifically designed to operate on a front-to-back basis.

Broadridge’s Securities Finance and Collateral Management (SFCM) system, and its decoupled Repo Order Quote (ROQ) component, provide such a solution. It provides a consistent data model, shared reference data and rock-solid integration between the key components. As well as a genuinely joined up view of market and inventory data.

Figure 4: Logical model of collateral trading and Broadridge model

Failing to have a front-to-back solution for collateral trading will result in a trading business which is both inefficient and will have trouble controlling risks and overall direction of trading, potentially allowing positions to develop in directions fare beyond trading objectives.

Cyclical trends

Front-to-Back as architectural strategy is clearly back in fashion, but unlike previous generations it does not necessarily mean using a ‘one box’ overly complex single system for all processing. It can mean using multiple systems for different stages of the trade lifecycle but making sure those separate components have full functional and mature interfaces.

Ideally taking advantage of the cost advantages that can be provided from the mutualisation of software development that comes from using a major software vendor.



Bitcoin Financialization (Part 3) – Calling All Crypto Asset Managers

Other | Trading & brokering Bitcoin Financialization (Part 3) – Calling All Crypto Asset Managers

TS Imagine
Bitcoin Financialization (Part 2) – The Many Stages of Bitcoin

Other | Trading & brokering Bitcoin Financialization (Part 2) – The Many Stages of Bitcoin

TS Imagine
Bitcoin Financialization (Part 1) – A Tectonic Shift in Asset Management

Other | Trading & brokering Bitcoin Financialization (Part 1) – A Tectonic Shift in Asset Management

TS Imagine
Technical Consulting, Project Management and Support

Best Practice | Trading & brokering Technical Consulting, Project Management and Support

pdv Financial Software GmbH