E

4 ALBERT EMBANKMENT LONDON SE1 7SR Telephone: +44 (0)20 7735 7611 Fax: +44 (0)20 7587 3210

FAL.5/Circ.42 16 May 2019

GUIDELINES FOR SETTING UP A MARITIME SINGLE WINDOW

1 The Facilitation Committee, at its forty-third session (8 to 12 April 2019), approved the attached Guidelines for setting up a maritime single window.

2 Member States and international organizations are invited to bring the Guidelines to the attention of all parties concerned.

3 Member States and international organizations are also invited to bring to the attention of the Committee, at the earliest opportunity, the results of the experience gained from the use of the Guidelines for consideration of action to be taken.

4 This circular revokes FAL.5/Circ.36.

***

I:\CIRC\FAL\05\FAL.5-Circ.42.docx

FAL.5/Circ.42 Annex, page 1

ANNEX

GUIDELINES FOR SETTING UP A MARITIME SINGLE WINDOW

TABLE OF CONTENTS

Contents

1 Introduction 3 2 Scope 3 2.1 Target audience ...... 3 2.2 Maritime transport ...... 4 2.3 Electronic messaging...... 4 2.4 No standards defined...... 4 3 Terminology 4 3.1 Parties ...... 4 3.1.1 Carrier ...... 4 3.1.2 Freight Forwarder ...... 4 3.1.3 Principal ...... 4 3.1.4 Ship agent ...... 4 3.2 Procedures ...... 5 3.2.1 Clearance ...... 5 3.2.2 Manifest...... 5 3.2.3 Bill of lading ...... 5 3.2.4 Waybill ...... 5 3.2.5 FAL documents ...... 5 3.3 Information Technology ...... 6 3.3.1 Electronic Data Interchange (EDI) ...... 6 3.3.2 UNECE; UN/EDIFACT ...... 6 3.3.3 Electronic signature ...... 6 3.3.4 Electronic seal ...... 6 3.4 Single window ...... 6 3.4.1 National single window (NSW) ...... 7 3.4.2 Maritime single window (MSW) ...... 7 3.4.3 Trade single window (TSW)/customs single window (CSW) ...... 7 3.4.4 Port single window (PSW) ...... 7 3.4.5 Port community system (PCS) ...... 8 3.4.6 Examples of single window and associated systems relationship ...... 8 4 Overview of international maritime trade 9 4.1 Different business process groups ...... 9 4.2 Transport timeline ...... 10 4.3 Parties and business functions related to a single window ...... 10 5 Developing a Basic Plan 12 5.1 Objective ...... 12 5.2 Conceptual architecture ...... 12 5.3 Determine scope and stakeholders ...... 14 5.3.1 MSW and/or TSW ...... 14 5.3.2 Clearance functions implemented ...... 14 5.3.3 Types of shipping supported ...... 14 5.3.4 Geographic scope ...... 15 5.4 Analyse relevant policy issues ...... 15 5.4.1 International shipping ...... 15

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 2

5.4.2 Regional shipping...... 16 5.4.3 National shipping and cabotage ...... 16 5.5 Consider use of legacy systems and processes ...... 16 5.6 Determine requirements for information security ...... 16 5.7 Support process automation ...... 17 5.8 Determine business model ...... 17 5.9 Information repository ...... 17 6 Implementation 18 6.1 Single window methodology and design process ...... 18 6.2 Key performance indicators ...... 19 6.3 Outline of system architecture ...... 19 6.4 Data harmonization...... 22 6.5 Data elements...... 22 6.6 Data entry into single window ...... 22 6.7 Tools to aid users' data entry ...... 23 6.8 Non-functional requirements ...... 23 6.9 Cyber security ...... 23 7 Interoperability 23 7.1 UN/EDIFACT and FAL Compendium ...... 24 7.2 Extensible Markup Language (XML) ...... 24 8 Characteristics 24 9 Operation and Maintenance 26 10 References 26 ANNEX A: MARITIME SINGLE WINDOW EXAMPLES 27 ANNEX B: LIST OF APPLICABLE STANDARDS 63 1 IMO: Facilitation Committee (FAL) ...... 63 2 World Health Organization (WHO) ...... 63 3 World Customs Organization (WCO) ...... 63 4 World Trade Organization (WTO) ...... 63 5 United Nations Economic Commission for Europe (UNECE) ...... 63 6 United Nations Conference on Trade and Development (UNCTAD) ...... 64 7 United Nations Commission on International Trade Law (UNCITRAL) ...... 64 8 United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT) ...... 64 9 International Organization for Standardization (ISO) ...... 65 10 Legal issues in a single window project ...... 65 11 PROTECT...... 65 12 SMDG ...... 65 13 Transportation Data Coordinating Committee (TDCC) and Accredited Standards Committee (ASC X12) ...... 65 14 Organization for the Advancement of Structured Information Standards (OASIS) — ebXML ...... 65 ANNEX C: TECHNICAL OUTLINE 67 ANNEX D: BASIC ITEMS FOR CONSIDERATION IN THE OPERATION AND MAINTENANCE MANAGEMENT 70

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 3

1 Introduction

There is a consensus that there is a need to reduce administrative burdens on shipping. FAL 40 adopted resolution FAL.12(40), Amendments to the annex to the FAL Convention, which includes new Standard 1.3bis which requires public authorities to establish systems for the electronic exchange of information to assist ship and port clearance processes. The inclusion of maritime transport within a "single window" environment is seen as an effective way of delivering Standard 1.3bis and also addressing the overall administrative burdens on shipping. In this regard, a single window environment should be implemented based on these Guidelines. The main characteristics of a single window environment, at least between individual ports within the same country, are harmonization, standardization and interoperability, avoiding proprietary technology and/or data models, and supporting the goal of international interoperability between single window environments in the future.

There is a substantial amount of literature available on the single window environment, but this is mostly concerned with trade- and cargo-related issues. The issue of clearance of the ship as a means of transport is less extensively covered. However the clearance of the ship and the cargo need to go hand in hand to allow the efficient operation of both the port and the ship. While these Guidelines attempt to provide guidance on maritime transport clearance, including the clearance of the ship, this does not necessarily mean that one needs to define different single window environments for transport and trade.

In these Guidelines, the main part describes the key points of development of a single window environment for the target audience shown in section 2.1. This includes key performance indicators, outlined in section 6.2, based on the characteristics, outlined in section 8, for a single window environment which addresses overall administrative burdens on shipping.

The annexes contain important information related to development of a single window environment.

2 Scope

Though recommendations and guidelines have been developed by the United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT), the World Customs Organization (WCO) and other organizations, they only provide basic definitions, models, data harmonization or roadmaps towards implementation of a single window environment. Implementers may face many difficulties in developing a single window environment, because there are no specific guidelines covering the maritime reporting element. The goal of this document is to develop single window environment guidelines and a framework that cover the entire life cycle. It is believed that the resulting environment will provide for (1) simplified electronic means of clearance of ships in maritime transport, (2) standardization of logistics activities, interface and information in overall maritime transport, and (3) improved maritime logistics efficiency and strengthened maritime logistics competitiveness of IMO Member States. These Guidelines are built upon general single window concepts and characteristics which have been expanded to integrate the requirements of maritime transport.

2.1 Target audience

The target audience of these Guidelines are public authorities or Administrations responsible for developing or modifying environments for a Maritime Single Window (MSW) and Contracting Governments that encourage the introduction of MSW environments to the public authorities etc. Depending on a country's situation, a Contracting Government may act as the public authority or Administration. These Guidelines will also be helpful for consultants on behalf of public authorities or Administrations and other interested organizations.

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 4

2.2 Maritime transport

These Guidelines focus on the development of a single window environment for maritime transport. However, transport is only one component of trade facilitation (see section 4.1) and maritime transport is only one of several other transport modes.

2.3 Electronic messaging

Electronic exchange of information, i.e. the elimination of manual handling and processing of information, is the most efficient way to perform the necessary clearance of ships. These Guidelines cover implementation of an electronic facility for clearance purposes.

2.4 No standards defined

These Guidelines do not define any particular standard for implementing a single window. They point to different internationally recognized standards that are available and that can be utilized as appropriate.

3 Terminology

This section includes commonly used terms when describing a single window application.

3.1 Parties

3.1.1 Carrier

The party undertaking the physical transport of a consignment, as part of a larger supply chain.

3.1.2 Freight forwarder

The party arranging the carriage of goods including related services and/or associated formalities on behalf of a freight shipper or consignee. The freight forwarder is often contracted by the principal, the consignor or the consignee, depending on which terms of contract apply in the business relation between them.

3.1.3 Principal

An individual or organization that entrusts the execution of some tasks, such as the execution of a carriage order, to a Contracting Party in return for renumeration.

3.1.4 Ship agent

The party representing the ship's owner and/or charterer (the Principal) in port. If so instructed, the agent is responsible to the Principal for arranging, together with the port, a berth, all relevant port and husbandry services, tending to the requirements of the master and crew, clearing the ship with the port and other authorities (including preparation and submission of appropriate documentation) along with releasing or receiving cargo on behalf of the Principal.

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 5

3.2 Procedures

3.2.1 Clearance

The process of getting the necessary permits (written, electronic or informal) to allow a certain process to be performed. In the scope of these Guidelines, the following clearances are relevant:

• Clearance for a ship to enter or leave national waters.

• Clearance for a ship to berth. This will normally include clearance for the cargo or passengers to proceed to import/immigration control.

• Clearance for the ship to load or offload.

• Clearance for the ship to leave berth.

• Clearance for cargo to be imported or exported.

Other forms of clearance may also be relevant, e.g. clearance to enter ship reporting areas, port fairways, channels, locks or other restricted traffic areas. However, this is normally part of traffic management.

3.2.2 Manifest

A document recapitulating the various data from bills of lading and other transport documents issued for the carriage of goods on board ships.

3.2.3 Bill of lading

A bill of lading is similar to a waybill (see below) and the two terms are sometimes used for the same document. However, a bill of lading is normally more formal and is often negotiable, which gives the person with ownership of the bill of lading the right of ownership of the goods and the right to re-route the shipment. Also, a feature of the bill of lading is that the original, either in paper or electronic equivalent, must be surrendered in order to obtain delivery of the goods, while proof of identity by the named consignee is sufficient in the case of a waybill. This term is also described in code value 705 under the UN Trade Data Element Directory Code list 1001 for document name code.

3.2.4 Waybill

An agreement between the consignor, carrier and consignee covering the transport of a consignment. This agreement covers the ownership and liability issues of the parties in relation to the consignment. This term is also described in the UN Trade Data Element Directory under Code list 1001 for document type.

3.2.5 FAL documents

Information presenting data by electronic means or by non-electronic means, as defined by the annex to the FAL Convention. Standard 2.1 of the annex to the FAL Convention lists documents representing the maximum reporting requirement for the purpose of those documents. Note that FAL forms have been developed as presented in appendix 1 of the FAL Convention.

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 6

3.3 Information Technology

3.3.1 Electronic Data Interchange (EDI)

The abbreviation EDI is used to refer to any type of electronic data interchange. The interchange can take place using UN/EDIFACT, XML or any other standardized file format. It is important however that all formats comply with international standards, particularly where trade has a preference for one or more standards, as this reduces the cost of compliance for trade for exchanging information.

