EUROPEAN COMMISSION

Brussels, 30.6.2020

COM(2020) 271 final

2020/0130(NLE)

Proposal for a

COUNCIL DECISION

on the position to be taken on behalf of the European Union in the Joint Committee, established by the Agreement between the European Union and the Swiss Confederation on the linking of their greenhouse gas emissions trading systems, as regards amending Annexes I and II to the Linking Agreement and the adoption of Linking Technical Standards

(Text with EEA relevance)

EXPLANATORY MEMORANDUM

1.Subject matter of the proposal

This proposal concerns the decision establishing the position to be taken on the Union's behalf in the Joint Committee established by the Agreement between the European Union and the Swiss Confederation on the linking of their greenhouse gas emissions trading systems in connection with the envisaged adoption of a decision regarding amending Annexes I and II to the Agreement and the adoption of Linking Technical Standards

2.Context of the proposal

2.1.The Agreement between the European Union and the Swiss Confederation on the linking of their greenhouse gas emissions trading systems

The Agreement between the European Union and the Swiss Confederation on the linking of their greenhouse gas emissions trading systems (‘the Agreement’) aims to connect the EU Emissions Trading System (EU ETS) with the Swiss one by allowing that allowances issued in one system can be traded and used for compliance in the other one, thus expanding the opportunities for climate change mitigation. The Agreement entered into force on 1 January 2020.

2.2.The Joint Committee

The Joint Committee, established by Article 12 of the Agreement, is responsible for administering the Agreement and ensuring its implementation. It can decide to adopt new annexes to the Agreement or amend existing ones. It can also discuss amendments to the Articles of the Agreement, facilitate the exchange of views on the Parties' legislation and conduct reviews of the Agreement.

The Joint Committee is a bilateral body composed of representatives of the Parties (the EU and Switzerland). Decisions taken by the Joint Committee shall be agreed by both Parties.

Pursuant to Article 3(7) of the Agreement, the Swiss registry administrator and the Union central administrator shall develop Linking Technical Standards (LTS) based on the principles set out in Annex II of the Agreement. The LTS shall describe the detailed requirements for establishing a robust and secure connection between the Swiss Supplementary Transaction Lot (SSTL) and the European Union Transaction Log (EUTL). The LTS will take effect, when adopted by decision of the Joint Committee.

2.3.The envisaged act of the Joint Committee

During its third meeting, which will be held in 2020, the Joint Committee is to adopt a decision pursuant to Article 3(7) of the Agreement regarding the adoption of Linking Technical Standards and will amend Annex I and II to the Agreement in accordance with Article 13(2) of the Agreement (‘the envisaged act’).

The purpose of the envisaged act is to describe, based on the principles set out in Annex II of the Agreement, the detailed requirements for establishing a robust and secure connection between the SSTL and the EUTL. To this end, it outlines the baseline for the technical specifications in terms or architectural, service and security requirements. With a view to minimising the risk of fraud, misuse or criminal activities involving the registries and to protecting the integrity of the link, details of the necessary procedures as well as their underlying considerations and agreements, should be treated confidentially. Therefore, the envisaged act addresses the necessary elements at a rather high level without revealing standards related to the security and safety of the link. Those should be laid down in further technical guidelines to be developed by a working group in accordance with Article 12(5) of the Agreement. The working group should at least include the Swiss registry administrator and the Union central administrator, both of which should ensure the continued, effective and efficient operation of the link as well as its adaptation to technical progress and new requirements relating to the safety and security of the link. Due to both the technical and sensitive nature of such guidelines and the need to adapt them to maintain an appropriate level of safety and security of the link, representatives of the Union in the Joint Committee should be informed and, where appropriate, able to agree such guidelines without a further decision of the Council.

The amendment to Annex I allows taking into account the progress made on establishing the registry link, when it comes to transferring the accounts of aircraft operators from the Union registry to the Swiss registry in accordance with Point 17 of Part B of Annex I to the Agreement. This way, a smooth transition of those accounts from the Union registry to the Swiss registry is ensured.

The amendment to Annex II to the Agreement also became necessary in the light of recent developments to ensure that the link can be made operational within an appropriate time frame. To this end, the amendment provides for an increased level of flexibility rendering a broader, but equivalent set of technologies compatible with the requirements of Annex II.

The envisaged act will become binding on the parties in accordance with Article 3(7) of the Agreement, which provides that the LTS and the amendments to Annexes I and II will take effect when adopted by decision of the Joint Committee. In accordance with Article 12(3) of the Agreement, decisions taken by the Joint Committee in the cases provided for in this Agreement will, upon their entry into force, be binding on the Parties.

3.Position to be taken on the Union's behalf

The Council Decision based on this proposal from the Commission determines the position of the European Union concerning the Decision of the Joint Committee to be taken on the adoption of Linking Technical Standards (LTS) and amendments to Annexes I and II for the operation of the link between the EU ETS and the ETS of Switzerland.

Article 3(7) of the Linking Agreement requires the development of Linking Technical Standards that will take effect following their adoption by the Joint Committee. The LTS are based on the principles laid down in Annex II of the Agreement and describe the detailed requirements for establishing a robust and secure connection between the transaction logs of the EU ETS and the ETS of Switzerland, with which both sides have to comply to make the link between the EU ETS and the ETS of Switzerland operational. For this reason, they are necessary for the link to work.

