Commission Regulation (EC) No 2216/2004 of 21 December 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 CouncilText with EEA relevance
Date: 2004-12-21
Institutions: European Commission
Subjects: database, documentary reference recording, operation of the Institutions, regulation of transactions, tradeable emission permit

29.12.2004

EN

Official Journal of the European Union

L 386/1

I

(Acts whose publication is obligatory)

COMMISSION REGULATION (EC) No 2216/2004

of 21 December 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)

TABLE OF CONTENTS

Chapter I

Subject matter and definitions . . . . . . . . . . . . . . . . . . . . . .

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

Chapter II

Registries and transaction logs . . . . . . . . . . . . . . . . . . . . . .

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

Chapter III

Contents of the registries . . . . . . . . . . . . . . . . . . . . . . . . .

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

Section 1

Reporting and Confidentiality . . . . . . . . . . . . . . . . . . . . . .

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

Section 2

Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

Section 3

Party accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

Section 4

Operator holding accounts . . . . . . . . . . . . . . . . . . . . . . . .

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

Section 5

Person holding accounts . . . . . . . . . . . . . . . . . . . . . . . . . .

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

Section 6

Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

Section 7

Codes and identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

Chapter IV

Checks and processes

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

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

Section 1

Blocking of accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

Section 2

Automated checks and the data reconciliation process . . . . . . .

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

Section 3

Execution and finalisation of processes . . . . . . . . . . . . . . . . .

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

Chapter V

Transactions

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

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

Section 1

Allocation and issue of allowances for the 2005-2007 period . . . . . . . . . . . . . . . . . .

Section 2

Allocation and issue of allowances for the 2008-2012 period and each subsequent five year
period . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

Section 3

Transfers and eligibility . . . . . . . . . . . . . . . . . . . . . . . . . .

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

Page

5

6

7

7

8

8

9

9

10

11

11

11

11

12

13

13

14

15

L 386/2

EN

Official Journal of the European Union

29.12.2004

Section 4

Verified emissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

Section 5

Surrender of allowances . . . . . . . . . . . . . . . . . . . . . . . . . .

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

Section 6

Cancellation and retirement

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

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

Section 7

Cancellation and replacement

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

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

Section 8

Voluntary cancellation and retirement

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

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

Chapter VI

Security standards, authentication and access rights . . . . . . . . .

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

Chapter VII

Availability and reliability of information . . . . . . . . . . . . . . .

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

Chapter VIII

Records and fees

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

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

Chapter IX

Final provisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

Annex I

Annex II

Annex III

Annex IV

Annex V

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

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

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

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

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

Annex VI

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

Table VI-1:

Unit Identification Code . . . . . . . . . . . . . . . . . . . . . . . . . .

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

Table VI-2:

Valid Initial Unit Type – Supplementary Unit Type . . . . . . . . .

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

Table VI-3:

Account Identification Code . . . . . . . . . . . . . . . . . . . . . . .

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

Table VI-4:

Permit Identification Code

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

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

Table VI-5:

Account Holder Identification Code

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

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

Table VI-6:

Installation Identification Code . . . . . . . . . . . . . . . . . . . . . .

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

Table VI-7:

Correlation Identification Code

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

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

Annex VII

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

Annex VIII

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

Table VIII-1:

Message Sequence Diagram for Processes concerning an Account or Verified Emissions . .

Table VIII-2:

Status Diagram for Processes concerning an Account or Verified Emissions . . . . . . . . . .

Table VIII-3:

Components and Functions for Processes concerning an Account or Verified Emissions . .

Table VIII-4:

MgmtOfAccountWS Component

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

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

Table VIII-5:

MgmtOfAccountWS.CreateAccount() function . . . . . . . . . . . .

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

Page

16

16

17

18

19

19

20

21

22

23

24

25

26

27

28

28

30

31

31

32

32

32

34

37

37

38

38

39

39

29.12.2004

EN

Official Journal of the European Union

L 386/3

Table VIII-6:

MgmtOfAccountWS.UpdateAccount() function . . . . . . . . . . .

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

Table VIII-7:

MgmtOfAccountWS.CloseAccount() function . . . . . . . . . . . . .

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

Table VIII-8:

MgmtOfAccountWS.UpdateVerifiedEmissions() function . . . . . .

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

Table VIII-9:

MgmtOfAccountWS.ReceiveAccountOperationOutcome() function . . . . . . . . . . . . . . .

Table VIII-10:

AccountManagement Component . . . . . . . . . . . . . . . . . . . .

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

Table VIII-11:

ManagementOfAccount.ValidateAccountCreation() function . . . .

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

Table VIII-12:

ManagementOfAccount.CreateAccount() function . . . . . . . . . .

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

Table VIII-13:

AccountManagement.ValidateAccountUpdate() function . . . . . .

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

Table VIII-14:

ManagementOfAccount.UpdateAccount() function . . . . . . . . .

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

Table VIII-15:

ManagementOfAccount.ValidateAccountClosure() function . . . .

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

Table VIII-16:

ManagementOfAccount.CloseAccount()

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

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

Table VIII-17:

ManagementOfAccount.ValidateVerifiedEmissionsUpdate()

. . . .

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

Table VIII-18:

ManagementOfAccount.UpdateVerifiedEmissions

. . . . . . . . . .

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

Table VIII-19:

Secondary Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

Annex IX

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

Table IX-1:

Tertiary Checks

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

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

Annex X

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

Table X-1:

Secondary Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

Annex XI

Annex XII

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

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

Table XII-1:

Community Independent Transaction Log Response Codes . . . .

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

Annex XIII

Annex XIV

Annex XV

Annex XVI

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

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

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

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

Page

41

43

44

44

45

46

47

49

50

52

52

53

53

54

55

56

58

59

60

62

62

68

70

73

75

THE COMMISSION OF THE EUROPEAN COMMUNITIES,

Having regard to the Treaty
Community,

establishing the European

Having regard to Directive 2003/87/EC of
the European
Parliament and of the Council of 13 October 2003 establishing
a scheme for greenhouse gas emission allowance trading within
the Community and amending Council Directive 96/61/EC (1),
and in particular Article 19(3) thereof,

the European
Having regard to Decision 280/2004/EC of
Parliament and of the Council of 11 February 2004 concerning
a mechanism for monitoring Community greenhouse gas
emissions and for implementing the Kyoto Protocol (2), and in
particular the first subparagraph, second sentence, Article 6(1)
thereof,

Whereas:

(1)

An integrated Community system of registries, consisting
of the registries of the Community and its Member States

(1) OJ L 275, 25.10.2003, p. 32.

(2) OJ L 49, 19.2.2004, p. 1.

L 386/4

EN

Official Journal of the European Union

29.12.2004

the

registries

incorporate

established pursuant to Article 6 of Decision No 280/
2004/EC that
established
pursuant to Article 19 of Directive 2003/87/EC and the
Community independent
transaction log established
pursuant to Article 20 of that Directive, is necessary to
transfer and cancellation of
ensure that
allowances does not
involve irregularities and that
transactions are compatible with the obligations resulting
from the United Nations Framework Convention on
Climate Change (UNFCCC) and the Kyoto Protocol.

the issue,

(2)

(3)

(4)

(5)

In accordance with Directive 2003/4/EC of 28 January
2003 on public access to environmental information (1)
and Decision 19/CP.7 of the Conference of the Parties to
the UNFCCC, specific reports should be made public on
a regular basis to ensure that the public has access to
information held within the
integrated system of
registries, subject to certain confidentiality requirements.

Community legislation concerning the protection of
individuals with regard to the processing of personal data
and on the free movement of such data,
in particular
Directive 95/46/EC on the protection of individuals with
regard to the processing of personal data and on the free
such data (2), Directive 2002/58/EC
movement of
concerning the processing of personal data and the
protection of privacy in the electronic communications
sector (3) and Regulation (EC) No 45/2001 on the
protection of individuals with regard to the processing of
personal data by the Community institutions and bodies
and on the free movement of such data (4), should be
respected where these are applicable to information held
and processed pursuant to this Regulation.

account,

and the

retirement

Each registry should contain one Party holding account,
one
cancellation and
replacement accounts required pursuant to Decision 19/
CP.7 of the Conference of the Parties to the UNFCCC for
each commitment period, and each registry established
pursuant to Article 19 of Directive 2003/87/EC should
contain holding accounts required to implement
the
requirements of that Directive for operators and for other
created in
persons. Each such account
accordance with standardised procedures to ensure the
integrity of the registries system and public access to
information held in this system.

should be

Article 6 of Decision No 280/2004/EC requires the
Community and its Member States
to apply the
functional and technical specifications for data exchange
standards for registry systems under the Kyoto Protocol,
the
elaborated pursuant
to Decision 24/CP.8 of
for
Conference of
the
to the UNFCCC,
establishment
and the
Community independent transaction log. The application

the Parties
and operation of

registries

(1) OJ L 41, 14.2.2003, p. 26.
(2) OJ L 281, 23.11.1995, p. 31.
(3) OJ L 201, 31.7.2002, p. 37.
(4) OJ L 8, 12.1.2001, p. 1.

(6)

(7)

(8)

(9)

(10)

(11)

and elaboration of these specifications in relation to the
integrated Community registries
the
incorporation of
the registries established pursuant to
Article 19 of Directive 2003/87/EC into the registries
established pursuant to Article 6 of Decision No 280/
2004/EC.

system allows

independent

transaction log will
The Community
in the
perform automated checks on all processes
Community registries
system concerning allowances,
verified emissions, accounts and Kyoto units, and the
UNFCCC independent
transaction log will perform
automated checks on processes concerning Kyoto units
to ensure that there are no irregularities. Processes that
fail
these checks will be terminated to ensure that
transactions in the Community registries system comply
with the requirements of Directive 2003/87/EC and the
requirements elaborated pursuant to the UNFCCC and
the Kyoto Protocol.

All
transactions in the Community registries system
should be executed in accordance with standardised
procedures and, where necessary, on a harmonised
timetable,
to ensure compliance with the
requirements of Directive 2003/87/EC and with the
requirements elaborated pursuant to the UNFCCC and
the Kyoto Protocol, and to protect the integrity of that
system.

in order

Minimum security
harmonised
standards
requirements on authentication and access rights should
be applied to protect the security of information held in
the integrated Community registries system.

and

each

Central

Administrator

registry
and
The
administrator should ensure that
interruptions to the
operation of the integrated Community registries system
are kept to a minimum by taking all reasonable steps to
and the
ensure
the
by
and
Community
providing for robust systems and procedures for the
safeguarding of all information.

availability of
independent

registries
log

transaction

the

Records concerning all processes, operators and persons
in the Community registries system should be stored in
accordance with the data logging standards set out in the
functional and technical specifications for data exchange
standards for registry systems under the Kyoto Protocol
elaborated pursuant
the
Conference of the Parties to the UNFCCC.

to Decision 24/CP.8 of

A transparent system of fees and a prohibition to charge
in the
specific
account
for
the
system will help ensure
Community registries
integrity of that system.

transactions

holders

29.12.2004

EN

Official Journal of the European Union

L 386/5

(12)

The measures provided for in this Regulation are in
accordance with the opinion of the Committee referred
to in Article 23(1) of Directive 2003/87/EC and Article
9(2) of Decision No 280/2004/EC.

HAS ADOPTED THIS REGULATION:

CHAPTER I

SUBJECT MATTER AND DEFINITIONS

Article 1

Subject matter

specifications

and operational

This Regulation lays down general provisions, functional and
and maintenance
technical
requirements concerning the standardised and secured registries
system consisting of registries,
in the form of standardised
electronic databases containing common data elements, and the
Community independent transaction log. It also provides for an
communication system between the Community
efficient
independent
transaction log and the UNFCCC independent
transaction log.

(f)

(g)

(h)

(i)

(j)

(k)

Article 2

Definitions

representative’ means

‘authorised
person
authorised to represent the Central Administrator, a registry
administrator, an account holder or a verifier pursuant to
Article 23;

natural

a

‘CDM registry’ means the clean development mechanism
registry established, operated and maintained by the
the clean development mechanism
executive board of
pursuant
the Kyoto Protocol and the
decisions adopted pursuant to the UNFCCC or the Kyoto
Protocol;

to Article 12 of

‘Central Administrator’ means the person designated by the
Commission pursuant to Article 20 of Directive 2003/87/
EC to operate and maintain the Community independent
transaction log;

independent

transaction log’ means

‘Community
the
independent transaction log provided for in Article 20(1) of
Directive 2003/87/EC for the purpose of recording the
issue,
and
established, operated and maintained in accordance with
Article 5;

cancellation of

allowances,

transfer

and

‘competent authority’ means the authority or authorities
designated by a Member State pursuant to Article 18 of
Directive 2003/87/EC;

detected by

an irregularity

‘discrepancy’ means
the
Community independent
transaction log or UNFCCC
independent transaction log whereby the proposed process
does not conform to the requirements specified under
Directive 2003/87/EC as elaborated in this Regulation and
the requirements elaborated pursuant to the UNFCCC or the
Kyoto Protocol;

