REGIS-TR, an update on Revised Technical Standards · REGIS-TR, an update on Revised Technical Standards Helena Mena , Business Analyst REGIS-TR Raúl Redondo, Business Analyst REGIS-TR

REGIS-TR, an update on Revised Technical

Standards

Helena Mena , Business Analyst REGIS-TR

Raúl Redondo, Business Analyst REGIS-TR

Jonathan Gallo, Business Analyst REGIS-TR

Nuria Sagrado, Head of Functional Design REGIS-TR

21 June 2017 2

Agenda

1 Revised Technical Standards

1.1 New data fields and values

1.2 Other changes to be implemented with the revised Technical Standards

Delegation Authorization Control 2

21 June 2017 3

New data fields and values (1/8)Action types + Level

New field “Level” for transaction and position reporting1

LevelT = Trade

P = Position

Changes the way of reporting transactions/positions (no longer valid to populate

field “Venue” blank and “Compression” set to “Y” for this purpose)

The field “ Compression “ will exclusively be used for portfolio compression

We will continue receiving these 2 types of records via the R001 files

Only “T” level records will be permitted via the R010 files

Introduction of new mandatory field "level" including new values to make a distinction between transaction and position reporting

Action

type

N = New

M= Modify

E = Error

C = Early termination

R = Correction

Z = Compression

V = Valuation update

P = Position reporting

“R” to correct/amend wrong values

“M” use in case material terms of the contract have changed

“P” allows to report ETD transactions (via R010) in one single message,

instead of the two messages required as of today (1 action type “N” + 1 action

type “Z” to report and later compress the ETD transactions prior to report the

position). However, the current way of reporting ETD transactions will still be

permitted.

The adaptation of existing fields and values as well as the introduction of new ones imply the following changes:

New “Action type” values 2

21 June 2017 4

R001 file type- XT, BK, CU and VU messages a)

Action type “N” + Level “T” will be used to report a new OTC (ETD) transactions

Action type “N” + Level “P” will be used to report a new position (instead of

populating the field “Venue” blank and “Compression” set to “Y” for this purpose)

Action type “P” + Level “T” combination not allowed for R001 files

Action type “P” + Level “P” combination is not permitted by ESMA

Action type “V” + Level “T/P” will still be permitted

Action type “N” + Level “T” will be used to report a new ETD transactions using

the existing model : EX “N” + TE”Z”

Action type “N” + Level “P” combination not allowed for R010 files

Action type “P” + Level “T” will be used to report a new ETD transactions using

the new model : “P” = “N” + “Z”

Action type “P” + Level “P” combination is not permitted by ESMA

Action type “V” + Level “T/P” is not permitted

According to the message type , the following combinations of the before mentioned fields will be permitted:

R010 file type- EX messages b)

R001 file

Action type Level

N T

N P

P T

P P

V T/P

R010 file

Action type Level

N T

N P

P T

P P

V T/P


21 June 2017 5

R001 file type- MX and TT messages c)

Action types “M” and “R” (modification messages) + Level “T/P” will be

permitted

Action types “E” and “C” (termination messages) + Level “T/P” will be

permitted

Action type “Z” (termination message) + Level “T” will be used to indicate trade

compression

Action type “Z” (termination message) + Level “P” is not permitted by ESMA

Action types “M” and “R” (modification messages) + Level “T” will be permitted

Action types “E”, “C” and “Z” (termination messages) + Level “T” will be

permitted

Action types “M” and “R” (modification messages) + Level “P” will not be

permitted since “P” level reports are not allowed via the R010 files

Action types “E” and “C” (termination messages) + Level “P” will not be

permitted since “P” level reports are not allowed via the R010 files

Action type “Z” (termination message) + Level “P” is not permitted by ESMA

According to the message type , the following combinations of the before mentioned fields will be permitted:

R010 file type- ME and TE messages d)

R001 file

Action type Level

M T/P

R T/P

E T/P

C T/P

Z T

Z P

R010 file

Action type Level

M T

R T

E T

C T

Z T

M/R P

E/C/Z P


6

ETD reporting now

ETD reporting upon RTS implementation

EX message with action type “N”

+ TE message with action type “Z”

Via the R010 (Transaction reporting)

XT message with action type “N” and field

+ “Venue” Blank + “Compression” set “Y”

Via the R001 file type (Position reporting)

Option 1

EX message with action type “N”

+ TE message with action type “Z”

and new field “Level” set to “T”

Option 2

EX message with action type “P”



Option 1

XT message with action type “N”

and new field “Level” set to “P”

Option 2


and new field “Level” set to “P”

Via the R001 file type (Position reporting)


Option 3



No necessary to report the Position

21 June 2017

New data fields and values (4/8)Action types

21 June 2017 7

