REMIT EMIR Reportable records of transactions in standardised wholesale energy transactions ('standard reporting form') Details to be reported to trade repositories Field No Field Identifier Description TRUM Number Format to be used Example ACER Comments Comments to the consultation Field Details to be reported Format Parties to the contract Parties to the contract 1 Reporting time stamp Date and time of reporting indicating time zone 1.1 Reporting timestamp Date and time of reporting to the trade ISO 8601 date format / UTC time format (ISO 8601 date format / UTC time format). repository.

The market participant or counterparty on behalf of whom the record of transaction is 2 ID of the market participant The market participant on behalf of whom the Field No 1, Seite 14, ID of the Legal Entity Identifier (LEI) (20 alphanumerical 12345678901234500000 reported shall be identified by a unique code. The code supplied should comply with theIt is clear to us that the foreseen field offers the 1.2 Counterparty ID Unique code identifying the reporting Legal Entity Identifier (LEI) (20 alphanumerical record of transaction is reported shall be market participant or digits), ACER code (xx alphanumerical digits), standard format of the code type used. largest flexibility possible for market counterparty. In case of an individual, a client digits), interim entity identifier (20 The field should contain the LEI, BIC, EIC, GS1/GLN or ACER registration code of the identified by a unique code. counterparty BIC (11 alphanumerical digits), or GS1/GLN market participant on whose behalf the transaction report is being made. The type of participants to choose the ID type, which fits code shall be used. alphanumerical digits), BIC (11 alphanumerical code used should be the same as the code that has been registered with ACER during code (13 alphanumerical digits). the participant registration process. the best to their needs. Still it would be wishful, digits) or a client code (50 alphanumerical If a third-party reporting agent is used to submit the transaction report on behalf of the if ACER would prioritise the use of such Ids. digits). market participants, please ensure that this field identifies the market participant and not the reporting agent. Such a prioritisation could look like: If there is The Legal Entity Identifier (LEI) code must comply with the following format: - A unique 20-character alphanumeric code, defined in the ISO 17442 standard a LEI available, please use the LEI. If not then The Bank Identification Code (BIC) code must comply with the following format: - A ujnique 11 character alphanumeric code, defined in the ISO 9362 standard a BIC should be used. If this is not available, - Identifies the following fields: please use the EIC code etc. o 4 character Institution / bank code o 2 character country code o 2 character location code o 3 character branch /office code The Energy Identification Coding (EIC) scheme, as defined by the following format: - A unique code containing alphanumeric values and hyphen separators up to a maximum of 16 characters - Identifies the following fields: o 2 character number identifying the issuing office o 1 character identifying the object type the code represents o 12 digits, uppercase characters or hyphen symbols allocated by the issuing office to identify the object o 1 character validity code based on the previous 15 characters The Global Location Number (GLN) is the (GS1) identification key for locations, as defined by the following format - A unique code containing 13 characters, with 12 identification characters and 1 check character - The code identifies the following fields: o GS1 company prefix (varying between 6 and 10 characters) o Location Reference The ACER code is defined by the following format: - A unique code containing 12 characters A participant must supply only one of these codes and it must be the same code as supplied to ACER upon registration or the ACER code provided by ACER at registration. In case of trades executed on Exchanges, this may be the ID of the Clearing House or CCP.

3 Type of code used Indicate the type of code (LEI, BIC, EIC, Field No 2, Seite 15, Type of L=LEI A This field shall identify the type of code used GS1/GLN or ACER registration code). code used in Field no 1 A=ACER code for market participant identification (LEI, BIC, B=BIC EIC, GS1/GLN or ACER registration code). E=EIC The code indicated must be identified in the G=GS1/GLN market participant´s registration form. The type defined in this field must align with the code value supplied in the field “ID of the market participant”. 4 Trader Login Username for The Login username of the trader or trading Field No 3, Seite 16, Trader Up to 52 alphanumerical digits 1234567890abcdefghi This field shall contain the Login username of Our understanding is that this field will be filled the market participant account as specified by the technical system of ID as identified by the the trader or trading account as specified by only by trading venues only for such the organised market place. organised market place the technical system of the organized market transactions executed and reported by them. place, trade matching system or trade Such usernames are personal data and should reporting system. be processed in accordance with the European ACER anticipates the username to be Data Protection Supervisor. anonymised, but consistently applied across the organized market place. ACER expects that centrally executed trade data is sourced directly from organized market places or third parties acting on their behalf. ACER accepts that the username cannot be consistently applied across multiple organized market places or venues, as user names are likely to be assigned by the organized market place or venue.

Field No 4, Seite 16, Trader Up to 52 alphanumerical digits 1234567890abcdefghi This field shall provide identification like Our understanding is that this field will be filled ID for the market participant username, name or registration number or the only by market participants only for OTC or counterparty trader as specified by the market participant or transactions, which are closed and reported by counterparty. themselves. 5 ID of the other market Unique identifier for the other market Field No 5, Seite 16, ID of the Up to 52 alphanumerical digits 1234567890abcdefghi This field shall identify the other market It is clear to us that the foreseen field offers the 1.3 ID of the other counterparty Unique code identifying the other counterparty Legal Entity Identifier (LEI) (20 alphanumerical participant participant of the contract. other market participant or participant or counterparty of the contract by a largest flexibility possible for market of the contract. This field shall be filled form digits), interim entity identifier (20 counterparty unique code (LEI, BIC, EIC, GS1/GLN or participants to choose the ID type, which fits the perspective of the reporting counterparty. In alphanumerical digits), BIC (11 alphanumerical ACER registration code of the market the best to their needs. Still it would be wishful, case of an individual, a client code shall be digits) or a client code (50 alphanumerical participant). The type of code used shall be the if ACER would prioritise the use of such Ids. used. digits). same as the code that has beed registered Such a prioritisation could look like: If there is with ACER during the participnat registration a LEI available, please use the LEI. If not then process. a BIC should be used. If this is not available, If the transaction was executed on an energy please use the EIC code etc. exchange, this may be the ID of the Clearing House or CCP. See the details under “ID of market participant” for the field detail specifics.

