Table of Contents Introduction 3 Understanding the Measurement of Processing Costs 4 Cost per Trade Benchmarking Methodology 6 Cost per Trade Benchmarking Cash Products 7 Cost per Trade Benchmarking OTC Derivatives 10 Measuring Scalability 13 STP Rate Benchmarking 15 The Impact of STP 17 Case Study 1 Major FX Bank 19 Case Study 2 TD Securities 21 Future Benchmarking Plans 23 Appendix A Activities Included in the Cost per Trade 25 About McLagan and Z/Yen 27 2 - Cost per Trade and STP Benchmarking
Introduction Most non financial services industries have long standing measurements of efficiency, from profitability in saw mills in the USA (PWC) to cost benchmarking for mobile phone operators in Europe (AT Kearney). However, formal efficiency measurement in wholesale financial markets is much less developed. There are a number of key reasons for this: 1. The continual evolution of financial products makes year on year comparison difficult; 2. Usage of different technology platforms (both internal and external) leads to incompatible process flows; 3. The banks themselves have traditionally focused more on driving business forward than on back office processing metrics. However, there have been a number of initiatives in recent years to measure back office efficiency and banks have begun to take cost and efficiency benchmarking seriously. This paper outlines the McLagan Z/Yen approach to cost and efficiency benchmarking in the back office and sets out two case studies where banks have used both technology and process re engineering to reduce the cost per trade. 3 - Cost per Trade and STP Benchmarking
Understanding the Measurement of Processing Costs Scope Before any metrics can be defined, there needs to be a careful definition of scope. In many banks, the activities covered by the operations groups differ significantly. For example, in some banks the creation and matching of confirmations is processed in operations, whereas in other banks, it is done in either a specialised middle office or in a front office support group. Therefore scope needs to be defined as a series of activities, which in turn have tight definitions. Table A opposite shows a typical set of activities that should be included in a back office cost per trade benchmark. Cost Drivers Agreement of scope is only the first step. Possibly the most important part of any benchmarking process is to identify the cost drivers. At an overall level, the number of trades is an obvious cost driver. But the trade count is becoming more complicated with algorithmic trading greatly increasing the number of executions, and settlement netting reducing the number of settlements. Key cost drivers are show in Table B opposite. Table A. Operations Activities Pre settlement Reference data Client confirmations & allocations Settlement Operational control Nostro and depot reconciliations Settlement exception management Collateral & margin management Coupon & dividend processing Corporate actions Customer relationship management Network management Table B. Cost Drivers Trade related Executions Allocations Confirmations Settlement related Netted settlements / payments Asset servicing Events 4 - Cost per Trade and STP Benchmarking
Understanding the Measurement of Processing Costs Benchmarks Used Finally, the metrics to be calculated must be agreed. Typical benchmarks include: Cost per trade (costs divided by trade count) Operational throughput (volume divided by headcount) Cost per head (cost divided by headcount) Cost economy of scale (cost per trade measured relative to volume) Operational throughput economy of scale (operational throughput measured relative to volume) In order to benchmark, participants must agree a common terminology to describe their processes. Although banks may call their functions and products by different names, they all do the same work! 5 - Cost per Trade and STP Benchmarking
Cost per Trade Benchmarking Methodology A typical methodology for a cost per trade benchmark is shown below. To get worthwhile results, it is clear that the process takes time. This is due to the following key reasons: 1. The exact details of the data to be collected and supporting definitions need to be agreed and signed off between participants before starting data collection. 2. The banks themselves tend to need at least six weeks to collect a first cut of data. 3. The quality assurance process is complex, and in many cases, involves presentation of draft findings to senior management for sign off. The quality assurance check is vital. Until the benchmarks are published in draft form, it is often impossible to understand whether differences between participants are real or caused by bad data. 6 - Cost per Trade and STP Benchmarking
Cost per Trade Benchmarking Cash Products Cash products typically have short settlement cycles with the entire trading / confirmation / settlement process taking one to three days. Cash trades include equities, bonds, foreign exchange, money markets and exchange traded derivatives. How Cash Trades are Measured There are three main measurements for cash trades: Executions using this as the main cost driver measures efficiency from a front office perspective Allocations using this as the main cost driver measures efficiency from a client perspective Netted settlements using this as the main cost driver measures efficiency from a back office perspective Sample Results A typical set of sample results for a global cash equities benchmark using executions and allocations as the volume drivers would look like this: The operations cost per trade shows the processing cost per trade for each bank together with the survey average. The survey average is weighted and is thus driven down by the low costs of high volume banks. 7 - Cost per Trade and STP Benchmarking
Cost per Trade Benchmarking Cash Products The economy of scale trend is calculated by plotting the cost per trade for each bank against their individual volumes and then drawing the line of best fit. This trend line can be used by both low and high volume banks to measure relative efficiency and also to estimate processing costs at projected higher (or lower) volume levels. Operational throughput shows the number of trades processed per head at each bank together with the survey average. Again, the survey average is weighted and is thus driven up by high efficiency of high volume banks. 8 - Cost per Trade and STP Benchmarking
Cost per Trade Benchmarking Cash Products The operations cost per head shows the average fully loaded cost per head at each bank. This includes compensation, occupancy, training, travel, PC and voice costs. Using the Results The graphs above should not be used in isolation as it is the correlation of data which is important. For example: A bank can have a high cost per trade for a low volume but still be relatively efficient by being below the economy of scale curve at that volume point A bank may follow a strategy of offshoring to reduce the cost per head. In many cases, this strategy has resulted (at least in the short term) by a decrease in operational throughput. Using a combination of these graphs can identify whether the strategy has been successful. Banks have used the data in many ways, for example setting internal objectives, justifying technology spend and modelling the impact on volume on future costs and headcount. 9 - Cost per Trade and STP Benchmarking
Cost per Trade Benchmarking OTC Derivatives How OTC Derivative Trades are Measured OTC derivatives trades which can stay on the books of a bank for many years are measured differently from cash trades. In particular, there are three key groups of processing events: Table C. OTC Derivatives Processing Events Initiation (On T (trade date), T+1 or shortly after) Maintenance (During the contract) Termination (at standard or early maturity) Matching of economic terms Trade confirmation Initial exchange / premium payments Rate resetting / corporate actions Payments / rolls Tear ups Exercises / expiries Novations / assignments Cost Drivers for Benchmarking a) Primary Cost per Trade As the major banks need to provide volume metrics to their regulators, all banks now count major events in the same way. Specifically, the following events are reported on a monthly basis: New external trades Unwinds/notional changes Option expiries Assignments/novations 10 - Cost per Trade and STP Benchmarking
Cost per Trade Benchmarking OTC Derivatives Therefore, the primary benchmark (cost per trade) is now to divide total costs by the total number of events. The graph below shows the average cost per trade for interest rate, credit and OTC equity derivatives for full year 2007. b) Lifecycle Cost per Trade A further method to benchmark efficiency in OTC derivatives is to calculate the lifecycle cost per trade. This is calculated as follows: 1. Divide processing costs into two buckets: Those staff working on trade date related activities, e.g. trade support, confirmations, premium payments etc. Those staff working on settlement related activities, e.g. rate resets, payments, rolls, corporate actions etc. 2. Divide bucket 1 by the number of economic events. This gives you the cost of putting the trade onto the books 11 - Cost per Trade and STP Benchmarking
Cost per Trade Benchmarking OTC Derivatives 3. Divide bucket 2 by the average number of trades in the portfolio over the year. This gives you the cost of keeping a trade on the books for a year 4. Multiply the cost of keeping a trade on the books for a year by the average maturity for the product, e.g. this might be 2.5 years for an interest rate swap. Typical lifecycle costs (from the Z/Yen 2007 survey) for an interest rate swap were as follows: A = putting the trade onto the books = $94 B = keeping a trade on the books for a year = $28 Lifecycle cost (2.5 years) = A + 2.5B = $164 c) Cost per Confirmation The cost per confirmation is calculated by isolating all confirmation related processing activities, e.g. confirmation creation, matching and chasing, together with electronic confirmation costs, and dividing the cost of these by the number of economic events which require a confirmation. d) Cost per Settlement The cost per settlement is calculated by isolating all settlement related processing activities, e.g. rate setting, payments and nostro reconciliations and dividing these by the number of payments made. Costing of OTC derivative trades is vital, as in many cases P&L is taken up front but the operations cost continues until maturity which can be 25 years or more. 12 - Cost per Trade and STP Benchmarking
Measuring Scalability The previous pages have focused on benchmarking of operations costs. While this is probably the most common usage of cost per trade benchmarking, adding a second area, IT costs, can give an additional perspective and can help to measure the scalability of the overall infrastructure. Benchmarking IT costs IT costs can vary hugely from year to year due to development projects. Therefore for cost per trade measurement, it is important to measure the lights out or run the bank cost which will exclude any strategic projects. Calculating this will give an IT cost for each bank that can then be divided by the trade count. The graph opposite shows the cost per trade (CpT) for foreign exchange transactions for Tier 1 and Tier 2 banks covering both operations and operations IT. The overall average shows that the IT overall average CpT is $0.92 or 45% of the operations CpT. 13 - Cost per Trade and STP Benchmarking
Measuring Scalability However: For the cheapest seven banks, the average IT CpT is $0.74 or 36% of the operations CpT. For the most expensive four banks (which also have the lowest volume), the average IT CpT is $3.39 or 98% of the operations CpT. The reason for this is that IT costs are relatively more fixed than operations costs as it can cost a similar amount for a bank to provide and support a system to process 1 million trades per year as one that processes 10 million trades per year. However, on a cost per trade basis, the cost is shared over more trades. Increased Scalability of High Volumes The economy of scale curve opposite shows this differential clearly, with banks processing less than 2.5 million trades per year having much higher IT costs per trade. Tier 3 banks, with very low trade volumes, can see per ticket costs of $25 or more. With increasing volumes at the larger FX banks, it is difficult to see how smaller banks who need to purchase and support their own systems can compete on a cost per trade basis. 14 - Cost per Trade and STP Benchmarking
STP Rate Benchmarking The Definition of STP Wikipedia defines straight through processing (STP) as enabling the entire trade process for capital markets and payment transactions to be conducted electronically without the need for re keying or manual intervention, subject to legal and regulatory restrictions. This is all very well, but it doesn t define where the process starts and ends and banks themselves have differing definitions: Bank 1: A trade is STP if, and only if, it is not manually touched across the whole processing lifecycle. The lifecycle includes all activities after the trade capture in the front office towards the generation of the booking entries after successful exchange of confirmations, clearing, settlement, and reconciliation. Bank 2: Trades which do not require operational intervention. Bank 3: An STP transaction should be considered as one which runs straight through settlement systems without any manual intervention whatsoever. This applies only to the actual settlement process, not including any previous manual intervention for example during the confirmation matching and or subsequent manual handling of a resulting inquiry/investigation. Bank 4: All trades coming from the front office system (so manual entry of trades by front office people is allowed) processed, confirmed, matched, settled and reconciled without any human intervention. A tighter definition might be, A trade is STP if it is processed without human intervention from trade capture to settlement with automatic generation of all confirmations, accounting entries and feeds to ancillary systems. Measurement of STP STP is normally measured as a single percentage of trades NOT requiring manual intervention, i.e. a 95% STP rate implies that 5% of trades have had to be touched manually. 15 - Cost per Trade and STP Benchmarking
STP Rate Benchmarking Sample Results The graph below shows the average STP rates as reported by banks in the 2007 Z/Yen cost per trade surveys. While FX and equities have relatively high STP rates, money markets and bonds are lower and currency options are below 50%. These STP rates also correlate with the cost per trade: High STP = Low cost per trade 16 - Cost per Trade and STP Benchmarking
The Impact of STP Obviously, high STP is good to achieve and, as stated above, will help to bring down the cost per trade. However, it is easy to look at any STP rate above 90% and say that is an automated process. The real difference occurs when you look at the non STP or exception rate. The two graphs below show the same data but in different formats. 17 - Cost per Trade and STP Benchmarking
The Impact of STP While Bank C looks like it has a good STP rate, in reality 7.6% of their trades are non STP and therefore exceptions which need manual intervention. This resulted in higher headcount and the highest cost per trade amongst peers. The Danger of High STP There is one drawback to high STP rates. This is the operational risk that will come either from system outages or from a change to one or more system parameters that move transactions from STP to exception queues. During times of market stress, when additional vigilance is needed before releasing payments to specific counterparties, markets or currencies, banks must ensure that sufficient numbers of staff are available to process exceptions. With current record trade volumes in many products (and reduced staff numbers), effectively increasing the STP rate is vital to maintaining control. This is particularly vital in OTC derivative products where manual processes are still widespread. 18 - Cost per Trade and STP Benchmarking
Case Study 1 Major FX Bank This bank is a major player in the FX market, ranked in the top 10 globally in terms of overall market share (Euromoney FX survey 2008) with huge growth over the past few years. This increased market share has resulted in significant growth in the volume of trades being processed as shown in the table below. The Challenge To cope with this increase in trade volume, a significant program of technology investment has been necessary to boost processing capacity to cope with peak days of over 250,000 trades. The Solution The bank has used technology from Wall Street Systems for many years but recently has faced a major transformational challenge: a) to provide increased capacity, and b) to give operational flexibility. A further challenge was how to cope with high transaction arrival rates, particularly in the early afternoon (UK time) with peak volumes from both the European and American markets. The approach taken has been to create three major processing hubs, in the UK, the US and Asia, and to upgrade all processing platforms covering confirmations, settlements and reconciliations. The clear strategy was to drive up capacity by wringing out improvements in every part of the process rather than looking for reductions in cost. In addition, with up to 40% of trades being settled via CLS, it was clear that establishing separate implementations of Wall Street Systems for CLS and non CLS trades would also increase capacity. Year 2001 6,500 2004 19,000 2006 58,000 Average Daily FX Trade Volume 2008 (est.) 200,000 Source: Z/Yen Surveys 2000 to 2007 Year 2001 2.60 2004 0.90 2006 0.67 2008 (est.) 0.20 Operations Cost Per Trade Source: Z/Yen Surveys 2000 to 2007 19 - Cost per Trade and STP Benchmarking
Case Study 1 Major FX Bank The Benefits While driven by the need to increase capacity, this strategy has also resulted in a significant reduction in the operations cost per trade as can been seen above. Additionally, the STP rate has also increased to over 99%. A senior manager at the bank commented: With our capacity issues now solved, the challenge moves to improving the process. Our technology needs to give us greater flexibility over exception handling, e.g. to allow us to pull certain trades or trade types out of the STP queue, based on counterparty or currency risk or to re prioritise the trade queue to allow instantaneous processing of late funding trades. The bank now faces further challenges with additional volume in 2008 and further projected increases in volume from prime brokerage business. However, the capacity is now available for future growth. 20 - Cost per Trade and STP Benchmarking
Case Study 2 TD Securities TD Securities, part of Toronto Dominion Bank, is a growing player in the FX market, with major growth over the past few years. The Challenge Five years ago, TD was struggling with a legacy, in house system to support foreign exchange trades. The system had a number of functional shortcomings, for example no link to CLS, and it was plagued by system bugs. There was no straight through processing (STP) as every trade needed manual intervention. The Solution Building another in house system was not a consideration, so TD selected and implemented the Wall Street Systems package on an Oracle platform including a link to CLS. At the same time, TD s operations group was restructured to match the new process flows. The first implementation was for money markets, followed by FX and then the credit module. All implementations went smoothly. The Benefits TD has been able to reduce headcount even while volume has increased. The trade volume has more than doubled over the last five years to 15,000 trades per day. Within operations, procedures have been tightened up and a faster service is now delivered to clients. Although the primary objective of the implementation was to deliver a more stable processing environment, the new system provides scalability and allows new feeds to come into the system, for example from web portals. Although not currently formally measured, the STP rate is now high though further work is still required to eradicate manual interventions. 21 - Cost per Trade and STP Benchmarking
Case Study 2 TD Securities Next Steps TD is now looking to upgrade its hardware and install the next version of the Wall Street Systems package (4.3). They also plan to measure both cost per trade and STP on a formal basis. Rhonda Westaway, Vice President for FX/Funding Technology Solutions at TD Securities says, The new system has made a great deal of difference to our business. We have been able to centralise, pulling global sites together and this has allowed us to work as one company and deliver a better service to our clients. 22 - Cost per Trade and STP Benchmarking
Future Benchmarking Plans The Benefits of Benchmarking Although successful benchmarking takes valuable time to pull data together, the value of using the results can be immeasurable to a forward thinking organisation. In particular, benchmarking: 1. Identifies specific strengths and weaknesses of organisations against peers, across products and against previous years; 2. Enables organisations to understand which way the market is moving and whether they are trending above or below the market; 3. Validates, puts into context and gives independent credibility to an organisation s own views on trade costing; 4. Supports internal marketing as good results make staff feel they have done a good job; 5. Identifies specific and across the board issues to enable planning of staff and IT enhancements; 6. Provides measurable targets for operations management; 7. Validates competitive costs to the front office. 23 - Cost per Trade and STP Benchmarking
Future Benchmarking Plans Z/Yen Surveys in 2009 McLagan is planning a range of Z/Yen surveys in 2009. The target plan dates are shown below. For further details, please contact Jeremy Smith. 24 - Cost per Trade and STP Benchmarking
Appendix A Activities Included in the Cost per Trade The following operations activities are included in the cost per trade data used in this paper: FX Trade capture Reference data Pre settlement Settlement CLS settlement Nostro reconciliations Exception management Mandatory projects Operations management & admin Equities & Bonds Trade capture Reference data Pre settlement Confirmation & allocation Settlement Operational control Nostro reconciliations Exception management Collateral & margin management Coupon/dividend processing Corporate actions Client relationship management Network management Mandatory projects Operations management & admin OTC Derivatives Trade capture Reference data Trade matching Confirmation processing Settlement calculation Settlement Operational control Nostro reconciliations Exception management Collateral management Customer valuations Client relationship management Mandatory projects Operations management & admin 25 - Cost per Trade and STP Benchmarking
Appendix A Activities Included in the Cost per Trade Where IT costs are shown, these include the following: Operations application support Maintaining trade processing systems (internal and external costs) External and internal interface system connectivity support Market driven and regulatory changes to existing systems Excludes support costs for front office trade capture systems Excludes depreciation of internal software builds and external software purchases Operations data centre/networks Costs of purchased hardware where expensed in current year Costs of purchase systems software where expensed in current year Maintenance costs of the above Depreciation costs of capitalised hardware and system software People costs to run the data centre, eg data centre operations, technical support Facilities costs of data centre Cost of IT help desks Cost of IT disaster recovery sites 26 - Cost per Trade and STP Benchmarking
About McLagan and Z/Yen Limited McLagan At McLagan, we help our clients make better decisions by applying market performance, productivity and pay information to their business problems. Our Belief Accurate market data is a requirement for aligning resources with opportunities. Market data identifies market opportunities, business improvement opportunities and prices for talent and products. Our Goal McLagan s goal is to provide a complete and accurate set of data coupled with insights to help management interpret market trends and apply them to improve business results. Our Business Model McLagan s business model is based on creating and expanding long term partnerships with our clients. As evidence of this, many of our key client relationships extend back to our firm's inception, more than 40 years ago. Z/Yen As part of McLagan, Z/Yen Limited is a leading provider of market intelligence to the Financial Services industry. Z/Yen Limited has a unique insight into the performance of operations and IT groups in all aspects of financial services. Z/Yen Limited's staff are experienced operations and IT professionals and understand how both quantitative and qualitative information gathering can be used to support decision making and therefore improve performance, retain clients, maintain control and increase bottom line profit. Since 2000, Z/Yen Limited's work in Financial Services has enabled the development of a unique and highly detailed database of operational cost and performance data derived from more than 30 major banks and 300 investment managers & hedge funds. The Z/Yen Cost per Trade and the Z/Yen Operational Performance Benchmark have become the industry standard. Contact Jeremy Smith Head of Z/Yen Benchmarking Phone +44 207 680 3071 Email jeremy.smith@mclagan.com 27 - Cost per Trade and STP Benchmarking