EUR-Lex Access to European Union law

Back to EUR-Lex homepage

This document is an excerpt from the EUR-Lex website

Document 32016R0480

Commission Implementing Regulation (EU) 2016/480 of 1 April 2016 establishing common rules concerning the interconnection of national electronic registers on road transport undertakings and repealing Regulation (EU) No 1213/2010 (Text with EEA relevance)

C/2016/1723

OJ L 87, 2.4.2016, p. 4–23 (BG, ES, CS, DA, DE, ET, EL, EN, FR, HR, IT, LV, LT, HU, MT, NL, PL, PT, RO, SK, SL, FI, SV)

ELI: http://data.europa.eu/eli/reg_impl/2016/480/oj

2.4.2016   

EN

Official Journal of the European Union

L 87/4


COMMISSION IMPLEMENTING REGULATION (EU) 2016/480

of 1 April 2016

establishing common rules concerning the interconnection of national electronic registers on road transport undertakings and repealing Regulation (EU) No 1213/2010

(Text with EEA relevance)

THE EUROPEAN COMMISSION,

Having regard to the Treaty on the Functioning of the European Union,

Having regard to Regulation (EC) No 1071/2009 of the European Parliament and of the Council of 21 October 2009 establishing common rules concerning the conditions to be complied with to pursue the occupation of road transport operator and repealing Council Directive 96/26/EC (1), and in particular Article 16(5) thereof,

Whereas:

(1)

Article 16(1) of Regulation (EC) No 1071/2009 establishes the obligation for Member States to keep a national electronic register of road transport undertakings which have been authorised by a competent authority to engage in the occupation of road transport operator. The relevant data contained in the national electronic registers should be made accessible to all the competent authorities of the other Member States. Article 16(5) and (6) of Regulation (EC) No 1071/2009 require the national electronic registers to be interconnected by 31 December 2012, mandating the Commission to adopt common rules concerning such interconnection. On the basis of this mandate, the Commission adopted Regulation (EU) No 1213/2010 (2), in order to facilitate the interconnection of the national electronic registers through a message exchange system called ERRU (European Registers of Road Transport Undertakings). The latter became operational on 31 December 2012.

(2)

During the last 3 years of operation of ERRU, the Commission, along with experts from Member States, has identified a certain number of aspects related to the practical use of ERRU that do not fully correspond to the administrative processes set up in Member States.

(3)

It is therefore necessary to address the shortcomings that have been identified in the daily operation of ERRU, aligning it with the relevant provisions of Regulation (EC) No 1071/2009, Regulation (EC) No 1072/2009 of the European Parliament and of the Council (3) and Regulation (EC) No 1073/2009 of the European Parliament and of the Council (4), as well as guaranteeing that ERRU is used in a uniform manner by competent authorities throughout the EU. Moreover, it is necessary to adapt the existing rules to the technical and scientific progress.

(4)

Commission Regulation (EU) 2016/403 (5) with regard to the classification of serious infringements of the Union rules, sets out a new list of categories, types and degrees of seriousness of serious infringements of Union rules, which in addition to those set out in Annex IV to Regulation (EC) No 1071/2009, may lead to the loss of good repute of the road transport undertaking or the transport manager. It is therefore necessary to enable ERRU to transmit information on the new list of infringements.

(5)

The provisions on personal data protection, as laid down in particular by Directive 95/46/EC of the European Parliament and of the Council (6), apply to the processing of any personal data pursuant to Regulation (EC) No 1071/2009. In particular, Member States must implement appropriate security measures to prevent misuse of personal data.

(6)

Where applicable, the provisions on personal data protection, as laid down by Regulation (EC) No 45/2001 of the European Parliament and of the Council (7) apply to the processing of any personal data pursuant to Regulation (EC) No 1071/2009.

(7)

Due to substantial amount of changes which should be made to the common rules for the implementation of the interconnection of the national electronic registers, it is necessary to replace Regulation (EU) No 1213/2010 by a new act. Regulation (EU) No 1213/2010 should therefore be repealed.

