Commission Regulation (EC) No 2216/2004 (repealed)Show full title

ANNEX I U.K. Hardware and software requirements of registries and the Community independent transaction log

Architecture requirements U.K.

1. Each registry and the Community independent transaction log shall include the following hardware and software in their architecture: U.K.

(a)

web server;

(b)

application server;

(c)

database server installed on a separate machine to that or those used for the web server and application server;

(d)

firewalls.

Communication requirements U.K.

[F1 2. When the communication link between the Community independent transaction log and the UNFCCC independent transaction log is not established: U.K.

(a)

the record of the time in the Community independent transaction log and each registry shall be synchronised to Greenwich Mean Time;

(b)

all processes concerning allowances, verified emissions, automatic national allocation plan table changes and accounts shall be completed by the exchange of data written in extensible markup language (XML) using the simple object access protocol (SOAP) version 1.1 over the hypertext transfer protocol (HTTP) version 1.1 (remote procedure call (RPC) encoded style).]

Textual Amendments

F1 Substituted by Commission Regulation (EC) No 916/2007 of 31 July 2007 amending Regulation (EC) No 2216/2004 for a standardised and secured system of registries pursuant to Directive 2003/87/EC of the European Parliament and of the Council and Decision No 280/2004/EC of the European Parliament and of the Council (Text with EEA relevance).

[F1 3. When the communication link between the Community independent transaction log and the UNFCCC independent transaction log is established: U.K.

(a)

the record of the time in the UNFCCC independent transaction log, Community independent transaction log and each registry shall be synchronised; and

(b)

all processes concerning allowances and Kyoto units shall be completed by the exchange of data;

using the hardware and software requirements set out in the functional and technical specifications for data exchange standards for registry systems under the Kyoto Protocol, elaborated pursuant to Decision 24/CP.8 of the Conference of the Parties to the UNFCCC.

If processes concerning verified emissions, accounts and automatic national allocation plan table changes are completed through an exchange of data via the UNFCCC independent transaction log and thereon to the Community independent transaction log, the data exchange shall be carried out using the hardware and software requirements set out in the functional and technical specifications for data exchange standards for registry systems under the Kyoto Protocol, elaborated pursuant to Decision 24/CP.8 of the Conference of the Parties to the UNFCCC.

If processes concerning verified emissions, accounts and automatic national allocation plan table changes are completed through an exchange of data via the Community independent transaction log, the data exchange shall be carried out in accordance with point (b) of paragraph 2.]

ANNEX II U.K. Tables to be contained in Member State registries

1.

Each Member State registry shall be capable of tabulating the following information which shall comprise the verified emissions table:

(a)

Years: in individual cells from 2005 onwards in ascending order.

(b)

Installation identification code: in individual cells comprising the elements set out in Annex VI and in ascending order.

(c)

Verified emissions: the verified emissions for a specified year for a specified installation shall be entered into the cell connecting that year to that installation’s identification code.

2.

Each Member State registry shall be capable of tabulating the following information which shall comprise the surrendered allowances table:

(a)

Years: in individual cells from 2005 onwards in ascending order.

(b)

Installation identification code: in individual cells comprising the elements set out in Annex VI and in ascending order.

(c)

Surrendered allowances: the number of allowances surrendered in accordance with Articles 52, 53 and 54 for a specified year for a specified installation shall be entered into the three cells connecting that year to that installation’s identification code.

3.

Each Member State registry shall be capable of tabulating the following information which shall comprise the compliance status table:

(a)

Years: in individual cells from 2005 onwards in ascending order.

(b)

Installation identification code: in individual cells comprising the elements set out in Annex VI and in ascending order.

(c)

Compliance status: the compliance status for a specified year for a specified installation shall be entered into the cell connecting that year to that installation’s identification code. The compliance status shall be calculated in accordance with Article 55.

ANNEX III U.K. Information concerning each operator holding account to be provided to the registry administrator

1.

Points 1 to 4.1, 4.4 to 5.5 and point 7 (activity 1) of the information identifying the installation as listed in section 11.1 of Annex I to Decision 2004/156/EC.[F2 The name of the operator should be identical to name of the natural or legal person that is the holder of the relevant greenhouse gas permit. The name of the installation shall be identical to the name indicated in the relevant greenhouse gas permit.]

2.

The permit identification code specified by the competent authority, comprising the elements set out in Annex VI.

3.

The installation identification code, comprising the elements set out in Annex VI.

4.

The alphanumeric identifier specified by the operator for the account, which shall be unique within the registry.

5.

Name, address, city, postcode, country, telephone number, facsimile number and e-mail address of the primary authorised representative of the operator holding account specified by the operator for that account.

6.

Name, address, city, postcode, country, telephone number, facsimile number and e-mail address of the secondary authorised representative of the operator holding account specified by the operator for that account.

7.

Name, address, city, postcode, country, telephone number, facsimile number and e-mail address of any additional authorised representatives of the operator holding account and their account access rights, specified by the operator for that account.

8.

Evidence to support the identity of the authorised representatives of the operator holding account.

Textual Amendments

F2 Inserted by Commission Regulation (EC) No 916/2007 of 31 July 2007 amending Regulation (EC) No 2216/2004 for a standardised and secured system of registries pursuant to Directive 2003/87/EC of the European Parliament and of the Council and Decision No 280/2004/EC of the European Parliament and of the Council (Text with EEA relevance).

ANNEX IV U.K. Information concerning accounts referred to in Article 11(1), (3) and (4) and person holding accounts to be provided to the registry administrator

1.

Name, address, city, postcode, country, telephone number, facsimile number and e-mail address of the person requesting the opening of the person holding account.

2.

Evidence to support the identity of the person requesting the opening of the person holding account.

3.

The alphanumeric identifier specified by the Member State, the Commission or person for the account, which shall be unique within the registry.

4.

Name, address, city, postcode, country, telephone number, facsimile number and e-mail address of the primary authorised representative of the account specified by the Member State, the Commission or person for that account.

5.

Name, address, city, postcode, country, telephone number, facsimile number and e-mail address of the secondary authorised representative of the account specified by the Member State, the Commission or person for that account.

6.

Name, address, city, postcode, country, telephone number, facsimile number and e-mail address of any additional authorised representatives of the account and their account access rights, specified by the Member State, the Commission or person for that account.

7.

Evidence to support the identity of the authorised representatives of the account.

ANNEX V U.K. Core terms and conditions

Structure and effect of core terms and conditions U.K.

1. The relationship between account holders and registry administrators. U.K.

The account holder and authorised representative’s obligations U.K.

2. The account holder and authorised representative’s obligations with respect to security, usernames and passwords, and access to the registry website. U.K.

3. The account holder and authorised representative’s obligation to post data on the registry website and ensure that data posted is accurate. U.K.

4. The account holder and authorised representative’s obligation to comply with the terms of use of the registry website. U.K.

The registry administrator’s obligations U.K.

5. The registry administrator’s obligation to carry out account holder’s instructions. U.K.

6. The registry administrator’s obligation to log the account holder’s details. U.K.

7. The registry administrator’s obligation to create, update or close the account in accordance with the provisions of the Regulation. U.K.

Process procedures U.K.

8. The process finalisation and confirmation provisions. U.K.

Payment U.K.

9. The terms and conditions regarding any registry fees for establishing and maintaining accounts. U.K.

Operation of the registry website U.K.

10. Provisions regarding the right of the registry administrator to make changes to the registry website. U.K.

11. Conditions of use of the registry website. U.K.

Warranties and indemnities U.K.

12. Accuracy of information. U.K.

13. Authority to initiate processes. U.K.

Modification of these core terms to reflect changes to this Regulation or changes to domestic legislation Security and response to security breaches U.K.Dispute resolution U.K.

14. Provisions relating to disputes between account holders. U.K.

Liability U.K.

15. The limit of liability for the registry administrator. U.K.

16. The limit of liability for the account holder. U.K.

Third party rights Agency, notices and governing law U.K.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ANNEX VI U.K. Definitions of identification codes

Introduction U.K.

1. This Annex prescribes the elements of the following identification codes: U.K.

(a)

unit identification code;

(b)

account identification code;

(c)

permit identification code;

(d)

account holder identification code;

(e)

installation identification code;

(f)

correlation identification code;

(g)

transaction identification code;

(h)

reconciliation identification code;

(i)

project identification code.

The version of the ISO3166 codes shall be as set out in the functional and technical specifications for data exchange standards for registry systems under the Kyoto Protocol, elaborated pursuant to Decision 24/CP.8 of the Conference of the Parties to the UNFCCC.

Display and reporting of identification codes U.K.

2. For the purpose of displaying and reporting the identification codes set out in this Annex, each element of an identification code shall be separated by a dash ‘-’ and without spaces. Leading zeros in numeric values shall not be displayed. The separating dash ‘-’ shall not be stored in the elements of the identification code. U.K.

Unit identification code U.K.

3. Table VI-1 details the elements of the unit identification code. Each Kyoto unit and allowance shall be assigned a unit identification code. Unit identification codes shall be generated by registries and shall be unique throughout the registries system. U.K.

4. A set of units shall be transmitted as a unit block defined by the starting block identifier and the ending block identifier. Every unit of a unit block shall be identical, except for their unique identifier element. Every unique identifier element of the units of a unit block shall be consecutive. When necessary to perform a transaction, keep track of, record or otherwise characterise a unit or unit block, registries or transaction logs shall create multiple unit blocks from a single unit block. When transmitting a single unit, the starting block identifier and ending block identifier shall be equal. U.K.

5. Multiple unit blocks shall not overlap with respect to their identifier element. Multiple unit blocks in the same message shall appear in the message in ascending order of their starting block identifier. U.K.

Table VI-1:

Unit Identification Code

Element	Display Order	Identifier Required for the Following Unit Types	Data Type	Length	Range or Codes
Originating Registry	1	AAU, RMU, CER, ERU	A	3	ISO3166 (2 letter code), ‘EU’ for the Community registry
Unit Type	2	AAU, RMU, CER, ERU	N	2	0 = not a Kyoto unit 1 = AAU 2 = RMU 3 = ERU converted from AAU 4 = ERU converted from RMU 5 = CER (not lCER or tCER) 6 = tCER 7 = lCER
Supplementary Unit Type	3	AAU, RMU, CER, ERU	N	2	Blank for Kyoto units 1 = Allowance issued for the 2008-2012 period and subsequent five-year periods 2 = Allowance issued for the 2005-2007 period 3 = Force-majeure allowance [F2 4 = Allowance issued for the 2008 to 2012 and subsequent five-year periods by a Member State that does not have AAUs]
Unit Serial Block Start	4	AAU, RMU, CER, ERU	N	15	Unique numeric values assigned by registry from 1 – 999 999 999 999 999
Unit Serial Block End	5	AAU, RMU, CER, ERU	N	15	Unique numeric values assigned by registry from 1 – 999 999 999 999 999
Original Commitment Period	6	AAU, RMU, CER, ERU	N	2	0 = 2005-2007 1 = 2008-2012 … 99
Applicable Commitment Period	7	AAU, CER, ERU	N	2	0 = 2005-2007 1 = 2008-2012 … 99
LULUCF Activity	8	RMU, CER, ERU	N	3	1 = Afforestation and reforestation 2 = Deforestation 3 = Forest management 4 = Cropland management 5 = Grazing land management 6 = Re-vegetation
Project Identifier	9	CER, ERU	N	7	Unique numeric value assigned for project
Track	10	ERU	N	2	1 or 2
Expiry Date	11	lCER, tCER	Date		Expiration date for lCERs or tCERs

6. Table VI-2 lists the valid initial unit type and supplementary unit type combinations. An allowance shall have a supplementary unit type regardless of the period for which it was issued and whether it has been converted from an AAU or other Kyoto unit. An AAU or other Kyoto unit that has not been converted into an allowance shall not have a supplementary unit type. On conversion of an AAU into an allowance in accordance with the provisions of this Regulation the supplementary unit type shall be set to 1. On conversion of an allowance into an AAU in accordance with the provisions of this Regulation there shall be no supplementary unit type. U.K.

Table VI-2:

Valid Initial Unit Type — Supplementary Unit Type

Initial Unit Type	Supplementary Unit Type	Description
1	[not applicable]	AAU
2	[not applicable]	RMU
3	[not applicable]	ERU converted from AAU
4	[not applicable]	ERU converted from RMU
5	[not applicable]	CER (not tCER or lCER)
6	[not applicable]	tCER
7	[not applicable]	lCER
1	1	Allowance issued for the 2008-2012 period and subsequent 5-year periods and is converted from an AAU
0	2	Allowance issued for the 2005-2007 period and not converted from an AAU or other Kyoto unit
0	3	Force-majeure allowance
[F2 0	4	Allowance issued for the 2008 to 2012 and subsequent five-year periods by a Member State that does not have AAUs, and which is not converted from an AAU or other Kyoto unit]

Account identification code U.K.

7. Table VI-3 details the elements of the account identification code. Each account shall be assigned an account identification code. Account identification codes shall be generated by registries and shall be unique throughout the registries system. Account identification codes of accounts that were previously closed shall not be re-used. U.K.

8. An operator holding account identification code shall be linked to one installation. An installation shall be linked to one operator holding account identification code. Holding accounts referred to in Article 11(1) and (2) shall not have an applicable commitment period, regardless of the account type. U.K.

Table VI-3:

Account Identification Code

Element	Display Order	Data Type	Length	Range or Codes
Originating Registry	1	A	3	ISO3166 (2 letter code), ‘CDM’ for the CDM registry, ‘EU’ for the Community registry
Account Type	2	N	3	100 = Party holding account 120 = operator holding account 121 = person holding account The remaining account types are as set out in the functional and technical specifications for data exchange standards for registry systems under the Kyoto Protocol, elaborated pursuant to Decision 24/CP.8 of the Conference of the Parties to the UNFCCC
Account Identifier	3	N	15	Unique numeric values assigned by a registry from 1 to 999 999 999 999 999 [F2 The Central Administrator shall define a separate sub-range of these values for the Community registry and each registry operated in a consolidated manner with the Community registry]
Applicable Commitment Period	4	N	2	0 for holding accounts 0-99 for retirement and cancellation accounts

Permit identification code U.K.

9. Table VI-4 details the elements of the permit identification code. Each permit shall be assigned a permit identification code. Permit identification codes shall be generated by the competent authority and shall be unique throughout the registries system. U.K.

10. A permit identification code shall be assigned to one operator. An operator shall be assigned at least one permit identification code. A permit identification code shall be assigned to at least one installation. An installation shall have one permit identification code at any single point in time. U.K.

