Are you ready for REMIT II? Essential updates for Algorithmic Traders

[1] An increasing number of REMIT infringement decisions penalise market manipulation in the form of placing erroneous orders, often known as “fat finger” errors, which can have very significant consequences for markets. The November 2023 incident in Finland, for example, illustrates the potential consequences of an erroneous order (although it should be noted that the investigation in that case is still ongoing)[2]. While all such cases to date appear to have involved human trading rather than algorithms, the risk of erroneous algorithmic orders is one of the key reasons for the new requirements under REMIT.

The importance attached by EU energy regulators to algorithmic trading is also emphasised by the report on the findings of an exploratory study published on 17 July 2024 by the Dutch competition and markets authority, the ACM, in conjunction with the Dutch financial markets regulator[3]. The study examined the growing use of algorithmic trading in wholesale energy markets in the Netherlands, concluding that while it can bring benefits, such as more efficient price formation and increased liquidity, it also carries risks, including increasing volatility and market manipulation. The ACM states that it will monitor this area particularly closely and may impose fines for non-compliance.

On 30 July 2024, ACER published an open letter on the notification requirements in respect of algorithmic trading, setting out its non-exhaustive view as to whether various examples of trading algorithm fall within the scope of the new requirements[4].

The new requirements in respect of algorithmic trading are found in Article 5a of REMIT. Article 5a is modelled on the provisions of Article 17 of the 2014 recast Directive on Markets in Financial Instruments, Directive 2014/65 (MiFID II). In other words, the new requirements in REMIT are based on requirements that have been in place in financial markets for some years, although with some important differences, as will be seen.

In this note, we outline the new requirements. We also consider how market participants can protect themselves contractually against the risks presented by trading algorithms purchased from third parties.

What is algorithmic trading?

Article 2(18) of REMIT defines algorithmic trading as:

“trading, including high-frequency trading, in wholesale energy products where a computer algorithm automatically determines individual parameters of orders to trade such as whether to initiate the order, the timing, price or quantity of the order or how to manage the order after its submission, with limited human intervention or no such intervention at all, not including any system that is only used for the purpose of routing orders to one or more organised marketplaces or for the processing of orders involving no determination of any trading parameters or for the confirmation of orders or the post-trade processing of executed transactions”

The ACM distinguishes (at section 3.2.1 of its study) between 3 types of algorithm:

• execution algorithms, used to execute a decision made outside the algorithm, by placing orders in an optimal way based on parameters (such as price and volume limits) set by the trader;
• signal generators, which signal trading opportunities to traders or execution algorithms, which take the decision whether to execute; and
• trading algorithms, which differ from execution algorithms in that they also decide whether to submit an order based on the information provided to them, either by a signal generator or by a human trader.

The ACM does not attempt to identify which of these types fall within the definition of algorithmic trading for the purposes of Article 2(18) of REMIT. In contrast, ACER’s open letter provides some indicators as to the treatment of various examples of trading algorithm.

It may be useful to quote ACER’s examples of in-scope algorithms, with its reasoning, followed by our own commentary. At the outset, however, it should be stressed that both the ACM’s and ACER’s neat allocations of algorithms into distinct categories are somewhat artificial, and it is more accurate to represent them as a continuum. Each algorithm is unique, with its own characteristics, and must be assessed individually against the Article 2(18) test.

“Internal (market participant’s) algorithms

In-house built, tested on an OMP, and deployed tool where a computer algorithm automatically determines individual parameters of orders such as whether to initiate the order, the timing, price or quantity of the order or how to manage the order after its submission, with limited or no human intervention.”

This example is not particularly useful, in that it does little more than repeat the Article 2(18) definition.

“External (OMPs’) ‘execution algorithms’ without human intervention

Trading functionalities with automated management of orders. E.g. orders that are executed through functionalities which additionally to routing orders to OMPs offer automated managing of the order (e.g. automatically redirecting unexecuted portions of such orders to other venues or slicing orders prior to execution). Such functionalities differ from automated order routing systems, as the latter merely determine the OMP (or OMPs) to which the order has to be sent without changing any parameter of the order (i.e. the order is unmodified in its components, including its size). On the contrary, algorithmic trading encompasses both the automatic generation of orders and the optimisation of order-execution processes (e.g. slicing of orders) by automated mean.”