(8)

The measures provided for in this Regulation are in accordance with the opinion of the Committee referred to in Article 42(1) of Regulation (EU) No 165/2014 of the European Parliament and of the Council (8),

HAS ADOPTED THIS REGULATION:

Article 1

Subject matter

This Regulation lays down the requirements regarding the connection of the national electronic registers on road transport undertakings to the ERRU messaging system, as set out in Article 16(5) of Regulation (EC) No 1071/2009.

Article 2

Definitions

For the purpose of this Regulation and in addition to the definitions laid down in Article 2 of Regulation (EC) No 1071/2009, the following definitions shall apply:

(a)

‘ERRU (European Registers of Road Transport Undertakings)’ means a system of interconnection of national electronic registers, set up in accordance Article 16(5) of Regulation (EC) No 1071/2009;

(b)

‘Asynchronous interface’ means a process whereby a message in response to a request is returned on a new HTTP connection;

(c)

‘Broadcast search’ means a request message from a Member State addressed to all other Member States;

(d)

‘Central hub’ means the information system enabling the routing of ERRU messages between Member States;

(e)

‘CPC’ means certificate of professional competence, as referred to in Article 8(8) of Regulation (EC) No 1071/2009;

(f)

‘Member State of infringement’ means the Member State in which a transport undertaking has committed an infringement;

(g)

‘Member State of establishment’ means the Member State in which an undertaking is established;

(h)

‘National system’ means the information system set up in each Member State for the purpose of emitting, processing and responding to ERRU messages;

(i)

‘Synchronous interface’ means a process whereby a message in response to a request is returned on the same HTTP connection as the one used for the request;

(j)

‘Requesting Member State’ means the Member State emitting a request or a notification, which is then routed to the responding Member States;

(k)

‘Responding Member State’ means the Member State to whom the ERRU request or notification is directed.

Article 3

Obligation to connect to ERRU

Member States shall carry out the interconnection of the national electronic registers referred to in Article 16 of Regulation (EC) No 1071/2009 to ERRU in accordance with the procedures and technical requirements laid down in this Regulation.

Article 4

Technical specifications

ERRU shall fulfil the technical specifications laid down in Annexes I to VII to this Regulation.

Article 5

Use of ERRU

1.   When exchanging information through ERRU, the competent authorities shall follow the procedures set out in Annex VIII to this Regulation.

2.   Member States shall grant their control bodies in charge of roadside checks access to the ERRU Check Community Licence functionality.

3.   In cases where several national control bodies are involved in roadside checks, the Member State shall decide which ones of those bodies shall be granted the access referred to in paragraph 2.

Article 6

Repeal

Regulation (EU) No 1213/2010 is hereby repealed as from the date of application of this Regulation. References to the repealed Regulation shall be construed as references to this Regulation.

Article 7

Entry into force

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

It shall apply from 30 January 2019.

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

Done at Brussels, 1 April 2016.

For the Commission

The President

Jean-Claude JUNCKER


(1)  OJ L 300, 14.11.2009, p. 51.

(2)  Commission Regulation (EU) No 1213/2010 of 16 December 2010 establishing common rules concerning the interconnection of national electronic registers on road transport undertakings (OJ L 335, 18.12.2010, p. 21).

(3)  Regulation (EC) No 1072/2009 of the European Parliament and of the Council of 21 October 2009 on common rules for access to the international road haulage market (OJ L 300, 14.11.2009, p. 72).

(4)  Regulation (EC) No 1073/2009 of the European Parliament and of the Council of 21 October 2009 on common rules for access to the international market for coach and bus services, and amending Regulation (EC) No 561/2006 (OJ L 300 14.11.2009, p. 88).

