Category: EMIR

Published: 17 February 2014

Last Updated: 14 March 2024

 

Each derivative contract under the EMIR reporting framework is required by the Commission Delegated Regulation (EU) No 148/2013 to have a Unique Trade Identifier (UTI).

13 March 2024 Annex IV (Guidance on the Unique Transaction ID (UTI) – Version 2.2) to the TRUM updated: additional clarification on the reporting of the Unique Transaction Identifier (UTI) and Contract ID in relation to transactions concluded bilaterally. additional clarification on the reporting of the Unique Transaction Identifier (UTI) and Contract ID in relation to transactions concluded bilaterally.  18 November 2022 ACER updates ANNEX IV to REMIT Transaction Reporting User Manual (TRUM) - Guidance on UTI -  aligning the UTI Generator with the additional allowed values for contract type and quantity unit for REMIT Table 1 reporting

 

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.
Subsequently, the unique Trade ID could be generated by the clearing member for its counterparty (e.g. MiFID investment firm).

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. 

Method 1:

- 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.

Method 2:

- 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.

Method 3:

-  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

-  ISDA Launches UTIPrefix.org to Help Drive Global Data Standards.

 

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.

 

Specific issues

 

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.

 

ACER's Frequently Asked Questions (FAQs) on REMIT transaction reporting   Question 3.1.17 REMIT Implementing Act Article 5(1)(b) and Annex, table 1 data field 31 (Unique transaction ID), table 2 data field no 11 (contract ID). We understand that market participants need to agree on their method of generating a Contract ID – this can include using the UTI algorithm provided by ACER. However, what should a MP do if its counterparty provides the ID after T+1 or T+30 or indeed not at all and they have not agreed to use the ACER algorithm? This is particularly of concern as the use of the ACER algorithm is not mandatory. Under REMIT, phase 2 transactions need to be provided either under table 1 (for contracts that specify and outright price and volume) or under table 2. In submitting a table 1 or 2 report the UTI field must be completed. However, it is possible a counterparty, who is not using the ACER algorithm, may not provide their UTI to us to enable us to report in the necessary timescales. We are engaging with our CPs to ensure this does not occur but it is always a risk. Our preferred approach is to: 1) Submit a temporary UTI, calculated based on the ACER algorithm. 2) Once we have received the UTI from the CP an 'error' report will be submitted to remove the previous report and a 'new' transaction report with the correct UTI will be submitted.   Answer Market participants should submit a temporary UTI, then once they have received the UTI from their counterparty, a 'Modify' report will be submitted to modify the previous report recalling the old UTI. In the schema there is a field called "AdditionalUtiInfo" field where the old UTI should be reported in the modified report.  ...

 

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.

Links   Transaction Reference Number (TRN)   Report Tracking Number (RTN)

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.”

 

ACER's Frequently Asked Questions (FAQs) on REMIT transaction reporting   Question 3.5.7 FAQ Question 3.1.17 states that for a Phase 2 reports in the Table 1 format that a change in UTI may be implemented through a modification of the existing report using either the for the Version 1 schema or the field in the case of the Version 2 schema. The following question has been raised: For Table 1 Phase 2 reports is this process mandatory, or can the Phase 1 Table 1 process of erroring out the first report and resubmitting a new report with a new UTI (without a link to the previous UTI) be used as an alternative process? Practical example: a new Phase 2 Table 1 report is successfully submitted by an MP but subsequently they wish to correct the UTI after discussion with the counterparty. They submit a report for that UTI with ActionType = "E" and they then submit a new report for the same deal with a new UTI (matching the counterparty's UTI) with ActionType = "N", they do NOT include any information about the original report or its UTI in the newly submitted report. Is this an acceptable process for correcting the UTI?   Answer Market participants should clearly distinguish the Error “E” from the Modification “M” case. As indicated in the TRUM, “E” for Error should be used to denote a cancellation of a wrongly submitted report, while “M” for Modification should be used for the modification of the details of a previously reported contract. In order to correct the UTI that was wrongly submitted, 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. However, with regard to Question 3.1.17 of the FAQs on REMIT transaction reporting, if a market participant’s counterparty provides the UTI after T+1 day or T+1 month, or alternatively not at all, the market participant who is reporting its reports should submit a temporary UTI. Once they have received the UTI from their counterparty, a ‘Modify’ report should be submitted to modify the previous report, recalling the old UTI. If a report is due to be reported on a T+1 day basis, all life cycle events related to that report have to be reported on a T+1 day basis. Otherwise, if a new report is due to be reported on a T+1 month basis, all life cycle events related to that report have to be reported on a T+1 month basis. Examples of ’modification‘, ’early termination‘ and ’error‘ reports are available in Annex II to the TRUM.

 

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. Therefore, each fund as counterparty must report a separate transaction each with its own UTI (p. 40).

 

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, 