This example usefully sheds some light on the distinction between order-routing software (out of scope) and algorithms that generate, manage and/or optimise the order, or change its parameters eg, by slicing it (in scope). Execution algorithms are likely to fall within the definition because they determine the optimum order, albeit based on parameters provided to them. However, if they make no sort of assessment and merely transmit orders to a marketplace, they will not meet the criteria.

“Stand-alone vendor algorithms by third parties

All types of algorithms independent of their complexity (e.g. PowerBot).”

This example is somewhat confusing. It is not at all clear why the fact that the algorithms are created by a third party means that “independent of their complexity” they are in scope. The better answer seems to be that it will depend on their functionality and whether they meet the Article 2(18) definition. Some third party algorithms will determine order parameters, with limited human intervention, and will meet the definition, whereas others will come closer to some of the “out of scope” algorithms illustrated below – and will therefore fall outside the Article 2(18) definition.

ACER also gives a number of examples of out of scope algorithms, which again we quote here, with our own commentary.

“External order types offered as standard functionalities by exchanges/OMPs

They are a standard way to interact with the market and are made available on a wide range of exchanges and execution platforms that do not contain further own dynamics apart from predefined parameters (e.g. Iceberg orders where the portion of orders is pre-defined and the slice doesn’t react or change when market conditions change, stop-limit orders, delayed orders).”

The point here seems to be that these algorithms do not interact with market conditions – a useful pointer to assessing whether the algorithms falls within or outside the definition.

“Systems used for the confirmation of orders or post-trade processing executed transactions

These are not directly related to placing orders/executing transactions.”

This example is also useful, pointing to an important indicator of in-scope algorithms.

“Signal generators

Signal generators do not act in the market. It will still be a human trader who will have to check the information provided by the signal generator and, if the suggestion provided is agreeable, either place a manual trade or set up an algo to trade.”

This one comes as no surprise, and highlights the fact that not acting in the market, and human intervention, are important hallmarks of out of scope algorithms. The vital decision whether to execute the option suggested by a signal generator is not taken by the algorithm, but by a human trader or another algorithm.[5]

“Systems for pure order routing

Systems which do not process any external parameters or market variables when forwarding orders in an automated way.”

This one also comes as no surprise, because it simply restates part of Article 2(18)

Who engages in algorithmic trading?

REMIT obligations in respect of algorithmic trading apply to the market participant.[6] The market participant is the person who enters into the transactions, i.e. the person who places the orders.[7] So if a market participant uses the output of an algorithm administered by another, the market participant rather than the algorithm provider will be responsible for compliance with the REMIT obligations. An example of this arises in relation to the operation of battery storage systems. The battery will often be operated by one entity, based on a battery optimisation algorithm that determines the optimum charge/discharge profiles according to energy, balancing and ancillary services prices, and battery state, while the orders executing the decisions made by the algorithm are actually placed by another party, the market participant. The algorithm determines the orders, so this is likely to amount to algorithmic trading, but it will be the company that trades the battery output, rather than the company that operates the battery, and may have developed the algorithm, that is responsible for compliance with the algorithm-related requirements of REMIT.

Another example is the provision of trading algorithms as a service, where a provider gives traders access to trading algorithms via a platform or other interface. In that case, the market participant is again the trader and not the service provider, and it is therefore the market participant that is responsible for compliance with Article 5a. However, the market participant will wish to delegate as much of its responsibility as possible to the service provider, and should ensure that it has the information that it needs from the service provider in order to comply with its REMIT obligations.

What are the new requirements under REMIT?

A market participant engaging in algorithmic trading is subject to two specific new obligations. The first is to have in place effective systems and risk controls to prevent erroneous orders and to prevent actions that may create or contribute to a disorderly market. The second is to notify the home NRA of its engagement in algorithmic trading. These are addressed in turn.

Effective systems and risk controls

A market participant that engages in algorithmic trading must have in place “effective systems and risk controls suitable to the business it operates to ensure that its trading systems are resilient and have sufficient capacity, are subject to appropriate trading thresholds and limits and prevent the sending of erroneous orders to trade or otherwise function in a way that may create or contribute to a disorderly market”. Its systems and risk controls must also ensure compliance with the requirements of REMIT and the rules of an OMP to which it is connected. The market participant must also have in place effective business continuity arrangements to deal with any failure of its trading system, and must ensure that its systems “are fully tested and properly monitored so that they meet the requirements laid down in this paragraph”.