(5)  Commission Regulation (EU) 2016/403 of 18 March 2016 supplementing Regulation (EC) No 1071/2009 of the European Parliament and of the Council with regard to the classification of serious infringements of the Union rules, which may lead to the loss of good repute by the road transport operator, and amending Annex III to Directive 2006/22/EC of the European Parliament and of the Council (OJ L 74, 19.3.2016, p. 8).

(6)  Directive 95/46/EC of the European Parliament and of the Council of 24 October 1995 on the protection of individuals with regard to the processing of personal data and on the free movement of such data (OJ L 281, 23.11.1995, p. 31).

(7)  Regulation (EC) No 45/2001 of the European Parliament and of the Council of 18 December 2000 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 (OJ L 8, 12.1.2001, p. 1).

(8)  Regulation (EU) No 165/2014 of the European Parliament and of the Council of 4 February 2014 on tachographs in road transport, repealing Council Regulation (EEC) No 3821/85 on recording equipment in road transport and amending Regulation (EC) No 561/2006 of the European Parliament and of the Council on the harmonisation of certain social legislation relating to road transport (OJ L 60, 28.2.2014, p. 1).


ANNEX I

GENERAL ASPECTS OF ERRU

1.   ARCHITECTURE

ERRU shall be composed of the following parts:

1.1.

A central hub, which shall be able to receive a request from the requesting Member State, validate it and process it by forwarding it to the responding Member States. The central hub will wait for each responding Member State to answer, consolidate all the answers and forward the consolidated response to the requesting Member State.

1.2.

A national system per Member State, which shall be fitted with an interface capable of both sending requests to the central hub and receiving the corresponding replies. National systems may use propriety or commercial software to transmit and receive messages from the central hub.

1.3.

As an alternative to 1.1, Member States may choose to use a compatible commercial network to exchange messages amongst themselves. In that case, each competent authority will provide statistics on the messages exchanged within that network to the central hub.

2.   MANAGEMENT

2.1.   The central hub shall be managed by the Commission, which shall be responsible for the technical operation and maintenance of the central hub.

2.2.   The central hub shall not store data for a period exceeding 6 months, other than the logging and statistical data set out in Annex VII.

2.3.   The central hub shall not provide access to personal data, except for authorised Commission personnel, when necessary for the purpose of maintenance and troubleshooting.

2.4.   Member States shall be responsible for:

2.4.1.

The setup and management of their national systems, including the interface with the central hub.

2.4.2.

The installation and maintenance of their national system, both hardware and software, whether proprietary or commercial.

2.4.3.

The correct interoperability of their national system with the central hub, including the management of error messages received from the central hub.

2.4.4.

Taking all the measures to ensure the confidentiality, integrity and availability of the information.

2.4.5.

The operation of the national systems in accordance with the service levels set out in Annex VI.

2.5.   MOVEHUB web portal

The Commission shall provide a web based application with secured access, referred to as ‘MOVEHUB web portal’, providing at least the following services:

(a)

Member State availability statistics

(b)

Notification of maintenance on the central hub and Member State national systems.

(c)

Aggregated reports

(d)

Contact management

(e)

XSD schemas

2.6.   Contact management

The contact management functionality will provide each Member State with the ability to manage the contact details regarding policy, business, operational and technical users of that Member State, being each Member State's competent authority responsible for the maintenance of its own contacts. It will be possible to view, but not edit, the contact details of the other Member States.


ANNEX II

ERRU FUNCTIONALITIES

1.

The following functionalities shall be provided through ERRU:

1.1.

Check Good Repute (CGR): allows the requesting Member State to send a query to one or all responding Member States, to determine the fitness of a transport manager and so the authorisation to operate a transport undertaking.

1.2.

Infringement Notification (INF): allows the Member State of infringement to notify the Member State of establishment that the transport undertaking has committed a serious infringement as referred to in Article 6(2)(b) of Regulation (EC) No 1071/2009. It also allows the Member State of infringement to request that penalties be applied to the transport undertaking in the Member State of establishment.

1.3.

