Borsa Italiana - MiFID Transaction Reporting Service

Borsa Italiana - MiFID Transaction Reporting Service Manuale del servizio Aprile 2014 Versione 2.1.0

Contents Indice 1 Storia delle modifiche 3 2 Introduzione 4 2.1 Scopo 5 2.2 Validità 5 2.3 Riferimenti 5 3 Transaction Reporting nella direttiva MiFID e nella disciplina nazionale 6 4 Descrizione del servizio 9 4.1 Requisiti 9 4.2 Specifiche Funzionali 10 4.3 Compliance Report 13 5 Specifiche tecniche 15 5.1 Cenni architetturali 15 6 Tracciati applicativi 17 6.1 Tracciato dei messaggi protocollo FIX 17 6.2 Tracciato record dei File 19

1 Storia delle modifiche Date Version Description Author 27 Ago 2007 1.0 Manuale del servizio - bozza BIt Systems 17 Sept 2007 1.0 Manuale del servizio BIt Systems 21 Nov 2007 2.0 Manuale del servizio inserimento Compliance Report 21 Lug 2008 2.0.1 Correzione CounterpartyCodeType G invece di M se MIC in tracciato record file ASCII BIt Systems BIt Systems 20 Settembre 2013 2.0.2 Revisione interna Borsa Italiana 2.1.0 Nuovo template e revisione descrizione controlli effettuati dal servizio Borsa Italiana 3

2 Introduzione Il servizio presentato di seguito, è uno dei servizi MiFID compliant offerto da Borsa Italiana (autorizzato da Consob ad operare in veste di Reporting Channel secondo quanto riportato nella Comunicazione n. DME/7047271 del 24-5-2007 e aggiornata al 13 settembre 2007) e realizzato per i soggetti tenuti ad assolvere l obbligo di transaction reporting nei confronti della Consob (banche e intermediari italiani e branch italiane di banche e intermediari esteri, di seguito complessivamente gli intermediari ) e disciplinato dall articolo 25 della Direttiva 2004/39/CE (MiFID, Markets in Financial Instruments Directive) e dalle relative norme di secondo livello. 4

2.1 Scopo Il presente documento ha l obiettivo di descrivere le caratteristiche tecnico / funzionali del servizio di MiFID Transaction Reporting di Borsa Italiana (nel seguito abbreviato anche in Transaction Reporting) al fine di consentire agli operatori che aderiscono a tale servizio di implementare gli interventi necessari per l adeguamento alla normativa MiFID. Il servizio è offerto agli intermediari (come sopra definiti) per l assolvimento dei propri obblighi nei confronti della Consob ed attiene alle operazioni concluse al di fuori dei mercati regolamentati italiani. 2.2 Validità Le indicazioni contenute nel presente documento hanno validità per tutti gli attori coinvolti nell attività di adeguamento del servizio di Transaction Reporting. 2.3 Riferimenti - Direttiva 2004/39/CE (MiFID, Markets in Financial Instruments Directive); - REGOLAMENTO (CE) N.1287/2006 DELLA COMMISSIONE del 10 AGOSTO 2006 ( Gazzetta ufficiale dell Unione europea ); - Regolamento Mercati CONSOB 11768; - Comunicazione CONSOB 7047271 del 24 maggio 2007; - Comunicazione CONSOB 7070407 del 27 luglio 2007. - Documento di consultazione di CONSOB del 7 novembre 2007 5

3 Transaction Reporting nella direttiva MiFID e nella disciplina nazionale La direttiva MiFID (MiFID, Markets in Financial Instruments Directive) afferma che le imprese di investimento che effettuano operazioni riguardanti strumenti finanziari ammessi alla negoziazione in un mercato regolamentato comunichino i dettagli di tali operazioni all Autorità competente il più rapidamente possibile (cosiddetto transaction reporting). Questo obbligo si applica a prescindere dal fatto che le operazioni siano state effettuate o meno in un mercato regolamentato e riguarda tutti gli strumenti finanziari negoziati nei mercati regolamentati europei. L art. 25, comma 5, della MiFID consente agli intermediari di poter effettuare le comunicazioni alle Autorità competenti, non soltanto direttamente, ma anche tramite un soggetto terzo che agisce per loro conto (cosiddetto Reporting Channel) e approvato dall Autorità competente. Al fine di dare attuazione alle previsioni di cui alla MiFID, la Consob ha progettato un sistema, denominato Transaction Reporting, in grado di supportare la ricezione e l invio del flusso di informazioni relativo all operatività su strumenti finanziari ammessi alla negoziazione nei mercati regolamentati dell Unione Europea. Più in particolare per quanto riguarda lo scambio di informazioni fra gli intermediari e la Consob, quest ultima ha previsto: di continuare a ricevere le segnalazioni delle operazioni effettuate dagli intermediari sui mercati regolamentati nazionali (attualmente Borsa Italiana, TLX e MTS) direttamente dalle rispettive società di gestione dei mercati, attraverso i tre canali attualmente esistenti; di ricevere su un quarto canale tutte le segnalazioni relative alle operazioni da essi effettuate al di fuori dei tre suddetti mercati regolamentati nazionali. Come anticipato il presente documento attiene esclusivamente alla trasmissione a Consob delle operazioni effettuate dagli intermediari al di fuori dei mercati regolamentati italiani. Per quanto attiene alla tempistica del flusso delle informazioni la Consob ha previsto che (v. Fig. 1), gli intermediari dovranno farle pervenire la segnalazione entro la fine della giornata lavorativa successiva al giorno in cui è stato concluso il contratto (ovvero entro le ore 23.59.59 di g 2 ). Il giorno lavorativo successivo (g 3 ) la Consob, effettuati i controlli di qualità sui dati ricevuti dai soggetti nazionali, invierà le informazioni dovute alle altre Autorità competenti 6

