EUROPEAN COMMISSION Brussels, 17.5.2018 SWD(2018) 181 final COMMISSION STAFF WORKING DOCUMENT



IMPACT ASSESSMENT

Accompanying the document Proposal for a Regulation of the European Parliament and of the Council establishing a European Maritime Single Window environment and repealing directive 2010/65/EU {COM(2018) 278 final}

{SEC(2018) 230 final}

{SWD(2018) 182 final}



Contents 1.Introduction: Political and legal context 1.1.Background: the Reporting Formalities Directive 1.2.Legal context 1.3.Policy context 1.4.Economic and trade context 2.Problem definition 2.1.What is the problem? 2.2.What are the problem drivers? 2.3.How will the problem evolve? 3.Why should the EU act? 3.1.Legal basis 3.2.Subsidiarity: necessity of EU action 3.3.Subsidiarity: added value of EU action 4.Objectives: What is to be achieved? 4.1.General objectives 4.2.Specific objectives 5.What are the available policy options?

5.1.What is the baseline from which options are assessed (option 0)? 5.2.Design of policy options 5.3.Description of policy measures and options 5.4.Overview of main differences between the harmonisation solutions 5.5.Discarded policy options 6.What are the impacts of the policy options? 6.1.Economic impacts 6.2.SME impacts 6.3.Social impacts 6.4.Environmental impacts 6.5.Other impacts 7.How do the options compare? 7.1.Stakeholder preferences 7.2.Effectiveness 7.3.Cost-efficiency 7.4.Coherence 7.5.Proportionality 7.6.Summary: comparison of options 8.Preferred option 9.REFIT (simplification and improved efficiency)

10.How will actual impacts be monitored and evaluated?



List of Annexes Annex 1: Procedural information 61 Annex 2: Stakeholder consultation 68 Annex 3: Who is affected and how? 79 Annex 4: Analytical methods 81 Annex 5: Reporting Formalities Directive 101 Annex 6: Policy options 104 Annex 7: Connected policy areas 112 Annex 8: Trade and economic patterns 118



Glossary Term or acronym Meaning or definition Back-end entities The authorities and IT systems receiving data via the National Single Windows DEM Data Exchange Mechanism ECSA European Community Shipowners’ Association EMSA European Maritime Safety Agency EMSWe European Maritime Single Window Environment ESPO European Sea Ports Organisation ENS Entry Summary Declaration EU European Union FAL Convention on Facilitation of International Maritime Traffic Front end users The shipping operators providing data into the National Single Window in connection to a port call ICT Information and Communication Technologies IMO International Maritime Organisation IPCSA International Port Community Systems Association ISC Inter-Service Consultation MOVE Directorate General for Mobility and Transport NSW National Single Window PCS Port Community System - an electronic platform connecting the systems operated by the organisations and entities making up a seaport community. The Port Community System facilitates exchange of operational or administrative information between different actors in the port; it can also include systems for optimisation of processes (e.g. “smart port” systems). The PCS can be operated and maintained either by a public, private or public/private organisation. RFD Directive 2010/65/EU on Reporting Formalities for ships Shipping operator Subject to specific reporting requirements set in the EU legal acts and international agreements, the operator may be a shipping company, a ship master or the representative of the shipping company/ship master SSN SafeSeaNet SSS Short Sea Shipping VTMIS Vessel Traffic and Monitoring Information System WCO World Customs Organisation

1.Introduction: Political and legal context Maritime transport operators face a wide range of reporting obligations every time a ship calls a port. Since the adoption of the Reporting Formalities Directive (RFD) in 2010 within the context of the European maritime transport space without barriers, some of this reporting is channelled via National Single Windows. The purpose of the RFD was to harmonise and simplify the administrative procedures for shipping operators, thus improving the efficiency and competitiveness of intra-EU maritime transport. The National Single Windows should give shipping operators the benefit of simplified reporting, more efficient clearance and thereby shorter release times for faster turnaround in ports. An evaluation of the RFD performed as part of the fitness check of the EU maritime transport policy in 2016-2017, found that these objectives have not been reached, although they remain highly relevant. Ultimately, the current RFD has been found ineffective: it does not provide the tools, incentives or requirements to achieve EU-wide harmonisation of reporting. The voluntary nature of the measures has also proven insufficient. Further, the provisions of the RFD are too vague to be supportive of improvements, as it does not have mechanisms for updating the framework to address these shortcomings in either delegated or implementing procedures. The problem analysis has been confirmed in consultations with the shipping industry and Member States. This impact assessment therefore assesses several options for improving the situation and for creating a more effective and efficient reporting environment to facilitate maritime transport and trade. 1.1.Background: the Reporting Formalities Directive The RFD was intended as a tool to establish a simplified reporting environment for ships by asking Member States to provide a single reporting entry point for a number of reporting formalities for ships. The RFD did not introduce any new reporting obligations for shipping but aimed at reducing administrative burden deriving from EU legal acts or from international legislation: ·by simplifying and rationalising information requirements set in different legal acts;

·by replacing paper submissions with harmonised digital submissions; and ·by harmonising reporting on national level and establishing a single entry point for multiple formalities, the National Single Windows. The RFD is not concerned with the processing or content of the reported data; only with streamlined reporting procedures and formats for the data requested from ships by the underlying legal acts. The data sets under the RFD scope are defined by the basic acts referred to in the RFD annex. The National Single Windows could be organised in different ways: e.g. centrally in the Member State or in a distributed system of National Single Window entry points. The National Single Windows channel the data submitted by the data providers (shipping operators) to the back-end data recipients (connected authorities and systems requiring these formalities). The National Single Windows thus perform two bundles of functionality: a) data collection from data providers, i.e. the functionality associated with receiving and validating the reported data set and sending back responses (reporting gateway); and b) data distribution to the authorities, i.e. the functionality associated with rearranging the information into specific data sets, sending them to the relevant authorities, and taking care of any related message exchanges. The RFD states that the same information (static data or data already reported and unchanged) should have to be reported by the shipping operator only once. The RFD also calls for coordinated and harmonised reporting at EU-level. The deadline for Member States to apply the new reporting regime was 1 June 2015. Among the main achievements of the RFD are the largely completed digitalisation of reporting and the connection of a number of data recipient authorities to the National Single Windows, creating a shared national entry point for certain ship reporting. However, the current RFD does not provide any binding specifications for the interfaces, data formats or reporting procedures for the National Single Windows. The consequence is that each Member State has developed a unique technical interface for reporting. There is no harmonised front-end (reporting interface/entry point) towards the shipping operators. In addition, much reporting is still requested via other channels. This is further discussed in the Problem description below. More information about the current ship reporting environment is found in Annex 5. 1.2.Legal context Maritime transport is subject to complex administrative procedures even if vessels sail only between EU ports (intra-EU maritime transport) and the cargo consists only of goods in free circulation ("Union goods"). These procedures involve a wide set of international and EU legislation on transport safety and security, environment protection, customs, veterinary and plant-protection, and national and local formalities for vessels arriving in or departing from ports. The RFD complements other EU legislation by providing a tool for streamlined reporting from shipping operators to data recipients (authorities). The directive covers a set of 14 digitalised reporting formalities resulting from international agreements and EU legal acts on vessel traffic and monitoring information and on transport of dangerous goods, on registration of persons sailing on board passenger ships, on the Schengen Border Code, on management of waste and cargo residues, on ship and port security, and on the Union Customs Code. The RFD also builds on the international level legislation and notably the International Maritime Organisation (IMO) framework for international ship reporting formalities. The IMO FAL Convention sets out some internationally agreed reporting formalities for ships. The RFD provides the European framework for electronic reporting according to these standards. The IMO however does not establish standards for all ship reporting formalities, nor does the international framework provide any guidance for simplified, digital reporting procedures and interfaces. 1.3.Policy context The RFD is part of the EU maritime transport policy, contributing to the overall Commission transport policy goal of completing the internal market for transport by removing remaining bottlenecks, barriers and administrative burden. It supports the Commission priorities of a deeper and fairer internal market and the digital single market and indirectly contributes to the priority of jobs, growth and investments. The objectives of the European maritime transport space without barrier, of harmonising and simplifying administrative procedures remain highly relevant for EU policy. This was confirmed by the European Council in its Valletta declaration on the EU's maritime policy and its conclusions on 8 June 2017 on the priorities for the EU's maritime transport policy until 2020, both underlining the need to reduce administrative burden for maritime transport by ensuring simplified and digitalised reporting procedures for ships and inviting the Commission to introduce measures for EU-level harmonisation of the reporting environment. The Council repeated this request again in its conclusions on digitalisation of transport on 8 December, 2017. The industry and maritime transport stakeholders also support the need to reduce the administrative burden through harmonisation. In a joint statement on 1 March 2017, ten EU industry associations called for a "a true European single window environment for maritime carriers that fully ensures the ‘reporting once’ principle and which shares all necessary cargo and conveyance data between governments and all relevant authorities". More recent statements e.g. by the European Community Shipowners’ Association have echoed this same position. A submission to the REFIT platform was done by Finland, as a survey amongst Finnish public administration, business and stakeholders identified the RFD as an example of EU legislation raising particular concerns.The proposal for a revised legal framework for reporting formalities is part of the Commission’s third mobility package, together with, among others, a proposal for a regulation on electronic freight transport information. These two initiatives share the same main objective, which is to facilitate the communication of regulatory information to authorities in electronic format, but differ in various respects. Such differences and similarities are further outlined below. The information concerned by the two initiatives has its source in different international, EU and Member States legal acts. These legal acts do not overlap between the two initiatives and the information sets are different. For example, the information required for fulfilling maritime reporting formalities includes cargo description, alongside a wide range of other information elements on the ship, its crew and passengers. The information requirements under the scope of the initiative on electronic freight transport information, while also containing elements of cargo description, are focused primarily on the transport operation itself – on the identity of the consignor, carrier and consignee, places of pick-up and delivery, route and several others. However, the two initiatives will ensure the interoperability of the electronic data concerned, concretely, by prescribing the same data model and syntax for the common data elements. Geographically, the scope of the electronic transport document initiative begins where the maritime reporting environment initiative ends. The initiative on electronic freight transport information concerns the transport of goods within the EU once these have been cleared for entry in the Union, following the process of maritime and customs reporting formalities. The proposal on freight transport information will allow the use of electronic documentation not just at the point of entry and exit of the EU – where it is already mandatory – but also in the following (or preceding, in case of export) phase of inland transport. Together, they will ensure appropriate coverage of information, for the entire travelling span of whatever the freight concerned. In terms of technical solutions envisaged, the two initiatives require however a different approach. This is because in the case of reporting formalities in ports, information must be submitted at a specific point in time to a pre-defined set of authorities; in the other case (electronic freight transport documents), information only needs to be available in case it is required for inspection. The two initiatives are therefore complementary and mutually reinforcing. The proposal for a revised legal framework for reporting formalities follows on the Fitness check of the Maritime Transport Policy initiated in 2016 under the Commission REFIT programme, which found the RFD framework inefficient and ineffective. The new proposal will be aligned with and supportive of the implementation of the Union Customs Code and its connected customs IT systems. More details on connected policy areas is found in Annex 7