In accordance with Decision No 2/2019 of the Joint Committee 1 of 5 December 2019 2 , the LTS relate to a provisional solution for the link between the EU ETS and the ETS of Switzerland. The provisional solution should be available as from May 2020 or as soon as possible thereafter.

In the light of recent developments, making the provisional solution available as from May 2020 or as soon as possible thereafter requires an increased level of flexibility in order not to make the implementation of the link depending on the operationalisation of a specific technology, as long as equivalent options are feasible.

Against this background and in order to ensure practically uninterrupted market access of certain aircraft operators, the transfer of their accounts from the Union registry to the registry of Switzerland should be undertaken with full regard to when it is possible to transfer allowances from one system to the other.

The development of a well-functioning international carbon market through bottom-up linking of emissions trading systems is a long-term policy goal of the EU and the international community, notably as a means to achieve the climate objectives of the Paris Agreement. In this respect, Article 25 of the Directive establishing the EU's Emissions Trading System (EU ETS) allows for the EU ETS to be linked with other emissions trading systems provided they are mandatory, have an absolute cap on emissions and are compatible, as it is the case with the Swiss system. Following the entry into force of the Agreement on 1 January 2020, the LTS taking effect represent an important step towards the implementation of the Agreement.

4.Legal basis

4.1.Procedural legal basis

4.1.1.Principles

Article 218(9) of the Treaty on the Functioning of the European Union (TFEU) provides for decisions establishing ‘the positions to be adopted on the Union’s behalf in a body set up by an agreement, when that body is called upon to adopt acts having legal effects, with the exception of acts supplementing or amending the institutional framework of the agreement.’

The concept of ‘acts having legal effects’ includes acts that have legal effects by virtue of the rules of international law governing the body in question. It also includes instruments that do not have a binding effect under international law, but that are ‘capable of decisively influencing the content of the legislation adopted by the EU legislature’ 3 .

4.1.2.Application to the present case

The Joint Committee is a body set up pursuant to Article 12 of the Agreement between the European Union and the Swiss Confederation on the linking of their greenhouse gas emissions trading systems.

The act which the Joint Committee is called upon to adopt constitutes an act having legal effects. The envisaged act will be binding under international law in accordance with Article 12(3) of the Agreement between the European Union and the Swiss Confederation on the linking of their greenhouse gas emissions trading systems.

The envisaged act does not supplement or amend the institutional framework of the Agreement.

Therefore, the procedural legal basis for the proposed decision is Article 218(9) TFEU.

4.2.Substantive legal basis

4.2.1.Principles

The substantive legal basis for a decision under Article 218(9) TFEU depends primarily on the objective and content of the envisaged act in respect of which a position is taken on the Union's behalf. If the envisaged act pursues two aims or has two components and if one of those aims or components is identifiable as the main one, whereas the other is merely incidental, the decision under Article 218(9) TFEU must be founded on a single substantive legal basis, namely that required by the main or predominant aim or component.

4.2.2.Application to the present case

The main objective and content of the envisaged act relate to environment.

Therefore, the substantive legal basis of the proposed decision is Article 192(1) TFEU.

4.3.Conclusion

The legal basis of the proposed decision should be Article 192(1) TFEU, in conjunction with Article 218(9) TFEU.

2020/0130 (NLE)

Proposal for a

COUNCIL DECISION

on the position to be taken on behalf of the European Union in the Joint Committee, established by the Agreement between the European Union and the Swiss Confederation on the linking of their greenhouse gas emissions trading systems, as regards amending Annexes I and II to the Linking Agreement and the adoption of Linking Technical Standards

(Text with EEA relevance)

THE COUNCIL OF THE EUROPEAN UNION,

Having regard to the Treaty on the Functioning of the European Union, and in particular Article 192(1), in conjunction with Article 218(9) thereof,

Having regard to the proposal from the European Commission,

Whereas:

(1)The Agreement between the European Union and the Swiss Confederation on the linking of their greenhouse gas emissions trading systems 4 (‘the Agreement’) was concluded by the Union by Council Decision (EU) 2018/219 5 and entered into force on 1 January 2020.

(2)Pursuant to Article 3(7) of the Agreement, the Joint Committee may adopt a decision on Linking Technical Standards (LTS) developed by the Swiss registry administrator and the Union central administrator and based on the principles set out in Annex II to the Agreement, describing the detailed requirements for establishing a robust and secure connection between the Swiss Supplementary Transaction Log (SSTL) and the European Union Transaction Log (EUTL). The LTS are then to take effect following their adoption by decision of the Joint Committee.

(3)Annex I to the Agreement should be amended in accordance with Article 13(2) of the Agreement to ensure a smooth transition in administration of aircraft operators attributed to Switzerland for the first time after the entry into force of the Agreement in accordance with point 17 of Part B of Annex I to the Agreement 6 by taking account of the progress made on establishing the registry link.

(4)Annex II should be amended to provide for a larger, but equivalent set of technologies to set up the registry link required by the Agreement.

(5)The Joint Committee, during its third meeting, to be held in 2020, is to adopt the developed Linking Technical Standards.

