Transaction Reporting Service: EMIR - borsaitaliana.it · Appendix 2 – UTI for ETD IDEM 2624...

Transaction Reporting Service: EMIR

Service Manual

DecemberSeptember 20167

Version 1.67

Contents

1.0 Revision History 4

2.0 Introduction 6

2.1 Scope 7 2.2 References 8

3.0 Trade Reporting in EMIR directive and European legislation 9

4.0 Service Description 10

4.1 Functional specifications 14 4.1.1 Reporting Procedure 16 4.1.2 Fields format 18 4.1.3 Directory structure of sFTP account 19 4.2 Validation data process 19 4.3 UnaVista matching process 22 4.4 Appendix 1 – Client reference data 2524 4.5 Appendix 2 – UTI for ETD IDEM 2624

Index

TRS Service Manual 16th December 2016

4

1.0 Revision History

Date Version Description Author

8 Jan 2014 1.0 Transaction Reporting Service to EMIR, English Version first draft

Borsa Italiana

21 Jan 2014 1.1 Changes to the first version:

Error codes of the TRS EMIR

Service added

Directory structure of sFTP

account added

Clarification on UTI for ETD IDEM

reporting

Clarification on automatically

generated reports for ETD IDEM

Borsa Italiana

4 Feb 2014 1.2 Changes to the version 1.1:

ETD IDEM automatic generation

not applied for positions

PUTI specifications removed from

Appendix 2

UnaVista field list reference file

updated

Error codes table modified (new

fields and values)

Borsa Italiana

11 Jul 2014 1.3 Updates for EMIR phase 2 (reporting obligations for collateral and mark to

market)

Borsa Italiana

17 Nov 2014 1.4 New/amendment to error codes due to ESMA/UnaVista validation changes

Borsa Italiana

10 Jun 2015 1.5 - UnaVista EMIR Reporting Field

Specification update to 1.9

- Common Data delegation mechanism no

longer supported

Borsa Italiana


5

- Description of error code 1203 amended

accordingly

16 Dec 2016 1.6 - Updates for Matching Response Files

- Updates to Appendix 3

Borsa Italiana

04 Sep 2017 1.7 - Updates for EMIR Revised RTS

(Regulatory Technical Standards)

- Appendix 3 moved to Technical

Specifications

Borsa Italiana


6

2.0 Introduction

Following the introduction of a new regulation, EMIR1 which will enter into force on 12th February

2014 (UE No 648/2012 of the European Parliament and of the Council of 4 July 2012 on OTC

derivatives, central counterparties and trade repositories) all financial transactions executed on OTC

and ETD (Exchange Trade Derivatives) contracts must be reported to ESMA2 certified Trade

Repositories.

The Regulation introduces provisions to improve transparency and reduce the risk on the derivatives

markets.

The service described in this document is offered by Borsa Italiana to its clients in order to facilitate

mandatory transactions and reporting duties, introduced by the EMIR regulation.

Information contained in the present document might be changed according to competent authorities

final approvals.

The current document version has been updated to reflect changes introduced by the Revised RTS

Reporting version of EMIR that will come into force on November 1st 2017.

Headline changes are the following:

- More fields: increases from current 85 to 129 (35 ‘Counterparty’ and 94 ‘Common Data’ fields);

- Important changes to product identifiers and product classification;

- More details on the methodology to populate ‘Notional’;

1 European Market Infrastructures Regulation – Regulation (EU) 648/2012 of the European Parliament and Council on OTC derivatives,

central counterparties and trade repositories – also referred to as “the Regulation” 2 ESMA is a European Union independent financial regulatory institution, that works in the field of securities legislation and regulation

to improve the functioning of financial markets in Europe, strengthening investor protection and cooperation between national competent authorities

Formatted: English (U.S.)


7

- Significant changes to the reporting of collateral & valuation;

- New asset class specific fields for CDS;

- Increase in number of interest rate fields;

- Changes to Action Types: position reporting made easier;

