FAQ

• Economic operators (EO) need to obtain an Economic operators Registration and Identification number (EORI) from the national customs authority of the EU Member State in which they are established or their business is taken place.
• For IT preparation, EOs should decide to either develop their own IT system or file ENS via STI-STP portal or use the service of an IT Service Provider. Further information and requirements for the technical preparation and self-conformance testing can be found in the ICS2 Technical Factsheet.
• Depending on their business activity, EOs need to decide whether single or multiple ENS filing should be lodged in ICS2. The type of ENS filing depends on the available consignment information for the carrier and other actors in the supply chain. More information can be found in the ICS2 Operational Guidance document for all modes of transport.

Please read attentively all the supporting materials (Guidance documents, Factsheets, eLearning modules) and ICS2 documents (functional and technical specifications) that are directly available from the ICS2 website and in the EU Advance Cargo Information System (ICS2) CIRCABC group.

In case of any questions regarding ENS filing, Economic Operator should contact the ICS2 National Service Desk of the given EU Member States where his/her EORI number was issued or where his/her business is taken place. Contact details of the ICS2 National Service Desks of the EU Member States are available in the EU Advance Cargo Information System (ICS2) CIRCABC group.

In general, the carrier bringing the goods into the customs territory of the European Union is obliged to lodge an Entry Summary Declaration (ENS). 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 (e.g. importer, consignee of the goods, freight forwarder) who holds those particulars and did not share them with the carrier. This will eventually enable the carrier to lodge a complete ENS. In such cases, a contractual agreement should be established with other participants in the supply chain. This agreement stipulates that each party submits their respective partial ENS filings based on the information available to them. Read more about multiple filing and roles/responsibilities in the Multiple filing Factsheet. 

Multiple filing can be an option when a carrier does not have all the required data to submit a complete single ENS filing. In this scenario, the carrier needs to make a contractual arrangement with the other actors in the supply chain so that each party submits their respective partial ENS datasets. The type of ENS filing for each party depends on the data available to that party – master or house and/or goods shipment (including buyer and seller) information.

In case of multiple partial filings, the carrier and the house level filers (freight forwarder or EU importer) need to exchange in advance the necessary information (e.g. the EORI of the carrier and house filer, and the number of the transport contract) that will be used for linking the partial ENS filings in ICS2.

More details is available in the Multiple filing Factsheet. 

The ICS2 Operational Guidance document and ICS2 Functional Specifications contain business model descriptions and practical examples about the ICS2 business processes for all modes of transport (air, sea and inland waterways, road, rail, express and postal business models). The documents are published in the EU Advance Cargo Information System (ICS2) CIRCABC group under the tab `Library`. Direct links to the ICS2 eLearning modules for all modes of transport are also available on the ICS2 website (Resources).

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 Testing.
• The receipt messages sent from an EO to TAPAS, it is observed to be 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 of the messages received back and finally considers that the initial user message was never sent to EO;
• 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 2 / Release 3). ICS2 Interface Control Document requires the use of the following hash function sha256 and signing algorithm rsa-sha256. See ICS2 HTI – ICD section Annex 2 Section 6.  Concerning “AgreementRef”, “EU-ICS2-TI-V2.0” is used for ICS2 Release 2 and Release 3 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 EO 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 it 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 trust store. The two certificates can be downloaded from theTAPAS_ICS2_CERTIFICATES.DOCX link (the file which contains both certificates), the TAPAS_ICS2_CONF_AS4.7z, and European Commission – STI TAXUD_seal.7z files from the EU Advance Cargo Information System (ICS2) group.

For conformance the Public (source) IP that the TAPAS central side is using for sending messages (from TAPAS to EO) is: 147.67.18.44. For 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. Traffic from those IPs 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 employees;

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.
• 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  eIDAS Dashboard
• The Certificate Authorities (CAs) on the LOTL can be divided into two categories:
• 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 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''[1] 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 (Mandatory in case the communication path is S2S)
• [1] 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 ICS2 testing All EOs can find the publicly accessible EO Self-conformance Testing related documentation on the public location in ICS2 testing and the EO Self-Conformance Testing related training materials in the Customs & Tax EU Learning Portal (europa.eu).

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;
• ICS2 EOs Common Technical System Specifications package for ICS2 Release 2 & 3.

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

• Conformance Test Organisation Document (CTOD) for EO for Release 3;
• Test Design Specifications for Economic Operator Conformance Test Cases for Releases 2 & 3;
• Test Design Specifications for Economic Operator Conformance Test Scenarios for Releases 2 & 3;
• 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 the page CIRCABC ICS2 Release 3. 

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