Our proposal : In the case of REGIS-TR that accepts partial messages for the “Modification” and “Correction” reports only those fields reported in the modification

message will be subject to the revised validations rules. Moreover, if customers report modification over trades reported with the current RTS, REGIS-TR will not request

them to fill in all the new mandatory fields for action type "N". Only if the field is reported in the modification message, the relevant cross validations will apply and

customer may be required to report additional fields.

ESMA response : ESMA states that in the case of the TRs that accept partial messages for the “Modification” and “Correction” reports (i.e. messages containing only

the strictly mandatory fields such as UTI or counterparties’ IDs and the fields that are modified/corrected), those TRs will need to ensure that the counterparties provide

all the applicable data elements when sending the “Modification” or “Correction” report for the first time upon the application date of the revised technical standards”.

Modifications (Q&A TR Question 44)

Modification logic

Modification over UTIs with special characters

Our proposal: The UTI shall only be validated upon trade reception. Therefore, trades with UTIs containing special characters that were reported prior to the

implementation of the Level II validations, shall still be updated by reporting the said UTI, following the same logic applied for the implementation of the Level II

validations. However, trades reported with special characters after the implementation of the revised technical standards will be rejected.

ESMA response : UTIs should be validated in all transaction reports

Important : Participants won´t be able to send any message over trades containing an Interim Trade ID . Therefore the update of Interim Trade Ids into Trade Ids is

highly recommended.

New data fields and values (5/8)Feedback received from ESMA

21 June 2017 8

Our question : Shouldn´t fields 67-77 only be reported when field 2.24 (delivery type) has been informed with "P“ as per physical and otherwise be left blank.?

ESMA response : ESMA states that financial derivative transactions related to the EU gas or electricity should be reported in the same way as physical derivate

transactions as there is no distinction between the two. A derivative for the physical delivery is settled with the delivery of the commodity. A financial derivative is settled

in cash. Financial derivatives that are related to a commodity settle against an index or reference price.

Energy section (Fields 2.67 to 2.77 )

Our question : If field 2.80 (strike price) is populated with 999999999999999.99999 (when the actual value is not available), what are customers expected to report in

field 2.81 (strike price notation) considering that the value "X" has not been defined and that only values U, P and Y are accepted according to the validations?

ESMA response :It should be the actual strike price notation. The "9999..." expression denotes that the price is not available, however even if the actual value is not yet

known, the entity should be able to determine whether for a given instrument the strike price should be expressed as monetary value or the percentage.

Strike Price Notation- Field 2.81

New data fields and values (6/8)Feedback received from ESMA

21 June 2017 9

Allowed identification types

Only a valid LEI may be reported for the following fields:

o Reporting Counterparty IDo Broker IDo Report submitting entity IDo Clearing member IDo CCP

LEI or CLC (for client code) may be reported for the following fields:

o Type of ID of the other Counterparty:o ID of the other Counterpartyo Type of ID of the Beneficiaryo Beneficiary ID

The “Other” category

Fields permitting negative values

Only The “Other” category shall be kept for the “Derivatives type” section (Field 2.1, former “Product ID 2” and renamed as “Contract type”)

The “Other” category shall be removed for the “Asset Class” section (Field 2.2, former “Product ID 1” and renamed as “Asset class”)

Specific guidance on what fields should be accepting negative values

o No impact as REGIS-TR already complies (“Mark to market value”, Price /Rate, Notional, Up-front payment, Strike Price

Fixed rate of leg 2, Exchange Rate 1, Forward exchange rate, Strike Price)

New data fields and values (7/8)

21 June 2017 10

New, erased and renamed fields

• Type of ID of the other Counterparty (already existed at RTR)

• Country of the other Counterparty

• Type of ID of the Beneficiary

• Collateral section (fields 1.24-1.35)

• Asset class (already existed at RTR)

• Product classification type / Product classification

• Product identification type / Product identification

• Underlying identification type ( already existed at RTR)

• Complex trade component ID

• Currency of Price

• Several fields of the interest rate section

• Load delivery intervals

• Days Of the Week

• Credit derivatives section ( fields 2.83-2.92)

New fields among others

Old name New name

Reporting entity ID Report submitting entity ID

Valuation time & Valuation date Valuation timestamp

Product ID 2 Contract type

Underlying ID type Underlying identification type

Underlying Underlying identification

Notional amount Notional

Date of settlement Settlement date

Currency 2 Deliverable currency 2

Contract capacity Delivery capacity

Option style Option exercise style

Fields which have been renamed

Name and domicile of the Counterparty

Contract with non- EEA counterparty

Taxonomy

Details of the Action Type

Deprecated fields

New data fields and values (8/8)

21 June 2017 11

Agenda





21 June 2017 12

Action type “N” and “V” to be populated by participants instead of by REGIS-TR1

2

