RegStream

Raw view of specific publication

Become a member today and discover RegStream features

We strive to provide our clients with top notch tools to enable better compliance Start Now

Technical Reporting Instructions - CSDR Article 9 - Internalised Settlement Reporting

Technical Reporting Instructions CSDR Article 9 - Internalised Settlement Reporting

24 March 2022 | ESMA65-8-6560

ESMA REGULAR USE

Document control:

Version

Date

Author

Comments

0. 1. 0

0. 2. 0

29/05/2018

31/05/2018

ED

ED

0. 3. 0

01/02/2019

ED

0. 4. 0

12/02/2019

ED

First draft

Correction of publication date of the CSDR Guidelines

Updated version to reflect FSD version v2. 2. 0

- Addition of sections 2. 1 (system actors), and 5. 6 (location of base/ derived CSDR9 message)

- Elaboration of Annex IV to include filenaming examples

- Minor textual improvements

0. 5. 0

1. 0. 0

2. 0. 0

19/02/2019

ED

- Minor textual improvements

25/02/2019

ESMA

- Minor textual improvements

08/03/2019

ESMA

- Minor improvement to reflect FSD version v4. 0. 0

3. 0. 0

27/03/2019

ESMA

4. 0. 0

06/05/2019

ESMA

5. 0. 0

10/05/2019

ESMA

Updated version to reflect FSD version v5. 0. 0

Updated version to reflect FSD version v6. 0. 0, to use of 4 digit in file naming convention.

- Clarifications on the use of ‘Status’ field of the report (NEWT/ AMND/ CANC)

- Minor update on the validation checks and descriptions of rules INS-015, INS- 016, INS-065, INS-066

6. 0. 0

23/05/2019

ESMA

- Addition of validation rule INS-015

- Minor update of validation rule INS-014

ESMA • CS 60747 – 103 rue de Grenelle • 75345 Paris Cedex 07 • France • Tel. +33 (0) 1 58 36 43 21 • www. esma. europa. eu

2

ESMA REGULAR USE

- Minor update in section ‘5. 6 ISO 20022 auth. 072. 001. 01 message definition - CSDR9 base/ derived message’ to clarify that the ‘country code’ element is optional.

- Minor update on the error description of content validation rules INS - 071. 3, INS - 072. 3 and file validation rule FIL - 105

- Update on the content validation rules that allow the system to accept LEIs with status “Merged” (as verified through the GLEIF database)

CR #5: new data validation to ensure that the submitting NCA country code is the same as the country reported under Settlement Internaliser Identification.

7. 0. 0

04/07/2019

ESMA

7. 1. 0

31/07/2019

ESMA

7. 2. 0

24/03/2022

ESMA

Distribution List:

Name

Department

Role

ESMA CSDR Project team

ED CSDR Project team

Reference documents:

Product Owner

Implementation

Ref Title

Version

Author Date

1

Regulation (EU) No 909/2014 of the European Parliament and of the Council of 23 July 2014 on improving securities settlement in the European Union and on central securities depositories and amending Directives

N/A

EU

23/07/2014

ESMA • CS 60747 – 103 rue de Grenelle • 75345 Paris Cedex 07 • France • Tel. +33 (0) 1 58 36 43 21 • www. esma. europa. eu

3

ESMA REGULAR USE

N/A

EU

11/11/2016

N/A

EU

11/11/2016

98/26/EC and 2014/65/EU and Regulation (EU) No 236/2012

2016

COMMISSION DELEGATED REGULATION (EU) 2017/391 of 11 November supplementing Regulation (EU) No 909/2014 of the European Parliament and of the Council with regard to regulatory technical standards further specifying the content of the reporting on internalised settlements

2016

laying

COMMISSION IMPLEMENTING REGULATION (EU) 2017/393 of 11 November down implementing technical standards with regard to the templates and procedures the reporting and information on transmission of internalised in accordance with Regulation (EU) No 909/2014 of the European Parliament and of the Council

settlements

for

Guidelines on Internalised Settlement Reporting under Article 9 of CSDR

N/A

ESMA

28/03/2018

CSDR Article 9 Internalised Settlement Reporting Functional Specifications Document

-

V4. 0. 0

ESMA

08/03/2019

2

3

4

5

ESMA • CS 60747 – 103 rue de Grenelle • 75345 Paris Cedex 07 • France • Tel. +33 (0) 1 58 36 43 21 • www. esma. europa. eu

4

ESMA REGULAR USE

Table of Contents

1

Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1. 1 Background. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1. 2 Project context. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1. 3 Scope of this document. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1. 4 Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 Overall process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2. 1 Actors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2. 2

Internalised Settlement reporting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2. 3 Potential Risk reporting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2. 4 Reporting and Submission Periods. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3 Error Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3. 1

Internalised Settlement reporting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3. 2 Potential Risk reporting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4 Modification of reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4. 1 Re-submission of report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4. 2 Cancellation of report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5

Internalised Settlement Reporting messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5. 1 Settlement Internaliser Report data message. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5. 2 Status advice / Feedback message. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5. 3

Feedback. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5. 4 Business Application Header. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5. 5 Business File Header. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5. 6

ISO 20022 auth. 072. 001. 01 message definition - CSDR9 base/ derived message 35

6 Annexes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

6. 1 Annex I: File Validation Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

6. 2 Annex II: Content Validation Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

6. 3 Annex III: Email message templates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

6. 4 Annex IV: File naming examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

6. 5 Annex V: Internalised Settlement reports - Examples for SetIn identification. . . . . . . . . . 75

5

ESMA REGULAR USE

1 Introduction

1. 1 Background

1. According to Article 9(1) of CSDR, settlement internalisers shall report to the Competent Authorities of their place of establishment on a quarterly basis the aggregated volume and value of all securities transactions that they settle outside securities settlement systems.

Competent Authorities shall, without delay, transmit the information received to ESMA and shall inform ESMA of any potential risk resulting from that settlement activity.

2. SetIns have to send quarterly reports to CAs, which CAs have to then send to ESMA in

accordance with:



Article 9 of CSDR;

• Commission Delegated Regulation (EU) 2017/391

• Commission Implementing Regulation (EU) 2017/393



ESMA Guidelines on internalised settlement reporting

3. The collection of data on internalised settlements will be performed by the CAs and sent to

ESMA; each CA will be collecting data from:









Settlement Internalisers established and operating within the CA’s jurisdiction, reporting their internalised settlement activity, including the activity of their branches in the CA’s jurisdiction;

Settlement Internalisers established in the CA’s jurisdiction, reporting the internalised settlement activity of their branches operating in the jurisdiction of other CAs within the EU;

The branches operating in the EU of Settlement Internalisers established outside the EU, reporting on their internalised settlement activity within the CA’s jurisdiction (LEI code of SetIn head office should be used for providing information on their identification);

Settlement Internalisers established within the CA’s jurisdiction, reporting the internalised settlement activity of their non-EU branches in an aggregated report with the Settlement Internaliser country code of operation set to “TS” (i. e. Third- Country States).

4. CAs should submit to ESMA reports on the potential risks resulting from the internalised settlement activity, in an agreed format. The reports on potential risks should be submitted within thirty (30) working days from the end of each quarter of a calendar year, specifying:

6

ESMA REGULAR USE



Identification of the reporting Competent Authority



Identification of potential risks (if any) resulting from the internalised settlement activity in their jurisdiction

1. 2 Project context

5. The below diagram shows the context and key logical components of the Central Securities

Depositories Regulation System:

6. The overall system is composed of the following logical components:

• CA internal systems receiving data from Settlement Internalisers and preparing them

for submission to ESMA. This is not included in the scope of this document

• The Hub: The aim of the Hub is to allow authorities to have a secure, central and common facility to exchange their data. The Hub is the network layer used for the purpose of data exchange between ESMA and CAs.

• ESMA Secured Web Interface: A web interface provided by ESMA supporting

o

the uploading of Internalised Settlement reports through a dedicated file- submission page; and

7

Settlement Internalisers Reporting SystemSettlement Internaliser CAESMA CAs internal Systems HUB

CAs internal Systems ESMA Database ReportvalidationCA

Submission via HUBSubmission via CSDR Secured Web Interface Settlement Internalisers Reporting System CAs internal Systems

CAs internal Systems Reportvalidation

ESMA Database CSDR Secured Web Interface

ESMA REGULAR USE

o

the submission of Potential Risks reports through a dedicated web entry form.

1. 3 Scope of this document

7. This document describes the processes and interfaces used to exchange information

between ESMA and CAs in the context of CSDR. In particular, it refers to:

• Overall process for Internalised Settlement reporting

• Overall process for Potential Risks reporting

• Common technical format for data submission

• Common set of data quality reports to be applied to each report

1. 4 Definitions

Authority Key

Country code of a CA

CA

CSDR

CSDRS9

Competent Authority designated by each Member State accordance with Article 11 of CSDR

in

Central Securities Depositories Regulation (Regulation (EU) No 909/2014)

CSDR System (i. e. ESMA’s project for implementing the ESMA CSDR Article9 IT solution)

EEA

European Economic Area

The CAs in the EEA EFTA States will be included, once CSDR, the Commission Delegated Regulation (EU) 2017/391, and the Commission (EU) 2017/393 are incorporated in the EEA Agreement and implemented in the legal and regulatory framework of the respective EEA EFTA States.

Implementing Regulation

ESMA

European Securities and Markets Authority

FSD

IT

ITMG

MS

PTSC

Functional Specifications Document

Information Technology

IT Management and Governance group

Member State

Post Trading Standing Committee

8

ESMA REGULAR USE

SetIns

TF

Settlement Internalisers

CSDR Guidelines Task Force

9

ESMA REGULAR USE

2 Overall process

2. 1 Actors

8. The CSDRS9 actors are:

• CA user, with core functionalities:

o Secured web interface:

▪ authenticate in system

▪ submit and manage (update/cancel) Internalised Settlement reports and

Potential Risks reports

▪ search/view/export Internalised Settlement reports and Potential Risks

reports

▪ create/view Internalised Settlement business intelligence reports

▪ obtain access to Feedback files (Archive page)

▪ manage CA contact details

o HUBEX:

▪ submit and manage (update/cancel) Internalised Settlement reports

▪ obtain access to Feedback files

• ESMA user, with core functionalities for the Secured web interface:

o authenticate in system

o search/view/export Internalised Settlement reports and Potential Risk reports

o create/view/export Internalised Settlement business intelligence reports

o configure system parameters for adjusting behaviour

o view CA contact details

10

Note: The following two actors, although they are part of the overall business flow as defined by Article 9 of CSDR, are not actors of the CSDRS9:

ESMA REGULAR USE

• Settlement Internalisers

• Branches of Settlement Internalisers

2. 2 Internalised Settlement reporting

9. Figure 1 depicts the flow of Settlement Internaliser data from Settlement Internalisers

established and operating within EU to Competent Authorities and then to ESMA.

Figure 1: Submission of Internalised Settlement report by EU-established Settlement Internalisers

10. Figure 2 depicts the flow of Internalised Settlement data originating from branches of a Settlement Internaliser operating within the EU in a member state different from its head office. In this case, the data flow starts from the branches, continues to the head office established and operating within the EU, to the Competent Authority of the head office, concluding to ESMA.

11

Competent Authorities (CAs) Settlement Internalisers $

MS1 $

MS2 $

$

$

SIs established andoperating withinEU Country 1 SIs established and operating withinEU Country 2

ESMA REGULAR USE

Figure 2: Submission of Internalised Settlement reports by EU-established Settlement Internalisers, having branches operating within the EU

11. Figure 3 depicts the flow of Settlement Internaliser data from Settlement Internaliser branches operating within the EU of a head office established outside the EU, to Competent Authorities, and then to ESMA. NOTE: For submission of SetIn reports by non- EU-established Settlement Internalisers having branches operating within the EU, the following process should be followed:

