BME markets Transaction Reporting Service. TRS v 2.1

Transcription

1 BME markets Transaction Reporting Service TRS v Jun 2018

2 Contents 1. BME markets transaction reporting service... 4 Introduction... 4 Notification of transaction reporting records to the competent authority Delegated reporting service file flow... 7 Organisation of record information... 7 Header format... 7 Functioning of records using identifier (RI)... 9 Details of TP record Details of CT record Details of DT record Details of TS record Details of DW record Details of EW record Details of DR record Record validation by the TRS ESMA validations BME validations Timetable Times when information can be sent Timetable for receipt of information General circuit Notifications Technical aspects of inbound files Nomenclature of the files sent by members to the TRS Nomenclature and format of the files sent by the TRS to members FI records VA records CONSOLIDATION Preliminary CONSOLIDATION Special cases of information still not sent to the CNMV Corrections Competent authority data request Examples Example 1. Corresponds to example 43 in the ESMA Guidelines. Document with reference ESMA/2016/ Example 2. Corresponds to example 82 in the ESMA Guidelines. Document with reference ESMA/2016/ Example 3. Corresponds to example 65 in the ESMA Guidelines. Document with reference ESMA/2016/ Example Example Example 6.1. Corresponds to example 70 in the ESMA Guidelines. Document with reference ESMA/2016/ Page 1

3 Example 6.2. Corresponds to example 71 in the ESMA Guidelines. Document with reference ESMA/2016/ Example 7. Trade over instruments on MEFF Power Market Ejemplo 8. Investment Funds Management trade TEXT PLAIN EXAMPLES ANNEX 1: Fields Format TP Record Format Prefixes RO record format. Transaction record RI record format. Identifier record Subregisters SubRegister CT of Clients Format Subregister DT of Client Decisor Format SubRegister DW of decisor makers within Firm Format SubRegister EW of executors within Firm Format Subregister DR of Other Data Format SubRegister TS of Transmission Format ANNEX 2: ESMA Validations Page 2

4 Amendments to the document please see 1.2 Market member will submit TP and CT records of XOFF trades. Market member will submit CT records of market trades. Equity market Transaction reporting ID will be composed as Fixed Income and derivatives markets. PTI will only submit to TRS information of trades of corporate events. There will be only one period to submit trade amendments. Details about CNMV information files requirements. Amendments to the document please see 2.0 New BME validations for short selling indicator and NCA transaction information requirement file. Page 3

5 Introduction 1. BME markets transaction reporting service This document describes the functioning of the Transaction Reporting Service (TRS) to be provided by BME markets, as per MiFID II requirements. MiFID II requires that all investment firms (and all markets for any investment firms not in the European Union) prepare a report for each transaction with financial products, which must contain the following fields: Page 4 RTS 22 field Description number 1 Report status 2 Transaction reference number 3 Trading venue transaction identification code 4 Executing entity identification code 5 Investment firm covered by Directive 2014/65/EU 6 Submitting entity identification code Buyer details 7 Buyer identification code 8 Country of branch for the buyer 9 Buyer first name(s) 10 Buyer surname(s) 11 Buyer date of birth Buy decision maker details 12 Buy decision maker code 13 Buy decision maker first name(s) 14 Buy decision maker surname(s) 15 Buy decision maker date of birth Seller details 16 Seller identification code 17 Country of branch for the seller 18 Seller first name(s) 19 Seller surname(s) 20 Seller date of birth Sell decision maker details 21 Sell decision maker code 22 Sell decision maker first name(s) 23 Sell decision maker surname(s) 24 Sell decision maker date of birth Transmission details 25 Transmission of order indicator 26 Transmitting entity identification code for the buyer 27 Transmitting entity identification code for the seller Transaction details 28 Trading date time 29 Trading capacity

6 30 Quantity 31 Quantity currency 32 Derivative notional increase/decrease 33 Price 34 Price currency 35 Net amount 36 Venue 37 Country of the branch membership 38 Up-front payment 39 Up-front payment currency 40 Complex trade component ID Instrument details 41 Instrument identification code 42 Instrument full name 43 Instrument classification 44 Notional currency 1 45 Notional currency 2 46 Price multiplier 47 Underlying instrument code 48 Underlying index name 49 Term of the underlying index 50 Option type 51 Strike price 52 Strike price currency 53 Option exercise style 54 Maturity date 55 Expiry date 56 Delivery type Operator, algorithms, exemptions and indicators 57 Investment decision within firm 58 Country of the branch responsible for the person making the investment decision 59 Execution within firm 60 Country of the branch supervising the person responsible for the execution 61 Waiver indicator 62 Short selling indicator 63 OTC post-trade indicator 64 Commodity derivative indicator 65 Securities financing transaction indicator Page 5

