COMMISSION STAFF WORKING PAPER

IMPACT ASSESSMENT

Accompanying document to the

PROPOSAL FOR A REGULATION OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL

ESTABLISHING A REGISTERED TRAVELLER PROGRAMME

TABLE OF CONTENTS

1........... Procedural issues and consultation of interested parties. 5

1.1........ Background. 5

1.2........ Consultation of interested parties. 6

1.3........ Data gathering. 10

1.4........ Inter-service steering group. 11

1.5........ Impact Assessment Board. 11

2........... Problem Definition. 11

2.1........ Why the creation of an RTP is being examined?. 11

2.1.1..... Legislative and technical aspects. 12

2.1.2..... Operational and practical aspects. 15

2.1.3..... Fundamental right issues. 16

2.2........ Problem: how to design an RTP?. 17

2.2.1..... The core features of an RTP. 17

2.2.2..... Could these features be provided through existing systems?. 17

2.3........ Design issues. 19

2.3.1..... Lodging an application for an RTP. 19

2.3.2..... Data storage. 20

2.3.3..... Vetting criteria. 21

2.3.4..... Automation of border control for registered travellers. 21

2.3.5..... Application fee. 21

2.4........ Baseline scenario - how will the situation evolve if no new action is taken at EU level?. 21

2.5........ Subsidiarity. 24

3........... Objectives of the RTP. 24

4........... Policy options. 25

4.1........ Policy option 2: Data storage. 25

4.1.1..... An RTP based on data stored in a separate token (sub-option 2a) 25

4.1.2..... An RTP based on data stored in a centralised database (sub-option 2b) 26

4.1.3..... An RTP based on data stored in a separate token combined with a central repository (sub-option 2c) 27

4.2........ Policy option 3: Vetting criteria. 28

4.2.1..... Same as for multiple-entry visa holders (based on current EU law) (sub-option 3a) 28

4.2.2..... More thorough vetting procedure (sub-option 3b) 28

4.2.3..... Discarded sub-option: Involvement of third countries in the vetting (sub-option 3c) 28

4.3........ Policy option 4: Automation of border control for registered travellers. 29

4.3.1..... Fully automated (sub-option 4a) 29

4.3.2..... Semi-automated (sub-option 4b) 29

4.4........ Policy option 5: Application fee. 29

4.4.1..... Fee of 20 EUR (sub-option 5a) 29

4.4.2..... No fee (sub-option 5b) 30

5........... analysis of impacts. 30

5.1........ Policy option 1: Lodging an application for an RTP. 31

5.2........ Policy option 2: Data storage. 31

5.2.1..... Data stored in a token (sub-option 2a) 31

5.2.2..... Data stored in a centralised database (sub-option 2b) 32

5.2.3..... Data (unique identifier i.e. application number) stored in a token and (unique identifier, biometrics and data from applications) in a central repository (sub-option 2c) 33

5.2.4..... Costs (all sub-options) 34

5.2.5..... Protection of fundamental rights, particularly privacy and data protection. 35

5.3........ Policy options 3 and 4: Vetting criteria and automation of border control 36

5.3.1..... Costs. 39

5.3.2..... Protection of fundamental rights, particularly privacy and data protection. 39

5.4........ Policy option 5: Application fee. 41

5.4.1..... Fee of 20 EUR (sub-option 5a) 41

5.4.2..... No fee (sub-option 5b) 41

5.4.3..... Costs (both sub-options) 41

6........... Comparison of options and identification of preferred policy option. 42

6.1........ Comparison of options. 42

6.2........ Preferred policy option. 46

6.3........ Assessment and considerations of EU added value, proportionality and legislative implications 51

6.3.1..... European value-added and proportionality. 51

6.3.2..... Legislative implications. 51

6.3.3..... Measures to ensure data protection and protection of the rights of travellers. 52

7........... Monitoring and evaluation. 53

ANNEX 1. 57

ANNEX 2. 58

ANNEX 3. 63

ANNEX 4. 65

ANNEX 5. 66

ANNEX 6. 75

ANNEX 7. 77

ANNEX 8. 83

ANNEX 9. 85

ANNEX 10. 86

1. procedural issues and consultation of interested parties

1.1. Background

The present impact assessment report and the legislative proposal it accompanies[1] are to be seen in the context of the progressive establishment of a European model of integrated border management of the external borders. The legislative proposal is part of the "next generation of border checks" package which is a strategic initiative in the Commission's Work Programme for 2012[2]. This package responds to two major and interconnected challenges: how to efficiently monitor travel flows and movements of third-country nationals across the external border for the Schengen area as a whole, and how to ensure that border crossings are fast and simple for the growing number of regular travellers that constitute the vast majority of border crossers, i.e. those fulfilling all entry conditions. This report addresses the second challenge: a separate report[3] and legislative proposal address the first one. The two reports and proposals are not dependant on each other as regards their implementation but a solution needs to be found to calculate the time spent in the Schengen area if fully automated border crossings would be provided for third-country nationals. An Entry/Exit System (EES) which is reflected in the second report and proposal would be a solution for that.

In its Communication of 13 February 2008 preparing the next steps in border management in the European Union[4] the Commission suggested the establishment of a Registered Traveller Programme (RTP[5]) for frequent and pre-vetted third-country national travellers. Such a programme essentially entails that certain groups of third-country nationals would benefit from facilitated border checks when entering the Schengen area, checks which are at least partly automated through the use of Automated Border Control (ABC) technology. The Communication was accompanied by an impact assessment report[6].

The RTP was endorsed in the "Stockholm Programme"[7] agreed by the European Council in December 2009, which highlighted that the Union must continue to facilitate legal access to the territory of the Member States. The RTP was included in the overview among the initiatives announced in the Action Plan Implementing the Stockholm Programme[8].

A Commission Communication in July 2010 on information management in the area of freedom, security and justice[9] presented an overview of the EU-level measures in place or planned that regulate the collection, storage or cross-border exchange of personal information for the purpose of law enforcement or migration management. It set out the conditions the Commission will apply in future when assessing any new system in this area including the approach of "privacy by design"[10]. It also drew the lessons of the development of other major systems in this area such as VIS and SIS II and concluded that 'as a possible safeguard against cost overruns and delays resulting from changing requirements, any new information system in the area of freedom, security and justice, particularly if it involves a large-scale IT system, will not be developed before the underlying legal instruments setting out its purpose, scope, functions and technical details have been definitively adopted.' It emphasised too that particular attention must be paid to the initial design of governance structures and pointed to the role that the new IT agency[11] could have in providing technical advice.

The Visa Information System (VIS), which manages the exchange of short-stay visa data between the Schengen and Schengen Associated states, started operations on 11 of October 2011 at the consulates in North Africa and 20 days after go-live of the VIS also at the border crossing points (verification of visas against the VIS).

The Conclusions of the European Council of 23 and 24 June 2011 called for work on "smart borders" to be moved forward rapidly. In response, the Commission adopted on 25 October 2011 a new Communication on the various options and the way ahead[12]. It concluded that the RTP would speed up the border crossings of 4-5 million travellers per year and lay the basis for enhanced investments in automated border control technologies at major border crossing points.

Against this background, the present impact assessment examines different implementation options in order to find the best possible way to implement the RTP. However, the impacts of the whole RTP are analysed based on the specific options.

The present report constitutes both the ex-ante evaluation required for programmes or activities occasioning expenditure from the EU Budget, and the impact assessment that will accompany the legislative proposal for the RTP.[13]

1.2. Consultation of interested parties

The Commission considered that before proposing any new initiative, an in-depth technical assessment and debate and with all relevant stakeholders on the future architecture of the RTP was necessary.

Based on the discussions and positions received from different stakeholders on the 2008 impact assessment and communication, the Commission identified the following interest groups as the most relevant stakeholders for consultation: Member States, the European Parliament, the European Data Protection Supervisor (EDPS), civil society and the private sector.

The consultation was carried out in several ways:

· publishing the 2008 impact assessment and communication;

· presenting a comprehensive technical assessment of the system and compilation of Member States' responses (three meetings with the Committee on Immigration and Asylum and two meetings with two different working groups of the European Security and Research Innovation Forum (ESRIF);

· distributing questionnaires to Member States;

· organising seminars and meetings including specific expert meetings and stimulating them with the discussion papers;

· meeting stakeholders bilaterally;

· publishing the 2011 Communication;

· giving presentations on the RTP and automation of border control at different fora.

Stakeholders views

Member States

The RTP has been under discussion at meetings with Member States' experts since 2008. A majority of Member States support the establishment of the RTP. During the consultations on the Commission's communication adopted in 2011, five Member States had doubts about the benefits of the RTP. Based on them the administrative burden should not be higher compared to the normal border check process. Furthermore, the high costs, solid cost-benefit analysis and the low number of travellers crossing their part of the external border were mentioned.

Member States are in favour of collecting a fee from the applicants for participation in the RTP. A large majority of Member States prefer to store information on Registered Travellers in a centralised database and consider that the implementation of ABC should be voluntary for them. However, there are concerns especially regarding the costs, vetting criteria/vetting procedure and lodging and examining of applications. Slightly divergent views exist on whether a fully automated or semi-automated system should be used, where applicable. Many third countries are also taking forward similar initiatives in this field, as shown through several meetings at the level of ministers and with senior officials from countries such as the USA and Canada.

