Customs action at the external border plays an essential role in protecting citizens and the internal market against safety and security threats. Advance cargo information and risk analysis will enable early identification of threats and help customs to intervene at the most appropriate place in supply chain.
For customs purposes, security and safety risks cover a range of issues including explosives in air cargo, narcotics, precursors, dangerous fake medicines, dangerous toys or electronics, contaminated foods, weapons, and all types of organised smuggling.
New threats like postal delivery of lethal synthetic opiates are now emerging. Organised groups use entry point shipping and arrange their supply chains to evade detection, innovating on a continuous basis.
At the same time, the volume of consignments supervised by customs is multiplying due to changes in the global trade business models generated by e-commerce. New advance data for goods in postal consignments will offer new opportunities as well as challenges.
ICS2 is a large-scale EU information system supporting the following
processes:
- lodging of the Entry Summary Declarations - ENS (advance cargo information) to customs;
- security and safety risk analysis by customs;
- arrival of means of transport;
- presentation of goods to customs authorities and control by the customs authorities of goods, where necessary.
ICS2 is not an import system and it is not used to process the customs
declarations for release into free circulation.
Entry of the goods into the EU is a 5-step process, consisting of:
- Lodging of the Entry summary declaration (ENS);
- Notification of the arrival of the means of transport;
- Presentation of goods;
- Temporary storage of goods and;
- Placing the goods under a customs procedure.
ICS2 business process scope covers three steps out of five: lodging the ENS, the notification of the arrival of the means of transport and the presentation of goods.
ICS2 will support the communication of advance cargo information for safety and security risk analysis on the entry of goods into the EU for the following transport modes: maritime, air, road, rail and inland waterways. General cargo, express and postal business models will also be affected by ICS2.
No. ICS2 will fully replace ICS1 with an entirely new business process in accordance with the Union Customs Code legal requirements and the strategic operational needs expressed in the EU Customs Risk Management Strategy and Action Plan (adopted in 2014). Furthermore, ICS2 enables multiple filing of advance cargo information for application of Article 127 (6) of the Union Customs Code and involves more supply chain actors and business models as per Article 127 (4) of the Union Customs Code, with the goal of collecting better quality and timely data related to the goods supply chains.
They will operate in parallel for a limited period of time. After the roll-out of ICS2 Release 3 on 1 March 2024, ICS1 will be phased out after a transitional period of 200 days.
The ICS2 Transition Strategy and Plan foresees implementation of the new system and consequently new Entry Summary Declaration requirements and related business and risk management processes in three operational releases.
- Release 1: Express carriers and European based postal operators and Third-country postal operators shipping to Europe – Pre Loading Advance Cargo Information (PLACI) using the minimum ENS dataset;
- Release 2: Postal operators, express and air carriers and freight forwarders – Operators have to complete ENS dataset for all goods in air transport;
- Release 3: Operators carrying goods on maritime and inland waterways and roads and railways – Carriers in these transport sectors have to complete ENS dataset for all goods in these sectors, including postal and express consignments.
- Release 1:
- Lodging of pre-loading minimum data set (PLACI) for air express and postal consignments;
- Presentation process for postal consignments.
- Release 2:
- Lodging of the complete ENS for all goods in air traffic;
- Lodging of the arrival notification for all goods in air traffic;
- Presentation process for air express consignments and general air cargo.
- Release 3:
- Lodging of the complete ENS for maritime and inland waterways, road and rail traffic (this includes goods in express and postal consignments transported in these means of transport);
- Lodging of the arrival notification for maritime and inland waterways;
- Presentation process for all goods on all modes of traffic.
An express consignment is a single item conveyed by or under the responsibility of an express carrier.
An express carrier is an operator providing integrated services of expedited/time- definite collection, transport, customs clearance and delivery of parcels whilst tracking the location of, and maintaining control over, such items throughout the supply of the service.
Entry Summary Declaration (ENS) is the act whereby a person informs the customs authorities, in the prescribed form and manner and within a specific time limit, that goods are to be brought into the customs territory of the Union.
ENS filing means either partial or full ENS data set required by the legislation per specific mode of transport or business model.
A multiple filing means that an ENS is composed of two or more partial ENS filings (i.e. two or more prescribed data sets), which together form an ENS declaration.
PLACI refers to a specific type of partial ENS filing, which is the mandatory minimum dataset (‘7+1’) to be filed as soon as possible prior to loading of the goods onto the aircraft in a third country. It is limited to air traffic only and covers all goods (i.e. general cargo, express consignments and postal consignments).
Pre-loading indicates the phase before the goods are loaded onto the means of transport that will bring them into the customs territory of the European Union.
Pre-arrival indicates the phase before the means of transport arrives in the customs territory of the European Union.
In general, the carrier bringing the goods into the customs territory of the European Union is obliged to lodge an ENS for those goods [Article 127 (4) UCC]. When the carrier does not have all legally required particulars of the ENS at its disposal, those particulars are to be filed by the person who holds those particulars and did not share them with the carrier. This will eventually enable the carrier to lodge a complete ENS [Article 127 (6) UCC; case of multiple filing].
Depending on the mode of transport, the ENS is to be filed within the following time limits:
Transport by sea
a) At the latest two hours before the arrival of the vessel at the first port of entry into the Union in case of goods coming from Greenland, Faeroe Islands, Iceland, ports on the Baltic Sea, Black Sea, Mediterranean Sea or Morocco;
b) The same two hours apply in cases where the goods are coming from other third country territories and enter the customs territory of the Union, the French overseas departments, the Azores, Madeira or the Canary Islands and the duration of the vessel’s journey is less than 24 hours;
c) At the latest four hours before the arrival of the vessel for bulk cargo in other cases than a) or b) above;
d) For containerised cargo in other cases than a) and b) 24 hours before the goods are loaded onto the vessel which will bring them into the customs territory of the Union.
Transport by air
e) The ENS, or when it is not possible, the minimum data set for air pre-loading, shall be lodged as early as possible but at the latest before the goods are loaded onto the aircraft which will bring them into the customs territory of the Union;
f) When only minimum data set was lodged under (e), the complete ENS shall be lodged at the time of actual departure of the aircraft when the duration of the flight is less than four hours;
g) For other flights than those mentioned under f), the complete ENS is to be lodged four hours before the arrival of the aircraft at the first airport in the customs territory of the Union.
Transport by rail
h) When the train voyage takes less than two hours from the last train formation station outside the customs territory of the Union to the first point of entry into the customs territory, the ENS is to be lodged at the latest one hour before the train arrives at the border entry point of the Union;
i) In other cases than those mentioned under h), the ENS is to be lodged at the latest two hours before the train arrives at the entry point of the Union.
Transport by road
The ENS shall be lodged at the latest one hour before the goods arrive at the entry point of the Union.
Transport by inland waterways
The ENS shall be lodged at the latest two hours before the goods arrive at the entry point of the Union.
ICS2 introduced the role of Sender, which consists of the system actor that technically constructs and exchanges the messages with the STI in accordance with the ICS2 message specifications. To guarantee integrity, and the non-repudiation of origin and receipt, the party acting as a Sender must register a digital certificate used to seal the exchanged messages in the UUM&DS system under its EORI.
The Sender can be the declarant/representative itself or it can be an IT Service Provider (ITSP) contracted by the declarant/representative. To be noted is that in such case, the declarant/representative remains declarant/representative. The ITSP is a technical actor that is also identified by an EORI as used in the technical AS4 message header.
An ITSP is any party that delivers IT Services to a declarant/representative by operating an AS4 access point as a Sender. An ITSP must be identified (EORI & digital certificate) and registered in UUM&DS to be authorized to exchanges messages with the Shared Trader Interface (STI).
Therefore, a party that provides a Software as a Service (SaaS) platform to an ITSP, or to a declarant/representative, is not an ITSP. It only provides technical components that require additional specific operational configuration to properly function as a Sender. This configuration occurs under the responsibility of the ITSP or declarant/representative that procured the SaaS services. (ICS2 requirements for this configuration are documented in ICS2 Interface Control document)
No. Only parties that operate an AS4 access point as a technical ‘Sender’ of ENS filings must register a digital certificate in UUM&DS. A Sender is understood as a system actor in the context of the ICS2 system and is authenticated and authorized from the system security point of view to exchange messages with the STI. The declarant/representative that uses an IT Service Provider (ITSP) doesn’t need a digital certificate registered in UUM&DS. Only the declarant/representative EORI included in the business payload of the messages needs it.
Release 1 and Release 2 messages are distinguished based on XML namespaces and WSDL end-points.
- For Release 1:
The business payload (e.g. IE3F32) is in the xml namespace "urn:wco:datamodel:WCO:CIS:1".
The Economic Operator will set the eb:AgreementRef at AS4 level to “EU-ICS2-TI-V1.0”.
The webservice end points for the interactions between CR-NES all refer to ‘V1’ versions (e.g. xmlns= http:// xmlns.ec.eu/BusinessActivityService/ICS/IRiskAnalysisOrchestratio...V1).
- For Release 2:
The business payload (e.g. IE3F32) is in the xml namespace " urn:wco:datamodel:eu:ics2:2".
The Economic Operator will set the eb:AgreementRef at AS4 level to “EU-ICS2-TI-V2.0”.
The webservice end points for the interactions between CR-NES all refer to ‘V2’ versions (e.g. xmlns= http:// xmlns.ec.eu/BusinessActivityService/ICS/IRiskAnalysisOrchestratio...V2).
The Release 1 and Release 2 flows are totally separated, both from a content perspective (business payload in different namespace) as well from a technical end-point perspective. Release 1 and Release 2 have different WSDL endpoints.
It will be feasible for the Economic Operators to lodge the ENS using EU Customs Trader Portal (EUCTP) ICS2 Shared Trader Portal (STI-STP): Economic Operator needs to have EORI number, Economic Operator needs to successfully log into EUCTP (STI-STP) via UUM&DS authentication and identification. The Economic Operator needs to fill all data required for ICS2 ENS filings as per Common Functional Technical Specification (available in CIRCABC).
Using STI-STP Economic Operator can also verify the status of their submission, make amendments to submitted ENSs, and configure preferences related to notifications and check notifications.
There is no need to register the IT Service Provider. The ITSP acts as Sender who is delivering the messages to STI on behalf of its clients.
The relation between the Economic Operator (airline company) and IT Service Provider does not need to be registered in anywhere.
On the other hand, in case of any legal dispute, IT Service Provider needs to prove to customs authorities that such relation was established during the period when messages were sent to ICS2.
The business content of messages will have to include both the airline company EORI number and the ground handling agent EORI number in respective ENS messages attributes, in this case:
- Airline company – would be declarant;
- Ground handling agent – would be representative;
- ITSP would be technical sender only in AS4 message.
All Economic Operators can find the publicly accessible EO self-conformance Testing related documentation on the public ICS2 Release 2 - Library (europa.eu).
For the smooth preparation prior to CT activities, Economic Operators should read and comprehend all the relevant documentation that has been provided to them:
- ICS2 EOs Common Technical System Specifications package for ICS2 Release 2 ICS2 Release 2 - Library (europa.eu)
- ICS2 Harmonised Trader Interface Specifications(SD-ICS2-HTI-Interface Control Document-SfA-v3.30.pdf), available at ICS2 Release 2 - Library (europa.eu)
Particularly, the consultation of the below documents is considered essential during the CT execution:
- Conformance Test Organisation Document (CTOD) for EO for Release 2 (TES-OTH-CTOD-ICS2-EO-R2 v1.20.docx), available at ICS2 Release 2 - Library (europa.eu)
- Test Design Specifications for EO Conformance Test Cases for Release 2 (ICS2-Economic Operator Conformance Test Cases-R2-v1.50.docx), available at ICS2 Release 2 - Library (europa.eu)
- Test Design Specifications for EO Conformance Test Scenarios for Release 2 (Economic Operator Conformance Test Scenarios-R2-v2.0.docx), available at ICS2 Release 2 - Library (europa.eu)
- Trainings that suggested to be provided by National Administrations to EOs:
- ICS2 Conformance Test;
- Digital certificates and registration of certificates;
- NA services and support to EOs.
- Other CT related material made publicly available:
- Self-Conformance Test (EO-CT), available at ICS2 Release 2 - Library (europa.eu)
- UUM&DS system: Your passport to EO applications (EO-UUM&DS), available at: Course: UUM&DS system: Your passport to EU applications, Topic: en (europa.eu)
In general, the latest accepted version of the EO Self-Conformance Testing related documentation is stored on: ICS2 Release 2 - Library (europa.eu)
An Economic Operator can access STI-STP through the following link: https://conformance.customs.ec.europa.eu/euctp - to go to the ICS2 Conformance test environment
An Economic Operator can access STI-STP through the following link: https://customs.ec.europa.eu/gtp/ - to go to the ICS2 Production environment
- Deploy one or more Access Point(s) according to HTI Interface Control Document specifications (SD-ICS2-HTI-Interface Control Document-SfA-v3.30.pdf ), available at ICS2 Release 2 - Library (europa.eu)
- Obtain a TLS certificate to be used at the transport layer (https) for identifying itself following the 2-way TLS security mechanisms;
- Obtain a sealing certificate to be used for sealing at message layer (see section 4.6.2 of the HTI Interface Control Document SD-ICS2-HTI-Interface Control Document-SfA-v3.30.pdf , available at ICS2 Release 2 - Library (europa.eu)
- Sender must be registered by customs authorities following the agreed national procedure. This includes the upload of the sealing certificate;
- Configure their own AS4 Access Point(s) in STI-STP:
- Log in on EUCTP and access STI-STP via UUM&DS authentication and identification;
- Select ''Manage Preferences'* from STI-STP menu;
- Add information on “Party Id definition”:
- Provide the Party ID (The Party ID format is defined in section 4.2.2.1 of the HTI Interface Control Document (SD-ICS2-HTI-Interface Control Document-SfA-v3.30.pdf), available at ICS2 Release 2 - Library (europa.eu)
- Define Message Exchange Pattern (“push” or “pull”);
- Provide the Endpoint (i.e., URL) (Available if the MEP is “push”);
- Provide the Certificate Authority that issues the TLS certificate;
- Insert Technical details (Name, Email address, Phone).
- Add information on “Default communication path”:
- Select Business domain (Postal, Maritime, Air, Rail, Road, Express);
- Select Communication path (UI, S2S);
- Party Id ID (Mandatory in case the communication path is S2S).
*User manual is provided as part of the STP application and supported by training material (to be delivered).
Each Economic Operator should obtain:
- A TLS (Transport Layer Security) certificate from a trusted Certificate Authority to be used at the transport layer (https) for identifying itself following the 2-way TLS security mechanisms. A trusted Certificate Authority (CA) in the TLS context can be a commercial CA trusted by DG TAXUD. The CA used need to be notified to DG TAXUD, but the certificate does not require registration;
- A digital certificate to be used for sealing at message layer, which should be registered in the National UUM&DS Application or in the Central UUM&DS Application. In case that an Economic Operator uses the services of an IT Service Provider, then this Economic Operator does not need to register this certificate since it will be done by its IT Service Provider.
The digital certificate for message sealing must be issued by a Certificate Authority (CA) that is on the official EU wide List of Trusted Lists (LOTL) or on the National Customs alternate list of the Member State to whom National UUM&DS would like to register this certificate.
The Certificate Authorities (CAs) on the LOTL can be divided into two categories:
- CAs that issue qualified certificates;
- CAs on the LOTL that issue non-qualified certificate for e-signature/sealing.
CAs for both categories are published in https://esignature.ec.europa.eu/efda/tl-browser/#/screen/home.
A certificate issued by the CAs on the LOTL can be used to perform registration at a National Customs Authority of any EU Customs authority. Alternatively, an EO can use a certificate issued by other CAs as long as the CA is present on the “National Customs Alternate List”. Certificates issued by such CA can only be used to perform the registration at National Customs Authority.
An EU Member State is responsible for managing the National Customs alternate list.
The actual content of LOTL is managed and published by each MS.
Considering that the registration of each Economic Operator’s system certificate is done in the corresponding National UUM&DS application, where neither DG TAXUD nor the contractors provide any access, the successful certificate registration may only be verified by the Economic Operator itself.
Nevertheless, the successful certificate registration is a precondition for the execution of all Economic Operator functional test cases. This means that, in case that the certificate was not correctly registered, TAPAS will return the EBMS:0004 exception with subcode: A001 to the Economic Operator and will not allow any further Economic Operator message exchange.
An Economic Operator can use the same sealing certificate that has been used for CONF as long as it is registered in UUM&DS, but it has to be registered also in UUM&DS in PROD.
The Economic Operator has to configure AS4 access point to sign (seal) the AS4 messages with the given certificate and should embed the full certificate path inside the AS4 message. This is established by configuring set-up to embed a wsse:BinarySecurityToken with a valueType attribute of type X509PKIPathv1 as per section 4.6.2 of ICS2 HTI – ICD (CTSS EO for R3 - SD-ICS2-HTI-Interface Control Document-SfA-v3.30.pdf) , available at ICS2 Release 2 - Library (europa.eu)
A certificate path is the chain of certificates from the Root Certificate of the CA - intermediate certificate issued by the CA/n - EO leaf certificate as issued by the CA. This is a critical aspect.
Certificate registration can be performed in one of the following ways:
1. Holder of the Key:
a. Log in as an Economic Operator (in the WAYF) and access Admin-Ext (in case of Central Certificate Management) or the relevant MS site (in case of Local Certificate Management);
b. Economic Operator registers the certificate using the certificate’s private key.
2. Not Holder of the Key: (process valid ONLY for Central Certificate Management)
a. Economic Operator creates a delegation to one of the employee;
b. Economic Operator shares public key with the employee;
c. Employee registers his own certificate (as Holder of the Key);
d. Employee logs in using the delegation from the Economic Opertor;
e. Employee registers the Economic Operator’s certificate (using the public key) and signs the registration with his own private key (from the certificate he has already registered).
The following URL redirects to an online course that provides Economic Operators with specific information about how to use the UUM&DS. Upon completion of the course, an Economic Operator will be able to confidently work with the UUM&DS and carry out delegation, certificate registration and authentication processes within the UUM&DS process flow.
Attend course by accessing the following URL:
https://customs-taxation.learning.europa.eu/course/view.php?id=494§ion=1
In the scope of Conformance Testing Campaign, an Economic Operator or a Customs Representative should have ‘STISTP_EXECUTIVE’ and/or ‘STISTP_CONFIGURATOR’ business profiles to grant the access rights of the required Shared Trader Interface – Shared Trader Portal (STI-STP) roles.
The user can subscribe to the notifications via ADMIN-EXT, in “Dashboard” section, select “My Notifications” and then select “Expiring user certificate”.
The user should check in due time that the certificate is active, also the user is responsible to renew it before its expiration date. This will ensure that there will be no interruption in operations due to certificate expiration.
- In case that an Economic Operator implements its own access point, then the Economic Operator holds both Sender and Declarant roles and should use its unique EORI number, in order to register its certificate and also use it in the functional payload (ENS filing);
- In case that an Economic Operator uses IT Service Provider services, then the IT Service Provider holds the Sender role and should register a certificate with its own EORI number. However, the Economic Operator still holds the Declarant role and should use its own EORI number for the ENS filing.
An EO should follow Annex II P-MODES SUMMARY from ICS2 HTI – ICD,
(CTSS EO for R3 - SD-ICS2-HTI-Interface Control Document-SfA-v3.30.pdf), available at ICS2 Release 2 - Library (europa.eu)
Specifically, Annex II includes all the required P-Mode configuration parameters. In addition, an Economic Operator should consult section 4.6.3 of the same documentation, which describes a particular configuration on the handling of the TLS certificates that cannot be expressed as a P-Mode parameter but is nevertheless an AS4 configuration element.
Such unique identifier is the eb:MessageId + the Content-Id of the part (In AS4 terms: eb:MessageId element value + eb:PartInfo@href attribute value of the given part).
According to ICS2 HTI – ICD (CTSS EO for R3 - SD-ICS2-HTI-Interface Control Document-SfA-v3.30.pdf), available at ICS2 Release 2 - Library (europa.eu) section 4.1.3.3, for an incoming user message the @mpc attribute should not be specified, thus, this results in the usage of the default MPC.
- In the messages sent to TAPAS, most EOs/ITSPs erroneously include the leaf certificate instead of the full certificate chain, (please check section 4.6.2 from the ICS2 HTI – ICD (CTSS EO for R3 - SD-ICS2-HTI-Interface Control Document-SfA-v3.30.pdf) available at ICS2 Release 2 - Library (europa.eu)).
- The receipt messages sent from an EO to TAPAS are wrongly signed (the empty SOAP body is not part of the signature). The receipt message occurs when an EO receives a user message from TAPAS. Then, the EO responds back with a receipt message indicating that it has successfully received the user message from TAPAS. The SOAP Body of this receipt message should be signed, otherwise TAPAS fails to validate the receipt messages received back and finally considers that the initial user message was never sent to the Economic Operator.
- The Economic Operator obtained a digital certificate and registered it in UUM&DS, however the selected security parameters are wrong, either hash function / signing algorithm or AgreementRef (“AgreementRef” is the parameter which defines which version of messages is used, for Release 1/ Release 2). ICS2 Interface Control Document (ICD) requires the use of the following hash function sha256 and signing algorithm rsa-sha256. See ICD section Annex 2 Section 6. Concerning “AgreementRef”, “EU-ICS2-TI-V2” is used for ICS2 Release 2 messages and “EU-ICS2-TI-V1.0” is used for Release 1 messages.
The Technical Message header ID number should be unique per declarant for each message sent by an Economic Operator. The LRN number should be unique too, otherwise the message will be rejected with an IE3N99. There is a requirement for Transport document (master level) to be unique for at least 1 year. For Transport document (house level) it is advised to be unique but it is not mandatory. Within the same house level ENS filing there should not be repetitive Transport document (house level) number. In F32 messages combination of Transport document (house level) and Reference number/UCR should be unique for at least one year.
In the STI, when the communication type is “TE”, it is validated against rule R3006.
The pattern, which the rule is checking is the following one:
ITU_E123_PATTERN = "^\\+(?:[0-9] ?){6,14}[0-9]$”
The pattern ^\+(?:[[0-9]] ?){6,14}[[0-9]]$ can be explained as three parts:
- A string is required in which the first character must be '+' (pattern part: \+);
- Then, a digit from 0-9 followed by a space character can be repeated minimum 6 times and maximum 14 times (pattern part: (?:[[0-9]] ?){6,14}).
Note that space character after a digit is not mandatory and can appear only one time.
- After that, a digit from 0-9 is required (pattern part: [[0-9]]).
Please find below some valid and invalid examples:
+3067493493 valid
+30 67493493 valid
+3 0 5 6 7 8 3 valid
+ 30 67493493 invalid (space character after '+')
+30 6743 invalid (digits after '+' are 5 and not 6, space is counted as one repetition with digit 0)
+30 1234567891011123 invalid (characters after '+' are 17, maximum length exceeded)
General note: Regardless the pattern, a valid international phone has the following format: +XX NNN XXXXXXX where XX = country code, NNN = city code, XXXXXXX = number.
As the ICS2 interactions with traders are asynchronous, validation of an incoming message can result in functional errors being detected after the reception. In that case, a functional error message is asynchronously sent to the sender. This message is defined as IE3N99 for a general validation error.
For all elements that contain timestamps, the values should be expressed in UTC format. This expression is the GMT zone followed by letter “z”. No local time zones or central European time should be used in that expression. An alternative way could be to use the local time followed by an offset (which points out the difference of that local time from the GMT). For more information, please refer to section of 4.2.1 of ICS2 HTI – ICD (CTSS EO for R3 - SD-ICS2-HTI-Interface Control Document-SfA-v3.30.pdf) available at ICS2 Release 2 - Library (europa.eu).
Structural issues with the system of the Economic Operator should be addressed to the National Service Desk where the Economic Operator has registered its EORI number.
The issues that are related with the certificates of an Economic Operator should be addressed in the National Service Desk where the certificates were registered. This will be in the majority of cases, the National Administration where the EORI number was registered but can differ from that sometimes, in particular when an IT Service Provider for operating an ICS2 access point is used for the submission of messages by the Economic Operator.
The National Service Desk is responsible for resolving any issue/incident that occurred or dispatch them to Central Service Desk. The responsible National Administration will share the information of the relevant tickets (that are registered in SYNERGIA ESS) with the Economic Operator.