1.4.Economic and trade context Maritime transport is a backbone of trade and communications within and beyond the single market. Almost one third of all intra-EU and three quarters of the internationally traded goods (in tonnes) are seaborne. In terms of value, about half of EU international trade in goods is transported by sea. The number of port calls by passenger or freight vessels in main EU-28 ports in 2016 was estimated at almost 2.1 million. Each year, around 400 million passengers embark and disembark at EU ports. Sea transport turnover was EUR 106 billion in total for EU28 in 2014. There are around 11 000 maritime transport enterprises in the EU28 and around 178 000 people directly employed in the maritime transport sector, with another 1.5 million jobs in EU ports, indirectly linked to the sea-borne trade and transport. Furthermore, the smooth functioning of port calls is one link in a longer transport chain. Ports are not the final destination of goods. The efficiency of the ship port calls, as affected e.g. by the efficiency of the reporting environment, will impact on the entire logistics chain and the hinterland transports of goods and passengers to and from the ports, notably by rail, road, inland waterways or pipelines. More details on the economic context can be found in Annex 8. 2.Problem definition 2.1.What is the problem? This initiative addresses the problem of the current inefficient port call reporting environment for maritime transport operators (legal reporting requirements for when a ship is to arrive in or depart from a port – a port call). Vessels in international traffic (generally larger vessels, shipping around 63% of all transported goods and 6% of the passengers going into or out of EU ports) are subject to both customs and maritime transport formalities. They need to submit a series of declarations and notifications at different points in time, starting with the Entry Summary Declaration (ENS) with cargo-related information, normally submitted even before departure from the third country port. Approaching the port call, they must also submit information and data relating to border controls, environmental controls, safety/security and traffic management. Some of these data elements are requested following legal requirements in EU or international law, other reporting is requested based on national legislation. Via the port reporting the ships may also arrange various port services such as pilotage and logistics for goods management (reporting not based on legislative requirements). Vessels in intra-EU traffic ship around 25% of all goods and 33% of the passengers to or from EU ports. They too may have to complete customs formalities: if they have left EU territorial waters (twelve nautical miles from the coast), if they carry non-EU goods or if they sail under a non-EU flag. They must also complete most of the maritime transport reporting formalities required for the international traffic vessels as described above, with possible exemptions from e.g. border controls within the Schengen zone. For vessels in national traffic (shipping 9% of the transported goods and 57% of all passengers to or from EU ports) there are normally less customs formalities applying, unless the vessel meets one of the criteria mentioned above (non-EU flag, departing from EU territorial waters or carrying non-EU goods). The border control reporting normally does not apply. Other maritime transport reporting formalities and port service information submissions must usually be completed. Some of the underlying legal acts to the RFD also have exemptions for vessels depending on their size, e.g. the Vessel Traffic Monitoring and Information System which does not apply to ships of less than 300 gross tonnage. There are also exemptions and simplifications for some vessels in regular services calling exclusively in intra-EU and/or national ports (e.g. ferries, cargo or cruise ships operating on a fixed route). The current RFD makes it mandatory for Member States to request the maritime reporting based on certain EU and international legislation via the National Single Windows. The national reporting requirements may also be channelled via the National Single Window while the large majority of customs formalities are done via separate IT systems. Some shipping companies prefer to do their port call reporting via automated machine-to-machine reporting if available in the port they call. This is especially common among the large shipping operators. Other shipping companies prefer reporting via graphic user interfaces and uploading information using spreadsheet files, if available in the port they call. Many companies also use ship agents to deal with the reporting formalities and/or cargo agents to deal with the customs formalities. The use of ship and/or cargo agents is often needed because of the diverging reporting systems in each Member State and in some cases in each port. The current legislative framework was evaluated in 2017. The evaluation concluded that the RFD is inadequately effective and efficient, in spite of the objectives remaining highly relevant and valid. The evaluation concluded that there is potential for further simplification and burden reduction in this area. This is also the strong messages repeatedly sent by stakeholders, calling for measures to urgently address the situation. The main barrier emphasised by the shipping operators and stressed in the evaluation, is the lack of harmonisation of the maritime National Single Windows and the overall lack of EU-level harmonisation of all reporting required by a carrier calling a port. Today, each National Single Window looks different. Data formats are different, reporting procedures are different and the scope of reporting through each National Single Window differs. Some Member States accept machine-to-machine reporting, others provide graphic user interface and accepts uploading of spreadsheets (or receives spreadsheets per e-mail). Some Member States allow reporting via port community systems into the National Single Windows or have delegated National Single Window functions to each port (decentralised system). The shipping operators thus have to adjust their reporting and their IT software and data sets for each Member State – or even for every individual port they call. The non-harmonised reporting environment makes reporting a very burdensome and time-consuming task for shipping operators. Indeed, the current legal act provides no guidance or binding specifications to guarantee the development of common data models, front-end interface or reporting procedures for shipping operators. The consequence is an unnecessary high administrative burden on shipping operators. The majority of the shipping companies replying to the open public consultation on the evaluation considered that administrative burden was reduced either not at all (61% of all shipping companies and ship-owners’ associations) or only to a limited extent by the adoption of the RFD. According to more than half of all responding shipping operators, the burden has in fact increased rather than decreased, as an effect of the old reporting requests via separate entry points often remaining in place in parallel to the new National Single Windows.

