European Regulations – REMIT Reporting Services and Solutions by CTRM Center

Research and Report

European Regulations â&#x20AC;&#x201C; REMIT Reporting Services and Solutions July 2015 Last updated March 2016

Sponsored by

and

In association with

REMIT Reporting Services and Solutions - July 2015 updated March 2016

© 2016 ETR Advisory Ltd and Commodity Technology Advisory LLC – All rights reserved Disclaimer The contents of this document are solely based on the opinion of the authors based on their reading of publicly available documents. Nothing contained in this document shall be considered legal advice, or advice or fact about any specific party. ETR Advisory Ltd and Commodity Technology Advisory llc bear no responsibility for any decisions made based on the contents of this document, or the consequences thereof. It is recommended that readers seek legal advice on any matter outlined in this document, and that any information about third parties be verified directly.

All enquires and comments relating this document should be directed to the authors:

ETR Advisory Ltd +44 20 3271 0091 aviv@etr-advisory.com

Commodity Technology Advisory LLC +1 281 207 5412 +420 775 718 112 info@comtechadvisory.com

REMIT Reporting Services and Solutions - July 2015 updated March 2016

1 Table of Contents 2

What is REMIT? ......................................................................................................................................................... 5 2.1

This Report ........................................................................................................................................................ 6

2.2

Inside Information and Market Manipulation .................................................................................................. 6

2.3

Registration ....................................................................................................................................................... 6

Reporting – Why? ..................................................................................................................................................... 7 3.1

Acts and Timelines ............................................................................................................................................ 8

3.2

Data sources and types– where does it originate? ........................................................................................... 9

Reporting requirements.......................................................................................................................................... 10 4.1

How the data gets to ARIS – RRMs and OMPs ................................................................................................ 10

4.2

Which activity is included in REMIT? .............................................................................................................. 11

4.2.1

LNG trades............................................................................................................................................... 12

4.3

WHO is covered by REMIT?............................................................................................................................. 12

4.4

To be reported on demand ............................................................................................................................. 12

4.5

Exemptions – 600, 10 and 20 .......................................................................................................................... 13

4.6

What is a “trade?”........................................................................................................................................... 13

4.7

What about EMIR? .......................................................................................................................................... 13

4.8

“What is a derivative”? - MiFID Annex I Section C .......................................................................................... 13

4.9

Who reports? .................................................................................................................................................. 14

4.9.1

RRMs ....................................................................................................................................................... 14

4.9.2

EMIR TR ................................................................................................................................................... 15

4.9.3

Organised Market Place .......................................................................................................................... 15

4.9.4

Direct reporting ....................................................................................................................................... 15

4.9.5

Fundamental data using a system operator ........................................................................................... 16

4.9.6

Electricity Transparency Regulation (ETR) – 543/2103 ........................................................................... 16

4.10

What needs to be reported and where is it defined?..................................................................................... 16

4.11

The UTI issue ................................................................................................................................................... 16

4.12

Schemas and Receipts..................................................................................................................................... 18

4.13

Standard vs non-standard, formats and phases ............................................................................................. 18

4.14

Report timing .................................................................................................................................................. 19

4.15

Back loading .................................................................................................................................................... 19

Reporting of orders and trades arising on Organised Market Places ..................................................................... 20 5.1

“Delegated reporting” under REMIT............................................................................................................... 20

5.2

What is an OMP under REMIT?....................................................................................................................... 20

5.3

OMP reporting – how should it work and what are the issues?..................................................................... 21

5.3.1

Unknown data ......................................................................................................................................... 22

REMIT Reporting Services and Solutions - July 2015 updated March 2016

5.3.2

Post trade events .................................................................................................................................... 22

5.3.3

Reconciliation .......................................................................................................................................... 22

5.3.4

Multiple agreements ............................................................................................................................... 23

5.4

5.4.1

Direct reporting ....................................................................................................................................... 23

5.4.2

Upload service ......................................................................................................................................... 24

5.4.3

Sending the data to an RRM ................................................................................................................... 24

5.4.4

“Full” RRM ............................................................................................................................................... 25

5.4.5

EMIR TR/RRM .......................................................................................................................................... 25

5.5

Different types of offering from OMPs ........................................................................................................... 23

Options available to a market participant for OMP reporting........................................................................ 25

5.5.1

Direct reporting agreements with all OMPs ........................................................................................... 25

5.5.2

Upload data from all OMPs and sent it to one or more full RRM ........................................................... 26

5.5.3

Ask OMPs to send data to full RRMs....................................................................................................... 26

5.5.4

Use an aggregated service ...................................................................................................................... 27

5.5.5

Combinations .......................................................................................................................................... 27

5.5.6

Is it possible for a market participant to become an RRM and send OMP data? ................................... 27

5.6

Keeping records of OMP activity..................................................................................................................... 27

5.7

Reconciliation.................................................................................................................................................. 28

5.8

Pros and cons of OMP approaches ................................................................................................................. 29

Meeting the full requirements – “Phase 2” ............................................................................................................ 30 6.1

Off venue reporting summarised .................................................................................................................... 30

6.1.1

“Look alike” trades .................................................................................................................................. 30

6.1.2

“Simple” trades ....................................................................................................................................... 31

6.1.3

“Complex” trades .................................................................................................................................... 31

6.1.4

The “Framework/execution” construct .................................................................................................. 31

6.1.5

Secondary transportation ....................................................................................................................... 32

6.1.6

Fundamental data reportable by market participants ........................................................................... 32

6.1.7

Backloading ............................................................................................................................................. 32

6.2

Meeting the full requirements – what are the options? ................................................................................ 33

6.2.1

Delegation ............................................................................................................................................... 33

6.2.2

Direct upload to an RRM without software ............................................................................................ 34

6.2.3

Direct sending of data to ACER ............................................................................................................... 34

6.2.4

Using software ........................................................................................................................................ 35

6.2.5

ETRM adapters ........................................................................................................................................ 35

6.2.6

Standalone software ............................................................................................................................... 37

6.3

Using a service ................................................................................................................................................ 42

REMIT Reporting Services and Solutions - July 2015 updated March 2016

6.3.1

Combining with a confirmations service ................................................................................................. 42

6.3.2

Combining with a trading portal ............................................................................................................. 43

6.4

Comparing solution types ............................................................................................................................... 44

6.5

Combining solutions........................................................................................................................................ 46

6.5.1

Temporary combinations ........................................................................................................................ 46

6.5.2

Using a combination of OMP reporting and uploading .......................................................................... 46

6.5.3

Using a TR/RRM ...................................................................................................................................... 46

6.5.4

Using a service and software .................................................................................................................. 48

6.5.5

Other combinations ................................................................................................................................ 49

6.6

Fundamental data ........................................................................................................................................... 49

6.6.1 7

Planning for compliance as a market participant – tasks to carry out ................................................................... 50 7.1

Registration ..................................................................................................................................................... 50

7.2

Product List ..................................................................................................................................................... 50

7.3

Locate data ...................................................................................................................................................... 50

7.4

Overall solution shape .................................................................................................................................... 50

7.5

Phase 1 solution .............................................................................................................................................. 50

7.6

Phase 2 solution .............................................................................................................................................. 51

7.7

Stay in touch and implement .......................................................................................................................... 51

What will happen next and getting further help .................................................................................................... 52 8.1

Who is responsible for reporting and reconciliation of fundamental data? .......................................... 49

Useful links and documents ............................................................................................................................ 52

Solutions directory and listings ............................................................................................................................... 53 9.1

RRM/TRs.......................................................................................................................................................... 54

9.2

Other “Full” RRMs ........................................................................................................................................... 56

9.3

Software .......................................................................................................................................................... 59

9.3.1

Stand-alone software .............................................................................................................................. 59

9.3.2

ETRM Software adapters ........................................................................................................................ 66

9.4

Services ........................................................................................................................................................... 69

REMIT Reporting Services and Solutions - July 2015 updated March 2016

2 What is REMIT? The Regulation of the wholesale Energy Market Integrity and Transparency (REMIT) came into force in December 2011, twenty days after the “Level 1” text was passed by the European Parliament. The main purpose behind REMIT is to outlaw market abuse in the wholesale gas and power market in Europe. REMIT is part of the “third package” of rules that are intended to move the EU towards a single wholesale market. REMIT applies to all physical and financial trades, and also includes LNG where the supply is intended for the EU network. Anyone who executes a trade for delivery inside the EU is subject to the rules, no matter where in the world they are based. In this sense REMIT is distinct from many financial regulations. REMIT is enforced by National Regulatory Authorities (NRAs), who are local energy regulators. For example, Ofgem enforce REMIT in the GB market using specifically drafted UK regulation, which has extended their powers of enforcement (Northern Ireland is covered by the “Utility Regulator”). The entire effort is coordinated on an EU-wide basis by ACER, the Agency for the Cooperation of Energy Regulators. REMIT can be considered to have four pillars: 1) 2) 3) 4)

Inside Information Market Manipulation prohibition Market Participant registration Data reporting

When REMIT went into force in December 2011, the inside information rules came into effect straight away. Enforcement powers for the market abuse parts of REMIT were to be implemented by each member state by June 2013. Most countries did not achieve this date, and even now there are a handful of countries that have yet to bring the rules into law. Market Participant registration and data reporting could only come into force with the adoption and coming into force of an Implementing Act, which comes from the European Commission. The Act came into force on 7 th January 2015. The two reporting deadlines are/were 9 and 15 months after this date.

REMIT Reporting Services and Solutions - July 2015 updated March 2016

2.1 This Report This report focuses on the data collection part of REMIT, with the second of the two deadlines still to pass. We will examine how to prepare for these deadlines, which fall on the 7th October 2015 and 7th April 2016. While the first deadline has passed, many will wish to reconsider how to deploy their solutions holistically. The report will examine the reporting requirements, the infrastructure that is building around the requirements and the various types of solution that are available to meet the requirements. It ends with a listing of the various solutions on offer from different vendors. The report is solely based upon the opinion of the authors and does not constitute legal advice. It is recommended that readers seek legal advice on any matter outlined in this document, and that any information about third parties be verified directly. Before looking at reporting it is worth having a brief overview of the other parts of REMIT.

2.2 Inside Information and Market Manipulation Under REMIT Articles 3 and 5, it is forbidden to utilise inside information for trading activity except in the case of some narrowly defined exemptions. Inside Information in the context of REMIT includes information related to physical assets. For example a power station outage, which has not been published, could be considered inside information. The approach to inside information in the energy world is to publish it, thus putting it into the public domain. REMIT stipulates that such publication should be carried out as soon as possible, except in certain circumstances when it may be delayed. Such circumstances include coverage of an immediate physical loss, or in order to fulfil security of supply obligations. For the time being most asset owners publish their inside information on their web site, or on one of several platforms. From 1st January 2017, those publishing inside information will need to do so in RSS or ATOM using prescribed formats to be found in ACER’s Manual of Procedures. REMIT also prohibits actual and attempted market manipulation, which can involve any activity that is considered “abusive”. The act, and also guidance issued by ACER does list some very specific examples, which include techniques such as “marking the close” and “market cornering”. In many cases the types of abuse are similar to the financial markets, although the physical side can make it more complex to detect. For example a market cornering will usually involve manipulating a physical supply and then profiting from a resulting movement on the financial side. Both inside information and market manipulation attract the heaviest sanctions under most regimes, which under some jurisdictions include criminal sanctions.

2.3 Registration REMIT requires all market participants to be registered in a central database known as the CEREMP, the Central European Registry for Energy Market Participants. While this database is run by ACER registration takes place at the local level, with each NRA providing a registration facility. NRAs had a deadline of 17 th March 2015 to get their systems up and running. Registration takes place in two parts: Completing the first results in an “ACER code”, a unique identifier provided to each participant. It also asks for some basic information, including details of certain responsible individuals in the organisation and the ultimate parent. The second stage involves providing more detailed information, such as the company structure as well as who will report. All registrations must be completed by the start of reporting. In many jurisdictions, it has been compulsory to complete the first stage already. Others do not specify a date. However it has been recommended that all start registration by the 17th June 2015. Those only reporting second phase data must register before such reporting commences.

REMIT Reporting Services and Solutions - July 2015 updated March 2016

Any legal entity that either trades in the market or with covered physical assets must carry out registration, which is free. Certain fields in the register will be made publically available for download from the ACER website, which is important to be able to correctly report certain fields.

3 Reporting – Why? Before considering HOW to report, it is worth looking at WHY the reporting is required. In general, the reason for reporting is so that the regulators, which comprise ACER and local National Regulatory Authorities (NRAs) can monitor the market for signals of breaches of REMIT Articles 3 and 5. As a result, Article 8 requires market participants to report, and Article 7 authorises ACER to monitor the market. ACER, the Agency for the Coordination of Energy Regulators, has been tasked with coordinating data collection, and also for monitoring the market as a whole. At the same time, each NRA is also responsible for monitoring their own market local markets. ACER will collect the data from across all of the markets and will aggregate it in a large database called ARIS, ACER’s Regulatory Information Service. The database is fed from many sources, including dedicated collection entities called “RRM”s, Transmission System Operators (TSOs) and others, including EMIR Trade Repositories (TRs). The data is then used as a feed to a surveillance system, which is run by ACER on the data. The system provides signals for ACER’s newly formed monitoring team to investigate potential breaches. The system ACER have chosen is the “SMARTS” system sold by Nasdaq OMX. The entire architecture is summarised in this

diagram from ACER: Source: ACER Documentation

REMIT Reporting Services and Solutions - July 2015 updated March 2016

It is worth noting that while the data collection will form a key input into monitoring, there are also other feeds, which in particular include notifications of suspicious activity that can be given by market participants, or “PPAT”s, Professional Persons Arranging Transactions who are obligated to report such suspicions under REMIT article 15. The topic of surveillance will be the subject of another report. In addition to using the data themselves, ACER sends a copy of each market’s data to each NRA who perform their own surveillance on the data, often using a different software package. Different NRAs have adopted different levels of monitoring so far. In at least one case, an NRA (Austria) has kicked off collection early so that monitoring can start as soon as possible. It is important to remember the purpose of collection and to bear this in mind when considering different data issues. By considering how the data will be utilised, it is often possible to deduce which data to send.

3.1 Acts and Timelines The key REMIT rules arise out of the original Act, which was entered into the European Union journal on 8th December 2011 and went into force 20 days later. The act contains all of the rules around inside information, market manipulation and other aspects of the rules. The Act is considered to be at “level 1” in terms of EU regulation. The act specified several dates and also relative milestones for REMIT to take effect: -

The rules around inside information were to take effect immediately. Member states were to pass enforcing legislation by the end of June 2013 for all of REMIT, and in particular for Articles 3 and 5, Inside Information and Market Manipulation. Most member states did not meet this deadline, although at the time of writing most had passed the legislation, with a few exceptions. Registration was to commence 3 months after the adoption of an Implementing Act. The Implementing Act was to be defined by the Directorate General of Energy (“DG Energy”), which is part of the European Commission, using a procedure known as “Commitology”. Data reporting was to commence 6 months after the Implementing Act came into force. This was to be for on venue trades. Off venue trades were to be reported from 12 months after the Implementing Act went into force.

The deadline originally set for the Implementing Act to go into force was also the middle of June 2013. However, the Implementing Act was not adopted until 17th December 2014, going into force 20 days later on 7th January 2015. In addition, the gap between going into force and the two reporting deadlines were each extended by 3 months, with on venue reporting starting after 9 months and off venue after 15. The reporting start dates were therefore set for the 7th October 2015 and 7th April 2016. The timeline as a whole can therefore be summarised as follows:

REMIT Reporting Services and Solutions - July 2015 updated March 2016

3.2 Data sources and types– where does it originate? Data is categorised in different ways under REMIT. Firstly one must consider the type of data, which broadly can be split into: -

