Apr 4, 2014

Issues posed by this recurring requirement and proposed long-term solutions.


The move from paper to electronic platforms and the development of multiple trade repositories means that there are many projects where firms must backload trades. Alexandra Mitu, Luiza Martac, Sarah Bater and Stephanie Barrows discuss the issues and what lessons can be learnt from their experiences in backloading projects.

Background

Backloading can have multiple definitions but in this article we will discuss the backloading of OTC derivative transactions onto electronic platforms. Backloading in this instance involves the pre-matching of trade data between counterparties and then simultaneously loading trades using appropriate affirmation platforms. When firms load existing trades into central platforms they are required to verify and pre-match trade details prior to loading. The verification process identifies mismatches between the counterparties, which need to be investigated and remediated.

Where two firms backload trades, a golden copy of the trade is generated. The operational risk in the firms is decreased because the trade attributes are agreed by both parties to the trade and there are no further manual touchpoints. Backloading trades makes it easier for a firm to report trades to regulators and reduce both capital charges and risk because backloading facilitates techniques such as:

  • Portfolio compression – a risk reduction process in which two or more counterparties wholly or partially terminate some or all of the derivatives submitted by those counterparties for inclusion the portfolio compression. Portfolio compression replaces the terminated derivatives with derivative whose combined notional value is less than the combined notional value of the terminated derivatives. The advantage of portfolio compression is that it reduces notional outstanding by eliminating matched trades or trades that do not contribute risk to the portfolio of a dealer. Operation of compression services can create new replacement contracts, where one contract is replaced by a new, smaller contract to allow the removal of an offsetting exposure;
  • Central clearing – if a trade is uploaded into a clearinghouse, the original trade counterparty is replaced by the clearinghouse. This is beneficial for the firms as their credit exposure to the original counterparty risk is reduced upon the clearing of the trade. Furthermore, when trades are in the clearinghouse it is easier for the firms to compress more trades;
  • Reporting of trades to global regulators; and Populating centralised platform for trade data (trade repositories).

History of backloading

In 2006 the DTCC CDS Trade Information Warehouse (TIW) was set up to take matched trade confirmations from the DTCC confirmation matching infrastructure and store a golden copy in the TIW. This process allowed market participants to automatically process credit events on these transactions whilst also calculating cash-flows and automatically settling those cash-flows through the central settlement system (CLS).

More recently other repositories have been set up as shown in Figure 1. Affirmation platforms were also set up to feed the trade data to those repositories.

Figure 1: Current trade repositories

aspect-operation2

Why do problems arise?

The main reason why problems arise are:

  • Counterparties – Many counterparties do not understand the motivation for backloading. As a   result they may not support the counterparty who is trying to backload. Backloading requires   synchronised input from both counterparties, so if one counterparty is not prioritising   appropriately, then the whole process can be delayed;
  • Increased costs – Counterparties may be put off by clearing costs;
  • Greater regulatory scrutiny – Some counterparties are concerned that trade backloading will alert   regulators to their trades which might result in new regulatory scrutiny;
  • Lack of skilled resources – Some counterparties may not have sufficient skilled resources to   perform the remediation work arising from trade backloading and hence backloading will be   delayed until suitable resources are available. These resources must be able to use the affirmation   platforms, be familiar with internal systems as well as having appropriate product knowledge;
  • Low counterparty prioritisation – If the counterparty requesting backloading is not a major client   of the firm then that counterparty might be not prioritised. Firms will often have limited resources   and may well prioritise those counterparties or trades which give the quickest and most effective   results. A firm may prioritise the largest trades, as these will have a greater effect on capital   reduction as opposed to smaller trades;
  • Poor client reference data – Some of the information required to backload is reference data. As   discussed in the client reference data article, poor reference data is a common issue in firms.   Often the backloading process is held up because a data clean-up process is required. The data   clean-up requires up-to-date client contact information. This information is often out of date and   it is difficult to source as many firms will not provide names of their staff;
  • Poor cooperation between departments at the backloading firms – Backloading issues require   collaboration between different departments, such as front office, middle office, operations, legal   and risk. For example, the front office may not prioritise static data issues especially if the issue   does not have a material impact on P&L; and
  • Historic trade issues – Some historic trades may not be compatible with the terms of new   clearing requirements and hence cannot be input into the trade repository. The trade must be   cancelled and a new trade created to replace the old one. Many historic trades were confirmed using manually created paper confirmations. For a number of reasons such as trading volumes, poor infrastructure and lack of a robust control environment, there are many discrepancies in trade data in these types of portfolios. These discrepancies must initially be researched and remediated internally and then between counterparties. Often, before the trade can be   backloaded, amendments are required which need negotiating between the two counterparties.

What can firms do to address these issues?

Backloading requires a project team to be set up to perform the backloading process. This resource needs to have a number of skills. Some of the work, including the initial upload from trade terms, is relatively straightforward however when disputes arise between two counterparties a higher skill-set is needed. For example, these issues will need to be escalated and action agreed with the front office and other internal stakeholders before coming to agreement with a counterparty. In order to do this the resource must understand the internal processes, the regulation and the product. Whilst most backloading differences between two counterparties are to do with static data, sometimes differences can have an economic effect on both risk and P&L. As such these trades may need a full investigation, including in some cases pulling the tapes of the original trade. Unless the backloading team are able to make trade amendments in the bank’s live risk systems, this may take time. It is therefore important that backloading teams are trained in order to deal with these issues.

It is also important that resource pools are flexible so that when the majority of the trades have been backloaded staff numbers can reduce and deal with the tail. The tail is normally much harder to backload and hence requires more experienced resources.

Clearly, good project governance and project management is required. This should include appropriate project governance such as planning, speaking to stakeholders in advance, trackers and training. Stakeholders include front office, compliance, risk, clients and operations. However, there are additional issues which need to be addressed:

  • Vanilla trades and large notional trades should be dealt with first;
  • Clients who are major clients of the bank should be prioritised; and
  • Key relationships at counterparties, who will help to resolve and escalate issues in a timely fashion, should be built early in the project.

Conclusion

Backloading will continue to occur as the regulatory environment drives the promotion of new utilities. It is important to understand that backloading can be for different purposes. It might be undertaken in response to global regulations or to create a centralised source for trade data. Banks should understand their motives for backloading and quantify the benefits.

The lesson learnt to date in backloading is to exercise controlled project management. All stakeholders should be identified and briefed so that they understand the reasons why backloading is occurring and what the challenges will be. Similarly across the industry, controlled synchronisation of backloading will ensure it maximises the benefits to participants. Backloading will become easier as banks and clients get used to more and more initiatives around backloading.