For the purposes of this Regulation, the definitions laid down in
Article 3 of Directive 2003/87/EC shall apply. The following
definitions shall also apply:

(a)

‘2005-2007 period’ means the period from 1 January 2005
to 31 December 2007 as referred to in Article 11(1) of
Directive 2003/87/EC;

(b)

‘2008-2012 period and subsequent five-year periods’ means
the period from 1 January 2008 to 31 December 2012 plus
consecutive five-year periods as referred to in Article 11(2)
of Directive 2003/87/EC;

(l)

‘force majeure allowance’ means a force majeure allowance
issued pursuant to Article 29 of Directive 2003/87/EC;

(m) ‘inconsistency’ means

an irregularity detected by the
transaction log or UNFCCC
Community independent
independent
information
transaction log whereby the
regarding allowances, accounts or Kyoto units provided by a
registry as part of the periodic reconciliation process differs
from the information contained in either
independent
transaction log;

(n) ‘Kyoto unit’ means an AAU, RMU, ERU or CER;

(o)

‘process’ means any one of
Article 32;

the processes referred to in

(c)

‘account holder’ means a person who holds an account in
the registries system;

(d)

‘assigned amount’ means the amount of greenhouse gas
emissions in tonnes of carbon dioxide equivalent calculated
in accordance with the emission levels determined pursuant
to Article 7 of Decision No 280/2004/EC;

(e)

‘assigned amount unit’ (AAU) means a unit issued pursuant
to Article 7(3) of Decision No 280/2004/EC;

(p)

(q)

a

registry

‘registry’ means
established, operated and
maintained pursuant to Article 6 of Decision No 280/2004/
EC, incorporating a registry established pursuant to Article
19 of Directive 2003/87/EC;

‘registry administrator’ means
the competent authority,
persons or person, designated by the Member State or the
Commission,
that operates and maintains a registry in
accordance with the requirements of Directive 2003/87/EC,
Decision No 280/2004/EC and this Regulation;

(s)

(t)

(u)

(v)

L 386/6

EN

Official Journal of the European Union

29.12.2004

(r)

‘removal unit’
Article 3 of the Kyoto Protocol;

(RMU) means a unit

issued pursuant

to

‘temporary CER’ (tCER) is a CER issued for an afforestation
the CDM which,
or reforestation project activity under
subject to the decisions adopted pursuant to the UNFCCC or
the Kyoto Protocol, expires at the end of the commitment
period following the one during which it was issued;

‘long-term CER’ (lCER) is a CER issued for an afforestation
or reforestation project activity under
the CDM which,
subject to the decisions adopted pursuant to the UNFCCC or
the crediting
the Kyoto Protocol, expires at
period of the afforestation or reforestation project activity
under the CDM for which it was issued;

the end of

Each registry shall incorporate the hardware and software
2.
set out in Annex I, be accessible via the Internet, and conform
to the functional and technical specifications required by this
Regulation.

3.
Each registry shall be capable of executing correctly all the
processes concerning verified emissions and accounts set out in
Annex VIII, the reconciliation process set out in Annex X and
all the administrative processes set out in Annex XI by the day
after the entry into force of this Regulation.

Each registry shall be capable of executing correctly all the
processes concerning allowances and Kyoto units set out in
this
Annex IX by the day after
Regulation, with the exception of the processes with process
types 04-00, 06-00, 07-00 and 08-00.

the entry into force of

‘third country registry’ means a registry established, operated
and maintained by a country listed in Annex B to the Kyoto
Protocol which has ratified the Kyoto Protocol and is not a
Member State;

Each registry shall be capable of executing correctly the
processes concerning allowances and Kyoto units with process
types 04-00, 06-00, 07-00 and 08-00 set out in Annex IX by
31 March 2005.

‘transaction’ means the issue, transfer, acquisition, surrender,
cancellation and replacement of allowances and the issue,
transfer, acquisition, cancellation and retirement of ERUs,
CERs, AAUs and RMUs and carry-over of ERUs, CERs and
AAUs;

Article 4

Consolidated registries

(w) ‘UNFCCC

independent

the
transaction log established, operated and
the United Nations

independent
maintained by the Secretariat of
Framework Convention on Climate Change;

transaction

log’ means

(x)

(y)

a

competent,

‘verifier’ means
accredited
verification body with responsibility for performing and
reporting on the verification process, in accordance with the
detailed requirements established by the Member State
pursuant to Annex V of Directive 2003/87/EC;

independent,

‘year’ means
Greenwich Mean Time.

a

calendar

year, defined according

to

CHAPTER II

REGISTRIES AND TRANSACTION LOGS

Article 3

Registries

A Member State or the Commission may establish, operate and
maintain their registry in a consolidated manner together with
one or more other Member States or the Community, provided
that its registry remains distinct.

Article 5

The Community independent transaction log

The Community independent

transaction log shall be
1.
established by the Commission in the form of a standardised
electronic database by the day after the entry into force of this
Regulation.

The Community

2.
shall
independent
incorporate the hardware and software set out in Annex I, be
accessible via the Internet, and conform to the functional and
technical specifications required by this Regulation.

transaction

log

3.
The Central Administrator designated pursuant to Article
20 of Directive 2003/87/EC shall operate and maintain the
Community independent transaction log in accordance with the
provisions of this Regulation.

The Central Administrator shall provide the administrative
in order to facilitate the

4.
processes referred to in Annex XI
integrity of the data within the registries system.

1. A registry in the form of a standardised electronic database
shall be established by each Member State and the Commission
by the day after the entry into force of this Regulation.

5.
The Central Administrator shall only perform processes
concerning allowances, verified emissions, accounts or Kyoto
its functions as Central
units where necessary to carry out
Administrator.

29.12.2004

EN

Official Journal of the European Union

L 386/7

transaction log shall be
The Community independent
6.
capable of executing correctly all
the processes concerning
allowances, verified emissions, accounts or Kyoto units set out
in Annex VIII and Annex IX by the day after the entry into
force of this Regulation.

such a link is established, all processes concerning
After
allowances, verified emissions, accounts 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 be capable of
executing correctly the reconciliation process set out in Annex
X and the administrative processes set out in Annex XI by the
day after the entry into force of this Regulation.

Article 8

Registry administrators

Article 6

Communication link between registries and the
Community independent transaction log

1. A communication link between each registry and the
Community independent transaction log shall be established by
31 December 2004.

1.
Each Member State and the Commission shall designate a
registry administrator to operate and maintain its registry in
accordance with the provisions of this Regulation.

Member States and the Commission shall ensure that there is no
conflict of interest between the registry administrator and its
account holders or between the registry administrator and the
Central Administrator.

2.
Each Member State shall notify the Commission of the
identity and contact details of the registry administrator for its
registry by 1 September 2004 in accordance with the
initialisation procedures set out in Annex XIV.

The Central Administrator shall activate the communication link
after the testing procedures set out in Annex XIII and the
in Annex XIV have been
initialisation procedures set out
completed
registry
relevant
administrator thereof.

and notify

successfully

the

From 1 January 2005 until

2.
the communication link
referred to in Article 7 has been established, all processes
concerning allowances, verified emissions and accounts shall be
completed through the exchange of data via the Community
independent transaction log.

3.
The Commission may instruct the Central Administrator to
temporarily suspend a process referred to in Annexes VIII and
IX initiated by a registry if that process is not being executed in
accordance with Articles 32 to 37.

the Central Administrator to
The Commission may instruct
temporarily suspend the communication link between a registry
and the Community independent transaction log or to suspend
all or some of the processes referred to in Annexes VIII and IX,
if that registry is not operated and maintained in accordance
with the provisions of this Regulation.

Article 7

Communication link between the independent transaction
logs

A communication link between the Community independent
transaction log and the UNFCCC independent transaction log
shall be established promptly after the UNFCCC independent
transaction log has been established.

The Member States and the Commission shall

3.
ultimate responsibility and authority for
maintenance of their registries.

retain
the operation and

The Commission shall coordinate the implementation of
registry
requirements of
and the Central

this Regulation with the
State

each Member

4.
the
administrators of
Administrator.

CHAPTER III

CONTENTS OF THE REGISTRIES

SECTION 1

Reporting and Confidentiality

Article 9

Reporting

Each registry administrator

the
1.
information listed in Annex XVI at the frequencies and to the
recipients set out in Annex XVI in a transparent and organised
manner via his registry web site. Registry administrators shall
not release additional information held in the registry.

shall make

available

available

shall make

The Central Administrator

the
2.
information listed in Annex XVI at the frequencies and to the
recipients set out in Annex XVI in a transparent and organised
manner via the Community independent transaction log web
site. The Central Administrator shall not
release additional
information held in the Community independent transaction
log.

L 386/8

EN

Official Journal of the European Union

29.12.2004

Each web site shall allow the recipients of the reports listed

3.
in Annex XVI to query those reports using search facilities.

4.
Each registry administrator is responsible for the accuracy
of the information that originates from his registry and is made
available via the Community independent
transaction log
website.

5. Neither the Community independent transaction log nor
registries
to submit price
information concerning allowances or Kyoto units.

account holders

require

shall

Article 10

Confidentiality

1. All information, including the holdings of all accounts and
all transactions made, held in the registries and the Community
independent transaction log shall be considered confidential for
any purpose other than the implementation of the requirements
of this Regulation, Directive 2003/87/EC or national law.

2.
Information held in the registries may not be used without
to
the prior consent of
operate and maintain those registries in accordance with the
provisions of this Regulation.

the relevant account holder except

perform processes

Each competent authority and registry administrator shall
3.
only
verified
concerning
emissions, accounts or Kyoto units where necessary to carry out
their functions as competent authority or registry administrator.

allowances,

SECTION 2

Accounts

Article 11

Accounts

From 1 January 2008 and from 1 January of the first year
4.
of each subsequent five-year period, each registry shall contain
one retirement account and the cancellation and replacement
accounts required by the relevant decisions adopted pursuant to
the UNFCCC or the Kyoto Protocol for the 2008-2012 period
and for each subsequent five-year period, created in accordance
with Article 12.

5. Unless otherwise provided, all accounts shall be capable of
holding allowances and Kyoto units.

SECTION 3

Party accounts

Article 12

Creation of Party accounts

The

relevant body of

and the
1.
Commission shall submit an application to their respective
registry administrator for the creation in their registries of the
accounts referred to in Article 11(1), (3) and (4).

the Member State

The applicant shall provide the registry administrator with the
information reasonably required by the registry administrator.
That
in
Annex IV.

include the information set out

information shall

the receipt of an application in
2. Within 10 days of
accordance with paragraph 1 or
the
communication link between the registry and the Community
independent transaction log, whichever is the later, the registry
in the registry in
administrator
accordance with the account creation process
in
Annex VIII.

shall create the account

activation of

set out

the

3.
The applicant referred to in paragraph 1 shall notify its
registry administrator within 10 days of any changes in the
information provided to its registry administrator pursuant to
such a
paragraph 1. Within 10 days of
notification the
that
information in accordance with the account update process set
out in Annex VIII.

the receipt of

shall update

administrator

registry

From 1 January 2005 onwards, each registry shall contain
1.
at least one Party holding account created in accordance with
Article 12.

The registry administrator may require the applicants
4.
referred to in paragraph 1 to agree to comply with reasonable
terms and conditions addressing the issues set out in Annex V.

From 1 January 2005 onwards, each Member State registry
2.
shall contain one operator holding account for each installation
created in accordance with Article 15 and each registry shall
contain at least one person holding account for each person
created in accordance with Article 19.

Article 13

Closure of Party accounts

3.
From 1 January 2005 onwards, each registry shall contain
one retirement account and one cancellation account for the
2005-2007 period and one cancellation account for the 2008-
2012 period, created in accordance with Article 12.

Within 10 days of
the receipt of an application from the
relevant body of a Member State or from the Commission to
close a Party holding account,
its registry administrator shall
in accordance with the account closure
close the account
process set out in Annex VIII.

29.12.2004

EN

Official Journal of the European Union

L 386/9

Article 14

Notification

Article 17

Closure of operator holding accounts

The registry administrator shall immediately notify the account
holder of the creation or update of his Party accounts and of
the closure of his Party holding accounts.

SECTION 4

Operator holding accounts

Article 15

Creation of operator holding accounts

1. Within 14 days of
the issue of each greenhouse gas
emissions permit to the operator of an installation where the
installation has not previously been covered by such a permit or
the activation of the communication link between the registry
and the Community independent transaction log, whichever is
the later, the competent authority, or the operator where the
competent authority so requires, shall provide the registry
administrator of the Member State registry with the information
set out in Annex III.

registry

the receipt of

the activation of
and

the information in
2. Within 10 days of
the communication link
paragraph 1 or
between the
independent
transaction log, whichever is the later, the registry administrator
shall create an operator holding account referred to in Article
11(2) for each installation in its registry in accordance with the
account creation process set out in Annex VIII.

