Reported issue ID: 05/2019
Allowance of overnomination in the event of capacity platform failure outside working hours
In the event of a failure of the PRISMA (or potentially other) booking platform leading to a disruption of capacity auctions, manual procedures may be invoked during business hours, but no workable fallback is available at other times. Even within working hours, the manual process may overrun the allowed day-ahead auction window. Improved fallback procedures would help to avoid unnecessary TSO balancing action. In the interim, allowance of within-day overnominations (e.g. by provision of no-notice interruptible capacity or an ex post allocation) would provide a simple, cost-effective fallback as an alternative.
The existing fallback procedures in case of auction failures are largely manual, which creates risks of errors and makes the process inaccessible outside the standard working hours. The length of the manual process also does not match the day-ahead auction window, which sometimes proves to be too narrow for the issues to be resolved. In the current environment, the burden of auction failures lies largely with the shippers, since:
a) they may need to readjust their positions to avoid imbalance, especially if there is no guarantee that a fallback procedure will be completed
b) some fallback procedures for day-ahead auctions rely on within-day market, which is both more expensive (through higher multipliers) and less liquid
In system operation terms, this also provides better opportunity for shippers to balance the system, potentially allowing gas to be brought into a market faster for example when a market experiences a sudden supply outage out of business hours and the platform fails, and reducing the TSO need to resort to system balancing action.
To conclude, EFET advocates for a review of fallback procedures, where greater harmonisation and automation would help understanding and operability. However, if changes are not justified because of costs involved, within-day overnominations could be introduced as the standard approach to fallback procedures. Such solution would be available at any time of the day, would not require any substantial development expenses and would give the system users the comfort of knowing that, under the worst-case scenario, they hold interruptible capacity after the auction. System operators would also have the time to analyse the situation in retrospect.
In regulatory terms, this could be provided in the form of interruptible capacity allocated without notice or retrospectively, or a waiver of overrun charges.
Network Code on Capacity Allocation Mechanisms, Commission Regulation (EU) 2017/459
- Czech Republic
- Northern Ireland
- United Kingdom
- Involved NRA(s)
- Involved TSO(s)
- Adjustement of implementation
You are about to add a file to comment
Please note the file will be visible to all the users and visitors of the Platform
Do not add any confidential documents.
Press "OK" if you still want to add a file, otherwise click "Cancel"
With reference to the solution supporting document below, some limitations exist for implementing over-nomination as standard fall-back procedure. Taking into account that a clear structured table already exists, with parameters that describe, for each TSO, the fall-back procedures and responsibilities in case of an auction failure, it is concluded that there is no need for further harmonisation.
This conclusion is also based on the fact that no clear benefit of having over-nomination as standard fall-back procedure could be identified, especially considering the low number of times a failure of the auction process has been reported in the past. Consequently, ACER is Page 2 of 2 of the opinion that the costs of implementing such fall-back procedures are disproportionate in comparison to the benefits that could result.
Therefore, it is concluded that the current overview table available on ENTSOG’s webpage already constitutes an ample solution and source of information for network users, and no need for an amendment to the Regulation has been identified. Regular updates of this table will continue to be made in the future.
For further details, reference is made to the Solution note and Solution supporting document below.