estere, e riceverà da quest ultime le informazioni di propria pertinenza. Pertanto, a partire dalla giornata lavorativa g 4 tutte le Autorità avranno a disposizione l insieme completo delle segnalazioni relative alle operazioni concluse il giorno g 1. A tal proposito, si specifica che verranno considerate giornate lavorative tutte le giornate di operatività del sistema Target 1 con l aggiunta di eventuali giornate comuni in cui gli intermediari comunicheranno alla Consob di essere operativi. Nel prosieguo, qualora non specificato, per giornata si deve intendere sempre giornata lavorativa. 1 Attualmente il sistema Target è chiuso nelle seguenti giornate: tutti i sabati e le domeniche, il 1 gennaio, il venerdì prima di Pasqua e il lunedì dopo Pasqua, il 1 maggio, il 25 e il 26 dicembre. 7

Fig. 1 - Tempistica del processo di ricezione e invio delle informazioni Termine ultimo per la comunicazione all Autorità di competenza Disponibilità dell insieme completo delle segnalazioni relative al giorno g1 Giornata in cui è effettuata la transazione Controlli di qualità e scambi di informazioni tra le Autorità Analisi delle transazioni concluse il giorno g1 g 1 g 2 g 3 g 4 t Da ultimo, per quanto attiene ai dettagli del contenuto informativo da comunicare alla Consob, questi ultimi dovranno essere conformi a quanto indicato nel Regolamento Mercati, in fase di modifica, nonché comunicazioni di dettaglio della Consob. 8

4 Descrizione del servizio Il servizio di Transaction Reporting realizzato da Borsa Italiana, che si configura dunque come Reporting Channel, viene offerto ai clienti per adempiere alla direttiva MiFID; Borsa Italiana funge da soggetto terzo per espletare le funzioni di seguito riportate di transaction reporting nei confronti di Consob. 4.1 Requisiti Il file da trasferire a Consob al fine di soddisfare gli obblighi di transaction reporting dovrà essere in formato XML. Il protocollo da utilizzare sarà SFTP. Presso i soggetti segnalanti dovranno essere presenti sia la componente client sia la componente server del protocollo. Il contenuto informativo che dovrà essere rispettato è descritto nel capitolo 5 (Tracciati applicativi). La comunicazione alla Consob dovrà essere effettuata entro la fine della giornata lavorativa successiva al giorno in cui è stato concluso il contratto (ovvero entro le ore 23.59.59 di g2). Di conseguenza alla Consob perverrà quotidianamente dai segnalanti un flusso di file, contenenti ciascuno i dettagli delle operazioni concluse il giorno precedente al di fuori dei mercati regolamentati italiani. Borsa Italiana, in quanto terza parte, invierà quotidianamente un file per ogni impresa di investimento a cui offre il servizio. Al riguardo, si sottolinea che qualora l intermediario non ha dati da inviare nella giornata g2 (in quanto nella giornata g1 non ha concluso alcuna operazione), esso dovrà comunque far pervenire alla Consob entro la fine del giorno g2 un file contenente soltanto le informazioni di base della segnalazione. Inoltre, si precisa che qualora la giornata g2 è lavorativa (come sopra definita), ma l intermediario è chiuso, quest ultimo sarà comunque tenuto a far pervenire in Consob la segnalazione relativa alla sua operatività nella giornata g1 con l usuale tempistica (ovvero entro le ore 23.59.59 di g2). Nel caso in cui un intermediario, per cause di forza maggiore, non possa far pervenire la segnalazione nei tempi dovuti, esso dovrà tempestivamente avvertire la Consob. Qualora un intermediario si accorga, nella stessa giornata di invio della segnalazione, di aver omesso, ovvero indicato erroneamente qualche transazione, potrà effettuare, sempre entro le ore 23.59.59 di tale giornata, una nuova trasmissione di dati che andrà a sovrascrivere completamente quella precedente. Qualora, invece, un intermediario si accorga oltre il termine ultimo delle ore 23.59.59 di g2 della presenza all interno del file già inviato di omissioni o di errori, le segnalazioni omesse o da aggiornare dovranno essere inserite nel primo flusso informativo utile, riportando nel file per ogni omissione e/o errore la data effettiva della negoziazione. 9