Table VI-4:

Permit Identification Code

Element	Display Order	Data Type	Length	Range or Codes
Originating Registry	1	A	3	ISO3166 (2 letter code), ‘EU’ for the Community registry
Permit Identifier	2	A	50	([0-9] [A-Z] [‘-’]) +

Account holder identification code U.K.

11. Table VI–5 details the elements of the account holder identification code. Each account holder shall be assigned an account holder identification code. Account holder identification codes shall be generated by registries and shall be unique throughout the registries system. Account holder identification codes shall not be re-used for another account holder and shall not change for an account holder throughout their existence. U.K.

Table VI-5:

Account Holder Identification Code

Element	Display Order	Data Type	Length	Range or Codes
Originating Registry	1	A	3	ISO3166 (2 letter code), ‘EU’ for the Community registry
[F1 Account Holder Identifier]	2	A	50	([0-9] [A-Z]) +

Installation identification code U.K.

12. Table VI–6 details the elements of the installation identification code. Each installation shall be assigned an installation identification code. Installation identification codes shall be generated by registries and shall be unique throughout the registries system. The installation identifier shall be an integer assigned as an increasing monotone sequence, starting from 1. Installation identifiers shall not contain gaps. Therefore when generating installation identifier n, a registry shall have generated every identifier in the range 1 to n-1. An installation identification code shall not be re-used for another installation and shall not change for an installation throughout its existence. U.K.

13. An installation identification code shall be assigned to one installation. An installation shall be assigned one installation identification code. U.K.

Table VI-6:

Installation Identification Code

Element	Display Order	Data Type	Length	Range or Codes
Originating Registry	1	A	3	ISO3166 (2 letter code), ‘EU’ for the Community registry
Installation Identifier	2	N	15	Unique numeric values assigned by a registry from 1 to 999 999 999 999 999

Correlation identification code U.K.

[F1 14. Table VI-7 details the elements of the correlation identification codes. Each process referred to in Annex VIII and Annex XIa shall be assigned a correlation identification code. Correlation identification codes shall be generated by registries and shall be unique throughout the registries system. Correlation identification codes shall not be re-used. The re-submission of a process concerning an account or verified emissions that was previously terminated or cancelled shall be assigned a new, unique correlation identification code.] U.K.

Table VI-7:

Correlation Identification Code

Element	Display Order	Data Type	Length	Range or Codes
Originating Registry	1	A	3	ISO3166 (2 letter code), ‘EU’ for the Community registry
Correlation Identifier	2	N	15	Unique numeric values assigned by a registry from 1 to 999 999 999 999 999

Transaction identification code U.K.

15. Each process under Annex IX shall be assigned a transaction identification code. Transaction identification codes shall be generated by registries and shall be unique throughout the registries system. Transaction identification codes shall not be re-used. The re-submission of a process concerning a transaction that was previously terminated or cancelled shall be assigned a new, unique transaction identification code. U.K.

16. The elements of the transaction identification codes are set out in the functional and technical specifications for data exchange standards for registry systems under the Kyoto Protocol, elaborated pursuant to Decision 24/CP.8 of the Conference of the Parties to the UNFCCC. U.K.

Reconciliation identification code U.K.

17. Each process under Annex X shall be assigned a reconciliation identification code. Prior to the communication link between the Community independent transaction log and UNFCCC independent transaction log being established, the Community independent transaction log shall generate the reconciliation identification code when requesting reconciliation information from registries for a specified time and date. Thereafter, registries shall receive the reconciliation identification code from the UNFCCC independent transaction log. The reconciliation identification code shall be unique throughout the registries system, and all messages exchanged through all stages of a reconciliation process for a specified time and date shall use the same reconciliation identification code. U.K.

18. The elements of the reconciliation identification codes are set out in the functional and technical specifications for data exchange standards for registry systems under the Kyoto Protocol, elaborated pursuant to Decision 24/CP.8 of the Conference of the Parties to the UNFCCC. U.K.

Project identification code U.K.

19. Each project shall be assigned a project identification code. Project identification codes shall be generated by the executive board of the CDM for CERs and by the relevant body of the Party or the Article 6 supervisory committee in accordance with Decision 16/CP.7 of the Conference of the Parties to the UNFCCC for ERUs and shall be unique throughout the registries system. U.K.

20. The elements of the project identification codes are set out in the functional and technical specifications for data exchange standards for registry systems under the Kyoto Protocol, elaborated pursuant to Decision 24/CP.8 of the Conference of the Parties to the UNFCCC. U.K.

ANNEX VII U.K. List of input codes

Introduction U.K.

1. This Annex defines the codes for all elements and code support tables. The version of the ISO3166 codes shall be as set out in the functional and technical specifications for data exchange standards for registry systems under the Kyoto Protocol, elaborated pursuant to Decision 24/CP.8 of the Conference of the Parties to the UNFCCC. U.K.

EU-specific codes U.K.

2. Field Name: Activity Type U.K.

Field Description: Numeric code indicating the activity type of an installation

Code	Description
1	Combustion installations with a rated thermal input exceeding 20 MW
2	Mineral oil refineries
3	Coke ovens
4	Metal ore (including sulphide ore) roasting or sintering installations
5	Installations for the production of pig iron or steel (primary or secondary fusion) including continuous casting
6	Installations for the production of cement clinker in rotary kilns or lime in rotary kilns or in other furnaces
7	Installations for the manufacture of glass including glass fibre
8	Installations for the manufacture of ceramic products by firing, in particular roofing tiles, bricks, refractory bricks, tiles, stoneware or porcelain
9	Industrial plants for the production of (a) pulp from timber or other fibrous materials (b) paper and board
99	Other activity opted-in pursuant to Article 24 of Directive 2003/87/EC

3. Field Name: Relationship Type U.K.

Field Description: Numeric code indicating the type of relationship between an account and a person or operator

Code	Description
1	Account holder
2	Primary authorised representative of the account holder
3	Secondary authorised representative of the account holder
4	Additional authorised representative of the account holder
5	Authorised representative of the verifier
6	Contact person for the installation

4. Field Name: Process Type U.K.

Field Description: Numeric code indicating the process type of a transaction

Code	Description
01-00	Issue of AAUs and RMUs
02-00	Conversion of AAUs and RMUs to ERUs
03-00	External transfer (2008-2012 onwards)
04-00	Cancellation (2008-2012 onwards)
[ F3 ]
06-00	Cancellation and replacement of tCERs and lCERs
07-00	Carry-over of Kyoto units and allowances issued for the 2008-2012 period and subsequent five-year periods
08-00	Change of expiry date of tCERs and lCERs
10-00	Internal transfer
01-51	Allowance issue (2005-2007)
10-52	Allowance issue (2008-2012 onwards)
10-53	Allowance allocation
01-54	Force-majeure allowance issue
10-55	Correction to allowances
03-21	External transfer (2005-2007)
10-01	Allowance cancellation (2005-2007)
10-02	Allowance surrender
04-03	Retirement (2005-2007)
10-41	Cancellation and replacement
[F2 10-61	conversion of surrendered allowances for retirement(2008 to 2012 onwards)
10-62	conversion of unallocated allowances for retirement (2008 to 2012 onwards)
05-00	retirement of Kyoto units (2008 to 2012 onwards)
05-01	retirement of surrendered allowances (2008 to 2012 onwards)
05-02	retirement of unallocated allowances (2008 to 2012 onwards)
01-22	Allowance issue (registries referred to in Article 63a)
03-00	External transfer (between a registry referred to in Article 63a and other registry)
10-22	Transfer between two registries referred to in Article 63a
05-22	retirement (registries referred to in Article 63a)]

Textual Amendments

F3 Deleted by Commission Regulation (EC) No 916/2007 of 31 July 2007 amending Regulation (EC) No 2216/2004 for a standardised and secured system of registries pursuant to Directive 2003/87/EC of the European Parliament and of the Council and Decision No 280/2004/EC of the European Parliament and of the Council (Text with EEA relevance).

5. Field Name: Supplementary Unit Type U.K.

Field Description: Numeric code indicating the supplementary type of a unit

Code	Description
0	No supplementary unit type
1	Allowance issued for the 2008-2012 period and subsequent five-year periods and is converted from an AAU
2	Allowance issued for the 2005-2007 period and not converted from an AAU or other Kyoto unit
3	Force-majeure allowance
[F2 4	Allowance issued for the 2008 to 2012 and subsequent five-year periods by a Member State that does not have AAUs, and which is not converted from an AAU or other Kyoto unit]

6. Field Name: Action Code U.K.

Field Description: Numeric code indicating the action in the account update process

Code	Description
1	Add people to the account or installation
2	Update people
3	Delete people

UNFCCC codes U.K.

7. The UNFCCC codes are set out in the functional and technical specifications for data exchange standards for registry systems under the Kyoto Protocol, elaborated pursuant to Decision 24/CP.8 of the Conference of the Parties to the UNFCCC. U.K.

ANNEX VIII U.K. Processes concerning accounts and verified emissions with response codes

Requirements for each process U.K.

1.

The following message sequence for processes concerning an account or verified emissions shall apply: U.K.

(a)

the authorised representative of an account shall submit a request to the registry administrator of that registry;

(b)

the registry administrator shall assign a unique correlation identification code comprising the elements set out in Annex VI to the request;

(c)

[F1 provided that these processes are completed through the exchange of data via the UNFCCC independent transaction log and thereon to the Community independent transaction log, the registry administrator shall call the appropriate operation on the UNFCCC independent transaction log account management Web service. In all other cases the registry administrator shall call the appropriate operation on the Community independent transaction log account management Web service;]

(d)

the Community independent transaction log shall validate the request by calling the appropriate validation function within the Community independent transaction log;

(e)

if the request is successfully validated and thereby accepted, the Community independent transaction log shall amend the information it holds in accordance with that request;

(f)

the Community independent transaction log shall call the ‘receiveAccountOperationOutcome’ operation on the account management Web service of the registry which sent the request, notifying the registry as to whether the request was successfully validated and thereby accepted, or whether the request was found to contain a discrepancy and was thereby rejected;

(g)

if the request was successfully validated and thereby accepted, the registry administrator which sent the request shall amend the information held in the registry in accordance with that validated request; otherwise, if the request was found to contain a discrepancy and was thereby rejected, the registry administrator which sent the request shall not amend the information held in the registry in accordance with that rejected request.

Table VIII-1: Message Sequence Diagram for Processes concerning an Account or Verified Emissions U.K.

[F1 2. Provided that these are completed through the exchange of data via the Community independent transaction log and thereon to the UNFCCC independent transaction log, a registry administrator sending a request should receive an acknowledgement of receipt from the UNFCCC independent transaction log within 60 seconds, and should receive a notification of validation from the Community independent transaction log within 24 hours. In any other case, a registry administrator sending a request should receive an acknowledgement of receipt from the Community independent transaction log within 60 seconds, and should receive a notification of validation from the Community independent transaction log within 24 hours.] U.K.

3.

The status of the process during the message sequence shall be as follows: U.K.

Table VIII-2: Status Diagram for Processes concerning an Account or Verified Emissions U.K.

4. The components and functions which are utilised during the message sequence are shown in table VIII-3 to VIII-18. Functions which are public shall be implemented as specified. Functions which are Privatee are for informational purposes only. The inputs of all functions have been structured to match the format and informational requirements described using web services description language, set out in the functional and technical specifications for data exchange standards for registry systems under the Kyoto Protocol, elaborated pursuant to Decision 24/CP.8 of the Conference of the Parties to the UNFCCC. An asterisk ‘(*)’ has been used to denote the fact that an element can appear multiple times as an input. U.K.

Table VIII-3: Components and Functions for Processes concerning an Account or Verified Emissions U.K.

Component	Function	Scope
MgmtOfAccountWS	CreateAccount()	Public
	UpdateAccount()	Public
	CloseAccount()	Public
	UpdateVerifiedEmissions()	Public
	ReceiveAccountOperationOutcome()	Public
AccountManagement	ValidateAccountCreation()	Private
	CreateAccount()	Private
	ValidateAccountUpdate()	Private
	UpdateAccount()	Private
	ValidateAccountClosure()	Private
	CloseAccount()	Private
	ValidateVerifiedEmissionsUpdate()	Private
	UpdateVerifiedEmissions()	Private
DataValidation	AuthenticateMessage()	Private
	CheckVersion()	Private
	DataFormatChecks()	Private

Table VIII-4: MgmtOfAccountWS Component U.K.

Purpose
The purpose of this component is to handle web service requests for the management of accounts and verified emissions.
Functions exposed through Web Services
CreateAccount()	Handles the account creation requests
UpdateAccount()	Handles the account update requests
CloseAccount()	Handles account closure requests
UpdateVerifiedEmissions()	Handles verified emissions update requests
ReceiveAccountOperationOutcome()	Receives an account operation (creation, update, …) outcome (‘accepted’ or ‘rejected’)
Other functions
Not applicable.
Roles
Community independent transaction log (for all functions) and registry (for the ReceiveAccountOperationOutcome function only)

Table VIII-5: MgmtOfAccountWS.CreateAccount() function U.K.

Purpose
This function receives an account creation request. The Community independent transaction log authenticates the initiating registry (Originating Registry) by calling the AuthenticateMessage() function and checks the version of the initiating registry by calling CheckVersion() function. If authentication and version checks pass, a ‘1’ result identifier is returned without any response codes, the contents of the request are written to a file by calling the WriteToFile() function and the request is put in a queue. If authentication or version checks fail, a ‘0’ result identifier is returned together with a single response code indicating the error cause. If the person (People) is not a natural person its name must be put in the LastName parameter. The ‘PersonIdentifier’ means the account holder identification code comprising the elements set out in Annex VI. The ‘IdentifierInRegistry’ means the alphanumeric identifier for the account as specified by the account holder pursuant to Annexes III and IV.
Input parameters
From	Mandatory
To	Mandatory
CorrelationId	Mandatory
MajorVersion	Mandatory
MinorVersion	Mandatory
Account (*)	Mandatory
AccountType	Mandatory
AccountIdentifier	Mandatory
IdentifierInReg	Mandatory
CommitmentPeriod	Optional
Installation	Optional
InstallationIdentifier	Mandatory
PermitIdentifier	Mandatory
Name	Mandatory
MainActivityType	Mandatory
Country	Mandatory
PostalCode	Mandatory
City	Mandatory
Address1	Mandatory
Address2	Optional
ParentCompany	Optional
SubsidiaryCompany	Optional
EPERIdentification	Optional
Latitude	Optional
Longitude	Optional
ContactPeople (see People)	Mandatory
People (*)	Mandatory
RelationshipCode	Mandatory
PersonIdentifier	Mandatory
FirstName	Optional
LastName	Mandatory
Country	Mandatory
PostalCode	Mandatory
City	Mandatory
Address1	Mandatory
Address2	Optional
PhoneNumber1	Mandatory
PhoneNumber2	Mandatory
[F1 FaxNumber	Optional]
Email	Mandatory
Output parameters
Result Identifier	Mandatory
Response Code	Optional
Uses
AuthenticateMessage WriteToFile CheckVersion
Used By
Not applicable (called as a web service).