• Settlement Internaliser branch (operating within EU) reports to the respective CA (according to the place of operation of the branch); if a non-EU SetIn has several branches in the same country, these branches ought to coordinate for submitting one report with aggregated value and volume figures for all branches, using the head head office’s LEI. The reports submitted by such branch(es) should report the country code of their place of operation within the “Country Code” field.

• CA sends reports to ESMA.

12

Competent Authorities (CAs) Settlement Internaliser (head office) established and operating withinEU Country 1 $

Settlement Internaliser (branches) operating within EU Countries 2 and 3 $

$

$

EU Country 2 branch EU Country 3 branches

MS1

2 3 1 Legend:Reports sent internally from SetIn branches operating within the EU to the head office established and operating within the EUReport sent from SetIn head office established and operating within the EU to Country 1 CA for its operation within Country 1Report sent from SetIn head office established and operating within the EU to Country 1 CA for its branch operation within Country 2

3 4 4Report sent from SetIn head office established and operating within the EU to Country 1 CA for its aggregated branch operation within Country 3 1 2

ESMA REGULAR USE

Figure 3: Submission of Internalised Settlement reports by non-EU-established Settlement Internalisers, having branches operating within the EU

12. Figure 4 depicts the flow of Settlement Internaliser data from Settlement Internaliser branches operating outside the EU to the head office established within the EU to the Competent Authority, to ESMA. NOTE: The head-office collects and aggregates all its internalised settlement activity for all its non-EU branches into one report for which the country code of the place of operation of the Settlement Internaliser (i. e. branch country code) is set to “TS” (i. e. Third Country States).

13

Competent Authorities (CAs)

MS2 Settlement Internaliser (branches) operating withinEU Countries 1 and 2 $

$

$

EU Country 1 branch EU Country 2 branches

MS1

2 1 Legend:Report sent from a branch operating in EU Country 1 of a SetIn established outside the EU to EU Country 1 CA for its operationReport sent from a branch operating in EU Country 2 of a SetIn established outside the EU to EU Country 2 CA for the consolidated value and volume of Settlement Internaliser operations for all branches operating in Country 2

1 2

ESMA REGULAR USE

Figure 4: Submission of Internalised Settlement reports by EU-established Settlement Internalisers, having branches operating outside the EU

13. Each submitted report will be uniquely identified by the combination:

• Settlement Internaliser identifier (LEI)

• Branch Country code (i. e. , County Code of the place of operation of the Settlement

Internaliser; if report relates to head-office operation, this field is left blank)

• Reporting period

14. The Internalised Settlement reports can be submitted to ESMA through:

• HUBEX: the submitting entities can upload the Internalised Settlement reports in the

dedicated folder in HUBEX.

• ESMA Secured Web Interface: the CSDRS9 offers a dedicated file-submission page

for the submitting entities to submit the Internalised Settlement reports in zip format.

15. The CSDRS9 will automatically dispatch a “reminder” email notification to a CA when the deadline for submitting Internalised Settlement reports is past but no valid record is registered in the DB.

16. Through the ESMA Secured Web Interface, CA users must define the contact details of the CA persons responsible for Internalised Settlement reporting. The CA must necessarily

14

Competent Authorities (CAs) Settlement Internaliser (head office) established and operating withinEU Country 1 $

Settlement Internaliser (branches) operating in Countries 2 and 3outside the EU $

$

$

Country 2 Country 3

MS1

2 1 Legend:Reports sent internally from SetIn branches operating outside the EU to the head office established and operating within the EUReport sent from SetIn head office established and operating within the EU to Country 1 CA for its operation within Country 1 2 1 3 3Report sent from SetIn head office established and operating within the EU to Country 1 CA for the aggregated operation of all its non-EU branches; the branch country code is set to TS i. e. Third-Country States

ESMA REGULAR USE

define a Legal Representative, a Business Representative, an IT Representative, and optionally e-mail addresses of Other Representatives.

The data to be provided include:

• For the Legal Representative contact: a) name, b) function, c) phone number, and d)

email address, which are mandatory fields.

• For the Business Representative contact: a) name, b) function, c) phone number, and

d) email address, which are mandatory fields.

• For the IT Representative contact: a) name, b) function, c) phone number, and d) email

address, which are mandatory fields.

• For the Other Representatives: a list of comma separated e-mail addresses, which is

an optional field.

17. Unless the details of the Legal, Business and IT Representative are defined, the CSDRS9

will not accept any Internalised Settlement report.

2. 3 Potential Risk reporting

18. Figure 5 depicts the submission of Potential Risks reports from Competent Authorities to ESMA. In this submission flow, each CA provides ESMA with information on Potential Risks resulting from the internalised settlement activity.

Figure 5: Submission of Potential Risks

15

ESMA REGULAR USE

19. The CSDRS9 offers a dedicated space within ESMA Secured Web Interface (i. e. , web entry form) where the submitting entities can fill-in and submit the necessary information on Potential Risks through the dedicated web entry form.

20. Potential Risks reports should be submitted by the submitting entities even if there are no Potential Risks to be reported for the current period. For these cases, a “no risk reported” check box should be selected.

21. The CSDRS9 will automatically notify CAs via email when the deadline for submitting their Potential Risks reports is approaching (e. g. 15 working days prior to the deadline). The deadline for the submission of the Potential Risks reports is thirty (30) working days after the end of the running quarter.

22. The CSDRS9 will automatically notify CAs via email in case they have not submitted the Potential Risks reports for the running quarter when the end of a submission period is reached.

2. 4 Reporting and Submission Periods

23. The periods described below are legal requirements based on Commission Delegated Regulation (EU) 2017/391 and Commission Implementing Regulation (EU) 2017/393.

However, the CSDRS9 will not impose time-limits for submitting new Internalised Settlement reports or updating existing ones. Figure 6 depicts the prescribed Reporting and Submission periods; during a quarter’s Submission period:



for Internalised Settlement reports, CAs must collect from Settlement Internalisers and subsequently submit to ESMA Internalised Settlement reports for the respective Reporting Period



for Potential Risks reports, CAs must submit to ESMA reports for the respective Reporting Period

16

ESMA REGULAR USE

Figure 6: Reporting and Submission Periods

Note: The above dates are relevant for the purpose of notifications/alerts generated and dispatched by the CSDRS9.

24. The following table summarises the deadlines for key events in the CSDRS9:

Type of Reporting

Task

Responsible

Deadline

Internalised Settlements

Quarterly internalised settlement report

CA

End of quarter + 15 working days

Potential Risks

Quarterly potential risks report

CA

End of quarter + 30 working days

17

Internalised Settlement reports

01/0101/0401/0701/10Q1 Reporting PeriodQ2 Reporting PeriodQ3 Reporting PeriodQ4 Reporting Period Q4 Submission PeriodQ1 Submission PeriodQ2 Submission PeriodQ3 Submission Period 15 working days 15 working days 15 working days 15 working days Potential Risks reports

01/0101/0401/0701/10Q1 Reporting PeriodQ2 Reporting PeriodQ3 Reporting PeriodQ4 Reporting Period Q4 Submission PeriodQ1 Submission PeriodQ2 Submission PeriodQ3 Submission Period 30 working days 30 working days 30 working days 30 working daysWorking days are considered all calendar days Monday to Friday.

ESMA REGULAR USE

3 Error Handling

3. 1 Internalised Settlement reporting

25. As soon as an Internalised Settlement report file is received by the CSDRS9 (either through HUBEX or ESMA Secured Web Interface), the CSDRS9 will check that the zip file transmitted by the submitting entity can be extracted and that the containing xml file uses the expected naming convention. The naming convention to be used by the CAs when application submitting is ____. xml, where:

or HUBEX)

the CSDR

through

