|UTI - Trade ID for EMIR derivatives reporting purposes|
EMIR Regulation contains a requirement that UTI must be unique but the issues how it should be generated or by whom have not been initially 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.
However, there are some self-standing frameworks, for example:
- ACER's UTI designation initiative as described in 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.
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.
Commission Implementing Regulation (EU) No 1247/2012 specifies that in absence of global unique trade identifier endorsed by ESMA, a unique code should be generated and agreed with the other counterparty (Table 2, field 12).
Hence, 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 (EU) No 148/2013 specifies that the Trade ID can have up to 52 characters, including four special characters, the special characters not being allowed at the beginning or at the end of the code.
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 Article 4a of the Implementing Regulation (EU) No 1247/2012 (as amended by the Commission Implementing Regulation (EU) of 19.10.2016) - see box.
While submitting the above EMIR reporting ITS amendments ESMA argued that where two counterparties couldn't agree on which of them should generate a unique trade identifier within the reporting timeline provided, the two reports pertaining to the same transaction wouldn't be identified consistently. It was 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 Implementing Regulation of 19 October 2016.
The generation of UTI can be delegated (ESMA confirmed this in the EMIR Q&As).
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.
- The characters ‘E01’.
- The MIC code (ISO 10383) of the applicable trading venue.
- A unique code generated by that trading venue (for centrally executed but non-centrally cleared trades) or by a CCP used by that trading venue to clear the derivative contract (for centrally executed and cleared trades). 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.
- The characters ‘E02’.
- The (20 character) Legal Entity Identifier of the generating entity (normally one of the parties to the trade and pursuant to the points (a), (c) and (e) of the hierarchy mentioned in Article 1(4) of the Commission Implementing Regulation (EU) No 1247/2012 (ITS on reporting to TR).
- A unique code generated by the unique Trade ID generating entity.
- The characters ‘E03’.
- 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.
For derivative contracts that are also reportable under the provisions of the Dodd-Frank Act the same value as the one to 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.
The following clarifications have been made by ESMA as regards the use of 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".
Rules for the use of Report Tracking Numbers are mostly analogous to the ones applied for the earlier Transaction Reference Number.
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.
Moreover, on 20 July 2018 ACER has explained the procedure to be effected by a market participant to correct the UTI that was wrongly in the REMIT transaction report.
According to the ACER’s answer to Question 3.5.7 in Frequently Asked Questions (FAQs) on REMIT transaction reporting (10th Edition), in such a case “the original report needs to be cancelled with Action type “E” and a new report with a new UTI (matching the counterparty's UTI) has to be submitted for the same deal with Action type “N”. The new report does not have to include any information about the original report or its UTI, since the original report was wrongly submitted in the first place.”
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.
CPMI and IOSCO framework
Another regulatory initiative to enable the global aggregation of OTC derivatives transaction data was undertaken by the Committee on Payments and Market Infrastructures, Board of the International Organization of Securities Commissions in August 2015.
The work started with the Consultative report on Harmonisation of the Unique Transaction Identifier where the institutions decided that further work should, in particular, focus on determination:
(i) which OTC derivatives transactions should be assigned a UTI,
(ii) which entity (or entities) should be responsible for generating UTIs in practice,
(iii) what should be the structure and format of a UTI,
(iv) what steps would help to ensure that UTIs generated under the new guidance are distinct (to the extent necessary to achieve aggregation) from those UTIs generated under existing regimes.
The above key areas are describes in greater detail in the subsequent document of the Committee on Payments and Market Infrastructures and the Board of the International Organization of Securities Commissions of February 2017 - Technical Guidance, Harmonisation of the Unique Transaction Identifier (CPMI and IOSCO Technical Guidance). The following passages refer to the said document.
Which OTC derivatives transactions should be assigned a UTI
The CPMI and IOSCO Technical Guidance does not determine, which transactions are reportable, the only purpose is to ensure that reportable transactions have UTIs.
Moreover, each reportable transaction should have a UTI that is different from the UTI of any other reportable transaction, however, if a particular transaction is reported more than once, then the same UTI should be used for each such report.
Responsibility for generating the UTI
Committee on Payments and Market Infrastructures and the Board of the International Organization of Securities Commissions in the Technical Guidance shared the view that only one entity should be responsible for generating the UTI for a particular transaction.
The said institutions also acknowledged a need to have a degree of harmonisation of the rules used to determine which entity should have that responsibility.
The three options have been preliminarily considered:
(i) for all jurisdictions to adopt equivalent (i.e. globally harmonised) rules defining which entity should be responsible for generating the UTI,
Therefore the solutions considered by the CPMI and IOSCO have involved the possibility of many entities being candidates for generating UTIs.
The CPMI and IOSCO have emphasised that the factors, as in the table below, should be considered by authorities for allocating responsibility for UTI generation. Not all factors will be relevant for all jurisdictions.
According to the CPMI and IOSCO Technical Guidance, authorities’ rules should ensure that "new UTIs are structured as a concatenated combination of the LEI of the generating entity at the point of generation and a unique value created by that entity (where this value only needs to be unique within the set of such values generated by that entity since the combination with the LEI will guarantee uniqueness)."
The said conception implies, moreover, that:
- if generation of the UTI has been delegated, the generating entity for the purpose of determining the LEI to be embedded in the UTI should be the entity that actually generates the UTI and not the entity that delegated the generation,
- there should be no requirement to update a UTI solely because the LEI of the generating entity is no longer valid or applicable for some reason.
Timing of UTI generation
The said institutions, moreover, underlined that UTIs should be generated in time for reporting.
According to the CPMI and IOSCO, there should be recognition that an entity that is required to report (using the UTI) may not be the same entity responsible for generating the UTI.
Entities generating UTIs should share them with other entities that require them in a timely manner.
Impact of life cycle events on the UTI
New UTIs should be used for the initial reports of new reportable transactions, when a UTI is allocated to a reportable transaction, it should remain as the identifier for that transaction throughout its life.
When a transaction is terminated and replaced with one or more other transactions, new UTIs should be used. According to the CPMI and IOSCO Technical Guidance this could occur when:
− the transaction is replaced by another transaction, e.g. due to compression or netting; or
− the transaction is split into different transactions.
Previous UTI should be maintained if new information is being reported about an OTC derivatives transaction about which a report has already been made, or some of the previously reported information has changed, then the report should be updated using the same UTI as previously, in particular where:
- some previously reported information, such as whether the trade has been confirmed, has changed,
- the contract is an amortising swap or similar and the notional has changed in accordance with the contractual terms,
- reporting of end-of-life events such as early termination,
Otherwise, a new UTI is should be used, examples of this include:
- change to either counterparty (this includes the transaction being cleared, ie cases in which one counterparty becomes the CCP),
If there is more than one such change to be applied to a report at the same time, then if any one of these changes would require a new UTI, a new UTI should be used.
The above approach describes the impact of life cycle events on the UTI and not on other data elements in reports and should apply irrespective of:
Technical Guidance, Harmonisation of the Unique Transaction Identifier, Committee on Payments and Market Infrastructures, Board of the International Organization of Securities Commissions, February 2017
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, Recital 6 and Article 4a andAnnex
Technical Guidance, Harmonisation of the Unique Transaction Identifier, Committee on Payments and Market Infrastructures, Board of the International Organization of Securities Commissions, February 2017
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, May 2017
Committee on Payments and Market Infrastructures, Board of the International Organization of Securities Commissions, Consultative report, Harmonisation of the Unique Transaction Identifier, August 2015
|Last Updated on Friday, 11 January 2019 21:41|