FAQ

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:

1. Lodging of the Entry summary declaration (ENS);
2. Notification of the arrival of the means of transport;
3. Presentation of goods;
4. Temporary storage of goods and;
5. 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.

In the scenarios the carrier is acting as person filing (by lodging F20, F21, F27, F28, F29 or F10, F11, F12 and F13), then they will receive the notifications related to the messages filed (when applicable).

However, the economic operator (EO) will have to setup its default communication path and notification preferences via the Shared Trader Portal (STP). Then they will receive the notification via S2S or U2S, depending on what channel they used in the configured default communication path.

• IE3R01 (ENS Registration Response)
• IE3N01 (ENS lifecycle validation error notification)
• IE3N10 (Amendment Notification)
• IE3R07 (Invalidation Acceptance Response)
• IE3Q01 (Do Not Load request)
• IE3Q02 (Additional information request)
• IE3Q03 (High Risk Cargo & Mail screening request)
• IE3N04 (Additional information request notification)
• IE3N05 (High Risk Cargo & Mail screening request notification)
• IE3N07 (House consignment in incorrect state notification)
• IE3N08 (Control notification)
• IE3R08 (ENS Consultation results)
• IE3N09 (Authorized Economic Operator control notification)
• IE3N99 (Error notification)

Any EO operator (including carriers) not acting as person filing, who wants to receive notifications, should setup its preferences and “Default Communication Path” access point through the STP, via “manage preferences” section. The channel can be set to STP (related notification can be checked by STP application) or to S2S via which messages with notifications will be send.  
(Please bear in mind that to access and use the STP, any EO needs to be registered in UUM&DS).

Any EO who wants to access the STP, needs to be user of UUM&DS and needs to contact the National Administration who grants ICS2 STP related roles.

To learn more about UUM&DS, it is possible to attend the online course by accessing the following URL: UUM&DS system: Your passport to EU applications

Following roles are defined for STP:

• Economic Operator Declarant (EO-DECL)
• Economic Operator Representative (EO-REP)
• Economic Operator Configurator (EO-CONF)
• Person Notifying Arrival (EO-PNA)
• Notify Party (EO-NOP)

Please bear in mind that National Administrations Service Desk (NSD) could support EOs who are having issues with their UUM&DS account or STP access, for the setup of system configuration and notification preferences. For the additional information, please check related training video in CIRCABC - EU Advance Cargo Information System (ICS2) - EO STP

Both the person filing and the carrier (if known to ICS2 system, meaning, if carrier is not person filing but has their preferences correctly set in the ICS2 STP) will always receive the DNL notifications (IE3Q01) via the S2S, if that is the channel used to lodge the filing. Either way, the DNL notification will also be visible in the STP.

ICS2 system needs to know the details of the EO (primarily, the partyID) to determine how to dispatch the messages or notifications and will use the channel used by the person filing to dispatch messages. Meaning, ICS2 will dispatch the messages and notifications to the EO via S2S if that was the way the filing was lodged. Otherwise, will send the notifications via U2S if the U2S was the channel used by the person filing.

For notifications for EO that are not the person filing, the system will act depending on the preferences set by the actor via the STP)

By default, following notifications are send both via U2S and S2S channel

• IE3Q01 (Do Not Load request);
• IE3Q02 (Additional information request);
• IE3Q03 (High Risk Cargo & Mail screening request).

The system will act depending on the preferences set by the actor via the STP. Furthermore, if ITSP sends messages on behalf of EO (House level and Carrier) then it is acting as a sender and its communication channel is set by default to S2S interface of ITSP.

The following are optional notifications for Carriers that could be set in the STP:

• IE3N03 (Assessment Complete Notification),
• IE3N04 (Additional Information request notification),
• IE3N05 (High Risk Cargo & Mail screening request notification)
  (Please note that if Carrier acts as person filling those notification are sent anyway)