1.4 Name of the counterparty Corporate name of the reporting counterparty. 100 alphanumerical digits or blank in case of This field can be left blank in case the coverage by Legal Entity Identifier (LEI). counterparty ID already contains this information. 1.5 Domicile of the Information on the registered office, consisting 500 alphanumerical digits or blank in case of counterparty of full address, city and country of the reporting coverage by Legal Entity Identifier (LEI). counterparty. This field can be left blank in case the counterparty ID already contains this information. 1.6 Corporate sector fo the Nature of the reporting counterparty´s Taxonomy: counterparty company activities (bank, insurance company, A = Assurance undertaking authorised in etc.). This field can be left blank in case the accordance with Directive 2002/83/EC; counterparty ID already contains this C = Credit Institution authorized in accordance information. with Directive 2006/42/EC; F = Investment firm in accordance with Directive 2004/39/EC; I = Insurance undertaking authorized in accordance with Directive 73/239/EEC; L = Alternative investment fund managed by AIFMs authorized or registered in accordance withDirective 2011/61/EU; O = Institution for occupational retirement provision within the meaning of Article 6(a) of Directive 2003/41/EC; R = Reinsurance undertaking authorized in accordance with Directive 2005/68/EC; U = UCITS and its management company, authorized in accordance with Directive 2009/65/EC; or Blank in case of coverage by Legal Entity Identifier (LEI) or in case of non-financial counterparties. 1.7 Financial or non-financial Indicate if the reporting counterparty is a F= Financial Counterparty, N = Non-Financial nature of the counterparty financial or non-financial counterparty in Counterparty. accordance with points 8 and 9 of Article 2 of Regulation (EU) No 648/2012. 1.8 Broker ID In case a broker acts as intermediary for the Legal Entity Identifier (LEI) (20 alphanumerical reporting counterparty without becoming a digits), interim entity identifier (20 counterparty, the reporting counterparty shall alphanumerical digits), BIC (11 alphanumerical identify this broker by a unique code. In case of digits) or a client code (50 alphanumerical an individual, a client code shall be used. digits). 6 Type of code used Indicate the type of code (LEI, BIC, EIC, Field No 6, Seite 17, Type of L=LEI A This field shall identify the type of code used GS1/GLN or ACER registration code). code used in Field no 5 A=ACER code for identifying the other market participant or B=BIC counterparty to the transaction (LEI, BIC, EIC, E=EIC GS1/GLN or ACER registration code). The G=GS1/GLN code indicated must be identified in the market participant´s registration form. The type defined in this field must align with the code value supplied in the field “ID of the other market participant”. 7 Trader Login Username for The Login username of the trader or trading the market participant account as specified by the technical system of the organised market place. 8 Organised market place In case the market participant uses an Field No 32, Seite 23, ISO 10383 Market Identifier Code (MIC), 4 1234 or The organized market place shall be identified This field is identical with the field 2.10 of 2.10 Venue of execution The venue of execution shall be identified by a ISO 10383 Market Identifier Code (MIC), 4 identification / OTC organised market place to execute the Organised market place digits alphabetical. 1234567890abcdefrgf by a unique code (MIC). The Market Identifier EMIR. It is not clear to us, how this field should unique code for this venue. In case of a digits alphabetical. contract, this organised market place shall be identifications/OTC Where MIC code is not available: Code (MIC) must comply with the ISO 10383 be filled, if the trading venue is a non-MTF contract concluded OTC, it has to be identified Where relevant, XOFF for listed derivatives identified by a unique code. LEI should be used standard for any organized market place. plattform, as these do not have any MIC code. whether the respective instrument is admitted that are traded off-exchange or XXXX for OTC Where relevant, - A unique 4 character code assigned to the Our understanding is that XOFF would not be to trading but traded OTC or not admitted to derivatives. XOFF for products listed that are traded off- market place or venue, alphanumeric the right code, as XOFF should be used only trading and traded OTC. exchange, or characters only for listed producht, i.e. for products admitted to OTC for OTC products. - In case the MIC code is not available, the LEI be traded in regulated markets (exchanges). should be used Products traded at non-MTF plattforms are not - For products listed and that are traded off- listed products. In our point of view OTC would exchange, XOFF should be used not be the appropriate code, either, as OTC - For OTC Products OTC should be used according to EMIR means a transaction on a standard product not traded at an organsised market place. According to REMIT are Non- MTF platforms organised market places. The format of the code "OTC" is not compliant with the given format of "4 digits alphabetical". Additionally we would like to point out that it might make sense in some cases to use other codes (like the LEI) to identify the market place, which is not possible with a format of 4 digits.

9 Reporting entity ID ID of the reporting party as established with the Field No 7, Seite 17, ID of the LEI (20 alphanumerical digits) 12345678901234500000 This field shall contain the ID of the reporting 1.9 Reporting entity ID In case the reporting counterparty has Legal Entity Identifier (LEI) (20 alphanumerical reporting party´s ACER registration. reporting entity ACER code (12 alphanumerical digits) party established with the reporting party´s delegated the submission of the report to a digits), interim entity identifier (20 ACER registration. Third-party RRMs will be third party or to the other counterparty, this alphanumerical digits), BIC (11 alphanumerical listed on the ACER website. entity has to be identified in this field by a digits) or a client code (50 alphanumerical The code used for the reporting entity ID unique code. Otherwise this field shall be left digits). should be the ACER defined code assigned blank. In case of an individual, a client code when registration for becoming a RRM is shall be used, as assigned by the legal entity completed. used by the individual counterparty to execute 1.10 Clearing member ID Inth case t d the reporting counterparty is not a Legal Entity Identifier (LEI) (20 alphanumerical clearing member, ist clearing member shall be digits), interim entity identifier (20 identified in this field by a unique code. In case alphanumerical digits), BIC (11 alphanumerical of an individual, a client code, as assigned by digits) or a client code (50 alphanumerical the CCP, shall be used. digits). 10 Beneficiary Identification If the transaciton was placed on behalf of a Field No 8, Seite 17, LEI (20 alphanumerical digits) 12345678901234500000 If the beneficiary is a market participant We do not understand the meaning of 1.11 Beneficiary ID The party subject to the rights and obligations Legal Entity Identifier (LEI) (20 alphanumerical client, identification of the client. Beneficiary identification of ACER code (12 alphanumerical digits) registered under REMIT, the beneficiary following statement: "In the event the code type arising from the contract. Where the digits), interim entity identifier (20 the market participant or BIC (11alphanumerical digits) identification should be supplied as the is defined, this should also be supplied within transaction is executed via a structure, such as alphanumerical digits), BIC (11 alphanumerical counterparty referenced in GS1/GLN code (13 alphanumerical digits) identifier code of the participant as registered the data." How should this work? Could you a trust or fund, representing a number of digits) or a client code (50 alphanumerical field no 1 with ACER. give us an example, please. Further, we do beneficiaries, the beneficiary should be digits). In the event the code type is defined, this not understand the intention of following identified as that structure. If the beneficiary of should also be supplied within the data. If the statement: " If the beneficiary of the contract is the contract is not a counterparty to this beneficiary of the contract is not a counterparty not a counterparty to the contract, the contract, the reporting counterparty has to to the contract, the beneficiary shall be beneficiary shall be identified by a unique identify this beneficiary by a unique code or, in identified by a unique code. code." In which way besides a unique code case of individuals, by a client code as could be the beneficiary identified? How assigned by the legal entity used by the should this field be filled, when the reporting individual. market participant is the same with the beneficiary. Should the field remain blank in this case or should this be field by the ID of the reporting market participant? Please note that under EMIR (according to ESMA Q&As) this field is filled in this case with the ID of the reporting market participant and that in this sense it would make sense to harmonise the field contents between the two transaction reporting regimes.