In preparation for the conference on Innovation Border Management organised by the Danish presidency and the Netherlands on 2 and 3 February 2012 in Copenhagen, Member States replied to the Presidency's questionnaire on the RTP and the EES[14]. According to these replies, a majority of Member States support the establishment of the RTP but most of them did not indicate their practical or technical implementation preferences.

The summary of the conference prepared by the Presidency[15] concluded that the RTP would bring significant benefits for the border check procedure, providing a possible means for a more effective deployment of border management resources from 'low-risk' to 'high-risk' passengers. This could help enhance security and reduce illegal migration, while providing travellers and business with cost-effective border passage services. However, some technical and political questions need to be discussed such as the storage of the data and the possible use of a token, the abolition of the obligation to stamp the passports and the full respect of privacy of the traveller including data protection. The Presidency conclusions were presented at the JHA Council on 8 March 2012.

During the consultations Member States commented on the specific options of the RTP (for example data storage) only at a very general level asking the Commission to come forward with the legislative proposals.

European Parliament

In its resolution on the February 2008 Communication, the European Parliament (EP) supported in principle the concept of the RTP and advocated a harmonised approach. The Parliament expressed doubts about establishing a new centralised database and was also concerned about the costs of the proposed system(s), stressing that all investments should be economically justified on the basis of benefits, and should produce mission value.[16]

The EP did not submit its opinion on the 2011 communication.

At the conference on Innovation Border Management on 2 and 3 February 2012 in Copenhagen, Members of the European Parliament expressed the view that the SIS II and the other IT tools actually under development should be in place and evaluated before the work on the RTP can be started.

European Data Protection Supervisor

On 7 July 2011 the European Data Protection Supervisor (EDPS), in his opinion[17] on the communication of the Commission on Migration[18], stressed the need to assess the use of existing systems before proposing any new ones. The EDPS was not fully convinced that the RTP is really necessary.

The EDPS was also consulted informally on the 2011 Communication on smart borders before its adoption. In his informal comments, the EDPS highlighted that the RTP proposal has to be supported by clear proof of its necessity and effective evaluation of current measures. He stressed: a) the principle of "privacy by design" e.g. designing the system in a way that limits its data protection impact, b) that only a one to one verification of biometrics should be possible, c) that no record on border crossings should be stored in the RTP, d) that data protection rights have to be ensured and e) that measures are taken to prevent "positive discrimination" from turning into "negative discrimination" of persons who are for example infrequent or first-time travellers. Furthermore, he asked to clarify which sources of data will be used for vetting.[19]

The EDPS provided comments on a draft of this impact assessment as well on a draft of the legislative proposal by letter of 10 August 2012. While welcoming the attention paid to data protection he considered inter alia that the transparency and legal certainty should be ensured, retention period should be limited in certain cases and Member States should not be allowed to store the data in national files.

Article 29 Data Protection Working Party

The Working Party addressed a letter to Commissioner Malmström on 12 June 2012 reacting to the 2011 Communication. It stressed that convincing evidence should be provided that the RTP would significantly facilitate access to the EU for registered travellers without placing an extra control burden on non-registered travellers. The Working Party also asked to consider all possible options for limiting the storage of personal data to the smallest amount possible. Furthermore, the Working Party highlighted that the vetting criteria should be clear and transparent, and that the final decision to grant/refuse access to the RTP would have to be made by a human being.

Civil society and the private sector

Civil society (academia, think tanks and NGOs), the private sector and FRONTEX[20] participated actively in the debate and organised several relevant conferences. Civil society provided input in various conferences and academic papers published on the subject. Civil society and the private sector support the establishment of the RTP[21]. The industry dealing with biometrics and manufacturing border control equipment asked for a harmonised approach to the RTP and minimum technical standards for equipment.

At the conference in Copenhagen a representative of IATA expressed support for an RTP. However, he stressed that the RTP should not lead to additional costs or burdens for airlines or airports.

The present report takes into account the questions and challenges raised by the stakeholders. Further details of the results of these consultations have been integrated in the choice of options and in the assessment of impacts. By organising series of meetings and presenting one impact assesment and two communications opening for input for all stakeholders during a period of four years, the Commission has done its utmost in seeking the views of all stakeholders concerned. Minimum standards for consultation were met.

1.3. Data gathering

Data-gathering and consultations with relevant authorities in the Member States and other stakeholders were undertaken by the Commission. The 2008 impact assesment showed the lack of data especially as regards exact travel flows and the time needed to cross the external border.

Therefore, the following types of data were of principal interest:

· Information on current and future size of travel flows at the external border; distinguishing between types of borders (air/sea/land) and groups of travellers (EU citizens and visa exempt/required third-country nationals);

· Time currently needed for border checks.

Data used was collected through questionnaires[22] as well as case studies, pilot projects and literature reviews and was used in particular for describing the context, defining problems, specifying the most important implementation options and finally analysing the impacts. Comparable data were gathered on entries and exits and also on the time needed to carry out border checks on different categories of travellers at different types of external borders. However, shortcomings in the availability and/or comparability of existing statistical data and the fact that many aspects (customs check, security check, infrastructure, etc.) affect the time needed for border crossings has made comparison and analysis difficult. With regard to numbers and forecasts of traffic of passengers it is important to note a wide disparity in the information available according to the different means of transport. If the information on air transport is reliable due to the particular challenges for this sector, it is much more reduced in relation to other modes of transport and it is obviously lacking in the case of people travelling by their own means of private transport.

With the help of FRONTEX the existing national ABCs based on Electronic Machine Readable Travel Documents in the EU as well as in third countries were analysed[23].

1.4 Inter-service steering group

An inter-service steering group (ISG) was set up on 29 September 2009 involving the Legal Service (SJ), the Secretariat-General (SG), DG Taxation and Customs Union (TAXUD), DG Enterprise and Industry (ENTR) and DG External Relations (RELEX). The group met on 2 October 2009 and, joined by DG Justice, Fundamental Rights and Citizenship, on 2 December 2010, on 16 February 2011 and on 31 January 2012. The last ISG meeting was also attended by the representatives of DG Mobility and Transport (MOVE) and of the Joint Research Centre (JRC). Communication between the members of the group was also conducted via e-mail and telephone.

1.5 Impact Assessment Board

The Impact Assessment Board (IAB) reviewed the draft impact assessment and delivered its opinion on 14 March 2012. The recommendations for improvement were accommodated in the final version of the report. In particular, the following changes were made: baseline scenario was sharpened and clarified; problem definition was widened including lessons learnt from the development of other large scale IT-systems and lessons learnt from Automated Border Control systems and national RTPs implemented in Member States and non-EU states; links to the Annexes and to the 2008 impact assessment were improved; stakeholders views were reported as widely as possible taking into account that views expressed by the stakeholders were quite general; the explanation of method used for calculating the costs was expanded and the expected costs and benefits for different stakeholders were more rigorously reported; re-affectation of border guards taking into account the expected increase in travel flows was clarified; and finally a clear overview on the European Data Protection Supervisor's views was added.

2. Problem Definition

2.1. Why the creation of an RTP is being examined?

The 2008 impact assessment identified and examined the main problems for a better management of migration flows. That impact assessment concluded that an RTP for third-country nationals should be established in the future, but did not discuss comprehensively all the relevant and important issues for the implementation of the EU wide RTP such as implementation options, costs and fundamental right aspects. As explained in the 2011 communication:

A RTP would significantly facilitate border crossings for frequent, pre-vetted and pre-screened third-country travellers at the Schengen external border. It would reduce the time spent at the border crossing points and facilitate travel and cross-border contacts. As far as possible, it would make use of new technologies such as Automated Border Control systems (used also for EU travellers) moving towards EU smart borders.

It is now time to assess the exact design of the system based on the specific implementation options identified during the consultations. Before discussing how best to design such a system, it is useful to recall the main aspects of the problems it will address because the nature and scope of these problems have direct implications for design choices. In the continued absence of an EU RTP for third-country nationals the basic problem remains the same as in 2008. Therefore the current problem definition is built on the previous impact assessment. However, the data gaps identified in 2008 were solved by organising data collection exercises at the external border and collecting information from Member States via questionnaires. The baseline scenario (status quo in 2008 impact assessment) is almost the same in the 2008 and 2011 impact assessments. The main differences between the two are that the VIS started operations and more ABC systems are implemented for EU citizens at the external border crossing points.

The following issues are not included in the selection and definition of implementation problems to be assessed, taking into account policy choices already made, input during the stakeholder consultation, and in view of the need to focus on the main implementation problems.

The scope of the RTP (only visa-exempt or all third-country nationals) and the use of different types of biometrics are not discussed in this impact assessment as they were discussed in the previous impact assessment and in the February 2008 Communication. First, current border checks do not distinguish between persons holding a visa and those that do not. A programme that aims at facilitating border checks for third-country nationals should therefore also not distinguish between these groups. Secondly, the same biometric identifier – fingerprints - should be used in the RTP as already decided at EU level with regard to the VIS, e-passports and residence permits.