Viceversa, in caso di rilevazione da parte della Consob di errori sintattici nel nome del file o nel formato dei dati contenuti nella segnalazione, il sistema di Transaction Reporting della Consob richiederà al soggetto segnalante la ritrasmissione dell intero file. Inoltre, qualora vengano rilevati errori semantici nei record di dati inviati, il sistema della Consob richiederà la ritrasmissione soltanto di tali specifici record. 4.2 Specifiche Funzionali Il sistema di Transaction Reporting di Borsa Italiana riceve le transazioni eseguite dagli intermediari inviati sia singolarmente, sia aggregate in file in modalità manuale o interconnessa (rif. Paragrafo 4.2.1), provvede ad applicare controlli di consistenza e completezza sui dati per poi inviarli a Consob. I controlli eseguiti sono: 1. Verifica sintattica del codice dello strumento finanziario. L utente può specificare sia un codice ISIN, sia un codice nativo di mercato/simbolo alfanumerico. 2. Verifica sintattica sui codici identificativi delle controparti e delle sedi di negoziazione o trading venue. Se la controparte o la trading venue viene indicata tramite un codice BIC, il servizio controlla anche che il 5 e il 6 carattere di tale codice corrisponda al codice ISO di uno dei paesi censiti in una tabella di configurazione sul database del sistema. 3. Verifica sintattica sulla valuta dell operazione e controllo dell appartenenza alla lista delle possibili valute ISO tramite ricerca su una tabella di configurazione sul database. 4. Controlli sintattici e semantici previsti da CONSOB. Le operazioni segnalate da un intermediario anche in momenti diversi della stessa giornata vengono prese in carico dal servizio che provvede ad eseguire i controlli sopra riportati ed a memorizzarle su database in attesa dell invio a Consob. Per ciascun intermediario l invio a Consob di tutte le operazioni prese in carico dopo l invio precedente avrà luogo sulla base di un piano di esecuzione configurato nel servizio. In alternativa sarà possibile forzare, cioè anticipare, l invio a Consob in modalità manuale dalla postazione Client del Transaction Reporting (nel seguito abbreviata in GUI, Graphical User Interface) oppure a seguito della ricezione di file con un opportuno flag all interno del nome: verranno inviate tutte le operazioni prese in carico dopo l ultimo invio. Eventuali errori riscontrati dal sistema a seguito dei controlli descritti, sono notificati al cliente tramite l invio del record errato secondo la modalità prevista (file, messaggio di errore sulla GUI, etc). 10

Per ciascun intermediario, uno o più file verranno inviati a CONSOB via protocollo SFTP e gli esiti verranno gestiti dal servizio e notificati alle postazioni GUI eventualmente connesse o ai canali attivi per le modalità interconnesse. Devono essere segnalati tutti i contratti conclusi su strumenti finanziari ammessi alla negoziazione in un mercato regolamentato dell Unione Europea, effettuati sia nei mercati regolamentati esteri sia al di fuori di essi. I contratti devono essere segnalati entro la fine della giornata lavorativa successiva al giorno in cui e stato concluso il contratto, ovverosia entro le 23.59.59 (T+1) 4.2.1 Funzionalità del Cliente Ciascun intermediario può trasmettere le proprie operazioni al servizio di Transaction Reporting di Borsa Italiana anche in momenti diversi nel corso dell intera giornata in: 1. Modalità manuale attraverso la GUI con: a. Input manuale di singoli contratti con la possibilità di modificare ed eventualmente cancellare operazioni sia già inviate, sia non ancora inviate a Consob; b. Caricamento di file in formato CSV (generato p.e. via Excel), XML, ASCII in APPEND o REPLACE. Ciascun file deve contenere operazioni relative ad una sola giornata e ciascuna operazione (univocamente identificata dall intermediario) può essere presente una sola volta nel file in uno dei seguenti stati: CancellationFlag = 0 (operazione creata o modificata) o CancellationFlag = 1 (operazione cancellata in questo caso non è necessario avere già segnalato l operazione in un file precedente). 2. Modalità interconnessa con: a. Invio di singoli contratti via protocollo FIX 4.2 b. Invio di file in formato CSV (generato p.e. via Excel), XML, ASCII via protocollo SFTP in APPEND o REPLACE. Ciascun file deve contenere operazioni relative ad una sola giornata e ciascuna operazione (univocamente identificata dall intermediario) può essere presente una sola volta nel file in uno dei seguenti stati: CancellationFlag = 0 (operazione creata o modificata) o CancellationFlag = 1 (operazione cancellata in questo caso non è necessario avere già segnalato l operazione in un file precedente). 11