Table VIII-6: MgmtOfAccountWS.UpdateAccount() function U.K.

Purpose
This function receives an account update request. The Community independent transaction log authenticates the initiating registry (Originating Registry) by calling the AuthenticateMessage() function and checks the version of the initiating registry by calling CheckVersion() function. If authentication and version checks pass, a ‘1’ result identifier is returned without any response codes, the contents of the request are written to a file by calling the WriteToFile() function and the request is put in a queue. If authentication or version checks fail, a ‘0’ result identifier is returned together with a single response code indicating the error cause. If the person (People) is not a natural person its name must be put in the LastName parameter. The ‘PersonIdentifier’ means the account holder identification code comprising the elements set out in Annex VI. The ‘IdentifierInRegistry’ means the alphanumeric identifier for the account as specified by the account holder pursuant to Annexes III and IV.
Input parameters
From	Mandatory
To	Mandatory
CorrelationId	Mandatory
MajorVersion	Mandatory
MinorVersion	Mandatory
Account (*)	Mandatory
AccountIdentifier	Mandatory
IdentifierInReg	Optional
Installation	Optional
PermitIdentifier	Optional
Name	Optional
MainActivityType	Optional
Country	Optional
PostalCode	Optional
City	Optional
Address1	Optional
Address2	Optional
ParentCompany	Optional
SubsidiaryCompany	Optional
EPERIdentification	Optional
Latitude	Optional
Longitude	Optional
ContactPeople (see People)	Optional
People (*)	Optional
Action	Mandatory
RelationshipCode	Mandatory
PersonIdentifier	Mandatory
FirstName	Optional
LastName	Optional
Country	Optional
PostalCode	Optional
City	Optional
Address1	Optional
Address2	Optional
PhoneNumber1	Optional
PhoneNumber2	Optional
FaxNumber	Optional
Email	Optional
Output parameters
Result Identifier	Mandatory
Response Code	Optional
Uses
AuthenticateMessage WriteToFile CheckVersion
Used By
Not applicable (called as a web service).

Table VIII-7: MgmtOfAccountWS.CloseAccount() function U.K.

Purpose
This function receives an account closure request. The Community independent transaction log authenticates the initiating registry (Originating Registry) by calling the AuthenticateMessage() function and checks the version of the initiating registry by calling CheckVersion() function. If authentication and version checks pass, a ‘1’ result identifier is returned without any response codes, the contents of the request are written to a file by calling the WriteToFile() function and the request is put in a queue. If authentication or version checks fail, a ‘0’ result identifier is returned together with a single response code indicating the error cause.
Input parameters
From	Mandatory
To	Mandatory
CorrelationId	Mandatory
MajorVersion	Mandatory
MinorVersion	Mandatory
Account (*)	Mandatory
AccountIdentifier	Mandatory
Output parameters
Result Identifier	Mandatory
Response Code	Optional
Uses
AuthenticateMessage WriteToFile CheckVersion
Used By
Not applicable (called as a web service).

Table VIII-8: MgmtOfAccountWS.UpdateVerifiedEmissions() function U.K.

Purpose
This function receives a verified emissions update request. The Community independent transaction log authenticates the initiating registry (Originating Registry) by calling the AuthenticateMessage() function and checks the version of the initiating registry by calling CheckVersion() function. If authentication and version checks pass, a ‘1’ result identifier is returned without any response codes, the contents of the request are written to a file by calling the WriteToFile() function and the request is put in a queue. If authentication or version checks fail, a ‘0’ result identifier is returned together with a single response code indicating the error cause.
Input parameters
From	Mandatory
To	Mandatory
CorrelationId	Mandatory
MajorVersion	Mandatory
MinorVersion	Mandatory
VerifiedEmissions (*)	Mandatory
Year	Mandatory
Installations (*)	Mandatory
InstallationIdentifier	Mandatory
VerifiedEmission	Mandatory
Output parameters
Result Identifier	Mandatory
Response Code	Optional
Uses
AuthenticateMessage WriteToFile CheckVersion
Used By
Not applicable (called as a web service).

Table VIII-9: MgmtOfAccountWS.ReceiveAccountOperationOutcome() function U.K.

Purpose
This function receives an account management operation outcome. [F1 The initiating registry (Originating Registry) authenticates the UNFCCC independent transaction log (or Community independent transaction log if all processes referred to in Annex VIII are completed through the exchange of data via the Community independent transaction log) by calling the Authenticate Message() function and checks the version of the transaction log by calling Check Version() function.] If authentication and version checks pass, a ‘1’ result identifier is returned without any response codes, the contents of the request are written to a file by calling the WriteToFile() function and the request is put in a queue. If authentication or version checks fail, a ‘0’ result identifier is returned together with a single response code indicating the error cause. The response code list is populated with couples (the account or installation identifier with an adjoining response code) if the outcome is ‘0’ for any other cause of error.
Input parameters
From	Mandatory
To	Mandatory
CorrelationId	Mandatory
MajorVersion	Mandatory
MinorVersion	Mandatory
Outcome	Mandatory
Response List	Optional
Output parameters
Result Identifier	Mandatory
Response Code	Optional
Uses
AuthenticateMessage WriteToFile CheckVersion
Used By
Not applicable (called as a web service).

Table VIII-10: AccountManagement Component U.K.

Purpose
The purpose of this component is to provide the validating and update functions for the management of accounts and verified emissions.
Functions exposed through Web Services
Not applicable.
Other functions
ValidateAccountCreation()	Validates an account creation
ValidateAccountUpdate()	Validates an account update
ValidateAccountClosure()	Validates an account closure
ValidateVerifiedEmissionsUpdate()	Validates a verified emissions update
CreateAccount()	Creates accounts
UpdateAccount()	Updates accounts
CloseAccount()	Closes accounts
UpdateVerifiedEmissions()	Updates verified emissions for installations
Roles
Transaction log (all functions), registry (for information only).

Table VIII-11: ManagementOfAccount.ValidateAccountCreation() function U.K.

Purpose
This function validates an account creation request. If a validation test fails, the account identifier and response code are added to the response code list.
Input parameters
From	Mandatory
To	Mandatory
CorrelationId	Mandatory
MajorVersion	Mandatory
MinorVersion	Mandatory
Account (*)	Mandatory
AccountType	Mandatory
AccountIdentifier	Mandatory
IdentifierInReg	Mandatory
CommitmentPeriod	Optional
Installation	Optional
InstallationIdentifier	Mandatory
PermitIdentifier	Mandatory
Name	Mandatory
MainActivityType	Mandatory
Country	Mandatory
PostalCode	Mandatory
City	Mandatory
Address1	Mandatory
Address2	Optional
ParentCompany	Optional
SubsidiaryCompany	Optional
EPERIdentification	Optional
Latitude	Optional
Longitude	Optional
ContactPeople (see People)	Mandatory
People (*)	Mandatory
RelationshipCode	Mandatory
PersonIdentifier	Mandatory
FirstName	Optional
LastName	Mandatory
Country	Mandatory
PostalCode	Mandatory
City	Mandatory
Address1	Mandatory
Address2	Optional
PhoneNumber1	Mandatory
PhoneNumber2	Optional
[F1 FaxNumber	Mandatory]
Email	Optional
Output parameters
Result Identifier	Mandatory
Response List	Optional
Messages
Range 7101 to 7110; range 7122 to 7160[F1 ;] [F2 7162].

Table VIII-12: ManagementOfAccount.CreateAccount() function U.K.

Purpose
This function creates accounts. For each account: Create the account and its details. Create all persons (People) and their details if they did not already exist and link these to the account. Update all information linked to persons (People) that already existed and that are linked to the account. Create the installation and installation details if an installation is linked to the account. Create all persons (People) linked to the installation (the contact person) if they did not already exist. Update all information linked to persons (People) that already existed and that are linked to the installation.
Input parameters
From	Mandatory
To	Mandatory
CorrelationId	Mandatory
MajorVersion	Mandatory
MinorVersion	Mandatory
Account (*)	Mandatory
AccountType	Mandatory
AccountIdentifier	Mandatory
IdentifierInReg	Mandatory
CommitmentPeriod	Optional
Installation	Optional
InstallationIdentifier	Mandatory
PermitIdentifier	Mandatory
[F2 PermitDate	Mandatory]
Name	Mandatory
MainActivityType	Mandatory
Country	Mandatory
PostalCode	Mandatory
City	Mandatory
Address1	Mandatory
Address2	Optional
ParentCompany	Optional
SubsidiaryCompany	Optional
EPERIdentification	Optional
Latitude	Optional
Longitude	Optional
ContactPeople (see People)	Mandatory
People (*)	Mandatory
RelationshipCode	Mandatory
PersonIdentifier	Mandatory
FirstName	Optional
LastName	Mandatory
Country	Mandatory
PostalCode	Mandatory
City	Mandatory
Address1	Mandatory
Address2	Optional
PhoneNumber1	Mandatory
PhoneNumber2	Optional
[F1 FaxNumber	Optional]
Email	Optional
Output parameters
Result Identifier	Mandatory
Uses
Not applicable.
Used By
Not applicable (called as a web service).

Table VIII-13: AccountManagement.ValidateAccountUpdate() function U.K.

Purpose
This function validates an account update request. If a validation test fails, the account identifier and response code are added to the response code list.
Input parameters
From	Mandatory
To	Mandatory
CorrelationId	Mandatory
MajorVersion	Mandatory
MinorVersion	Mandatory
Account (*)	Mandatory
AccountIdentifier	Mandatory
IdentifierInReg	Optional
Installation	Optional
PermitIdentifier	Optional
[F2 PermitDate	Optional]
Name	Optional
MainActivityType	Optional
Country	Optional
PostalCode	Optional
City	Optional
Address1	Optional
Address2	Optional
ParentCompany	Optional
SubsidiaryCompany	Optional
EPERIdentification	Optional
Latitude	Optional
Longitude	Optional
ContactPeople (see People)	Optional
People (*)	Optional
Action	Mandatory
RelationshipCode	Mandatory
PersonIdentifier	Mandatory
FirstName	Optional
LastName	Optional
Country	Optional
PostalCode	Optional
City	Optional
Address1	Optional
Address2	Optional
PhoneNumber1	Optional
PhoneNumber2	Optional
FaxNumber	Optional
Email	Optional
Output parameters
Result Identifier	Mandatory
Response List	Optional
Messages
Range 7102 to 7107; range 7111 to 7113; 7120; 7122; 7124; range 7126 to 7158.

Table VIII-14: ManagementOfAccount.UpdateAccount() function U.K.

Purpose
This function updates the details of an account. If action = ‘Add’: For each link to be added: If the person (People) existed, update its details if required. If the person (People) did not exist, create the person (People) and link it to the account. If action = ‘Update’: For all persons (People) to update and that are linked to the account, update their details. If action = ‘Delete’: Remove the link between the person (People) and the account (for example, an additional authorised representative is removed). If an installation is linked to the account, update the installation details if required. Update the details of the persons (People) linked to the installation if details have been submitted (by using the same ‘Add’, ‘Update’ and ‘Delete’ actions).
Input parameters
From	Mandatory
To	Mandatory
CorrelationId	Mandatory
MajorVersion	Mandatory
MinorVersion	Mandatory
Account (*)	Mandatory
AccountType	Mandatory
AccountIdentifier	Mandatory
IdentifierInReg	Mandatory
Installation	Optional
InstallationIdentifier	Mandatory
PermitIdentifier	Mandatory
[F2 PermitDate	Mandatory]
Name	Mandatory
MainActivityType	Mandatory
Country	Mandatory
PostalCode	Mandatory
City	Mandatory
Address1	Mandatory
Address2	Optional
ParentCompany	Optional
SubsidiaryCompany	Optional
EPERIdentification	Optional
Latitude	Optional
Longitude	Optional
ContactPeople (see People)	Mandatory
People (*)	Mandatory
RelationshipCode	Mandatory
PersonIdentifier	Mandatory
FirstName	Optional
LastName	Mandatory
Country	Mandatory
PostalCode	Mandatory
City	Mandatory
Address1	Mandatory
Address2	Optional
PhoneNumber1	Optional
PhoneNumber2	Optional
FaxNumber	Optional
Email	Optional
Output parameters
Result Identifier	Mandatory
Uses
Not applicable.
Used By
Not applicable (called as a web service).

Table VIII-15: ManagementOfAccount.ValidateAccountClosure() function U.K.

Purpose
This function validates an account closure operation. If a validation test fails, the account identifier and response code are added to the response code list.
Input parameters
From	Mandatory
To	Mandatory
CorrelationId	Mandatory
MajorVersion	Mandatory
MinorVersion	Mandatory
Account (*)	Mandatory
Purpose
AccountIdentifier	Mandatory
Output parameters
Result Identifier	Mandatory
Response List	Optional
Messages
7111; range 7114 to 7115; 7117; range 7153 to 7156; 7158[F1 ;] [F2 7161 .]

Table VIII-16: ManagementOfAccount.CloseAccount() function U.K.

Purpose
This function closes an account or accounts by setting the end validity date of the account(s) to be closed to the current date.
Input parameters
Registry	Mandatory
CorrelationId	Mandatory
MajorVersion	Mandatory
MinorVersion	Mandatory
Account (*)	Mandatory
AccountIdentifier	Mandatory
Output parameters
Result Identifier	Mandatory

Table VIII-17: ManagementOfAccount.ValidateVerifiedEmissionsUpdate() function U.K.

Purpose
This function validates a verified emissions update. If a validation test fails, the installation identifier and response code are added to the response code list.
Input parameters
From	Mandatory
To	Mandatory
CorrelationId	Mandatory
MajorVersion	Mandatory
MinorVersion	Mandatory
VerifiedEmissions (*)	Mandatory
Year	Mandatory
Installations (*)	Mandatory
InstallationIdentifier	Mandatory
VerifiedEmission	Mandatory
Output parameters
Result Identifier	Mandatory
Response List	Optional
Messages
Range 7118 to 7119; range 7152 to 7156; 7159[F1 ;] [F2 7525 .]