Orders - All pre trade activity for a trade, in particular arising from activity on an Organised Market Place (OMP). (Also see later note about off venue orders). Trades – Actual trades – this includes trade executed on or off an OMP. A trade will include any wholesale contract and will include items such as Power Purchase Agreements (PPAs). See the later section for a full discussion on what qualifies as a “trade”. Fundamental data – actual physical data, such as nominations, flows and other actuals.

As such therefore data can originate from the following sources: -

On OMP activity – i.e. on an Exchange or Broker platform. Bilateral activity – directly between parties. On a physical network, usually involving a type of system operator.

The type and source of activity will determine the possible routes of the data from source to ARIS.

REMIT Reporting Services and Solutions - July 2015 updated March 2016

4 Reporting requirements In basic terms, every covered market participant is responsible for making sure that each piece of required data is reported to ACER. As under EMIR, BOTH sides of a trade (and order in some cases) must report the data, using the same identifier. The data must be sent to ARIS, ACER’s central database, using a variety of mechanisms. In many cases, responsibility for reporting may be delegated. We will now drill down into the details of the reporting.

4.1 How the data gets to ARIS – RRMs and OMPs Data is to reach ACER via a variety of routes, which partly depends on its source and type, and partly in within the choice of the Market Participant. The possible routes can be summarised by the following diagram:

In general, market participants may not send data directly to ARIS. Rather they must send data using an intermediary called an “RRM”, a Registered Reporting Mechanism. An RRM is an entity specifically set up for forwarding data from market participants to ARIS. OMPs are obligated by the REMIT Implementing Act to “offer a data reporting agreement” (Article 6(1)) for all data that originates on their platform. They are therefore obliged to send data whose source is the platform, should the market participant wish to use it. Since such a service can be charged for, and also because there are sometimes issues with using such a service, the market participants may choose not to use it, although an answer given by ACER in a questions and answers document issued on the 16th February 2016 increases the incentive to use such as agreement. A market participant may choose to become an RRM themselves for the sending of off venue data. Registering as one will introduce several new requirements, which will often not be desirable (see section 5.4.1).

REMIT Reporting Services and Solutions - July 2015 updated March 2016

Fundamental data is usually sourced from TSOs and other system operators. It is usually the TSO that will be required to send such data to ARIS. However, there are exceptions, such as gas in storage (See section 6.6) and when handling LNG. Finally, “derivatives” data that is reported under EMIR where a trade falls under both rule sets does not have to be re-reported under REMIT. Instead it must be forwarded by the EMIR TR to ARIS. This will be examined in the next section. To summarise, there are in total five “routes” for data to reach ACER: 1) 2) 3) 4) 5)

Via an RRM Via an EMIR TR Using an Organised Market Place Directly, if registered as an RRM Fundamental data – using a System Operator or RRM

Note that some entity types outlined above may fulfil more than one role. For example some EMIR TRs will also act as full RRMs, as will some OMPs. However not all EMIR TRs offer such a service and neither do most OMPs. Each of these routes will be examined in more detail in later sections.

4.2 Which activity is included in REMIT? REMIT covers the entire wholesale market in power, gas and LNG in the European Union, spanning both physical and financial trading and fundamental data. The REMIT Implementing Act (Article 3(1)) lists the following types of contract as being covered by REMIT:

 

     

  

Intraday or within-day contracts for the supply of electricity or natural gas where delivery is in the Union whether auctioned or continuously traded, Day-ahead contracts for the supply of electricity or natural gas where delivery is in the Union whether auctioned or continuously traded, Two-days-ahead contracts for the supply of electricity or natural gas where delivery is in the Union whether auctioned or continuously traded, Week-end contracts for the supply of electricity or natural gas where delivery is in the Union auctioned or continuously traded, After-day contracts for the supply of electricity or natural gas where delivery is in the Union irrespective of where and how they are traded, in particular regardless of whether they are auctioned or continuously traded, Other contracts for the supply of electricity or natural gas with a delivery period longer than two days where delivery is in the Union whether auctioned or continuously traded, 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, Options, futures, swaps and any other derivatives of contracts relating to electricity or natural gas produced, traded or delivered in the Union. Contracts relating to the transportation of electricity or natural gas in the Union between two or more locations or bidding zones concluded as a result of a primary explicit capacity allocation by or on behalf of the TSO specifying physical or financial capacity rights or obligations, Contracts relating to the transportation of electricity or natural gas in the Union between two or more locations or bidding zones concluded between market participants on secondary markets, specifying physical or financial capacity rights or obligations, including resale and transfer of such contracts, Options, futures, swaps and any other derivatives of contracts relating to the transportation of electricity or natural gas in the Union.

In short, ANY gas or power related wholesale contract is included under REMIT. However, there some important subtleties about what is considered to be wholesale which will be examined in section 4.5.

REMIT Reporting Services and Solutions - July 2015 updated March 2016

4.2.1

LNG trades

There has been a great deal of discussion as to the level of inclusion of LNG in REMIT. LNG is explicitly mentioned in the REMIT Implementing Act with respect to fundamental data, but nowhere else. In the 14th Questions and Answers document issued by ACER on 16th February 2016, it was stated by ACER that LNG is “undoubtedly” in REMIT. As a result, where any rule refers to “gas” it would include LNG. This has some implications that at the time of writing (Q1 2016) have still not been resolved. For example, gas transportation is to be reported using table 4, but these are clearly not suitable for LNG. Another issue is identifying exactly which contracts and trades are within scope, and for “delivery in the Union”, especially if the deal does not “land”. These issues are unlikely to be resolved by the go live date of 7th April. In general LNG trades would be reported using the “framework/execution” construct that is to be used for long-term gas trades. In the absence of concrete examples from ACER market participant will need to form their own view on how to report or take the appropriate advice.

4.3 WHO is covered by REMIT? Unlike other regulations, REMIT is applied according to the location of the trade, rather than the market participant. Therefore any market participant must register, report and comply with REMIT, even if they are based outside of the EU. The coverage extends to any wholesale market participant. This includes any market participant that executes energy contracts on an Organised Market Place, and those who buy and sell energy bilaterally. There are two “ends of the chain” that must also be considered: -

Producers – generally only sell energy. There is an exemption for small producers which will be examined in section 4.5. Consumers – those who buy power or gas only for their own consumption. In general such trading is not considered to be part of the wholesale market unless the economic unit in question has the capability to consume more than 600 GWh per annum.

Outside of these exemptions, anyone transacting in the above product list is covered by REMIT and must report the relevant data.

4.4 To be reported on demand The REMIT Implementing Act (Article 4(1)) specifies that some types of trade only need to be reported “at the request of the agency (ACER)”. These are as follows: -

Intragroup contracts, Contracts for the physical delivery of electricity produced by a single production unit with a capacity equal to or less than 10 MW or by production units with a combined capacity equal to or less than 10 MW Contracts for the physical delivery of natural gas produced by a single natural gas production facility with a production capacity equal to or less than 20 MW, Contracts for balancing services in electricity and natural gas.

The intra group exemption is in contrast to EMIR, where such trades must be reported. Those who only engage in internal and/or balancing trades must still register in the CEREMP. The practical upshot of this exemption is that these types of data do not need to be reported to an RRM or via an OMP. Instead the data must be kept and provided either to ACER or to the relevant NRA only when requested, and in any reasonable format.

REMIT Reporting Services and Solutions - July 2015 updated March 2016

It should also be noted that ACER have issued a “letter of no action relief” stating that they will not request any such data until at least January 2017. This does not preclude NRAs asking for the data in the interim.

4.5 Exemptions – 600, 10 and 20 As outlined above there are two types of exemption in terms of who and what is covered by REMIT. Firstly, there is an exemption for market participants who only purchase energy for their own consumption, known as “end users”. The REMIT Act (Article 2(4)) states that energy purchased by final customers is not considered to be part of the wholesale market unless it is to a final customer with a consumption capacity of more than 600 GWh per annum. It defines the capacity to be measured as “consumption at individual plants under the control of a single economic entity”. Secondly at the producer end, any single production unit with the capability to produce less than 10Mw of power, or 20Mw of gas is also exempt. Similarly, contracts to such units are also exempt. The REMIT Questions and Answers document differentiates between a site where the production facility has less than 10/20Mw of capacity, and a contract covering such a facility. The answer states that the contract must cover less than 10/20Mw of capacity, and the site must have less than that capacity. If a contract covers several sites, and the sum of the sites’ capacities is over 10/20Mw, the contract is covered by REMIT, even if each site is below that capacity individually. See answer II.4.32 in the Questions and Answers document for further details.

4.6 What is a “trade?” There is some confusion about the definition of a “trade” when it comes to REMIT. Any “wholesale” contract is encompassed by REMIT. This includes long-term contracts such as Power Purchase Agreement and tolling agreements.

4.7 What about EMIR? Any trade (or contract) in gas and power, whether physical or financial, is subject to the REMIT rules, that is, the manipulation and inside information rules apply to it. However it is also the case that some of those trades will also be under EMIR, if they are deemed “financial” trades and are not “spot” (the next section discusses how to determine financial status). The REMIT Implementing Act explicitly states (Article 6(5)): “Where persons have reported details of transactions in accordance with Article 26 of Regulation (EU) No 600/2014 [MiFID II] or Article 9 of Regulation (EU) No 648/2012[EMIR] their obligations in relation to reporting those details under Article 8(1) of Regulation (EU) No 1227/2011[REMIT] shall be considered as fulfilled.” As a result of this ruling, if a trade is reported under EMIR to a recognised Trade Repository, and it is also under EMIR, no further reporting of it needs to take place. Instead the Trade Repository is obligated to forward the trade on to ACER. This is despite the fact that REMIT requires fields of data that are not in EMIR. In the case of overlapping trades, ACER will not receive these fields. (It is likely in the future that this will change, since the fields are in the rules for a reason.). Since there is no requirement under EMIR to report orders, these must be reported to ACER via one of the other routes available, such as via an OMP or RRM, even when the trade is under EMIR. A combined TR/RRM will make handling this occurrence easier.

4.8 “What is a derivative”? - MiFID Annex I Section C The question of which commodity trades are actually considered “derivatives” is a complex one that is the subject of a great deal of discussion. The answer to this question is important: It determines which trade are under EMIR and therefore subject to be included in threshold calculation questions, and which ones are not. It also determines the “reporting route” of a trade when gas or power is involved. Copyright 2016 – ETR Advisory Ltd and Commodity Technology Advisory LLC

REMIT Reporting Services and Solutions - July 2015 updated March 2016

The trade status is generally determined in Annex I Section C of MiFID. EMIR references the same section for scoping purposes. The most important parts of the rules are sections C6 and C7, which under MIFID read as follows: (6) Options, futures, swaps, and any other derivative contract relating to commodities that can be physically settled

provided that they are traded on a regulated market and/or an MTF; (7) Options, futures, swaps, forwards and any other derivative contracts relating to commodities, that can be physically settled not otherwise mentioned in C.6 and not being for commercial purposes, which have the characteristics of other derivative financial instruments, having regard to whether, inter alia, they are cleared and settled through recognised clearing houses or are subject to regular margin calls; There are many subtleties to these paragraphs, which revolve around the words “can be” and “must be” physically settled. Following a ruling by the FCA on behalf of ESMA in 2013, the practical upshot of the rules has been taken to mean that physical forwards are only considered derivatives if they are executed on a venue that is considered to be a “multilateral trading facility” (MTF), or a “regulated market” (i.e. an exchange). Following this ruling, most broker platforms, that were until that point run as MTFs spawned a “non MTF” version, thus removing most physical forwards from EMIR (and MiFID). A new set of guidelines has been issued by ESMA on this topic, and it will go into effect on 7th August 2015. This should be consulted for further guidance. Note that spot trades are always outside of EMIR, and therefore all spot trades in gas and power are reported via REMIT. A spot trade is generally one, which delivers or settles within two days. Again there are many details contained within this statement that are beyond the scope of this report. MiFID II, which comes into effect on 3rd January 2017, will change this status again, in several respects. This includes the bringing into MiFID and EMIR of all emissions trades and certificates. Originally, emissions were part of REMIT, but they have been removed because of this upcoming change. Also, the new status of “OTF” (Organised Trading Facility) for many venues will require another look at which trades fall under which rule set.

4.9 Who reports? As outlined in section 4.1, there are several routes by which data can “get” to ACER: 1) 2) 3) 4) 5)

Via an RRM Via an EMIR TR Using an Organised market place Directly, if registered as an RRM Fundamental data – using a System Operator or RRM

Each of these will now be examined in turn:

4.9.1

RRMs

A Registered Reporting Mechanism is the key route by which data gets to ACER. Only RRMs can send data to ACER and access the ARIS database. In effect an RRM is the “TR” of EMIR and the place to which data is sent by a market participant. There are however some important differences: Primarily, an RRM is merely a forwarding mechanism to ACER, whereas an EMIR TR is the ultimate destination. Although there are retention requirements for an RRM, it purpose is to act as a “go between” market participants and ARIS.

REMIT Reporting Services and Solutions - July 2015 updated March 2016

Secondly, becoming an RRM involves meeting lesser requirements than to become an EMIR TR. There are still requirements about security, ability to provide the service and financial stability, but these are lower than for a TR. As a result, REMIT is likely to see more RRMs than EMIR saw TRs. Strictly speaking, any entity that sends data to ACER must register as an RRM, including the other 4 “types” of sender. However a full RRM will send most types of data to ACER if sent to it by a market participant, no matter what the data type. Since the requirements to be an RRM are lower than a TR, it is conceivable that a market participant will wish to become an RRM himself or herself. This would save them paying fees to another RRM and provide direct access to ARIS. The pros and cons of such an approach are discussed later in this report.

4.9.2

EMIR TR

As outlined above, any trade that is in both EMIR and REMIT does not have to be sent again to an RRM, under the “avoidance of double reporting” principle. As a result every EMIR Trade Repository is a route to ACER. Note that some EMIR TRs will also offer “full RRM” services, permitting all data to be sent to them for any regulation. However not all TRs offer such a service. Those that do are intending to act as a “one stop shop” to which all data can be sent, no matter where its “final destination”.

4.9.3

Organised Market Place

Any Organised Market Place (i.e. an exchange or broker platform) that supports the trading of covered contracts must “offer a data reporting agreement” under Article 6(1) of the REMIT Implementing Act. The first reporting data of REMIT on the 7th October 2015 covers only orders and trades that arise from such OMPs, with an official list of OMPs having been published by ACER. An OMP is obliged to offer data reporting (which can be charged for) on any data that arises from the platform. For an exchange this would generally cover the entire trade lifecycle, whereas for a broker platform it could only cover execution. Several later sections will look at OMP reporting in more detail. However it is worth noting that a market participant is not obliged to report using the OMP channel. Also note that some OMPs are offering “full RRM” services in addition to the obligatory offerings. Note however that due to the answer given by ACER in the 14th Questions and Answers document (III.2.43) there is a reduced liability for reporting if a market participant signs the data reporting agreement offered by an OMP or their preferred RRM. Each OMP has a different type of offering, and these will also be examined in section 5.4.

4.9.4

Direct reporting

As outlined above, it is possible for a market participant to become an RRM themselves, and this option in clearly being contemplated by some for the second phase of REMIT reporting. However such reporting is only permitted for off venue trades. In addition, ACER have, since February 2016, been discouraging market participants from following this route.

REMIT Reporting Services and Solutions - July 2015 updated March 2016

4.9.5

Fundamental data using a system operator