It may be useful to explore these obligations in more detail.

The starting point for the regulation of algorithmic trading is the adoption of effective systems and risk controls. They must be suitable to the business operated by the market participant, taking into account the objective of avoiding erroneous orders and avoiding the creation or contribution to a disorderly market.

This means that the level of sophistication and complexity of the systems and controls will need to be proportionate to the risk of causing one of these outcomes and the consequences of it happening. This should be assessed by reference to an appropriate risk matrix. Systems put in place by a trader trading large volumes with a high frequency and with significant price spreads are likely to need to be more sophisticated than systems put in place by the operator of a single small battery storage system, for example.

The systems and risk controls put in place by market participants engaging in algorithmic trading must also ensure compliance with the requirements of REMIT.

These requirements include the Article 3 prohibition of insider trading. This means that the market participant’s trading algorithm must be sufficiently ring-fenced that it cannot access or use any inside information, for example, outage information in relation to physical assets that it also operates (eg. a generation unit, a demand unit, a battery storage system or grid infrastructure), which might give rise to insider trading.

The greater risk in this context, however, is that of infringing the Article 5 prohibition of market manipulation. Not only must the systems and risk controls avoid erroneous orders (as noted above), which may send false or misleading signals and be treated as market manipulation, but they must also avoid other forms of market manipulation, for example engaging in layering and spoofing,[8] or marking the reference period.[9] The algorithm should clearly be designed so that it avoids deliberately engaging in manipulative conduct. In addition (because energy regulators and ACER generally take the view that no intent is required in order to infringe REMIT, and that infringement can therefore result from the effects of an order in the absence of manipulative intent), the algorithm should also be designed so that it avoids unintentional manipulation – a greater challenge to the designer. Careful thought will need to be given to the way in which markets operate and the likely (and unlikely) effects of the various orders placed by the algorithm. The algorithm should be designed so that it follows a rational economic logic and (as far as possible) avoids making non-intuitive trades.[10] The parameters determined by it must reflect market fundamentals and the market participant’s net position on the market. The algorithm should also include safeguards to ensure that its interactions with other algorithms do not give rise to market manipulation. In 2019 the German NRA, the Bundesnetzagentur, imposed penalties on Uniper and two of its traders for manipulating the German gas balancing market. The traders explained that their actions were “intended to beat automated trading algorithms”.[11] Such conduct is also likely to be manipulation if engaged in by an algorithm.

The ACM study highlights a number of examples of generic risks of market manipulation posed by algorithmic trading. They include the following:

• the suggestion that algorithms might be more susceptible to manipulation than manual trading due to their reliance on processing large quantities of data. Manipulating input information could influence the output of the algorithm;
• “robot battles” between algorithms, where algorithms compete for the highest buy order, until one of the algorithms sells at the highest buy order price of the other, and then withdraws its own buy order. This would be layering/spoofing in human trading and is likely to be the same if carried out by an algorithm; and
• algorithms creating feedback loops and placing orders so quickly that the order books become invisible to other market participants.

The ACM study also identifies a number of more specific risk factors that remain even where market participants put compliance and monitoring procedures in place. In particular, the ACM notes the ability of machine-learning algorithms to learn that manipulative trading may be more profitable. This is echoed by an interesting recent paper[12] pointing to the tendency of algorithms to learn to manipulate markets, and even to learn to coordinate manipulation with other algorithms. It is therefore prudent to build appropriate safeguards into algorithms that might be at risk of similar interactions, to avoid infringement of Article 5. However, this is made more difficult by a number of the other factors identified by the ACM, including:

• the difficulty of testing for all possible trading scenarios as algorithms become more complex – particularly testing for extreme market conditions which by definition occur only rarely and may cause self-learning algorithms to take less sound decisions;
• the difficulty of testing for the interactions of all of the complex data sources on which algorithms base their decisions (a factor to which we return below), as well as the fact that input data may itself be incorrect; and
• the fact that errors or undesirable trading patterns may not be detected for some time;
• the importance of setting appropriate limit values, in order to ensure that pre-trade controls are effective.

The combination of these factors, and the lack of familiarity of regulators with these factors and with the ways in which algorithms may interact, mean that the regulators’ initial steps into investigation and enforcement in this area are likely to be very hesitant and at risk of error. Whether that will result in under-or over-enforcement remains to be seen.