Field No 9, Seite 18, Type of L=LEI L This field shall identify the type of code used We believe that there is a typing error in the code used in field no 8 A=ACER code for beneficiary identification (LEI, BIC, EIC, following statement: "The type of code defined B=BIC GS1/GLN or ACER registration code). The in this field must align with the code value E=EIC code indicated must be identified in the market supplied in the field “ID of the market G=GS1/GLN participant´s registration form. participant”." In our point of view "ID of the The type of code defined in this field must market participant" should read "Beneficiary align with the code value supplied in the field identification" “ID of the market participant”. 11 Trading capacity Identifies whether the transaction was Field No 10, Seite 18, P=Principal P This field identifies whether the transaction was The ACER comments to this field are not clear 1.12 Trading capacity Identifies whether the reporting counterparty P=Principal, A=Agent executed on own account (on own behalf or Trading capacity of the A=Agent executed on own account (on own behalf or behalf to us. Especially following statement should be has concluded the contract as principal on own behalf of a client) orfor the account of, and on market participant or of a client) or for the account of, and on behalf of, checked again: "When Trading Capacity is 'P', account (on own behalf or behalf of a client) or behalf of, a client. counterparty in field no 1 a client. ACER will apply the below listed admitted the value for Beneficiary is not applicable". We as agent for the account of and on behalf of a values for reasons of harmonization with reporting understand that this field should be left blank, client. of transactions under EU financial market when the Beneficiary is identical to the legislation. reporting market participant. Please note that The table below indicates which values to assign under EMIR (according to ESMA Q&As) this for trading capacity and under what field is filled in this case with the ID of the circumsances. reporting market participant and that in this Principal (P): When the participant executing the sense it would make sense to harmonise the transaction is doing so on their own behalf field contents between the two transaction Agent (A): When a participant has executed a reporting regimes. transaction on behalf of another participant For all trading capacities, the value for “ID of market participant” should be identified as the LEI, BIC, EIC, GS1/GLN or ACER registration code of the participant performing the trading. - When Trading Capacity is ‘P’ (Principal) the value for Beneficiary is not applicable - When Trading Capacity is ‘A’ (Agent) , the ID of Market Participant value will be the LEI, BIC, EIC, GS1/GLN or ACER registration code of the trading firm and the Beneficiary value will be the LEI, BIC, EIC, GS1/GLN or ACER registration 12 Buy / sell indicator Identifies whether the contract was a buy or Field no 11, Seite 19, B=Buy B This field must contain “buy” or “sell” to show 1.13 Counterparty side Identifies whether the contract was a buy or B=Buyer, S=Seller sell for the market participant identified in field Buy/Sell Indicator S=Sell whether the transaction was a buy or a sell sell. In the case of an interest rate derivative 2. from the perspective of the reporting market contract, the buy side will represent the payer participant or counterparty as indicated in filed of leg 1 and the sell side will be the payer of no 1 or, in the case of an agent transaction, of leg 2. the client. When reporting an order transaction, there should always be a value to indicate the intention of the market participant to buy or sell. When reporting a trade transaction, the buy/sell indicator is used to identify which side of the trade the values relate to. Field no 12, Seite 19, I=Initiator I This field shall identify whether the market Our understanding is that this field is only Initiator/Aggressor A=Aggressor participant was the initiator or aggressor in relevant for transactions executed throuhg case of trades executed through brokers. trading venues and is going to be filled and reported only by them. 1.14 Contract with non-EEA Indicates whether the counterparty is domiciled Y=Yes, N=No counterparty outside the EEA. 1.15 Directly linked to Information on whether the contract is Y=Yes, N=No commercial activity or objectively measurable as directly linked to the treasury financing reporting counterparty´s commercial or treasury financing activity, as referred to in Article 10(3) of Regulation (EU) No 648/2012. 1.16 Clearing threshold Information on whether the reporting Y=Above, N=Below counterparty is above the clearing threshold as referred to in Article 10(2) of Regulation (EU) No 648/2012. This field shall be left blank in case the reporting counterparty is a financial counterparty, as referred to in point 8 of Article 2 Regulation (EU) No 648/2012. 1.17 Mark to market value of Mark to market valuation of the contract, or Up to 20 numerical digits in the format contract mark to model valuation where applicable xxxx,yyyyy. under Article 11(2) of Regulation (EU) No 648/2012. 1.18 Currency of the markt to The currency used for the mark to market ISO 4217 Currency Code, 3 alphabetical digits. market value of the valuation of the contract or markt to model contract valuation where applicable under Article 11(2) of Regulation (EU) No 648/2012. 1.19 Valuation date Date of the last mark to market or mark to ISO 8601 date format. model valuation. 1.20 Valuation time Time of the last mark to market or mark to UTC time format. model valuation. 1.21 Valation type Indicate whether valuation was performed M=mark to market / O=markt to model. mark to market or mark to model. 1.22 Collateralisation Whether collateralisation was performed. U=uncollateralised, PC=partially collateralised, OC=one way collateralised or FC=fully collateralised. 1.23 Collateral portfolio Whether the collateralisation was performed Y=Yes, N=No on a portfolio basis. Portfolio means the collateral calculated on the basis of net positions resulting from a set of contracts, rather than per trade. 1.24 Collateral portfolio code If collateral is reported on a portfolio basis, the Up to 10 numerical digits. portfolio should be identified by a unique code determined by the reporting counterparty.

1.25 Value of the collateral Value of the collateral posted by the reporting Specify the value the total amount of collateral counterparty to the other counterparty. Where posted; up to 20 numerical digits in the format collateral is posted on a portfolio basis, this xxxx,yyyyy. field should include the value of all collateral posted for the porfolio. 1.26 Currency of the collateral Specify the value of the collateral for field 25. Specify the currency of field 25; ISO 4217 value Currency Code, alphabetical digits. If a Product ID is reported and contains the relevant product information below, this Section 2a - Contract Contract Type information is not required to be reported. type 13 Taxonomy The taxonomy used for describing the 2.1 Taxonomy used The contract shall be identified by using a Identify the taxonomy used: classification of the reported contract. product identifier. U = Product identifier [endorsed in Europe] I = ISIN/AII + CFI E = Interim taxonomy 14 Taxonomy type The taxonomy type used to report the record of transactions. 15 Product ID The contract shall be identified by using a 2.2 Product ID 1 The contract shall be identified by using a For taxonomy = U unique product identifier. product identifier. Product Identifier (UPI), to be defined For taxonomy = I: ISIN or AII, 12 digits alphanumerical code For taxonomy = E: Derivative class: CO = Commodity CR = Credit CU = Currency EQ = Equity IR = Interest Rate OT = Other Field No 24, Seite 20, IND=Intraday or Within day FW This field shall identify the contract type, e.g. 2.3 Product ID 2 The contract shall be identified by using a For taxonomy = U: Blank Contract Type DAH=Day Ahead whether it is an intraday or within day contract, product identifier. FW=Forward style contract a day ahead contract or a forward style For taxonomy = I: FU=Future style contract contract. CFI, 6 characters alphabetical code OPT= Option style contract SPI=Spot contracts that settle against an index For taxonomy = E: FWI=Forward contracts that settle against an Derivative type: index CD= Contracts for difference FUI=Future contracts that settle against an FR= Forward rate agreements index FU= Futures OPI=Option on a physical Forward that settles FW=Forwards OP=Option against an index SW=Swap SW=Financial exchange of contract cash flows OT= Other SP=Spread combination against two or more contract OT=Other

16 Product code type The code type used to report the record of transactions. 17 Underlying The underlying shall be identified by using a 2.4 Underlying The underlying shall be identified by using a ISIN (12 alphanumerical digits); unique identifier for this underlying. In case of unique identifier for this underlying. In case of LEI (20 alphanumerical digits); baskets or indices, an indication for this baske baskets or indices, an indication for this basket Interim entity identifier (20 alphanumerical or index shall be used where a unique or index shall be used where a unique digits); identifier does not exist. identifier does not exist. UPI (to be defined); B = Basket; I = Index. 18 Underlying code type The code type used to report the record of transactions. 19 Currency The currency of the notional amount 2.5 Notional currency 1 The currency of the notional amount. In the ISO 4217 Currency Code, 3 alphabetical digits. case of an interest rate derivative contract, this will be the notional currency of leg 1. 2.6 Notional currency 2 The currency of the notional amount. In the ISO 4217 Currency Code, 3 alphabetical digits. case of an interest rate derivative contract, this will be the notional currency of leg 2. 2.7 Deliverable currency The currency to be delivered. ISO 4217 Currency Code, 3 alphabetical digits.

20 Master agreement type If the contract is not admitted to trading at an 2.24 Master Agreement type Reference to the name of the relevant master Free Text, field of up to 50 characters, organised market, reference to any master agreement, if used for the reported contract identifying the name of the Master Agreement agreement (e.g. ISDA Master Agreement, (e.g. ISDA Master Agreement; Master Power used, if any. Master Power Purchase and Sale Agreement, Purchase and Sale Agreement; International European Master Agreement etc.) ForEx Master Agreement; European Master Agreement or any local Master Agreements). 21 Master agreement version Reference to the date of the master agreement 2.25 Master Agreement version Reference to the year of the master agreement Year, xxxx. version, if any (e.g. 1992, 2002, …) version used for the reported trade, if applicable (e.g. 1992, 2002, etc.). 22 Taxonomy of the Taxonomy code of the underlying instrument or Underlying instruments. Section 2b - Details on Details of the transaction the transaction Field No 23, Seite 20, Up to 52 alphanumerical digits. 123454637 This field shall identify the contract by using a It is not clear to us, what this field relates to the Contract ID unique identifier. field "Transaction identification" (Field Nr. 25 For standardized contract, the contract of the Implementing Acts and Field Nr. 28 of identifier shall be provided by the organized the TRUM 'Transaction ID'). market place or execution venue. 23 Transation time stamp The day and time the transaction was Field no 26, Seite 21, ISO 8601 date format using UTC time format. 2014-01-29T10:35:56.000+00:00 This field shall contain the date and time of the execution of the 2.19 Execution timestamp As defined in Article 1(2). ISO 8601 date format / UTC time format. transaction, indicating time zone (ISO 8601 date format in UTC executed, modified or cancelled, indicating Transaction time stamp Or time zone). The values supplied should adhere to the following time zone (ISO 8601 date format / UTC time 2014-01-29T10:35:56.000Z format: format). - YYYY[-MM[-DD[Thh[:mm[:ss]]][TZD]]]] For example to represent 5 August 2013 at 10:22:41 and 69 milliseconds, the following value would need to be supplied. - 2013-08-05T10:22:41.069Z Where: - T is used to separate between the date and the time - Z is used to identify that the date is in UTC (Coordinated Universal Time (a.k.a “zulu” time)) The timestamp would need to be adjusted to accommodate for any time zone differences to align with the UTC time zone. Time stamps concerning standardized transactions will relate to the event, referred to in field Action Type. The time stamp of a standardized trade as of when it is entered into the system of record as operated by the market participant is of no relevance for ACER. Market participants shall ensure that ACER receives the trading time information as in ISO 8601 Time Format in UTC time, YYY- MM-DD HH:MM:SS.sssZ, and shall contact their RRM(s) to see if this requirement is met. Where the ‘seconds’ element of the trading time is unknown or not captured, please use a default of ‘00’ and where the ‘milliseconds’ element of the timestamp is unknown or not captured, the default of ‘000’ should be used. However, market participants should strive to capture this information correctly. Where reporting firms are unable to meet the requirement to populate the trading time field with the actual trading time, and instead give the time at which the trade is entered into their system (when this i not materially different from the actual trading time), market participants should make best efforts to minimize any discrepancy between the trading time and the booking time.