In addition to order and trade data, ACER will be collecting fundamental data, defined by the REMIT Implementing Act (Article 2(1)) as: “Information related to the capacity and use of facilities for production, storage, consumption or transmission of electricity and natural gas or related to the capacity and use of LNG facilities, including planned or unplanned unavailability of these facilities;” Generally it is System Operators such as TSOs, SSOs and LSOs who must report fundamental data. There are however gaps where market participants will need to report data themselves, via an RRM that offers the appropriate facility. This is examined in section 6.6.

4.9.6

Electricity Transparency Regulation (ETR) – 543/2103

The “ETR” rules came into force in January 2015. There require the reporting of electricity “transparency data” to ENTSO-E. The rules have some overlap with REMIT, both in terms of fundamental data and inside information. However, this is not the same rule set; compliance with one does not signify compliance with the other. Some platforms, such as National Grids MODIS platform will offer compliance with more than one rule set, but this is not always the case.

4.10 What needs to be reported and where is it defined? Depending on the data type and format to be sent in, a particular set of fields must be sent for each data item. The sets of fields, and their names are defined in the REMIT Implementing Act, which was produced by DG Energy. Details of what goes into each field are found in a document known as the Trade Reporting User Manual, the TRUM, which is produced by ACER. The TRUM is intended to be used by RRMs to establish how to send data to ACER. However, every market participant should be familiar with its contents. The TRUM is a very detailed document, which provides a great deal of guidance as to how to fill each field. ACER is also publishing a comprehensive examples document attempting to cover many types of trade in the market. (This is in contrast to EMIR, where very little descriptive information was made available by the regulator). The TRUM also contains guidance on many important issues, such as generation of UTIs and deciding which format to use. The TRUM document is evolving and at the time of writing the TRUM was on its first official version. An update is expected shortly after this report is published.

4.11 The UTI issue REMIT is a “two sided” reporting regime, in the same way as EMIR, and in both cases each counterparty to the trade must report it with the same unique identifier known as the “UTI”, the Unique Transaction Identifier. An issue prevalent under EMIR was that for bilateral trades, there was no mandated method for deciding either who generates the UTI, or how it should be generated, although ISDA did propose a methodology. In addition, since the EMIR UTI is 52 characters long, there is a transmission issue: how does the generating side get the UTI to the other in time for reporting.

REMIT Reporting Services and Solutions - July 2015 updated March 2016

Unfortunately the lack of a mandated solution meant confusion and issues for EMIR. Under REMIT ACER have tried to solve this issue by: -

Mandating that all OMP trades use the UTI generated by the OMP Promising an algorithm to be used for bilateral trades, based on the trade data

By mandating the algorithm, any market participant not using it MUST agree it with the counterparty. Failure to do so will result in the non-complaint party’s trade being rejected. This prevents larger counterparties “muscling in” on who generates the code and how. The algorithm is to be found in Annex IV of the TRUM. There are two algorithms: one for table 1 and one for table 2. Each uses certain trade attributes as parameter to come up with the UTI after using a hashing algorithm. While the algorithm does not work on every occasion it is likely to be widely adopted.

REMIT Reporting Services and Solutions - July 2015 updated March 2016

4.12 Schemas and Receipts ACER is defining standard XML schemas for sending data of each type to ARIS. These cover the four formats in which trades and orders are to be sent, formats for fundamental data, and others. In addition, a standard “receipt” is defined. This contains information about the status of a data transmission, in a standard form. The idea is that RRMs and others pass these standard receipts back to the market participant, who in turn can use it for reconciliation. This standardisation of response makes the design of software and systems much easier for REMIT than it was for EMIR, since each RRM essentially returns status in the same format. There is not yet a standard data format that is in widespread use across competing systems in the energy-trading world, in the same way the FIX or FpML are used in the financial world. “ACER XML”, as it is known, is likely to become that standard. Many RRMs have already announced that they will accept data in this format from market participants, and several OMPs are offering data downloads in ACER XML. There is therefore the distinct possibility that ACER XML will become the de facto data exchange format used across systems for all of these types of data.

4.13 Standard vs. non-standard, formats and phases REMIT defines two distinct classes of trade for reporting: “Standard” and “Non – Standard”. Implementing Act defines these as follows (Article 2(2, 3)):

The REMIT

‘standard contract’ means a contract concerning a wholesale energy product admitted to trading at an organised

market place, irrespective of whether or not the transaction actually takes place on that market place;” ‘Non-standard contract’ means a contract concerning any wholesale energy product that is not a standard contract; So a standard contract is any contract on a venue, or any contract that “looks like” a contract on a venue. At the same time, the TRUM provides 4 different formats for reporting orders and trades:    

Format 1 – “Standard supply contracts” Format 2 – “Nonstandard supply contracts” Format 3 – Electricity transportation contracts Format 4 – Gas transportation contracts

Each format contains a different number of fields (with format 1 containing the most at 58). These are all outlined in the REMIT Implementing Act and fully described in the TRUM. Format 4 is in fact the EDIGas 5.1 XML standard and is outlined in a more detailed REMIT manual to be found on the EDIGas web site. Note that for formats 3 and 4, market participant are only required to report secondary trades. Primary trades/allocations are to be reported by the system operator. The TRUM states the following: “Details of transactions executed within the framework of non-standard contracts specifying at least an outright volume and price shall be reported using Table 1 of the Annex to the Implementing Acts” The TRUM goes on to outline how this may work as follows: “With regard to “specifying at least an outright volume and price”, the Agency understands that once the volume and the price of the transaction is known to the two parties (which can occur after the delivery of the commodity), the transaction is complete. There is little difference between a physical spot/forward contracts traded at an organised market place with a price settled against an index and an execution under non-standard contract framework, which settles days after the delivery of the energy commodity, ends. In fact, both of these two contracts may not have a fixed price or volume before the delivery of the energy commodity starts and, most likely, both of them will be completely settled after the delivery period ends. Copyright 2016 – ETR Advisory Ltd and Commodity Technology Advisory LLC

REMIT Reporting Services and Solutions - July 2015 updated March 2016

However, while the physical spot/forward contract traded on an organised market place is reported with the contracted volume and the fixing index (which most likely is publicly available), the transaction executed under the framework of a non-standard contract has to be reported once the delivered quantity and the price are known, but still using Table 1 of the Annex to the Implementing Acts” In terms of dates only trades executed on an Organised Market Place need to be reported by 7th October 2015. Any other trade (i.e. bilateral trades), no matter in which format, need to be reported only from 7th April.

4.14 Report timing Data generally needs to be reported according to the following timing: On Venue T+1 day NA NA NA

Off Venue Format 1 T+1 day/T+1 month Format 2 T+1 month Format 3 T+1 day/T+1 month Format 4 T+1 day/T+1 month Fundamental data T+1 day Off venue trades are to be reported within one day if they “look like” a trade on a venue. Otherwise they are to be reported within one month of the event.

4.15 Back loading Like EMIR, REMIT has a back loading requirement, i.e. a requirement to report trades that were executed before the reporting date. Unlike EMIR, the requirement only applies to trades that were still active on the reporting date. EMIR also requires trades that were open on the day that the requirements came into force. If this were translated into REMIT requirements, you would need to go back to December 2011. For each reporting date, Market Participants have 3 months in which to backload the trades, i.e.: -

On venue trades which were active on 7th October 2015 must be back loaded by 7th January 2016 Other trades, which were active on 7th April 2016, must be back loaded by 7th July 2016.

Note that OMPs will not necessarily back load trades for market participants.

REMIT Reporting Services and Solutions - July 2015 updated March 2016

5 Reporting of orders and trades arising on Organised Market Places This next section of the report will focus on the requirements of the first reporting phase, which commenced on the 7th October 2015. It will begin by looking at the concept of “delegated reporting” under REMIT.

5.1

“Delegated reporting” under REMIT

The concept of delegated reporting is one where a market participant instructs another party to report for them. In general for bilateral trades, two types of delegation are commonly practiced: -

“Counterparty delegation” – where the one of the two parties to a trade reports on behalf of the other (which can only occur under a “two sided” reporting regime) “Third party delegation” – where an entity that is not party to the trade reports. The third party may be an OMP, an RRM or simply another party offering a service. In some cases the third party may be another internal entity within an organisation.

Under EMIR it is not possible to delegate responsibility for reporting, even if it is allowed operationally. The practical upshot of this is that if the delegate fails to report, it is the original market participant that has broken the rules. The implication of this is that market participants need to run frequent checks to ensure that those to whom they have delegated have met their obligation. REMIT takes a different approach to this: According to the REMIT Implementing Act Article 11(2), if one party reports on behalf of another, it becomes responsible for any failure to pass on the appropriate data, so long as the third party had the correct data to begin with. However, the Act does state that those delegating: “shall nevertheless take reasonable steps to verify the completeness, accuracy and timeliness of the data which they submit through third parties.”

In practice therefore, reconciliation is required under REMIT as well as EMIR, although perhaps not at the same level. The 14th REMIT Questions and Answers document, issued on 16th February 2016, strengthened the concept of delegated responsibility by suggesting that when reporting using the data reporting agreement provided by the OMP (or their preferred RRM), the above responsibility is relieved.

5.2 What is an OMP under REMIT? An “Organised Market Place” under REMIT is defined by the REMIT Implementing Act (Article 2(4)) as: (a) a multilateral system, which brings together or facilitates the bringing together of multiple third party buying and selling interests in wholesale energy products in a way that results in a contract, (b) any other system or facility in which multiple third-party buying and selling interests in wholesale energy products are able to interact in a way that results in a contract. These include electricity and gas exchanges, brokers and other persons professionally arranging transactions, and trading venues as defined in Article 4 of Directive 2014/65/EU [MiFID II] of the European Parliament and of the Council In practice, this means an exchange or broker platform, as well as some other platforms such as the Irish “SEM” market platform. ACER publishes a constantly updated list of the officially recognised OMPs on their web site, which at the time of writing numbers over 65 platforms. Exchanges, and broker platforms work differently, and the implications of trading on each will differ when implementing the first phase of REMIT reporting, as we shall see in the following sections.

REMIT Reporting Services and Solutions - July 2015 updated March 2016

5.3 OMP reporting – how should it work and what are the issues? The theory behind OMP reporting is that to meet the reporting requirements of on venue activity, market participants would need to carry out very little work. Each OMP is to register as an RRM, or select a preferred one, (not a “full” RRM) and each of their members needs to sign an agreement with them. Once signed, the market participant can focus on the second reporting date and not worry about the first.

Reality however is quite different, due to three issues: 1) Unknown data 2) Post trade events 3) Reconciliation

REMIT Reporting Services and Solutions - July 2015 updated March 2016

5.3.1

Unknown data

Several of the fields that must be sent to ACER are not generally known by the OMP. The key such field is the Beneficiary ID when the beneficiary is not the market participant (for example when acting as Agent). This is only a problem when such trades are struck, and the issue therefore does not apply to all market participants.

5.3.2

Post trade events

Generally trades executed on a broker platform are then handed over to the counterparties once struck. This means that post trade modifications and early terminations are not carried out by the broker, but between the counterparties themselves. Since the broker will not be aware of these events, they will need to be notified to ACER somehow. Some OMPs may offer the facility to make such notifications on their platforms and some will not, and in any case, the counterparties may wish to report post trade events via a “full RRM”. Those electing to use another platform to send initial executions to ACER, but not post trade events will face a “timing issue” if they use another RRM to report the events. This can be summarised by the following diagram:

The issue is that if a post trade event occurs on the same day as the initial execution, it will not be clear whether the OMP has reported. If the post trade event is then reported to the RRM, it may get rejected because the original trade will not yet be registered in the ARIS system.

5.3.3

Reconciliation

Since this report was first written, ACER have issued an answer stating that if a market participant signs the data reporting agreement of either the OMP, or their preferred RRM, the requirement to reconcile is relieved. However those choosing to either report the data themselves via a third party RRM, or those who ask the OMP to “send” data to a different RRM, will still have this requirement. Never the less, many will wish to try to use as few RRMs as possible since it is still best practice to perform a reconciliation. In addition, most of those who trade energy do not store their orders anywhere on their site, but will never the less wish to keep a copy of the data that the regulator has about them, both to be able to “replay” what has happened in the event of an investigation and also as a possible feed to a surveillance system. Those who trade across many OMPs, and who use them to report, will find this data gathering process quite difficult, since each OMP will make the data available in a different fashion.

REMIT Reporting Services and Solutions - July 2015 updated March 2016

5.3.4

Multiple agreements

Those who trade with many OMPs, and who use them to report the data, will need to sign a data reporting agreement with each, who will also have different offerings and pricing. This will lead to the need to manage many contracts and relationships. There has been an attempt to introduce a “standard data reporting agreement” by certain bodies, but it has not been universally adopted.

5.4 Different types of offering from OMPs During the run up to 7th October 2015, OMP brought their offerings to market. These fall into several categories: -

Direct reporting Upload service Sending the data to an RRM “Full” RRM EMIR TR/RRM

5.4.1

Direct reporting

An OMP is obliged to offer a service to report data that arose from activity on their platform to ACER. In that capacity, each OMP must somehow offer a direct service to each member of the platform to send the data to ACER. The OMP may charge for this service, and may also delegate the service to another party to deliver. But the agreement would be between the market participant and the OMP for data delivery and from February 2016 would have the liability characteristics just described. Generally the agreement would apply to data that arises on the platform, i.e. all order data, trade data that the OMP has (not including beneficiary information) and also events that arise on the platform (which for broker platforms excludes post trade events). However, some OMPs may offer to address these goals with their direct service, for example offering a service, which permits the reporting of post trade events (which would need to be notified by the market participant to the OMP). There is no obligation to use the OMP’s direct reporting agreement so long as the market participant finds another way to report, although the more recent ruling could make direct reporting more attractive. The previous section examined the issues with using one or more direct services. The next section will also look at this topic.

REMIT Reporting Services and Solutions - July 2015 updated March 2016

5.4.2

Upload service

A market participant may elect to upload the data from the OMP and find a way to send it himself or herself to ACER. If such an option was chosen, either for orders, trades or both, the market participant will need to obtain the data from the OMPs. Many OMPs intend to offer an upload service so that market participants can obtain such data. The data is usually offered in ACER XML, although some OMPs may only offer the data in other formats. It is generally easier to send the data on if it is available in ACER XML. However the recent ruling means that there will be extra liability when choosing this route compared to direct reporting.

5.4.3

Sending the data to an RRM

Some OMPS offer to send data to one or more (full) RRMs on behalf of the market participant. Under this arrangement, the OMP sends the nominated RRM the data, which forwards it to ACER on the market participant’s behalf. The benefit of this arrangement is that all of the data, which a market participant reports, is routed via one central point, improving reconciliation ability and control. If one adds off venue data to this equation the proposition is very attractive, although the downside of extra liability when not using the OMP’s preferred RRM needs to be considered. Each OMP may offer to send its data only to specific RRMs. Many OMPs are restricting this offer to RRMs that accept data in ACER XML.

REMIT Reporting Services and Solutions - July 2015 updated March 2016

5.4.4

“Full” RRM

An OMP may elect to become a “Full” RRM, i.e. they will offer the service of standalone RRMs alongside meeting their OMP obligations. They will accept orders and trades from any other OMP (whether sent directly or by the market participant) and off venue data will also be accepted. The full offering is provided together with one or more of the other offering types (the direct reporting offering is mandatory in any case). It generally suits market participants who mainly trade on that OMP, but will also have a certain proportion of other trades. However nothing precludes such an OMP being considered instead of another full RRM. Some of these OMPs also offer “phase 2” off venue reporting.

5.4.5

EMIR TR/RRM

Some EMIR Trade Repositories also act as “Full” RRMs (although not all offer this service). These TRs have added a service which allows them to act as RRM for any type of data under REMIT. Using an EMIR TR/RRM suits those who have activity across a variety of jurisdictions. Data can be sent to the “destination” no matter under which rule set it is found, and it can be routed to the appropriate destination. This arrangement has several benefits, such as the reuse of a solid infrastructure already in production, “future proofing” against new regulations, and also the ability to deal with one provider only. Some such TRs/RRMs will also partner with OMPs and services in order to acquire OMP data either directly or with an aggregator.