In addition to the risk of market manipulation, the ACM also highlights the risk of the algorithm being fed with inside information, and the need to ensure that a person with inside information must not pass it to the algorithm, or otherwise intervene with the algorithm, before it has finished running and generated its output.

Article 17 of MiFID II provides for ESMA to prepare draft regulatory standards (RTS) to set out the details of the systems and risk controls outlined in the Article. These may then be adopted as delegated acts, in the form of Regulations, by the European Commission. RTS 6, Commission Delegated Regulation 2017/589, sets out “regulatory technical standards specifying the organisational requirements of investment firms engaged in algorithmic trading”. In contrast, Article 5a of REMIT contains no equivalent, so there will be no ACER equivalent to RTS 6.

Nord Pool Guidance on algorithmic trading

It is to be hoped that ACER’s REMIT guidance, a new edition of which is currently in preparation, will give further guidance on the contents of the systems and risk controls required by Article 5a. Until it does, or if it does not, Nord Pool’s existing Best Practice Guidance for algorithmic trading provides a good starting point. The Nord Pool Guidance draws heavily on RTS 6. The ACM study notes that all of the market participants that it interviewed have compliance and risk measures in place, of varying degrees of complexity.

The Nord Pool guidance provides as follows:

• it is good practice to identify orders and transactions generated by an algorithm by using a distinct trader ID.
• it is best practice to establish a clear and formalised governance model with clear lines of accountability and effective procedures for communication of information. In particular, the market participant should have a dedicated REMIT compliance function. A particularly important (and sensible) principle in the Nord Pool Guidance is that “every staff member, that plays a more than marginal role in the lifecycle, of a trading algorithm, should have a general understanding of how the algorithm works”. According to Nord Pool, the compliance team should understand the algorithm well enough be able to challenge the developers on the practical implications of the algorithm. This may be difficult to achieve in reality, given the complexity of algorithms and the large volumes of data involved, but compliance teams will need to do their best to dig into the details. Traders should have a sufficient understanding of REMIT to avoid infringement, and the market participant should have sufficient staff with the skills to manage its algorithmic trading. The governance arrangements should also ensure that it is clear which individuals have the right to deploy and change the parameters of the algorithm;
• the design of the algorithm should take into account the market abuse prohibitions of REMIT, and the market participant should assess whether the combination of strategies may send false or misleading signals to the market. The market participant should also have the ability to stop trading activity by an algorithm (a “kill functionality”), and possibly also to suspend trading. The algorithm should also be designed with safeguards against unintended trading activity, eg. when interacting with other algorithms, and to ensure against the use of inside information (see above);
• the algorithm should also be tested before deployment, in a separate test environment, following a structured procedure, and with the results properly documented. In particular, the testing should assess whether the algorithm might infringe the REMIT prohibitions, how it interacts with other algorithms, whether it might be tricked by another market participant and whether it might contribute to disorderly markets. There should also be a defined and suitable process for approving the algorithm for use;
• the algorithm should be deployed with adequate pre-trade controls, ie, limits on parameters such as prices, volumes, restrictions on operation in the event of market price movements in excess of certain limits, etc. The UK financial regulator, the FCA, has made it clear that market participants must implement effective “hard blocks” (limits that cannot be overridden by individual traders), pop-up messages that cannot be dismissed unread, and other appropriate warnings that are sufficiently clear, together with effective and real-time supervision and monitoring functions;
• post-trade controls should also include effective real-time or close to real-time monitoring whether the algorithm is performing as intended, together with effective procedures for activating the kill functionality in all circumstances, including in cases of loss of connectivity etc; and
• finally, market participants should keep adequate records of the design, testing and deployment of its algorithms and of the implementation and operation of the systems and controls outlined above.

The ACM study notes that a number of platforms already impose specific conditions on market participants wishing to deploy algorithmic trading, including requirements on conformance testing, implementing effective compliance and monitoring systems and specific trading limits.

Notifying the home NRA of algorithmic trading

The second new obligation imposed on a market participant engaging in algorithmic trading is to notify its home NRA and ACER of that fact. The home NRA may require the market participant to provide a description of the nature of its algorithmic trading strategies, details of the trading parameters or limits to which the trading system is subject, compliance and risk controls to ensure compliance with the requirements of Article 5a(1) and details of the testing of its trading systems. The market participant must keep, for a period of 5 years, sufficient records to enable the home NRA to monitor compliance.