For the national authorities and port operators, this is not a major problem. From the view of an individual port, the information exchange with ships is normally perceived as smoothly functioning. From the side of shipping companies and maritime transport operators however, as they call to different ports, the multitude of different and sometimes duplicating/overlapping reporting requests becomes a burden. This is the message repeatedly sent from shipping companies and their EU-level associations. Every year, more than 2 million port calls are made in the EU. For these port calls, the maritime transport operators are obliged to submit a large set of information. The evaluation found that on average, the time spent on reporting for one single port call ranges between one and three hours. This translates into around 4.6 million staff hours spent on reporting per year for all EU port calls. The large majority (90%) of all stakeholders consulted for the evaluation and the impact assessment consider that this time spent on reporting could be substantially further reduced by harmonisation and simplification of the reporting environment. As a consequence of the unnecessary administrative burden facing the shipping operators, maritime transport is less competitive than other transport modes. Moreover, the attractiveness of the profession is reduced and has been reported as an important cause for employee dissatisfaction in the sector. The lack of harmonisation of maritime transport reporting creates an obstacle to an efficient and optimised movement of ships and cargo and thereby hampers the smooth functioning of the internal market. In the wider perspective, this mismatch of administrative proceedings and their low efficiency affects the whole EU logistic chain, beyond maritime transport (multimodal transport links; rail, road and inland waterway), since the overly burdensome administration of reporting results in less efficient logistic planning and increased lag time in ports. The issue is of relevance primarily for the maritime Member States and their authorities linked to the maritime National Single Windows; for the maritime transport operators; and for all stakeholders involved in and around port operations and port management. The problems impact in first hand on the maritime transport sector and the shipping operators. See also detailed table in Annex 6. 2.2.What are the problem drivers? The evaluation identified the following drivers: P1. Diverse ship reporting formats, interfaces and procedures used throughout the EU The RFD did not introduce binding technical specifications for electronic interfaces, but left the implementation of the National Single Windows to Member States. According to the Directive, the Commission should develop mechanisms for the harmonisation and coordination of reporting formalities within the Union, together with the Member States. This was done: an expert group on maritime administrative simplification and electronic information services (the eMS group) developed some definitions, business rules and guidelines and a standard data set in 2015. The European Maritime Safety Agency (EMSA) also developed a prototype of a National Single Window and the results are transparently shared and made available, including user manuals and templates. These guidelines and support activities have however not proved very effective. They are not binding, nor very detailed; the guidelines have not hindered fragmented implementation of different National Single Window set-ups at Member State level. Furthermore, the RFD has no mechanisms to continuously develop and improve provisions for harmonisation and no tools for update of the legal framework in step with technical or political developments (e.g. a governance system, delegated/implementing acts). The absence of binding common standards has led to the introduction of reporting interfaces which are technically different for practically each port call. Data sets and reporting formats differ, sometimes even within a Member State. Data models and interfaces are not aligned even between Member States who participated in coordination projects such as AnNa. The European shipping industry association ECSA concludes on the reporting formats encountered by their members: “These are not only complex and repetitive, but even worse, they are completely unharmonised throughout the EU”. The non-harmonisation is especially burdensome for vessels calling into several EU ports (as compared to vessels in national traffic or going in liner traffic between the same two ports – although those vessels are also affected by inefficiencies and duplication of reporting beyond the non-harmonisation issue). The non-harmonisation is in particular an issue for vessels in tramp/non-fixed routes traffic, calling always into different ports. Tramp traffic vessels make up around 60% of all port calls, with around 40% of all port calls being by vessels in liner traffic. Furthermore, there are many different channels or interfaces with which the maritime operators need to adapt their systems in order to provide all information required for a port call. For one port call, they might have to send data through National Single Windows in XML, through a port community system in EDIFACT and use a third format or data model for national customs system. This creates an expensive technical environment to maintain. This is not a matter of harmonisation of data formats; with the introduction of the new Union Customs Code legislative package, customs reporting formalities have already undergone a process of harmonisation at EU level. However, since the harmonised customs formalities are requested in a separate reporting channel from the maritime reporting formalities, shipping operators state that the total time spent on reporting for them is affected negatively (see further information below in chapter on impacts of options). The existence of several additional reporting entry points in parallel to the National Single Window limits the actual harmonisation of reporting. It reduces the added value of the National Single Window for the industry, who is faced with multiple reporting channels simultaneously. The situation of non-harmonisation is highly unlikely to be solved only by full implementation of the current Directive. The RFD lacks the instruments for achieving harmonisation: crucially, it lacks the possibility of adopting binding specifications. When asked in the consultations, no single Member State replied that they intend to change current systems towards harmonisation on the basis of the voluntary guidelines. In such context, full compliance of Member States with the requirements of the existing Directive might consolidate a situation of nationally harmonised but EU differentiated reporting systems, which might render even more difficult a further evolution towards a single EU approach, as demanded by the industry. P2. Diverse ship reporting requirements throughout the EU Currently, the RFD reporting rules only concern some of the formalities envisaged by EU legislation and international maritime agreements. National requirements are only reported via the National Single Window on voluntary basis while some EU formalities, e.g. related to customs aspects, are only partially included. Currently, some 230 data elements fall under the 14 formalities for mandatory RFD reporting (RFD Annex 1, part A: EU legislation and B: international obligations). This includes the core maritime transport reporting elements for e.g. safety, security, traffic management, border controls and waste control (environmental objectives), as well as the seven standardised IMO forms relating to e.g. dangerous goods, crew and passenger lists and the general and cargo declarations. The data reported via the National Single Windows thus serve several purposes and covers a broad spectrum of policy areas. However, in addition to these EU and international reporting obligations, ships are obliged to send many additional information elements when calling a port. A large part of the reporting burden comes from the non-harmonised national reporting requirements that are not mandatorily channelled via the National Single Windows. These requirements also differ from Member State to Member State. A Member State sub-group, together with the Commission services, is currently mapping the additional data elements derived from national legislation (RFD Annex 1, part C), estimated to make up at least 200 additional data elements. Moreover, maritime operators must provide transport-related information required for statistical purposes. In addition, data related to the ships’ cargo are required, primarily by customs authorities but also by maritime transport authorities. This data has recently been mapped by the so called eManifest pilot project. The project has identified a cargo data set of another 150 data elements possibly required for the fulfilment of customs formalities related to the arrival/departure of a ship from/to an EU port. The list of customs formalities/functionalities requiring this information includes: Entry Summary Declaration, Arrival Notification, Presentation Notification, Declaration for Temporary Storage, Customs Goods Manifest, Electronic Transport Document for simplified transit, Re-Export Notification, Export Summary Declaration, and Exit Notification for Export. These customs formalities are currently not channelled via the National Single Windows but mainly through customs IT systems (national or upcoming EU-level systems). Customs authorities are currently establishing a harmonised data set under the implementation of the Union Customs Code and an EU-level single access point (the ICS2 shared trader interface for the Entry Summary Declaration) is being developed. All data elements listed above have already been mapped out by the Commission in cooperation with EMSA and Member States in a single data set, providing an overview of all data that may be requested from ships in EU port under the current RFD scope and beyond.