Obligation to report CPTY 1 and CPTY 2 in all messages regardless of the delegation scenario3

REGIS-TR CSV-XML harmonization4

Enable collateral and valuation reporting for the ETD trades5

Backloading OTC derivatives and ETD positions (Extension February 2019) 6

7 Field Erasing Protocol (R010)

Delegation “P” (Participant Delegation) Removal .Limit the delegation scenarios to “Y” and “N”

Other changes to be implemented with the revised Technical Standards

(1/7)

13

Action type “N” and “V” to be populated by participants instead of by REGIS-TR1

Currently XT, BK and EX messages are automatically assigned the action type “N” by the system when they reach REGIS-TR.

However, with the new RTS, “P” is another possible value. Therefore, this field should no longer be filled in by the system, instead participants

should populate it.

The first report received for a given UTI by the reporting counterparty shall only contain value "N" or "P". If the first report for a given UTI by the

counterparty is with action types "M", "E", "C", "R", "Z" or "V" it shall be rejected.

VU and CU messages will be enhanced and the action type “V” should be reported by the participants in those messages.

XT, BK and EX messages Action type “N”

Action type “P”

Currently: filled in by the system

New RTS:

Participants

should now fill

in the field

VU and CU messages Action type “V”

Only values accepted

for a first report for a

given UTI

Currently: filled in by the system

New RTS:

Participants

should now fill

in the field

21 June 2017


(2/7)

21 June 2017 14

Delegation “P” (Participant Delegation) Removal

REGIS-TR has the Participant delegation (“P” delegation) implemented which consisted of a limited capacity to modify the data of a certain trade

where one Reporting Participant (RP2) had delegated the reporting to another Reporting Participant (RP1 ).

New RTS: ESMA has stated that only full delegation must be allowed in the reporting.

Message type Before After Changes?

XT / EX Reporting of Delegation "P" is permitted Reporting of Delegation "P" will not be permitted. YES

MX / MEFor delegation "P”, the RP 1 (delegated entity), may

amend his own CPTY data + common data.

The RP 1 (delegated entity), may amend his own CPTY

data + the CPTY data of RP2 + common data.YES

MX / MEFor delegation "P”, the RP 2 (delegating entity), may

amend its own CPTY data.

The RP 2 (delegating entity), may NOT amend his own

CPTY data except for the exposure data through a

modification with action type “V”.

YES

TT/ TEFor delegation "P”, only the RP 1 (delegated entity), may

terminate both legs the trade.

For delegation "P”, only the RP 1 (delegated entity), may

terminate both legs the trade.NO

CU, VU

For delegation "P”, both, the RP 1 (delegated entity) and

the RP2 (himself or through another RP or TP) may

update its own collateral and valuation information.

For delegation "P”, both, the RP 1 (delegated entity) and

the RP2 (himself or through another RP or TP) may

update its own collateral and valuation information.

NO

Different scenarios before and after the implementation


(3/7)

2

21 June 2017 15

Obligation to report CPTY 1 and CPTY 2, in all messages regardless of the delegation scenario

Changes that need to be implemented

According to ESMA, all messages (not only those with action type “N”) must include the identifications of Counterparty 1 and Counterparty 2 and

also the corresponding mirror effect (Counterparty 2 and Counterparty 1) in both XML and CSV formats, in case of delegation.

All messages

Identifications of

Counterparty 1 and

Counterparty 2

Mirror effect

(Counterparty 2 and

Counterparty 1)

Direct reporting

Delegated

reporting

Party ID/ Type 1 and Counterparty ID/ Type 2 fields must always be informed at least in the first counterparty data set and in the second

Counterparty data set too when delegation “Y” takes place.

Inclusion of the identification of both counterparties on each counterparty data set in the CSV files equating to XML format.

MX/ME, TT/TE, CU and VU messages must be enabled to allow the following changes :

o The counterparty IDs must always be included at least in the first counterparty data set.

o In delegation scenarios, these messages must be reported with 2 counterparty data sets:


(4/7)

3

21 June 2017 16

REGIS-TR CSV-XML harmonization

REGIS-TR has developed a harmonization between CSV and XML formats , which includes:

o The new fields, the adjustments and adaptations of current fields imposed by ESMA due to the new RTSs.

o An alignment of field order and a reorganization of all of them.

Reporting now Reporting upon RTS implementation

CSV files include just one counterparty identification set of fields

regardless of whether the trade is delegated or not.

Many fields do not follow a common structure in the CSV and the

XML files. Naming and the order in which fields are placed is not

the same in both file types.

CSV files will include a second counterparty identification set of

fields, so that the mirror image of the parties’ identifications can

be populated in the delegation scenarios.

REGIS-TR will realign the fields so both file types (CSV and

XML) will have the same order. The CSV message structure will

be updated in order to be alike to the XML message structure.