4.2.2 Modalità di segnalazione tramite file L intermediario può inviare le segnalazioni tramite uno o più file per ciascun trading day. Il nome del file deve contenere: il codice BIC dell intermediario, la data di invio del file o reporting date (se diversa dalla business date, il file contiene le correzioni apportate ai record di cui Consob ha segnalato l errore), la business date, il numero di versione (numero progressivo univoco per la coppia reporting date-business date), l indicatore A (append) o R (replace) e l indicatore di invio forzato a Consob. Il servizio accetta dati in formato CSV (<filename>.csv), ASCII con campi di lunghezza fissa (<filename>.txt) ed XML (<filename>.xml). Il nome di un file ha il seguente formato: <ReportingFirm>_<ReportingDate>_<BusinessDate>_<SerialNo>_<AppendReplaceFlag>_<SendNowFlag>.< ext> con: <ReportingFirm>: BIC code di 11 caratteri <ReportingDate>: data di inoltro delle operazioni nel formato YYYYMMDD <BusinessDate>: data di esecuzione delle operazioni nel formato YYYYMMDD <SerialNo>: progressivo giornaliero su 3 cifre. Ogni giorno il progressivo deve ripartire da 001 e, nel corso della stessa giornata, non possono essere gestiti file che non rispettivo l'ordine di sequenza. <AppendReplaceFlag>: assume i valori A (Append) o R (Replace) <SendNowFlag>: indicatore di invio forzato a CONSOB che può assumere i valori Y o N. Un esempio di nome di file corretto è il seguente: BIC12345678_20070724_20070724_001_A_N.txt. Ogni volta che l intermediario invia un file in modalità Append nella stessa giornata, le operazioni in esso contenute vengono prese in carico dal servizio ed aggiunte a quelle ricevute precedentemente. Nel caso di un operazione già ricevuta nella stessa giornata, il nuovo record aggiornerà l ultimo ricevuto (o eventualmente lo cancellerà se il nuovo reca il flag CancellationFlag = 1). Inviando invece un file in modalità Replace tutte le operazioni ricevute nella giornata corrente in qualunque modalità vengono annullate e sostituite in blocco da quelle presenti nel file. A fronte della ricezione di ciascun file il servizio Transaction Reporting di Borsa Italiana genera un file di esiti transazionali, mentre, a fronte dell invio a Consob, viene generato un unico file di esiti istituzionali a prescindere dal numero di file e/o dalle modalità di segnalazione delle operazioni. 12

4.2.3 Funzionalità di monitoraggio e supervisione I contratti segnalati in modalità manuale o interconnessa possono essere visualizzati dagli intermediari all interno della GUI attraverso un tool di monitoraggio delle singole transazioni, che consente anche un controllo dei file trasmessi. Il suddetto tool consente inoltre di modificare e/o cancellare operazioni precedentemente inoltrate al servizio di Transaction Reporting di Borsa Italiana al più entro 4 giorni lavorativi precedenti la giornata corrente. Il servizio avrà un client di monitoring e gestione degli intermediari aderenti ad uso esclusivo di Borsa Italiana con visibilità System (cioè multi-member) in modalità readonly, senza cioè consentire di inserire/modificare o cancellare operazioni segnalate dagli intermediari. Nel caso in cui il cliente si interfacci tramite invio di file, il servizio ritornerà le segnalazioni di errore tramite invio di un file. Sarà cura dell utente provvedere alla correzione degli errori. 4.3 Compliance Report Gli intermediari riceveranno giornalmente il Compliance Report di conferma dell avvenuta trasmissione delle operazioni dopo la ricezione degli esiti da Consob. Il tracciato è di seguito riportato e comprende sia i campi inviati a CONSOB sia campi di servizio del Transaction Reporting utili a ricostruire la storia delle transazioni. FieldName Key Type Size Nullable Description MemberID Yes int No Identificativo del Member associato alla transazione TrxDate Yes char 10 No Data della transazione. Formato: YYYY-MM-DD TrxID Yes char 40 No Chiave univoca della transazione relativamente alla data e al Member SeqNum Yes int No Indice progressivo della storia della transazione. Inizia da 1 EvtSeqNum No Int No IsLast No Int No Indica se il record è l ultimo della storia della transazione. 0: Non è l ultimo 1: E l ultimo KeyID No Int No Assieme al MemberID, fornisce una chiave alternativa per identificare la transazione Status No int No Stato della transazione: 1: Stored 2: Processing 3: Waiting resp 4: Ok 5: Non-blocking Error 6: Blocking Error 7: Deleted DataCheck No Int No Esito dei controlli effettuati sui dati della transazione. 1: Ok 2: Warning 3: Error Operation No char 1 No Operazione associata alla transazione. 13

