1
Introduction A dominant theme for OTC derivative markets throughout 2010 has been the intense and rapid process of regulatory reform. From the passing of the Dodd-Frank Act and the flurry of CFTC and SEC proposed rulemakings in the US, to the EMIR and MiFID consultations in the EU, regulators are fundamentally redefining the structure of these markets. We can expect this to continue throughout 2011. One of the recurring themes across many of the regulatory proposals is transparency, and specifically regulatory transparency. The events of the crisis demonstrated to regulators that they did not have adequate information over the risk exposures that some counterparties were building up through OTC derivative products, with catastrophic results. The objectives for increased regulatory transparency can be divided into three broad areas: Prudential supervision – monitoring the build-up and concentration of risk exposures at both institutional and systemic levels; Preventing market abuse – detecting market manipulation, fraud or other abuse; and Crisis management – providing a central record to resolve positions after an institution fails. Regulatory Proposals Regulators of different jurisdictions are at different stages in outlining how they intend to achieve these objectives. Swap data repositories will undoubtedly play a key role in providing the infrastructure, storing much of the related transaction and position data, maintaining the integrity of the records, and providing effective access to relevant authorities. In the EU, the Commission has proposed only broad minimum requirements for reporting to trade repositories at this stage, leaving details on the format and frequency to be determined at a later date for each class of derivatives. Preparation of the technical standards is delegated to ESMA (European Securities and Markets Authority), a new European Supervisory Authority, and are due to be submitted to the Commission by June 2012. In the US, however, the CFTC and SEC have prepared detailed specifications of the data fields and timing requirements, with rules to be finalised by July 2011. The framework proposed by the CFTC segments the data into swap creation data (such as the primary economic terms of the swap and confirmation data) and swap continuation data (such as life-cycle or contract event data and valuation information), and distributes responsibility for reporting data items across a number of market stakeholders depending on the details of the trade. Risking the good in search of the best: assessing the practical issues of recent OTC derivative transparency reporting proposals The CFTC also proposes development and application of three unique identifiers in all swap reporting, one each for Counterparty, Swap and Product. These are designed to give regulators full flexibility in querying and aggregating repository data across any dimension. Both the CFTC and SEC will require prompt reporting of swap transaction data to a repository; for most swaps the CFTC proposes reporting within 15-30 minutes, and the SEC proposes real-time, so the data can then be disseminated publicly. Practical Issues Increased regulatory transparency is recognised as a valuable goal and, in principle, has full industry support. There are, however, significant practical hurdles to implementation of the reporting proposals, of which two are highlighted below. The first relates to data availability, and the risk of compromising data integrity through applying a one-size-fits- all approach across products. The level of process and data automation differs greatly across asset classes, counterparties and product sets. The OTC derivatives industry has made substantial progress under the guidance of the NY Fed to deliver on regulatory demands for increased process standardisation and automation, and this will continue to be a work in progress. For example, it has taken five years to increase the level of CDS electronic confirms to an impressive 98.8% of trades, but Rates and Equities are still at 78.0% and 33.3% respectively 1 , as they have a much broader product set and user base and different trade processes to contend with. Some of the required data will need sourcing from multiple systems within institutions, requiring careful aggregation before reporting. Some of the data does not exist at all and, even assuming suitable standards can be defined, would require fundamental process redesign to deliver. As an example, unique product and counterparty identifiers would have to be agreed on a global basis across all market stakeholders, and maintained through an ever-changing corporate and product landscape. This is a worthy aspirational goal but, given the clear delivery risks, it should not be a predicate to improved regulatory reporting. The second issue is the difficulty in achieving multiple regulatory goals using a single reporting infrastructure. A single infrastructure (per asset class) provides significant benefits in terms of robustness and efficiency gains, and is, perhaps, the only practical approach given the difficulties in aggregating data from multiple partial repositories. However, the different regulatory objectives require different content and timing of reporting, for example trading activity data for detecting market abuse, and position data for prudential supervision. There can also be significant differences in timing requirements, for example it is difficult to see the incremental benefits that accrue to either prudential supervision or market abuse monitoring from ever more rapid reporting; here the priority should be on ensuring appropriate structure and integrity of data. There are drawbacks of requiring pre-confirmation reporting, which is likely to be of lower quality than confirmed data, and will also require substantial process redesign to extract earlier in the trade-flow. It is important to explicitly tie the requirements back to the underlying regulatory objectives of the reporting, so that delivery of fundamental ‘must-haves’ are not threatened by ‘nice-to-haves’. What analyses and monitoring processes will regulators be conducting, and what data is required to support these? Without linking back to objectives in this way there is a risk of data quantity winning over quality and key risks being lost in a deluge of reporting and process. There will need to be a reconciliation process between the repository and market participants to ensure data quality, but it is not clear why this needs to be performed on a daily basis for all trades. Developing and operating this process would be a major undertaking for the industry, with marginal benefit compared to a more practical frequency. Recommendations The current proposals have a clear, and sometimes unfortunate, analogy in many large IT projects: data requirements that do not reflect the current underlying processes; a lack of clarity over required functionality that drives an expansion in scope to capture all data ‘just in case’; and a ‘big-bang’ implementation that aim to achieve everything at once. These factors have been important weaknesses in successful delivery of similar projects. It is, therefore, critically important to: be realistic over the current level of data availability and build solutions around that, rather than start with a blank slate approach that attempts to introduce fundamentally new structures; be clear over how the different regulatory objectives drive minimum data and timing requirements; prioritise the key deliverables and be mindful of the cost/benefit of exceeding these minimum standards; and separate the near-term and long-term deliverables, and build a credible roadmap for reaching the desired end state. Continued evolution of market infrastructure should, of course, be – and is – encouraged, to deliver further automation and process/legal standardisation. This evolution will then support improvements to data richness, quality and timeliness in regulatory reporting. “Implementing OTC Derivatives Market Reforms” – FSB, 25 October 2010 (data as at June 2010)