- Improvements to the commodities specific fields;

- Changes/clarifications to the reporting of complex derivatives and cleared trades.

2.1 Scope

This document describes the functional and technical features of the service.


8

2.2 References

- Questions and Answers - Implementation of the Regulation (EU) No 648/2012 on OTC derivatives,

central counterparties and trade repositories (EMIR) – ESMA document

- UnaVista EMIR Reporting Field Specification v2.3.0.4.xlsx – UnaVista document

- Transaction Reporting Service_ EMIR - tTechnical sSpecifications – Borsa Italiana document


9

3.0 Trade Reporting in EMIR directive and European legislation

EMIR European Union regulation completes the already in force MIFID directive, which specifies new

obligations for ETD and OTC derivatives.

EMIR rules outline regulatory framework for derivatives ETD and OTC contracts addressed to all

involved stakeholders, central counterparties, financial counterparties and clearing members.

Furthermore, EMIR establishes Trade Repositories, a system designated to collect and store all

derivatives ETD and OTC contracts life cycle data.

Borsa Italiana service will use UnaVista EMIR Trade Repository to collect, validate and reconcile all the

operations regarding ETD and OTC on all the asset classes.

Borsa Italiana TRS EMIR service allows to send ETD and OTC transactions to the trade repository,

errors management, thanks to automatically syntactic checks, and the dispatch of the data compliant

with legislation to UnaVista.


10

4.0 Service Description

The TRS EMIR service is placed between client and Trade Repository and according to ESMA

definitions it will be acting as a Third Party. The client maintains data ownership and reporting

responsibility.

Transaction reporting must take place via file upload, this file must use one of the formats listed below

and the layout defined by UnaVista described in “UnaVista EMIR Reporting Field Specification

v23.0.4.xlsx” contained in the package available at

http://www2.londonstockexchangegroup.com/unavista-emir-documentation-pack.

The service will allow clients to perform the following actions:

- Manual transaction entry via GUI

- Bulk Transactions upload from file via GUI

- Exceptions management and upload of corrected transactions

- File upload via SFTP

- Consultation of transaction reports for 5 days after submission

- Consultation of Matching Response Files via SFTP

- Historical data consultation

- Data export on .csv file

Supported formats are:

- csv

- ascii

- xml

The transaction must be sent by the end of the next trading day following the trade (that is by T+1

23:59:59)


11

Trades reporting syntactic validity is checked before being transmitted to UnaVista central Trade

Repository.

UnaVista will then validate and perform a reconciliation process by T+2. For each phase, Trade

Repository will send response files to TRS EMIR.

These files will be available to clients for consultation, error management and reporting. (see 4.2)

Clients are also required to report the lifecycle records until the expiration of the financial instruments

or until the position is closed.

TRS EMIR also offers a data enrichment service, starting from the reference data provided by the user

during the service subscription (described in Appendix 1).

In addition, for ETD derivatives contracts on instruments cleared by CCG, the data will be used by

Transaction Reporting to retrieve from the Borsa Italiana database all the information regarding

contracts lifecycle stages in order to fill out the files correctly to be sent to UnaVista hence reducing

the manual data entry needed by clients.

All validations, exception management and reporting resubmission will be managed by Transaction

Reporting.

For ETD transactions cleared by CC&G, automatic generation will be configurable, clients will be able

to specify if they want to use this service or if they prefer to personally send ETD transactions on

CC&G guaranteed markets.

Regardless of this choice, transactions sent by clients, once syntactic checks are passed, will be sent to

UnaVista Trade Repository in any case.

In the following diagram, based on ESMA guidelines, pag. 59123 of “Questions and Answers -

Implementation of the Regulation (EU) No 648/2012 on OTC derivatives, central counterparties and

trade repositories (EMIR)” document issued on 3 April 2017, automatically generated transactions for

ETD cleared by CCG (in case the Client opt for this configuration) are depicted:


12

In case the Client of the TRS EMIR Service is a General Clearing Member and the transaction has been