(either

files

• is prefix “NCA” followed by the Country Code of the submitting entity (e. g.

“NCAFR”)

• is the standard text “DATISR” standing for Data for Internalised Settlements

• is the standard text “CSDR9”

• contains the following elements delimited by “-“:

o

o

the Country code (ISO country code or the special value “TS”) that the report concerns

the LEI of the Settlement Internaliser (For branches of SetIns established outside the EU, branches should submit their reports providing the LEI of the head office (non-EU))

o

the year for which the content of the report relates to

o

the quarter for which the content of the report relates to (can be “Q1”, “Q2”, “Q3” or “Q4”) e. g. “FR-3157006IAVSO21FPLG03-2019-Q1”1

• is a four digits number stating the version of the report, which is an integer positive number. For its first submission, this number is 0001, and for every update/cancellation, this number is increased by 1 (e. g. , 0002, 0003 etc. ). For submissions that follow a cancellation, this number continue to increase by 1.

Example Q1_0001. xml”

filename:

“NCAFR_DATISR_CSDR9_FR-3157006IAVSO21FPLG03-2019-

1 If we assume that a German SetIn submits two files to the German CA, one for its own activity and one for its branch activity in “NCADE_DATISR_CSDR9_DE-98570084BVSO21FYLG12-2019- Italy, Q1_0001_20190403151312. zip” “NCADE_DATISR_CSDR9_IT-98570084BVSO21FYLG12-2019- Q1_0001_20190403161451. zip”.

will and

filenames

then

two

the

be:

18

ESMA REGULAR USE

The reporting XML file must be archived into a zip file and either be uploaded onto the HUBEX System or submitted through the ESMA Secured Web Interface.

Example Q1_0001. zip”

filename:

“NCAFR_DATISR_CSDR9_FR-3157006IAVSO21FPLG03-2019-

Upon reception of the file by HUBEX or the CSDR application, a timestamp will be added with the current date/time and the file will be then processed by the CSDRS9. In the former case, HUBEX routes it to the CA user’s “Outgoing” folder dedicated to the CSDRS9 and suffixes it with a timestamp in YYYYMMDDHHMMSS format (24h format, CET Central European Time). In latter case, the CSDRS9 automatically suffixes the timestamp in the filename. The naming convention is “____- __Timestamp. zip”

Example filename after being suffixed with a timestamp: “NCAFR_DATISR_CSDR9_FR- 3157006IAVSO21FPLG03-2019-Q1_0001_20190403151312. zip”

Note: Further file naming examples are available in Annex IV: File naming examples

26. A Settlement Internaliser report contains:

• one Report Header part, containing metadata for the report, comprising:

o Creation Date Time (i. e. the date the report was submitted by the SetIn to the

CA)

o Reporting Date (i. e. the last date of the quarter being reported)

o Currency (it should always be set to EUR)

o Report Status (NEWT for new report, AMND for an updated report, CANC for a

cancelation report)

• one Settlement Internaliser part, containing:

o

identification data of the Settlement Internaliser, i. e. ,

▪ LEI of the settlement internaliser

▪ Contact details of the liaison at the Settlement Internaliser

▪ Country code of the place of establishment of the Settlement Internaliser

(i. e. head- office) relating to the data that the report concerns

▪ Country code of the place of operation of the Settlement Internaliser (i. e.

branch), relating to the data that the report concerns, if applicable

19

ESMA REGULAR USE

o data for Overall Total, Financial Instruments, Transaction Types, Client Types

and Total Cash Transfers of the SetIn for the quarter and specified country

• one or more Issuer CSD parts, containing:

o

identification data of the Issuer CSD, i. e. ,

▪ LEI of the Issuer CSD (if known)



the first two characters of the ISIN code (and all manually configured 2- characters codes, e. g. XS/ EU),

▪ Country code of the Issuer CSD (if known)

o data for the Overall Total, Financial Instruments, Transaction Types, Client Types and Total Cash Transfers of the SetIn for the quarter, specified country and specific Issuer CSD

27. All business data is reported under two core data structures:



the Aggregate structure, containing:

o Settled data (volume, value)

o Failed data (volume, value)

o Total data (volume, value)



the Failed Rate structure, containing:

o Volume Percentage

o Value Percentage

28. Each report must be characterised by one of three possible statuses:

• New report (RptSts=NEWT):

o when a CA first reports for a given reporting period for a given country, or

o when a CA re- instates a previously cancelled report.

In both cases, if the file is successfully validated, the system will store a respective “IS entry” in the DB, flagging it as a “valid” record.

• Update report (RptSts=AMND): when a CA wishes to update data of a valid “IS entry”.

If the file is successfully validated, it will be stored in the DB as a “valid” report, while its previous version will be flagged as “invalid”.

20

ESMA REGULAR USE

• Cancel report (RptSts=CANC): when a CA has used an incorrect ‘LEI’ or ‘Reporting Period’ of a report, then the CA should cancel the previously submitted report. Hence the CA should submit an identical report with Reporting Status ‘Cancel’. Such a cancellation submission is necessary since the LEI and Reporting Period values are both part of the unique identification of the report. If the file is successfully validated, it will “invalidate” the existing “IS entry”. The cancelled data will be marked as cancelled and maintained in the DB. Cancelled data are not available for search and are not used for the content validation checks and the compilation of the standardised reports of the CSDRS9.

Further information on the versioning of the reports are available in paragraph 18.

29. Always when the CSDRS9 receives an Internalised Settlement report, it will process it and produce a feedback file. The filename of the feedback file will comply with the following naming convention “___-. zip”, where:

• is the standard text “CSDR9”

• is the standard text ‘FDBISR’ standing for feedback files generated by the system as a result of validation on processed data for Internalised Settlements reports

• is prefix “NCA” followed by the Country Code of the submitting entity (e. g.

“NCAFR”)

• and are identical to the respective received Internalised Settlements

report

Example Q1_0001_20190403151312. zip”

filename:

“CSDR9_FDBISR_NCAFR_FR-3157006IAVSO21FPLG03-2019-

If the original file was submitted through ESMA Secured Web Interface, the feedback filename is made available within the Archive page in ESMA Secured Web Interface, while if the original file was submitted through HUBEX, the feedback file is uploaded onto the outgoing folder to the appropriate incoming CA folder in HUBEX.

30. At this stage, if an error is identified during file validation, the processing stops, all records contained in the submitted file are rejected and a feedback message explaining the reason for rejection is sent to the submitting entity, through a feedback file generated by the system. Furthermore, an email notification is sent to the submitting entity (CA) containing the ESMA email address to contact for obtaining support if required. The submitting entity will have to fix the errors and resubmit the full file for reprocessing.

31. After the successful transmission validation, the CSDRS9 will perform XML validation of the received file against the commonly agreed XSD schema for Internalised Settlement data reporting (ISO-20022 message)annexed to the ’Settlement Internaliser Report data message’ section of the current document.

21

ESMA REGULAR USE

32. At this stage, if an error is identified, the processing stops, all records contained in the file are rejected and a feedback message explaining the reason for rejection is sent to the submitting entity. Furthermore, an email notification is sent to the submitting entity (CA), containing the ESMA email address to contact for obtaining support if required. The submitting entity will have to fix the errors and resubmit the full file for reprocessing.

33. After the successful completion of format validation, the CSDRS9 will perform automated

data quality checks, as described in section 6. 2. This process can lead to:

• errors: forming defects that render the report invalid, requiring correction and re-

submission before its contents can be accepted and stored in the system’s DB

• warnings: in case there are no errors, warnings from potential errors that shall be checked by ESMA, while the report is accepted by the system and its content stored in the system’s DB

• no errors: the report is accepted by the system

34. During content validation, if at least one error is identified, the corresponding file (i. e. the complete Internalised Settlement report) will be rejected. The CSDRS9 will send feedback (through a feedback file generated by the system) to the submitting entity on the full list of validation checks that failed, reporting errors. Furthermore, an email notification is sent to the submitting entity (CA), containing the ESMA email address to contact for obtaining support if required. The submitting entity will have to fix the errors and resubmit the full file for reprocessing

35. If data content validation is completed identifying no errors, the CSDRS9 will send a confirmation of data receipt to the submitting entity, through a feedback file generated by the system and will store the received records included in the submitted file in the database.

Furthermore, an email notification is sent to the submitting entity (CA), containing the ESMA email address to contact for obtaining support if required.

36. Immediately after successful content validation (i. e. no error is identified), the system will perform two kinds of “warning” checks. If any of the two checks fails, the system will notify ESMA users. The following two kinds of “warning” checks are defined:





the system will check the SetIn reported against the previous reporting period. If the SetIn was not reported in the previous reporting period, a “warning” email notification will be sent (to the ESMA user).

the system will check the Issuer CSDs reported against a static list of Issuer CSDs contained in the system’s DB. If data against an unknown Issuer CSD is reported, a “warning” email notification will be sent (to the ESMA user).

22

ESMA REGULAR USE

3. 2 Potential Risk reporting

37. Validation on the Potential Risk report entry form will be performed on-the-fly, upon user’s web entry form submission (submission by the CA user). In case data errors are identified, the web entry form will prompt the submitting user (CA) to provide valid input on the respective erroneous field. The submitting user (CA) will have to fix the errors and resubmit the web entry form for reprocessing.

38. If data submission is successfully completed, the CSDRS9 will confirm receipt through the web-page. Moreover, an email notification will be dispatched (to the corresponding CA user), confirming the successful receipt of the submitted Potential Risks report.

23

ESMA REGULAR USE

4 Modification of reports

4. 1 Re-submission of report

39. An Internalised Settlement report can be re-submitted, allowing the CA to correct potential erroneous data. To re-submit, all file and content validation rules are applicable, with the following deviations:

• The filename updating the data of an already submitted report must be identical to the filename (i. e. ____) of the previous version of the report, increasing the value of Key2 (i. e. version number) by 1, as described in paragraph 25.

• Under the respective status field, the XML should include the value “update”.

• The report must be uniquely identified and matched to its previous version by the rules

described under paragraph 13.

40. When the CSDRS9 receives a SetIn report relating to a LEI which does not correspond to an EU country (i. e. a report that relates to a non-EU SetIn), the system will verify if the submission relates to an update of an existing report. If indeed the submission relates to an update, the system will cross-check the name of the person responsible (field “Name of person responsible”) against the previous version of the report. If contact person between the two reports is different, the system will notify the CA that an update on an existing report might be incorrect.

41. A Potential Risks report can be re-submitted, allowing the CA to correct potential erroneous data. To do so, the secured web interface (i. e. , web entry form) allows the CA users to view the latest submitted report, pre-populated with the data of the existing record. The CA user may then modify and re-submit the report.

4. 2 Cancellation of report

42. An Internalised Settlement report can be cancelled, allowing the CA to correct an

erroneous LEI or Reporting Period. To cancel:

• A new “cancellation” report is submitted, abiding by the naming convention specified at

paragraph 25.

• Under the respective status field, the XML should include the value “cancel”.

• The report must be uniquely identified and matched to its previous version by the rules

described at paragraph 13.

• The cancelled data will be marked as cancelled and maintained in the system

database.

24

ESMA REGULAR USE

43. Cancellation of Potential Risks reports is not supported.

25

ESMA REGULAR USE

5 Internalised Settlement Reporting messages

5. 1 Settlement Internaliser Report data message

44. Figure 7 depicts the conceptual schema of the Internalised Settlement reporting XSD.

Figure 7: Conceptual schema of the Internalised Settlement report XSD

45. Figure 8, Figure 9 and Figure 10 depict the various element names and data types that model in full the Internalised Settlement report. For the reader’s better understanding, the presentation of all XSD elements is combined with the Internalised Settlement report, as defined in COMMISSION IMPLEMENTING REGULATION (EU) 2017/393.

26

Settlement Internaliser Report Report Header Settlement Internaliser Issuer CSD

11. . *1 Settlement Internaliser Identification Issuer CSD Identification

1 Overall Total Financial Instrument Transaction Type Client Type Total Cash Transfer 1 Settled Failed Total Volume Percentage Value Aggregate Failed Rate 1 1 per type(9 Financial Instrument types) 1 per type(5 Transaction types) 1 per type(2 Client types) 1 1 for each category Categories

ESMA REGULAR USE

27

Figure 8: Internalised Settlement XSD – Overall structure

ESMA REGULAR USE

Figure 9: Internalised Settlement XSD – Structure containing financial data

28

ESMA REGULAR USE

Figure 10: Internalised Settlement XSD – Financial, Transaction and Client Types and Cash Transfers

46. The Settlement Internaliser report XSD file is attached below.

29

ESMA REGULAR USE

47. A Settlement Internaliser report sample XML file is attached below.

5. 2 Status advice / Feedback message

48. The

filename of a

convention “___-. xml” as described in paragraph 29.

file abides by

feedback

following

the

49. The feedback file is compressed in zip format, and contains one XML file with the same

filename but different file extension (xml instead of zip), as described in paragraph 29.

Example zip filename: “CSDR9_FDBISR_NCAFR_FR-3157006IAVSO21FPLG03-2019- Q1_0001_20190403151312. zip”. Within this file, one XML file will be contained, named “CSDR9_FDBISR_NCAFR_FR-3157006IAVSO21FPLG03-2019-Q1_0001. xml”.

50. The feedback file may report one of the following three statuses:

• Corrupted (CRPT): the Internalised Settlement report is flagged as corrupted when:

o zip file cannot be opened or decompressed

• Rejected (RJCT): the Internalised Settlement report is flagged as rejected when:

o zip file does not contain one single XML file

o

the contained xml file does not have the same filename as the container zip file (except timestamp and extension)

o

the report does not use the same XML Schema as the one used by the system

o

the report uses exactly the same filename previously used

o

the report relates to a country that is not recognised as an EEA country

o

the report cannot be validated against the XML Schema

o

the content of the report violates any of the Data Content Validation rules, in which case Record Status elements will be included in the feedback file, detailing the exact records violating Data Content validation rules, all having the status “RJCT”

• Accepted (ACPT): the Internalised Settlement report is flagged as accepted when it

passes successfully all validation checks

30 SettlementInternaliserReportV01_auth. 072. 001. 01_sample. xml

ESMA REGULAR USE

51. A feedback report (status advice message) comprises the Status Advice message

component, which contains two distinct components:

• Message Status component, i. e. , validation information regarding the full received

SetIn report, containing:

o Status (i. e. , status of the whole message)

▪ ACPT for accepted report

▪ RJCT for rejected report

▪ CRPT in case the file that contains the received report is corrupted

o Validation Rule, containing information on the rule which failed/could not be validated. This element reports rules that may be violated which are not bound to a specific record but instead relate to the whole report. The specific sub- elements are:



Identification (unique identification of the validation rule)

▪ Description (further information on the validation rule)

• Record Status component, i. e. , validation information regarding specific erroneous record(s) included in the received SetIn report. This element reports rules that may be violated which are bound to a specific record. The specific sub-elements are:

o Original Record Identification, i. e. , unique identification of the Issuer CSD

erroneous record: [first 2-characters of ISIN, LEI]

o Status, i. e. , status RJCT for the erroneous record

o Validation Rule, i. e. , unique identification and further details on the rule that

failed per record, containing:



Identification

▪ Description

5. 3 Feedback

52. The structure and details of the derived Status Advice message is outlined in Figure 11.

31

ESMA REGULAR USE

32

Figure 11: Status Advice XSD structure

53. The Feedback file XSD is attached below.

54. A feedback sample XML file is attached below.

Name: StsAdvc Name: MsgSts Name: Sts Name: VldtnRule Name: Id Name Desc Name: RcrdSts Name: OrgnlRcrdId Name: Sts Name: VldtnRule Name: Id Name DescStatusAdvice_auth031. 001. 01_sample. xml

ESMA REGULAR USE

5. 4 Business Application Header

55. The Business Application Header (BAH) is a header that has been defined by the ISO 20022 community that can form part of an ISO 20022 business message. Specifically, the BAH is an ISO20022 message definition (head. 001. 001. 01) which can be combined with any other ISO20022 message definition to form a business message. It gathers together, in one place, data about the message, such as which organisation has sent the business message, which organisation should be receiving it, the identity of the message itself, etc.

56. The purpose of the BAH is to provide a consistent and predictable way for this data to be conveyed with the message, regardless of implementation factors such as the choice of network. The use of the BAH in CSDR reporting is mandatory. With respecti to the ‘From’ and ‘To’ elements, each CA will define the appropriate ID for filling in the ‘ID’ element, for the SetIn-CA communication. The below table presents the list of mandatory elements of the BAH that should be included in the message and how the should be populated.

NOTE: The ‘From’/ ‘To’ elements are composed of two sub-elements (i. e. , ID and SchmeNm).

The ‘ID’ is a mandatory element of type ‘Max35Text’ (based on string). The ‘SchmeNm’ is an optional element of type ExternalOrganisationIdentification1Code (based on string) allowing an additional code of max4text to be used if needed.

Element

Description

Usage in Reporting Message (i. e. Report)

Usage in Status Advice Message (i. e. Feedback)

From

The sender of the message

. . <. < OrgId>. .

. . <. .

.

Country code of the CA

EU

To

The recipient of the message

. . <. < OrgId>. .

. . <. . .

Business Message Identifier

Unambiguously identifies the Business Message to the MessagingEndpoi nt that has created the Business Message.

EU

Country code of the CA

Same as Reporting Message

Rules for populating this identifier to be specified at national level

33

ESMA REGULAR USE

Message Definition Identifier

Creation Date

Related

Identification of the type of the message (ISO 20022 message identifier)

The identifier of relevant ISO 20022 message (using base name only) of the reporting message, i. e. , auth. 072. 001. 01

The identifier of relevant ISO 20022 message (using base name only) of the generated feedback file, i. e. , auth. 031. 001. 01

Date and time in ISO 8601 format.

Unused

The copy of the BAH of the referred data message (it allows to link the status advice and the reporting message)

Date and time when this Business Message was created

Specifies the Business Application Header of the Business Message to which this Business Message relates.

57. The Business Application Header XSD is the one attached below.

5. 5 Business File Header

58. Each ISO 20022 business message shall be sent together with the Business Application Header (BAH) message. These are separate messages and should be packaged within an additional structure, referred to as “envelope”, in order to constitute a single XML file. The Business File Header is a simple XML file that encapsulates the BAH and the Reporting message or Status Advice message.

59. The Business File Header XSD is the one attached below.

34

ESMA REGULAR USE

5. 6 ISO 20022 auth. 072. 001. 01 message definition - CSDR9 base/

derived message

The approved ISO20022 base message definition for the CSDR9 Internalised Settlement reporting (i. e. SettlementInternaliserReportV01 – auth. 072. 001. 01) is available at the ISO20022 website under section: Catalogue of messages > Full catalogue > auth – Authorities (https://www. iso20022. org/).

The derived version of the auth. 072. 001. 001 ISO20022 message definition forms a cut down version of the approved ISO20022 base message definition and its XSD version is the one used by the CSDRS9. The derived message is available at MyStandards platform (https://www2. swift. com/mystandards) within space (https://www2. swift. com/mystandards/#/publishing!usage_guidelines); in order to access this space a SWIFT account is required.

the ESMA group publishing

The differences between the auth. 072. 001. 01 base message definition and the derived message definition are described in detail below:





'Supplementary Data' section: this section, that is available in the base message forming a standardised section for all ISO 20022 base message definitions, has been removed from the CSDR9 derived message definition

'Settlement Internaliser Identification' section - 'LEI' element: the following comment has been added in the CSDR9 derived message definition to further clarify the usage of this element

o The LEI identification is used to uniquely identify the Settlement Internalisers that submit reports. For head-offices and branches of Settlement Internalisers established within the EU, Settlement Internalisers must submit reports providing the LEI of the head-office (EU). For branches operating in the EU of Settlement Internalisers established outside the EU, branches must submit their reports providing the LEI of the head-office (non-EU).



'Settlement Internaliser Identification' section - 'Country' element: the following comment has been added in the CSDR9 derived message definition to further clarify the usage of this element

o The country code is used to identify the country of the place of establishment of the Settlement Internaliser (head-office) when the Settlement Internaliser is established within the EU, or the place of operation (branch) when the Settlement Internaliser is established outside the EU.



'Settlement Internaliser Identification' section - 'Branch' element: the following comment has been added in the CSDR9 derived message definition to further clarify the usage of this element

35

ESMA REGULAR USE

o The branch country code (ISO 3166) is used to identify the country of the branch of a Settlement Internaliser established within the EU when the report concerns data relating to a branch(es) operating in a different jurisdiction than the place of establishment of the Settlement Internaliser (head-office). For branches operating within the EU, the country code (ISO 3166) of the place where the branch operates must be provided. If the report concerns data relating to branches of EU Settlement Internalisers operating outside the EU, the code ‘TS’ must be used. If the report concerns data relating to branches of non-EU established Settlement Internalisers operating within the EU, the branch country code should not be provided. A valid ISO 3166 2-character code should be used, apart from the case where the 2-characters 'TS' code is used.



'Issuer CSD' section: the following comment has been added in the CSDR9 derived message definition to further clarify the usage of this section

o Defines dataset relating to the combination between the first two characters of the ISIN and the LEI of the Issuer CSD (when provided). Each combination of the first two characters of the ISIN and the LEI should be unique.



'Issuer CSD' section - 'LEI' element: the following comment has been added in the CSDR9 derived message definition to further clarify the usage of this element

o The LEI code is used to identify the Issuer CSD. Although optional, if it is known,

it should be provided.



'Issuer CSD' section - 'First Two Characters Instrument Identification' element: the following comment has been added in the CSDR9 derived message definition to further clarify the usage of this element

o

If the instrument identifier is a valid ISIN or follows the ISIN format, the first two characters of the instrument identifier should be used. For financial instruments without an ISIN or ISIN formatted identifier, the 2 character code 'IC' should be used.



'Issuer CSD' section - 'Country' element: the following comment has been added in the CSDR9 derived message definition to further clarify the usage of this element

o The country code is used for the identification of the Issuer CSD2.

2 In case both the LEI and country code are populated, the system will validate the correctness of the reported country code comparing it against the country code corresponding to the LEI in the GLEIF reference data. In case of inconsistency, the report will be rejected.

In case the LEI is populated, while the country code is not, the system will automatically fetch the country code corresponding to the LEI in the GLEIF reference data and store it.

36

ESMA REGULAR USE

6 Annexes

6. 1 Annex I: File Validation Rules

ID

1

Control

Validation rules

Error code

Transmission Validation

Error message

All files on CSDRS9 are compressed in zip format. When treating a file, the first step is the decompression of the zip file.

This error is returned by the system if the file cannot be decompressed.

FIL-101 The file cannot be

decompressed.

2 Once the file is decompressed, CSDRS9 checks that the decompressed container zip file contains exactly one XML file. This error is returned by the system when no XML or more than one file is found.

FIL-102 The file contains no or more

than 1 XML file.

FIL-103 The name of the XML file is not consistent with the name of its container ZIP file.

3 Once the file is decompressed and it is verified that exactly one XML file is submitted, CSDRS9 checks that the sender code, the Sender, the Recipient, the Country code report concerns, the LEI of the Settlement Internaliser, the Year, the Quarter and the Version of the XML file and of the ZIP file are identical. This error is returned by the the aforementioned fields is not identical in the ZIP and XML filenames.

system when any

that

the

of

Format Validation

1

When a file is received, the system checks whether a file with the same filename has already been submitted to CSDRS9.

The timestamp of the file should not be taken into account for this validation.

FIL-107 File has already

been submitted once

37

ESMA REGULAR USE

FIL-104 The

ISO 20022 Message

Identifier is not valid.

FIL-105 The

file structure does not the XML

to

correspond schema.

38

The ISO 20022 Message Identifier must refer to the agreed schema used by the system.

Validate that the file sent fits to the corresponding XML schema.

2

3

Record

Identifier3

ESMA REGULAR USE

6. 2 Annex II: Content Validation Rules

#

0. 1

0. 2

Control

Error code

Error message

0. Header Information:

INS-001

The Currency is not valid. Only the value “EUR” is expected.

No

INS-002

The date [Reporting period value] is not valid. One of YYYY-03- 31, YYYY-06-30, YYYY-09-30 or YYYY-12-31 is expected, where YYYY is the year of the report.

No

The element of the report must always contain the value “EUR”.

The element of the report must have one of the following values:

YYYY-03-31

YYYY-06-30

YYYY-09-30 or

YYYY-12-31

3 Certain validation rules may be violated more than once within the same Internalised Settlement report. For this reason, when such a rule is violated, it is necessary for the respective feedback file to precisely indicate the exact record violating the rule. When a validation rule is violated in the Settlement Internaliser part of the report, the record identifier within the feedback file will be “Row | Settlement Internaliser”, while when it is violated in the Issuer CSD part, the record identifier will be “Row | Issuer CSD LEI | Two-characters ISIN | Country code ”. For validation rules that may be violated only once, no record identifier will be present.

39

ESMA REGULAR USE

INS-003

The Sender Country code of the filename [Country code in Sender] is not consistent to the Sender Country code [Id element in the xml] of the Settlement Internaliser Report.

No

0. 3

Where YYYY, is the year of the report (e. g. 2018).

The 2-character ISO country code retrieved from the field of the filename must be the same as the . . . . . . of the Business Application Header

1. Settlement internaliser information: .

1. 1 Obsolete

1. 2 Obsolete

1. 3

The must be ISO 17442 valid

INS-013

The LEI [LEI] is not valid according to ISO 17442.

Yes

1. 4 Country code: The country code of the element of the report’s filename must be consistent to the or of the

Settlement Internaliser

1. 4. 1 The Country code included in the

element of the report’s filename must be the same as the Settlement

the Internaliser report, the is not provided.

in case

of

INS-014. 1

The Country code of the filename [Country code in Key1] is not consistent to the Country code of establishment [Country code element in the xml] of the Settlement Internaliser Report.

No

40

ESMA REGULAR USE

INS-014. 2

The Country code of the filename [Country code in Key1] is not consistent to the Country code of operation [Country code element in the xml] of the Settlement Internaliser Report.

1. 4. 2 The Country code included in the

element of the report’s filename must be the same as the

the Settlement Internaliser, if provided.

element

of

1. 4. 3 The value, if provided, must be either a valid EEA ISO 3166 country code or equal to ‘TS’.

INS-014. 3

The branch country code is not valid, since it must relate either to an EEA country code or to a Third Country State (i. e. ‘TS’).

No

1. 5

The must

INS-015

The LEI [LEI] is not a valid LEI

Νο

• exist in the GLEIF database; the validityEndDate of the • respective GLEIF record is NULL; and

the status of the respective GLEIF "Lapsed", record “Merged”, "Pending transfer" or "Pending archival".

"Issued",

is

1. 6

If INS-015 has been successfully validated the provided LEI is valid in GLEIF database) then:

(meaning

that

If the LEI_LADR_COUNTRY field of this LEI in the GLEIF database is an

INS-016

The Country code [Ctry] is not consistent with the country in the Legal address as listed in GLEIF.

Yes

41

ESMA REGULAR USE

EEA country, validate that it is the same as the field.

1. 7

1. 8

INS-017

The Country code [Ctry] is not valid, since it must be an EEA country code

Yes

that

(meaning

If INS-015 has been successfully validated the provided LEI is valid in FIRDS) and if the LEI_LADR_COUNTRY FIRDS field of this LEI is not an EEA country, the

value is a valid EEA ISO 3166 country code.

then validate

that

The country of the sender (identified as characters 4-5 of the filename) must be the same as the country reported under Document/SttlmIntlrRpt/SttlmIntlr/Id /Ctry

INS-018

The country of the sender [Country code in Sender] is not consistent with the Settlement Internaliser Identification element.

the country reported under

1. 8

2. 1

The sum of settled volume plus failed volume must be equal to the total volume:

. . + . . = . .

2. Financial Instruments < FinInstrm>

2. 1. 1 For Eqty element

INS-021. 1

For the financial instrument “Transferable securities referred to in point (a) of Article 4(1)(44) of Directive 2014/65/EU” the sum of settled volume plus failed volume is not equal to the total volume.

Yes

42

ESMA REGULAR USE

2. 1. 2 For SvrgnDebt element

INS-021. 2

2. 1. 3 For Bd element

INS-021. 3

2. 1. 4 For OthrTrfblScties element

INS-021. 4

2. 1. 5 For XchgTradgFnds element

INS-021. 5

2. 1. 6 For CllctvInvstmtUdrtkgs element

INS-021. 6

2. 1. 7 For MnyMktInstrm element

INS-021. 7

2. 1. 8 For EmssnAllwnc element

INS-021. 8

For the financial instrument “Sovereign debt referred to in Article 4(1)(61) of Directive 2014/65/EU” the sum of settled volume plus failed volume is not equal to the total volume.

For the financial instrument “Transferable securities referred to in point (b) of Article 4(1)(44) of Directive 2014/65/EU other than sovereign debt referred in Article 4(1)(61) of Directive 2014/65/EU” the sum of settled volume plus failed volume is not equal to the total volume.

to

For the financial instrument “Transferable securities referred to in point (c) of Article 4(1)(44) of Directive 2014/65/EU” the sum of settled volume plus failed volume is not equal to the total volume.

For the financial instrument “Exchange-traded funds as defined in point (46) of Article 4(1) of Directive 2014/65/EU” the sum of settled volume plus failed volume is not equal to the total volume.

For the financial instrument “Units in collective investment undertakings other than ETFs” the sum of settled volume plus failed volume is not equal to the total volume.

For the financial instrument “Money market instruments other than sovereign debt referred in Article 4(1)(61) of Directive 2014/65/EU” the sum of settled volume plus failed volume is not equal to the total volume.

to

Yes

Yes

Yes

Yes

Yes

Yes

For the financial instrument “Emission allowances” the sum of settled volume plus failed volume is not equal to the total volume.

Yes

43

ESMA REGULAR USE

2. 1. 9 For OthrFinInstrms element

INS-021. 9

For the financial instrument “Other financial instruments” the sum of settled volume plus failed volume is not equal to the total volume.

Yes

2. 2

For each type of financial instrument, the sum of settled value plus failed value must be equal to the total value:

. . + . . = . .

2. 2. 1 For Eqty element

INS-022. 1

2. 2. 2 For SvrgnDebt element

INS-022. 2

2. 2. 3 For Bd element

INS-022. 3

2. 2. 4 For OthrTrfblScties element

INS-022. 4

2. 2. 5 For XchgTradgFnds element

INS-022. 5

For the financial instrument "Transferable securities referred to in point (a) of Article 4(1)(44) of Directive 2014/65/EU" the sum of settled volume plus failed volume is not equal to the total volume.

For the financial instrument "Sovereign debt referred to in Article 4(1)(61) of Directive 2014/65/EU" the sum of settled volume plus failed volume is not equal to the total volume.

For the financial instrument "Transferable securities referred to in point (b) of Article 4(1)(44) of Directive 2014/65/EU other than sovereign debt referred in Article 4(1)(61) of Directive 2014/65/EU" the sum of settled volume plus failed volume is not equal to the total volume.

to

For the financial instrument "Transferable securities referred to in point (c) of Article 4(1)(44) of Directive 2014/65/EU" the sum of settled volume plus failed volume is not equal to the total volume.

For the financial instrument "Exchange-traded funds as defined in point (46) of Article 4(1) of Directive 2014/65/EU" the sum of settled volume plus failed volume is not equal to the total volume.

Yes

Yes

Yes

Yes

Yes

44

ESMA REGULAR USE

2. 2. 6 For CllctvInvstmtUdrtkgs element

INS-022. 6

2. 2. 7 For MnyMktInstrm element

INS-022. 7

2. 2. 8 For EmssnAllwnc element

INS-022. 8

2. 2. 9 For OthrFinInstrms element

INS-022. 9

For the financial instrument "Units in collective investment undertakings other than ETFs" the sum of settled volume plus failed volume is not equal to the total volume.

For the financial instrument "Money market instruments other than sovereign debt referred in Article 4(1)(61) of Directive 2014/65/EU" the sum of settled volume plus failed volume is not equal to the total volume.

to

Yes

Yes

For the financial instrument "Emission allowances" the sum of settled volume plus failed volume is not equal to the total volume.

Yes

For the financial instrument "Other financial instruments" the sum of settled volume plus failed volume is not equal to the total volume.

Yes

2. 3

For each type of financial instrument, the Failed Rate Volume % must be consistent to the corresponding Aggregate Failed and Aggregate Total data:

. . * 100 / . . = .

2. 3. 1 For Eqty element

INS-023. 1

2. 3. 2 For SvrgnDebt element

INS-023. 2

For the financial instrument "Transferable securities referred to in point (a) of Article 4(1)(44) of Directive 2014/65/EU" the Failed Rate Volume % is not consistent to the corresponding Aggregate Failed and Aggregate Total data.

For the financial instrument "Sovereign debt referred to in Article 4(1)(61) of Directive 2014/65/EU" the Failed Rate Volume % is not consistent to the corresponding Aggregate Failed and Aggregate Total data.

Yes

Yes

45

ESMA REGULAR USE

2. 3. 3 For Bd element

INS-023. 3

2. 3. 4 For OthrTrfblScties element

INS-023. 4

2. 3. 5 For XchgTradgFnds element

INS-023. 5

2. 3. 6 For CllctvInvstmtUdrtkgs element

INS-023. 6

2. 3. 7 For MnyMktInstrm element

INS-023. 7

For the financial instrument "Transferable securities referred to in point (b) of Article 4(1)(44) of Directive 2014/65/EU other than sovereign debt referred in Article 4(1)(61) of Directive 2014/65/EU" the Failed Rate Volume % is not consistent to the corresponding Aggregate Failed and Aggregate Total data.

to

For the financial instrument "Transferable securities referred to in point (c) of Article 4(1)(44) of Directive 2014/65/EU" the Failed Rate Volume % is not consistent to the corresponding Aggregate Failed and Aggregate Total data.

For the financial instrument "Exchange-traded funds as defined in point (46) of Article 4(1) of Directive 2014/65/EU" the Failed Rate Volume % is not consistent to the corresponding Aggregate Failed and Aggregate Total data.

For the financial instrument "Units in collective investment undertakings other than ETFs" the Failed Rate Volume % is not consistent to the corresponding Aggregate Failed and Aggregate Total data.

For the financial instrument "Money market instruments other than sovereign debt referred in Article 4(1)(61) of Directive 2014/65/EU" the Failed Rate Volume % is not consistent to the corresponding Aggregate Failed and Aggregate Total data.

to

Yes

Yes

Yes

Yes

Yes

46

ESMA REGULAR USE

2. 3. 8 For EmssnAllwnc element

INS-023. 8

2. 3. 9 For OthrFinInstrms element

INS-023. 9

For the financial instrument "Emission allowances" the Failed Rate Volume % is not consistent to the corresponding Aggregate Failed and Aggregate Total data.

For the financial instrument "Other financial instruments" the Failed Rate Volume % is not consistent to the corresponding Aggregate Failed and Aggregate Total data.

Yes

Yes

2. 4

For each type of financial instrument, the Failed Rate Value % must be consistent to the corresponding Aggregate Failed and Aggregate Total data:

. . * 100 / . . = .

2. 4. 1 For Eqty element

INS-024. 1

2. 4. 2 For SvrgnDebt element

INS-024. 2

2. 4. 3 For Bd element

INS-024. 3

For the financial instrument "Transferable securities referred to in point (a) of Article 4(1)(44) of Directive 2014/65/EU" the Failed Rate Value % is not consistent to the corresponding Aggregate Failed and Aggregate Total data.

For the financial instrument "Sovereign debt referred to in Article 4(1)(61) of Directive 2014/65/EU" the Failed Rate Value % is not consistent to the corresponding Aggregate Failed and Aggregate Total data.

For the financial instrument "Transferable securities referred to in point (b) of Article 4(1)(44) of Directive 2014/65/EU other than sovereign debt referred in Article 4(1)(61) of Directive 2014/65/EU" the Failed Rate Value % is not consistent to the corresponding Aggregate Failed and Aggregate Total data.

to

Yes

Yes

Yes

47

ESMA REGULAR USE

2. 4. 4 For OthrTrfblScties element

INS-024. 4

2. 4. 5 For XchgTradgFnds element

INS-024. 5

2. 4. 6 For CllctvInvstmtUdrtkgs element

INS-024. 6

2. 4. 7 For MnyMktInstrm element

INS-024. 7

2. 4. 8 For EmssnAllwnc element

INS-024. 8

2. 4. 9 For OthrFinInstrms element

INS-024. 9

For the financial instrument "Transferable securities referred to in point (c) of Article 4(1)(44) of Directive 2014/65/EU" the Failed Rate Value % is not consistent to the corresponding Aggregate Failed and Aggregate Total data.

For the financial instrument "Exchange-traded funds as defined in point (46) of Article 4(1) of Directive 2014/65/EU" the Failed Rate Value % is not consistent to the corresponding Aggregate Failed and Aggregate Total data.

For the financial instrument "Units in collective investment undertakings other than ETFs" the Failed Rate Value % is not consistent to the corresponding Aggregate Failed and Aggregate Total data.

For the financial instrument "Money market instruments other than sovereign debt referred in Article 4(1)(61) of Directive 2014/65/EU" the Failed Rate Value % is not consistent to the corresponding Aggregate Failed and Aggregate Total data.

to

For the financial instrument "Emission allowances" the Failed Rate Value % is not consistent to the corresponding Aggregate Failed and Aggregate Total data.

For the financial instrument "Other financial instruments" the Failed Rate Value % is not consistent to the corresponding Aggregate Failed and Aggregate Total data.

Yes

Yes

Yes

Yes

Yes

Yes

3. Type of transactions

48

ESMA REGULAR USE

3. 1

For each type of transaction, the sum of settled volume plus failed volume must be equal to the total volume.

. . + . . = . .

3. 1. 1 For SctiesBuyOrSell element

INS-031. 1

3. 1. 2 For CollMgmtOpr element

INS-031. 2

3. 1. 3 For SctiesLndgOrBrrwg element

INS-031. 3

3. 1. 4 For RpAgrmt element

INS-031. 4

3. 1. 5 For OthrTxs element

INS-031. 5

For the type of transaction "Purchase or sale of securities" the sum of settled volume plus failed volume is not equal to the total volume.

Yes

For the type of transaction "Collateral management operations" the sum of settled volume plus failed volume is not equal to the total volume.

For the type of transaction "Securities lending and securities borrowing" the sum of settled volume plus failed volume is not equal to the total volume.

Yes

Yes

For the type of transaction "Repurchase transactions" the sum of settled volume plus failed volume is not equal to the total volume.

Yes

For the type of transaction "Other securities transactions" the sum of settled volume plus failed volume is not equal to the total volume.

Yes

3. 2

For each type of transaction, the sum of settled value plus failed value must be equal to the total value:

. . + . . = . .

3. 2. 1 For SctiesBuyOrSell element

INS-032. 1

3. 2. 2 For CollMgmtOpr element

INS-032. 2

For the type of transaction "Purchase or sale of securities" the sum of settled value plus failed value is not equal to the total value.

Yes

For the type of transaction "Collateral management operations" the sum of settled value plus failed value is not equal to the total value.

Yes

49

ESMA REGULAR USE

3. 2. 3 For SctiesLndgOrBrrwg element

INS-032. 3

3. 2. 4 For RpAgrmt element

INS-032. 4

3. 2. 5 For OthrTxs element

INS-032. 5

For the type of transaction "Securities lending and securities borrowing" the sum of settled value plus failed value is not equal to the total value.

Yes

For the type of transaction "Repurchase transactions" the sum of settled value plus failed value is not equal to the total value.

Yes

For the type of transaction "Other securities transactions" the sum of settled value plus failed value is not equal to the total value.

Yes

3. 3

For each type of transaction, the Failed Rate Volume must be consistent to the corresponding Aggregate Failed and Aggregate Total data:

. . * 100 / . . = .

3. 3. 1 For SctiesBuyOrSell element

INS-033. 1

3. 3. 2 For CollMgmtOpr element

INS-033. 2

3. 3. 3 For SctiesLndgOrBrrwg element

INS-033. 3

3. 3. 4 For RpAgrmt element

INS-033. 4

For the type of transaction "Purchase or sale of securities" the Failed Rate Volume % is not consistent to the corresponding Aggregate Failed and Aggregate Total data.

For the type of transaction "Collateral management operations" the Failed Rate Volume % is not consistent to the corresponding Aggregate Failed and Aggregate Total data.

For the type of transaction "Securities lending and securities borrowing" the Failed Rate Volume % is not consistent to the corresponding Aggregate Failed and Aggregate Total data.

For the type of transaction "Repurchase transactions" the Failed Rate Volume % is not consistent to the corresponding Aggregate Failed and Aggregate Total data.

Yes

Yes

Yes

Yes

50

ESMA REGULAR USE

3. 3. 5 For OthrTxs element

INS-033. 5

For the type of transaction "Other securities transactions" the Failed Rate Volume % is not consistent to the corresponding Aggregate Failed and Aggregate Total data.

Yes

3. 4

For each type of transaction, the Failed Rate Value % must be consistent to the corresponding Aggregate Failed and Aggregate Total data:

. . * 100 / . . = .

3. 4. 1 For SctiesBuyOrSell element

INS-034. 1

3. 4. 2 For CollMgmtOpr element

INS-034. 2

3. 4. 3 For SctiesLndgOrBrrwg element

INS-034. 3

3. 4. 4 For RpAgrmt element

INS-034. 4

3. 4. 5 For OthrTxs element

INS-034. 5

For the type of transaction "Purchase or sale of securities" the Failed Rate Value % is not consistent to the corresponding Aggregate Failed and Aggregate Total data.

For the type of transaction "Collateral management operations" the Failed Rate Value % is not consistent to the corresponding Aggregate Failed and Aggregate Total data.

For the type of transaction "Securities lending and securities borrowing" the Failed Rate Value % is not consistent to the corresponding Aggregate Failed and Aggregate Total data.

For the type of transaction "Repurchase transactions" the Failed Rate Value % is not consistent to the corresponding Aggregate Failed and Aggregate Total data.

For the type of transaction "Other securities transactions" the Failed Rate Value % is not consistent to the corresponding Aggregate Failed and Aggregate Total data.

Yes

Yes

Yes

Yes

Yes

4. Type of clients

51

ESMA REGULAR USE

4. 1

For each type of client, the sum of settled volume plus failed volume must be equal to the total volume:

. . + . . = . .

4. 1. 1 For Prfssnl element

INS-041. 1

4. 1. 2 For Rtl element

INS-041. 2

For the type of client "Professional clients as defined in point (10) of Article 4(1) of Directive 2014/65/EU" the sum of settled volume plus failed volume is not equal to the total volume.

For the type of client "Retail clients as defined in point (11) of Article 4(1) of Directive 2014/65/EU" the sum of settled volume plus failed volume is not equal to the total volume.

4. 2

For each type of client, the sum of settled value plus failed value must be equal to the total value:

. . + . . = . .

4. 2. 1 For Prfssnl element

INS-042. 1

4. 2. 2 For Rtl element

INS-042. 2

For the type of client "Professional clients as defined in point (10) of Article 4(1) of Directive 2014/65/EU" the sum of settled value and failed value is not equal to the total value.

For the type of client "Retail clients as defined in point (11) of Article 4(1) of Directive 2014/65/EU" the sum of settled value and failed value is not equal to the total value.

Yes

Yes

Yes

Yes

4. 3

For each type of client, the Failed Rate Volume % must be consistent to the corresponding Aggregate Failed and Aggregate Total data.

. . * 100 / . . = .

4. 3. 1 For Prfssnl element

INS-043. 1

For the type of client "Professional clients as defined in point (10) of Article 4(1) of Directive 2014/65/EU" the Failed Rate Volume %

Yes

52

4. 3. 2 For Rtl element

INS-043. 2

ESMA REGULAR USE

is not consistent to the corresponding Aggregate Failed and Aggregate Total data.

For the type of client "Retail clients as defined in point (11) of Article 4(1) of Directive 2014/65/EU" the Failed Rate Volume % is not consistent to the corresponding Aggregate Failed and Aggregate Total data.

Yes

4. 4

For each type of client, the Failed Rate Value % must be consistent to the corresponding Aggregate Failed and Aggregate Total data.

. . * 100 / . . = .

4. 4. 1 For Prfssnl element

INS-044. 1

4. 4. 2 For Rtl element

INS-044. 2

For the type of client "Professional clients as defined in point (10) of Article 4(1) of Directive 2014/65/EU" the Failed Rate Value % is not consistent to the corresponding Aggregate Failed and Aggregate Total data.

For the type of client "Retail clients as defined in point (11) of Article 4(1) of Directive 2014/65/EU" the Failed Rate Value % is not consistent to the corresponding Aggregate Failed and Aggregate Total data.

Yes

Yes

5. 1

The sum of settled volume plus failed volume of the cash transfers must be equal to the total volume.

. . + . . =

5. Cash transfers

INS-051

The sum of settled volume plus failed volume of the cash transfers is not equal to the total volume.

Yes

53

ESMA REGULAR USE

INS-052

The sum of settled value and failed value of the cash transfers is not equal to the total value.

Yes

INS-053

For cash transfers, the Failed Rate Volume % is not consistent to the corresponding Aggregate Failed and Aggregate Total data

Yes

INS-054

For cash transfers, the Failed Rate Value % is not consistent to the corresponding Aggregate Failed and Aggregate Total data

Yes

54

. .

5. 2

The sum of settled value and failed value of the cash transfers must be equal to the total value.

. . + . . =

. .

5. 3

For cash transfers, the Failed Rate Volume % must be consistent to the corresponding Aggregate Failed and Aggregate Total data.

. .

. . =

* 100

/

.

5. 4

For cash transfers, the Failed Rate Value % must be consistent to the corresponding Aggregate Failed and Aggregate Total data.

. .

. . =

* 100

/

.

ESMA REGULAR USE

6. 1 Obsolete

6. Issuer CSD information

6. 2

6. 3

6. 4

INS-062

The LEI [LEI value] is not valid. LEI in the FIRDS database.

Yes

INS-063

The ISIN code of the Issuer CSD is not valid.

Yes

In case of new ISINs, please make sure to inform ESMA before submitting them in the report.

If provided, the must be ISO 17442 valid.

The first two characters of the ISIN code of the financial instruments must be provided. The characters pairing must map to a valid ISO-3166-1 2- characters country code. This rule is not applied for character pairings that are explicitly set as exceptions by the ESMA IT Administrator.

identified

An Issuer CSD within the report is the uniquely combination of two characters ISIN of

and the LEI .

by first

the

the

Only one Issuer CSD block with this combination must exist in the report.

INS-064

If LEI is provided:

Yes

There are more than one Issuer CSDs with an ISIN Code starting with and LEI:

If LEI is not provided:

There are more than one Issuer CSDs with ISIN Code starting with:

6. 5

If provided, the must

INS-065

The LEI [LEI] is not a valid LEI.

Yes

• exist in the GLEIF database;

55

ESMA REGULAR USE





the validityEndDate of the respective FIRDS record is NULL; and "Issued", "Lapsed", “Merged”, “Pending transfer" or "Pending archival" as per latest record published by GLEIF for this LEI.

6. 6

If INS-065 has been successfully validated then: Validate that the country in Legal Address is the same as the field.

INS-066

The Issuer CSD country code [Ctry] is not consistent to the country of location in GLEIF.

Yes

7. Aggregation of volume and value

7. 1

For each type of financial instrument, the sum of total volumes reported for all Issuer CSDs must be equal to the overall total volume of this type of instrument:

. >. . . . = Sum of . . >. . . .

7. 1. 1 For Eqty element

INS-071. 1

For the financial instrument "Transferable securities referred to in point (a) of Article 4(1)(44) of Directive 2014/65/EU" the sum of total volumes reported for all Issuer CSDs is not equal to the overall total volume of this type of instrument, reported under the Settlement Internaliser block.

No

56

ESMA REGULAR USE

7. 1. 2 For SvrgnDebt element

INS-071. 2

For the financial instrument "Sovereign debt referred to in Article 4(1)(61) of Directive 2014/65/EU" the sum of total volumes reported for all Issuer CSDs is not equal to the overall total volume of this type of instrument, reported under the Settlement Internaliser block.

7. 1. 3 For Bd element

INS-071. 3

For the financial instrument " Transferable securities referred to in point (b) of Article 4(1)(44) other than sovereign debt of Article 4(1)(61) of Directive 2014/65/EU " the sum of total volumes reported for all Issuer CSDs is not equal to the overall total volume of type of the Settlement Internaliser block.

instrument, reported under

this

7. 1. 4 For OthrTrfblScties element

INS-071. 4

7. 1. 5 For XchgTradgFnds element

INS-071. 5

For the financial instrument "Transferable securities referred to in point (c) of Article 4(1)(44) of Directive 2014/65/EU" the sum of total volumes reported for all Issuer CSDs is not equal to the overall total volume of this type of instrument, reported under the Settlement Internaliser block.

For the financial instrument "Exchange-traded funds as defined in point (46) of Article 4(1) of Directive 2014/65/EU" the sum of total volumes reported for all Issuer CSDs is not equal to the overall total volume of this type of instrument, reported under the Settlement Internaliser block.

No

No

No

No

7. 1. 6 For CllctvInvstmtUdrtkgs element

INS-071. 6

For the financial instrument "Units in collective investment undertakings other than ETFs" the sum of total volumes reported for all Issuer CSDs is not equal to the overall total volume of this

No

57

7. 1. 7 For MnyMktInstrm element

INS-071. 7

7. 1. 8 For EmssnAllwnc element

INS-071. 8

7. 1. 9 For OthrFinInstrms element

INS-071. 9

ESMA REGULAR USE

type of instrument, reported under the Settlement Internaliser block.

For the financial instrument "Money market instruments other than sovereign debt referred in Article 4(1)(61) of Directive 2014/65/EU" the sum of total volumes reported for all Issuer CSDs is not equal to the overall total volume of this type of instrument, reported under the Settlement Internaliser block.

to

For the financial instrument "Emission allowances" the sum of total volumes reported for all Issuer CSDs is not equal to the overall total volume of this type of instrument, reported under the Settlement Internaliser block.

For the financial instrument "Other financial instruments" the sum of total volumes reported for all Issuer CSDs is not equal to the overall total volume of this type of instrument, reported under the Settlement Internaliser block.

No

No

No

7. 2

For each type of financial instrument, the sum of total values reported for all Issuer CSDs must be equal to the overall total value of this type of instrument.

. >. . . . = Sum of . . >. . . .

7. 2. 1 For Eqty element

INS-072. 1

For the financial instrument "Transferable securities referred to in point (a) of Article 4(1)(44) of Directive 2014/65/EU" the sum of the total values reported for all Issuer CSDs is not equal to the overall

No

58

7. 2. 2 For SvrgnDebt element

INS-072. 2

7. 2. 3 For Bd element

INS-072. 3

7. 2. 4 For OthrTrfblScties element

INS-072. 4

7. 2. 5 For XchgTradgFnds element

INS-072. 5

ESMA REGULAR USE

total value of this type of instrument, reported under the Settlement Internaliser block.

For the financial instrument "Sovereign debt referred to in Article 4(1)(61) of Directive 2014/65/EU" the sum of the total values reported for all Issuer CSDs is not equal to the overall total value of this type of instrument, reported under the Settlement Internaliser block.

For the financial instrument " Transferable securities referred to in point (b) of Article 4(1)(44) other than sovereign debt of Article 4(1)(61) of Directive 2014/65/EU" the sum of the total values reported for all Issuer CSDs is not equal to the overall total value of this type of instrument, reported under the Settlement Internaliser block.

For the financial instrument "Transferable securities referred to in point (c) of Article 4(1)(44) of Directive 2014/65/EU" the sum of the total values reported for all Issuer CSDs is not equal to the overall total value of this type of instrument, reported under the Settlement Internaliser block.

For the financial instrument "Exchange-traded funds as defined in point (46) of Article 4(1) of Directive 2014/65/EU" the sum of the total values reported for all Issuer CSDs is not equal to the overall total value of this type of instrument, reported under the Settlement Internaliser block.

No

No

No

No

59

ESMA REGULAR USE

7. 2. 6 For CllctvInvstmtUdrtkgs element

INS-072. 6

7. 2. 7 For MnyMktInstrm element

INS-072. 7

7. 2. 8 For EmssnAllwnc element

INS-072. 8

7. 2. 9 For OthrFinInstrms element

INS-072. 9

For the financial instrument "Units in collective investment undertakings other than ETFs" the sum of the total values reported for all Issuer CSDs is not equal to the overall total value of this type of instrument, reported under the Settlement Internaliser block.

For the financial instrument "Money market instruments other than sovereign debt referred in Article 4(1)(61) of Directive 2014/65/EU" the sum of the total values reported for all Issuer CSDs is not equal to the overall total value of this type of instrument, reported under the Settlement Internaliser block.

to

For the financial instrument "Emission allowances" the sum of the total values reported for all Issuer CSDs is not equal to the overall total value of this type of instrument, reported under the Settlement Internaliser block.

For the financial instrument "Other financial instruments" the sum of the total values reported for all Issuer CSDs is not equal to the overall total value of this type of instrument, reported under the Settlement Internaliser block.

No

No

No

No

7. 3

For each type of transaction, the sum of total volumes reported for all Issuer CSDs must be equal to the overall total volume of this type of transaction.

. >. . . .

Transaction>. . .

=

Sum

of

. . >.

of

7. 3. 1 For SctiesBuyOrSell element

INS-073. 1

For the type of transaction "Purchase or sale of securities" the sum of total volumes reported for all Issuer CSDs is not equal to the

No

60

ESMA REGULAR USE

7. 3. 2 For CollMgmtOpr element

INS-073. 2

7. 3. 3 For SctiesLndgOrBrrwg element

INS-073. 3

7. 3. 4 For RpAgrmt element

INS-073. 4

7. 3. 5 For OthrTxs element

INS-073. 5

overall total volume of this type of transaction, reported under the Settlement Internaliser block.

For the type of transaction "Collateral management operations" the sum of total volumes reported for all Issuer CSDs is not equal to the overall total volume of this type of transaction, reported under the Settlement Internaliser block.

For the type of transaction "Securities lending and securities borrowing" the sum of total volumes reported for all Issuer CSDs is not equal to the overall total volume of this type of transaction, reported under the Settlement Internaliser block.

For the type of transaction "Repurchase transactions" the sum of total volumes reported for all Issuer CSDs is not equal to the overall total volume of this type of transaction, reported under the Settlement Internaliser block.

For the type of transaction "Other securities transactions" the sum of total volumes reported for all Issuer CSDs is not equal to the overall total volume of this type of transaction, reported under the Settlement Internaliser block.

No

No

No

No

7. 4

For each type of transaction, the sum of total values reported for all Issuer CSDs must be equal to the overall total value of this type of transaction.

. >. . . .

Transaction>. . .

=

Sum

of

. . >.

of

61

ESMA REGULAR USE

7. 4. 1 For SctiesBuyOrSell element

INS-074. 1

7. 4. 2 For CollMgmtOpr element

INS-074. 2

7. 4. 3 For SctiesLndgOrBrrwg element

INS-074. 3

7. 4. 4 For RpAgrmt element

INS-074. 4

7. 4. 5 For OthrTxs element

INS-074. 5

For the type of transaction "Purchase or sale of securities" the sum of total values reported for all Issuer CSDs is not equal to the overall total value of this type of transaction, reported under the Settlement Internaliser block.

For the type of transaction "Collateral management operations" the sum of total values reported for all Issuer CSDs is not equal to the overall total value of this type of transaction, reported under the Settlement Internaliser block.

For the type of transaction "Securities lending and securities borrowing" the sum of total values reported for all Issuer CSDs is not equal to the overall total value of this type of transaction, reported under the Settlement Internaliser block.

For the type of transaction "Repurchase transactions" the sum of total values reported for all Issuer CSDs is not equal to the overall total value of this type of transaction, reported under the Settlement Internaliser block.

For the type of transaction "Other securities transactions" the sum of total values reported for all Issuer CSDs is not equal to the overall total value of this type of transaction, reported under the Settlement Internaliser block.

No

No

No

No

No

7. 5

For each type of client, the sum of total volumes reported for all Issuer CSDs must be equal to the overall total volume of this type of client.

. >. . . . = Sum of . . >. . . .

62

ESMA REGULAR USE

7. 5. 1 For Prfssnl element

INS-075. 1

7. 5. 2 For Rtl element

INS-075. 2

For the type of client "Professional clients as defined in point (10) of Article 4(1) of Directive 2014/65/EU" the sum of total volumes reported for all Issuer CSDs is not equal to the overall total volume of this type of client, reported under the Settlement Internaliser block.

No

For the type of client "Retail clients as defined in point (11) of Article 4(1) of Directive 2014/65/EU" the sum of total volumes reported for all Issuer CSDs is not equal to the overall total volume of this type of client, reported under the Settlement Internaliser block.

No

7. 6

For each type of client, the sum of total values reported for all Issuer CSDs must be equal to the overall total value of this type of client.

. < ClntTp >. . . . = Sum of . . >. . . .

7. 6. 1 For Prfssnl element

INS-076. 1

7. 6. 2 For Rtl element

INS-076. 2

For the type of client "Professional clients as defined in point (10) of Article 4(1) of Directive 2014/65/EU" the sum of total values reported for all Issuer CSDs is not equal to the overall total value of this type of client, reported under the Settlement Internaliser block.

For the type of client "Retail clients as defined in point (11) of Article 4(1) of Directive 2014/65/EU" the sum of total values reported for all Issuer CSDs is not equal to the overall total value of this type of client, reported under the Settlement Internaliser block.

No

No

7. 7

The sum of total volumes reported for all Issuer CSD blocks for cash transfers must be equal to the total volume of cash overall

INS-077

The sum of total volumes reported for all Issuer CSDs for cash transfers is not equal to the overall total.

No

63

ESMA REGULAR USE

under transfers Settlement Internaliser block

reported

the

. >. . .

of . >. . .

Sum

=

7. 8

The sum of total value reported for all Issuer CSD blocks for cash transfers must be equal to the overall total value of cash transfers reported under the Settlement Internaliser block.

INS-078

The sum of total value reported for all Issuer CSDs for cash transfers is not equal to the overall total.

No

. >. . tl>.

of . >. . .

Sum

=

7. 9

The sum of total values reported for all types of financial instruments, all types of transactions, and all types of clients must be equal to the overall total value.

. . . =

Sum of (>. . . . ) for all Types of FinInstrm =

Sum of (>. . . . ) for all Types of Transactions =

Sum of < ClntTp>. . . . ) for all Types of Clients

64

ESMA REGULAR USE

7. 9. 1 For SttlmIntlr element

INS-079. 1

7. 9. 2 For IssrCSD element

INS-079. 2

The sum of total values for all types of financial instruments, all types of transactions, and all types of clients is not equal to the overall total value within the Settlement Internaliser block.

The sum of total values for all types of financial instruments, all types of transactions, and all types of clients is not equal to the overall total value within the Issuer CSD block.

Yes

Yes

7. 10 The sum of total volumes reported for all types of financial instruments, all types of transactions, and all types of clients must be equal

to the overall total volume.

. . . =

Sum of (>. . . . ) for all Types of FinInstrm =

Sum of (>. . . . ) for all Types of Transactions =

Sum of < ClntTp>. . . . ) for all Types of Clients

7. 10. 1 For SttlmIntlr element

INS-0710. 1

7. 10. 2 For IssrCSD element

INS-0710. 2

The sum of total volumes for all types of financial instruments, all types of transactions, and all types of clients s not equal to the overall total volumes within the Settlement Internaliser block.

The sum of total volumes for all types of financial instruments, all types of transactions, and all types of clients is not equal to the overall total volumes within the Issuer CSD block.

Yes

Yes

7. 11 The Failed Rate Volume % for the overall total must be consistent to the corresponding Aggregate Failed and Aggregate Total data:

. . * 100 / . . = .

65

ESMA REGULAR USE

7. 11. 1 For SttlmIntlr element

INS-0711. 1

7. 11. 2 For IssrCSD element

INS-0711. 2

The Failed Rate Volume % for the Overall total is not consistent to the corresponding Aggregate Failed and Aggregate Total data within the Settlement Internaliser block.

The Failed Rate Volume % for the Overall total is not consistent to the corresponding Aggregate Failed and Aggregate Total data within the Issuer CSD block.

Yes

Yes

7. 12 The Failed Rate Value % for the overall total must be consistent to the corresponding Aggregate Failed and Aggregate Total data:

. . * 100 / . . = .

7. 12. 1 For SttlmIntlr element

INS-712. 1

7. 12. 2 For IssrCSD element

INS-712. 2

The Failed Rate Value % for the Overall total is not consistent to the corresponding Aggregate Failed and Aggregate Total data within the Settlement Internaliser block.

The Failed Rate Value % for the Overall total is not consistent to the corresponding Aggregate Failed and Aggregate Total data within the Issuer CSD block.

Yes

Yes

8. Consistency validation

8. 1

The filename of a newly received file must either relate to a new

INS-081

If + combination does not exist in DB and Version !=1:

No

combination with (i. e. version) set to “0001”, or submitted

combination with

(i. e. version) set to the

previously

a

It is the first time that the System receives an Internalised Settlement report for the given CA, Country, LEI and Quarter/Year and therefore its version should be set to 0001.

66

ESMA REGULAR USE

previous Version increased by 1 (see paragraph 25).

If + combination exists in DB, and Version number (Key2) is less than {PreviousVersion+1}:

Version [Key2] of the Internalised Settlement report has already been submitted in the past to the System. A new version may be submitted.

If + combination exists in DB, and Version number (Key2) is greater than {PreviousVersion+1}:

Version [Key2] of the Internalised Settlement report is higher than the expected version; its previous version received by the System was {PreviousVersion}.

8. 2

A report with RptSts=NEWT must submit an IS entry that does not exist in the CSDR database.

A report with RptSts=AMND must refer to a valid IS entry in the CSDR database.

A report with RptSts=CANC must refer to a valid IS entry in the CSDR database.

INS-082

If RptSts=NEWT:

No

The submitted Internalised Settlement of CA [CA] with LEI [LEI], Country code of operation [BrnchId] and Reporting period [Quarter]/[Year] already exists in the System as a valid record.

If RptSts=AMND:

No Internalised Settlement report of CA [CA] with LEI [LEI], Country code of operation [BrnchId] and Reporting period [Quarter]/[Year] to be updated exists in the System as a valid record.

67

ESMA REGULAR USE

If RptSts=CANC:

No Internalised Settlement of CA [CA] with LEI [LEI], Country code of operation [BrnchId] and Reporting period [Quarter]/[Year] to be cancelled exists in the System as a valid record.

8. 3

8. 4

8. 5

To accept an SetIn report by a CA, the CA contact details of the Legal, Business, and IT liaison must be populated

To accept an SetIn report by a CA, the reporting period cannot be a future reporting period

INS-083

System cannot accept an Internalised Settlement report unless the CA Legal, Business and IT Representative details are fully populated. Please populate through the respective ESMA Extranet CSDR page.

No

INS-084

System cannot accept an Internalised Settlement report for a future reporting period.

No

To accept a SetIn report by a CA, the reporting period cannot be before July 2019

INS-085

System cannot accept an Internalised Settlement report for a reporting period before July 2019, which forms the first reporting period.

No

68

ESMA REGULAR USE

6. 3 Annex III: Email message templates

60. The email sent to the CAs to remind them the deadline for submitting an Internalised Settlement Report has passed without ESMA receiving valid information from the CA will follow the template below:

To

CC

Subject

Body

None

ESMA Register CSDRS9: Overdue submission for quarter /

Internalised Settlement Report

Your country has not submitted Internalised Settlement Reports for / by their due date of .

Please submit your report the soonest possible. Alternatively, if you have no report to .

inform ESMA by sending an email

to submit, please

If you require technical assistance for submitting your report(s), please contact ESMA at .

Parameters

= email addresses of CA Contact details, as per relevant Use case

= the quarter of the just expired reporting period

= the year of the just expired reporting period

= the country code that has not submitted a report

= the deadline (as per the Assumption section of the relevant Use Case)

= the email of ESMA team monitoring submissions (defined in a system parameter file)

69

ESMA REGULAR USE

61. The email sent to the CAs to remind them the deadline for submitting an Internalised

Settlement Report is approaching will follow the template below:

To

CC

Subject

Body

None

ESMA Register CSDRS9: Deadline for Internalised Settlement Report submission for / is approaching

The deadline / is on .

for submitting

Internalised Settlement Reports

for

If you require technical assistance for submitting your report(s), please contact ESMA at .

Parameters

= email addresses of CA Contact details, as per relevant Use Case

= the quarter of the just expired reporting period

= the year of the just expired reporting period

= the deadline (as per the Assumption section of the relevant Use Case)

= the email of ESMA team monitoring submissions (defined in a system parameter file)

62. The email sent to the CAs to remind them the deadline for submitting a Potential Risks Report has passed without ESMA receiving information from the CA will follow the template below:

To

CC

Subject

None

ESMA Register CSDRS9: Overdue Potential Risks Report submission for quarter /

70

ESMA REGULAR USE

Body

Your country has not submitted a Potential Risks Report for / by its due date of .

Please submit your report the soonest possible.

If you require technical assistance for submitting your report, please contact ESMA at .

Parameters

= email addresses of CA Contact details, as per relevant Use Case

= the quarter of the just expired reporting period

= the year of the just expired reporting period

= the country code that has not submitted a report

= the deadline (as per the Assumption section of the relevant Use Case)

= the email of ESMA team monitoring submissions (defined in a system parameter file)

63. The email sent to the CAs to remind them the deadline for submitting a Potential Risks

Report is approaching will follow the template below:

To

CC

Subject

Body

None

ESMA Register CSDRS9: Deadline for Potential Risks Report submission for / is approaching

The deadline / is on .

for submitting

the Potential Risks Reports

for

If you require technical assistance for submitting your report(s), please contact ESMA at .

71

ESMA REGULAR USE

Parameters

= email address of CA Contact details, as per relevant Use Case

= the quarter of the just expired reporting period

= the year of the just expired reporting period

= the deadline (as per the Assumption section of the relevant Use Case)

= the email of ESMA team monitoring submissions (defined in a system parameter file)

64. The email sent to the CAs to confirm that a Potential Risks Report is received by ESMA

will follow the template below:

To

CC

Subject

Body

None

ESMA Register CSDRS9: Potential Risks receipt confirmation /

for

The current email forms confirmation of receipt of the Potential Risks report of for /

Parameters

= email addresses of CA Contact details, as per relevant Use Case

= the quarter of the just expired reporting period

= the year of the just expired reporting period

= the country code that has not submitted a report

= the email of ESMA team monitoring submissions (defined in a system parameter file)

65. The email sent to the CAs to notify them that a feedback file for an Internalised Settlement report is available on the HUB or through the ESMA Secured Web Interface will follow the template below:

72

ESMA REGULAR USE

To

for submissions through Extranet

for submissions through HUBEX

CC

None

Subject

Body

ESMA Register CSDRS9: Feedback file for a Internalised Settlement report submission for /

Your file has been processed and has been . Please download the feedback file for more details.

If you require technical assistance for submitting your report(s), please contact ESMA at .

Parameters

= email addresses of CA Contact details, as per relevant Use Case

= the email address fetched from LDAP

= the quarter of the just expired reporting period

= the year of the just expired reporting period

= The filename of the submitted file

= “accepted” if feedback file status is ACPT; “rejected” if feedback file status is CRPT or RJCT.

= the email of ESMA team monitoring submissions (defined in a system parameter file)

6. 4 Annex IV: File naming examples

66. Example 1:

• Reporting entity (CA): DE

73

ESMA REGULAR USE

• Settlement Internaliser place of establishment: DE

• Settlement internaliser country of operation: DE

• XML

filename:

“NCADE_DATISR_CSDR9_DE-3157006IAVSO21FPLG03-2019-

Q1_0001. xml”

• Zip

filename

(suffixed with

timestamp):

“NCADE_DATISR_CSDR9_DE-

3157006IAVSO21FPLG03-2019-Q1_0001_20190403151312. zip”

67. Example 2:

• Reporting entity (CA): GR

• Settlement Internaliser place of establishment: GR

• Settlement internaliser country of operation: IT

• XML

filename:

“NCAGR_DATISR_CSDR9_IT-3157886IAVSO21FPLG03-2019-

Q1_0001. xml”

• Zip

filename

(suffixed with

timestamp):

“NCAGR_DATISR_CSDR9_IT-

3157886IAVSO21FPLG03-2019-Q1_0001_20190403151312. zip”

68. Example 3:

• Reporting entity (CA): GR

• Settlement Internaliser place of establishment: GR

• Settlement internaliser country of operation: Third country State

• XML

filename:

“NCAGR_DATISR_CSDR9_TS-3153306IAVSO21FPLG03-2019-

Q1_0001. xml”

• Zip

filename

(suffixed with

timestamp):

“NCAGR_DATISR_CSDR9_TS-

3153306IAVSO21FPLG03-2019-Q1_0001_20190403151312. zip”

69. Example 4 (applicable for example of paragraph 72):

• Reporting entity (CA): DE

• Settlement Internaliser place of establishment (non-EU based head office): ZW

• Settlement internaliser country of operation (branch operating within the EU): DE

74

ESMA REGULAR USE

• XML

filename:

“NCADE_DATISR_CSDR9_DE-3912003WX2IHW9BSEP43-2019-

Q1_0001. xml”

• Zip

filename

(suffixed with

timestamp):

“NCADE_DATISR_CSDR9_DE-

3912003WX2IHW9BSEP43-2019-Q1_0001_20190403151312. zip”

6. 5 Annex V: Internalised Settlement reports - Examples for SetIn

identification

70. Example 1: Submission of Internalised Settlement reports by EU-established Settlement

Internalisers (Germany and Italy)

SI Identification

XML

DE CA - reporting

IT CA - reporting

element

values

values

LEI Identifier4

LEI

3912003WX2IHW9B SEP43

213800E5JT257M7 W5O29

4 The LEI identification is used to uniquely identify the Settlement Internalisers that submit reports. For head-offices and branches of Settlement Internalisers established within the EU, Settlement Internalisers must submit reports providing the LEI of the head- office (EU). For branches operating in the EU of Settlement Internalisers established outside the EU, branches must submit their reports providing the LEI of the head-office (non-EU).

75

ESMA REGULAR USE

Country Code establishment)5

