Operations functions have changed over the last few years. The functions were previously in-house, siloed and reactive with trade discrepancies not detected until some time after trade date. These functions are now evolving into trade date control functions, which identify discrepancies within hours of trading. Stuart McClymont and Danielle Morphew at JDX Consulting discuss this evolution and what the future holds.
Background
The operational support model for OTC derivatives is evolving to focus on post-trade processes and activities being performed immediately after trades have been executed by the front office. This trend is a result of the need to identify errors much sooner in the trade life-cycle for market, credit, settlement, and operational risk mitigation purposes. At the same time there has been a drive towards more efficient and scalable processes through the use of automation. The drive in automation for both technology and process is a result of the need to increase the capacity, scale and quality of the traditional operational support model.
Figure 1: The traditional operational support model
Figure 1 describes the traditional operational support model. Trades are executed between trading, sales and clients, which are then booked in trade capture systems on trade date. From trade date to any number of days after trade date, the same trade is then touched by multiple functions of the operations support model. For example:
• Middle office enters the trade into the books and records;
• Documentation teams draft the trade confirmation based on the representation of the trade in their books and records. This confirmation is communicated with the client to get the confirmation executed. Any differences between the representation of the bank and the representation of the client are raised to the middle office to resolve the discrepancies;
• Reporting teams report the trades to regulated trade repositories from their perspective but also, in the case of delegated reporting, on behalf of the counterparty. The reported trades must be reconciled with what was reported to the regulators and what the counterparty expected to be reported. Any differences are raised to the middle office to resolve;
• Settlement teams calculate the settlement amount and confirm with the client. Any differences in the settlement value get raised to the middle office to resolve;
• Collateral teams calculate the margin call based on the trade and all prior trades with the same client. The collateral teams speak to the client to agree the margin call and any differences caused by trade discrepancies are raised to the middle office; and
• Risk and product controllers calculate the risk and P&L on the trade, communicate this to the front office and any issues or differences are raised to the middle office for resolution.
These individual functions are performed a number of days after trade date. The functions are duplicative in terms of client contact and in terms of raising the same discrepancy, on a trade, from four different departments to the same middle office. The process requires considerable resourcing, it is not efficient and not always performed in a timely manner.
The OTC derivatives industry has automated a number of processes to improve the scale and control of these processes. With the release of the SwapsWire infrastructure across both sell and buy-side in 2002, rates derivative confirmations could be electronically affirmed between two institutions rather than manually via paper documents. With the introduction of Depository Trust and Clearing Corporation (DTCC) confirmation matching infrastructure in 2003, credit default swap (CDS) confirmations could be electronically matched between two parties. These two initiatives provided more control and accuracy in the confirmation function as well as increased capacity. At the same time the automation reduced the average confirmation execution timeframes.
The next major milestone was the delivery of the DTCC CDS Trade Information Warehouse (TIW) in 2006, which took the matched trade confirmation from the DTCC confirmation matching infrastructure and stored it as a golden copy in the TIW database. The TIW allowed market participants to automatically process credit events on credit derivative transactions whilst also calculating cash-flows and automatically settling them via Continuous Linked Settlements (CLS). At the same time the TIW provided reporting to the OTC Derivatives Regulatory Forum (ODRF) and OTC Derivatives Supervisory Group (ODSG). This gave the two regulatory groups the ability to monitor trade exposure across each TIW institution. The global view, provided by the TIW, was invaluable to the regulators during the crisis of 2008.
Unfortunately, the TIW was only developed for CDS and an equivalent warehouse did not exist for rates, equities, FX or commodities. There had been attempts to build such repositories for rates and equities, however these repositories were neither fully linked to the confirmation process nor the settlement or corporate action processes. It was for these reasons that the repositories were not taken up by the industry.
The inability to access a globally complete data set, as well as the unreliability of the data, created a perceived opaqueness in the OTC derivatives markets. In addition, the poor timescale of these processes prevented regulators from gaining full access to the data for monitoring of exposure and trading patterns. Consequently, the G20 countries gathered in Pittsburgh in September 2009 and agreed that all OTC derivative contracts should be reported to trade repositories, that all standardised OTC derivative contracts should be traded on exchanges or electronic platforms, where appropriate, and OTC derivatives contracts should be cleared through central counterparties. The G20 further agreed that non-centrally cleared contracts should be subject to higher capital and margin requirements than the contracts had previously incurred. The regulators agreed to implement these initiatives by the end of 2012 at the latest.
As a result, the G20 countries, via legislative texts such as Dodd-Frank Act in the US, European Market Infrastructure Regulation in Europe (EMIR), and numerous legislations across the remaining G20 countries, mandated the introduction of these additional requirements. The G20 countries mandated these rules to improve the timeliness and accuracy of the functions described above and meet the requirements set out by the Pittsburgh meeting.
In addition, the regulators introduced other risk mitigation requirements such as portfolio reconciliation, dispute resolution processes, and portfolio compression requirements. The portfolio reconciliation requirements mandate the periodic exchange and reconciliation of trades between two counterparties, depending on the nature of the counterparties and their portfolio sizes. Unfortunately for operations, these additional regulations layered even more duplicated processing layers on top of an already duplicative series of functions.
The industry now faces the challenge of implementing the additional functions and integrating them to ensure each function is performed once, with downstream functions reusing output from upstream functions.
Without successfully addressing this challenge the regulations will add further fixed cost onto an already expensive post-trade model when compared to more mature products like cash equities or bonds.
The evolving operations model
A new operating model is starting to evolve to replace the old model, which reduces the number of processes and avoids duplication. The primary objective of the new model is that a trade is executed with a counterparty on trade date and stored in the trade capture infrastructure. That trade is then sent real-time to the counterparty to be agreed and matched. Any discrepancies are raised real-time to the trading and sales desks to resolve. Once the trade is fully matched and agreed with the counterparty it is sent downstream for processing for confirmation, reporting, settlement, collateral risk and P&L purposes. The only discrepancies that should occur would be due to rate differences or accrual periods due to wrong static data rather than trade data or curves used to calculate trade valuations. All trade attributes used in the confirmation, reporting, settlement, collateral or risk functions are what had already been agreed and matched with the counterparty up front.
The only additional reconciliation needed is a full trade and position reconciliation to the reporting reposi- tory eliminating the need for portfolio reconciliations between each counterparty.
Figure 2: The revised operational support model
There will be further automation within firms and across the industry. For example, firms and clients will roll out electronic confirmation platforms for a greater product set and a broader set of industry users. There will be further use of document generation and document digitisation platforms for trade confirmations, term-sheets, master agreements, and credit support annexes.
Conclusion
The industry will eliminate certain functions in the post-trade process by relying on upstream functions to give them the reassurance that trades are accurate. Eventually the industry will see the elimination of the confirmation process for standardised OTC derivatives as a distinct process within institutions.
Hence the automation will result in more real-time transparency of what has been traded and who is exposed to who. Whilst the new processes required to meet new regulatory requirement will initially increase costs, as more industry automation occurs, these costs will reduce and the risks associated with the administration of OTC derivatives will be reduced.
Firms who understand the new operating model will collaborate solutions through common platforms and utilities. The increased automation through the platforms will ultimately reduce the cost base of adminis- trating OTC derivatives.