7 Two sources will be used to complete these fields in the Transaction Reporting Service provided by BME markets: a) From data available to BME markets, and b) A database of data provided by each market Member. With a view to optimising the data available from BME, and to facilitate the inputting of additional data by members, BME has segmented the information needed to prepare the transaction report for a transaction into different records, all in plain text (CSV) format. The records are named as follows: Record type TP CT DT TS DW EW DR Description Record containing transaction data from the market. This type of record will be provided by members on in certain circumstances, such as those detailed later in this document. Contains transaction holder ID information. Contains information on the person or entity making the decision for the customer. Provides information on order transmission. Contains information on the decision maker for the transaction within the firm. Contains information on the execution of the transaction within the firm. Used to provide other details not included in the previous records. Notification of transaction reporting records to the competent authority The Transaction Reporting Service of BME markets is open not only to entities whose National Competent Authority is the CNMV but also to entities required to notify to other National Authorities. The service enables an XML file to be provided containing a firm's transaction report: Directly to the National Competent Authority for all transactions on the market (with MIC). Through BME's ARM to the National Competent Authority for all off-exchange transactions (XOFF transactions from a transaction or transaction performed on the market). Directly to the CNMV for all off-exchange transactions (XOFF transactions from a transaction or transaction performed on the market), provided the member performing them is a non-eu member. Page 6

8 2. Delegated reporting service file flow Organisation of record information The various types of records can be used in two ways: 1. By assigning records to a transaction. If used in this way, the member must send the TRS information on each type of record for each transaction. 2. By assigning records to an identifier. If used in this way, each record must be associated with an identifier, which may be included in the market order (in relation to order record keeping obligations). The TRS will bring together the appropriate record of each type to collate the information needed for the specific transaction in the transaction report. Further information on this matter is provided in the point entitled Functioning of records using identifiers (RI)" of this document. In order inform the TRS how each record is to be used, the record sent must always be preceded by a header entitled: 1. RO if the record is to be associated with a specific transaction (operation). 2. RI of the record is to be associated with an identifier or short code. If data on a transaction can be entered through RI and RO records, the information provided through RO records will be deemed correct (for further information, see example 3 in the Examples section). Header format RO, transaction record The RO prefix allows several records to be associated with a transaction. As the information needed to prepare a transaction report for this transaction has been divided into different types of record, a record must be created for each class: CT, DT, TS, DW, EW and DR. Each record contains a type of information and must be notified according to the date of the transaction, i.e. depending on the type of transaction, some of these records will not be necessary. Each of these record types must be preceded by a RO header with the following structure: No. RTS 22 Field Information Description 1 TypeReg RO Record type 2 Action A-Registration Indicates purpose of a TOP record sent. B-Deregistration 3 4 ExctgPty Legal entity identifier Executing entity LEI 4 TrdnVn MIC MIC of market generating the record. 5 Page 7 Execution code Code of transaction for which data is provided.

9 6 Trade date YYYY-MM-DD Trade date with the format: YYYY-MM-DD 7 BuyrSellr B-Buy S-Sell Direction of the transaction. 8 SubRegiste DR, CT, DW, Indicates type of record preceded by this r EW, DT or TS header: CT, DT, TS, DW, EW or DR. As can be seen in the description, with regard to field 8 the RO allows different types of information to be provided (according to the type of record that follows it) for one of the directions of the transaction. If the member reporting a transaction is both the buyer and seller, the member must send a set of records for the purchase and another set for the sale. RI, Identifier record The RI prefix allows several records to be associated with an identifier. All types of records can be associated, except the TP record Member will be solely entitled to use RI record to submit information of trades carried out on D and D-1, being D the date of the RI record submission. In the event of submitting several ones for a same day, the last one replaces the former. Information related to an identifier can be sent by two manners: Daily and the STR will be in charge of managing the necessary information to complete every trade bearing in mind the changes made on the information submitted along the time or the fact that the information is equal to the one submitted the previous day, even if the data identifying the key are the same of the previous day. For this purpose the initial effective date and final effective data shall be the same, specifying the execution date of the trades that are going to be linked to this information. Once, in this case the initial date is indicated, not being before D-1, and being D the date the RI record is sent; and final effective date or very far in the future. In a timely manner once a change occurs, i.e., an initial date is indicated, not being before D-1, and being D the date the RI record is sent and a final effective date different to the initial date. Thus, another RI record must be submitted on the effectiveness end date or, the day, before the effectiveness end date, when a change of the information related to that identifier occurs. Each of these record types must be preceded by an RI header with the following structure: RTS No. Field Information Description 22 1 TypeReg RI Record type A-Registration Indicates purpose of a TOP record sent. 2 Action B-Deregistration Legal entity 3 4 ExctgPty Executing entity LEI identifier Page 8