Finally, another aspect which presents a smaller problem: today, paper copies of a set of at least 100 ship certificates such as Certificate of Registry and Certificate of Class are kept on-board ships to provide proof that the vessels are compliant with various regulations and conventions. The management and keeping of paper certificates is often seen as an administrative burden and an area where digitalisation could bring further benefits. Paper certificates are also exposed to forgery and fraud which could be avoided with digitalisation, provided that relevant cyber-security measures are introduced. Bringing in a more comprehensive data set into the coordinated and harmonised reporting environment would require changes to the RFD. The current legal framework does not have the update mechanisms to allow a broadening of the data set. More detailed information on the data elements within and beyond the current scope of RFD can be found in Annex 5. P3. Unclear legal framework for sharing and using reporting information Today, data flows are suboptimal and duplicate reporting takes place because of lack of data sharing between authorities. The data provider – e.g. the carrier or the agent appointed as their representative for these purposes – today submits through the National Single Windows a set of data including both static and dynamic data. The static data can be broken down into two subcategories: permanent static and temporarily static data elements. Information which does not commonly change (identification and particulars such as tonnage) is considered permanent static. The information which does not usually change between the departure and arrival ports, such as crew and passenger lists, or hazardous cargo information, is considered temporarily static information. The dynamic information, such as waste on board, cargo or estimated arrival time, is the one that changes regularly. There are two main aspects of reporting the same data only once. First, there is the issue of the same data often being requested several times within the same port call. Respondents in the consultations (in particular shipping companies and ship agents) stressed that multiple reporting is a fact. In some ports (28% of respondents even claim: in most ports), maritime operators are required to report the same information (static and dynamic) separately to different authorities when calling a port. Sometimes the reason is vertical silos: the authorities act independently without coordination. Sometimes there is a horizontal issue where central authorities fail to share data with local ones. This means that many Member States and ports still have an inefficient data sharing environment where reported data is not sufficiently channelled to all relevant data recipients. Reporting only once within the same port supports efficiency of reporting but also to some extent contributes to burden reduction for the shipping operator by minimising duplication of work, as described in the Commission Study on eGovernment and the Reduction of Administrative Burden by EY and DTI from 2014. The reporting-only-once was an objective mentioned already in the current RFD but not achieved; the poor implementation of the current provisions is at least partly a result of unclear Directive provisions providing insufficient instructions. The second aspect is the “reporting only once” enabling the re-use of static data from one port call to another (also not sufficiently addressed in the current RFD). This is not taking place at all today, except in a few pilot project cases of exchange services between ports with connected systems. These pilot projects show that the re-use of unchanged data would in principle be possible, assuming that data protection and data quality rules are respected throughout the data exchange chain. Lack of re-use of data between ports is a missed opportunity for simplified reporting for shipping operators (e.g. enabling pre-filled forms or transforming the departure form from one port into the arrival form for next port). This especially makes some difference for smaller shipping operators reporting manually (via graphic user interface) where any duplication in reporting obligations means some time lost. It also increases the complexity of port calls for ships with small crews. In the consultations, 81% of all respondents expect to have some or high benefits from data re-use, with highest focus on the need for data re-use among shipping operators and ship agents. However, the reporting only once between ports is also about missed opportunities for the wider chain of transport logistics. The current lack of data sharing between ports (within and beyond a Member State) means that business potential for more efficient procedures for ports and for authorities is untapped. Access to this information would in many cases be quicker for these stakeholders by way of interconnecting the existing reporting systems rather than only requiring all updates directly from the vessels. It should also be noted that some information reported to the National Single Windows today is already exchanged between the Member States through SafeSeaNet. However, the Member States have reported that they do not use this data for reduction of reporting duplications by ships, in spite of the possibility offered in the RFD. Re-use and efficient sharing of data within the context of the RFD is today hampered primarily by unclear or missing specifications on data definitions and use/re-use. Authorities’ obligation to share data, even for the same port call, is not clearly enough specified. The vague provisions of the RFD have therefore not supported the objective of moving towards the “reporting only once”; this is a clear shortcoming of the current Directive. Furthermore, recipients of cargo or ship information are reluctant to share data since the legal framework – as regards aspects of data control, confidentiality, liability and access rights – is perceived as unclear. The current RFD does not provide sufficient specifications and support on this. For example, concerns regarding the interpretation of the General Data Protection Regulation have been voiced in several of the consultation events, with data recipients uncertain about how to deal with potentially sensitive personal data elements such as passenger lists or crew personal data. Clear rules for accessing data are also missing, according to consulted stakeholders. This has an impact also on the information which is commonly considered as open data, such as departure and arrival times which could be of value for efficiency gains throughout the multimodal transport chain. There is today no uniform application on how this data should be treated. Some Member States make it public but only locally through port information boards, other share it via Internet. The inconsistent approaches reduce the possibility of using this data for multimodal transport management. These issues would not be solved by full implementation of the current Directive; the RFD does not provide sufficiently clear provisions to achieve these objectives on its own and in its current form. P4. Inadequate implementation of current legislation The unspecific definitions and provisions of the Directive have in turn also hampered implementation and enforcement of the directive. The slow implementation of the RFD is not the core problem for shipping operators (and full implementation would not solve problem drivers 1-3, as described above), although it does contribute to the complexity of the reporting environment. It is telling that operational National Single Windows are still under implementation in eight of the 23 maritime Member States. In addition, even where there are National Single Windows implemented, there are not always national procedures, national technical standards, or an actual single entry point for reporting. A likely reason for the diverse interpretations of the current RFD is that the provisions are extremely vague, giving very little guidance or direction to Member States, who could reasonably claim they are not in principle failing their obligations. Ultimately, Member States have not had sufficiently hard incentives to establish their national single windows in a harmonised way. Considering that technical assistance and voluntary guidelines have been offered but not widely applied, lack of resources, know-how or time are not assessed to have been the main barriers to implementation. It seems rather to be the absence of binding specifications and clear instructions causing the uncertainties. Furthermore, the provisions have been too vague to support the Commission in pursuing infringements or other follow-up procedures. The effect of the slow and uneven implementation of the RFD was to create additional differences between the reporting environments from one Member State to the next, aggravating the core problems as described above under drivers 1-3.

2.3.How will the problem evolve? The RFD does not provide binding technical specifications for harmonised reporting interfaces or to include new or missing EU or national reporting obligations. The current situation with diversity of reporting procedures, formats and interfaces is unlikely to change in the future without EU level interventions. The existing structures for exchange of best practices between the Member States have not so far been effective for delivering harmonised implementation of the National Single Windows. Guidelines have been developed in close cooperation with Member States and technical assistance for implementation has been offered via EMSA. Quantitative estimates of the impact of these initiatives, in particular the uptake effect of the EMSA prototype, are not available but the Member States indicated in the consultations that no further changes to current systems are planned as a result of these activities. For the shipping operators, the administrative burden linked to lack of harmonised single entry point(s) and lack of harmonisation of data requirements will therefore remain high: in total 50 million staff hours are estimated to be spent on reporting during the baseline period (EU28). In addition, new challenges and issues will emerge, risking render the current legal framework out of date. More information on how the situation is likely to evolve until 2030 can be found in section 5.1. 3.Why should the EU act? 3.1.Legal basis Article 100 (2) of the Treaty stipulates that "The European Parliament and the Council, acting in accordance with the ordinary legislative procedure, may lay down appropriate provisions for sea and air transport." 3.2.Subsidiarity: Necessity of EU action The legitimate rights of Member States to manage and develop their port reporting systems must not unduly restrict the proper functioning of the internal transport market. Maritime transport is to a large extent a single market concern; only 9% of the seaborne trade in the EU is national, compared to 25% and 66% for respectively intra-EU trade and extra-EU trade. Moreover, the ports are not the final destination of the goods and via the hinterland connections a large part of the goods going through ports either comes from or continues to another Member State. It is therefore in the interest of the Union to ensure the smooth functioning of ship port calls, for the sake of the wider internal transport market and for the considerable economic investments and cross-border business interests linked to the sector. The problems addressed by this initiative – inefficient reporting environment for shipping operators in connection to a port call, resulting in cumbersome administration for transport operators – are unlikely to be solved sufficiently by Member States in the framework of their national constitutional systems (necessity test) as the maritime transport is a highly international sector. Policies developed and implemented on a national or sub-national level are unlikely to produce solutions harmonised at the EU level (compare with successfully harmonised customs formalities thanks to Union Customs Code EU-level legislative package) and cannot efficiently address the cross-border information exchanges. Fragmented national legislation and transport systems, often incompatible with each other, lead to a sub-optimal situation as far as the Internal Market in maritime transport is concerned. The inadequacy of voluntary harmonisation measures has also been clearly shown in the past. The existing non-binding guidelines and the regular interaction between Member States have not improved the situation and have not resulted in less fragmentation. Stakeholders widely agree with this assessment, as expressed in the consultations where a majority of respondents (74%) in the open public consultation stated that these issues should be addressed on the EU level (87% of the shipping companies and ship masters; 69% of responding Member States). 82.5% of the respondents believed that the actions should be mandatory (97% of shipping companies and shipmasters; 67% of Member States). Most respondents believed that only soft measures will have low effectiveness, and hence bring very limited benefits. It could in principle also be considered to act on the matter primarily on the international level and via the IMO. However, the IMO only works by voluntary implementation and non-detailed specifications and has no mechanism for enforcement. While the IMO does address some of the ship reporting aspects such as the reporting formalities specified under the FAL Convention, the IMO does not address other of the policy areas covered by EU law. Action only at international level will not bring added value for EU maritime transport operators with regard to the reporting environment. On the contrary, it is usually the EU that pushes the development of the IMO framework by being a forerunner in adopting more effective, efficient and harmonised rules; going further than the lowest common denominator agreements in the international forum. The harmonised reporting environment was not achieved by voluntary action at EU-level and it is highly unlikely that better results could be achieved by similar non-binding action via the international organisations. 3.3.Subsidiarity: Added value of EU action The proposed action can be better achieved at Union level than at national level as substantial results can only be achieved by a coherent framework addressing pan-European needs. The development and implementation of common standards and facilities need to be coordinated and aligned along with the other relevant EU and international initiatives and technological developments as well as socioeconomic developments. This work would normally primarily be done in the context of the underlying legal acts and the resulting data requirement agreements subsequently taken up in the RFD framework for the coordination of reporting. Such a framework permitting and ensuring the required connections and complementarity with the various existing reporting systems as well as development towards common data definitions can only be created at EU level. No international body provides an alternative forum for creating the coordination mechanism for the comprehensive body of ship reporting requirements under international, EU and national legislation. The European Union is in a privileged position to offer leverage and propagate best practices and common standards for harmonisation, to promote cross-border cooperation, and to facilitate the establishment of a wide market for digitalised transport services. The competition between ports is strong and the port community often protective of its independence and individual competitive advantages. Only by acting at the EU level can the level playing field and the European Maritime Transport Space without Barriers be ensured. As is shown in the analysis of impacts below, action at EU level to achieve full harmonisation could result in an administrative burden reduction of 50-75% of the staff hours currently lost on overly cumbersome reporting procedures, with additional indirect benefits in terms of possible faster turn-around time in ports, better logistics chain predictability, higher job satisfaction among staff and gains in terms of more staff hours released for e.g. safety and business related processes on-board. In addition, the initiative offers potential for further contributing to the efficiency of the entire Single Market multimodal transport chain by enhancing information flows and reducing potential bottle-necks in connection to port calls. There are, in particular, opportunities for added value in exploiting the data sharing aspects of the proposal to enable future cross-modal information exchanges and by ensuring that the harmonised data formats support interoperability across the transport modes.

