1. Counter-activations
Compromise proposal for counter-activations in the mFRR- and aFRR-Platforms

2. What are counter-activations?
Counter-activations are equal to activations of both a upward and downward bids at exactly the same time.
Counter-activations in this context is not related to situations where the system direction changes within the ISP, which may also cause activations in both directions.
Price [EUR/MWh]
Volume [MW]
Common Merit Order List (CMOL)
In case of price inversion between the upward and downward CMOL, the optimisation algorithm will naturally tend to activate in both directions if this is not explicitly prevented by an additional constraint.

3. Why are counter-activations controversial?
Prevention of CA is hard to achieve together for instance with indivisible bids or unforeseen rejection of divisible bids.
 From algorithmic perspective, it is therefore beneficial to allow CA
But there is a side effect for the market: counter-activating these bids is creating an additional economic surplus, like the preceding markets (DA, ID)
Price [EUR/MWh]
Volume [MW]
Common Merit Order List (CMOL)
The perception of this side effect is very different
Some NRAs/TSOs and BSPs/BRPs believe that the side effect is very negative: not the role of TSOs, threat for ID…
Some NRAs/TSOs and BSPs/BRPs believe that the side effect is positive by itself thanks to the additional surplus created

4. Can the side effect be avoided / reduced?
Overview
Can the side effect be avoided / reduced?
PICASSO:
The aFRR market design does not include indivisible bids and the optimisation problem is linear  blocking CA is possible
Allowing CA would require a change of approach for the order of the optimisation algorithm compare to what has been previously decided (IN should then be before aFRR) or to have more complex algorithm
MARI:
Lessons learned from the TERRE project clearly stated that it is very difficult to avoid counter-activations.
The MARI project wanted a second opinion on that, and engaged with algorithmic specialists and asked them to analyse the problem.
From algorithmic point of view, it is easier to block the counter activations, due to the integration with IGCC
From algorithmic point of view, it is extremely difficult to block the counter activations, no commercial solution available, and not obvious that a custom solution will be possible

5. Summary of the analyses in PICASSO
Algorithm perspective
Feasibility of blocking CAs
PICASSO TSOs have concluded that in terms of algorithm, all options are possible (allowing CAs, allowing partially CAs, blocking CAs). The difference with MARI arises from the absence of indivisible and link bids.
Interactions between IN and aFRR
Having implicit netting within aFRR (where it applies) before IN contributes to increase efficiency (see INIF: optimisation region)
But having IN after aFRR without specific tweaking of the algorithm will lead not to activate the bids for CAs
Other considerations
Mixed views…
BSP-to-BSP exchange and role of the TSOs
Economic efficiency
Risks for mark-ups
Efficient use of cross-zonal capacity
Transparency or understandability of the results for BSPs
Importance of: repartition of surplus between TSOs, non-monotonic behaviour of price, non-intuitive flows & negative rent
Legal requirements (REMIT, EBGL)
Conclusion
PICASSO TSOs propose to block the possibility of counter-activations in a first stage

6. Summary of the analyses in MARI
Algorithm starting point
«1-step» vs. «2-step»
As a starting point, MARI TSOs, comforted by an external analysis (N-Side), believe that the 1-step algorithm is the most efficient in terms of optimisation for the balancing, and use of CZC
MARI project context
Foreseen use of indivisible bids
Based on the current design decisions in the MARI project, the use of extended features such as indivisible bids or linking between bids are necessary for technical reasons and also for TSOs to be able to operate their balancing processes
Implementation concerns
Risk on the go-live date due to complexity of handling CA
Extended features generate cases of acceptance / rejection of divisible and indivisible bids that MARI has to handle
According to the external analysis (N-Side), the handling of those cases with the reduction/blocking of counter-activations is not known in terms of algorithmic implementation, and it is unknown if a solution can be found
Conclusion
MARI TSOs propose to secure (technically and timely) the implementation of the mFRR platform based on a 1-step algorithm, acknowledging the possibility of counter-activations as a side effect in a first stage

7. The perception of the side effects are different
TSOs evaluate the impact of the side effects differently
In general TSOs that are more reactive (high aFRR share) are against counter activations, where the other TSOs are more positive towards counter activations.
This is all based on expected impact on the market, there is no data on the table – just expectations.
The future bidding strategy by BSPs is unknown

8. And then commit in the IFs to monitor the side effects
Common proposal from MARI and PICASSO
Starting point shall be:
To fully allow counter activations in MARI & to fully block them in PICASSO (Package Deal)
And then commit in the IFs to monitor the side effects

9. Benefits of the compromise
An agreement today increases the probability for the final IF approval by MC in December 2018
Partly satisfies all TSO’s concerns
“Reactive concerns” mitigated in aFRR
“Proactive concerns” mitigated in mFRR
The risk of not finding a solver for the MARI AOF is reduced
The MARI solution is more similar to the TERRE solution  IT can be re-used
The joint implementation of PICASSO and IGCC is straightforward
Similar approach than TERRE