The EO should configure its preferences in STP to receive any notification, as the ICS2 system needs to know the partyID and the communication channel preferred by the EO in order to dispatch them.

Nonetheless, please bear in mind that in the case an ITSP is used or EO is using its own IT system to send S2S messages, all the notifications aimed to the person filing are by default sent via the same channel.  Furthermore, please note that the default settings for the carriers is that the notifications (IE3N03, IE3N04 and IE3N05) are disabled, therefore, to receive them, you need to login into STP and enabled them, even if the communication goes via S2S (the ITSP interface).

The following messages will always be sent to the person filing, when applicable:

• IE3R01 (ENS Registration Response)
• IE3N01 (ENS lifecycle validation error notification)
• IE3N10 (Amendment Notification)
• IE3R07 (Invalidation Acceptance Response)
• IE3Q01 (Do Not Load request)
• IE3Q02 (Additional information request)
• IE3Q03 (High Risk Cargo & Mail screening request)
• IE3N07 (House consignment in incorrect state notification)
• IE3N08 (Control notification)
• IE3N09 (Authorized Economic Operator control notification)
• IE3R08 (ENS Consultation results)
• IE3N99 (Error notification)

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)

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.

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

• 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  CIRCABC - EU Advance Cargo Information System (ICS2) - ICS2 CTSS.
• 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.

• 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 CIRCABC - EU Advance Cargo Information System (ICS2) - ICS2 Testing.

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.

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:

1. A string is required in which the first character must be '+' (pattern part: \+);
2. 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.

3. 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.

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.

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 CIRCABC - EU Advance Cargo Information System (ICS2) - ICS2 Testing.

MSs’ user on behalf of EOs user, could configure the following information via the MON&BS:

• Trader information;
• Notification preferences;
• System configuration, which contains the trader’s AS4 AP preferences (if information is configured for the trader);
• Default communication path.

This is recommended in the scenario that EOs have issues in UUM&DS or with STP access.

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.

Below is the certificate information which is used in the Conformance environment:

• Owner: C=BE, ST=Belgium, L=Brussels, O=SPEED2ng, O=European Commission, OU=SPEED2ng TL, OU=DG TAXUD, CN=sti-taxud
• Issuer: C=BE, ST=Belgium, L=Brussels, O=European Commission, OU=DG TAXUD, CN=DG TAXUD PROD C

Below is the certificate information which is used in the Production environment:

• Owner: CN= European Commission - STI TAXUD, OU=DG TAXUD, O=European Commission, L=Brussels, C=BE;
• Issuer: CN=Advanced eIDAS Class2 e-Szigno CA 2016, O=Microsec Ltd., L=Budapest C=HU.

Certificate Attributes: CN: Common Name, OU: Organisational Unit, O: Organisation, L: Locality, C: Country Name

The EOs should import the full chain of certificates to their truststore. The two certificates can be downloaded from the following links:

CIRCABC ICS2 Release 2 folder – TAPAS_ICS2_CERTIFICATES.DOCX file contains both certificates: ICS2 Release 2 - Library (europa.eu)

CIRCABC ICS2 Release 3 folder – TAPAS_ICS2_CONF_AS4.7z and European Commission – STI TAXUD_seal.7z files: ICS2 Release 3 - Library (europa.eu)

For conformance and production environment the Public (source) IP that the TAPAS central side is using for sending messages (from TAPAS to EO) is: 147.67.18.4 (In Q2 2024, the public source IP in Conformance environment will change to: 147.67.18.44). Traffic from this IP needs to be allowed through the EO firewalls to be able to receive messages from TAPAS Central side 

According to ICS2 HTI – ICD (CTSS EO for R3 - SD-ICS2-HTI-Interface Control Document-SfA-v3.30.pdf), available at  CIRCABC - EU Advance Cargo Information System (ICS2) - ICS2 Testing 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.

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).

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.

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 security reasons, the only network ports allowed are 80, 443, 9443, 9444, 9445, 8443, 4443, 8445, 9081, 9082 and 9003.