the Community

the operator where the
3.
The competent authority, or
competent authority so requires,
shall notify the registry
administrator within 10 days of any changes in the information
provided to the registry administrator pursuant to paragraph 1.
Within 10 days of the receipt of such a notification the registry
administrator shall update the operator’s details in accordance
with the account update process set out in Annex VIII.

4.
The registry administrator may require operators to agree
to comply with reasonable terms and conditions addressing the
issues set out in Annex V.

Article 16

Holding of Kyoto units in operator holding accounts

An operator holding account shall be capable of holding Kyoto
units where authorised by Member State or Community
legislation.

the

The

authority

competent

shall notify

1.
registry
administrator within 10 days of a greenhouse gas emissions
permit being revoked or surrendered for an installation that is,
as a result, not covered by any such permit. Without prejudice
to paragraph 2, the registry administrator shall close all operator
holding accounts relating to that revocation or surrender in
accordance with the account closure process set out in Annex
VIII on 30 June the year after the revocation or surrender took
place if the relevant installation’s entry in the latest year of the
compliance status table is greater than or equal to zero. If the
relevant installation’s entry in the latest year of the compliance
status table is less than zero, the registry administrator shall
close its account the day after the entry is greater than or equal
to zero or the day after the competent authority has instructed
the registry administrator to close the account because there is
no reasonable prospect of further allowances being surrendered
by the installation’s operator.

in accordance with paragraph 1,

2.
If there is a positive balance of allowances or Kyoto units in
an operator holding account which the registry administrator is
to close
registry
administrator shall first request the operator to specify another
account within the registry system to which such allowances or
Kyoto units shall then be transferred. If the operator has not
responded to the registry administrator’s request within 60 days,
the registry administrator shall transfer the balance to the Party
holding account.

the

Article 18

Notification

The registry administrator shall immediately notify the account
holder of the creation, update or closure of his operator holding
account.

SECTION 5

Person holding accounts

Article 19

Creation of person holding accounts

1. An application for the creation of a person holding account
shall be submitted to the registry administrator of the registry
concerned.

The applicant shall provide the registry administrator with the
information reasonably required by the registry administrator.
in
That
Annex IV.

include the information set out

information shall

L 386/10

EN

Official Journal of the European Union

29.12.2004

the receipt of an application in
2. Within 10 days of
accordance with paragraph 1 or
the
communication link between the registry and the Community
independent transaction log, whichever is the later, the registry
administrator shall create a person holding account
in its
registry in accordance with the account creation process set out
in Annex VIII.

activation of

the

The registry administrator shall not establish more than 99
person holding accounts in any one person’s name in its
registry.

3.
The applicant shall notify the registry administrator within
10 days of any changes in the information provided to the
registry administrator pursuant to paragraph 1. Within 10 days
of the receipt of such a notification the registry administrator
shall update the person’s details in accordance with the account
update process set out in Annex VIII.

4.
The registry administrator may require the applicants
referred to in paragraph 1 to agree to comply with reasonable
terms and conditions addressing the issues set out in Annex V.

Article 20

Holding of Kyoto units in person holding accounts

A person holding account shall be capable of holding Kyoto
units where authorised by Member State or Community
legislation.

Article 21

Closure of person holding accounts

1. Within 10 days of the receipt of an application from a
registry
person to close a person holding account,
administrator shall close the account in accordance with the
account closure process set out in Annex VIII.

the

If a person holding account has a zero balance and no
2.
transactions have been recorded during a period of 12 months,
the registry administrator shall notify the account holder that
the person holding account shall be closed within 60 days
unless the registry administrator receives within that period a
the person holding
request
account be maintained. If the registry administrator does not
receive any such request from the account holder, it shall close
the account in accordance with the account closure process set
out in Annex VIII.

from the account holder

that

Article 22

Notification

Article 23

Authorised representatives

Each account holder

shall appoint a primary and a
1.
secondary authorised representative for each account created in
accordance with Articles 12, 15 and 19. Requests to the registry
administrator to carry out processes shall be submitted by an
authorised representative on behalf of the account holder.

2.
Each Member State and the Commission may allow
account holders in its registry to nominate an additional
authorised representative whose agreement
required in
secondary
addition to the agreement of
authorised representative to submit a request to their registry
administrator
the processes
to carry out one or more of
pursuant to Articles 49(1), 52, 53 and 62.

the primary or

is

shall

Each verifier

authorised
3.
least one
representative to enter or approve the entry of
the annual
verified emissions for an installation into the verified emissions
table in accordance with Article 51(1).

appoint

at

4.
Each registry administrator and the Central Administrator
shall appoint at least one authorised representative to operate
and maintain their registry and the Community independent
transaction log on behalf of that administrator.

SECTION 6

Tables

Article 24

Tables

1.
From 1 January 2005 onwards, each Member State registry
shall contain one verified emissions table, one surrendered
allowances table, and one compliance status table.

Each registry may contain additional tables for other purposes.

2.
The Community independent transaction log shall contain
one national allocation plan table for each Member State for the
the 2008-2012 period and for each
2005-2007 period,
subsequent five-year period.

The Community independent
additional tables for other purposes.

transaction log may contain

3.
The tables in each Member State registry shall contain the
information set out in Annex II. The operator holding accounts
and person holding accounts shall contain the information set
out in Annex XVI.

The registry administrator shall immediately notify each account
holder of the creation, update or closure of his person holding
account.

allocation plan table

The national
in the Community
independent transaction log shall contain the information set
out in Annex XIV.

29.12.2004

EN

Official Journal of the European Union

L 386/11

SECTION 7

Codes and identifiers

Article 25

Codes

SECTION 2

Automated checks and the data reconciliation process

Article 28

Each registry shall contain the input codes set out in Annex VII
and the response codes set out in Annex XII in order to ensure
the correct interpretation of information exchanged during each
process.

Article 26

Account identification codes and alphanumeric identifiers

Detection of discrepancies by the Community independent
transaction log

The Central Administrator shall ensure that the Community
1.
independent transaction log conducts the automated checks set
out in Annex VIII, Annex IX and Annex XI for all processes
concerning allowances, verified emissions, accounts and Kyoto
units to ensure that there are no discrepancies.

Before creating an account the registry administrator shall assign
to each account a unique account identification code and the
alphanumeric identifier specified by the account holder as part
of the information given under Annexes III and IV respectively.
Before creating an account, the registry administrator shall also
assign to the
account holder
identification code comprising the elements set out in Annex
VI.

account holder

a unique

CHAPTER IV

CHECKS AND PROCESSES

SECTION 1

Blocking of accounts

Article 27

Blocking of operator holding accounts

If, on 1 April of each year starting in 2006, an installation’s
1.
annual verified emissions for the preceding year have not been
entered into the verified emissions table in accordance with the
verified emissions entry process set out
the
registry administrator shall block the transfer of any allowances
out of the operator holding account for that installation.

in Annex VIII,

2. When the installation’s annual verified emissions for the
year referred to in paragraph 1 have been entered into the
verified emissions table, the registry administrator shall unblock
the account.

The registry administrator shall

3.
immediately notify the
relevant account holder and the competent authority of the
blocking and unblocking of each operator holding account.

4.
Paragraph 1 shall not apply to the surrender of allowances
pursuant to Article 52 or the cancellation and replacement of
allowances pursuant to Articles 60 and 61.

2.
If the automated checks referred to in paragraph 1 identify
a discrepancy in a process under Annex VIII, Annex IX and
Annex XI, the Central Administrator shall immediately inform
the registry administrator or administrators concerned by
returning an automated response detailing the exact nature of
the discrepancy using the response codes set out in Annex VIII,
Annex IX and Annex XI. Upon receiving such a response code
the registry
for a process under Annex VIII or Annex IX,
administrator of
terminate that
the initiating registry shall
process and inform the Community independent transaction
log. The Central Administrator shall not update the information
contained in the Community independent transaction log. The
shall
registry
immediately inform the relevant account holders
the
process has been terminated.

administrator or

administrators

concerned

that

Article 29

Detection of inconsistencies by the Community
independent transaction log

The Central Administrator shall ensure that the Community
1.
the data
transaction log periodically initiates
independent
reconciliation process set out in Annex X. For that purpose the
Community independent
record all
processes concerning allowances, accounts and Kyoto units.

transaction log shall

Through that process, the Community independent transaction
log shall check that the holdings of Kyoto units and allowances
in each account in a registry are identical to the records held in
the Community independent transaction log.

If

If

is

an

during

detected

inconsistency
process,

the
the Central Administrator

data
2.
reconciliation
shall
immediately inform the registry administrator or administrators
concerned.
the Central
the inconsistency is not resolved,
Administrator shall ensure that the Community independent
transaction log does not allow any further process under Annex
VIII and Annex IX concerning any of the allowances, accounts
or Kyoto units which are the subject of the earlier inconsistency
to proceed.

L 386/12

EN

Official Journal of the European Union

29.12.2004

Article 30

Detection of discrepancies and inconsistencies by the
UNFCCC independent transaction log

each process referred to in Annex IX a unique transaction
identification code. Each such identification code shall comprise
the elements set out in Annex VI.

registry

informs

If the UNFCCC independent transaction log, following an
1.
automated check,
administrator or
the
administrators concerned of a discrepancy in a process, the
registry administrator of the initiating registry shall terminate
the process and inform the UNFCCC independent transaction
log thereof. The
administrators
concerned shall
immediately inform the relevant account
holders that the process has been terminated.

registry administrator or

2.
If the UNFCCC independent transaction log has detected an
inconsistency, the Central Administrator shall ensure that the
Community independent transaction log does not allow any
further process under Annex VIII and Annex IX concerning any
the earlier
of
inconsistency, and which is not
to the UNFCCC
independent transaction log’s automated checks, to proceed.

the Kyoto units which are the subject of

subject

Article 31

Registry automated checks

conducted within the

Prior to and during the execution of all processes the registry
administrator shall ensure that appropriate automated checks
to detect
are
discrepancies and thereby terminate processes in advance of
the Community
automated checks being
independent
independent
transaction
transaction log.

conducted by
log

or UNFCCC

in order

registry,

Article 34

Finalisation of processes concerning accounts and verified
emissions

All processes referred to in Annex VIII shall be final when both
independent transaction logs successfully inform the initiating
registry that they have not detected any discrepancies in the
proposal sent by the initiating registry.

to the communication link between the
However, prior
transaction log and the UNFCCC
Community independent
independent
transaction log being established, all processes
referred to in Annex VIII shall be final when the Community
independent transaction log successfully informs the initiating
registry that
it has not detected any discrepancies in the
proposal sent by the initiating registry.

Article 35

SECTION 3

Execution and finalisation of processes

Finalisation of processes concerning transactions within
registries

Article 32

Processes

Each process shall follow the complete sequence for message
exchanges for that type of process as set out in Annex VIII,
Annex IX, Annex X and Annex XI. Each message shall conform
to the format and informational requirements described using
web services description language as elaborated pursuant to the
UNFCCC or the Kyoto Protocol.

Article 33

Identification codes

The registry administrator shall assign to each process referred
to in Annex VIII a unique correlation identification code and to

the external
All processes referred to in Annex IX, except
transfer process,
final when both independent
shall be
transaction logs inform the initiating registry that they have not
detected any discrepancies in the proposal sent by the initiating
registry and the
successfully sent
initiating registry has
confirmation to both independent transaction logs that it has
updated its records in accordance with its proposal.

to the communication link between the
However, prior
transaction log and the UNFCCC
Community independent
independent
transaction log being established, all processes
referred to in Annex IX, except the external transfer process,
shall be final when the Community independent transaction log
informs the initiating registry that
it has not detected any
discrepancies in the proposal sent by the initiating registry and
the initiating registry has successfully sent confirmation to the
Community independent transaction log that it has updated its
records in accordance with its proposal.

29.12.2004

EN

Official Journal of the European Union

L 386/13

Article 36

Finalisation of the external transfer process

allocation plan table

into the Community
the national
independent transaction log in accordance with the initialisation
procedures set out in Annex XIV.

external

shall be

transfer process

The
final when both
independent transaction logs inform the acquiring registry that
they have not detected any discrepancies in the proposal sent by
the initiating registry and the acquiring registry has successfully
sent confirmation to both independent transaction logs that it
has updated its
in accordance with the initiating
registry’s proposal.

records

shall

process

transaction log being established,

communication link between the
to the
However, prior
transaction log and the UNFCCC
Community independent
the external
independent
transfer
final when the Community
independent transaction log informs the acquiring registry that
it has not detected any discrepancies in the proposal sent by the
initiating registry and the acquiring registry has successfully sent
confirmation to the Community independent transaction log
that it has updated its records in accordance with the initiating
registry’s proposal.

be

Article 37

Finalisation of the reconciliation process