A: La transazione non era in stato Waiting W: La transazione era in stato Waiting CancFlag No Int No Menzione di annullamento: 0: New 1: Cancel TargetOp No Int No Indica l operazione da effettuare per inviare la transazione al sistema target. 1: Insert (la transazione non è stata ancora mai inviata al sistema target) 2: Update (la transazione è già stata inviata almeno una volta al sistema target) TrxTime No char 8 No Orario della transazione. Formato: HH:mm:SS TimezoneOffset No char 3 No Sfasamento dell orario della transazione rispetto all orario locale InsertDate No char 10 No Data in cui la transazione è stata inserita nella tabella. Formato: YYYY-MM-DD InsertTime No char 12 No Orario in cui la transazione è stata inserita nella tabella. Formato: HH:mm:SS.ttt LastUpdDate No char 10 No Data dell ultima modifica apportata alla transazione. Formato: YYYY-MM-DD LastUpdTime No char 12 No Orario dell ultima modifica apportata alla transazione. Formato: HH:mm:SS.ttt UserID No int Yes Identificativo dello User associato alla transazione. Nel caso delle transazioni lette da file ricevuti tramite server SFTP l utente non è definito (UserID vale NULL) Source No int No Sorgente da cui è stata catturata la transazione. 1: Manual input (tramite la GUI) 2: File (tramite la GUI) 3: FIX 4: File FTP (tramite server SFTP) FileName No varchar 50 Yes Nome del file (senza path) dal quale è stata letta la transazione. Deve contenere la data di segnalazione. E significativo se Source vale 2 o4, altrimenti vale NULL FileProg No int Yes Indice progressivo estratto da FileName. Vale NULL se FileName vale NULL I dati vengono esportati in un file in formato csv che contiene: Prima riga : ExportDate=DD/MM/YYYY (data in cui è stato effettuato l export) Seconda riga : Nomi dei campi Righe successive : Dati 14

5 Specifiche tecniche 5.1 Cenni architetturali Il servizio Transaction Reporting di Borsa Italiana è implementato su una infrastruttura tecnologica ridondata con un centro primario e un sito di disaster recovery. Il collegamento tra gli intermediari e il sistema centrale ospitante il servizio e garantito dalla rete di Borsa Italiana (Bit Network) ove presente. In alternativa e previsto un collegamento internet/vpn. Per quanto riguarda il protocollo di comunicazione verso CONSOB, si realizza un canale SFTP, con trasferimento di un file in formato XML per ogni intermediario. Il protocollo di scambio prevede le seguenti funzionalità: Autenticazione: l autenticazione dell utente è basata su una Username e una Password; invio da parte dell intermediario del file di transazioni; conferma da parte della Consob di avvenuta ricezione di un file corretto; richiesta della Consob di ritrasmissione del file completo a fronte di eventuali errori, sia relativi alla sintassi dei dati, che alla corruzione del file stesso (il protocollo prevede soltanto due cicli di ritrasmissione automatica, oltre i quali è richiesto l intervento di un operatore); richiesta della Consob di ritrasmissione di singole transazioni semanticamente scorrette. La seguente figura illustra il sistema completo di Transaction Reporting verso Consob comprensivo dello schema di connessione degli intermediari al Reporting Channel System (Canale di ricezione 4 della Consob). 15

Intermediari via Borsa Italiana Intermediari via TLX Intermediari via MTS Intermediari via terze parti Atri intermediari che segnalano direttamente Borsa Italiana S.p.A. TLX S.p.A MTS S.p.A Reporting Channel Canale di ricezione 1 Canale di ricezione 2 Canale di ricezione3 Canale di ricezione4 Consob Server per l elaborazione e la memorizzazione dei dati Dati Anagrafici Transazioni 16