executed by one of its Non Clearing Members (Investment firm), reports “1” and “4” will be

automatically generated and the Client of the Service is stated as the reporting counterparty. It will also

be possible to configure the Service in order to limit the automatic generation to report “1” only (GCM vs

CCP) in case the General Clearing Member opts for this choice when subscribing to the Service.

If the Client of the Service is a direct member of CCG and is itself the investment firm of this transaction,

the schematic above is simplified and report “1” only is generated.

In case the Client of the Service is a Non Clearing Member who acts as the Investment Firm of this

transaction, report “3” will be automatically generated.


13

The automatic generation of reports will be applicable for both trades, and positions (as ofsince 12th of

August 2014 when reporting obligations for collateral and mark to market come came into force) and

lifecycles.

For those customers who have opted for automatic generation of transactions, the following procedures

will be applied by the TRS EMIR service:

- two different types of Positions records (both identified with Message Type – CD60 = “P”) will be

sent to UnaVista: “aggregated” Positions and “per instrument” Positions;

- aggregated Positions represent the overall Position per each portfolio managed by the CCP and

contain the collateral value posted by the GCM/ICM to the CCP. According to CCP guidelines, the

positions are grouped by account following the account structure under EMIR:

o House Account;

o Main Omnibus Client Account;

o Additional Omnibus Account (AOA);

o Individual Segregated Account (ISA);

- per instrument Positions where the mark to market calculated by the CCP is populated at financial

instrument level but the collateral value is left to zero (because GCMs/ICMs do not post collateral

on an instrument basis).

The PUTI (Position UTITrade ID, UnaVista ESMA field CD128A2.12) will be populated with the portfolio

ID (generated by the CCP) for aggregated Positions and with the CCG Position code (see Appendix 2)

for per instrument Positions.

Regarding OTC and ETD derivatives contracts which are not cleared by CC&G, reporting enrichment

concerns only static reference data provided by client when the contract is concluded (see form in

Appendix 1).

Further to new guidance provided by the UnaVista Trade Repository, it is worth noting that UTI

validation rules have changed. Initially, when the EMIR reporting obligations came into force in February

Field Code Changed


14

2014, UnaVista validated uniqueness of the UTI in combination with the Reporting Counterparty LEI

and the Other Counterparty ID. This catered for situations where one counterparty was passed the

same UTI for two different trades by two different counterparties. Given the low likelihood of this

happening, and the complications that arose from this approach, UnaVista was to follow suit with the

majority of other TRs and enforce UTI uniqueness at the Reporting Counterparty level. This removes

any confusion over what happened when the Other Counterparty ID was updated on an existing trade,

as well as the implications of updating a dummy UTI and Other Counterparty ID on the same report.

This change impacts any user who previously reported multiple trades with the same UTI, e.g. a

clearing member reporting against the CCP and against their client. Those users need to create and

agree additional UTIs for one or both of these trades to ensure uniqueness of the UTI, in line with the

EMIR standards and in line with other TRs.

4.1 Functional specifications

Borsa Italiana Transaction Reporting receives trades executed by members who have subscribed to the

service, trades sent both individually and automatically are aggregated and consistency and

completeness checks are performed before dispatching the files to UnaVista.

All the operations reported during the whole trading day are accepted by the service and will be

checked as described in 4.2, stored in the Database and then sent to UnaVista.

All transactions accepted by TRS EMIR are sent UnaVista real time for any member.

In the event of a file failing the checks, errors are notified to the clients with the wrong record sent

through the agreed procedure (file, error message on the GUI , etc).

One or more files will be sent to UnaVista via sFTP for each members, the results will be managed by

the service and notified to the connected TRS EMIR clients or to the interconnected active channels.

As described in the legislation, contracts, and positions and lifecycle must be reported by the end of

the next working day after the contract day, that is by 23:59:59 (T+1). See fig.1.

Nevertheless, Transaction Reporting EMIR service will accept contract reporting for any day (T+n).


15