On 16 April 2024, ACER published an open letter on the implications of the revision of REMIT on data reporting and notification obligations.[13]

It explained that notification of the use of algorithmic trading will be made via the CEREMP portal, which will be treated as notification of both ACER and the NRA. However, in Italy, Romania and Slovenia, notification will instead be made to the NRA, which will be treated as notification of both authorities.

Contracting for algorithmic trading

The complexity of developing trading algorithms means that many market participants will need to procure them from third party vendors, or will procure algorithmic trading as a service from a platform. There are a number of issues to consider in procuring algorithms or the corresponding service, and a number of provisions that market participants should consider including in their contracts in order to protect their position:

• liability – liability under REMIT rests with the market participant rather than the vendor. The market participant should therefore include in its purchase contract an express obligation on the vendor or provider to assist the market participant in complying with its REMIT requirements. The extent to which the market participant can impose obligations on the vendor will depend heavily on the bargaining power of the parties and the type of algorithm being purchased. For example, a market participant negotiating with a vendor that sells an existing algorithm to multiple customers on its standard terms may be in a weaker position than a market participant negotiating with a vendor that develops a bespoke algorithm in accordance with the requirements of the market participant. At the same time, the vendor will wish to ensure that to the extent it accepts liability for the algorithm, it does so only where the algorithm is used in accordance with its agreed purpose, and not where the market participant has either used it incorrectly or has itself selected the order parameters that resulted in manipulation or disruption to the market.
• testing – as well as conformance testing (ie. API testing between the trading platform, the algorithm and any other systems that they use), market participants should ensure that robust testing and acceptance procedures are outlined in the contract (particularly in the light of the REMIT requirement that systems are fully tested), clearly indicating the relevant criteria, responsible party, and timeframes/testing periods. Nord Pool’s Guidance explains that the market participant should assess the testing procedures of the vendor (meaning that it must have staff members who understand the algorithm and the design/development process well enough to be able to assess its compliance), the vendor’s documentation and whether in-house testing is also required. Market participants will be able to point to the requirements imposed by REMIT in order to justify the corresponding contractual provisions. In addition to the Nord Pool requirements, market participants should ensure that any new algorithm is tested not only in the laboratory, but also, if possible, in a market testing environment, shadow running or sandbox where it can interact with real market conditions, other orders and inputs etc. In particular, interactions with other algorithms will be important, for the reasons outlined above, and testing should as far as possible also cover unusual market situations, unusual input data, etc;
• record keeping – appropriate audit and record keeping obligations will be vital for transparency as to how the algorithm is operating and also as to how any problems occurred (which in turn can help determine responsibility and subsequent liability). In view of the “black box” nature of some complex trading algorithms, the contract should ensure that, there are clear records documenting, for example, the logic and rationale/configuration of the algorithm (in simple terms), the tests conducted and ongoing testing procedures, the limits/controls of use of the algorithm, the programming code (including version control), per algorithm output information on produced orders and trade, order history and responsible staff for making/approving changes;
• monitoring – REMIT requires market participants to ensure that systems are properly monitored. In some cases, it may be appropriate for the market participant to seek to pass this obligation on to its vendor or service provider. If so, the market participant should ensure that the vendor’s monitoring operations are robust. If it retains the responsibility, it should consider whether there are any tools that it requires from the vendor so that it can carry out monitoring activities. As in the case of testing requirements, market participants may be able to point to the REMIT requirements in order to justify their requests to vendors;
• warranties – the contract should include clear warranties about the quality of the software (eg. that it will meet the pre-trade controls and will be free from material defects), and should also include appropriate indemnities for specified losses. Standard IT sector warranties, such as ISO 27001 certification, should also be obtained. While market participants may seek to include warranties that the algorithm will not access or use any inside information and will avoid deliberately or unintentionally engaging in manipulative conduct, market participants should be aware that the complexity of the algorithm may cause difficulties in establishing the cause of issues – market participants may be unable to substantiate breach of contract claims and the vendor may be unwilling to give a warranty where it is unable to verify its own compliance. A particularly important issue in the light of the risks highlighted above is for the vendor to warrant (and to ensure) that the algorithm does not interact with other algorithms in such a way as to result in market manipulation; and
• licensing – the contract will need to grant the market participant adequate and sufficient rights to use and modify/update the algorithm. Market participants should watch out for limits imposed by vendors on order volume and price when considering the intended use of the algorithm.