Table VIII-18: ManagementOfAccount.UpdateVerifiedEmissions function U.K.

Purpose
Updates the verified emissions for the year and installation specified.
Input parameters
From	Mandatory
To	Mandatory
CorrelationId	Mandatory
MajorVersion	Mandatory
VerifiedEmissions (*)	Mandatory
Year	Mandatory
Installations (*)	Mandatory
InstallationIdentifier	Mandatory
VerifiedEmission	Mandatory
Output parameters
Result Identifier	Mandatory

Preliminary checks for each process U.K.

5. The Community independent transaction log shall check the status of a registry for each process concerning an account or verified emissions. If the communication link between the registry and the Community independent transaction log has not been established or is temporarily suspended pursuant to Article 6(3) in respect of the requested process concerning an account or verified emissions, it shall be rejected and the response code 7005 shall be returned. U.K.

[F1 6. The Community independent transaction log shall perform registry version and registry authentication checks, and message viability checks, on each process concerning an account or verified emissions and return the appropriate response codes if a discrepancy is detected, as set out in Table XII-1 under the range 7900 to 7999. The abovementioned checks are equivalent to the checks related to the response codes that are set out in the functional and technical specifications for data exchange standards for registry systems under the Kyoto Protocol, elaborated pursuant to Decision 24/CP.8 of the Conference of the Parties to the UNFCCC and are reproduced in the last column of Table XII-1 alongside the equivalent response codes under the range 7900 to 7999. If a check under the above mentioned data exchange standards that is equivalent to the checks whose response codes are set out in Table XII-1 under the range 7900 to 7999 or the implementation by the UNFCCC independent transaction log of such a check is changed by the ITL Administrator, the Central Administrator shall disable the equivalent check.] U.K.

7. The Community independent transaction log shall perform data integrity checks on each process concerning an account or verified emissions and return response codes in the range 7122 to 7159 if a discrepancy is detected. U.K.

Secondary checks for each process U.K.

8. The Community independent transaction log shall perform secondary checks on each process concerning an account or verified emissions which has passed all of the preliminary checks. The secondary checks, and the adjoining response codes which are returned when a discrepancy is detected, are set out in table VIII-19. U.K.

Table VIII-19: Secondary Checks U.K.

Process description	Community independent transaction log response codes
Account creation	Range 7101 to 7110 7160
Account update	Range 7102 to 7105 Range 7107 to 7108 7111 7113 7120 7160
Account closure	7111 Range 7114 to 7115 7117
Verified emissions update	Range 7118 to 7119

ANNEX IX U.K. Processes concerning transactions with response codes

Process types U.K.

1. Each process concerning a transaction shall be assigned a process type consisting of an initial process type and a supplementary process type. The initial process type shall describe its category as set out in the functional and technical specifications for data exchange standards for registry systems under the Kyoto Protocol, elaborated pursuant to Decision 24/CP.8 of the Conference of the Parties to the UNFCCC. The supplementary process type shall describe its category as set out in the provisions of this Regulation, elaborated pursuant to Directive 2003/87/EC. The process types are set out in table IX-1. U.K.

Requirements for each process U.K.

2. The message sequence for processes concerning a transaction, the status of the transaction and the status of the Kyoto units or allowances involved in the transaction during the message sequence, and the components and functions which are utilised during the message sequence, are set out in the functional and technical specifications for data exchange standards for registry systems under the Kyoto Protocol, elaborated pursuant to Decision 24/CP.8 of the Conference of the Parties to the UNFCCC. U.K.

Preliminary checks for each process U.K.

3. The Community independent transaction log shall check the status of a registry for each process concerning a transaction. If the communication link between the registry and the Community independent transaction log has not been established or is temporarily suspended pursuant to Article 6(3) in respect of the requested process, it shall be rejected and the response codes 7005 or 7006 shall be returned. U.K.

[F1 4. The Community independent transaction log shall perform the following categories of preliminary checks on each process concerning a transaction: U.K.

(a)

registry version and registry authentication checks;

(b)

message viability checks;

(c)

data integrity checks;

(d)

general transaction checks; and

(e)

message sequence checks.

The Community independent transaction log shall return the appropriate response codes if a discrepancy is detected, as set out in Table XII-1 under the range 7900 to 7999. The above-mentioned checks are equivalent to the checks related to the response codes that are set out in the functional and technical specifications for data exchange standards for registry systems under the Kyoto Protocol, elaborated pursuant to Decision 24/CP.8 of the Conference of the Parties to the UNFCCC and are reproduced in the last column of Table XII-1 alongside the equivalent response codes under the range 7900 to 7999. If a check under the above mentioned data exchange standards is equivalent to the checks whose response codes are set out in Table XII-1 under the range 7900 to 7999 and the implementation by the UNFCCC independent transaction log of such a check is changed by the ITL Administrator, the Central Administrator shall disable the equivalent check.]

Secondary and tertiary checks for each process U.K.

5. For each process concerning a transaction which has passed all of the preliminary checks, the Community independent transaction log shall perform the following secondary checks to ascertain whether: U.K.

(a)

the Kyoto units or allowances are held in the transferring account (a discrepancy returns response code 7027);

(b)

the transferring account exists in the specified registry (a discrepancy returns response code 7021);

(c)

the acquiring account exists in the specified registry (a discrepancy returns response code 7020);

(d)

both accounts exist in the same registry for an internal transfer (a discrepancy returns response code 7022);

(e)

both accounts exist in different registries for an external transfer (a discrepancy returns response code 7023);

(f)

the transferring account is not blocked pursuant to Article 27 (a discrepancy returns response code 7025);

(g)

force majeure allowances are not being transferred (a discrepancy returns response code 7024).

6. The Community independent transaction log shall perform tertiary checks on each process concerning a transaction which has passed all of the preliminary checks. The tertiary checks, and the adjoining response codes which are returned when a discrepancy is found, are set out in table IX-1. U.K.

Table IX-1:

Tertiary Checks

Process description	Process type	Community independent transaction log response codes
Issue of AAUs and RMUs	01-00	[not applicable]
Conversion of AAUs and RMUs to ERUs	02-00	7218
External transfer (2008-2012 onwards)	03-00	Range 7301 to 7302 7304 [F2 Range 7221 to 7222]
Cancellation (2008-2012 onwards)	04-00	[not applicable]
[ F3 ]
Cancellation and replacement of tCERs and lCERs	06-00	[not applicable]
Carry-over of Kyoto units and allowances issued for the 2008-2012 period and subsequent five-year periods	07-00	[not applicable]
Change of expiry date of tCERs and lCERs	08-00	[not applicable]
Internal transfer	10-00	7304 Range 7406 to 7407
Allowance issue (2005-2007)	01-51	Range 7201 to 7203 7219
Allowance issue (2008-2012 onwards)	10-52	Range 7201 to 7203 7205 7219
Allowance allocation	10-53	7202 7203 Range 7206 to 7208 7214 7216 7304 7360
Force-majeure allowance issue	01-54	7202 Range 7210 to 7211 7215 7217 7220
Correction to allowances	10-55	Range 7212 to 7213
External transfer (2005-2007)	03-21	7302 Range 7304 to 7305 Range 7406 to 7407 [F2 Range 7221  to 7222]
Allowance cancellation (2005-2007)	10-01	7212 7305
Allowance surrender	10-02	7202 7304 Range 7353 to 7356
Retirement (2005-2007)	04-03	7209 7305 7357 Range 7360 to 7362
Cancellation and replacement	10-41	(2005 to 2007) 7205 7212 7219 7360 7402 7404 Range 7406 to 7407 (2008-2012 onwards) 7202 7205 7219 7360 Range 7401 to 7402 Range 7404 to 7407 [F2 (registries referred to in Article 63a) 7219 Range 7223 to 7224 7360 7402 7404 7406 Range 7407 to 7408 7202]
[F2 Conversion of surrendered allowances for retirement (2008 to 2012 onwards)	10-61	7358
Conversion of unallocated allowances for retirement (2008 to 2012 onwards)	10-62	7364 , 7366
Retirement of Kyoto units (2008 to 2012 onwards)	05-00	7360 7365
Retirement of surrendered allowances (2008 to 2012 onwards)	05-01	Range 7359 to 7361 7365
Retirement of unallocated allowances (2008 to 2012 onwards)	05-02	7360 , 7361 Range 7363 to 7365
External transfer (between a registry referred to in Article 63a and other registry)	03-00	Range 7225 to 7226
Allowance issue (registries referred to in Article 63a)	01-22	Range 7201 to 7203 7219 7224
Retirement (registries referred to in Article 63a)	05-22	Range 7227 to 7228 7357 Range 7360 to 7362
Transfer between two registries referred to in Article 63a	10-22	7302 , 7304 Range 7406 to 7407 7224 7228]

[F2 7. An external transfer between a registry referred to in Article 63a and other registry shall be carried out in the following steps: U.K.

(a)

upon the account holder's request to transfer allowances with a supplementary unit type 4 from an account in a registry referred to in Article 63a, the transferring registry:

(i)

checks if the balance of the Party holding account in the registry referred to in Article 63a which is only capable of holding allowances with a supplementary unit type 1, 2 or 3 is at least equal to the quantity to be transferred;

(ii)

redirects the allowances to the Party holding account in the registry referred to in Article 63a which is only capable of holding allowances with a supplementary unit type 4;

(iii)

transfers an equivalent amount of supplementary unit type 1, 2 or 3 allowances from the Party holding account that is only capable of holding allowances with a supplementary unit type of 1, 2 or 3 to the account of the account holder initiating the transaction;

(iv)

transfers these supplementary unit type 1, 2 or 3 allowances from account of the account holder initiating the transaction to the destination account;

(b)

upon the account holder's request to transfer allowances with a supplementary unit type of 1, 2 or 3 to an account in a registry referred to in Article 63a, the acquiring registry:

(i)

transfers the allowances with a supplementary unit type of 1, 2 or 3 to the destination account;

(ii)

transfers these allowances from the destination account to the Party holding account in the registry operated in accordance with Article 63a which is only capable of holding allowances with a supplementary unit type 1, 2 or 3;

(iii)

transfers an equivalent amount of supplementary unit type 4 allowances from the Party holding account that is only capable of holding allowances with an initial unit type of 0 and a supplementary unit type of 4 to the destination account. If the balance on the Party holding account capable of holding supplementary unit type 4 allowances is less than the quantity that needs to be transferred, the missing number of supplementary unit type 4 allowances are created on the Party holding account before the transfer.]

ANNEX X U.K. Reconciliation process with response codes

Requirements for the process U.K.

1. [F1 When the communication link between the Community independent transaction log and the UNFCCC independent transaction log is not established, each registry shall respond to any request made by the Community independent transaction log to submit the following information for a specified time and date:] U.K.

(a)

the total number of allowances held in each account type in that registry;

(b)

the unit identification codes of any allowance held in each account type in that registry;

(c)

the transaction log and audit log history of any allowance held in each account type in that registry;

(d)

the total number of allowances held in each account in that registry;

(e)

the unit identification codes of any allowance held in each account in that registry; and

(f)

the transaction log and audit log history of each allowance held in any account in that registry.

2. [F1 When the communication link between the Community independent transaction log and the UNFCCC independent transaction log is established, each registry shall respond to any request made by the UNFCCC independent transaction log to submit the following information for a specified time and date:] U.K.

(a)

the total number of allowances, AAUs, RMUs, ERUs, CERs (not tCERs or lCERs), lCERs and tCERs, held in each account type in that registry;

(b)

the unit identification codes of any allowance, AAU, RMU, ERU, CER (not tCER or lCER), lCER and tCER, held in each account type in that registry; and

(c)

the transaction log and audit log history of any allowance, AAU, RMU, ERU, CER (not tCER or lCER), lCER and tCER held in each account type in that registry.

3. [F1 When the communication link between the Community independent transaction log and the UNFCCC independent transaction log is established, each registry shall respond to any request by the UNFCCC independent transaction log made on behalf of the Community independent transaction log, or by the Community independent transaction log to submit the following information for a specified time and date:] U.K.

(a)

the total number of allowances, AAUs, RMUs, ERUs, CERs (not tCERs or lCERs), lCERs and tCERs held in each account in that registry;

(b)

the unit identification codes of any allowance, AAU, RMU, ERU, CER (not tCER or lCER), lCER and tCER held in each account in that registry; and

(c)

the transaction log and audit log history of any allowance, AAU, RMU, ERU, CER (not tCER or lCER), lCER and tCER held in each account in that registry.

4. The message sequence for the reconciliation process, the status of the reconciliation process and the status of the Kyoto units or allowances involved in the reconciliation process during the message sequence, and the components and functions which are utilised during the message sequence, are set out in the functional and technical specifications for data exchange standards for registry systems under the Kyoto Protocol, elaborated pursuant to Decision 24/CP.8 of the Conference of the Parties to the UNFCCC. U.K.

Preliminary checks for the process U.K.

5. The Community independent transaction log shall check the status of a registry during the reconciliation process. If the communication link between the registry and the Community independent transaction log has not been established or is temporarily suspended pursuant to Article 6(3) in respect of the reconciliation process, the process shall be rejected and the response code 7005 shall be returned. U.K.

[F1 6. The Community independent transaction log shall perform registry version and registry authentication checks, message viability checks, and data integrity checks during the reconciliation process and return the appropriate response codes if a discrepancy is detected, as set out in Table XII-1 under the range 7900 to 7999. The above-mentioned checks are equivalent to the checks related to the response codes that are set out in the functional and technical specifications for data exchange standards for registry systems under the Kyoto Protocol, elaborated pursuant to Decision 24/CP.8 of the Conference of the Parties to the UNFCCC and are reproduced in the last column of Table XII-1 alongside the equivalent response codes under the range 7900 to 7999. If a check under the above mentioned data exchange standards that is equivalent to the checks whose response codes are set out in Table XII-1 under the range 7900 to 7999 or the implementation by the UNFCCC independent transaction log of such a check is changed by the ITL Administrator, the Central Administrator shall disable the equivalent check.] U.K.

Secondary checks for the process U.K.

7. The Community independent transaction log shall perform secondary checks during the reconciliation process, once the preliminary checks have been passed. The secondary checks, and the adjoining response codes which are returned when an inconsistency is detected, are set out in table X-1. U.K.

Table X-1:

Secondary Checks