3.3.2 UNECE; UN/EDIFACT

UNECE is the abbreviation for the United Nations Economic Commission for Europe. UN/EDIFACT is the abbreviation for the United Nations Electronic Data Interchange for Administration, Commerce and Transport. It is a special format defined by UN/CEFACT and later standardized by the International Organization for Standardization (ISO) as the ISO 9735 standards.

3.3.3 Electronic signature

Data in electronic format which is attached to or logically associated with other electronic data and which serves as a method of authentication that meets the following requirements:

.1 it is uniquely linked to the signatory;

.2 it can identify the signatory;

.3 it is created using means that the signatory can maintain under his/her sole control; and

.4 it is linked to the data to which it relates in such a manner that any subsequent change of the data is detectable.

3.3.4 Electronic seal

An electronic seal is technically the same as an electronic signature, used by an organization.

3.4 Single window

In the annex to the FAL Convention, single window is defined as a facility that allows submission of standardized information covered by the Convention to a single entry point. The facility is generally understood to be based on electronic data transmission and relies on system software to distribute the data submitted to the receivers in accordance with the system rules and user agreements. The literal definition of single window allows for any type of data transmission that employs a single entry point and avoids duplication. UNECE Recommendation No.33 defines a single window as an electronic facility providing trade facilitation measures that allows parties involved in trade and transport to lodge standardized information and documents with a single entry point to fulfil all import, export and transit-related regulatory requirements. Individual data elements should only be submitted once electronically.

WCO members prefer to use the term single window environment because single window implementations are invariably a collection of interdependent facilities, regulatory requirements and cross-border regulatory agencies' business processes. The establishment of the single

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 7 window environment for border-control procedures for conveyance, transport equipment, goods and crew is considered by customs administrations as the best solution to the complex problems of border automation and information management involving multiple cross-border regulatory agencies.

UN/CEFACT has also defined in a Technical Note the term "Single Window Environment". The important message of the explanation is that "once information has been sent to the Environment, an economic operator need not submit their data multiple times because it will already be stored in the system". This is also referred to as the principle of "reporting once only" to eliminate the need to submit the same or similar information separately to different authorities. Also, it describes that "the main objective of Single Window implementation is to put in place trade facilitation mechanisms (not the creation of an electronic solution)."

In these Guidelines, "(maritime or trade etc.) single window" would indicate "(maritime or trade etc.) single window environment" which basically describes the total concept including "system", plan, operation, maintenance, legal issues, data sharing and collaboration between stakeholders etc., unless otherwise stated. When the phrase "(maritime or trade etc.) single window system" is used, this would mean the information system described from a technical viewpoint.

3.4.1 National single window (NSW)

Where a nation has established a single environment for the collection, distribution and exchange of information for national authorities across different sectors such as maritime, port and trade.

These Guidelines use the term single window only, except when referring to single window solutions that mix local clearance functions (e.g. for one or a few ports) and national clearance functions through one common national single window.

3.4.2 Maritime single window (MSW)

The term "maritime single window" (MSW) can be defined as a one-stop service environment that covers maritime and port administrative procedures, such as port entry/departure declaration, notice of security reports, and other related information between private sectors and public authorities nationwide. In other words, an MSW is a single window in the scope of maritime and port fields. Sometimes for some countries, an MSW may also serve as an NSW or trade single window/customs single window (TSW/CSW). Note that an MSW is called by different names in each area. For example, in ASEAN countries and Japan an MSW is called "Port EDI system."

3.4.3 Trade single window (TSW)/customs single window (CSW)

The term "Trade single window (TSW)/customs single window (CSW)" can be defined as an environment that covers procedures related to exports and imports goods such as customs clearance. Sometimes for some countries, TSW/CSW (hereinafter referred to as "TSW") may also serve as an MSW.

3.4.4 Port single window (PSW)

A single window environment that provides information at a local level about a vessel to the authorities at that level, usually a single port. PSW systems should, where possible, be connected to a higher-level NSW or MSW. In the latter case, PSW systems may function as a single point of access for NSW regarding reporting formalities. PSW can also be part of the wider Port Community System (PCS) in a port.

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 8

3.4.5 Port community system (PCS)

A PCS is defined by IPCSA(International Port Community Systems Association) as a neutral and open electronic platform enabling intelligent and secure exchange of information between public and private stakeholders in order to improve the competitive position of the sea and air portsʹ communities; and optimizes, manages and automates port and logistics processes through a single submission of data and connecting transport and logistics chains.

A PCS is a modular system with functionality designed to provide all the various sectors and players within a port community environment with tools specific to them, thus delivering a tightly integrated system. Developed for port users by port users, a PCS encompasses exports, imports, trans-shipments, consolidations, hazardous cargo and maritime statistics reporting. PCS covers Business to Business (B2B), Business to Government (B2G) and Government to Business (G2B) and in some cases Government to Government (G2G) exchanges.

PCS can also act as gateways into SW (including MSW, NSW or TSW).

3.4.6 Examples of single window and associated systems relationship

A conceptual image showing the possible relations of each single window is described in figure 1. Note that the figure does not cover all possible system relations (e.g. some countries do not have PSW but have MSW). With regard to other detail patterns, please see item 7 or 9 of maritime single window examples in annex A.

Figure 1 – Examples of single window and associated systems relationship

(This figure is replicated from TC 65/INF.6/Add.1; however some descriptions are modified.)

* Note: Vessel traffic service (VTS): a service implemented by a Competent Authority, designed to improve the safety and efficiency of vessel traffic and to protect the environment. The service should have the capability to interact with the traffic and to respond to traffic situations developing in the VTS area.

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 9

4 Overview of international maritime trade

This section discusses the concepts behind the MSW and looks at its relationship to the general trade requirements which in many cases include their own single windows.

One of the major factors affecting the successful deployment of any technical system, whether a single window or not, is how well it satisfies the requirements of the intended users. This implies that the designers of the single window need to know who the users are and what requirements they have.

Thus, the main message in this section is that trade has different dimensions, each with different parties and different responsibilities. A single window solution must define what dimensions, what parties and what responsibilities it is intended to serve and then implement technical solutions that satisfy these requirements.

Additionally, a single window solution should demonstrate that the integration of any new or additional reporting into a single window does actually have benefits in terms of trade facilitation.

4.1 Different business process groups

Trade involves a number of different business processes which interact to meet the higher-level objective of movement of goods. Figure 2 attempts to illustrate some of the main business processes and parties in trade and transport. The top level, driving the whole process, is international trade. This creates the need for transportation, which in many cases is supplied by transport service providers, e.g. the forwarders. The actual transport may be performed over several legs, some of which are typically by ship. During the ship transport, there are also operational issues that need to be addressed between the parties involved in the transport operation. Figure 2 – Main business processes in trade and transport

International Buy Ship Pay trade

Transport Consignor Forwarder Carrier Ship’s Consignee services agent

Transportation Load Sea Port Discharge

Ship Owner Charterer Manager Seafarer Authorities operations

Figure 2 visualizes a high-level view of the processes, thus it is highly simplified and the real processes are significantly more complex. Also, these four levels may be repeated several times over the freight operations and the roles and actions on each level will often be intertwined with other levels' roles and actions.

The users' requirements on each level are driven by the business process on that level and have different focuses. On the highest level they are driven by the sale and purchase of transported goods, while on the lowest level they are driven by the need for better use of

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 10 resources and infrastructure. Thus, a single window may not be able to cater for all requirements and in some cases the use of a combination of different "single" windows and more conventional party-to-party interaction will be more appropriate.

4.2 Transport timeline

Reporting requirements and hence the use of the single window will depend on where a ship or the cargo is on its voyage. Figure 3 below shows some of the phases that can be used as a reference for reporting.

Figure 3 – Timeline in a transport process

Departure from End of sea passage Full ahead on passage previous port EOSP FAOP

Sea Port Notice Sea Moor Discharge Load Aweigh Departure passage approach of passage Readiness

Pilot pick-up Enter / leave Passing baseline reporting area

Depending on applicable rules or commercial processes, a number of other subdivisions are in use. Some are included in figure 3:

• Passing baseline: Where the ship enters national waters, normally with some reporting requirements to the coastguard, navy or police.

• End of sea passage (EOSP): Normally used in transport contracts, where the ship decelerates from transit speed.

• Pilot pick-up: Often at EOSP.

• Enter/leave ship reporting area/VTS area.

• Full ahead on passage (FAOP): Where transit to the next port starts.

Note also that the sea passage may contain channel or strait passages and that the port approach likewise may be subdivided into more phases.

4.3 Parties and business functions related to a single window

Figure 4 below shows a more detailed view of the user groups involved in clearance of a ship.

The different groups of actors with individual responsibilities have a significant impact on what information, at what time and in which format needs to be exchanged.

The top-level boxes define the main user groups responsible for the clearance process and the rectangles at the bottom show the user groups involved in the transport operation.

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 11

Figure 4 – User groups involved in clearance of a ship

Ship Port / Nautical Import /export Immigration inspection Terminal Security Security Security Security Security Contraband Ship safety Ship safety Ship safety Environment Environment Environment Environment Other Payment Payment Payment Operations Operations Cargo

Ship , Agent , Owner /Manager Charterer , cargo owner , passenger , consignee , consignor

The colour of the top-level boxes indicates whether the group of actors processes clearance purely for maritime transport (yellow) or for several transport modes (orange). The port and terminal actors have been shown to belong to both areas. This is because the terminal (or in some cases the port) also has to relate to hinterland transport, e.g. by road, rail or inland waterways.

To indicate the reason for the information exchanges, the top-level boxes have some internal operational labels showing some of the operations performed.

The arrows indicate reporting requirements. Green arrows show data flows that normally have to take place well before arrival while mauve arrows show flows that take place closer to or even after arrival.

Table 1 below shows some examples of specific parties that can be assigned to the actor groups. The actual parties may have different names and functions in different countries and even in different ports, but the list presented here is relatively general.

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 12

Table 1 – Specific parties Group Function Example party (documents) Nautical Security Navy (ISPS reports, arrival notifications) Safety Coastguard (arrival notifications, passing baseline) VTS, pilot, ship reporting area (arrival notifications) Environment Coastguard (dangerous goods manifest, ballast water reports) Payments Fairway fees, pilot fees Operations VTS, pilot (arrival notification) Inspection Security Port State control (ISPS documents) Safety Port State control (certificates) Environment Port State control (waste and oil records) Other ILO (contracts) Port/terminal Security Port security officer (ISPS reports) Safety Safety officer (dangerous goods manifest, arrival notification) Environment Safety officer (waste reports, ballast water reports) Payment Port/terminal fees Operations Arrival/departure notifications Cargo Clearance status for cargo, cargo manifest Import/export Security Cargo manifest Contraband Arrival notification (previous ports), cargo manifest Environment Cargo manifest, veterinary, health, other certificates Payment Customs dues Immigration Security Crew list, passenger list

5 Developing a Basic Plan

Sections 5 to 8 are written as short step-by-step guidelines to the implementation of a single window system for maritime transport. Each step is relatively briefly described, but will give references to other parts of the guidelines with more information when required. Also, more detailed information can be found in the IMO FAL Compendium on Facilitation and Electronic Business (FAL Compendium).

Note that the results of each new step may invalidate certain assumptions from earlier steps, possibly requiring some backtracking.