If other ports are to be used by EOs then Central Service Desk should be notified to implement a change to allow traffic on that port through central firewall.

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.

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 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&section=1

An EU Member State is responsible for managing the National Customs alternate list.

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 types the PIN provided with the certificate’s private key in order to register the certificate. At no circumstances does the Economic Operator reveal or provide the private key to a third party application or entity whatsoever

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 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.

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.

Each EO should register its sealing certificate in the National UUM&DS Application of its Member State. In case there is no National UUM&DS application, the Member State should decide if Central UUM&DS application should be used. The process for the latter case is described in the UUM&DS Central Certificate Registration Manual for EOs.

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.

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 CIRCABC - EU Advance Cargo Information System (ICS2) - ICS2 Testing
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.

The actual content of LOTL is managed and published by each MS.

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 CIRCABC - EU Advance Cargo Information System (ICS2) - ICS2 Testing

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.

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.

Countries that haven't implemented their own IAM, must go through the Central European system. In order to do that, these MSs must access the EU login instance. This will allow the usage of one unique account for different EC central services and support two steps or two factors authentication using respectively mobile app and UBI key. Type D countries have their own Subdomain Administrator who is managing the national user accounts. A Member State needs to contact their national Subdomain Administrators.

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.

• 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 CIRCABC - EU Advance Cargo Information System (ICS2) - ICS2 Testing
• 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 CIRCABC - EU Advance Cargo Information System (ICS2) - ICS2 Testing
• 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 CIRCABC - EU Advance Cargo Information System (ICS2) - ICS2 Testing
    • 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).

Trade association representatives can find the published versions of the EO Self-Conformance Testing related documentation in CIRCABC. All EOs can find the publicly accessible EO Self-conformance Testing related documentation on the public location in CIRCABC and the EO Self-Conformance Testing related training materials in the Customs & Tax EU Learning Portal - ICS2 End-To-End Testing for EOs.

For the smooth preparation prior to the CT activities, the EOs should read and comprehend all the relevant documentation that has been provided to them:

• ICS2 Harmonised Trader Interface Control Document [R02];
• ICS2 EOs Common Technical System Specifications package for ICS2 Release 2 & 3 [R08].

Particularly, the consultation of the below documents is considered essential during the CT execution:

• Conformance Test Organisation Document (CTOD) for EO for Release 3 [R09];
• Test Design Specifications for Economic Operator Conformance Test Cases for Releases 2 & 3 [R11];
• Test Design Specifications for Economic Operator Conformance Test Scenarios for Releases 2 & 3 [R10];
• Trainings that will be provided by National Administrations to EOs:
  • ICS2 Conformance Test;
  • Digital certificates and registration of certificates;
  • NA services and support to EOs.

In general, the latest accepted version of the EO Self-Conformance Testing related documentation is stored on CIRCABC - EU Advance Cargo Information System (ICS2) - ICS2 Testing.

Yes. In this case, the messages sent to Shared Trader Interface (STI) need to be sealed with ITSP’s digital certificate registered in Unified User Management and Digital Signatures (UUM&DS). (There is no need to use Airlines certificates or UUM&DS delegation function).

In case that an Economic Operator (EO) (e.g. Airline company customer of ITSP) is not a Sender and the EO uses the services of an ITSP, then this EO does not need to register this certificate since it will be done by its ITSP.

The EORI number of EOs (Airline companies) is to be used only in the business payload of the messages.

In case ITSP is providing the services to several parties, he may use several EORIs in the business message payload, each time the EORI of the party (Declarant) on whose behalf messages are sent should be used.

When an ITSP offers its services to several EOs of the same business role, then, during Self-conformance testing, it is required to perform only one campaign, not a separate campaign for each EO.

Relevant information can also be found here.

An EO can use two separate ITSPs to comply with ICS2 Release 2 requirements. For example, one for mail and another for cargo transportation. An EO has the ability to perform the Conformance Testing at any time within the timeframe of execution and as many times as needed, either independently or through the ITSP of its choice.