6 Tracciati applicativi 6.1 Tracciato dei messaggi protocollo FIX Il servizio accetta dati in formato FIX attraverso il messaggio Trade Capture Report (AE). Per ogni messaggio AE ricevuto il servizio risponde con uno o più messaggi Trade Capture Report Ack (AR) in cui il campo TrdRptStatus (939) indica lo stato del report sia in considerazione del controllo effettuato direttamente dal servizio (presenza dei campi obbligatori, controlli sintattici e semantici, ) sia in relazione all invio del report a CONSOB. Il campo TrdRptStatus può assumere i seguenti valori: 0 Accepted : Il report è stato accettato da CONSOB, la procedura di report è conclusa con successo 1 Rejected : Il report è in errore. L errore può essere stato rilevato dal servizio o da CONSOB 101 Stored : Il report è stato accettato dal servizio ed è in attesa di essere mandato a CONSOB. A seguito dell invio a CONSOB si riceverà lo stato 0 o 1. MsgType = AE 6.1.1 Trade Capture Report Campo FIX Valore Obbligatorio 571 TradeReportID Identificatore univoco del Report Y 1 Account Y 660 AcctIDSource 1 - BIC (Bank Identification Code - SWIFT managed) code (ISO9362) Y 75 TradeDate YYYYMMDD Y 60 TransactTime HHmmSS Y 7566 TimezoneOffset +/-HH Y 54 Side 1 - Buy 2 Sell Y 528 OrderCapacity A - Agency P - Principal Y 48 SecurityID Y 22 SecurityIDSource 4 - ISIN number 8 - Exchange Symbol Y 31 LastPx Y 17

15 Currency ISO 4217 - Currency Code Y 32 LastQty Y 448 PartyID Controparte Y 447 PartyIDSource B - BIC (Bank Identification Code - SWIFT managed) code (ISO9362) G - MIC (ISO 10383 - Market Identificer Code) D - Proprietary / Custom code Y 30 LastMkt ISO 9362 - SWIFT/Bank Identifier Code (BIC) ISO 10383 - Market Identifier Code (MIC) Codice CED 'OTC' Y 17 ExecID Chiave del contratto Y 487 TradeReportTransType 0 New 1 Cancel Y 6.1.2 Trade Capture Report Ack MsgType = AR Campo FIX Valore Obbligatorio 571 TradeReportID Identificatore univoco del Report Y 75 TradeDate YYYYMMDD Y 17 ExecID Chiave del contratto Y 487 TradeReportTransType 0 New 1 Cancel Y 751 TradeReportRejectReason 0 - Successful 100 - Error 58 Text Descrizione dell errore N 939 TrdRptStatus 0 Accepted (accettato da CONSOB) 1 Rejected (in errore) 101 Stored (accettato dal servizio e in attesa di invio a CONSOB) Y Y 18

6.2 Tracciato record dei File Il servizio accetta dati in formato CSV, ASCII con campi di lunghezza fissa e XML. E possibile inviare file via SFTP o tramite il client. Il nome di un file ha il seguente formato: ReportingFirm_ReportingDate_BusinessDate_ Prog_AppendReplaceFlag_SendNowFlag ReportingFirm : BIC ReportingDate : data di invio del file nel formato YYYYMMDD BusinessDate : data alla quale si riferiscono i contratti nel formato YYYYMMDD Prog : progressivo dei file su tre caratteri. Per ogni ReportingFirm il progressivo deve essere incrementato ad ogni invio di file per la coppia ReportingDate - BusinessDate (non contano nel controllo del progressivo AppendReplaceFlag, SendNowFlag). File con un progressivo non valido vengono rifiutati. In particolare vengono rifiutati file con un progressivo minore o uguale all ultimo ricevuto, è invece possibile utilizzare progressivi non strettamente consecutivi (per esempio 1, 2, 4, 7, ). AppendReplaceFlag : assume i valori A (append) o R (replace). Se il file viene inviato in replace tutti i dati ricevuti nella giornata o dall ultimo invio a CONSOB, anche attraverso altri canali (FIX o manuale), vengono rimossi dal servizio come se non fossero mai stati ricevuti, i contratti contenuti nel file vengono elaborati dal servizio. Se il file viene inviato in append i dati ricevuti nella giornata o dall ultimo invio a CONSOB non vengono rimossi, i contratti contenuti nel file vengono aggiornati. SendNowFlag : flg di invio forzato a CONSOB, assume i valori Y o N. Se vale Y tutti i contratti ricevuti nella giornata o dall ultimo invio a CONSOB, anche attraverso altri canali (FIX o manuale), vengono inviati a CONSOB. L estensione del file è.csv per il formato csv,.txt per il formato ASCII con campi di lunghezza fissa e.xml per il formato xml Esempi di invio di file. 19