The reconciliation process referred to in Annex X shall be final
when all inconsistencies between the information contained in a
registry and the information contained in the Community
independent transaction log for a specific time and date have
been resolved,
reconciliation process has been
successfully re-initiated and completed for that registry.

and the

CHAPTER V

TRANSACTIONS

SECTION 1

instruct

2. A Member State shall notify each correction to its national
allocation plan together with each corresponding correction in
its national allocation plan table to the Commission.
If the
correction to the national allocation plan table is based upon
the national allocation plan notified to the Commission which
was not rejected under Article 9(3) of Directive 2003/87/EC or
on which the Commission has accepted amendments and that
correction is in accordance with methodologies set out in that
national allocation plan or results from improvements in data,
the Central Administrator to
the Commission shall
enter the corresponding correction into the national allocation
plan table held in the Community independent transaction log
in accordance with the initialisation procedures set out
in
Annex XIV. In all other cases, the Member State shall notify the
correction to its national allocation plan to the Commission and
if the Commission does not reject this correction in accordance
with the procedure in Article 9(3) of Directive 2003/87/EC, the
Commission shall
instruct the Central Administrator to enter
the corresponding correction into the national allocation plan
transaction log
table held in the Community independent
in accordance with the initialisation procedures set out
in
Annex XIV.

The

shall,

registry

subsequent

administrator

3.
to any
correction made pursuant to paragraph 2 which occurs after
allowances have been issued under Article 39 and which
reduces the total quantity of allowances issued under Article 39
for the 2005-2007 period, transfer the number of allowances
specified by the competent authority from the holding accounts
referred to in Article 11(1) and (2) in which the allowances are
held to the cancellation account for the 2005-2007 period.

correction shall

The
correction to allowances process set out in Annex IX.

take place

in accordance with the

Article 39

Issue of allowances

Allocation and issue of allowances for the 2005-2007 period

Article 38

National allocation plan table for the 2005-2007 period

1.
By 1 October 2004, each Member State shall notify to the
Commission its national allocation plan table, corresponding to
the decision taken under Article 11 of Directive 2003/87/EC. If
the national allocation plan table is based upon the national
allocation plan notified to the Commission which was not
rejected under Article 9(3) of Directive 2003/87/EC or on which
the
the Commission has accepted proposed amendments,
instruct the Central Administrator to enter
Commission shall

After the national allocation plan table has been entered into
the Community independent transaction log and, subject to
Article 38(2), by 28 February 2005, the registry administrator
shall
in the
issue the total quantity of allowances set out
national allocation plan table into the Party holding account.

When issuing such allowances the registry administrator shall
identification code to each allowance
assign a unique unit
comprising the elements set out in Annex VI.

Allowances shall be issued in accordance with the allowance
issue (2005-2007) process set out in Annex IX.

L 386/14

EN

Official Journal of the European Union

29.12.2004

Article 40

Article 43

Allocation of allowances to operators

Issue of force majeure allowances

Without prejudice to Articles 38(2) and 41, by 28 February
2005 and by 28 February of each year thereafter for the 2005-
2007 period, the registry administrator shall transfer from the
Party holding account to the relevant operator holding account
the proportion of the total quantity of allowances issued under
Article 39 which has been allocated to the corresponding
installation for that year in accordance with the relevant section
of the national allocation plan table.

Where foreseen for an installation in the national allocation
plan of
the registry administrator may
transfer that proportion at a later date of each year.

the Member State,

Allowances shall be allocated in accordance with the allowance
allocation process set out in Annex IX.

If

instructed to do so by the competent authority,

the
1.
registry administrator shall issue into the Party holding account
the number of
force majeure allowances authorised by the
Commission for the 2005-2007 period pursuant to Article 29
of Directive 2003/87/EC.

Force majeure allowances shall be issued in accordance with the
force majeure allowance issue process set out in Annex IX.

2.
The registry administrator shall enter the number of issued
force majeure allowances into the sections of the surrendered
allowance table designated for those installations and years for
which authorisation was given.

3. When issuing force majeure
registry
administrator shall assign a unique unit identification code to
each such force majeure allowance comprising the elements set
out in Annex VI.

allowances

the

Article 41

SECTION 2

Surrender of allowances on instruction of the competent
authority

If instructed to do so by the competent authority pursuant to
Article 16(1) of Directive 2003/87/EC, the registry administrator
shall surrender part or all of
the total
quantity of allowances issued under Article 39 which has been
allocated to an installation for a specific year, by entering the
number of surrendered allowances into the section of
the
surrendered allowance table designated for that installation for
that year. These surrendered allowances shall remain in the
Party holding account.

the proportion of

surrendered on instruction of

Allowances
competent
authority shall be surrendered in accordance with the allowance
allocation process set out in Annex IX.

the

Article 42

Allocation of allowances to new entrants

If instructed to do so by the competent authority, the registry
administrator shall transfer a proportion of the total quantity of
allowances issued under Article 39 that are remaining in the
Party holding account to the operator holding account of a new
entrant.

Allowances shall be transferred in accordance with the internal
transfer process set out in Annex IX.

Allocation and issue of allowances for the 2008-2012 period
and each subsequent five year period

Article 44

National allocation plan table for the 2008-2012 period and
each subsequent five year period

1.
By 1 January 2007 and by 1 January 12 months before the
start of each subsequent five year period, each Member State
shall notify to the Commission its national allocation plan table,
corresponding to the decision taken under Article 11 of
Directive 2003/87/EC. If the national allocation plan table is
based upon the national allocation plan notified to the
Commission which was not rejected under Article 9(3) of
Directive 2003/87/EC or on which the Commission has
accepted proposed amendments, the Commission shall instruct
the Central Administrator to enter the national allocation plan
transaction log
table
in accordance with the initialisation procedures set out
in
Annex XIV.

into the Community

independent

If

2. A Member State shall notify each correction to its national
allocation plan together with each corresponding correction in
its national allocation plan table to the Commission.
the
correction to the national allocation plan table is based upon
the national allocation plan notified to the Commission which
was not rejected under Article 9(3) of Directive 2003/87/EC or
on which the Commission has accepted amendments and that
correction results from improvements in data, the Commission
shall
the
the Central Administrator
corresponding correction into the national allocation plan table
transaction log in
held in the Community independent
accordance with the initialisation procedures as set out
in
Annex XIV. In all other cases, the Member State shall notify the
correction to its national allocation plan to the Commission and

to enter

instruct

29.12.2004

EN

Official Journal of the European Union

L 386/15

if the Commission does not reject this correction in accordance
with the procedure in Article 9(3) of Directive 2003/87/EC, the
Commission shall
instruct the Central Administrator to enter
the corresponding correction into the national allocation plan
table held in the Community independent transaction log in
accordance with the initialisation procedures set out in Annex
XIV.

Where foreseen for an installation in the national allocation
plan of
the registry administrator may
transfer that proportion at a later date of each year.

the Member State,

Allowances shall be allocated in accordance with the allowance
allocation process set out in Annex IX.

The

shall,

registry

subsequent

administrator

to any
3.
correction made pursuant to paragraph 2 which occurs after
allowances have been issued under Article 45 and which
reduces the total quantity of allowances issued under Article 45
for
five-year periods,
convert the number of allowances specified by the competent
authority into AAUs by removing the allowance element from
the unique unit
each such AAU
identification code of
comprising the elements set out in Annex VI.

the 2008-2012 period or subsequent

correction shall

The
correction to allowances process set out in Annex IX.

take place

in accordance with the

Article 45

Issue of allowances

After the national allocation plan table has been entered into
the Community independent transaction log and, subject to
Article 44(2), by 28 February of the first year of the 2008-2012
period and by 28 February of the first year of each subsequent
five-year period, the registry administrator shall issue the total
quantity of allowances set out in the national allocation plan
table into the Party holding account by converting an equal
quantity of AAUs held in that holding account into allowances.

This conversion shall take place through adding the allowance
element to the unique unit identification code of each such
AAU, comprising the elements set out in Annex VI.

The issue of allowances for the 2008-2012 period and each
subsequent five-year period shall take place in accordance with
the allowance issue (2008-2012 onwards) process set out in
Annex IX.

Article 46

Allocation of allowances to operators

Article 47

Surrender of allowances on instruction of the competent
authority

If instructed to do so by the competent authority pursuant to
Article 16(1) of Directive 2003/87/EC, the registry administrator
the total
shall surrender part or all of
quantity of allowances issued under Article 45 which has been
allocated to an installation for a specific year, by entering the
number of surrendered allowances into the section of
the
surrendered allowance table designated for that installation for
that year. These surrendered allowances shall remain in the
Party holding account.

the proportion of

surrendered on instruction of

competent
Allowances
authority shall be surrendered in accordance with the allowance
allocation process set out in Annex IX.

the

Article 48

Allocation of allowances to new entrants

If instructed to do so by the competent authority, the registry
administrator shall transfer a proportion of the total quantity of
allowances issued under Article 45 that are remaining in the
Party holding account to the operator holding account of a new
entrant.

Allowances shall be transferred in accordance with the internal
transfer process set out in Annex IX.

SECTION 3

Transfers and eligibility

Article 49

Without prejudice to Articles 44(2) and 47, by 28 February
2008 and by 28 February in each year thereafter, the registry
administrator shall transfer from the Party holding account to
the relevant operator holding account the proportion of the
total quantity of allowances issued under Article 45 which has
been allocated to the corresponding installation for that year in
accordance with the relevant section of the national allocation
plan table.

Transfers of allowances and Kyoto units by account
holders

The registry administrator shall carry out any transfer

1.
between holding accounts referred to in Article 11(1) and (2):

L 386/16

EN

Official Journal of the European Union

29.12.2004

(a) within its registry as requested by an account holder in
accordance with the internal transfer process set out in
Annex IX;

(b) between registries as requested by an account holder for
allowances issued for the 2005-2007 period in accordance
with the external transfer (2005-2007) process set out in
Annex IX; and

(c) between registries as requested by an account holder for
allowances issued for the 2008-2012 period and subsequent
five-year periods and Kyoto units in accordance with the
external transfer (2008-2012 onwards) process set out in
Annex IX.

2. Allowances may only be transferred from an account in a
registry to an account in a third country registry or the CDM
Registry, or acquired from an account in a third country registry
or the CDM Registry by an account in a registry, where an
agreement has been concluded in accordance with Article 25(1)
of Directive 2003/87/EC and such transfers are in accordance
with any provisions relating to the mutual
recognition of
allowances under that agreement drawn up by the Commission
pursuant to Article 25(2) of Directive 2003/87/EC.

Article 50

Eligibility and the commitment period reserve

1. A Member State may not
transfer or acquire ERUs or
AAUs, or use CERs, until 16 months have elapsed since the
submission of
its report in accordance with Article 7(1) of
Decision 280/2004/EC, unless the Secretariat to the UNFCCC
has informed that Member State that compliance procedures
will not be commenced.

to Article 8 of Decision No 280/2004/EC,

Pursuant
the
Secretariat to the UNFCCC informs a Member State that it does
not meet the requirements allowing it to transfer or acquire
ERUs or AAUs, or use CERs, the relevant body of the Member
State shall
to initiate
instruct the registry administrator not
those transactions requiring such eligibility.

if

2. When,
from 1 January 2008 onwards, the holdings of
ERUs, CERs, AAUs and RMUs valid for the relevant five-year
period in the Party holding accounts, operator holding accounts,
person holding accounts and retirement accounts in a Member
State approach a breach of the commitment period reserve,
calculated as 90 % of the Member State’s assigned amount or
five times its most recently reviewed inventory,
100 % of
the Commission shall notify that
is the lowest,
whichever
Member State.

SECTION 4

Verified emissions

Article 51

Verified emissions of an installation

1. Upon the verification as satisfactory, in accordance with the
detailed requirements established by the Member State pursuant
to Annex V of Directive 2003/87/EC, of an operator’s report on
the emissions from an installation during a previous year, the
verifier shall enter or approve the entry of the annual verified
emissions for that installation for that year into the section of
the verified emissions table designated for that installation for
that year in accordance with the verified emissions update
process set out under Annex VIII.

the

The

instruct

competent

2.
registry
authority may
administrator to correct the annual verified emissions for an
installation for a previous year, to ensure compliance with the
detailed requirements established by the Member State pursuant
to Annex V of Directive 2003/87/EC, by entering the corrected
annual verified emissions for that installation for that year into
the section of the verified emissions table designated for that
installation for
in accordance with the verified
emissions update process set out under Annex VIII.

that year

SECTION 5

Surrender of allowances

Article 52

Surrender of allowances

An operator shall surrender allowances for an installation by
requesting or, where provided in Member State legislation, be
deemed to have requested, the registry administrator to:

(a)

transfer a specified number of allowances for a specified
year from the relevant operator holding account into the
Party holding account of that registry;

(b) enter the number of transferred allowances into the section
that
the surrendered allowance table designated for

of
installation for that year.

The transfer and entry shall take place in accordance with the
allowance surrender process set out under Annex IX.

29.12.2004

