ics2 sti vision document trader interface... · 2020-02-28 · sti release 2: full postal and air...

ICS2 Shared Trader Interface - Vision

Sensitivity: Limited DG Issue Date: 31/10/2017 Version: 1.0.3

European Commission DIRECTORATE GENERAL

DG TAXUD


European Commission, B-1049 Brussels – Belgium, Telephone: (32-2) 299 11 11

Original Template Author: DIGIT.01.MIA – Version 2012-01

Ref. Ares(2017)5574377 - 15/11/2017



Document Control Information

Settings Value

Directorate: DG TAXUD

Project Name: ICS2 Shared Trader Interface

Document Author: CUST-DEV3

System Owner: DG TAXUD – ICS2 team

Project Manager: Bzdela Bartlomiej

Revision Status: SfR

Sensitivity: Limited DG

Issue Date: 14/11/2017

Document Approver(s):

(All Approvers are required. Records of each approver must be maintained.)

Approver Name Role

SANTOS Paulo José DG TAXUD Principal Advisor – Harmonisation and IT

Coordination

PAPAMICHALOPOULOU Lina Head of Unit B2

DE COSTER Sophie Head of Unit A3 ff

ABECASIS Margarida Head of Unit A5

THEUNISSEN Paul-Hervé Head of Unit A6

DE JAEGHER Guido ICS2 team lead

Document Reviewers: (Records of each required reviewer must be maintained.)

Reviewer Name Role

DG TAXUD ICS2 team staff STI system owner and system supplier

DG TAXUD Unit A3 staff Customs processes and Project Management

DG TAXUD Unit A5 staff Enterprise Architecture and IT operations

DG TAXUD Unit B2 staff Customs IT systems for the Union Customs Code

NOTE: All Reviewers in the list are considered required unless explicitly listed as Optional.

Summary of Changes:

The Document Author is authorized to make the following types of changes to the document without requiring

that the document be re-approved:

Editorial, formatting, and spelling;

Clarification.

To request a change to this document, contact the Document Author or Owner.

Configuration Management: Document Location

The latest version of this controlled document is stored in CIRCABC.



TABLE OF CONTENTS

1 Executive Summary ......................................................................................................... 6

2 Positioning Overview ...................................................................................................... 8

2.1 The ICS2 Harmonised Trader Interface .................................................................................. 9

2.2 Business Opportunity ............................................................................................................ 9

2.3 Problem/Opportunity Statement .......................................................................................... 9

2.4 Expected Benefits ................................................................................................................ 10

2.5 New or Updated Business Processes Proposed for Automation ......................................... 11

3 Project Scope ................................................................................................................ 15

3.1 Project Includes ("IN" Scope) ............................................................................................... 15

3.1.1 Project Activities ........................................................................................................................... 15

3.1.2 Functional Scope ........................................................................................................................... 16

3.1.3 Trader Interfaces ........................................................................................................................... 17

3.1.4 Phasing of Scope ........................................................................................................................... 17

3.1.4.1 STI release 1 - Postal and express Air pre-load .............................................................. 18

3.1.4.2 STI release 2 - Full Air (postal, express, Air cargo) .......................................................... 18

3.1.4.3 STI release 3 – Maritime, Rail and Road ......................................................................... 19

3.2 Project Excludes ("OUT" of Scope) ...................................................................................... 19

4 Project Governance and Stakeholders ........................................................................... 20

4.1 Governance ......................................................................................................................... 20

4.1.1 Member States .............................................................................................................................. 20

4.1.2 Economic Operators ...................................................................................................................... 22

4.1.3 Commission – DG TAXUD .............................................................................................................. 23

4.2 Stakeholders and Roles ....................................................................................................... 23

4.2.1 Member States .............................................................................................................................. 23

4.2.2 Commission DG TAXUD ................................................................................................................. 24

4.3 User Environment ................................................................................................................ 26

4.3.1 Economic Operators ...................................................................................................................... 26

4.3.2 Member State users ...................................................................................................................... 26

4.3.3 Commission users ......................................................................................................................... 26

5 Business Needs and Features ........................................................................................ 27

6 Alternatives and Synergies ............................................................................................ 29

6.1 Alternatives ......................................................................................................................... 29

6.2 Synergies with other projects .............................................................................................. 29

7 Project Approach .......................................................................................................... 31

7.1 Methodological Approach ................................................................................................... 31



7.2 Change management .......................................................................................................... 31

7.3 Project risks ......................................................................................................................... 32

8 Cost, Timing and Resources ........................................................................................... 35

8.1 Cost ...................................................................................................................................... 35

8.2 Timing .................................................................................................................................. 41

8.2.1 Phase 1 – ICS2 STI release 1 .......................................................................................................... 41



8.3 Planned Resources .............................................................................................................. 45

9 Information System Description .................................................................................... 46

9.1 Architectural Principles ....................................................................................................... 46

9.2 ICS2 Common specifications................................................................................................ 46

9.3 System overview .................................................................................................................. 46

9.3.1 Shared Trader Interface ................................................................................................................ 47

9.3.2 The STI Trader UI in the Generic Trader Portal ............................................................................. 48

9.3.3 The Economic Operator systems ................................................................................................... 48

9.3.4 The ICS2 Common Repository ....................................................................................................... 48

9.3.5 UUM&DS ....................................................................................................................................... 48

9.3.6 CCN2 .............................................................................................................................................. 48

9.3.7 Reference Systems ........................................................................................................................ 48

9.4 Interfaces ............................................................................................................................. 48

9.4.1 System-to-system interface with EO Systems ............................................................................... 49

9.4.2 Graphical user interface for EO ..................................................................................................... 49

9.4.3 Other interfaces ............................................................................................................................ 49

9.5 Network ............................................................................................................................... 49

9.6 Storage ................................................................................................................................ 49

9.6.1 Operational data storage .............................................................................................................. 50

9.6.2 Audit data storage ......................................................................................................................... 50

9.6.3 Archiving storage........................................................................................................................... 50

9.7 Information System Position Statement ............................................................................. 51

9.8 Dependencies ...................................................................................................................... 51

10 Constraints .................................................................................................................... 53

10.1 Legal, Regulatory Restrictions and Applicable Documents ................................................. 53

10.2 Security Constraints ............................................................................................................. 53

10.2.1 Organisational ............................................................................................................................... 53

10.2.2 Confidentiality Traceability and Accountability ............................................................................. 53

10.2.3 Integrity ......................................................................................................................................... 54



10.2.4 Availability ..................................................................................................................................... 54

10.2.5 Data Encryption ............................................................................................................................. 54

10.2.6 Access scope ................................................................................................................................. 54

10.2.7 User access management .............................................................................................................. 54

10.3 Data Protection Constraints ................................................................................................ 54

10.3.1 Data protection checklist: ............................................................................................................. 54

10.3.2 Conclusion ..................................................................................................................................... 55

10.4 Volumetric Constraints ........................................................................................................ 55

11 Quality Ranges and Information System Requirements ................................................. 56

11.1 Availability and Integrity ...................................................................................................... 56

11.2 Usability ............................................................................................................................... 57

11.3 Maintainability..................................................................................................................... 57

11.4 Applicable Standards ........................................................................................................... 57

11.5 System Requirements .......................................................................................................... 57

11.5.1 Storage .......................................................................................................................................... 57

11.5.2 Application server ......................................................................................................................... 58

11.6 Performance Requirements ................................................................................................ 58

11.6.1 Scalability ...................................................................................................................................... 58

11.6.2 Network capacity .......................................................................................................................... 58

11.6.3 Concurrent requests...................................................................................................................... 58

11.6.4 Response times ............................................................................................................................. 59

12 Licensing and Installation .............................................................................................. 60

13 ANNEX 1: Document History ......................................................................................... 61

14 ANNEX 2: Vision document glossary .............................................................................. 62

15 ANNEX 3: References .................................................................................................... 65



1 Executive Summary This Vision Document is to be read in combination with the ICS2 programme Business Case (current version v3.1) and the ICS2 Transition Strategy & Plan (currently under review).

The ICS2 programme identifies the Trader Interface (TI) as the project to implement the required common functionalities and to respect the agreed interfaces of the Harmonised Trader Interface (HTI) and the ones of the Common Repository (CR) applicable to the exchanges between customs and trade.

The HTI will be implemented operationally either as the Shared Trader Interface (STI) or National Trader Interface (NTI). The HTI generally and the ICS2 Shared Trader Interface (ICS2 STI) project specifically1 will contribute to the overall ICS2 business objective as defined in the EU strategy and action plan for customs risk management, adopted by the Commission on 21 August 2014 and endorsed by the Council in December 2014. This will be achieved by ensuring that economic operators with a role in the commercial supply chain can submit required information (entry summary declaration) in a harmonised way, taking into account international standards, without undue costs for business or for customs authorities.

It also contributes to the overall mission of the customs to maintain a proper balance between facilitation of legitimate trade and customs control measures necessary to supervise Union’s international trade.

The ICS2 STI will provide to thousands of economic operators that bring the goods into the European Union a first ever single instance of a harmonised trader interface with the customs authorities. This is of particular importance since it will cover one of the three main customs Trans-European Systems (TES), and is the largest in terms of the business-to-customs transactions and information exchanges2.

Instead of the today’s need to connect to each and every national ICS interface which have different technical and to a certain extent also different functional connectivity requirements, businesses will communicate with the EU customs for ICS2 via one unique interface (i.e. lodgement of entry summary declarations and all related information exchange). This will save money to the trade and to those customs authorities deciding to join to the implementation of the STI project.

The adoption of regulation (EU) No. 952/2013 of the European Parliament and the Council laying down the Union Customs Code provides the necessary initial legal steps (UCC Article 127(6)) to address the identified problems in data quality of the issued Entry Summary Declaration (ENS) data (i.e. multiple filing).

In July 2016, the CPG endorsed the approach proposed by DG TAXUD for a staged implementation of ICS2, which took into consideration the programme size and funding constraints. The overall implementation of the ICS2 programme was consequently broken down into blocks. The split is mainly driven by availability of financial and human resources and its overall complexity, whilst at the same time ensuring that each block provides a distinctive value on its own.

The Trader Interface scope is covered by the first block which is further divided in

Block 1a: to be delivered by 2020 and mainly limited by the available funding by the Customs 2020 Programme;

Block 1b: to be delivered by 2023 and must provide the necessary IT capacity and resources to cover the needs for the full volumetric, the high availability and high performance.

The CPG of 29th June 2017 approved the DG TAXUD implementation proposal for an ICS2 Shared Trader Interface (STI) as described in the document 'Shared Trader Interface Project Proposal' attached to note ARES(2017)2826621 of 06/06/2017[R04]. This 'Shared' implementation proposal was elaborated because a common/unique ICS2 trader interface implementation was not feasible due to some Member States’ expressed intention to implement the HTI nationally. Nevertheless, the majority of the Member States expressed their preference to collaborate on this component in order to save budget and resources and to provide a further facilitation to the trade.

1 As well as the NTI

2 NCTS and AES are the other two Trans-European Systems



Following this proposal, it was agreed that this STI IT component will become a Union component from a C2020 programme perspective, that the Member States will take the role of STI Business Owner and that DG TAXUD will take the role of STI System Owner and System Supplier.

In parallel with the inception activities leading to the Shared Trader Interface Vision Document the DG TAXUD ICS2 team, supported by the ICS2 Project Group composed of a limited number of the Member States customs and of the relevant trade associations, elaborated on the ICS2 Transition Strategy & Plan. One of the main outcomes of this activity is a precise scoping proposal which proposes the roll-out of the ICS2 programme in three time defined releases. From an STI perspective this implies a consistent development and deployment in accordance to three releases. The releases have a production date on 15/03 or 01/03 of a given year such to avoid operational dates on 01/01 of a given year considering the Christmas holiday periods:

STI release 1: Postal (Air) pre-load and Air express pre-load which entails implementing block 1.a with a proposed production date of 15/03/2021

STI release 2: full Postal and Air cargo and express which entails implementing part of block 1.b with a proposed production date of 01/03/2023

STI release 3: Maritime and Rail & Road which entails implementing the rest of block 1.b with a proposed production date of 01/03/2024.

The ICS2 Transition Strategy & Plan elaborates further on the ICS2 block 2 implementation but this is not applicable to the Shared Trader Interface scoping proposals as it concerns the customs-to-customs domain and interfaces. Although the CPG endorsement of the ICS2 Transition Strategy & Plan is only planned for December 2017, the proposed STI functional scoping in this Vision Document is based on the currently proposed best transition scenario. If this scenario would not be the one eventually endorsed this will lead to a change of this STI Vision Document.