Check Community Licence (CCL): allows the requesting Member State to send a query to the responding Member State (i.e. the Member State of establishment) to determine if a transport undertaking is operating with a valid Community licence.

2.

Other message types deemed suitable for the efficient functioning of ERRU shall be included, for instance error notifications.


ANNEX III

ERRU MESSAGE PROVISIONS

1.   GENERAL TECHNICAL REQUIREMENTS

1.1.   The central hub will provide both synchronous and asynchronous interfaces for the exchange of messages. Member States may choose the most suitable technology to interface with their own applications.

1.2.   All messages exchanged between the central hub and the national systems must be UTF-8 encoded.

1.3.   Member States will ensure that their national systems can receive and process messages containing Greek or Cyrillic characters.

2.   XML MESSAGES STRUCTURE AND SCHEMA DEFINITION (XSD)

2.1.   The general structure of XML messages shall follow the format defined by the XSD schemas installed in the central hub.

2.2.   The central hub and the national systems shall transmit and receive messages that conform to the message XSD schema.

2.3.   National systems will be capable of sending, receiving and processing all messages corresponding to any of the functionalities set out in Annex II.

2.4.   The XML messages shall include at least the minimum requirements laid down in the Appendix to this Annex.

Appendix

Minimum requirements for the content of the XML messages

Common Header

Mandatory

Version

The official version of the XML specifications will be specified through the namespace defined in the message XSD and in the version attribute of the Header element of any XML message. The version number (‘n.m’) will be defined as fixed value in every release of the XML Schema Definition file (xsd).

Yes

Test Identifier

Optional id for testing. The originator of the test will populate the id and all participants in the workflow will forward/return the same id. In production it should be ignored and will not be used if it is supplied.

No

Technical Identifier

A UUID uniquely identifying each individual message. The sender generates a UUID and populates this attribute. This data is not used in any business capacity.

Yes

Workflow Identifier

The workflowId is a UUID and should be generated by the requesting Member State. This id is then used in all messages to correlate the workflow.

Yes

Sent At

The date and time (UTC) that the message was sent.

Yes

Timeout

This is an optional date and time (in UTC format) attribute. This value will be set only by the Hub for forwarded requests. This will inform the responding Member State of the time when the request will be timed out. This value is not required in MS2TCN_<x>_Req and all response messages. It is optional so that the same header definition can be used for all message types regardless of whether or not the timeoutValue attribute is required.

No

From

The ISO 3166-1 Alpha 2 code of the Member State sending the message or ‘EU’.

Yes

To

The ISO 3166-1 Alpha 2 code of the Member State to which the message is being sent or ‘EU’.

Yes

Check Good Repute

Check Good Repute Request

Mandatory

Business Case Identifier

A serial or reference number identifying each individual request.

Yes

Requesting Competent Authority

The competent authority that has issued the search request.

Yes

Transport Manager Details

Yes, if no CPC details

Family Name

Transport manager's family name(s) as indicated on the CPC.

Yes

First Name

Transport manager's complete given name as indicated on the certificate of professional competence.

Yes

Date of Birth

Transport manager's birth date in ISO 8601 format (YYYY-MM-DD).

Yes

Place of Birth

Transport manager's place of birth.

No

CPC Details

Yes, if no transport manager details

CPC Number

Number of certificate of professional competence

Yes

CPC Issue Date

Date of issuance of the CPC, in ISO 8601 format (YYYY-MM-DD).

Yes

CPC Issue Country

Issuing country of the CPC in ISO 3166-1 alpha 2 format.

Yes


Check Good Repute Response

Mandatory

Business Case Identifier

A serial or reference number matching the business case identifier of the request.

Yes

Requesting Competent Authority

The competent authority that has issued the search request.

Yes

Responding Competent Authority

The competent authority that has responded to the search request.

Yes

Status Code

The status code of the search (e.g. found, not found, error, etc.).

Yes

Status Message