Names will be also updated.


(5/7)

4

21 June 2017 17

Enable Collateral and Valuation reporting for the ETD Trades.

Reporting now Reporting upon RTS implementation

Collateral Reporting

REGIS-TR permits Collateral updates for OTC transactions

and ETD/CFD positions at both levels:

o Trade ID

o Portfolio level

Collateral Reporting

REGIS-TR will permit the Collateral reporting for ETD/CFD

transactions reported through :

o The R001/R003 files (CU- Collateral Messages) .

Valuation updates

REGIS-TR permits Valuation updates for OTC transactions and

ETD/CFD positions.

Collaterals and Valuation updates reporting

Collateral and Valuation reporting for R010 files( ETD/CFD

transactions ) is not enabled: customers must always update

collaterals at trade level or at portfolio level via the R001.

Valuation updates

REGIS-TR will permit the Valuation updates for ETD/CFD

transactions reported through :

o The R001/R002 files (VU-Valuation Messages).

Collaterals and Valuation updates reporting

At Trade Level: Collateral and Valuation updates should only be

permitted via the R001 for ETD/CFD transactions initially

reported with action type “N” and level “T”.

At Position Level :The participant can report the position via

R001 where he can update the Collateral and Valuation at position

level, as it is currently done, If:

o The original transaction EX is later compressed (N + Z);

o Or if the trade EX was directly reported with action type “P”

(same effect as N + Z)


(6/7)

5

21 June 2017 18

Backloading OTC derivatives and ETD positions ( Extension February 2019)

Those derivatives contracts which were entered into before, on or after 16th August 2012, that were not outstanding on the reporting start date must

be reported within 5 years of the reporting start date (12-February-2019).

Field Erasing Protocol7

Currently it is in place for R001 files and will be implemented for R010 files.

Updated Cross validations to erase information will apply. This validations will be the same for the R001 and R010 reporting channel.

As it is currently stablished, the command ‘NULL’ will be maintained to erase data in CSV formats.

Also, for the XML format we will maintain the same nomenclature, e.g.: if the intention is to erase the field CORPORATE SECTOR the tag must be

informed as follows: <corporateSector xsi:nil="true" />


(7/7)

6

21 June 2017 19

Agenda





21 June 2017 20

In case of inconsistency between the information received in the Authorized Reporting Entities CSV file and the data reported by clients:

Needs to control the identifiers of

the counterparties that have been

authorized to report on behalf of

others.

Implement the corresponding

delegation controls.

REGIS-TRAuthorized reporting entities

(RPs and TPs)

Authorised Reporting Entities CSV file

(Authorised entities File upload) –File

Type R020

List of authorized TPs or RPs to be

provided by their Underlying

customers, i.e. RPs and NRE

accounts

This information will be used to

build the system control.

REGIS-TR will flag the trades to the relevant participants, NCAs and ESMA

An Unauthorized Delegated Trade Report ( D438) will be created to incorporate the flagged trades.

Delegating reporting entities

(RPs and NREs)

Delegating Reporting Entities CSV

file (Delegating Entities file upload)-

File Type R021

List of direct customers on behalf

of whom TPs and RPs report to

REGIS-TR: TPs and RPs shall

inform REGIS-TR of every

underlying customer they are

entitled to report on behalf of.

This information will be stored in

the REGIS-TR database and will

not be used to build the system

control.

ESMA obliges the TRs to control who is authorized to report on whose behalf:

Delegation Authorization Control

Any questions?

Helena Mena

Business Analyst

REGIS-TR S.A.

[email protected]

Website:

http://www.regis-tr.com

LinkedIn:

REGIS-TR

Twitter:

@TradeRepository

Contact details

Raúl Redondo

Business Analyst

REGIS-TR S.A.

[email protected]

[email protected]

+34 91 709 5570

Jonathan Gallo

Business Analyst

REGIS-TR S.A.

[email protected]

Nuria Sagrado

Head of Functional Design

REGIS-TR S.A.

[email protected]

mailto:[email protected]





Disclaimer

21 June 2017 22

"This presentation is prepared for general information purposes only. The information contained

herein is not intended to provide professional legal advice and should not be relied upon in that

regard.

Readers should seek appropriate professional advice where necessary before taking any action

based on the information contained in this document.

REGIS-TR, S.A. makes no guarantees, representations or warranties and accepts no responsibility

or liability as to the accuracy or completeness of the information, and under no circumstances will it

be liable for any loss or damage caused by reliance on any opinion, advice or statement made in

this document.

Information in this document is subject to change without notice."

REGIS-TRREGIS-TR

Documents

REGIS-TR, an update on Revised Technical Standards · REGIS-TR, an update on Revised Technical Standards Helena Mena , Business Analyst REGIS-TR Raúl Redondo, Business Analyst REGIS-TR