10 4 TrdnVn MIC 5 6 Starting_Dat e Ending_Dat e 7 Identifier 8 SubRegister YYYY-MM-DD YYYY-MM-DD CT, DW, EW, DT, TS or DR MIC of market segment for which the record is generated. Character asterisk (*) can be used to inform that record is valid for all MICs.. Record validity initial date with the format: YYYY-MM-DD Record validity final date with the format: YYYY-MM-DD. Initial and final date can be the same, for records only valid for a day. Identifier code associated with the record that this header precedes. Indicates type of record preceded by this header: CT, DT, TS, DR, DW or EW. Effectiveness dates allow to specify the effectiveness or validity of the information that accompanies this record: Informing the initial effective date and final effective date is compulsory. In the event that it is informed just for one day, the initial and final date shall be the same day. If the information provided with the RI record is intended to be maintained forever, final date must be For those cases where the information provided with the record is considered static, the STR will keep it until the effective date or until another RI record is submitted to replace the previous one. Initial date will not be previous to D-1, being D the date the RI record is sent to the STR. When an RI record has a range of dates that matches partially the range of dates of a previously sent RI record, TRS will take the information of the last RI sent just for the range of dates reported in the record. Functioning of records using identifier (RI) As per Regulation (EU) No 600/2014 of the European Parliament and of the Council, Article 25 thereof, operators of a trading venue shall keep at the disposal of the competent authority the relevant data relating to all orders in financial instruments received through their systems. Commission Delegated Regulation (EU) 2017/580 specifically establishes what data must be recorded. Of the data for which records must be kept, three may be used in relation to transaction reporting: RTS 24 3 Field Information Description Client identifier: Code used to identify the client of the member or participant of the trading venue. Page 9

11 4 5 Investment decision within the firm Execution within the firm Code used to identify the person or algorithm in the member or participant of the trading venue responsible for the investment decision, as per Article 8 of Commission Delegated Regulation (EU) 2017/590. Code used to identify the person or algorithm in the member or participant of the trading venue responsible for execution of a transaction deriving from the order, as per Article 9 of Commission Delegated Regulation (EU) 2017/590. These data will be provided by each member in each order using whole numbers between 100 and 4,294,967,295 (2^32-1). These numbers are identification codes representing unique keys linked to a database managed by BME. These codes in the order may then be used in the transaction reporting with the identifier records that the member has provided. Specifically: The identifier given in the order as "client ID code" will be used to establish which CT record, DT record and TS record will be used in the transaction report for the transaction generated by this order. The identifier given in the order as "investment decision within the firm" will be used to establish which DW record will be used in the transaction report for the transaction generated by this order. The identifier given in the order as "execution within the firm" will be used to establish which EW record, will be used in the transaction report for the transaction generated by this order. Following identification codes are set for all users with following values: Field 4, Client identification code (ClientID): 0- There is no client in this order (self-account order). In this case is not necessary for the market Member to submit additional information of the order s holder. 1- Aggregated order: related to client identification/ counterparty flag INTC. Field 5, Investment decision code within the firm (DcsnwFirm): 0- There is no decision within the firm (decision has been reached out of the firm). Field 6, Execution code within the firm. (ExctwFirm): 3- Client information is used to fill in the executor s. Data contained CT, DW and EW records are larger in TRS case than in Order Record Keeping (ORK). As long as an entity hires the TRS, it would be able to send not only the data required in these three records of the ORK, but also the additional data necessary to do the Transaction Reporting. By this way, all the additional data could already be send though the ORK service. Page 10

12 Details of TP record The TRS will receive TP records from each BME market in which members have contracted the Transaction Reporting Service for all transactions executed in the market (not for off-exchange transactions XOFF). These records will have the following fields: No RTS2 Field Information Description. 2 1 TypeReg TP Record type 2 Action A- Registration B- Deregistrati on Indicates purpose of a TOP record sent. 3 BuyrSellr B-Buy Order direction. Specifies if the transaction is S-Sell a purchase or a sale 4 ClientID Short code of client specified in order 5 DcsnwFirm 6 ExctwFirm 7 PType Page 11 LEI, MIC, INTC Short code of decision maker within firm specified in order Short code of executing entity within firm specified in order Counterparty identification type If PType=LEI, the LEI of the Counterparty in 8 7,16 LEICnpty the transaction. (LEI of market central counterparty) If PType=MIC, for bilateral market 9 7,16 MICCnpty transactions with no CCP. Trading Venue MIC code where the transaction was executed TxId Transaction report ID TradPlcMtchgId Market execution ID 12 4 ExctgPty Executing entity LEI 13 5 InvstmtPtyInd Indicates whether member is or is not subject to Directives 39/2004 and/or 65/ SubmitgPty LEI code of TR transmitting entity TrnsmssnInd Transmission of order indicator TradDt Trade date and time TradgCpcty Trading capacity TypeQty Type of units of quantity in transaction Unit Trading unit. For equities, derivatives and some fixed-income market transactions NnmMntry Monetary unit QtyCurrency Price currency TypePric Transaction price type Pric Price BsisPts Currency Instrument price expressed as a percentage. Only applicable for certain fixed-income market products. Transaction price currency. Only if price is expressed in monetary units.