5.5 Options available to a market participant for OMP reporting Given the above offering types, a market participant has the following options when deciding how to meet the first phase of REMIT reporting obligations: -

Sign a direct reporting agreement with each OMP used Upload data from all OMPs and send it to one or more full RRM Ask OMPs to send data to full RRMs Use a aggregated service Combinations

5.5.1

Direct reporting agreements with all OMPs

Under this model, the market participant signs a direct agreement with each OMP, as outlined in section 5.4.1. However, if broker platforms are amongst the OMPs in question, an arrangement needs to be made to pass post trade events to ACER. If the OMP offers a mechanism themselves to report such events then this can be used. Otherwise a full RRM will need to receive such events. Similarly, data such as beneficiary ID and others will also need to be given to the OMP if the market participants trades as agent.

REMIT Reporting Services and Solutions - July 2015 updated March 2016

5.5.2

Upload data from all OMPs and sent it to one or more full RRM

Under this model, the OMP obtains data from each OMP themselves by uploading it onto their site. The OMP then sends the data themselves to one RRM, using either an internal mechanism or software.

An alternative to this model is for the OMP to send order data directly to ACER and for the market participant to upload trade data only.

5.5.3

Ask OMPs to send data to full RRMs

Under this model, the market participant signs tripartite agreements, getting the OMPs to send data to one or more RRMs. Since not all OMPs offer this service, and especially not to the same RRMs, the model may not be as “neat” as it first appears.

REMIT Reporting Services and Solutions - July 2015 updated March 2016

5.5.4

Use an aggregated service

Some services are available that can collect data from most OMPs, and provide it as an aggregated feed. An example of this is available from a market access and gateway service. The aggregated data can then either be forwarded to one RRM, or uploaded by the market participant and send to the RRM via an internal mechanism of software.

5.5.5

Combinations

It may be necessary to combine the approaches outlined above. Examples of combinations would include: -

Using some OMPs’ direct reporting services and uploading others – this may be used for a variety of reasons, such as service availability, whether “post trade events” is an issue or cost. Getting some OMPs to send data directly to an RRM and uploading others – could be used when some OMPs will send data to the OMP of choice whilst others require it to be uploaded. Reporting orders directly and trades by “upload and send”.

Each combination has its pros and cons, and the best choice will depend on each individual situation. The next section will examine some of these.

5.5.6

Is it possible for a market participant to become an RRM and send OMP data?

Until recently, the question of whether a market participant may become an RRM themselves and report uploaded data was ambiguous. However, shortly before the completion of the first version of this report, ACER published an answer, which stated that this is not permitted. This may be found in the 7th edition of the Questions and Answers document, section III.2.25.

5.6 Keeping records of OMP activity When an OMP sends data on behalf of a market participant it is considered best practice to obtain a copy of this data. The data is being sent to regulators, who may well launch investigations into a market participant based on its contents. It is therefore important to have a copy of this data so that any occurrence may be “replayed”. In addition, the data can be used as the basis of a surveillance system, which may well pre-empt any investigation by regulators.

REMIT Reporting Services and Solutions - July 2015 updated March 2016

5.7 Reconciliation While the REMIT Implementing Act permits “outsourced delegation”, as outlined in the earlier section, there is a requirement to “take reasonable steps to verify the completeness, accuracy and timeliness of the data”, although not necessarily when signing the OMP’s own agreement. If it is required, data must be reconciled periodically, in two ways:

“Receipts” received from ACER must be examined and compared with what has been sent The data records sent must be checked against source (from the OMP) and records

The method of reconciliation will depend on how the data has been sent. In any case, it is considered best practice to perform periodic data checks, to ensure that the regulator has the correct information. The answer of February 16th has given market participants food for thought in terms of their OMP reporting strategy. Many had desired a system where all OMPs would send data to their preferred RRM, consolidating the data and ensuring that agreements, reconciliation and replay were simple. However if the answer is taken at face value, it would appear that reaching such a state now gives rise to an unwelcome additional liability.

REMIT Reporting Services and Solutions - July 2015 updated March 2016

5.8 Pros and cons of OMP approaches Here we examine some of the considerations that could be borne in mind whether deciding on an approach to meet the requirements of the first phase of RENIT reporting, and the pros and cons of the approaches above:

Pros Direct reporting with each OMP

Upload and send

Send OMP data directly to RRMs or TR/RRMs

Aggregated service

 Very little work to do for market participants, particularly if trading on exchanges  Could be relatively cheap  May remove the need for reconciliation

Cons

 Different agreements with each OMP  Different pricing  How to report post trade events and beneficiary data  Need to obtain records of data sent  Little control  Complete control  More work for over data market participant to  Post trade events upload data and and beneficiary then send to information can RRM be sent  Good path to off  Could require specialist venue reporting software and/or processes  Requirement to reconcile  Little work for  Not all OMPs can market send data to the participants same RRM  Data is ready  Need to obtain consolidated. records of data sent  Less control  Reconciliation required unless RRM is “preferred” by OMP  Less work for  Extra cost market  Post trade event participant problem still exists  Reconciliation is possible in one  Likely to give risk place to new liability  Includes order unless the information service is the “preferred” RRM.

Considerations

Whom it suits

 Number of OMPs  Those who do not trade on  Whether broker many OMPs platforms are used  Those who mainly trade on exchanges  Those for whom reconciliation is not desired

 Number of OMPs  Those who trade on many OMPs,  Data volume especially broker  Internal platforms infrastructure  Those with many  Whether OMP off venue deals provides service and in which format

 Range of OMPs used  Preferred RRM

 Those who use a range of OMPs that can send to the same RRM (especially if it is the “preferred” one).

 Range of OMPs used

 Those who trade across many OMPs who do not want an internal solution

REMIT Reporting Services and Solutions - July 2015 updated March 2016

6 Meeting the full requirements – “Phase 2” While the October 7th 2015 deadline covered on-venue activity, the deadline of April 7th 2016 covers all other activity. This section will examine those requirements and some of the issues around them. Even at the time of the latest report update, one month before reporting starts, there are many unknowns around off venue reporting. It is therefore likely that additional changes will be made after the 7th April. The section will start by looking at the requirements around off venue trades and then look at different solution options.

6.1 Off venue reporting summarised The term “trade” encompasses a wide range of activity, ranging from off venue versions of on venue trades to long term contracts such as PPAs, long-term gas supply agreements, and others. These, together with secondary transportation trades form part of phase, 2, as does certain types of fundamental data. Phase 2 has two “deadlines” for sending data once it arises (usually when the trade is stuck): -

T+1 day – for “standard” trades and fundamental data T+1 month – for “non-standard” trades and contracts.

REMIT has several formats that can be used for phase 2 (on venue trades can only be sent in “format 1”). These, together with the reporting deadlines, can be summarised as follows:

Type

Format

Timescale

Comment

“Look alike”

T+1 day

i.e. the trade is off venue, but an equivalent contract exists on an OMP.

Simple

T + 1 month

Other trades with a fixed volume and price. May include single index trades.

Complex

T + 1 month

Contracts and trade that do not have fixed price and/or volume.

Framework/ Execution

2/1

T + 1 month

Framework contract (e.g. PPA) to be reported in Format 2 when signed/modified Executions to be reported monthly in Format 1 with volume and price, linked to the “parent” framework contract.

Secondary transportation

3/4

Fundamental

T+1 day/month

T+1 day

Power in format 3 and gas in format 4. Timing depends on “standard” status. •

Gas balances in storage

•

LNG unloads and reloads

•

LNG monthly load schedule

Each type of data will now be explained in turn:

6.1.1

“Look alike” trades

The REMIT Implementing Act defines a “standard contract as “a contract concerning a wholesale energy product admitted to trading at an organised market place, irrespective of whether or not the transaction actually takes place

REMIT Reporting Services and Solutions - July 2015 updated March 2016

on that market place”. Those trades executed on a venue are clearly standard contracts. However the definition also provides for off venue trades that “look like” trades executed on a venue. It is clearly not always easy to determine if a specific trade is a look alike. However, the “standard/non-standard” status” does not need to be reported, it simply affects the reporting deadline. This may find it easier to report all “candidate” trade within one day rather than to attempt to determine status.

6.1.2

“Simple” trades

The Implementing Act states that any trade with a fixed volume and price should be reported using table 1. The format permits one counterparty, up to one index, no volume optionality and simple price optionality. Any trade that has fixed volume and price, and can be reported using table 1 thus should be. There is an open question (at the time of writing) as to how to report off venue trades with one index, which can be reported using format 1, but do not have a fixed price. At the time of writing the market was divided by this issue and no clear answer had been given.

6.1.3

“Complex” trades

Any trade or contract that cannot be “fitted” into format 1, needs to be reported in format 2. While format 2 has less fields than format 1, it permits far more flexibility in terms of repeating fields and groups. It is possible to specify multiple: -

Counterparties Indices Volume Optionality bands Price Optionality Delivery points Commodities (i.e. gas AND power)

This format can be used for almost any occurrence. In terms of pricing, it is necessary to provide a formula or narrative based price of up to 1,000 characters. It is possible to use summaries, and as this field is not “matched” market participants have some flexibility as to what to put in this field. It is import to get the indices, and volume optionality fields correct in order to permit the regulators to run effective surveillance on the records.

6.1.4

The “Framework/execution” construct

The most “prominent” feature of phase 2 reporting is the description of long-term contracts and child executions. Using this “construct”, a long-term contact is described using format 2. This is reported once, unless the contract itself is modified, in which case it is resent using a “lifecycle” event. This would only apply to “real” modifications, such as a signed amendment. Actual volumes and prices are reported using a “child” execution, linked to the parent by setting the link ID field in the format 1 record, to the UTI (ContractID) of the parent framework. The documentation provided by ACER (TRUM Annex II) guides that executions should be sent to mirror the billing cycle relating to the framework, so that in a usual situation, one execution per month should be sent. However it does provide for sending executions more often. While there is no clear guidance on the topic, the market convention at the time of writing is that volumes over a month should be summed, and a weighted average price calculated, giving the volume and price to report in the execution. Execution are to have UTIs, but these are one sided and will not be matched.

REMIT Reporting Services and Solutions - July 2015 updated March 2016

Executions are to be sent up to one month after the volume and price are known. The ACER documentation states that the latest time that the “clock starts ticking” in when the month’s delivery is invoiced. However if a contract is involved less frequently than monthly it should be reported as monthly anyway.

6.1.5

Secondary transportation

REMIT requires that capacity and transportation trades (see section 4.2 for the full definition) be reported using formats 3 (power) and 4 (gas). Primary capacity and transportation is to be reported by the system operator. However market participants must report secondary capacity and transportation as part of phase 2. If the trade is “standard” it must be reported within a day, otherwise within one month. The format 3 uses an “ENTSO-E” format and format 4 uses EDIGas 5.1. There is a full REMIT manual for version 5.1 on the EDIGas web site, as well as the relevant section of the TRUM. The formats are complex and at the time of writing in March 2016 there is still a great deal of confusion over how these formats are to be constructed. So far, ACER have not issued any examples of these trade types. Until the end of 2015, many third party RRMs were not planning to report formats 3 and 4. However some third party RRMs have now reconsidered this, although less functionality is usually offered than for the mainstream formats. Some, but not all, secondary capacity and transportation platforms will also offer to report the trades as a service to their customers. It is likely that the issue of formats 3 and 4 will continue to occupy the market after go live on the 7th April.

6.1.6

Fundamental data reportable by market participants

This is discussed on more detail in section 6.6

6.1.7

Backloading

As for on venue activity, any trade or contract that is open on the 7 th April must be “back loaded” within 90 days. This is relatively straightforward, except for data reported using the framework/execution construct. Most framework contracts are long term, and will thus be subject to back loading. Execution generally do not have to be back loaded. But there is a question around when to report an execution due after 7th April (say for the month of April), when the parent framework is not yet loaded, since its deadline is in July. Answers from ACER state that you may not load an execution until the framework has been sent. This implies (although not all that explicitly) that if necessary one can defer loading the execution until the back loading deadline if desired. Market participants should rely on their own advice over whether to follow this strategy.

REMIT Reporting Services and Solutions - July 2015 updated March 2016

6.2 Meeting the full requirements – what are the options? We have already examined the options for complying with phase 1 of REMIT in the previous section. This section will examine how a market participant can meet the REMIT reporting requirements as a whole, considering both phases of REMIT reporting. It will focus on order and trade data, although there will also be a quick examination of fundamental data reporting. In general a market participant has the following high-level options available to meet the reporting requirements: -

Delegation – outsourcing reporting as much as possible. Direct upload via RRM – using a “full” RRM or TR/RRM to report all of the data, but without software. Direct sending to ACER – becoming an RRM. Software – Purchase or build software to be installed on site or as a “managed service” that gathers the data and sends it to one or more RRMs. Service – an off-site service, which can gather some of the data and to which the rest may be sent.

It is possible to combine the different methods to form one solution. We will first examine each of the options available. We will then look at how these may be combined into a workable solution.

6.2.1

Delegation

We have already examined delegation to an OMP in the previous section. However other forms of delegation are also commonly practiced in trade reporting: Counterparty delegation is the process where one counterparty of a two-sided trade reports for the other. This practice is very common for EMIR reporting, where a larger counterparty may report on behalf of a smaller one. Under EMIR, most recognised Trade Repositories explicitly recognise this type of delegation, allowing for shortened messages to be sent by the party offering the service so that contract details only need to be sent once. REMIT does not explicitly recognise such delegation. In fact the REMIT Implementing Act states (Article 6(7)): “Where a third party reports on behalf of one or both counterparties, or where one counterparty reports the details

of a contract also on behalf of the other counterparty, the report shall contain the relevant counterparty data in relation to each of the counterparties and the full set of details that would have been reported had the contracts been reported by each counterparty separately.” Never the less, it is likely that some counterparties may offer such delegated services to others. This is particularly likely where a larger company purchases energy from a smaller supplier that is in REMIT (i.e. has a capacity of more than 10/20MW). Such suppliers will be reluctant to set up technology to report a small number of trades, and so counterparty delegation makes more sense. Under REMIT, there is not much additional data that the delegating party needs to supply to the other in order to be able to report, making the process easier.

REMIT Reporting Services and Solutions - July 2015 updated March 2016

Third party delegation refers to a situation where an entity that is not party to a trade reports it for one or both sides. Whilst an RRM and OMP are clearly offering such a service, others may do as well. As with counterparty delegation, it is feasible that a larger entity may offer a smaller counterparty the service of reporting their trades, even if they are not party to it. Offering such a service does not necessitate becoming an RRM, since the larger counterparty can pass the trades on to an RRM who reports it to ACER. The principle of third party delegation may also be applied across the internal entities within an organisation. Whilst internal trades are not to be reported under REMIT, one entity within the organisation may report on behalf of another, to an RRM. If this occurs, third party delegation is effectively taking place. In both cases, those offering and using such services will need to consider how to get extra data items to the other party. For example, when using counterparty delegation, some fields, such as the beneficiary ID, or trader ID, will not be known by the party offering the service. In some cases this could add complexity when using such as service, although for smaller counterparties without complex trades there are usually simple solutions available. However, as mentioned above, there are not many of these fields under REMIT, especially since in most cases there will not be a separate beneficiary.

6.2.2

Direct upload to an RRM without software

