Multilateral CSA Staff Notice 91-306 Compliance Review Findings for Reporting Counterparties
Multilateral CSA Staff Notice 91-306 Compliance Review Findings for Reporting Counterparties
Multilateral CSA Staff Notice 91-306
Compliance Review Findings for Reporting Counterparties
June 6, 2019
1. Introduction
Staff of the Ontario Securities Commission (OSC) and of the Autorité des marchés financiers (AMF) (Staff or we)) are publishing this Notice to describe joint findings of reviews of compliance with derivatives reporting requirements in Ontario and Québec. These requirements are in OSC Rule 91-507 Trade Repositories and Derivatives Data Reporting (the OSC TR Rule) and AMF Regulation 91-507 respecting Trade Repositories and Derivatives Data Reporting (the AMF TR Rule), jointly referred to as the TR Rules.
The purpose of the TR Rules is to improve transparency in the over-the-counter (OTC) derivatives market. Derivatives data is essential for effective regulatory oversight of the derivatives market, including the ability to identify and address systemic risk and the risk of market abuse.
2. Focus of Compliance Reviews
These initial compliance reviews focused on reporting counterparties that are the most active{1} in the Ontario and Québec OTC derivatives markets and their compliance with requirements under the TR Rules.
3. Purpose of Compliance Reviews
The purpose of the compliance review is to:
• reinforce the importance of derivatives data reporting;
• assist reporting counterparties in better understanding their reporting obligations and the OSC's and AMF's expectations;
• assess levels of compliance with the reporting requirements of the TR Rules;
• identify obstacles to compliance with reporting requirements; and
• improve the quality of the data received by the OSC and the AMF.
4. Description of the Compliance Reviews
A joint OSC/AMF team conducted reviews between 2016 and 2018. Where appropriate, the reviews were coordinated and carried out with other regulators that have oversight of the reporting counterparties subject to the reviews.
The reviews consisted of an assessment of each reporting counterparty's compliance with OSC Rule 91-506 Derivatives: Product Determination, AMF Regulation 91-506 respecting Derivatives Determination, (jointly, the Scope Rules) and the TR Rules. This entailed a review of the reporting counterparty's policies, processes and controls related to transaction reporting and a test of their reported data.
A one-month period was selected from which all OTC derivatives transactions were provided by the reporting counterparty to the OSC and/or the AMF (depending on if the review was made jointly with the OSC and the AMF, or separately) for comparison against data received from the trade repositories. A sample of transactions was selected for more detailed testing where Staff observed data quality issues. Analysis was performed on the completeness, and accuracy of these transactions and the timeliness of their reporting and involved reviewing original transaction confirmations and source system data.
After the analysis of the selected derivatives data, Staff identified reporting issues relating to particular transactions and communicated them to the reporting counterparties under review. The reporting counterparties then undertook a review of why the issues occurred and how they could be remedied in the future.
5. Description of Compliance Tests
As part of our testing, we focused on the following areas of compliance with the requirements of the TR Rules and Scope Rules:
Compliance: whether all derivatives transactions that are reportable under the Scope Rules are reported to a designated or recognized trade repository.
Timeliness: whether all new, amendment and exit messages are reported to a designated or recognized trade repository by the T+1 reporting deadline.
Completeness: whether the fields required to be reported to a trade repository pursuant to the TR Rules have been reported.
Accuracy: whether the details contained in original transaction confirmations or source system data which are required to be reported to a designated or recognized trade repository accurately reflect transaction details received by either the OSC or the AMF (or both in some cases).
Valuation: whether valuation data has been reported to a designated or recognized trade repository according to the requirements in the TR Rules.
Controls and oversight: the existence and effectiveness of key controls, processes, policies, and procedures in place to oversee compliance with the TR Rules.
6. Observations
Based on the sample of transactions reviewed, the majority of data required to be reported to a designated or recognized trade repository was accurate, complete and reported in a timely manner. The following section contains a summary of the material instances where submitted transaction data did not meet the requirements in the TR Rules. Generally, these observations were consistent across all reporting counterparties reviewed.
As stated in section 3, the purpose of these compliance reviews is to assess, identify, assist, reinforce and improve compliance with the TR Rules. However, depending on the deficiencies identified, their frequency of occurrence and the level of post-review remediation success, we may consider additional regulatory steps to address the non-compliance.
i. Non-reporting of derivatives transactions required to be reported:
Our focus when conducting these reviews was to ensure that all activity required to be reported was being captured. Without confidence that the entire universe of OTC derivatives activity required to be reported is being collected, we cannot fully rely on the results of our analytical work.
During our review, we observed situations where a derivative product that should have been reported to a trade repository was not reported for the following reasons:
a. The transaction was incorrectly deemed to be out-of-scope of the reporting requirement.
b. The transaction was incorrectly flagged as not reportable due to an internal system mapping error.
c. Due to an incorrect application of the International Swaps and Derivatives Association (ISDA) tie-breaker methodology in the case of the OSC TR Rule, or an incorrect application of Section 25 Reporting Counterparty under the AMF TR Rule, the reporting counterparty determined it was the non-reporting counterparty and did not have the obligation to report.
d. Reporting duties delegated to a third-party service provider were not fulfilled by the third party, and controls were not in place to effectively assess if such third-parties were properly reporting the transactions.
e. Transactions that were executed, novated to a clearing agency and then terminated within the reporting counterparty's system before reaching an executed status in the reporting systems, were not reported to a designated or recognized trade repository.
ii. Reporting of transactions that are not required to be reported:
We also observed the converse issue to item (i) above where transactions being reported were not required to be reported or were required to be reported but were reported by both counterparties. Over-reporting creates redundant data through duplication and information surplus on activity outside our area of interest. Transaction duplicates also create data quality issues that require additional filtering and validation before the data can be used for analysis.
The most common examples of over-reporting include the following:
a. Incorrect product mapping whereby physically settled commodity swaps and spot foreign exchange transactions are incorrectly reported.
b. Incorrect application of the ISDA tie-breaker methodology, in the case of the OSC TR Rule, and incorrect application of Section 25 of the AMF TR Rule, caused both counterparties to determine they were the reporting counterparty and report the same transaction using different unique transaction identifiers (UTIs).
c. When a transaction was cleared but the original transaction was not terminated, two transactions with two UTIs were reported where only one UTI should exist.
d. For certain cleared transactions, beta transactions were reported by both the reporting counterparty of the alpha trade and the clearing agency when only the clearing agency should report.
iii. Transactions reported with a non-unique transaction identifier:
We also observed that some transactions were reported using a transaction identifier that was not unique. The use of a non-unique transaction identifier creates data quality issues (multiple occurrences of duplicate UTIs in the reported data) that require additional filtering and validation before the data can be used for analysis.
The most common reasons for the reporting of non-unique transaction identifiers include the following:
a. The UTI generation logic used by the reporting counterparty has flaws.
b. The transactions are executed and recorded in disparate source systems resulting in the generation of duplicate UTIs.
iv. Primary economic terms are not reported in a timely manner:
Primary economic terms must be reported to a trade repository in real time if technologically practicable, and no later than one business day after the execution date of the transaction. This gives sufficient time for the reporting counterparty to gather and report all required information.
Despite this requirement, there were many examples of transactions not being reported to a trade repository within the required timeframe, and instead being reported days, weeks or months past the deadline.
The most common reasons for late reporting include the following:
a. Transactions were rejected by the trade repository and the reporting counterparty did not have adequate systems in place to be aware of the rejection, address the reason, and rereport the transaction in a timely manner.
b. The reporting counterparty encountered processing errors which prevented the creation of valid reporting messages to be reported to the trade repository.
v. Issues reporting Legal Entity Identifiers (LEI):
The OSC's and the AMF's key method of identifying counterparties and aggregating and analysing data is through the use of the LEI code. The LEI is a unique identifier used to connect OTC derivatives data to other data sets and create a broader picture of marketplace activity. OTC derivatives transactions reported without an LEI create gaps in our data, impede our ability to aggregate activity and positions, and require additional data mapping and validation effort.
As a result, we are very concerned when transactions are submitted with anything other than an active LEI code.
During our review, we noticed, with a high degree of frequency, the following examples where an active LEI was not accurately reported when it was required:
a. Both reporting and non-reporting counterparty fields contained the same LEI. These submissions create unreliable data that are unusable for analysis.
b. The reporting counterparty did not report the LEI of the non-reporting counterparty despite an LEI for the non-reporting counterparty being available in the Global LEI Foundation (GLEIF) database. In these cases, an internal identifier or other non-LEI value was reported in place of the LEI. The primary factor causing this observation was a lack of controls over (i) trading with counterparties without an LEI and (ii) the input of counterparty information, such as the LEI, into the reporting system.
c. Either the reporting or non-reporting counterparty LEI's have lapsed. A lapsed LEI is an LEI where the associated reference data (entity name, address of headquarters, address of legal formation, etc.) has not been updated for more than one year. Since the quality of the LEI data diminishes if the reference information attached to it is inaccurate, a lapsed LEI is a sign of potentially poorer data quality.
Despite these examples, there were occasions where an LEI was not reported for legitimate reasons, including:
a. When the non-reporting counterparty is not eligible to receive an LEI as in the case where the non-reporting counterparty is a natural person.
b. When the non-reporting counterparty is an entity from a jurisdiction in which there are laws preventing the disclosure of its identity in other jurisdictions (a masking jurisdiction) and the reporting counterparty has received exemptive relief from either the AMF or the OSC not to report these LEIs.
- - - - - - - - - - - - - - - - - - - -
Expectations for obtaining and reporting counterparty LEIs
Staff expect, and the TR Rules require, that each local counterparty to a reportable transaction, if eligible, obtain an LEI and renew it annually to ensure the data is accurate.
For transactions reported in reliance on exemptive relief, Staff expect a decrease in masking for Financial Stability Board (FSB) member jurisdictions following the FSB's November 19, 2018 publication of the report Trade reporting legal barriers, Follow-up of 2015 peer review recommendations (FSB Report),{2} which details progress by FSB member jurisdictions to remove or address legal barriers to full reporting of OTC derivatives data to trade repositories.
Staff intend to give full effect to the recommendations and supplementary recommendations in the FSB Report. Accordingly, we will consider jurisdiction specific updates in the FSB Report in connection with any exemptive relief. Reporting counterparties are reminded that as a condition to exemptive relief, a reporting counterparty is required to make diligent efforts to correct any reporting in a timely basis, and further that masking relief generally ceases to be available three months after a reporting counterparty becomes aware that there is no longer a legal barrier to full reporting.
Local counterparties can obtain an LEI from several different Local Operating Units approved by the GLEIF to issue LEIs to Canadian entities. A list of these entities is available at the GLEIF web site (www.gleif.org).
- - - - - - - - - - - - - - - - - - - -
vi. Issues reporting accurate Unique Product Identifiers (UPI):
The OSC and the AMF identify OTC derivatives products using a UPI code from which transactions can be aggregated into categories of similar products for analytical purposes. If products are misclassified or not classified using an industry-standard method of identifying derivatives products, we are unable to correctly assess market trends and characteristics.
During our review, we noticed the following examples where the UPI was not accurately reported:
a. Transactions were frequently classified as being "exotic" despite belonging to a category of product where a method of classification was available that more appropriately categorized the transactions (e.g., bond forwards).
b. Transactions were classified as containing a basket of underlying assets when only one underlying asset existed.
- - - - - - - - - - - - - - - - - - - -
Expectations for classification of products by UPI
We expect reporting counterparties to use the most relevant product classification identifier when describing the type of OTC derivative product traded. This will require communicating with the trade repositories to understand the list of product identification codes available. Trade repositories should work with reporting counterparties to categorise all product types suitable for classification to minimize the use of the exotic identifier.
- - - - - - - - - - - - - - - - - - - -
vii. Incomplete or inaccurate underlying asset identifiers:
The underlying asset identifier is a critical data element in understanding trends and characteristics within the collected data. When the underlying asset is omitted, unclear or inaccurate, the transaction data is largely unusable or misleading.
During our review, we noticed the following examples where the underlying asset identifier was not accurately reported:
a. The underlying asset identifier was blank.
b. The underlying asset identifier was reported using an internal identification code rather than a universal asset identifier.
c. The underlying asset identifier was inaccurate. For example, the underlying asset was reported as a single security when the actual asset was a basket of assets.
d. The underlying asset identifier was incomplete. For example, the underlying asset was a basket of securities that did not match the list of reported underlying asset identifiers.
- - - - - - - - - - - - - - - - - - - -
Expectations for reporting the contents of swap baskets
As detailed in the Committee on Payments and Market Infrastructure (CPMI) and the International Organization of Securities Commissions' (IOSCO) Technical Guidance reports on Unique Product Identifiers{3} and Critical Data Elements{4} (together, CPMI IOSCO Technical Guidance), we expect each underlying asset of a custom basket to be identified by a universal identifier that can be recognized by the OSC and the AMF. Specifically, where an underlying asset does not have a universal identification code, we expect that it be described using a recognizable name that sufficiently describes its generic characteristics (e.g., "private_loan_internal_ID123456").
- - - - - - - - - - - - - - - - - - - -
viii. Inaccurate calculation of notional amounts:
The notional amount of an OTC derivative is a way of measuring its size and is used to better understand the level of activity in these markets. While there are several ways in which the notional amount can be calculated, our review revealed that in certain product categories, calculation methodologies were inconsistent. The OSC and the AMF are contemplating adopting international standards developed for the purpose of describing the preferred method for measuring notional amount.
In addition to inconsistent calculation methodologies, we also identified the following examples where the notional amount was not accurately reported:
a. The notional amount unit of measure was inconsistent between various sources systems which resulted in rounded notional amounts being reported to the trade repositories (e.g., 10,000,000 being reported as 10).
b. Inconsistent approaches to the calculation of notional amount for commodity and equity swaps. While guidance on how to calculate notional amount for certain products is limited, we expect reporting counterparties to adopt a consistent approach to these calculations within each asset class within their own systems.
ix. Inaccurate and incomplete reporting of primary economic terms:
Many fields representing the primary economic terms of a new transaction were found to contain inaccurate or incomplete data when compared to the transaction confirmations. This section summarizes the most important fields:
a. Price: We found that reporting counterparties use many different measures for price and that price is reported inconsistently. For example, the price of an option was represented inconsistently as either a strike price or a premium amount.
b. Cleared: Many reported transactions did not specify whether a transaction was cleared or not due to incomplete information in the Cleared Y/N field. This lack of information creates uncertainty to the regulator when trying to determine the rate at which products are being cleared.
c. Premium: Certain option transactions were reported with a nil value for the premium amount rather than the premium amount per the transaction confirmation. Missing or incorrect premium values were also noted for caps, floors, and swaptions.
d. Floating leg: Transactions were reported where fields relating to the floating leg, such as notional currency, notional amount and floating rate, were not provided or were provided with dummy values.
e. Expiration date: Inaccurate expiration dates, when compared to the original confirmation or source system data, were reported.
- - - - - - - - - - - - - - - - - - - -
Expectations for reporting the price of a derivative transaction
CPMI IOSCO Technical Guidance includes direction on the data elements used to report the price of a trade based on the product type. We expect reporting counterparties to follow this guidance and anticipate adopting them in the future.
- - - - - - - - - - - - - - - - - - - -
x. Inaccurate valuation data:
The ongoing reporting of valuation data is a critical component of the OSC's and the AMF's market analysis and systemic risk measurement functions. As a result, we are focused on ensuring that all outstanding transactions are being revalued on a daily basis, as required by the TR Rules.
During our review, we noticed many examples of incorrect valuation reporting, including:
a. No valuation amount was reported for certain outstanding transactions.
b. A valuation of $0 was reported for outstanding transactions for multiple consecutive days which led to the discovery that the correct current valuation was not being reported.
c. The same valuation amount was reported for multiple consecutive days, which led to the discovery that the correct current valuation was not being reported.
d. Valuation messages were being reported late causing the prior day's valuation to be rolled-over in the files reported to the OSC and the AMF.
xi. Inadequate processes and controls:
Staff noted various shortcomings in oversight measures that either directly caused or failed to identify many of the data quality concerns outlined above. We noticed the following examples where internal processes could be improved to more effectively monitor compliance with the TR Rules:
a. Difficulties in the ability to retrieve previously reported transaction records due to system migrations, multiple system sources, or manual processes.
b. Lack of robust reconciliation processes to detect unreported transactions.
c. Failure to monitor automated steps in the reporting process from transaction origination to submission, such as the accurate generation of Financial products Markup Language (FpML) messages prior to submission to a trade repository.
d. Inadequate oversight of client onboarding processes causing downstream issues in the reported counterparty identifier data.
e. Technological limitations of internal systems that are not capable of accurately capturing and reporting the derivatives data for certain types of transactions.
f. Inadequate controls surrounding new products traded without the required reporting solution already put in place.
g. Incomplete documentation of processes and controls.
h. Insufficient oversight of the trade reporting process by the compliance and/or audit functions.
- - - - - - - - - - - - - - - - - - - -
Expectations of practices for improving the quality of reported trade data:
Reporting counterparties should:
Coordinate with trade repositories to improve submission templates: In cases where submission templates and transactional data field specifications issued by trade repositories do not allow reporting counterparties to accurately capture all required fields, reporting counterparties are expected to notify the trade repositories of any concerns and work towards rectifying the templates and/or field specifications to reflect the terms of the transactions. For example, reporting counterparties should work closely with trade repositories to reduce the amount and types of transactions with the product identification classification of "exotic" and develop agreed upon methods to accurately report these types of products.
Perform substantive sample testing: Reporting counterparties were noted to primarily rely on internal controls to monitor compliance with the TR Rules. We recognize that implementation and monitoring of internal controls serves a critical function, however, it is also important to complement existing controls through substantive testing of transaction data. This type of testing, in which transactions are traced through the reporting life cycle, is essential to identify areas for improvement that may not be captured by controls alone.
Report errors or omissions: Upon discovery of a system or process breakdown, Staff expect reporting counterparties to evaluate the impact on previously reported data in addition to implementing necessary fixes to address the error on a go-forward basis. Reporting counterparties should appropriately oversee the resubmission of any live trade data upon the discovery of an error in the reported data. Reporting counterparties are expected to report errors or omissions in reported derivatives data to the relevant trade repository as soon as technologically practicable upon discovery of the error or omission, and in no event later than the end of the business day following the day of discovery. In instances where a significant error or omission has occurred impacting a substantial number of transactions, we would expect the reporting counterparty to notify the relevant authority, as soon as practicable, describing the general nature of the error or omission, number of transactions impacted, date and duration of error, steps taken to remedy the error or omission and any planned remediation steps.
Seek clarification from Staff for novel reporting issues: Given the complexity and breadth of the transactions being reported, additional guidance or coordination with Staff may be warranted to cover reporting intricacies not otherwise explicitly addressed. As a result, Staff encourage reporting counterparties to seek further clarification from Staff when necessary to proactively improve the quality of reported data and ensure novel reporting issues are addressed in a consistent manner.
- - - - - - - - - - - - - - - - - - - -
7. Summary of Root Causes and Remedies
The main goal of the reviews is to identify incorrect data reporting, determine the source of the errors, fix the problem and, as a result, improve the quality of the data we receive and use in our analysis.
This section details some of the general root causes of the issues identified in the previous section and the types of remedies that have been implemented or recommended. All reporting counterparties should review these root causes and remedies when assessing the performance and accuracy of their own trade reporting systems and responsibilities.
i. Mapping issues:
On multiple occasions, the reporting counterparties identified mapping issues to be the root cause of incorrect product identifiers, underlying asset identifiers and prices. A mapped field exists when a combination of one or more data fields is transformed using a pre-defined sequence of calculations, into a final (mapped) value which is generated and submitted to the trade repository. A mapping issue can exist for many reasons, including data errors within mapping tables, coding issues and data entry issues. Once a mapping issue is identified and fixed, the incorrect reported data is typically resolved, and no further action is required.
ii. Control breakdowns:
We identified areas in reporting processes where more stringent controls would have prevented the reporting of internal client identifier codes and lapsed LEIs instead of active LEIs. In addition, instances were noted where control processes correctly flagged non-reported transactions as requiring remediation, but these processes were not vigorous enough for the errors to be addressed in a timely manner. Lastly, we identified scenarios where accuracy issues were identified by existing controls and corrected on a go-forward basis; however, data resubmissions were not made for live transactions previously reported with the inaccurate data.
iii. Oversight of third-party service providers:
We noted instances where some reporting obligations had been delegated to third-party service providers. An overall lack of oversight by reporting counterparties over these delegated responsibilities can be attributed to some of the reporting issues identified. In particular, some reporting counterparties do not have a line of sight to verify whether service providers report all reportable transactions to a trade repository. Additionally, we found reporting counterparties may be unable to assess whether the delegated data to be reported is accurate and reported within the required timeframes. Oversight measures are necessary as reporting counterparties may delegate reporting obligations but ultimately remain responsible for ensuring the timely and accurate reporting of derivatives data required by the TR Rules.
iv. Reconciliation issues:
Often, the root cause of a non-reported transaction was the absence of a reconciliation process to review transaction submissions. A reconciliation of transactions that should be received by the trade repository enables reporting counterparties to confirm that transactions are being reported by counterparties as well as to ensure that reported information is agreed to by both counterparties.
A reconciliation process to monitor the timeliness of data submissions would also have prevented situations where creation data for transactions was submitted several days beyond the timelines required by the TR Rules. Control measures are important to identify issues such as transactions executed but not yet reported, or transactions rejected by the trade repository and not resubmitted. Such a reconciliation allows reporting counterparties to identify issues in the timeliness of submissions and initiate further investigations to determine the cause of any delays.
v. TR Rule Interpretations:
Often, the source of the incorrect reported data was a misunderstanding of what is required under the TR and Scope Rules. Further clarification from the OSC and/or the AMF on how to report certain mandatory data fields, such as Price, Unique product identifier, Notional amount and Counterparty side will assist reporting counterparties to correctly report this data.
In some cases, however, an incorrect interpretation of the TR Rules resulted in incomplete data being submitted to the trade repository. Specifically, there were many instances where a reporting counterparty only submitted data flagged as mandatory by the trade repository submission templates, resulting in transactions missing many key economic fields. Reporting counterparties should not rely on a trade repository's mandatory fields and should submit all data required by the TR Rules.
Another frequent example of an incorrect interpretation of the TR Rules was the non-reporting of transactions between affiliates. Inter-affiliate transactions are required to be reported.
vi. Lack of validation processes at TRs:
Validation processes at the trade repositories would, theoretically, prevent some invalid data from being sent to the OSC and/or the AMF. We expect trade repositories to utilize data validation processes in their systems to the extent possible and we intend, in the near future, to provide guidance and requirements on the types of validations that should be introduced. For example, trade repositories may be required to reject submitted transactions that have incomplete relevant data fields.
8. Conclusions and Next Steps
Since the completion of these reviews, we have observed an improvement in the quality of the reported data. This is due, in large part, to dialogue between the regulators, trade repositories and reporting counterparties on how trade data should be reported, where processes can be improved and what regulators' expectations are. Continued co-ordination is necessary to improve the data quality even further.
With the CPMI and IOSCO guidance to standardize derivative transaction terms complete, it will be incorporated into reporting requirements either in the form of changes to the TR Rules or through changes in trade repository work flows.
Working with trade repositories to improve their data vetting and validation systems will reduce the amount of poor-quality data entering their systems and in turn ours. Building processes that reject transactions missing key pieces of data is a potential solution as is agreeing to use standardized forms or templates to ingest data for certain products on a consistent basis.
The OSC and the AMF will continue to perform these reviews, including focusing on foreign based reporting counterparties, to better understand the issues that these entities face when complying with our rule.
As is our normal process, depending on the deficiencies identified during a review, we may consider recommending further regulatory action to remediate the deficiencies.
Questions
Please refer your questions to any of the following:
{1} "Most active" refers to entities with the largest number of reported trades as the reporting counterparty which collectively represented approximately 70% of outstanding notional submitted as of October 2018.
{2} http://www.fsb.org/wp-content/uploads/P191_1_18-4.pdf.
{3} https://www.iosco.org/library/pubdocs/pdf/IOSCOPD580.pdf.
{4} https://www.iosco.org/library/pubdocs/pdf/IOSCOPD611.pdf.