regis-tr, an update on revised technical standards · regis-tr, an update on revised technical...
TRANSCRIPT
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
New data fields and values (2/8)Action types + Level
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
New data fields and values (3/8)Action types + Level
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”
and new field “Level” set to “T”
Via the R010 (Transaction reporting)
Option 1
XT message with action type “N”
and new field “Level” set to “P”
Option 2
XT message with action type “N”
and new field “Level” set to “P”
Via the R001 file type (Position reporting)
Via the R001 (Transaction reporting)
Option 3
XT message with action type “N”
and new field “Level” set to “T”
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
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 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
Other changes to be implemented with the revised Technical Standards
(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
Other changes to be implemented with the revised Technical Standards
(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:
Other changes to be implemented with the revised Technical Standards
(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.
Other changes to be implemented with the revised Technical Standards
(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)
Other changes to be implemented with the revised Technical Standards
(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" />
Other changes to be implemented with the revised Technical Standards
(7/7)
6
21 June 2017 19
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 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.
Website:
http://www.regis-tr.com
LinkedIn:
REGIS-TR
Twitter:
@TradeRepository
Contact details
Raúl Redondo
Business Analyst
REGIS-TR S.A.
+34 91 709 5570
Jonathan Gallo
Business Analyst
REGIS-TR S.A.
Nuria Sagrado
Head of Functional Design
REGIS-TR S.A.
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