Fig. 1 – Information transmission schedule

T Trade Date T+1 T+2 T3

Rep

ort

dis

pat

chin

g d

ead

line

Qu

alit

y ch

ecks

on

th

e in

form

atio

ns

sen

t to

Au

tho

riti

es a

nd

rec

on

cilia

tio

n

by

Un

aVis

ta.

Res

ult

s se

nt

to c

lien

ts

Ava

ilab

ility

of

all R

epo

rtin

gs

for

Day

T

Ava

ilab

ility

of

Rep

ort

ings

co

nsu

ltat

ion

fo

r d

ay T

(h

isto

ric)

Rep

ort

dis

pat

chin

g to

TR

S

No

tifi

cati

on

res

ult


16

4.1.1 Reporting Procedure

Each user can insert their own reports during the trading day in one of the following ways:

GUI, accessible via web server or via local client. Loading a file or manually inserting in a

dedicated window

File upload via sFTP

Loading via GUI

a. Single contract manual upload. Some fields in the input window will be filled with the reference

data provided (see Appendix 1).

b. File upload. Each file can contain transactions from different days.

Transaction reported both manually and via file upload, will be real time displayed on the client

transaction window.


17

SFTP file upload

Each trading day TRS EMIR service will be able to manage multiple files submission.

File name must contain the company ID called LEI (Legal Entity Identifier), file upload date and a

progressive identification number

<ReportingFirm>_<ReportingDate>_<Prog>.<Ext>

<ReportingFirm>: reporting firm LEI code

<ReportingDate>: file submission date. Date must be in YYYYMMDD format

<Prog>: 3 digits progressive id starting from 001. Files whose id is less than or equal to the

last received file will be ignored.

Secure file transfer is available 24 hours 7 days a week.

Reports sent Monday to Friday will be managed and sent to UnaVista real time, whilst ones sent

Saturday and Sunday will be accepted and dispatched to UnaVista the next Monday.

Clients will be requested to login with UserId and password provided during service subscription or via

SSH using RSA public key exchange

All uploaded files will be shown real time in client “Files” window and identified as “FileSFTP” under the

“Source” column.


18

4.1.2 Fields format

This section describes the file format requested by UnaVista.

A complete list of Fields format is available at the following link:

http://www2.londonstockexchangegroup.com/unavista-emir-documentation-pack (file “UnaVista EMIR

Reporting Field Specification v23.0.4.xlsx”)

Character

File must contain only 8-bit ASCII (ISO 8859-1) characters.

Alphanumeric field

Alphanumeric fields marked as ‘Alpha’ can contain only alphanumerical characters

Numerical data

Numerical data are indicated as ‘Decimal’. Field length also includes decimal digits. For example, length

30 (25,5) is 25 integer and 5 decimals. Delimiter is full stop (.).

Date and Time

All the data inserted in the file must have YYYYMMDD format.

Time will have HH:MM:SS (24-hour-clock) format and time zone UTC.

Files must have an header with the field name as specified by UnaVista:

http://www2.londonstockexchangegroup.com/unavista-emir-documentation-pack (file “UnaVista EMIR

Reporting Field Specification v23.0.4.xlsx”)

Please note that a sample file is available on the Borsa Italiana website.

http://www2.londonstockexchangegroup.com/unavista-emir-documentation-pack

http://www2.londonstockexchangegroup.com/unavista-emir-documentation-pack


19

4.1.3 Directory structure of sFTP account

The sFTP account of each Client is organized with the following directories under the home dir:

- Incoming (directory where the TRS EMIR service saves the response and matching response files and a copy of the automatically generated files for ETD IDEM)

- Outgoing (directory where the Client application uploads the transaction files)

From the file transfer protocol standpoint, the Client application will execute a sFTP put into the

Outgoing directory whenever it needs to send its own transaction files to the TRS EMIR Service, whilst

the Client application will perform a sFTP get from the Incoming directory to download the response

files provided by the service following the different validation data processes described in the next

