The Transaction Log under the Kyoto Protocol

Transcription

1 Working Paper No. 9 (2003), Annex II Pre-sessional consultations on registries Bonn, Germany, 2 June 2003 The Transaction Log under the Kyoto Protocol Functional Specification Draft version <4.0> Page 1 of 25

2 Table of Contents 1. INTRODUCTION Purpose Intended Audience Scope Definitions, Acronyms and Abbreviations References ASSUMPTIONS FUNCTIONAL REQUIREMENTS Data Exchange Standards Data Exchange Standard Automated Checks Logging Transactions Logging Messages and Notifications Logging Transaction Log Users Message and Notification Processing Transaction Processing Issuance Sequence Conversion Sequence (Issuance of ERUs) External Transfer Sequence (Transfers between Registries) Internal Transfer Sequence (Cancellation) Internal Transfer Sequence (Retirement) Carry-Over Sequence Transaction Cancellation Transaction Confirmation Transaction Discrepancy Notification Transaction Error Notification Transaction Flagging NON-FUNCTIONAL REQUIREMENTS...18 Page 2 of 25

3 4.1 General Flexibility of the system Runtime adaptability Help / Support Common Look and Feel Classes of User Interfaces Ease of use Dependability Mean Time to Failure Availability Performance Performance of System Scalability Safety System Backup Recovery Security Authentication Authorization GENERAL CONSTRAINTS Product and Vendor independence DOCUMENTATION REQUIREMENTS User Documentation Systems Documentation Modelling Messages and Interaction INTERFACES User Interfaces User Interface for Reference Data User Interface for Messaging...23 Page 3 of 25

4 7.1.3 User Interface for Auditing User Interface for Reports User Interface for Automated Checks User Interface for Administration User Interface for Transaction Sequences Class of Comfort Hardware Interfaces Common Interfaces Software Interfaces Communications Interfaces Data Exchange Standard...25 Page 4 of 25

5 Functional Specification 1. Introduction 1.1 Purpose The purpose of this functional specification of the transaction log is to define the key requirements that the log will need to fulfil. This document represents the first stage of translating the results of the international political negotiations into a technical system that is to, one day in the future, perform the tasks that the negotiators foresaw. It therefore also sets out constraints within which the system will have to operate and, where a wider range of options is possible, acceptance criteria upon which the system will be judged. The next step in developing the transaction log will be the preparation of a technical specification. Whereas the functional specification sets out what the transaction log needs to do, the technical specifications will detail how, in technological terms, this needs to be done. 1.2 Intended Audience This document is by necessity technical in nature. It is primarily intended to guide technical experts in preparing the technical specification and constructing the transaction log. 1.3 Scope The transaction log is to verify that transactions conducted by national registries and the CDM registry conform to the rules established under the Kyoto Protocol. Through being integrated into the flow of electronic communication between registries, the transaction log is to monitor and log the course of transactions and conduct independent and automated checks for discrepancies from an agreed set of transaction rules. These checks are to be conducted on the creation ( issuance ), use ( retirement ) or destruction ( cancellation ) of units within registries and the movement ( transfer ) of units between registries. When notified of a discrepancy by the transaction log, registries are to terminate the transaction. All communication is to be routed through a central communications hub integrated with the transaction log and is to occur by means of the data exchange standards. National registry (of an Annex I Party) CDM registry (Non-Annex I Party) Sender/receiver Communication via the data exchange standards Sender/receiver Sender/receiver Communication hub Autochecks Transaction log Page 5 of 25

6 This functional specification contains: Assumptions Functional requirements. Non-Functional requirements. General constraints Documentation requirements Interfaces 1.4 Definitions, Acronyms and Abbreviations See glossary appended to this document for definitions, acronyms and abbreviations. 1.5 References This specification is derived from decisions by the Conference of the Parties to the UNFCCC: On emissions trading and projects under the clean development mechanism and joint implementation, see decisions 15-18/CP.7 document FCCC/CP/2001/13/Add.2 On modalities for accounting for assigned amount (including requirements for national registries and the transaction log in section II of the annex), see decision 19/CP.7 document FCCC/CP/2001/13/Add.2 On the CDM registry, see appendix D to the annex of decision 17/CP.7 document FCCC/CP/2001/13/Add.2 On the data exchange standards, see decision 24/CP.8 document FCCC/CP/2002/7/Add.3 Page 6 of 25