Field No 27, Seite 21, This field shall contain the name of the Our understanding is that this field considers Contract name contract as identified by the organised market only transactions traded at a trading venue and place. that it will be filled and reported only by them. In case ACER foresees market participants to fill this field for OTC transactions, as well, we would like for a clear guidance, which name should be used, as standard products are named differently from one trading venue to the other.

24 Transaction type Indicator that signifies whether the transaction is an energy commodity contract or a derivative, e.g. a physical or financial forward, future or option. 25 Transaction identification Unique identifier for a transaction as assigned Field No 28, Seite 22, Up to 52 alphanumerical digits. 1234567890abcdefrgf This field shall contain a unique identifier for a It is not clear to us, what this field relates to the 2.8 Trade ID A Unique Trade ID agreed at the European Up to 52 alphanumerical digits. by the organised market place of execution, or Transaction ID transaction as assigned by the organized field "Contract ID" (Field Nr. 23 of the TRUM). level, which is provided by the reporting by the two market participants in case of purely market place of execution, or by the two counterparty. If there is no unique trade ID in bilateral contracts. market participants in case of purely bilateral place, a unique code should be generated and contracts. agreed with the other counterparty. The transaction identifier is a representation of the identifier uniquely used by the organized market place when the transaction is represented to the market participant. The value populated in this field should be compliant with the data type fields and should allow ACER to identify the transaction to a market participant which can be reconciled with their records. 26 Linked Transaction ID Where a transaction is linked to another Field No 29, Seite 22, Linked Up to 52 alphanumerical digits. 1234567890abcdefrgf Where a transaction is linked to another Our understanding is that this field considers transaction by a trading venue, a referencing transaction ID transaction by a trading venue, a referencing only transactions linked together by trading ID is required by the trading venue to link the ID is required by the trading venue to link the venues (i.e. spread trades) and that it will be transaction(s). transactions. filled and reported only by them. The linked transaction identifier must identify the transaction and/or execution transactions that are associated with the execution. Field No 30, Seite 22, Linked Up to 52 alphanumerical digits. 1234567890abcdefrgf This field shall identify the order that is Our understanding is that this field will be filled order ID associated with the transaction referenced in and reported only by trading venues. This Field field no 19. must be referenced to the field no. 29.