Based on the evaluation carried out by Frontex, there has not been any major changes in technology or functioning of ABC systems since the 2008 impact assessment was carried out[24]. The forms of national RTPs have also followed the same approach as in 2008. They are developed for EU citizens and require enrolment of biometric data. The continued use and possible small increase of national RTP is not relevant in the selection and definition of implementation problems to be assessed, as the basic scope is different: a national RTP is for EU citizens, while a EU RTP will be for third-country nationals.

2.1.1. Legislative and technical aspects

EU law requires that systematic checks are carried out at the Schengen external borders on all travellers (both on entry and exit). The Schengen area without internal border controls currently includes all Member States except Romania, Bulgaria, Cyprus, UK and Ireland and four other European countries (Norway, Iceland, Switzerland and Liechtenstein). Schengen states are committed to maintaining common EU borders and common standards for border controls.

Thorough checks are normally carried out on third-country nationals, and minimum checks on EU citizens and persons enjoying the right of free movement[25]. As illustrated in Annex 2, current rules for third-country nationals could be described as "one-size-fits-all" as the same checks apply regardless of any differences in risk between different travellers or their frequency of travel. This is because current legislation does not allow for exceptions to the principle of thorough border checks except for those categories of third-country nationals that are specifically mentioned in the Schengen Border Code[26] or in the Local Border Traffic Regulation[27] such as Heads of States and border residents.

Only a very small minority of persons crossing the external border are able to benefit from the above-mentioned exceptions: approximately two million equivalent to 0,2 % of total passenger flows. This number can be expected to remain largely constant, with a marginal increase due to an increased take up of local border traffic regimes. By the end of 2010, 110 000 local border traffic permits were issued by Member States.

While the Visa Code allows frequent travellers to be issued with a multiple-entry visa, thereby avoiding the situation where those travellers would need to apply for a visa for each journey into the Schengen area during a five year period, multiple-entry visa holders do not benefit from any facilitation at the actual border crossing.

Border checks on EU citizens can be automated, based on the current legislation, if they hold an e-passport (also called biometric passport) which stores biometric data of its holder (facial image and, as of 2009, fingerprints). Several Member States have already implemented such ABC systems at their airports. Only Portugal has implemented ABC systems at all international airports and the UK several airports as can be seen from Annex 3. Other Member States have implemented them only at their biggest airports. The ABC process is described in Annex 2, chapter 2 but in principle it is the same as in the manual border check booth but, in this case, is carried out by a machine.

Although ABC systems are widely used by Member States and non-EU Member States alike as illustrated in Annexes 3 and 4[28], they still follow the same principles as they did in 2008. The main lessons learnt and the main rationale behind the ABC systems are to improve the accuracy and efficiency of border checks by enabling the accurate verification of travel documents and identification of travellers with biometric data. Automated border controls have a positive effect on deterring forged or stolen passports and improving identity verification. Furthermore, they increase throughput capacity at border crossing points and border efficiency by allowing border guards to focus on higher risk travellers or serve other travellers not using ABC. A majority of ABC systems rely on an e-passport.

Some Member States have implemented a form of national RTP for EU citizens[29]. The main feature of national RTPs is that they do not rely on the e-passport. Therefore the traveller needs to be pre-enrolled before being granted access to the RTP i.e. biometric data must be captured and stored in a database or in a token.

Many non-EU countries such as the US, Canada, Australia and Singapore have also automated their border check procedures based on the same type of technology. The access granted for these programmes are limited. They are established only for their own citizens or their own citizens and neighbouring country citizens. However, as the figures in Annex 4 demonstrate some of the programmes have numerous participants; Singapore eIACS system has three million users and the US systems have one million users. The average processing time at the gate is 12 seconds for all the systems described in Annex 4.

The rationale behind the national RTPs and the main implementation choices made have not changed since 2008 impact assessment. The essential elements of the implemented RTPs are:

· Ensuring that registered travellers do not present a risk in terms of irregular immigration or internal security. This is generally done by:

– Undertaking a risk assessment prior to the registration. For instance people are checked against watch lists and other police databases. Biometrics may also be collected for undertaking security searches in police databases (i.e. biometrics are collected, stored and used to run security checks in the US, Canada, the Netherlands, Germany and France).

– Restricting the eligibility of participants. For instance, in France and the Netherlands only EU, EEA and Swiss nationals can participate; in the APEC countries the scheme is open only to business people that are frequent travellers and national of countries participating into the scheme.

– Eligibility might be extended to non-nationals providing that certain security conditions are met. For example, participants to the APEC business Card are checked against watch lists of all participant countries and the US/NL citizens can join the FLUX programme after vetting is done by both parties and green/red light exchanged.

· Ensuring faster border checks. This is done by creating ABC systems or self-service kiosks and creating separated lanes.

· Ensuring the integrity of border checks by undertaking random checks.

· Verification of travellers’ identities with biometric checks. All the schemes use biometrics.

However, under current EU law, this kind of automated process cannot be used for third-country nationals. The thorough border check requires border guards to interview a traveller and manually stamp his/her travel document and to calculate the time spent in the Schengen area, processes which cannot be automated, and, as described above, the legislation limits the exceptions that can be made to this rule.

At the moment, several systems such as the SIS, the VIS, EURODAC and API (Advanced Passenger Information) are used at the external borders. These systems, their legal basis, objectives and some statistics are described in Annex 5. Some of the existing systems such as the VIS and the SIS would have a strong managerial, technical and border check procedural link with the RTP as explained in Annex 6. As a summary, the same technical solutions and equipment already used for the VIS and the SIS at consulates and at external border crossing points could also be used for the RTP purposes.

In summary, the current legal and technical context present the following problems:

– only a very minor share of third-country nationals can benefit from any kind of facilitated or simplified border check, and Member states border guard authorities have no possibilities to distinguish between travellers presenting a lower level of risk or an unknown level of risk,

– existing technical means, in the form of automated border control and registered traveller programmes, can only be used for EU citizens and at national level, not for third-country nationals or for the Schengen area as a whole.

2.1.2. Operational and practical aspects

Current travel flows at the EU external border and potential target group for the RTP

According to the most recent comprehensive data provided by the Member States, there were 669 million external border crossings in 2009, 675 million in 2010 and 700 million in 2011, including EU citizens and third-country nationals. The number of border crossings did not increase significantly during the past few years, presumably because of the economic downturn. The overwhelming majority of passengers are travellers who comply with all the existing rules. At the busiest and largest border crossing points Member States have problems managing existing passenger flows and therefore they have started using ABC systems for EU citizens.

To gather comparable data on border crossings, the Czech and Swedish Presidencies together with the Commission organised a data collection exercise at all external border crossing points from 31 August to 6 September 2009[30]. Based on the data collected during this exercise, 73,5 % of travellers crossing the border are EU citizens or persons enjoying the right of free movement (9,1 million/week), 15,2 % are third-country nationals without a visa (2,1 million/week) and 11,3 % are third-country nationals holding a visa (1,4 million/week).

It would, however, be wrong to assume that all third-country nationals are a potential target group for an RTP, as several factors must be taken into account. Not all third-country nationals are frequent travellers and thus not willing or eligible to join the RTP. An important element to highlight is that, based on some Member States' estimates, 10 % of travellers can make up 70-80 % of overall border crossings at certain border crossing points. In other words, the share of the total travel flows made up of frequent travellers is more interesting and relevant than the share of persons crossing the border. Fluidity of border crossings and throughput capacity of border crossing points can be greatly improved even if only a small percentage of third-country nationals were to join the RTP. Moreover, the number of third-country nationals crossing the border differs significantly among Member States and also among border crossing points. As an illustration: during the one week period of the 2009 data collection exercise, over three million travellers crossed the borders of Spain whereas the figure was 8 000 to Luxembourg. Most third-country nationals, including visa-holding third-country nationals, cross the border via land borders, the next largest number by air borders and the smallest via sea borders.

Nevertheless, it is reasonable to assume that many third-country nationals cross the borders several times a year. For example, business travellers, workers on short-term contracts, researchers, students, third-country nationals with close family connections to EU citizens and third-country nationals living in regions bordering the EU are all likely to make multiple border crossings in a given year. These third-country nationals are the main target group for the RTP. Approximately 11 million Schengen visas are issued every year[31]. On average around 20 %[32] of visa applications are for multiple-entry visas, which could entail around 2.2 million third-country nationals among visa holders crossing the external borders several times per year. Considering the needs of business and economic cooperation including constant international travel, the demand should, at least, be similar among non visa holders. Based on the above reasoning, it is estimated that maximum of 5 million new applications for the RTP would be submitted by third-country nationals every year. As statistics on third-country nationals' border crossings per nationality and/or statistics on the reasons for applying a multiple-entry visa do not exist at the EU level, more detailed evidence on the expected breakdown of potential candidates by region or professional status cannot be provided.

During the above-mentioned one week period 6,5 million travellers crossed the border via air borders. 2,6 million of them (40%) crossed the air border via the 10 busiest airports of the EU and 3,7 million (57%) via the 20 busiest airports[33].