7 2. Assumptions The assumptions for this functional specification are organized in a table in order to identify their impact on affected requirements. A1 Assumption The descisions contained in the derivation documents will remain stable Page 7 of 25

8 3. Functional Requirements This section defines the requirements for the transaction log that are directly related to its functionality. These are organized in three sub-sections: 3.1 Data Exchange Standards 3.2 Automated Checks 3.1 Data Exchange Standards The data exchange standards are the basis for the collaboration of the national registries of Annex I Parties, the CDM registry and the transaction log. They provide for the implementation of a common data transfer format and common functionality to ensure accurate, transparent and efficient data transfer between registries and the transaction log Data Exchange Standard TL-FR1 The transaction log shall use the data exchange standards for data transmission to and from registries The requirements for the transaction log specified in the functional specification of the Data Exchange Standard must be met in full 3.2 Automated Checks The transaction log checks if transactions being performed by the registries are in conformity with specified rules and logs information relating to these transactions. This information provides for a full audit trail. In addition the transaction log provides multiple interfaces for different actors to interact with the system. The diagrams below give an overview on the functions and actors of the transaction log Automated Checks Logging Issuance Conversion External transfer Cancellation Retirement Carry Over National Registry CDM Registry Page 8 of 25

9 User Interfaces Officer Administrator Reference Data Messaging Auditing Reports Administration of Automated Checks Administration of Transaction Sequences Logging Logging Transactions TL-FRA1 The transaction log and communication hub shall provide information on transactions for audits Must log for every transaction, including: Time certification information Record set as specified in DES-FR3 Transaction type Transaction number Transaction status Transaction stage Sender registry Logging Messages and Notifications TL-FRA2 The transaction log and communication hub shall provide information on messages and notifications for audits Must at least log for every message and notification: Identifier Content Time certification information Logging Transaction Log Users TL-FRA3 The transaction log shall provide information on its users for audits Every interaction with the system must be logged Data to be logged includes: User Time and Date Data Inputs Page 9 of 25

10 3.2.4 Message and Notification Processing TL-FRA4 Messages and notifications sent by registries must be identifiable and shall be processed in a uniform manner All messages and notifications must go through a standard sequence. Mandatory steps in the sequence are: Log message or notification Send acknowledgement of incoming messages and notification to sender Forward message or notification to automated checks, destination registry or administrator Transaction Processing TL-FRA5 Transactions shall be processed through a specific sequence Sequences must be defined for the following transaction types: Issuance Conversion (issuance of ERUs) External transfer (transfers between registries) Internal transfer (cancellation) Internal transfer (retirement) Carry-over Transactions are automatically identified and processed Page 10 of 25

11 3.2.6 Issuance Sequence TL-FRA6 The transaction log shall verify the validity of the issuance of AAUs, RMUs and CERs, based on the issuance process Minimum input data: Transaction number Initiating registry Commitment period Transaction type Total quantity of units Serial number for each unit, in blocks Destination account number Time certification The transaction is valid when: Data format of messages and notification is complete Data format of messages and notification is correct Each serial number is complete Each serial number format is correct Each serial number is unique Each RMU serial number contains the appropriate LULUCF activity element Each ERU and CER serial number contains the appropriate project identifier Total number of AAUs would not exceed the Party's reviewed assigned amount pursuant to Articles 3.7 and 3.8 Total number of RMUs would not exceed the Party's reviewed net changes in emissions and removals pursuant to Articles 3.3 and 3.4 Total number of CERs to be issued does not exceed the associated CDM Executive Board issuance instruction No unresolved questions of implementation relating to inventories remain under Article 8 process No issuance of RMUs before the end of the commitment period (unless annual issuance option is selected ) Actions following the automated checks: Notify registry of transaction validity, as appropriate Notify registry of transaction discrepancy discovered, as appropriate Where a discrepancy is discovered, flag relevant units in the transaction log data records Where confirmation is received from registries that a transaction is terminated, remove flag from relevant units Page 11 of 25

