UTI - Trade ID for EMIR derivatives reporting purposes

 


 

 

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

 

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

 

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.

 

Article 4a of the 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 (as amended by the Commission Implementing Regulation (EU) of 19.10.2016)

 

Unique Trade Identifier

 

A report shall be identified through either a global unique trade identifier endorsed by ESMA or, in the absence thereof, a unique trade identifier agreed by the counterparties.

 

Where counterparties fail to agree on the entity responsible for generating the unique trade identifier to be assigned to the report, the counterparties shall determine the entity responsible for generating a unique trade identifier in accordance with the following:

 

(a) for centrally-executed and cleared trades, the unique trade identifier shall be generated at the point of clearing by the central counterparty (CCP) for the clearing member. Another unique trade identifier shall be generated by the clearing member for its counterparty;

 

(b) for centrally-executed but not centrally-cleared trades, the unique trade identifier shall be generated by the trading venue of execution for its member;

 

(c) for centrally-confirmed and cleared trades, the unique trade identifier shall be generated at the point of clearing by the CCP for the clearing member. Another unique trade identifier shall be generated by the clearing member for its counterparty;

 

(d) for trades that were centrally-confirmed by electronic means but were not centrally-cleared, the unique trade identifier shall be generated by the trade confirmation platform at the point of confirmation;

 

(e) for all trades other than those referred to in points (a) to (d), the following shall apply:

 

(i) where financial counterparties trade with non-financial counterparties, the financial counterparties shall generate the unique trade identifier;

 

(ii) where non-financial counterparties above the clearing threshold trade with non-financial counterparties below the clearing threshold, those non-financial counterparties above the clearing threshold shall generate the unique trade identifier;

 

(iii) for all trades other than those referred to in points (i) and (ii), the seller shall generate the unique trade identifier.

 

3. The counterparty generating the unique trade identifier shall communicate that unique trade identifier to the other counterparty in a timely manner so that the latter is able to meet its reporting obligation.

 

Recital 6

 

Where two counterparties cannot agree on which of them should generate a unique trade identifier within the reporting timeline provided, the correct identification and association of the two reports pertaining to the same transaction may not be possible. It is therefore necessary to establish criteria for the generation of unique trade identifiers so as to avoid counting the same transaction twice.

 

 

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

 

 


 

 

 

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.

 

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

 

 

 

ACER's Frequently Asked Questions (FAQs) on REMIT transaction reporting

 

Question

 

Related documents: FAQs, Q 1.1.17: Two companies are subject to REMIT transaction reporting and both registered parties with ACER. Both companies are currently reporting their trades under their separate ACER Code.

 

On July 1 these companies will merge to one company and will use one ACER Code in the future.

 

We will therefore rename the new joint company and use the ACER code of one of the previous companies and delete the code of the other.

 

Do we need to cancel trades already reported as one of the former companies and resend them as new submissions under the merged company and new name with new UTI?

 

We would like to get guidance on how to proceed for our REMIT reporting!

 

Example: Company number 1 as a MP is currently reporting trades under REMIT under its own ACER code. On July 1 Company number 1 will be novated and become a new company which will have the ACER Code of Company number 2. What are the implications for trades reported under Company number 1?

 

Our current interpretation is to cancel all trades reported under Company number 1 and resend them under the name of the new joint company.

 

Is this correct and will the counterparty be obliged to do the same?

 

Answer

 

As presented in Q 1.1.17 of the FAQs on Transaction Reporting, in order to report a novation, an early termination with the old UTI and a new trade with a new UTI should be reported. Both Companies number 1 and 2 will have to submit an early termination report with Action Type “C” for Cancel the old trade and a new submission with Action Type “N” for the new trades of the Company number 1.

 

Question

 

Can you please clarify if the EMIR approach to Novations will be applied.

 

Scenario 1: Trade being fully novated

 

Will we be required to send a cancel/ exit for the trade (old UTI) against pre novation party and a 'new' submission for the trade (New UTI) against the new party? i.e. same UTI cannot be used post novation

 

Scenario 2: Trade to be split by Novation

 

Will we be required to send a modify (old UTI) for the trade remaining with the original party and a 'new' for the trade (New UTI) with new party?

 

Answer

 

In order to report a novation, an early termination with the old UTI and a new trade with a new UTI should be reported. Both market participants, MP1 and MP2 have to submit an early termination report with Action Type "C" for Cancel the old trade and e.g. MP1 and MP3 a new submission with Action Type "N" for the new trade between MP1 and MP3 with a new UTI.

 

Question

 

Can you please clarify if the EMIR approach to Novations will be applied.

 

Scenario 1: Trade being fully novated


Will we be required to send a cancel/ exit for the trade (old UTI) against pre novation party and a ‘new’ submission for the trade (New UTI) against the new party? i.e. same UTI cannot be used post novation


Scenario 2: Trade to be split by Novation


Will we be required to send a modify (old UTI) for the trade remaining with the original party and a ‘new’ for the trade (New UTI) with new party?


In order to report a novation, an early termination with the old UTI and a new trade with a new UTI should be reported. Both market participants, MP1 and MP2 have to submit an early termination report with Action Type “C” for Cancel the old trade and e.g. MP1 and MP3 a new submission with Action Type “N” for the new trade between MP1 and MP3 with a new UTI.
Novation of trades: MP 1 will rename itself and become MP 3 with all codes (ACER, LEI etc) from MP 1. Do we need to modify any trades or do we just need to change the data in CEREMP?


MP 2 will merge with MP 3 to one legal entity MP 3 which comprises the assets of former MP 2 and MP 3: do we need to early terminate trades for MP 2 and submit new trade reports for MP 3? Can we resubmit the complete trades under the merged company (MP 3) or do we actually need to split trades in delivered and undelivered segments? Are any differences between table 1 and table 2 to be taken into account?


Example: MP 2 has a deal with MP X (external party) for cal 2016. A merger between MP 2 and MP 3 takes place on August 1. Are the deals already reported and settled to be early terminated and submitted as new under MP 3? Does MP X to do the same?

 

Has MP X to be informed/asked to do the same?

 

Since we had already submitted a question to ACER previously and received no feedback as to now we would ask you to reply by June 3 in order for us to do necessary preparations.


If we do not receive a response from ACER we will proceed with our best effort: we will send early terminations for open trades for MP 2 and submit new reports for MP 3 without splitting the trades.

 

Answer


All the open trades have to be novated with the name of the new legal entity to notify the change of the counterparty to the contract. In order to report a novation, an early termination with the old UTI and a new trade with a new UTI should be reported.
Both market participants, MP2 and MPX have to submit an early termination report with Action Type “C” for Cancel the old trade and MPX and MP3 have to provide a new submission with Action Type “N” for the new trade between MPX and MP3 with a new UTI.

 

 

 

 

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

 

 

 

Advertisements


 

 

 

 

 



Last Updated on Tuesday, 26 September 2017 11:33
 

Search

Copyright © 2009 - 2017 Michal Glowacki. All rights reserved.
The materials contained on this website are for general information purposes only and are subject to the disclaimer