The Total Cost of Ownership (TCO) of the ICS2 Shared Trader Interface covering the period 2017-2027 is estimated at 30.78M€.

(detailed cost removed)

The estimated costs for the period 2017-2020 are to be covered by the C2020 programme. From the budgetary year 2021 onwards, the estimated costs are to be covered by the C2020 programme successor.



2 Positioning Overview From a high-level perspective, the Trader Interface (Shared Trader Interface or National Trader Interface implementation) is a component of the ICS2 trans-European system. The Trader Interface is to implement on the one hand the agreed Business-to-Customs interactions and on the other hand the agreed interfaces with the ICS2 Common Repository component. The implementation is to be compliant with the legal base and the ICS2 common system specifications. The ICS2 Harmonised Trader Interface is part of these specifications and defines the common functional and IT technical aspects which are to be respected by any implementation party.

The ICS2 Trader Interface belongs to the external domain of a given trans-European system and its implementation is by definition the responsibility of the Member States. Nevertheless, as explained under the Executive Summary, an ICS2 Shared Trader Interface IT component will be developed and operated as a Union Component. This Shared Trader Interface component will be positioned at exactly the same level as any other national implementation of the ICS2 Trader Interface.

The figure below depicts the positioning of the ICS2 Shared Trader Interface in perspective of the ICS2 IT high-level implementation architecture.

Figure 1: Positioning Overview



The following sections explain into more detail the Harmonised Trader Interface concept, the business opportunity, the problem/opportunity statement, the expected benefits and the new or updated business processes proposed for automation.

2.1 The ICS2 Harmonised Trader Interface The 'Harmonised Trader Interface (HTI)' concept has been introduced in the ICS2 programme in order to reduce the burden on Economic Operators operating and bringing goods into more than one Member State. This is not an implementation in itself but part of the ICS2 common system specifications.

Respecting the HTI part of the ICS2 common system specifications will make sure that the implementations are:

'unique' from a functional perspective: data elements, specified exchanges, rules, conditions, etc.;

'unique' from a technical (IT payload) perspective: syntax notation (XML, XSD).

Furthermore, it is the objective that there is a 'unique' implementation of the identity/access management and the digital signature requirements via the UUM&DS implementation. The harmonisation capabilities of the IT connectivity layers are further to be investigated as well (see further in Information System Description).

2.2 Business Opportunity As documented in the ICS2 programme Business Case (ICS2) [R01], some Member States, but not all, have expressed their interest in the provision of a shared implementation of the ICS2 Harmonised Trader Interface. Member States can freely choose whether to opt-in to use this shared application.

In the scope of the ICS2 programme, the business opportunities offered by the ICS2 Shared Trader Interface are:

Reduction of investment costs for Member States as the efforts to implement new system capabilities (development, conformance testing and operation) required by the business needs are built once and operated by DG TAXUD, acting as system owner and system supplier;

Enhance harmonisation of interfaces with trade with the implementation of the Harmonised Trader Interface specifications for ICS2 information exchanges with the relevant customs systems.

2.3 Problem/Opportunity Statement

The problem of

providing an implementation for the ICS2 Harmonised Trader Interface specifications

Affects all Member States

the impact of which is investment and operational costs for each and every Member State implementation

a successful solution would be to provide an IT implementation respecting the Harmonised Trader Interface specifications, with multi-Member State capabilities.

The problem of

connecting (in the broad sense of the term) Economic Operator systems with different ICS2 customs system implementations

Affects the Economic Operators operating in more than one Member State

the impact of which is Risk of diversion and additional costs for the Economic Operators

a successful solution would be to provide an implementation of the ICS2 Trader Interface with a maximum level of interoperability such to reduce the number of required connections.



2.4 Expected Benefits The Trader Interface component, Shared Trader Interface or National Trader Interface, is an integral part of the ICS2 trans-European system and will as such contribute to the benefits expressed in the ICS2 programme Business Case:

Support of the new advance cargo information – ENS – requirements by receiving high quality of goods supply chain data from all modes of transport and closing the critical data quality loopholes of the existing ICS system;

Support of advanced air cargo security requirements by receiving data on goods prior to their loading onto the aircraft in a third country;

Support of the specific business model of postal operators operating under the UPU rules;

Facilitation for Economic Operators who operate in and bring goods into more than one Member State by providing a functionally and technically harmonized electronic interface. This will be further amplified by the fact that the STI will further reduce the number of implementations at Union level.



2.5 New or Updated Business Processes Proposed for Automation It must be understood that the Shared Trader Interface does not implement all ICS2 business processes but only a subset of them. This chapter identifies the business processes of the ICS2 programme of which some functionalities related to the communication with the traders are automated by the Shared Trader Interface. The complete business process descriptions can be found in the ICS2 common system specifications.

Process Category3 Domain4 Sub-domain5 Macro Process6 Process7 Process Updates (EN) from the STI

Legislation

lifecycle Customs

Customs policy: customs

modernisation and trade

facilitation

Supply chain

security Register Filing

The current ICS relation of one declarant per

ENS changes. Various supply chain actors

become obliged, when the conditions of

Article 127 (6) UCC apply, to submit

3 Process Category - The EC processes are classified in 14 process categories as follows: Asset Management, Audit, Communication & Dissemination, Coordination, Document Management, Financial Management, Grant Management, Human Resources, IT, Legislation Lifecycle, Policy Lifecycle, Procurement, Program Management, Strategic Planning.

4 Domain - The domain is the cutting of the highest level of activities of the Commission. A DG has only a few areas of activities, sometimes only one. In some cases, a domain is shared by several DGs, and even by all DGs.

5 Sub-Domain - A Sub-Domain is a subset of areas of activities that meets a set of common objectives and constraints.

6 Macro-process - A macro-process is a set of processes related to a sub-domain. It corresponds to a grouping of activities according to a common business logic. Sometimes the consolidation process corresponds to the sequential execution of many processes.

7 Process - The CEAF defines a process as an organised and repetitive sequence of actions involving resources which aims at producing a result to satisfy a client’s need.




particulars of an ENS depending on their role

in the supply chain.

Economic Operators concerned become

obliged to submit ENS particulars within the

legally defined time-limits. For example, in

the case of air traffic to submit data as early

as possible prior to the loading of an air

cargo or mail consignment, or in the

maritime either prior to loading of a

containerised goods consignment (‘deep sea

traffic’) or prior to arrival to the Union.

The STI will validate different types of ENS

filings from economic operators operating

across all transport sectors and various

business models, and will communicate the

acceptance of the ENS filings or its rejection,

in the case when the validation will fail.

Legislation

lifecycle Customs



facilitation

Supply chain

security Amend Filling

An original ENS filing can be amended by an

amendment filing which refers to the

original filing by its Master Reference

Number (MRN).




Legislation

lifecycle Customs



facilitation

Supply chain

security Invalidate filing

An original ENS filing can be invalidated by

the person filling or is automatically

invalidated after a defined period.

Legislation

lifecycle Customs



facilitation

Supply chain

security

Perform risk analysis

– mitigation

information

During the risk analysis process the

Responsible Member State applies, when

necessary, appropriate risk mitigation

measures in order to ensure a proper risk

analysis outcome. These measures can be a

request for information to the Economic

Operator and a request for HRCM (High Risk

Cargo or Mail) screening in the air cargo pre-

loading phase (which are to be forwarded to

the Economic Operators via the STI).

Legislation

lifecycle Customs



facilitation

Supply chain

security

Process arrival of the

means of transport

In case of air and maritime transport an arrival notification for the means of transport is to be lodged by the Economic Operator. The arrival notification identifies the Member State of Actual First Entry and triggers controls on goods which were identified being a risk requiring a control at the first point of entry in the EU (i.e. security and safety threat of such nature that immediate action is required upon arrival).




The arrival notification can be lodged either

via the ICS2 Trader Interface or the national

arrival system.

Legislation

lifecycle Customs



facilitation

Supply chain

security Control notification

In the case a Member State of first entry will decide to perform physical controls of goods connected to a holder of the status of an AEO for security, it will communicate to that economic operator involved an advanced notification prior to arrival of means of transport to the customs office of first entry via the STI about the control to be carried out upon arrival.



3 Project Scope 3.1 Project Includes ("IN" Scope) The Shared Trader Interface is a system component of the ICS2 Trans-European System (TES). The overall scope of the project is to implement the required common functionalities and to respect the agreed interfaces of the Harmonised Trader Interface and the ones of the Common Repository applicable to the exchanges with the trade.

Figure 2: Project Scope

3.1.1 Project Activities The project includes the following main activities:

Effective project management, including management of issues and risks;

Elaboration of specifications for the Shared Trader Interface, conform with the common system specifications;

Construction of the Shared Trader Interface system component (development and testing by the DG TAXUD development contractor);

The support for establishing the ICS2 TES helpdesk, and development of the STI interfaces and features supporting helpdesk, including STI related procedures;

Transition of the STI component into operations. This includes deployment and acceptance by the DG TAXUD operations contractor and integration tests with components such as UUM&DS, CCN2, TARIC3, CS/RD2, TATAFng, eDelivery profile (with the selected exchange protocol AS4 implementation);

Perform conformance tests with the Member States and the Economic Operators;

Perform End-to-End testing with the Member States and the Economic Operators including the interactions through the ICS2 TES helpdesk;

Set-up and execute the required communication plan with the Economic Operators in collaboration with the Member States;

Common Specifications

Common Domain

External Domain

Interoperability(based on CCN2)

Common Repository

National Domain

Shared Trader Interface

Trad

er S

yste

ms

National TraderInterface

SCOPE





Preparation of the training materials and training environment followed by the training execution;

Perform operations of the STI component (running and monitoring the system, provision of agreed level service desk support) and SLA management in line with agreed non-functional requirements;

Enforce security of the ICS2 STI component;

Apply effective change and release management.

3.1.2 Functional Scope The functional scope of the Shared Trader Interface must cover the required functionalities defined by the ICS2 common system specifications and respect the agreed interfaces of the Harmonised Trader Interface and the ones with the Common Repository applicable to the exchanges with trade.

The functional scope is derived from the:

ICS2 common system specifications;

Additional requirements mapped to functions allowing the consultation of the ENS information and their status and the possibility to identify and authenticate traders and for traders to manage their preferences;

Additional requirements mapped to functions required for the operation of the STI project (both from a business ownership and system ownership). Examples of these are auditing, monitoring, reporting and consultation of information and depicted in the following figure:

Figure 3 ICS2 STI functional scope

Authentication and authorisation covers the authentication and authorisation of Traders, Members State and Commission users;

Manage preferences encompasses the management of Traders’ preferences concerning the notifications they receive from the STI;

Monitoring and Audit will include the monitoring and auditing features that will be available to Commission and Member State users;

Submit, Amend and Invalidate ENS includes the processing of the ENS filings corresponding respectively to the submission, amendment and invalidation requests;



Generate MRN; the STI will generate MRN identifiers for every ENS filing and the arrival notification;

Syntactic/Semantic Validation includes the validations to be performed by the STI. This includes the validations performed using the reference data services;

Notify Validation Errors covers the submission of error notifications in case a syntactic and/or semantic errors are detected by the STI;

Acknowledge Reception; the STI will acknowledge the reception of the different ENS filings;

Consult ENS encompasses the consultation of the ENS stored in the Common Repository;

Notify ENS events corresponds to the Notification of the EO concerning the main events of the workflow, filtered on EO preferences;

Provide Additional Information covers the submission of additional information from the Traders to the STI;

Perform HRCM Screening covers features related to the submission of the High Risk Cargo or Mail Screening results;

Process Arrival Notification concerns the reception of arrival notification filing.

From a data perspective, the STI shall cover and support all applicable ENS filing types, with specific data sets and validation rules (both syntactic and semantic) for the different transport modes and business models: maritime and inland waterways traffic, air traffic (cargo, express, mail), express consignments and postal consignments other than air, rail, and road and the arrival notification.

3.1.3 Trader Interfaces The Shared Trader Interface will implement a System to System (S2S) interface to Economic Operator systems according to the HTI specifications.

In addition, User to System (U2S) capabilities will be available in the STI Release 2 to allow Economic Operators with low volume of ENS filings to fulfil their legal obligations without making significant IT investments.

3.1.4 Phasing of Scope In July 2016, the CPG endorsed the approach proposed by DG TAXUD for a staged implementation of ICS2 programme, which took into consideration the programme’s size and funding constraints.