13 26 35 NetAmt Net transaction amount TradVn MIC of market on which transaction executed CtryOfBrnch Country of member's branch UpFrntPmt Up-front payment amount UpFrntPmt Up-front payment currency _currency CmplxTrad Code linking various trades as part of a CmpntID package InstrmID ISIN of financial instrument WvrInd Waiver indicator SctiesFincgTxInd TRUE FALSE «True» shall be populated where the transaction falls within the scope of activity but is exempted from reporting under Regulation (UE) 2015/2365. «False» otherwise. When a trade has been cancelled in equity markets, the market will request the deregistration of this trade to TRS. If this trade has already been reported to the competent authority, TRS will request a deregistration to the competent authority. When a market trade is deregistered, market member must submit a deregistration of all of its XOFF trades associated. PTI system will only submit TP record to STR of trades derived from corporate events. Market members can deregister TP records of XOFF trades sending a TP record setting Action field to B. This cause the deregistration of the whole XOFF trade. To amend XOFF trades, market members can send another registration of a TP record with the new information. With reference to off-exchange transactions (XOFF), members must send a TP record for the allocations made by members or any other off-exchange (XOFF) transaction. When it is the member who sends the TP record to notify an XOFF transaction, fields 8 (TxId) and 9 (TradPlcMtchgld or execution number) must be completed as per the following logic: Characters "XX" Execution date of the original transaction generating the XOFF subsequently. MIC of the original market generating the XOFF subsequently. ID of the original transaction (TradPlcMtchgId) generating the XOFF subsequently. Direction of the original transaction, using "B" for purchases and "S" for sales. Three serial numbers starting with 001, used to make each XOFF transaction code unique. Page 12

14 Example: On the date , a purchase was made on the financial derivatives market with the MIC XMIC and transaction codefi This was an aggregated transaction that must be separated into three allocations or disclosures using a sequential enumerator. These disclosures will carry the following execution numbers: XX XMICFI B001 XX XMICFI B002 XX XMICFI B003 Details of CT record CT records provide client identification data. They will have the following structure: RTS No. Field Information Description 22 1 SubRegister CT Record type 2 PType LEI, P, INTC Buyer or seller ID type 3 7,16 LEI 4 7,16 Prsn_Schme Nm Legal entity identifier NIDN, CCPT, CONCAT If PType=LEI. Client LEI. If the identifier is an ordering party (as is the case with fund managers), the fund manager's LEI will be used. If PType=P. ID type for natural person 5 7,16 Prsn_Id National_ID If PType=P. Client identifier. DNI (national ID number) for Spain 6 9,18 Prsn_FrstNm If PType=P. Client forename. 7 10,1 If PType=P. Client surnames. Prsn_Nm Surnames ,2 If PType=P. Client date of birth Prsn_BirthDt Date of birth 0 9 8, 17 CtryOfBrnch [Not applicable to equities, but does apply to derivatives and fixed income] Country of the branch placing the order This field must indicate the country of the branch receiving the order from the client or making the investment decision on a client's behalf as per a discretionary mandate from said client. If this activity has not been carried out by a branch, the code for the home Member State of the investment firm or the code of the country in which the investment firm has its headquarters or registered address (in the case of non-eu firms) must be entered. When the transaction corresponds to a transmitted order that meets the transmission conditions specified in Article 4 [of Commission Delegated Regulation (EU) 2017/590], the information received from the transmitting entity must be entered in this field. The identifiers for natural persons must follow the ranking provided in Annex II: "National client identifiers for natural persons to be used in transaction reports" of Commission Delegated Regulation (EU) 2017/590 of 28 July Page 13

15 If a there are several clients for the same identifier or trade (joint account), several CT records (one for each individual in the joint holding) must be sent on separate lines, using the same transaction code (if RO used) or the same identifier (if RI used). If a record is sent with the "Deregister" command in a CT record sent for which joint holders would have been sent, the TRS will deregister all the joint holders associated with the transaction (if a RO is used) or identifier (if an RI is used), i.e. it is not possible to deregister just one holder in joint account records, rather all will have to be deregistered and a new correct list sent. When a market member wants to make any trade ownership amendment, whether is a market trade or XOFF, it must send a RO-CT with Action field set to A to update ownership information. When CT records of an aggregated trade is amended, submitting a deregistration and then registering a CT record, it will be necessary market member to submit a deregistration of every XOFF trade associated. When the TRS receives a CT deregistration from a market member, there will not be ownership and it will be necessary to register the ownership. To make any XOFF ownership amendment it is required to deregistrate the XOFF trade sending a deregistration TP and then submit all registration records to register the trade with new ownership information. It is not necessary for the market member to send a CT registration when dealing on own account, that is to say, the member is the owner of the transaction. The market will be responsible for sending the CT record of the operation to the STR. Only a CT record is allowed for own account trades. Details of DT record These records cover information on client decision makers. If the client is the decision maker or the transaction holder is the market Member, the member does not need to send a DT record, as these data are left blank in the transaction report. No. 1 2 Page 14 RTS 22 Field Information Description SubRegist er Dcsn_typ eprsn DT LEI, P 3 12,21 LEI LEI 4 12,21 Prsn_Sch menm NIDN,CCPT,CO NCAT 5 12,21 Prsn_Id National_ID 6 13,22 Prsn_Frst Nm Name Record type Indicates if the decision maker is a natural or legal person If PType=LEI. Only completed if the decision maker acts under a power of representation. Decision maker LEI If PType=P. Only completed if the decision maker acts under a power of representation and is a natural person. ID code types for natural person decision maker If PType=P. Only completed if the decision maker acts under a power of representation. Decision maker national ID If PType=P. Only completed if the decision maker acts under a power of representation and is a natural person. Decision maker first name