Esempio1: 1. Invio di BIC12345678_20070724_20070724_001_A_N.txt : Il file contiene i contratti 1, 2 e 3. I contratti vengono salvati dal servizio 2. Invio di BIC12345678_20070724_20070724_002_A_N.txt : Il file contiene i contratti 1 e 4. Il contratto 1 viene aggiornato e il contratto 4 viene salvato dal servizio 3. Invio di BIC12345678_20070724_20070724_003_R_Y.txt Il file contiene i contratti 1, 2 e 4. I contratti 1, 2 e 4 vengono aggiornati, il contratto 3 viene eliminato (come se non fosse mai stato inviato al servizio). I contratti 1, 2 e 4 vengono immediatamente inviati a CONSOB poiché il flag di invio forzato è Y. 4. Invio di BIC12345678_20070724_20070724_004_A_N.txt Il file contiene i contratti 1, 5 e 6. Il contratto 1 viene aggiornato e i contratti 5 e 6 vengono salvati dal servizio. 5. Invio di BIC12345678_20070724_20070724_005_R_N.txt Il file contiene il contratto 5. Il contratto 5 viene aggiornato, l aggiornamento del contratto 1 e il contratto 6 vengono eliminati (come se non fossero mai stati inviati al servizio). 6. All ora programmata il contratto 5 verrà inviato a CONSOB Esempio2 : modifiche di contratti inviati il giorno prima 1. Invio di BIC12345678_20070725_20070724_001_A_N.txt : Il file contiene i contratti 2 e 5. I contratti vengono aggiornati. 2. Invio di BIC12345678_20070725_20070724_002_R_N.txt Il file contiene il contratto 2. Il contratto 2 viene aggiornato, la modifica del contratto 5 viene eliminata (come se non fosse mai stata inviata al servizio). 3. All ora programmata il contratto 2 verrà inviato a CONSOB Per i file ricevuti via SFTP il servizio genera dei file di risposta: R_ReportingFirm_ReportingDate_BusinessDate_Prog.csv 20

che contengono lo stato dei contratti ricevuti. I file di risposta vengono generati e inviati appena sono disponibili nuovi stati dei contratti ricevuti. 6.2.1 Tracciato CSV La prima riga del file contiene i nomi dei campi. Il file deve terminare con una riga contenente la stringa #END_REPORT# Nome campo Formato Valore ReportingFirmID 11x ReportingFirmIDType=1 ISO 9362 - SWIFT/Bank Identifier Code (BIC) ReportingFirmIDType 2n 1 - BIC (Bank Identification Code - SWIFT managed) code (ISO9362) TradingDate YYYYMMDD TradingTime HHmmSS TimeOffset (-)(+)HH ISO 8601 Time Zone Offset Format; SHH BuySellIndicator 1n 1 = Buy 2 = Sell TradingCapacity 1c A - Agency P Principal InstrumentIdentification ISO 6166 - International Securities 12x ISIN Identification Number (ISIN) 30x ExchangeCode Exchange Symbol InstrumentIdentificationType 1d 4 ISIN 8 - Exchange Symbol UnitPrice 19n.5n PriceNotation 3c ISO 4217 - Currency Code Quantity 19n.5n Counterparty 11x CounterpartyCodeType = B 4x CounterpartyCodeType = M 4x CounterpartyCodeType =D (CED Code) CounterpartyCodeType 1c B = ISO 9362 - SWIFT/Bank Identifier Code (BIC) G = ISO 10383 - Market Identifier Code (MIC) D = Proprietary/Custom code 21

11x (BIC) TradingVenue 4x (MIC) 4x (Codice CED) OTC TransactionReferenceNumb 40x er ISO 9362 - SWIFT/Bank Identifier Code (BIC) ISO 10383 - Market Identifier Code (MIC) Codice CED OTC Chiave del contratto CancellationFlag 1n 0 = Not cancelled 1 = Cancelled by the Reporting Firm n : numero c : lettera x: qualunque carattere stampabile ASCII 6.2.2 Tracciato record file ASCII Il tracciato record è costituito da campi di lunghezza fissa. Il file deve terminare con una riga contenente la stringa END_REPORT# Field Name Lunghezza Formato Valore ReportingFirmID 11 11x ReportingFirmIDType=1 ISO 9362 - SWIFT/Bank Identifier Code (BIC) Proprietary / Custom code ReportingFirmIDType 2 2n 1 - BIC (Bank Identification Code - SWIFT managed) code (ISO9362) TradingDate 8 YYYYMMDD TradingTime 6 HHmmSS TimeOffset 3 (-)(+)HH ISO 8601 Time Zone Offset Format; SHH BuySellIndicator 1 1n 1 = Buy 2 = Sell TradingCapacity 1 1c InstrumentIdentification 12 12x InstrumentIdentificationType 1 1n UnitPrice 25 19n.5n A - Agency P Principal ISO 6166 - International Securities Identification Number (ISIN) 4 ISIN 8 - Exchange Symbol 22