It is possible to load data from a market participant’s site straight to a “full” RRM, or TR/RRM, without the use of an intervening system, by uploading a file with the data one a daily basis, or as required. Many will wish to use a spreadsheet or csv file for such an upload. However, because many energy trades are deeply hierarchical, this may be impractical, and instead the data will need to be uploaded in ACERXML, or some other XML format. It is expected that some RRMs will provide facilities to aid this process, either by offering tools, or by allowing data to be entered on a web site.

6.2.3

Direct sending of data to ACER

In some cases market participants may elect to become RRMs themselves, so that they can upload the data straight into ARIS. While this option is not permitted for phase 1 reporting, it is feasible for phase 2, and ACER are expecting several to take it up, although they have been discouraging this practice due to a possible high workload. There are certain benefits to becoming an RRM, in particular: - Fees – there will be no charge from ACER for data uploads - Control – the market participant has full control over what is reported - Access to receipts – the receipts are sent directly to the market participant - Access to information – applying to be an RRM gives access to information from ACER which is not currently being shared with other market participants - Lack of dependency – on another entity to be ready on time.

REMIT Reporting Services and Solutions - July 2015 updated March 2016

While these benefits may be attractive, becoming an RRM may be an onerous process. RRMs need to comply with financial and technical requirements, including additional technical requirements, which may be expensive to put in place. In addition, ACER will need certain information about the entity’s financial structure, which many may not wish to share. To become approved as an RRM, it is also necessary to pass ACER’s tests, which need to be conducted in line with their timetable. This may not suit the market participant. All of this needs to be considered when deciding whether to apply. In addition, the ongoing changes likely to arise after the REMIT go live means that becoming an RRM will require an ongoing investment. Multi entity groups may choose to elect one entity to become an RRM, or to set one up separately, in order to report on behalf of the others. This would mitigate the requirement to share financial information to a degree. It has been suggested to ACER that a “self-reporting RRM” category be permitted, where the requirements are less onerous. It may be the case that this will be available for off venue reporting. Note that according to answer III.2.25 of the REMIT Questions and Answers document, market participants may not report OMP data directly, even if they are also RRMs.

6.2.4

Using software

There are several software packages available, which can be used to collect data from across the organisation, and from OMPs, and to send the data to one or more RRMs. Such software could also be built by a market participant on a custom basis. The software is either installed on the site of the market participant or delivered as a “managed service” and provides a connecting service to the reporting destination. The majority of such packages will cover more than one rule set. For example, most packages that are planning to support REMIT will already cover EMIR in some form. Software packages (and builds) fall into two general categories: -

ETRM adapters – where a connecter is built from a specific ETRM vendor’s packages straight to an RRM Standalone software – software that is designed to take data from multiple sources and forward it to an RRM

Note that at least two ETRM vendors offer a standalone package, i.e. the software is not attached to their ETRM by default, and can in fact be used even if their ETRM package is not found on the site (although ready-made connectors to own product should be provided).

6.2.5

ETRM adapters

Most market participants will have at least one ETRM (Energy Trading and Risk Management) system installed in some form, which will be used as a foundation system to run parts of the business. Usually the ETRM will store many of the trades executed by the market participant.

REMIT Reporting Services and Solutions - July 2015 updated March 2016

Some ETRM suppliers will provide dedicated “adapters” directly from their system to one or more RRMs or TR/RRMs (software providers often prefer to work with TR/RRMs in order to reduce the number of adapters and relationships). The adapter will often sit alongside an offering used for EMIR, Dodd Frank or another regulation. It will examine the trades that are entered or modified within the system, and generate the appropriate data at the correct point in the trade lifecycle. It will do so by “looking” at the data and deriving the appropriate data file in the form required by the RRM (which will usually by ACER XML). It will then connect to the RRM and manage the interactions with it. Some adapters will also pull in ACER receipts and connect them back to the trades, providing the appropriate reports back to the user. Note that no ETRM solution on the market at present is known to handle orders, and this aspect of reporting will not be handled by such an adapter. The adapter pulls data only from the ETRM concerned. If a market participant has more than one ETRM, or trades which are not contained in any system, they will have the following options: 1 – Install adapters for the other systems as well – this will lead to many solutions being installed. If trades are not in a system at all, the equivalent option for those trades is to upload a file with a trade representation, as mentioned above. 2 – Import all trades into the ETRM – this will not usually be practical. As a result, use of an ETRM adapter is optimal for those with one such system, and few trades outside of it. In addition to considering trades that are not in the system, those who opt for the ETRM adapter route will need to think about: -

Orders – how are these sent to ACER and reconciled? OMP data – will the adapter only be used for off venue, trades? How does the adapter handle post trade events in such a situation? Enrichment and missing data – the ETRM will need to obtain some data from outside the system, such as the Unique Trade Identifier. How will the system obtain such data? In addition, certain IDs will need to be “enriched” (see the next section). Record keeping – how does the system store a record of what was actually sent to the repository?

The relative pros and cons of using such an adapter will be considered in section 6.4.

REMIT Reporting Services and Solutions - July 2015 updated March 2016

6.2.6

Standalone software

Standalone software is dedicated to sending regulatory data to one or more regulatory destinations, such as REMIT RRMs, EMIR TRs, TR/RRMs, Dodd Frank SDRs and others. Generally such software takes in data from a variety of sources, be it ETRM systems, other systems, spreadsheets or trading venues, and “routes” the data to the correct reporting destination. Some of the systems will also handle orders.

Adopting a “software” approach often has a higher up front cost. However there are several benefits that may be realised from such an investment, for example: - Protection – having all data stored within an “own” system can assist the process of investigation should it occur. This applies to both “reported” data, i.e. an audit that is looking for reasons why data is alleged to be misreported, or “alleged abuse” data, i.e. an allegation is made of market manipulation, in which case the data can be used by the market participant to assess the “what actually happened” and support a case. While such data may also be obtainable with other solution types it will be much easier to access meaningfully with a software solution. - Data warehouse - the installation of software may form the basis of a wider data warehouse which can be used for other purposes, such as cross commodity position management, credit management or as a feed to a surveillance system. Often the business case for a central data warehouse is hard to realise, when given standalone. However, once a warehouse of data has been created of regulatory reasons, the incremental cost of further solutions will reduce. Systems may be installed on site or offered as a “managed service”, and will offer a variety of connections for both input and output. They will generally perform the following key functions: -

Data acquisition Data enrichment Regulatory routing Communication with regulatory destination Reconciliation and tracking Reporting and audit

Now we will examine each function in turn:

REMIT Reporting Services and Solutions - July 2015 updated March 2016

6.2.6.1 Data acquisition The software will have different mechanisms for acquiring the data. The mechanisms fall into different categories: -

Data load – the software will permit data in different forms (e.g. a table on a database, XML file in a specific format, csv or excel file) to be loaded. Usually the system will specify the format in which the data is to be sent to the system, although many products on the market have a great deal of flexibility in how data is presented to the software. The system will have a variety of mechanisms to “pull” the data in, either in real time or in batch, and where in batch pulled in at regular intervals or when a specific event occurs (for example a file being placed in a directory). For REMIT, it is expected that most systems should be able to “read” ACER XML. Adapter – special adapters can be written into specific commercial systems, such as an ETRM system this is different to the “ETRM” adapter outlined above, since this type of adapter will pull data from an ETRM system into the stand-alone software. This type of adapter will be used in a variety of circumstances instead to a direct one: Firstly it would be used when the ETRM is one of many systems from which data needs to be pulled. Secondly, the direct adapter, or source ETRM may not have the required base data or enrichment capability required by the regulatory destination. Connection to trading venue – many standalone packages will have connections to trading venues. For REMIT these will be OMPs, and the systems will have different capabilities as to which sort of data they can pull, i.e. just trade data or order data too. Some system will pull data directly from OMPs. Others may use an aggregated feed that is commercially available; some will utilise existing feeds and enrich them. Direct – Some systems will permit manual entry of data straight into them, although this is the exception rather than the rule.

6.2.6.2 Data enrichment Data enrichment takes two key forms: -

Code substitution Completion of data

Most reporting regimes require certain data items to be in a certain form. For example. Data about entities will often need to be reported in a standard form such as the LEI (Legal Entity Identifier) or in the case of REMIT the ACER code. Other examples include product codes, trade identifier and codes for specific types of contract. A standalone reporting system will substitute codes that are imported into the system with the correct code for the appropriate destination. This is usually accomplished by aliasing i.e. the process of mapping the code in one system to another:

REMIT Reporting Services and Solutions - July 2015 updated March 2016

The substitution may be a simple switch, or more advanced. For example a specific contract may be translated into several fields’ worth of standard coding. When data is loaded into a stand-alone system, some of it may also be missing, and it will be the job of the software to complete the data. The software will employ a variety of means to do so, such as, matching data from different systems, using pre-defined product codes to determine other fields or linking together records from different parts of the trade lifecycle. Data enrichment is a key function of stand-alone software and is often one of the main drivers for purchasing it. 6.2.6.3 Regulatory routing A standalone package will usually offer functionality that can determine under which rule set a trade falls, and to where it should be reported, given its attributes. The package will usually look at attributes such as where it was executed (both in terms of country and venue), the type of trade, the commodity and the delivery date. For example, a trade will need to be reported under REMIT if it is: - A gas or power trade - For delivery in the EU - And has not been reported under EMIR A standalone regulatory reporting package will be able to examine the field attributes and determine which trades are “in” and which trades are out. In order to correctly evaluate the above rules, the system would also need to be able to determine which trades are in EMIR. In some cases the software will connect to a TR/RRM, which will move some of the routing logic “out” to the TR/RRM. Given that the rules change over time, the package vendor will need to provide regular updates to ensure compliance.

REMIT Reporting Services and Solutions - July 2015 updated March 2016

6.2.6.4 Communication with regulatory destination A regulatory package will offer built in and supported connections to different reporting destinations, such as EMIR Trade Repositories, REMIT RRMs, TR/RRMs and others such as Dodd Frank SDRs. In the case of REMIT the package will need at least one mechanism to send data to ACER, which could be via a dedicated adapter to an RRM, the support of a direct link to ACER (which would require the user to become an RRM themselves), by offering their own RRM service (which at least one vendor is offering) or another mechanism. One connection to a TR/RRM is also possible. By offering a connection to a specific destination, the vendor will need to undertake to support that destination going forward. Any change made by the destination will need to be supported by the package. The package will be able to support the specific language of the destination, turning whichever data is loaded into the correct set of events, whether in ACER XML or another, required by the destination. When considering a package, it is important to consider the destinations supported – if a package only offers certain destinations, the user will need to subscribe to that one and pay their fees, and an ongoing relationship will need to be established between the market participant (i.e. the user) and the destination. This is an important feature to consider when buying a package. Some vendors will support multiple packages even under one rule set. While this offers users a choice, it is important to remember that any connection offered by a software package will need to be supported by a vendor. If a vendor supports too many connections without many users per connection, then the enterprise may become non-viable for the vendor. The commitment by the vendor to the destination therefore also needs to be assessed. 6.2.6.5 Reconciliation and tracking A software package will not only send data to a reporting destination, but will also results back and track what has “happened” to any messages that have been sent to ARIS. When data is sent to ARIS, it results in a “receipt” being sent back to the market participant, but via the route from which it came, i.e., via the RRM in question. Receipts will generally relate to the status on a trade reporting and support three levels of validation: 1) XML is correctly formatted – the ACER XML has been received by ACER in a valid format. 2) The data has been “accepted” – the ACER XML and all of the codes in the message (such as the identifiers user for counterparty information) are valid and the data is considered “reported”. 3) The data is matched – the counterparty to the trade has also sent the data and it matches. Those using a software package should always pass level 1, since failure indicates an issue with the software. Most packages will offer tracking facilities to establish the status of trades and whether they have passed levels 2 and 3. Reports and workflow will be available to show trades that have not been validated yet, and more importantly highlight any “rejection” messages received showing that there is an issue with the data. The package should offer similar functionality for other regimes, especially for EMIR, which, as another “two sided” reporting regime, generally has the same type of validation, but without standardised receipts.

REMIT Reporting Services and Solutions - July 2015 updated March 2016

6.2.6.6 Reporting and audit A software package should offer functionality to store and “historise” any data sent to it, transformed by it, sent out of it, and any responses received. It should be possible for a snapshot of the state of the data to be taken at any point and to be able to replay all interactions through it. Such functionality is vital to a software package, since it permits the user to “prove” what has taken place on site, and how the market participant has complied with the rules. This will be especially important if an external audit, by a regular or another entity, requires information on why data was sent in a certain way, and also provides “protection” in the case of an investigation. Such investigations could cover reporting of data or alleged abuse. Under REMIT a regulator may also ask for more information about data. Having a system with appropriate functionality in place will permit the market participant to be able to respond to such requests quickly. REMIT has four categories of data that are not to be reported, but which must be made available “on request to regulators, as outlined in section 4.4. These are: -

Trades between internal entities Trades made with a power production unit with less than 10Mw of installed capacity Trades made with a gas production unit with less than 20Mw of installed capacity “Balancing” trades

It is useful, although not essential for a system to be able to store these so that they can be given to a regulator. If the software does not offer this functionality, it is still possible to obtain the data using other means, such as by pulling data from source systems. This is feasible since the data does not have to be reported as a matter of course. Getting such data into the system will also require effort. Users should consider the pros and cons of storing such data in the software. In addition to audit functionality, most software will offer a variety of reports into status, the quality of the data and the ability to drill into it. Some packages will also offer the ability to write custom reports.

REMIT Reporting Services and Solutions - July 2015 updated March 2016

6.3 Using a service There are many ways in which one can define a regulatory reporting service, but in this case we will define it as one which: -

Operates off the site of the market participant, Provides facilities that are over and above what a “standard” RRM or other repository provides.

Usually a service will be combined with an existing offering. There are two primary such services on offer to the market at the moment: 1. Combined with a confirmations matching service 2. Combined with a trading portal offering. Each provides value in a different manner:

6.3.1

Combining with a confirmations service

A confirmations service takes in appropriate trade details from counterparties that have executed OTC trades and “matches” them in order to confirm them. This is accomplished by each counterparty sending in a message to a centralised matching service. The terms are then compared and if they are the same they are matched. The primary such service in the energy industry offers a facility which extends the original message format and can then use the data in it to perform regulatory reporting. This was provided for EMIR where the service then forwarded the appropriate message to a chosen EMIR Trade Repository. For REMIT this same service will also act as RRM, so an extended message can be forwarded straight to ACER. Many OMPs also forward data directly to the service for phase one of REMIT, reducing the amount of work required in order to implement it, since data does not have to be uploaded and resent. However not all OMPs send data in this way.

REMIT Reporting Services and Solutions - July 2015 updated March 2016

This service particularly suits those who are already using it for confirmations. For others, it may involve more upfront work than other options, and this may also apply to those who need to “widen” the message. A “lite” version is also available for those with smaller volumes.

6.3.2

Combining with a trading portal

A trading portal provides a market participant access to many OMPs via one point. The portal is in a position to be able to report much of the data that arises out of interactions with OMPs via its facilities since it already has access to some of the data. The primary such portal in use in energy trading provides a facility to report this data, and has combined it with the ability to upload and therefore report off venue data.

For EMIR, the service permits reporting to one of several EMIR TRs. If the portal had the data it could be enriched and forwarded. If not, facilities were provided to upload the data and it could then be reported. For REMIT, a similar facility is provided, and the portal will also act as RRM. In addition to reporting, a service is offered to store reconciled and enriched data that has been sent, solving the reconciliation issue outlined earlier. The service in fact is offered in three parts: Firstly, access is provided to all OMP data that the service can obtain. It can be used with the resident RRM, uploaded by the user or sent to another RRM. Secondly the service allows the uploading of additional data so that it can be reported under EMIR or REMIT, and thirdly it can act as RRM itself. It is possible to take any combination of these services. This type of service particular suits those who already make extensive use of it, trade on many OMPs and do not wish to store the data themselves.