16 7 14,23 Prsn_Nm Surnames 8 15,24 Prsn_Birt hdt Date of birth If PType=P. Only completed if the decision maker acts under a power of representation and is a natural person. Decision maker surnames If PType=P. Only completed if the decision maker acts under a power of representation and is a natural person. Decision maker date of birth When a DT record is used by way of the identifier method (through an RI), the decision maker identifier must match that of the client. If a client performs transactions in which the decision maker is the same, and transactions in which the decision maker is different, the member must generate two different identifiers. Example: CT record with identifier 32,655 and DT record with identifier 32,655: when the client has a decision maker. CT record with identifier 32,656 and no DT record: when the client is the decision maker. Client details in records 32,655 and 32,656 are the same (as the client is the same), although one identifier or the other is used in the order to correctly identify the decision maker in the transaction report. Details of TS record These records are associated with information on the order transmission, as defined in Article 4 of RTS 22. If there is no order transmission, the member is not required to send a TS record as the aforesaid data will be left blank in the transaction report. No RTS Field Information Description TypeReg TS Record type 2 25 Transmissi on of order indicator 3 26,27 Trnsmttg 0-False / 1-True Legal entity identifier Indicates if there is an order transmission from one firm to another. LEI of other firm transferring order to the market member, when the transmission requirements are met. When a TS record is used by way of the identifier method (through an RI), the transmission identifier must match that of the client. If a client performs transactions in which there is a transmission, and transactions in which there is no transmission, the member must generate two different identifiers. Example: CT record with identifier 32,655 and TS record with identifier 32,655: when the transaction derives from a transmission. CT record with identifier 32,656 and no TS record: when the transaction does not derive from a transmission. Client details in records 32,655 and 32,656 are the same (as the client is the same), although one identifier or the other is used in the order to correctly identify the existence of a transmission in the transaction report. Page 15

17 Details of DW record These records contain information on the transaction decision maker's identity when the decision has been taken within the member. In all other cases, this information does not need to be provided. No. 1 RTS Field Information Description SubRegiste r Dcsn_type Prsn DW P-Person A-Algorithm 3 57 Dcsn_Algo Algorithm code Dcsn_Othr_ SchNm Dcsn_Othr_ Id Dcsn_Ctry OfBrnch NIDN, CCPT, CONCAT National_ID Country code Record type Type of decision maker If Dcsn_typePrsn='A'. Code of algorithm taking the transaction decision within the firm. If Dcsn_typePrsn='P'. National ID code type If Dcsn_typePrsn='P'. National ID of transaction decision maker within the firm. If Dcsn_typePrsn='P'. Country where the transaction decision maker within the firm is located. If the decision is taken by an algorithm, this is left blank. Details of EW record These records contain information on the identity of the executing broker within the firm. No. RTS 22 Field Information Description 1 SubRegister EW Record type 2 59 Exct_typePr sn P-Person A-Algorithm C-Client 3 59 Exct_Algo Algorithm code Exct_Othr_S chnm Exct_Othr_I d Exct_CtryOf Brnch NIDN, CCPT, CONCAT National_ID Country code Type of transaction executing entity within the firm. If the execution is performed by the client, Executor Type= C shall be informed in order to TRS reports as Execution within firm the code NORE If Exct_typePrsn='A'. Code of algorithm sending order to the market within the executing member. If Exct_typePrsn='P'. National ID code type If Exct_typePrsn='P'. National ID of the person sending the order to the market within the executing member. If Exct_typePrsn='P'. Country of the branch supervising the person responsible for the execution. Only completed if not an algorithm. Page 16

18 Details of DR record These records contain the rest of the information required for the transaction report and not included in the other records. Members can choose to send a DR record by way of an identifier (using an RI) with the identifier of zero. This would mean that the values assigned to each of the fields associated with this DR record with an identifier of zero would be used as default values in all transactions of the market Member for the market specified in MIC fields of the RI record. DR records can also be provided for specific transactions (using RO), either because default data have not been sent (as a DR record with an identifier of zero has not been sent) or because the data identified as being default data for a specific transaction are not correct. No RTS Field Information Description TypeReg DR Record type 2 40 Page 17 CmplxTrad CmpntId 3 62 ShrtSellgInd 4 64 RskRdcgTx 5 8,17 CtryOfBrnch [Applicable to equities, does not apply to derivatives and fixed income] SESH, SELL, SSEX, UNDI Unique ID code for executions comprising a basket or package trade. Short selling indicator. Completed in sales on a firm's own behalf or that of its clients. Left blank in the case of an aggregated order. Can be completed with the following codes: SSEX - Short sale with exemption. A market making short sale or short sale in a primary market SESH - Short sale with no exemption. All other short sales SELL - No short sale. An ordinary sale, not a short sale. UNDI Information not available Indicator of reduction in commodities risk, only applies to warrants, certificates and energy derivatives. If the transaction reduces commodity risk="true", otherwise "False" This field must indicate the country of the branch receiving the client order or taking the investment decision on the client's behalf acting under a discretionary mandate provided by said client, as per Article 14.3 [of Commission Delegated Regulation (EU) 2017/590]. If this activity has not been performed by a branch, the code for the home Member State of the investment firm or the code of the country in which the investment firm has its headquarters or registered address (in the case of non-eu firms) must be entered. When the transaction corresponds to a transmitted order that meets the transmission conditions specified in Article 4 [of Commission Delegated Regulation (EU) 2017/590], the information received from the transmitting entity must be entered in this field.

