Data Exchange Standards in support of transaction processes 08 November 2004 Bonn, Germany

1. Data Exchange Standards in support of transaction processes 08 November 2004 Bonn, Germany Peggy Quarles Perrin Quarles Associates, Inc. peggyquarles@pqa.com

2. What is the purpose of the DES? • Define secure communication mechanism • Coordinate registry and ITL actions in transaction and reconciliation processes • Define data requirements for ITL review of registry transfers and unit block actions • Standard setting and procedures for technical cooperation • Ensure consistency with Kyoto rules • Requirements to ensure robust registries

3. How is the DES Organized? • Introductions and General Information • Section 3: Communications and Security • Section 4: Unit Transactions • Section 5: Reconciliation • Section 6: ITL Administrative Processes • Section 8: Change Management • Section 9: Registry Testing

4. Annexes for Technical Developers

5. How do Registries and the ITL Communicate? VPN XML Request “I am proposing a transfer to another registry.” XML Response “Proposal is acceptable, I will log and forward this.” Transferring Registry ITL XML Request “I have a transfer proposal, Please confirm or reject.” XML Response “The proposal is acceptable.” Acquiring Registry

6. What Makes the Exchange Secure? • Authentication through digital signatures • Virtual Private Network (VPN) • Encryption

7. What are the Communications Standards? • Web services and the Simple Object Access Protocol (SOAP) • Virtual Private Network (VPN) • Extensible Mark-up Language (XML)

8. Transaction Processes • A transaction is a unique operation on a unit or block of units. • A transaction is comprised of a series of actions related to a specific process. • Each transaction is processed in stages and results in the return of a message to the registry or to the ITL.

9. Kyoto Protocol Transaction Types • Issuance: Initial creation of an AAU, RMU, CER, tCER or lCER • Conversion: Transformation of an AAUs or RMUs into ERUs • External transfer: To move units from an account in one registry to an account in another • Cancellation: To move a unit into a cancellation account permanently (can be voluntary, mandatory, or for project-related reasons)

10. Kyoto Protocol Transaction Types • Replacement of tCERs and lCERs: To take account of the temporary nature of removals • Retirement: Internal transfer of units to retirement accounts to meet compliance target • Carry-over of units to next Commitment Period • Expiry Date Change: To extend the “life” of a tCER or lCER.

11. Transaction States • Proposed: Transaction that has been sent to ITL • Accepted: External transaction approved by ITL and accepted by Acquiring Registry • Terminated: Transaction invalidated by ITL and ended by Registry • Finalised: Transaction was validated and completed by Registry • Cancelled: Transaction that was not responded to within 24 hours

12. Account Types • Holding. For units not designated for a specific purpose, and available to be transferred. • Pending. For units issued by the CDM Registry, prior to their distribution to project participants • Cancellation. For units no longer available for trading or compliance • Retirement. For units used for compliance • Replacement. For units compensating for tCERs and lCERs which expire or otherwise lose their validity

13. Serial Numbers Some Unit characteristics cannot change: • Originating Registry or Party • Unique identifier • Original Commitment Period • Track • LULUCF Activity Code • Existing Project Number

14. More on Serial Numbers Some Unit characteristics can change, through specific transactions: • Applicable Commitment Period (through Carry-over) • Expiry Date (only tCERs and lCERs) • Unit Type (Conversion of AAUs and RMUs to ERUs)

15. Unit Blocks • Start Block and End Block define “Unit Blocks” of serialized units • Unit Blocks can be “split” within a registry and within the ITL • A unit is uniquely identified by the registry in which it is created and its unique number (for example, FR100001) • CDM Registry uses the project host Party instead of the Registry (for example IN100001).

16. Unique Identifiers

17. Key Transaction Terms • Transaction: A series or exchange of messages relating to a single transfer of units • Message: A communication between the ITL and a registry • Response: Information sent about a proposed transaction (Transaction ID, response codes, statuses)

18. Single Registry Transactions Initiating Registry ITL Is it Okay? Does registry confirm? Processing Generate Proposal Send Proposal to ITL for validation Processing Validate Proposal Update Transaction Status Send result of validation to registry Processing Update Status Send notification to ITL of the update transaction state Processing Update Transaction Status

19. Single Registry Behaviour Diagramand theIssuance Example

20. Registry Web Services and Functions

21. What does the Issuance Transaction Look Like? Consult Annex L for examples. .

22. Categories of Checks

23. Transaction-specific Checks for Issuance

24. Completing the Transaction – Discrepancy • The Registry terminates the transaction, and sends a terminated message to the ITL • The ITL records the transaction as terminated and the unit blocks proposed are NOT created • The Registry can correct the error and resend to ITL as new Transaction

25. Completing the Transaction – No Discrepancy • The Registry finalizes the transaction, creates the unit blocks in the Registry database, sends a finalized message to the ITL • The ITL records the transaction as finalized and creates the new Unit Blocks in the ITL database.