1. Possible elements of the technical standards Pre-sessional consultations on registries Bonn, 2-3 June 2002 Andrew Howard UNFCCC secretariat ahoward@unfccc.int

2. 2 Scope of presentation Considerations in developing technical standards Possible elements of the technical standards Process for developing standards Possible technical standards based on document FCCC/TP/2002/3

3. 3 Considerations in developing technical standards For data exchange only … … or also for the registries themselves? Differences in domestic policies? Open or closed performance standards? Compulsory and/or optional standards? Evolution / review of standards? Minimum technical standards to ensure the “accurate, transparent and efficient exchange of data between national registries, the CDM registry and the transaction log” What degree of harmonization? How to ensure registries may develop independently? What can be learned from other fields?

4. 4 Possible elements of technical standards? Number formats Message exchange Message content Communications protocols Security Internal verification procedures User interfaces Data storage Registry administrators Institutional / legal frameworks

5. 5 Possible number formats 2A=2 alpha characters (e.g. FR for France) 12n=12 numeric characters (e.g. 000014735449 for unique number) 4An=4 alpha and numeric characters (e.g. B358 for project identifier) Serial numbers  commitment period, Party, unit type, sink activity, project, unique number Account numbers  Party, unique number Transaction numbers  commitment period, Party, unique number Example of a serial number 2n2A1n1n12n4An Rearrange or add elements domestically? Different domestic numbers but translated?

6. 6 Message exchange between registries Messages communicate between registries and the transaction log Provide for information sharing and for transactions to occur Provide for the automated checks of the transaction log Message sequence defines the transaction procedure Electronic messages read by the registries themselves  Automated (and fast) processing … if in a readable format! Which messages needed? In what sequence? With what content?

7. 7 Possible message exchange: International transfer Account in national registry of Party A Transaction log (automated checks) Account in national registry of Party B 1 Pre-advice Instruction response 6 Instruction 5 Confirmation 77 Proposal 3 Transaction record containing: - trans. number - trans. type - serial numbers - account numbers 3 3 Proposal response Proposal response 4 4 Pre-advice response 2

8. 8 Account in national registry of Party A Transaction log (automated checks) Confirmation 4 Proposal 1 Transaction record containing: - trans. number - trans. type - serial numbers - account numbers 1 Proposal response 2 Possible message exchange: Domestic issuance Issuance 3

9. 9 Possible message content Messages 1 to 7 Transaction number (generated by initiating registry) Other information (e.g. reason for rejection by the transaction log) Transaction status Message 2: accepted / declined Message 4: approved / rejected Message 5: continue / cancel Message 6: completed / terminated Message 7: completed / terminated Messages 1 and 3 Transaction number Transaction record (type, serial numbers, account numbers)

10. 10 Possible communications protocols Electronic messages read by the registries themselves  Automated (and fast) processing … if in a readable format! Messages need to conform to standardized formats To be accurately and automatically read by receiving registry Use of different formats is possible … but requires translation For example XML (eXtensible Markup Language) provides for the sender to tag text with a description of the information contained in the text SWIFT (Society for Worldwide Interbank Financial Telecommunication) defines structured text messages for the financial services industry

11. 11 Possible security standards Security required to Prevent unauthorized manipulation of data Authenticate the sender of electronic messages Messages can be encrypted prior to transmission Recipient requires the encryption key to decode messages Registry ARegistry B Secure connection (e.g. Secure Sockets Layers) Firewall Digital Certificate

12. 12 Other possible technical standards Internal verification procedures Maintaining data accuracy Verify identity of message senders Respect limits set for the commitment period reserve and sink units Institutional and legal frameworks Registry administrators etc, etc, etc …. User interfaces With the public, legal entities, other registries and the transaction log Data storage Accounting conventions and data retention

13. 13 Development of standards - ISO International Organization for Standardization (ISO) 12,000 ISO standards since establishment in 1947 Steps in the process 1.Define the technical scope of the future standard (working groups of experts from interested countries, including industry, research, government, consumer bodies) 2.Negotiation of detailed specification for the standard (consensus-building stage) 3.Formal approval as an ISO standard (requiring approval by two thirds of members actively participating) Reviews normally occur at intervals of not more than 5 years

14. 14 Development of standards - ECSDA European Central Securities Depositories Association (ECSDA) Formed in 1997 to develop links for cross-border securities trading Settlement and payment in Euros Involves CSDs, investors, market intermediaries and banks The model Each CSD needs only one gateway; no individual networks Real-time, automated processing Standardization of links across full network A single message carrier A manual processing fall-back option

15. 15 Development of standards - more on ECSDA ECSDA development of standards 1. Defined the high-level model of how they wanted to work (working group 1) 2. Refined the model; developed the detail (working group 3) 2. Developed the supporting technical design (working group 4) Working group 4 adopted ISO15022 standard messages Machine-readable messages SWIFT defines messages (in cooperation with ECSDA) ISO formally approves messages as being ISO15022 compliant Can be used across the SWIFT network http://www.iso15022.org/

16. 16 www.unfccc.int Andrew Howard UNFCCC secretariat ahoward@unfccc.int Possible elements of the technical standards