18
1 Andrew Howard UNFCCC secretariat www.unfccc.int [email protected] International transaction log Roles and functions Intersessional consultations on registry systems Bonn 8-10 November 2004

1 Andrew Howard UNFCCC secretariat [email protected] International transaction log Roles and functions Intersessional consultations on

Embed Size (px)

Citation preview

1

Andrew HowardUNFCCC secretariat

[email protected]

Internationaltransaction log

Roles and functions

Intersessional consultationson registry systems

Bonn8-10 November 2004

2

Integration of the ITL

Independent transaction log

Communications hub

Virtual private network

Basechecks

Supple-mentary

checks

NR2 NR3 NR4 CDM-RNR1

Supplementarytransaction log1

Supplementarytransaction log2

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

Technically speaking

Client Registry Server

`

Client Registry PCWeb ApplicationServer Cluster

DatabaseServers

FirewallFirewall

InternetVPN Endpoint

VPN Concentrator

Traffic betweenregistry server and ITLweb application server

is SSL encrypted

The IPSec tunnelsthrough any firewalls

and the Internet

CommunicationsHub

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

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

Core data in the ITL

Unit blocksEach unit issued, its status and the registry in which it is currently held

Transaction logs Current and historical transaction records

Reconciliation logsAll reconciliation actions performed, inconsistent unit blocks identified and cases of manual intervention carried out

Notification logsAll notifications to sent to registries and record of whether actions are carried out

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

Message sequence with STLs

AcquiringRegistry

TransferringRegistry

CITL

Other STL

ITL

2. Perform ITL checks on proposal

3. Route proposalto 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 transaction15. Notify ITL

10. Notify transferring registry

11. Finalize transaction

12. NotifyITL

10

ITL notificationsIndicating required actions

11

ITL notifications to registries

ReplacementsRequirements for tCER or lCER replacement due to impending expiry, reversal of storage, or failure to submit a certification report for the project

CancellationsRequirements 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 IssuanceRequirements for operational entities to compensate for excess issuance for a CDM project

CPR levelRequirements 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-overTo indicate the quantity of units which may be carried-over or which must be cancelled

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

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

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

ITL response codesIndicating negative check results

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

Check categories

Version and authentication

Can the ITL verify submitter’s identity?

Message validity Is the message readable and complete?

Registry validity Are registries involved able to operate?

Transaction data integrity Does the data makes sense?

Message sequences Is 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

ITL response code examples

Response code 2017 5008

Check name Project identifier AAU issuance quantity

Check descriptionCERs, 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 category Data integrity Transaction-specific

Transaction type All Issuance