27 Transaction reference A unique identification number for the Field No 31, Seite 22, Up to 52 alphanumerical digits. 1234567890abcdefrgf This field shall contain a unique identification Under EMIR this field is filled with the 2.9 Transaction reference A unique identification number for the An alphanumerical field up to 40 characters. number transaction provided by the reporting entity or a Transaction reference number for the transaction provided by the Transaction Reference Number of the number transaction provided by the reporting entity or a third party on its behalf. number reporting entity or a third party on ist behalf. transactions reported under MiFID (a kind of third party on its behalf. The format and content of the transaction MiFID UTI). As far as we understand, ACER reference number is at the discretion of the has a completely different understanding of reporting entity. this field. We would like to ask for a harmonisation of the contents of this field between the two reporting regimes (EMIR and REMIT). 2.11 Compression Identify whether the contract results from a Y = if the contract results from compression; compression exercise. N=if the contract does not result from compression. 28 Voice-Brokered Indicates whether the transaction was voice Y=YES Y This field shall indicate whether the Why is this extra field necessary? This brokered, "Y" if it was, left blank if it was not. transaction was voice-brokered, i.e. "Y"if it information can be captured with an was, left blank if it was not. appropriate code under the Field No 32" Organised market place identifications/OTC" (Field Nr. 8 of the Implementing Acts). 29 Price The price per unit or derivative excluding, Field No 34, Seite 23, Price Up to 20 numerical digits in the format 53.45 This field shall include the price per unit. The 2.12 Price/rate The price per derivative excluding, where Up to 20 numerical digits in the format where applicable, commission and accrued xxxx,yyyy. price should be represented as a decimal applicable, commission and accrued interest. xxxx,yyyyy. interest. value, identifying the price of the unit. The value should be provided as a value as expressed by the market place.

Field No 35, Seite 35, Fixing Up to 52 alphanumerical digits. Heren NBP day-ahead This field shall contain information concerning index the fixing index that sets the price for the contract, such Heren TTF Day-ahead, etc., if applicable.