REMIT Reporting Services and Solutions - July 2015 updated March 2016

6.4 Comparing solution types The following chart compares the solution types and considers when each would be appropriate:

Delegation (via OMPs or other, e.g. to counterparty)

Upload using files to RRM

Pros

Cons

Considerations

When best

 Least amount of “work”, especially with heavy use of OMPs.  Can delegate off venue trades to one or more counterparties  Delegated responsibility under REMIT  Complete control  In some cases a simple solution  May be relatively cheap for smaller volumes  Control of data

     

 How many OMPs are traded on  Volumes  For off venue, number of counterparties and whether they offer delegated reporting

 Those who trade on few OMPs, or for small market participants who trade with larger counterparties offering a delegated service. Access to data still needs to be considered. Also consider new answer of February 2016.

 Volume  Complexity and variety of data

 For those with a small amount of data

 Volume  IT capability  Willingness to be transparent

 For larger players who have a deep IT capability and wish to maintain control

 Where is data?  Does vendor offer a connector and to which destination?  Cost

 For those where most data is in one RRM and vendor offers a solution

Direct send to ACER (i.e. become RRM)

 Full control  Access to information from ACER  No fees

Software – ETRM Adapter

 Could be a simple solution  Outsource work of understanding requirements to someone else  Maintenance of adapter by someone else

Could require many agreements Loss of control Post trade events for broker traded May end up expensive Loss of “control” Lack of access to data for use in investigations

 Could get complex if too many trades  Will need to get files into appropriate formats  Difficult to handle life cycle events  How to get how of OMP data  Hard to make work for orders  Possible increase in liability  Will need to pass ACER security and financial requirements  Will need to pass ACER tests  Subject to audit  Not permitted for OMP data  Possible increase in liability  Only works if most data is in one ETRM  Relying on someone else for solution  How to handle orders and OMP trades

REMIT Reporting Services and Solutions - July 2015 updated March 2016

Pros Software-Standalone  Another party has to worry 

   

Service

  

about multiple regulations and formats Software will keep up with rules about regulation applicability Event reconstruction made easier Data is enriched Outsourced maintenance Full protection in case of audit from both “alleged abuse” and reporting investigations by regulators Reuses existing infrastructure May be cost efficient Maintenance of controls whilst outsourcing some work and responsibility

Cons

Considerations

When best

 Could be a complex implementation  May involve larger up front investment

 How many sources of data?  How many regulations need to be met?

 Those who operate under multiple regulations and have multiple data sources

 Lock in to vendor who could raise prices later  Some loss of control  In some cases initial implementation may be expensive  May involve an increase in liability

 Existing use of service  Cost of implementation  Relationship with vendor

 Those who already use the service who do not have a large implementation to extend its use to regulation.  Those who wish to outsource as much as possible

REMIT Reporting Services and Solutions - July 2015 updated March 2016

6.5 Combining solutions In many cases, adopting one solution type may be too simplistic an approach to meeting the regulatory requirements. Instead a combination of solutions may be more optimal. The combination could be temporary or permanent.

6.5.1

Temporary combinations

The most obvious temporary solution is one that lasts for REMIT phase 1, and is then replaced for phase 2. For example, it may be optimal for phase 1 to sign direct agreements with OMPs, but to then plan to use standalone software for phase 2, not only for off venue trades but for all trades. This has the benefit of allowing more time for a solution to be implemented, whilst phase 1 is “taken care of”. OMP trades can be reported from 7th October by the OMP and the focus can be on reporting off venue trades using the software by 7th April. After that date, OMP trades can also be brought into the system when ready, even if the OMP does the actual reporting to reduce liability. The data can then be used so that a full record of all activity is kept. This approach works best when the OMPs are exchanges, since the post trade event issue does not need to be handled. The approach could also utilise a service on a temporary basis, if the service is easy to implement.

6.5.2

Using a combination of OMP reporting and uploading

In some cases, it may be feasible to use each OMP’s service to report on venue orders and trades, but to load off venue trades to a separate RRM. It is likely that this combination will be used by many, especially by smaller market participants who only trade on a few OMPs and do not have a high volume of off venue trades, which is a common scenario. Where the OMP offers a “full RRM” service, the combination will involve using the same provider. Given the later ruling on liability, this option may now prove to be more popular.

Variations of this combination are also possible. For example, a service could be used for OMP trades alongside an upload to elsewhere.

6.5.3

Using a TR/RRM

Some EMIR Trade Repositories (TR) also offer a “full” RRM service, thus turning them into a “one stop shop” for regulatory data reporting. When considering holistic requirements for reporting, including EMIR and others, there are benefits in selecting such a destination, as outlined in section 4.9.2.

REMIT Reporting Services and Solutions - July 2015 updated March 2016

A TR/RRM may also accept data from OMPs, as with other full RRMs, making on venue collection easier. Such a setup may be represented as follows:

Under such a setup, the market participant only needs to send data to one destination. However, if a specific venue will not send data to it, direct agreements will be necessary with those OMPs only. In addition to EMIR data (whether energy or not) the TR may handle data under other current or future rules, such as the Swiss FinFrag and MiFID II. The approach can also be combined with software, removing the need for multiple adapters, as follows:

REMIT Reporting Services and Solutions - July 2015 updated March 2016

6.5.4

Using a service and software

There are several ways in which a service can be combined with software: Firstly, if using either type of service, the software could be the conduit by which trades (or just off venue trades) get to the service. This allows the service to act as the “destination” for REMIT but for the software to route trades to their destination for other rules. It also allows the software to collect data from across the enterprise.

Alternatively, one can make use of a service that aggregates OMP data to feed software, which then further enriches it, and then routes the software to the appropriate destination.

REMIT Reporting Services and Solutions - July 2015 updated March 2016

6.5.5

Other combinations

There are many other combinations of solution possible. Each market participant will need to assess their own situation to establish the best combination.

6.6 Fundamental data In general fundamental data is to be forwarded by the relevant system operator to ACER. There are however, some gaps in this. The REMIT Implementing Act Articles 8 and 9 specify (as also outlined in ACERs Manual of procedures) that fundamental data is to be reported by the following parties: -

On behalf of market participants, ENTSO-E and ENTSOG shall report to the Agency information through European Transparency Platforms TSOs for electricity and gas or third parties on their behalf shall report to the Agency information related to nominations

LNG System Operators on their behalf shall report to the Agency information related to LNG facilities and cargos Storage System Operators shall report to the Agency information related to gas storage facility or group of gas storage facilities through a joint platform Market participants or Storage System Operators on their behalf shall report to the Agency the amount of gas the market participant has stored at the end of the gas day

The three types of data to be reported by market participants from the 7th April onwards are: -

Gas balances in store – to be reported on a daily basis LNG unloads and reloads – to be reported on a daily basis Next month’s planned unloads and reloads – to be reported for the next month at a daily resolution.

As with formats 3 and 4, there has been a lack of information as to how this data is to be reported, and the major RRMs have only adopted its reporting later in the cycle. It is likely that the schemas, about which there are many unanswered questions, will be revised after go live.

6.6.1

Who is responsible for reporting and reconciliation of fundamental data?

Several previous sections have mentioned the requirement to reconcile data that has been sent to ACER via a delegated party. There is an outstanding question as to whether this level of reconciliation is also required for fundamental data, in the same way as for other data referred to in the REMIT Implementing Act Article 11(2) and examined in section 5.3.3. Many in the market have not yet considered this requirement, and opinion is still divided as to whether reconciliation of fundamental data is necessary. Market participants are advised to think through their stance and plans carefully.

REMIT Reporting Services and Solutions - July 2015 updated March 2016

7 Planning for compliance as a market participant – tasks to carry out In order to plan a REMIT solution it is recommended that the following steps be carried out, at a minimum. We will examine the steps at a high level only. Each market participant will have a different situation and therefore the appropriate plan will differ from case to case. Each section here is brief, since they will rely on the tools provided in previous sections. [Note that sections 7.1 to 7.5 were not updated in later versions of the document.]      

Registration Product list Locate data Overall solution shape Phase 1 solution Stay in touch and implement

7.1 Registration It is recommended that registration be commenced as soon as possible. Under some NRAs, the deadline for registration commencement was 17th June and others will require registration shortly. While registration does not have to be completed before reporting starts, there is little downside to entering the information required as soon as it is available.

7.2 Product List It is important to create a list of all eligible products traded, including those which must be reported as a matter of course and those which needs to be reported “on demand”. The list will form the basis of decisions as to solution shapes, and allow a market participant to work out where the data actually is. Once the list is created, it is necessary to determine under which format it will be reported under REMIT, since the data will need to be located. If the trade is “on venue” it will be in the first format. Other trades may be in one of the other 3 formats as well. Part of this step involves listing which OMPs the products are traded on, and whether they are exchanges or broker platforms. This will be a major determinant in establishing the solution shape.

7.3 Locate data Once the product list has been created, it is important to understand where the data for each field required is located. For on venue trades, the location may well be the venue itself (and this is likely to be the case for orders). Even if this is the case, it is worth noting whether a copy also reside on site. Each field in the TRUM needs to be mapped, even if at a basic level, in order to ensure that there is a route for the data to reach ACER.

7.4 Overall solution shape This stage is possibly the most important one of preparation, working out the “solution shape”, i.e. whether to use OMP reporting, delegation, software, a service or a combination, as has been examined above. It is recommended that vendors, including RRMs and OMPs only be selected once the shape has been established. Having said this, it is worth looking at what is available before establishing the shape, although this must be with reference to the specific needs and satiation of the market participant. As such therefore this is very much an iterative process.

7.5 Phase 1 solution Once the overall desired shape is known, it is vital to work out how the requirements of phase 1 will be met, without delay. The shape chosen will be partly determined by the overall shape, and partly by the other factors examined in

REMIT Reporting Services and Solutions - July 2015 updated March 2016

section 5.5. This is also the stage at which to decide whether to adopt a temporary solution, or a permanent one, as examined in section 5.8. This is also when an RRM should be chosen. It is tempting to leave the selection of a phase 1 solution to the “last minute” on the basis that OMPs, or certain services, will carry out reporting. However, it is recommended that this not be relied upon until all data agreements are signed. Even after this stage, it is useful to have a contingency plan in case an OMP fails to report, or fails to provide data to a third party, on the first reporting date.

7.6 Phase 2 solution The phase 2 solution needs to primarily consider how all of the required data will be captured and sent to the selected RRM. There are several sources of data that need to be discovered and linked to the RRM, which correspond to the types of data outlined in section 6.1. Each is likely to have a different source: -

Look alike, simple and stand-alone complex trades - are likely to come from an ETRM system. These will need to be sourced and somehow transformed for sending to the RRM. This will happen in different ways depending on the solution shape chosen Framework contracts – are unlikely to be stored in any system. A mechanism will need to be found to capture the required data elements, and to send them to an RRM, either ACER XML or via another method. Some dedicated regulatory software will permit users to manually enter the framework and transform it into ACER XML. Some services, and RRMs will also provide a GUI, which permits such entry. Executions – Sometimes these are stored in ETRM systems, in which case the data can be extracted for onwards sending. At other times, the data will need to be manually captured; either using dedicated software or possibly manually entered into a service or RRM. Transportation and capacity – while this data is sometimes to be found in an ETRM, it often is not and will need to be sourced from where it is stored. Many will need to then transform this into the appropriate XML format, although some RRMs may permit it to be entered using a GUI. Expect more activity in this area in the months after the 7th April. Fundamental data – market participants must report the fundamental data as outlined in section 6.6. This data is unlikely to be in any RRM. It will therefore be necessary to find the data and possibly transform it into the correct format before it is sent to the RRM

7.7 Stay in touch and implement While this section is intended as a guideline, the solution must be approached as any project, with a budget, timeline and scope. It is every project manager’s job to keep within these three objectives, and a REMIT project is no different. There are however, some important differences, in particular: -

The timeline cannot be moved Neither can the scope, at least not by the market participant. The requirements may change later.

This last two points are important: while a market participant may not change scope, the details around the rules change on a daily basis, and these must be kept up with and understood during the implementation and also after it. In some cases, there will be ambiguity over a requirement. In order to address these it is important to stay in touch with others facing the same issues, until definitive rulings are created. Having a moving target and scope, controlled by others, with ambiguity, and a fixed timeline is challenging. It is important to equip oneself with the tools to meet this challenge as best as possible.

REMIT Reporting Services and Solutions - July 2015 updated March 2016

8 What will happen next and getting further help At the time of writing, there were still many unknowns around the reporting of phase 2 data even a few weeks before the go live. On February 16th, ACER announced that the schemas will change in spring 2017. We can thus expect a “phase 3” over the coming months. Updates to developments are also available on www.energytradingregulation.com. The authors listed on the inside cover may also be contacted for further assistance.

8.1 Useful links and documents Many of the documents that are useful for better understanding REMIT can be found in the REMIT Portal: https://www.acer-remit.eu/portal/public-documentation The following table outlines the key documents contained there: Name REMIT Regulation REMIT Implementing Regulation TRUM TRUM Annex II Examples XML Trade Examples TRUM Annex IV UTI Generator MoP on data reporting Schemas Questions and Answers Transaction Reporting FAQ

Description The original “Level 1” REMIT Act 1227/2011 approved by the European Parliament. The Implementing Act 1348/2014 approved by the Directorate General of Energy, European Commission which specifies how reporting is to be carried out. The Transaction Reporting User Manual, which provides detailed guidance on the formats, and a field-by-field description for each format. Provides a description of how data is to be reported with a long list of examples. Also explains how executions work. These are XML files that match the examples in Annex II The ACER UTI generation algorithm and accompanying documentation. The Manual of Procedures on data reporting which include a field-by-field description of fundamental data. The XSD files which define each data format. A frequently updated document which answers questions raised about the different parts of REMIT. A document, which contains many questions and answers about REMIT transaction reporting.

The EDIGas REMIT Manual for reporting gas capacity and transportation can be found at: http://www.edigas.org/download/00-Remit-Implementation-Guideupd5.zip

REMIT Reporting Services and Solutions - July 2015 updated March 2016

9 Solutions directory and listings This section lists the various solutions that are on offer to market participants in order to comply with REMIT Reporting as outlined in this guide. It has been compiled using publicly available information, which has been edited to suit the style of this guide. It is recommended that market participant contact each vendor for further details of their solutions. The authors make no warranty for the accuracy of any information contained in this document. The listing will be divided into the following sections, broadly in line with the categories mentioned in the guide i.e.:   



RRM/TRs Other “Full” RRMs Software o Stand alone o ETRM extensions Services

The sections will offer a paragraph of each solution. The information provided is based on public information available at the time of writing; Updates and additions to the list will be made periodically. The authors bear no responsibility for any errors or omissions from the listings. Vendors who wish to send in corrections are welcome to do so by communicating with the authors using the contact details provided on the inside cover of the guide.

REMIT Reporting Services and Solutions - July 2015 updated March 2016

9.1 RRM/TRs This section lists RRM/TRs as outlined in section 5.4.5, as follows: -

REGIS-TR CME ICE TradeVault Europe

Both REGIS-TR and ICE have confirmed that they will act as full RRM/TRs. The status of CME is not yet clarified. 9.1.1.1

REGIS-TR