19 OTC post-trade indicator Only applicable to the leg of the transaction between the member and its client, i.e. to the XOFF (from the member to its clients). This may be completed with the following flags: 6 63 OTCPstTradInd For all instruments: BENC = Transaction with benchmark parameters ACTX = Agency cross LRGS = Transaction with large post-trade volume ILQD = Transaction with illiquid instruments SIZE = Transaction above the specific size CANC = Cancellation AMND = Amendment 7 29 TradgCpcty 7 Exempt FALSE TRUE For shares and similar instruments: SDIV = Transaction with special dividend RPRI = Transaction with price improvement DUPL = Reporting of duplicate trading TNCP = Transactions not contributing to price discovery process for the purposes of Article 23 of Regulation (EU) No 600/2014 For instruments other than shares and similar instruments: TPAC = Combined transaction XFPH = Transaction with exchange of physical assets Trading capacity. This field allows market member to amend trading capacity informed in TP record by BME. It is not required to fulfil this field if TP capacity is correct If market member amend this field, next time DR record is sent this field must be fulfilled. All transactions will be included by default in the TR (this field will be FALSE by default). In the case that any transaction of the entity would not have to be included in the TR, this filed should be populated as TRUE. In case trade had been reported, market member can send a Exempt=1 and TRS sill submit to the competent authority a deregistration of this trade and this trade will be saved in TRS database as Exempt=1 Page 18

20 ESMA validations 3. Record validation by the TRS The European Securities and Markets Authority (ESMA) has established a raft of validations that each transaction in a transaction report must pass. The full table is attached as Annex 2. BME validations As well as all the validations proposed by the ESMA, BME will also perform the following validations: ClientID: if the client code associated to a transaction is zero (predetermined value, please see section Functioning of records using identifier (RI) of Chapter 2 Delegated reporting service file flow ), the field Trading Capacity must contain value DEAL or MATCH. BME reserves the utilization of the first 100 identifiers (numbers from 0 to 99). Any RI record using numbers below 100 will be rejected. BME will check aggregated market trades have INTC as only ownership. Several CT records are not allowed for aggregated trades. Specific validations within every filed will be the following: RTS 22 Page 19 Field name 1 Report status Description / Field completion / Validations Can be: NEW/CANC. CANC only when a TR that has already been sent is to be cancelled 2 TR ID This is the transaction report identifier: 3 Market execution reference: Execution ID This is the market execution number Executing entity LEI Member as per Directives 39/2004 or 65/2014 (Art. 4.1) Code of TR transmitting entity 7 Buyer identifier Market member LEI. It will be checked that the member has adhered to the BME markets TR in said segment and asset for the trading date being reported. Field confirming whether the member is a financial entity recognised in the EU. LEI code of the Trading Venue or the BME ARM LEI. LEI or national ID of the holder of the bought instruments. If it is the counterparty in the transaction, the following is entered in this field: BMECLEARING's LEI in clearing house transaction, or the MIC of the market segment in bilateral market transactions with no CCP. "INTC" entered if a transaction is aggregated. If the identifier is an ordering party (as is the case with fund managers), the fund manager's LEI will be used. If the trading capacity (29) is DEAL, fields 9 to 15 are left

21 blank. Country code of the branch of the entity where the order was generated. Only completed if the order is from a 8 Country of buyer's client or executed on a client's behalf under a generic branch mandate (in which case, fields 9 to 15 are also completed). Left blank if an order is on the member's own behalf. 9 Buyer's first name Buyer's first name, natural person. May be up to 25 in the case of joint ownership. 10 Buyer's surname Buyer's surname if a natural person. May be up to 25 in the case of joint ownership. 11 Buyer's date of Buyer's date of birth if a natural person. May be up to 25 birth national, in the case of joint ownership. Code of 12 person/firm taking Only completed if the decision maker is not the client. the purchase Would be the decision maker LEI or national ID decision. 14 Surname of person Only completed if the decision maker is not the client taking the and is a natural person. purchase decision. 15 Date of birth of Only completed if the decision maker is not the client person taking the and is a natural person. purchase decision. 16 Seller identification Same as field 7, but with sale data. 17 Country of seller's branch Same as field 8, but with sale data. 18 Seller's first name Same as field 9, but with sale data. 19 Seller's surname Same as field 10, but with sale data. 20 Seller's date of birth Same as field 11, but with sale data. 21 Code of person/firm taking Same as field 12, but with sale data. the sale decision. 22 First name of person taking the Same as field 13, but with sale data. sale decision. 23 Surname of person taking the sale Same as field 14, but with sale data. decision. 24 Date of birth of person taking the sale decision. Same as field 15, but with sale data Transmission of order indicator Code of buying member who transmits the order. Code of selling member who transmits the order. The transmitting entity will enter "True" in its reporting when the transmission conditions stipulated in Article 4 of RTS 22 are not met, "False" must be entered in all other instances. Where one exists, LEI of other firm transferring buying order to the market member. Where one exists, LEI of other firm transferring selling order to the market member. Page 20