(6)It is appropriate to establish the position to be taken on the Union's behalf in the Joint Committee, as the LTS will be binding on the Union.

(7)Adoption of the LTS represents an important element relating to the implementation of the Agreement, in order to allow establishing the technical foundations of the link and to outline the baseline for the technical specifications in terms of architectural, service and security requirements.

(8)In accordance with Article 13(1) of the Agreement, the Joint Committee may agree on technical guidelines to ensure the proper implementation of the Agreement including establishing a robust and secure connection between the SSTL and the EUTL. The technical guidelines should be developed by a working group set up pursuant to Article 12(5) of the Agreement. The working group should at least include the Swiss Registry administrator and the Union Registry central administrator and should furthermore assist the Joint Committee in its functions pursuant to Article 13 of the Agreement.

HAS ADOPTED THIS DECISION:

Article 1

The position to be taken on the Union's behalf in the third meeting of the Joint Committee established by the Agreement between the European Union and the Swiss Confederation on the linking of their greenhouse gas emissions trading systems, as regards the adoption of Linking Technical Standards and amending Annexes I and II to the Agreement, shall be based on the draft act of the Joint Committee attached to this Decision.

Minor changes to the draft Decision may be agreed to by the representatives of the Union within the Joint Committee without a further decision of the Council.

Article 2

The representatives of the Union within the Joint Committee may agree to technical guidelines to ensure the proper implementation of the Agreement including establishing a robust and secure connection between the SSTL and the EUTL. To this end, a working group shall be set up pursuant to Article 12(5) of the Agreement that shall assist the Joint Committee in its functions pursuant to Article 13 and in particular Article 13(1) of the Agreement.

Done at Brussels,

(1)    The position to be taken on behalf of the EU has been determined by Council Decision (EU) 2019/2106 of 21 November 2019 on the position to be taken, on behalf of the European Union, within the Joint Committee established by the Agreement between the European Union and the Swiss Confederation on the linking of their greenhouse gas emissions trading systems, as regards the amendment of Annexes I and II to the Agreement (OJ L 318 of 10.12.2019, p. 96).

(2)    Available from https://ec.europa.eu/clima/sites/clima/files/ets/markets/docs/decision_201902_swiss_ets_linking.pdf  

(3)    Judgment of the Court of Justice of 7 October 2014, Germany v Council, C-399/12, ECLI:EU:C:2014:2258, paragraphs 61 to 64.

(4)    OJ L 322, 7.12.2017, p. 3.

(5)    Council Decision (EU) 2018/219 of 23 January 2018 on the conclusion of the Agreement between the European Union and the Swiss Confederation on the linking of their greenhouse gas emissions trading systems (OJ L 43, 16.2.2018, p. 1).

(6)    Decision no 2/2019 of the Joint Committee established by the Agreement between the European Union and the Swiss Confederation on the linking of their greenhouse gas emissions trading systems of 5 December 2019 amending Annexes I and II to the Agreement between the European Union and the Swiss Confederation on the linking of their greenhouse gas emissions trading systems, available from https://ec.europa.eu/clima/sites/clima/files/ets/markets/docs/decision_201902_swiss_ets_linking.pdf  

EUROPEAN COMMISSION

Brussels, 30.6.2020

COM(2020) 271 final

ANNEX

to the

Proposal for a Council Decision

on the position to be taken on behalf of the European Union in the Joint Committee, established by the Agreement between the European Union and the Swiss Confederation on the linking of their greenhouse gas emissions trading systems, as regards amending Annexes I and II to the Linking Agreement and the adoption of Linking Technical Standards

DECISION No 2/2020 OF THE JOINT COMMITTEE ESTABLISHED BY THE AGREEMENT BETWEEN THE EUROPEAN UNION AND THE SWISS CONFEDERATION ON THE LINKING OF THEIR GREENHOUSE GAS EMISSIONS TRADING SYSTEMS
of …
on amending Annex I and II to the Agreement and Linking Technical Standards (LTS)

THE JOINT COMMITTEE

Having regard to the Agreement between the European Union and the Swiss Confederation on the linking of their greenhouse gas emissions trading systems 1 (hereinafter ‘the Agreement’) and in particular Article 3(7) and Article 13(2) thereof,

Whereas:

(1)Decision No 2/2019 of the Joint Committee of 5 December 2019 2 amended Annexes I and II to the Agreement thus fulfilling the conditions for linking set out in the Agreement.

(2)Following adoption of Decision No 2/2019 of the Joint Committee and pursuant to Article 21(3) of the Agreement, the Parties exchanged their instruments of ratification, since they consider all conditions for linking as set out in the Agreement to have been fulfilled.

(3)In accordance with Article 21(4) of the Agreement, the Agreement entered into force on 1 January 2020.

(4)Annex I to the Agreement should be amended in accordance with Article 13(2) of the Agreement to ensure a smooth transition in administration of aircraft operators attributed to Switzerland for the first time by taking account of the progress made on establishing the registry link.

(5)In order to accommodate recent developments and ensure an increased level of flexibility to establish the registry link required by the Agreement, Annex II to the Agreement should be amended in accordance with Article 13(2) of the Agreement to provide for a larger, but equivalent set of technologies to set up the registry link.