4.Objectives: What is to be achieved? 4.1.General objectives The general objective of the initiative is to contribute to the smooth functioning of the single market and facilitate trade and transport by addressing the currently cumbersome and diverse reporting procedures for ships calling EU ports. This means a well-functioning, harmonised and future-proof digital reporting environment enabling interconnectivity and coordination of transport and customs related reporting, to improve the efficiency, attractiveness and environmental sustainability of maritime transport while contributing also to the integration of the sector to the digital multimodal logistics chain. 4.2.Specific objectives The initiative will contribute to the general objective by pursuing the following specific objectives: ·To harmonise reporting procedures, interfaces and data formats in order to support the European Maritime Transport Space without Barriers. This objective addresses the problem driver of diverse ship reporting procedures, interfaces and formats. ·To reduce administrative burden in ship reporting by providing a single entry point, thereby boosting efficiency, competitiveness, jobs and growth in maritime transport, ports and in connected sectors along the entire logistics chain. This objective addresses the problem driver of diverse ship reporting. ·To contribute to increased efficiency of digital reporting for maritime operators by facilitating data sharing/reuse for the application of the “reporting only once” principle. This will in turn contribute to the establishment of the Digital Single Market by removing legal uncertainties in the digital maritime transport environment, such as access to and transfer of open data, data liability, interoperability and standards, while taking in account relevant legal frameworks such as the General Data Protection Regulation (GDPR) and the Regulation on electronic identification and trust services (eIDAS). This objective addresses the problem driver of unclear legal framework for data sharing. ·By adopting a clearer legal framework in line with the objectives above, with detailed provisions and binding technical specifications, the main barriers to implementation of the current RFD will be removed and the success rate of the new proposal is expected to be substantially higher than for the RFD. 5.What are the available policy options? 5.1.What is the baseline from which options are assessed (Option 0)? Under this option the Commission would continue to rely on the existing framework, without undertaking further action to address the weaknesses identified. Without EU level harmonisation, the reporting burden from a non-harmonised reporting environment is expected to remain unchanged. The baseline period has been set to 2020-2030, in line with that of other initiatives of the 3rd Mobility Package. There is no possibility of implementation earlier than 2020; beyond 2030 technical developments are expected to substantially change the overall reporting environment in unforeseeable ways. The soft measures assumed to be continued in the baseline scenario (e.g. technical assistance, voluntary guidelines) would not be effective on their own, as already proven by past experience. In the consultations, Member States were asked whether they plan to develop their existing systems towards a more harmonised format on the basis of the existing support mechanisms from the EU. In this respect, it is noteworthy that no single Member State replied that they planned any such changes. Harmonisation is therefore not expected to take place in the baseline period without additional EU action and the current problem are therefore unlikely to be solved in this scenario. This includes exchanging and using data and information for reduction of administrative burden and improving efficiency. Data re-use is expected to remain low due to the continued legal uncertainties on rights to use and share the information and the lack of clear mandatory obligation on Member States to enable such data re-use. In the baseline scenario, the significant growth of the overall activity of the transport sector including shipping is projected to continue, driven by global economic and trade growth. These developments concern both passenger and freight transport with maritime freight transport projected to grow at higher rates than passenger transport, following more closely the GDP developments and the increasing demand for traded goods. International maritime activity (including both intra-EU and extra-EU) would grow by more than 70% between 2010 and 2050 (1.4% per year). For the cruise sector, a steady growth has been reported during the last decade and is expected to continue based on data from CLIA. In addition, a 50% growth of cargo handled in EU ports is projected by 2030 according to a study of the European Parliament. The modal share of maritime transport has remained fairly steady over time and is not projected to change significantly by 2050. The expected growth of trade and, subsequently, in volumes, is however not expected to increase the number of port calls. The trend towards growing average ship size is likely to continue, with large-capacity and large-scale ships being increasingly in demand, notably for sake of economics of scale. This development will affect the total number of future port calls: larger ships will be able to carry the increased volume of cargo; therefore, the number of port calls will slightly decrease over time: by about 2% from 2020 to 2025 and by 1.3% from 2025 to the projected 2.02 million port calls in 2030. Growth of ship size is most visible in the container segment, with an average ship size increase of about 5%, and in the cruise segment, with an annual increase of about 4%. For other ship types, the size is projected to remain relatively stable over time, in line with the historical developments. For authorities, continued digitalisation of government services and systems, as monitored via the EU Digital Economy and Society Index, is expected to continue, generating some benefits in terms of efficiency and simplification for ship reporting. The adoption rate however commonly varies with some Member States significantly more prone to quickly apply digital frameworks and others lagging behind. EU level digitalisation initiatives such as on eDelivery for secure and reliable exchange of data and documents as well as Horizon 2020 Information and Communication Technologies, may help push a more even implementation rate. The average time estimated by shipping stakeholders in the current system is 1-3 hours per port call. The wide range is explained by the very different reporting burden notably for vessels in tramp traffic (60% of all port calls; mainly general cargo and bulk vessels of less than 10 000GT) compared to fixed route traffic (40% of all port calls; mainly other types of vessels and larger bulk vessels). These tramp /non-fixed route operators typically make port calls in multiple ports and multiple Member States, facing a higher burden of non-harmonised reporting (estimated average 3 hours per port call). Fixed route transport (e.g. ferries) and large liner vessels typically call in same and few ports and have lower average reporting times (estimated average 1 hour per port call). The non-fixed route operators typically run smaller vessels but make up 60% of all the port calls and a very high share of the total time spent on reporting in the EU.