The overall implementation of the ICS2 programme has been broken down into blocks. The split is mainly driven by availability of financial and human resources whilst at the same time ensuring that each block provides a distinctive value on its own.

The Shared Trader Interface scope is covered by the first block which is further divided in:

Block 1a: to be delivered by 2020 and mainly limited by the available funding by the Customs 2020 Programme;

Block 1b: to be delivered by 2023 and must provide the necessary IT capacity and resources to cover the needs for the full volumetric, the high availability and high performance.

Figure 4 ICS2 Shared Trader Interface – High-Level Planning



In parallel with the inception activities for the Shared Trader Interface project, the ICS2 team supported by the ICS2 Project Group elaborated on the ICS2 transition strategy & plan. One of the outcomes of this activity is a more specific definition of the functional scoping for blocks 1a and 1b and a related timing.

Although the CPG endorsement of the ICS2 transition strategy & plan is only planned for December 2017, the proposed STI functional scoping in this Vision Document is already based on the currently proposed transition scenario. If this scenario would not be the one eventually endorsed this will lead to a change of this STI Vision Document.

Proposed ICS2 transition scenario

The proposed scenario implies a transition strategy 'by group' starting with Postal (Air) and Air express pre-load, followed by full Postal and Air express and Air cargo, with the last group being Maritime and Rail & Road.

This overall ICS2 roll-out proposal implies from an Economic Operator and STI perspective 3 operational/production timelines with different impacted stakeholders and a gradual support of the different ENS filing types. The releases have a production date on 15/03 or 01/03 of a given year such to avoid operational dates on 01/01 of a given year considering the Christmas holiday periods:

Postal and Air express pre-load to be operational as from 15/3/2021;

full Postal and Air to be operational as from 1/3/2023;

Maritime, Rail and Road to be operational as from 1/3/2024.

Taking into consideration this transition strategy, the Shared Trader Interface overall project will be implemented in three distinct phases following an incremental approach. The outcome of each phase will be a Shared Trader Interface release covering the features required for the corresponding group. The scope covered by each STI release (i.e. in total three releases) is defined in the following sections and the corresponding timing in section 8.2.

3.1.4.1 STI release 1 - Postal and express Air pre-load

During the first phase, the different technical challenges will be addressed by implementing the architectural decisions taken and documented during the elaboration. The design of the first release of STI will cope with the different non-functional requirements with a specific attention to the system performance and integration with other systems. This first STI release of the Shared Trader Interface will be used as reliable basis for the subsequent iterations.

In terms of business coverage, the first STI release will provide a system-to-system (S2S) interface allowing the trader systems to file the ENS messages required to support Postal (Air) and Air Express pre-load partial ENS filings and to exchange the necessary information between the trade and the Common Repository as part of the functional scope of this first release. The relevant filing types will be supported by the first STI release of the STI component for this purpose. More detailed information about the filing types covered by the first STI release is given in [R02]. In addition, the features and user interfaces required for the Member State and Commission users will be implemented according to the agreed functional requirements.

3.1.4.2 STI release 2 - Full Air (postal, express, Air cargo)

Building upon the STI release 1, the second phase will implement the air pre-arrival for postal and express and the air pre-loading and pre-arrival for air cargo. Additional ENS filing types will be supported by the system-to-system interfaces to support these.

The second STI release of the STI will also include a User Interface for the traders covering the same business domains as the system-to-system interface allowing traders to file ENS without specific developments.



More detailed information concerning the subset of filing types to be implemented in the second STI release is given in [R02].

3.1.4.3 STI release 3 – Maritime, Rail and Road

The last phase will include the remaining transport domains: Maritime and inland waterways, Rail and Road with the related additional ENS filing types.

More detailed information concerning the subset of filing types to be supported in the last phase is given in [R02].

3.2 Project Excludes ("OUT" of Scope) The following functionalities are explicitly out of scope of the STI project:

STI will not support national deviations and will strictly comply to the accepted common system specifications;

Registration of Economic Operators. This shall be provided by Member States using other systems: EOS (Economic Operator Systems) and UUM&DS;

Management of ENS lifecycle and state. This is fully managed by the Common Repository (CR);

Risk Management and control functionalities. This is managed by the Common Repository (CR) and National Risk Management systems;

Database repository of ENS. The Common Repository (CR) is the master repository of ENS;

Management of reference data, goods, Economic Operators and their authorisations: this shall be provided by other DG TAXUD systems;

Sharing of information between Shared Trader Interface and National Trader Interface implementations;

System-to-System integration of the Shared Trader Interface with any other Member State system;

1st Level Helpdesk. This shall be provided by Member States as they have the required customs business knowledge to support the Economic Operators;

Training to the Traders, to the Economic Operators: This shall be ensured by the MS, following the train-the-trainer trainings provided by DG TAXUD.



4 Project Governance and Stakeholders 4.1 Governance To fully respect the roles and responsibilities of the STI project implementation the governance aspects will need to be set-up accordingly, following the governance scheme applied to MASP projects.

The STI implementation requires appropriate governance which is not only to steer the project activities but also to cover the undertaking of operational activities. The governance will be instrumental to govern the collaboration between MS and COM at all stages of the project, in particular in endorsing the specifications, subsequent artefacts, the STI IT component before its entry in production, and most importantly the change and release management process.

The steering and coordination of the project amongst STI MS will be done during the ECCG.

Figure 5 Project Governance & Stakeholders

4.1.1 Member States

Existing committees managing the ICS2 programme will be involved in the scope of the STI. These

committees are:

Customs Policy Group (CPG);

Electronic Customs Coordination Group (ECCG);

Risk Management Strategy Implementation Coordinating Group (RIMSCO).

Name Customs Policy Group (CPG) – Customs policy and strategy decisions



Role The CPG – Customs Policy Group – has the responsibility to orient and

approve the ICS2 programme strategy. Each new phase of the

programme needs to be approved by the CPG and it will also monitor

the implementation.

The decision about the GO/NO-GO for the implementation phase of the

ICS2 block 1a will be taken by the CPG mid-2018.

Permanent Members Member States, represented by Directors General or Deputies

Optional Members None

Deviation from the

Standard R&R 8Model

None

Name Electronic Customs Coordination Group (ECCG)

Role The ECCG – Electronic Customs Coordination Group – monitors and

steers the ICS2 programme as part of the MASP. It will need to approve

project documents and coordinate about the progress of national and

central developments. Some important system architecture elements or

patterns will also be approved by it. The STI project will run in parallel

with the other sub-projects (e.g. Common Repository) of the ICS2

programme9 and it will also have dependencies on other MASP projects

(CCN2, datacentre high availability, etc.).

The trans-European coordination between the sub-projects of ICS2