22 28 Page 21 Executing date and time 29 Trading capacity Details of the date and time of the execution with the format: YYYY-MM-DDThh:mm:ss.ddddddZ. Where "T" separates date from time, and "Z" indicates that the time is CUT. 'dddddd' are fractions of a second. On the XOFF side, the market time is used. Can be: MTCH: Trading on behalf of a third party. / DEAL: Trading on own behalf / AOTC:. Any other capacity. 30 Quantity Number of units of the instrument. 31 Price currency 32 Increase or decrease in the notional value of the derivatives contract Not applicable, as the quantities are not monetary units, rather a number of securities or contracts. Not applicable for BME markets. 33 Transaction price The price of the transaction. 34 Transaction price Currency in which the transaction has been made. currency Always EUR 35 Net transaction Solely for fixed income. Other validations: those amount described in Annex Market on which transaction executed MIC of the market on which the security is traded. 37 Country of member's branch Country code of the member executing the order. 38 Up-front payment Not applicable, left blank 39 Up-front payment currency Not applicable, left blank 40 Ind. linking various Unique ID code for executions comprising a fixedincome basket or derivatives strategy. executions for reporting Financial instrument identifier Financial instrument name Financial instrument classification ISIN of the financial instrument being traded. Left blank. Information via FIRDS. Left blank. Information via FIRDS. 44 Notional currency 1 Left blank. Information via FIRDS. 45 Notional currency 2 Left blank. Information via FIRDS. 46 Price multiplier Left blank. Information via FIRDS. 47 Underlying financial instrument code Left blank. Information via FIRDS. 48 Underlying index name Left blank. Information via FIRDS. 49 Term of underlying index Left blank. Information via FIRDS. 50 Option type Left blank. Information via FIRDS. 51 Strike price Left blank. Information via FIRDS. 52 Strike price Left blank. Information via FIRDS.

23 currency 53 Option exercise style Left blank. Information via FIRDS. 54 Maturity date of financial instrument Left blank. Information via FIRDS. 55 Derivative expiry date Left blank. Information via FIRDS. 56 Delivery type Left blank. Information via FIRDS. 57 Person or algorithm taking the investment purchase (within the firm) Country of the branch responsible for the investment decision (within the firm) Person or algorithm responsible for the execution (within the firm) Country of the branch supervising the person responsible for the execution (within the firm) 61 Waiver indicator Short selling indicator OTC post-trade indicator Commodity derivative indicator (commodity risk) Reporting exemption indicator Reporting exemption indicator Reporting exemption indicator Completed with the national ID of the person or code of the algorithm taking the decision within the firm. Only completed when performed on own behalf or on behalf of a client with a generic mandate. Country where the transaction decision maker within the firm is located. Only completed for natural persons. Not completed for algorithms. Completed with the national ID of the person or code of the algorithm sending the market order within the executing member. Country code of the branch where the executing party is located. If the order is executed by an algorithm, this is left blank. Indicator of the waiver type (blocks, hidden volume, etc.). Left blank or with waiver. This field is only populated for trades made in a trading venue; empty for XOFF trades. Only can be fulfilled for sell transactions if trade is not aggregated. Not applicable for derivatives Only applicable to the leg of the transaction between the member and its client, i.e. to the XOFF (from the member to its clients). Commodity derivative risk indicator. If the transaction REDUCES commodity risk="true", otherwise "False". FALSE (fixed). No market transaction will be performed to obtain finance. SFT, e.g. ECB bond purchase A trade cannot be set to exempted again if it was previously set to exempted. A trade that has been requested by a NCA cannot be set to exempted Page 22

24 Times when information can be sent 4. Timetable The SFTP service that can be used to send information to the TRS can receive files at any time. Over this period, files can be sent containing records with the information BME markets need to perform the contracted transaction reporting. STR will consider any file received after 8 p.m. as received next day. STR generates reports at this time. Timetable for receipt of information The TRS will generate from 17:00 on D+1, a report on the status of the records that must be sent to the transaction report for D. The process to generate the transaction report will commence as from 20:00 hours on D+1. At the end of this process, the TRS will provide information on the final status of each transaction in terms of whether it has been sent in the XML file to the supervisor, or if it was incomplete or incorrectly reported, in which case information on the reason for it not being incorporated in the XML file will be given. General circuit 07:30 Opening of member-trs information channels. After 18:00 At 17:00 the process to the issuance of information from TRS on status of transactions and their incorporation in the transaction report will start. 20:00 Closure of member-trs information channels. After 20:00 Generation of transaction report records for delivery to the CNMV, BME ARM and member. Generation of the report on no notified transactions and reason for not being notified. Page 23