It is important to know the existing border check time, as even small change in it per traveller could remarkable affect the overall time needed to cross the border. According to the Member States' replies to the questionnaire prepared by the Czech Presidency together with the Commission, average time for a border check for visa holders on entry at air borders is 1 minute 44 seconds, for visa-exempt third-country nationals 1 minute 3 seconds and for EU citizens 15 seconds. The average time at air borders on exit is for visa holders 1 minute 11 seconds, for visa-exempt nationals 52 seconds and for EU citizens 15 seconds. Average border check for third-country nationals last at land borders 10-30 seconds longer than at air borders. Average border check times at land borders are reported in Annex 2. At sea borders the average times are quite similar than at land borders.

In summary, the operational and practical context presents the following problems:

– an already massive travel flow at the EU external border can be expected to further increase,

– border checking times is significantly longer for third-country nationals compared to EU citizens, and can be expected to further increase due to the implementation of the VIS.

2.1.3 Fundamental right issues

Data protection is a fundamental right enshrined in Article 8 of the Charter of Fundamental Rights of the European Union and has to be protected accordingly.

Initiatives in the area of freedom, security and justice for the purpose of border management or law enforcement which include the collection, storage and use of personal information pose significant challenges in terms of achieving the right balance between the legitimate aim of maintaining internal security or managing migration and the individuals’ right to privacy and data protection. Interference with the right to privacy should be considered necessary if it answers a social need and if it is proportionate and justified with regard to the aim pursued.

With the RTP the Data Protection Directive 95/46 applies and mechanisms shall be established for the effective protection of the fundamental rights of third-country travellers who are willing or who have been accepted to the programme.

In addition, the basic instruments need to be complemented by laying down specific rules on certain aspects of the protection of personal data i.e. specify the purposes for collecting and accessing the relevant personal data, the competent authorities which have access to these data, to the extent of the access, the retention of the data, the rights of the data subjects, which personal data shall be processed in the system and the competence of the supervisory bodies for monitoring the processing of data, both as regards the Member States and Community institutions and bodies; for the supervision of the latter the European Data Protection Supervisor is the competent authority.

2.2. Problem: how to design an RTP?

2.2.1. The core features of an RTP

The common features of an RTP which would be necessary in order to develop it in the first place need to be defined without prejudice to any choice on how it should be implemented. These core features, which formed part of the preferred option of the impact assessment carried out in 2008, can be defined as follows: a programme which allows certain third-country nationals to benefit from a facilitated border check (as opposed to the current rules on a thorough border check for all third-country nationals), during a given period of validity, and which involves using new technology to either semi-automate or fully automate the border check process. Participation in the programme would be subject to a pre-screening which would involve the vetting against certain criteria and the enrolment of personal data, including biometrics. The RTP would not change the requirement of obtaining a visa, if applicable. Finally, the RTP and all processes involved (data on application, pre-screening etc.) would be designed so that they adhere to data protection rules and do not decrease the level of border check security compared to the baseline situation.

Taking into account that border checks are currently fully harmonised at EU level, an EU RTP must be implemented in a harmonised way in the whole Schengen area with regard to the above criteria. The third-country nationals participating in the RTP would benefit from the same facilitated border checks at all parts of the external borders of the EU (of all Schengen Member States) and can use ABC systems wherever available.

2.2.2. Could these features be provided through existing systems?

The existing systems, the SIS, the VIS or EURODAC, cannot be used for the RTP purposes as they are developed for distinct and different purposes, namely, to enhance security of the Schengen area, to manage visa applications and to manage asylum applications whereas the RTP would facilitate travel. To expand the functionalities of the VIS and/or the SIS and/or the EURODAC would require a complete change of the legal basis and current capacity limitations could only be overcome by significant further investments. The VIS feasibility study, carried out in 2003 before the development of the VIS, suggested that it would not be beneficial to develop several large-scale IT systems as one. The workflow of the VIS is optimised to deal with 10 million visa applications per year. Adding 5 million RTP applications to top of that would require significant investments especially with hardware, software, data storage and communication infrastrucure. Furthermore, working processes should be changed as the VIS would cover both visa holders and visa exempted. Moreover, there would be significant data protection implications if the system were to include both visa holders and visa-exempt persons.

Border guards' work at the external border crossing points would be more difficult and time-consuming if the security and facilitation tools (for example the SIS/VIS/EURODAC and the RTP) were to be mixed. The different types of alerts and information would be delivered by one system and border guards would every time need to verify very carefully whether the information received concerns security or facilitation aspects. At the moment, border guards know immediately that there is an important issue with the traveller and a more thorough check is required, if an alert is distributed by the SIS.

Moreover, the principle of purpose limitation needs be adhered to and the risk of "function creep" has to be prevented as highlighted by the EDPS in his opinion on the Commission Communication on migration[34]. With regard to Advanced Passenger Information (API) and Passenger Name Record (PNR) the situation is even more difficult as the API directive is implemented differently in Member States, no central component exists, data submitted by carriers is limited and the quality of data, even though reliable, does not meet the requirements of the RTP. The same applies to the PNR. Therefore the possibility of including the RTP functionality in the VIS/SIS/EURODAC/API/PNR itself/themselves can be discarded. Nevertheless, intelligent use could be made of possible synergies with technical equipment already in place as described in Annex 6.

In addition, there would be major technical and functional links between the VIS and the RTP. The technical development of an RTP should exploit technical synergies, organisational simplification and economies of scale to the maximum by using the same technical platform as the VIS. Biometric matching functionality could be performed by the existing Biometric Matching System, which already provides such a functionality for the VIS. However, the biometric data stored in the VIS could not be legally exploited by the RTP as the VIS is systematically checked only on entry wheras the ccess granted to the RTP (and biometrics) should be checked both on entry and exit.Although some Member States have implemented a national form of the RTP, those RTPs cannot be expanded or used as a platform for the EU wide RTP. National RTPs are developed mainly for EU citizens based on the national needs and technical specifications and they are not interoperable. Furthermore, already existing national RTPs neither store the data of entries or exits nor do they calculate the duration of stay within the Schengen area. Therefore, the Smart Borders Package (i.e. RTP and EES) specifically complements the required elements to attain the objectives.

Finally, building a new system upon existing national systems would contradict essentially the lessons learnt from the development of other large-scale IT systems, which were already presented in the 2010 Communication:

(a) it might lead to unpredictable technical problems and delays, especially for the adaptation of national systems and the migration of data;

(b) the development of the RTP shall not be started before the legal basis is in place, in order to avoid developing premature functional specifications;

(c) the Agency for the operational management of large-scale IT systems in the area of freedom, security and justice shall be entrusted to develop and operationally manage the centralised part of the system including uniform interfaces in Member States;

(d) the processes established with the new IT system shall follow the same principles as for VIS to make the process as easy as possible for border guards and consular authorities.

2.3. Design issues

There are a number of key choices that need to be made when designing an RTP. These choices must strike the right balance between maximising the overall usefulness and efficiency of the system in addressing the overall problem as described in section 2.1 and minimising its impact on fundamental rights. This involves choices both with regard to the overall architecture of the system and additional features in relation to the "core" system as described in section 2.2.1.

By maximising only usefulness and/or efficiency of the system there is a risk for ignoring other important aspects such as fundamental rights and vice versa. For example, the RTP could be designed so that it would be easy to use for border and consular authorities, any search criteria used would give access to all information (alphanumeric and biometric data) and flexible access rights would be given for all relevant authorities, even third countries. However, all this would cause huge data protection implications and would not be proportionate against the objectives of the RTP. The best possible balance must be found taking into account usefulness, efficiency, security and fundamental rights.

In summary the choices involve deciding the data to be collected and processed; defining with precision the purpose of the system; deciding the retention period of the data taking into account the purpose; and finally deciding on how to technically implement the system in practice.

2.3.1. Lodging an application for an RTP

The actual application process will need to be designed i.e. determining where should applications be submitted in practice. The overall take-up for participation in the programme will determine how many travellers will in practice be able to benefit from a facilitated check at the border and consequently directly impact on queuing times. The interest in the RTP among third-country nationals will greatly depend on how difficult or easy it will be to join the RTP. From the traveller's point of view one key issue is how convenient it will be for him/her to reach the office where (s)he will be able to lodge an application for the RTP. Generally, travellers are not willing to journey hundreds of kilometres to sign up to a voluntary system. This decision will also have an effect on the authorities obliged to receive and process the applications.

There would be three sub-options for lodging an application: a) at any external border crossing point, b) at any Member State consulate[35] and c) at both places.

Sub-options 1a and 1b would have a negative effect on the number of the RTP applications and thus would limit the advantages of the RTP. Sub-option 1a would require visa holders to submit two set of applications including supporting documents; first at the consulate for a visa and then at the external border for an RTP. This would require extra time and work from visa holders and one could estimate that 1/3 of potential registered travellers among visa holders equivalent to 800 000 third-country nationals per year would not be willing to do it i.e. would not apply for access to the RTP.