Product REGIS-TR covers reportable data under REMIT including transactions, filled and unfilled orders, standard and nonstandard contracts as well as historical data back loading. Regardless of the source and file format, reporting entities can easily transmit files to REGIS-TR via multiple connection options (SOAP API Web service, sFTP and manual upload). All transmitted data will be normalised, enriched, formatted and validated by REGIS-TR to ensure timely and successful submission to ACER. REGIS-TR’s reporting portal provides a single way to monitor all reportable trade activity via a single interface. Using a customisable dashboard, users can check data on demand; monitor their reporting status in real-time and handle exceptions in an efficient manner. The web-based interface grants secure and access to the platform with no additional hardware or software requirements. In line with its aim of becoming a leading European integrated solution for regulatory reporting, REGIS-TR will support future European regulatory reporting requirements, thereby ensuring minimised client effort and compliance with all regulations across jurisdictions. REGIS-TR is a sponsor of this report and a fuller outline of the solution can be found towards the end of this report. Vendor and website REGIS-TR is a joint venture between Deutsche Börse Group and Bolsas y Mercados Españoles. www.regis-tr.com

REMIT Reporting Services and Solutions - July 2015 updated March 2016

9.1.1.2

CME

Product While the CME web site has a “REMIT” page there is no indication as to whether a full RRM service will be offered alongside the Trade Repository service. Vendor and website CME Group Inc www.cmegroup.com 9.1.1.3

ICE TradeVault Europe

Product ICE have announced that their TradeVault Trade Repository will function as a full REMIT RRM. ICE will also send data that arises from activity on their own OMPs to ACER via the TradeVault. The TradeVault will leverage its existing TR service to deliver a comprehensive REMIT reporting solution to market participants. Market participants will be able to upload non-ICE data using ICE’s eConfirm front-end platform (via XML API, tab delimited file upload or manual GUI report entry) or by uploading the ACER XML format files provided by their non-ICE exchanges/brokers. Market participants will also be able to use TradeVault for the reporting of bilateral OTC transactions when reporting starts for trades executed outside of OMPs on 7 April 2016. This will allow market participants to consolidate all their REMIT reportable data in a single RRM to allow ease of reconciliation. Vendor and website Intercontinental Exchange Inc www.theice.com

REMIT Reporting Services and Solutions - July 2015 updated March 2016

9.2 Other “Full” RRMs Other “full” RRMS, as outlined in section 5.4.4, currently known are as follows (services are outlined in the next section): -

Abide Financial Nordpool Spot Polish Power Exchange Seeburger

9.2.1.1

Abide Financial – TransacPort RRM

Product Abide Financial is an independent, UK Approved Reporting Mechanism (ARM), overseen by the FCA. The company offers process management and post-trade transaction data analysis facilities that enable clients to meet reporting requirements under MiFID EMIR and evolving regulations like REMIT, ASIC and MAS. Clients reporting under REMIT through Abide will benefit from:     

Extension of our established TransacPort EMIR and MiFID transaction reporting and data management service to REMIT. Centralised data reporting and reconciliation for full EMIR, MiFID and REMIT compliance Data format flexibility – ACER XML, CpML, CSV. Reporting efficiency through using the same RRM as OMPs and fewer interfaces with ACER ARIS. Connectivity to other RRMs

Abide Financial provide a full REMIT service for reporting orders-to-trade and transactions to the ACER ARIS database:       

‘Standard’ and ‘Non-Standard’ contracts Orders to-trade-placed on Organised Market Places (OMPs) including filled and unfilled orders (and modifications thereof) Transactions executed at OMPs Transactions concluded outside OMPs Inter-group transactions Trade lifecycle events Transaction data backloading

Data enrichment will utilise client static or reference data deposited in TransacPort RRM during the onboarding process. Vendor and website Abide Financial www.abide-financial.com

REMIT Reporting Services and Solutions - July 2015 updated March 2016

9.2.1.2

Nordpool Spot – REMIT Reporting Service

Product Nord Pool Spot offer all market participants an end-to-end service that ensures REMIT obligations are carried out in an efficient, secure and easy manner. The service allows members and any other market participant to report transactions (including orders to trade) relating to standard and non-standard contracts. The service can be used to report all trades at Nord Pool Spot/N2EX markets, at any other Organised Market Place (Power Exchange) or outside organised market places (OTC contracts). Features include:     

Automated reporting of orders and transactions on Nord Pool Spot/N2EX day-ahead and intraday markets directly to the ACER system (ARIS). All reporting will be carried out in the ACER specified XML format. The REMIT Web Portal gives market participants oversight of the reporting process, including access to reported files, confirmation receipts and alerts. Reporting of electricity and gas orders and transactions at other Organised Market Places (OMPs) than Nord Pool Spot/N2EX or outside OMPs. In addition to this, Nord Pool Spot will deliver market participants orders and transactions to a third party RRM of their choice.

Vendor and website Nord Pool Spot www.nordpoolspot.com

REMIT Reporting Services and Solutions - July 2015 updated March 2016

9.2.1.3

Polish Power Exchange – RRM TGE

Product The Polish Power Exchange, POLPX will offer a “full” RRM, RRM TGE. It enables the following:   

Reporting of transactions, including orders to trade, concluded through an organised market place (as of 07.10.2015). Reporting of OTC transactions (as of 07.04.2016). Backloading of the existing contracts (07.10.2015 - 07.07.2016).

The reporting service is carried out through the RRM to the extent required in the Implementing Acts and according to the format consistent with ARIS (ACER REMIT Information System) which is ACER's central IT system that processes REMIT-related data. A dedicated web application - rrm.tge.pl - enables monitoring of the reporting process by the authorised representatives of market participants including:      

Reviewing a summary statement of recent reports. Detailed view of reports sent to ARIS. Downloading reports sent to ARIS. Viewing and downloading feedback messages from ARIS. Verification of the summary of applied charges. Access to notifications about major events in the course of the reporting process, e.g. report acceptance by ARIS or an error occurrence.

Vendor and website Towarowa Giełda Energii S.A – Polish Power Exchange - POLPX www.tge.pl 9.2.1.4

Seeburger

Product Seeburger’s RRM is offered alongside their stand-alone software solution (see section 9.2.1.4). The RRM allows to secure, confidential and complete transfer of messages to ACER. It keeps the entire reporting channel in view, and meets the requirements of legislators including ACER. Benefits include:     

English support Operation in ISO 27001 certified data centers in Germany. Short contract periods - 3-month notice period Optional: Connect with OMP partner Optional: Executive Dashboard

Vendor and website Seeburger AG www.seeburger.com

REMIT Reporting Services and Solutions - July 2015 updated March 2016

9.3 Software 9.3.1

Stand-alone software

This section lists known stand alone software packages, as described in section 6.2.6. The following packages are listed: Vendor Broadpeak eOpt CH Consult OpenLink Seeburger Seven2One SunGard 9.3.1.1

Package K3 eComply DeltaConx CubeIntelligence – Regulatory Cube EMIR/REMIT Trade Reporting Solution Regulatory Reporting Solution XDM Compliance

Broadpeak K3

Product K3 is a user-driven integration platform complete with associated analytics and meaningful data insights. The product is a single stop for compliance reporting, whether reporting under Dodd-Frank, FATCA, GATCA, EMIR, REMIT, Canada OTC Regulations, CAT or another regime. K3 comes with adapters and experience to connect to multiple regulatory destinations, which include DTCC, ICE, REGIS-TR, EFETNet and ICE TradeVault. K3 also offers a warehouse that tracks and supervises every element of data and interaction with both data sources and regulatory destinations. It allows users to choose whatever data store they wish to persist flowed data, whether it is relational or non-relational. The product connects many types of application, with off-the-shelf adapters to everything from Exchanges to Salesforce to older legacy applications. K3 is also designed to operate with any messaging bus. K3 is used by the world’s largest companies to solve ongoing compliance challenges. As regulatory requirements change, users can adjust on the fly to stay compliant. Vendor and website Broadpeak Partners Inc www.broadpeakpartners.com

REMIT Reporting Services and Solutions - July 2015 updated March 2016

9.3.1.2

eOpt eComply

Product e·Comply is a Regulatory Reporting application, designed specifically with the reporting obligations under EMIR and REMIT in mind. Some key features include:      

Third party trade reporting - can be offered as a Service Comprehensive entity mapping possibilities Direct upload of Orders to Trade Trade background information management Exhaustive Reporting capability Service based application with complete visibility to the Compliance responsible users

Other benefits include:      

Simple and Robust - In design and functionality Configurable at the Users' level Realtime or Batch Reporting Requires minimal User intervention for normal functioning Agile in adapting to changes in Regulatory Requirements Optimally Priced to suit a wide range of needs

e·Comply has in-built Interfaces to downstream Repositories, like REGIS-TR and has open interfacing to several upstream systems for Trades and Orders to Trade. Direct upload from Broker platform feeds allows online processing of Orders to Trade and Just-in-Time Reporting. Bespoke interfacing can be taken up under Fixed Price Contracts. Vendor and website eOpt Solutions www.eOpt.org

REMIT Reporting Services and Solutions - July 2015 updated March 2016

9.3.1.3

CH Consult - DeltaConx

Product The deltaconX Regulatory Platform is a software solution catering for the European Financial and Energy Market Participants. It enables users to meet various regulatory requirements such as EMIR, REMIT, StromVV, FinFraG and MiFID II. deltaconX supports full automation and Straight through-Processing (STP) of all the reporting relevant data, which is received by one or more source systems. Dynamic error handling allows users to identify issues and actively supports data correction or completion e.g. UTIs or various timestamps. The product supports CpML and a variety of APIs, as well as an Excel interface. Various features such as defining “default values” and “data mappings” reduce adaptation time for interfaces to ETRMs etc. The rules engine permits users to configure complex internal delegation scenarios such as company structures. deltaconX allows users to gain full control over all reporting processes across:     

Corporate groups Source systems Asset classes Transaction types Reporting channels

A dashboard allows users to monitor all the necessary processes in the selected timeframe. “Personalised filters” deliver the requested information enabling risk managers, back office or technical staff to adapt the frontend to their needs. The product logs every user interaction and provides full audit control over all system processes. deltaconX is offered on a SaaS basis which avoids the need for IT hardware and software licenses along with necessary system maintenance and release upgrades. Included are all of the required adaptations requested by the regulators or trade repositories.

Vendor and website CH Consult GmBH www.deltaconx.com

REMIT Reporting Services and Solutions - July 2015 updated March 2016

9.3.1.4

OpenLink CubeIntelligence – Regulatory Cube

Product The CubeIntelligence Regulatory Cube is a stand-alone piece of software helps market participants better comply with regulatory requirements by:      

Permitting rapid development of adapters to OpenLink and other source systems. Processing the data in order to prepare it for regulatory trade reporting through data enrichment and the application of certain rules. Executing operations like auditing, reporting and error tracking before the data is transmitted. Providing an easy and robust trade reporting system to third party repositories. Custom reporting, drill-down and custom aliasing capabilities. Performing threshold calculations and portfolio reconciliations under EMIR.

The system has several components: The Cube ETL Layer manages data acquisition. The layer can “extract, transform and load,” pull data from source systems and transform it into required formats and perform lookups such as LEI and UPI transformations. It can also apply complex rules to the data, for example, on a trade, leg or portfolio basis, deriving the trade status to be sent to the TR and RRM based on changes in the appropriate fields. The system comes pre-configured for EMIR and REMIT. The Regulatory Cube processing engine of the solution, it takes in trade and other data from source systems, processes it and places it in the data mart, the storage part of the Cube which keeps data in an easy to query denormalised format. The Cube process calculates results such as thresholds on-the-fly, and permits data to also be queried as required. Installations can also use the Cube Reference Data Manager to store information such as counterparty data, or elect to use their own master data management system. The engine also manages the workflow around the reporting process, and provides a comprehensive set of configurable processes to manage the reporting cycle as per individual installation preference. The engine can cope with different types of market participants. For example, it is possible to switch on and off the reporting of valuation information and collateral. The engine is capable of differentiating between different group entities and handling them as required. The publisher tool pushes the data from the data mart to the receiving repository and processes response messages from the repository to the Regulatory Cube. The tool publishes to XML using the REGIS-TR repository, which will communicate to both EMIR TRs and REMIT RRMs. The solution can be hosted or deployed at the client site. The deployment depends on each individual setup and where the data is located. Vendor and website OpenLink Financial LLC www.openlink.com

REMIT Reporting Services and Solutions - July 2015 updated March 2016

9.3.1.5

Seeburger – EMIR/REMIT Trade Reporting Solution

Product Seeburger’s EMIR/REMIT Trade Reporting solution is a stand alone piece of software which can be used in two modes: Option 1 - Manual entry / import data - For all standard instruments specific "Forms" are available that contain only fields, for example for reporting of a FX forward contract are required. All entries are checked for syntax and consistency errors. Option 2 - Automated upload by coupling to any portfolio / trading / treasury system / SAP - data is retrieved from any system (Data Collection). It then passes through a syntactic and mandatory field check. After successful testing, the data is translated into the required data format (XML) will be sent in encrypted form to a trade repository (TR REGIS - TR, DTCC) or directly to the Authority (ACER) via Seeburger’s RRM (see section 9.2.1.4). The status messages of the respective transmission are collected and stored as the next step allowing the entire process to be monitored. The system provides the following benefits:         

Manual entry / import or connection to any portfolio / trading / treasury system Automated transmission and reception of feedback Client capability Compliance check integrated as a Quality Gate Process transparency through monitoring Maximum security and confidentiality Auditable through traceability Messages for standard and non-standard transactions Scales with future requirements: fundamentals of the MTS, BaFin, MiFID, etc.

Vendor and website Seeburger AG www.seeburger.com

REMIT Reporting Services and Solutions - July 2015 updated March 2016

9.3.1.6

Seven2One – Regulatory Reporting Solution

Product Seven2one offers companies a secure, efficient and market-tested reporting solution that is fully compliant with EMIR/REMIT. The software solution supports users throughout the process – from importing data from upstream systems to reporting to the authorities/central registers. The reporting solution includes:         

Reporting of trades/orders for all commodities and product types, fully compliant with EMIR, REMIT Automated data management and reporting Interfaces for ETRM and other upstream systems Audit compliant history of data streams and reports Monitoring (traffic light function) of process steps via reporting cockpit Updates for the communication modules independent of the release compliant with current legal regulations AN expansion path for other reporting obligations (MiFID, BaFin etc.) without the need to reinstall/install new software (modular technology) Flexible master data management including complete historisation of counterparties, products etc. Manual data input (individual trades, UTI, confirmation time stamp)

Seven2One provide updates for communication modules, independent of the release, ensuring that reporting is compliant with current legal regulations at all times without the need for a complete rollout or expensive modification the individual software installation. The reporting solution maps all asset classes including complex derivatives such as swaps and customised products. It also maps non-standardised products and any changes there may be in the supply profile, e.g. transactions with load profiles. Seven2One also offer a transparency data reporting solution which connects to EEX’s transparency reporting platform. Vendor and website Seven2one Informationssysteme GmbH www.seven2one.de

REMIT Reporting Services and Solutions - July 2015 updated March 2016

9.3.1.7

SunGard XDM Compliance

Product SunGard’s XDM Compliance module is a flexible stand-alone tool that allows companies to gradually adopt and integrate new regulations and reporting requirements covered by EMIR, REMIT and MiFID II . As the specification of each Regulation increases, the business rules for generating reports can be adapted to comply with the changes in regulations as well as the generating the reporting required. The module provides a set of tools and processes which simplify the management and maintenance of the business rules underlying regulations and reporting requirements. Contracts can be subject to multiple regulations with different reporting requirements. The module provides a centralized environment to support all these regulations, with the respective business rules. Users can directly create and maintain business rules to comply with changes and evolution in the reporting requirements. Contract information is maintained within a dedicated data model to allow transparent integration with different ETRM systems. XDM uses CpML, for contract modelling and communication. Support for additional formats and standards (such as FpML, csv, and other forms of XML) is also available. The module leverages XDM’s Workflow and scripting frameworks to provide the ability to dynamically modify the process workflows and rules. Validations can be defined, to make sure that only the correctly processed reports are communicated, while the inconsistent ones are submitted to manual inspection by users. XDM Compliance also provides full administration and logging of scheduled batch processes. XDM Compliance can be set up as an additional module of an existing XDM-based solution or as an independent XDM instance, which interfaces with external ETRM / Contract Management systems. Vendor and website SunGard Data Systems Inc www.sungard.com www.energeya.com