25 Technical aspects of inbound files 5. Notifications Files are coded in UTF8 formal with a variable string length depending on the record type; fields are delimited using the character ";". Text fields (Char) will be delimited by double quotation marks. Within any field, double quotation mark is not allowed. The following data types are specified hereon to determine the maximum values allowed: Decimal Date Datetime Char Int32 Numeric fields where the. (dot) character is used to separate decimals. For negative figures, the - sign is included to the left of the first significant digit. The specified number of significant digits cannot be exceeded. Fields to specify dates and with the format YYYY-MM-DD Used to specify dates and time, using the ISO 8601 format YYYY-MM- DDThh:mm:ss.ffffffZ Text fields that must be completed with a maximum of the specified number of characters. It is not mandatory to fulfil this field until maximum length is reached. Integer number of 32 bits. Nomenclature of the files sent by members to the TRS The names of files containing the records that a member wants to send to the TRS will comprise the following: INB_LEI1_LEI2_TYPE_YYYMMDD_SEQ.EXT_MD5 INB(3) INBOUND. Indicates an inbound file. LEI1(20) LEI of the member sending the file LEI2(20) LEI of the member on behalf of which the file is being sent. Can be the same as LEI1 if the members are one and the same. TYPE(4) File type: o TR: for those files sent in period 1 (until D+8 with regard to execution date) o ORTR: files with this name will be used not only for TR purposes but also regarding ORK (Order Record Keeping) o FR: files sent to STR upon the competent authority information requirement (see competent authority demand file) YYYYMMDD(8) File communication date. SEQ(3) Three-digit sequence. Example: 001 EXT(3) File extension: DAT MD5(33) The file's MD5 hash will be included after the extension to be able to validate that the file is the same at the source and destination. Page 24

26 This file will contain the various types of records defined in this document. The file is encrypted. As a general rule, any deliveries by a member will be accepted. Deliveries are additive (except when there is a syntax error in the content of the file, in which case the entire file will be rejected). Deregistration process is described in the section on RI and RO record types. Multiple file uploads are allowed: ACTION field used to distinguish whether it involved a REGISTRATION (ACTION field= A and the record does not exist in the TRS), MODIFICATION (ACTION field= A and record exists in the TRS), DEREGISTRATION (ACTION field= B ). Any change that is not cumulative to records associated with a single identifier (CT record) will involve sending a deregistration record and various registration records with the new holders. Inbound files to the TRS will be processed in the order they are received. Members are responsible for sending them in the correct order. Each file uploaded to the TRS will simultaneously generate a response file stating that the file was uploaded correctly pending consolidation (cross-check of member's information + market information and ESMA/BME validations) Nomenclature and format of the files sent by the TRS to members The names of files containing the records of information on TR status that the TRS wants to send to a member will comprise the following: OUT_LEI1_LEI2_TYPE_YYYMMDD_SEQ.EXT_MD5 OUT(3) OUTBOUND. Indicates an outbound file. LEI1(20) LEI of the member sending the file LEI2(20) LEI of the member on behalf of which the file is being sent. Can be the same as LEI1 if the members are one and the same. TYPE(4) File type: TR: for those files sent in period 1 (until D+8 with regard to execution date) ORTR: files with this name will be used not only for TR purposes but also regarding ORK (Order Record Keeping). RC: response to additional sending files. Files sent in period 2 (D+10 on forward with regard to execution date). FQ: response to files sent upon the competent authority information requirement. CPRE: result from the Preliminary Consolidation carried out at 17h in D+1. CFIN: result from the Final Consolidation carried out at 20h in D+1. TRA: Final STR file sent to competent authority (CNMV), also sent to the member. TRCA: Competent authority response (CNMV) regarding the information of files TR. FRCA: CNMV response to information requirements (files FR sent to STR). YYYYMMDD(8) File generation date. SEQ(3) Three-digit sequence. Example: 001 EXT(3) File extension. Page 25

27 MD5(33) The file's MD5 hash will be included after the extension to be able to validate that the file is the same at the source and destination. These files contain two records types informing the member of the status of the contents of the files that the TRS has processed. The file is encrypted. TRS sends response files to the member in a number of cases: 1.- Result of the validation of syntax and content of TP, RO-RI records. This validation is performed after each file submission to TRS. 2.- Result of BME consolidation process. 3.- Result of validations by CNMV. FI records This type of record contains information sent by the TRS to members on the TRS's treatment of a file sent by a member, indicating the GLOBAL status of the file. Details of the possible validation errors are given in the VA record. Its structure is as follows: No. Field Information Description 1 TypeReg FI Record type 2 Source BME, NCA Origin of response information. BME or regulatory authority (CNMV) 3 CreDT Date sent 4 ExctgPty LEI Market LEI 5 FileName Name of file sent 6 Sts Status (Table 1) 7 TtlNbOfRcrds Total registers 8 stactp Number of accepted transactions 9 stpdng Number of pending transactions 10 strjct Number of rejected transactions 11 strcvd Number of received transactions Table 1: StatusCode Name Definition ACPT Accepted Report has been accepted CRPT Corrupted file The file is corrupt INCF Incorrect File name is incorrect filename PART Partially accepted Report has been partially accepted. Some records have been accepted and others not. RJCT Rejected The entire report has been rejected. For example: - Sts= ACPT indicates that file FileName was fully accepted. Page 26