Risking the good in search of the best: assessing the ...cbs.db.com/new/docs/FOA_2011_DB_v37.pdf · not reflect the current underlying processes; a lack of clarity over required functionality

  • Upload
    others

  • View
    0

  • Download
    0

Embed Size (px)

Citation preview

Page 1: Risking the good in search of the best: assessing the ...cbs.db.com/new/docs/FOA_2011_DB_v37.pdf · not reflect the current underlying processes; a lack of clarity over required functionality

IntroductionA dominant theme for OTC derivative markets throughout 2010 has been the intense and rapid process of regulatory reform. From the passing of the Dodd-Frank Act and the flurry of CFTC and SEC proposed rulemakings in the US, to the EMIR and MiFID consultations in the EU, regulators are fundamentally redefining the structure of these markets. We can expect this to continue throughout 2011.

One of the recurring themes across many of the regulatory proposals is transparency, and specifically regulatory transparency. The events of the crisis demonstrated to regulators that they did not have adequate information over the risk exposures that some counterparties were building up through OTC derivative products, with catastrophic results.

The objectives for increased regulatory transparency can be divided into three broad areas:• Prudential supervision – monitoring the build-up and

concentration of risk exposures at both institutional and systemic levels;

• Preventing market abuse – detecting market manipulation, fraud or other abuse; and

• Crisis management – providing a central record to resolve positions after an institution fails.

Regulatory ProposalsRegulators of different jurisdictions are at different stages in outlining how they intend to achieve these objectives. Swap data repositories will undoubtedly play a key role in providing the infrastructure, storing much of the related transaction and position data, maintaining the integrity of the records, and providing effective access to relevant authorities.

In the EU, the Commission has proposed only broad minimum requirements for reporting to trade repositories at this stage, leaving details on the format and frequency to be determined at a later date for each class of derivatives. Preparation of the technical standards is delegated to ESMA (European Securities and Markets Authority), a new European Supervisory Authority, and are due to be submitted to the Commission by June 2012.

In the US, however, the CFTC and SEC have prepared detailed specifications of the data fields and timing requirements, with rules to be finalised by July 2011. The framework proposed by the CFTC segments the data into swap creation data (such as the primary economic terms of the swap and confirmation data) and swap continuation data (such as life-cycle or contract event data and valuation information), and distributes responsibility for reporting data items across a number of market stakeholders depending on the details of the trade.