12 3.2.7 Conversion Sequence (Issuance of ERUs) TL-FRA7 The transaction log shall verify the validity of the conversion of AAUs or RMUs to ERUs, based on the conversion process Minimum input data is: Transaction number Initiating registry Commitment period Transaction type Total quantity of units Serial number for each unit, in blocks Source account number Time certification JI project identifier The transaction is valid when: Data format of messages and notification is complete Data format of messages and notification is correct Annex I Party is eligible to participate in the mechanisms Legal entity is authorized by the Party to participate in the mechanisms Each serial number is complete Each serial number format is correct Each serial number is unique Each RMU serial number contains the appropriate LULUCF activity element Each ERU and CER serial number contains the appropriate project identifier No serial number modification has occurred (other than the addition of a project identifier, as appropriate) Each unit is held in the initiating registry No unit is associated with an ongoing transaction No unit has been previously cancelled No unit has been previously retired No unit is associated with an unresolved discrepancy Each unit is recognized as valid for the current commitment period Each base unit is an AAU or RMU Each base unit was issued by the initiating Party Total number of ERUs to be issued does not exceed the verified reduction/removal No unresolved questions of implementation relating to inventories remain under Article 8 process Actions following the automated checks: Notify registry of transaction validity, as appropriate Notify registry of transaction discrepancy discovered, as appropriate Where a discrepancy is discovered, flag relevant units in the transaction log data records Where confirmation is received from registries that a transaction is terminated, remove flag from relevant units Page 12 of 25

13 3.2.8 External Transfer Sequence (Transfers between registries) TL-FRA8 The transaction log shall verify the validity of transfers of AAUs, CERs, ERUs and RMUs between registries, based on the external transfer process Minimum input data is: Transaction number Initiating registry Commitment period Transaction type Total quantity of units Serial number for each unit, in blocks Source account number Destination account number Time certification The transaction is valid when: Data format of messages and notification is complete Data format of messages and notification is correct Annex I Party is eligible to participate in the mechanisms Legal entity is authorized by the Party to participate in the mechanisms Each serial number is complete Each serial number format is correct Each serial number is unique Each RMU serial number contains the appropriate LULUCF activity element Each ERU and CER serial number contains the appropriate project identifier No serial number modification has occurred (other than the addition of a project identifier, as appropriate) Each unit is held in the initiating registry No unit is associated with an ongoing transaction No unit has been previously cancelled No unit has been previously retired No unit is associated with an unresolved discrepancy Each unit is recognized as valid for the current commitment period No unresolved questions of implementation relating to inventories remain under Article 8 process There would be no violation of the Party's commitment period reserve Actions following the automated checks: Notify registry of transaction validity, as appropriate Notify registry of transaction discrepancy discovered, as appropriate Where a discrepancy is discovered, flag relevant units in the transaction log data records Where confirmation is received from registries that a transaction is terminated, remove flag from relevant units Page 13 of 25

14 3.2.9 Internal Transfer Sequence (Cancellation) TL-FRA9 The transaction log shall verify the validity of the cancellation of AAUs, CERs, ERUs and RMUs, based on the internal transfer process Minimum input data is: Transaction number Initiating registry Commitment period Transaction type Total quantity of units Serial number for each unit, in blocks Source account number Destination account number Time certification The transaction is valid when: Data format of messages and notification is complete Data format of messages and notification is correct Each serial number is complete Each serial number format is correct Each serial number is unique Each RMU serial number contains the appropriate LULUCF activity element Each ERU and CER serial number contains the appropriate project identifier No serial number modification has occurred (other than the addition of a project identifier, as appropriate) Each unit is held in the initiating registry No unit is associated with an ongoing transaction No unit has been previously cancelled No unit has been previously retired No unit is associated with an unresolved discrepancy Each unit is recognized as valid for the current commitment period No unresolved questions of implementation relating to inventories remain under Article 8 process Actions following the automated checks: Notify registry of transaction validity, as appropriate Notify registry of transaction discrepancy discovered, as appropriate Where a discrepancy is discovered, flag relevant units in the transaction log data records Where confirmation is received from registries that a transaction is terminated, remove flag from relevant units Page 14 of 25

15 Internal Transfer Sequence (Retirement) TL-FRA10 The transaction log shall verify the validity of the retirement of AAUs, CERs, ERUs and RMUs, based on the internal transfer process Minimum input data is: Transaction number Initiating registry Commitment period Transaction type Total quantity of units Serial number for each unit, in blocks Source account number Destination account number Time certification The transaction is valid when: Data format of messages and notification is complete Data format of messages and notification is correct Annex I Party is eligible to use CERs towards compliance Each serial number is complete Each serial number format is correct Each serial number is unique Each RMU serial number contains the appropriate LULUCF activity element Each ERU and CER serial number contains the appropriate project identifier No serial number modification has occurred (other than the addition of a project identifier, as appropriate) Each unit is held in the initiating registry No unit is associated with an ongoing transaction No unit has been previously cancelled No unit has been previously retired No unit is associated with an unresolved discrepancy Each unit is recognized as valid for the current commitment period No unresolved questions of implementation relating to inventories remain under Article 8 process Actions following the automated checks: Notify registry of transaction validity, as appropriate Notify registry of transaction discrepancy discovered, as appropriate Where a discrepancy is discovered, flag relevant units in the transaction log data records Where confirmation is received from registries that a transaction is terminated, remove flag from relevant units Page 15 of 25