REMIT Reporting Services and Solutions - July 2015 updated March 2016

9.3.2

ETRM Software adapters

This section lists ETRM systems that are known to have regulatory adapters, as outlined in section 6.2.5. The following packages are listed: Vendor Pioneer Allegro Brady Plc OpenLink Trayport/Contigo 9.3.2.1

Package TRM Tracker EMIR and REMIT Solution Energy ETRM IRM enTrader

Pioneer â&#x20AC;&#x201C; TRM Tracker

Product TRMTracker is workflow driven and supports the straight-through processing (STP) of information throughout the entire organization. Its business intelligence reporting engine also offers a template-driven report writer (SQL, OLAP, Cube) that offers drillable insight into C/ETRM operations down to the transaction layer on reports of all at-risk models, including enterprise risk metrics (i.e. CFaR, TPE, PFE, EaR, Credit Risk Management, CVaR etc.). The product offers front, middle and back office functionality and forms the basis of compliance with the relevant regulation. Pioneer also offer a separate ComplianceTracker product which provides enterprise-wide compliance tracking, performance monitoring and reporting for corporate, regulatory, environmental and other compliance requirements. Vendor and website Pioneer Solutions LLC www.pioneersolutionsglobal.com

REMIT Reporting Services and Solutions - July 2015 updated March 2016

9.3.2.2

Allegro Development– EMIR and REMIT Solution

Product Allegro offer an “EMIR and REMIT” solution as an add-on to their CTRM system in order to support compliance with the regulations. Allegro’s solution offers the following    

Ensuring compliance, reducing errors and streamlining the trade reporting, confirmation and reconciliation processes. Effectively transforming trades into regulatory protocols and formats and providing direct connectivity to European trade repositories. Tracking the complete compliance business process, including reporting status and comprehensive audit trails. Managing all regulatory reference data and trade information, and monitoring against the clearing threshold and position limits.

The solution offers what is required to fulfil the new trading restrictions and mitigate risk. Beyond providing energy trading and risk management functionality, Allegro is designed to support business processes and workflow controls. Vendor and website Allegro Development Corporation www.allegrodev.com 9.3.2.3

Brady Plc– Energy ETRM

Product Brady’s Energy ETRM solution includes features that ensure compliance, with the new EMIR and REMIT regulations that help to reduce error and streamline the reporting, clearing and reconciliation process. Brady Energy ETRM is a standard, out-of-the box product that with processes and interfaces for deal clearing and reconciliation with exchanges already in place. The solution includes:    

Trading and Risk Management Data Management Logistics Settlement

Vendor and website Brady Plc www.bradyplc.com

REMIT Reporting Services and Solutions - July 2015 updated March 2016

9.3.2.4

OpenLink - IRM

Product IRM is a platform for energy trade processing from front to back office, including portfolio and risk management. With a focus on the gas and power industries, the solution supports multiple commodities and provides comprehensive electricity and gas scheduling across system operators in multiple markets. OpenLink IRM is also widely used for for.ecasting and optimization; providing a unique engine to optimize entire unit portfolios including renewables in one, integrated model. The product includes direct adapters to EMIR TRs and REMIT RRMs. The solution is offered in parallel to OpenLink’s CubeIntelligence product outlined in section 9.3.1.4. Vendor and website OpenLink Financial LLC www.openlink.com 9.3.2.5

Trayport/Contigo - enTrader

Product enTrader is a multi-commodity energy trading platform which is easy to use and configure without extensive implementation and configuration effort. The Trayport network provides an execution platform for Gas, Power, Oil, Coal, Carbon and Freight across all European markets. enTrader is fully integrated with Trayport Trading Gateway and all trades executed on the Trayport platform are automatically imported and mapped to energy derivative instruments in enTrader for further processing and valuation – without set up or configuration. enTrader includes features such as trade data enrichment, real-time trade valuation, confirmations, formula based pricing, forward curve management and automated settlement ensuring Straight Through Processing (STP) for the Front, Middle, Back Offices and operations. The product includes:   

Wide EU energy market coverage - All trades executed on the Trayport platform are automatically loaded to pre-configured derivative instruments in enTrader. Straight through processing (STP) - a single vendor product platform for trade execution, portfolio risk management, physical delivery scheduling and EMIR and REMIT regulatory compliance reporting. Flexible delivery - SaaS and on premise deployment options available.

The product is offered separately to the Trayport’s Complete service outlined in section Chyba! Nenalezen zdroj odkazů.. Vendor and website Trayport Contigo Ltd www.contigo.co.uk

REMIT Reporting Services and Solutions - July 2015 updated March 2016

9.4 Services Two services, as outlined in section 6.3, are listed: -

EFETNet eRR Trayport Complete

9.4.1.1

EFETNet - eRR

Product EFETNet’s eRR service operates on a similar model to that described in section 6.3.1. eRR is offered as part of “CMS”, the central matching service that also hosts eCM, the electronic confirmations matching service. EFETnet’s eRR establishes Straight Through Processing for regulatory reporting, delivering reporting compliance for REMIT and EMIR. eRR operates through a single standard interface providing connectivity to the different regulatory repositories. The service offers the following benefits:    

Single data format and interface for all submissions Extensive reconciliation of portfolios using eRR and third party data Automates the regulatory reporting process Addresses all regulatory reporting through a single service

Vendor and website EFETNet BV www.efetnet.org

REMIT Reporting Services and Solutions - July 2015 updated March 2016

9.4.1.2

Trayport – Complete

Product Trayport’s Complete service operates in a similar model to that described in section 6.3.2. The service offers the following benefits:       

Full real time STP integration with Trading Gateway Back loading of trades available from September. Complete workflow control via a real-time dashboard One click upload of non-Trayport trades via CSV or XML files. Hosted solution can be deployed quickly Full audit history of all reported transactions with the option to integrate with other trade record systems Option for trade-to-reporting STP achieved using Trayport reference data enrichment service.

For capture, Complete automatically aggregates matched and un-matched orders and trades across multiple venues into a single data feed when utilising Trayport trading systems such as Joule and Trading Gateway. This eliminates the need for a separate reporting agreement with each marketplace. Complete’s Data Warehouse can be utilised as a central repository of enriched events and act as a ‘System of Record’ of order and/or trade data for REMIT reporting. Import off-Trayport orders and trades by utilising Complete’s Programmatic API to feed data from 3rd party systems or alternatively the Excel/CSV file upload feature (available via the Complete User Interface). REMIT's Reference Data set includes: Order ID field, contract definition data, counterparty data, delivery and settlement data and value and volume calculations, and is used for enrichment. For reporting, Complete allows market participants to use flexible reporting strategies to manage compliance with their REMIT obligation. Complete offers Trayport developed and managed connectivity to a chosen RRM with enriched events forwarded directly to the RRM in the ACER format and recorded receipts returned to clients directly. Market Participants will need to reconcile what they have reported to the RRM with the events contained in the Participant's own System of Record. Trayport Complete offers 2 options:  

The participant may capture receipts from the Trayport Complete API and add them to their existing System of Record; or The participant may use Trayport Complete itself as the System of Record and use the Complete User Interface to check that each event has been successfully reported. This will be particularly useful for participants who do not currently maintain a record of their orders.

Vendor and website Trayport Limited www.trayport.com

ABOUT REGIS-TR

Comprehensive REMIT reporting solutions The European trade repository REGIS-TR now offers services for REMIT, allowing clients to meet both their EMIR and REMIT reporting obligations in an efficient and secure way.

Maintain a robust oversight process The Regulation on Energy Market Integrity and Transparency (REMIT) requires market participants to report wholesale energy market contracts within the EU via a Registered Reporting Mechanism (RRM). Standardised contracts on organised market places will need to be reported from 7 October 2015 onwards, whereas the REMIT reporting obligation for all other contracts will enter into force on 7 April 2016. Trading across multiple organised market places (OMPs) and on a bilateral basis makes it difficult to meet these reporting requirements efficiently. By delegating reporting requirements to various OMPs, market participants risk facing issues in terms of data management, monitoring and reconciliation. Non-compliance risks may also arise as OMPs do not have access to all reportable data such as lifecycle events/modifications as well as non-standard contracts.

How can we help? Reporting through Regis-TR offers you multiple benefits, whether you are a reporting participant, reporting on behalf of market participants, or a non-reporting party delegating reporting: Integrated reporting solution REGIS-TR covers reportable data under REMIT including transactions, filled and unfilled orders, standard and nonstandard contracts as well as historical data backloading. Regardless of the source and file format, reporting entities can easily transmit files to REGIS-TR via multiple connection options (SOAP API Web service, sFTP and manual upload). All transmitted data will be normalised, enriched, formatted and validated by REGIS-TR to ensure timely and successful submission to ACER. Enhanced customer experience through a single application REGIS-TRâ&#x20AC;&#x2122;s reporting portal provides a clear and easy way to monitor all reportable trade activity via a single interface. Thanks to a customisable dashboard, users can check data on demand, monitor their reporting status in real-time and handle exceptions in an efficient manner. The web-based interface grants secure and seamless access to the platform with no additional hardware or software requirements. Mitigated market fragmentation Interoperable links between REGIS-TR and leading OMPs/RRMs such as EEX, Gaspoint Nordic, Powernext, Trayport and EFETnet enable market participants to benefit from direct reporting from their OMPs to REGIS-TR, providing a single consolidated view of all reporting activity. Covering all your reporting needs As an approved TR and RRM, REGIS-TR is uniquely positioned to offer you regulatory reporting solutions for EMIR and REMIT. In line with its aim of becoming a leading European integrated solution for regulatory reporting, REGISTR will support future European regulatory reporting requirements, thereby ensuring minimised client effort and compliance with all regulations across jurisdictions.

Our footprint in the energy market •

Strong expertise in energy derivatives regulatory reporting, processing significant energy commodity volumes

•

Member of Deutsche Börse Group and BME which includes the European Energy Exchange (EEX) including member entities such as EPEX SPOT, Gaspoint Nordic, Powernext and MEFF Power

•

First TR involved in the ACER pilot project and working groups

•

Close collaboration with Europe’s leading energy utilities for the development of innovative REMIT reporting solutions

Easy onboarding to REGIS-TR REGIS-TR offers an entire suite of services to ensure seamless and efficient onboarding: Streamlined onboarding Existing customers of REGIS-TR can leverage their existing technical infrastructure, benefiting from a lighter onboarding process Regional support Receive detailed technical guidance from our specialist technical and product staff Supporting documentation REGIS-TR provides extensive supporting documentation including a detailed guide to reporting commodities for EMIR, elaborated in collaboration with leading European energy participants and containing useful information for EMIR-REMIT reporting Test environment Access REGIS-TR’s free REMIT test environment to ensure easy data submission

For further information, please contact: John Kernan REGIS-TR Senior Vice President – Product Management Tel: +352 243 36342 Email: john.kernan@regis-tr.com

ABOUT Sapient Global Markets

Sapient Global Markets Sapient Global Markets, a part of Publicis. Sapient, is a leading provider of services to today’s evolving financial and commodity markets. We provide a full range of capabilities to help our clients grow and enhance their businesses, create robust and transparent infrastructure, manage operating costs, and foster innovation throughout their organisations. We offer services across Advisory, Analytics, Technology and Process, as well as unique methodologies in program management, technology development and process outsourcing. Sapient Global Markets operates in key financial and commodity centres worldwide, including Boston, Chicago, Houston, New York, Calgary, Toronto, London, Amsterdam, Düsseldorf, Geneva, Munich, Zurich and Singapore, as well as in large technology development and operations outsourcing centres in Bangalore, Delhi and Noida, India. We have been helping organizations maximise trading opportunities by optimising processes and infrastructure in the energy and commodities space since 1992. During that time, we have worked with over 100 firms on more than 4000 projects, in areas such as: 1. Regulatory Reform Sapient Global Markets has extensive experience and knowledge of regulatory reform, having implemented a range of projects globally to meet regulatory directives such as EMIR, REMIT, MiFID and Dodd Frank. Our dedicated regulatory reform practice helps to create a strategic platform for today’s and tomorrow’s mandates. We achieve this by working with our clients in a variety of capacities—from business strategy, operations, data and technology strategy to solutions design and implementation. 2. C/ETRM Application Services To address increased market complexity and regulatory reform, firms need to optimise the processes and infrastructure that power their trading environments. Likewise, the way in which they incorporate new applications into the firm’s existing infrastructure is critical to their success. We provide a comprehensive suite of services to help firms get the most from their back-office, trading and risk management applications. Long-standing relationships with leading platform vendors, experience optimising these platforms and a flexible sourcing model allow us to align closely with individual business requirements as firms implement new systems and processes. 3. Visualisation With an unmatched understanding of how capital and commodity firms work, our team of designers and technology experts infuse industry knowledge with research methodologies that leverage a user-centered design process to develop trading interfaces, investor research platforms, portfolio management workspaces, interactive product applications and collaborative workspaces.

We use the latest technologies and collaborate with portfolio managers, research analysts, heads of research and traders to create working environments that maximise every action and present information in a more usable way. 4. Enterprise Risk Sapient Global Markets’ Enterprise Risk approach offers definition, planning, implementation and integration services to help firms create a complete risk program or tackle a specific risk project. We recommend incorporating visualisation into a firm’s strategy development to address and satisfy all user perspectives throughout the technical design process. By engaging stakeholders early and often in any risk project, firms will improve the likelihood of the adoption and utilization of new tools and methods. Our singular focus on the capital and commodity markets gives us a deep understanding of risk data requirements and usage for critical processes across the industry. We bring this knowledge to each one of our engagements and apply it to each firm’s organisational goals. 5. Advanced Portfolio Optimization Sapient Global Markets has developed an advanced Physical Portfolio Optimisation approach to help firms realize the most value from their assets and supply chain. Our portfolio optimisation toolset can be customised to simulate a firm’s trading environment so firms can generate and analyse viable scenarios and uncover the actions to take that will result in the most incremental revenue. We are one of the few companies that has the expertise in all critical areas of energy trading required to develop a physical portfolio optimisation program—and the infrastructure, reach and scalability to serve large and mid-size clients around the world. We can help firms move beyond decisions based on intuition and simple modelling tools and enable them to tap the unrealised potential in their portfolio. For more information about Sapient Global Markets, contact us at sgm@sapient.com.

ABOUT ETR Advisory

ETR Advisory Ltd is a small consultancy which provides advice and training in the application of regulations to the Energy and Commodities markets, as well as general advice in the domain. Our detailed knowledge of the rules and the technology platforms and solutions around them permits us to help our clients navigate and implement the best solutions while being ready for future rules. Since being founded in May 2013 by Aviv Handler, ETR has advised over twenty five Market Participants, E/CTRM companies, trading platforms and repositories. ETR has also provided training to many companies. ETR runs the blog at www.energytradingregulation.com, which provides news and thoughts about developments in the regulatory field in one place. Aviv Handler is a specialist in the regulation of the commodities and energy market providing advice and services to the energy and commodity markets in the understanding, preparation and implementation of European Energy and Commodity Market Regulations. He focuses focus on all streams of regulation including EMIR, REMIT, MiFiD II, CRD IV and MAR as well as applicable rules across the globe. He has domain expertise in compliance (REMIT, EMIR, MiFiD, Basel II/III, CAD, CRD IV), credit risk, commodity and energy trading (gas, power, oil), with extensive knowledge of regulation, credit, risk and ETRM systems and financial messaging.

www.energytradingregulation.com Email: aviv@etr-advisory.com Tel: +44 20 3271 0091