An explanatory status description (if necessary).

No

Found Transport Manager Details

Yes if Status Code is Found

Family Name

Transport manager's family name(s) as recorded in the register.

Yes

First Name

Transport manager's complete given name as recorded in the register.

Yes

Date of Birth

Transport manager's birth date in ISO 8601 format (YYYY-MM-DD) as recorded in the register.

Yes

Place of Birth

Transport manager's place of birth as recorded in the register.

Yes

CPC Number

Number of certificate of professional competence as recorded in the register.

Yes

CPC Issue Date

Date of issuance of the CPC, in ISO 8601 format (YYYY-MM-DD) as recorded in the register.

Yes

CPC Issue Country

Issuing country of the CPC in ISO 3166-1 alpha 2 format as recorded in the register.

Yes

Total Managed Undertakings

The number of transport undertakings with which the transport manager is associated.

Yes

Total Managed Vehicles

The total number of vehicles with which the transport manager is associated.

Yes

Fitness

Declaration of either ‘Fit’ or ‘Unfit’.

Yes

End Date of Unfitness

End date of unfitness of the transport manager in ISO 8601 format (YYYY-MM-DD). Applicable if the Fitness is unfit.

No

Search Method

The method used to find the transport manager: NYSIIS, CPC, Custom.

Yes

Transport Undertaking (for each found Transport Manager)

Yes if Managed Undertakings > 0

Transport Undertaking Name

The name of the transport undertaking (name and legal form) as recorded in the register.

Yes

Transport Undertaking Address

The address of the transport undertaking (address, postal code, city, country) as recorded in the register.

Yes

Community Licence Number

The serial number of the community licence of the transport undertaking as recorded in the register.

Yes

Community Licence Status

The status of the community licence of the transport undertaking as recorded in the register.

Yes

Managed Vehicles

The number of vehicles managed as recorded in the register.

Yes

Infringement Notification

Infringement Notification Request

Mandatory

Business Case Identifier

A serial or reference number identifying each individual request.

Yes

Notifying Authority

The competent authority that issues the infringement notification.

Yes

Transport Undertaking

Yes

Transport Undertaking Name

The name of the transport undertaking against which the infringement is being recorded.

Yes

Community Licence Number

The serial number of the certified true copy of the Community license of the transport undertaking.

Yes

Vehicle Registration Number

The Vehicle registration number of the offending vehicle.

Yes

Vehicle Registration Country

The country in which the vehicle is registered.

Yes

Serious Infringement

Yes

Date of Infringement

Date of the infringement in ISO 8601 format. (YYYY-MM-DD)

Yes

Category

The category of the infringement:

MSI — Most serious infringement

VSI — Very serious infringement

SI — Serious infringement

Yes

Infringement Type

In accordance with the classification provided in Annex IV to Regulation (EC) No 1071/2009 and Annex I to Regulation (EU) 2016/403

Yes

Date of Check

The date of the check at which infringement has been ascertained in ISO 8601 format (YYYY-MM-DD).

Yes

Penalty Imposed (for each Serious Infringement)

Yes

Penalty Imposed Identifier

The serial number of the individual penalty imposed.

Yes

Final Decision Date

The final decision date of the penalty imposed in ISO 8601 format (YYYY-MM-DD).

Yes

Penalty Type Imposed

Declaration of either:

101 — ‘Warning’

201 — ‘Temporary ban on cabotage operations’

202 — ‘Fine’

203 — ‘Prohibition’

204 — ‘Immobilisation’

102 — ‘Other’

Yes

Start Date

The start date of the penalty imposed in ISO 8601 format (YYYY-MM-DD)

No

End Date

The end date of the penalty imposed in ISO 8601 format (YYYY-MM-DD)

No

Is Executed

Yes/No

Yes

Penalty Requested (for each Serious Infringement)

No

Penalty Requested Identifier

The serial number of the individual penalty requested.

Yes

Penalty Type Requested