Process description	Community independent transaction log response codes
Reconciliation	Range: 7501 to 7524

Manual intervention U.K.

8. If the information held in a registry has been amended in response to a process initiated but not finalised pursuant to Articles 34, 35 or 36, the Central Administrator shall instruct the registry administrator of that registry to reverse that process by amending the information held back to its original state. U.K.

If the information held in a registry has not been amended in response to a process initiated and finalised pursuant to Articles 34, 35 or 36, the Central Administrator shall instruct the registry administrator of that registry to finalise that process by amending the information held accordingly.

9. Where the reconciliation process has identified an inconsistency, the Central Administrator shall coordinate with the registry administrator or administrators concerned in order to determine the origin of the inconsistency. The Central Administrator shall then, as necessary, either amend the information held in the Community independent transaction log or request the registry administrator or administrators concerned to make specific manual adjustments to the information held in their registry. U.K.

ANNEX XI U.K. Administrative processes with response codes

Administrative processes U.K.

1. The Community independent transaction log shall provide the following administrative processes: U.K.

(a)

Transaction clean-up

:

all processes under Annex IX which have been initiated but not yet terminated, completed or cancelled within 24 hours shall be cancelled. Transaction clean-up occurs on an hourly basis.

(b)

Outstanding units

:

all allowances which have not been cancelled pursuant to Articles 60 or 61 on or after 1 May 2008 and on or after 1 May in the first year of each subsequent five-year period shall be identified.

(c)

Process status

:

a registry administrator may query the status of a process under Annex IX which has been initiated by that registry administrator.

(d)

Time synchronisation

:

upon request, each registry administrator shall provide the system time of its registry in order that the consistency between the system time of a registry and the system time of the Community independent transaction log can be checked, and that the two times can be synchronised. Upon request, a registry administrator shall change the system time of its registry in order to ensure time synchronisation.

[F1 2. When the communication link between the Community independent transaction log and the UNFCCC independent transaction log is established and all processes concerning allowances, verified emissions, accounts, automatic national allocation plan table changes and Kyoto units shall be completed through the exchange of data via the UNFCCC independent transaction log and thereon to the Community independent transaction log, the Community independent transaction log shall only continue to provide the administrative process under point (b) of paragraph 1.] U.K.

2. After the communication link between the Community independent transaction log and the UNFCCC independent transaction log has been established, the Community independent transaction log shall only continue to provide the administrative process under paragraph 1(b). U.K.

3. Each registry shall be capable of executing correctly the additional administrative processes provided by the UNFCCC independent transaction log, set out in the functional and technical specifications for data exchange standards for registry systems under the Kyoto Protocol, elaborated pursuant to Decision 24/CP.8 of the Conference of the Parties to the UNFCCC. U.K.

Requirements for each process U.K.

4. The message sequence for administrative processes and the components and functions which are utilised during the message sequence are set out in the functional and technical specifications for data exchange standards for registry systems under the Kyoto Protocol, elaborated pursuant to Decision 24/CP.8 of the Conference of the Parties to the UNFCCC. U.K.

Checks for each process U.K.

5. If, during the period referred to in paragraph 2, the Community independent transaction log detects a discrepancy under paragraph 1(a) it shall return the appropriate response codes as set out in the functional and technical specifications for data exchange standards for registry systems under the Kyoto Protocol, elaborated pursuant to Decision 24/CP.8 of the Conference of the Parties to the UNFCCC. U.K.

6. If the Community independent transaction log detects a discrepancy under paragraph 1(b) it shall return the response code 7601. U.K.

7. During the period referred to in paragraph 2 and where a message is received from a registry under paragraph 1(c) for a process referred to in Annex IX the Community independent transaction log shall perform the following checks: U.K.

(a)

Status of a registry: if the communication link between the registry and the Community independent transaction log has not been established or is temporarily suspended pursuant to Article 6(3) in respect of the requested process, the message shall be rejected and the response code 7005 shall be returned.

(b)

Registry version and registry authentication, message viability, and data integrity: if the Community independent transaction log detects a discrepancy, the message shall be rejected and the appropriate response codes shall be returned as set out in the functional and technical specifications for data exchange standards for registry systems under the Kyoto Protocol, elaborated pursuant to Decision 24/CP.8 of the Conference of the Parties to the UNFCCC.

8. During the period referred to in paragraph 2 and where a message is received from a registry under paragraph 1(d) the Community independent transaction log shall perform the following checks: U.K.

(a)

Status of a registry: if the communication link between the registry and the Community independent transaction log has not been established or is temporarily suspended pursuant to Article 6(3) in respect of the requested process, the message shall be rejected and the response code 7005 shall be returned.

(b)

Registry version and registry authentication, message viability, data integrity and time synchronisation: if the Community independent transaction log detects a discrepancy, the message shall be rejected and the appropriate response codes shall be returned as set out in the functional and technical specifications for data exchange standards for registry systems under the Kyoto Protocol, elaborated pursuant to Decision 24/CP.8 of the Conference of the Parties to the UNFCCC.

[F2 ANNEX XIa U.K. Processes concerning automatic national allocation plan table changes

1. In accordance with Articles 17(3) and 44(2), registries may propose to the Community independent transaction log to check and implement an automatic change to the national allocation plan through a process described in this Annex. U.K.

Requirements for each process U.K.

2. In accordance with Articles 17(3) and 44(2), registries may propose to the Community independent transaction log to check and implement an automatic change to the national allocation plan through a process described in this Annex: U.K.

(a)

the registry administrator shall initiate the automatic national allocation plan table change process by assigning a unique correlation identification code comprising the elements set out in Annex VI to its request;

(b)

the registry administrator shall call the appropriate operation on the Community independent transaction log automatic national allocation plan table change Web service;

(c)

the Community Independent Transaction Log shall validate the request by calling the appropriate validation function within the Community Independent Transaction Log;

(d)

if the request is successfully validated and thereby accepted, the Community Independent Transaction Log shall amend the information it holds in accordance with that request;

(e)

the Community Independent Transaction Log shall call the ‘ receiveNapManagementOutcome ’ operation on the automatic national allocation plan table change Web service of the registry which sent the request, notifying the registry as to whether the request was successfully validated and thereby accepted, or whether the request was found to contain a discrepancy and was thereby rejected;

(f)

if the request was successfully validated and thereby accepted, the registry administrator which sent the request shall amend the information held in the registry in accordance with that validated request; otherwise, if the request was found to contain a discrepancy and was thereby rejected, the registry administrator which sent the request shall not amend the information held in the registry in accordance with that rejected request.

3. Provided that automatic national allocation plan table change processes are directed through the UNFCCC independent transaction log, a registry administrator sending a request should receive an acknowledgement of receipt from the UNFCCC independent transaction log within 60 seconds, and should receive a notification of validation from the Community independent transaction log within 24 hours. In all other cases, a registry administrator sending a request should receive an acknowledgement of receipt from the Community independent transaction log within 60 seconds, and should receive a notification of validation from the Community independent transaction log within 24 hours; U.K.

4. The components and functions which are utilised during the message sequence are shown in table XIa-1 to XIa-6. The inputs of all functions have been structured to match the format and informational requirements described using web services description language, set out in the functional and technical specifications for data exchange standards for registry systems under the Kyoto Protocol, elaborated pursuant to Decision 24/CP.8 of the Conference of the Parties to the UNFCCC. An asterisk ‘ (*) ’ has been used to denote the fact that an element can appear multiple times as an input. U.K.

Table XIa-1:

Components and Functions for Processes concerning automatic national allocation plan table changes

Component	Function	Scope
NAPTableManagementWS	AddNEInstallationtoNAP()	Public
	IncreaseNAPallocationtoNEInstallation()	Public
	RemoveNAPallocationofclosingInstallation()	Public

Table XIa-2:

NAPTableManagementWS Component

Purpose
The purpose of this component is to handle web service requests for the management of automatic changes to the national allocation plan table
Functions exposed through Web Services
AddNEInstallationtoNAP()	Handles the requests for adding new entrant new installations to the national allocation plan table
IncreaseAllocationtoNEInstallationinNAP()	Handles the requests for increasing the allocation in the national allocation plan table of existing installations that are new entrants
RemoveNAPallocationofclosingInstallation()	Handles the requests for removing the allocation from the national allocation plan table of installations that are closing
Other functions
Not applicable.
Roles
Community independent transaction log (for all functions) and registry (for the receiveNapManagementOutcome function only)

Table XIa-3:

NAPTableManagementWS.AddNEInstallationtoNAP() function

Purpose
This function receives a request for adding a new entrant new installation to the national allocation plan table. The allowances allocated for the years before the current year will have a value of zero. If the new entrant new installation does not receive an allocation, the amount of allowances will have a value of zero. If the new entrant new installation does receive an allocation, the reserve is reduced by an equivalent quantity. The Community independent transaction log authenticates the initiating registry (Originating Registry) by calling the AuthenticateMessage() function and checks the version of the initiating registry by calling CheckVersion() function. If authentication and version checks pass, a ‘ 1 ’ result identifier is returned without any response codes, the contents of the request are written to a file by calling the WriteToFile() function and the request is put in a queue. If authentication or version checks fail, a ‘ 0 ’ result identifier is returned together with a single response code indicating the error cause. The ‘ PermitIdentifier ’ means the permit identification code comprising the elements set out in Annex VI.
Input parameters
From	Mandatory
To	Mandatory
CorrelationId	Mandatory
MajorVersion	Mandatory
MinorVersion	Mandatory
InitiatingRegistry	Mandatory
CommitmentPeriod	Mandatory
NewValueofReserve	Mandatory
Installation (*)	Mandatory
PermitIdentifier	Mandatory
InstallationIdentifier	Mandatory
Allocation (*)	Mandatory
YearinCommitmentPeriod	Mandatory
AmountofAllowances	Mandatory
Output parameters
Result Identifier	Mandatory
Response Code	Optional
Uses
AuthenticateMessage WriteToFile CheckVersion
Used By
Not applicable (called as a web service).

Table XIa-4:

NAPTableManagementWS.IncreaseAllocationtoNEInstallationinNAPIncreaseallocationtoNEInstallationinNAP() function

Purpose
This function receives a request for increasing the allocation of installations already existing in the national allocation plan table that are considered new entrants. The allowances allocated for the years before the current year won’t be modified. The reserve is reduced by a quantity that is equivalent to the quantity allocated in this process. The Community independent transaction log authenticates the initiating registry (Originating Registry) by calling the AuthenticateMessage() function and checks the version of the initiating registry by calling CheckVersion() function. If authentication and version checks pass, a ‘ 1 ’ result identifier is returned without any response codes, the contents of the request are written to a file by calling the WriteToFile() function and the request is put in a queue. If authentication or version checks fail, a ‘ 0 ’ result identifier is returned together with a single response code indicating the error cause.
Input parameters
From	Mandatory
To	Mandatory
CorrelationId	Mandatory
MajorVersion	Mandatory
MinorVersion	Mandatory
InitiatingRegistry	Mandatory
CommitmentPeriod	Mandatory
NewValueofReserve	Mandatory
Installation (*)	Mandatory
InstallationIdentifier	Mandatory
Allocation (*)	Mandatory
Yearincommitmentperiod	Mandatory
AmountofAllowances	Mandatory
Output parameters
ResultIdentifier	Mandatory
ResponseCode	Optional
Uses
AuthenticateMessage WriteToFile CheckVersion
Used By
Not applicable (called as a web service).

Table XIa-5:

NAPTableManagementWS RemoveNAPallocationofclosingInstallation() function

Purpose
This function receives a request for removing installations existing in the national allocation plan table. The allowances yet unallocated will be deleted and an equivalent quantity of allowances will be added to the reserve. The Community independent transaction log authenticates the initiating registry (Originating Registry) by calling the AuthenticateMessage() function and checks the version of the initiating registry by calling CheckVersion() function. If authentication and version checks pass, a ‘ 1 ’ result identifier is returned without any response codes, the contents of the request are written to a file by calling the WriteToFile() function and the request is put in a queue. If authentication or version checks fail, a ‘ 0 ’ result identifier is returned together with a single response code indicating the error cause.
Input parameters
From	Mandatory
To	Mandatory
CorrelationId	Mandatory
MajorVersion	Mandatory
MinorVersion	Mandatory
InitiatingRegistry	Mandatory
CommitmentPeriod	Mandatory
NewValueofReserve	Mandatory
Installation (*)	Mandatory
InstallationIdentifier	Mandatory
Output parameters
Result Identifier	Mandatory
Response Code	Optional
Uses
AuthenticateMessage WriteToFile CheckVersion
Used By
Not applicable (called as a web service).

Table XIa-6:

NAPTableManagementWS receiveNapManagementOutcome () function

Purpose
This function receives a NAP management operation outcome. The initiating registry (Originating Registry) authenticates the UNFCCC independent transaction log (or Community independent transaction log if all processes referred to in Annex VIII are directed through Community independent transaction log and thereon to the UNFCCC independent transaction log) by calling the AuthenticateMessage() function and checks the version of the transaction log by calling CheckVersion() function. If authentication and version checks pass, a ‘ 1 ’ result identifier is returned without any response codes, the contents of the request are written to a file by calling the WriteToFile() function and the request is put in a queue. If authentication or version checks fail, a ‘ 0 ’ result identifier is returned together with a single response code indicating the error cause. The response code list is populated with couples (a response code with possibly a list of installation identifiers) if the outcome is ‘ 0 ’ for any other cause of error.
Input parameters
From	Mandatory
To	Mandatory
CorrelationId	Mandatory
MajorVersion	Mandatory
MinorVersion	Mandatory
Outcome	Mandatory
Response List	Optional
Output parameters
Result Identifier	Mandatory
Response Code	Optional
Uses
AuthenticateMessage WriteToFile CheckVersion
Used By
Not applicable (called as a web service).

Table XIa-7:

Processes concerning NAP Table changes

Process description	Community independent transaction log response codes
NAPTableManagementWS.AddNEInstallationtoNAP	7005, 7122, 7125, 7153, 7154, 7155, 7156, 7159, 7215, 7451, 7452, 7700, 7701, 7702, 7703, 7704
NAPTableManagementWS.IncreaseallocationtoNEInstallationinNAP	7005, 7153, 7154, 7155, 7156, 7159, 7207, 7451, 7452, 7700, 7701, 7702, 7703, 7705
NAPTableManagementWS RemoveNA PallocationofclosingInstallation	7005, 7153, 7154, 7155, 7156, 7159, 7207, 7451, 7700, 7706

5. If all the checks have been passed successfully, the Community independent transaction log automatically implements the national allocation plan table change into its database and informs the registry administrator and the Central Administrator thereof.] U.K.