Our understanding is that this field do not make sense for standardised transactions. A reference price is only be used either for transactions with a price formula, which are Field No 36, Seite 24, Index Up to 20 numerical digits in the format 52.45 This field shall contain the value fo the fixing non-standards or for futures with a fixed price, value xxxx,yyyy. index. which refer to another price and which are anyway reported under EMIR. 30 Price notation The manner in which the price is expressed. Field No 37, Seite 24, Price ISO 4217 Currency Code, 3 asphabetical digits EUR This field must contain the ISO standard 2.13 Price notation The manner in which the price is expressed. E.g. ISO 4217 Currency Code, 3 alphabetical currency currency code in which the unit price is digits, percentage. expressed. Currency needs to be expressed in ISO standard currency code and units in SI standar units (e.g. EUR per MWh, or in the case of options, e.g. EUR per month, EUR per year.) 31 Notional amount Original value of the contract. Field No 38, Seite 24, Up to 20 numerical digits in the format 53450.00 This field shall specify the value of the 2.14 Notional amount Original value of the contract. Up to 20 numerical digits in the format Notional amount xxxx,yyyy. contract. The value should populate the actual xxxx,yyyyy. value of the contract for any contract for which the price and quantity is fixed, for example the purchase for L tradable contract, each of them for X quantity for Y Euros, the value would L*X*Y. Field No 39, Seite 24, ISO 4217 Currency Code, 3 asphabetical digits EUR This field shall identify the currency of the Notional currency notional amount. 32 Price multiplier The number of units of a financial instrument Field No 40, Seite 25, Up to 20 numerical digits in the format 100.00 This field shall specify the number of units Our understanding is following: Company X is 2.15 Price multiplier The number of units of the financial instrument Up to 10 numerical digits. which are contained in a trading lot; for Quantity xxxx,yyyy. included in the contract. The number of units buying 5 lots of a 10-MW Product. This field is which are contained in a trading lot; for example, the number of derivatives must be represented as a whole number filled with the figure: 10 example, the number of derivatives represented by one contract. without rounding. represented by one contract. 33 Quantity Total number of units included in the contract. Field No 41, Seite 25, Total Up to 20 numerical digits in the format 1000.00 This field shall identify the total number of Our understanding is following: Company X is 2.16 Quantity Number of contracts included in the report, Up to 10 numerical digits. notional contract quantity xxxx,yyyy. units of the wholesale energy product. buying 5 lots of a 10-MW Product. This field is where more than one derivative contract is filled with the figure: 50 (5*10=50). reported.

2.17 Up-front payment Amount of any up-front payment the reporting Up to 10 numerical digits in the format counterparty made or received. xxxx,yyyyy for payments made by the reporting counterparty and in the format xxxx,yyyyy for payments received by the reporting counterparty. 34 Quantity unit The unit of measurement used. Field No 42, Seite 25, Up to 10 digits in text format MWh This field will identify the unit of measurement Quantity unit used to represent the quantity, e.g. MWh.

35 Delivery type Whether the contract is settled physically or in Field No 43, Seite 25, P=Physical P This field identifies whether the contract is 2.18 Delivery type Indicates whether the contract is settled C=Cash, P=Physical, O=Optional for cash. Settlement method C=Cash settled physically or in financially upon delivery physically or in cash. counterparty. O=Optional for counterparty or it is optional for one of the parties. The values which can be used to represent this are: - P for physically settled - C for cash settled - O if optional for counterparty 36 Effective date Date when obligations under the contract 2.20 Effective date Date when obligations under the contract ISO 8601 date format. come into effect. come into effect. 37 Maturity date Original date of expiry of the reported contract. Field No 44, Seite 25, ISO 8601 date format 2014-01-29 This field represents the original date of expiry 2.21 Maturity date Original date of expiry of the reported contract. ISO 8601 date format. An early termination shall not be reported in Maturity Date of the reported contract. An early termination An early termination shall not be reported in this field. shall not be reported in this field (ISO 8601 this field. format using UTC time zone). 38 Termination date Termination date of the reported contract. If Field No 45, Seite 26, ISO 8601 date format 2014-01-29 This field represents the termination date of 2.22 Termination date Termination date of the reported contract. If ISO 8601 date format. not different from maturity date, this field shall Termination date the reported contract. If not different from not different from maturity date, this field shall be left blank. maturity date, this field shall be left blank (ISO be left blank. 8601 format using UTC time zone). 39 Exercise date The date an option is exercised. Field No 48, Seite 27, Option ISO 8601 date format Example:1 This field specifies the date or dates an option exercise date 29/01/2014 is exercised. If more than one, multiple fields Example: 2 may be used. 29/01/2014 28/02/2014 31/03/2014 40 Settlement date Date of the settlement of the underlying. 2.23 Date of Settlement Date of settlement of the underlying. If more ISO 8601 date format. than one, further fields may be used (e.g. 23A, 23B, 23C, etc.). Section 2d - Clearing 2.28 Clearing Obligation Indicates, whether the reported contract is Y=Yes, N=No subject to the clearing obligation under Regulation (EU) No 648/2012. 2.29 Cleared Indicates, whether clearing has taken place. Y=Yes, N=No 2.30 Clearing timestamp Time and date when clearing took place. ISO 8601 date format / UTC time format. 2.31 CCP In case of a contract that has been cleared, the Legal Entity Identifier (LEI) (20 alphanumerical unique code for the CCP that has cleared the digits), interim entity identifier (20 contract. alphanumerical digits), BIC (11 alphanumerical digits) or a client code (50 alphanumerical digits). 2.32 Intragroup Indicates whether the contract was entered Indicates whether the contract was entered into as an intragroup transaction, defined in into as an intragroup transaction, defined in Article 3 of Regulation (EU) No 648/2012. Article 3 of Regulation (EU) No 648/2012. Section e - Interest Rates 2.33 Fixed rate of leg 1 An indication of the fixed rate leg 1 used, if Numerical digits in the format xxxx,yyyyy. applicable. 2.34 Fixed rate of leg 2 An indication of the fixed rate leg 2 used, if Numerical digits in the format xxxx,yyyyy. applicable. 2.35 Fixed rate day count The actual number of days in the relevant fixed Actual/365, 30B/360 or Other. rate payer calculation period, if applicable.

