1. 1 Andrew Howard UNFCCC secretariat www.unfccc.int ahoward@unfccc.int International transaction log Roles and functions Intersessional consultations on registry systems Bonn 8-10 November 2004

2. 2 Integration of the ITL Independent transaction log Communications hub Virtual private network Base checks Supple- mentary checks NR 2 NR 3 NR 4 CDM-RNR 1 Supplementary transaction log 1 Supplementary transaction log 2

3. 3 ITL roles and functions Independently checks transactions proposed by registries against modalities, rules and limits set out in COP decisions Registries required to terminate transactions where discrepancies from the rules are identified ITL and its communications hub are integrated in the processing and stages of the data exchange standards Regular reconciliation of registry data with the ITL ITL notifications informing registries of required actions ITL ensures integrity of transactions before their completion

4. 4 Technically speaking

5. 5 Key design issues Real-time performance, high availability Message queuing to handle high volumes Oversight of the secure network with registries Platform independent Modular design to allow growth and change Flexibility to add or change ITL checks

6. 6 Supporting technical specifications Database design and structure Logical flows for transaction and reconciliation processes Detailed specifications for ITL checks Links to other databases for some checks -Compilation and accounting database -CDM information system -JI information system (track 2) Detailed specifications for ITL notifications

7. 7 Core data in the ITL Unit blocks Each unit issued, its status and the registry in which it is currently held Transaction logsCurrent and historical transaction records Reconciliation logs All reconciliation actions performed, inconsistent unit blocks identified and cases of manual intervention carried out Notification logs All notifications to sent to registries and record of whether actions are carried out

8. 8 Integration with STLs ITL passes messages to STLs where involved Parties belong to a regional trading scheme (eg EU trading) -Standard transaction processes -Internal transfers under EU trading Direct pass through of information where desired (eg account management messages) Limited processing by ITL in order to maintain consistent records with STLs (eg splitting unit blocks)

9. 9 Message sequence with STLs 2. Perform ITL checks on proposal 3. Route proposal to appropriate STL 4. Specific EC checks applied by CITL 5. Return evaluation result 1. Propose transaction 6. Forward proposal to acquiring registry 7. Finalize transaction 9. Finalize transaction 8. Notify ITL 13. Notify CITL 14. Finalize transaction 15. Notify ITL 10. Notify transferring registry 11. Finalize transaction 12. Notify ITL

10. 10 ITL notifications Indicating required actions

11. 11 ITL notifications to registries Replacements Requirements for tCER or lCER replacement due to impending expiry, reversal of storage, or failure to submit a certification report for the project Cancellations Requirements for units to be cancelled due to net LULUCF emissions or non-compliance of a Party with its emissions target in the previous period Excess Issuance Requirements for operational entities to compensate for excess issuance for a CDM project CPR level Requirements to raise unit holdings to meet the CPR level, where a CPR level change, cancellation or replacement leaves a Party below this level Unit carry-over To indicate the quantity of units which may be carried-over or which must be cancelled

12. 12 Cancellation types Net source cancellation For net LULUCF emissions (Articles 3.3/4) Non-compliance cancellation For non-compliance with an emissions target in the previous commitment period Voluntary cancellation Cancellation voluntarily carried out by unit holder Excess issuance cancellation Where CDM Executive Board requires an operational entity to compensate for prior excess issuance of CERs, tCERs or lCERs Mandatory cancellation For removing units from holding accounts: - expired tCERs and lCERs - lCERs permanently ineligible for transfer - any units not been carried over after true-up

13. 13 Replacement types tCER replacement for expiry Undertaken upon expiry of a tCER lCER replacement for expiry Undertaken upon expiry of a lCER lCER replacement for reversal in storage Undertaken for a reversal of net removals from a CDM project lCER replacement for non-submission of certification report Undertaken where a certification report has not been provided the project

14. 14 Fulfilment of ITL notifications 30 days to fulfil required actions Notification identifier is given by registries for each transaction relating to the notification ITL associates relevant transactions with identifiers  ITL assesses when required actions are completed Follow-up notifications by the ITL  to indicate when a required action is complete  to provide status updates on fulfilment Unfulfilled cancellation and replacement notifications taken into account in CPR calculations (after 30 days)

15. 15 ITL response codes Indicating negative check results

16. 16 ITL responses No discrepancies identified  positive message, transaction continues Discrepancies identified  negative message, registry terminates transaction  response code indicates reason for check failure Some checks are primarily technical  ensuring that registry systems communicate well Some checks are primarily policy-related  ensuring conformity with Kyoto rules Check categories define order in which checks are applied

17. 17 Check categories Version and authentication Can the ITL verify submitter ’ s identity? Message validityIs the message readable and complete? Registry validityAre registries involved able to operate? Transaction data integrityDoes the data makes sense? Message sequencesIs the message in the correct order? General transaction checks Does the message comply with general requirements for transactions? Transaction-specific checks Does the message comply with Kyoto requirements for the type of transaction?

18. 18 ITL response code examples Response code20175008 Check nameProject identifierAAU issuance quantity Check description CERs, tCERs, lCERs and ERUs must have a valid project identifier The quantity of AAUs issued must not exceed allowed quantity for the commitment period Check categoryData integrityTransaction-specific Transaction typeAllIssuance