EN

Official Journal of the European Union

L 386/17

Article 53

Article 56

The use of CERs and ERUs

Entries into the compliance status table

The use of CERs and ERUs by an operator in accordance with
Article 11a of Directive 2003/87/EC in respect of an installation
shall take place through an operator requesting the registry
administrator to:

The registry administrator shall enter

the installation’s
1.
compliance status figure calculated in accordance with Article
55 for each year into the section of the compliance status table
designated for that installation.

(a)

transfer a specified number of CERs or ERUs for a specified
year from the relevant operator holding account into the
Party holding account of that registry;

(b) enter the number of transferred CERs and ERUs into the
section of the surrendered allowance table designated for
that installation for that year.

From 1 January 2008 onwards, the registry administrator shall
only accept requests to use CERs and ERUs up to a percentage
of the allocation made to each installation, as specified by that
administrator’s Member State in its national allocation plan for
that period.

The transfer and entry shall take place in accordance with the
allowance surrender process set out under Annex IX.

Article 54

Surrender of force majeure allowances

The issue of
force majeure allowances in accordance with
Article 43 shall constitute the surrender of those force majeure
allowances.

Article 55

Calculation of compliance status figures

Upon an entry being made into the section of the surrendered
allowance table or verified emissions table designated for an
installation, the registry administrator shall:

(a) during the years 2005, 2006 and 2007 determine the
compliance status figure for that installation and for each
year by calculating the sum of all allowances surrendered
from the year 2005 up to and including the current year
minus the sum of all verified emissions from the year 2005
up to and including the current year;

(b) during the year 2008 and each year thereafter determine the
compliance status figure for that installation and for each
year by calculating the sum of all allowances surrendered
from the year 2008 up to and including the current year
minus the sum of all verified emissions from the year 2008
up to and including the current year, plus a correction
factor. The correction factor shall be zero if the 2007 figure
was greater than zero, but shall remain as the 2007 figure if
the 2007 figure is less than or equal to zero.

2. On 1 May 2006 and on 1 May of each year thereafter the
registry administrator shall notify the compliance status table to
the competent authority. In addition, the registry administrator
shall notify any changes to the entries for previous years of the
compliance status table to the competent authority.

Article 57

Entries into the verified emissions table

Where, on 1 May 2006 and on 1 May of each year thereafter,
no verified emissions figure has been entered into the verified
emissions table for an installation for a previous year, any
substitute emissions figure determined pursuant to Article 16(1)
of Directive 2003/87/EC which has not been calculated in
accordance with the detailed requirements established by the
Member State pursuant to Annex V of Directive 2003/87/EC
shall not be entered into the verified emissions table.

SECTION 6

Cancellation and retirement

Article 58

Cancellation and retirement of surrendered allowances and
force majeure allowances for the 2005-2007 period

On 30 June 2006, 2007 and 2008 the registry administrator
shall cancel a number of allowances, CERs, and force majeure
allowances held in the Party holding account pursuant
to
Articles 52, 53 and 54. The number of allowances, CERs, and
force majeure allowances to be cancelled shall be equal to the
total number of
entered in the
surrendered allowances
surrendered allowance table for the periods 1 January 2005 to
30 June 2006, 30 June 2006 to 30 June 2007, and 30 June
2007 to 30 June 2008.

Cancellation shall take place by transferring CERs, with the
exception of CERs resulting from projects referred to in Article
11a(3) of Directive 2003/87/EC, from the Party holding account
into the cancellation account for the 2008-2012 period, and by
transferring allowances and force majeure allowances from the
Party holding account to the retirement account for the 2005-
in accordance with the retirement (2005-2007)
2007 period,
process set out in Annex IX.

L 386/18

EN

Official Journal of the European Union

29.12.2004

Article 59

(b)

Cancellation and retirement of surrendered allowances for
the 2008-2012 period and subsequent periods

On 30 June 2009 and on 30 June of each year thereafter, the
registry administrator shall cancel allowances surrendered for
the 2008-2012 period and each subsequent five year period, in
accordance with the retirement (2008-2012 onwards) process
set out in Annex IX, by:

(a) converting a number of allowances issued for that five-year
period and held in the Party holding account, equal to the
total number of allowances surrendered pursuant to Article
52 as entered in the surrendered allowance table since
1 January 2008 on 30 June 2009 and since 30 June of the
preceding year on 30 June of the subsequent years,
into
AAUs by removing the allowance element from the unique
unit identification code of each such AAU comprising the
elements set out in Annex VI; and

(b) transferring a number of Kyoto units of the type specified
by the competent authority, with the exception of Kyoto
units resulting from projects referred to in Article 11a(3) of
Directive 2003/87/EC,
total number of
allowances surrendered pursuant to Articles 52 and 53 as
entered in the surrendered allowance table since 1 January
2008 on 30 June 2009 and since 30 June of the preceding
year on 30 June of the subsequent years, from the Party
holding account to the retirement account for the relevant
period.

to the

equal

SECTION 7

Cancellation and replacement

Article 60

Cancellation and replacement of allowances issued for the
2005-2007 period

On 1 May 2008, each registry administrator shall cancel and, if
replace
instructed to do so by the competent authority,
allowances held in his registry in accordance with the allowance
cancellation and replacement process set out in Annex IX by:

allowances

replacement

if instructed to do so by the competent authority, issuing a
number of
the
competent authority by converting an equal number of
AAUs issued for the 2008-2012 period held in the Party
holding account into allowances by adding the allowance
element to the unique unit identification code of each such
AAU comprising the elements set out in Annex VI;

specified by

(c)

transferring any such replacement allowances referred to in
(b) from the Party holding account into the operator and
person holding accounts
competent
authority from which allowances were transferred under
point (a).

specified by the

Article 61

Cancellation and replacement of allowances issued for the
2008-2012 period and subsequent periods

On 1 May in 2013 and on 1 May in the first year of each
subsequent five year period, each registry administrator shall
cancel and replace allowances held in its registry in accordance
with the allowance cancellation and replacement process set out
in Annex IX by:

(a)

transferring all allowances issued for the preceding five-year
period from their operator and person holding accounts to
the Party holding account;

(b) converting a number of allowances, equal to the number of
allowances issued for the preceding five-year period minus
the number of allowances surrendered pursuant to Article
into AAUs by
52 since 30 June of
removing the allowance element
from the unique unit
identification code of each such AAU comprising the
elements set out in Annex VI;

the preceding year,

(c)

issuing an equal number of replacement allowances by
converting AAUs issued for the current period held in the
Party holding account
into allowances by adding the
allowance element to the unique unit identification code of
each such AAU comprising the elements set out in Annex
VI;

(a)

transferring a number of allowances, equal to the number of
allowances issued for the 2005-2007 period minus the
number of allowances surrendered pursuant to Articles 52
and 54 since 30 June of the preceding year, from their
holding accounts referred to in Article 11(1) and (2) to the
cancellation account for the 2005-2007 period;

(d) transferring a number of

those allowances issued under
point (c) for the current period from the Party holding
account into each operator and person holding account
from which allowances were transferred under point (a),
equal to the number of allowances that were transferred
from those accounts under point (a).

29.12.2004

EN

Official Journal of the European Union

L 386/19

SECTION 8

CHAPTER VI

Voluntary cancellation and retirement

SECURITY STANDARDS, AUTHENTICATION
AND ACCESS RIGHTS

Article 62

Voluntary cancellation of allowances and Kyoto units

1.
The registry administrator shall carry out any request from
an account holder pursuant to Article 12(4) of Directive 2003/
87/EC to voluntarily cancel allowances or Kyoto units held in
any of his holding accounts. The voluntary cancellation of
allowances and Kyoto units shall take place in accordance with
paragraphs 2 and 3.

Article 64

Security standards

Each registry shall comply with the security standards set

1.
out in Annex XV.

The Community independent transaction log shall comply

2.
with the security standards set out in Annex XV.

issued for

For allowances

2.
the 2005-2007 period the
registry administrator shall transfer the number of allowances
specified by the account holder
to the
cancellation account for the 2005-2007 period in accordance
with the allowance cancellation (2005-2007) process set out in
Annex IX.

from his account

and

subsequent

For Kyoto units and allowances issued for the 2008-2012
3.
five-year
registry
period
administrator shall
the number of Kyoto units or
allowances specified by the account holder from his account to
the appropriate cancellation account for the 2008-2012 period
and subsequent
in accordance with the
cancellation (2008-2012 onwards) process set out Annex IX.

five-year periods

transfer

periods

the

4. Allowances or Kyoto units held in a cancellation account
may not be transferred to any other account in the registries
system or to any account in the CDM registry or in a third
country registry.

Article 63

Article 65

Authentication

The Member States and the Community shall use the digital
certificates issued by the Secretariat to the UNFCCC, or an entity
designated by it,
registries and the
to authenticate their
Community independent
transaction log to the UNFCCC
independent transaction log.

However, from 1 January 2005 until the communication link
between the Community independent
transaction log and
UNFCCC independent transaction log is established, the identity
of each registry and the Community independent transaction
log shall be
and
authenticated using digital
usernames and passwords as specified in Annex XV. The
Commission, or an entity designated by it, shall act as the
certification authority for all digital certificates and shall
distribute the usernames and passwords.

certificates

Retirement of Kyoto units

Article 66

1.
If instructed by the relevant body of the Member State, the
registry administrator shall transfer any quantity and types of
Kyoto units specified by that body which have not already been
retired pursuant to Article 59 from the Party holding account to
the appropriate retirement account in his registry in accordance
with the retirement (2008-2012 onwards) process set out in
Annex IX.

2. An operator or person shall not be able to transfer
allowances from his operator or person holding account into a
retirement account.

3. Kyoto units held in a retirement account may not be
transferred to any other account in the registries system or to
any account in the CDM registry or in a third country registry.

Access to registries

1. An authorised representative shall only have access to the
accounts within a registry which he is authorised to access or be
able to request the initiation of processes which he is authorised
to request pursuant to Article 23. This access or these requests
shall take place through a secure area of the website for that
registry.

shall

issue

registry

administrator

The
authorised
representative with a username and password to permit the
to which he is
to accounts or processes
level of access
authorised. Registry
additional
apply
administrators may
security requirements at their discretion if they are compatible
with the provisions of this Regulation.

each

L 386/20

EN

Official Journal of the European Union

29.12.2004

The registry administrator may assume that a user who has
2.
entered a matching username and password is the authorised
representative registered under that username and password,
until such point that the authorised representative informs the
registry administrator that the security of his password has been
registry
a
compromised and requests
administrator shall promptly issue such replacement passwords.

replacement. The

The registry administrator shall ensure that the secure area
3.
of the registry website is accessible to any computer using a
widely available Internet browser. Communications between the
authorised representatives and the secure area of the registry
website shall be encrypted in accordance with the security
standards in Annex XV.

The registry administrator shall take all necessary steps to
the

4.
ensure that unauthorised access to the secure area of
registry website does not occur.

CHAPTER VII

AVAILABILITY AND RELIABILITY OF INFORMATION

Article 68

Availability and reliability of registries and the Community
independent transaction log

The Central Administrator and each registry administrator shall
take all reasonable steps to ensure that:

(a)

the registry is available for access by account holders 24
hours a day, 7 days a week, and that the communication
link between the registry and the Community independent
transaction log is maintained 24 hours a day, 7 days a week,
thereby providing backup hardware and software in the
event of a breakdown in operations of
the primary
hardware and software;

Article 67

(b) the registry and the Community independent transaction
log respond promptly to requests made by account holders.

Suspension of access to accounts

1.
The Central Administrator and each registry administrator
may only suspend an authorised representative’s password to
any accounts or processes to which he would otherwise have
access if the authorised representative has, or that administrator
has reasonable grounds to believe the authorised representative
has:

(a) attempted to access accounts or processes which he is not

authorised to access;

(b) repeatedly attempted to access an account or a process

using a non-matching username and password; or

(c) attempted, or is attempting, to undermine the security of

the registry or the registries system.

They shall ensure that the registry and Community independent
transaction log incorporate robust systems and procedures for
the safeguarding of all data and the prompt recovery of all data
and operations in the event of a disaster.

They shall keep interruptions to the operation of the registry
and Community independent transaction log to a minimum.

Article 69

Suspension of access

independent

transaction log

suspend access
and a

to the
The Central Administrator may
Community
registry
administrator may suspend access to his registry if there is a
breach of security of the Community independent transaction
log or of a registry which threatens the integrity of
the
Community independent transaction log or of a registry or the
integrity of the registries system and the back-up facilities under
Article 68 are similarly affected.

in any year

2. Where access to an operator holding account has been
suspended pursuant to paragraph 1 or pursuant to Article 69
between 28 April and 30 April
from 2006
onwards, the registry administrator shall, if so requested by the
account holder and following submission of his authorised
representative's
supporting evidence,
surrender the number of allowances and use the number of
CERs and ERUs specified by the account holder in accordance
with the allowance surrender process set out in Article 52 and
53 and Annex IX.

