European Union: New ESMA Guidance On EMIR Transaction Reporting

ESMA published a revised set of Q&As on EMIR on 11 February, the eve of the EMIR transaction reporting go-live date. They include updates and new guidance in several areas, including transaction reporting.

This Client Alert pulls together the relevant new/modified sections from the latest Q&As (available at: http://www.esma.europa.eu/content/QA-VI-EMIR-Implementation) applicable to the 12 February EMIR reporting start date. We have reproduced those sections below with added commentary. The aim is to assist those who will need to ensure that their reporting set-up incorporates this new guidance to focus on the main points of relevance to them.

Our commentary is in dark red – for ease of reference. Pages 69 to 71 of the Q&As also include transaction reporting scenarios applicable to OTC trades. We have not reproduced them here.

There is a statement on ESMA's website mentioning the new Q&As saying that "ESMA appreciates that it will require a certain amount of time for both reporting firms and TRs to properly incorporate this further guidance." See http://www.esma.europa.eu/news/ESMA-provides-further-details-trade-reporting-updated-EMIR-QA?t=326&o=home.

  • TR Question 4(b): Reporting of outstanding positions following the entry into force of EMIR (Backloading)

Commentary: This is a modification as opposed to a new question and reflects a clarification of previous guidance. It is reflective of what we and many others in the market had understood to be the position in any event. Nevertheless, it provides an additional degree of comfort that this common understanding was correct. The underlined language reflects the modification.

Q: Should information on valuation and collateral be reported for contracts entered into from 16 August 2012?

A: OTC derivatives transactions that are still outstanding on the date when the reporting obligation for this information comes into force (i.e. 180 days after the reporting start date) will need to include the information on valuation and collateral as from the date of the reporting obligation and not for all the days from 16 August 2012 to the date of the application of the reporting obligation pursuant to Article 5 of Commission Implementing Regulation (EU) No 1247/2012 of 19 December 2012 laying down implementing technical standards with regard to the format and frequency of trade reports to trade repositories according to Regulation (EU) No 648/2012 of the European Parliament and of the Council on OTC derivatives, central counterparties and trade repositories. Similarly, contracts that were terminated before the reporting obligation starts applying should not include the information on collateral and valuation.

  • TR Question 10(d) – Codes: LEI (Legal Entity Identifier)

Commentary: This may make it difficult for European entities to enter into reportable EMIR trades with counterparties in jurisdictions where local law or regulation prevents information about that counterparty from being reported.

Q: If a counterparty is established in a third country whose legal framework prevents the disclosure of its identity by the European counterparty subject to the reporting obligation, how should the European counterparty fill the counterparty field?

A: Article 9(5) EMIR provides that at least the identities of the parties to the derivative contracts should be reported to trade repositories. This requirement cannot be waived. Therefore, a European counterparty dealing with counterparties that cannot be identified because of legal, regulatory or contractual impediments, would not be deemed compliant with Article 9(5) of EMIR.

  • TR Question 18 – Article 9 of EMIR – Reporting to TRs: UTI construction

Commentary: As a matter of practicality it seems likely that most market participants would use either method 1 or method 2 to generate a UTI (Unique Trade Identifier), but ESMA prescribes certain alphanumerical characters as pre-defined prefixes dependent upon which method is used. You may have already had similar information if, and to the extent that, you have been told this by your TR (Trade Repository), but it is worthwhile highlighting this where you will be responsible for generating UTIs as this is the first time these methods have been set out by ESMA in its guidance on trade reporting.

The use of "should be allowed to be used" in the first paragraph below suggests that it is not mandatory to use the same trade identifier where the same trade is subject to two reporting obligations in different jurisdictions. Similarly, the use of "could" in the second last sentence suggests that Unique Swap Identifiers under Dodd-Frank can be, but are not required to be, used where a trade is reportable under both regimes.

The requirement to agree which form of a Unique Trade ID they will use (i.e. which generation method) before reporting a derivative contract may lead to some consternation and last minute emails between counterparties. Taking a pragmatic approach, if parties have already entered into reporting delegation agreements or have agreed which of them will be responsible for generating the UTI, then the policy aim behind this (i.e to avoid competing methods being used) should be achieved. If an agreement gives the generating party or the delegate a wide discretion then this may suffice as agreement to abide by the decision of that generating party as to which generation method is used. As a matter of good housekeeping, parties who generate UTIs on this basis may want to inform their counterparties which method they are using and that they have decided to use it in exercise of their agreed discretion.

Q: How to construct a Unique Trade ID?

A: Commission Delegated Regulation (EU) No 148/2013 specifies that in the absence of a Trade ID agreed at the European Level, a unique code should be generated and agreed with the other counterparty (Table 2, field 8). This means that only one Trade ID should be applicable to any one derivative contract that is reported to a trade repository under EMIR and that the same Trade ID is not used for any other derivative contract. It is also acknowledged that contracts reported under EMIR rules might also be reported under the rules of other jurisdictions. Hence, the same Trade ID should be allowed to be used in both those jurisdictions for reporting the given contract in order to facilitate the reconciliation among all the data sets.

Commission Implementing Regulation (EU) No 1247/2012 specifies that the Trade ID can have up to 52 characters. Therefore a Trade ID that is less than 52 characters in length is permissible provided that it meets the other criteria laid out here. There is no requirement to pad out Trade ID values to make them 52 characters long.

As an illustration, ESMA considers that any of the methods provided in the following list of Trade ID construction would be deemed to meet the requirements for reporting under EMIR. ESMA reserves the initial three character sequences 'E00' to 'E99' inclusive for these purposes. The Trade ID should be formed by the concatenation (without separators) of the three elements in each case.

Method 1:

a. The characters 'E01'. The characters '000' will also be permitted but only for derivative contracts executed before 12 February 2015.

b. The MIC code (ISO 10383) of the applicable trading venue.

c. A unique code generated by that trading venue or by a CCP used by that trading venue to clear the derivative contract. If the CCP generates the code and if derivative contracts executed on that trading venue could be cleared by more than one CCP, then measures should be put in place to avoid different CCPs generating the same value.

Method 2:

    a. The characters 'E02'.

    b. The (20 character) Legal Entity Identifier of the generating entity (normally one of the parties to the trade).

    c. A unique code generated by the Unique Trade ID generating entity.

Method 3:

    a. The characters 'E03'.

    b. A unique code generated independently by both counterparties based on the pre-agreed set of information about the trade in such a way that both counterparties will arrive at the same code and that it would be unique with respect to any other report. The two counter-parties are responsible for providing the same code. The information used should include Common Data from Table 2 of the Commission Delegated Regulation (EU) No 148/2013 and the Legal Entity Identifiers of the two counterparties.

Method 4:

Note that ESMA considers this approach as sub-optimal and therefore intends to maintain it as a possibility only for derivative contracts that have been or will be entered into before 12 February 2015:

    a. The characters 'E04' or '000'.

    b. An identifier of the generating entity other than the full Legal Entity Identifier (normally one of the parties to the trade).

    c. A unique code generated by the Unique Trade ID generating entity.

For derivative contracts that are also reportable under the provisions of the Dodd-Frank Act, the same value as would be reported under the Dodd-Frank Act, i.e. the Unique Swap Identifier, could be used.

Counterparties should agree which form of a Unique Trade ID they will use before reporting the derivative contract. This therefore includes determining the approach that they will use to define which entity generates the Unique Trade ID.

  • TR Question 19 – Article 9 of EMIR – Reporting to TRs: UTI generation

Q: What criteria should be applied by the two counterparties to determine the one that would generate the Unique Trade ID?

A: ESMA would like to stress the importance of the general obligation according to which the counterparties need to agree the report's contents before submitting it to TRs. This obligation stems from the requirement of Article 9(1) of EMIR, 'counterparties and CCPs shall ensure that the details of their derivative contracts are reported without duplication' and is specified in the European Commission's Frequently Asked Questions document Section II Question 5:
http://ec.europa.eu/internal_market/financial-markets/docs/derivatives/emir-faqs_en.pdf

At the same time, ESMA believes that there might be merits to suggest a non-binding approach that could be followed by counterparties in case of disagreement on the responsibility to generate a Unique Trade ID. This approach is suggested without prejudice to other arrangements on the generation of a Unique Trade ID that counterparties might agree on.

The generation and communication of the Unique Trade ID should occur at the earliest possible stage in the trade flow.

The following order of preference could be suggested for generation and communication of the Unique Trade ID:

  • For centrally executed and cleared trades the code could be generated either:
    • by execution venue for its member or
    • at the point of clearing by the CCP for the clearing member. Subsequently, the Unique Trade ID could be generated by the clearing member for its counterparty (e.g. MiFID investment firm).
  • For centrally confirmed and cleared trades – at the point of clearing by the CCP for the clearing member.
  • For centrally confirmed but not cleared trades – at the point of confirmation (by the confirmation platform).
  • For other trades, the following hierarchy could be followed:
    • Financial counterparty generating the Unique Trade ID for their non-financial counterparty;
    • Non-financial counterparty above the clearing threshold generating the Unique Trade ID for their non-financial counterparty below the clearing threshold;
    • Within the same group of entities in case of disagreement the seller generates the Unique Trade ID.

TR Question 20 – Article 9 of EMIR – Reporting to TRs:

Empty fields

Commentary:

ESMA has said it appreciates time will be required for parties to fully comply with this updated guidance. Nevertheless, if parties are able to incorporate this part of the guidance into their transaction reports at an early stage, it may save them having to go back and complete these fields in reports they have already submitted if ESMA requires all submitted reports to follow this format.

Q: Are all fields specified in the Annex of the Commission Delegated Regulation (EU) No 148/2013 mandatory?

A: In general, all fields specified in the RTS are mandatory. Nevertheless, two different instances need to be acknowledged, namely:

1. The field is not relevant for a specific type of contract/trade, for example:

  • settlement date field where the underlying is an index,
  • commodity underlying field in case of equity derivatives,
  • Domicile of the Counterparty in case of coverage by LEI.

2. The field is relevant for a given type of contract/trade, however:

a. there is a legitimate reason why the actual value of this field is not being provided at the time the report is being submitted, or

b. none of the possible values provided for in the Annex of the Commission Implementing Regulation (EU) 1247/2012 for a given field apply to the specific trade (e.g. in the case of report submitted by the CCP, field No 7 in the Table 1 Counterparty Data).

In order to enable the TRs distinguishing between the two instances above and allow them to comply with requirements of Article 19 of the Commission Delegated Regulation (EU) 150/2013 (in particular to verify the compliance of the reporting counterparty or submitting entity with the reporting requirements), a different approach should be envisaged when it comes to population of the not-relevant and relevant fields.

In the first case, since the field is not relevant for a given trade, it should be left blank.

In the second case, the mandatory relevant field should not be left blank and should include the NA value instead.

  • TR Question 21 – Article 9 of EMIR – Reporting to TRs: UPI taxonomy

Commentary: Although most of this is unlikely to be news to most reporting parties, it is worth bearing in mind the clarification in point 4 that proprietary classification identifiers provided by TRs should not be used to complete data fields 2 and 3 of the Common Data section of a transaction report.

Q: In the absence of a Unique Product Identifier taxonomy endorsed in Europe, what identifiers should be used for derivative contracts for which neither ISIN nor AII codes are available?

A: According to Article 4(3) of the Commission Implementing Regulation (EU) No 1247/2012 in cases where a unique product identifier does not exist and a derivative contract cannot be identified by using the combination of ISIN or AII with the corresponding CFI code, the type of derivative contract shall be identified through the Interim taxonomy on the following basis:

1. The derivative class (field No 2 in the Table 2 Common data) shall be identified as one of the following:

    a. commodities;

    b. credit;

    c. foreign exchange;

    d. equity;

    e. interest rate;

    f. other.

2. The derivative type (field No 3 in the Table 2 Common data) shall be identified as one of the following:

    a. contract for difference;

    b. forward rate agreement;

    c. forwards;

    d. futures

    e. options;

    f. swaps;

    g. other.

3. In case of derivative contracts not falling into a specific derivative class or type, the report shall be made on the basis of the derivative class or derivative type that the counterparties agree the derivative contract most closely resembles.

4. In the absence of UPI taxonomy endorsed in Europe, no other taxonomy, classification or code should be used to populate these fields (i.e. Fields No 2 and 3 in the Table 2 Common data). If the Trade Repository offers a proprietary classification or taxonomy it could be used to populate other additional fields provided for by the given Trade Repository, but it should not be used for population of Fields No 2 and 3 referred to above.

  • TR Question 22 – Article 9 of EMIR – Reporting to TRs: Venues with AII codes

Q: How to determine whether a particular contract has to be identified by the ISIN code or by the AII codes?

A: Derivative contracts traded on trading venues in the European Union and classified as the AII venues should be identified by the combination of the AII and CFI codes. The full list of such regulated markets (flagged as the AII venues in the 'Instrument Identifier' column) can be found in the MiFID Data Base (in the 'Regulated Markets' section) published on the ESMA website: http://mifiddatabase.esma.europa.eu/Index.aspx?sectionlinks_id=23&language=0&pageName=REGULATED_MARKETS_Display&subsection_id=0. Note that only the AII and CFI codes should be used for AII venues to ensure consistent reporting. For options and futures traded on MTFs the involved MTF should be consulted.

Derivative contracts traded on any other venues should be identified either by the ISIN code if available or, where ISIN code is not available, the Interim taxonomy as specified in Article 4(3) of the Commission Implementing Regulation (EU) No 1247/2012.

  • TR Question 23 – Article 9 of EMIR – Reporting to TRs: AII code

Q: How to populate field No 2 (Product ID 1) in the Table 2 Common Data for the AII derivative contracts?

A: Field No 2 should be populated with the Exchange Product Code assigned by the Regulated Market. At the same time field No 10 (Venue of execution) in the Table 2 Common Data should be populated with the MIC code of the venue of execution and not with 'XOFF' or 'XXXX'.

  • TR Question 24 – Article 9 of EMIR – Reporting to TRs: Buy/Sell indicator for swaps

Q: How should the field No 13 (Counterparty side) in the Table 1 Counterparty data be populated for the Equity, Debt and Dividend swaps?

A: As a general principal, the buyer of the Equity Swap should be the Fixed Rate Payer (the buyer is the one who receives the equity performance).
In case of Equity Swap – the buyer of the Equity Swap is the one who gets the risk of the price movement of the underlying (the Fixed Rate Payer and Equity Amount Receiver). So the seller is the Equity Amount Payer and Fixed Rate Receiver.

In case of the Equity Swap with two equity legs – the buyer of the Equity Swap is the one who gets the risk of the price movement of the underlying.

In case of Debt Swap – the buyer of the Debt Swap is the one who gets the risk of the price movement of the bond. So the seller is the Bond Performance Amount Payer and Fixed Rate Receiver.

In case of Dividend Swap – the buyer of the Dividend Swap is the one who receives the equivalent actual dividend payments, so the seller is the Dividend Payer and Fixed Rate Receiver.

  • TR Question 25 – Article 9 of EMIR – Reporting to TRs: Decimal values in fields No 15 and 16

Q: Are decimal values allowed in the fields No 15 (Price multiplier) and 16 (Quantity) in the Table 2 Common data?

A: Yes, the specified format of up to 10 numerical digits should be understood as also allowing for the decimal values.

  • TR Question 26 – Article 9 of EMIR – Reporting to TRs: Complex Contracts

Q: How the following cases should be reported:

    a. A contract stemming from another contract (e.g. option on a future)

    b. Trading strategies (e.g. Straddle or butterfly trades)

    c. A transaction with 2 legs

A: 

    a. If the first contract ceases to exist before giving rise to the second one which is materially different from the first one, the two contracts should be reported separately. Therefore, even though the two contracts are connected in the way they come into existence, they should be reported in two separate reports.

    b. The two (or more) derivative contracts related to the same trading strategies should be reported separately.

    c. Both legs of the contract should be reported in one report, where the combination of fields in the Annex of the Commission Delegated Regulation (EU) No 148/2013 provides for this. Otherwise, a report per leg should be submitted.

  • TR Question 27 – Article 9 of EMIR – 'Leg 1' and 'Leg 2' fields

Q: Which leg of the transaction should be assigned to the 'Leg 1' field and which one to the "Leg 2"?

A: As these fields are included in the Table 2 as Common data, counterparties are expected to agree a consistent approach to assigning each leg to the respective field in the report. Lack of agreement would lead to reconciliation problems at the TR level.
The obligation to agree the reports content stems from the requirement of Article 9(1) of EMIR, 'counterparties and CCPs shall ensure that the details of their derivative contracts are reported without duplication' and is specified in the European Commission's Frequently Asked Questions document Section II Question 5: http://ec.europa.eu/internal_market/financial-markets/docs/derivatives/emir-faqs_en.pdf.

Client Alert 14-048

The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.

To print this article, all you need is to be registered on Mondaq.com.

Click to Login as an existing user or Register so you can print this article.

Authors
 
In association with
Related Video
Up-coming Events Search
Tools
Print
Font Size:
Translation
Channels
Mondaq on Twitter
 
Register for Access and our Free Biweekly Alert for
This service is completely free. Access 250,000 archived articles from 100+ countries and get a personalised email twice a week covering developments (and yes, our lawyers like to think you’ve read our Disclaimer).
 
Email Address
Company Name
Password
Confirm Password
Position
Mondaq Topics -- Select your Interests
 Accounting
 Anti-trust
 Commercial
 Compliance
 Consumer
 Criminal
 Employment
 Energy
 Environment
 Family
 Finance
 Government
 Healthcare
 Immigration
 Insolvency
 Insurance
 International
 IP
 Law Performance
 Law Practice
 Litigation
 Media & IT
 Privacy
 Real Estate
 Strategy
 Tax
 Technology
 Transport
 Wealth Mgt
Regions
Africa
Asia
Asia Pacific
Australasia
Canada
Caribbean
Europe
European Union
Latin America
Middle East
U.K.
United States
Worldwide Updates
Check to state you have read and
agree to our Terms and Conditions

Terms & Conditions and Privacy Statement

Mondaq.com (the Website) is owned and managed by Mondaq Ltd and as a user you are granted a non-exclusive, revocable license to access the Website under its terms and conditions of use. Your use of the Website constitutes your agreement to the following terms and conditions of use. Mondaq Ltd may terminate your use of the Website if you are in breach of these terms and conditions or if Mondaq Ltd decides to terminate your license of use for whatever reason.

Use of www.mondaq.com

You may use the Website but are required to register as a user if you wish to read the full text of the content and articles available (the Content). You may not modify, publish, transmit, transfer or sell, reproduce, create derivative works from, distribute, perform, link, display, or in any way exploit any of the Content, in whole or in part, except as expressly permitted in these terms & conditions or with the prior written consent of Mondaq Ltd. You may not use electronic or other means to extract details or information about Mondaq.com’s content, users or contributors in order to offer them any services or products which compete directly or indirectly with Mondaq Ltd’s services and products.

Disclaimer

Mondaq Ltd and/or its respective suppliers make no representations about the suitability of the information contained in the documents and related graphics published on this server for any purpose. All such documents and related graphics are provided "as is" without warranty of any kind. Mondaq Ltd and/or its respective suppliers hereby disclaim all warranties and conditions with regard to this information, including all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement. In no event shall Mondaq Ltd and/or its respective suppliers be liable for any special, indirect or consequential damages or any damages whatsoever resulting from loss of use, data or profits, whether in an action of contract, negligence or other tortious action, arising out of or in connection with the use or performance of information available from this server.

The documents and related graphics published on this server could include technical inaccuracies or typographical errors. Changes are periodically added to the information herein. Mondaq Ltd and/or its respective suppliers may make improvements and/or changes in the product(s) and/or the program(s) described herein at any time.

Registration

Mondaq Ltd requires you to register and provide information that personally identifies you, including what sort of information you are interested in, for three primary purposes:

  • To allow you to personalize the Mondaq websites you are visiting.
  • To enable features such as password reminder, newsletter alerts, email a colleague, and linking from Mondaq (and its affiliate sites) to your website.
  • To produce demographic feedback for our information providers who provide information free for your use.

Mondaq (and its affiliate sites) do not sell or provide your details to third parties other than information providers. The reason we provide our information providers with this information is so that they can measure the response their articles are receiving and provide you with information about their products and services.

If you do not want us to provide your name and email address you may opt out by clicking here .

If you do not wish to receive any future announcements of products and services offered by Mondaq by clicking here .

Information Collection and Use

We require site users to register with Mondaq (and its affiliate sites) to view the free information on the site. We also collect information from our users at several different points on the websites: this is so that we can customise the sites according to individual usage, provide 'session-aware' functionality, and ensure that content is acquired and developed appropriately. This gives us an overall picture of our user profiles, which in turn shows to our Editorial Contributors the type of person they are reaching by posting articles on Mondaq (and its affiliate sites) – meaning more free content for registered users.

We are only able to provide the material on the Mondaq (and its affiliate sites) site free to site visitors because we can pass on information about the pages that users are viewing and the personal information users provide to us (e.g. email addresses) to reputable contributing firms such as law firms who author those pages. We do not sell or rent information to anyone else other than the authors of those pages, who may change from time to time. Should you wish us not to disclose your details to any of these parties, please tick the box above or tick the box marked "Opt out of Registration Information Disclosure" on the Your Profile page. We and our author organisations may only contact you via email or other means if you allow us to do so. Users can opt out of contact when they register on the site, or send an email to unsubscribe@mondaq.com with “no disclosure” in the subject heading

Mondaq News Alerts

In order to receive Mondaq News Alerts, users have to complete a separate registration form. This is a personalised service where users choose regions and topics of interest and we send it only to those users who have requested it. Users can stop receiving these Alerts by going to the Mondaq News Alerts page and deselecting all interest areas. In the same way users can amend their personal preferences to add or remove subject areas.

Cookies

A cookie is a small text file written to a user’s hard drive that contains an identifying user number. The cookies do not contain any personal information about users. We use the cookie so users do not have to log in every time they use the service and the cookie will automatically expire if you do not visit the Mondaq website (or its affiliate sites) for 12 months. We also use the cookie to personalise a user's experience of the site (for example to show information specific to a user's region). As the Mondaq sites are fully personalised and cookies are essential to its core technology the site will function unpredictably with browsers that do not support cookies - or where cookies are disabled (in these circumstances we advise you to attempt to locate the information you require elsewhere on the web). However if you are concerned about the presence of a Mondaq cookie on your machine you can also choose to expire the cookie immediately (remove it) by selecting the 'Log Off' menu option as the last thing you do when you use the site.