16 Carry-Over Sequence TL-FRA11 The transaction log shall verify the validity of the carry-over of AAUs, CERs and ERUs to the next commitment period, based on the carry-over process Minimum input data is: Transaction number Initiating registry Commitment period Transaction type Total quantity of units Serial number for each unit, in blocks Source account number Time certification The transaction is valid when: Data format of messages and notification is complete Data format of messages and notification is correct Each serial number is complete Each serial number format is correct Each serial number is unique Each RMU serial number contains the appropriate LULUCF activity element Each ERU and CER serial number contains the appropriate project identifier No serial number modification has occurred (other than the addition of a project identifier, as appropriate) Each unit is held in the initiating registry No unit is associated with an ongoing transaction No unit has been previously cancelled No unit has been previously retired No unit is associated with an unresolved discrepancy Each unit is recognized as valid for the current commitment period Each unit to be carried over is listed in the Party's final compilation and accounting report No unit is an RMU No unit is an ERU converted from an RMU No unit is a CER from an afforestation or reforestation CDM project activity No unresolved questions of implementation relating to inventories remain under Article 8 process Total number of ERUs to be carried over does not exceed the limit Total number of CERs to be carried over does not exceed the limit Actions following the automated checks: Notify registry of transaction validity, as appropriate Notify registry of transaction discrepancy discovered, as appropriate Where a discrepancy is discovered, flag relevant units in the transaction log data records Where confirmation is received from registries that a transaction is terminated, remove flag from relevant units Page 16 of 25

17 Transaction Cancellation TL-FRA12 The transaction log shall cancel a transaction Cancellation criteria are: A period of time (to be specified) has elapsed without response to a message Affected registries are automatically informed Transaction Confirmation TL-FRA13 The transaction log shall confirm the validity of a transaction All affected registries are automatically informed Confirmation criteria are: Automated checks do not discover any discrepancies Transaction Discrepancy Notification TL-FRA14 The transaction log shall inform affected registries of a discrepancy discovered by the automated checks Discrepancy information is contained in the notification Rules against which there is a discrepancy Affected units Affected registries and the secretariat are automatically informed Transaction Error Notification TL-FRA15 The transaction log shall inform affected registries of messages or notifications containing incomplete data or incorrect format Affected registries are automatically informed about the error in a transaction Transaction Flagging TL-FRA16 The transaction log shall, in its data records, flag units for which a discrepancy has been discovered Affected units remain flagged until confirmation is received from all affected registries that the transaction has been terminated Page 17 of 25

18 4. Non-Functional Requirements This section defines the requirements for the transaction log that are not directly related to its functionality. These are organized in five sub-sections: 4.1 General 4.2 Dependability 4.3 Performance 4.4 Safety 4.5 Security 4.1 General Flexibility of the system TL-GR1 The transaction log shall be flexible to allow additions and changes Upgrades or changes in functionality do not impose a complete rebuild of the system Runtime adaptability TL-GR2 Clearly defined release process Changes and upgrades to the system must be possible during the runtime of the system Help / Support TL-GR3 Help and support shall be provided for the UNFCCC secretariat Service Level Agreements and Operation Level Agreements in place Common Look and Feel TL-GR4 The transaction log user interface shall be designed according to UN standards Application of the UN visual styleguide Classes of User Interfaces TL-GR5 The transaction log user interface shall be realized as a web based GUI Browsers listed in the UN blueprint have to be supported Ease of use TL-GR6 The transaction log shall be easy and intuitive to use Successful user acceptance test Page 18 of 25