Risking the good in search of the best: assessing the practical issues of recent OTC derivative transparency reporting proposals

The CFTC also proposes development and application of three unique identifiers in all swap reporting, one each for Counterparty, Swap and Product. These are designed to give regulators full flexibility in querying and aggregating repository data across any dimension.

Both the CFTC and SEC will require prompt reporting of swap transaction data to a repository; for most swaps the CFTC proposes reporting within 15-30 minutes, and the SEC proposes real-time, so the data can then be disseminated publicly.

Practical IssuesIncreased regulatory transparency is recognised as a valuable goal and, in principle, has full industry support. There are, however, significant practical hurdles to implementation of the reporting proposals, of which two are highlighted below.

The first relates to data availability, and the risk of compromising data integrity through applying a one-size-fits-all approach across products. The level of process and data automation differs greatly across asset classes, counterparties and product sets. The OTC derivatives industry has made substantial progress under the guidance of the NY Fed to deliver on regulatory demands for increased process standardisation and automation, and this will continue to be a work in progress. For example, it has taken five years to increase the level of CDS electronic confirms to an impressive 98.8% of trades, but Rates and Equities are still at 78.0% and 33.3% respectively1, as they have a much broader product set and user base and different trade processes to contend with.

Some of the required data will need sourcing from multiple systems within institutions, requiring careful aggregation before reporting. Some of the data does not exist at all and, even assuming suitable standards can be defined, would require fundamental process redesign to deliver. As an example, unique product and counterparty identifiers would have to be agreed on a global basis across all market stakeholders, and maintained through an ever-changing corporate and product landscape. This is a worthy aspirational goal but, given the clear delivery risks, it should not be a predicate to improved regulatory reporting.

The second issue is the difficulty in achieving multiple regulatory goals using a single reporting infrastructure. A single infrastructure (per asset class) provides significant benefits in terms of robustness and efficiency gains, and is, perhaps, the only practical approach given the difficulties in aggregating data from multiple partial repositories. However, the different regulatory objectives require different content and timing of reporting, for example trading activity data for detecting market abuse, and position data for prudential supervision. There can also be

significant differences in timing requirements, for example it is difficult to see the incremental benefits that accrue to either prudential supervision or market abuse monitoring from ever more rapid reporting; here the priority should be on ensuring appropriate structure and integrity of data. There are drawbacks of requiring pre-confirmation reporting, which is likely to be of lower quality than confirmed data, and will also require substantial process redesign to extract earlier in the trade-flow.

It is important to explicitly tie the requirements back to the underlying regulatory objectives of the reporting, so that delivery of fundamental ‘must-haves’ are not threatened by ‘nice-to-haves’. What analyses and monitoring processes will regulators be conducting, and what data is required to support these? Without linking back to objectives in this way there is a risk of data quantity winning over quality and key risks being lost in a deluge of reporting and process. There will need to be a reconciliation process between the repository and market participants to ensure data quality, but it is not clear why this needs to be performed on a daily basis for all trades. Developing and operating this process would be a major undertaking for the industry, with marginal benefit compared to a more practical frequency.

RecommendationsThe current proposals have a clear, and sometimes unfortunate, analogy in many large IT projects: data requirements that do not reflect the current underlying processes; a lack of clarity over required functionality that drives an expansion in scope to

capture all data ‘just in case’; and a ‘big-bang’ implementation that aim to achieve everything at once. These factors have been important weaknesses in successful delivery of similar projects.

It is, therefore, critically important to:• be realistic over the current level of data availability and build

solutions around that, rather than start with a blank slate approach that attempts to introduce fundamentally new structures;

• be clear over how the different regulatory objectives drive minimum data and timing requirements; prioritise the key deliverables and be mindful of the cost/benefit of exceeding these minimum standards; and

• separate the near-term and long-term deliverables, and build a credible roadmap for reaching the desired end state.

Continued evolution of market infrastructure should, of course, be – and is – encouraged, to deliver further automation and process/legal standardisation. This evolution will then support improvements to data richness, quality and timeliness in regulatory reporting.

“Implementing OTC Derivatives Market Reforms” – FSB, 25 October 2010 (data as at June 2010)