ANNEX XII U.K. List of response codes for all processes

[F1 1. The Community independent transaction log shall return response codes as part of each process, where specified in Annexes VIII to XIa. Each response code shall consist of an integer within the range 7000 to 7999. The meaning of each response code is given in table XII-1.] U.K.

2. Each registry administrator shall ensure that the meaning of each response code is maintained when displaying information in respect of a process under Annex XVI to the authorised representative who initiated that process. U.K.

Table XII-1:

Community Independent Transaction Log Response Codes

[ F3 ]
[F2 Response Code	Description	Equivalent response code under the data exchange standards]
7005	The current status of the initiating (or transferring) registry does not permit this process to take place.
7006	The current status of the acquiring registry does not permit this process to take place
7020	The specified account identification code does not exist in the acquiring registry.
7021	The specified account identification code does not exist in the transferring registry.
7022	The transferring account and acquiring account must be in the same registry for all transactions except external transfers.
7023	The transferring account and acquiring account must be in different registries for external transfers.
7024	Force majeure allowances cannot be transferred out of the Party holding account unless being cancelled and retired in accordance with Article 58.
7025	The transferring account is blocked for all transfers of allowances out of that account, with the exception of the surrender and cancellation and replacement processes pursuant to Articles 52, 53, 60 and 61.
7027	One or more units in the serial block are not recognised as being held by the transferring account.
7101	The account has already been created.
7102	An account must have one and only one account holder.
7103	An account must have one and only one primary authorised representative.
7104	An account must have one and only one secondary authorised representative.
7105	An installation must have one and only one contact person.
7106	The installation associated to this account is already associated to another account.
7107	The authorised representatives of the account must all be different.
7108	The alphanumeric identifier specified for the account is already specified for another account.
7109	The account type being created has not been given the correct commitment period.
7110	An operator holding account must have one and only one installation associated with that account.
7111	The specified account does not exist, and therefore it is not possible to update or close the account.
7113	It is not possible to change the account holder of a person holding account.
7114	The specified account has already been closed therefore it is not possible to close the account.
7115	The specified account still holds units and therefore it is not possible to close the account.
7117	The installation linked to the specified account is not in compliance therefore it is not possible to close the account.
7118	The specified installation does not exist and therefore it is not possible to update the verified emissions table for that installation.
7119	The specified year is a future year and therefore it is not possible to update the verified emissions table for that year.
7120	The people and their relationship with the account do not exist and therefore it is not possible to update that relationship.
7122	The correlation identifier is not in valid format or is out of range.
7124	The account alphanumeric identifier is not in valid format or is out of range
7125	The permit identifier is not in valid format or is out of range.
7126	The installation name is not in valid format or is out of range.
7127	The installation main activity is not in valid format or is out of range.
7128	The installation country is not in valid format or is out of range.
7129	The installation postal code is not in valid format or is out of range.
7130	The installation city is not in valid format or is out of range.
7131	The installation address1 is not in valid format or is out of range.
7132	The installation address2 is not in valid format or is out of range.
7133	The installation parent company is not in valid format or is out of range.
7134	The installation subsidiary company is not in valid format or is out of range.
7135	The installation EPER identification is not in valid format or is out of range.
7136	The installation latitude is not in valid format or is out of range.
7137	The installation longitude is not in valid format or is out of range.
7138	The people relationship code is not in valid format or is out of range.
7139	The person identifier is not in valid format or is out of range.
7140	The people first name is not in valid format or is out of range.
7141	The people last name is not in valid format or is out of range.
7142	The people country is not in valid format or is out of range.
7143	The people postal code is not in valid format or is out of range.
7144	The people city is not in valid format or is out of range.
7145	The people address1 is not in valid format or is out of range.
7146	The people address2 is not in valid format or is out of range.
7147	The people phonenumber1 is not in valid format or is out of range.
7148	The people phonenumber2 is not in valid format or is out of range.
[ F3 ]
7150	The people email is not in valid format or is out of range.
7151	The people action is not in valid format or is out of range.
7152	The installation verified emission is not in valid format or is out of range.
7153	The from element is not in valid format or is out of range.
7154	The to element is not in valid format or is out of range.
7155	The major version is not in valid format or is out of range.
7156	The minor version is not in valid format or is out of range.
7157	The account type is not in valid format or is out of range.
7158	The account identifier is not in valid format or is out of range.
7159	The installation identifier is not in valid format or is out of range.
7160	It is not possible for a person holding account to have a contact person or his details, or an installation or its details (as listed in section 11.1 of Annex I to Commission Decision 2004/156/EC) associated with that account.
[F2 7161	The installation related to the operator holding account is not indicated as ‘ closed ’ in the national allocation plan table and therefore it is not possible to close the account.
7162	The installation related to the operator holding account does not have an entry in the national allocation plan table and therefore it is not possible to open the account.	]
7201	The amount of allowances for the specified period requested to be issued exceeds the amount approved by the Commission in the national allocation plan.
7202	The acquiring account is not a Party holding account.
7203	The national allocation plan table has not been submitted to the Commission and therefore it is not possible for the issuance or allocation of allowances for the specified period to take place.
7205	The units requested to be converted into allowances must be AAUs that have been issued for a commitment period matching the commitment period for which allowances are being issued.
7206	The specified acquiring account is not the operator holding account which is associated to the specified installation.
7207	The installation does not exist in the national allocation plan table.
7208	The specified year does not exist in the national allocation plan table.
7209	The acquiring account is not the retirement account for the 2005-2007 period.
7210	Force-majeure allowances can only be issued prior to 30 June 2008.
7211	The amount of force-majeure allowances requested to be issued exceeds the amount approved by the Commission for the commitment period.
7212	The acquiring account is not the cancellation account for the 2005-2007 period.
7213	The reduction in the number of allowances exceeds the correction to the NAP as approved by the Commission.
7214	The number of allowances transferred is not strictly equal to the number foreseen in the NAP for the specified installation and specified year.
7215	The installation does not exist.
7216	The number of allowances transferred for the specified installation and specified year as foreseen in the national allocation plan has already been transferred.
7217	The specified year is not part of the period 2005-2007.
7218	The specified AAUs are allowances and therefore it is not possible to convert those AAUs into ERUs.
7219	The units requested to be issued do not have the correct allowance identification code and therefore it is not possible for the issue to take place.
7220	The units requested to be issued do not have the correct force majeure allowance identification code and therefore it is not possible for the issue to take place.
[F2 7221	The acquiring or transferring account may not be in a registry referred to in Article 63a.
7222	The allowances to be transferred may not have a supplementary unit type 4.
7223	The acquiring account must be the cancellation account for the relevant period.
7224	Allowances to be issued must have a supplementary unit type 4.
7225	The combined holdings after the transaction of the two Party holding accounts involved in the transaction in the registry referred to in Article 63a must be equal to their combined holdings before the transaction.
7226	The balance of the Party holding account capable of holding supplementary unit type 1, 2 or 3 allowances must be greater than or equal to the quantity to be transferred from the registry referred to in Article 63a.
7227	The acquiring account must be the retirement account for the current period.
7228	Allowances must be those issued for the current period.	]
[F1 7301	Warning: holdings calculated pursuant to Decision 18/CP.7 of the Conference of the Parties of the UNFCCC are only 1 % above commitment period reserve	]
7302	There is no mutual recognition agreement between the transferring registry and the acquiring registry that enables the transfer of allowances.
7304	After 30 April of the first year of the current period, allowances issued for the preceding period may only be transferred to the cancellation account or retirement account for that period.
7305	Allowances are not those issued for the 2005-2007 period.
7353	It is not possible to surrender allowances issued for the period 2005-2007 for the period 2008-2012 and subsequent five-year periods.
7354	The transferring account is not an operator holding account.
7355	It is not possible to surrender allowances issued for the current period for the previous period.
7356	Units are not eligible for surrender pursuant to Article 53.
7357	The number of allowances and force majeure allowances requested to be transferred to the retirement account is not equal to the number of allowances surrendered pursuant to Articles 52 and 54.
7358	The number of AAUs requested to be converted from allowances is not equal to the number of allowances surrendered pursuant to Article 52.
7359	The number of units requested to be transferred to the retirement account is not equal to the number of allowances surrendered pursuant to Article 52 and 53.
7360	The transferring account(s) are not Party holding account(s).
7361	Units are not eligible for retirement pursuant to Articles 58 and 59.
7362	The number of CERs requested to be transferred to the cancellation account is not equal to the number of allowances surrendered pursuant to Article 53.
[F2 7363	the quantity of AAUs to be retired is not equal with the quantity of allowances converted with the ‘ conversion of unallocated allowances for retirement ’ process.
7364	The transaction is not initiated after 30 June of the year following the last year of the relevant five-year period.
7365	The units to be retired are allowances and thus cannot be retired.
7366	The quantity to be converted cannot exceed the number of allowances issued but not allocated.	]
7401	The number of AAUs requested to be converted into allowances is not equal to the number of allowances cancelled.
7402	Specified unit type requested to be cancelled in advance of replacement is not an allowance issued for the preceding period.
7404	The number of allowances cancelled is not equal to the number of allowances to be cancelled pursuant to Article 60(a) and 61(b).
7405	The quantity of allowances cancelled from the transferring account is not equal to the quantity of allowances transferred back to this account.
7406	The transferring account(s) must be accounts referred to in Article 11(1) and (2).
7407	The acquiring account(s) must be accounts referred to in Article 11(1) and (2).
[F2 7408	The number of allowances cancelled must be equal to the number of allowances to be cancelled pursuant to Article 63o.
7451	The total quantity of allowances in the updated NAP and in the current NAP must be equal.
7452	The quantity allocated to new entrants may not be greater than the quantity by which the reserve is decreased.	]
7501	There is an inconsistency between the registry and the CITL in the operator holding account unit blocks.
7502	There is an inconsistency between the registry and the CITL in the person holding account unit blocks.
7503	Information: there are no inconsistencies between the registry and the CITL in the operator holding account unit blocks.
7504	Information: there are no inconsistencies between the registry and the CITL in the person holding account unit blocks.
7505	There is an inconsistency between the registry and the CITL in the totals of the operator holding account unit blocks.
7506	There is an inconsistency between the registry and the CITL in the totals of the person holding account unit blocks.
7507	Information: there are no inconsistencies between the registry and the CITL in the totals of the operator holding account unit blocks.
7508	Information: there are no inconsistencies between the registry and the CITL in the totals of the person holding account unit blocks.
7509	There is an inconsistency between the registry and the CITL in the Party holding account unit blocks.
7510	There is an inconsistency between the registry and the CITL in the retirement account unit blocks.
7511	There is an inconsistency between the registry and the CITL in the cancellation account unit blocks.
7512	Information: there are no inconsistencies between the registry and the CITL in the Party holding account unit blocks.
7513	Information: there are no inconsistencies between the registry and the CITL in the retirement account unit blocks.
7514	Information: there are no inconsistencies between the registry and the CITL in the cancellation account unit blocks.
7515	There is an inconsistency between the registry and the CITL in the totals of the Party holding account unit blocks.
7516	There is an inconsistency between the registry and the CITL in the totals of the retirement account unit blocks.
7517	There is an inconsistency between the registry and the CITL in the totals of the cancellation account unit blocks.
7518	Information: there are no inconsistencies between the registry and the CITL in the totals of the Party holding account unit blocks.
7519	Information: there are no inconsistencies between the registry and the CITL in the totals of the retirement account unit blocks.
7520	Information: there are no inconsistencies between the registry and the CITL in the totals of the cancellation account unit blocks.
7521	There is an inconsistency between the registry and the CITL in the replacement account unit blocks.
7522	Information: there are no inconsistencies between the registry and the CITL in the replacement account unit blocks.
7523	There is an inconsistency between the registry and the CITL in the totals of the replacement account unit blocks.
7524	Information: there are no inconsistencies between the registry and the CITL in the totals of the replacement account unit blocks.
[F2 7525	The verified emissions figure for year X cannot be corrected after 30 April of year X+1 unless the competent authority notifies the Central Administrator the new compliance status applicable to the installation whose verified emissions figure is corrected.	]
7601	Reminder: the specified unit blocks of allowances issued for the previous period have not yet been cancelled pursuant to Articles 60 and 61.
[F2 7700	The commitment period code is out of range.
7701	Allocation must be provided for all the years within the commitment period except the years before the current one.
7702	The new reserve must remain positive or zero.
7703	The amount of allowances to allocate for an installation and a year must be greater than or equal to 0.
7704	The permit identifier must exist and be connected to the installation identifier.
7705	The amount of allowances allocated for an installation and a year in the updated NAP must be greater than or equal to this amount in the current NAP.
7706	The amount of allowances deleted from the NAP table for installations must be equal to the amount by which the reserve is increased.
7901	Initiating registry must be listed in Registry table.	1501
7902	Initiating registry status must allow transactions to be proposed. (The CITL will maintain the current status of each registry. In this case, the CITL must recognize that the registry is fully operational.).	1503
7903	Acquiring registry status must allow transactions to be accepted. (The CITL will maintain the current status of each registry. In this case, the CITL must recognize that the registry is fully operational.).	1504
7904	Registry status must allow reconciliation actions to be conducted. (The CITL will maintain the current status of each registry. In this case, the CITL must recognize that the registry is available for reconciliation.).	1510
7905	Transaction ID must be comprised of a valid registry code followed by numeric values.	2001
7906	Transaction type code must be valid.	2002
7907	Supplementary Transaction Type code must be valid.	2003
7908	Transaction status code must be valid.	2004
7909	Account Type code must be valid.	2006
7910	Initiating Account Identifier must be greater than zero.	2007
7911	Acquiring Account Identifier must be greater than zero.	2008
7912	The Originating Registry of all unit blocks must be valid.	2010
7913	Unit Type code must be valid.	2011
7914	Supplementary Unit Type code must be valid.	2012
7915	Unit Serial Block Start and Unit Serial Block End must be present.	2013
7916	Unit Serial Block End must be greater than or equal to the Unit Serial Block Start.	2014
7917	RMUs, ERUs converted from RMUs, tCERs and lCERs must have a valid LULUCF activity code.	2015
7918	AAUs, ERUs converted from AAUs and CERs must not have a LULUCF activity code.	2016
7919	ERUs, CERs, tCERs, and lCERs must have a valid Project ID.	2017
7920	AAUs or RMUs must not have a Project ID.	2018
7921	ERUs must have a valid ‘ Track Code ’ .	2019
7922	AAUs, RMUs, CERs, tCERs and lCERs must not have a track code.	2020
7923	AAUs, RMUs, ERUs and CERs must not have an Expiry Date.	2022
7924	Transaction ID for proposed transactions must not already exist in the CITL.	3001
7925	Transaction ID for ongoing transactions must already exist in the CITL.	3002
7926	Previous completed transactions cannot be completed again.	3003
7927	Previously rejected transactions cannot be completed.	3004
7928	Transactions for which a CITL discrepancy has been previously identified cannot be completed.	3005
7930	Previously terminated transactions cannot be completed.	3007
7931	Previously cancelled transactions cannot be completed.	3008
7932	Previously accepted external transactions cannot be terminated.	3009
7933	Transaction status of Accepted or Rejected is not valid for non-external transactions.	3010
7934	Transaction status from Initiating registry must indicate status of Proposed, Completed, or Terminated.	3011
7935	Transaction status from Acquiring registry for an External Transfer must indicate status of Rejected or Accepted.	3012
7936	Applicable Commitment Period must correspond to the current or next Commitment Period (including their ‘ true-up ’ periods).	4001
7937	Units identified in the transaction must already exist in the CITL.	4002
7938	Units identified in the transaction must be held by Initiating registry.	4003
7939	All attributes of all unit blocks must be consistent with CITL unit block attributes except where attributes are changed by the current transaction.	4004
7940	All unit blocks in transaction must be for a single Applicable Commitment Period.	4005
7941	For all transactions except for external transfers, the Initiating and Acquiring Registries must be the same.	4006
7942	For external transfers, the Initiating and Acquiring Registries must be different.	4007
7943	Units identified in the transaction must not have inconsistencies identified through reconciliation with the CITL.	4008
7945	Units identified in the transaction must not be involved in another transaction.	4010
7946	Cancelled units must not be subject to further transactions.	4011
7947	A transaction proposal must contain at least one unit block.	4012
7948	A transaction must not issue more than one Unit Type.	5004
7949	The Original Commitment Period must be the same for all units issued by the transaction	5005
7950	The Applicable Commitment Period must be the same as the Original Commitment Period for all units issued by the transaction.	5006
7951	Cancellation to Excess Issuance Cancellation Account must not take place in a national registry.	5152
7952	The Acquiring Account for a cancellation transaction must be a cancellation account.	5153
7953	Account identifiers must be provided for acquiring accounts in cancellation transactions.	5154
7954	The unit blocks to be cancelled must have the same Applicable Commitment Period as the cancellation Account.	5155
7955	The Initiating registry retiring units must be a national registry or the Community Registry.	5251
7956	The Acquiring Account for a retirement transaction must be a retirement account.	5252
7957	Account identifiers must be provided for acquiring accounts in retirement transactions.	5253
7958	The Unit Blocks retired must have the same Applicable Commitment as the Retirement Account.	5254
7959	The Initiating registry carrying over units must be a national registry.	5301
7960	The Initiating Account for a carry-over transaction must be a holding account.	5302
7961	Units may be carried-over only to the next subsequent commitment period.	5303
7962	Reconciliation Identifier must be greater than zero.	6201
7963	Reconciliation ID must be comprised of a valid registry code followed by numeric values.	6202
7964	Reconciliation status must be a value between 1 and 11.	6203
7965	Reconciliation snapshot must be a date between 1 October 2004 and the current date plus 30 days.	6204
7966	Account Type must be valid.	6205
7969	Reconciliation ID must exist in the Reconciliation Log table.	6301
7970	Reconciliation status sent by registry must be valid.	6302
7971	Incoming reconciliation status must be the same as the reconciliation status recorded by the CITL.	6303
7972	The registry reconciliation snapshot DateTime must be consistent with the CITL Reconciliation Snapshot DateTime.	6304]