19 4.2 Dependability Mean Time to Failure TL-DR1 The failure rate of the system shall be reduced to a minimum. To be specified Availability TL-DR2 The availability of the system per year shall be a maximum. To be specified 4.3 Performance Performance of System TL-PR1 The transaction log shall be able to handle multiple users, connections, messages and transactions initially Scalability TL-PR2 The performance of the transaction log shall be scaleable 4.4 Safety System Backup TL-SR1 A copy of the system shall be at hand in case of system failure System is backed up on a regular basis Recovery TL-SR2 The recovery of the system shall be possible within a short period of time. Consistency with system status before failure occurs 4.5 Security Authentication TL-SER1 Only authenticated users shall be able to use the transaction log Users can only work with the transaction log after they have authenticated themselves Page 19 of 25

20 4.5.2 Authorization TL-SER2 The system shall provide for authorisation levels Possibility for authorisation on system functionalities for different roles Page 20 of 25

21 5. General 5.1 Product and Vendor independence TL-C1 The transaction log shall be product and vendor independent Page 21 of 25

22 6. Documentation Requirements 6.1 User Documentation TL-DR1 How the user can interact with the system shall be documented 1 electronic document, in English Complete Meets needs of different user types 6.2 Systems Documentation TL-DR2 The system shall be documented 1 electronic MS Word Document, in English Topics to be covered: Recovery of the system Administration of the system Detailed description of the software system Configuration of the system FAQ for the system Complete Accepted by the support vendor for operations and maintenance needs Appropriate for future development 6.3 Modelling Messages and Interaction DES-DR3 Modelling messages and interaction between systems shall be done using a standard notation Must use UML Page 22 of 25

23 7. Interfaces This section defines the interfaces that must be supported by the system. These are organized in four sub-sections: 7.1 User Interfaces 7.2 Hardware Interfaces 7.3 Software Interfaces 7.4 Communications Interfaces 7.1 User Interfaces User Interface for Reference Data TL-UIR1 The system shall have a user interface to enter reference data into the system (to facilitate the automated checks) Minimum reference data to be entered is : Eligible Parties Authorized legal entities Assigned amount pursuant to Article 3.7 and 3.8 of the Protocol Net changes in emissions and removals pursuant to Articles 3.3 and 3.4 of the Protocol Emissions and removals from CDM projects Emissions and removals from JI projects Latest Party emissions inventory data Unresolved questions of implementation relating to inventories Inform registry and the secretariat of any violation of the commitment period reserve following receipt of latest Party emissions inventory data Automation of high volume data inputs User Interface for Messaging Constraint TL-UIR2 The transaction log shall have a user interface for handling messages and notifications Minimum features to be implemented: View messages and notifications Answer messages and notifications Send messages and notifications Organize messages and notifications o Open / closed / pending / archive Message and notification can be assigned to a transaction User Interface for Auditing TL-UIR3 The transaction log shall have a user interface to performing audits Auditing results can be saved to external disk or printed out Enable a user to get detailed information, at minimum on the: Transaction trail Transaction status Transaction stage Message trail Unit trail Unit status Page 23 of 25

24 7.1.4 User Interface for Reports TL-UIR4 The transaction log shall have a user interface to generate reports manually Reported results can be saved to external disk or printed out Reports can be configured Reports can be automated Enable a user to generate a report on the following areas (at minimum): Pending transactions Transactions with flagged units Completed transactions Terminated transactions Transaction cancellations Unit flagging Eligibility and suspension of Annex I Parties of messages / notifications Hacker attacks System uptime System downtime System load System errors User Interface for Automated Checks TL-UIR5 The system shall have a user interface to enter and edit data for the automated checks Data to be entered is : Commitment period reserve (percentage) Period for filling up the commitment reserve (days) Limit of CER carry-over (percent) Limit of ERU carry-over (percent) User Interface for Administration TL-UIR6 The system shall have an user interface for the user and registry management of the system Minimum features are to include: Add user Remove user Edit user Change password Add registry Remove registry Edit registry User Interface for Transaction Sequences TL-UIR7 The system shall have an user interface for transaction sequence administration Minimum features are to include: Assign rule to sequences Remove rule from sequence Page 24 of 25

25 7.1.8 Class of Comfort TL-UIR8 The system shall provide information for users on system use Must be an electronic help system 7.2 Hardware Interfaces Common Interfaces TL-HR1 The transaction log system shall support common hardware interfaces. Common hardware interfaces are considered to be keyboard and network connection. 7.3 Software Interfaces The software interfaces of the transaction log are to national registries and the CDM registry. 7.4 Communications Interfaces Data Exchange Standard TL-FR1 The transaction log communication shall only be through standard communication interfaces See Data exchange standards Page 25 of 25