(6)Pursuant to Article 3(7) of the Agreement, the Swiss registry administrator and the Union central administrator should develop Linking Technical Standards (LTS) based on the principles set out in Annex II of the Agreement. The LTS should describe the detailed requirements for establishing a robust and secure connection between the Swiss Supplementary Transaction Log (SSTL) and the European Union Transaction Log (EUTL). The LTS should take effect when adopted by decision of the Joint Committee.

(7)In accordance with Article 13(1) of the Agreement, the Joint Committee should agree on technical guidelines to ensure the proper implementation of the Agreement including on establishing a robust and secure connection between the SSTL and the EUTL. Technical guidelines may be developed by a working group set up pursuant to Article 12(5) of the Agreement. The working group should at least include the Swiss Registry administrator and the Union Registry central administrator and should assist the Joint Committee in its functions pursuant to Article 13 of the Agreement.

(8)In view of the technical nature of the guidelines and the need to adapt them to ongoing developments, the technical guidelines developed by the Swiss registry administrator and the Union central administrator should be submitted to the Joint Committee for information or, where appropriate, approval,

HAS ADOPTED THIS DECISION:

Article 1

The second paragraph of point 17 in Part B of Annex I to the Agreement is hereby replaced by the following text:

“Aircraft operators attributed to Switzerland for the first time after the entry into force of this Agreement shall be administered by Switzerland after 30 April of the year of attribution and once the provisional registry link is operational.”

Article 2

The fourth subparagraph of Annex II to the Agreement is hereby replaced by the following text:

“The LTS shall specify that the communications between the SSTL and the EUTL consist of secure exchanges of webservices messages based on the following technologies 3 or equivalent:

·web services using Simple Object Access Protocol (SOAP)

·hardware-based Virtual Private Network (VPN)

·XML (Extensible Markup Language)

·digital signature, and

·network time protocols.”

Article 3

The Linking Technical Standards (LTS), as annexed to this Decision, are hereby adopted.

Article 4

Herewith, a working group shall be set up pursuant to Article 12(5) of the Agreement. It shall assist the Joint Committee to ensure the proper implementation of the Agreement including the development of technical guidelines for the implementation of the LTS.

The working group shall at least include the Swiss Registry administrator and the Union Registry central administrator.

Article 5

This Decision shall enter into force on the day of its adoption.

Done in English at Brussels, on XX 2020.

For the Joint Committee

ANNEX

LINKING TECHNICAL STANDARDS (LTS)

pursuant to Article 3(7) of the Agreement between the European Union and the Swiss Confederation on the linking of their greenhouse gas emissions trading systems

Standard for Provisional Solution

1.Glossary

Table 1-1 Business Acronyms and Definitions

Table 1-2 Technical Acronyms and Definitions

2.Introduction

The Agreement between the European Union and the Swiss Confederation on the linking of their greenhouse gas emissions trading systems of 23 November 2017 (“Agreement”) provides for the mutual recognition of emission allowances that can be used for compliance under the Emissions Trading System of the European Union (“EU ETS”) or the Emissions Trading System of Switzerland (“ETS of Switzerland”). To operationalise the link between the EU ETS and the ETS of Switzerland, a direct link between the European Union Transaction Log (EUTL) of the Union Registry and the Swiss Supplementary Transaction Log (SSTL) of the Swiss registry shall be established, which will enable the registry-to-registry transfer of emission allowances issued under either ETS (Article 3(2) of the Agreement). To operationalise the link between the EU ETS and the ETS of Switzerland, a provisional solution shall be in place by May 2020 or as soon as possible thereafter. Parties shall cooperate to replace the provisional solution with a permanent registry link as soon as possible (Annex II of the Agreement).

Pursuant to Article 3(7) of the Agreement, the Swiss registry administrator and the central administrator of the Union Registry shall develop Linking Technical Standards (LTS) based on the principles set out in Annex II to the Agreement, describing the detailed requirements for establishing a robust and secure connection between the SSTL and the EUTL. The LTS developed by the administrators shall take effect when adopted by a decision of the Joint Committee.

The LTS, as recorded in this document is to be adopted by the Joint Committee by its Decision No 2/2020. In accordance with this Decision, the Joint Committee shall request the Swiss registry administrator and the Union central administrator to develop further technical guidelines to operationalise the link and to ensure that these are continuously adapted to technical progress and new requirements relating to the safety and security of the link and to its effective and efficient operation.

2.1.Scope

This document represents the common understanding between the Parties to the Agreement regarding the establishment of the technical foundations of the link between the registries of the EU ETS and the ETS of Switzerland. While it outlines the baseline for the technical specifications in terms of architectural, service and security requirements, some further detailed guidance will be needed to operationalise the link.

For the proper functioning, the link will require processes and procedures in order to further operationalise the link. Pursuant to Article 3(6) of the Agreement, those matters are detailed in a separate common operational procedures (COP) document, to be adopted separately by decision of the Joint Committee.

2.2.Addressees

This document is addressed to the Swiss registry administrator and the central administrator of the Union Registry.

3.General Provisions

3.1.Architecture of the Communication Link

The purpose of this section is to provide a description of the general architecture of the operationalisation of the link between the EU ETS and the ETS of Switzerland and the different components involved in it.