Declaration of either:

101 — ‘Warning’

301 — ‘Temporary withdrawal of some or all of the certified true copies of the Community licence’

302 — ‘Permanent withdrawal of some or all of the certified true copies of the Community licence’

303 — ‘Temporary withdrawal of the Community licence’

304 — ‘Permanent withdrawal of the Community licence’

305 — ‘Suspension of the issue of driver attestations’

306 — ‘Withdrawal of driver attestations’

307 — ‘Issue of driver attestations subject to additional conditions in order to prevent misuse’

Yes

Duration

The duration of the requested penalty (calendar days).

No


Infringement Notification Response

Mandatory

Business Case Identifier

A serial or reference number matching the business case identifier of the request.

Yes

Originating Authority

The competent authority that issued the original infringement notification.

Yes

Licensing Authority

The competent authority responding to the infringement notification.

Yes

Status Code

The status code of the infringement response (e.g. found, not found, error, etc.).

Yes

Status Message

An explanatory status description (if necessary).

No

Transport Undertaking

Yes

Transport Undertaking Name

The name of the transport undertaking as recorded in the register.

Yes

Penalty Imposed

No

Penalty Imposed Identifier

The serial number of the individual penalty imposed (given in the Penalty Requested Identifier of the Infringement Notification).

Yes

Authority Imposing Penalty

The name of the authority imposing penalty.

Yes

Is Imposed

Yes/No

Yes

Penalty Type Imposed

Declaration of either:

101 — ‘Warning’

301 — ‘Temporary withdrawal of some or all of the certified true copies of the Community licence’

302 — ‘Permanent withdrawal of some or all of the certified true copies of the Community licence’

303 — ‘Temporary withdrawal of the Community licence’

304 — ‘Permanent withdrawal of the Community licence’

305 — ‘Suspension of the issue of driver attestations’

306 — ‘Withdrawal of driver attestations’

307 — ‘Issue of driver attestations subject to additional conditions in order to prevent misuse’

102 — ‘Other’

Yes

Start Date

The start date of the penalty imposed in ISO 8601 format (YYYY-MM-DD).

No

End Date

The end date of the penalty imposed in ISO 8601 format (YYYY-MM-DD).

No

Reason

Reason if penalty is not imposed.

No


Infringement Notification Acknowledgement

Mandatory

Business Case Identifier

A serial or reference number matching the business case identifier of the notification or the response.

Yes

Status Code

Status code of the acknowledgement.

Yes

Status Message

Status Message String

No

Originating Authority

For an IN_Ack: in the legislation this field is represented as ‘Destination Competent Authority Identifier’.

For an IR_Ack: in the legislation this field is represented as ‘Acknowledging Competent Authority Identifier’.

Yes

Licensing Authority

For an IN_Ack: in the legislation this field is represented as ‘Acknowledging Competent Authority Identifier’.

For an IR_Ack: in the legislation this field is represented as ‘Destination Competent Authority Identifier’.

Yes

Acknowledgement Type

Defining Acknowledgement Type

Possible Values:

‘IN_Ack’

‘IR_Ack’

Yes

Check Community Licence

Check Community Licence Request

Mandatory

Business Case Identifier

A serial or reference number identifying each individual request.

Yes

Originating Authority

The authority issuing the search request.

No

Transport Undertaking

Yes

Transport Undertaking Name

The name of the transport undertaking for which the community licence details are requested.

Yes

Community Licence Number

The serial number of the certified true copy of the community license for which the details are requested.

Yes

Vehicle Registration Number

The vehicle registration number for which the certified true copy of the community licence is issued.

No


Check Community Licence Response

Mandatory

Business Case Identifier

A serial or reference number identifying each individual request.

Yes

Originating Authority

The authority that issued the search request.

No

Transport Undertaking

Yes

Transport Undertaking Name

The name of the transport undertaking (name and legal form) as recorded in the register.

Yes

