Data Exchange Standards in support of transaction processes

08 November 2004Bonn, Germany

Peggy Quarles

Perrin Quarles Associates, Inc.

peggyquarles@pqa.com

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

• 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

How is the DES Organized?

Annexes for Technical Developers

Annex Purpose

A Glossary

B, C, D Guidelines for Developing Technical Components and Functions

E Checks Performed by ITL and Response Codes

F Definition of Identifiers

G List of Codes

H Test Protocols

I, K, L Data Exchange Formats (WSDLs and Examples)

J Checklist of Requirements

How do Registries and the ITL Communicate?

VPN

XML Request“I am proposing a transfer

to another registry.”

XML Request“I have a transfer proposal,

Please confirm or reject.”

XML Response“Proposal is acceptable, I will

log and forward this.”

XML Response“The proposal is acceptable.”

ITL

TransferringRegistry

AcquiringRegistry

What Makes the Exchange Secure?

• Authentication through digital signatures

• Virtual Private Network (VPN)

• Encryption

What are the Communications Standards?

• Web services and the Simple Object Access Protocol (SOAP)

• Virtual Private Network (VPN)

• Extensible Mark-up Language (XML)

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.

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)

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.

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

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

Serial Numbers

Some Unit characteristics cannot change:

• Originating Registry or Party

• Unique identifier

• Original Commitment Period

• Track

• LULUCF Activity Code

• Existing Project Number

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)

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).

Unique Identifiers

Type Example Rules

Account Number FR1000 Registry Code + unique #, assigned by Registry

Transaction Number

FR1000 Registry Code + unique #, assigned by Registry

Reconciliation Number

FR1000 Registry Code + unique #, assigned by ITL

Project Number BO101 Party Code + unique #, assigned by Executive Board or JI Committee

Notification Number

1001 Unique #, assigned by ITL.

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)

Processing

Processing

Processing

Processing

Single Registry Transactions

Initiating Registry ITL

Send Proposal to ITL for validation

Validate Proposal

Is it Okay?

Send result of validation to registry

Send notification to ITL of the update transaction state

Update Transaction Status

Update Status

Generate Proposal

Update Transaction Status

Does registry confirm?

Single Registry Behaviour Diagramand theIssuance Example

:InitiatingRegistry

User Initiates Transaction

:ITL

:Registry User

sd Single Registry Transactions

Registry Checks Transaction

Generate_Proposal()

ITL Validates Proposal

[ Result = Validation Checks Fail ]alt

[ Result = Validation Checks Successful ]

AcceptProposal()

Finalise_Transaction()

AcceptNotification()

Record Transaction as Completed

AcceptNotification()

[ Result = Registry Terminates Issuance ]

Terminate Transaction(see reference diagram)

[ Result = Registry Confirms Issuance ]

ref

Discrepancy Notification(see reference diagram)

ref

altThis section describes the events that follow from the registry terminating the transaction.

This section describes the events that follow from a successful validation.

This section describes the events that follow from the validation checks failing.

This section describes the events that follow from the registry completing the transaction.

Transfer XML Document 1

Transfer XML Document 2

Transfer XML Document 3

Record Transaction as Checked (No Discrepancy)

Registry Web Services and Functions

Name Type Purpose

AcceptNotification Web service

Receives transaction messages from ITL

AcceptProposal Web service

Receives requests for external transfers from ITL

Check_Version; Data_Integrity_Check; Validate_Proposal;

Preliminary_checks

Functions Performs checks for all incoming transactions

Generate_Proposal; Finalise_Proposal

Functions Create and sends transaction; completes successful transfer

Write_to File; Write_to_Message_Log; Write_to_Transaction; Write_to_Transaction_Block; Write_to_Transaction_Status

Functions Logging and Data Updates

What does the Issuance Transaction Look Like?

Consult Annex L for examples.

.

Categories of Checks

Category Purpose

Version and AuthenticationCan the ITL verify the identify of the

submitter?

Message Validity Is the message readable and complete?

Registry ValidityAre the registries involved authorized 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 ChecksDoes the message comply with Kyoto

requirements for type of transaction?

Transaction-specific Checks for Issuance

Check Numbers Type of Check

5001, 5002, 5003 Checks on who can issue what types of units

5004, 5005, 5006 Checks on the characteristics of the unit blocks to be issued

5007 Have these unit blocks already been issued?

5008, 5009 Would issuing these blocks exceed the allowable number?

5010, 5011, 5012, 5013, 5014, 5015,5016

Are the units and unit characteristics for CDM projects correct?

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

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.