When applying the more specific reporting time estimates for these different vessel and traffic types, the resulting estimate is a total of 4.6 million hours spent currently on reporting per year for all EU port calls. Despite the slight reduction in the total number of port calls over time (see section 2.4), the number of hours spent for reporting is projected to remain high, at 4.4 million hours by 2030. For the entire baseline period 2020-2030 and for EU28, 50 million hours are estimated to be spent on reporting, equivalent to around EUR 1.5 billion expressed as present value in 2020. The current National Single Windows cost on average 265 000 per Member State and year in operational and maintenance costs. Taking into account the above presentation of projected problem evolution, development of number of port calls and the time spent on reporting in each port call, the baseline cost for the National Single Windows for EU28 over the entire baseline period is estimated at EUR 108 million (for the detailed cost calculations, see Annex 4). The option of remaining at status quo also received very low support (7%) by all respondents in the consultations. 5.2.Design of policy options A number of decisions were made as point of departure for identifying viable policy options. These choices have been made as a result of the consultations and following discussions with Commission and external experts. The purpose was to define at an early stage what solutions would solve the problems identified, be realistic and sufficiently acceptable to the main stakeholders. 1.In order to address the problem of inefficient reporting environment for ships, the main options considered here are building on the already existing framework (National Single Windows structure). This was a demand from Member States in the consultation event in October 2017. Options that would require an entirely different set-up have therefore been discarded from consideration as it would be inefficient – and unacceptable to a main stakeholder group – not to make use of the investments and efforts already made. As mentioned in chapter 1, the National Single Windows perform two bundles of functionality: data collection from the front-end users (shipping operators) and data distribution to the back-end authorities (data recipients). The present initiative is concerned with the harmonisation of the reporting gateways, but does not change the connections to the back-end authorities beyond enabling more efficient data distribution and data sharing. 2.The new and harmonised reporting gateway should be offered as a reporting path always available for shipping operators and accepted by authorities, in line with the strong request from the shipping industry and as a trade facilitation measure. This does not mean that other reporting entry points must be banned, but only that if data providers choose to use the EU-level harmonised maritime transport gateway to submit their reporting formalities, data recipients must accept those submitted reports and refrain from requesting additional and separate reporting. There are two main reasons for not forcing the closure of all other reporting entry points beyond the digital harmonised maritime reporting gateway. First, it would be highly difficult to determine e.g. who should be included in the scope for reporting via this harmonised reporting gateway for maritime transport and who may use e.g. the customs IT systems directly. The maritime transport sector is highly heterogeneous and reporting requirements differ: some report all of the data elements, some (e.g. small vessels or operators on regular lines) have exemptions. Some split their data sets by having the cargo data reported via cargo agents, other report everything together. There is no sharp line between economic operators primarily affected by the maritime transport reporting, those primarily managing the customs formalities, and those concerned with both. For those actors mostly working with the cargo issues, it will be easier to continue reporting straight into the customs IT systems; this possibility must therefore remain for them. Second, Member States may want to offer a national entry point for the vessels only active in national traffic (9% of maritime freight transport). If they find this convenient there is no reason for the Union to forbid such duplication. It may serve a purpose to give SMEs in national traffic a more local reporting path, especially in the case of an EU-level central gateway option. It is assumed that such national alternatives would primarily be interesting in the short-term and as a transition period since, following the consultations, it is clear that the great majority of shipping operators will prefer the offered EU-harmonised option. For the possibility to report directly to the individual back-end authorities and IT systems, this would not entail duplication of systems. A decision to maintain alternative reporting systems in the National Single Windows will rest entirely with the Member States. 3.The National Single Windows should remain a coordination mechanism, serving primarily as a router (with technical converter between data formats where needed) to pass two-way information between the maritime transport operators and the data recipients (e.g. port authorities, customs interfaces and IT systems, border control authorities, the SafeSeaNet, statistics authorities) with the aim to facilitate reporting for the maritime industry. The harmonised reporting gateway will not process data beyond data format translations/transformation, first data quality checking, certain (temporary) data storage for technical purposes or other procedures necessary to smoothly link the data from providers to recipients. All final processing will continue to be done by the specialised systems of the connected data recipients. The reason for this assumption is first, to avoid building new systems on top of the already functioning ones for the sake of costs and proportionality, and second to avoid incoherence and interference with the back-end systems where the data processing normally takes place. The objective of adding the harmonised reporting gateway is not to change the functionalities that National Single Windows and specialised systems already perform satisfactorily, but only to ensure a simplified and harmonised front-end of reporting to reduce shipping operators’ burden. 4.The initiative will not create new reporting requirements but will coordinate the reporting between the data providers in the maritime transport sector and the data recipients as specified in the underlying legal acts referred to in the revised legal act. This may require translation of data formats in order to ensure a harmonised front end reporting (from the maritime transport operators) as well as reporting output at the back-end (to the connected entities and authorities receiving the data). Any reporting requests via the harmonised reporting gateway shall fully respect the applicable technical specifications of the underlying legal acts and IT systems supporting these underlying legal acts (e.g. customs legislation, SafeSeaNet requirements specified in the VTMIS Directive, etc.). This design principle follows on clear demands from both shipping operators and Member States. 5.The new reporting environment must ensure clear and fair division of responsibility and accountability for all connected entities, including guarantee of the National Competent Authorities’ full responsibility and liability for the intermediary services of the National Single Windows vis-à-vis both the data providers and the connected data recipients (e.g. functional and legal responsibility, high availability, ensuring two-way flows of information, etc.). This is a logical point of departure for enabling a comprehensive scope and the well-functioning interconnection of maritime and customs reporting environments. 5.3.Description of policy measures and options Taking into account the principles mentioned above and following the results of the consultations with the relevant stakeholders, a number of possible measures were identified. To address the first and the second driver, several possible mutually exclusive solutions have been identified. In addition, some measures are necessary to ensure a proper and well-functioning framework. These measures are common for all the options (complementary measures). Mutually exclusive measures (alternative) Problem Driver 1: Diverse ship reporting formats, interfaces and procedures used throughout the EU No. Policy measures A-D Alt. A Harmonised reporting gateways as front-end to the National Single Windows (NSWs): based on binding technical specifications Introduce binding harmonised requirements and technical specifications for the front-end reporting gateway in the existing NSWs in the Member States. The specifications would cover e.g. data content, message structure format, exchange protocols, user interface requirements and other rules as necessary for ensuring the necessary information exchanges business rules. They would be set at EU level but responsibility for implementation and operation would be fully on the Member States. The result would be a decentralised system of NSWs with identical reporting gateway functionalities for ship reporting. Alt. B Harmonised reporting gateways as front-end to the National Single Windows (NSWs): based on common IT solution Develop a mandatory common harmonised reporting gateway/ front-end interface component (IT solution) at EU level, for installation in every NSW. Regular updates as required would be supplied via the EU. The operational responsibility would be on Member States but with helpdesk functions for the software installation at EU level. The result would be a decentralised system of identical reporting gateways in every Member State. Alt. C Central European level reporting gateway: introduction of a centralised European Maritime Single Window Introduce a centralised, EU-level reporting gateway / front-end interface (European Maritime Single Window). The centralised reporting gateway would offer one single reporting entry point for all port calls throughout the EU including the necessary two-way information exchanges between the data providers and the back-end connected entities and systems. The NSWs would remain in place as the router between the centralised reporting gateway and the national level data recipients. Member States would be responsible for ensuring connection of their National Single Windows to the centralised gateway. Alt. D Mandatory Port Community Systems (PCS) as basis for harmonised reporting gateways in Member States (technical specifications) Build the EU level harmonisation requirements and binding technical specifications on mandatory PCS reporting gateways in the Member States (all other details same as in alternative A above). Problem Driver 2: Diverse ship reporting information requirements throughout the EU – several parallel reporting entry points No. Policy measure Alt. 1 Comprehensive single entry point solution (introduction of a mandatory comprehensive Maritime Single Window data set) Set a wide scope for the reporting by ships in connection to a port call to be accepted via the harmonised reporting environment: covering the current scope of RFD, the national reporting requirements and channelling of customs formalities for ships into (and return messages from) the customs IT systems at national and EU level. Alt. 2 Separate entry points customs / maritime (introduction of a mandatory limited Maritime Single Window data set) Set a limited scope for the reporting by ships in connection to a port call to be accepted via the harmonised reporting environment: covering the current scope of RFD and the national reporting requirements. Customs formalities to be reported via the parallel and harmonised customs IT systems. Common/complementary set of measures (enabling framework)

Problem Driver 2: Diverse ship reporting information requirements throughout the EU – several parallel reporting entry points No. Policy measure I Introduction of specifications for acceptance of e-certificates Enable development of e-certificates acceptance by initiating processes for specifications and technical solutions (e.g. common registries). Problem Driver 3: Unclear legal framework for sharing and using reporting information – no “reporting only once” No. Policy measure II Establishment of data re-use principles for “reporting only once” A set of clear principles, rules and rights for data sharing and reuse will be developed to ensure correct and smooth data management and “reporting only once” for carriers, as a minimum first step within the same port. Clear definitions for different requirements will be provided. Definitions and specifications concerning the processing and management of personal or commercially sensitive data will be addressed. III Development of common databases to support the system This includes a common exemption database, a common (federated) user database(s) and a common ship repository for improved data flows and data exchanges. Problem Driver 4: Inadequate implementation No. Policy measure IV Introduction of a governance mechanism A governance mechanism will be created to ensure timely and appropriate legal and technical updates. Implementing and/or delegated powers for maintenance of e.g. the technical specifications are proposed. This will be accompanied by the set-up of the required expert groups for coordination and consultation with Member States and with industry stakeholders as needed. V Development of a complaint/feedback mechanism A complaint/feedback mechanism will be offered to maritime transport operators as a tool to alert authorities if the harmonised reporting and the reporting only once principles are not respected or if any technical fault is found in the reporting systems. VI Development of helpdesk function To facilitate implementation, technical support to Member States on the reporting environment specifications and possible IT solution in the form of e.g. helpdesk functions, technical advice or development of application guidelines will be developed. The measures have been packaged in policy options along the two main dimensions: to address the harmonisation requirements (mutually exclusive measures A-D) and to define the scope of what shipping operators can report via the harmonised reporting environment (mutually exclusive measures 1-2). Six measures (I – VI) are common for all policy options. As a result, eight policy options have been considered and six of them have been retained for in-depth analysis, in addition to the baseline (see section 5.1): A: Harmonised NSW gateways: technical specifications B: Harmonised NSW gateways: common IT solution C: Central reporting gateway D: Mandatory PCS (discarded) 1. Comprehensive single entry point solution Option A1: Measures A, 1 and I-VI Option B1: Measures B, 1 and I-VI Option C1: Measures C, 1 and I-VI Option D1: Measures D, 1 and I-VI 2. Separate entry points customs / maritime Option A2: Measures A, 2 and I-VI Option B2: Measures B, 2 and I-VI Option C2: Measures C, 2 and I-VI Option D2: Measures D, 2 and I-VI The main difference between the options is in terms of roles and responsibilities and the division of tasks between Commission and the Member States, as is further described below. 5.3.1.Policy option A1: Harmonised reporting gateways as front-ends to the NSWs: binding technical specifications and requirements (decentralised/distributed) - comprehensive scope Harmonisation Policy option A1 is to introduce binding requirements and technical specifications for harmonising the reporting gateways (front-end interfaces) of existing National Single Windows in the Member States. The specifications would cover data content, message structure format, exchange protocols, user interface requirements and other rules as necessary for ensuring the necessary information exchanges. They would be set at EU level but responsibility for implementation and operation would be fully on the Member States. It would also be the responsibility of Member States to prepare and perform updates, maintenance and support services as required. Coordination and overview of updates for permanent alignment with relevant legal and technical developments should be led by the Commission with support of relevant experts. The technical specifications will be designed with a view to enable full interoperability between the National Single Windows, future-proofing for next phases of more access and exchange of relevant data (see also section on data re-use below). The result would be a decentralised system of very similar (subject to possible nuance interpretations of the specifications at Member State level) National Single Window front ends, allowing the shipping operators to adjust their reporting systems only once for being able to report in any EU port in the same way. The technical specifications for data and interfaces will be designed to enable both machine-to-machine reporting and reporting via graphic user interface to meet the needs of all kinds of shipping operators. In the longer term, specifications for reporting from autonomous ships could also be introduced. The option requires a connection between the National Single Window and all entities and systems assigned by the underlying legal acts to connect as back-end data recipients; e.g. by connecting the National Single Window as a user to the relevant customs trader interfaces. The back-end technical specifications, from a National Single Window to a relevant local, national or EU level system, would be derived from the requirements in the underlying reference legal acts to ensure all relevant entities continue to receive the data, reports and notifications in a useful and timely manner and in compliance with the functional requirements and technical specifications of the recipient systems (i.e. customs systems). Coordination or data format translation efforts will be needed if several connected entities require the same information in different formats. The National Single Window would thus have a routing and, where/if needed, a technical data format translation function. The data and notifications/declarations received from shipping operators would be split so that each data recipient only receives specific data elements ("need to know" basis). Information flows shall follow the timelines for fulfilment of respective reporting needs; notably the timelines for customs formalities as prescribed in the customs legislation. Declarants (shipping operators) will remain liable and responsible for the correct and timely submission of their reports and notifications. For any potentially personal data, the data recipient will be responsible and accountable for managing the data in line with all applicable data protection rules (e.g. GDPR, national requirements) to ensure proper data privacy including no storage of sensitive data beyond prescribed timelines. Any feedback provided by relevant authority, port operator or port service provider should be send to the declarant via the same channel as received. To facilitate reporting from maritime carriers, where internet connection is sometimes lacking, offline options for reporting will be considered, where appropriate and possible.