ANNEX XIII U.K. Testing procedures

1. A registry and the Community independent transaction log shall complete the following stages of testing: U.K.

(a)

Unit tests: individual components shall be tested against their specifications.

(b)

Integration tests: groups of components, comprising parts of the complete system, shall be tested against their specifications.

(c)

System tests: the system as a whole shall be tested against its specifications.

(d)

Load tests: the system shall be subjected to peaks in activity reflecting the likely demands that will be made on the system by its users.

(e)

Security testing: any security weaknesses of the system shall be identified.

2. Individual tests for a registry carried out as part of the testing stages set out in paragraph 1 shall be conducted according to a pre-defined test plan and the results shall be documented. This documentation shall be made available to the Central Administrator on request. Any deficiencies in a registry detected during the testing stages set out in paragraph 1 shall be addressed before any testing of data exchange takes place between that registry and the Community independent transaction log. U.K.

3. The Central Administrator shall require a registry to complete the following stages of testing: U.K.

(a)

Authentication tests: the ability of the registry to identify the Community independent transaction log, and vice versa, shall be tested.

(b)

Time synchronisation tests: the ability of the registry to establish its system time and to change its system time in order to be consistent with the system time of the Community independent transaction log and UNFCCC independent transaction log shall be tested.

(c)

Data format tests: the ability of the registry to generate messages corresponding to the appropriate process status and stage and to the appropriate format, set out in the functional and technical specifications for data exchange standards for registry systems under the Kyoto Protocol, elaborated pursuant to Decision 24/CP.8 of the Conference of the Parties to the UNFCCC, shall be tested.

(d)

Programming code and database operations tests: the ability of the registry to process messages received which correspond to the appropriate format, set out in the functional and technical specifications for data exchange standards for registry systems under the Kyoto Protocol, elaborated pursuant to Decision 24/CP.8 of the Conference of the Parties to the UNFCCC, shall be tested.

(e)

[F1 Integrated process testing: the ability of the registry to execute all processes, including all relevant statuses and stages set out in Annexes VIII to XI and XIa, and to allow manual interventions to the database pursuant to Annex X, shall be tested.]

(f)

Data logging tests: the ability of the registry to establish and maintain the records required pursuant to Article 73(2) shall be tested.