PriceNotation 3 3c ISO 4217 - Currency Code Quantity 25 19n.5n Counterparty 11 11x CounterpartyCodeType = B 4x CounterpartyCodeType = G 4x CounterpartyCodeType =D (CED Code) CounterpartyCodeType 1 1c B = ISO 9362 - SWIFT/Bank Identifier Code (BIC) G = ISO 10383 - Market Identifier Code (MIC) D = Proprietary/Custom code 11x (BIC) ISO 9362 SWIFT/Bank Identifier Code (BIC) TradingVenue 11 4x (MIC) ISO 10383 Market Identifier Code (MIC) 4x (Codice CED) Codice CED OTC OTC TransactionReferenceNumber 40 40x Chiave del contratto CancellationFlag 1 1n 0 = Not cancelled 1 = Cancelled by the Reporting Firm n : numero c : lettera x: qualunque carattere stampabile ASCII 6.2.3 Tracciato record del File XML Il formato xml è descritto in TradeReporting.xsd L elenco dei campi è comunque descritto nella seguente tabella: Nome campo Formato Valore ReportingFirmID 11x ISO 9362 SWIFT/Bank Identifier Code (BIC) TradingDate YYYY-MM-DD TradingTime HHmmSS TimeOffset (-)(+)HH ISO 8601 Time Zone Offset Format; SHH BuySellIndicator 1n 1 = Buy 2 = Sell 23

TradingCapacity 1c A Agency P Principal InstrumentISIN 12x ISO 6166 International Securities Identification Number (ISIN) InstrumentExchangeCode 12x Exchange Symbol UnitPrice 19n.5n PriceNotation 3c ISO 4217 Currency Code Quantity 19n.5n CounterPartyBIC 11x CounterPartyMIC 4x CounterPartyCED 4x TradingVenueBIC 11x ISO 9362 SWIFT/Bank Identifier Code (BIC) TradingVenueMIC 4x ISO 10383 Market Identifier Code (MIC) TradingVenueOTC OTC OTC TransactionReferenceNumber 40x Chiave del contratto CancellationFlag 1n 0 = Not cancelled 1 = Cancelled by the Reporting Firm n : numero c : lettera x: qualunque carattere stampabile ASCII 24

Un esempio di Xml è il seguente: <?xml version="1.0" encoding="utf-8"?> <TradeReporting xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xsi:nonamespaceschemalocation="tradereporting.xsd" Version="1.0"> <TradeReportingRecord> < ReportingFirmID>BIC12345632</ReportingFirmID> <TradingDate>2007-08-24</TradingDate> <TradingTime>15:45:00</TradingTime> <TimeOffset>+00</TimeOffset> <BuySellIndicator>1</BuySellIndicator> <TradingCapacity>P</TradingCapacity> <InstrumentExchangeCode>IT1234567890</InstrumentExchangeCode> <UnitPrice>12345678912345.12345</UnitPrice> <PriceNotation>EUR</PriceNotation> <Quantity>2.5</Quantity> <CounterPartyBIC>BICABCDE001</CounterPartyBIC> <TradingVenueBIC>BICZXCVB001</TradingVenueBIC> <TransactionReferenceNumber>TRX0001</TransactionReferenceNumber> <CancellationFlag>0</CancellationFlag> </TradeReportingRecord> </TradeReporting> 25

6.2.4 File di risposta Il file di risposta inviato per i contratti ricevuti via file (csv, ascii con campi di lunghezza fissa e Xml) via SFTP è sempre in formato csv. Nel caso di ricezione di un file sintatticamente sbagliato il servizio risponde con un file con i seguenti campi: Nome campo Formato Valore FileName Nome del file ricevuto ErrorCode 3n Codice dell errore ErrorDescription 200x Descrizione dell errore Altrimenti il file di risposta conterrà informazioni sullo stato dei contratti. Il file termina con una riga contenente la stringa #END_REPORT# Nome campo Formato Valore TradingDate YYYYMMDD TransactionReferenceNumber 40x Chiave del contratto CancellationFlag 1n 0 = Not cancelled 1 = Cancelled by the Reporting Firm 0 - Successful 3n TreadeReportResult 100 - Error ErrorDescription 200x Descrizione dell eventuale errore TradeReportStatus 3n 0 Accepted : Il report è stato accettato da CONSOB, la procedura di report è conclusa con successo 1 Rejected : Il report è in errore. L errore può essere stato rilevato dal servizio o da CONSOB 101 Stored : Il report è stato accettato dal servizio ed è in attesa di essere mandato a CONSOB. A seguito dell invio a CONSOB si riceverà lo stato 0 o 1. n : numero c : lettera x: qualunque carattere stampabile ASCII 26

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 clients-services@borsaitaliana.it +39 02 72426348/606/647 Service Desk Italy service-desk@borsaitaliana.it Toll Free: 0080026772000 From mobile: +39 02 45411399