Scope of reporting The body of data elements which are, on basis of EU, international or national law, asked from a ship at a port call, must be clearly defined for the European Maritime Single Window environment. The data elements agreed for this scope must then be coordinated and harmonised into an agreed format for the shipping operators at front-end, to avoid duplications and to ensure harmonised reporting. The new legal proposal should therefore include references to this wider set of underlying legal acts for the scope. In addition, a more detailed data set would be needed as a technical tool to aid the front-end interface set-up and as a service and business guidance to the maritime transport operators. This technical tool data list would be a living document to reflect – not prescribe – the data requirements following any legislative updates or updates of technical specifications of the underlying back-end systems. Authorities must not request these data set elements in non-harmonised format nor ask for additional data outside of the single window reporting environment. The aim is to protect shipping operators from excessive administrative burden. In option A1, the scope of the European Maritime Single Window environment covers the comprehensive set of all reporting for a vessel to perform a port call. This would include e.g. all entry/exit formalities and notifications required from the carrier by customs (under the Union Customs Code; reference to UCC to be included into the new RFD legislation) and all national level data elements (Part C of the current RFD, Annex 1). This is in line with stakeholders' opinions reported in the consultations. 82.5% of all responders to the public consultation (93.5% of all shipping companies and ship masters; 50% of all Member States) stated that national requirements should be included in the new framework in order to harmonise all information required for a port call. 6.5% of all open public consultation respondents did not agree the national requirements should be included (0% of shipping companies and ship masters; 19% of Member States) and 11% had no opinion or felt neutral to the proposal. These results are also in line with those obtained during the evaluation when a large part of the shipping stakeholders specifically ask also for a more comprehensive approach to maritime transport and customs reporting. The European Community Shipowners’ Association stressed that: “It goes without saying that we want the customs reporting to be part of it as well. Only in this way shipping can finally enjoy the single market.”For rationalisation and simplification, the scope of the fully harmonised Maritime Single Window data set – notably the national data elements from current RFD, Part C – will be scrutinised in a process together with Member States and connected authorities to ensure that unnecessary (e.g. traditionally requested but now redundant) data elements are over time cleared from the reporting requests. In order to enable this comprehensive data set, timelines and data requirements must be aligned in detail with the current developments of the customs IT systems. The IT systems related to the customs formalities proposed to be included in the scope of the RFD successor (e.g. ICS2) are scheduled to be ready by 2024-25. The implementation of the comprehensive European Maritime Single Window environment should be prepared with technical set-ups and test runs to align with this time frame. All customs reporting via the European Maritime Single Window environment should then be in direct correspondence with the rules, specifications and requirements derived from the Customs legislation and technical specifications of the underlying customs IT systems, and reflect any amendments and updates in these underlying legal acts and specifications. Initiate development towards e-certificate acceptance Just above 80% of respondents to the open public consultation also stated that the new framework should include provisions on certain e-certificates (notably ship certificates) to allow for future fully paperless ships. This issue will be addressed in the revised reporting formalities framework with appropriate references and links to the parallel initiative on electronic transport documents. IMO has also issued Guidelines for the Use of Electronic Certificates promoting the use of secure e-certificates for maritime transport. The common databases and registries anyways established in the European harmonised digital reporting s environment could in later steps be exploited to also allow and enable future secure use of e-certificates and reference numbers for EU port calls. Development of clear data re-use principles for step-wise process towards “reporting only once” of same data In its Council conclusions on Digitalisation of transport on 5 December 2017, the European Council specifically called on the Commission to apply the 'once only’ principle when developing new or revising existing legislation, in order to keep it fit for the digital age. The “once only” principle aims to reduce administrative burden by avoiding that the same business actor is required to supply the same information more than once to the authorities, as first priority within the same port. The goal is to “get the data to circulate, not the user”: authorities may not request that an operator submits again the same, unchanged data as already sent, unless for corrections or updates. This does not imply that the transport operators will not be obliged to report at several different points in time (e.g. customs formalities required by law at several phases: e.g. early stage before a planned port call, formalities required closely before calling a port and formalities upon departure from port). New or changed data must always be reported again. There has been a strong message from consulted stakeholders that the reported information should be more efficiently shared and reused, both to reduce the burden of reporting and for the sake of maximising multimodal transport facilitation. Better access to data contributes to facilitating digital solutions for “smart ports”, significantly speeding up ports procedures with indirect cost-savings and business opportunity improvements for the entire multimodal transport chain. 80.5% of all respondents stated in the open public consultation that they would have some or high benefits from more data sharing and data re-use (75% of the Member States, 83.5% of the shipping companies and ship masters, 100% of the ship agents). 11% of the consulted stakeholders expected related benefits to be low (12.5% of the Member States, 10% of shipping companies and ship masters) and 7.5% expressed no opinion on this question. According to the respondents, the benefits would be increased productivity and time savings from avoiding duplicate reporting. A set of clear principles, rules and rights for data sharing and reuse will therefore be developed to ensure correct and smooth data management and “reporting only once” for carriers. As a minimum first step, the data re-use within the same port must be addressed. Clear definitions for different requirements will be provided, filling the gaps of the current legal framework. Clear roles, responsibilities and accountability for all entities connected to the system will be defined, together with legal obligations/enablements set out in the legislative framework together with the necessary business rules, common standards and procedures. Coordination and technical support should be offered to the connecting entities if needed. The protection of personal data must be well covered in the system, e.g. by ensuring that personal data is erased without delays once not needed, in compliance with the General Data Protection Regulation. A distinction will be made between non-personal and personal data including with clarity in definitions of e.g. data reports including the name of the responsible data provider (e.g. ship master). Definitions and guidelines concerning the processing and management of commercially sensitive data will be addressed. For supporting and enabling real, efficient and secure application of the “reporting only once” principle, common eGovernment building blocks e.g. for eID and eSignature should be exploited. The aim is to enable the application of "reporting only once". To achieve this, a step-wise approach will be taken, with the requirements for sharing of static information and sharing within the same port as a first priority. In subsequent steps, data re-use and data sharing in support of multimodal transport services and more efficient functioning of the logistics chains will be addressed including increased data sharing for "reporting-only-once" at Member State and EU level. Reuse of declarants’ own historical data submitted earlier to another node in the reporting environment should be facilitated where possible. Development of common databases