identity by means of

Article 70

Notification of suspension of access

1.
In the event of a breach of security of the Community
independent transaction log that may lead to suspension of
access, the Central Administrator shall promptly inform registry
administrators of any risks posed to registries.

29.12.2004

EN

Official Journal of the European Union

L 386/21

In the event of a breach of security of a registry that may
2.
lead to suspension of access, the relevant registry administrator
shall promptly inform the Central Administrator who shall, in
turn, promptly inform other registry administrators of any risks
posed to registries.

Article 72

Change management

If

the registry administrator becomes aware that

is
3.
necessary to suspend either access
to accounts or other
operations of the registry, he shall give all relevant account
holders and verifiers,
the Central Administrator and other
registry administrators such prior notice of the suspension as is
reasonably practicable.

it

If

4.
is
the Central Administrator becomes aware that
necessary to suspend access to operations of the Community
registry
independent
administrators
is
reasonably practicable.

transaction log,
such prior notice of

the suspension as

shall

give

all

it

it

The notices referred to in paragraphs 3 and 4 shall include
5.
the suspension and shall be clearly
the likely duration of
displayed on the public area of that registry’s web site or on the
public area of the Community independent transaction log's
web site.

Article 71

Testing area of each registry and the Community
independent transaction log

Each registry administrator shall establish a testing area
1.
within which any new version or release of a registry can be
tested in accordance with the testing procedures set out in
Annex XIII so as to ensure that:

(a) any testing procedures on a new version or release of a
registry are completed without reducing the availability to
account holders of the version or release of the registry
which currently has a communication link with the
transaction log or UNFCCC
Community independent
independent transaction log; and

(b) any communication link between a new version or release
of a registry and the Community independent transaction
log or UNFCCC independent transaction log is established
and activated with minimum disruption to its account
holders.

The Central Administrator shall establish a testing area so

2.
as to facilitate testing procedures referred to in paragraph 1.

3.
The registry administrators and the Central Administrator
shall ensure that the hardware and software of their testing area
shall perform in a manner
the
performance of the primary hardware and software referred to
in Article 68.

representative of

that

is

and the Secretariat

The Central Administrator shall coordinate with registry
1.
administrators
to the UNFCCC the
preparation and implementation of any amendments to this
Regulation resulting in changes in the functional and technical
specifications
their
registry
implementation.

system before

the

of

2.
If, as a result of a these amendments, a new version or
release of a registry is required, each registry administrator shall
successfully complete the testing procedures set out in Annex
XIII before a communication link is established and activated
between the new version or release of that registry and the
Community
or UNFCCC
independent
independent transaction log.

transaction

log

If, as a result of

3.
Each registry administrator shall continuously monitor the
availability, reliability and efficiency of his registry in order to
ensure a level of performance which meets the requirements of
the
this Regulation.
suspension of the communication link pursuant to Article 6(3),
a new version or release of a registry is required, each registry
administrator shall successfully complete the testing procedures
set out in Annex XIII before a communication link is established
and activated between the new version or release of that registry
and the Community independent transaction log or UNFCCC
independent transaction log.

this monitoring or

CHAPTER VIII

RECORDS AND FEES

Article 73

Records

The Central Administrator and each registry administrator
1.
shall store records concerning all processes and account holders
set out in Annex III, Annex IV, Annex VIII, Annex IX, Annex X
and Annex XI
for 15 years or until any questions of
implementation relating to them have been resolved, whichever
is the later.

2. Records shall be stored in accordance with the data logging
standards elaborated pursuant to the UNFCCC or the Kyoto
Protocol.

L 386/22

EN

Official Journal of the European Union

29.12.2004

Article 74

Fees

Any fees charged by the registry administrator
to account
holders shall be reasonable and shall be clearly displayed on the
public area of that registry’s web site. Registry administrators
shall not differentiate any such fees on the basis of the location
of an account holder within the Community.

Registry administrators shall not charge account holders for
transactions of allowances pursuant to Article 49, Articles 52 to
54 and Articles 58 to 63.

CHAPTER IX

FINAL PROVISIONS

Article 75

Entry into force

This Regulation shall enter into force on the day following that
of its publication in the Official Journal of the European Union.

This Regulation shall be binding in its entirety and directly applicable in all Member States.

Done at Brussels, 21 December 2004.

For the Commission

Stavros DIMAS

Member of the Commission

29.12.2004

EN

Official Journal of the European Union

L 386/23

Hardware and software requirements of registries and the Community independent transaction log

ANNEX I

Architecture requirements

1.

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

(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

2.

From 1 January 2005 until 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 Community independent transaction log and each registry shall be synchronised to
Greenwich Mean Time;

(b) all processes concerning allowances, verified emissions 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).

3. After 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, verified emissions, accounts 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.

L 386/24

EN

Official Journal of the European Union

29.12.2004

ANNEX II

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.

29.12.2004

EN

Official Journal of the European Union

L 386/25

ANNEX III

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.

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.

L 386/26

EN

Official Journal of the European Union

29.12.2004

ANNEX IV

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.

29.12.2004

EN

Official Journal of the European Union

L 386/27

ANNEX V

Core terms and conditions

Structure and effect of core terms and conditions

1. The relationship between account holders and registry administrators.

The account holder and authorised representative’s obligations

2. The account holder and authorised representative’s obligations with respect to security, usernames and passwords,

and access to the registry website.

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

data posted is accurate.

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

website.

The registry administrator’s obligations

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

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

7.

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

Process procedures

8. The process finalisation and confirmation provisions.

Payment

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

Operation of the registry website

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

11. Conditions of use of the registry website.

Warranties and indemnities

12. Accuracy of information.

13. Authority to initiate processes.

Modification of these core terms to reflect changes to this Regulation or changes to domestic legislation

Security and response to security breaches

Dispute resolution

14. Provisions relating to disputes between account holders.

Liability

15. The limit of liability for the registry administrator.

16. The limit of liability for the account holder.

Third party rights

Agency, notices and governing law

L 386/28

EN

Official Journal of the European Union

29.12.2004

ANNEX VI

Definitions of identification codes

Introduction

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