(ii)  for jurisdictions to have compatible, but not necessarily equivalent, rules defining which entity should be responsible for generating the UTI,

(iii)  to have a UTI construct/algorithm appropriate for the authorities’ characteristics, in particular the consistency characteristic, while not necessarily harmonising the rules about responsibility for generating the UTI.


The CPMI and IOSCO have doubts about the feasibility and suitable infrastructure for centralised generation of UTIs, given the number of UTIs required. 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.

 

Step	Factor to consider	Responsibility for UTI generation
1	Is a CCP a counterparty to this transaction?	If so, the CCP. Otherwise, see step 2.
2	2. Is a counterparty to this transaction a clearing member of a CCP, and if so is that clearing member acting in its clearing member capacity for this transaction?	If so, the clearing member.  Otherwise, see step 3.
3	Was the transaction executed on a trading platform?	If so, the trading platform. Otherwise, see step 4.
4	Is the transaction cross-jurisdictional (i.e. are the counterparties to the transaction subject to more than one jurisdiction's reporting rules)?	If so, see step 10.  Otherwise, see step 5.
5	Do both counterparties have reporting obligations?	If so, see step 6.  Otherwise, see step 7.
6	Has the transaction been electronically confirmed or will it be and, if so, is the confirmation platform able, willing and permitted to generate a UTI within the required time frame under the applicable rules?	If so, the confirmation platform. Otherwise, see step 7.
7	Does the jurisdiction employ a counterparty-status-based approach (eg, rule definition or registration status) for determining which entity should have responsibility for generating the UTI?	If so, see step 8. Otherwise, see step 11.
8	Do the counterparties have the same regulatory status for UTI generation purposes under the relevant jurisdiction?	If so, see step 11. Otherwise, see step 9.
9	Do the applicable rules determine which entity should have responsibility for generating the UTI?	If so, the assigned entity. Otherwise, see step 12.
10	Does one of the jurisdictions have a sooner deadline for reporting than the other(s)?	If so, then the UTI generation rules of the jurisdiction with the sooner reporting deadline should be followed. Otherwise, see step 11.
11	Do the counterparties have an agreement governing which entity should have responsibility for generating the UTI for this transaction?	If so, the agreed entity. Otherwise, see step 12.
12	Has the transaction been electronically confirmed or will it be and, if so, is the confirmation platform able, willing and permitted to generate a UTI within the required time frame under the applicable rules?	If so, the confirmation platform. Otherwise, see step 13.
13	Is there a single TR to which reports relating to the transaction have to be made, and is that TR able, willing and permitted to generate UTIs under the applicable rules?	If so, the TR Otherwise, one of the counterparties, based on sorting the identifiers of the counterparties with the characters of the identifier reversed and picking the counterparty that comes first in this sort sequence.

 

UTI structure


In order to ensure the UTI's uniqueness, the data standard recommended by the CPMI and IOSCO Technical Guidance is formed of the two composites:
- the UTI from the Legal Entity Identifier (LEI) of the generating entity,
- a unique value created by that generating entity.

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.

Subscribe to read more …