What lies ahead? Final thoughts in preparing for REMIT II

Algorithmic trading has been a feature of energy trading for some years, and best practice, whether implemented on the trader’s own initiative or at the instigation of an exchange, has already introduced a number of important controls and safeguards, such as pre-deployment testing, pre-trade controls and monitoring.

REMIT II now places these measures on a new footing, changing best practice into regulatory requirements closely monitored and enforced by regulators. The risks of REMIT infringement as a result of an algorithm placing either an incorrect order or an actively manipulative order – possibly even as the result of an interaction with another algorithm – grow with the wider use of increasingly complex algorithms, and the wider range of inputs used to feed them. Article 5a of REMIT attempts to manage those risks, although conversely it also heightens the prospect of enforcement. It is likely that we will see investigations and decisions by the regulators on some of these issues over the next few years. In order to reduce their risks, market participants will need to have a good understanding of the algorithms that they use, and of the ways in which they can result in market manipulation, and will need to ensure that they build appropriate safeguards into their contracts and their internal monitoring.

[1] We are grateful to Iain McGowan, Head of Compliance at InCommodities, for his comments on a draft of this note. Any errors are ours, however.

[2] https://www.bloomberg.com/news/articles/2023-11-23/trader-error-causes-huge-plunge-in-finnish-power-prices; https://energiavirasto.fi/en/-/the-energy-authority-to-launch-an-investigation-on-an-incorrect-tender-submitted-to-the-power-exchange-on-23-november-2023.

[3] https://www.acm.nl/system/files/documents/rapport-marktstudie-algoritmische-handel-energiemarkt-pl.pdf.

[4] https://www.acer.europa.eu/sites/default/files/REMIT/Guidance%20on%20REMIT%20‌Application/Open%20Letters%20on%20REMIT%20Policy/Open-letter-on-algorithmic-trading.pdf

[5] See also the ESMA Questions and Answers On MiFID II and MiFIR market structure topics https://www.esma.europa.eu/sites/default/files/library/esma70-872942901-38_qas_markets_structures_issues.pdf “The use of algorithms which only serve to inform a trader of a particular investment opportunity is not considered as algorithmic trading, provided that the execution is not algorithmic”. See also Nord Pool’s REMIT Best Practice Guidance, section 3.3.2.

[6] Article 5a.

[7] Article 2(7).

[8] According to ACER REMIT Guidance (6th edition), ‘layering’ is defined as “issuing multiple non-genuine orders to trade at different price levels (layers) on one side of the order book, in order to enter into one or multiple transactions on the other side of the order book; and ‘spoofing’ as “issuing a single large or multiple non-genuine orders at the same price level on one side of the order book, in order to enter into one or multiple transactions on the other side of the order book”.

[9] According to ACER REMIT Guidance (6th edition), ‘marking the reference period’ means “entering into orders to trade or executing transactions on a wholesale energy product at a reference time of the trading session (e.g. marking the closing, the opening, the settlement) in an effort to increase, decrease or maintain the reference price (e.g. closing price, opening price, settlement price) at a specific level.”

[10] See “Non-intuitive commercial exchanges in SDAC: analysis and recommendations” in ACER’s REMIT Quarterly, Issue No 33: https://acer.europa.eu/sites/default/files/REMIT/REMIT%20Reports%20and%20Recommendations/REMIT%20Quarterly/REMITQuarterly_Q2_2023.pdf

[11] Bundesnetzagentur - Press - Fines for manipulation of wholesale energy market

[12] Cartea, Álvaro and Chang, Patrick and García-Arenas, Gabriel, Spoofing and Manipulating Order Books with Learning Algorithms (November 21, 2023). Available at SSRN: https://ssrn.com/abstract=4639959 or http://dx.doi.org/10.2139/ssrn.4639959

[13] https://www.acer.europa.eu/sites/default/files/REMIT/Guidance%20on%20REMIT%20Application/Open%20Letters%20on%20REMIT%20Policy/Open-letter-on-REMIT-revision-implications.pdf