Commission Regulation (EC) No 916/2007Dangos y teitl llawn

ANNEX I U.K.

Annexes I, II, III, VI to XIII and XVI to Regulation (EC) No 2216/2004 are amended as follows:

1.

Annex I is amended as follows:

(a)

paragraph 2 is replaced by the following:

‘2. When the communication link between the Community independent transaction log and the UNFCCC independent transaction log is not established:

(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).’;

(b)

paragraph 3 is replaced by the following:

‘3. When the communication link between the Community independent transaction log and the UNFCCC independent transaction log is established:

(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.’.

2.

In Annex III, the following sentences are added to paragraph 1:

‘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.’.

3.

Annex VI is amended as follows:

(a)

in Table VI-1 the text ‘4 = Allowance issued for the 2008 to 2012 and subsequent five-year periods by a Member State that does not have AAUs’ is added in column ‘Range or codes’, row ‘Supplementary unit type’;

(b)

in Table VI-2 the following row is added:

‘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’

(c)

in Table VI-3 the text ‘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’ is added to the text in column ‘Range or codes’, row ‘Account Identifier’;

(d)

in Table VI-5, the words ‘Permit Identifier’ are replaced by ‘Account Holder Identifier’;

(e)

paragraph 14 is replaced by the following:

‘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.’.

4.

Annex VII is amended as follows:

(a)

in the table under paragraph 4 the following row is deleted:

‘05-00

Retirement (2008 to 2012 onwards)’

(b)

in the table under paragraph 4 the following rows are added:

‘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)’

(c)

in the table under paragraph 5 the following row is added:

‘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’

5.

Annex VIII is amended as follows:

(a)

in paragraph 1, point (c) is replaced by the following:

‘(c)

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.’;

(b)

paragraph 2 is replaced by the following:

‘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.’;

(c)

in Tables VIII-5, VIII-11 and VIII-12 the line:

‘FaxNumber

Mandatory’

is replaced by:

‘FaxNumber

Optional’

(d)

in Table VIII-9, the text: ‘The initiating registry (Originating Registry) authenticates the UNFCCC independent transaction log (or Community independent transaction log prior to the link between the Community independent transaction log and UNFCCC independent transaction log being established) by calling the Authenticate Message() function and checks the version of the transaction log by calling Check Version() function.’ is replaced by the following text:

‘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.’;

(e)

in Table VIII-11 the number ‘7162’ is added to the last row;

(f)

in Tables VIII-12 and VIII-14 after the row containing ‘PermitIdentifier’, the following row is inserted:

‘PermitDate

Mandatory’

(g)

in Table VIII-13 after the row containing ‘PermitIdentifier’, the following row is inserted:

‘PermitDate

Optional’

(h)

in Table VIII-15 the number ‘7161’ is added to the last row;

(i)

paragraph 6 is replaced by the following:

‘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.’;

(j)

in Table VIII-17 the number ‘7525’ is added to the last row.

6.

Annex IX is amended as follows:

(a)

paragraph 4 is replaced by the following:

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

