2020-12-03

Grexel shapes the future of GOs via FaStGO #2

The RED II extends the coverage of Guarantees of Origin (GOs) from mere electricity to gases (including hydrogen) and heating/cooling. As the scope of the GOs expands, so do the requirements posed to the registry system providers. Another factor in the mix is the upcoming CEN EN 16325 standard. The new standard is referenced in the RED II making it part of the mandatory regulation. It is, however, not yet known when the updated standard will be available. It might even be so beyond the directive implementation deadline, which is June 2021.

The European Commission’s department for energy (DG ENER) has assigned the design of the new standard as well as for instance giving guidelines for IT infrastructure, fraud prevention and residual mix calculation to the FaStGO-project. You can find the project’s tasks and more detailed information here. In this blog we will focus on FaStGOs effects on the technical requirements for GOs as well as the changing requirements for the IT infrastructure.

The main aim of the FaStGO-project is to support the CEN & CENELEC official standardization work. Amid growing volumes, variety, and the number of participating countries, DG ENER also wanted to develop a vision and specification for the future IT infrastructure for GOs. Registries and hubs are very important part of the practical level GO management. Thus, the Task 3 of FaStGO develops a vision, requirements specification, and a data protocol for multi-energy/-purpose GO.

Task 3 of the FaStGO

The vision part of the work, task 3.1, identified a wide range of possible IT infrastructure models ranging from a fully decentralized peer-to-peer network of blockchain wallets to a fully centralized single registry model. These were analyzed and compared with the current hub-centric model. Also, stakeholders were consulted and their feedback incorporated during the process.

Centralized single registry model and a hybrid consisting of a central registry and national registries were seen as efficient and economical. They were nonetheless not recommended in the short term because of issues relating to sovereignty of countries and legal mandate to run such a service. Instead, the recommendation was to take an evolutionary approach based on already existing hub-centric architecture. The evolutions would add central elements to the existing hub, such as automatic residual mix calculation, and a centralized cancellation facility. The full vision document can be found here.

Laura Malinen and Marko Lehtovaara

Laura Malinen and Marko Lehtovaara

Laura is Grexel’s project manager who spends her days building customer success in various projects. She is a curious follower of the trends and development of the field.

Marko is the CEO of Grexel who has spent the last 20 years studying, building and fixing energy certification systems in Europe and abroad.

In this blog they discuss the FaStGO-project especially from the perspective of a registry service provider.

The task 3.2 developed a data protocol for the multi-energy carrier and multi-purpose GO. The work took the existing AIB EECS data protocol as the basis and expanded and modernized it. Now it carries the new data fields foreseen in the standard proposal, different purposes, as well as other foreseen changes. The main challenge of this task was the moving target; the official standardization work was and is, at the time of writing of this blog, ongoing. The outcome of the data protocol task gives the issuing bodies and registry providers visibility on the future and can be used a basis for designing support for RED II. One must, however, follow the official standard development to be able to catch the final version of required and optional data fields, as well as related validations. The final task 3.2 report can be found here.

The high-level requirements specification, task 3.3, explores technical feasibility of the recommended infrastructural novelties recommended by the vision. The requirements are specified in the form of user stories, epics and data structure, which can be further groomed and implemented using an agile development approach. The new features are also evaluated and recommendation on implementation approach given. The task 3.3 report is not published yet, but we will link it as soon as it will be available.

Practical implications

There will be plenty of administrative work regarding the changes in the coming years. One key decision is that each member state or region needs to decide on the Issuing Bodies for different energy carriers. This can of course be solved in several ways – for instance Finland will de-centralize the issuing body duties while Sweden centralizes them to a single agency.

These new (or existing) issuing bodies must then implement the scheme(s) according to at least the official standard, and in addition, to decide whether to join AIB or ERGaR to further harmonise the implementation to facilitate international trade. Naturally, also registries need to be either acquired or updated.

On a practical note this puts the ball in the IT service providers’ court.

We want our systems to comply with all the relevant European regulation. This also includes the upcoming standard. Although keeping the systems constantly up to speed with the changing regulatory framework will require a lot of work from us, it does not have to require it from our customers. We truly consider keeping the system compliant with regulation our problem. In addition to providing registry services we are happy to consult both new and existing issuing bodies in the challenges the upcoming significant changes will pose. We’re happy to work on this with you – please contact us .