On the other hand, sub-option 1b would include extra costs and loss of time for visa-exempt nationals since this category of travellers would have to travel to the consulate to lodge their application for the RTP and have their biometric data captured. One could estimate that at least half of potential RTs among visa-exempt third-country nationals equivalent to 1,3 million third-country nationals per year would not apply for the RTP in the consulate.

Implementation costs for EU and Member States would only be between 1 to 5 million EUR more in case of the sub-option 1c – allowing the lodging of applications at the border crossing points as well as at the consulates – than either sub-option 1a or 1b. Comparing the costs and the effects of the sub-options against the number of the RTP applications sub-option 1c would clearly be the most cost-effective sub-option to meet the objectives "to facilitate the crossing of EU external borders and to promote access to the RTP". Furthermore, it would be coherent with the existing border and visa policy. Therefore, the chosen sub-option is 1c without further analysis. At Member States level all the implementation costs would fall on visa and border authorities. Allowing the traveller to choose the best place for him/her to lodge an application would guarantee a larger number of participants in the programme, thus helping Member States to manage their passenger flows at the external border crossing points.

It can be predicted that the applications would be directed to the most appropriate authorities: travellers requiring a visa would most probably lodge their applications at the consulates and visa-exempt travellers would do so at the border crossing points.

2.3.2. Data storage

The pre-screening will involve the enrolment of the applicants' personal data, including biometrics (fingerprints). The design of this part of the process is important for the overall security of the system, the potential impact on the fundamental rights of RTs, and the actual functioning of a facilitated check at the border. Persons without fingerprints or with unreadable fingerprints would need to be excluded from the RTP[36]. Alphanumeric data from the application file as well as biometrics specified in Annex 8 need to be stored somewhere, so border guards can verify at the border, whether the person is a registered traveller. The question therefore arises how and where that data should be stored and for how long, taking into account that it must be available to the border guard of any Member State where the person is physically crossing the border. Whenever new information systems and different ways of storing information are at stake, the respect of the Charter of Fundamental Rights of the EU, particularly the right to respect for private life and right to the protection of personal data, and the cost of the systems require a careful assessment before any final decisions are made.

The need for real-time information exchange between Member States will need to be considered, taking into account that one Member State's decision to grant/revoke/extend access to the RTP will determine whether a person will benefit from facilitated border checks at the external border of another Member State. Integration with existing processes at the external border and/or at the consulates should be ensured. Furthermore, security aspects of data storage need to be highlighted.

Whatever the system used to store the data, the effective implementation and enforcement of data protection rules must be ensured. Personal data should be protected against any unauthorised use. The right to access and verify the data, purpose limitation, etc. must be monitored.

2.3.3. Vetting criteria

The RTP requires that all participants are pre-vetted and pre-screened. The criteria for that process must therefore be defined, to ensure that the same criteria are applied by all Member States and that they meet the requirements in terms of preventing irregular immigration and ensuring security.

Vetting criteria should be proportionate in relation to both the internal security of the EU and the objectives of the RTP, as their definition will influence the take-up of the programme. Also, the time needed for examining and processing the applications as well as related costs should be taken into consideration.

2.3.4. Automation of border control for registered travellers

A key question involves defining how facilitated border checks should be implemented in practice at the border crossing points. In other words, as concerns RTs, how the current thorough border checks should be adapted for this specific group of travellers. Directly linked to the definition of "facilitation" is the question of automating border checks. To fully automate third-country nationals' border checks, a solution has to be found for calculating the period of authorised stay in the Schengen area at entry and exit or this requirement needs to be abolished as regards RTs. At the moment, the calculation is based on the stamps affixed on the third-country nationals' travel document.

Automation will significantly impact many issues, for example, the throughput capacity of border crossing points and hence the impact on border crossing times. It will also have an impact on the required space and human resources needed at the border crossing point, and naturally, it will significantly impact the traveller's border crossing experience. The overall benefits that will be derived from how facilitated border checks will be defined can subsequently be assessed against the costs for setting up the system (cf section 2.3.2. on data storage).

2.3.5. Application fee

Whether an application fee should be paid by the applicant would need to be decided. An application fee, if any could follow the same logic as the visa fee according to current EU legislation (60 EUR) i.e. the fee would be calculated so that it covers Member States' administrative costs for examining applications.

2.4. Baseline scenario - how will the situation evolve if no new action is taken at EU level?

Doing nothing at the EU level would mean that third-country nationals' border crossings could not be facilitated except those specifically mentioned in the SBC and the Local Border Traffic Regulation meaning that thorough checks would be applicable for third-country nationals and no access to ABC could be given for them. Taking into account that border crossings at the largest and busiest border grossing points have been increasing and will continue to do so in the future[37], Member States with problems managing queues already today would have no other tool than hiring more staff and rebuilding infrastructure if at all feasible; any future increase in travel flows would lead to more problems of this kind. Furthermore, the full roll-out of the VIS will worsen the situation at the external border crossing points and thefore longer queues are expected. All third-country nationals holding a visa will be verified against the VIS on entry by using the visa sticker number in combination with verification of fingerprints. The fingerprint verification against the VIS will start in 2014 and it will inevitably slow down the border check procedure by some tens of seconds per visa holder. To cope with the forecasted 80% increase of travel flows at the air borders and the verification of visa holders' fingerprints at entry, Member States would need to hire approximately 17 500 border guards more equivalent to costs of 542,5 million Euro per year across the EU. Any increase in travel flows at sea and land borders would require a proportionate increase of staff level. All the costs would fall on border guard administrations.

This impact assessment is prepared in parallel with the impact assessment on the creation of an EES. An EES would replace the current system of stamping passports with the electronic registration of the dates and place of entry and exit of third-country nationals admitted for short stays to the Schengen area to allow for accurate and reliable calculation of authorised stays. In order to fully meet its purpose, such a system should record visa holders' and non-visa holders' movements alike and be applied consistently at all border crossing points. An EES would be integrated into the ABC and would allow for fully automated border crossings for third-country nationals replacing current manual calculation of authorised stay based on the stamps in the passport. Without the EES fully automated systems could not be implemented for third-country nationals.

However, the RTP could be implemented without an EU-wide EES, but Member States would then have to implement a semi-automated border control for RTs meaning that after successfully passing through the automated part of the border control procedure (i.e. ABC gate), the RT would be guided to the border guard who would stamp the travel document and calculate the length of stay in the Schengen area. This would remarkable diminish the added value and attractiveness of the RTP.

The EES does not as such form part of the baseline for this impact assessment - the two systems (EES and RTP) are not dependent on each other as regards their implementation – but the potential development of an EES has to be taken into account in relation to automation of border control for third-country nationals.

In terms of national developments, a continued further introduction of ABC for EU citizens by Member States at major airports is likely, as is the further development of national RTPs. However, these developments are not relevant, as they only concern EU citizens, except with regard to the automated gates installed at border crossing points. Those same gates installed for EU citizens could largely be also used by third-country nationals if the EU RTP is implemented.

Currently, only one Schengen country has a project running at the air border crossing point with a third country based on semi-automated border controls both in the Member State and the third country[38]. Some other Member States may develop an RTP for third-country nationals based on this model. The overall impact of such systems with regard to facilitating travel flows of third-country nationals to the EU can however be assumed to be limited: they only involve a minimum facilitation of the border check (a semi-automated system). Moreover, such programmes can only operate on a bilateral basis based on an agreement between one Member State and one specific third country. The target group for this type of RTP is therefore also effectively limited to third-country nationals who cross the external border of the two countries at the same location each time. A widespread take up of such programmes will also be hampered by the exponentially increasing number of bilateral agreements needed should they involve several Member States and several third countries, with travellers obliged to carry out multiple registrations with each programme individually.

While the continued use and possible small increase of national RTPs described in section 2.1.1 forms part of the baseline for this impact assessment, it is not relevant for the problem definition or the assessment of the options, as the basic scope is different: a national RTP is for EU citizens, while a EU RTP will be for third-country nationals. Member States can thus continue to use their "national RTPs" also in the future[39], and these national RTPs would not affect the implementation of the EU-wide RTP discussed in this impact assessment. The EU RTP needs to be developed based on the common technical standards and it should be interoperable with the existing and future processes and workflows at the consulates and at the external border. Furthermore, synergies with the existing EU-wide systems should be exploited.

In general, no significant change is expected in the current situation with regard to third-country nationals' border checks. Therefore, the baseline for this impact assessment consists of the existing SIS[40], the successful roll-out of the VIS as well as the establishment of an Agency for the operational management of large-scale IT systems in the area of freedom, security and justice (the Agency)[41]. Other developments in the EU's policy on border management are not relevant here, such as changes to the legal framework of FRONTEX, the development of Eurosur, or other amendments to the Schengen Borders Code.

In summary, the baseline scenario can be described as the following:

– the current one-size-fits all approach to border checks of third-country nationals will continue with no possibility to distinguish between different travellers based on risk and no possibilities to provide a facilitated border check for low-risk, frequent travellers,

– assuming limited expansion of personnel numbers in the Member States, border crossing times will increase due to the higher passenger flows, use of larger passenger aircrafts and ferries/cruise ships, and the implementation of the VIS,

– border crossing times for EU citizens will decrease due to a continued take-up of ABC systems.

