Conceptual analysis for the establishment of a global information-sharing focal point: supplementary information for MOP 2 provisional agenda item 4.1: related document: FCTC/MOP/2/6

Conceptual analysis for the establishment of a global information-sharing focal point Supplementary information for MOP 2 provisional agenda item 4.1 Related document: FCTC/MOP/2/6 A. BASIC SYSTEM DESIGN FEATURES The Focal Point to be created pursuant to Article 8 FCTC Protocol is designed to provide a communications platform allowing Parties to exchange information upon request in the context of their enforcement work against the illicit tobacco trade. Such information exchange upon request is a well-known working concept when customs authorities cooperate across borders to fight smuggling. The concept is for instance set out at multilateral level in the Model Memorandum of Understanding on Mutual Administrative Assistance endorsed by the World Custom Organization. According to Article 8, the Focal Point is to be located at the Convention Secretariat. It should be accessible to all Parties, enabling Parties to make enquiries and receive relevant information. The basic components of the global tracking and tracing regime set out in the FCTC Protocol are national/regional tracking and tracing systems and a Focal Point linking these together. Whilst there is a well-established legal framework of how information can be shared, the Protocol offers little guidance as to how this is to be achieved in practice. It is thus for the Working Group, and the FCTC Protocol membership at large, to develop a fully-functioning system. Two fundamental questions to guide this process are: Parties national/ regional tracking and tracing systems Focal Point Global tracking and tracing regime components Supplementary information I. What are the key steps in the process of sharing information through the Focal Point? II. What are the systemic requirements underpinning a well-functioning information sharing system via the Focal Point? I. Key steps – Process flow Considering a generic process for sharing information via a Focal Point, this operates as a query-based system to facilitate information exchange. The Focal Point is an intermediary actor, receiving requests from one Party, routing them to relevant other Parties, and eventually providing the initial Party with the information requested. The below graph provides an overview of the key steps in an elementary Focal Point information sharing process. The blue colour represents the FCTC Protocol Parties (either Party requesting or sharing product information) and the green colour represents the Focal Point component. 1. Requesting Party investigates: Following a seizure of tobacco products, a Party sends a request to the Focal Point for detailed tobacco product information. This request is based on the unique identification marking on the products as mandated by the Protocol. 2. Party request: The Party sends the request and the Focal Point receives it. 3. Focal Point process: The Focal Point validates the request and matches the unique identification marking with potentially involved Parties. 4. Process update feedback: The Focal Point shares collected information with requesting Party e.g. the validity of the request validity and Parties potentially involved. 5. Focal Point request: The Focal Point routes and submits the request to the Parties potentially involved. 6. Involved Parties process: Some Parties' systems receive the request and share the retrieved information with the Focal Point. 7. Involved Parties answer: The answer is submitted (routed back) to the Focal Point. 8. Focal Point process: The Focal Point receives, validates and consolidates information from Parties involved. FCTC Protocol’s PartyFCTC Protocol’s Party 1. Investigate 2. Request 3. Process 5. Request 10. Process 9. Answer 8. Process 7. Answer 6 . P ro ce ss Focal Point solution 4. Process update feedback Focal Point Supplementary information 3 9. Focal Point answer: The Focal Point shares the information received and consolidated with the requesting Party. 10. Process: The requesting Party is able to ascertain the validity of the unique identification marking as well as the point of diversion, supported by the received information. It should be noted that the above is a process flow based on the assumption that information would flow both ways (i.e. request and subsequent reply) through the Focal Point. Another theoretical process flow would be that the Focal Point routes only the requests to the relevant Parties, but replies are sent to the requesting Party in a direct data exchange. For the purposes of this paper this option is not considered in further detail as it would require much more complex IT communication links, considering the increasing number of Protocol Parties. II. Basic requirements What are then the systemic requirements for a well-functioning Focal Point? ➢ Trust: The Focal Point should create trust between Parties by having effective mechanisms to ensure accurate use, provision of data to the right stakeholder, and maximising global cooperation. For information sharing to work well, the Parties must trust that the sensitive data communicated via the Focal Point will be handled appropriately. There needs to be clear understanding of the international standards on mutual cooperation and gateways that must be met before information can be shared. The design of the Focal-Point needs to take account that adequate safeguards are in place to ensure compliance of authorities with Article 8(9) (d) and (e). ➢ Minimal impact: In light of the global reach of the Focal Point, it should allow for each Party system to request and share data in line with their specific capacities. This can range from enabling manual processes up to fully automatic systems integrated with a Party's system. Minimum impact also means that the Focal Point works with existing systems and would not require Parties to change these again. ➢ Technological neutrality: Different Parties have already developed a range of national or regional track and trace systems, or are in the process of setting up such systems. Whilst following the relevant FCTC Protocol rules, these systems may nonetheless differ substantially in terms of the governance, design and technology used. The Focal Point will have to provide a platform linking to a variety of national systems, without prescribing one or the other model. Supplementary information ➢ Party scalability: There are 58 Parties1 to the Protocol and it is expected this number will continue to grow. The Focal Point should therefore facilitate and support the future boarding of additional Parties with minimal effort and ensure the Focal Point can be maintained. NP) Purpose: There needs to be a common understanding of the circumstances that would lead to a request and what the tracking data, once received, will be used for. This will help identify the useful data needed and in turn the system’s structure. It will also help set expectations with parties regarding any follow up action. 1 Source: United Nations Treaty Collection, consulted on 18/02/2020 Supplementary information 5 B. KEY ISSUES FOR DISCUSSION Considering the process flow as described above (see A.I.), a number of policy choices will eventually have to be taken for the practical design of the Focal Point, in order to create a system which best meets Parties’ needs. This technical document is intended to support the discussion of the Parties on the key decision points set out in detail in this chapter. Each decision point contains a description, options involved and guidance to support discussion. Following the request made by Parties at the first meeting of the Working Group, the Key Facilitators have proposed recommendations of preferable options for each of the decision points as a basis for discussion. The key decision points laid out are the following: 1. Product Level Request 2. Request entry 3. Requested product information 4. Unique identification markings 5. Information sharing 6. Confidentiality of information 7. Operational data language 8. Evaluation of the response Supplementary information 1. Product level request The Focal Point can support different options for how a Party can request information to investigate and detect illicit trade. Options: a. Product information – Focal Point enables Parties' request for information regarding tobacco products based on specific unique identification marking applied to a single product (tobacco pack). b. Product and aggregation information – Focal Point enables Parties' request for information regarding single products and aggregation/ consolidated information of tobacco products through the supply chain, including trade across Parties. This allows the requesting party to receive the information on the respective aggregation level, including all the products included in this aggregation. Guidance: Parties to the Protocol may record and consolidate aggregated product information. Each aggregation level may have its own code standards, which would mean the Focal Point would have to process additional code standards - bringing additional complexity. Dependencies: This decision does not have any direct impact on other Focal Point decisions. However, if aggregation is chosen that would have an impact on 8 Evaluation of the Response. Recommendation: Option A Motivation: Striving for a simple but workable system at this early stage, it is deemed sufficient for the proper function of the information exchange system if the Focal Point would only process unique identification markings relating to one single pack. A facility to also process aggregations could be added at a later stage. This would also facilitate timely detection of illegitimate product (for instance of goods in transit, checks at borders). This is a point that should be returned to with Parties at a later stage. Supplementary information 7 2. Request entry The issue is about how the unique identification marking from a given pack is practically entered into the Focal Point IT system. It supports and enables secure information sharing amongst Parties. To make a request to the Focal Point, options range from manual to computer assisted – e.g. picture – entry of the product’s unique identification marking. Options: a. Manual entry - This option requires manual effort from the Party to enter the product’s unique identification marking ID in the Focal Point system. b. Scanner based entry - This option allows Parties to scan the product’s unique identification marking. The unique identification marking recognised by the scanner can be submitted to the Focal Point system. c. Image based entry - This option allows Parties to enter the product’s unique identification marking in the Focal Point by taking a picture of the product and submit via e.g. a smartphone. Guidance: Option A is the easiest to implement, but requires manual effort to register each unique marking and increases the time to register a request. There is also an increased error rate. This option also requires unique identification markings to be human readable. Option B scanner based entry reduces manual effort, time and error rate. However it requires a unique identification marking recognition engine so the Focal Point can interpret the unique identification marking. It also requires a device to recognise unique identification markings (scanner/smartphone). Parties would need to share respective encoding and decoding rules. Option C hugely increases the size volume of requests and requires an image recognition engine. 1 In case of option C, certain (mobile) equipment is required to be considered for implementation e.g. any device capable of capturing an image. An image recognition engine is required for the GSP to recognise the unique identification marking, which can rely on human operation or be fully automated. 2 It is necessary for every pack to have either a human-readable or a machine-readable unique identification marking. Parties may also consider the addition of a free text box, or otherwise, to allow for a justification to accompany the request. Dependencies: This design decision point does not have any direct dependency on another Focal Point capability, nevertheless could impact on the storage capacity. Recommendation: A combination of Options A and B. Both manual entry and scanner based entry should be supported. Motivation: Different Parties may look at the costs and benefits of options a and b in different terms, considering issues such as propensity to error, work load and access to technology. Their collective interests are best served by giving them the possibility to choose between Options A and B depending on their local preferences and capacities. Supplementary information Option C adds complexity with uncertain added value. 3. Requested product information The Focal Point supports and enables secure information sharing amongst Parties. Parties will need to decide what level of detail on a specific product should be requested and shared. Options: a. Required by FCTC Protocol Minimal information in accordance with Article 8.4 Protocol b. Additional to FCTC Protocol Additional information also mentioned in Article 8.4 (e.g. more detailed information on the supply chain). Guidance: The information exchanged should be the most relevant to assist Parties. Additional information in the form of free text should be limited to the extent possible however Parties could consider the insertion of free text. Adding free text will however only make sense if other Parties are willing to read that text in the language of drafting; practically this will mean that Parties would be agreeable to communicate such free text in a language to be agreed. Dependencies: This decision point does not have any direct dependency, as Parties are responsible for recording and storing product’s information. However, this should be considered along with discussion point 7 ‘operational data language’. Recommendation: Option B Motivation: The system should be as automated as possible; however Parties may well find it opportune to inform the receiving Party/Parties with some background to the request made. This makes the use of the system transparent and thus increases the plausibility and legitimacy of its use. However, practical guidance on the choice of the language to be used may be recommendable. Moreover it should be clear to all Parties that a free text facility is optional. 4. Unique identification marking – Party matching This is arguably the most important point of all in terms of designing the system. The Focal Point needs to interpret which Parties potentially have information on a requested tobacco product (based on the product's unique identification marking). This can range from querying every Party (option a) to issuing/ involved Parties (options b and c). This decision point is critical for determining which data the Focal Point needs to store. Information to be stored (e.g. unique identification issuing and accepting coding rules by the Focal Point must be secure and not breach any confidentiality requirements. Supplementary information 9 Options: a. No matching (routing to all Parties) – This option means the request will be routed to all Parties, many of which will not recognise the unique identification marking. No unique identification storage capacity would be required in this scenario. b. Identifying unique identification marking issuing Party – The Focal Point matches the received unique identification marking with the issuing Party. This is done via a mapping component containing unique identification marking code structure per Party. This option requires the central storage of Parties' ‘generic’ unique identification marking issuing coding rules i.e. limited storage capacity needed. c. Identifying Parties where unique identification marking structure is valid – Focal Point matches the received unique identification marking with the issuing Party and all other Parties recognising the unique identification marking code (e.g. unilateral and bilateral recognition). This option requires the storage of Parties' unique identification marking issuing and accepting coding rules i.e. limited storage FCTC Protocol’s Party A – Requesting Party Focal Point 3. Process Focal Point Party B Party C Party D Party Z ... 4. Request RoutingUnique marking–Party matching Validity: Code issuing Party: Parties accepting code: Route: unknown unknown unknown unknown 1. Investigate Information on the pack (UM1) Validity: Code issuing Party: Parties accepting code: Route: unknown unknown unknown unknown FCTC Protocol’s Party A – Requesting Party Focal Point 3. Process 4. Request RoutingUnique marking–Party matching Validity: Code issuing Party: Parties accepting code: Route: unknown Party B unknown unknown 1. Investigate Information on the pack (UM1) Validity: Code issuing Party: Parties accepting code: Route: unknown unknown unknown unknown Unique marking-Party matching engine Party A Issuer+Serial#+ProductCode+TimeStamp Parties UM code structure Parties accepting UM code structure No information available Party B ProductCode+Serial#+RetailPrice+VerificationCode No information available . . . . . . . . . Focal Point Party B Party C Party D Party Z ... Supplementary information capacity required. Theoretically, there could be other options based on central storage of virtually all global tracking and tracing information. Such options are not further considered here, due to the requirements to store vast amount of information coupled with significant data security concerns. In the view of the Working Group, such demanding requirements cannot be met with the resources and capacities available. Guidance: Option A would arguably be the easiest to put in place but would not be a targeted querying system, which may result in significant delays in receiving a reply. As the number of Parties grows, the number of non-relevant queries would be significant. Option B would be a targeted querying system, however would only identify the country that issued a code which may result in an incomplete overview. Option C would offer the most complete overview of countries involved and product movements. Dependencies: If Options B or C were chosen, this decision point requires that all participating Parties communicate the generic code structure used by their national or regional traceability systems to the Focal Point, and keep this information always up to date. The code FCTC Protocol’s Party A – Requesting Party Focal Point 3. Process 4. Request RoutingUnique marking–Party matching Validity: Code issuing Party: Parties accepting code: Route: unknown Party B Party B, C, D unknown 1. Investigate Information on the pack (UM1) Validity: Code issuing Party: Parties accepting code: Route: unknown unknown unknown unknown Unique marking-Party matching engine Party A Issuer+Serial#+ProductCode+TimeStamp Parties UM code structure Parties accepting UM code structure Party B, C,… Party B ProductCode+Serial#+RetailPrice+VerificationCode Party A, D,… . . . . . . . . . Focal Point Party B Party C Party D Party Z ... Supplementary information 11 structures have to include an element allowing for the identification of an originating Party. Depending on international standards used for aggregation, a broader querying of Parties involved may be necessary. Recommendation: Option C Motivation: If all Parties were constantly flooded with a large number of requests (Option A) from the Focal Point, without these requests being relevant to them, there is a real risk that signals from the Focal Point would increasingly be disregarded in practice. Option B only gives an incomplete picture of the actual distribution chain which today often covers several countries. Such a limited visibility would not suffice to identify where product has dropped out of the legal distribution chain. 5. Information sharing When a Party requests detailed information on a specific tobacco product, the speed at which the Focal Point can respond depends on the type of interaction and validation that is required by the Party / Parties potentially having the information on the tobacco product. In a manual scenario (option a) Parties can validate before sharing information with requesting Parties. In option c, the interaction is fully automated which means involved Parties will share information automatically with the requesting Parties. Option B is option C with manual validation. The options differ in terms of the Focal Point requirements. Option A can function with a simple web-based interface, while option b and c will require a system-to-system connection. Options: a. Manual response to request – Focal Point-Party interaction for sharing information does not work as a real time system. All data responses would be entered manually by the receiving Party, which takes time and may invite errors. However, each Party has full control over which data is shared via the Focal Point. b. Manual validation of automatically generated request – Focal Point-Party interaction for sharing information does not work as a real time system. The responses are generated automatically by the national or regional system operated by the receiving Party. However, before the response is sent back to the Focal Point, the receiving Party has the option to require manual validation of that request. This option provides each Party with control over the information shared, however it increases the overall response time for a specific query. Nonetheless, in this option Parties can decide if Focal Point- Party interaction is manual or automated. The automatic scenario is the same as described below. c. Automatic response to request – Focal Point-Party interaction for sharing information works as a real time system. The system needs to be fully automated, which minimises human intervention as data is shared automatically with the Focal Point. However, the Party sharing the product Supplementary information information does not have real-time control over the data sharing and is only able to monitor the data sharing retrospectively. Guidance: Dependencies: This decision is an important element in deciding whether and how the Focal Point IT system would interlink with the national or regional traceability systems. Where all data entry by the receiving Party is manual (Option A), it would seem feasible that no technological linkage takes place for the time being. Conversely, both a fully automated response (Option C) or such a response subject to manual validation (Option B) requires a fully-fledged IT link between the national or regional systems and the Focal Point. Recommendation: Option A with a review after 3 years Motivation: It is reasonable to expect that during the first years of operation of the Focal Point, not too many requests will be generated by the participating Parties. To facilitate the roll-out of a simple but functional system, manual data entry may suffice. Linking the various IT systems is resource-intensive, since tailor-made solutions may be required in many jurisdictions. Creating such an IT link later, building on the first experiences gained by users during the “pilot phase” also allows for the creation of a more refined solution, reflecting users’ needs and interest. However, in the longer term, there is no denying the fact that there are clear advantages (in terms of swift response times and accuracy of the data entered) associated with a fully or quasi automated response (Options B and C). In terms of its functionalities, this is a superior solution and the system design of the Focal Point should cater for such a later expansion from the start. This will also be important in terms of detection or verification capabilities. However, depending on Parties’ technical readiness, Option A may need to be sustained even if more advanced Parties decide to migrate to Options B or C. FCTC Protocol’s Parties – Involved Parties 5 . P ro ce ss Focal Point 6. Answer Focal Point Involved Parties Party A is requesting information on: • UM 1 Option a – manual response to request 1. Request received 2. Human validation required 3. Party’s validator validates information to be shared 4. Information is shared Option b – automatic response to request 1. Request received 2. Human validation required 3. Party’s validator validates information to be shared 4. Information is shared Time Supplementary information 13 6. Confidentiality of information Once an involved Party shares product information it needs to remain secure and confidential. The Focal Point needs to know with which Party the received information should be shared. Request encryption enables the Focal Point to ensure information security and confidentiality, while being able to route the request to the relevant Party. Encryption goes beyond the basic means of authentication based on the distribution of credentials only to the trusted parties. Options: a. Request’s link encryption – Link encryption enables secure communication between two actors such as the Party and the Focal Point. When data reaches an actor, it is decrypted so that it knows which way to send it next. b. Combination of link and end-to-end encryption – Request is encrypted with both link encryption and end-to-end encryption to transfer the information securely between the involved Parties and the requesting Party. Different encryption methods are applied to different parts of a request. The Focal Point would decrypt the requested unique identification marking for the matching engine to interpret to which Parties to route the request. Once the involved Parties provides a response, the Focal Point would not be able to decrypt the response, only the unique identification marking linked to the response to route it to the relevant requesting Party. This means that the sensitive information in the reply remains encrypted until it reaches the requesting Party. Guidance: Considering the sensitive nature of certain data, it is crucial to ensure it is handled correctly. The security framework needs to ensure secure communication between Parties and the Focal Point with access only for authorised colleagues accessing the system. Dependencies: This design decision does not have any direct dependency on another Focal Point capability per se. However, we need to bear in mind that data subject to end-to-end Requesting Party Focal Point Involved Parties Option a – link encryption Encryption channel 3 Encryption channel 2 Encryption channel 4 Encryption channel 1 Requesting Party Involved Parties Option b – link + end-to-end encryption Focal Point Encryption channel 1 Encryption channel 2 Encryption channel 3Encryption channel 4 End-to-end channel encryption Supplementary information encryption cannot be processed in any way (e.g. translated.). In both options, Parties are assumed to have technical means of exchanging encryption certificates and keys. Recommendation: Option B Motivation: considering the importance of creating a system for the cross-border exchange of data based on mutual trust, only a system equipped with advanced security features is suitable. 7. Operational data language Considering the various different language regimes of Parties and their tracking and tracing systems, it may be advisable to agree on specific language for operational data (e.g. product location), or accept information being shared in any of the accepted languages. Options: a. Requesting Party’s language – The responses would need to be translated to the requesting Party’s language (in case of a different language). This would mean that encryption is restricted to option a (link encryption) as the content of the response would need to be accessed by the Focal Point for translation purposes. This would also require sophisticated translation functionality. b. FCTC Protocol’s defined languages – The language of both request and answer is aligned with the Protocol’s official languages. One common language for information exchange could also be defined. This would require sophisticated translation functionality. c. Involved Party’s language –The responses could also be shared in the involved Parties’ languages, which means no translation process would occur in the Focal Point. d. Mutual agreement – The language of the request is to be agreed between the Parties involved in the request. This would require sophisticated translation functionality. Guidance: It is clear that Parties of the Protocol use many different languages and there may be situations in which specific information (e.g. street name) is only available in a Party’s local/ regional language. Considering the clear guidance from members of the working group on tracking and tracing for a simple and workable solution, sophisticated translation may not be necessary at the establishment phase. However information terms, codes and text for data elements should be standardised as much as possible to facilitate exchange. From a technical perspective, Parties would need to provide the character sets that are supported by their national or regional traceability systems. Parties may consider a free text box to allow for an informal translation in a commonly accepted language for urgent requests. Dependencies: This design decision does not have direct dependency on another Focal Point capability. However, if Parties were to choose 6 ‘confidentiality of information’ option a link encryption could not also be chosen as the Focal Point would need to access the reply for translation purposes. Supplementary information 15 Recommendation: Option C relying to the largest possible extent on standardised data fields (i.e. so that translation is not required). 8. Evaluation of the response After a requesting Party receives information, a specific Focal Point process can assist in visualising the received information and support in investigative conclusions (pre-evaluation). Options a. No Focal Point pre-evaluation on UI – Focal Point shares the received responses with the requesting Party and presents it without any logic organisation (e.g. organising the product route), or pre-assessment conclusion on the validity of the requested pack on that Party. b. Focal Point pre-evaluation on UI – Focal Point shares the received responses with the requesting Party and presents a pre-assessment conclusion on the validity of the requested pack. This functionality would be based on the unique identification marking matching engine. This depends on the product information requested, as the Focal Point would need to be capable of interpreting data. This would require decryption of received information and would require significant computational power. Guidance: FCTC Protocol Party A – Requesting Party 10 . Process Party D: Information on the pack (UM1) Validity : Code issuing Party : Parties accepting code : Route : ✓ - - Party D to A Option a – no Focal Point pre - evaluation Party B: Information on the pack (UM1) Validity : Code issuing Party : Parties accepting code : Route : ✓ Party B Party B, C, D Party B to C Party C: Information on the pack (UM1) Validity : Code issuing Party : Parties accepting code : Route : ✓ - - Party C to D Consolidated information on the pack (UM1) Validity : Code issuing Party : Parties accepting code : Route : ✓ Party B Party B, C, D Party B – C – D – A Option b – Focal Point pre - evaluation Supplementary information Option A would present responses to the requesting Party without any analysis - this could mean additional complexity for the users interpreting the data (e.g. chronological sequence). Option B would present the information in a meaningful and more user-friendly manner. However, this would require decryption and computational power. A clear business case would be needed to establish what, if any, would be the additional compliance benefit. Dependencies: This decision point depends on the option chosen for ‘1. Product level request’. If aggregation of products is chosen, the Focal Point would need to correctly match aggregation of products and display accordingly (e.g. Pallet X contains Boxes Y etc.). It also depends on ‘3. Requested product information’. Depending on the information requested/ shared, the Focal Point will need to interpret the data and present it in a meaningful and user- friendly manner. Finally, it depends on ‘6. Confidentiality of information’ which may require a different configuration. Parties must be ready to present the requested information in a structured manner that respects basic chronology of reported events and includes relevant meta data so as to provide a meaningful reply. Recommendation: Option A for the foreseeable future. The following table provides an overview of the recommended options Decision Point Recommended Option 1. Product Level Request Option A: Product information (pack level) 2. Request entry Option A and B: Manual and scanner based entry 3. Requested product information Option B: Additional information 4. Unique identification marking – Party marching Option C: Match will all issuing and recognising Parties 5. Information sharing Option A: Manual entry 6. Confidentiality of information Option B: Link + end-to-end encryption 7. Operational data language Option C: Involved Parties languages 8. Evaluation of the response Option A: No pre-evaluation Final Note: While all effort has been made to indicate whether design decisions would have direct dependency on other Focal Point functionalities, Parties should be aware when considering all the above options that not all theoretically possible options may be chosen in all theoretically possible combinations. *** Supplementary information 17 C. COSTING The mandate for the working group on tracking and tracing specifies “to the extent possible, a cost estimate of implementing the global information-sharing focal point at the level of the Convention Secretariat should be made.” In this respect, this chapter provides a high-level estimate of cost of the Focal Point solution. The second session of the Meeting of the Parties, (The Hague, November 2020) will adopt a workplan and budget for the biennium 2022-2023. It is important to assist the Secretariat, in consultation with the Bureau of the Meeting of the Parties, to take the cost of the establishment of the Focal Point into account in their budgetary proposal to the Meeting of the Parties. However, this high level costing estimate costing sets out the cost of the Focal Point over seven years, in an effort to provide a total cost estimate of implementing the Focal Point in line with the mandate of the working group. The total cost estimate of the Focal Point over seven years includes one-off investment costs planned to be incurred in the first three years (e.g. costs for technical specifications, implementation, testing, change management, etc.), as well as recurring costs during the following four operational years (e.g. costs for maintenance, operation, etc.). The cost model is based on the recommended functionalities and options set out above in points A and B. This is an initial estimation at an early stage of the Focal Point, so a 20 % error margin is applied. This margin should cover unexpected costs (e.g. software choices, uncertainties regarding IT infrastructure etc. – see technical background note), as well as potential savings (e.g. discounts from solution vendors, quantity discounts, etc.). Moreover, a 25 % contingency factor is applied to cover any cost deviations regarding technical developments and integrations with Parties tracking and tracing systems. It should be emphasised that only incremental costs are considered, i.e. costs on top of business-as-usual costs. This framework does not cover future costs as a result of the on- boarding of new Parties, or additional resources that may be needed to implement the Focal Point solution. This cost estimation is taking place at an initial design phase so not all necessary information is available. Therefore a certain number of assumptions and limitations had to be taken into account. Assumptions: - The Focal Point will be hosted on a physical data centre available - Estimated yearly maintenance costs do not take into account the development of integrations with systems not explicitly mentioned (e.g. on-boarding of additional Parties) - The infrastructure costs are only related to costs at the hosting domain, excluding costs at Parties domain Limitations: - Estimations are based on desk research and market understanding, but no solution vendors were contacted directly Supplementary information - There is a high level of uncertainty as regards infrastructure costs. For instance, software choices may influence infrastructure investment. The below figure presents the different costs that should be considered for the different phases of the Focal Point. Costs Per Activity In light of the assumptions and limitations outlined above, below is an overview of the costs per activity for a seven year period. Design & Build costs are considered to be incurred during the first three years (e.g. costs for technical specifications, implementation, testing, change management, etc.) Run & Maintain costs are considered to be incurred during the following four years (e.g. costs for maintenance, operation, improvements, etc.). Design & specifications Infrastructure System development & integration Change management DESIGN & BUILD (one-off costs) RUN & MAINTAIN (yearly recurring costs) Analysis & architecture Specifications Infrastructure purchase/lease Infrastructure installation and configuration Software installation, configuration & testing Software purchase Development & integration Deployment & operational set-up Testing Support & training Administrative changes Governance Software Design (Architecture governance) Infrastructure Practical adoption & support Software Architecture maintenance & upgrade Specifications maintenance & upgrade Infrastructure lease Software license Infrastructure maintenance Infrastructure operation Service desk support Training Stakeholder management Governance Software maintenance Software operation Compliance Compliance Infrastructure may or not be bought depending on stakeholder’s preference for hosting Supplementary information 19 Costs Per Activity (total seven year estimation) Design & Build costs (over 3 years) Cost Total design and specification costs (Analysis & architecture; Specification) 850,000 € Total infrastructure costs (Hardware, Software, Facilities (data centre space, power and cooling), Storage, Network and bandwidth, Disaster recovery, Installation, Configuration and integration) 1,300,000 € Total system development & integration costs (Solution design and development, Integration, Deployment & operational set-up, Test) 1,350,000 € Total change management costs (Support & training; Administrative change; Governance) 500,000 € Total Design and Build costs 4,000,000 € Run & Maintain costs (over 4 years) Cost Total design and specification recurring costs (Analysis & architecture; Specification) 50,000 € Total infrastructure recurring costs (Hardware, Software, Facilities (data centre space, power and cooling), Storage, Network and bandwidth, Disaster recovery, Installation, Configuration and integration) 4,350,000 € Total system development, integration and running recurring costs (Maintenance, Operation, Running) 450,000 € Total change management recurring costs (Support & training, Stakeholder management, Governance, Compliance) 1,600,00 € Total Run and Maintain recurring costs 6,450,000 € Supplementary information Total Cost Overview To allow for the Secretariat, in consultation with the Bureau of the Meeting of the Parties, to present a proposed budget to the 2nd Meeting of the Parties to the Protocol reflecting work that needs to be carried out in 2022-2023, the below table sets out the total cost estimate per year. The amount estimated for the first two years together (2022 and 2023) is EUR 2,5 million. Total Cost Overview Year Cost Estimate 1 800,000 € 2 1,700,000 € 3 1,600,000 € 4 1,600,000 € 5 1,600,000 € 6 1,600,000 € 7 1,550,000 € Total 10,450,000 € Margin of error 20% ***THE HIGH-LEVEL COST ESTIMATION, BROKEN DOWN TO COSTS PER ACTIVITY AND TOTAL COSTS PER YEAR IS BASED ON INFORMATION AVAILABLE AT THIS INITIAL DESIGN PHASE. PLEASE NOTE THE ASSUMPTIONS AND LIMITATIONS OF THIS HIGH-LEVEL COST ESTIMATE OUTLINED ABOVE. *** Supplementary information 21 D. SUPPORTING RESPONSIBILITY A crucial aspect of establishing a Focal Point is ensuring its appropriate operation. From an organisational perspective, Parties will need to define processes necessary for implementing, running and maintaining the system. A crucial component will be the establishment of a suitable governance layer, covering various aspects of the system. Parties will need to define who is responsible for what and how decisions are taken. This is strictu sensu, outside today’s mandate of the working group. Nonetheless a number of issues for consideration are outlined to assist the Meeting of the Parties in their considerations of whether to mandate the working group to continue its work, in close coordination with the FCTC Secretariat, also to further develop options in this area. Just some of the issues Parties will need to consider are the following: Monitoring and reporting Monitoring and reporting of the operational performance requires full visibility of its main process (requests for information), to ensure its performance is as expected. Monitoring should be easily visualised with simple dashboards and only accessible by authorised users. Internal Auditing Internal audit process would ensure that all processes are operating as intended. A particularly important area for auditing would be access events and requests to the Focal Point. Risk management procedures could also be established and evaluated. Management Strategic management of the system to review overall performance and ensure the Focal Point is aligned with its objectives. This may involve evaluation necessary modifications to the Focal Point when necessary and ensuring adequate resources (financial, operational, technological etc.) are available. Operational management of the system to ensure appropriate governance. This may involve service level management, security and risk management. Parties should consider defining and monitoring adequate key performance indicators (KPIs) will support the solution's performance evaluation through each phase of its lifecycle. Technical and operational support This is necessary to ensure technical configurations, including updating Parties, users, profiles, access rights, and the unique marking standards. Only authorised Parties to the Protocol may have access to the Focal Point. Due to potentially sensitive information passing through the Focal Point, there should be sufficient safeguards to ensure only authorised users access the data. An authorisation model should follow a formal risk assessment. Setting of access rights should be reviewed periodically and adapted accordingly. Parties will need to consider whether the Parties themselves are responsible for ensuring appropriate operation of the system, including responsibility for configurations and management of users (users, rights, unique identification markings etc.). Another option is the Convention Secretariat is responsible for ensuring appropriate operation of the system, including Supplementary information responsibility for configurations and management of users (users, rights, unique identification markings etc.) From a governance perspective, a central body responsible for managing supporting processes like reporting, audit, monitoring and configurations would be desirable. Option B would empower the Convention Secretariat to take responsibility of these processes. However, that would not preclude the Convention Secretariat from delegating the responsibility to an independent third party.