(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

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.

Unit identification code

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.

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.

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.

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

29.12.2004

EN

Official Journal of the European Union

L 386/29

Element

Display Order

Identifier
Required for the
Following Unit
Types

Data Type

Length

Range or Codes

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

AAU, RMU,
CER, ERU

AAU, RMU,
CER, ERU

AAU, RMU,
CER, ERU

N

N

N

15

15

2

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

Unique numeric values assigned
by registry from 1 –
999 999 999 999 999

Unique numeric values assigned
by registry from 1 –
999 999 999 999 999

0 = 2005-2007

1 = 2008-2012

…

99

AAU, CER,
ERU

N

2

0 = 2005-2007

1 = 2008-2012

…

99

Unit Serial
Block Start

Unit Serial
Block End

Original
Commitment
Period

Applicable
Commitment
Period

4

5

6

7

L 386/30

EN

Official Journal of the European Union

29.12.2004

Element

Display Order

Identifier
Required for the
Following Unit
Types

LULUCF
Activity

8

RMU, CER,
ERU

N

Data Type

Length

Range or Codes

3

7

2

1 = Afforestation and
reforestation

2 = Deforestation

3 = Forest management

4 = Cropland management

5 = Grazing land management

6 = Re-vegetation

Unique numeric value assigned
for project

1 or 2

Expiration date for lCERs or
tCERs

Project
Identifier

Track

Expiry Date

9

10

11

CER, ERU

ERU

N

N

lCER, tCER

Date

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.

Table VI-2: Valid Initial Unit Type — Supplementary Unit Type

Initial Unit Type

Supplementary Unit Type

Description

1

2

3

4

5

6

7

1

0

0

[not applicable]

[not applicable]

[not applicable]

[not applicable]

[not applicable]

[not applicable]

[not applicable]

1

2

3

AAU

RMU

ERU converted from AAU

ERU converted from RMU

CER (not tCER or lCER)

tCER

lCER

Allowance issued for the 2008-2012 period and
subsequent 5-year periods and is converted from an
AAU

Allowance issued for the 2005-2007 period and not
converted from an AAU or other Kyoto unit

Force-majeure allowance

Account identification code

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.

29.12.2004

EN

Official Journal of the European Union

L 386/31

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.

Table VI-3: Account Identification Code

Element

Display Order

Data Type

Length

Range or Codes

1

2

3

4

A

N

N

N

3

3

15

2

ISO3166 (2 letter code), ‘CDM’ for the
CDM registry, ‘EU’ for the Community
registry

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

Unique numeric values assigned by a
registry from 1 to 999 999 999 999 999

0 for holding accounts

0-99 for retirement and cancellation
accounts

Originating Registry

Account Type

Account Identifier

Applicable Commitment
Period

Permit identification code

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.

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.

Table VI-4: Permit Identification Code

Element

Display Order

Data Type

Length

Range or Codes

Originating Registry

Permit Identifier

1

2

A

A

3

50

ISO3166 (2 letter code), ‘EU’ for the
Community registry

([0-9] | [A-Z] |[‘-’]) +

Account holder identification code

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.

L 386/32

EN

Official Journal of the European Union

29.12.2004

Table VI-5: Account Holder Identification Code

Element

Display Order

Data Type

Length

Range or Codes

Originating Registry

Permit Identifier

1

2

A

A

3

50

ISO3166 (2 letter code), ‘EU’ for the
Community registry

([0-9] | [A-Z]) +

Installation identification code

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.

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

installation identification code.

Table VI-6: Installation Identification Code

Element

Display Order

Data Type

Length

Range or Codes

Originating Registry

Installation Identifier

1

2

A

N

3

15

ISO3166 (2 letter code), ‘EU’ for the
Community registry

Unique numeric values assigned by a
registry from 1 to 999 999 999 999 999

Correlation identification code

14. Table VI-7 details the elements of the correlation identification codes. Each process under Annex VIII 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.

Table VI-7: Correlation Identification Code

Element

Display Order

Data Type

Length

Range or Codes

Originating Registry

Correlation Identifier

1

2

A

N

3

15

ISO3166 (2 letter code), ‘EU’ for the
Community registry

Unique numeric values assigned by a
registry from 1 to 999 999 999 999 999

Transaction identification code

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.

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.

29.12.2004

EN

Official Journal of the European Union

L 386/33

Reconciliation identification code

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.

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.

Project identification code

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.

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.

L 386/34

EN

Official Journal of the European Union

29.12.2004

ANNEX VII

List of input codes

Introduction

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.

EU-specific codes

2.

Field Name: Activity Type

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

Code

Description

Combustion installations with a rated thermal input exceeding 20 MW

Mineral oil refineries

Coke ovens

Metal ore (including sulphide ore) roasting or sintering installations

Installations for the production of pig iron or steel
continuous casting

(primary or secondary fusion)

including

Installations for the production of cement clinker in rotary kilns or lime in rotary kilns or in other
furnaces

Installations for the manufacture of glass including glass fibre

Installations for the manufacture of ceramic products by firing, in particular roofing tiles, bricks,
refractory bricks, tiles, stoneware or porcelain

Industrial plants for the production of (a) pulp from timber or other fibrous materials (b) paper
and board

1

2

3

4

5

6

7

8

9

99

Other activity opted-in pursuant to Article 24 of Directive 2003/87/EC

3.

Field Name: Relationship Type

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

Code

Description

1

2

3

4

5

6

Account holder

Primary authorised representative of the account holder

Secondary authorised representative of the account holder

Additional authorised representative of the account holder

Authorised representative of the verifier

Contact person for the installation

29.12.2004

EN

Official Journal of the European Union

L 386/35

4.

Field Name: Process Type

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

Code

Description

01-00

02-00

03-00

04-00

05-00

06-00

07-00

Issue of AAUs and RMUs

Conversion of AAUs and RMUs to ERUs

External transfer (2008-2012 onwards)

Cancellation (2008-2012 onwards)

Retirement (2008-2012 onwards)

Cancellation and replacement of tCERs and lCERs

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

01-51

10-52

10-53

01-54

10-55

03-21

10-01

10-02

04-03

10-41

Internal transfer

Allowance issue (2005-2007)

Allowance issue (2008-2012 onwards)

Allowance allocation

Force-majeure allowance issue

Correction to allowances

External transfer (2005-2007)

Allowance cancellation (2005-2007)

Allowance surrender

Retirement (2005-2007)

Cancellation and replacement

5.

Field Name: Supplementary Unit Type

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

Code

Description

No supplementary unit type

Allowance issued for the 2008-2012 period and subsequent five-year periods and is converted
from an AAU

Allowance issued for the 2005-2007 period and not converted from an AAU or other Kyoto unit

Force-majeure allowance

0

1

2

3

L 386/36

EN

Official Journal of the European Union

29.12.2004

6.

Field Name: Action Code

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

Code

Description

Add people to the account or installation

Update people

Delete people

1

2

3

UNFCCC codes

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.

29.12.2004

EN

Official Journal of the European Union

L 386/37

ANNEX VIII

Processes concerning accounts and verified emissions with response codes

Requirements for each process

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

(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) prior to the communication link between the Community independent transaction log and the UNFCCC
independent transaction log being established, the registry administrator shall call the appropriate operation on
the registry
the Community independent
thereafter,
administrator shall call
transaction log account
management Web service;

transaction log account management Web service,
the appropriate operation on the UNFCCC independent

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

(g)

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;

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

L 386/38

EN

Official Journal of the European Union

29.12.2004

2.

Prior to the communication link between the Community independent transaction log and the UNFCCC independent
transaction log being established, a registry administrator sending a request should receive an acknowledgement of
receipt from the Community independent transaction log within 60 seconds. Thereafter, a registry administrator
sending a request should receive an acknowledgement of receipt from the UNFCCC independent transaction log
within 60 seconds. A registry administrator sending a request should receive a notification of validation from the
Community independent transaction log within 24 hours.

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

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

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.

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

Component

Function

Scope

MgmtOfAccountWS

CreateAccount()

UpdateAccount()

CloseAccount()

UpdateVerifiedEmissions()

Public

Public

Public

Public

ReceiveAccountOperationOutcome()

Public

29.12.2004

EN

Official Journal of the European Union

L 386/39

Component

Function

Scope

AccountManagement

ValidateAccountCreation()

CreateAccount()

ValidateAccountUpdate()

UpdateAccount()

ValidateAccountClosure()

CloseAccount()

Private

Private

Private

Private

Private

Private

ValidateVerifiedEmissionsUpdate()

Private

DataValidation

AuthenticateMessage()

UpdateVerifiedEmissions()

CheckVersion()

DataFormatChecks()

Private

Private

Private

Private

Table VIII-4: MgmtOfAccountWS Component

Purpose

The purpose of this component is to handle web service requests for the management of accounts and verified
emissions.

CreateAccount()

UpdateAccount()

CloseAccount()

Functions exposed through Web Services

Handles the account creation requests

Handles the account update requests

Handles account closure requests

UpdateVerifiedEmissions()

Handles verified emissions update requests

ReceiveAccountOperationOutcome()

Receives an account operation (creation, update, …)
outcome (‘accepted’ or ‘rejected’)

Not applicable.

Other functions

Roles

Community independent transaction log (for all functions) and registry (for the ReceiveAccountOperationOutcome
function only)

Table VIII-5: MgmtOfAccountWS.CreateAccount() function

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.

L 386/40

EN

Official Journal of the European Union

29.12.2004

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

To

CorrelationId

MajorVersion

MinorVersion

Account (*)

AccountType

AccountIdentifier

IdentifierInReg

CommitmentPeriod

Installation

InstallationIdentifier

PermitIdentifier

Name

MainActivityType

Country

PostalCode

City

Address1

Address2

ParentCompany

SubsidiaryCompany

EPERIdentification

Latitude

Longitude

ContactPeople (see People)

People (*)

RelationshipCode

PersonIdentifier

FirstName

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Optional

Optional

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Optional

Optional

Optional

Optional

Optional

Optional

Mandatory

Mandatory

Mandatory

Mandatory

Optional

29.12.2004

EN

Official Journal of the European Union

L 386/41

LastName

Country

PostalCode

City

Address1

Address2

PhoneNumber1

PhoneNumber2

FaxNumber

Email

Result Identifier

Response Code

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Optional

Mandatory

Mandatory

Mandatory

Mandatory

Output parameters

Mandatory

Optional

Uses

— AuthenticateMessage

— WriteToFile

— CheckVersion

Not applicable (called as a web service).

Used By

Table VIII-6: MgmtOfAccountWS.UpdateAccount() function

This function receives an account update request.

Purpose

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.

From

To

Input parameters

Mandatory

Mandatory

L 386/42

EN

Official Journal of the European Union

29.12.2004

CorrelationId

MajorVersion

MinorVersion

Account (*)

AccountIdentifier

IdentifierInReg

Installation

PermitIdentifier

Name

MainActivityType

Country

PostalCode

City

Address1

Address2

ParentCompany

SubsidiaryCompany

EPERIdentification

Latitude

Longitude

ContactPeople (see People)

People (*)

Action

RelationshipCode

PersonIdentifier

FirstName

LastName

Country

PostalCode

City

Address1

Address2

PhoneNumber1

PhoneNumber2

FaxNumber

Email

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Mandatory

Mandatory

Mandatory

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Optional

29.12.2004

EN

Official Journal of the European Union

L 386/43

Output parameters

Mandatory

Optional

Uses

Result Identifier

Response Code

— AuthenticateMessage

— WriteToFile

— CheckVersion

Not applicable (called as a web service).

Used By

Table VIII-7: MgmtOfAccountWS.CloseAccount() function

This function receives an account closure request.

Purpose

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

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Output parameters

Mandatory

Optional

Uses

From

To

CorrelationId

MajorVersion

MinorVersion

Account (*)

AccountIdentifier

Result Identifier

Response Code

— AuthenticateMessage

— WriteToFile

— CheckVersion

Not applicable (called as a web service).

Used By

L 386/44

EN

Official Journal of the European Union

29.12.2004

Table VIII-8: MgmtOfAccountWS.UpdateVerifiedEmissions() function

This function receives a verified emissions update request.

Purpose

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

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Output parameters

Mandatory

Optional

Uses

From

To

CorrelationId

MajorVersion

MinorVersion

VerifiedEmissions (*)

Year

Installations (*)

InstallationIdentifier

VerifiedEmission

Result Identifier

Response Code

— AuthenticateMessage

— WriteToFile

— CheckVersion

Not applicable (called as a web service).

Used By

Table VIII-9: MgmtOfAccountWS.ReceiveAccountOperationOutcome() function

This function receives an account management operation outcome.

Purpose

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 AuthenticateMessage() function and checks the version
of the transaction log by calling CheckVersion() function.

29.12.2004

EN

Official Journal of the European Union

L 386/45

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

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Optional

Output parameters

Mandatory

Optional

Uses

From

To

CorrelationId

MajorVersion

MinorVersion

Outcome

Response List

Result Identifier

Response Code

— AuthenticateMessage

— WriteToFile

— CheckVersion

Not applicable (called as a web service).

Used By

Table VIII-10: AccountManagement Component

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.

ValidateAccountCreation()

ValidateAccountUpdate()

ValidateAccountClosure()

Other functions

Validates an account creation

Validates an account update

Validates an account closure

ValidateVerifiedEmissionsUpdate()

Validates a verified emissions update

CreateAccount()

UpdateAccount()

Creates accounts

Updates accounts

L 386/46

EN

Official Journal of the European Union

29.12.2004

CloseAccount()

Closes accounts

UpdateVerifiedEmissions()

Updates verified emissions for installations

Transaction log (all functions), registry (for information only).

Roles

Table VIII-11: ManagementOfAccount.ValidateAccountCreation() function

This function validates an account creation request.

Purpose

If a validation test fails, the account identifier and response code are added to the response code list.

Input parameters

From

To

CorrelationId

MajorVersion

MinorVersion

Account (*)

AccountType

AccountIdentifier

IdentifierInReg

CommitmentPeriod

Installation

InstallationIdentifier

PermitIdentifier

Name

MainActivityType

Country

PostalCode

City

Address1

Address2

ParentCompany

SubsidiaryCompany

EPERIdentification

Latitude

Longitude

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Optional

Optional

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Optional

Optional

Optional

Optional

Optional

Optional

ContactPeople (see People)

Mandatory

29.12.2004

EN

Official Journal of the European Union

L 386/47

People (*)

RelationshipCode

PersonIdentifier

FirstName

LastName

Country

PostalCode

City

Address1

Address2

PhoneNumber1

PhoneNumber2

FaxNumber

Email

Result Identifier

Response List

Range 7101 to 7110; range 7122 to 7160.

Mandatory

Mandatory

Mandatory

Optional

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Optional

Mandatory

Optional

Mandatory

Optional

Output parameters

Mandatory

Optional

Messages

Table VIII-12: ManagementOfAccount.CreateAccount() function

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.

From

To

CorrelationId

Input parameters

Mandatory

Mandatory

Mandatory

L 386/48

EN

Official Journal of the European Union

29.12.2004

MajorVersion

MinorVersion

Account (*)

AccountType

AccountIdentifier

IdentifierInReg

CommitmentPeriod

Installation

InstallationIdentifier

PermitIdentifier

Name

MainActivityType

Country

PostalCode

City

Address1

Address2

ParentCompany

SubsidiaryCompany

EPERIdentification

Latitude

Longitude

ContactPeople (see People)

People (*)

RelationshipCode

PersonIdentifier

FirstName

LastName

Country

PostalCode

City

Address1

Address2

PhoneNumber1

PhoneNumber2

FaxNumber

Email

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Optional

Optional

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Optional

Optional

Optional

Optional

Optional

Optional

Mandatory

Mandatory

Mandatory

Mandatory

Optional

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Optional

Mandatory

Optional

Mandatory

Optional

29.12.2004

EN

Official Journal of the European Union

L 386/49

Result Identifier

Not applicable.

Not applicable (called as a web service).

Output parameters

Mandatory

Uses

Used By

Table VIII-13: AccountManagement.ValidateAccountUpdate() function

This function validates an account update request.

Purpose

If a validation test fails, the account identifier and response code are added to the response code list.

Input parameters

From

To

CorrelationId

MajorVersion

MinorVersion

Account (*)

AccountIdentifier

IdentifierInReg

Installation

PermitIdentifier

Name

MainActivityType

Country

PostalCode

City

Address1

Address2

ParentCompany

SubsidiaryCompany

EPERIdentification

Latitude

Longitude

ContactPeople (see People)

People (*)

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Optional

L 386/50

EN

Official Journal of the European Union

29.12.2004

Action

RelationshipCode

PersonIdentifier

FirstName

LastName

Country

PostalCode

City

Address1

Address2

PhoneNumber1

PhoneNumber2

FaxNumber

Email

Result Identifier

Response List

Mandatory

Mandatory

Mandatory

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Output parameters

Mandatory

Optional

Messages

Range 7102 to 7107; range 7111 to 7113; 7120; 7122; 7124; range 7126 to 7158.

Table VIII-14: ManagementOfAccount.UpdateAccount() function

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

29.12.2004

EN

Official Journal of the European Union

L 386/51

Input parameters

From

To

CorrelationId

MajorVersion

MinorVersion

Account (*)

AccountType

AccountIdentifier

IdentifierInReg

Installation

InstallationIdentifier

PermitIdentifier

Name

MainActivityType

Country

PostalCode

City

Address1

Address2

ParentCompany

SubsidiaryCompany

EPERIdentification

Latitude

Longitude

ContactPeople (see People)

People (*)

RelationshipCode

PersonIdentifier

FirstName

LastName

Country

PostalCode

City

Address1

Address2

PhoneNumber1

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Optional

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Optional

Optional

Optional

Optional

Optional

Optional

Mandatory

Mandatory

Mandatory

Mandatory

Optional

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Optional

Optional

L 386/52

EN

Official Journal of the European Union

29.12.2004

PhoneNumber2

FaxNumber

Email

Result Identifier

Not applicable.

Not applicable (called as a web service).

Optional

Optional

Optional

Output parameters

Mandatory

Uses

Used By

Table VIII-15: ManagementOfAccount.ValidateAccountClosure() function

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.

From

To

CorrelationId

MajorVersion

MinorVersion

Account (*)

AccountIdentifier

Result Identifier

Response List

Input parameters

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Purpose

Mandatory

Output parameters

Mandatory

Optional

Messages

7111; range 7114 to 7115; 7117; range 7153 to 7156; 7158.

Table VIII-16: ManagementOfAccount.CloseAccount() function

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.

Registry

CorrelationId

Input parameters

Mandatory

Mandatory

29.12.2004

EN

Official Journal of the European Union

L 386/53

MajorVersion

MinorVersion

Account (*)

AccountIdentifier

Result Identifier

Mandatory

Mandatory

Mandatory

Mandatory

Output parameters

Mandatory

Table VIII-17: ManagementOfAccount.ValidateVerifiedEmissionsUpdate() function

This function validates a verified emissions update.

Purpose

If a validation test fails, the installation identifier and response code are added to the response code list.

Input parameters

From

To

CorrelationId

MajorVersion

MinorVersion

VerifiedEmissions (*)

Year

Installations (*)

InstallationIdentifier

VerifiedEmission

Result Identifier

Response List

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Output parameters

Mandatory

Optional

Messages

Range 7118 to 7119; range 7152 to 7156; 7159.

Table VIII-18: ManagementOfAccount.UpdateVerifiedEmissions function

Updates the verified emissions for the year and installation specified.

Purpose

From

To

CorrelationId

MajorVersion

Input parameters

Mandatory

Mandatory

Mandatory

Mandatory

L 386/54

EN

Official Journal of the European Union

29.12.2004

VerifiedEmissions (*)

Year

Installations (*)

InstallationIdentifier

VerifiedEmission

Result Identifier

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Output parameters

Mandatory

Preliminary checks for each process

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.

6.

Prior to the communication link between the Community independent transaction log and the UNFCCC independent
transaction log being established, 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, 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. Thereafter, each registry shall receive
such response codes from the UNFCCC independent transaction log.

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.

Secondary checks for each process

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.

Process description

Account creation

Account update

Account closure

Verified emissions update

Table VIII-19: Secondary Checks

Community independent transaction log response codes

Range 7101 to 7110

7160

Range 7102 to 7105

Range 7107 to 7108

7111

7113

7120

7160

7111

Range 7114 to 7115

7117

Range 7118 to 7119

29.12.2004

EN

Official Journal of the European Union

L 386/55

ANNEX IX

Processes concerning transactions with response codes

Process types

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.

Requirements for each process

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.

Preliminary checks for each process

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.

4.

Prior to the communication link between the Community independent transaction log and the UNFCCC independent
transaction log being established, 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,

and return the appropriate response codes if a discrepancy is detected, 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. Thereafter, each registry shall receive such
response codes from the UNFCCC independent transaction log.

Secondary and tertiary checks for each process

5.

For each process concerning a transaction which has passed all of
independent transaction log shall perform the following secondary checks to ascertain whether:

the preliminary checks,

the Community

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

L 386/56

EN

Official Journal of the European Union

29.12.2004

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

Table IX-1: Tertiary Checks

Process description

Process type

Community independent transaction log response
codes

Issue of AAUs and RMUs

Conversion of AAUs and RMUs to ERUs

External transfer (2008-2012 onwards)

Cancellation (2008-2012 onwards)

Retirement (2008-2012 onwards)

Cancellation and replacement of tCERs and
lCERs

Carry-over of Kyoto units and allowances
issued for the 2008-2012 period and
subsequent five-year periods

Change of expiry date of tCERs and lCERs

Internal transfer

Allowance issue (2005-2007)

Allowance issue (2008-2012 onwards)

Allowance allocation

Force-majeure allowance issue

01-54

01-00

02-00

03-00

04-00

05-00

06-00

[not applicable]

7218

Range 7301 to 7302
7304

[not applicable]

Range 7358 to 7361

[not applicable]

07-00

[not applicable]

08-00

10-00

01-51

10-52

10-53

[not applicable]

7304
Range 7406 to 7407

Range 7201 to 7203
7219

Range 7201 to 7203
7205
7219

7202
7203
Range 7206 to 7208
7214
7216
7304
7360

7202
Range 7210 to 7211
7215
7217
7220

29.12.2004

EN

Official Journal of the European Union

L 386/57

Process description

Process type

Community independent transaction log response
codes

Correction to allowances

10-55

Range 7212 to 7213

External transfer (2005-2007)

03-21

Allowance cancellation (2005-2007)

Allowance surrender

Retirement (2005-2007)

10-01

10-02

04-03

Cancellation and replacement

10-41

7302
Range 7304 to 7305
Range 7406 to 7407

7212
7305

7202
7304
Range 7353 to 7356

7209
7305
7357
Range 7360 to 7362

(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

L 386/58

EN

Official Journal of the European Union

29.12.2004

ANNEX X

Reconciliation process with response codes

Requirements for the process

1.

Prior to the communication link between the Community independent transaction log and the UNFCCC independent
transaction log being 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:

(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. After the communication link between the Community independent transaction log and the UNFCCC independent
transaction log has been 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:

(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. After the communication link between the Community independent transaction log and the UNFCCC independent
transaction log has been established, each registry shall respond to any request by the UNFCCC independent
transaction log made on behalf of the Community independent transaction log to submit the following information
for a specified time and date:

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

29.12.2004

EN

Official Journal of the European Union

L 386/59

Preliminary checks for the process

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.

6.

Prior to the communication link between the Community independent transaction log and the UNFCCC independent
transaction log being established, 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 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. Thereafter, each registry shall receive such
response codes from the UNFCCC independent transaction log.

Secondary checks for the process

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.

Table X-1: Secondary Checks

Process description

Reconciliation

Community independent transaction log response codes

Range: 7501 to 7524

Manual intervention

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.

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.

L 386/60

EN

Official Journal of the European Union

29.12.2004

ANNEX XI

Administrative processes with response codes

Administrative processes

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

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

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

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.

Requirements for each process

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.

Checks for each process

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.

6.

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

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:

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

29.12.2004

EN

Official Journal of the European Union

L 386/61

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:

(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
the
standards for registry systems under the Kyoto Protocol, elaborated pursuant to Decision 24/CP.8 of
Conference of the Parties to the UNFCCC.

L 386/62

EN

Official Journal of the European Union

29.12.2004

ANNEX XII

List of response codes for all processes

1. The Community independent transaction log shall return response codes as part of each process, where specified in
Annex VIII, Annex IX, Annex X and Annex XI. 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.

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.

Table XII-1: Community Independent Transaction Log Response Codes

Response Code

Description

7005

7006

7020

7021

7022

7023

7024

7025

The current status of the initiating (or transferring) registry does not permit this process to take
place.

The current status of the acquiring registry does not permit this process to take place

The specified account identification code does not exist in the acquiring registry.

The specified account identification code does not exist in the transferring registry.

The transferring account and acquiring account must be in the same registry for all transactions
except external transfers.

The transferring account and acquiring account must be in different registries for external transfers.

Force majeure allowances cannot be transferred out of the Party holding account unless being
cancelled and retired in accordance with Article 58.

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

7102

7103

7104

7105

7106

7107

7108

7109

7110

7111

7113

7114

7115

The account has already been created.

An account must have one and only one account holder.

An account must have one and only one primary authorised representative.

An account must have one and only one secondary authorised representative.

An installation must have one and only one contact person.

The installation associated to this account is already associated to another account.

The authorised representatives of the account must all be different.

The alphanumeric identifier specified for the account is already specified for another account.

The account type being created has not been given the correct commitment period.

An operator holding account must have one and only one installation associated with that account.

The specified account does not exist, and therefore it is not possible to update or close the account.

It is not possible to change the account holder of a person holding account.

The specified account has already been closed therefore it is not possible to close the account.

The specified account still holds units and therefore it is not possible to close the account.

29.12.2004

EN

Official Journal of the European Union

L 386/63

Response Code

Description

7117

7118

7119

7120

The installation linked to the specified account is not in compliance therefore it is not possible to
close the account.

The specified installation does not exist and therefore it is not possible to update the verified
emissions table for that installation.

The specified year is a future year and therefore it is not possible to update the verified emissions
table for that year.

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.

L 386/64

EN

Official Journal of the European Union

29.12.2004

Response Code

Description

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.

7149

The people fax number is not in valid format or is out of range.

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.

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

7205

7206

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.

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.

The specified acquiring account is not the operator holding account which is associated to the
specified installation.

29.12.2004

EN

Official Journal of the European Union

L 386/65

Response Code

Description

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

7214

The reduction in the number of allowances exceeds the correction to the NAP as approved by the
Commission.

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

7219

7220

The specified AAUs are allowances and therefore it is not possible to convert those AAUs into
ERUs.

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.

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.

7301

Warning: approaching breach of the commitment period reserve.

7302

7304

There is no mutual recognition agreement between the transferring registry and the acquiring
registry that enables the transfer of allowances.

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

7358

7359

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.

The number of AAUs requested to be converted from allowances is not equal to the number of
allowances surrendered pursuant to Article 52.

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.

L 386/66

EN

Official Journal of the European Union

29.12.2004

Response Code

Description

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

7401

7402

7404

7405

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.

The number of AAUs requested to be converted into allowances is not equal to the number of
allowances cancelled.

Specified unit type requested to be cancelled in advance of replacement is not an allowance issued
for the preceding period.

The number of allowances cancelled is not equal to the number of allowances to be cancelled
pursuant to Article 60(a) and 61(b).

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

7501

7502

7503

7504

7505

7506

7507

7508

7509

There is an inconsistency between the registry and the CITL in the operator holding account unit
blocks.

There is an inconsistency between the registry and the CITL in the person holding account unit
blocks.

Information: there are no inconsistencies between the registry and the CITL in the operator holding
account unit blocks.

Information: there are no inconsistencies between the registry and the CITL in the person holding
account unit blocks.

There is an inconsistency between the registry and the CITL in the totals of the operator holding
account unit blocks.

There is an inconsistency between the registry and the CITL in the totals of the person holding
account unit blocks.

Information: there are no inconsistencies between the registry and the CITL in the totals of the
operator holding account unit blocks.

Information: there are no inconsistencies between the registry and the CITL in the totals of the
person holding account unit blocks.

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

7513

Information: there are no inconsistencies between the registry and the CITL in the Party holding
account unit blocks.

Information: there are no inconsistencies between the registry and the CITL in the retirement
account unit blocks.

29.12.2004

EN

Official Journal of the European Union

L 386/67

Response Code

Description

7514

7515

7516

7517

7518

7519

7520

7521

7522

7523

7524

7601

Information: there are no inconsistencies between the registry and the CITL in the cancellation
account unit blocks.

There is an inconsistency between the registry and the CITL in the totals of the Party holding
account unit blocks.

There is an inconsistency between the registry and the CITL in the totals of the retirement account
unit blocks.

There is an inconsistency between the registry and the CITL in the totals of the cancellation account
unit blocks.

Information: there are no inconsistencies between the registry and the CITL in the totals of the
Party holding account unit blocks.

Information: there are no inconsistencies between the registry and the CITL in the totals of the
retirement account unit blocks.

Information: there are no inconsistencies between the registry and the CITL in the totals of the
cancellation account unit blocks.

There is an inconsistency between the registry and the CITL in the replacement account unit blocks.

Information: there are no inconsistencies between the registry and the CITL in the replacement
account unit blocks.

There is an inconsistency between the registry and the CITL in the totals of the replacement
account unit blocks.

Information: there are no inconsistencies between the registry and the CITL in the totals of the
replacement account unit blocks.

Reminder: the specified unit blocks of allowances issued for the previous period have not yet been
cancelled pursuant to Articles 60 and 61.

L 386/68

EN

Official Journal of the European Union

29.12.2004

ANNEX XIII

Testing procedures

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

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

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

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

Integrated process testing: the ability of the registry to execute all processes, including all relevant statuses and
stages set out in Annex VIII, Annex IX, Annex X and Annex XI, 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.

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 Annex VIII, Annex IX, Annex X and Annex XI are contained within that registry's
database and interpreted and used appropriately in respect of processes.

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.

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.

29.12.2004

EN

Official Journal of the European Union

L 386/69

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.

L 386/70

EN

Official Journal of the European Union

29.12.2004

ANNEX XIV

Initialisation procedures

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

(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
Article 72.

the system and procedures of

the registry in respect of change management pursuant to

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

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:

(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

4.

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

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

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

29.12.2004

EN

Official Journal of the European Union

L 386/71

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.

7.

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

L 386/72

EN

Official Journal of the European Union

29.12.2004

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 account
identification codes of the cancellation accounts, retirement accounts and replacement accounts of each registry.

the Parties to the UNFCCC, the Commission shall

inform the Secretariat to the UNFCCC of

29.12.2004

EN

Official Journal of the European Union

L 386/73

ANNEX XV

Security standards

Communication link between the Community independent transaction log and each registry

1.

From 1 January 2005 until the communication link between the Community independent transaction log and the
UNFCCC independent transaction log is established, all processes concerning allowances, verified emissions and
accounts shall be completed using a communication link with the following properties:

(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
(HTTP) basic authentication scheme
(http://www.ietf.org/rfc/rfc2617.txt).

transfer protocol

2. After the communication link between the Community independent transaction log and the UNFCCC independent
transaction log is established, all processes concerning allowances, 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.

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

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:

(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:

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

L 386/74

EN

Official Journal of the European Union

29.12.2004

(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

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.

system shall maintain a record of previous passwords

(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

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.

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.

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

7.

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

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

29.12.2004

EN

Official Journal of the European Union

L 386/75

ANNEX XVI

Reporting requirements of each registry administrator and the Central Administrator

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

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.

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:

(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:

(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:

(a) verified emissions figure 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

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.

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:

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

L 386/76

EN

Official Journal of the European Union

29.12.2004

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

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:

(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
in compliance with its
that
commitment under Article 3, paragraph 1 of the Kyoto Protocol shall be displayed from 15 January onwards of
year (X+1);

the Member State is not

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

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.

29.12.2004

EN

Official Journal of the European Union

L 386/77

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.

Publicly available information from the Community independent transaction log

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.

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

(a) account identification code of
elements set out in Annex VI;

the transferring account: the code assigned to the account comprising the

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

Information from each registry to be made available to account holders

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.

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:

(a) current holdings of allowances or Kyoto units;

(b)

(c)

(d)

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;

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

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