(functional specifications, Common Repository, trader interface and

helpdesk deployment, etc. will be the responsibility of the Commission

together with the MS through the ECCG.

This Vision Document is to be approved by the ECCG.

Permanent Members Member States, represented by IT & Customs Business Coordinators

Optional Members Switzerland and Norway

Deviation from the

Standard R&R Model

None

8 Roles and Responsibilities. 9 The different sub-projects (Common Repository, STI and national developments) will need to be

coordinated and monitored by the ECCG. The STI and Common Repository projects will have their own Vision Document and consequently their own project lifecycle.



Name RIMSCO

Role This group is mandated by Directors-General of the Member States

(CPG) to monitor and coordinate the implementation of actions

necessary for achieving the Objectives outlined in the EU Strategy for

customs risk management. Hence this is a group of DG representatives

from all Member States, linked to the CPG. The group will mainly

identify the priorities, their timing, monitor the work being developed

and identify the possible unexpected effects, synergies to other actions

and/or revision of time-plans.

Permanent Members Two representatives designated by their Director-General from all

Member States with the appropriate level of expertise in the field of risk

management. The representatives should have the necessary authority

to perform the requested tasks in particular in making available the

required resources of actions and initiatives at national level.


Deviation from the

Standard R&R Model

None

Furthermore, the following MS bodies will contribute to the project or will be kept informed:

The Customs Business Group (CBG) will follow the customs business side of the STI project. In

case there are risk management aspects to be discussed a joined CBG-RIMSCO meeting can be

organised. All Member States are members of the CBG. The TCG members can be invited as well;

The CPG in June 2017 approved the proposal to set-up a dedicated STI Project Group in order to

provide the relevant expertise of the traders and the MS experts to the project. The set-up of the

Project Group was approved by the C2020 Programme Coordination Group (PCG) CPG/157/001

and a first meeting will be organised in November 2017;

The IT Systems Development Group (ITSDG) will follow the IT aspects of the STI project. All

Member States are members of the ITSDG. The TCG members can be invited as well;

The Customs Expert Group (CEG/CRM) is responsible for the risk management matters and is to

be informed about the project's progress and to be consulted in case clarifications are required

about risk management aspects.

4.1.2 Economic Operators

The Economic Operators are important stakeholders in the ICS2 trans-European system as they have to

provide the required ENS quality data. They are represented in the STI project by the members of the

Traders Contact Group (TCG). The TCG members are permanent members of the ECCG and will be invited

for all STI meetings of the CBG and ITSDG. Furthermore, they are part of the STI Project Group.



Name Trade Contact Group (TCG)

Role Trade experts providing their input and advice about business and IT

aspects related to the required ICS2 exchanges between the Economic

Operators and the Trader Interface.

Permanent Members Approved members are associations (Europe or world-wide) involved in

customs related activities at the European level


Deviation from the

Standard R&R Model

None

4.1.3 Commission – DG TAXUD

The Commission STI project is managed by the DG TAXUD ICS2 team which is acting as STI project

manager, system owner and system supplier. The DG TAXUD ICS2 team has to work in close collaboration

with:

The DG TAXUD Enterprise Architecture and IT operations unit A5 as they manage all DG TAXUD

business-agnostic configuration items (CCN/CCN2, UUM&DS, infrastructure, etc.);

The DG TAXUD Customs IT Systems for the Union Customs Code unit A6 as they manage the

application architecture reference (TATAFng), the reference data services (CS/RD2, CRS, TARIC3)

and the Generic Trader Portal initiative.

The STI project sponsor is the Principal Advisor of DG TAXUD for IT Harmonisation and Coordination and

the ICS2 DG TAXUD policy owner is the DG TAXUD Risk Management and Security unit (B2). Other

involved DG TAXUD units are the Management of programmes and EU training (R3), Customs Legislation

(A2) and Customs Processes and Project Management (A3).

The overall DG TAXUD IT governance is managed by the IT Steering Committee which is providing its

approval for the different project steps. Finally, the IT Board of the Commission is providing its approval

for the Business Case and the Vision Document.

4.2 Stakeholders and Roles

The Economic Operators, the Member States and DG TAXUD are the main stakeholders of the project.

The following explores more into detail on the roles and responsibilities of the Member States and DG

TAXUD. This is in accordance with the document 'Shared Trader Interface Project Proposal' attached to

note ARES(2017)2826621 of 06/06/2017 elaborating on the 'Shared Trader Interface (STI) in parallel with

NTI' implementation alternative [R04]. This proposal was endorsed by the CPG on 29th June 2017.

4.2.1 Member States

The STI MSs as Business Owners will be responsible collectively, as one governance body, for organising and actively participating in the following activities (non-exhaustive list):

Participate at the ECCG meetings to steer the project and at the associated change management

board;



Provide necessary competent resources in terms of required FTE expertise (referred further as

‘assigned staff of the STI MS’) to support different project phases, working closely with the COM

ICS2 team preferably at the same physical location;

Manage processes related to the registration, identification and maintenance of the identities of

the Economic Operators and their representatives, in their Identity & Access Management (IAM)

systems, connected to the UUM&DS;

Contribute to and agree on the security plan and data access policy;

Consult and involve the Economic Operators during the system's implementation and testing

activities;

Organise conformance testing with traders;

Organise and deliver Traders user trainings;

Implement the required changes in the impacted national systems (if any) to be able to integrate

with the STI;

Provide ICS2 TES helpdesk facilities (1st level) to the Economic Operators;

Exclusively manage and operate their own IAM systems infrastructure, services and procedures;

Enforce security in the identity and access management processes and systems for Economic

Operators;

Check the business and technical readiness of the Trader before they start to send ENS to the STI;

Participate in the conformance testing (end-to-end test) between Shared Trader Interface,

Common Repository, National systems and Trade systems;

Contribute actively to the collaborative activities and in particular to the change and release management process.

4.2.2 Commission DG TAXUD

DG TAXUD will act as STI Component Owner and System Supplier and delegates this role to the DG

TAXUD ICS2 team. In its role of System Owner and System Supplier it will be responsible for organizing,

actively participating in and implementing the following activities (non-exhaustive list):

Act as the STI project manager;

Perform the STI inception activities resulting in the STI Vision Document, in collaboration with

the assigned staff of the STI MS;

Elaborate the functional and technical specifications of the STI, in collaboration with the assigned

staff of the STI MS;

Construct the STI, in collaboration with the assigned staff of the STI MS;

Run the conformance tests and support the STI MS during their participation to the conformance

tests;

Deliver the STI as an IT component operated in the DG TAXUD datacentre and ensure that the

high availability requirements agreed are met;

Deliver test plan which can be used to validated technical readiness of the Trader before they

start to send ENS to the STI;



Provide the training environment. And initial training materials (train-the-trainer);

Comply with the Service Level agreement for the STI operations;

Enforce security of the STI IT component;

Maintain the STI following the agreed change requests;

Evolve, support and bugfix the STI throughout its lifecycle as an IT component;

Offer the agreed levels of support to the TES help desk.

The sharing of responsibilities between the STI MS and the COM is summarised in the table below. It will

be formalised in the MoU.

Responsibilities MS COM Application specification (elaboration) Yes Yes

Application development (construction) No Yes

Perform conformance tests Yes Yes

Change management Yes Yes

Application maintenance No Yes

Helpdesk and support (Level 1) Yes No

Helpdesk and support (Level 2 and 3) No Yes

End user access management Yes No

Business operation Yes No

Software operation No Yes

Project management No Yes

Trans-European Project Coordination No Yes

National integration of traders Yes No



4.3 User Environment

4.3.1 Economic Operators

The Economic Operators issue mainly ENS filings to the ICS2 system fulfilling their legal obligations in the context of the entry of goods into the EU Customs Union. The Economic Operator population includes different actors such as carriers (maritime, air, road and rail), freight forwarders (maritime and air), express couriers, postal services and IT service providers.

When involved in customs business, Economic Operators need to have an EORI number as a unique identifier for customs identification purposes.

From an IT perspective, the Economic Operator has to register in a given Member State’s Identity and Access Management system that will be used for authentication purposes through the UUM&DS federated system.

4.3.2 Member State users

Member State users are not users involved in the ENS filing compared to the Economic Operators. Nevertheless, as provider of the 1st Level Helpdesk, Member States users should be able to check the status of the processing of the ENS and associated errors and validation results.

Furthermore, as data owner of the information, Member State users may be provided access to the information stored in the Shared Trader Interface, specific to their Member State.

4.3.3 Commission users

DG TAXUD users are not involved in the ENS filing compared to the Economic Operators. Nevertheless, as provider of the agreed service levels, DG TAXUD should have access to the technical logs, including security and technical errors.

Furthermore, as system owner and system supplier, DG TAXUD users may need to have access to technical and service monitoring functionalities required for capacity management, service level management and to support the ICS2 TES helpdesk.



5 Business Needs and Features

ID Need

Need Priority Difficulties10 Features

1 Facilitation of EOs in information

exchanges regarding customs

formalities for the entry of

goods into EU Customs Union.

High Major changes in business

processes and message

exchanges requires major

updates to Economic Operators

systems.

High number of ENS filings to be processed.

The STI will provide an implementation of the ICS2 Harmonized

Trader Interface specifications. This is consequently limiting the

number of access points to be used by the Economic Operators;

It will provide a system to system and a user interface for traders

having no supply chain system.

2 Improve data quality and filing

arrangements.

High Maintaining quality of ENS data

using different message structure

and rules for different domains.

High number of validation using code lists

Implement consistent and harmonised message validation process

including syntactical and semantical checks;

Allow necessary data to be supplied by the most relevant actor, per

process phase, in a given supply chain;

Enable supply chain actors to provide additional information on

consignments upon request;

Use common services for reference data validation.

10 This field describes the main concerns (worries) related to this need.



ID Need

Need Priority Difficulties10 Features

3 Ensure Confidentiality, Integrity

and Availability of the

information exchanged

High Registration of traders in

different Member States.

Data owned nationally stored in a

shared repository.

Apply data security and data protection measures compliant to

Article 12 UCC;

Implement the required access granting procedures to the STI

component (end users and IT support) that will need to clearly

define who can access the STI data and on what basis.

4 High-availability running on a

basis of 24 hours a day, all year

round.

High Redundant and interconnected

data centres and ongoing support

services.

Apply the agreed high-availability implementation (see chapter 11

for more information).

5 Be performant enough to

answer within the required and

agreed timeframe to the trade

(appropriate timeframe for each

different type of business

model).

High Large number of the received

ENS filing.

Cope with increased number of

users, increased transaction and

data volumes.

Adopt an effective architecture and infrastructure to meet

performance requirements to authenticate the sender, to receive,

validate, reject or register ENS filings and send related responses

(rejection or acknowledge and provision of MRN) to the sender or

other supply chain actors where appropriate within 120 seconds

independently from submissions in parallel;

Adopt an architecture enabling horizontal scalability, in terms of

storage and processing capacity;

Implement an asynchronous communication model for better load

distribution and peak support.



6 Alternatives and Synergies 6.1 Alternatives The different trader interface implementation options were identified and documented in chapter 8.5.2 of the ICS2 programme Business Case document [R01]:

National Trader Interface (NTI) only. This alternative is compliant to the current ICS implementation as each and every MS is to operate its own implementation;

Common Trader Interface. This alternative is only feasible when all MS agree with a common implementation. Following the survey that was organized in 2015 this is not the case. Consequently, this option was not further elaborated;

Shared Trader Interface (STI) in parallel with NTI. This option provides the possibility that a given Member State develops its own implementation and that on the other hand Member States can opt-in to collaborate for a shared implementation. This shared implementation is delegated to the Commission with agreed governance rules.

The third alternative, also presented as the ‘COM’ scenario was further elaborated In the document 'Shared Trader Interface Project Proposal' attached to note ARES(2017)2826621 of 06/06/2017[R04]. More specifically, it provided further details on the governance, the C2020 funding options for the required MS experts and the STI functionality.

This updated STI project proposal was

approved by the DG TAXUD ITSC;

reviewed by ECCG and RIMSCO by written procedure;

presented at the ECCG meeting on 8th of June 2017;

presented at the joined CBG and RIMSCO meeting on 20th of June 2017;

endorsed by the CPG on 29th of June 2017.

Consequently, it is assumed that no further analysis is required in the context of this Vision Document and that the endorsed STI project proposal is applicable.

6.2 Synergies with other projects

The following synergies have been identified at Commission level11 for the build of the Shared Trader Interface IT component:

The ICS2 Harmonised Trader Interface (HTI) specifications will provide the common specifications for both the STI and the NTI implementations;

The ICS2 Common Repository (CR) IT component implements all the common ENS Lifecycle functions and conform to the ICS2 Common System Specifications. The latter specifies the required interfaces between the CR and the trader interface implementations (STI or NTI);

The ICS2 TES helpdesk project aims to create the necessary connections and interactions between the different helpdesks at national and EC level. The STI operations will use the ICS2 TES helpdesk processes and procedures;

The Generic Trader Portal initiative is to provide a graphical user interface for Economic Operators to interact with various customs business processes such as customs decisions (the

11 Member States may identify other synergies, such as with other transactional systems of presentation of arrival, presentation of goods, customs declarations (implementation of UCC Article 130, etc.)



currently only implementation), electronic BTI, electronic AEO, etc. The envisaged STI user interface for Economic Operators is to be integrated into this Generic Trader Portal component;

The Uniform User Management and Digital Signatures (UUM&DS) system aims at providing an end-to-end solution that supports secure trader access to Customs Systems over the Internet by using STORK technology and federating MS IAM systems. This Extended Federated IAM solution supports the trader authentication and authorisation by using STORK 2.0 protocols and will be used to provide means of identification of traders connected to the STI (U2S and S2S). Additionally, it will provide services on top of Public Key Infrastructures (PKI) that will allow to validate public keys used to verify digitally signed messages from traders;

The CCN2 platform is the trans-European exchanges platform and will be used to exchange the service operations between the ICS2 STI and the ICS2 Common Repository. The CCN2 platform offers the added value of exposing asynchronously web services using the one-way message exchange pattern to ensure a decoupled communication between the parties, as well as other added value services such as security, federated governance, monitoring, interoperability and auditing;

The Connecting Europe Facility (CEF) eDelivery building block will be evaluated for a possible implementation of the AS4 message exchange protocol such that this will ensure an interoperable, secure and reliable data exchange between business and customs;

The TATAFng application architecture reference of the DG TAXUD central developments will serve as baseline for the design of the relevant subsystem components of the Shared Trader Interface;

The Customs Reference System (CRS) is the existing DG TAXUD application which collects trader information from the different trader related acquisition systems such as REX (Registered Exporters), EOS (Economic Operators System) and CDMS (Customs Decisions Management System). It provides as the reference point services to replicate and validate the necessary trader information. The applicable services are to be used by the STI mainly for validation purposes;

The TARIC3 application is the existing DG TAXUD application which is the reference point for tariff information, including the different goods nomenclature schemes. The applicable services are to be used by the STI mainly for goods code validation purposes;

The CS/RD2 application is the existing DG TAXUD application which is the reference point for customs authority information and code lists such as country codes, etc. The applicable services are to be used by the STI mainly for code list and customs office code validation purposes;

The High Availability DG TAXUD Data Centres will provide hosting services for the STI component implemented on the TAXUD SOA Platform (TSOAP).



7 Project Approach This chapter describes the Shared Trader Interface project approach, as it is aligned with the principles of the ICS2 project.

7.1 Methodological Approach The project will apply the methods as specified in TEMPO, the DG TAXUD methodology. TEMPO is aligned with the RUP@EC and PM² methodologies and provides a Software Development LifeCycle (SDLC) for SOA type of implementations.

In compliance with the SDLC, each phase of the Shared Trader Interface project development activities will be organised following the standard RUP@EC methodological approach, with Elaboration, Construction and Transition phases, followed by Operations.

The elaboration of the STI specifications and its subsequent development will be outsourced to the external CUSTDEV3 contractor and the required operational services to the external ITSM3 Operations contractor.

QA services will be delivered by the external QA contractor.

The operation of the Shared Trader Interface will be regulated by a specific Implementing Act (based upon Art 17 UCC) and completed by the "Terms of Collaboration" (TOC). The TOC describes further the collaborating organisations (MSs, DG TAXUD, external contractors) and defines further the rights and obligations of each of the collaborating parties contributing to the operations of system. The TOC also:

Defines the mutual obligations of the MSs and the DG TAXUD around the Common Domain;

Includes the assembly of all the individual Service Level Agreements (SLAs) set up with the MS;

Defines the DG TAXUD’s responsibility to ensure that a unique system, with regard to the business process to be supported, emerges from the combination of national and community components;

Defines responsibilities, services, common plans and procedures facilitating collaboration (includes ITIL Service Support and Service Delivery processes);

Defines roles and responsibilities of MS especially as regards the data sharing and access rights;

Defines the principles used for the Business Continuity implementation.

7.2 Change management Changes to the functional or technical specifications can impact the external interfaces and consequently the common and/or national developments. Change management will be applied within the normal project management activities and according to the TEMPO guidelines and under the governance described in Chapter 4. Change requests will be subject to approval of the Change Management Board (i.e. the ECCG).

Change management is to be applied as soon as baseline specifications are created and to be applied until the end of the ICS2 operational lifecycle.



7.3 Project risks

ID Magnitude12

Description Probability of occurrence13

Severity14 Impacts Risk Action15 Owner Status

1 3 Member State and trade association resources will be necessary to support the ICS2 project team. If these resources are not made available there is a risk that the STI component is not developed according to the expected quality.

1 3 Quality of delivery Mitigation:

Put in place an STI Project Group to support the elaboration activities until mid-2018.

Once the GO decision for the implementation is taken mid-2018 the Project Group mandate is to be extended.

CPG/ECCG Mitigation actions

2 6 Construction delayed because of delays in the agreement on the ICS2 common system specifications and more specifically on the Harmonised Trader Interface part.

2 3 Time to delivery Mitigation: Collaboration with the Member States and Trade at ECCG level and within the ICS2 Project Group.

ICS2 team Identified

3 6 Economic operators will be required to timely adapt their business processes and systems to

3 2 Time to delivery, operation volumes and transition

Mitigation: Provide ICS2 Common System Specifications (including

Economic operators

Identified

12 A calculated value as a function of the severity and probability of the risk

13 A numeric value denoting the relative probability that the risk should occur.

14 A numeric value denoting the relative severity of the impact of the risk if it should occur.

15 Risk Actions: Avoidance/ Transfer/ Mitigation Strategy / Contingency Plan



ID Magnitude12



the requirements of the ICS2.

This entails a risk of delays in time caused by insufficient availability of resources to implement and test their applications interacting with the STI.

strategy. the HTI specifications) as early as possible.

The Economic Operators are represented in the STI project group such that they are involved in the development process from the early stages.

Provide and execute a communication and training plan as early as possible and in parallel with the STI construction phase.

4 4 Delay in delivery of external dependencies: CCN2, UUM&DS, TSOAP, AS4 (eDelivery profile) component implementation, etc.

2 2 Time to delivery, missing functionalities

Mitigation: Apply effective project management by monitoring the progress and the provision of a fall-back architecture when possible.


5 3 The implementation risks not to be compliant with expectations in terms of performance, capacity and availability.

1 3 Operations Mitigation: Validation of the architectural choices as early as possible during the project by performing benchmark tests. If not satisfactory a fall-back architecture/design will be provided.




ID Magnitude12



6 3 Key members of the project teams leave.

3 1 Time to delivery Mitigation: Define back-up roles

Mitigation: Govern knowledge transfer.

DG TAXUD ITSC

Identified

7 3 Legal Implementing Act for ICS2 not in force by the first operational ICS2 milestone (currently planned for 15/03/2021).

1 3 Time to delivery

Start of the operational phase delayed

Mitigation:

Legal assessment will be performed beginning 2018 resulting in a possible implementation plan of which the implementation act will be part of.

ICS2 team and involved DG TAXUD business units

Identified

8 3 The funding for the post 2020 project activities is not yet secured: under C2020 only the funding for the STI Release 1 is covered.

1 3 Planned delivery of blocks beyond 2020

Mitigation: The next MFF should provide the funding for the next releases beyond 2020.

It is expected that the required information will be available by mid-2018.

Member States

Mitigation actions



8 Cost, Timing and Resources

The project implementation will be divided in three phases in line with the transition scenario defined in

the ICS2 Transition Strategy & Plan [R02]. The timing and costs defined in the following sections is bound

to this transition scenario and must be adapted in case of change. The scope of each phase is defined in

section 3.1.4.

The Elaboration of the STI phase 1 can start in Q4 2017. Following the project implementation phases

(construction, transition) the STI phase 1 is foreseen to be technically ready for deployment in operations

in 2020.

The estimated costs for the period 2017-2020 are to be covered by the C2020 programme. From the budgetary year 2021 onwards, the estimated costs are to be covered by the C2020 programme successor.

8.1 Cost The Total Cost of Ownership (TCO) of the ICS2 Shared Trader Interface covering the period 2017-2027 is estimated at 30.78M€.


The cost centres defined in the tables below (the lines of the table) are standard cost centres to develop and operate a Trans-European customs System component. They contain cost for the development of the software itself, but also the costs of the necessary servers, COTS and related licences to be paid. The Shared Trader costs include:

Conformance Testing - Covering the cost to execute the required activities for Conformance testing. The platform used for testing isn't included here, but in the Hardware and Software line;

QA services - Covering acquisition of IT services for quality assurance and quality control of the delivery processes and deliverables;

Hardware, OS, RDMS, Storage, DEV tools – covering the cost of Physical Servers, Virtual

Machines Operating Systems and DG TAXUD standard applicative stack (RDBMS, Application server,…), physical storage (as detailed in 9.6), and development tools for all required environments as listed in Chapter12. Infrastructure cost is based on calculations by DG TAXUD based on the availability and performance assumptions listed in Chapter 11;

Development – covering the cost of development and configuration effort required to design,

construct, integrate, test and transition the system; i.e. covering the effort involved in elaboration, construction and transition phases. The development will be based on COTS software components. The development cost is based on a function point counting, and a separate evaluation of the efforts required for the integration with external systems and communication channels including the proof of concepts necessary to validate as early as possible the performance and validity of the main architectural decisions. The development cost will be further detailed at the end of the elaboration phase when the functional specifications required to perform an accurate counting are available;

Maintenance and change management – covering annual costs of maintaining the system:

change management on specifications, analysis and code in the limit of corrective or evolutive maintenance. The maintenance cost is calculated as a percentage of the development costs;

Training – involving preparation of e-learning modules, completion of a physical train-the-

trainer sessions. It is assumed that additional training to the EOs is handled by the Member States. The training costs are calculated based on an e-learning module and training session to be organised in Brussels for the National Administration users. Dedicated training campaign will be organised to cover the features brought by each STI versions. In addition, after the start of operations yearly training session for Member States will be provided;



Support – covering second and third level support. It is assumed that first level support is

handled by the Member States. The cost covers resources to provide technical support for IT and resources for helpdesk operations;

AS4 (eDelivery profile) – Covers the costs for, licensing installation and support, the integration with one of existing AS4 (eDelivery profile) implementations within the overall DG TAXUD IT architecture. This estimate is based on the assumption that the eDelivery AS4 profile specification will be successfully evaluated and included as part of the Harmonized Trader Interface specification.

It is to be noted that the internal project management activities and the ICS2 common system specifications activities are not costed in these tables but covered by the resources as specified under 8.3. The Costs are presented first for the complete scope, then per release following the ICS2 Transition Strategy & Plan [R02].



8.1.1 Costs for Release 1 (detailed cost removed)


Sensitivity: Limited DG Issue Date: 31/10/2017 Status: SfR

8.2 Timing The planning of the Shared Trader Interface project is aligned with the ICS2 transition Strategy & Plan [R02] and more specifically with the proposed Transition Scenario C. This scenario involves a transition strategy by group

starting with Postal (Air) and Air Express pre-load;

followed by the air pre-arrival for postal and express and the air pre-loading and pre-arrival for air cargo and;

completed by last group being Maritime, Rail and Road.

Consequently, the Shared Trader Interface project will be split into three phases each of them aligned with a group defined in the ICS2 transition Strategy & Plan. The outcome of each phase will be an ICS2 STI release implementing the required business functionality.

The planning structure of the three phases is equivalent and described in the following sections. The timing is expressed in relative and absolute terms.

8.2.1 Phase 1 – ICS2 STI release 1

The first phase of the ICS2 STI project will start upon approval of the current vision document with the elaboration phase and will result in the delivery of the first ICS2 STI release with an estimated production date on 15/03/2021.

The approval of the ICS2 STI Vision Document is marked with T0 as relative date in the planning table below. The T1 relative date marks the Go/No Go decision to be taken by the CPG for the implementation of block 1a, of which the STI is part. This first release will implement only the relevant S2S interfaces for the Postal (Air) and Air Express pre-load. The STI elaboration activities will continue after T1 for one quarter.

The construction activities will bring the ICS2 STI release 1 in a state ready to participate in tests with external stakeholders (Economic Operators). This implies:

Software development;

Unit testing performed by the development contractor;

Factory Acceptance Testing performed by the development contractor;

Site Acceptance Testing performed by the ITSM operations contractor;

Integration Testing with the other related IT components for which DG TAXUD is responsible (e.g. UUM&DS, TARIC3, CRS, CS/RD2, CCN2, AS4 component, etc.).

The transition phase will include all activities needed for the go-live of the ICS2 STI Release 1. This implies:

The provisioning and the installation of the different environments such as Conformance, Training and Production including the required network capabilities;

the execution of the different Conformance testing threads: o STI compliance with the Common Repository interfaces; o STI compliance with the Harmonized Trader Interfaces; o Traders’ conformance testing including connectivity test, payload test and full functional

scenario tests;

the execution of the End-to-End testing with all components;

the delivery of the trainings.

The communication plan activities will start as early as possible, in parallel with the construction phase activities.

The NTI and the trader implementations are to be started when the ICS2 Common System Specifications are available and to be ready for conformance testing by Q2 2020. It is to be noted that the preparation of the conformance testing environment is to be performed beforehand meaning an overlap of one quarter between the construction and the transition phases.



Figure 6 ICS2 STI – Phase 1

The high-level planning of the first phase of the STI is outlined in the table below.

Relative dates Absolute dates

Project Phase/Milestone Responsibl

e Start Date

End date

Base

line

Start Date End date

Approval of the ICS2 STI Vision Document

ITSC T0 12/12/2017

STI elaboration ICS2 Team T0 T0+3Q 15/12/2017 30/09/2018

GO/NO GO decision by CPG if STI implementation can start

CPG T0+2Q T1 Mid 2018

STI construction ICS2 Team T1+1Q T1+8Q 01/07/2018 30/06/2020

STI Transition

STI Conformance Preparation and Testing

ICS2 Team T1+7Q T1+10Q 1/04/2020 31/12/2020

STI E2E Preparation and Testing

ICS2 Team T1+10Q T1+11Q 01/10/2020 31/03/2021

Training delivery ICS2 Team T1+9Q T1+11Q 01/07/2020 15/03/2021



Communication Plan preparation and execution

ICS2 Team and STI MS

T1+1Q T1+11Q 01/07/2018 15/03/2021

STI start of operations ICS2 Team and STI MS

T0+13Q 15/03/2021

Table 5 ICS2 STI Phase 1 milestones


The second phase of the ICS2 STI project will start upon the completion of the elaboration of phase 1 and will result in the delivery of the second ICS2 STI release with an estimated production date on 01/03/2023.

The end of the elaboration of ICS2 STI phase 1 is defined as the T0 baseline start date for the ICS2 STI phase 2.

The planned activities will follow the pattern of ICS2 STI phase 1.


The high-level planning of the second phase of the ICS2 STI is outlined in the table below.


Project Phase/Milestone

Responsible

Start Date

End date Base

line Start Date End date

STI R1 elaboration finalized

STI Team T0 30/09/2018

STI elaboration STI Team T0+1Q T0+6Q 01/10/2018 31/03/2020

STI construction STI Team T0+7Q T0+14Q 01/04/2020 31/03/2022

STI Transition


STI Team T0+13Q T0+17Q 01/01/2022 31/12/2022

STI E2E Preparation and

STI Team T0+17Q T0+18Q 01/10/2022 01/03/2023



Testing

Training delivery STI Team T0+15Q T0+18Q 01/04/2022 01/03/2023


STI Team T0+7Q T0+18Q 01/04/2020 01/03/2023

STI start of operations STI MS T0+18Q 01/03/2023



The third phase of the ICS2 STI project will start upon the completion of the elaboration of phase 2 and will result in the delivery of the third ICS2 STI release with an estimated production date on 01/03/2024.

The end of the elaboration of ICS2 STI phase 2 is defined as the T0 baseline start date for the ICS2 STI phase 3.

The planned activities will follow the pattern of ICS2 STI phase 1.


The high-level planning of the third phase of the STI is outlined in the table below.


Project Phase/Milestone Responsible Start Date End date Base

line Start Date End date

STI R2 elaboration finalized STI Team T0 31/03/2020

STI elaboration STI Team T0 T0+3Q 01/04/2020 31/12/2021

STI construction STI Team T0+3Q T0+11Q 01/01/2021 31/12/2023

STI Transition




STI Team T0+11Q T0+15Q 01/01/2023 31/12/2023

STI E2E Preparation and Testing

STI Team T0+14Q T0+16Q 01/10/2023 01/03/2024

Training delivery STI Team T0+13Q T0+16Q 01/04/2023 01/03/2024


STI Team T0+3Q T0+16Q 01/01/2021 01/03/2024

STI start of operations STI MS T0+ 16Q 01/03/2024


8.3 Planned Resources

The Shared Trader Interface Project Team will be part of the DG TAXUD ICS2 team.

Shared Trader Interface IT Project 2017 2018 2019 2020 2021 2022 2023 2024

Implementation in FTE

ICS2 Team - Statutory Staff 1 2 2 2 2 2 2 1

ICS2 Team - Intramuros consultants

1 3 3 3 3 3 3 1

TOTAL 2 5 5 5 5 5 5 2

Table 8 Commission's Planned Resources for Shared Trader Interface

The table above covers the estimates in Full Time Equivalent (FTE) for Commission staff and intramuros

consultants.



9 Information System Description This section provides a high-level view of the Information System, its capabilities, interfaces with other applications, and systems configurations.

The ICS2 STI architecture must be compliant to the functional and non-functional requirements and consider the legal, organisational, planning and strategic constraints.

The ICS2 STI Component must be considered being part of the whole ICS2 project, for which the key non-functional requirements are high-availability, performance, security, reliability and scalability. The overall system, its layers from the infrastructure and network up to the high-level services, must be architected to achieve the required level for these qualities.

The ICS2 STI Component will be aligned with the SOA architectural decisions as specified in the MASP strategy.

High-availability requires an infrastructure architected to achieve this quality. Please refer to chapter 11 for details on high availability requirements.

Performance requires adequate sizing and configuration of the infrastructure and COTS, scalability, clusters of services with load balancers, optimal algorithms and minimization of unnecessary file and network data traffic.

9.1 Architectural Principles The ICS2 STI Information System architecture must respect the following architectural principles or constraints. These constraints have been defined per the IT architecture recommendation from DG TAXUD and the non-functional requirements.

AP1. The ICS2 STI Component will use the CCN2 platform for all trans-EU communications; AP2. The UUM&DS system will be used for authentication, authorization and non-repudiation of Economic

Operators using digital certificates; AP3. The ICS2 STI Component will be aligned to enterprise architecture guidelines and follow the Tariff

Application Technical Architecture Framework new generation (TATAFng) which is a framework defining guidelines, services and components and includes a reference architecture for all DG TAXUD SOA applications.

AP4. The ICS2 STI design must comply with security requirements and security constraints defined in Section 10.2;

AP5. The ICS2 system will comply with the quality requirements as defined in Section 11; AP6. The ICS2 STI Component must guarantee high availability and failover strategy defined in Section

11.1; AP7. The ICS2 STI application architecture must enable horizontal scalability, in terms of storage and

processing capacity as defined in 11.5; AP8. The ICS2 STI Component must guarantee performance in processing the volumetric defined in section

11.6; AP9. The ICS2 STI Component will be accessible to Economic Operators from the Internet. It’s UI

components will be Web based, IPG and W3C compliant, and will follow EC requirements concerning security, accessibility and multilingualism. The UI design will be based on DIGIT’s UI Framework (eUI – UX@EC). The UI component must be aligned to the Generic Trader Portal guidelines.

9.2 ICS2 Common specifications As for all existing trans-European systems, the ICS2 STI Technical System Specifications must comply with the Functional Systems Specifications. The Commission, with the support of the MS, will provide the common functional and technical system specification for ICS2 including the Harmonised Trader Interface specifications to which the ICS2 STI Component must be aligned.

9.3 System overview Figure 9. ICS2 STI Component overview below provides an overview of the envisaged ICS2 Shared Trader Interface in terms of system components and interfaces. More details of these building blocks are provided in the sections below.



UUM&DS Reference Systems

ICS2 Common Repository

EO System

Generic Trader Portal (GTP)

STI Trader UI

STI core

Economic Operator

CRS IT Application

CS/RD2 IT Application

TARIC3 IT Application

CRApplication

eDelivery

STI CR Interface

UUM&DS

Internalnetwork

Public internet

CCN2over internal

network

Public internet

STI MS and Commission

UI

Internalnetwork

STI Reference Data Cache

Member Stateuser

TAXUD user

CCN2

Figure 9. ICS2 STI Component overview

9.3.1 Shared Trader Interface The AS4 implementation will follow the eDelivery AS4 profile specification to ensure interoperability and easy adaptation by the Economic Operator systems as it provides the implementation of the reliability and non-repudiation requirements in a standardized and well documented way. Additionally, it provides an asynchronous integration with the STI Core services.

The AS4 implementation and integration into the IT Architecture of DG TAXUD will be analysed and assessed during the STI elaboration activities.

The STI Core provides the services required by the ENS filing processes, be it a registration, amendment or invalidation. Such filing received by the STI Component will be validated (possibly after conversion from EDIFACT to XML) and a response to the Economic Operator will be send, including a generated MRN in case of a new registration. Successfully validated filings are subsequently handed over to the STI CR interface to be forwarded to the ICS2 CR system component. The validation relies on data obtained using the reference data services of the TARIC3, CRS and CS/RD2 IT Applications.



The STI core provides as well the services required to process notifications and requests from the ICS2 CR system as obtained by the STI CR interface and forward them to the Economic Operators (possibly after conversion from XML to EDIFACT) taking into account the preference of the Economic Operators concerning notifications. Through these preferences, Economic Operators can indicate through which channel they want to be notified (the user interface or the system-to-system interface), and if they want to un-subscribe to optional notifications.

Finally, the STI core provides synchronous consultation and preference management services that the EO user can use through the ICS2 STI Trader Portal module. The MS user can use similar consultation services.

The STI CR Interface is responsible for submitting the Economic Operator messages to the ICS2 CR services over CCN2. Furthermore, it is responsible for receiving ICS2 CR messages and consuming STI Core services to ensure they reach the Economic Operators.

The STI Reference data cache is responsible for loading and caching reference data used during validation from the TARIC3, CRS and CS/RD2 IT Applications.

The STI MS and Commission UI is a user interface allowing MS users to consult the status in the STI of ENS filings and other notifications from the trader on the one hand, and responses and requests from the ICS2 CR on the other hand.

9.3.2 The STI Trader UI in the Generic Trader Portal The Generic Trader Portal is an IT Application providing a user interface for Economic Operators to interact with various customs business processes. The portal is modular by design and provides reusable notification and submission services for its modules. An ICS2 STI module will be developed that will allow an Economic Operator to construct and submit ENS filings and related messages, and receive responses and notifications through it. Additionally, Economic Operators can use this user interface to manage their preferences.

9.3.3 The Economic Operator systems These are the systems of the Economic Operators, either managed by the Economic Operator itself, by its representative or by an intermediate service provider. They are the endpoint used by the Economic Operator to submit ENS filings and related messages and receive and process responses and notifications.

9.3.4 The ICS2 Common Repository The ICS2 Common Repository system is the common domain IT component of the ICS2 system that will provide the common referential and storage of the ENS data, that will make the relevant ENS data (individually or merged by consignment) available to the MS customs and that will make the consolidated ENS data available for risk analysis to the relevant MS. It will also collect and share the risk analysis results amongst MS, and provide data analytic tools.

9.3.5 UUM&DS ICS2 STI will use UUM&DS for cross border identification, authentication and authorization of Economic Operators or their representatives, both for user-to-system as for system-to-system communication. Furthermore, the UUM&DS system is the enabler for digital signature of Economic Operator messages.

9.3.6 CCN2 CCN2 is the trans-European exchanges platform and will be used to exchange the service operations between the ICS2 STI and the ICS2 Common Repository.

The CCN2 platform offers the added value of exposing asynchronously web services using the one-way message exchange pattern to ensure a decoupled communication between the parties, as well as other added value services such as security, federated governance, monitoring, interoperability and auditing.

9.3.7 Reference Systems The ICS2 STI will use reference data services to retrieve all common reference data. This includes data from different central systems (CS/RD2, TARIC3, CRS) about common code lists, customs office lists, goods nomenclatures, Economic Operator’s information.

To ensure high-availability and high performance of the ICS2 STI Component, the reference data retrieved daily from the Reference Systems and will be stored locally and cached.

9.4 Interfaces In the section below an overview of the interfaces between the components is described.



9.4.1 System-to-system interface with EO Systems This interface ensures the system-to-system communication between the Economic Operator systems and the ICS2 STI over the public internet.

The interface will implement the AS4 standard, a web services based business-to-business messaging protocol that aims to facilitate the exchange of electronic business messages while ensuring the necessary security and reliability requirements.

Some benefits of this standard are:

AS4 offers a secure document exchange protocol for use over the Internet to transport arbitrary payloads. Support for message security and confidentiality is provided by WS-Security 1.0 and 1.1 standards. This includes combinations of XML Digital Signatures and XML Encryption X.509 security tokens for signing and encrypting as primary means for authenticating messages, ensuring privacy, and guaranteeing safe data transmission;

The AS4 standards provide support for non-repudiation and non-repudiation of receipt;

AS4 makes use of the message receipt as a signal to the original message sender that the recipient of the message has received the business payload;

AS4 supports duplicate message detection and message retry/resending scenarios for when receipts for messages are not received by the sender;

AS4 supports payload compression.

Moreover, the AS4 standard is selected as the message exchange protocol of the eDelivery building block of the Connecting Europe Facility (CEF) Programme.

9.4.2 Graphical user interface for EO The web interface between the Economic Operator users and the ICS2 STI UI is provided over the public internet.

A web application accessible through HTTPS will be provided as an ICS2 module of the Generic Trader Portal. UUM&DS will provide the necessary authentication, identification and authorisation services.

9.4.3 Other interfaces The interface with the ICS2 CR system component is provided by the CCN2 platform over the internal network. The same platform will be used by the national trader interfaces to interact with the ICS2 CR system, but in that case over the CCN WAN network.

The interface with the Common Reference Systems offer services that the ICS2 STI Component will consume over the internal network.

The interface with the UUM&DS system offers services for authentication, identification, authorisation and non-repudiation over the internal network using digital certificates.

The interface with the MS users is provided over the CCN2 platform.

9.5 Network The following section describes important aspects of the used networks, as presented in the Figure 9. ICS2 STI Component overview above.

The public internet includes traffic between the Economic Operators and their systems and Central applications (shared and common). As depicted in Figure 9 it supports the communication between the Economic Operator systems and the ICS2 STI, as well as between the Economic Operator users and the graphical user interface of the ICS2 STI in the Generic Trader Portal.

The internal network includes traffic between the ICS2 STI Component and the UUM&DS services, the ICS2 CR system and the Reference Systems.

The CCN WAN network will not be used for traffic between the ICS2 STI Component and the ICS2 CR system component as they are located in the same datacentre and therefore connected over the internal network. The CCN2 services of federated user management, security enforcement, routing of requests and one-way message exchange pattern services will be used.

9.6 Storage The data of the ICS2 STI Component can be split in operational and non-operational data. The former contains the signed messages send by and to the Economic Operators that are taking part of a non-finished ENS



lifecycle. The latter contains audit and logging, and the archived signed messages of the Economic Operators to ensure non-repudiation.

9.6.1 Operational data storage The operational data will be stored in a high-available Oracle RAC database hosted on the high-available datacentres of DG TAXUD.

The sizing estimates of the operational data depend on the lifecycle duration of the ENS. During this lifecycle, the status of the messages that are issued from and to the Economic Operator must be readily available. The operational data is also used as a buffer towards the ICS2 CR system in case of unavailability.

Data Phase 1 Phase 2 Phase 3 Source and explanation

Messages from and to the Economic Operators

0,2 TB 0,8 TB 1.5 TB The storage is calculated based on incoming and outgoing messages for 200 days (configurable) assuming the volumetric constraints in section 10.4.

Reference data 1 GB 1 GB 1 GB To ensure high-availability of the ICS2 STI Component, the relevant reference data retrieved daily from the Reference Systems will be stored locally.

User data (profiles, configuration, access rights, ...)

- - - Negligible

Table 9: Operational storage

9.6.2 Audit data storage The functional audit data will be stored centrally for both the ICS2 STI and the ICS2 CR. The sizing is estimated as follows:


Functional audit data used for traceability

2,1 GB 21,3 GB

31,9 GB It is estimated that functional audit data per incoming messages is 0,1KB, and is kept for 3+1 years for traceability purposes. The storage is calculated assuming the volumetric constraints in section 10.4.

Table 10: Audit and logging storage

9.6.3 Archiving storage Once the lifecycle of the ENS has finished, there is no need to keep the messages from and to the Economic Operator readily available, and can be archived outside the operational database. The sizing is estimated as follows:


Signed messages from and to the Economic Operators

4 TB 14 TB 27 TB The signed and compressed messages will be stored for 10 years. ENS data older than 10 years will be purged (deleted) from the ICS2 STI Component to meet legal requirements. The storage is calculated assuming the volumetric constraints in section 10.4.

Table 11: Archiving storage



9.7 Information System Position Statement

For Economic operators

Who are lodging and processing all required formalities regarding entering of goods into the territory of the European Union

the (Information System name) The Shared Trader Interface is a component of the ICS2 trans-European system

That supports the fulfilment of the Objectives 1 and 2 of the EU Risk Management Strategy by providing an implementation of a harmonized interface with the Economic Operators

Unlike ICS 1,

our Information System will provide services needed for entering of goods into the territory of the European Union, in such a way that satisfies the UCC regarding the new Risk Management Objectives.

Our Information System has a Confidentiality level

LIMITED HIGH

Our Information System has an Integrity level

CRITICAL

Our Information System has an Availability level

STRATEGIC

Our Information System has a Security classification

SPECIFIC

9.8 Dependencies ICS2 STI will depend on the following systems, and it is assumed that these systems will be functional and available when the ICS2 STI component is deployed in the testing and production environments.

Central Application

Status Integration needs

UUM&DS User-to-system exists, System-to-system and digital signature services are under development

ICS2 STI will use UUM&DS for authentication, identification and authorization of Economic Operators’ users, as well for allowing them to digitally sign a message, in the context of user-to-system interaction. It will use UUM&DS for authentication, identification and authorization of Economic Operators, as well for validating the digital signature of their messages, in the context of system-to-system interaction.

CCN2 Existing The CCN2 services of federated user management, security enforcement, routing of requests and one-way messaging pattern services are used. It is assumed that CCN2 will be able to handle the volume of messages as specified in section 11.6.

The CCN2 Performance and HA/DRP capacity will be scaled for ICS2 project

CS/RD2 Existing ICS2 STI will use the Central Services/Reference Data System as the source for the consultation of code lists and custom office lists.

TARIC3 Existing ICS2 STI will use the TARIC3 system to consult information on goods.

TSOAP Existing, to be scaled up

TSOAP will be used to host STI, it will have to be scaled up to reach non-functional requirements of STI Release 2

TATAF NG Existing, to be adapted

ICS2 STI will use TATAF NG modules, some of the TATAF NG modules may need adaptation for the STI project



Central Application

Status Integration needs

CRS Existing ICS2 STI will use the CRS system to validate Economic Operator identifiers (EORI and MRA).

GTP Under development

The ICS2 STI will use the Generic Trader Portal system to expose a graphical user interface module to the Economic Operators.

AS4 Implementation

Existing The ICS2 STI will use the AS4 protocol with an implementation compliant to eDelivery AS4 profile specification .

Table 12: Dependencies



10 Constraints This chapter identifies the Legal and Regulatory Restrictions that are applicable, as well as the high-level Security Requirements and Data Protection Constraints. The final section defines the classification levels of the project.

It addresses the measures required to assure the Confidentiality, Integrity and Availability of the information processed by the ICS2 STI application as well as the volumetric constraints.

10.1 Legal, Regulatory Restrictions and Applicable Documents The adoption of regulation (EU) No. 952/2013 of the European Parliament and the Council laying down the Union Customs Code provides the necessary initial legal steps (UCC Article 127(6)) to address the identified problems in data quality of the issued Entry Summary Declaration (ENS) data (i.e. multiple filing).

Furthermore, the system must meet the EU legal requirements for the protection of data, respecting the category of data security classification. The applicable documents are the following:

- Regulation (EC) No 45/2001 of the European Parliament and of the Council of December 2000 on the protection of individuals with regard to the processing of personal data by the Community institutions and bodies and on the free movement of such data [45/2001];

- Personal Data protection REGULATION (EU) 2016/679 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation);