2.36 Fixed leg payment Frequency of payments for the fixed rate leg, if An integer multiplier of a time period frequency applicable. describing how often the counterparties exchange payments, e.g. 10D, 3M, 5Y. 2.37 Floating rate payment Frequency of payments for the floating rate leg, An integer multiplier of a time period frequency if applicable. describing how often the counterparties exchange payments, e.g. 10D, 3M, 5Y. 2.38 Floating rate reset Frequency of floating rate leg resets, if D=An integer multiplier of a time period frequency applicable. describing how often the counterparties exchange payments, e.g. 10D, 3M, 5Y. 2.39 Floating rate of leg 1 An indication of the interest rates used which The name of the floating rate index, e.g. 3M are reset at predetermined intervals by Euribor. reference to a market reference rate, if applicable. 2.40 Floating rate of leg 2 An indication of the interest rates used which The name of the floating rate index, e.g. 3M are reset at predetermined intervals by Euribor. reference to a market reference rate, if applicable. if a UPI is reported and contains all the if a UPI is reported and contains all the information below, this is not required to be information below, this is not required to be reported unless to be reported according to reported unless to be reported according to Section 2g - Regulation (EU) No 1227/2011 of the Regulation (EU) No 1227/2011 of the Commodities European Parliament and of the Council European Parliament and of the Council General 2.45 Commodity base Indicates the type of commodity underlying the AG = Agricultural contract. EN = Energy FR = Freights ME = Metals IN = Index EV = Environmental EX = Exotic Field No 25, Seite 20, Energy G=Gas G The energy commodity shall be identified as Why is this field necessary? Are the fields 13- 2.46 Commodity details Details of the particular commodity beyond Agricultural Commodity E=Electricity electricity € or gas (G). 17 of the implenting acts not enough to gather field 45. GO = Grains oilseeds this information? Or does TRUM not foresee DA = Dairy them anymore? LI = Livestock FO = Forestry SO = Softs Energy OI = Oil NG = Natural gas CO = Coal EL = Electricity IE = Inter-energy Metals PR = Precious NP = Non-precious Environmental WE = Weather EM = Emissions Energy Information to be reported according to Information to be reported according to Regulation (EU) No 1227/2011, if applicable Regulation (EU) No 1227/2011, if applicable If a UPI is reported and contains all the If a UPI is reported and contains all the information below, this is not required to be information below, this is not required to be Section 2h - Options reported. reported. 41 Option type Specification of whether an option is a call or a Field No 47, Seite 26, Option P=Put C Specification of whether an option is a call or a 2.55 Option type Indicates whether the contract is a call or a P=Put, C=Call. put. type C=Call put or a mixture of both. The following values put. M=Mixed should be used to represent the options types: - P for put options - C for call options - M for mixed options

42 Option style Indicates whether the option may be exercised Field No 46, Seite 26, Option A=American B This field indicates whether the option may be 2.56 Option style (exercise) Indicates whether the option may be exercised A=American, B=Bermudan, E=European, only a a fixed date (European and Asian style), Style B=Bermudan exercised only at a fixed date (European and only a a fixed date (European and Asian style), S=Asian. a series of pre-specified dates (Bermudan) or E=European Asian style), a series of pre-specified a series of pre-specified dates (Bermudan) or at any time during the life of the contract S=Asian (Bermudan) or at any time during the life of the at any time during the life of the contract (American style). O=Other contract (American style). The following values (American style). should be used to represent the option styles: - A for American style - B for Bermudan style - E for European style - S for Asian style - O for other styles

43 Strike price The strike price of an option or other wholesale Field No 49, Seite 27, Option Up to 10 numerical digits in the format 125.98 This field specifies the strike price (or exercise 2.57 Strike price (cap/floor rate) The strike price of the option. Up to 10 numerical digits in the format energy product. strike price xxxx,yyyy. price) of an option at which the option holder xxxx,yyyyy. can buy or sell the underlying commodity. The paid price is represented as per the definition in field no 25.

Delivery profile 44 Delivery point or zone EIC code(s) for the delivery point(s) or market Field no 50, Seite 27, Delivery EIC coe, 16 character alphanumeric code. 12345678-----sdf This field shall identify the delivery bidding 2.47 Delivery point or zone Delivery point(s) of market area(s). EIC code, 16 character alphanumeric code. area(s). zone zone. The delivery zone represents the actual zone of delivery for physically delivered contracts. Where possible the delivery zone should be defined as the registered delivery point of the contract, this can be in the form on the Energy Identification Code (EIC) code(s) as per the defined schema by ENTSO-E and ENTSO-G. When identifying the delivery zone, EIC Y- codes shall be used. EIC Y-codes are used to represent a specific “Area” as defined by the schema.

45 Interconnection Point Identification of the border(s) or border 2.48 Interconnection Point Identification of the border(s) or border point(s) Free text, field of up to 50 characters. point(s). of a transportation contract. 46 Load type Identification of the delivery profile (baseload, Field No 54, Seite 28, Load B = Baseload B This field is used for the identification of the In the column "Format to be used" the letter 'B' 2.49 Load type Repeatable section of fields 50-54 to identify Repeatable section of fields 50-54 to identify peak, off-peak, block hours or other) which Type P = Peak delivery profile of the contract, which is used for both Baseload and Block Hours. the product delivery profile which correspond the product delivery profile which correspond corresponds to the delivery periods of a day. O = Off Peak corresponds to the delivery periods of a day. We believe that this is a typing error. to the delivery periods of day. to the delivery periods of a day: B = Block Hours The following values are valid for the definition BL = Base Load S = Shaped of load type: PL = Peak Load D = Gas Day - B for Base Load OP = Off-Peak - O for Off Peak BH = Block Hours - P for Peak OT = Other - H for Block Hours - S for Shaped Field No 55, Seite 29, Days of WD = Weekdays AD This field shall specify the days of the week for Why is this field necessary? Standard products the week WE = Weekends the delivery period (weekdays, weekends or all are well defined by each trading venue. It AD = All days days). should be possible to get this information from the Field Nr. 23 "Contract ID".