Security being a key part for the definition of the architecture, all measures have been taken to have a robust architecture. Although the foreseen permanent registry link will be based on web services, the provisional solution will use a file exchange mechanism instead.

The technical solution uses:

·A secure message exchange transfer protocol.

·XML messages.

·XML based digital signature and encryption.

·VPN Appliance or equivalent secure data transport network.

3.1.1.Message Exchange

The communication between the Union Registry and the Swiss registry will be based on a message exchange mechanism through secured channels. Each end will count on its own repository of received messages.

Both Parties will keep a log of the messages received, together with the processing details.

Errors or unexpected status are to be reported, as alerts, and human contact between the support teams should take place.

3.1.2.XML Message – High level Description

An XML Message contains one of the following:

·One or several Transaction Requests and/or one or several Transaction Responses;

·One operation/response related to reconciliation;

·One Test message.

Every message contains a header with:

·Originating ETS system;

·Sequence Number.

3.1.3.Ingestion Windows

The provisional solution is based on predefined ingestion windows that are followed by a set of named events. Transaction requests received through the link will only be ingested at predefined intervals, and includes a technical validation for outgoing and incoming transactions. In addition, reconciliations may run in a daily basis and can be triggered manually.

3.1.4.Transaction Message Flows

Outgoing transactions

This reflects the point of view of the transferring ETS. The sequence diagram above depicts all the specific outgoing transaction flows.

Main flow “Normal Transaction” (with steps indicated in the drawing above):

(a)On the transferring ETS, the transaction request is sent from the registry to the Transaction log, once all the business delays are over (24 hours delay, where applicable).

(b)Transaction log validates the transaction request.

(c)The transaction request is sent to the destination ETS.

(d)The acceptance response is sent to the originating ETS’ registry.

(e)The destination ETS validates the transaction request.

(f)The destination ETS sends the acceptance response back to the originating ETS’ Transaction log.

(g)The Transaction log sends the acceptance response to the registry.

Alternative flow “Transaction Log Rejection” (with steps indicated in the drawing above, starting equally from a) ):

(a)In the originating system, the transaction request is sent from the registry to the Transaction log, once all the business delays are over (24 hours delay, where applicable).

Followed by:

(b)Transaction log does not validate the request

(c)Rejection message is sent to the originating registry.

Alternative flow “ETS Rejection” (with steps indicated in the drawing above, starting from a)):

(a)In the originating ETS, the transaction request is sent from the registry to the Transaction log, once all the business delays are over (24 hours delay, where applicable).

(b)Transaction log validates the transaction.

(c)The transaction request is sent to the destination ETS.

(d)The acceptance message is sent to the originating ETS’ registry.

Followed by:

(e)The acquiring ETS’ Transaction log does not validate the transaction.

(f)Acquiring ETS sends the refusal response to the transferring ETS’ Transaction log.

(g)Transaction log send the refusal to the registry.

Incoming Transactions

This reflects the point of view of the acquiring ETS. The specific flow is depicted in the following sequence diagram:

The diagram shows:

1.When the acquiring ETS’ Transaction log validates the request, it sends the acceptance message to the Transferring ETS and a ‘transaction completed’ message to the acquiring ETS’ registry.

2.When an incoming request is refused on the acquiring Transaction log and it is refused, the transaction request is not sent to the acquiring ETS’ registry.

Protocol

The transaction message cycle involves only two messages:

·Transferring ETS → Acquiring ETS Transaction Proposal.

·Acquiring ETS → Transferring ETS Transaction Response: Either Accepted or Rejected (including the reason for rejection).

–Accepted: Transaction is completed.

–Rejected: Transaction is terminated.

Transaction status

·Transferring ETS transaction status will be set to ‘proposed’ when the request is sent.

·Acquiring ETS transaction status will be set to ‘proposed’ when the request is received and while it is being treated.

·Acquiring ETS transaction status will be set to ‘completed’/’terminated’, when the proposal is processed. Acquiring ETS will then send the corresponding acceptance/rejection message.

·Transferring ETS transaction status will be set to completed/terminated when the acceptance/rejection is received and processed.

·In the Transferring ETS the transaction status will remain as proposed if no response is received.

·Acquiring ETS will set to ‘terminated’ any transaction staying as proposed for more than 30 minutes.

3.2.Data Transfer Security

The data in transit will be subject to four levels of security:

(1)Network access control: Firewall and network interconnection layer.

(2)Transport level encryption: VPN or equivalent secure data transport network.

(3)Session level encryption: Secure message exchange transfer protocol.

(4)Application level encryption: XML Content encryption and signature.

3.2.1.Firewall and Network Interconnection

The link shall be established over a network protected by a hardware-based firewall. The firewall shall be configured with rules such that only “registered” clients can make connections to the VPN server.

3.2.2.Virtual Private Network (VPN)

All communications between the Parties shall be protected using a secure data transport technology. In the case of a Virtual Private Network (VPN), the infrastructure should be based on hardware or virtual appliances. VPN technologies provide the ability to "tunnel" through a network like the Internet from one point to another, protecting all communications. Prior to the creation of the VPN tunnel, a digital certificate is issued to a prospective client end-point, allowing the client to provide proof of identity during the negotiation of the connection. Each Party is responsible for installing the certificate into its VPN end-point. Using digital certificates, each end VPN server will access a central authority to negotiate authentication credentials. During the tunnel creation process, encryption is negotiated, ensuring that all communications through the tunnel are protected.