2.5. Subsidiarity

Under Articles 74, 77(2)(b) and 77(2)(d) of the Treaty on the Functioning of the European Union, the Union has the power to adopt measures relating to checks on persons and the efficient monitoring of the crossing of external borders.

The need for intervention at European level is clear. No Member State alone is able to build up an RTP providing facilitated border checks across the Schengen Member States. One individual Member State's decision to grant access to an EU-wide RTP would have an impact on all Schengen countries and must therefore be regulated at EU level. Any measures related to border control would have to apply to the Schengen area without internal border controls which currently includes all the Member States except Romania, Bulgaria, Cyprus, UK and Ireland and four other European countries (Norway, Iceland, Switzerland and Liechtenstein). Schengen states are committed to maintaining common EU borders and common standards for border controls. Checks are carried out only at the external border, after which the traveller can travel freely within the Schengen area.

It is vital for the internal security of the Schengen area that all the binding rules linked to border control are decided at EU level.

Therefore, the objectives cannot be sufficiently achieved by the Member States acting alone but can be better achieved at EU level.

3. objectives of the RTP

The general objectives of the RTP are:

· To facilitate the crossing of EU external borders by third-country nationals;

· To maintain the current level of security.

The specific objectives are:

· To promote access to the RTP for certain categories of frequent, pre-vetted third-country nationals;

· To ensure protection of registered traveller's fundamental rights, in particular their personal data;

· To avoid discrimination between different groups of travellers.

The operational objectives are:

· To decrease the time and costs of border crossings for frequent travellers and to increase the throughput capacity of border crossing points. Border checks of registered travellers should not take more than 20-40 seconds on average.

· To free up border control resources by 25% from checking cross border movements of frequent and pre-vetted travellers and to enable better focus on checking higher risk travellers[42] and/or serve other travellers.

4. policy options

In addition to the baseline, five policy options linked to the implementation of the RTP were identified during the consultation with stakeholders. Because stakeholders had diverging views on their implementation and in order to allow for a cost-benefit analysis, for each of these five policy options real practical implementation options have been defined.

The five policy options and their sub-options are independent implementation options for the RTP in the sense that the choice of one sub-option does not influence the choice of sub-options in relation to the other policy options. In total, there are 13 sub-options which could be combined into a large number of equally feasible combinations or "packages" which would have been impractical to analyse. For this reason, each sub-option has been analysed individually. It should be noted, however, that the impacts of policy options 3 and 4 and their sub-options are linked. Furthermore, as the best choice for the Policy option 1 "lodging an application for an RTP" is clearly the lodging of applications at both border crossing points and consulates (cf 2.3.1.), it is not discussed again in this section.

4.1. Policy option 2: Data storage

4.1.1. An RTP based on data stored in a separate token[43] (sub-option 2a)

Under this sub-option, the personal data (alphanumeric and biometric data)[44] enrolled from each successful RTP applicant would be stored on a chip on a plastic card ("token"), to be issued by the Member State having approved the application. The alphanumeric data (but not biometric) would be stored by the Member State in question in a national database. No European database would be set up nor any information exchanged at European level.

When crossing the border, using automated gates, the document reader incorporated into the gate would read the traveller's passport, the visa sticker if applicable, and the token. The traveller's fingerprints would be read by the fingerprint reader incorporated into the gate. Checks against databases (such as SIS and national databases) would be run using the data from the passport. The validity of the visa, if applicable, would be checked against the VIS. The traveller's identity and the access granted to the RTP would be verified against the data stored on the token (alphanumeric data and biometrics).

This sub-option would involve defining common technical standards for the token including security and layout aspects to guarantee interoperability and security across the Member States and visibility across the Schengen area. On the basis of the prior definition of business requirements for the token to be adopted by the Commission in a comitology procedure, the European Agency for the operational management of large-scale IT systems in the area of freedom, security and justice established by Regulation (EU) No 1077/2011 of 25 October 2011 (the Agency) would be responsible for the definition of the technical specifications for the token. The technical specifications would be agreed with Member States by the Commission in a Comitology procedure. It can be noted in this regard that the option of using an e-passport held by the third-country national as a token can be discarded from the start; not all third-country nationals are issued with e-passports, most if not all third countries issue e-passports with only the facial image as biometric identifier, and full access to the third-country national's data on the chip for all Member States' border guard authorities is not feasible within the short- to medium-term.

During the consultations on the Commission's communication adopted in 2011, one Member State was clearly in favour of a token-based system. The majority of Member Sates preferred a centralised system.

4.1.2. An RTP based on data stored in a centralised database (sub-option 2b)

Under this sub-option, a centralised database would be developed, in the form of a Registered Traveller System (RTS). Biometrics (fingerprints) and alphanumeric data from the application file on all registered travellers would be stored in the RTS[45].

When crossing the border, using automated gates, the document reader incorporated into the gate would read the traveller's passport and the visa sticker, if applicable. The traveller's fingerprints would be read by the fingerprint reader incorporated into the gate. Checks against databases (such as SIS and national databases) would be run using the data from the passport. The validity of the visa, if applicable, would be checked against the VIS. The traveller's identity and the access granted to the RTP would be verified against the data stored in the RTS (alphanumeric and biometric data).

It is assumed (based on the technical studies and the consultations) that the centralised system could be based on a similar technical platform as the VIS. Functionalities and responsibilities for the RTS would be established. On the basis of implementing measures adopted by the Commission in a comitology procedure, the Agency would develop and operationally manage the RTS[46].

During the consultations on the Commission's communication adopted in 2008 and 2011, Member States expressed a clear preference for a centralised system. The European Parliament expressed doubts about the setting up of a new centralised database and was of the opinion that no new instruments and systems should be launched until the existing tools are fully operational, safe and realiable.

4.1.3. An RTP based on data stored in a separate token combined with a central repository (sub-option 2c)

Under this sub-option, only the unique identifier (application number) would be stored on the token, while biometric data together with the unique identifier and data from the application would be stored in a central repository. A link (unique identifier e.g. application number) between the repository and the token is needed to verify the validity of the access granted to the RTP. The token is needed in order to carry out a verification (1:1) against the repository[47] at the border check. A verification takes only seconds.

The main difference between a central database and a central repository is that in a central database, the alphanumeric and the biometric data are stored together and accessed together. In the repository, the alphanumeric data and the biometric data are, from a technical perspective, stored in separate sections. In this case, the biometric verification at the border check can only be performed by physically producing the token (unique identifier). This verification produces only a hit/no hit result. However, the visa and border authorities should use the central repository for examining applications, for the examination whether to revoke or extend access granted to the RTP, in case of lost or stolen token and if any problems occur with facilitating registered travellers' border crossing. Since for these purposes all information stored in the central repository may be relevant, the competent authority should have access either to the complete application file including biometric data of the applicant or only to the separate section of central repository containing alphanumeric data. Access shall be given to the competent authorities only if the specific search criteria are met.

The same principles as in the two sub-options above would apply, with regard to the issues related to the token as well as the issues related to the centralised database. The Agency would be responsible for the development and management of the central repository and for the definition of the technical specifications for the token whereas Member States would be responsible for management of tokens. The technical specifications would be agreed with the Member States by the Commission in a Comitology procedure.

When crossing the border, using automated gates, the document reader incorporated into the gate would read the traveller's passport, the visa sticker if applicable, and the token of the traveller. The traveller's fingerprints would be read by the fingerprint reader incorporated into the gate. Checks against databases (such as SIS and national databases) would be run using the data from the passport. The validity of the visa, if applicable, would be checked against the VIS. The travellers' identity and the access granted to the RTP would be verified against the data (alphanumeric and biometric data) stored in the central repository. However, any verification would not be possible without physically producing the token at the border. The link between the token and the repository would be the unique identifier stored on the token.

During the consultations on the Commission's communication adopted in 2011, two Member States were in favour of a token/central repository system. However, these Member States did not provide concrete reasoning why they prefer this option.

4.2. Policy option 3: Vetting criteria

4.2.1. Same as for multiple-entry visa holders (based on current EU law) (sub-option 3a)

Under this sub-option, vetting criteria would be aligned with the criteria for multiple-entry visa holders[48]. As can be seen from Annex 9 vetting would be performed to verify that the entry conditions are met. Vetting would be done using the same data sets as used when examining multiple-entry visa applications (application form, supporting documents, EU-wide databases such as the SIS and VIS, if applicable and national databases).

The EDPS in his informal comments on the draft 2011 communication highlighted that the sources of data used for the vetting of applicants must be clarified.

4.2.2. More thorough vetting procedure (sub-option 3b)

A few Member States have raised the issue of having as thorough a vetting procedure as possible. For them, the vetting done for visas is insufficient to give access to the RTP and especially to move to a full automation of border control. Fully automated border control would therefore, in their opinion, require stricter vetting procedures.

This sub-option involves therefore adding the following procedural steps:

· a consultation between Member States would always be compulsory before a decision on an RTP application is made,

· a third-country national should choose the Member States at whose external borders he/she would like to benefit from a facilitated border check. Each of the Member States chosen would check the third-country national's data from their own databases (border guard, police, etc.) and verify watch lists before the third-country national's access to the RTP would be granted/refused.