If an EO needs to use for their Conformance testing (CT) campaign an EORI that does not exist in EOS/CRS then they should contact their Responsible MS (please find details here: Economic Operators Registration and Identification number (EORI) (europa.eu). The MS is able to create the EORIs in EOS, which will be replicated to CRS. In both environments, Conformance and Production, EOS/CRS and ICS2 systems are integrated. However, Conformance and Production are separated environments, therefore, if an EORI is needed for CT, the EORI should be logged in Conformance. If it is needed in Production, then the encoding should happen in Production. In the eventual scenario that the MS don’t manage to encode the EORIs on their side for any reason (e.g. access rights or any temporary issue), they could eventually log a ticket to Central Service Desk.

The EO who wants to receive notifications will have to perform specific actions in STP (please bear in mind that to access and use the STP, any EO needs to be registered in UUM&DS ) depending on both, its role on the ICS2 business process and the IT tool used for ICS2.

The main cases are described in the table below.

For example:

1. If the EO is acting as a person filing and uses the EO system (system developed and maintained by EO itself) to lodge the ENS, the EO will have to access STP to configure its access point. For the person filing all the notifications will be sent by default. To disable some / all notifications the user should manage its notifications preferences by switching off the related buttons via the STP Manage preferences menu – Notifications section.
2. If the EO is acting as a carrier not being in role of person filing (e.g. carrier that has been indicated by house level filer in house ENS filing as carrier) and uses the EO system (S2S) to get notifications, the carrier will have to access STP to configure its access point and default communication path to specify to which system the notifications are sent (EO system or STP). In this case, the notifications will not be sent by default. Hence, in order to receive some / all notifications the user should switch on all needed notification(s) via STP Manage preferences menu - Notifications section.
3. If the EO is acting as a carrier not being in role of person filing and makes use of an ITSP (IT service provider – technical sender of ICS2 messages), the user of ITSP will have to access STP to configure its access point (register his partyID to ICS2). After that, the user of the carrier (not being in role of person filing) will need to login in to STP and set the Default Communication path. The Default Communication path will be used to specify to which system the notifications are sent. In particular:
   1. to get notifications in the ITSP system in Default Communication path the user of the carrier has to configured S2S for that specific business domain. When the user of the carrier configures the Default Communication path, the party ID of the ITSP will have to be specified.
   2. to get notifications in the STP in Default Communication path the user of the carrier has configured U2S for that specific business domain. In this case no party ID will be requested.

In both cases chosen notification(s) should be switched on in STP Manage preferences menu - Notifications section

Default Communication path should be configured for each business domain.

Please keep in mind that for the person filing (PF) notifications, the notification will be routed to the sender access point without considering the default communication path (ICD-HTI section 3.3.2.3 CIRCABC - EU Advance Cargo Information System (ICS2) - ICS2 CTSS. The default communication path is for other EOs notifications only (carriers not being in role person filing, supplementary declarants, notified parties etc.)

In the scenarios where the carrier is acting as person filing, the notifications will be sent to the same system from where the ENS was lodged. The following notifications will be received:

• IE3R01 (ENS Registration Response);
• IE3R07 (Invalidation Acceptance Response);
• IE3R08 (ENS Consultation results);
• IE3N01 (ENS lifecycle validation error notification);
• IE3N02 (ENS not complete notification);
• IE3N03 (Assessment complete);
• IE3N07 (House consignment in incorrect state notification) – as of ICS2 Release 3 (applicable only to maritime);
• IE3N08 (Control notification) – as of ICS2 Release 3 (applicable only to maritime);
• IE3N09 (Authorized Economic Operator control notification);
• IE3N10 (Amendment Notification);
• IE3N99 (Error notification);
• IE3Q01 (Do Not Load request);
• IE3Q02 (Additional information request);
• IE3Q03 (High Risk Cargo & Mail screening request).

A carrier not acting as person filing, who wants to receive notifications, should set up its “notifications preferences”, “Default Communication Path” and “access point configurations” through the STP, via “manage preferences” section. The notifications can be received via STP or via S2S depending on configuration done in STP for Default Communication Path.

• The following notifications will be received:IE3R01 (ENS Registration Response);
• IE3R08 (ENS Consultation results);
• IE3N03 (Assessment complete);
• IE3N04 (Additional information request notification);
• IE3N05 (High Risk Cargo & Mail screening request notification);
• IE3N09 (Authorised Economic Operator control notification);
• IE3Q01 (Do Not Load request).

Any EO that wants to access the STP, needs to be user of UUM&DS and needs to contact the National Service Desk who grants ICS2 STP related roles.

To learn more about UUM&DS, it is possible to attend the online course by accessing the following URL: UUM&DS system: Your passport to EU applications, Topic: en (europa.eu)

Following roles are defined for STP:

• Economic Operator Declarant (EO-DECL);
• Economic Operator Representative (EO-REP);
• Economic Operator Configurator (EO-CONF);
• Person Notifying Arrival (EO-PNA);
• Notify Party (EO-NOP).

Please bear in mind that the National Service Desk (NSD) will support EOs who are having issues with their UUM&DS account or STP access for the setup of system configuration and notification preferences.

For the additional information please check related training video in CIRCA 

Both the person filing and the carrier (if known to ICS2 system, meaning, if carrier is not person filing but has their preferences correctly set in the ICS2 STP).   will always receive the DNL notifications (IE3Q01). Person filing will get DNL via the channel it has used to lodge the ENS filing and the DNL duplicate notification will also be visible in STP while carrier not acting as person filing can choose where to get those notifications as per description under (What actions should be performed by an EO in order to receive notifications?)

ICS2 system needs to know the details of the EO to determine where to dispatch the messages or notifications. Person filing and person notifying the arrival by default will get the notifications via the channel that was used to lodge ENS filing or arrival notification. E.g. ICS2 will dispatch the messages and notifications to the EO via S2S if that was the way the ENS filing was lodged. Otherwise, will send the notifications via U2S if the U2S was the channel used by EO to lodge ENS filing.

For notifications for EO that are not the person filing, the system will act depending on the preferences set by the actor via the STP.

By default, following notifications are send to person filing via U2S:

• IE3Q01 (Do Not Load request);
• IE3Q02 (Additional information request);
• IE3Q03 (High Risk Cargo & Mail screening request).

The system will act depending on the preferences set by the EO via the STP. If an ITSP sends messages on behalf of EO (House and/or Master ENS filer) then it is acting as a technical sender of ENS filings, and its communication channel is set by default to S2S interface of ITSP. Duplicate notifications can be received via STP as well. In order an ITSP could receive notifications addressed e.g., to carrier that is not acting as person filing, that carrier should configure its default communication path in STP by indicating the PartyID of ITSP.

The EO should configure its preferences in STP to receive any notification via ITSP system, as the ICS2 system needs to know the partyID and the communication channel preferred by the EO in order to dispatch them.  

The following messages will be sent to the person filing, when applicable:

• IE3R01 (ENS Registration Response);
• IE3R07 (Invalidation Acceptance Response);
• IE3R08 (ENS Consultation results);
• IE3N01 (ENS lifecycle validation error notification);
• IE3N02 (ENS not complete notification);
• IE3N03 (Assessment complete);
• IE3N07 (House consignment in incorrect state notification);
• IE3N08 (Control notification) – as of ICS2 Release 3 (applicable only to maritime);
• IE3N09 (Authorized Economic Operator control notification);
• IE3N10 (Amendment Notification);
• IE3N11 (ENS pending notification);
• IE3N99 (Error notification);
• IE3Q01 (Do Not Load request);
• IE3Q02 (Additional information request);
• IE3Q03 (High Risk Cargo & Mail screening request).