Generic Template Proposal – January 2012
Scope: DFA eligible trades - OTC Equity, Credit and Interest Rate Derivatives
US regulatory requirement
Under the DFA (dodd-frank act) trade verification / trade matching, should apply to trades prior to PET (primary economic term) reporting to the SDR (swap data repository). It is assumed that trade verification for trades executed via a SEF (swap execution facility) and or trades processed via and electronic platform will be addressed by the relevant vendor. For the remaining “paper” population, as defined below, a trade verification solution is required within 1 hourfollowing execution ** in the first year, thereafter 30 minutes.
Extract from the CFTC Final Rule - December 2011- page 227-8
Credit, equity, foreign exchange, and interest rate swaps. For each such credit swap, equity swap, foreign exchange instrument, or interest rate swap:
The reporting counterparty, as determined pursuant to § 45.8, must report all primary economic terms data for the swap, within the applicable reporting deadline set forth in paragraph (c)(1)(i)(A) or (c)(1)(i)(B) of this section. However, if the swap is voluntarily submitted for clearing and accepted for clearing by a derivatives clearing organization before the applicable reporting deadline set forth in paragraphs (c)(1)(i)(A) or (c)(1)(i)(B) of this section, and if the swap is accepted for clearing before the reporting counterparty reports any primary economic terms data to a swap data repository, then the reporting counterparty is excused from reporting required swap creation data for the swap.
If the non-reporting counterparty is a swap dealer, a major swap participant, or a non-SD/MSP counterparty that is a financial entity as defined in CEA § 2(h)(7)(C), or if the non-reporting counterparty is a non-SD/MSP counterparty and verification of primary economic terms occurs electronically, then the reporting counterparty must report all primary economic terms data for the swap as soon as technologically practicable after execution, but no later than: one hour after execution during the first year following the compliance date; and 30 minutes after execution thereafter.
If the non-reporting counterparty is a non-SD/MSP counterparty, and if verification of primary economic terms does not occur electronically, then the reporting counterparty must report all primary economic terms data for the swap as soon as technologically practicable after execution, but no later than: 24 business hours after execution during the first year following the compliance date; 12 business hours after execution during the second year following the compliance date; and 30 minutes after execution thereafter.
** Execution, for the purpose of the generic template proposal, is defined as the point at which the deal is struck, defined further as when the trader(s) say “done”.
Extract from the CFTC Final Rule - December2011
Requires reporting of (i) creation and (ii) continuation data until termination
Creation data: (i) primary economic terms of the swap verified or matched by the counterparties at or shortly after the time of execution and (ii) all of the terms of the swap included in the legal confirmation. Continuation data: over the life of the swap, all changes to the primary economic terms of the swap and reporting of the valuation.
The reporting counterparty, as determined pursuant to § 45.5, must report any primaryeconomic terms data for the swap asset class of the swap that is not reported by the SEF or DCM
Transactions that are not executed via a SEF or a DCM (designated contract market), in addition to Transactions that are not processed on an electronic platform, for whatever reason, can be defined as “paper”.Importantly the “paper” population will exclude Transactions that are negatively affirmed and remain. Such trades are out of scope in relation to this paper, and will be addressed separately.
This paper is not intended to address RT “Real-time” Reporting requirements, nor USI generation, dissemination and retention. It is assumed that Transactions submitted for PET “verification” will contain a USI (unique swap identifier). It is assumed that PET reporting will either follow or be combined with RT reporting, and that RT reporting will require a USI. Although USI is not a required field under Part 43, it is a vendor requirement. If a trade is submitted for trade pairing via the generic template and neither party has submitted a USI, the utility will inform both parties.
OTC Derivatives Supervisors Group / OTC Derivatives Regulatory Forum (ODRF)
In February 2011 the ODRF requested that trade pairing apply to all OTC Equity Transactions, and that trades be identified for reporting purposes as trade paired (validated) or not trade pairing (not validated). Whilst the text requested that a matching facility be present within the EDRR (Equity Derivative Reporting Repository) the method of pairing (verification) is to be determined by the Equity Steering Committee.
Extract from a letter from the ODRF to the Equity Steering Committee dated February 2011
Pairing details
Regulators need to understand whether a trade recorded in the EQD TR is: (i) electronically matched at inception, (ii) subject to other confirmation and/or reconciliation service, (iii) paired in the repository or (iv) one sided.[1] We consider as key priority the use of matching and confirmation platforms to provide pre-paired trade sides to the TR. For those trade sides that
cannot be electronically matched a matching mechanism within the TR will be required in order to identify whether a trade is paired. Any trade sides that are incapable of being paired should be recorded accordingly with the aim of keeping to a minimum those trades reported in this manner. We are very conscious that without transparency as to the quality of the data, and without such minimum quality as would be provided by paired trade records, the EQD TR data risks being unreliable for various regulatory purposes.
We also note that the TR should have functionality to internally pair combinations of trades that are linked (e.g. DTCC mentioned in our last Subgroup meeting that synthetic futures and forwards are booked as two separate trades and not linked).
The ODRF requirement is deemed to apply to OTC Equity Derivative Transactions only.
Trade Verification Definition
Action / input from both parties. Either acceptance of the submitting parties’ record by the other party or a matching function of records submitted by both parties’.
Reporting Party Rules
This paper is not intended to address RP rules, such rules are to be defined by each ISDA Asset Class Steering Committee
Generic template
For “paper” Transactions, PET fields need to be reported to the SDR. Paper Transactions need to be “verified” prior to PET Reporting. The Credit, Equity and Interest Rate Derivatives Asset Classes plan to address this requirement by expanding upon MarkitSERV’s current Generic Template functionality. A “light-touch” electronic template whereby partieswill be able to populate agreed PET fields for trade “verification”, defined as“Input from both parties, either acceptance of the submitting parties’ record by the other party or a matching function of records submitted by both parties’.
Both parties will have the ability to submit PET data via the GT with or without supplying a USI (unique swap identifier). Both parties will have the ability to extract the USI provided by the other party. If both parties submit the same trade each with its own USI, this will be addressed by the application of RP rules (to be defined for Transactions whereby a SD faces another SD.
An exception management process is required to address incorrect submission by the parties including non adherence of the RP rules. MarkitSERV will be asked to provide a process whereby USIs can be corrected following a RP error.
Each asset class will determine what fields can be supplied in relation to a final PET template from the Regulators. ISDA, via the FpML WG, will determine what fields can be delivered by July, and thereafter
Block Level Reporting
PET reporting is expected to be reported at the executed (unallocated) block level, followed by further reporting at the allocated level.
Additional Operational Benefits
At present the majority of the G16 firms have adopted a “risk mitigation” process whereby Transactions details are agreed by contacting the counterparteither by phone or by email. A general form of template is utilized by each asset class, with parties exchanging trade reference numbers upon agreement of the terms of the Transaction in most cases. This normally takes place within 5 business days of the trade date. It should however be noted that not all c/parts are willing to risk mitigate.
Risk Mitigation
Whilst Risk Mitigation has had relative success, Q4 2011 data above, the current T+5 time frame would need to be tightened significantly to meet the CFTC requirements.
Subject to agreement of the fields required for trade verification for PET Reporting and the delta to RT reporting, it is possible that a generic template solution could replace this process for the majority of the population. For the avoidance of doubt it is not expected that all of the current proposed PET fields will be captured by the GT solution. A combination of mandatory and voluntary fields will be submitted for approval by ISDA to the Regulators. Subject to feedback the PET template may be expanded to incorporate additional fields in line with reporting capabilities of the RPs.
Solution Limitations
Whilst the industry can enhance existing and introduce additional methods to verify transactions in order to meet the pre-requisite for PET reporting, without a Regulatory mandate to cover all c/parts there will be a population of trades that will not be validated.
In this case there are two options;
a)Send the PET record to the SDR but flag the record as “not-validated”
b)Do not send the PET record until such time as the record is validated
Option (a) would provide a 100% trade population and therefore provide the most accurate account of the trading population. To be determined by the Regulators, the vendor will allow for both scenarios.
Alternative method of Trade Verification
Subject to the agreed PET field template there are other methods available to the RP (reporting parties); these include Risk Mitigation and Port Reconciliation.
Portfolio Reconciliation
The majority of the SD (swap dealers)already utilize various forms of PortfolioReconciliationtools; the process is currently run on a T+1 basis. The process could be expanded to include the additional PET fields but this would require an intra-day Port-rec. process.
1