|UTI - Trade ID for EMIR derivatives reporting purposes|
Page 1 of 2
EMIR Regulation contains a requirement that UTI is unique but the issues how it should be generated or by whom have been initially not specified at the legislative level.
This imperfection has been rectified in the Commission Implementing Regulation (EU) 2017/105 of 19 October 2016 amending Implementing Regulation (EU) No 1247/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, which introduced unambiguous rules determining the entity responsible for generating UTI to be assigned to the EMIR trade report where counterparties fail to agree thereon.
ESMA did not yet receive any formal request to endorse a UTI framework and there are no details yet on how these will look like (save for ACER's recent UTI designation initiative as described in draft Annex IV to the REMIT Trade Reporting User Manual – Guidance on UTI, as well as Technical Guidance of the Committee on Payments and Market Infrastructures and the Board of the International Organization of Securities Commissions - Harmonisation of the Unique Transaction Identifier of February 2017- see below).
Pending the agreement on a single approach for the construction of the Trade ID at the European level, the Trade ID should be based on a unique code generated and agreed with the other counterparty before entering into any derivative trade.
Only one Trade ID should be applicable to any one derivative contract that is reported to a trade repository under EMIR and the same Trade ID musn't be used for any other derivative contract (however, the question arises whether the trade repository is under the obligation to verify the uniqueness of the Trade ID reported).
It is, moreover, 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 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.
Entities eligible to assign UTI
Commission Delegated Regulation 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.
So, as it stands from EMIR technical standards on reporting, if there is no endorsed UTI, a code should be bilaterally assigned by the counterparties and be assigned by the venue operator, confirmation platform or the CCP.
ESMA underlined moreover that there is a general obligation according to which the counterparties need to agree the report's contents (the UTI including) before submitting it to trade repository.
This obligation stems from the requirement of Article 9(1) of EMIR, which reads: "counterparties and CCPs shall ensure that the details of their derivative contracts are reported without duplication", and is, moreover, expressly spelled out in the European Commission's Frequently Asked Questions document Section II Question 5, as well as in the Recital 1 to the Commission Delegated Regulation (EU) of 19.10.2016 amending Commission Delegated Regulation (EU) No 148/2013 supplementing Regulation (EU) No 648/2012 of the European Parliament and of the Council on OTC derivatives, central counterparties and trade repositories with regard to regulatory technical standards on the minimum details of the data to be reported to trade repositories.
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 has been suggested by ESMA for generation and communication of the Unique Trade ID:
1. 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.
2. For centrally confirmed and cleared trades - at the point of clearing by the CCP for the clearing member.
3. For centrally confirmed but not cleared trades – at the point of confirmation (by the confirmation platform).
4. 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.
The above rules had initially the character of ESMA's recommendations, however, due to the low pairing rates of the trade repository reconciliation process, ESMA in the Consultation Document, Review of the technical standards on reporting under Article 9 of EMIR of 10 November 2014 (ESMA/2014/1352 assessed that an additional prescriptive rule should be included to account for the cases where counterparties fail to agree on the responsibility to generate a UTI.
Hence, it was proposed to introduce a specific provision - reflecting the above hierarchy - into EMIR Implementing Technical Standards. In this way the rules prescribing which reporting entity is responsible for the creation and transmission of the UTI in the absence of agreement between counterparties, will have the force of law.
That said, Annex 2 to the Final Report Review of the Regulatory and Implementing Technical Standards on reporting under Article 9 of EMIR of 13 November 2015 (ESMA/2015/1645) proposed the respective UTI governing framework, which has been subsequently incorporated into the aforementioned Commission Implementing Regulation of 19.10.2016.
While submitting the above EMIR reporting ITS amendments ESMA argued that where two counterparties cannot agree on which of them should generate a unique trade identifier within the reporting timeline provided, the two reports pertaining to the same transaction will not be identified consistently. It is therefore necessary to establish criteria for the generation of unique trade identifiers so as to avoid double-counting of the same transaction.
As is clearly visible, above ESMA's reasoning became the basis for the formulation of Recital 6 of the said Regulation of 19.10.2016.
Metods for establishing UTI
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.
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.
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.
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 counterparties 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.
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.
Practically, as media report, the process for assigning the UTI is confused by different approaches taken by clearing houses, "some of which have provided UTIs on cleared trades to member firms, while others have only provide guidance and left it to their members to generate the UTI themselves" (Financial News "Emir reporting rules set for stronger enforcement").
There are also available the respective commercial services like for instance Trioptima UTI Pairing Functionality.
In the absence of officially-endorsed UTI generation standard the derivatives' industry makes its own efforts to set the relevant procedures - see, for example:
- the periodically updated ISDA manual Unique Trade Identifier (UTI): Generation, Communication and Matching, as of 2014 October 2 or
UTI generation for cleared trades
ESMA's Discussion Paper, The trading obligation for derivatives under MiFIR, 20 September 2016, ESMA/2016/1389 (p. 42) draws the attention to the fact that under EMIR, a bilateral trade that is subsequently cleared can be reported several times, each time under a new Trade ID.
As an illustration, a bilateral trade between a Counterparty 1 (CT1) and Counterparty 2 (CT2), both within the EEA, which is subsequently cleared, can be reported several times with several trade IDs that cannot be easily matched.
It could be reported first as a bilateral trade between CT1 and CT2, and then as two cleared trades, one between CT1 and its CCP and one between CT2 and its CCP, with both sides of the trades reporting in each case.
This can be further complicated when counterparties use the services of clearing members, thus adding further reports to the dataset.
If in some cases when UTIs have to be changed after the initial report, the counterparties will have the choice to enter a report within the reporting deadline and subsequently modify it (due to issues with the UTI or other fields), or not to report it at all or to report it late.
However, due to exposure to potential legal sanctions the latter options are rather theoretical in nature.
The separate issue to be faced under EMIR reporting requirements is the need to retrospectively allocate UTI to old trades subject to backloading.
ESMA has explained that to the extent that a backloaded contract is still outstanding at the time of reporting, a Trade-ID needs to be agreed between the two counterparties and reported, together with the other information on that contract.
To fulfill this obligation it will be often necessary to contact bilaterally with the past counterparties, sometimes system providers may be helpful in this task.
There is a chance, the said troubles will be eased given the European Commission's Proposal of May 2017 for EMIR amendments become binding law (Proposal for a Regulation of the European Parliament and of the Council amending Regulation (EU) No 648/2012 as regards the clearing obligation, the suspension of the clearing obligation, the reporting requirements, the risk-mitigation techniques for OTC derivatives contracts not cleared by a central counterparty, the registration and supervision of trade repositories and the requirements for trade repositories, COM(2017)208).
Among legislative modifications envisioned in the said document is the removal of backloading requirement, hence the reporting on historic transactions would no longer be required.
UTI, Transaction Reference Number (TRN) and Report Tracking Number
Trade ID (UTI) needs to be differentiated from Transaction Reference Numbers (TRN) and Report Tracking Number.
Each pair of reports (where both counterparties are subject to EMIR reporting obligations) or single reports (where only one of the counterparties is subject to EMIR reporting obligations) should have a unique Trade ID value.
As regards the difference in the two fields: Trade ID and Transaction Reference Number ESMA initially clarified that there is "no common EMIR and MiFID ID yet for derivatives. The Trade ID is the key one for EMIR reporting (per contract). The transaction reference number was designed for MiFID reporting purposes and included in the EMIR reporting obligation so that reporting to TRs is also meaningful for MiFID purposes."
Initially, the respective field for Trade ID in the EMIR reporting format was Field 8 in the Table 2, while the Transaction Reference Number was reported in the Field 9.
There were available following clarifications as regards Transaction Reference Numbers:
- Transaction Reference Number should be the same among groups of reports which relate to the same execution;
- In order to ensure uniqueness across reports relating to the same execution, the TRN should be based on a unique code assigned to this execution;
- The generation of the TRN should have its origin in a centralised infrastructure (e.g. the trading venue or the CCP);
- TRN should be by default the execution code assigned by the trading venue. In case this is not feasible or available due to the market model, a code generated at the clearing level by the CCP can be used;
- The reporting counterparties are expected to obtain TRN from the trading or clearing confirmations that they receive from the investment firm or from the clearing member or CCP;
- The reporting counterparties are expected to transmit the TRN to their counterparties to allow them to fulfil their reporting obligations;
- There is no requirement to ensure that the TRN reported under EMIR has the same value as the Transaction Reference Number reported under MiFID.
The views with respect to the use of TRN within the EMIR reporting scheme have changed with the adoption of the Consultation Document, Review of the technical standards on reporting under Article 9 of EMIR of 10 November 2014 (ESMA/2014/1352), in which ESMA said:
"The current Table 2 Field 9 "Transaction Reference Numbers" was intended to mirror the equivalent field in a transaction report created according to Article 25 MiFID. As this logic has been amended further to ESMA clarification of ETDs reporting, it now conflicts with the concept of Transaction Reference Number within MiFID transaction reporting. For the avoidance of confusion and in order to better reflect the purpose of this field, it is proposed to rename the field to "Report Tracking Number" while maintaining its population logic, i.e. unique code assigned to the execution and common among a group of reports related to the same execution."
This was consequently upheld in the ESMA's Final Report Review of the Regulatory and Implementing Technical Standards on reporting under Article 9 of EMIR of 13 November 2015 (ESMA/2015/1645), p.11.
Commission Implementing Regulation (EU) of 19.10.2016 amending Implementing Regulation (EU) No 1247/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 retreats from the use of Transaction Reference Numbers in EMIR reports and replaces them with Report Tracking Numbers.
Annex to the said Regulation envisions Trade ID to be reported in Field 12 and Report Tracking Number in the Field 13 of the Table 2 (Common data).
Pursuant to the description of the Field 13, as stipulated in the above Annex to the Regulation of 19.10.2016, the Report Tracking Number is "a unique number for the group of reports which relate to the same execution of a derivative contract".
UTI generation for REMIT trade reports
Another interesting UTI designation model (see attachment) has been recommended by the the European energy market watchdog - the Agency for the Cooperation of Energy Regulators (ACER).
In the REMIT reporting context there is a requirement placed by the REMIT Implementing Regulation on wholesale energy market participants to make sure that ACER receives the correct UTI in the correct format for transactions.
This should be the UTI assigned by the organised market place of execution or by the two market participants in the case of bilateral contracts to match the two sides of a transaction.
To enable the generation and usage of the UTI for bilateral trades that take place outside an organised market place ACER has developed and made public an algorithm which makes possible to generate the same UTI from the economic terms of the bilateral trade without any communication between the two market participants (based on using a hash function which allows creating exactly the same UTI value if the input data is the same, and an excel spreadsheet which is available on REMIT Portal).
The ACER's algorithm is based on the concatenation of economic terms included in the contract and the standardization to 50 characters.
The UTI generation works in two steps:
1) the relevant information is entered into a spreadsheet or any other applications capable of running the required task, e.g. web GUI, java etc; and
2) the relevant information is concatenated first, "ashed" and an UTI is generated.
As ACER underlines, this process works identically for both the reporting parties and is independent of the party (buyer or seller) generating the UTI values since both parties using the same algorithm will generate matching UTIs independently and without the need of exchanging data.
ACER recommends, it may make sense for market participants' IT departments to build the UTI generator into their local trading system enabling the UTI generation whenever they enter a trade.
ACER's Excel spreadsheet for UTI generation is available here (click on Annexes of the TRUM "Annex IV - Guidance on UTI - Last update 16 February 2016" for download).
Given that participants need to agree on their method of generating a contract ID, there may arise a problem, if the other counterparty to the trade fails to provide the ID within the mandated timescale (in the REMIT reporting scheme respectively T+1 or T+30) or indeed not at all, and, as a consequence, the counterparty is unable to use the agreed designation in the transaction report.
Prescribed method under REMIT to proceed in such a case is market participants should submit a temporary UTI, then once they have received the UTI from their counterparty, a 'Modify' report (and not 'Error' report) should be submitted to modify the previous report recalling the old UTI (Frequently Asked Questions (FAQs) on REMIT transaction reporting, Question 3.1.17 - see box).
In the REMIT schema there is a field called "AdditionalUtiInfo" field where the old UTI should be reported in the modified report.
Merger - impact on UTIs under REMIT reporting scheme
New obligations arise for merged companies, if they were subject to REMIT transaction reporting and were registered parties with ACER with separate ACER Codes.
Merger means the trades already reported under REMIT as one of the former companies must be cancelled by both merged companies (submission of an early termination report with Action Type “C”) and resent as new submission (Action Type “N”) under the merged company and new name with new UTI (see ACER's stance in the box).
REMIT executions under non-standard contracts - a special case for UTI
The UTI is a mandatory field in the REMIT schema.
Overall, under the REMIT reporting framework UTI is a unique number that identifies the report uniquely.
This is reflected for example in the fact that if the contract is subject to a novation, this must be reported under the REMIT reporting scheme as an early termination of the previous trade with the old UTI and a new trade with a new UTI should be reported.
However, executions under the framework of non-standard contracts deserved a special treatment under the scheme rules, since, as follows from Frequently Asked Questions (FAQs) on REMIT transaction reporting (answers to Questions 3.4.1 and 3.4.2), there is no expectation from the ACER that the buyer and seller unique number for the execution will have to be the same.
The UTI is needed for the ID of the record, otherwise the market participant will not be able to make any amendments and/or recall the transaction.
ACER explained in the above document that the Unique Number can be "any number the market participant likes" (e.g. the transaction ID available in their system), as long as it is unique for that market participant and not used for other executions.
It could be, for example, any progressive unique number for the market participant who is reporting the execution.
UTI under the SFTR
The ESMA's Consultation Paper Draft RTS and ITS under SFTR and amendments to related EMIR RTS, 30 September 2016, ESMA/2016/1409 (p. 79) reminds there is currently no global Unique Trade Identifier for the SFT transactions that could be applied, therefore ESMA proposes to include in the technical standards specific rules prescribing which entity is responsible for the creation and transmission of the UTI under the SFTR.
In particular, ESMA proposes to follow under the SFTR the UTI generation waterfall approach aligned with the one included in the revised implementing technical standards on reporting under Article 9 of EMIR.
In the said Consultation Paper ESMA clarified, moreover, that in the case of additional position-level reporting for cleared trades, a UTI that represents the new position resulting from netting of individual trades should be reported (p. 39).
Regarding the possibility to identify an asset pool among different funds as counterparty ESMA underlined under the SFTR funds are considered counterparties to SFTs.
|Last Updated on Tuesday, 18 July 2017 23:31|