The client VPN end-points shall be configured to maintain the VPN tunnel permanently, in order to allow reliable, two-way, real-time communication between the Parties at all times.

Any other equivalent solution shall be compliant with the abovementioned principles.

3.2.3.IPSec Implementation

In case of using a VPN solution, the use of the IPSec protocol to form the site-to-site VPN infrastructure will provide for site-to-site authentication, data integrity, and data encryption. IPSec VPN configurations ensure proper authentication between two end-points in a VPN connection. The Parties will identify and authenticate the remote client via the IPSec connection using a digital certificates provided by a Certificate Authority recognised by the other end.

IPSec also ensures data integrity of all communications passed through the VPN tunnel. Data packets are hashed and signed using the authentication information established by the VPN. Confidentiality of the data is assured likewise by enabling IPSec encryption.

3.2.4.Secure Message Exchange Transfer Protocol

The provisional solution relies on multiple encryption layers to securely exchange data between the Parties. Both systems and their different environments are interconnected at the network level by means of VPN tunnels or equivalent secure data transport networks. At the application level files are transferred using a secure message exchange transfer protocol at session level.

3.2.5.XML Encryption and Signature

Within XML files, signing and encryption occurs at two levels. Every transaction request, transaction response and reconciliation message is digitally signed individually.

In a second step, every sub element of the ‘message’ element is individually encrypted.

In addition, as third step and to ensure the integrity and non-repudiation of the whole message, the root element message is digitally signed. This results in a high level of protection for the XML embedded data. The technical implementation observes the World Wide Web Consortium standards.

To decrypt and verify the message, the process is followed in reverse order.

3.2.6.Cryptographic Keys

Public key cryptography will be used for encryption and signing.

For the specific case of IPSec, a digital certificate issued by a Certificate Authority (CA) trusted by both Parties shall be used. This CA verifies identity and issues certificates which are used to positively identify an organisation and setup secure data communications channels between the Parties.

3.3.List of Functions under the Link

The link specifies the transmission system for a series of functions that implement the business processes derived from the Agreement. The link also includes the specification for the reconciliation process and for the test messages that will allow the implementation of a heartbeat monitoring.

3.3.1.Business Transactions

From the business perspective, the link contemplates four (4) types of Transaction Requests:

·External transfer:

·After entry into force of the ETS linking, EU and CH allowances are fungible, and thus fully transferrable, between the Parties.

·A transfer sent through the link will involve a transferring account on an ETS and acquiring account on the other ETS.

·The transfer can include any amount of the four (4) types of allowances:

·Swiss general allowances (CHU)

·Swiss aviation allowances (CHUA)

·EU general allowances (EUA)

·EU aviation allowances (EUAA)

·International Allocation:

Aircraft Operators administered by one ETS with obligations on the other ETS and entitled to receive free allowances from that second ETS, will receive free aviation allowances, from the second ETS, by means of the international allocation transaction.

·Reversal of International Allocation:

This transaction will happen in the case that free allowances allocated to an aircraft operator holding by the other ETS has to be reversed in total.

·Return of Excess Allocation:

Similar to the reversal, but where the allocation does not need to be fully reversed, and only the over allocated allowances have to be returned to the allocating ETS.

3.3.2.Reconciliation Protocol

Reconciliations will only take place after the windows for messages ingestion, validation and processing are closed.

Reconciliations are an integral part of the security and consistency measures of the linking. Both Parties will agree on the exact timing of reconciliation before creating any schedule. A daily scheduled reconciliation can take place if agreed by both Parties. At least a scheduled reconciliation will be executed however after the ingestion takes place.

Either Party can nevertheless initiate manual reconciliations at any time.

3.3.3.Test Message

A test message is foreseen to test end-to-end communication. The message will contain data that will identify it as a test and will be answered upon reception by the other end.

3.4.Standards for Web Services

Web services will not be used in the provisional solution. It is worth noting however that the shape and format of XML messages will remain unchanged to a great extent. With the introduction of the permanent registry link in the future, web services should allow the exchange of XML messages in real-time.

3.5.Web Services Specific Definition

This section is not applicable for the provisional solution. As mentioned in the previous section, web services will only be used in the future permanent registry link.

3.6.Data Logging Requirements

To support the need for both Parties to maintain accurate and consistent information, and to provide tools for use in the reconciliation process to resolve inconsistencies, four (4) types of data logs shall be maintained by both Parties:

·Transaction logs;

·Reconciliation logs;

·Message archive;

·Internal audit logs.    

All data in these logs shall be maintained at least during three (3) months for the purposes of troubleshooting and their further retention will depend on the applicable law at each end for the purpose of auditing. Log files older than three (3) months may be archived into a secure location in an independent IT system, as long as it can be retrieved or accessed within a reasonable period.

Transaction Logs

Both EUTL and SSTL subsystems contain Transaction log implementations.

More specifically, the Transaction logs will keep a record of each proposed transaction sent to the other ETS. Each record contains all the fields of the transaction content and the subsequent outcome of the transaction (the response of the receiving ETS). The Transaction logs will also keep a record for the incoming transactions as well as the response sent to the originating ETS.