4.2.3. Discarded sub-option: Involvement of third countries in the vetting (sub-option 3c)

Some Member States considered that the country of origin of a traveller should also be involved in the pre-screening by carrying out a check of their databases (border guard, police, etc.) and watch lists and deliver a "green light/red light" message, or grant a certificate on the traveller's good behaviour in the country of origin. This possibility is discarded from the start, for several reasons. A vetting by a third country would effectively give a third country a decisive influence on whether (or not) a third-country national should benefit from facilitated checks to enter the EU. Some third countries may not be willing to do any kind of vetting on their own citizens for several reasons; one being that it would cause additional burden for them without bringing any concrete benefits. Certain third countries, especially those with a poor human rights record, could delay the vetting procedure or postpone the delivery of a certificate, particularly with regard to specific individuals (journalists, rights defenders etc.). In the worst situation access to the RTP could be given only to persons having a "privileged status" in their country. For its practical implementation it would also require the exchange of personal data using technical means between each Member State and each third country. This kind of vetting would neither be proportionate in light of the objectives of the RTP nor feasible within the short- to medium-term, and this sub-option is therefore not further assessed. This option also raises serious data protection concerns as it requires the exchange of personal data with third countries which may not provide adequate safeguards and protections for processing personal data. Furthermore, this sub-option would not be coherent with the EU's policy on information exchange with third countries.

4.3. Policy option 4: Automation of border control for registered travellers

4.3.1. Fully automated (sub-option 4a)

Under this sub-option the facilitated border check for registered travellers would essentially be identical to the minimum check currently applied to EU citizens, although for third-country nationals the consultation of databases (such as SIS) would have to be systematic and compulsory. Registered travellers' border checks could thus be fully automated and under normal circumstances no human intervention would be required, using largely the same automated gates as currently used for EU citizens. Verification of the identity of the traveller would be made against biometric data (stored according to one of the sub-options under policy option 2). However, human intervention should be provided immediately if a traveller is "refused" by the system or any malfunction occurs.

This sub-option would require that a solution is found to calculate the time spent in the Schengen area. The EES would be a solution for that.

The majority of Member States were in favour of fully automated border control system for registered travellers. However, some of them asked the Commission to launch a study on the usefulness of the ABC systems for third-country nationals and expressed doubts on demand for an RTP and ABC as they have only few entries/exits outside the Schengen area.

4.3.2. Semi-automated (sub-option 4b)

Under this sub-option, the facilitated check would be defined as a minimum check with certain additional elements. Registered travellers' border checks would include as a first step the same process as in sub-option 4a; passing through an automated gate for the verification of the identity, access granted to the RTP, and checks against databases (such as SIS). As a second step, human intervention would still be required; the automated process would be followed by an individual decision, by the border guard, to authorise or refuse entry or exit, and the passport could be manually stamped as today.

Only very few Member States supported a semi-automated border control for registered travellers considering that it would better guarantee security aspects.

4.4. Policy option 5: Application fee

4.4.1. Fee of 20 EUR (sub-option 5a)

Under this sub-option, a fee of 20 EUR would be introduced. The fee is calculated on the basis of the administrative cost to Member States for examining applications. It is estimated that 5 million third-country nationals would apply for access to the RTP each year. Half of them would be visa exempted and half third-country nationals requiring a visa. The examination of one application would take 45 minutes, on average[49], including checking the supporting documents, capturing biometric data and conducting interviews, if applicable. If a multiple-entry visa application were examined at the same time as a RTP application and based on the same supporting documents, then the time needed for examining a RTP application would be reduced by half. In the abstract, the total time needed for examining and granting/refusing access to the RTP would be 2,81 million hours per year equivalent to 73,1 million EUR or 1 705 persons[50] across Member States. The fee could therefore be set at 20 EUR per each individual application. However, the fee could be reduced to 10 EUR if a visa and a RTP appliation were examined at the same time. The fee would not cover any additional costs for issuing a token and sending the token to the applicant by mail.[51] All the Member States which expressed their views during the consultations were in favour of collecting a fee from the registered travellers.

4.4.2. No fee (sub-option 5b)

This sub-option would involve imposing no fee whatsoever on applicants.

5. analysis of impacts

This section considers each of the sub-options described in section 4 against the assessment criteria. The sub-options have been rated on a nine-point scale with respect to their likely performance relative to the general objectives. The options are assessed against the baseline. All options are also assessed against other relevant criteria, in this case criteria belonging to the general economic and social criteria:

· The total one-time development cost of the system related to the expected duration of three years and the total yearly operational costs for the ensuing period of five years, divided into central (EU) and national (Member States) costs; the tables in annexes 10.1-10.3. contain more detailed information on cost categories and costs per item; a breakdown and more detailed description of the administrative costs is provided in annex 10.4.

· Protection of fundamental rights, particularly privacy and data protection.

Only the criteria relevant for each sub-option have been analysed, and otherwise omitted.

The impacts have graphically been indicated with symbols:

- √√√√ || Highest negative impact/cost

- √√√ || Significant negative impact/cost

- √√ || Medium negative impact/cost

- √ || Small negative impact/cost

0 || No impact

√ || Small positive impact/savings

√√ || Medium positive impact/savings

√√√ || Very significant positive impact/savings

√√√√ || Highest positive impact/savings

As explained at the start of section 4, all policy options and their sub-options are independent implementation options. However, the impacts of the sub-options with regard to policy options 3 and 4 (vetting criteria and automation of border control) are directly linked, in the sense that the impact of the sub-options with regard to vetting cannot be assessed without knowing which is the preferred option with regard to automation, and vice versa. Consequently the available four sub-options (3a, 3b, 4a, 4b) from the two policy options have been combined in the assessment into the four variations possible, and the impact of all four variations is assessed in an integrated way.

As the preferred sub-option of policy option 1 is clear (cf 2.3.1.) and the sub-options of policy options 2 (data storage) and 5 (application fee) are purely technical implementation options which are not linked to other policy options, they have not been presented and analysed in combination with the other policy options.

It must be noted that in the impact assessment it was very difficult to estimate the impact in practice of the RTP on the number of border guards needed at the external border and on travellers´ waiting time as these depend almost entirely on the individual border crossing point.

There are very big differences between the traveller profiles at different border crossing points at the external border as described in section 2.1.2. and Annex 2 (for example, the number of third-country nationals vs. EU citizens differs greatly). Also, the current capacity to manage passenger flows at a specific border crossing point (infrastructure, data transmission system, customs and security checks, etc.) has a significant effect on travellers´ waiting time and also on border guard resources needed. As a result of the above factors, precise estimates of the impact of each sub-option on border crossing times and the need for human resources would only be possible based on a detailed analysis of the current situation at each and every border crossing point (over 1800) of the Schengen area, which is not practically feasible.

5.1. Policy option 1: Lodging an application for an RTP

Sub-options are not analysed as the preferred option is clearly 1c; lodging an application for an RTP at the external border and at consulates (cf 2.3.1.).

5.2. Policy option 2: Data storage

As regards all the sub-options, the EDPS highlighted the privacy by design, only a one to one verification of biometrics should be possible, data protection rights should be ensured and no record should be stored in the RTP database/token.

5.2.1. Data stored in a token (sub-option 2a)

· To facilitate the crossing of EU external borders by third-country nationals √√√

A token-based system would significantly facilitate border crossings compared to the baseline situation. A token-based system would guarantee facilitated border crossings as any technical break down or failure of the system would not have effects on Member States' other systems.

However, a token-based system adds one step to the automated border control process, as a token needs to be physically placed on a document reader (integrated in the gate) and "opened", and the identity of the registered traveller should be verified against the data stored in a token. This additional verification step would increase somewhat (a few seconds) the time needed for a border check. From the travellers point of view the experience will therefore be a bit more complicated and cumbersome compared to a centralised system, as not only the passport and the visa sticker (if applicable) needs to be put on the reader but also the token.

A token as such would give more visibility to the EU RTP. However, a traveller who has forgotten to bring the token cannot make use of his/her access to the RTP. Furthermore, a renewal of access to the RTP could not be made centrally, as the person would need to appear in person to have a new token issued. This is likely to reduce the attractiveness of the RTP to persons who do not travel often but, as already indicated before, these do not constitute the main target group of the programme.

The EU could consider promoting the token-based system – based on existing and future EU technical standards – at a global level following its full implementation in the EU.

· To maintain the current level of security √√

The overall impact will increase security due to the verification of the identity of travellers using biometrics, as concerns non-visa holders.

However, a token-based system could be exploited for "Registered Traveller shopping", as no data is stored from any previous applications which can be accessed by the authority assessing the application. Nothing would prevent a person from repeatedly lodging applications at several locations to increase his/her chance of success, although a uniform application of the vetting criteria would minimise this risk.

Multiple tokens could be issued for the same registered traveller not subject to the visa requirement: it would be possible to lodge multiple applications and obtain several tokens linked to the same person travelling with different travel documents. This risk is not, however, relevant for visa holders as their identity can be biometrically verified in the VIS. For persons not holding a visa the risk of identity fraud could be reduced by requiring an applicant to hold a biometric passport.