Transport Undertaking Address

The address of the transport undertaking (address, postal code, city, country) as recorded in the register.

Yes

Community Licence Details

Yes

Licence Number

The serial number of the community licence of the transport undertaking as recorded in the register.

Yes

Licence Status

The status of the community licence of the transport undertaking as recorded in the register:

‘Active’

‘Suspended’

‘Withdrawn’

‘Expired’

‘Lost/stolen’

‘Annulled’

‘Returned’

Yes

Licence Type

The type of the community licence as recorded in the register. A declaration of:

‘Community licence for passenger transport’

‘National licence for passenger transport’

‘Community licence for goods transport’

‘National licence for goods transport’

Yes

Start Date

The start date of the community licence.

Yes

Expiry Date

The expiry date of the community licence.

Yes

Withdrawal Date

The withdrawal date of the community licence.

No

Suspension Date

The suspension date of the community licence.

No

Suspension Expiry Date

The date on which the community licence suspension expires.

No

Managed Vehicles

The number of vehicles managed as recorded in the register.

Yes

Certified True Copy Details

Yes

Licence Number

The serial number of the certified true copy of the community licence of the transport undertaking as recorded in the register (this is the licence number that was received in the request).

Yes

Licence Status

The status of the certified true copy of the community licence of the transport undertaking as recorded in the register:

‘Active’

‘Suspended’

‘Withdrawn’

‘Expired’

‘Lost/stolen’

‘Annulled’

‘Returned’

Yes

Licence Type

The type of the certified true copy of the community licence as recorded in the register. A declaration of:

‘Community licence for passenger transport’

‘National licence for passenger transport’

‘Community licence for goods transport’

‘National licence for goods transport’

Yes

Start Date

The start date of the certified true copy of the community licence.

Yes

Expiry Date

The expiry date of the certified true copy of the community licence.

Yes

Withdrawal Date

The withdrawal date of the certified true copy of the community licence.

No

Suspension Date

The suspension date of the certified true copy of the community licence.

No

Suspension Expiry Date

The date on which the certified true copy of the community licence suspension expires.

No


ANNEX IV

TRANSLITERATION AND NYSIIS SERVICES

1.   The NYSIIS algorithm implemented in the central hub shall be used to encode the names of all the transport managers in the national register.

2.   Member States should always use the NYSIIS key as the primary search mechanism when searching the register for a transport manager via the CGR functionality.

3.   Additionally, Member States may employ a custom algorithm to return additional results.

4.   The search results will indicate via which search mechanism a record was found, either NYSIIS, or CPC or custom.


ANNEX V

SECURITY REQUIREMENTS

1.   HTTPS must always be used for the exchange of messages between the central hub and the national systems.

2.   National systems will use the PKI certificates provided by the Commission for the purposes of securing the transmission of messages between the national system and the hub.

3.   National systems shall implement, as a minimum, certificates using the SHA-2 (SHA-256) signature hash algorithm and a 2 048 bit public key length.


ANNEX VI

SERVICE LEVELS

1.   National systems shall fulfil the following minimum level of service:

1.1.

They shall be available 24 hours a day, 7 days a week.

1.2.

Their availability shall be monitored by a heartbeat message issued from the central hub.

1.3.

Their availability rate shall be 98 %, according to the following table (the figures have been rounded to the nearest convenient unit):

An availability of

means an unavailability of

Daily

Monthly

Yearly

98 %

0,5 hours

15 hours

7,5 days

Member States are encouraged to respect the daily availability rate, however it is recognised that certain necessary activities, such as system maintenance, will require a down time of more than 30 minutes. However, the monthly and yearly availability rates remain mandatory.

1.4.

They shall respond to a minimum of 98 % of the requests forwarded to them in 1 calendar month.

1.5.

When sending check good repute responses, infringement notification acknowledgements and check community licence responses in accordance with Annex VIII:

1.5.1.

They shall respond to requests within 10 seconds.