(country of

Ctry

DE

IT

Branch (Country of operation)6

Country

Code

BrnchId

71. Example 2: Submission of Internalised Settlement reports by EU-established Settlement

Internalisers (France), having branches operating within the EU (Germany and Italy)

SI Identification

FR CA - reporting values

5 The country code is used to identify the country of the place of establishment of the Settlement Internaliser (head-office) when the Settlement Internaliser is established within the EU, or the place of operation (branch) when the Settlement Internaliser is established outside the EU.

6 The branch country code (ISO 3166) is used to identify the country of the branch of a Settlement Internaliser established within the EU when the report concerns data relating to a branch(es) operating in a different jurisdiction than the place of establishment of the Settlement Internaliser (head-office). For branches operating within the EU, the country code (ISO 3166) of the place where the branch operates must be provided. If the report concerns data relating to branches of EU Settlement Internalisers operating outside the EU, the code ‘TS’ must be used. If the report concerns data relating to branches of non-EU established Settlement Internalisers operating within the EU, the branch country code should not be provided. A valid ISO 3166 2-character code should be used, apart from the case where the 2-characters 'TS' code is used.

76

ESMA REGULAR USE

XML

element

Report (2)

Report (3)

Report (4)

LEI Identifier

LEI

969500BQRMP Z4F9HTD84

969500BQRMP Z4F9HTD84

969500BQRMP Z4F9HTD84

Country (country establishment)

Code of

Country Branch Code (Country of operation)

Ctry

FR

FR

FR

BrnchId

DE

IT

72. Example 3: Submission of Internalised Settlement reports by non-EU-established

Settlement Internalisers, having branches operating within the EU (Germany and Italy)

SI Identification

XML

DE CA - reporting

IT CA - reporting

element

values

values

77

ESMA REGULAR USE

LEI Identifier

LEI

3912003WX2IHW9B SEP43

213800E5JT257M7 W5O29

Country Code establishment)7

(country of

Ctry

DE

IT

Branch Country Code (Country of operation)

BrnchId

73. Example 4: Submission of Internalised Settlement reports by EU-established Settlement Internaliser (Germany), having branches operating outside the EU (Zimbabwe and Djibouti)

SI Identification

DE CA - reporting values

7In the case of non-EU established SetIn having branches operating within the EU, the EU based branch(es) are responsible to submit data to the respective CA of the country where they are operate. Hence, the reports submitted by this/these branch(es) should report the country code of their place of operation within the Country Code of establishment element. The country code of the operation of the branch (i. e. , DE, IT) is reported within the ‘Country Code of establishment’ element, since it is the branch that is responsible to submit the report to the CA and not the non-EU head office.

78 ESMA REGULAR USE XML element Report (2) Report (3) LEI Identifier LEI 3912003WX2IHW9 BSEP43 3912003WX2IHW9 BSEP43 Country Code establishment) (country of Ctry DE Branch Country Code (Country of Operation) BrnchId DE TS 79

Disclaimer: RegRadar is not endorsed nor affiliated with the source authority. This material does not constitute any advice. This material is machine translated and does not constitute an official translation by the source authority. Please note that the information can be obtained free of charge through the source website.