47 Delivery Start Date and Start date and time of delivery Field No 51, Seite 28, ISO 8601 date format 2014-01-29T10:35:56+00:00 Start date and time of delivery (SIO 8601 2.50 Delivery Start Date and Start date and time of delivery. ISO 8601 date format / UTC time format. Time Delivery start date and time format using UTC time zone) will represent the Time first period of time that the participant is responsible for delivering the product in accordance with the contract. 48 Delivery End Date and End date and time of delivery Field No 52, Seite 28, ISO 8601 date format 2014-01-29T10:35:56+00:00 End date and time of delivery (ISO 8601 format 2.51 Delivery End Date and End date and time of delivery. ISO 8601 date format / UTC time format. Time Delivery end date and time using UTC time zone) will represent the final Time period of time that the participant is responsible for delivering the product in accordance with the contract. Field No 53, Seite 28, HH = Half Hour M This field shall specify the duration of the Why is this field necessary? Products with an Duration H = Hour delivery period. interval of a quarter of an hour should be D = Day foreseen. W = Week M = Month Q = Quarter S = Season Y = Annual Field No 56, Seite 29, Load ISO 8601 date format Example: 1 This field shall specify the time interval for Does this mean that the reporting of a delivery intervals 07:00-19:00 each block or shape. schedule with time intervals of a quarter of an Example:2 hour (15min) foresees that each interval of 15 10:00-11:00 min must be reported separately? 12:00-13:00 15:00-16:00 49 Transaction capacity Quantity, i.e. number of units included in the Field No 57, Seite 29, 20 numerical digits in the format xxxx,yyyy Example: 1 This field shall specify the capacity, i.e. the The given format does not comply with the 2.52 Contact capacity Quantity per delivery time interval. Free text, field of up to 50 characters. transaction, per delivery time interval. Delivery capacity 10 number of units that can be included in the example given. Which is the "row 47" Example: 2 transaction, per delivery time interval. The mentioned in the column "Example"? 10(for first row in 47) capacity is represented as a whole number of 20(for second row in 47) units based on the defined unit capacity. For 20 (for the third row in 47) example, if a contract has a delivery capacity of 1 kWh, it should be represented as 1, with a value of kWh defined in field no 58.

50 Quantity unit The unit of measurement used. Field No 58, Seite 30, Up to 10 digits in text format. MWh This field shall specify the unit of 2.53 Quantity unit Daily or hourly quantity in MWh or kWh/d 10 numerical digits in the format xxxx,yyyyy. Quantity unit used in field no measurement used in the contract. which corresponds to the underlying 57 commodity. 51 Price/time interval quantity If applicable price per quantity per delivery time Field No 59, Seite 30, Up to 52 alphanumerical digits 300EUR/10MWh This field shall specify, if applicable, the price This field is not clear to us. 2.54 Price/time interval quantity If applicable, price per time interval quantities. 10 numerical digits in the format xxxx,yyyyy. interval. Price/time interval quantity per quantity per delivery time interval for block products (e.g. 300 EUR/10MWh) Additional information for capacity contracts for the transportation of electricity or natural gas 52 Transportation type Identifies the transportation type of the contract. 53 Originating Market Identifies the originating market area concerned. 54 Destination Market Identifies the market are where the delivery will take place. 55 Intrasystem(s) Where applicable the system(s) used to transport between the seller´s and buyer´s system. 56 Interconnection Point(s) Where applicable identification of the border(s), border point(s) or entry/exit point(s) of a transportation contract. Section 2c - Risk Confirmation Mitigation / Reporting 57 Confirmation timestamp Date and time of the confirmation Field No 60, Seite 30, ISO 8601 date format, UTC time format. 2014-01-29T10:35:56+00:00 The confirmation date and time stamp (ISO 2.26 Confirmation timestamp Date and time of the confirmation, as defined ISO 8601 date format, UTC time format. Confirmation time stamp 8601 format using UTC time zone) are used to under Commission Delegated Regulation (EU) represent the time at which the transaction No 149/2013 indicating time zone in which the was confirmed. confirmation has taken place. 58 Confirmation means Whether the contract was electronically Field No 61, Seite 30, Y=Non-electronically confirmed E This field represents the definition of how the What does "implicit" mean? 2.27 Confirmation means Whether the contract was electronically Y=Non-electronically confirmed, N=Non- confirmed, non-electronically confirmed or Confirmation means N=Non-confirmed contract was confirmed, whether the contract confirmed, non-electronically confirmed or confirmed, E=Electronically confirmed. remains unconfirmed. E=Electronically confirmed was electronically confirmed, non- remains unconfirmed. I=Implicit electronically confirmed or remains. The following values are valid: - Electronic - Confirmed - Unconfirmed - Implicit

Section 2i - Modifications Lifecycle information to the report 59 Action type When the report contains: Field No 62, Seite 31, N=New N The lifecycle information is used to identify the What kind of modifications should be reported 2.58 Action type Whether the report contains: N = New - a contract or post-trade event for the first Lifecycle information M=Modify stages or states of a transaction. Each stage of under the status "modified"? - a derivative contract or post-trade event for M = Modify time, it will be identified as ‚new‘; E=Error the transactions should be reported to ACER to the first time, in which case it will be identified E=Error - a contract which contains either quantity or C=Cancel provide a full picture of the transaction and the as ‘new’; C = Cancel price changes for different ‘blocks’ of energy stages the transaction went through before - a modification of details of a previously Z = Compression according to a given load profile over time, the completion. reported derivative contract, in which case it V = Valuation update transaction must be split in several records, When the report contains: will be identified as ‘modifiy’; O = other each of them reporting a single value for - An order or contract or post-trade event for the - a cancellation of a wrongly submitted report, quantity and price, and referring to each time first time, it will be identified as “new”; in which case, it will be identified as ‘error’; period in which both price and quantity are fix, - A modification of details of a previously reported - a termination of an existing contract, in which it will be identified as ‘split’; order or contract, it will be identified as “modify”; case it will be identified as ‘cancel’; - a modification of details of a previously - A cancellation of a wrongly submitted report, it - a compression of the reported contract, in reported contract, it will be identified as will be identified as “error”; which case it will be identified as ‘modify’; - A termination of an existing order or contract, it ‘compression’; - a cancellation of a wrongly submitted report, will be identified as “cancel”; - an update of a contract valuation, in which All transactions must follow a lifecycle that it will be identified as ‘error’; case it will be identified as ‘valuation update’; indicates the state of the transaction. The - a termination of an existing contract, it will be - any other amendment to the report, in which sequence of the lifecycle must be maintained for identified as ‘cancel’; case it will be identified as ‘other’. all transactions. The following rules must be - any other amendment, it will be identified as applied for all transactions; ‘other’. - The first report of any transaction must be with a lifecycle state of “new” - No transaction can be submitted with a lifecycle of “modify” if it has not either been already reported as new and or has been reported as the state of “cancel” - An “error” transaction report shall invalidate all transaction reports received prior to the “error” report, any transaction reports received following an “error” report must start from a “new” report 60 Details of action type Where field 51 is reported as 'other' the details 2.59 Details of action type When field 58 is reported as 'other' the details Free text, field of up to 50 characters. should be specified here. of such amendment should be specified here.