1.5.2.

The global request timeout (time within which the requestor may wait for a response) shall not exceed 20 seconds.

1.5.3.

They shall be able to service a request rate of 6 messages per second.

1.6.

National systems will not send requests to the ERRU hub at a rate exceeding 2 requests per second.

1.7.

Every national system shall be able to cope with potential technical problems of the central hub or national systems in other Member States. These include, but are not limited to:

(a)

Loss of connection to the central hub

(b)

No response to a request

(c)

Receipt of responses after message timeout

(d)

Receipt of unsolicited messages

(e)

Receipt of invalid messages

2.   The central hub shall:

2.1.

Feature an availability rate of 98 %.

2.2.

Provide to national systems notification of any errors, either via the response message or via a dedicated error message. The national systems, in turn, shall receive these dedicated error messages and have an escalation workflow in place to take any appropriate action to rectify the notified error.

3.   Maintenance

Member States shall notify other Member States and the Commission of any routine maintenance activities via the web application, at least 1 week before the beginning of those activities if technically possible.


ANNEX VII

LOGGING AND STATISTICS

1.   This annex provides details of logging and statistical data collected at the central hub, not at the Member States.

2.   In order to ensure privacy, the data for statistical purposes shall be anonymous. Data identifying a specific transport manager, transport undertaking or CPC will not be available for statistical purposes.

3.   Logging information shall keep track of all transactions for monitoring and debugging purposes, and allow the generation of statistics about these transactions.

4.   Personal data shall not be retained in the logs for more than 6 months. Statistical information will be retained indefinitely.

5.   The statistical data used for reporting will include:

(a)

The requesting Member State.

(b)

The responding Member State.

(c)

The type of message

(d)

The status code of the response.

(e)

The date and time of the messages.

(f)

The response time.


ANNEX VIII

USE OF ERRU

1.   CHECKING THE GOOD REPUTE OF TRANSPORT MANAGERS

When verifying through ERRU, in accordance with Article 11(4) of Regulation (EC) No 1071/2009, whether a transport manager has been declared in one of the Member States as unfit to manage the transport activities of an undertaking, Member States shall perform a broadcast CGR search by sending a Check Good Repute Request. The responding Member States shall reply to the request by sending a Check Good Repute Response.

2.   EXCHANGE OF INFORMATION ON INFRINGEMENTS

2.1.   When exchanging information on serious infringements through ERRU, in accordance with Article 13(1) of Regulation (EC) No 1072/2009 or Article 23(1) of Regulation (EC) No 1073/2009, the Member State of infringement shall notify the Member State of establishment in the event of one or more infringements committed by a transport undertaking, in the frame of Article 16 of Regulation (EC) No 1071/2009. The notification shall be carried out by sending an Infringement Notification Request.

2.2.   The Infringement Notification Request shall be sent as soon as possible, and at the latest within 6 weeks of the final decision on the matter. It will give the details of the infringements, the status of the penalties imposed and the penalties requested, if any, in the Member State of establishment.

2.3.   The Member State of establishment shall reply to the Infringement Notification Request by sending an Infringement Notification Response, as soon as possible and at the latest within 6 weeks of the final decision on the matter, informing of which, if any, of the penalties requested by the Member State of infringement have been imposed. If such penalties are not imposed, the Infringement Notification Response shall include the reasons therefor.

2.4.   In all cases, any Infringement Notification shall be acknowledged with an Infringement Notification Acknowledgment.

3.   CHECKING THE COMMUNITY LICENCE

3.1.   When checking the availability of the Community licence referred to in Article 4 of Regulation (EC) No 1072/2009 and Regulation (EC) No 1073/2009, a Member State may request, via a Check Community Licence Request sent to the Member State of establishment, the information on the Community licence mentioned in Article 16(2)(d) of Regulation (EC) No 1071/2009.

3.2.   The Member State of establishment shall reply by sending a Check Community Licence Response.


Top