(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.’;

(b)

Table IX-1 is amended as follows:

(i)

the text ‘Range 7221 to 7222’ is inserted to column ‘Community independent transaction log response codes’, row ‘External transfer (2008 to 2012 onwards)’;

(ii)

the text ‘Range 7221 to 7222’ is inserted to column ‘Community independent transaction log response codes’, row ‘External transfer (2005 to 2007)’;

(iii)

the text ‘(registries referred to in Article 63a); 7219; Range 7223 to 7224; 7360; 7402; 7404; 7406; Range 7407 to 7408; 7202’ is added to column ‘Community independent transaction log response codes’, row ‘Cancellation and replacement’;

(iv)

the following row is deleted:

‘Retirement (2008 to 2012 onwards)

05-00

Range 7358 to 7361’

(v)

the following rows are added:

‘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’

(c)

The following paragraph 7 is added:

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

(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.’.

7.

Annex X is amended as follows:

(a)

in paragraph 1, the introductory phrase is replaced by the following:

‘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:’;

(b)

in paragraph 2, the introductory phrase is replaced by the following:

‘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:’;

(c)

in paragraph 3, the introductory phrase is replaced by the following:

‘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:’;

(d)

paragraph 6 is replaced by the following:

‘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.’.

8.

In Annex XI, paragraph 2 is replaced by the following:

‘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.’.

9.

Annex XII is amended as follows:

(a)

paragraph 1 is replaced by the following:

‘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.’;

(b)

Table XII-1 is amended as follows:

(i)

the column headings and the following line are deleted:

‘Response Code	Description
7149	The people fax number is not in valid format or is out of range’

(ii)

the following column headings and the following lines are inserted in the appropriate numerical order:

‘Response Code	Description	Equivalent response code under the data exchange standards
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
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
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
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
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
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’

(iii)

the line:

‘7301

Approaching breach of commitment period reserve’

is replaced by:

‘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’

10.

Annex XIII is amended as follows:

(a)

in paragraph 3, point (e) is replaced by the following:

‘(e)

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.’;

(b)

paragraph 4 is replaced by the following:

‘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.’.

11.

In Annex XIV, paragraph 7 is replaced with the following:

‘7. The XML schema for submitting a national allocation plan table to the Commission is the following:

<?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>’.

12.

Annex XV is amended as follows:

(a)

in paragraph 1 the introductory phrase is replaced by the following:

‘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:’;

(b)

paragraph 2 is replaced by the following:

‘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.’.

13.

Annex XVI is amended as follows:

(a)

paragraph 1 is replaced by the following:

‘1. The Central Administrator shall display and update the information in paragraphs 2 to 4a 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.’;

(b)

paragraph 2 is amended as follows:

(i)

in point (a) the following sentence is added:

‘In the case of operator holding accounts, the account holder name should be identical to name of the natural or legal person that is the holder of the relevant greenhouse gas permit;’;

(ii)

point (c) is replaced by the following:

‘(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, unless the registry administrator allows account holders to request keeping all or some of this information confidential and the account holder requested the registry administrator in writing not to display all or some of this information.’;

(c)

paragraph 3 is amended as follows:

(i)

point (d) is replaced by the following:

‘(d)

allowances and any force majeure allowances allocated and issued 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 and any corrections to such allocations;’;

(ii)

the following point (e) is added:

‘(e)

The date of the greenhouse gas permit's entry into force and the date of the opening of the account.’;

(d)

paragraph 4 is amended as follows:

(i)

point (a) is replaced by the following:

‘(a)

verified 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);’;

(ii)

point (c) is replaced by the following:

‘(c)

a symbol identifying whether the installation related to the operator holding account did or did not surrender the necessary number of allowances for year X by 30 April of year (X+1) in accordance with point (e) of Article 6(2) of Directive 2003/87/EC and any subsequent changes to that status pursuant to corrections to verified emissions in accordance with Article 51 (4) of this Regulation shall be displayed from 15 May onwards of year (X+1). Depending on the installation's compliance status figure and the registry's operational status, the following symbols shall be displayed together with the following statements:

Table XVI-1: compliance statements

Compliance status figure for year X under Article 55 on 30 April of year (X+1)	Symbol	Statement
	to be displayed on CITL and registries
Total surrendered allowances in accordance with Articles 52, 53, 54 for period ≥ verified emissions in period until current year	A	“A number of allowances and Kyoto units greater than or equal to verified emissions were surrendered by 30 April”
Total surrendered allowances in accordance with Articles 52, 53 and 54 for period < verified emissions in period until current year	B	“A number of allowances and Kyoto units lower than verified emissions were surrendered by 30 April”
	C	“Verified emissions were not entered until 30 April”
Verified emissions in period until current year were corrected pursuant to Article 51	D	“Verified emissions were corrected by competent authority after 30 April of year X. The competent authority of the Member State decided that the installation is not in compliance for year X.”
Verified emissions in period until current year were corrected pursuant to Article 51	E	“Verified emissions were corrected by competent authority after 30 April of year X. The competent authority of the Member State decided that the installation is in compliance for year X.”
	X	“Entering verified emissions and/or surrendering was impossible until 30 April due to the allowance surrender process and/or verified emissions update process being suspended for the Member State's registry in accordance with Article 6(3)” ’

(iii)

the following point (d) is added:

‘(d)

a symbol indicating if the installation’s account is blocked in accordance with Article 27(1) shall be displayed from 31 March onwards of year (X+1).’;

(e)

the following paragraphs 4a and 4b are inserted:

‘4a. The national allocation plan table of each Member State, indicating the allocations to installations and the quantity of allowances reserved for later allocation or sale shall be displayed and updated whenever there is a correction to the national allocation plan table, clearly indicating where corrections were made.

4b. The fees charged for the opening and annual maintenance of holding accounts in each registry shall be displayed on a continuous basis. Updates to this information shall be notified to the Central Administrator by the registry administrator within 15 days of any change in fees.’;

(f)

in paragraph 6, the following point (e) is added:

‘(e)

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

(g)

the following paragraph 12a is inserted:

‘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.’.

ANNEX II U.K.

The following Annex XIa is inserted to Regulation (EC) No 2216/2004:

“‘ANNEX XIa 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. The following message sequence for processes concerning automatic national allocation plan table changes shall apply: 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.

(1)

OJ L 316, 16.11.2006, p. 12.’;