- Commission Decision (EU, Euratom) 2017/46 of 10 January 2017 on the security of communication and information systems in the European Commission: this text lays down the basic principles and responsibilities relating to IT security in the Commission. This Decision will be supplemented by new Implementing Rules in 2017; currently, the previous Implementing Rules and Standards adopted under its predecessor, C(2006)3602, remain valid (except where they conflict with the new Decision;

- REGULATION (EU) No 952/2013 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 9 October 2013 laying down the Union Customs Code [UCC] (UCC Article 12);

- UCC IT Security Policy. This is the IT Security Policy for the Trans European Systems (TES) developed and used as a support to the Union Customs Code (UCC) legislation [UCC/MCC- SEC];

- TEMPO Information Security Policy. This is the Information Security Policy applicable to all Information Systems under the responsibility of DG TAXUD [TAXUD-SEC].

10.2 Security Constraints The security constraints that apply to the ICS2 STI Component are described below.

10.2.1 Organisational In accordance with the Article 12 [UCC] the information acquired by the Member State’s customs authority or the Commission in the course of performing their duties in relation to ICS2 STI are provided on a confidential basis and is covered by the obligation of professional secrecy.

All phases within the ICS2 STI development lifecycle will perform activities from the security perspective as defined in the overall ICS2 Security Plan.

The operations will be assigned by DG TAXUD to the ITSM external contractor.

The ICS2 business continuity plan will provide the different measures to be taken for business continuity for the ICS2 overall system and for the ICS2 STI in particular.

10.2.2 Confidentiality Traceability and Accountability Least Privilege Principle. The users SHALL have the minimum of user access rights, strictly necessary for the accomplishment of their tasks.

Need to Know Principle. A user SHALL NOT have access to information of the information system as such unless he/she has a specific need for the information (need to know). Access to the information MUST be necessary for the conduct of one's official duties, applicable to them in carrying out their duties, on a need to know or need to access principle basis.

Note that the Least Privilege and Need to Know principles result in expressly permitting access to information: to reduce opportunities for unauthorised or unintentional modification or misuse of information, access to information and the information system is limited to authorised persons, applicable to them in carrying out



their duties. Users shall access only that information for which they have been granted explicit authorisation. Access rules SHALL be preceded from the assumption that all is forbidden unless it is expressly permitted.

Accountability. A user is responsible and accountable for actions done with his/her credentials even if these actions were carried out by another individual using these credentials, if it is demonstrated that the user provided his credential to the other user or if it is demonstrated that the user has neglected protecting the confidentiality of his/her credentials.

Audit logs recording user activities, exceptions and other security-relevant events shall be produced and kept by the ICS2 STI component for a minimum of 4 years (3 years plus the current year) to assist in future investigations and access control monitoring. These logs shall record sufficient information to allow for full accountability and traceability of events. Each MS will be able upon request to access this Audit/Trace data in the context of assuring the transparency of the business scope.

Non-repudiation services shall be incorporated to facilitate the resolving of any disputes about occurrence or non-occurrence of an event or action.

10.2.3 Integrity The system must guarantee, keep and support the integrity and consistency of data processed in the system in order to detect any corruption of information either deliberate or unintentional.

10.2.4 Availability The system shall be resilient and protected against intrusion, denial of service and other acts of sabotage or negligence, in line with the system security classification level.

10.2.5 Data Encryption Transport level encryption must be enforced to protect all information communicated/transmitted between the ICS2 STI Component and the Economic Operator systems. No transport level encryption is needed for communication over the internal network within the datacentre.

The data at rest in the ICS2 STI will not be encrypted.

10.2.6 Access scope The ICS2 STI Component shall ensure that it will only be accessed by authorized EOs for ENS filing and related function purposes. The EOs will only be able to access the ENS data that they are authorized for (only their own data or the data of the EO they legally represent).

Furthermore, Member State and Commission users will access the ICS2 STI Component according to the assigned authorisation grants.

10.2.7 User access management The ICS2 STI Component will integrate with UUM&DS (Uniform User Management and Digital Signatures) and CCN2 for authentication and authorisation.

UUM&DS will manage the Trader and the Commission users. CCN2 will manage the Member State users.

10.3 Data Protection Constraints The ICS2 STI Component will be designed in compliance with the Article 12 of the Union Customs Code (REGULATION (EU) No 952/2013 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 9 October 2013), Personal Data protection Regulation (EU) 2016/679 which regulates the protection of individuals with regard to the processing of personal data and the free movement of such data which is implemented into national law and applicable to all EU Member States and Regulation (EC) No 45/2001 which lays down the same rights and obligations, but on the level of the EU institutions and bodies. Where applicable, appropriate consideration will be given to data minimization (minimal processing of personal data), data retention (automatic review/deletion of personal data after a specific period of time), putting in place appropriate security measures and building privacy statements into the system to inform the uses that their personal data is being processed.

10.3.1 Data protection checklist: Data protection checklist Yes No

1 Does this application process any data allowing the identification of an individual person?

Process means as well as to collect, structure, format, file, transform, store,

https://secure.edps.europa.eu/EDPSWEB/edps/site/mySite/lang/de/Legislation



transfer data on any kind of media.

2 Personal data is extracted or imported from another Information System. Name: CRS DG: TAXUD This Information System is notified to the DPO The other Information System owner given his agreement?

3 Personal data is manually collected

4 Personal data is collected on-line

5 Nature and origin of personal data:

Medical, assessment, social, e-monitoring, log;

Other nature;

External citizens, other EU Institutions;

EU Economic Operators;

Commission Staff.

6 Does any new version of the application have an impact on the currently notified processing?

10.3.2 Conclusion Based on the answers to the checklist the conclusion is that: Yes No

1 The system/application foresees to process personal data

In conclusion, the ICS2 STI Component foresees to process personal data, a notification in compliance with Regulation 45/2001 will be prepared during the Elaboration phase of the project.

10.4 Volumetric Constraints The ICS2 STI Component will need to manage the submission, reception, validation and processing of 100 million ENS filings per year in the first phase, 193 million in the second phase and 282 million in the final phase (figures are incremental). Please note that the figures for the postal (air) ENS filings are still to be confirmed.

Assuming a distribution where most messages are issued during business days and business hours, the ICS2 STI Component will receive 7 ENS filings per second in the first phase, 19 in the second phase and 27 in the third phase. Peak submission rates are expected to be 23 ENS filings per second in the first phase, 64 in the second phase and 108 in the final phase.

The average ENS filing size is assumed to be 6.600 bytes for partial/full ENSs. These estimates are based on constructed message samples, extrapolation from an ICS1 message sample, and the best knowledge of the experts. In the system-to-system interface, ENS filings are assumed to be grouped by 10 filings per message on average.

Although theoretically the proposed AS4 protocol does not limit the message size, a maximum message size will be defined to allow a correct sizing of the infrastructure needs.

Additional messages received by the ICS2 STI Component are responses to requests as defined in the business processes supported. The ICS2 STI Component sends responses as well to Economic Operator submissions, and notifications on changes in the ENS lifecycle. The response submission rates are estimated at twice the submission rates of the Economic Operators.

It is assumed that the volume of business and technical exceptions to be handled because of bad data quality or other process exceptions shall be close to the rate of error messages in ICS phase 1 – i.e. below 1%.



11 Quality Ranges and Information System Requirements 11.1 Availability and Integrity The ICS2 STI Component must be available 24 hours per day, 365 days per year (24x365) with a very limited unscheduled downtime according to the overall business availability requirements. In case of a system failure a fall-back procedure will need to be defined according to Art. 6 (3) (b) UCC. This fall-back procedure will be specified in the ICS2 business continuity plan which will provide the different measures to be taken for business continuity for the ICS2 overall system and for the ICS2 STI in particular.

Downtime due to maintenance activities and the deployment of a new application version will be avoided to the maximal extend possible by following the zero-downtime principle. Any other maintenance activity where this principle cannot be achieved will take place in an allocated service window of maximum 1 hour per week and will be planned and announced in advance.

Outside the maintenance window, the availability of the ICS2 Shared Trader Interface Component will be of 99,25% for STI Release 1 and 99.45% from STI Release 2 onwards. The target availability is a combination of the availability of the different components as defined in Table 13 below.

Component Target availability STI Release 1

Target availability STI Release 2 and 3

Data Centres Availability (see below for more details) 99,6% 99,8%

CCN2 Platform Availability 99,7% 99,7%

UUM&DS Availability 99,95% 99,95%

Combined availability 99,25% 99,45%

Table 13: Target availability

The two DG TAXUD datacenters have a high-availability infrastructure for all layers from network access up to application layer, also using global and local load balancers. Current setup allows active/passive disaster recovery between the primary datacenter located in Drosbach and secondary datacenter in Kayl (both in Luxemburg). DG TAXUD plans to achieve an active/active double datacenter setup as to increase high-availability and load capacity.

Due to high concurrency and high bandwidth requirements for database access, active/passive cluster configuration will be used for this layer. High-availability will be enforced with a standby database on the second DC with real-time replication keeping the databases synchronized.

For achieving the high-availability requirement of the data centres, DG TAXUD plans an increase of the service level as specified in the table below. The silver service level will be available as from Q4 2017 and will consequently be used for STI Release 1.

For gold service level, further improvements will drastically reduce the disaster recovery time and maximum downtime. Given that the gold service level requires considerable funding not available under the current Customs 2020 budget provisions this service level will be effective by Q3 2022, assuming that funds are available in Q1 2021 to build the needed capacity. This implies that the gold service will be effective as of STI Release 2, provided that the required funding is made available.

Q4 2017 Q3 2022

Applications (Software) 99,85 99,90

Platform (COTS Middleware) 99,88 99,95

Operating System 99,92 99,97

Network 99,95 99,98

Building & Facilities 99.995 99.995



Combined 99.6 99.8

Service Silver Gold

Max. downtime (per month) 3h 1.3h

Disaster Recovery time 6h 60min

Table 14: DC Availability at the different layers according to availability levels (Silver/Gold)

In case of unscheduled unavailability, the RTO16 (max of downtime and disaster recovery time) for silver service level is 6 hours and for the gold service level is 1.3h. To ensure integrity, the RPO17 requested by the business is 0 hours, however this request for a zero RPO must be requalified in light of the design, financial and technological feasibility constraints.

Furthermore, interaction with dependent legacy non-high-availability components such as the TARIC3 system must be decoupled.

The availability of the ICS2 STI Component must be decoupled from the availability of the ICS2 CR system component. This means that the interaction between the systems must be asynchronous, and the CCN2 communication platform must be able to buffer messages until the system is available again. This buffer must be configurable and scalable.

11.2 Usability The ICS2 STI Component must be easy-to-use. The user interface of the ICS2 STI will be delivered in English but shall be able to support all other official languages of the EU once the translations are provided by the MS customs authorities for their official languages.

11.3 Maintainability The system shall be designed for high maintainability. All parameters of the system shall be configuration-driven and modifiable without recompilation and unavailability of the system. Furthermore, the COTS that are going to be used are to be assessed in function of their specific maintenance capabilities.

11.4 Applicable Standards The interface to the Economic Operators will be compliant with the OASIS standards AS4 and ebMS 3.0, which composes the fundamental Web Services standards SOAP 1.1, SOAP 1.2, SOAP with Attachments, WS-Security, WS-Addressing, and reliable messaging (WS-Reliability 1.1 or WS-ReliableMessaging 1.2). The client software must be compliant with the following software infrastructure: An Internet browser compliant with HTML5 and CSS3.

11.5 System Requirements

11.5.1 Storage The relational database management system of the DG TAXUD platform (currently Oracle 12c RAC) will implement this component, configured for multi-datacentre high-availability and disaster recovery, following the timetable in section 11.1.

This system is horizontally scalable, having the ability to add instances in case of higher load.

16 The recovery time objective (RTO) is the maximum tolerable length of time that a computer, system, network, or application can be down after a failure or disaster occurs.

17 The recovery point objective (RPO) is the age of files that must be recovered from backup storage for normal operations to resume if a computer, system, or network goes down as a result of a hardware, program, or communications failure



11.5.2 Application server This component is the Java EE applications server, which is the container for the ICS2 STI application. Oracle WebLogic is the underlying Java EE application server supporting the DG TAXUD SOA platform.

11.6 Performance Requirements The ICS2 STI Component will need to guarantee to be able to handle the volume of ENS messages (complete and/or partial ENS filings and related notifications and responses) that are expected to be received from trade during the ENS Lifecycle process as elaborated in 10.4.

11.6.1 Scalability The ICS2 system must be designed such that it can scale in function of increased number of users and increased transaction and data volume without changing the technical architecture and without downtime, in order to allow a smooth transition to the 3rd and final phase.

This will include among other design decisions the use of stateless services to encapsulate business logic which can be horizontally scalable. Services will be deployed on clustered application servers. State will be managed in the database alone, using a horizontally scalable database solution (Oracle RAC). All other components (queues, cache, schedulers, …) must be deployable in a distributed way and must be horizontally scalable.

11.6.2 Network capacity The following table summarizes the estimated data exchange volumes for STI Releases 1, 2 and 3 based on the volumetric constraints defined above.

Network Bandwidth STI R1 Bandwidth STI R2 Bandwidth STI R3

With the EO systems External 0,4 Mbps (peak 1,4) 1,3 Mbps (peak 5,1) 2,4 Mbps (peak 9,6)

With the ICS2 CR system Internal 0,3 Mbps (peak 1,3) 1,2 Mbps (peak 4,8) 2,4 Mbps (peak 9,4)

With the Common Reference systems

Internal Negligible Negligible Negligible

With UUM&DS Internal Negligible Negligible Negligible

Table 15: Network capacity

11.6.3 Concurrent requests The term “concurrent requests” used below is technical and means total number of humans/systems making request to the system within a predefined period (1 second). This is different from the number of simultaneous users (humans or other systems) using the system, which typically is far higher than the concurrent requests. This technical parameter is important to be estimated to assure provision of proper hardware and software architecture at the peak loads of the system.

The users of the ICS2 STI Component are the Economic Operator users using the graphical user interface, the Economic Operator systems, and the member state users.

The following table summarizes the requirements to support concurrent users for the ICS2 STI Component based on the current estimates.

Concurrent requests STI R1



EO users on the UI n/a 1 1

EO S2S systems 20 60 99

MS helpdesk users 5 5 5

Table 16: Concurrent requests/second

The following table summarizes the expected total number of STI users. More information is required to establish a more accurate estimate for the number of User Interface (UI) EO users and EO S2S access points for the STI releases 2 and 3.

STI R1 STI R2 STI R3



EO users for the UI n/a More info required More info required

EO S2S systems 30-40 (Express and Postal)

More info required More info required

MS helpdesk users 50-60 (2 per MS) 90-100 (3 per MS) 90-100 (3 per MS)

MS customs officials 90-100 (3 per MS) 150-180 (5 per MS) 150-180 (5 per MS)

Commission helpdesk users 3-5 5-10 5-10

Table 17: Expected total number of STI users

11.6.4 Response times The ICS2 STI Component must respond in a reasonable timing to both the Economic Operator systems and to the requests from the user interface.

The system to system implementation must guarantee a throughput such that the maximum response time of the ENS filing registration and the MRN allocation doesn’t exceed 120 seconds. It is expected that average response time should be around 1s; a more the specific estimates will be provided when the final HTI specification is available.



12 Licensing and Installation

The Shared Trader Interface will be based on COTS components to be determined during the individual

Elaboration phases. The budgetary estimates for licence costs are provided in Chapter 8.

In the definitive setup (block 1b setup), the Share Trader Interface will be installed in the DG TAXUD Data

Centres in an Active / Active deployment distributed over two data centres to address the high availability

requirements.

The following environments are to be envisaged:

Environment Count Comment

Production 1 One environment on two data centres, with clusters per

layer.

Conformance Test 1 Similar to production, but with reduced processing

capacity and without HA option.

The Conformance test environment will be available to

the Economic Operators.

Integration Test 1 Integration testing

Training 1 Member state testing; prior to conformance testing.

Site Acceptance Test 1 preSAT/SAT, performance and High Availability testing.

Factory Acceptance Test 3 preFAT/FAT

FAT Integration

Pre-production (supporting the incident management

process)

Development 1 Developers environment

Table 18: Environments List



13 ANNEX 1: DOCUMENT HISTORY

Version Date Comment Modified Pages

1.00 31/10/17 Version issued to the ITSC All

1.01 31/10/17 SfR version issued by the CUSTDEV3 contractor All

1.02 13/11/17 Internal version All

1.03 14/11/17 Version for review to ECCG, RIMSCO and TCG All



14 ANNEX 2: VISION DOCUMENT GLOSSARY

The glossary below provides the reader with an overview of terms used throughout this vision document.

Term Description

AS4 AS4 is a Conformance Profile of the OASIS specification and represents an open standard for the secure and payload-agnostic exchange of Business-to-business documents.

CAPEX Capital Expenditure

CBG Customs Business Group

CCN Common Communication Network

CDMS Customs Decisions Management System

CEAF The Commission Enterprise Architecture Framework. It shows from each stakeholder’s perspective (business or IT) the blueprint of all aspects involved in constructing information systems and how they relate.

CEF Connecting Europe Facility

CEG Customs Expert Group

CIRCABC CIRCABC is a collaborative platform, which offers an easy distribution and management of documents.

COM Commission

COTS The term Commercial off-the-shelf product (hardware or software) refers to readily available products that can be acquired from the market (instead of being developed in-house).

CPG Customs Policy Group

CRM Customs Risk Management

CRS Customs Reference System

DC or Data Centre

The Data Centre concerns the provision of hosting facilities (infrastructure, hardware, software, network, etc.) to run and operate the information systems.

DIGIT Directorate-General for Informatics

DPC Data Protection Commissioner

DPO Data Protection Officer

EBMS 3.0 Electronic Business using eXtensible Markup Language Messaging Services 3.0

EC European Commission

ECCG Electronic Customs Coordination Group

EDIFACT Electronic Data Interchange for Administration, Commerce and Transport

eDelivery The eDelivery building block helps public administrations to exchange electronic data and documents with other public administrations and businesses in an interoperable and secure way

EIS European Information System

ENS Entry Summary Declaration

EORI Economic Operator Registration and Identification

EOS Economic Operators System

FAT Factory Acceptance Testing

FTE Full-Time Equivalent. One FTE indicates the equivalent work of one full-time person. A half FTE indicates the equivalent work of a half-time person, and so on.

GTP Generic Trader Portal

HRCM High Risk Cargo and Mail

HTI Harmonized Trader Interface

HTTPS Hypertext Transfer Protocol Secure



IAM Identity & Access Management

ICS Import Control System

IFPUG International Function Point Users Group

INEA Innovation and Networks Executive Agency

Information System

A system, whether automated or manual, that comprises people, machines, and/or methods organised to collect, process, transmit, and disseminate data that represent user information

IPG Information Providers Guide

ITIL Information Technology Infrastructure Library

ITSC IT Steering Committee

ITSDG IT Systems Development Group

ITSM IT Service Management

MASP Multi-Annual Strategic Plan

MRA Mutual Recognition Agreement

MRN Master Reference Number

NRR Non-Repudiation of Receipt

NTI National Trader Interface

OPEX Operational Expenditure

PCG Programme Coordination Group

PKI Public Key Infrastructure

Programme The term Programme often refers to the collection of projects aimed towards the same goal (e.g. the ABAC programme which comprised many projects to realise the introduction of an accrual based accounting in the Commission).

Project

Projects are performed by people, constrained by limited resources, and planned, executed, and controlled. A project is a temporary endeavour undertaken to create a unique product or service. Temporary means that every project has a definite beginning and a definite ending. Unique means that the product or service is different in some distinguishing way from all similar products and services. Projects are often critical components of the performing organizations' business strategy.

RAC Real Application Clusters

RDBMS Rational Database Management System

REX Registered Exporters

RIMSCO Risk Management Strategy Implementation Coordinating Group

RPO Recovery Point Objective

RTO Recovery Time Objective

RUP Rational Unified Process

S2S System to System

SAT Software Acceptance Testing

SDLC Software Development Life Cycle

SLA Service Level Agreement

SOA Service Oriented Architecture

Stakeholder An individual who is materially affected by the outcome of the information system. Stakeholders of an information system (amongst others) are : the business units, the users of the system, the supplier of the system, etc.

STI Shared Trader Interface

STORK Secure idenTity acrOss boRders linKed

TAXUD Directorate-General Taxation and Customs Union

TCG Traders Contact Group



TCO

Total Cost of Ownership. The TCO of an information system defines the total estimated cost to develop the system, to put it into production, to operate it, to support it, to maintain it, to phase it out at the end, etc. The cost estimation is as comprehensive as possible and should include all costs from the very inception of the system until its phase out.

TEMPO Quality Management System of DG TAXUD (Taxud Electronic Management of Projects On-line)

TES Trans European Systems

TOC Terms of Collaboration

TSOAP TAXUD SOA Platform

U2S User to System

UCC Regulation (EU) No 952/2013 of the European Parliament and of the Council of 9 October 2013 laying down the Union Customs Code

UPU Universal Postal Union

UUM&DS Uniform User Management & Digital Signatures

WAN Wide Area Network

XML eXtensible Markup Language

XSD XML Schema Definition



15 ANNEX 3: REFERENCES

Id Title Reference Version Date

R01 Business Case UCC new Import Control System (ICS2)

N/A 3.1.1 27/06/2017

R02 Transition Strategy & Plan

Import Control System (ICS2)

N/A 1.00 To be reviewed by the MS as from 17/11/2017

R03 ICS Common Repository Vison document

ARES(2017)2626310 2.0 12/05/2017

R04 Shared Trader Interface Project Proposal

ARES(2017)2826621 N/A 06/06/2017

Electronically signed on 15/11/2017 09:47 (UTC+01) in accordance with article 4.2 (Validity of electronic documents) of Commission Decision 2004/563