paragraph.

4.2 Validation data process

This chapter describes how the validation process works, from Transaction Reporting EMIR service pre

acceptance ( fields format and length, headers etc) to the validation and reconciliation by UnaVista.

Checks performed by Transaction Reporting service are:

1. Instrument identification code check. Users can specify both the ISIN and the native market

alphanumerical symbol. If this field is left empty or invalid data has been submitted, the

system will display an error message and the report will be not dispatched to UnaVista

2. Syntactic and file length check as established by UnaVista.

Following response .txt files will be returned to user containing reports outcomes:


20

Initial validation file, will contain possible format inconsistency, fields correctness and file

format. This check is performed real time by Transaction Reporting EMIR service before files

are sent to UnaVista EMIR TR and will be identified by suffix TRSRes:

Ex: <original file name>_TRSRes.txt

Reponse file from UnaVista EMIR TR File further to delivery and first check. This file will be

sent to clients in 20 minutes after it has been forwarded by TRS EMIR and is identified by

suffix ‘_UVRes’;

Ex: <original file name>_UVRes.txt

Response file from Trade Repository following transaction recording. This file will be returned

within 2 hours from the report being sent and will be identified by suffix ‘_UVTR’.

Ex: <original file name>_UVTR.txt

All response files will contain the information below:

- File handling timestamp (UnaVista will use UK Time)

- Number of transactions sent

- Number of invalid transactions

- Position in the file of the transaction that has generated the error

- Name of the field that has generated the error

- Error code. The list of the error codes is detailed in Annex 3.

- Error code description

- Field Value that has generated the error


21

- Reporting Firm Id

- Transaction Id (UTI)

- Position UTI (PUTI)Filler (PUTI field has been deprecated)

- Report Message Type (Trade, or Position or Life Cycle)

The values returned in the response files will be consistent with the ones sent in the initial report. Ex:

in case the user doesn’t fill a field, this will be returned empty.

Intraday dispatching outcomes and pending status will be displayed in “Files and Transactions”

window.

TRS Server UnaVista TR

1) reporting submission

2) data validation

Result acknowledgment

and errors management

5) UV and TRS data validation

4) report dispatch to UnaVista

6) Report sending validation/ exceptions

3) first reporting result

7) reports forward to

EMIR

TRS Client

T/T+1 T/T+1 T/T+1


22

4.3 UnaVista matching process

The UnaVista EMIR Trade Repository performs a check to find a counterparty report with a matching

Unique Trade Identifier (UTI) for each trade received from the Borsa Italiana EMIR Transaction

Reporting.

If UnaVista is unable to find the report from the other counterparty to the trade within its system, it

then requests the other side of the trade from other Trade Repositories for 7 days. If the other Trade

repositories do not have the other side of the trade UnaVista will discontinue polling for the other side of

the trade. However when another Trade Repository requests the trade in relation to Borsa Italiana,

UnaVista will then receive the other side of the transaction details. Furthermore, if TRS EMIR service

submits an update on a trade, UnaVista will then request an updated version from all trade repositories

for 7 days.

Once located, matched pairs undergoes a field comparison check and the resulting matching statuses

are notified on a daily basis to the TRS EMIR service which, in turn, provides them to each client by

means of Matching Response Files.

UnaVista is reconciling ever common data field on all trade reports submitted where the other

counterparty (CP3) is an EEA counterparty and not an individual. This is a requirement under EMIR,

since every common data field on a trade should match between the two reports. However, some fields

are more significant than others, and should be addressed sooner.

To make this distinction, UnaVista prioritises the differences. As a result trades will fall into one of four

matching statuses:

- Unpaired: UnaVista has not been able to find other side of trade, based on the two

counterparty LEIs and the UTI.

- Differences: UnaVista has paired the trade and reconciled it, but there are differences on one

or more key fields that must be address urgently. For a list of ESMA fields that need to be

matched, see the UnaVista EMIR Reporting Field SpecificationReconciliation Fields file

