Possible elements of the technical standards Pre-sessional consultations

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

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 2

Considerations in developing technical standards Minimum technical standards to ensure the “accurate, transparent and efficient exchange of data between national registries, the CDM registry and the transaction log” • 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? • What degree of harmonization? • How to ensure registries may develop independently? • What can be learned from other fields? 3

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 4

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

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? 6

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

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

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

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 (e. Xtensible 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 10

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

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 User interfaces • With the public, legal entities, other registries and the transaction log Data storage • Accounting conventions and data retention Registry administrators Institutional and legal frameworks etc, etc …. 12

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 13

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 14

Development of standards - more on 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 ISO 15022 standard messages • Machine-readable messages • SWIFT defines messages (in cooperation with ECSDA) • ISO formally approves messages as being ISO 15022 compliant • Can be used across the SWIFT network http: //www. iso 15022. org/ 15

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