For a new legislative framework under policy option A1 to work smoothly, it would be necessary to introduce certain common databases to support the interconnected system. This will include a common exemption database, a common (federated) user database(s) and a common ship repository. These common tools would ensure efficient flows and exchanges within the European Maritime Single Window environment (decentralised or centralised). eGovernment building blocks and existing tools for e.g. digital signature and eID would be applied; Horizon 2020 Information and Communication Technologies and relevant industry guidelines will be taken into account. Introduction of a governance mechanism To ensure flexibility and to keep the legislation relevant for the long-term in view of technical and legal developments over time, a governance mechanism must be created. This is especially the case to ensure the system remains maximum efficient also with a view to ICT innovations and new technical possibilities developing. Implementing and/or delegated powers for maintenance of the technical specifications and control of related updates, for the harmonised technical data set and for the data reuse rules and rights will therefore be needed. This will be accompanied by the set-up of the required expert groups for coordination and consultation with Member States and with industry stakeholders as needed. The governance mechanisms should be coordinated by the Commission transport sector but would closely involve relevant Commission services/agencies from all involved policy areas. Development of a complaint/feedback mechanism The Commission is responsible for appropriate follow-up and possible infringement procedures in case of Member States non-compliance, in order to ensure business continuity and equal access to harmonised services for the maritime transport operators. With more clear and specific legal provisions of the new legal proposal (in particular: detailed binding specifications), the Commission will have the possibility of pursuing effective infringement procedures, unlike under the current RFD. Member States and their National Competent Authorities in charge of the National Single Windows will in turn be responsible and accountable for the implementation of the harmonised reporting gateway/front-end. They will also be responsible for the connection to the back-end entities at EU and national level. A complaint/feedback mechanism will also be developed, offering the maritime transport operators a tool to alert authorities if the harmonised reporting and the reporting only once principles are not respected or if any technical fault is found in the reporting systems. Introduction of helpdesk function To facilitate implementation, technical support on the functioning of the European Maritime Single Window environment specifications in the form of helpdesk functions, technical advice and development of application guidelines or other tools to support the Member States will be developed. The helpdesk is for the Member States and will in options A1-A2 focus on providing support on the interpretation of the technical specifications and the data set. This support may also be provided in forms of offered trainings. Support functions towards the front-end and back-end users (data providers and data recipients) will continue to be the responsibility of the National Single Window competent authority. Clear information to business operators about access to the specific content-related helpdesks for various parts of the reporting formalities will be available. 5.3.2.Policy option A2: Harmonised reporting gateways as front-ends to the NSWs: binding technical specifications and requirements (decentralised/distributed) – limited scope Policy Option A2 is exactly the same as policy option A1 with the difference that the scope is limited to cover only the current mandatory RFD reporting formalities and the national legal requirements (current RFD Part C data). The customs IT systems will remain as a parallel interface for completion of customs formalities. This option would, according to the consulted shipping operators, not fully solve the issue of shipping operators being required to report to several reporting entry points (the harmonised reporting gateway(s) for maritime transport and to the various harmonised customs trader interfaces and portals). The harmonisation of information requirements at customs level will still be achieved, as it stems from the already adopted UCC legislation. Without the interconnection with the customs IT systems, the timeline could be shortened and implementation of the European Maritime Single Window environment will be more flexible. With this option, complex interlinkage between the European Maritime Single Window environment and the customs IT systems will not be implemented, avoiding risks of non-synchronisation between back-end entity technical specifications and the maritime reporting gateway. The risk of technical failures will therefore be reduced, same as the development and maintenance costs related to the project implementation. 5.3.3.Policy option B1: Harmonised reporting gateways as front-ends to the NSWs: common IT solution for harmonised interface and formats (decentralised/distributed; EU-level development responsibility, Member State operational responsibility) - comprehensive scope Option B1 is to develop a mandatory common reporting gateway IT solution at EU level and deliver it to all Member States for installation in every National Single Window as a harmonised front-end interface towards the shipping operators. The front-end component will enable submission of data in a common EU format to different National Single Windows by converting the harmonised data to a specific national format used by the National Single Window, and vice versa. The front-end component could also provide data validation and authentication functionalities. The National Single Windows will plug in this new harmonised front-end reporting gateway into their existing system, simply replacing the old user interfaces. The front-end IT solution will be developed as open-source software, therefore allowing the national competent authorities to easily modify the back-end of the reporting gateway for the plug-in to their National Single Window, if necessary. For all other functionalities, the National Single Windows will remain the same, performing the same role towards the back-end entities and requiring minimum adaptations. The reporting gateway IT solution will be developed as in option A, at EU-level. The common data format translation keys for any transformations done by the front-end component from EU formats to national formats would also be developed at EU level, based on the data mapping already completed. Regular updates as required would be supplied via the EU (task may be delegated to a technical support function) following update plans agreed together with the Member States (governance mechanism). The technical implementation for this option will take into account the approach and progress made with the ICS2 Trader Interface as a dedicated channel to receive the Entry Summary Declaration (ENS). The development cost for this common IT solution would be carried at EU level including for all updates required to remain aligned to the technical specifications of the underlying legal acts. Responsibility for the functioning of the front-end component would be on the EU-level entity in charge of the task. Member States would be responsible for adopting/installing the front-end component package within given timelines and to follow instructions for regular and timely updates and maintenance of the system. The operational responsibility would be on Member States, providing helpdesk functions for their connected national entities and for the front-end data providers. Some helpdesk functions towards the National Single Windows regarding the front-end component and specifications will be provided at EU level. The result would be a decentralised (distributed) reporting system of identical reporting gateways in every Member State. As in option A1, the Member States would still be free to organise the back-end connections including to Port Community Systems however they prefer, as long as the set-up respects the common rules and specifications and the quality of services and information flows between the maritime transport operators and the connected entities and authorities remain sufficiently high.

Main principles concerning all sub-measures including scope, liability and responsibility for all involved entities, EU level coordination and governance mechanisms, e-certificates initiative, helpdesk functions etc. would be arranged as in option A1 above. Governance and helpdesk functions will be required regardless of the policy option, as technical enablers to ensure the reporting environment works smoothly and can remain aligned with legal and technical developments. In options B1-B2, the helpdesk will provide support on the installation of the front-end gateway solution to the National Single Windows. 5.3.4.Policy option B2: Harmonised reporting gateways as front-ends to the NSWs: common IT solution for harmonised interface and formats (decentralised/distributed; EU-level development responsibility, Member State operational responsibility) – limited scope Option B2 is exactly the same as policy option B1 with the difference that the scope will be limited. In option B2, the same limited scope / technical data set is considered as in option A2. 5.3.5.Policy option C1: Harmonised reporting via a central gateway (centralised solution) – comprehensive scope Option C1 is to introduce a centralised European reporting gateway hosted and operated by an EU-level entity or technical support function. The centralised window would offer one single reporting entry point for all port calls throughout the EU including the necessary two-way information exchanges between data providers and connected entities and systems. Shipping operators would also still have the choice to report directly to the various customs trader interfaces. Member States may also in this case want to continue maintaining the old reporting gateway (front-end interface) of the National Single Windows as an option for SME operators in domestic traffic. However, if a shipping operator chooses to report via the centralised European reporting gateway, authorities would not be allowed to request additional reporting also via other entry points (reporting only once). The centralised European reporting gateway would channel incoming reporting and notifications directly to other EU-level systems, such as the Harmonised Trader Interface for customs entry summary declarations. It would channel other data via the National Single Windows for transmissions to national level data recipients. Help desk and other support related to the functioning of the European reporting gateway will be provided at EU level. The National Single Windows would remain in place but with adaptations. They would serve mainly as a router between the centralised European gateway and the national level data recipients (receiving data from the central front-end gateway and continuing the functionality of distributing that data to national level back-end entities). Member States would be responsible for ensuring connection of their National Single Windows to the centralised gateway. In principle, National Single Windows could also continue to offer an alternative reporting channel through their former front-end gateways. If Member States wish to maintain this possibility as a voluntary alternative for the maritime operators it would be allowed – in addition to, not a replacement of the centralised European reporting gateway. Strong back-up and cyber security solutions would be required to ensure resilience and availability of the system. Main principles concerning all sub-measures including scope, liability and responsibility for all involved entities, EU level coordination and governance mechanisms, e-certificates initiative, helpdesk functions etc. would be arranged as in options A1 and B1 above. The helpdesk in option C1-C2 will provide support to Member States on all issues regarding their connection into the centralised reporting gateway, as well as on the common data set and data formats. Support towards national back-end entities continues to be provided via National Single Window competent authorities. 5.3.6.Policy option C2: Harmonised reporting via a central gateway (centralised solution) – limited scope Option C2 is exactly the same as policy option C1 with the difference that the scope will be limited. In option C2, the same limited scope / technical data set is considered as in options A2 and B2.

5.4.Overview of main differences between the harmonisation solutions Options A1-A2 Options B1-B2 Options C1-C2 Harmonisation tool Harmonisation achieved via legally binding common technical specifications for Member States to implement a harmonised reporting front-end gateway to their National Single Windows. Harmonisation achieved via identical front-end components for the harmonised reporting gateway, developed at EU level and installed at each National Single Window Harmonisation achieved via a centralised gateway at EU-level. The gateway will provide single EU-level entry point for the reporting. It will forward the received information to the National Single Windows and provide users authentication, validate data and provide logging and monitoring functionalities. Role of Member States To develop the new front-end solution based on the EU specifications, adapt the National Single Window accordingly and to continue to operate and maintain the National Single Window. To plug in the provided front-end component to their National Single Windows and to continue to operate and maintain the National Single Window. To adapt the National Single Window to be connected with the centralised gateway layer including shifting some functionalities from front-end to routing roles; to operate and maintain the National Single Window as routing structure. Role of the EU To deliver the technical specifications; to coordinate the governance and updates To develop and deliver the common IT solution that can be plugged in at all National Single Windows as the new reporting gateway; to coordinate the governance and updates. To develop, establish and operate the central reporting gateway; to coordinate the governance and updates National Single Windows Remain as the reporting entry points, adapted to the harmonised format; will