Reconciliation Logs

The Reconciliation Log contains a record of each reconciliation message exchanged between both Parties, including the reconciliation id, the timestamp and the result of the reconciliation: Reconciliation status “Pass” or “Discrepancies”. In the provisional solution reconciliation messages are an integral part of the messages exchanged.

Both Parties shall log each request and its response in the Reconciliation Log. Although information in the Reconciliation Log is not shared directly as part of the Reconciliation itself, access to this information may be necessary in order to resolve inconsistencies.

Message Archive

Both Parties are required to archive a copy of the exchanged data (the XML files), sent and received, and whether those or XML messages were correct in their format or not.

The main purpose of the archive is for auditing, to have an evidence of what was sent and received to and from the other Party. In that sense, along with the files, the related certificates need to be archived as well.

These files will also provide additional information for troubleshooting.

Internal Audit Log

These logs are defined and used by each Party on its own.

3.7.Operational Requirements

The exchange of data between both systems is not fully autonomous in the provisional solution, this means it requires operators and procedures to operationalise the link.

4.Availability Provisions

4.1.Communication Availability Design

The architecture for the provisional solution is fundamentally an ICT infrastructure and software that allows the communication between the ETS of Switzerland and the EU ETS. Ensuring high levels of availability, integrity and confidentiality of this flow of data becomes then an essential aspect to consider in the design of the provisional solution and the permanent registry link. Being a project in where the ICT infrastructure, the custom made software, and the processes play an integral role, all three elements have to be taken into account in order to design a resilient system.

ICT infrastructure resilience

General provisions chapter to this document detail the architectural building blocks. On the ICT infrastructure side, the provisional linking sets up a resilient VPN network (or equivalent) that creates secure communication tunnels over which secure message exchanges can take place. Other infrastructure elements are configured in high-availability and/or count on fall-back mechanisms.

Custom Software resilience

The custom developed software modules enhance the resilience by retrying the communication for a given period of time with the other end if due to any reason, it is not available.

Service resilience

In the provisional solution, data exchanges between Parties occur at predefined timeslots throughout the year. Some of the steps required in the prescheduled data exchanges require manual intervention by system operators and/or registry administrators. Taking this aspect into account, and in order to increase the availability and success of the exchanges:

·The operational procedures foresee significant time windows to perform each step.

·The software modules for the provisional solution implement asynchronous communication.

·The automatic reconciliation process will detect if there were issues in the ingestion of data files at either end.

·Monitoring processes (ICT infrastructure and custom software modules) are considered into and trigger Incident Management procedures (as defined in the common operational procedures document). Those procedures that aim at reducing the time to restore normal operation following incidents are essential to ensure high availability ratios.

4.2.Initialisation, Communication, Re-activation and Testing Plan

All different elements involved in the architecture of the provisional solution shall pass a series of individual and collective tests in order to confirm the platform is ready at ICT infrastructure and information system level. These operational tests are a compulsory prerequisite each time the platform transitions the provisional solution from suspended to operational status.

The operational status activation of the link requires then the successful execution of a predefined test plan. This shall confirm that each registry has performed a set of internal test first, followed by end-to-end connectivity validation prior to begin the submission of production transactions between both Parties.

The test plan should mention the overall test strategy and details about the testing infrastructure. In particular, for each element in every test block it should include:

·The test criteria and tools;

·The roles assigned to perform the test;

·The expected results (positive and negative);

·Test schedule;

·The logging of test results requirements;

·Troubleshooting documentation;

·Escalation provisions.

As a process, the operational status activation tests could be split in four (4) conceptual blocks or phases:

4.2.1.Internal ICT Infrastructure Tests

These tests are meant to be performed and/or checked individually by both Parties at each end.

Every element of ICT infrastructure at each end shall be tested individually. This includes every single component of the infrastructure. These tests can be executed automatically or manually but shall verify that every element of the infrastructure is operational.

4.2.2.Communication Tests

These tests shall start individually at each Party and conclude in cooperation with the other end.

Once individual elements are operational, the communication channels between both registries needs to be tested. To this end, each Party shall verify that Internet access works, the VPN tunnels (or equivalent secure transport network) are established, and there is site-to-site IP connectivity. Reachability of the local and remote infrastructure elements and IP connectivity should then be confirmed to the other end.

4.2.3.Full System (end-to-end) Tests

These tests are meant to be executed at each end and results shall be shared with the other Party.

Once communication channels and each individual component of both registries have been tested, each end shall prepare a series of simulated transactions and reconciliation that are representative of all functions to be implemented under the link.

4.2.4.Security Tests

These tests are meant to be performed and/or triggered by both Parties at each end and as detailed in sections ‘Security Testing Guidelines’ and ‘Risk Assessment Provisions’.

Only after each of the four phases/blocks have ended with a predictable results, the provisional link can be considered in operational status.

Testing resources 

Each Party shall count on specific testing resources (specific ICT infrastructure software and hardware) and shall develop testing functions into their respective systems in order to support the manual and continuous validation of the platform. Manual individual or cooperative testing procedures can be executed at any time by registry administrators. Operational status activation is a manual process in itself.

It is likewise foreseen that the platform performs automatic checks at regular intervals. Those checks are aimed at increasing the availability of the platform by detecting early potential infrastructure or software issues. This platform monitoring plan is composed of two elements:

·ICT infrastructures monitoring: at both ends the infrastructure will be monitored by the ICT infrastructure service providers. The automatic tests will cover the different infrastructure elements and the availability of the communication channels.

·Application monitoring: the provisional linking software modules will implement system communication monitoring at application level (either manually and/or at regular intervals) that will test the end-to-end availability of the linking by simulating some of the transactions over the link.

4.3.Acceptance/Testing Environments

The architecture of the Union Registry and the registry of Switzerland consist of the following three environments:

·Production (PROD): This environment holds the real data and processes real transactions.

·Acceptance (ACC): This environment contains non-real or anonymised, representative data. It is the environment where system operators by both Parties validate new releases.

·Test (TEST): This environment contains non-real or anonymised, representative data. This environment is limited to registry administrators and meant to be used to perform integration tests by both Parties.

Except for the VPN (or equivalent network), the three environments are fully independent of each other, meaning hardware, software, databases, virtual environments, IP-addresses, ports are set up and operate independently of each other.

As for the VPN layout, this is set-up in two different environments, one for PROD, another independent one for ACC and TEST.

5.Confidentiality and Integrity Provisions

Security Mechanisms and Procedures foresee a two person-role (4-eye principle) for operations occurring in the link between the Union Registry and the Swiss registry. The two person-role shall apply whenever necessary however, it might not apply to all steps undertaken by registry administrators.

The security requirements are considered and addressed in the security management plan, which includes likewise processes related to the handling of security incidents following an eventual security breach. The operational part of these processes is described in the COP.

5.1.Security Testing Infrastructure

Each Party commits in setting up a security testing infrastructure (by using the common set software and hardware used in the detection of vulnerabilities at development and operation phases):

·Separated from the production environment;

·Where security is analysed by a team independent from the development and the operation of the system.

Each Party commits performing both static and dynamic analysis.

In the case of dynamic analysis (like penetration testing), both Parties commit to restrict the evaluations ordinarily to the test and acceptance environments (as defined in ‘Acceptance/Testing environments’ section). Exceptions to this policy are subject to approval of both Parties.

Before being deployed in the production environment, every software module of the link (as defined in the ‘Architecture of the communication link’ section) shall be security tested.

Testing infrastructure must be separated at both network and infrastructure levels from the production one and allow to carry out the security tests required to check compliance with security requirements.

5.2.Link Suspension and Reactivation Provisions

In case, there is a suspicion that the security of the registry of Switzerland, the SSTL, the Union registry or the EUTL has been compromised, both Parties shall immediately inform each other and suspend the link between the SSTL and the EUTL.

Suspensions

Suspension of the registry link in accordance with the Annex II of the Agreement may happen due to:

·Administrative reasons (maintenance,….), and therefore planned;

·Security reasons (or IT infrastructure breakdowns), and therefore unplanned.

In case of emergency, either Party will inform the other Party and suspend unilaterally the registry link.

If decision is made to suspend the registry link, then each Party will therefore ensure the link is interrupted at network level (by blocking parts or all incoming and outgoing connections).

Communication Reactivation

Decision to reactivate will be taken as detailed in the COP and in any case not before successful completion of the security testing procedures as detailed in ‘Security testing guidelines’ and ‘Initialisation, Communication re-activation and testing plan’ sections.

5.3.Security Breach Provisions

A security breach is considered as a Security Incident impacting the confidentiality and the integrity of any sensitive information and/or the availability of the system handling them.

Sensitive information is identified in the Sensitive Information List and may be handled in the system or in any related part.

Information directly related to the security breach will be considered as sensitive, marked “ETS Critical” and handled according to the handling instructions, unless specified otherwise.

5.4.Security Testing Guidelines

5.4.1.Software

Security testing, including penetration testing if applicable, shall be performed at least on all new major releases of the software in accordance with the security requirements set out in the LTS in order to assess the security of the linking and the related risks.

If no major release has been produced in the last 12 months, a security testing shall be performed on the current system considering the cyber threat evolution that occurred in the last 12 months.

Security testing of the registry link shall be done in the acceptance environment and, if required, in the production environment and with coordination and mutual agreement of both Parties.

Web application testing will observe international open standards such as the ones developed by the Open Web Application Security Project (OWASP).

5.4.2.Infrastructure

The infrastructure supporting the production system shall be regularly scanned against vulnerabilities (at least once a month) and detected vulnerabilities fixed in the same principle as defined in the previous section using up-to-date vulnerability database.

5.5.Risk Assessment Provisions

If penetration testing is applicable it must be included in the security testing.

Each Party may contract a specialized company for the performance of security testing, provided this company:

·Has the skills and the experience of such security testing;

·Is not reporting directly to the developer and/or its contractor and is neither involved in the development of the software of the link nor being a subcontractor of the developer;

·Has signed Non-Disclosure Agreement to keep the results confidential and to handle them at the “ETS Critical” level in accordance with the handling instructions.

(1)    OJ L 322, 7.12.2017, p. 3.

(2)    OJ [XXXX]

(3)    Those technologies are currently used for establishing a connection between the Union Registry and the International Transaction Log as well as between the Swiss Registry and the International Transaction Log.