[F1 4. The Central Administrator shall require a registry to demonstrate that the input codes referred to in Annex VII and the response codes referred to in Annexes VIII to XI and XIa are contained within that registry's database and interpreted and used appropriately in respect of processes.] U.K.

5. The testing stages set out in paragraph 3 shall take place between the testing area of the registry and the testing area of the Community independent transaction log, established pursuant to Article 71. U.K.

6. Individual tests carried out as part of the testing stages set out in paragraph 3 may vary to reflect the software and hardware used by a registry. U.K.

7. Individual tests carried out as part of the testing stages set out in paragraph 3 shall be conducted according to a pre-defined test plan and the results shall be documented. This documentation shall be made available to the Central Administrator on request. Any deficiencies in a registry detected during the testing stages set out in paragraph 3 shall be addressed prior to a communication link between that registry and the Community independent transaction log being established. The registry administrator shall demonstrate that any such deficiencies have been addressed by the successful completion of the testing stages set out in paragraph 3. U.K.

ANNEX XIV U.K. Initialisation procedures

1. By 1 September 2004 at the latest, each Member State shall notify the Commission of the following information: U.K.

(a)

Name, address, city, postcode, country, telephone number, facsimile number and e-mail address of the registry administrator for its registry.

(b)

Address, city, postcode and country of the physical location of the registry.

(c)

The uniform resource locator (URL) and the port(s) of both the secure area and public area of the registry, and the URL and the port(s) of the testing area.

(d)

Description of the primary and backup hardware and software used by the registry, and of the hardware and software supporting the testing area pursuant to Article 68.

(e)

Description of the systems and procedures for the safeguarding of all data, including the frequency with which a backup of the database is undertaken, and the systems and procedures for prompt recovery of all data and operations in the event of a disaster pursuant to Article 68.

(f)

Description of the security plan of the registry established pursuant to the general security requirements under Annex XV.

(g)

Description of the system and procedures of the registry in respect of change management pursuant to Article 72.

(h)

Information requested by the Central Administrator to enable the distribution of digital certificates pursuant to Annex XV.

Any subsequent changes shall be promptly notified to the Commission.

2. For the period 2005-2007, each Member State shall notify the Commission of the number of force majeure allowances to be issued, subsequent to an authorisation to issue such allowances being granted by the Commission pursuant to Article 29 of Directive 2003/87/EC. U.K.

3. In advance of the 2008-2012 period and each subsequent five year period, each Member State shall notify the Commission of the following information: U.K.

(a)

The total number of ERUs and CERs which operators are allowed to use for each period pursuant to Article 11a(1) of Directive 2003/87/EC.

(b)

The commitment period reserve, calculated in accordance with Decision 18/CP.7 of the Conference of the Parties to the UNFCCC as 90 per cent of the Member State’s assigned amount or 100 % of five times its most recently reviewed inventory, whichever is lowest. Any subsequent changes shall be promptly notified to the Commission.

National allocation plan table requirements U.K.

4. Each national allocation plan shall be submitted in accordance with the formats set out in paragraphs 5 and 7. U.K.

5. The format for submitting a national allocation plan table to the Commission is the following: U.K.

(a)

Total number of allowances allocated: in a single cell the total number of allowances that are allocated for the period covered by the national allocation plan.

(b)

Total number of allowances in the new entrants reserve: in a single cell the total number of allowances that are set aside for new entrants for the period covered by the national allocation plan.

(c)

Years: in individual cells for each of the years covered in the national allocation plan from 2005 onwards in ascending order.

(d)

Installation identification code: in individual cells comprising the elements set out in Annex VI and in ascending order.

(e)

Allocated allowances: the allowances to be allocated for a specified year for a specified installation shall be entered into the cell connecting that year to that installation’s identification code.

6. The installations listed under paragraph 5(d) shall include installations unilaterally included under Article 24 of Directive 2003/87/EC and shall not include any installations temporarily excluded under Article 27 of Directive 2003/87/EC. U.K.

[F1 7. The XML schema for submitting a national allocation plan table to the Commission is the following: U.K.

<?xml version= " 1.0 " encoding= " UTF-8 " ?>

<xs:schema targetNamespace= " urn:KyotoProtocol:RegistrySystem:CITL:1.0:0.0 " xmlns:xs= " http://www.w3.org/2001/XMLSchema " xmlns= " urn:KyotoProtocol:RegistrySystem:CITL:1.0:0.0 " elementFormDefault= " qualified " >

<xs:simpleType name= " ISO3166MemberStatesType " >

<xs:restriction base= " xs:string " >

<xs:enumeration value= " AT " />

<xs:enumeration value= " BE " />

<xs:enumeration value= " BG " />

<xs:enumeration value= " CY " />

<xs:enumeration value= " CZ " />

<xs:enumeration value= " DE " />

<xs:enumeration value= " DK " />

<xs:enumeration value= " EE " />

<xs:enumeration value= " ES " />

<xs:enumeration value= " FI " />

<xs:enumeration value= " FR " />

<xs:enumeration value= " GB " />

<xs:enumeration value= " GR " />

<xs:enumeration value= " HU " />

<xs:enumeration value= " IE " />

<xs:enumeration value= " IT " />

<xs:enumeration value= " LT " />

<xs:enumeration value= " LU " />

<xs:enumeration value= " LV " />

<xs:enumeration value= " MT " />

<xs:enumeration value= " NL " />

<xs:enumeration value= " PL " />

<xs:enumeration value= " PT " />

<xs:enumeration value= " RO " />

<xs:enumeration value= " SE " />

<xs:enumeration value= " SI " />

<xs:enumeration value= " SK " />

</xs:restriction>

</xs:simpleType>

<xs:simpleType name= " AmountOfAllowancesType " >

<xs:restriction base= " xs:integer " >

<xs:minInclusive value= " 0 " />

<xs:maxInclusive value= " 999999999999999 " />

</xs:restriction>

</xs:simpleType>

<xs:group name= " YearAllocation " >

<xs:sequence>

<xs:element name= " yearInCommitmentPeriod " >

<xs:simpleType>

<xs:restriction base= " xs:int " >

<xs:minInclusive value= " 2005 " />

<xs:maxInclusive value= " 2058 " />

</xs:restriction>

</xs:simpleType>

</xs:element>

<xs:element name= " allocation " type= " AmountOfAllowancesType " />

</xs:sequence>

</xs:group>

<xs:simpleType name= " ActionType " >

<xs:annotation>

<xs:documentation>The action to be undertaken for the installation

A

=

Add the installation to the NAP

U

=

Update the allocations for the installation in the NAP

D

=

Delete the installation from the NAP

For each action, all year of a commitment period need to be given

</xs:documentation>

</xs:annotation>

<xs:restriction base= " xs:string " >

<xs:enumeration value= " A " />

<xs:enumeration value= " U " />

<xs:enumeration value= " D " />

</xs:restriction>

</xs:simpleType>

<xs:complexType name= " InstallationType " >

<xs:sequence>

<xs:element name= " action " type= " ActionType " />

<xs:element name= " installationIdentifier " >

<xs:simpleType>

<xs:restriction base= " xs:integer " >

<xs:minInclusive value= " 1 " />

<xs:maxInclusive value= " 999999999999999 " />

</xs:restriction>

</xs:simpleType>

</xs:element>

<xs:element name= " permitIdentifier " >

<xs:simpleType>

<xs:restriction base= " xs:string " >

<xs:minLength value= " 1 " />

<xs:maxLength value= " 50 " />

<xs:pattern value= " [A-Z0-9\-]+ " />

</xs:restriction>

</xs:simpleType>

</xs:element>

<xs:group ref= " YearAllocation " minOccurs= " 3 " maxOccurs= " 5 " />

</xs:sequence>

</xs:complexType>

<xs:simpleType name= " CommitmentPeriodType " >

<xs:restriction base= " xs:int " >

<xs:minInclusive value= " 0 " />

<xs:maxInclusive value= " 10 " />

</xs:restriction>

</xs:simpleType>

<xs:element name= " nap " >

<xs:complexType>

<xs:sequence>

<xs:element name= " originatingRegistry " type= " ISO3166MemberStatesType " />

<xs:element name= " commitmentPeriod " type= " CommitmentPeriodType " />

<xs:element name= " installation " type= " InstallationType " maxOccurs= " unbounded " >

<xs:unique name= " yearAllocationConstraint " >

<xs:selector xpath= " yearInCommitmentPeriod " />

<xs:field xpath= " . " />

</xs:unique>

</xs:element>

<xs:element name= " reserve " type= " AmountOfAllowancesType " />

</xs:sequence>

</xs:complexType>

<xs:unique name= " installationIdentifierConstraint " >

<xs:selector xpath= " installation " />

<xs:field xpath= " installationIdentifier " />

</xs:unique>

</xs:element>

</xs:schema>.]

8. As part of the initialisation procedures set out in the functional and technical specifications for data exchange standards for registry systems under the Kyoto Protocol, elaborated pursuant to Decision 24/CP.8 of the Conference of the Parties to the UNFCCC, the Commission shall inform the Secretariat to the UNFCCC of the account identification codes of the cancellation accounts, retirement accounts and replacement accounts of each registry. U.K.

ANNEX XV U.K. Security standards

Communication link between the Community independent transaction log and each registry U.K.

1. [F1 When the communication link between the Community independent transaction log and the UNFCCC independent transaction log is not established, all processes concerning allowances, automatic national allocation plan table changes, verified emissions and accounts shall be completed using a communication link with the following properties:] U.K.

(a)

Secure transmission shall be achieved through the use of secure socket layer (SSL) technology with a minimum of 128 bit encryption.

(b)

The identity of each registry shall be authenticated using digital certificates for the requests originating from the Community independent transaction log. The identity of the Community independent transaction log shall be authenticated using digital certificates for each request originating from a registry. The identity of each registry shall be authenticated using a user name and password for each request originating from a registry. The identity of the Community independent transaction log shall be authenticated using a user name and password for each request originating from the Community independent transaction log. Digital certificates shall be registered as valid by the certification authority. Secure systems shall be used to store the digital certificates and usernames and passwords, and access shall be limited. Usernames and passwords shall have a minimum length of 10 characters and shall comply with the hypertext transfer protocol (HTTP) basic authentication scheme (http://www.ietf.org/rfc/rfc2617.txt).

[F1 2. When the communication link between the Community independent transaction log and the UNFCCC independent transaction log is established, all processes concerning allowances, automatic national allocation plan table changes, verified emissions, accounts and Kyoto units shall be completed using a communication link with the properties set out in the functional and technical specifications for data exchange standards for registry systems under the Kyoto Protocol, elaborated pursuant to Decision 24/CP.8 of the Conference of the Parties to the UNFCCC.] U.K.

Communication link between the Community independent transaction log and its authorised representatives, and each registry and all authorised representatives in that registry U.K.

3. The communication link between the Community independent transaction log and its authorised representatives, and between a registry and the authorised representatives of account holders, verifiers and the registry administrator, when the authorised representatives are obtaining access from a network different from the one serving the Community independent transaction log or that registry, shall have the following properties: U.K.

(a)

Secure transmission shall be achieved through the use of secure socket layer (SSL) technology with a minimum of 128 bit encryption.

(b)

The identity of each authorised representative shall be authenticated through the use of usernames and passwords, which are registered as valid by the registry.

4. The system for issuing usernames and passwords pursuant to paragraph 3(b) to authorised representatives shall have the following properties: U.K.

(a)

At any time, each authorised representative shall have a unique username and a unique password.

(b)

The registry administrator shall maintain a list of all authorised representatives who have been granted access to the registry and their access rights within that registry.

(c)

The number of authorised representatives of the Central Administrator and registry administrator shall be kept to a minimum and access rights shall be allocated solely on the basis of enabling administrative tasks to be performed.

(d)

Any default vendor passwords with Central Administrator or registry administrator access rights shall be changed immediately after installation of the software and hardware for the Community independent transaction log or registry.

(e)

Authorised representatives shall be required to change any temporary passwords they have been given upon accessing the secure area of the Community independent transaction log or registry for the first time, and thereafter shall be required to change their passwords every two months at a minimum.

(f)

The password management system shall maintain a record of previous passwords for an authorised representative and prevent re-use of the previous ten passwords for that authorised representative. Passwords shall have a minimum length of 8 characters and be a mix of numeric and alphabetical characters.

(g)

Passwords shall not be displayed on a computer screen when being entered by an authorised representative, and password files shall not be directly visible to an authorised representative of the Central Administrator or registry administrator.

Communication link between the Community independent transaction log and the general public, and each registry and the general public U.K.

5. The public area of the website of the Community independent transaction log and the public website of a registry shall not require authentication of its users representing the general public. U.K.

6. The public area of the Community independent transaction log website and the public area of a registry website shall not permit its users representing the general public to directly access data from the database of the Community independent transaction log or the database of that registry. Data which is publicly accessible in accordance with Annex XVI shall be accessed via a separate database. U.K.

General security requirements for the Community independent transaction log and each registry U.K.

7. The following general security requirements shall apply to the Community independent transaction log and each registry: U.K.

(a)

A firewall shall protect the Community independent transaction log and each registry from the Internet, and shall be configured as strictly as is possible to limit traffic to and from the Internet.

(b)

The Community independent transaction log and each registry shall run regular virus scans on all nodes, workstations and servers within their networks. Anti-virus software shall be updated regularly.

(c)

The Community independent transaction log and each registry shall ensure that all node, workstation and server software is correctly configured and routinely patched as security and functional updates are released.

(d)

When necessary, the Community independent transaction log and each registry shall apply additional security requirements to ensure that the registry system is able to respond to new security threats.

ANNEX XVI U.K. Reporting requirements of each registry administrator and the Central Administrator

Publicly available information from each registry and the Community independent transaction log U.K.

1. The Central Administrator shall display and update the information in paragraphs 2 to 4 in respect of the registry system on the public area of the Community independent transaction log's web site, in accordance with the specified timing, and each registry administrator shall display and update this information in respect of its registry on the public area of that registry's web site, in accordance with the specified timing. U.K.

2. The following information for each account shall be displayed in the week after the account has been created in a registry, and shall be updated on a weekly basis: U.K.

(a)

account holder name: the holder of the account (person, operator, Commission, Member State);

(b)

alphanumeric identifier: the identifier specified by the account holder assigned to each account;

(c)

name, address, city, postcode, country, telephone number, facsimile number and email address of the primary and secondary authorised representatives of the account specified by the account holder for that account.

3. The following additional information for each operator holding account shall be displayed in the week after the account has been created in the registry, and shall be updated on a weekly basis: U.K.

(a)

points 1 to 4.1, 4.4 to 5.5 and point 7 (activity 1) of the information identifying the installation related to the operator holding account as listed in section 11.1 of Annex I to Commission Decision 2004/156/EC;

(b)

permit identification code: the code assigned to the installation related to the operator holding account comprising the elements set out in Annex VI;

(c)

installation identification code: the code assigned to the installation related to the operator holding account comprising the elements set out in Annex VI;

(d)

allowances and any force majeure allowances allocated to the installation related to the operator holding account, which is part of the national allocation plan table or is a new entrant, under Article 11 of Directive 2003/87/EC.

4. The following additional information for each operator holding account for the years 2005 onwards shall be displayed in accordance with the following specified dates: U.K.

(a)

[F1 erified emissions figure, along with its corrections in accordance with Article 51 for the installation related to the operator holding account for year X shall be displayed from 15 May onwards of year (X+1);]

(b)

allowances surrendered pursuant to Articles 52, 53 and 54, by unit identification code, for year X shall be displayed from 15 May onwards of year (X+1);

(c)

a symbol identifying whether the installation related to the operator holding account is or is not in breach of its obligation under Article 6(2)(e) of Directive 2003/87/EC for year X shall be displayed from 15 May onwards of year (X+1).

Publicly available information from each registry U.K.

5. Each registry administrator shall display and update the information in paragraphs 6 to 10 in respect of its registry on the public area of that registry's web site, in accordance with the specified timing. U.K.

6. The following information for each project identifier for a project activity implemented pursuant to Article 6 of the Kyoto Protocol against which the Member State has issued ERUs shall be displayed in the week after the issue has taken place: U.K.

(a)

project name: a unique name for the project;

(b)

project location: the Member State and town or region in which the project is located;

(c)

years of ERU issuance: the years in which ERUs have been issued as a result of the project activity implemented pursuant to Article 6 of the Kyoto Protocol;

(d)

reports: downloadable electronic versions of all publicly available documentation relating to the project, including proposals, monitoring, verification and issuance of ERUs, where relevant, subject to the confidentiality provisions in Decision -/CMP.1 [Article 6] of the Conference of the Parties to the UNFCCC serving as the meeting of the Parties to the Kyoto Protocol[F1 ;]

(e)

[F2 any set-aside table drawn up in accordance with Commission Decision 2006/780/EC (1) .]

7. The following holding and transaction information, by unit identification code comprising the elements set out in Annex VI, relevant for that registry for the years 2005 onwards shall be displayed in accordance with the following specified dates: U.K.

(a)

the total quantity of ERUs, CERs, AAUs and RMUs held in each account (person holding, operator holding, Party holding, cancellation, replacement or retirement) on 1 January of year X shall be displayed from 15 January onwards of year (X+5);

(b)

the total quantity of AAUs issued in year X on the basis of the assigned amount pursuant to Article 7 of Decision No 280/2004/EC shall be displayed from 15 January onwards of year (X+1);

(c)

the total quantity of ERUs issued in year X on the basis of project activity implemented pursuant to Article 6 of the Kyoto Protocol shall be displayed from 15 January onwards of year (X+1);

(d)

the total quantity of ERUs, CERs, AAUs and RMUs acquired from other registries in year X and the identity of the transferring accounts and registries shall be displayed from 15 January onwards of year (X+5);

(e)

the total quantity of RMUs issued in year X on the basis of each activity under Article 3, paragraphs 3 and 4 of the Kyoto Protocol shall be displayed from 15 January onwards of year (X+1);

(f)

the total quantity of ERUs, CERs, AAUs and RMUs transferred to other registries in year X and the identity of the acquiring accounts and registries shall be displayed from 15 January onwards of year (X+5);

(g)

the total quantity of ERUs, CERs, AAUs and RMUs cancelled in year X on the basis of activities under Article 3, paragraphs 3 and 4 of the Kyoto Protocol shall be displayed from 15 January onwards of year (X+1);

(h)

the total quantity of ERUs, CERs, AAUs and RMUs cancelled in year X following determination by the compliance committee under the Kyoto Protocol that the Member State is not in compliance with its commitment under Article 3, paragraph 1 of the Kyoto Protocol shall be displayed from 15 January onwards of year (X+1);

(i)

the total quantity of other ERUs, CERs, AAUs and RMUs, or allowances, cancelled in year X and the reference to the Article pursuant to which these Kyoto units or allowances were cancelled under this Regulation shall be displayed from 15 January onwards of year (X+1);

(j)

the total quantity of ERUs, CERs, AAUs, RMUs and allowances retired in year X shall be displayed from 15 January onwards of year (X+1);

(k)

the total quantity of ERUs, CERs, AAUs carried over in year X from the previous commitment period shall be displayed from 15 January onwards of year (X+1);

(l)

the total quantity of allowances from the previous commitment period cancelled and replaced in year X shall be displayed from 15 May onwards of year X;

(m)

current holdings of ERUs, CERs, AAUs and RMUs in each account (person holding, operator holding, Party holding, cancellation or retirement) on 31 December of year X shall be displayed from 15 January onwards of year (X+5).

8. The list of persons authorised by the Member State to hold ERUs, CERs, AAUs and/or RMUs under its responsibility shall be displayed in the week after such authorisations have been given, and shall be updated on a weekly basis. U.K.

9. The total number of CERs and ERUs which operators are allowed to use for each period pursuant to Article 11a(1) of Directive 2003/87/EC shall be displayed in accordance with Article 30(3) of Directive 2003/87/EC. U.K.

10. The commitment period reserve, calculated in accordance with Decision 18/CP.7 of the Conference of the Parties to the UNFCCC as 90 % of the Member State's assigned amount or 100 % of five times its most recently reviewed inventory, whichever is lowest, and the number of Kyoto units by which the Member State is exceeding, and therefore in compliance with, its commitment period reserve shall be displayed on request. U.K.

Publicly available information from the Community independent transaction log U.K.

11. The Central Administrator shall display and update the information in paragraph 12 in respect of the registry system on the public area of the Community independent transaction log's web site, in accordance with the specified timing. U.K.

12. The following information for each completed transaction relevant for the registries system for year X shall be displayed from 15 January onwards of year (X+5): U.K.

(a)

account identification code of the transferring account: the code assigned to the account comprising the elements set out in Annex VI;

(b)

account identification code of the acquiring account: the code assigned to the account comprising the elements set out in Annex VI;

(c)

account holder name of the transferring account: the holder of the account (person, operator, Commission, Member State);

(d)

account holder name of the acquiring account: the holder of the account (person, operator, Commission, Member State);

(e)

allowances or Kyoto units involved in the transaction by unit identification code comprising the elements set out in Annex VI;

(f)

transaction identification code: the code assigned to the transaction comprising the elements set out in Annex VI;

(g)

date and time at which the transaction was completed (in Greenwich Mean Time);

(h)

process type: the categorisation of a process comprising the elements set out in Annex VII.

[F2 12a. The Central Administrator shall make available on the public area of the Community independent transaction log's web site from 30 April onwards of year (X+1) information indicating the percentage share of allowances surrendered in each Member State for year X that were not transferred prior to their surrender.] U.K.

Information from each registry to be made available to account holders U.K.

13. Each registry administrator shall display and update the information in paragraph 14 in respect of its registry on the secure area of that registry's web site, in accordance with the specified timing. U.K.

14. The following elements for each account, by unit identification code comprising the elements set out in Annex VI, shall be displayed on the account holder's request to that account holder only: U.K.

(a)

current holdings of allowances or Kyoto units;

(b)

list of proposed transactions initiated by that account holder, detailing for each proposed transaction the elements in paragraph 12(a) to (f), the date and time at which the transaction was proposed (in Greenwich Mean Time), the current status of that proposed transaction and any response codes returned consequent to the checks made pursuant to Annex IX;

(c)

list of allowances or Kyoto units acquired by that account as a result of completed transactions, detailing for each transaction the elements in paragraph 12(a) to (g);

(d)

list of allowances or Kyoto units transferred out of that account as a result of completed transactions, detailing for each transaction the elements in paragraph 12(a) to (g).

(1)

[F2 OJ L 316, 16.11.2006, p. 12 .]

Textual Amendments

F2 Inserted by Commission Regulation (EC) No 916/2007 of 31 July 2007 amending Regulation (EC) No 2216/2004 for a standardised and secured system of registries pursuant to Directive 2003/87/EC of the European Parliament and of the Council and Decision No 280/2004/EC of the European Parliament and of the Council (Text with EEA relevance).