published on Borsa Italiana website at URL:


23

http://www.borsaitaliana.it/borsaitaliana/gestione-mercati/emir/emir.htm. Key fields for

matching are those with “Reconciliation Category” = 1.

- The following fields must match:

- UTI

- Reporting Firm ID

- Other Counterparty ID

- Buy/Sell Indicator

- Instrument ID Taxonomy

- Instrument ID (Product ID 1)

- Instrument Classification (Product ID 2)

- Notional Currency 1

- Notional Currency 2

- Notional

- Price Multiplier

- Quantity

- Maturity Date

- Cleared

- Reconciled with Differences: UnaVista has paired the trade and there are no differences in

key fields, but there are differences in non-key fields that must be addressed.

- Reconciled: UnaVista has paired the trade, and all fields match.

All matching response files will contain the information below:

- Reporting Firm Id

- Other Counterparty Id

- Transaction Id (UTI)

- Transaction source (manual, file, sFTP file, automatically generated)

- Internal Id

Formatted: Indent: Left: 0.78", Nobullets or numbering

http://www.borsaitaliana.it/borsaitaliana/gestione-mercati/emir/emir.htm


24

- Last update date (UnaVista will use UK Time)

and, where appropriate, also the following:

- Difference field name

- Difference field value

- Other Counterparty field value

- Break priority (key or non-key field)


25

4.4 Appendix 1 – Client reference data

TRS EMIR, in order to facilitate clients reporting activity on OTC and ETD not cleared by CC&G and

decrease the amount of data requested for each operation, provides a data enrichment service using

the Reference Data given by the member at service establishment. Data will be provided by filling out

a dedicated form:

ABI Code: mandatory for ETD IDEM reporting only and if the Client chooses for the automatic

generation of cleared by CC&G transactions. It is however recommended the Client always

specifies its own ABI code upon subscription of the TRS EMIR Service.

Reporting Counterparty ID [CP2ESMA field 1.2]: LEI code. Company Univocal Id

Reporting Firm Corporate Name [CP4] – company name

Reporting Firm Registered Office [CP5] – company registered address

Reporting Firm Country Code of Branch [CP5A]: Company Country ISO code

Reporting Firm Corporate Sector [ESMA field 1.6CP6]: company business sector (ex. Bank,

Insurance , investment bank, lending institution, etc)

Reporting Firm Financial Status [ESMA field 1.7CP7]: specifies if reporting counterparty is

financial, not financial or other (ex. Clearing house)

Moreover, clients who subscribe the service and report ETD contracts on instruments cleared by CC&G will

be asked to provide the same data listed above. They will also be requested to specify if they prefer to

report directly or use the transaction automatic generator feature.




26

4.5 Appendix 2 – UTI for ETD IDEM

This paragraph describes in which way the Clearing system generates UTI codes in order to identify

uniquely trades (for ETD reporting only).

Further details are available in the “Trade Repository Reporting” document published on Cassa di

Compensazione e Garanzia website (www.ccg.it) under “EMIR>Trade Repository” area.

UTI for ETD trades

Field Name Length Description API field

MIC-Code 10 Fixed value

‘000CGIT000’

Participant Code 5 5 digits ABI code identifying

the participant originating the

trade

NotifyContract/Abicode

Trade Date 8 Format YYYYMMDD NotifyContract/ContractDate

Product ID 12 Isin Code NotifyContract/ISINCode

Trade Number 12 Contract number, left padded

with zeros

NotifyContract/ContractNumber (*)

Trade Indicator 1 B=Buy S=Sell (from the

Participant perspective)

NotifyContract/Side

Chain Indicator 1 C=Between CM and CCP

T=Between Trading Member

and Clearing Member

(*) through BCS it is possible to get the trade number (see table above) for each ETD trade (contract

number). Using BCS, it is also possible to fetch the corresponding trade number assigned by the trading

platform (SOLA).

In case the Client opts for the automatic generation of cleared by CC&G ETD transactions, the TRS EMIR

