1 / 45

1. Context

Electronic Customs Coordination Group Item 16 Reporting from the PG analysing the implementation feasibility of Obj 1&2 of the RM Strategy Brussels, 3 December 2014. 1. Context. EU Risk Management Strategy Multiple filing inscribed in the UCC

goinsm
Télécharger la présentation

1. Context

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Electronic Customs Coordination GroupItem 16Reporting from the PG analysing the implementation feasibility of Obj 1&2 of the RM StrategyBrussels, 3 December 2014

  2. 1. Context • EU Risk Management Strategy • Multiple filinginscribed in the UCC • Joint meetings ECCG/CCC-RM/CCC-FOR/CCC-DIH on 1/07/2014 and of meeting of TCG on 3/07/2014 =>Working document TAXUD(2014)2233525

  3. 1. Context • CPG meeting May & July 2014 => Need for furtherimplementation (feasibility) analysis of approach [1-]2-3 linked to Obj 1&2 of the RM Strategy => Supported by a new Project Group • Call for interest to CPG in July 2014 • PG Kick-off on 11 September2014

  4. 2. Mandate & role of the PG Objective: Prepare a comprehensive analysis for the CPG Meeting of December 2014 to examine the feasibility of the implementation in terms of processes and requirements, organisational, technological, financial,…

  5. "PG supporting the analysis of the implementation feasibility for objectives 1 &2 of the Risk Management Strategy" Workingarrangements • Number of plannedevents • Plenary meetings + subgroup meetings (riskmanagament/customs business processes/IT) • Use of PICS for e-collaborative edition of document • FromSeptember till November 2014 • Number and Profile of participants • Final composition: 25 experts from 13 MS • Trade invited on ad hoc basis

  6. 3. Meetings • 11/09/2014 1st Plenary+ 12/09 RM Subgroup • 24-25/09/2014 Subgroups • 8-9/10/2014 2ndPlenary+ Subgroups • 29-30/10/2014 Subgroups + TCG halfday • 19/11/2014 3rd Plenary

  7. 4. Activities • Requirementsdefinition (chapter 3) • Risk Management Requirementsdefined • Definition of e-screening • Definition of ENS+ lifecycle • FunctionalRequirementsdefined + whatis a new requirement + merger key per transport mode • Non functionalRequirementsdefined

  8. ENS+ Lifecycle The “ENS+ lifecycle” is a term for easy reference to the complex entry process starting with • an EO submitting a complete or a partial ENS to Customs; then • customs receiving, validating, processing, making the submitted data (ENS or partial ENS) available to other relevant Member States, performing collaboratively security and safety risk management, making available all the data that is being added to the (partial/complete) ENS such as risk results, decisions, control results, etc; and closing the process with • customs indicating a final state variable to the actual case of the transaction and potential controls performed.

  9. Approaches and options confirmed and completedfrom an IT perspective • Architecture definition (chapter 4) • Functional blocks identified to build IT landscape • SWOT analysis (volumetrics, roles, efficiency, effectiveness, etc)

  10. Solution architecture options 3 Approches – 6 options

  11. How we did it? CBA: 3 approaches Business and functional requirements + Volumetric Functional Architecture (what we need to do?) Application Architectures (how it will work?) Technological Solutions (what technology can do that?) Refinement Planning Costs Six IT implementation + SWOT Analysis options

  12. 3 Approaches • Approach 1: Peer-to-peer networking • Approach 2:Common repository for ENS+ lifecycle support • Approach 3:Adding a harmonised interface for trade

  13. Illustrative example of ENS Lifecycle e-screening reception/validation riskanalysis reception/validation Makeavailable merge RA - results arrival - status presentation - status control - results

  14. Functional blocks

  15. 326.9 millions of ENS parts are expected from trade per year

  16. Approach 1 – 2 options • Approach 1 – Option A: IT trader interfaces are to be operated by each and every MS. The MS architecture is fully decentralised without common IT components except CCN/CCN2 in order to streamline the exchange of data; • Approach 1 – Option B: a technically optimised version of Approach 1 – Option A. It introduces a central referential index that would help to find the required information at the right place;

  17. Approach 1 – Option A

  18. Functional IT Architecture – A1A

  19. Approach 1 – Option B

  20. Functional IT Architecture – A1B

  21. Approach 2 – 1 option • IT trader interfaces are to be operated by each and every MS. • The ENS parts are filed and merged in a common place; they are availablefromthere to all MS. • A common repository containing complete ENS data provides the possibility of an effective and efficient implementation of different services such as ENS+ lifecycle services, Risk Management collaboration services and e-screening services. These services are consequently made available to all MS;

  22. Approach 2

  23. Functional IT Architecture – A2

  24. 3 Options for Approach 3 • Option A:Filing to a selected office • Following legal rules, the EO file to a customs office which subsequently pushes data to the responsible customs office of entry. • Option B: Harmonised national interfaces • The EO has to address the MS trader interface in function of the FCOE or the presumed one. • Option C: Central Trader Interface • This option provides a central unique IT trader interface.

  25. Approach 3 - Option A: Filing to one MS • AnEconomic Operator can lodge an ENS submission to any FCOE in the EU via the IT trader interface of the MS to which it is connected to following an assignment protocol; • The receiving IT trader interface will route the messages to the FCOE or the presumed one.

  26. Approach 3 – Option A

  27. Functional IT Architecture – A3A

  28. Approach 3 - Option B: Harmonised national interfaces • The offered IT trader interfaces across all MS are fully harmonised from business, semantic and IT technical viewpoint; • The Economic Operator has to address the IT trader interface of the MS in function of the FCOE or the presumed one.

  29. Approach 3 – Option B

  30. Functional IT Architecture – A3B

  31. Approach 3 - Option C: Central Trader Interface • This option provides a shared unique IT implementation of the trader interface. One single gateway for the IT communications between traders and customs.

  32. Approach 3 – Option C

  33. Functional IT Architecture – A3C

  34. Estimated costs

  35. While EU COM costs raise, MS costs significantly drop as of A2 and A3-C

  36. Costs by approaches MS vs COMM

  37. Recommendations to CPG CPG endorsement requested for • Approach 2 and set up a Common Repository for mandatory use by all Member States. • as an "add-on" to the Common Repository, the possibility of collaboration among interested Member States with the support of the Commission to be applied for the development, implementation and operation of a Shared Trader Interface. • as an “add on” to the Common Repository, the introduction of a shared functionality for e-screening.

  38. Options Trader Interface National National Shared Shared e-screening National Shared Shared National National Risk Analysis National Risk Analysis National Risk Analysis National Risk Analysis National e-screening National e-screening Shared e-screening Common Repository & Services (mandatory) 1 2 3 National Trader Interface National Trader Interface Shared Trader Interface Trader Trader Trader Trader

  39. The Common Repository will be a commonly shared service developed and technically operated by the Commission on the basis of commonly agreed business rules and IT compliance defined in close cooperation with the Member States. • Operational responsabilities remain with MS.

  40. Recommendations to CPG Legal implications • Concerning the ENS+ lifecycle • Concerning the implementation of the recommended option • Concerning data protection and data security Statements on Resource and Critical dependencies

  41. Way forward Business Case & Vision document GO/NO GO decision Solution operational (first release) System Specifications ready GO/NO GO decision CPG: GO/NO GO decision Solution developed 2015 2016 2014 Project coordination (EU Commission in the lead) Common repository & services (EU Commission in the lead) Preparation of CPG document Elaboration Phase Inception Phase Construction Phase Transition Phase e-screening (“Opt-in Member States” leading committees) Shared trader interface (“Opt-in Member States” leading committees)

  42. Thank you !

  43. Annex slides In Case of…

  44. ENS+ Lifecycle The “ENS+ lifecycle” is a term for easy reference to the complex entry process starting with • an EO submitting a complete or a partial ENS to Customs; then • customs receiving, validating, processing, making the submitted data (ENS or partial ENS) available to other relevant Member States, performing collaboratively security and safety risk management, making available all the data that is being added to the (partial/complete) ENS such as risk results, decisions, control results, etc; and closing the process with • customs indicating a final state variable to the actual case of the transaction and potential controls performed.

  45. Illustrative example of ENS Lifecycle e-screening reception/validation riskanalysis reception/validation Makeavailable merge RA - results arrival - status presentation - status control - results

More Related