Access to the RTP cannot be revoked centrally, in case a person no longer fulfils the conditions. As long as a token holder presents his token at the border within the validity period marked on the token, assuming ABC is used, he/she can use the RTP even if there would be reasons to cancel his/her "membership" (he/she could be flagged in the SIS but only for one of the legally possible categories of alerts). Access granted to the RTPcan only be revoked by physically cancelling (destroying) the token.

5.2.2 Data stored in a centralised database (sub-option 2b)

· To facilitate the crossing of EU external borders by third-country nationals √√√√

A centralised RTP would not require travellers to carry any additional document besides the passport. The traveller would however not receive any physical confirmation or "proof" that he or she is a registered traveller; this would be dependent on verification against the records in the RTS.

Border guards would always be able to check whether a person is a registered traveller by searching in the centralised database. During ABC, biometric verification against the RTS could be done simultaneously with other processes and can easily be integrated into the automated process.

Member States were in favour of centralised system whereas the European Parliament expressed doubts on establishing it.

· To maintain the current level of security √√√

Overall the impact on security is positive compared to the baseline due to the verification of the identity of travellers using biometrics, as concerns non-visa holders.

A centralised system would be more secure than a token-based system as there would be no token which could be falsified. Having a reliable, accessible record of the registered travellers would help to examine a subsequent application wherever the application is lodged. Problems related to Registered Traveller shopping, multiple identity fraud and central revocation/renewal of access granted to the RTP are effectively solved by a centralised database. However, a centralised system could be hacked, just as any other data storage which is connected to a network.

5.2.3 Data (unique identifier i.e. application number) stored in a token and (unique identifier, biometrics and data from applications) in a central repository (sub-option 2c)

· To facilitate the crossing of EU external borders by third-country nationals √√√

In terms of the border management process, this sub-option involves the introduction of two new factors compared to the baseline – travellers carrying tokens and a new central repository to which all border crossing points and consulates must be connected.

In this sub-option there is a need to read the token as well as to search the central repository, in order to verify the identity of the traveller and that he is the rightful holder of the token. The automated process may therefore be marginally slower (a few seconds) compared to the other sub-options. The traveller must carry the token to benefit from the RTP membership at the border, but appearance in person is not necessary for renewal or revocation.

The visibility of the programme is achieved, but the feasibility of promoting it at global level is reduced, as the functioning of the system depends on centralised storage of personal data.

· To maintain the current level of security √√√

Overall the impact on security is positive due to the verification of the identity of travellers using biometrics, as concerns non-visa holders.

This sub-option allows for preventing identity fraud and for revoking or renewing RTP membership centrally. "Registered traveller shopping" would be prevented if the fingerprints of rejected applicants are also stored in the repository together with the date of previous application(s) and the reasons for rejection.

5.2.4 Costs (all sub-options)

The costs in the 2008 impact assessment were taken from the technical feasibility study performed earlier, where the minimum technically feasible option, a web-based application for both the EES and the RTP, was chosen as the option for cost calculation. The pure development costs for both systems together remained, therefore, relatively low and the cost estimation did not include other required costs, as for example a secure network. The costs for a web-based communication network for both the EES and the RTP in 2008 impact assessment were 100.000 EUR per year, compared to 13 million EUR per year (based on the current market prices) for a secure network only for the one system now.

This was the main reason why it was decided to prepare a separate detailed cost study in 2010 with the help of an external contractor[52]. Costs were calculated for numerous different scenarios. However, only the most relevant cost scenarios are presented in this impact assessment. All the cost parameters were established so that the costs were calculated on the basis of 'maximum value' estimates within a reasonable range meaning that the cost were calculated so that they should not overrun the budget in any circumstances (details on the cost study are in Annex 10).

The table below sets out the total development costs, the yearly operational costs, and accumulated total costs for development and operation (one-time costs and 5 years of yearly operational costs) for each of the three sub-options. As there is no central technical development in the token-based sub-option there are no EU costs for that sub-option. The costs below do not include the costs for examining applications, which are described under policy option 5. The sub-option 2c is clearly the most expensive one. The development costs would be 164 million EUR for Member States (MS) and 43 million EUR for the EU. Yearly operational costs would be for 81 million EUR for Member States and 20 million EUR for the EU. During the consultations on the Commission's communication adopted in 2011, the majority of Member States were concerned about the high costs of the systems (RTP and EES) and asked for a cost-benefit analysis and the EU's financial support.

Table 1 – Costs, policy option 2

Suboptions || One time development cost at central and national level (3 years of development) (in EUR million ) || Yearly operational cost at central and national level (5 years of operation) (in EUR million) || Total costs at central and national level (8 years) (in EUR million) || ANNEX

Data stored in a token || 151 (Member States (MS) 151) || 95 (MS 95) || 626 (MS 626) || Annex 10.1

Data stored in a centralised database || 190 (MS 152, EU 38) || 94 (MS 76, EU 18) || 660 (MS 532, EU 128) || Annex 10.2

Data (unique identifier number) stored in a token and (unique identifier, biometrics and data from application) in a central repository || 207 (MS 164, EU 43) || 101 (MS 81, EU 20) || 712 (MS 569, EU 143) || Annex 10.3

In Member States the costs would fall on the ministry responsible for managing the system. Every Member State would be free to choose the best possible one and it could be for example the Ministry of Interior as is the case in many Member States with the SIS or the Ministry of Foreign Affairs as is the case in many Member States with the VIS.

5.2.5 Protection of fundamental rights, particularly privacy and data protection

A centralised system would have significant impacts on fundamental rights, particularly data protection and protection of privacy. The data would be stored in a form that could be manipulated and there is a potential risk, as with any data of this type, that it could be used inappropriately. The RTP should follow the requirements set in existing EU law for the VIS as to privacy, data protection and fundamental rights of travellers, including establishing clear rules on access rights, purpose limitation, monitoring and supervision of data processing, data security, etc.

A token-based system excludes the need for establishing a new EU level IT-system and a new centralised database. A token-based system would therefore have less of an impact on fundamental rights, privacy and data protection than establishing a centralised system. Personal data on travellers is stored only on a token and no centralised register or database would exist. The authorities would have access only to one individual's data. A one-to-many search using biometrics becomes technically impossible. However, the same data protection rules as for the centralised system would be needed.

On the other hand, a missing, lost or stolen token is a de facto risk that will require high demands on preventing the misuse of tokens and ensuring their security. Furthermore, there would also be a risk of cloning the token (electronic chip) or of unauthorised access to the token, especially as regards the alphanumeric data which is not normally as well-secured as biometrics. To minimise the risks above the token would need to follow the same security requirements as residence permits or e-passports. The main risk with a purely token-based system would be "Registered traveller shopping" as no data is stored from any previous application which could be accessed by the visa or border authority assessing the application.

In a token-based system, data protection benefits would need to be safeguarded so that Member States could store the registered travellers' alphanumeric data but not biometric data in their national databases. This would mean that instead of having a single EU database for registered travellers, all Member States could establish their own database containing only alphanumeric data.

In the sub-option combining a token with a central repository, the drawbacks related to data protection of the two other sub-options are present but with clear limitations. A one-to-many search in the central repository to establish a person's identity is impossible at the border check, and the risk of cloning or accessing the data on the token is minimised. As regards biometrics, border guards would have only hit/no hit responses at the border check. Alphanumeric and biometric data from the application file stored in the repository would be accessible to duly authorised staff of border control and visa authorities when assessing applications, renewing/revoking access to the RTP, in case of lost or stolen token or any problems occur with facilitating registered travellers' border crossings subject to the specific search criteria. The AMCHAM EU supports a token with a central repository approach as separating the storage of anonymised data may allow for the use of advanced and secure mechanism to protect the most sensitive data at a lower cost.

As regards all sub-options, the scope of access to RTP data should be limited exclusively to duly authorised staff of border control and visa authorities, as far as access to the data is necessary for the performance of their tasks namely assesing RTP applications and facilitating third country nationals' travel. No access to the information stored in the RTP should be given to any other authorities or third countries.

The RTP shall respect the fundamental rights of all travellers and comply with the principles laid down in the Charter of Fundamental Rights of the EU and in particular Articles 7 and 8 thereof. Furthermore, in addition to the intervention of national data protection authorities to require correction or deletion of erroneous data, a review procedure for challenging or correcting potential errors in accordance with the right to an effective remedy (Article 47(1) of the Charter of Fundamental Rights of the EU) would have to be laid down.

Table 2 - Assessment of policy option 2

Sub-options || To facilitate the crossing of EU external borders || To maintain the current level of security || Cost || Protection of fundamental rights

Data stored in a token || √√√ || √√ || -√√ || -√

Data stored in a centralised database || √√√√ || √√√ || -√√ || -√√√

Data (unique number) stored in a token and (biometrics and data from applications) in a repository || √√√ || √√√ || -√√√ || -√

5.3 Policy options 3 and 4: Vetting criteria and automation of border control

As explained in the beginning of this section, the available four sub-options (3a, 3b, 4a, 4b) from the two policy options have been combined into the four variations possible, and the impact of