service will use:

- The CCP UTI when reporting the transaction in which the reporting firm is populated with the

Clearing member and the other counterparty is populated with the CCP


27

- The CCP UTI modified replacing the chain indicator T with C (UTI last char) when reporting

the transaction in which the reporting firm is populated with the Clearing member and the

other counterparty is populated with the Trading Member3 and viceversa

UTI for per instrument positions related to ETD trades

Field Name Length Description API field

MIC-Code 10 Fixed value

‘000CGIT000’

Position indicator 1 It will be left blank This field

shall be populated with “-“

Participant Code 5 5 digits ABI code identifying

the participant originating the

trade

NotifyPositions/Abicode

Account 1 Can be “H” for house

accounts, or “C” for client

accounts

NotifyPositions /Accounttype

SubAccount 4 Four chars subaccount code.

The asterisk “*” in the

omnibus account shall be

replaced by the underscore

“_” (Eg. “_OMN”)

NotifyPositions /SubAccount

Product ID 12 Isin Code NotifyPositions /ISINCode

In case the Client opts for the automatic generation of cleared by CC&G ETD postions, the TRS EMIR

service will use:

- The CCP UTI for positions when reporting the transaction in which the reporting firm is

populated with the Clearing member and the other counterparty is populated with the CCP

3 In this context, Trading member means Investment Firm / Broker in the terminology used in ESMA documents.


28

- The CCP UTI for positions modified adding at the end “T” when reporting the transaction in

which the reporting firm is populated with the Clearing member and the other counterparty is

populated with the Trading Member and viceversa.


29

4.6 Appendix 3 – Error codes

4.7

4.8 The “Error Codes” sheet of the “UnaVista EMIR Reporting Field Specification v2.4.xlsx” document details the list of the possible error codes returned in the different response files of the TRS EMIR Service.

4.9 In addition, the error codes detailed in the following table could also be returned.

4.10

Field Code

Field

Validation Check Error Code

Action Type Field Dependency

Message Type Field Dependency

Validation Field Dependencies

- -

"Transaction successfully processed" (*_TRSRes.txt feedback files)

"Transaction accepted by trade repository" (*_UVTR.txt feedback files) 4.11 0 4.12 - 4.13 - 4.14 -

- - Error processing file: 'Invalid reporting date'

4.15 -2 4.16 - 4.17 - 4.18 -

- - “Length of report is greater than 5000” or “Length of value at position n is greater than 512”

4.19 -15

4.20 - 4.21 - 4.22 -

CP2

Reporting Firm ID

Reporting Firm ID not authorized for upload by Borsa Italiana

4.23 -37

4.24 - 4.25 - 4.26 -


Formatted: Heading 2

Formatted: Font: Not Bold
























Formatted: Indent: Left: 0"


30

Disclaimer

This document contains text, data, graphics, photographs, illustrations, artwork, names, logos, trade marks, service marks and information (“Information”) connected with Borsa Italiana S.p.A. (“Borsa Italiana”). Borsa Italiana attempts to ensure Information is accurate, however Information is provided “AS IS” and on an “AS AVAILABLE” basis and may not be accurate or up to date. Information in this document may or may not have been prepared by Borsa Italiana and in this last case is made available without responsibility on the part of Borsa Italiana.

The publication of this document does not represent solicitation, by Borsa Italiana, of public saving and is not to be considered as a recommendation by Borsa Italiana as to the suitability of the investment, if any, herein described.

Contact Details

Borsa Italiana Clients Technology Service team

Technical Account Management Italy

[email protected]

+39 02 72426348/606/647

Service Desk Italy

[email protected]

Toll Free: 0080026772000

From mobile: +39 02 45411399

Transaction Reporting Service: EMIR - borsaitaliana.it · Appendix 2 – UTI for ETD IDEM 2624...

Documents

Transcript of Transaction Reporting Service: EMIR - borsaitaliana.it · Appendix 2 – UTI for ETD IDEM 2624...