Home

EFET_TRUM

1. Data Field no 41 Settlement Method The method O Optional for counterparty isn t something that most deal capture systems would hold Generally contracts are agreed to be either physically or financially settling The only example we have seen and this is rare is where an option trade with two underlying binary options one for cash settlement and the other for physical delivery Data Field no 42 Last trading date and time We consider this field as unnecessary as this is not contract level information This data would be better provided by the organised market places and could then be extrapolated based on field 21 Data Field no 51 Duration We do not believe that this field provide any useful information over and above the period which can be interpolated from fields 49 and 50 Data Field no 53 Days of the week In order to provide a detailed delivery profile the list should also include public holidays However it should be noted that such may be difficult to implement for many market participants depending on their IT system This information could be better provided through the delivery profile shown in fields 54 55 and 57 aw Ke EFE European Federation of Energy Traders kk Data Field no 54 Load Delivery Intervals We are not sure why this is required given that the intervals are determined by the product which has been uniquely identified in field 21 Data Field no 58 Confirmation T
2. electricity and gas to a single consumption unit with a capability to consume Data Field no 11 Buy sell indicator In the description it is mentioned that in some cases where order is neither buy nor sell value BS should be reported however this is not valid since reserved field length is just 1 character That aside we are unsure under what conditions we would ever need to use the value BS as the only case this may be apparent is for float float physically settling swaps However a physically settling float float swap would normally be represented using two linked physical contracts one buy and one sell Data Field no 12 Initiator Aggressor Suggest that the value Sleeve be treated as a separate field This is normally represented as two fields in ETRM systems Initiator and Sleeve so could potentially be less implementation effort to report as separate fields Data field No 19 Which mechanism and controls are facilitated by the RRMs and the Agency in the terms of keeping this volume hidden or undisclosed when we are obliged to report the volume Data Field no 22 Contract Type Wouldn t the value SW Financial exchange of contract cash flows swap fall under the scope of EMIR Suggest that this be renamed to Swap style contracts which could be used for reporting physically settling swaps although these would normally be booked as linked physical contracts one buy one sell Data
3. events must be made available Trade matching process needs to be documented and explained given the level of detail of some traditional confirmation matching fields eg all timestamps this list will be smaller than what is used for market practice on confirms matching We would like ACER to clearly define what is the minimum data that is needed to match trades Is there one particular field a small number of fields that must match before a trade is considered matched Are the fields indicated at the back of the TRUM the minimum fields that must be completed The UTI process needs to be clarified What UTI should be reported for ETD and OTC Cleared trades For a contract concluded on an exchange for example two UTI s are produced One UTI is produced by the Exchange and another UTI is produced by the CCP The market participant only has access to the Exchange UTI This is very important if a market participant is required to report lifecycle events for standard contracts themselves In general the question is raised whether this the same UTI as that reported by ESMA ACER s solution architecture diagram suggest that web services only operate one way and this service is offered by ACER to RRMs and MPs Reporting Entities to send the transactional data to ACER ACER plans to send responses to Reporting Entities via email It is very important that ACER change their web services so that it operates bi directionally The read receipt and a
4. particularly around unpriced contracts are free text so the contents will vary between participants even though they are referring to the same thing Looking to standardise such fields would potentially increase the value of this data Similarly there are a number of fields which provide data which is available through extrapolation of other fields Reducing the number of fields would help reduce the cost of participant implementation in terms of IT costs and effort but will also reduce the potential for conflicting data and mismatches 16
5. Field no 25 Contract name We consider this field a duplication of information due to the fact that the contract is uniquely identified in field 21 Data Field no 26 Contract Trading Hours We consider this field as unnecessary as this is not contract level information This data would be better provided by the organised market places and could then be extrapolated based on field 21 Data Field no 28 Linked Transaction ID Most deal capture systems do not allow you to link spread transactions which are booked separately and additional IT development and investment would needed to link these for reporting Data Field no 29 Linked Order ID Not all deal capture systems would inherently capture and link market orders to transactions as these are not required for trade lifecycle P amp L or risk processes Additional IT development and investment would needed to link these for reporting aw Ke x EFE eee of Energy Traders x It should also be noted that there isnt always a simple 1 1 relationship between contracts and orders as an order may be fulfilled by many contracts We would therefore like a clear description of this field Order ID identifies the unique Order ID specified by the OMP and the Linked Order ID identifies a transaction which is the result of an executed order But Linked Order ID also facilitates when an order is amended where the original Order ID should be applied in this field and the new Or
6. MIT trades should follow the same field guideline sets standard nor standard trades orders Only exception is the REMIT trades in scope of EMIR which should follow the EMIR definitions without double reporting obligation on OMPs Once these trades have been reported by the MP under EMIR OMPs should not report the same data to the ACER even not on a voluntary basis In your view are Tables 1 3 and 4 of Annex of the draft Implementing Acts suited for the reporting of contracts referred to in Article 3 1 a 9 and Article 3 1 b 3 respectively 15 aw Ke of Energy Traders x A common issue in EFET s opinion is the difference in representation in various ETRM systems This causes market participants to report the initially identical transaction in a different manner The use of Linked Transaction IDs allows for reconstitution of the trade strategy but creates a heavy operational and IT burden on MPs to implement The application of this Linked Transaction ID does however not facilitate matching of the underlying transactions constituting such a trade strategy as these are often encoded differently in ETRM systems AS stated above we would ask that ACER provide clarity on each of these fields in terms of permitted values field sizes formats mandatory optional conditional logic etc as this would be required when developing the reporting solution We would also like to highlight that a number of the fields
7. ated on a swap although this is quite a rare occurrence and is probably of limited value to ACER This would typically be something that is validated during a bilateral confirmations process between the participants Data Field no 33 last Fixing Date We believe that this field will not provide any significant value and can be interpolated through the contract duration and the frequency fields 18 19 34 Fixings are normally based on calendar months any deviations from this convention would not be picked up by taking only the first and last dates This field may be useful for identifying how any back stub is treated on a swap although this is quite a rare occurrence and is probably of limited value to ACER This would typically be something that is validated during a bilateral confirmations process between the participants 13 aw Ke EFE R of Energy Traders x Data Field no 35 Settlement Method The method O Optional for counterparty isn t something that most deal capture systems would hold Generally contracts are agreed to be either physically or financially settling The only example we have seen and this is rare is where an option trade with two underlying binary options one for cash settlement and the other for physical delivery Data Field no 38 Option First Exercise Date Format should contain day and hour We would appreciate clarification from ACER that this field refers to the cont
8. ch a high usability of the TRUM it is important to describe the examples in the highest level of detail 8 Please provide us with your views on the field guidelines for the reporting of transactions in non standard supply contracts EFET considers the field guidelines foreseen in this section as not entirely fit for purpose merely a copy of field guidelines for standard transactions These guidelines need to be analysed and expanded where necessary Examples should be added where possible and appropriate EFET Welcomes the fact that the subject of volume optionality is incorporated into the field design however we feel that some other aspects of complexity around non standard supply contracts may still need to be considered For example The logic around describing complex non standard delivery profiles such as e Multi strike options strips e Physically settled swaps modelled as two linked physical contracts e Non standard fixing periods 11 aw Ke FET ae a of Energy Traders e Baskets and formula pricing We would very much welcome further clarification from ACER of which non standard contracts should be reported via the standard form in order to allow for proper IT implementation Comments on specific data fields Data Field no 10 Buy sell indicator In the description it is mentioned that in some cases where order is neither buy nor sell value BS should be reported however this is not valid since reserved f
9. cknowledgement processes need to be explained and documented in detail It is crucial that both Acceptances and Rejections are confirmed by ACER to the RRM MP The reporting on request demand needs to be aligned to the same data format and reporting process as currently stated in the TRUM We would therefore request a more detailed explanation from ACER on how participants are expected to report contracts on request i e 3 1 4 p 13 contract reportable on request both from a data schema and a process perspective We thus recommend including a detailed description of how these contracts should be reported whether using the standard non standard or otherwise field format along with any specific guidance on timescales and requirements to continue reporting such trades after the initial request Sufficient time should be granted to deliver these reports Trade reporting examples needs to be checked for consistencies and further expanded to cover orders to trade and all transaction types that are foreseen in REMIT The usability of the TRUM depends in particular of a clear distinction between standard and non standard contracts Until date of the consultation this clear distinction is missing It is of utmost importance that a clear definition is rendered 2 Please provide us with your general comments on the purpose and structure of the draft TRUM In particular please provide your opinion on whether the information the Agency intends to
10. contracts If yes please explain which scenarios these examples should cover In our opinion examples should support the detailed field guidelines specifically in cases where mapping of non standard trade attributes is necessary to a standardised common representation of such transactions Emphasis needs to be placed on the timely availability of the final TRUM so that market participants can prepare themselves efficiently for their compliance obligations Some examples of transactions that could be added e Custom load shapes e Indexed trades with additional spread premium e Physically settling swaps represented by 2 linked physical contracts e Long term contract e g Long term gas supply agreement with minimum monthly volume take or pay clause with option for additional volumes multiple delivery points and price formula based on public indexes Brent prices fuel oil prices gas oil prices fx rate natural gas prices 14 aw Ke EFE European Federation of Energy Traders k 10 11 12 13 14 15 e Supply contract to final customers with variable load profile depending on industrial needs end consumer and right of a number of clicks Please provide us with your views on the field guidelines for the reporting of transactions in electricity transportation contracts EFET considers the data field descriptions not to be detailed enough Additional details are therefore required si
11. d options need to be separated and tackled by separate reporting data standards Linking orders to trades is a complex relationship that will not be currently available in all participant deal capture systems This is not always a simple 1 1 relationship and will involve significant IT effort to implement as each OMP is likely to have a different data structure for order data and underlying trade activity e Supply contracts see 3 1 1 and 5 need to be clarified e Reporting Treatment Physical swaps amp spreads required the application of linked trade ID This is complicated and needs to be out weighted against additional implementation risk and cost e More details of option styles shall be provided e Clear split in reporting data needs to be inserted for Order to trades and all trade types Examples must be included for all of the above e There is no field defined as internal contract identifier This is very important because it allows us to ensure the traceability of the contract reported with internal systems It is used also in EMIR e Matching process and rules need to be defined e Reporting rules on complex price formulas for standard and non standard contracts needs to be defined Comments on specific data fields Data Field no 3 Trader ID as identified by the organised market place and or for the market participant or counterparty Trader ID as identified by the organised market place and or for the market partici
12. der ID is applied to Order ID When that amended order gets executed is it the intention that the original Order ID is overwritten with the actual Linked Order ID Data Field no 33 Fixing Index There are a large number of indices and each participant is likely to utilise a different naming convention unless there is a standardised list We would question the usefulness of a free text narrative which differs between participants One suggestion may be to signify whether the contract is fix priced index priced or priced through a formula basket Data Field no 34 Index Value We dont believe this field to be very useful as when booking a floating price contract it wouldn t make commercial sense to use an index which has already fixed We agree that any spread agreed against an index is useful information to report but we believe that this should be separated into a new field rather than confuse the index fixing with bespoke contractual spreads Market index fixings are not contract level information Contracts may reference indices which are used in order to determine settlement prices but the indices are market level information Data Field No 36 Notional Amount Trades that have an unknown price at the time reporting should be left blank This is mainly for indexed trades suppose but how is the procedure for filling out this field Is it something that we should do as MP or is it the RRM EFET or ACER that facilitates this feature
13. ental Data Reporting FDR Procedures Market Participants MPs are interested in a clarification of the legal status of these ACER publications As ACER indicates in its consultation of these publications that it intends to review these regularly MPs are also questioning how often changes to these ACER publications will occur as they will have to adopt their own implementation to be compliant with ACER requirements The enforceability of the TRUM needs thus to be explained in detail including the legal value of the ACER REMIT Newsletters cfr Q amp A ESMA Furthermore the delegation concept needs to be clarified in all due detail MPs only report purely OTC transactions via their RRM but what about lifecycle events for OMP trades what about non standard transactions The reasonable steps as in Article 11 3 of the Implementing Acts MPs are required to take to verify the completeness accuracy and timeliness of the data the third parties submit on their behalf needs to be explained in detail This delegation concept needs to address the concerns of a growing complexity of MPs positions towards delegating service providers who cannot take over all reporting duties eg lifecycle events of fax confirmed trades are only available to MPs MPs are therefore worried if OMPs will impose one side service agreements for delegated reporting under Art 6 1 REMIT IA and question how this can be avoided It remains also questionable to what e
14. ges the UTI always has to be different o Trading Scenario n 2 3 Electricity day ahead contract traded ona Continuous Market exchange Field 27 Regarding exchanges the UTI always has to be different Fieldn 51 52 from field 22 FW arises that this example is about day trades without choice on single hours therefore the fields n 51 52 have to be fulfilled with D Day instead of H Hour field n 51 and B Base instead of H Hour field n 52 o Trading Scenario n 2 4 Gas within day contract traded on a Continuous Market exchange Field n 27 Regarding exchanges the UTI always has to be different Field n 38 39 Gas is traded in MW and not in daywork MWh d Acer should be conform with the product taxonomy EMIR and not implement additional products Otherwise the data reporting isn t consistent with the product template and the confirmation o Trading Scenario n 2 5 Gas day ahead contract traded on a Continuous Market exchange Field n 27 Regarding exchanges the UTI always has to be different Field n 38 39 Gas is traded in MW and not in daywork MWh d Acer should be conform with the product taxonomy EMIR and not implement additional products Otherwise the data reporting isn t consistent with the product template and the confirmation Field n 51 O isnt defined At the exchange examples in Annex III examples of transaction reporting different UTIs are used Wit
15. he maximum or a median Data Field no 25 Volume Optionality Intervals The narrative for this field is a copy paste error A free text interval description is of questionable use as each participant is likely to define their own naming conventions e g March March14 March2014 Mars etc Data Field no 26 Volume QOptionality Capacity The narrative for this field is a copy paste error Volume optionality could perhaps be better represented through use of a MIN and MAX on the quantity field 12 aw Ke EFE European Federation of Energy Traders kk Data Field no 27 Type of Index Price We are unsure what a Fixed Index is If it means a fixed price contract we would expect this field to be left blank There are a large number of indices and each participant is likely to utilise a different naming convention unless there is a standardised list We would question the usefulness of a free text narrative which differs between participants One suggestion may be to signify whether the contract is fix priced index priced or priced through a formula basket Data Field no 28 Price or Price Formula We question whether a price number and a formula name string should be contained within a common field We are also_unclear of the usefulness of this field given that formulae will be a representations of complex expressions unique to each participant For example a value of A B C KW isn t meaningf
16. hin the framework of EMIR the same UTI is used for both parties Regarding the UTI there should only be in our point of view one number for ESMA 10 aw Ke x EFE ee of Energy Traders x and ACER This number is distributed by the platforms for standard contracts and is then used uniformly 7 In your view are there any additional examples to be added in ANNEX IiI of the draft TRUM Please provide a description of example s that in your opinion should be covered EFET recommends following additional examples to be added to Annex III of the TRUM Backloaded trades Standard traded off OMPs Various option contracts eg Power gas physical option on FWD contract Orders to trades Balance of week month Working day next week Lifecycle events of standard deal on OMP and bi lateral standard deal only reporting of changed value or full report e If deemed necessary for the sake of completeness other maturities then the ones already included o electricity peak load and off peak day ahead contract electricity base load weekly monthly quarterly yearly forward contract electricity peak load weekly monthly quarterly yearly forward contract electricity off peak weekly monthly quarterly yearly forward contract gas quarterly forward contract gas yearly forward contract 00000 Furthermore In Annex III the description of the given examples lacks the information about which exchange and which product is meant Finally in order to rea
17. ield length is just 1 character That aside we are unsure under what conditions we would ever need to use the value BS as the only case this may be apparent is for float float physically settling swaps However a physically settling float float swap would normally be represented using two linked physical contracts one buy and one sell Data Field no 12 Contract Type Wouldnt the value SW Financial exchange of contract cash flows swap fall under the scope of EMIR Suggest that this be renamed to Swap style contracts which would be used for reporting physically settling swaps although these would normally be booked as linked physical contracts one buy one sell Data Field _no 14 Contract ID This field is not applicable for non standard contracts Data Field no 15 Estimated Notional Amount The text refers to orders although these wont be applicable for non standard contracts Data Field no 17 Delivery Point Areas This information may not be available in all cases especially where an option holder is able to nominate where delivery will take place Data Field no 20 Volume Optionality These enumerations overlap each other For example volume can be F Fixed and M Min Max or it may be V Variable and C Complex Data Field no 21 Total Notional Contract Quantity If the volume optionality 20 is variable for this contract which quantity should we use for the notional The minimum t
18. imestamp We are not sure why this is required for REMIT and expect this field to nearly always be null when a contract is first reported Data Field no 59 Confirmation Means We are not sure why this is required for REMIT and expect this field to nearly always be null when a contract is first reported In addition many intra day contracts are non confirmable in the market as they deliver before the standard confirmation timelines A new non confirmable value would be needed to reflect these contract types 6 Please provide us with your views on the examples of transaction reporting listed in ANNEX Ill of the draft TRUM Do you consider the listed examples useful to facilitate transaction reporting EFET considers the Creation of Annex as very useful However the Maintenance of this section needs to be addressed described and supported by a process Furthermore Inconsistencies between field guidelines and trade examples need to be mitigated Below we listed some inconsistencies in the examples given in Annex III o Inthe examples the time is generally parameterised with Z UTC so that the examples are about trades in UK as only in UK the time Z is used The examples contains incoherent date regarding contracts products Delivery Start Date and timeframe l e in the trading scenario n 3 5 As Z is used it describes a trade in UK the British Base has the timeframe 23 00Z 23 00Z but the Load Delivery interval
19. include in the first edition of the TRUM is sufficient for the first phase of the transaction reporting contracts executed at organised market places If not please explain which additional information should be covered EFET is generally positive about the purpose and structure of the draft TRUM guiding the 1 phase of REMIT transaction reporting aw Ke x EFE eee of Energy Traders x EFET recommends the backloading process to be covered Guidance on this process is required since some of the requested fields specifically for trades to be backloaded will only be available by participants after some significant IT development Clarity is required on the backloading periods and on whether there are any deviations allowances from the field list rules The backloading process should be considered when determining the mandatory optional nature of the field lists Lifecycle information should be included in the guidelines and in the trade examples There are open questions as regards the reporting channels for life cycle events and orders to trade This is in particular true for such transactions which are executed over OMPs because under current TRUM guidance it is not allowed for MPs to report these transactions directly to ACER themselves and MPs would have to build interfaces to each OMP to submit life cycle events e EFET questions if at all and how life cycle events ACER refers to post trade events in this RRM Require
20. ir total consumption in one go but rather sign up to Flexible purchasing contracts where they buy in small clips typically 5MW but could be less then that of different wholesale products and over a long period of time up until the delivery period These trades can be both back to backed in the wholesale market or they are netted off against other retail positions Guidance is needed on if such contracts are reportable at all and what information we are required to report in this circumstance Please note that reporting for these customers could be very onerous and costly for a supplier and it is important to have clear guidance on what the requirements are 4 Please provide us with your views on the explanation of product contract and transaction provided in this Chapter in particular on whether the information is needed to facilitate transaction reporting aw Ke EFE European Federation of Energy Traders k EFET welcomes the increased level of detail and clarification value of the TRUM 5 Please provide us with your views on the field guidelines for the reporting of transactions in standard supply contracts EFET considers the Field guidelines to be generally helpful with following remarks e We would appreciate guidance on each field in terms of whether it is mandatory optional or conditional and any other applicable rules Likewise for data types number string etc e Orders to trade standard contracts an
21. is specified with O0 00Z 24 00Z The timeframe 00 00 24 00 without Z is the German Base Furthermore if it was a British Base the Delivery Start Date in the example 3 5 should be 2014 07 31 as it starts one hour earlier 23h than the German Base 00 00h o Trading Scenario n 1 1 Electricity hourly contract traded on an Auction Market Field n 22 SPO isn t defined We would have assumed that ACT should be used o Trading Scenario n 1 2 Electricity block contract traded on an Auction Market exchange Field n 22 SPO isn t defined o Trading Scenario n 1 3 Electricity day ahead contract traded on an Auction Market exchange aw Ke EFE eee of Energy Traders x Field n 39 MP2 this field contains an arithmetic error it has to be 240 instead of 0 Field n 51 52 from field 22 FW arises that this example is about day trades without choice on single hours therefore the fields 51 52 have to be fulfilled with D Day instead of H Hour field 51 and B Base instead of H Hour field 52 o Trading Scenario n 2 1 Electricity hourly contract traded on a Continuous Market exchange Field n 22 SPO isn t defined Field n 27 Regarding exchanges the UTI always has to be different o Trading Scenario n 2 2 Electricity block contract traded on a Continuous Market exchange Field n 22 SPO isn t defined Field n 27 Regarding exchan
22. ist creates an additional IT task on all MPs this needs to be well documented and made available timely The list of standard contracts must be made available in a standardised format and supported by an extraction and download process so that MPs reporting systems can easily embed them into their system landscape We would like to clarify with ACER that bilateral trades off organised market places should be reported using the standard supply contract field list but these will not be in scope for the initial go live of standard contract reporting Phase 1 aw Ke of Energy Traders x Do you agree that the list of standard contracts in Annex Il should also be considered sufficient to list the organised market places or would you prefer to have a separate list of organised market places Please justify your views EFET prefers a separate list of organised market places and a list of the standard contracts each OMP offers This list should be published well before the start date of transaction reporting under REMIT The list of standard contracts in its current stage in the draft TRUM is created out of different elements of which the OMP is one However market standardisation for products could make such an OMP element unnecessary It would therefore be more future proof to build a separate list of OMPs The list must be maintained regularly adding new or inactivating old data at defined periodic intervals A clear proce
23. ments for standardized transactions executed at OMPs can be reported because this information is not available to OMPs e EFET would be interested in an exhaustive list of definitions for life cycle events e EFET wonders how orders to trade for derivatives which are reported to trade repositories under EMIR should be reported to ACER since orders have not to be reported under EMIR e EFET wants to avoid different or additional reporting channels with regard to these items An important concept is the bidirectional reporting services that should build the heart of ARIS Currently this draft version of the TRUM reflects an architecture that hints at one sided processes which is in our opinion incorrect 3 Please provide us with your views on the Agency s proposed approach as regards the list of standard contracts In particular please provide your views on whether e the list of standard contract types enables reporting parties to establish whether to use Table 1 or Table 2 of Annex of the draft Implementing Acts when reporting information under REMIT and e the identifying reference data listed in ANNEX Il to be collected by the Agency would be sufficient and suitable to establish the list of standard contracts EFET considers the list of standard contracts to be complete However the process to maintain update publish crosscheck etc this list of standard contract types needs to be clarified As the implementation of this l
24. milar to the level of information for the standard contracts It is also important to provide relevant example values Please provide us with your views on whether examples of transaction reporting should be added as regards transactions in electricity transportation contracts If yes please explain which scenarios these examples should cover EFET considers it useful to add examples Please provide us with your views on the field guidelines for the reporting of transactions in gas transportation contracts Additional examples are required in particular where contracts relating to the transportation of electricity or natural gas concluded between market participants on secondary markets physical or financial capacity rights or obligations including relate and transfer of such contracts Please provide us with your views on whether examples of transaction reporting should be added as regards transactions in gas transportation contracts If yes please explain which scenarios these examples should cover EFET considers it useful to add examples Do you agree that if organised market places trade matching or reporting systems agree to report trade data in derivatives contracts directly to the Agency they must do so in accordance with Table 1 of Annex of the draft Implementing Acts as regards contracts referred to in Article 3 1 a 9 and Table 3 or 4 as regards contracts referred to in Article 3 1 b 3 EFET recommends all RE
25. pant or counterparty Several national laws in Europe eg in Germany for market participants who are part of the Workers Council prohibit to pass on data related to individuals The TRUM states that This field indicate the ID used by the market place to identify the user entering into the transaction that is reported This is most likely an electronic ID for the trader market participant account Not clear how to populate the value for bilateral contracts traded off organised market places We believe that Trader ID should not be mandatory for off organised market places also taking into account that if a party wish to offer delegated reporting services to its counterparty it s almost impossible to report this counterparty data The value a12345 is not explained properly Data Field No 6 Reporting entity ID Generally speaking this field is a determination of Registered Reporting Mechanism Who can be a RRM and what is ACERs idea as to who should function as a RRM aw Ke x EFE ee of Energy Traders x Furthermore we would like to know what happens if we decide to change RRM in the middle of our regulatory reporting How is the process for this and what other fields and procedures are affected from this decision Data field_No_8 How are we supposed to interpret the minimum threshold 600 GWh Year What is the difference between the supply of electricity or gas for the use of final customers and supply of
26. ractual exercise dates not the ACTUAL dates upon which an option is exercised during the trade lifecycle Data Field no 39 Option Last Exercise Date Format should contain day and hour We would appreciate clarification from ACER that this field refers to the contractual exercise dates not the ACTUAL dates upon which an option is exercised during the trade lifecycle Data Field no 41 Option Strike Index There are a large number of indices and each participant is likely to utilise a different naming convention unless there is a standardised list We would question the usefulness of a free text narrative which differs between participants One suggestion may be to signify whether the contract is fix priced index priced or priced through a formula basket Data Field no 42 Option Strike Index Type we are unclear what information this field is trying to convey One suggestion may be to signify whether the contract is index priced or priced through a formula basket Data Field no 43 Option strike index sources We understand the reasoning for requesting this information however we believe that by standardising the values within field 41 would better address this requirement The index should reference the source otherwise the situation could arise where conflicting data is provided 9 Please provide us with your views on whether examples of transaction reporting should be added as regards transactions in non standard supply
27. ss must be defined for the treatment of any product which is not listed within the standard contracts list e g are they automatically assumed to be non standard There is specific guidance missing within the TRUM regarding reporting transactions related to the following types of contracts listed within Article 3 List of reportable contracts in the draft REMIT Implementing Acts e i Contracts of 600 GWh year or more for the supply of electricity or natural gas for the use of final customers e ii Contracts for the supply of electricity or natural gas to a single consumption unit with a technical capability to consume 600 GWh year or more e We require more guidance on what type of customers would be applicable for this 600GMh year threshold e We understand that the alternative ii would only apply to supply contracts with customers that consume above 600GWh over 1 extremely large site and not to customers that have a total consumption above 600GWh but spread across many small sites for example gt 1000 sites eventually across the EU e With regard to the alternative i we question if that alternative should not be better deleted because it raises more questions than it answers Supply contracts with large industrial customers are substantially different to wholesale contracts and therefore specific guidance should be given for these types of contracts For example many retail customers of this size do not purchase the
28. ul without the term sheet The formula will not detail averaging rules listed observations FX rules rounding precision etc One suggestion may be to signify whether the contract is fix priced index priced or priced through a formula basket Data Field no 29 Fixing index There are a large number of indices and each participant is likely to utilise a different naming convention unless there is a standardised list We would question the usefulness of a free text narrative which differs between participants One suggestion may be to signify whether the contract is fix priced index priced or priced through a formula basket Data Field no 30 Fixing index type We believe this is the same as field 12 Data Field no 31 Fixing index sources We understand the reasoning for requesting this information however we believe that by standardising the values within field 29 would better address this requirement The fixing index should reference the source otherwise the situation could arise where conflicting data is provided Data Field no 32 First Fixing Date We believe that this field will not provide any significant value and can be interpolated through the contract duration and the frequency fields 18 19 34 Fixings are normally based on calendar months any deviations from this convention would not be picked up by taking only the first and last dates This field may be useful for identifying how any front stub is tre
29. xtent MPs can rely on OMPs taking up the reporting obligation on their behalf as for example some trading venues could argue that they are not OMPs On top of that EFET is interested in DG Energy s view on liability of market participants vs liability of OMPs and 3rd persons reporting on behalf of MPs see Art 11 REMIT IA The open question is about which steps MPs have to take in detail for example is the complete accurate and timely sending of trade data to OMPs sufficient to discharge the liability or are any other measures to be taken MPs should not be de facto forced to put in place a complex cumbersome and cost consuming tool for the reporting of lifecycle events only if they do not have the option to decide reporting also the original trade directly to the ACER Similarly mandatory reporting and legally enforceable obligation on OMPs to report on platform deals and solution must to be proposed by ACER whereby no additional efforts or costs for MPs to report EFET promotes and facilitates European energy trading in open transparent sustainable and liquid wholesale markets unhindered by national borders or other undue obstacles We currently represent more than 100 energy trading companies active in over 27 European countries For more information visit our website at www efet org 2 aw Ke EFE eae of Energy Traders x trade events OR the option for MPs to report both original on platform deal and trade
30. ze FE European Fe deration E of Energy Traders x EFET response to ACER public consultation on ACER s Transaction Reporting User Manual TRUM for transaction reporting under REMIT EFET Market Supervision Committee 2 September 2014 aw Ke x EFE eee of Energy Traders x 1 Please provide us with your views on the scope and the objectives of this document In particular please provide your opinion on whether the kind of information included and the structure of the TRUM are suitable to facilitate transaction reporting If not please explain which additional information the TRUM should cover and or how it should be structured EFET welcomes the increase in quality ACER brought to this draft version of the Transaction Reporting User Manual for REMIT Reporting The addition of trade examples has brought extra clarification to the TRUM and has increased the value of this document as a readiness indicator for REMIT reporting compliance and implementation Emphasis needs to be placed on the timely availability of the final TRUM so that market participants can prepare themselves efficiently for their compliance obligations According to Art 11 REMIT IA ACER shall publish technical and organizational requirements for a transaction reporting the so called TRUM Transaction Reporting User Manual b Requirements for the registration of RRMs RRM Requirements and c Manual of Procedures on Fundam

EFET_TRUM

Contents

Download Pdf Manuals

Related Search

Related Contents