5.1 Objective

An MSW implemented in accordance with these guidelines should achieve the following objectives:

.1 enhance the efficiency of reporting and clearance processes, and maritime trade;

.2 maximize harmonization and standardization at least between ports at the national level; and

.3 minimize administrative burdens for shipping.

5.2 Conceptual architecture

The system depicted below represents a conceptual architectural model that defines the structure and behaviour of the MSW. This model assumes that a single authority (CIM, Centralized information model (see sections 5.8 and 5.9) has the responsibility to operate the system that receives information electronically via the single window and thereby disseminates this information to all relevant stakeholders.

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 13

The conceptual model illustrates that the MSW consists of an environment whereby ship data providers can submit information electronically either through a user interface or a system-to-system interface. The information is digitized, and the individual data elements will be submitted once only.

Figure 5 – Maritime single window conceptual architecture

Within this general system configuration there are many possible ways of how to define the architecture of an MSW depending upon each State's own requirements and conditions.

Figure 5 illustrates the information flows which take place within the MSW, such as:

• the submission of information by the shipping industry (e.g. ship master or agent) and the receipt of decisions from authorities; and

• the distribution of the received information to the authorities and the submission of their decisions to the shipping industry.

Due to the rapid evolution of technologies during the last decade and the exponential rise in the possibilities of exchange and storage, it is recommended to have an open architectural vision geared to the future. Central topics include:

.1 modular design and standardized interfaces;

.2 ensure interconnection with ships/agent for reporting;

.3 ensure interconnection with authorities and entities having autonomous systems;

.4 exchange with stakeholders/users not having (own) computer systems;

.5 compensate for the absence, the poor quality or the high costs of telecom links; and

.6 ensure continuity of the service.

The amended FAL Convention mandates the use of modern information and communication technology and, in particular, electronic exchange of information, including electronic data interchange (EDI), to transmit information related to maritime transport. The use of EDI is a central part of the conceptual architecture.

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 14

5.3 Determine scope and stakeholders

It is necessary to determine what functions the single window will have and who the main stakeholders are. The main issues are described in sections 5.3.1 to 5.3.4.

5.3.1 MSW and/or TSW

In the context of shipping, two main types of single window, MSW and TSW, can generally be distinguished, although in practice many implementations will be a mix of the two.

MSW: The FAL Convention and the FAL Compendium define the maximum amount of clearance information that may be required before a ship can go to berth. However, getting cleared according to the FAL requirements does not automatically imply that the passengers or crew can enter the country or that the cargo can be imported. Normally, ship clearance means that cargo can be offloaded to the quay side and that passengers may disembark for immigration control.

TSW: Most existing single window implementations deal with the import and/or export clearance of cargo, thus as a TSW. Depending on the national structure, they can be operated by or on behalf of various authorities, e.g. customs or veterinary or agricultural authorities. This means TSW. This is related, among other things, to the protection of national interests in terms of taxation and to protection of the State from various forms of dangerous imports.

5.3.2 Clearance functions implemented

Consideration may also be given to the different types of clearance that can be given. The following categories can be distinguished:

.1 Clearance of ship to enter territorial waters: This allows the ship to proceed from international to national waters and usually requires some kind of permit from border control, military or similar entities.

.2 Clearance of ship to berth: This includes clearance of the ship in relation to various safety and security issues, possibly including sanitary, phytosanitary and security-related clearance of cargo and passengers.

.3 Clearance of passengers and crew: This includes necessary measures to allow the crew and passengers to leave the ship.

.4 Clearance of cargo for discharge, load or trans-shipment.

.5 Clearance for bunker or other port operations.

Similar clearance levels may be defined for departure. Note also that this list does not include customs' and other authorities' clearance of goods for import and export, which are typically TSW functions.

5.3.3 Types of shipping supported

There are wide variations between types of shipping, each with certain challenges:

.1 ROPAX: unknown cargo in passengers' cars; partly very short international ferry rides; special consideration required to achieve clearance without excessive delays for embarkation and disembarkation.

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 15

.2 Passenger/Cruise: large groups of passengers, ʺday immigrantsʺ.

.3 Ro-ro/Container: large amounts of cargo information, typically in UN/EDIFACT format; manifest/bills of lading are often sent as electronic documents.

.4 Bulk: simple manifests/bills of lading; simple customs procedures.

.5 General cargo: more complex manifests and customs procedures; several receivers and shippers. Some sectors include vessels with regular and more frequent calls.

Thus, the proposed single window should consider what types of ships are most likely to be handled through the system and what can be handled as exceptions.

5.3.4 Geographic scope

A single window can provide clearance for different geographic areas. From larger to smaller areas, some examples are the following:

.1 regional clearance: clearance for entry into a region of more than one State;

.2 national clearance: clearance for entry into a State; and

.3 port clearance: clearance for entry into a specific port.

Depending on national legislation and regional agreements, one or more of these levels of clearance may be required, and are maintained by one or more clearance authorities.

Review and analysis of business processes and information flows

It is necessary to review and analyse the current business processes and their information flows when introducing an MSW. For setting a single entry point and realizing "reporting once only", the business processes and their information flows would be changed. In addition, it would be better to consider streamlining other related business processes and their information flows, taking this opportunity. For changing the business processes and their information flows, it would be helpful to set up a framework for discussions with relevant stakeholders.

5.4 Analyse relevant policy issues

Legislation and policy issues are perhaps the most complex factors in the establishment of a single window. UNECE Recommendation No.35, "Establishing a Legal Framework for an International Trade Single Window", refers to the way of approaching the common legal issues encountered when developing a single window. In addition to Recommendation No.35, there are also legal issues related to different types of shipping that need to be considered as described in 5.3.1, 5.3.2 and 5.3.3. Furthermore, particular consideration should be given to some of the experiences gained in other projects.

5.4.1 International shipping

Requirements for international shipping are usually transcribed into national legislation. For reporting requirements, national legislation will often reflect the FAL Convention. However, there might be parallel regional requirements; for example, as in Directive 2010/65/EU of the European Parliament and of the Council. Other national, regional or international legislation to be considered cover, for example, security clearance or special requirements for early arrival notification.

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 16

5.4.2 Regional shipping

Some regions have special legislation covering ship traffic between States in the region. This typically involves stricter controls at entry to the region than when moving between regional ports.

5.4.3 National shipping and cabotage

National shipping and cabotage operations are normally covered in national legislation. Cabotage agreements may again refer to international legislation.

5.5 Consider use of legacy systems and processes

The introduction of new single window systems will by necessity change some business processes. The purpose of the single window is to simplify trade and transport processes. However, the overall cost of a new system will be determined by the costs of necessary software and hardware investments as well as by the costs of changes to processes. Where legacy processes are retained, care should be taken to ensure consistency with newer automated ship clearance systems. If deemed possible to help reduce costs, a SW could utilize existing systems with interfaces enabling exchange of information with both new and legacy systems, unless retaining legacy systems would unduly impact the overall objective of simplification. Some issues that can be considered are as follows:

.1 Tools exist that let users interface/interact with electronic systems without needing overly specialized software. Several common tools such as Adobe Reader, Microsoft Excel and others can read and write XML files with a graphical user interface. However, while the general software allows you to create documents in the XML format, it does not always strictly follow the requirements for the format and structure of such a document, which can significantly complicate the automated processing of such a document and serve as a reason for refusing to accept it. It seems more appropriate to use specialized software with open source code to solve such cases.

.2 An automated information transaction system (see sections 3.3.1 and 3.3.2) may in some cases simplify the overall design of the complete system by allowing legacy document formats to be used.

However, in all cases the emphasis should be on the harmonization of processes and data models, as discussed in section 6.4.

5.6 Determine requirements for information security

As the single window will be used for transactions that can have commercial as well as legal importance, it needs to address the issue of information security. Security normally involves some or all of the following concepts:

.1 Confidentiality: Assurance that information is not disclosed to unauthorized individuals or systems.

.2 Integrity: Assurance that the received (or sent) information is correct and logically consistent. .3 Authentication: Assurance that the identity of the sender (or receiver) is the one specified.

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 17

.4 Authorization: Assurance that the sender or receiver has the authority to provide or receive the information.

.5 Availability: Assurance that the system is available when needed.

.6 Non-repudiation: Assurance that the sender or receiver of information cannot deny that the information was sent or received.

.7 Message transmission: Assurance that messages through the single window are traceable and that some concept of guaranteed delivery is applied.

Sufficient emphasis needs to be put on implementing technical features that address the relevant security issues.

5.7 Support process automation

Several of the security mechanisms are also required to support full automation of administrative processes. To automate, for example, ship reporting, it is necessary that the automation system can show evidence that the report was sent and that the receiver cannot tamper with the content. It is normally also required that the sender of a message can be authenticated.

5.8 Determine business model

The success of the single window will also depend on to what degree the business model matches user expectations. Thus, the selection of a suitable business model is important. There is a wide range of variants from which to choose, but some typical models are the following:

.1 fully operated and funded by public authorities. No payment for using the system;

.2 funded by commercial port companies with no direct pay for usage. This may make sense as a single window can significantly simplify many port processes; and

.3 paid for by users as a fee per transaction. This assigns costs directly to the users of the system. This is mostly the case with port community systems operated by private companies.

The benefit of waiving usage fees is that the uptake among users may be quicker. This will in turn give faster return on investments for the shore authorities and other users. However, this model also requires the long-term funding to be in place before the system is implemented.

5.9 Information repository

The report "Blueprint for a virtual port" (BLU-VH) describes three different models for collaboration through electronic systems such as a single window. The report analyses these three models in terms of different perspectives, namely infrastructure, messaging, security and mobility. The three e-collaboration models are:

.1 Bilateral information model (BIM): In this model, information is exchanged directly between the different actors on a bilateral basis. This is the traditional system without a single window or where the single window only supplies information about what server can perform what function.

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 18

.2 Centralized information model (CIM): In this model, data is stored at a central information service provider. Information can be retrieved from this central information service provider by trading partners that have the right to do so.

.3 Decentralized information model (DIM): In this model, data is stored and controlled by each individual party. A broker service can help in retrieving the information from the right source.

Many modern systems related to maritime and port fields currently use the CIM approach, while, as an example, the European Union's SafeSeaNet is a DIM system, playing a wider role of a federation of distinct NSWs (or MSWs) in which a central hub, known as the European Index Server, keeps track of important events, with Member States storing the information on each event. The index server receives a notification each time a report is made to a Member-State system, but the full details of the report are stored either at the Member-State level or even more locally within a Member State and only exchanged with other users on the basis of a request sent via the European Index Server. This model allows a balance to be found between supporting the free flow of information throughout the system and allowing individual users to deliver their data-collection and processing functions in the most appropriate way to suit their own operational and organizational context.

6 Implementation

6.1 Single window methodology and design process

To successfully transform existing reporting and clearance processes into a single window, which at least embodies the reporting requirements of the annex to the FAL Convention, the methodology and process should address the following:

.1 the needs of all stakeholders;

.2 the commitment to an efficient single window;

.3 the development of a harmonized list of data reporting requirements;

.4 an agreed reporting format which meets the needs of all stakeholders of local or international trade; and

.5 where appropriate, the use of international and recognized standards for communication between business users and the MSW, as many of these users may be foreign or international entities.

Also, the administrative and business processes required to govern the efficient operation of the single window must be addressed, regardless of the technology solution selected to implement it. In particular, consideration should be given to:

.1 administrative and business processes for a service model which embodies "report once" and the secure and efficient distribution and reuse of data;

.2 the legal and regulatory environment required to support such a service model; and

.3 the data privacy provisions that govern each partyʹs access to information in the MSW.

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 19

Finally, the technology which may be implemented to enable the single window processes to function as efficiently as possible has to be considered.

The general methodology for normal system implementation is shown in figure 6. (Note: this is a general methodology, it does not exclude other methods).

An MSW is a complex entity and will need a professional approach to software development. The responsible party needs to make sure that it has the necessary expertise in house, or search for assistance externally.

The following subsections describe the recommended methodologies to implement a single window from a technical perspective.

Figure 6 – General methodology for normal system implementation

Project plan Analysing Design Implementation/Test Operating/Maintenance

Preliminary Service/System Service/System AS-IS analysis Service design Investigation implementation operating

Setup project TO-BE Service/System System design Testing/Evaluation plan analysis maintenance

GAP analysis Migration

6.2 Key performance indicators

In order to evaluate the extent to which an MSW achieves its objectives as outlined in section 5.1, the way in which it is implemented and operated should be assessed using key performance indicators based on the characteristics for a single window environment, provided in section 8.

The key performance indicators in conjunction with the characteristics should be used to access the development (see section 5), implementation (see section 6) and performance of the MSW in achieving those objectives outlined in section 5.1. Additionally, it should be used as part of the process of identifying an appropriate MSW from those described in annex A for adoption and implementation.

6.3 Outline of system architecture

There are several components with different requirements, from top to bottom as shown in figure 7, and from left to right as shown in figure 8:

.1 The business users (agents, shipowners, ship crew) that input to the SW should as far as possible use international standards for protocols and data format.

.2 However, one should expect different transmission paths, e.g. machine to machine or Internet and Internet-based mechanisms.

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 20

.3 There is a database and some business/event logic in the middle. This has to be adapted in international requirements based on item 1 users, and local requirements based on the actual administration users (to the right in figure 8, and at the bottom in figure 7).

.4 The next step is to provide logic and filters for local users (not everyone will have access to all data).

.5 Outputs are, as for business users, possibly different amongst the different administrations. It may be more difficult to find international standards in this area as the interfaces typically are based on local and national legislation.

.6 Notifications from administration users to business users such as permission are transmitted from bottom to top as shown in figure 7 and from right to left as shown in figure 8. Note that communication with ships may require special provisions, e.g. due to limited connectivity and bandwidth or security measures blocking incoming data to the ship.

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 21

Figure 7 – Image of system architecture

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 22

Figure 8 – Image of system architecture

O/P Agent A 1 Port authority Agent B O/P Coast guard 2 Agent C Event handling Event O/P Custom 3 Ship master A Maritime O/P administration

Ship master B 4

I/Petc.) GUI(M2M,

Data Input logic Inputlogic / Data Filter Data Output logic Output logic Filter / Data Data Base Data O/P Other Ship master C 5 administration

6.4 Data harmonization

This is achieved by initiating developments in the areas of process analysis, best practices and international trade procedures. Where appropriate, the UN/CEFACT Modelling Methodology (UMM) is used to support the development of trade facilitation and electronic business solutions. The UN/CEFACT Library Maintenance Team is responsible for consistency and harmonization of data (core components) across business domains and sectors, contributing to a concise and well-defined glossary of business terms and business data semantic definitions and to the structuring of data exchanges.

An important part of the single window design is to harmonize the representation of data between the different authorities and users of the single window. This is discussed in the WCO Data Model on Single Window Data Harmonization (WCO Data Model).

6.5 Data elements

The Compendium on Facilitation and Electronic Business (FAL.5/Circ.40, as amended) serves as a reference manual for creating the systems needed to support transmission, receipt and response of information required for the arrival, stay and departure of ships, persons and cargo through ports using electronic data interchange (EDI) messaging. It contains the table which shows the Organization's definitions for the recommended data elements in the arrival, stay and departure reports described in the FAL Convention and for the required data elements when reporting security-related information under SOLAS regulation XI-2/9.2.2 and MSC.1/Circ.1305.

6.6 Data entry into single window

Normally it is necessary to consider different ways for data to be entered into the system. These methods should cater for different users' requirements and possibilities for entering data. Some common methods are:

.1 Machine to machine interface:

A preferred solution allowing IT systems of the relevant stakeholder onboard and/or on shore to automatically send and receive, through a secure connection, electronic information regarding a shipʹs arrival to a port. This could be done via a web service or any of numerous other technical ways.

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 23

.2 Graphical user interface (GUI):

GUI is the main alternative to machine to machine communication and a common approach when automatic submission is not possible from an economic or operational perspective. It always involves a person entering information. GUI is useful for the reporting of vessels that only call at a port occasionally, whose reporting requirements are modest and where the pattern of ad-hoc worldwide trading precludes the owner or operator investing in an automatic system.

6.7 Tools to aid users' data entry

For EDI interfaces, it is also necessary to consider how the users format their EDI file. In most automated systems, the EDI formatting is done by the local administrative systems and sent more or less automatically to the single window. However, it is also possible to provide data-entry tools that allow the user to enter data manually and generate an EDI file for deposit through email or directly through the Internet.

Data-entry tools can be stand-alone applications or can be implemented with the help of HTML forms, Adobe PDF or Microsoft Excel workbooks, for example. The benefit of the latter variants is that they do not require installation of any special software on board the ship or on the user's premises.

6.8 Non-functional requirements

During the implementation phase, one has to consider various "non-functional" requirements that limit the implementation selections quite substantially. The typical problem is establishing the degree to which one can expect the prospective users to actually make use of the new technological solutions provided. This is obviously a critical issue regarding the final adoption of the proposed technical solutions.

6.9 Cyber security

In order to respond to the growing cyber threats, cyber security technologies have become essential to the operation and management of an MSW. The management of cyber risk should be done in accordance with international standards and best practices including the Guidelines on maritime cyber risk management (MSC-FAL.1/Circ.3), which provides high-level recommendations for maritime cyber risk management.

7 Interoperability

Based on the UNECE Recommendation No.36, there are four levels of technical interoperability: the methodology for dataset creation, datasets, business processes and messaging. When data interchange of electronic messages between electronic systems is implemented, there are two key elements: communication protocol (e.g. HTTPS, FTPS and SMTP), and data format, which allows for syntax rules, format, code of messages and data code. Both should be decided through discussion with related stakeholders. The FAL Compendium identifies data format standards that can be used to implement system collaboration of an MSW and promote interoperability. Another important aspect of interoperability is ensuring legally significant trusted trans-boundary electronic interaction of documents between stakeholders from different jurisdictions.

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 24

7.1 UN/EDIFACT and FAL Compendium

There are multiple international data standards in use in maritime trade. UN/EDIFACT messages are by far the most widely used at the time of writing, however XML and other formats are also now in use, particularly in administrations. The main reference for use of UN/EDIFACT should be the FAL Compendium, which contains a comprehensive discussion of the relevant UN/EDIFACT standards.

7.2 Extensible Markup Language (XML)

Most new developments within the area of electronic messaging are based on the use of eXtensible Markup Language (XML). XML is a relatively simple system for electronic data interchange with extensive support in common office automation tools and off-the-shelf or public-domain computer software.

However, the relative ease with which new variants of XML can be created has led to a large number of different and partly competing standards. This also applies to ship clearance, although the use of XML for this purpose is not widely implemented. Some relatively well known examples are: PortNet in Finland; the (Electronic Notice of Arrival/Departure (eNOA/D) system by the United States Coast Guard (http://www.nvmc.uscg.gov/); and SafeSeaNet in Europe (http://www.emsa.europa.eu/).

At the time of writing, none of the XML messages can be identified as a likely emerging de-facto standard for ship clearance, although these are the applicable de-jour standards for ship clearance such as ISO 28005 series and 15000 series.

8 Characteristics

An MSW which conforms to the objectives for setting up a single window in maritime transport, as outlined in paragraph 5.1, should be established with at least the following characteristics:

.1 demonstrates conformity with FAL Standard 1.6 that public authorities should limit the information they require from shipowners and other parties concerned to that required by the FAL Convention;

.2 notwithstanding paragraph 8.3.1 below, demonstrates that where additional information may be required to eliminate duplication of reporting requirements by public authorities, ports (including PCS) and other stakeholders, this information is part of a single, standardized reporting procedure and format. In this regard, the single window incorporates the recommended practice in FAL Standard 1.3quin, in particular:

.1 the extent of the reporting requirements is defined in an agreed maximum harmonized list of data reporting requirements, which is valid in every port and meets the needs of all public authorities, ports (including PCS) and other stakeholders;

.2 the harmonized maximum list of data reporting requirements should be periodically reviewed to ensure that it represents the absolute minimum reporting requirement that can be achieved;

.3 the maximum list of data reporting requirements determines the content of the standardized single window reporting format;

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 25

.4 in conformance with the principle of reuse of submitted information, there should be no need for additional information to be provided by the ship, shipowner, operator or agent acting on their behalf to any other national or local reporting system; and

.5 measures should be in place for amending reporting procedures, data structures and formats. This should include notification of changes, including systems requirements, to the shipping industry well in advance of the changes becoming effective. This would be in accordance with FAL Standard 1.3ter;

.3 has a reporting procedure and format which embodies "report once" reporting, particularly for shipping companies and ships. It should use a centralized information management system that:

.1 ships and companies report to (one-to-many) and receive communications regarding decisions and other information from public authorities, ports (including PCS) and other stakeholders. Ships should not be required to report more than once for multiple port calls within the same country unless there has been a change to the shipʹs reportable circumstances;

.2 all public authorities, ports (including PCS) and other stakeholders receive reports from, reuse and transmit communications regarding decisions and other information; and

.3 ships should not be required to submit to public authorities any information that is produced by another public authority;

.4 reflects the relevant UN Recommendations;

.5 does not make it possible for any stakeholder to implement a reporting procedure or format which runs in parallel to, or duplicates, any element of the single window;

.6 demonstrates that it:

.1 is technology neutral and capable of evolving with technological developments which may further enhance the efficiency of maritime trade;

.2 is provided with a robust means of ensuring ships and companies can determine the extent to which information, particularly sensitive information and information not required by the FAL Convention, is shared through the single window;

.3 incorporates information security measures, taking into account international standards, national legislation and guidance on information and cyber security;

.4 incorporates back-up arrangements to ensure that any failure or malfunction of the single window does not prevent ships from efficiently reporting or hinder clearance processes; and

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 26

.5 is capable of being interoperable with other single windows, internationally, in the future by avoiding reliance on proprietary data models.

9 Operation and Maintenance

An MSW is required to accept online applications from the private sector 24 hours a day, seven days a week. In other words, public authorities managing an MSW are required to ensure stable operation at all times. Thus, it is necessary for public authorities to deploy technical staff to organize the daily operation team and deal with system failures that occur as well as to appropriately monitor and maintain their MSW (See annex D).

10 References

 Boertien, N. et al., Blueprint for a virtual port, an integrated view on next generation Internet in the Port of Rotterdam. Virtuele Haven Consortium, 7 June, 2002.

 Directive 2010/65/EU of the European Parliament and of the Council of 20 October 2010 on reporting formalities for ships arriving in and/or departing from ports of the Member States and repealing Directive 2002/6/EC.

 IMO Convention on Facilitation of International Maritime Traffic (FAL Convention), 1965.

 IMO Compendium on Facilitation and Electronic Business, FAL.5/Circ.40, as amended.

 Revised Kyoto Convention on the Simplification and Harmonization of Customs Procedures, WCO, 2006.

 UNECE Recommendation No.33, Recommendation and Guidelines on Establishing a Single Window.

 UNECE Recommendation No.35, Establishing a Legal Framework for International Trade Single Window.

 UNECE Recommendation No.36, Single Window Interoperability.

 UNECE Technical Note on Terminology for Single Window and other electronic platforms.

 WCO Data Model — Single Window Data Harmonization, WCO, 2015.

 WCO SAFE Framework of Standards, June 2007.

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 27

ANNEX A: MARITIME SINGLE WINDOW EXAMPLES

Annex A contains MSW examples and other related single windows that are not MSW. These examples could be used to assist IMO Member States that do not yet have an MSW in establishing one. The examples provide experience and knowledge of how some Member States have approached the implementation of an MSW and provides those looking to create an MSW with a source of information, advice and guidance.

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 28

ANNEX A.1

FINLAND

1 Name of system

Portnet

2 Introduction

.1 Purpose

Fulfil the requirements laid down in EU legislation for setting up single window systems for maritime reporting formalities.

.2 Stakeholders involved

.1 Finnish Transport Agency

.2 Finnish Customs

.3 Finnish Border Guard

.4 Finnish Ports

.5 Port information providers

.3 Legal framework

.1 Directives 2010/10/EU, 2002/59/EC (as amended), 2009/16/EC; and

.2 Vessel Traffic Service Act (623/2005), Act on Fairway Dues (1122/2005), Customs Act (304/2016).

.4 Leading principles

From operational point of view, we are aiming at providing a "one-stop-shop" type of system for declarants to provide information and thus reduce the administrative burden for the maritime industry.

A leading principle is also to link all port call related information regarding ship clearance to one ship call-id. We carefully follow the sensitivity clauses laid down in EU-legislation and national legislation regarding protection of personal data and business-related data.

.5 First year of operation

2000

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 29

3 Governance

.1 Establishing body

Finnish Transport Agency and Finnish Customs

.2 Management body

Finnish Transport Agency and Finnish Customs

.3 Operating body

Finnish Customs Sea Traffic Center and Finnish Transport Agency maritime services

4 Geographic coverage of the system

Nationwide covering all seaports in Finland. About 60 ports registered to the system.

5 Type of single window (maritime, trade, other)

Maritime single window

6 Type of system user

Maritime Authorities: Finnish transport agency and Transport safety agency, Customs, Border Guard, Finnish Environment Institute.

Finnish Ports: 20 largest ports receive information via message based (XML) interface Ship Agents: They are main data providers. There are about 100 registered companies, who provide information to the system.

Ship managers: There are about 600 registered companies, who are providing information to the system.

7 Architecture of the system

Please find enclosed a very simplified chart of the system.

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 30

8 Functionalities of the system

- collect data on port calls – try to reuse data to the extent possible;

- collect fairway dues as laid down in act on faiway dues;

- collect information for maritime statistics;

- send port call information to SafeSeaNet and EU/Thetis;

- provide information for national VTS, Icebreaker network and Pilots;

- send information to Finnish Ports regarding their port traffic;

- collect passenger and crew lists as laid down in Schengen Border Code;

- collect information regarding Maritime Declaration of Health as defined in IHR; and

- collect information for Customs and Border control risk analysis.

9 Integration or collaboration with other government systems

- Finnish Ports (XML)

- SafeSeaNet/Thetis (XML)

- Customs (XML)

- Border Guard (XML)

- VTS-system (SOAP)

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 31

- Icebreaker network (SOAP)

- Pilot network (SOAP)

- Digitraffic (public timetable information for port traffic) API-interface (REST)

10 Information distribution

11 Partnership (public/private)

Initially Portnet was a public/private partnership project together with Finnish Maritime Authorities, Customs and Ports. However since 2008 Portnet has been governed only by State authorities (Finnish Transport Agency and Finnish Customs).

12 Interfaces for input, output and exchange (web, M2M (Machine to Machine)

.1 Type of user-interface

.2 Type of GUI (if any)

Portnet consists of WUI/GUI and M2M interface (www.portnet.fi).

.3 Type of applied message format(s), standard(s) or Data Model(s)

Data model is nationally tailor made not based on WCO data model; and

Portnet supports UN/EDIFACT for the following messages: CUSREP, CUSCAR, IFTDGN.

.4 Type of communication protocol (e.g. FTP(S), SMTP(S), HTTP(S) etc.)

Mainly SFTP (HTTP(S).

.5 Type of API or Webservice protocol (e.g. REST, SOAP etc.)

API, REST and SOAP are supported;

SSL encryption, 2-way SSL for external connections; and

fully doubled system platform all servers (HA proxy, application, message, database).

13 Reuse of data

To some extent regarding port calls within our own ports.

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 32

ANNEX A.2

GERMANY

1 Name of system

National Single Window (NSW) Deutschland.

2 Introduction

.1 Purpose

Reducing administrative burden for reporting obligations for ships based on FAL forms and requirements of DIRECTIVE 2010/65/EU on reporting formalities for ships arriving in and/or departing from ports of the Member States of the European community by means of the electronic data transmission.

.2 Stakeholders involved

.1 Federal Ministry of Transport

.2 Federal-, State- and local authorities

.3 Port Information Providers

.3 Legal framework

.1 Directive 2010/65/EU of the European Parliament and of the Council on reporting formalities for ships arriving in and/or departing from ports of the Member States; and

.2 National Law, ʺGesetz über das Verfahren für die elektronische Abgabe von Meldungen für Schiffe im Seeverkehr über das Zentrale Meldeportal des Bundesʺ, (Act of Parliament about the procedure for reporting by electronic means for sea going ships over the Federal National Single Window).

.4 Leading principles

Confidentiality and data protection by encryption.

The unique PortCallId is generated by the NSW core system, triggered by the shipowner or his subcontractor.

The shipowner is responsible for the distribution of the unique PortCallId to all mandated reporting parties or subcontractors.

Updating (or reset) of a notification class is only possible by using the institution where the initial notification class was reported.

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 33

.5 First year of starting operation

Since 1 May 2015

3 Governance

.1 Establishing body

Ministry of Transport

.2 Management body

Wasser und Schiffahrtsverwaltung des Bundes (Federal Water- and Shipping Authority)

.3 Operating body

Havariekommando (Emergency response Centre)

4 Geographic coverage of the system

German territorial water ways, exclusive economic zone, all ports of Germany which may be used by sea going ships, based on UNLOCODE.

5 Type of single window (maritime, trade, other)

Maritime

6 Type of system user

Governmental authorities which have by European Community-, Federal German- and/or State law (legislative acts) the right to receive information provided by the NSW.

7 Architecture of the system

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 34

8 Functionalities of the system

See picture paragraph 7

.1 German NSW supports the reuse of data were applicable;

.2 using the PCSs for notifications to the NSW, the existing business processes of the shipping industry are still in use. The reuse of data from business processes to fulfil reporting obligations to the authorities is supported; and

.3 no additional reporting to the competent authorities is necessary.

9 Integration or collaboration with other government systems

.1 Information reused in the Maritime Traffic Management System and VTSs of the Federal Water- and Shipping Authority and at the Port Management Systems;

.2 SAR Operation System; and

.3 National Maritime Emergency Response Centre in Cuxhaven.

10 Information distribution

.1 Customs

.2 Port Authorities

.3 Border Control

.4 Health Authorities

.5 PCS

.6 PSC

11 Partnership (public/private)

No

12 Interfaces for input, output, and exchange (web, M2M (Machine to Machine))

.1 Type of user-interface:

.1 Web;

.2 M2M (or System to System, S2S); and

.3 HTTP;

.2 only registered users are granted access to the web clients;

.3 Shema Validation (XSD);

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 35

.4 OTP (token generated by app);

.5 2-way SSL certificates for access to the authority;

.6 systems in the NSW infrastructure and for usage of the NSW web interface;

.7 access restriction via IP-address range for access to the authority systems in the NSW infrastructure;

.8 SSL encryption for NSW web portal; and

.9 Type of applied message format: XML.

13 Reuse of data

Yes, see 9.

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 36

ANNEX A.3

JAPAN

1 Name of system

NACCS (Nippon Automated Cargo and Port Consolidated System)

2 Introduction

.1 Purpose

For online processing of procedures taken with maritime/port authorities, customs and other relevant administrative authorities or related private-sector services for arriving/departing ships and aircraft or import/export cargo.

.2 Stakeholders involved

.1 Sea: shipping companies, agents of shipping companies, container yard operators, warehouse operators, NVOCC, customs brokers, forwarders, shipʹs stores, insurance companies, importers/exporters, vanpool operators.

.2 Air: airline companies, air cargo agents, warehouse operators, flight caterers and suppliers, customs brokers, aircraft stores, insurance companies, importers/exporters.

.3 Government agencies

.1 Port related: Ministry of Finance (Customs); vessel traffic service centers; Port management body; Ministry of Health, Labour and Welfare (Quarantine); Ministry of Justice (Immigration); port traffic control office; harbour master; District transport bureau; coast guard stations.

.2 Customs related: Ministry of Finance (Customs); Ministry of Health, Labour and Welfare (food, pharmaceuticals and medical devices); Ministry of Agriculture, Forestry and Fisheries (animal and plant quarantine); Ministry of Economy, Trade and Industry

3 Legal framework

National law (namely, Act on Processing, etc. of Business Related to Import; and export by Means of Electronic Data Processing System).

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 37

4 Leading principles

.1 NACCS has functions which quickly and accurately perform online processing of administrative procedures such as ship and aircraft arrival/departure procedures, import/export declarations and various quarantine procedures. This system allows various declarations and applications to be electronically processed paperlessly without having to go to the administrative agencies, thereby attaining efficiency of business processing in administrative agencies as well.

.2 NACCS performs various procedures such as ship and aircraft arrival/departure and import/export declaration procedures electronically. For instance, in customs clearance procedures, information sharing is attained among the users and by utilizing information recorded in previous operations. Therefore, the burden of inputting data in subsequent works is reduced and the processing time in subsequent works is shortened.

.3 NACCS functions as an information transmission system that allows users to exchange various information. Thus, there is no need for multiple users to keep in contact with one another for communication and information can be checked with NACCS.

5 First year of starting operation

.1 In 1999, Port EDI system started operation. This was an electronic application system for port arrival/departure addressed to the port management body and harbour master.

.2 In 2003, the Port EDI system and customs system (NACCS) were interconnected to enable all port-related procedures, addressed to different authorities, to be sent at one time, and then the Port EDI system was integrated into NACCS in 2008.

6 Governance

.1 Establishing body

Nippon Automated Cargo and Port Consolidated System, Inc. (Note that NACCS was established by this body; however, the maritime part, the Port EDI system, which is now integrated and consolidated to NACCS, was established by Ministry of Transport (current Ministry of Land, Infrastructure, Transport and Tourism).

.2 Management body

Nippon Automated Cargo and Port Consolidated System, Inc. (Note that NACCS is managed by this body; however, it should be noted that the maritime part, the Port EDI system, used to be managed by the Ministry of Transport (current Ministry of Land, Infrastructure, Transport and Tourism).

.3 Operating body

Nippon Automated Cargo and Port Consolidated System, Inc.

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 38

.4 Geographic coverage of the system nationwide

Type of single window (maritime, trade, other). Ship and aircraft arrival/ departure procedures and import/export declarations.

7 Type of system user

NACCS users are as follows:

.1 sea: Shipping companies, agent of shipping companies, container yard operators, Warehouse operators, NVOCC, customs brokers, forwarders, Shipʹs stores, insurance companies, importers/exporters, vanpool operators;

.2 air: airline companies, air cargo agents, warehouse operators, flight caterers and suppliers, customs brokers, aircraft stores, insurance companies, importers/exporters;

.3 Government agencies

.1 port related Ministry of Finance (Customs); vessel traffic service centres; Port management body; Ministry of Health, Labour and Welfare (Quarantine); Ministry of Justice (Immigration); Port traffic control office; harbour master; district transport bureau; coast guard stations; and

.2 custom related Ministry of Finance (Customs); Ministry of Health, Labour and Welfare (food, pharmaceuticals and medical devices); Ministry of Agriculture, Forestry and Fisheries (animal and plant quarantine); Ministry of Economy, Trade and Industry.

8 Architecture of the system

Private users NACCS Government Acceptance of Submission of agencies declaration declaration (Customs procedure, MOF - Customs） Selectivity (Port procedure, MLIT) (Air/Sea, Quarantine (for human), MHLW)

(Air/Sea, Immigration procedure, MOJ) Inquiry of Permission (Trade Control, METI) Cargo info. (Food hygiene, MHLW) (Pharmaceutical Affairs, MHLW) Inquiry of (Animal Quarantine, MAFF) Cargo info. (Plant Quarantine, MAFF)

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 39

9 Functionalities of the system

Shipping Sea-cargo Air-cargo Airline company company Submitting entry/departure notice, Submitting entry/departure notice, Manifest and Passenger List Shipping Air cargo Manifest and Passenger List Agent agent NACCS NVOCC Flight caterer CI & supplier CI CI Shipping CI broker Consolidator CI and Notice of permission Container yard CI & Notice of permission operator Warehouse CI and Notice of permission operator Import/Export Declaration Warehouse Declaration/Notification Import/Export Declaration operator & Notice of permission & Notice of permission Customs broker Information related Information related Customs business business broker Settlement Importer Settlement /Exporter Importer Bank Bank MOJ,MOF (Customs), /Exporter MHLW, MAFF, MLIT, METI etc. *CI (Cargo Information)

.1 Integration or collaboration with other government systems

As answered in No.7

.2 Information distribution

NACCS is an application system and deliver application information addressed to each administrative agency such as customs, harbour master, port management body and immigration.

.3 Partnership (public/private)

Data Processing Operation Council (Air Special Committee and Sea Special Committee) and working groups.

10 Interfaces for input, output and exchange (web, M2M (Machine to Machine))

.1 Type of user-interface (e.g. web, desktop application, and/or M2M (or System to System, S2S))

Web, desktop application, S2S

.2 Type of GUI (if any)

.3 Type of applied message format(s), standard(s) or Data Model(s) (e.g. UN/EDIFACT, WCO Data Model etc.)

NACCS EDI message, MIME, XML; EDIFACT and ebMS

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 40

.4 Type of communication protocol (e.g. FTP(S), SMTP(S), HTTP(S) etc.)

HTTP (S), SMTP/POP3, FTP

.5 Type of API or Webservice protocol (e.g. REST, SOAP etc.)

Webservice protocol; HTTPS

11 Reuse of data

Yes

Currently, the following two functions are provided:

.1 reloading of previous submission data for creating new submissions; and

.2 reuse of data of previous procedures of the same cargo to next procedures, including the customs duty payment.

In addition to the above, a data exporting function is available for data reuse in other systems.

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 41

ANNEX A.4

MARSHALL ISLANDS

1 Name of system:

Maritime single window

2 Introduction

.1 Purpose

The port of Majuro in the Republic of the Marshall Islands (RMI) is not complex and handles a very small amount of commercial traffic yearly, as far as scale is concerned. RMI is of the view that as IMO develops an agreed maritime single window (MSW), the rules and procedures will be flexible in its implementation, thus taking into consideration the varying low levels of trade in small island developing States such as RMI, where the MSW systems costs are a major factor. If it appears that IMO may not develop or insert a flexibility clause into a future agreed MSW, RMI proposes that a low- cost, less complex software solution could be created in partnership with similar Contracting Governments which face similar situations.

.2 Stakeholders involved

Visiting vessels, local shipping agent and government agencies (Ports Authority, Immigration, Customs, Quarantine, EPA).

.3 Legal framework

None yet

.4 Leading principles

Ministry of Transportation and Communication – Secretary of T&C RMI Ports Authority

.5 First year of starting operation

Not yet operated – Design and conceptualization stage, before production and then operation.

3 Governance

.1 Establishing body

Ministry of Transport and Communications

.2 Management body

Ministry of Transportation and Communication – Secretary

RMI Ports Authority

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 42

.3 Operating body

Ministry of Transportation and Communication – Secretary

RMI Ports Authority

4 Geographic coverage of the system

Nationwide, which corresponds in practice in the RMI to the only port of commerce with commercial traffic (port of Majuro).

5 Type of single window (maritime, trade, other)

Maritime and trade

6 Type of system user

.1 vessels calling to and departing from port of Majuro;

.2 local shipping agents; and

.3 RMI Governmental agencies: RMI ports Authority, Immigrations, Customs, Quarantine, EPA.

7 Architecture of the system

Design stage

8 Functionalities of the system

Design stage

9 Integration or collaboration with other government systems

N/A

10 Information distribution

Expected

11 Partnership (public/private)

One system envisaged, operated by Government working with private sector

12 Interfaces for input, output, and exchange (web, M2M (Machine to Machine))

Design stage

13 Reuse of data

Expected

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 43

ANNEX A.5

REPIBLIC OF KOREA

1 Name of system

Port-MIS

2 Introduction

.1 Purpose

It is an information system that has online processed all administrative tasks related to ship transfer and cargo carry-in/out that occurs at ports, and it connects national ports to one single network to realize non-visit civil petition administration anytime anywhere around the clock such as dealing with civil petitions using EDI, Internet and mobile.

.2 Stakeholders involved

Shipping Company/Agency Terminal Operation Company, Shipper/Forwarder, Minister of Maritime Affairs and Fisheries, Regional Maritime Affairs and Fisheries Office, Ministry of Justice, Port Authority, Customs, Quarantine Station, Maritime Environment Management Corporation.

.3 Legal framework

Article 89 of the Harbor Act

Article 88 of the Enforcement Decree of the Port Act

Regulation on procedures for establishing, operating and using port logistics integrated information system

.4 Leading principles

In order to handle all port operations such as entrance of vessels at ports of trade, use of facilities within ports, control items, cargo handling, collection of revenue, departure of ships, a petition application must be made through wired/wireless Internet network and port logistics information relay network.

.5 First year of starting operation:

Since 1995

3 Governance

.1 Establishing body

Minister of Maritime Affairs and Fisheries

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 44

.2 Management body

Minister of Maritime Affairs and Fisheries

.3 Operating body

Minister of Maritime Affairs and Fisheries.

Korea Logistics Network Company is in charge of system operation.

4 Geographic coverage of the system

It is responsible for all trade ports in Republic of Korea

5 Type of single window (maritime, trade, other)

A system that handles all port operations such as loading and unloading of dangerous goods, inbound and outbound ports for trading, and using facilities in port, control issues, cargo handling, tax collection and others.

6 Type of system user

Refer to 2.2

7 Architecture of the system

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 45

8 Functionalities of the system

Refer to 7

9 Integration or collaboration with other government systems

It is a system constructed to get each piece of information easily by providing shipping-port-Distribution field related people with ubiquitous Distribution information by gathering/integrating to one place through the Internet, and realizes task efficiency through JIT provision of shipping-Distribution information and pursuing convenient uses.

10 Information distribution

Refer to 9

11 Partnership (public/private)

No

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 46

12 Interfaces for input, output, and exchange (web, M2M (Machine to Machine))

.1 Type of user-interface (e.g. web, desktop application, or/and M2M (or System to System, S2S))

Web service

• Constructing Service Platform Based on Electronic Government Standard Framework.

• Constructing Association Standard Interface Platform that has considered Open, Share, Communicate, Collaborate.

OpenAPI Service for Convenient Information Usage of Shipping and port logistics Information Center.

.2 Type of GUI (if any)

.3 Type of applied message format(s), standard(s) or Data Model(s) (e.g. UN/EDIFACT, WCO Data Model etc.)

EDI(UN/EDIFACT), ebXML(UN/CEFACT), JSON, XML

.4 Type of communication protocol (e.g. FTP(S), SMTP(S), HTTP(S) etc.)

HTTP protocol is used by default. It is an ESB-based system, all protocols supported by ESB are available. (WSDL, SOAP, REST, etc.)

.5 Type of API or Webservice protocol (e.g. REST, SOAP etc.)

13 Reuse of data

Refer to 9

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 47

ANNEX A.6

SPAIN

1 Name of system

DUEPORT

2 Introduction

.1 Purpose

.1 simplify and harmonize the administrative procedures applicable to maritime transport through the generalization of the electronic data transmission;

.2 declarants can report electronically the administrative formalities linked to the arrival, stay on, and departure of a Spanish maritime port; and

.3 be the point at which all information is reported only once and is made available to the Spanish competent authorities, other European Union Member States and EMSA (European Maritime Safety Agency).

.2 Stakeholders involved

.1 Declarant:

Shipping companies

Maritime Agents

.2 Reporting Parties:

Port Community Systems PCS

IT Solution Providers

.3 Authorities:

Custom – Agencia Estatal de Administración Tributaria AEAT-Aduanas

Maritime Administration – Dirección General Marina Mercante y Capitanías Marítimas

Search and Rescue – SASEMAR

Border Control – Policía Nacional

Health Authority – Subdirección General de Sanidad Exterior

Coast and Port Security (Civil Guard) – Guardia Civil

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 48

Defence – Spanish Navy/Ministry of Defence

EMSA-SafeSeaNet

Port Authorities (local access to NSW)

Puertos del Estado (development, maintenance, operation, user support)

3 Legal framework

Directive 2010/65/EU of the European Parliament and of the Council of 20 October 2010 on reporting formalities for ships arriving in and/or departing from ports of the Member States and repealing Directive 2002/6/EC.

Real Decreto 1334/2012.de 21 de diciembre, sobre formalidades exigibles a buques mercantes que lleguen a puertos españoles o salgan de estos.

Orden FOM/1194/2011, de 29 de abril, por la que se regula el procedimiento integrado de escala de buques en puertos de interés general.

4 Leading principles

.1 Only support the data required under the legislation. Data Set has been established based on reporting formalities.

.2 The scope of reporting formalities for customs include Summary Declaration of Temporary Storage and Cargo Manifest.

.3 The Maritime Single Window will enable single reporting of data for use by multiple authorities.

.4 Different messages for different reporting formalities.

.5 A ShipCallID as a unique identifier for a vessel call so as to facilitate data exchange between stakeholders.

.6 Based on EDIFACT and XML messages.

.7 MSW will send a technical receipt confirmation for each received message.

.8 The reporting channel can be a port system (e.g. PCS) or dedicated system so long as they support the reporting formality and the established interface of the maritime single window.

.9 MSW directly connected to competent national authorities.

.10 Replace mechanism.

.11 Only the original declarant/reporting party can replace data or cancel a declaration from the MSW and according the mechanisms given.

.12 Messages processed in the order they are sent. Only the last received data will be stored.

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 49

.13 The validation by the maritime single window is for processing the message for further transmission and will not be affected by a rejection from a receiving system.

.14 The MSW is not the place where checks on timeliness will be conducted (LP26).

.15 The maritime single window is not the place where checks on the completeness of the reporting formalities will be conducted.

.16 Data and Times reported in local time indicator.

5 First year of starting operation

Actual system in 2015.

First single window system with Customs in 1994.

First single window system with Maritime Administration in 2000.

6 Governance

.1 Establishing body

NMSW developed by Puertos del Estado.

Port authorities and PCS as local point of access to National Maritime Local Window.

.2 Management body

Puertos del Estado

.3 Operating body

Puertos del Estado

7 Geographic coverage of the system

Nationwide

8 Type of single window (maritime, trade, other)

Maritime

9 Type of system user

.1 Business side:

.1 Ship agents

.2 Shipping companies

.3 Captains of vessels

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 50

.2 Authority side:

.1 Custom – Agencia Estatal de Administración Tributaria AEAT-Aduanas

.2 Maritime Administration – Dirección General Marina Mercante y

.3 Capitanías Marítimas

.4 Search and Rescue – SASEMAR

.5 Border Control – Policía Nacional

.6 Health Authority – Subdirección General de Sanidad Exterior

.7 Coast and Port Security (Civil Guard) – Guardia Civil

.8 Defence – Spanish Navy/Ministry of Defence

.9 EMSA – SafeSeaNet

10 Architecture of the system

Spanish National Maritime Single Window Architecture

Web Apps HTTPS Tier Java Server AJAX/JavaScript Faces

Model View Facelets Controller

Business Tier Proxy Access Edifact

Presentation

HTTPS XML/

EJB EJB Enterprise Apps Message Broker App

Access Control Web Services Transformation Message Interceptors JMS Queues Structure

Translation Validation Tier

Alert Manager Receive Queue XML/Edifact Message Scheduler Audit Send Queue

Distribution Business Persistence Framework

Entities Object Relation Mapper Entity Validation Integrity Assurance JDBC Driver

Oracle Data Base Management System

Tier Data

11 Functionalities of the system

.1 Request

.2 Report

.3 Acknowledge

.4 Feedback (Maritime Administration)

.5 Clearance (Maritime Administration)

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 51

12 Integration or collaboration with other government systems

13 Information distribution

.1 Custom – Agencia Estatal de Administración Tributaria AEAT-Aduanas

.2 Maritime Administration – Dirección General Marina Mercante y Capitanías Marítimas

.3 Search and Rescue – SASEMAR

.4 Border Control – Policía Nacional

.5 Health Authority – Subdirección General de Sanidad Exterior

.6 Coast and Port Security (Civil Guard) – Guardia Civil

.7 Defence – Spanish Navy / Ministry of Defence

.8 EMSA-SafeSeaNet

14 Partnership (public/private)

We periodically tender development, maintenance and user support services.

15 Interfaces for input, output, and exchange (web, M2M (Machine to Machine))

.1 Type of user-interface (e.g. web, desktop application and/or M2M (or System to System, S2S))

.1 M2M based on EDIFACT messages. Maritime Declaration of Health based on XML message.

.2 Graphical User Interface GUI

.3 Spreadsheets for Passenger and Crew Lists

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 52

.2 Type of GUI (if any)

.3 Type of applied message format(s), standard(s) or Data Model(s) (e.g. UN/EDIFACT, WCO Data Model etc.)

.4 Type of communication protocol (e.g. FTP(S), SMTP(S), HTTP(S) etc.)

.5 Type of API or Webservice protocol (e.g. REST, SOAP etc.)

16 Reuse of data

Reuse of data not possible yet. We are defining with port authorities the preferred option to reuse data between Spanish ports (voyages between Spanish ports).

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 53

ANNEX A.7

SWEDEN

1 Name of system

Reportal (The Swedish Maritime Single Window)

2 Introduction

.1 Purpose

Reportal aims at fulfilling the EU directive 2010/65 and have integrated all the reporting formalities stated there. Reportal is also used for ordering Pilots and handling Fairway dues. In Sweden Reportal also has a connection to ports where information regarding a specific port call is forwarded to the port. Reportal aims to simplify the task of reporting maritime travel not only by unifying the existing systems, but also by taking big steps in removing redundant and/or outdated information in the reporting process.

.2 Stakeholders involved

.1 Swedish Maritime Administration

.2 Swedish Coast Guard

.3 Swedish Customs

.4 Swedish Transport Agency

.5 Swedish Ports

.6 Reporting Party (Shipowners, Agents and so on)

.3 Legal framework

.1 Directive 2010/65 (EU)

.2 National laws

.4 Leading principles

.1 Responsive and easy to use

.2 Require the data needed for the port call not more

.3 Use of reference data

.4 Secure and keep confidentiality

.5 Use of WCO data model

.6 "Post office" system, data is stored in the receiving administration's systems

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 54

.5 First year of starting operation

2015

3 Governance

.1 Establishing body

Swedish Maritime Administration

.2 Management body

Swedish Maritime Administration (in cooperation with governmental stakeholders)

.3 Operating body

Swedish Maritime Administration

4 Geographic coverage of the system

Sweden

5 Type of single window (maritime, trade, other)

Maritime including customs and border control regulations

6 Type of system user

.1 Ship agents

.2 Crew on board a vessel

.3 Shipowner

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 55

7 Architecture of the system

The first picture describes the flow of the system and the connected Administrations. The second picture shows the implementation in more detail and how the different system components are connected.

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 56

8 Functionalities of the system

.1 Portal integration

.2 Graphical User Interface

.3 Machine-to-machine

.4 Upload of spreadsheet for bulky data

.5 Integration platform

.6 Clearance functions

9 Integration or collaboration with other government systems

See architecture and stakeholder involved

10 Information distribution

Yes, see previous answers. Reportal works like a post office for the connected Administrations.

11 Partnership (public/private)

Public

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 57

12 Interfaces for input, output, and exchange (web, M2M (Machine to Machine))

.1 Type of user-interface

GUI and M2M

.2 Type of GUI

Web-based

.3 Type of applied message format(s), standard(s) or Data Model

WCO

.4 Type of communication protocol

FTP(S), HTTP(S)

.5 Type of API or Web service protocol

SOAP

13 Reuse of data

Yes, the general port call data reported is used for all connected Administrations.

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 58

ANNEX A.8

UKRAINE

1 Name of system

Maritime single window – MSW (Морське Єдине Вікно – МЄВ)

2 Introduction

.1 Purpose

MSW is an information telecommunication system in the form of a software and hardware complex of information subsystems that provides an environment for collecting, distributing and exchanging information about ships with a well-ordered and commonly defined data structure, rules and access rights management in accordance with the current requirements of international and national legislation, and customized interaction at the level of system-system for transparent organization of mutual access of users in accordance with applicable regulations, technological schemes and access rights and comply with requirements on electronic document management.

.2 Stakeholders involved

Authorities:

- SE "Ukrainian Sea Ports Authority"

- Fiscal Service of Ukraine

- Border Control of Ukraine

- Sanitary Service of Ukraine

- Phytosanitary Service of Ukraine

- Authority of railway transport of Ukraine

Parties:

- Maritime Agents

- Container Line Agents

- Forwarders

- Terminal Operators

- Transport Companies

- Port Community Systems

- Service Providers

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 59

.3 Legal framework

Resolution of the Cabinet of Ministers of Ukraine dated 21 May 2012 No.451 "Issues of passing through the state border of persons, road, water, rail and air transport carriers and goods moved by them".

.4 Leading principles

Single providing of information in legally trusted form in one place to simplify formalities of passing through the state border persons, road, water, rail and air transport carriers and goods moved by them.

.5 First year of starting operation

In production, in present time functionality is provided by PCS ʺISPSʺ.

3 Governance

.1 Establishing body

SE "Ukrainian Sea Ports Authority", Maritime Authority of Ukraine

.2 Management body

SE "Ukrainian Sea Ports Authority", Maritime Authority of Ukraine

.3 Operating body

SE "Ukrainian Sea Ports Authority", Maritime Authority of Ukraine (in future), now – service provider "PPL 33-35" JSC

4 Geographic coverage of the system

Sea ports nationwide

5 Type of single window (maritime, trade, other)

Maritime

6 Type of system user

.1 Maritime agents

.2 Container line agents

.3 Forwarders

.4 Terminal operators

.5 Transport companies

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 60

7 Architecture of the system

Figure 1 - General architecture

Figure 2 – Simplified messaging process

8 Functionalities of the system

.1 Vessel operation

.1 Voyage planning

.2 NOA/NOD

.3 Actual Arrival Acknowledgment

.4 Actual Departure Acknowledgment

.5 Port Clearance

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 61

.2 Cargo operation

.1 Preliminary information for Customs risk management

.2 Actual arriving

.3 Actual departure

.4 Cargo clearance

.3 Port and terminal operation

.1 Border and gateway movement

.2 Transport planning and operation

.3 Service planning and execution

.4 Exchange of legally trusted information between port community members

9 Integration or collaboration with other government systems

The PCS (and MSW in future) is integrated with Customs (trade) single window, with IT solution of national railways and with operational systems of port terminals.

10 Information distribution

.1 Customs

.2 Ports authorities

.3 Border control

.4 National police

.5 National security

11 Partnership (public/private)

Present PCS is a fully private product that is provided to government operation free of charge.

12 Interfaces for input, output, and exchange (web, M2M (Machine to Machine)

.1 Type of user-interface:

.1 Web

.2 Desktop application

.3 System to System

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 62

.2 Type of GUI:

.1 Web

.2 Windows-based

.3 Type of applied message format(s)

XML

.4 Standard(s) or Data Model(s)

ISO 28005-based with national extensions

.5 Type of communication protocol

HTTP(S)

.6 Type of API or Webservice protocol:

REST-based messaging with two-level DES encryption

13 Reuse of data

All information in the system can be accessible and reused with strict regulations from business process owners.

***

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 63

ANNEX B: LIST OF APPLICABLE STANDARDS

1 IMO: Facilitation Committee (FAL)

The IMO Facilitation Committee is working together with Member States to ensure that ships transit from port to port without unnecessary delays by simplifying and reducing paper work and formalities during their stay and departure on international voyages. More information can be found at: http://www.imo.org/en/OurWork/Facilitation/FALCommittee/Pages/default.aspx

2 World Health Organization (WHO)

WHO issues the international health regulations (IHR), more information can be found at: http://www.who.int/en/

3 World Customs Organization (WCO)

The World Customs Organization (WCO), established in 1952 as the Customs Cooperation Council (CCC) is an independent intergovernmental body whose mission is to enhance the effectiveness and efficiency of Customs administrations. More information can be found at: http://www.wcoomd.org/en.aspx

Also, WCO has developed the WCO DATA Model, which is a set of carefully combined data requirements that are mutually supportive and which will be updated on a regular basis to meet the procedural and legal needs of cross-border regulatory agencies such as customs, controlling export, import and transit transactions. More information can be found at: http://www.wcoomd.org/Topics/Facilitation/Instrument%20and%20Tools/Tools/Data%20Model

Furthermore, WCO has developed the WCO Compendium which describes how to build a single window environment. More information can be found at: http://tfig.unece.org/contents/wco-single-window-compendium.htm

4 World Trade Organization (WTO)

The World Trade Organization (WTO) is the only global international organization dealing with the rules of trade between nations. At its heart are the WTO agreements, negotiated and signed by the bulk of the worldʹs trading nations and ratified in their parliaments. The goal is to ensure that trade flows as smoothly, predictably and freely as possible.* More information can be found at: https://www.wto.org/index.htm

5 United Nations Economic Commission for Europe (UNECE)

The United Nations Economic Commission for Europe (UNECE) administers, among others, the Inland Transport Committee, which is responsible, among others, for the Customs Convention on the International Transport of Goods under Cover of TIR Carnets (TIR Convention) and the International Convention on the Harmonization of Frontier Controls of Goods.

* Also, traders from both developing and developed countries have frequently highlighted the vast amount of "red tape" that exists in moving goods across borders. To address this, WTO members have forged the Trade Facilitation Agreement (TFA), which came into force on 22 February 2017. More information can be found at: https://www.wto.org/english/tratop_e/tradfa_e/tradfa_e.htm#III

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 64

The UNECE also hosts the United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT) which maintains and publishes recommendations and standards reflecting best practices in trade and transport procedures, related data and documentary requirements. More information can be found at http://www.unece.org/info/ece-homepage.html, also http://www.unece.org/cefact.html and http://www.unece.org/trans/welcome.html Especially, UNECE provides the Trade Facilitation Implementation Guide, which is a tool for simplifying cross-border trade. More information can be found at: http://tfig.unece.org/index.html

6 United Nations Conference on Trade and Development (UNCTAD)

Established in 1964, UNCTAD aims at the development-friendly integration of developing countries into the world economy.

UNCTAD is the focal point within the United Nations for the integrated treatment of trade and development and interrelated issues in the areas of finance, technology, investment and sustainable development.

UNCTAD has developed a number of instruments such as the Automated System for Customs Data (AYSCUDA) to deal with customs requirements in developing countries.

More information can be found at: http://www.unctad.org/

7 United Nations Commission on International Trade Law (UNCITRAL)

UNCITRAL is the core legal body within the United Nations system in the field of international trade law. More information can be found at: http://www.uncitral.org/

8 United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT)

UN/CEFACT does not have a legislative role in international shipping, but it develops and maintains specifications that are referenced in legislation and other standards. The most relevant work for shipping is the work on UN/EDIFACT and related standards, e.g. the "Technical Note on Terminology for Single Window and other electronic platforms" which implies five key elements of the definition of a single window:

• parties involved in trade and transport;

• standardized information and documents;

• single entry point;

• fulfilling regulatory requirements; and

• single submission of individual data.

This includes a comprehensive data model covering all modes of transport: the Multi-Modal Transport Reference Data Model. This data model not only covers all the potential needs of the transport and logistics industry, but also provides links to all other sectors of the international supply chain including regulatory procedures.

More information can be found at https://www.unece.org/cefact/

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 65

9 International Organization for Standardization (ISO)

ISO is a non-governmental organization established in 1947. The mission of ISO is to promote the development of standardization and related activities worldwide with a view to facilitating the international exchange of goods and services, and to developing cooperation in the spheres of intellectual, scientific, technological and economic activity. The work of ISO results in international agreements, which are published as international standards. More information is available at: http://www.iso.org/

10 Legal issues in a single window project

When considering a SW, the legal framework and governance is critical and should be developed so that there are clear responsibilities and liabilities for the system development, maintenance and operation.

Governance between the government agencies and stakeholders is required to ensure that when legislation changes the SW can be updated without affecting the operation.

In addition there should be clear guidance on data protection and privacy of information to ensure all national, regional and international regulations are complied with.

11 PROTECT

The PROTECT Group was established by the port authorities of several major ports in north-west Europe. The Group aims to harmonize the implementation of the UN/EDIFACT standard messages for vessel reporting in the different ports (see http://www.protect- group.org/ for more information).

12 SMDG

SMDG is a non-profit foundation, run by and on behalf of companies and organizations working in the maritime industry, such as container terminals, ocean carriers and related companies and organizations. More information can be found at: http://www.smdg.org/

13 Transportation Data Coordinating Committee (TDCC) and Accredited Standards Committee (ASC X12)

TDCC devised an electronic railway bill of lading in 1975 and went on to establish a suite of electronic documents for rail, motor, ocean and air freight. Individual companies and industries began developing their own means of exchanging data, which raised the prospect of splintering and conflicting documents that created more work for the users rather than less. The result, in 1979, was the United States EDI standard, which became accredited under the American National Standards Institute (ANSI) as the ASC X12 committee. ASC X12 incorporated the work of TDCC into its standards in the early 1980s. More information can be found at: http://www.x12.org/

14 Organization for the Advancement of Structured Information Standards (OASIS) — ebXML

OASIS is a non-profit international consortium that drives the development, convergence and adoption of e-business standards.

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 66

OASIS develops XML-based standards for a wide range of applications. The most relevant is ebXML (Electronic Business Extensible Markup Language), which was started in 1999 as an initiative of OASIS and UN/CEFACT. OASIS has also published Universal Business Language (UBL). More information can be found at: https://www.oasis-open.org/

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 67

ANNEX C: TECHNICAL OUTLINE

There are some standards and technical methodologies that are or may be applicable to single window implementation for ship clearance. These are listed in the following sections. This is not an exhaustive list, but attempts have been made to include the most relevant.

However, it should be noted that at the time of writing, it is mainly UN/EDIFACT standards as listed in the FAL Compendium that are used to any great extent.

1 Basic technical methodologies

Technology develops rapidly and these guidelines do not recommend the use of any specific technical solutions. These guidelines mainly focus on use by public authorities, so that does not refer to detailed technical methods. However, the knowledge of technical methods will be helpful for public authorities when they develop an MSW with system vendors, etc.

1.1 Basic principle to be applied

1.1.1 A possible methodology is based on the underlying principles of a recently developed information technology called service-oriented architecture (SOA). SOA is a software design methodology for implementing an information system comprising interoperable, reusable services. In other words, SOA implements a distributed information system so that services can be discovered and used within multiple, separate subsystems across several business domains. Flexibility is enhanced through the loose coupling of services. Interoperability is enhanced across heterogeneous software applications by using a well-known standard for defining and accessing these services. That combination, flexibility and interoperability enables agile adaptation to rapidly changing business environments. This technical methodology covers the overall process and method for implementing a single window. It is a technical methodology for design, implementation and operation of a single window system for maritime transport business in a detailed manner.

1.1.2 This annex contains technical guidelines proposing a methodology for the design, implementation and operation of a single window system for maritime transport. Since the single window system is a software system, this methodology is based on a well-known development process. That process has five phases: planning, analysis, design, implementation, testing and delivery. These phases are shown in figure 1, which also shows the detailed tasks for each of the five phases.

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 68

Figure 1 – Single window service development and implementation methodology

Test and Plan Analysis Design Implementation Delivery

Analyse current Work and BP Service Setup Test system Analysis Definition implementing environment environment Setup system Current System Architecture Component Training development Analysis Definition Implement plan Single Window Component Interface Delivery Model Design Implement Analysis Define the Interface UI Implement requirements design

Extracts the Interface Service advanced design Implement items

1.2 Methodology deliverables

Regardless of the model chosen for development, or whether or not it is done in iterations, the following phases are the minimum for setting up a maritime single window. This matrix is shown as a template and is not to be mistaken for a full model.

No. Phase Activity Task Deliverables 1 Plan Understand system Identify relevant systems Analysis of existing systems environment Establish Team formation, division of Development plan development plan labour and development schedule 2 Analysis Analyse business Analyse current Business analysis report and business businesses Definition of business process business modelling Analyse current System analysis System analysis report system Analyse single Analysis of single window Report on the analysis of single window model model window model Analysis of best practice Report on benchmarking cases cases Define requirements Stakeholder survey Survey result Stakeholder interview Analysis report on interview Requirements specification Requirements specification Derive improvement Define future model Definition of future model measures 3 Design Define services Service specification Service specification Service design Service design Define architecture Architecture specification Architecture specification Architecture design Architecture design Database design Database design Design component Component specification Component specification Component design Component design

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 69

Design interface Interface specification Interface specification Interface design Interface design Design user User interface design User interface design interface User interface design User interface design 4 Implement Establish Define development Definition of development ation development environment environment environment Implement Implement components Components codes component Implement interface Implement interface interface codes Implement user Implement user interface User interface codes interface Implement services Implement services Services implementation codes 5 Testing Testing Prepare test cases Test cases and Conduct unit test Result of unit test operation Design combined test Combined test specification Conduct combined test Result of combined test Training Prepare user manual User manual Prepare operator manual Operator manual Train users Report on user training Train operators Report on operator training

Operation Takeover test Result of takeover test System release Report on system release

1.3 System architecture

In principle, a single window system for maritime transport business should be scalable in its structure and, to the extent possible, reusable. It should be based on analysed and applicable business processes and low-level functions as simple service components. They can be used as is or composed (assembled) into more complex services as needed. The SW system should be designed in such a way that users can access it using standard communication protocols. NSW systems should provide a harmonized interface for international data exchange with other (N)SW and systems operated by the maritime transport industry.

I:\CIRC\FAL\05\FAL.5-Circ.42.docx FAL.5/Circ.42 Annex, page 70

ANNEX D: BASIC ITEMS FOR CONSIDERATION IN THE OPERATION AND MAINTENANCE MANAGEMENT

Item Description Total Overall management and for system operation Management Operation Management of resources such as CPU and memory, scheduled Management inspection, live monitoring, security check, access log and back up etc. User Accept the application of use from users; add their user data to database; Management and issue user ID and password. Define user access rights and, if necessary, update. Data Insert regularly updated data into database (e.g. relation between ship Management name, IMO Number and call sign). Manage update history record. Security Make sure that the system is at all times updated and provide system and Management data and information protection from internal or external threats. Help Desk Respond to user queries on how to use system functions, requests for (Support desk) improvements and contact in case of system failures. for User System Failure Investigate causes of system failures that occur. If said failure was caused Management by hardware, software including OS and middleware, or network, work together with the supplier and deal with the problem. On the other hand, if it was caused by application, work together with system developer and deal with the problem. Application Bug fixing and minor modification of system. Maintenance Software Apply available software patches to keep their system up to date. Maintenance Server Ensure proper environment of server room such as room temperature and (Hardware) access control to the room. Management *Nowadays, many owners of systems do not have their own server room and tend to make use of cloud server. Network Modify network when administrative computers are added or system Maintenance configuration is changed.

______

I:\CIRC\FAL\05\FAL.5-Circ.42.docx