Some of our business partners may use cookies on our site (for example, advertisers). However, we have no access to or control over these cookies and we are not aware of any at present that do so.

Log Files

We use IP addresses to analyse trends, administer the site, track movement, and gather broad demographic information for aggregate use. IP addresses are not linked to personally identifiable information.

Links

This web site contains links to other sites. Please be aware that Mondaq (or its affiliate sites) are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of these third party sites. This privacy statement applies solely to information collected by this Web site.

Surveys & Contests

From time-to-time our site requests information from users via surveys or contests. Participation in these surveys or contests is completely voluntary and the user therefore has a choice whether or not to disclose any information requested. Information requested may include contact information (such as name and delivery address), and demographic information (such as postcode, age level). Contact information will be used to notify the winners and award prizes. Survey information will be used for purposes of monitoring or improving the functionality of the site.

Mail-A-Friend

If a user elects to use our referral service for informing a friend about our site, we ask them for the friend’s name and email address. Mondaq stores this information and may contact the friend to invite them to register with Mondaq, but they will not be contacted more than once. The friend may contact Mondaq to request the removal of this information from our database.

Security

This website takes every reasonable precaution to protect our users’ information. When users submit sensitive information via the website, your information is protected using firewalls and other security technology. If you have any questions about the security at our website, you can send an email to webmaster@mondaq.com.

Correcting/Updating Personal Information

If a user’s personally identifiable information changes (such as postcode), or if a user no longer desires our service, we will endeavour to provide a way to correct, update or remove that user’s personal data provided to us. This can usually be done at the “Your Profile” page or by sending an email to EditorialAdvisor@mondaq.com.

Notification of Changes

If we decide to change our Terms & Conditions or Privacy Policy, we will post those changes on our site so our users are always aware of what information we collect, how we use it, and under what circumstances, if any, we disclose it. If at any point we decide to use personally identifiable information in a manner different from that stated at the time it was collected, we will notify users by way of an email. Users will have a choice as to whether or not we use their information in this different manner. We will use information in accordance with the privacy policy under which the information was collected.

How to contact Mondaq

You can contact us with comments or queries at enquiries@mondaq.com.

If for some reason you believe Mondaq Ltd. has not adhered to these principles, please notify us by e-mail at problems@mondaq.com and we will use commercially reasonable efforts to determine and correct the problem promptly.