EUR-Lex Access to European Union law

Back to EUR-Lex homepage

This document is an excerpt from the EUR-Lex website

Document 52013SC0050

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

/* SWD/2013/050 final */

52013SC0050

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 /* SWD/2013/050 final */


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 all four variations is assessed in an integrated way. The variations are:

· Same vetting as for multiple-entry visa holders (3a), fully automated border crossing (4a)

· Same vetting as for multiple-entry visa holders (3a), semi-automated border crossing (4b)

· More thorough vetting procedure (3b), fully automated border crossing (4a)

· More thorough vetting procedure (3b), semi-automated border crossing (4b)

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

Vetting criteria and procedures should be proportionate to the objectives of the RTP. Multiple-entry visas have already been issued for years and the criteria for their issuance have been tested. Travellers subject to the visa requirement would not have to deliver several different supporting documents. This would enable simultaneous processing of a visa application and an RTP application and hence minimise the increase of work at the consulates and maximise the number of RTP applications submitted by visa-required third-country nationals.

Based on the Member States' analysis the border processing time using a fully automated ABC system is significantly shorter compared to the baseline (manual checks). For example, in Portugal's RAPID and Germany's EasyPass, e-passport based systems, automated border crossings based on facial recognition take 15-20 seconds, in Germany's iris-based ABG system using a conventional passport and template stored in a database, automated border crossings take 10-15 seconds and in France's fingerprint based PARAFE system, it takes 20 seconds. With the traditional border check procedure a border guard can perform an average of six EU citizens' border checks per minute whereas the same border guard can supervise 26 border checks by using the RAPID system. At Lisbon airport, one border guard monitors seven automated border check gates. In theory, RAPID increases the capacity of border checks during peak hours by around 430 % with the same number of border guards. Based on the presentation given by the Netherlands in the Innovation Border Management Conference held in Copenhagen on 2 and 3 of February 2012 36 e-gates, with 12 border guards supervising them, can process 5,7 million passengers per year. To process the same number of travellers with manual border control process 48 border guards would be needed. At Schipol airport, passengers' waiting time is reduced by 15 million minutes per year.

By comparison, according to the Member States' replies to the Czech Presidency and the Commission's questionnaire, currently (baseline) the average time for a (manual) border check is roughly between one and two minutes, depending on the type of border and whether the traveller is required to hold a visa or not. Based on these examples, the RTP with full automation would reduce significantly the border crossing time for third-country nationals at the busiest external border crossing points. As illustrated in section 2.1.2, 57% of border checks at air borders are performed at the 20 busiest air border crossing points in the EU.

In semi-automated border control, part of the process would be automated but border authorities would still carry out part of the border check manually (for example stamping of passport to calculate the time spent in the Schengen area). Time savings for border crossings for this sub-option would be limited compared to the baseline (manual checks). The interest for the traveller is also significantly reduced, as there will be a need to pass through two processes – the automated gate and appearing at the control booth – which can certainly be perceived as a step backwards compared to the baseline (manual check going directly to the control booth). The Netherlands conducted a survey from 9 May till 16 May 2011 in which a total of 242 of the US participants in the FLUX programme responded. The FLUX is a semi-automated programme. All respondents with an American passport indicated that their passports are stamped. 84% of the respondents were either outspoken negative (40%) about this requirement or regarded it as bureaucratic red tape (44%). Many comments which the respondents volunteered to give addressed this issue.

An automated system would allow for more efficient use of border control resources, the best use of available space at the border crossing points, and at the same time enable more efficient service for travellers[53], especially at busy border crossing points. As the experience of Member States' national ABC systems show, a substantial number of border guards can be freed up for other duties and thus facilitate also those travellers' border crossings who do not use the ABC system. Based on the final report on the cost analysis on Entry/Exit and RTP systems made by the external contractor[54], 7,68 border guards are needed per manual lane per million travellers to perform border checks whereas the rate using an ABC system is 2,73 persons. In a semi-automated system, these savings would largely be absent as each traveller would still need to be checked by a border guard.

Most travellers are already familiar with different types of e-services and are ready to use them. Approximately 90% of them are willing to use ABC systems as surveys conducted in the Netherlands, in the United Kingdom and in Australia show. The details of the surveys are reported in Annex 2.

During the consultations, several Member States recalled that the travel flows at the external borders are increasing constantly and all Member States are facing the same problem i.e. how to manage them efficiently and cost-effectively. The only answer for them is automation of border controls to the largest extent, also including for third-country nationals. Big investments would be needed in technology but "investing" only in human resources and old-fashioned border check procedures with stamping is the most expensive solution. In the long term, technical solutions will lead to savings. Some Member States saw an EES as a condition for the RTP and especially for full automation of border control. Common standards were pleaded as quickly as possible on the ABC and the RTP. Full automation of border control should be made available not only for business travellers but also, for example, for tourists travelling often to the EU.

Moreover, the American Chamber of Commerce to the European Union (AMCHAM EU) on its position statement on the Smart Borders of 23 of March 2012 highlights the use of ABC wherever possible to ensure more efficient border checks and a positive experience for the traveller.

By the end of 2010, over 200 automated border control gates have been installed at border crossing points. In addition to that, several Member States are planning to install them[55].

· To maintain the current level of security

With the use of fully automated border control, the same checks against databases (such as SIS) would be carried out as in the baseline situation (manual checks). Furthermore, the identity of the traveller would be verified using biometrics, which is not the case in the baseline situation as regards non-visa holders.

However, a few Member States proposed to have a more thorough vetting. 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. The precise gains in security arising from stricter criteria are not easy to identify. If national databases of several Member States were to be checked, this would raise the level of security, but at the same time it would require additional time and effort from Member States, thus reducing the positive impacts of the RTP. All data on the applicant would need to be sent to other Member States. Furthermore, awaiting replies from all Member States would be a time-consuming process. Notably, such a process would be inconsistent with the current process for the issuance of visas as well as the border checks, for which only the Member State carrying out the check consults its own national databases, the SIS and the VIS, if applicable. It would therefore be disproportionate to introduce such a requirement for registered travellers.

It is true that there could be some negative effects when using ABC for third-country nationals. Border guards are accustomed to observing even the faintest cues, for example, reading the unusual behaviour of a human being. This human factor is removed if the checks of the registered travellers are fully automated. It is possible to spoof fingerprints using modern techniques and materials; fingerprints can even be bought or stolen. However, the use of "liveness" detection built into fingerprint readers help mitigate this risk. Furthermore, border guards need to monitor ABC gates and could always check the traveller manually if any reason arises (e.g. random checks). Notably, these "weaknesses" of the ABC process cannot be addressed by introducing stricter vetting procedure, which shows that the impact on the level of security of stricter vetting procedure is in fact virtually non-existent.

5.3.1      Costs

Stricter vetting with a compulsory consultation mechanism between Member States would require the creation and maintenance of a communication network between Member States that would enable sending confidential information from one Member State to another, similar to the VIS Mail application, the consultation mechanism used in the VIS. The costs for the Agency to develop and create such a communication network would be approximately 1 million EUR at EU level and approximately 3 million EUR for Member States. In Member States the development costs for such consultation mechanism would fall on the ministry responsible for managing the system and operating costs would need to be paid by border and visa authorities.

Furthermore, stricter vetting procedure would significantly increase administrative costs for the Member States with an estimated 182 million EUR per year (see Annex 10.4). Half of the costs would fall on border authorities and half on visa authorities.

The costs for automation would vary between Member States depending on the number of ABC systems installed. All the costs for automation would fall on border authorities.

5.3.2      Protection of fundamental rights, particularly privacy and data protection

Although the RTP is voluntary for third-country nationals, stricter vetting procedure using a consultation mechanism between Member States would have a significant effect on the protection of fundamental rights, particularly privacy and data protection. Personal data would have to be sent through a network between Member States. This would require adeguate technical and security measures to ensure the protection of information processed and exchanged. The EDPS stressed in his informal comments on the 2011 communication that data protection rights have to be ensured irrespective of whether data subjects take part in a programme voluntarily or not.

The potential issue of discrimination through assuming that travellers who are not registered or accepted by a Member State are suspicious needs to be addressed. This issue was raised also by the EDPS in his informal comments on the 2011 communication. He highlighted that measures should be taken to prevent positive discrimination from turning into a negative one of persons who do not have a strong track record of reliability, for example infrequent or first-time travellers. This issue arises especially if the vetting is too strict. This important topic should therefore be incorporated into the training programme on fundamental rights which Frontex organises for border guards. In order to raise awareness with the general public, this issue should also be covered during the information campaigns organised before the RTP starts operations. The leaflets and posters should clearly state that travellers are free to choose whether to apply for the RTP and use the ABC. Those not using the ABC are not considered as more risky travellers.

Detailed provisions would be required to provide third-country national applicants with the reasons why they have not been granted access to the programme. A system of review of the refusal and revocation of membership, and 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 put in place.

As technical failures or breakdowns can always happen, contingency plans should be in place and these plans should be made clear to the travellers, airlines/carriers and all authorities working at the border crossing point. If a registered traveller  is unable, for example, for any reason, to use the ABC, and is redirected toward a manual border check, due attention should be paid to ensure that the ensuing procedures are in full compliance with fundamental rights, in particular with human dignity, and are conducted without stigmatisation.

As regards a centralised RTP in which the data is stored in a centralised database, supervision by the EDPS and cooperation between National Supervisory Authorities and the EDPS should be guaranteed and facilitated. As regards a token-based system without any centralised database or data exchange between Member States, National Supervisory Authorities would mainly be responsible for supervising and monitoring the access rights and purpose limitation. Data protection authorities should have the means necessary to access to the information processed and intervene and enforce compliance with data protection rules.

During the consultations, Member States highlighted the importance of data protection aspects in general.

Table 3 - Assessment of policy options 3 and 4

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

Same vetting as for multiple-entry visa holders, fully automated border crossing || √√√√ || √ || -√ || 0

Same vetting as for multiple-entry visa holders, semi-automated border crossing || √ || √√ || -√ || 0

More thorough vetting, fully automated border crossing || √√√ || √√ || -√√ || --√√

More thorough vetting, semi-automated border crossing || √ || √√√ || -√√√ || --√√

5.4         Policy option 5: Application fee

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

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

As described in section 4.4, this sub-option would allow to neutralise the costs incurred by the RTP as far as the examination of applications is concerned, which is approximately 73,1 million EUR. It would be consistent with the approach chosen for the treatment of visa applications, and also consistent with the fact that a registered traveller is effectively buying an additional service, on which he/she is not dependent in terms of his/her rights to cross the external border of the Schengen area, a service which will only be of interest to a certain category of travellers. From the travellers perspective, the additional cost of 20 EUR (independent application) or 10 EUR (a registered traveller application together with a multiple-entry visa application) is not likely to be considered discouraging in a context where the main target group are persons who travel to the EU several times per year. It is also relatively minor compared to the normal visa fee (60 EUR). There is broad consensus among stakeholders that a fee should be collected from the applicant for participation in the RTP.

5.4.2      No fee (sub-option 5b)

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

This sub-option would undoubtedly have a bigger impact in attracting as many persons as possible to the programme, also in the sense of making the programme and its benefits known more quickly, as people who hesitate about the benefits would be more willing to "give it a try" if it were free. This impact is however limited, considering that any traveller will be able to observe the use of automated gates when crossing the external border and thus also observe the benefits in terms of shorter queues.

There is a risk that many ineligible applications would be submitted, thus increasing Member States authorities' workload and administrative costs.

5.4.3      Costs (both sub-options)

The cost of examining applications is fully taken into account when assessing the impact of these sub-options. This brings the net cost of sub-option 5a to zero taking into account the revenue from the fee, while the cost for sub-option 5b is equivalent to the full (estimated) cost for examining applications, that is, 73.1 million EUR. Half of the full cost for examining applications (i.e. 36,6 million EUR) would fall on visa authorities and half on border authorities.

Table 4 - Assessment of policy option 5

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

Application fee 20/10 EUR || √√ || - || 0 || -

No application fee || √√√ || - || -√√ || -

6. Comparison of options and identification of preferred policy option

6.1.        Comparison of options

Table 5 – comparison of policy options

Policy options and sub-options || To facilitate the crossing of EU external borders by third-country nationals || To maintain the current level of security || Costs || Protection of fundamental rights

Option 0 Baseline || 0 || 0 || 0 || 0

Option 2 Data stored in a token (2a) || √√√ || √√ || -√√ || -√

Data stored in a centralised database (2b) || √√√√ || √√√ || -√√ || -√√√

Data (unique identifier number) stored in a token and (unique identifier, biometrics and data from application) in a central repository (2c) || √√√ || √√√ || -√√√ || -√

Options 3 and 4*) Same vetting as for multiple-entry visa holders, fully automated border crossing || √√√√ || √ || -√ || 0

Same vetting as for multiple-entry visa holders, semi-automated border crossing || √ || √√ || -√ || 0

More thorough vetting, fully automated border crossing || √√√ || √√ || -√√ || -√√

More thorough vetting, semi-automated border crossing || √ || √√√ || -√√√ || -√√

Option 5 Application fee 20/10 euro (5a) || √√ || - || 0 || -

No application fee (5b) || √√√ || - || -√√√ || -

*) the impacts of sub-options with regard to the 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 into the four possible variations, and the impact of all four variations is assessed in an integrated way.

Table 5 summarises the assessment of impacts done in chapter 5. The three sub-options of policy option 1 (lodging an application for an RTP) are not included in the table as the best choice is described already in chapter 2.3.1. The following comparison and identification of the preferred option will also take into account the following criteria:

· Effectiveness – the extent to which options achieve the objectives of the proposal;

· Efficiency – the extent to which objectives can be achieved with the proportionate cost;

· Coherence – the extent to which options are coherent with overarching objectives of EU policy.

Data storage

All three sub-options contribute significantly to the objectives as defined and are notably fully coherent with EU border policy: security and prevention of irregular immigration is not diminished during the border crossing, while the EU's openness to the world and its capacity to facilitate cross-border people-to-people contacts, trade and cultural exchange is boosted. Furthermore, innovation and development of high-tech technology is accelerated. An RTP for all third-country nationals travelling frequently will show the EU's determined ambition to be open for legitimate travel. The programme would be the first in the world which is open to all third countries, and which is operable across several states, in this case across the whole Schengen area. In this context, Europe can be seen as a pacesetter for the rest of the world.

A drawback of all three sub-options is that the benefits are nowadays mainly related to air border crossing points. This is reflected in the data available from the benefits in terms of processing times which are all based on the experiences from airports. However, at land border crossing points that are organised in such a way that passengers are checked outside their vehicles, an ABC system can also be used[56]. Furthermore, at sea borders ABC systems could be easily implemented, especially in cruise and ferry terminals. Some Member States have already planned to do so[57].

The token-based sub-option allows for visibility and limits data protection concerns. The sub-option based on a centralised RTP is more secure and easier to implement in practice at the border crossing point. The latter is, however, counterbalanced by the need to develop a new centralised system in which all the data is available and subject to search.

The sub-option based on a token/central repository can be seen as a hybrid between the above two sub-options, combining their respective advantages. It minimises the use of personal data in an EU system and it avoids the main of the security drawbacks of the token-based system. It provides, however, for the most complicated integration into the border control process as it introduces both a verification of the token as well as a verification against a central repository.

Vetting criteria and automation of border control

The assessment showed that stricter vetting procedure does not have any real impact on the security of the border check itself, and also that the facilitation of border crossings of semi-automated border controls is too limited to bring added value. Furthermore, stricter vetting procedure would increase significantly Member States' administrative costs and would have a significant effect on the protection of fundamental rights. Therefore, stricter vetting criteria and semi-automated border control would not be effective and/or efficient. Furthermore, stricter vetting criteria would not be coherent with the EU border policy.

Member States having implemented an ABC system reported that the system is the most cost-effective solution for them as it saves cost in terms of staff, increase throughput capacity of border crossing point and it enables border guards to focus more on the most risky travellers and/or serve other travellers.

Application fee

By introducing a fee of 20 EUR, Member States administrative costs for examining applications would be neutralised. It would also be consistent and coherent with the approach chosen for the treatment of visa applications. However, no fee sub-option would better guarantee large number of participants in the programme. Downside of this option would be that many ineligible applications would be submitted and the cost for visa and border authorities would be 73,1 million EUR.

Costs-benefit analysis

Data storage

The two sub-options on a token-based system and a centralised database are almost equal as concerns total costs, but this hides important differences between them: the token-based system puts effectively all costs on the Member States, as all technical implementation will be done by them.

An important difference between the token-based and the token/central repository sub-options is in the different costs for tokens: in the former case, biometric data needs to be stored on the token, in a secured chip, which brings the cost of one token to 5 EUR. In the latter case, no data other than the unique identifier (application number) needs to be stored on the token, in the form of a barcode, which limits the price to 1 EUR. The cost for tokens would fall on Member States i.e. border and visa authorities.

Most importantly however, the costs for the sub-option with a token/central repository are clearly the highest of all sub-options as can be seen from the table 1.

Automation of border control

The use of ABC is most efficient and cost-effective at those border crossing points where the number of travellers is the highest and where it is most challenging to manage passenger flows. However, there are border crossing points which would not gain any benefits on automation due to the small number of travellers.

An estimate would be that Member States in total would invest in 175 automated gates per year, to gradually expand their capacity for handling travel flows in this way as the number of travellers and also registered travellers increase.

The costs of automation would therefore greatly vary depending on the number of automated gates that would be implemented. Automation of border controls would introduce extra implementation costs for the Member States, but it would also guarantee more efficient management of passenger flows, release border check resources for checking on higher-risk travellers and/or serve other travellers, and would generate cost savings in the long run due to a reduced need for personnel per million of traveller crossing the border.

As part of the baseline the required resources for border checks today in terms of border guards can be estimated at around 40 000 persons at a salary cost of 1 240 million EUR[58], equivalent to 1,65 EUR per passenger on each entry and exit.

At the moment, it is not possible to calculate the exact benefits of the automation and/or the RTP in quantitative and monetary terms as it would require at least the following information to be available in addition to the number of border crossings and the border crossing time per category of travellers (EU citizens, visa holders and non-visa holders): number of manual and automated lanes and number of registered travellers (visa holders and visa exempted) per border crossing point. However, some very general calculations can be done based on the Member States experiences. Together with automation, the RTP could reduce border control resources needed by around 40 % i.e. in theory 16,000 border guards (equivalent to 500 million EUR/year[59]) who can focus on/serve other travellers and cope with the expected increase of traveller flows. Even if more modest savings were to be the starting point for calculation (i.e. 250 million EUR/year), Member States would have net cost savings (+81 million EUR) already after the second year of operation of the RTP[60].

The release of around 40% of border guards includes the possibility to cope with an increase of 62% of travel flows, which means that 40.000 border guards would be able to check 1.125 million travellers instead of 675 million travellers[61]. With the introduction of the RTP, it would be possible to manage the largest part of the expected increase of 80% of travel flows at the air borders with the current number of personnel.

A further estimate was done in the external cost study where, compared to the costs incurred in the baseline, the need to invest in automated gates would increase Member States' one-time costs by 38 %, but would in the long run reduce their total costs by 64 %.[62]

Based on the general calculations above, the conclusion can be drawn that the personnel and the investment costs for establishing and maintaining the RTP system would be compensated within a reasonable timeframe in the form of a lower unit price per border check and personnel resources who are able to focus on other tasks and/or cope with the increasing travel flows. .

Risks

As technical failures or breakdowns can always occur with one or another system, contingency plans should be in place and these plans should be made clear to the travellers, airlines/carriers and all authorities working at the border crossing point. In case of any failure of the system(s), the easiest and clearest contingency plan would be to return to the existing process i.e. manual border check procedure. This would apply to any situation where the RTP is down with regard to all three sub-options. In this regard the token-based system can be regarded as less risky, in that it does not rely on the functioning of a central component to function.

As with any large scale IT-system, there are always risks with implementation. Therefore, proper implementation of the RTP can only be ensured if all relevant actors fulfil their obligations, respect the lessons learnt from establishing the previous large-scale IT systems and take advantage of the adopted legal basis and the technical possibilities for performing facilitated border checks on registered travellers. Common technical processes, using the system in the same way all around the external borders and a consistent implementation combined with solid overall data quality would ensure the expected results are reached. Mitigating the implementation risks by entrusting the Agency to develop a common technical platform and a standard national client which is fully tested and fulfils all legal requirements for its use by Member States would ensure that all Member States could cope with the RTP without having any major implementation problems.

Furthermore, a strong monitoring mechanism with clear milestones, benchmarks and advanced compliance testing are needed to ensure a coordinated development and implementation phase throughout all Member States.

6.2.        Preferred policy option

Lodging an application for an RTP

For policy option 1 it is clear that 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. Therefore, the preferred sub-option is lodging an application for an RTP at any border crossing point and at any Member States consulate. The cost-effectiveness of this sub-option is clearly the best and it is fully coherent with existing border and visa policy.

Data storage

To identify the preferred option with regard to policy option 2 is more complex as demonstrated in chapter 6.1. The total scoring of each sub-option in relation to policy option 2 is almost equal, but each sub-option displays distinctly different weaknesses: the token-based sub-option displays significant security issues, the central database sub-option displays significant fundamental rights issues, and the token/central repository sub-option significant cost issues. However, the cost benefit analysis shows that even the higher one-time costs and yearly operational costs of the token/central repository sub-option will be fully compensated in the long run by the economic benefits of the RTP as a whole for the Member States. This is therefore the preferred sub-option with regard to policy option 2. This sub-option provides for a proportionate balance between security, facilitation and data protection. The data stored in a central repository would be available for border guards only when assessing application, renewing/revoking access to the RTP, the token is lost or stolen or any problems occur with facilitating registered travellers' border crossings. While performing border checks a border guard would receive only hit/no hit information. With this option "privacy by design" is implemented.

Vetting criteria and automation of border control

For policy options 3 and 4 it is clear that the total impact of combining the same vetting criteria as for multiple-entry visas with fully automated border control has the highest impact on facilitating registered travellers' border crossings. Furthermore, it offers a balanced approach to security and protection of fundamental rights. It is also the least expensive approach taking into account the costs associated with stricter vetting procedure and semi-automated border control. Full automation would be a cost-effective tool especially at the busiest border crossing points where capacity problem and queues exist already nowadays.

It should however be noted that the implementation of fully automated border control requires that an Entry/Exit System is developed and implemented in parallel, which would allow for replacing the stamping obligation with an electronic registering of entry and exit dates of all travellers including those having access to the RTP.

Application fee

For policy option 5 it is reasonable to accompany the RTP with a fee of 20 EUR that would cover the administrative costs of examining applications, which would be set at a level that should not discourage potential applicants. The fee could be reduced to 10 EUR if a multiple-entry visa application and an RTP application are examined at the same time based on the same supporting documents.

Impacts on relations with third countries

There would be positive impacts on relations with third countries as all third-country nationals whether requiring a visa or not could apply for access to the RTP. The RTP would allow moving from a country-centric approach to a person-centric approach in which the country of origin does not play an important role. The main criteria to grant or refuse access to the RTP would be the security risk posed by an individual.

Impacts on other stakeholders such as operators, carriers and other authorities working at the external border

There would not be any direct impacts on other stakeholders. However, positive impacts could be achieved for operators and carriers as the throughput capacity of border crossing point would increase thus giving more flexibility for operators and carriers to plan their actions such as connection flights. This is especially of interest at airport hubs where connection times are often between 30 and 60 minutes as it would offer attractive connections from outside the EU into the Schengen area and vice versa.

Costs of the preferred option

Examining applications

The costs for examining the applications based on the preferred sub-option under the policy option 1 amount to 73.1 million EUR per year for the Member States.

The administrative fee would cover this part of the costs. The total maximum revenue of the administrative fee, which would cover the examination of applications, would be 75 million EUR/year.

Data storage

The estimated total one-time costs of the preferred option of the RTP for the Agency to develop a centralised part would be 43 million EUR, spread out over 3 years and annual average costs for maintenance/operations would be 20 million EUR/annum. The total one-time costs for Member States to develop and set-up their national infrastructures would be 164 million EUR, spread out over 3 years and annual average costs for maintenance/operations would be 81 million EUR/annum. The above-mentioned costs include also administrative costs except the costs for examining applications. These are however only the costs related to the development and running of the system itself. The following elements need to be added to this.

Automation of border control

ABC system costs will vary greatly from one Member State to another. For that reason, the cost cannot be calculated in advance. Member States can choose the border crossing points where they would implement the ABC system. Each Member State would inevitably have to make a precise assessment for each individual border crossing point, whether ABC would bring enough added-value to the throughput capacity of the border crossing point and thus decrease or limit travellers’ border crossing time.

Information campaign

To raise awareness with the general public, the information campaign should be organised. The estimated costs for a campaign based on those for the VIS would be 80 000 EUR including video and printed materials such as posters and leaflet. These cost would be covered by the EU budget.

Cost for third countries and other stakeholders such as operators, carriers and other authorities working at the external border

For third countries and other stakeholders, no costs would be incurred due to the implementation of the RTP. After possible adoption of the RTP, third countries and other stakeholders will be informed accordingly of the facilitation mechanism and especially that third-country nationals could apply for access to the RTP.

Financial support

The Commission's proposal for the next multi-annual financial framework (MFF) includes a proposal of 4,6 billion EUR for the Internal security Fund (ISF) for the period 2014-2020. In the proposal, 1,1 billion EUR is set aside as an indicative amount for the development of an EES and an RTP assuming development costs would start from 2015, and covering 4 years of operation. Moreover, outside the scope of the ISF, a separate amount of 822 million EUR is set aside for the management of existing large scale-IT systems (Schengen Information System II, Visa Information System and EURODAC).

The Commission envisages entrusting the implementation tasks for these systems to the Agency for the Operational Management of Large-Scale IT-Systems in the area of Freedom, Security and Justice established by Regulation (EU) N° 1077/2011 of the European Parliament and the Council.[63] Providing financial support for national development costs would ensure that difficult economic circumstances at national level do not jeopardise or delay the projects.

This is different from the approach under the current MFF where the EU has funded from its budget the central costs related to the development of VIS and SIS II, while the External Borders Fund has co-financed up to 75% of the costs incurred by Member States as part of their national programmes.

Once the new systems would be operational, future operational costs in the Member States could be supported by their national programmes. It is proposed that Member States may use 50% of the allocations under the national programmes to support operating costs of IT systems used for the management of migration flows across the external borders of the Union. These costs may include the cost for the management of VIS, SIS and new systems set up in the period, staff costs, service costs, rental of secure premises etc. Thus, the future instrument would ensure continuity of funding, where appropriate.

Member States are responsible for the development and the integration into their national IT-systems as well as into their national border control processes. It is therefore not possible to calculate or to assume the proportion of costs that is likely to be borne by the Member States, because the concrete implementation in each Member State will depend on the specific situation there. The main cost factors on the side of the Member States are the costs for human ressources in the border control and for the operation of the national systems. These costs are not included in the cost tables.

Significant cost savings could also be achieved if the RTP is built together with the EES, compared to the situation in which both systems would be built totally independently. The main cost savings come at the central level (EU) from reduced costs for hardware, software and infrastructure and at Member States' level from administrative and office space cost savings.

Conclusion

In summary, the preferred option consists of

· The lodging of applications at consulates as well as border crossing points;

· The combination of a token and a centralised storage of anonymized biometric data of each applicant and the data from an application. The comprehensive list of data which would need to be stored is in Annex 8;

· Applying the same vetting criteria as currently defined in EU law for multiple-entry visas;

· Giving registered travellers access to a fully automated border control process;

· Charging a fee of 20 EUR per RT application. However, a reduced fee (10 EUR) would be introduced in cases where a visa application and an RTP application are examined at the same time based on the same supporting documents.

The preferred option should be designed so that it takes into account privileged position of non-EU family members of EU citizens who have a right to obtain a visa and move freely[64]. Furthermore, no entry and/or exit data should be stored in the central repository.

The advantages of the preferred option can be summarised as follows:

· It will significantly facilitate registered travellers' border crossings regardless of whether automation is used. Based on Member States but also other countries experiences, the RTP together with automation can reduce waiting times at the border crossing point by up 70 % - 85 %[65]. Even without automation, registered travellers' border crossing times will be reduced from two minutes to 20 – 40 seconds.

· Based on the very general calculation, it will considerably release border control resources to focus more on higher-risk travellers and/or serve other travellers. Together with automation the RTP could reduce border control resources needed by maximum of 40 % i.e. in theory 16 000 border guards, equivalent to 500 million EUR per year across Member States. The re-affectation of border guards would be very important noting the forecasted increase of travel flows especially at the air borders.

· It will give a tool for Member States to manage increasing passenger flows cost-efficiently using new technologies without decreasing the level of security.

· It will increase the efficiency and effectiveness of border checks and offer flexibility for operators and carriers to organise their tasks and actions.

· It will boost economy and cultural exchange especially at the local level.

· It will show the EU's determination to be open for legitimate travel.

· It will introduce a person-centric approach to border checks.

· It will minimise the potential impact on fundamental rights, notably privacy and data protection. Different sensitive data will be stored separately and any search against the repository at the first line control will not be possible without presenting a token. As regards biometrics, border guards will have only hit/no hit responses at the first line control. Furthermore, a one to many search using biometrics at first line control will be technically impossible.

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

6.3.1.     European value-added and proportionality

The preferred option needs to be implemented at all EU external border crossing points and will have implications on the border guard resources of all Schengen countries. The preferred option ensures that the EU has a common approach to the RTP based on common legislation and thus it guarantees that rules continue to be the same at all Schengen borders. For third-country national travellers, this means that the RTP is available to them at all Schengen border crossing points without separate vetting. In other words, a person vetted by one Member State may benefit from facilitation when crossing the external borders of any other Member State. Without common rules this would not be possible.

In terms of proportionality, an RTP implemented based on the preferred option builds to a large extent on existing processes, investments and technical equipment, including: the same document readers and fingerprint scanners as used/installed today at all Member States' border crossing points, for the purposes of SIS and VIS; the same automated border control gates used/installed today for EU citizens could be used to a large extent also for third-country nationals; use of the same biometric identifiers as for the EU e-passport, for the VIS and for the residence permits (but only fingerprints); the same criteria for access to the RTP as for multiple-entry visa according to current EU legislation; a facilitated check practically identical to the current "minimum check" for EU citizens.

Based on the consultations, the preferred option was clearly supported only by two Member States. Majority of Member States were in favour of a centralised system without giving any statements of the reasons. Although the preferred option is not a preferred option for Member States, it provides for a balanced approach between security, facilitation and data protection as evidenced in this impact assessment. In this respect, the preferred option meets the requirement of proportionality.

A key issue to consider for proportionality is one of costs, as the development of the RTP entails significant costs for the Member States and/or the EU budget. This consideration should take into account that no other measure currently exists that could provide for facilitated border crossings for third-country nationals, that no such alternative exists that could be developed in the future, and that the RTP will allow significant savings for Member States in the medium- to long term. It should also take into account unquantifiable benefits in signalling to third-country nationals, from any third country, that the EU does not consider it necessary to impose a thorough border check for each individual, but is ready to facilitate the border crossings for, potentially, millions of persons; a measure of openness unequalled by any other country in the world.On this basis the preferred option therefore constitutes a proportionate mechanism to deliver on the objectives of facilitating third-country nationals' border crossings across the Schengen area and of countering the lack of tools to manage increasing passenger flows.

6.3.2.     Legislative implications

New EU legislation would be required to implement the RTP. Furthermore, the Schengen Borders Code and the Agency regulation would need to be amended.

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

It is important that the preferred option fully complies with the relevant legislation on the protection of personal data, in particular the data protection principles and the requirements of necessity, proportionality, purpose limitation and quality of data; and that safeguards and mechanisms are in place for the effective protection of the fundamental rights of the individual travellers and in particular the protection of their private life and their personal data. Staff and third-country nationals must be made aware of these rights.

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. According to Article 6 of Directive 95/46/EC Member States shall provide, inter alia, that personal data must be processed fairly and lawfully, and that they are collected for specified, explicit and legitimate purposes. Furthermore, the processing of personal data must be adequate, relevant and not excessive in relation to purposes for which they are collected and processed.

The application of the same data protection provisions as for the VIS and the status quo including the retention of information for a maximum of five years would be necessary to ensure adequate data protection provisions for the preferred option. The personal data stored in the central repository (biometrics and alphanumeric data from applications) should be kept for no longer than is necessary for the purposes of the RTP. It is appropriate to keep the data for a maximum period of five years, in order to enable data on previous applications to be taken into account for the assessment of the subsequent RTP applications, renewal of the access to the RTP and also taking into account the re-use of fingerprints stored in the repository (59 months). Furthermore, a five year retention period would allow granting access to the RTP for five years without a new application. This would be in line with the issuance of a multiple-entry visa for trusted travellers (maximum period 5 years) whose data is kept in the VIS for 5 years. The data should be deleted automatically after the period of five years, unless there are grounds to delete it earlier. Data on refused applications should be kept five years whereas data from inadmissible applications should not be stored in the central repository at all. No personal data is stored in the token but only a unique identifier number (e.g. application number). A new application would need to be submitted to renew this access once the period of validity has expired. In addition, provisions would be necessary to ensure that:

· The data stored[66] is only accessible and used by duly authorised staff of responsible border and visa authorities, as far as necessary for the performance of their tasks. These authorities would also be responsible for correcting and/or deleting the data stored in a repository or in a token (biometrics and alphanumeric data).

· The registered traveller can opt out of the system at any time.

· Individuals are properly informed and have the right to access information held on them. A system for review of the refusal and revocation of membership in the RTP and a review procedure for challenging or correcting potential errors, by recourse to data protection authorities and by judicial review, in accordance with the right to an effective remedy (Article 47(1) of the Charter of Fundamental Rights of the EU) and Directive 95/46/EC would have to be laid down. Reasons for refusal and revocation shall be given to the applicant.

· There is no potential issue of discrimination through assuming that travellers who are not registered or accepted by a Member State are suspicious.

· The data processing is to be supervised by the EDPS as far as EU institutions and bodies are involved, and by national data protection authorities, as far as Member States' authorities are involved. This supervision and cooperation between National Supervisory Authorities and the EDPS should be guaranteed and facilitated. Data protection authorities should have the intervention powers necessary to ensure the respect of compliance with data protection rules. The EDPS and the National Supervisory Authority shall ensure that an audit of the personal data processing activities is carried out in accordance with relevant international auditing standards. Access to information and all relevant documents and records shall be given to the EDPS by the Agency and by the Member State for the National Supervisory Authority.

· Data security needs to be ensured to avoid unauthorised access or destruction or alteration of data and security breaches. Moreover, mechanisms to ensure effective monitoring of data processing need to be in place, such as logs of processing operations and access to the system.

Given the large numbers of new travellers affected and the need to process their biometric data the travellers would need to be well informed on the data protection aspects and complaints/appeals mechanisms in line with the right to an effective remedy, with indication of data protection authorities competent to deal with their complaints and requests.

7. monitoring and evaluation

The Management Authority (the Agency) would ensure that systems are in place to monitor the functioning of the RTP against the main policy objectives. Two years after the RTP is brought into operation and every two years thereafter, the Agency would submit to the European Parliament, the Council and the Commission, a report on the technical functioning of the RTP including the security thereof.

Three years after the RTP is brought into operation and every four years thereafter, the Commission would produce an overall evaluation of the RTP including examining results achieved against objectives, assessing the continuing validity of the underlying rationale, the application of the legal basis for the RTP, the implementation and the collection and use of biometric data, compliance with data protection rules and other fundamental rights, and the organisation of the procedures related to applications. The Commission would submit the reports on the evaluation to the European Parliament and the Council accompanied, where necessary, by appropriate proposals to amend the Regulation establishing the RTP.

Member States should provide the Agency and the Commission with the information necessary to draft the reports referred above. The information should be provided according to the quantitative parametres predefined by the Agency and the Commission respectively. The cost for reporting, monitoring, evaluating and organising periodical data gatherings are included in the Management authority/Member States admininistrative costs in Annexes 10.1 – 10.3.

Examples of monitoring and evaluation indicators:

General objective || Indicator

To facilitate the crossing of EU external borders by third-country nationals. || Number of persons in the programme. Time needed for registered travellers to cross an external border. System availability. Number of persons crossing the border using ABC systems.

To maintain the current level of security. || Number of persons whose access to the RTP is revoked or refused. Error rates e.g. false hits, Failure to Enrol Rate (FTE) and False Acceptance Rate (FAR).

Specific and operational objectives || Indicator

To promote access to the RTP for certain categories of frequent, pre-vetted third-country nationals. || Number of persons in the programme by category (visa required/visa exempt) and by grounds of access requested (business persons/students/workers etc). Average time of enrolment at the border crossing point and at the consulate.

To ensure protection of registered travellers' fundamental rights, in particular their personal data. || Number of complaints by individuals to the national Supervisory Authority (data protection authority). Error rates e.g. false hits, Failure to Enrol Rate (FTE) and False Acceptance Rate (FAR).

To avoid discrimination between different groups of travellers. || Number of complaints lodged against the authorities on wrong decisions and/or discrimination.

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. || Time needed for registered travellers to cross an external border by using ABC systems/manual lanes. The throughput capacity of border crossing point increased by XX per cent.

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 and/or serve other travellers. || Average time of enrolment at the border crossing point and at the consulate. Border guard resources replaced/made available by the RTP to focus on checking higher risk travellers and/or carrying out other relevant tasks.

Most of this information would be generated automatically (repository and ABC). However, Member States would need to organise information gathering excercises on the time needed for registered travellers to cross an external border, average time of enrolment and border guard resources replaced/made available by the RTP. Furthermore, Member States should keep records on the complaints lodged against them. These information could be gathered from Member States' yearly reports and/or based on samples taken periodically. Periodical samples on the time needed to cross the border and on the enrolment time would need to be taken once per year.

ANNEXES

Annex 1         List of acronyms

Annex 2         Complementary information on problem definition

Annex 3         Current and planned Automated Border Control systems in the Member

States based on e-passport, FLUX pilot programme

Annex 4         Number of participants participating in some programmes and

processing times

Annex 5         Databases and systems at EU level

Annex 6         Existing systems link to the RTP and management of the systems

Annex 7         Final results of the data collection held form 31 August to 6 September

Annex 8         Data to be stored

Annex 9         Vetting criteria

Annex 10       Costs

ANNEX 1

LIST OF ACRONYMS

ABC              Automated Border Control

Agency          Agency for operational management of large-scale IT systems in the area of freedom, security and justice

API                Advanced Passenger Information

BMS              Biometric Matching System

EBF               External Borders Fund

EDPS                        European Data Protection Supervisor

ESRIF           European Security and Research Innovation Forum

EES               Entry/Exit System

EURODAC   European Dactyloscopie (EU Fingerprint Database for Identifying Asylum Seekers

Frontex          European Agency for the management of operational cooperation at the external borders of the Member States of the European Union

IAB               Impact Assessment Board

IATA             International Air Transport Association

ISF                Internal Security Fund

MRZ              Machine Readable Zone (of the travel document)

PNR              Passenger Name Record

RTP               Registered Traveller Programme

RTS               Registered Traveller System

SBC              Schengen Borders Code

SIS                Schengen Information System

VIS                Visa Information System

ANNEX 2

COMPLEMENTARY INFORMATION ON PROBLEM DEFINITION

1. Legislative aspects

While EU citizens' and third-country nationals' border crossing lanes are separated and respective border checks differ i.e. thorough checks are normally carried out on third-country nationals and minimum checks on EU citizens and persons enjoying the right of free movement, current rules could be described as "one-size-fits-all" regardless of any differences in risk between different travellers or their frequency of travel. The main reason behind the current approach has been to ensure a consistent and high level of security with regard to all travellers, taking into account that from the perspective of the border guard carrying out the actual checks, virtually all travellers are anonymous, with few if any tools available for the border guard to distinguish between the travellers posing no risk whatsoever (the vast majority) and those that do pose such a risk.

Consequently, all third-country nationals need to go through a manual border check procedure carried out by border authorities which requires time and human resources. In accordance with the Schengen Border Code, at entry, a thorough border check for third-country nationals, in addition to a travel document check, implies a check to determine their purpose of stay, whether they possess sufficient means of subsistence etc, as well as a search in the Schengen Information System (SIS) and in national databases to verify that they are not a threat to public policy, internal security, public health and the international relations of the Schengen States. Furthermore, a search in the Visa Information System (VIS) is obligatory at entry.

Current legislation allows only minor exceptions to the principle of thorough border checks. The Schengen Borders Code regulates the facilitated border checks for Heads of State; aircraft pilots and other crew members; seamen; holders of diplomatic, official or service passports and members of international delegations; and cross-border workers. The Local Border Traffic Regulation concerns facilitated border checks for border residents who provide proof of legitimate reasons to frequently cross an external land border under the local border traffic regime.

As a result, beyond these limited exceptions, the current legal framework does not allow for differentiating between, for example, a traveller coming to Europe for the first time and a traveller arriving for 50th time, having travelled regularly every month for the past years.

2. Technical aspects

The ABC process starts with passport scanning. The traveller inserts the data page of the passport into the passport reader. The reader technically checks the physical security features of the passport, reads the Machine Readable Zone (MRZ) and communicates with the chip in the passport to verify the authenticity of the document. A live facial image (or fingerprints) of the traveller is then compared to the one stored in the chip to verify the identity of the traveller. Random checks are carried out against the SIS and national databases. This process is in principle the same as in the manual border booth but, in this case, is done by a machine. If the match is successful and the travel document is found to be genuine, the automated gate opens and the traveller can enter the territory of the Member States; if not, the traveller is referred to a manual check. Border authorities monitor the whole process including the matching of the facial image, but they can monitor several gates at once.

Some Member States have implemented a form of RTP for EU citizens. The main difference between this type of RTP and ABC is that a traveller needs to be pre-enrolled before being granted access to the RTP i.e. biometric data should be captured. The automated process at the border is the same with both programmes. However, in a RTP, a traveller's information is often stored in and retrieved from a database or in a token instead of the e-passport.

One Schengen country has a project running at the air border crossing point with a third country giving access to ABC both in the Member State and the third country. For third-country nationals, this programme involves a semi-automated border check to ensure that border guards can comply with the requirements in the Schengen Borders Code including stamping the travel document of the third-country national.

Based on Member States' experiences (but also on those of other countries such as the US), the use of an ABC system can drastically decrease waiting times, increase the throughput capacity of border crossing points and provide an effective tool with which to manage passenger flows. The US conducted a statistical analysis on the effectiveness of the Global Entry pilot programme based on data for 1 575 flights from November 19, 2008 to January 9, 2009. That analysis indicates that "participation in Global Entry may reduce a passenger's waiting time by up to 70 %. It also reduces the variability of waiting time[67]". Equally the Portuguese RAPID system has decreased both the border crossing time and human resources needed for managing passenger flows. RAPID was used between May 2007 and October 2009 by 612 066 travellers which is 18 % of the total amount of border crossings made in Portugal's external air borders by EU citizens and persons enjoying the right of free movement. The biggest group of users were men and travellers aged 26-35 years.

3. Operational and practical aspects

Current travel flows at the EU external border

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. Based on the data collected during the above mentioned 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).[68] Based on this exercise, in theory 26,5 % would qualify as a potential target group for a RTP.

The number of third-country nationals crossing the border differs significantly among Member States and also among border crossing points. Most of the third-country nationals and also third-country nationals holding visas cross the border via land borders, the next largest number by air borders and the smallest via sea borders. For example, in Finland 58 % of travellers are third-country nationals (52 % of them visa holders), whereas in Slovakia the number is 12 % (9 % of them visa holders). In Lithuania, 55 % of travellers crossing the land borders are visa holders whereas the proportion at some countries' air borders is quite small; 1 % in Luxembourg, 7 % in Portugal and 11 % in France.

Also, the total amount of travellers differs a lot between Member States. During the one week period, over three million travellers crossed the borders in Spain[69] and almost two million in France whereas the figures were only 8 000 in Luxembourg and 36 000 in Malta. Based on the figures above, one cannot estimate for the Schengen area as a whole how many third-country nationals would join a RTP and use it at a certain border crossing point.

Border processing times

To find out the time needed to cross the external border, the Czech Presidency together with the Commission launched a questionnaire. According to the Member States' replies to the questionnaire, currently the average time for a border check for visa holders on entry at the land border is 2 minutes 17 seconds, for visa-exempt nationals 1 minute 12 seconds and for EU citizens 20 seconds. The average time on exit at the land border is for visa holders 1 minute 34 seconds, for visa-exempt nationals 58 seconds and for EU citizens 18 seconds.

The average time at air borders on entry for visa holders is 1 minute 44 seconds, for visa-exempt 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.

The time spent on a border check at the sea border is not reported because the results are quite similar to checks carried out at land borders. The aforementioned times do not include anything else but basic borders check at first-line (verification of the identity of the person and checking of travel document(s) and necessary databases) in a situation where everything seems to be in order concerning the traveller.

As can be seen, the longest time is needed for border checks on entry at the land and sea borders for visa holders. However, visa holders represent only a small minority of travellers at sea borders.

From a practical point of view it should also be noted that at air borders and sea borders the sizes of airplanes[70] and ships are growing and airplane/ship timetables are very tight. On the other hand, at land borders, border checks take longer than at air borders, and they are more complex to manage in instances when individuals arrive in groups at a land border crossing point in cars, busses or trains[71]. It should also be noted that at the land border, border guards do not have any advance information on passengers before they arrive at the external border which means that it is not possible to perform any pre-arrival checks on the travellers. Normally this is not the case with other border types[72].

At the largest border crossing points there are often long queues; it can take hours to cross the external border. All passengers, including those who travel frequently and have always complied with all the rules, are negatively affected by the queues. EU citizens' and third-country nationals' border crossing lanes are separated, but this has not and will not solve the problem of queuing.

Given the very large number of border crossings, even small changes in the border crossing time are potentially very significant. However, also many other factors contribute to overall time spent at borders , including: check in times; customs checks; time spent waiting for luggage; air traffic delays and security checks.

Other factors influencing border processing times

Taking the current legislative framework as given and setting aside the use of new technology, possibilities to influence border processing times are very limited. Increasing the number of border guards working at the external border or adding new, traditional lanes and manual border control booths is not a workable solution for both practical and financial reasons as discussed already in the previous impact assessment. At many border crossing points additional traditional lanes and/or manual control booths cannot be added without undertaking extensive construction works; therefore some Member States are already using ABC/semi-automated systems at their external border crossing points.

From an EU perspective it should also be recalled that it is not possible to harmonize all factors influencing border crossing times at the border crossing points (infrastructure, exact border check procedure, number of border guards, use of ABC etc.) through legislation. Border crossing points and their passenger flows can differ significantly. This is also reflected in Article 14 of the Schengen Border Code: "Member States shall deploy appropriate staff and resources in sufficient numbers to carry out border control at the external borders, in accordance with Articles 6 to 13, in such a way as to ensure an efficient, high and uniform level of control at their external borders".[73]

Some survey results

Many people crossing the border are already familiar with e-services and are capable of dealing with different matters without outside assistance. Among the e-services most commonly used are, for example, e-invoices, e-banking, flight check-in via internet or automated kiosk and internet shopping. Also, government services are increasingly provided to citizens online. The general trend is to gradually move towards online and automated services. Taking into account the experiences of Member States having introduced ABC for EU citizens, the interest and readiness of travellers in using new technology can therefore be assumed to be high. Most travellers are willing to use ABC systems as a survey conducted in the UK shows. Based on the survey, around 90 % of UK air travellers support the use of biometric scanning and ABC systems[74]. The Netherlands conducted a survey from 9 May 2011 till 16 May in which a total of 242 of the US participants in the FLUX programme responded. 95 % of respondents considered the programme excellent or good. 82 % will renew their membership and 17 % are considering it. Some of the respondents (20 persons) asked for an expansion of the programme to other European countries. The main reason for joining the programme was a fast border crossing (98 %); not priority parking or availability of a lounge (17 %).

Australian Customs and Border Protection Service launched an independent survey involving face-to-face interviews at several airports during the last ten days of each month from October 2009 to January 2011. By almost all the respondents were generally satisfied with the service provided. More than two thirds of the respondents highlighted that SmartGate was an efficient, prompt and quick option. Over 80 % did not mention any negative aspects when questioned about SmartGate[75].

ANNEX 3

CURRENT AND PLANNED AUTOMATED BORDER CONTROL SYSTEMS IN THE MEMBER STATES

Country || Locations || Biometrics

Austria || Vienna airport || Face

Belgium || Brussels airport || Face

Czech Republic || Prague airport || Face

Estonia || Tallinn airport || Face and fingerprints

Finland || Helsinki-Vantaa Airport Vaalimaa land border crossing point || Face

France || Orly airport Paris-Charles-de-Gaulle airport || Fingerprints

Germany || Frankfurt Airport || Face

Netherlands || Schipol airport || Face/iris

Norway || Oslo airport. Plans to expand to the land border crossing points || Face

Portugal || International airports. Plans to expand to the seaports || Face

Spain || Madrid and Barcelona airports || Facie and fingerprints

United Kingdom || Several airports || Face/iris

Furthermore, at least Denmark, Bulgaria, Latvia, Romania and Hungary have preliminary plans to start using ABCs.

FLUX PILOT PROGRAMME

FLUX (Fast Low Risk Universal Crossing) is the official name for the pilot programme between the US and the NL which started on 23 April 2009. FLUX aim is to facilitate and speed up border checks for pre-approved, trusted travellers by providing them with automated processes at the border.

A single, web-based application is submitted simultaneously to both governments by the applicant. All applicants are subject to comprehensive Government background checks, collection of biometric data (Iris in NL and fingerprints in US) and interviews by both countries' officers. Each country conducts its own vetting and only for its own programme. Based on the agreed vetting criteria, several database checks are made but only "green light/red light" information is exchanged. In addition to that, travellers are checked every time when crossing the border against national databases (and the SIS in EU).

FLUX participants become a member of both Global Entry in the US and Privium in the NL. Membership is fee-based and the fee depends on the chosen option i.e. the traveller can choose a higher fee and then use preferential parking, ClubLounge etc.

ANNEX 4

NUMBER OF PARTICIPANTS PARTICIPATING IN SOME PROGRAMMES AND PROCESSING TIMES

Country || Participants || Processing time || Note

Australia and New Zealand- SmartGate || All e-passport holders – 2 million processed/year || 38 seconds (17 seconds at the automated gate) || AUS and NZ citizens

Germany - ABG || 24 000 || 10-15 seconds || EU/EEA/CH citizens

Hong Kong – eChannel (all BCPs) and Vehicular eChannel (land) || All Smart Identity Card holders || 12 seconds || Hong Kong and Macao citizens/residents + certain frequent visitors

Netherlands - PRIVIUM || 46 000 || 12 seconds || EU/EEA/CH citizens. US citizens via FLUX

Singapore - eIACS || 3 million users (70 000 transactions per day) || 8-12 seconds || Singapore and Malaysian citizens

Malaysia – Autogate (at air and land border) || 300 000 || 9-12 seconds || Malaysian citizens

United Kingdom - IRIS || 250 000 || 15 seconds || EU/EEA/CH + third-country nationals under certain conditions

United States – Global Entry, NEXUS, SENTRI, and FAST || over 1 million in Global Entry || Depends on the programme || US citizens, US nationals, US lawful permanent residents. For example, Dutch citizens via FLUX.

ANNEX 5

DATABASES AND SYSTEMS AT EU LEVEL

Centralised databases containing alerts on persons and other categories of data for law enforcement and border control purposes have been set up and/or are being developed at EU level. Furthermore, a police co-operation mechanism for exchanging information on DNA, fingerprints and vehicle registration data has been established through the Prüm Treaty/Prüm Decisions.

SIS

The Schengen Information System (SIS) is a centralised information system. The SIS, together with the cooperation of the SIRENE bureaux, set up pursuant to the provisions of Title IV of the Convention implementing the Schengen Agreement of 14 June 1985 (Schengen Convention) on the gradual abolition of checks at common borders constitutes an essential tool for the application of the provisions of the Schengen acquis as integrated into the framework of the European Union.

The main categories of data contained in the SIS are:

· Persons wanted for arrest for extradition purposes;

· Third-country nationals to be refused entry to the Schengen territory;

· Missing persons (minors and adults);

· Witnesses and persons required to appear before the judicial authorities in connection with criminal proceedings;

· Person or vehicles to be put under discreet surveillance or for specific checks;

· Certain categories of objects (e.g. stolen identity cards, vehicles, firearms, bank notes).

The SIS provides access to alerts on persons and objects to the following authorities:

· authorities responsible for border checks;

· authorities carrying out and coordinating other police and customs checks within the country;

· national judicial authorities, inter alia, those responsible for the initiation of public prosecutions in criminal proceedings and judicial inquiries prior to indictment, in the performance of their tasks, as set out in national legislation;

· authorities responsible for issuing visas, the central authorities responsible for examining visa applications, authorities responsible for issuing residence permits and for the administration of legislation on third-country nationals in the context of the application of the Union acquis relating to the movement of persons;

· authorities responsible for issuing vehicle registration certificates.

It is up to each Member State to decide which national authorities are competent and shall have access to some or all categories of SIS alerts depending on that competence.

Europol and Eurojust also have access to certain categories of alerts. Europol may access data entered for alerts for arrest, alerts for discreet surveillance or specific check and alerts on objects for seizure or use as evidence in criminal proceedings. Eurojust may access data entered for alerts for arrest and alerts for a judicial procedure.

The SIS operates on the principle that the national systems cannot exchange computerised data directly between themselves, but instead only via the central system. The SIS enables the users to check persons and objects both at external borders and within the territory of the Schengen States. The SIS provides law enforcement authorities with information on why a certain individual is wanted, what action is to be taken and whether the person is presumed violent and armed.

However, as the information contained in the SIS is only sufficient for the authorities on the ground to take the correct initial actions it is necessary for the Member States to be able to exchange supplementary information, either on a bilateral or multilateral basis, as required for implementing certain provisions of the Schengen Convention, and to ensure full application of Title IV of the Schengen Convention for the SIS as a whole.

Article 92(4) of the Schengen Convention provides that Member States shall, in accordance with national legislation, exchange through the authorities designated for that purpose (SIRENE), all information necessary in connection with the entry of alerts and for allowing the appropriate action to be taken in cases where persons in respect of whom, and objects in respect of which, data have been entered in the Schengen Information System, are found as a result of searches made in this System.

The Schengen States are the owners of the data they introduce into the SIS and bear the responsibility for their legality and accuracy.

Annual statistics on the number of alerts are collated and published by the Council, not only on the total number of alerts but also the different categories of alert.

· By the start of 2011 (01.01.2011), the total of valid records in the SIS reached 35.69 million which means an increase by 12.9% compared to the start of 2010.

· Nearly 30 million records existed on that date on lost, stolen and misappropriated identity documents (passports, identity cards, driving licence);

· More than 1.2 million records existed on that date on wanted persons;

· The vast majority of alerts on persons are about third-country nationals who shall be denied entry to the Schengen area;

· The SIS currently stores only alphanumeric data (letters and numbers), comprising data as regards individuals on[76]:

· names, including aliases;

· sex;

· objective physical characteristics not subject to change;

· date and place of birth;

· nationality;

· whether the persons are armed or violent;

· the reason for the alert; and

· the action to be taken.

In the context of EU enlargement, the technological platform needed to be upgraded and additional features were desired. For these reasons, the second-generation Schengen Information System (SIS II) is being developed.

SIS II has been designed to function in an enlarged Europe, but also to deal with new challenges and use biometrics to aid in the verification of a person's identity. SIS II will provide the following new functionalities:

· The addition of new categories of alerts (aircrafts, boats, boat engines, containers, industrial equipment, vehicle number plates, vehicle registration documents);

· The addition of new categories of data, including biometric data (biometric data such as fingerprints and digital facial images may be stored for the purposes of confirming identity; and

· The interlinking of alerts.

On 20 December 2006 two Regulations[77] and a Council Decision[78] were adopted on the establishment, operation and use of SIS II.

VIS

The Visa Information System (VIS) is a system for the exchange of short-stay visa data between the Schengen and the Schengen Associated States that was initially established in 2004[79]. All functionalities of the VIS are based on visa applications or visa decisions attached to applications. After a first registration, a visa application can be amended, until a decision is made whether or not a Schengen visa should be issued. After visa issuance, further decisions can be made, for example, an issued visa can be revoked or annulled, or a visa can be extended. VIS supports the storage, maintenance and retrieval of this information.

The main objectives of the VIS are:

· to facilitate the visa application procedure;

· to prevent the bypassing of the criteria for the determination of the Member State responsible for examining the application ("visa shopping");

· to facilitate the fight against fraud;

· to facilitate checks at external border crossing points and within the territory of the Member States;

· to assist in the identification of any person who may not, or may no longer fulfil the conditions for entry to, stay or residence on the territory of the Member States;

· to facilitate the application of Regulation (EC) No 343/2003 ("Dublin II" Regulation);

· to contribute to the prevention of threats to the internal security of any of the Member States.

According to the text of Regulation (EC) No 767/2008 of the European Parliament and of the Council of 9 July 2008, the VIS will store personal data from visa applicants:

· Data on the applicant (i.e. name, address, occupation);

· Data on the visa application process (date and place of the application, visas requested, issued, refused, annulled, revoked or extended);

· Biometrics (photographs and fingerprints).

According to Council Decision 2008/633/JHA of 23 June 2008, law enforcement authorities from Member States and Europol will have restricted and indirect access to the VIS data. Each Member State will have to designate an authority responsible for controlling law enforcement access to the database and the police will have to supply evidence that their query is necessary for criminal investigations.

Transfer of data to third countries or international organisations is in principle not allowed. By way of derogation, certain data may be transferred or made available if necessary in individual cases for proving the identity of a third country national, including for the purpose of return, providing that specific conditions are met. Data obtained pursuant to Decision 2008/633/ JHA may only be transferred or made available in an exceptional case of urgency, only for the purpose of the prevention and detection of terrorists and serious crime offences and with the consent of the Member State that entered the data. Furthermore, a permanent Management Authority (the Agency) will be responsible for the VIS database and the visa application data will be stored for a maximum of five years.

The VIS started operations in the first region on 11 October 2011 on the basis of the Commission implementing decision of 21 September 2011 (2011/636/EU) and Commission Decision of 30 November 2009 (2009/49/EC). The operations started first 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). On 10 May 2012, the VIS was successfully launched in the second region, the Near East (Israel, Jordan, Lebanon and Syria). Further, the VIS on 2 October 2012 started operations in a third region, the Gulf (Afghanistan, Bahrain, Iran, Iraq, Kuwait, Oman, Qatar, Saudi Arabia, United Arab Emirates and Yemen).

BMS

The Biometric Matching System (BMS) developed for the VIS is an information search engine that can match biometric data from visa applications, identity management systems and policing systems. The BMS is designed to enable justice and immigration authorities to deal with security and other issues related to terrorism, organized crime, irregular immigration, visa shopping, identity theft and fraud.

The BMS database will be able to store the fingerprints of up to 70 million people and process more than 100,000 verification and identification requests per day. The system will perform one-to-one comparisons for biometric verifications and one-to-many searches for biometric identifications.

The BMS is developed using a service-oriented architecture approach, has the capability to connect with a number of IT systems and manage functions related to visas, immigration, border control and police cooperation. In addition, the technical architecture will be flexible enough to accommodate new developments in EU policy as immigration and border control procedures evolve.

EURODAC

Eurodac is a fingerprint database[80] that stores and compares the fingerprints of asylum applicants and irregular immigrants and allows Member States to determine the State responsible for examining an asylum application in accordance with the Dublin II Regulation[81]. The EURODAC central unit operates a central database comparing fingerprints, an automated fingerprint identification system (AFIS) and a secure communication system for data transmission from and towards the national units (National Access Points) in Member States.

Data collected for any asylum applicants over 14 years of age include:

· Fingerprint and control images;

· Date of the asylum application;

· The Member State where the asylum application was filed;

· The gender of the applicant.

Data are collected according to three categories:

· Category 1: data of asylum applications. Fingerprints of asylum applicants are sent to the Central Unit for comparison against fingerprints of other asylum applicants who have previously lodged their application in another Member State. Fingerprint of these individuals are s deleted when an individual obtains the nationality of one of the Member States.

· Category 2: data of aliens apprehended in connection with irregular crossing of an external border and where not repatriated. Fingerprints of these individuals are sent to the EURODAC Central Unit for storage only, in order to be compared against the data of any asylum application submitted subsequently to the Central Unit. This data is retained for two years, but is deleted if the individual receives a residence permit, departs the territory of a Member State or obtains the nationality of one of the Member States.

· Category 3: data of aliens found illegally present in a Member State. This data is not stored but is searched against the data of asylum applicants stored in the central database. The transmission of this category is not mandatory but optional for Member States.

In 2010, EURODAC processed:

· 215,463 fingerprints of asylum seekers (Category 1), an 9% decrease compared to the previous year (236,936),

· 11,156 fingerprints of people crossing the borders irregularly (Category 2), a 64% decrease compared to the previous year (31,071), and

· 72,840 fingerprints of people apprehended while illegally residing on the territory of a Member State (Category 3). This figure has decreased by 14,86 % from the previous year (85,554), demonstrating a growing interest from Member States to make use of this search possibility.

The increase in transactions may be due to the fact that most Member States have installed fingerprint scanning devices at their external borders.

EURODAC data also provide information on multiple asylum applications. In 2010, 24,16 % of aliens applying for asylum had already lodged one or more applications in the same Member State or in another Member State. Out of a total of 215,463 asylum applications, 52,064 were ‘multiple applications”. See Table 1 for a comparison with previous years.

Table 1 EURODAC information on multiple applications.

Year || Number of asylum applications recorded by EURODAC (Category 1) || At least one asylum application lodged previously (in the same or in another Member State)

2007 || 197,284 || 31,910 (16,17%)

2008 || 219,557 || 38,445 (17,5%)

2009 || 236,936 || 55,226 (23.3%)

2010 || 215,463 || 52,064 (24,16%)

Sources: EURODAC annual reports[82].

Prüm Treaty

The Prüm Convention was signed between Belgium, Germany, Spain, France, Luxembourg, the Netherlands and Austria in May 2005 on the stepping up of cross-border cooperation, particularly in combating terrorism, cross-border crime and irregular migration. In June 2007, important provisions of the Prüm Treaty dealing with police co-operation and information exchange on DNA-profiles, fingerprint reference data and vehicle registration data were incorporated into the legislative framework of the EU by the Prüm Council Decisions and were scheduled to be fully implemented in all Member States by August 2011. More than half of the Member States, however, were sigificantly lagging behind this deadline in 2011. Considerable implementation progress is now expected in the course of 2012.

In addition to the above, the Treaty contains provisions for the deployment of armed air marshals on intra-Schengen flights, joint police patrols, and entry of armed police forces into another state.

The Prüm Decisions does not establish a central database containing personal data, but allow law enforcement authorities direct access to databases in other Member States in the case of vehicle registration data and access on a 'hit'/'no hit' basis to databases in the case of DNA and dactyloscopic data. Neither do they authorise the sharing of data on individuals who have been found illegally staying in a Member State or who have remained beyond their authorised length of stay in the Schengen area.

API

According to Article 26 of the Schengen Convention, carriers are responsible for the checking of documents of the passengers they transport into the Member States and may be penalised when third country nationals are found at the borders without the necessary travel documents.

Following the decision of the Executive Committee of Schengen in 1994 which considered the advanced transmission of passenger data as a valuable tool for enhancing border security, Member States gradually implemented API practices reflecting diversified national approaches. In order to harmonise these practices and introduce common standards on the information to be transmitted as well as on the data protection safeguarding clauses, Spain presented in 2003 an Initiative that led to the adoption of the Council Directive 2004/82/EC of 29 April 2004 on the obligation of carriers to transmit passenger information (API Directive).

The explicit purposes of this Directive are to improve border control and combat illegal immigration by the transmission of advance passenger data by air carriers to the competent national authorities.

Whilst the initial proposal aimed for the inclusion of all carriers, the version finally adopted limits its scope to air carriers given their key role in controlling immigration flows from distant places of origin and since they alone had the necessary registration system. In any case, the Directive does not prevent Member States from imposing obligations on other carriers.

On the other hand the Directive does not introduce a general obligation for air carriers to transmit passenger information since data is only transmitted at the request of border authorities, depending on Member States appreciation of the risks involved. Moreover the information concerns only passengers who are carried from third countries into EU territory. The information shall be transmitted electronically (or in case of failure by any appropriate means), in advance of departure, to the authorities of the first authorised border crossing point.

Information shall comprise:

· the number and type of travel document used,

· nationality,

· full names,

· the date of birth,

· the border crossing point of entry into the territory of the Member States,

· code of transport,

· departure and arrival time of the transportation,

· total number of passengers carried on that transport,

· the initial point of embarkation.

Article 4 of the Directive foresees an obligation on Member States to impose dissuasive penalties on carriers, which, as a result of fault, have not transmitted the data required or have transmitted incomplete or false data (maximum amount not less than 5 000 €, minimum amount not less than 3 000 €).

The transmission, use and storage of such data are subject to strict compliance with Directive 95/46/EC on data protection by the authorities of the Member States and carriers. Data must be deleted by carriers within 24 hours after the arrival and also by the border authorities unless data is needed as evidence in proceedings aiming at the enforcement of legislation on entry and immigration.

The deadline to transpose the Directive was 5 September 2006. All Member States have adopted national measures to comply with the Directive since then.

However, according to the information available in most Member States no systematic use of the advanced passenger information is made yet.

PNR

PNR data is unverified information provided by passengers, and collected by and held in air carriers' reservation and departure control systems for their own commercial purposes. It contains several different types of information, such as travel dates, travel itinerary or ticket information. In February 2011, the Commission presented a proposal for a Directive on the use of PNR data for the prevention, detection, investigation and prosecution of terrorist offences and serious crime[83].

ANNEX 6

EXISTING SYSTEMS LINK TO THE RTP AND MANAGEMENT OF THE SYSTEMS

When a third-country national enters the Schengen area it is obligatory for border authorities to consult the data and alerts on persons and, where necessary, objects included in the SIS. When a third-country national exits the Schengen area, the SIS may be consulted. This means that due to the current use of the SIS, the border crossing points are connected to the data network and equipped with travel document readers. The SIS check is carried out automatically when the MRZ of the travel document is read.

A second EU system, the VIS, forms an important part of the border check process. In order to facilitate border checks and fight against visa fraud, visas are checked at the external borders against the VIS by using the visa sticker number. Verification of fingerprints at the external border crossing points will also become mandatory after a three year transitional period from the start of operations.

The same document readers that are used for the SIS checks and the same fingerprint readers that are used for the VIS checks may also be used for the RTP. Furthermore, ABC systems already implemented at the border may be used in the future for automation of third-country nationals´ border crossings through the integration of fingerprint readers. In some ABC systems fingerprint readers already exist.

With the RTP in mind, the above means that consulates and border crossing points should have already been connected to the data network (VIS and SIS) and fingerprint readers on entry will have been procured by 2013/2014 at the latest to fulfil the requirements for the obligatory use of the VIS.

Management

As regards large scale IT systems, only EURODAC and the VIS are operational and managed by Directorate HOME of the Commission with the support of DG DIGIT in the case of EURODAC[84]. The EURODAC system is located in Luxembourg and Brussels. SIS II is and VIS was developed by the Commission and based on the legal instruments establishing and governing SIS II and VIS the systems shall be located in Strasbourg (central unit) and near Salzburg (back-up unit). The VIS already started operations and the development of the SISII is ongoing.

Following an impact assessment carried out to study the different options for performing the task of "Management Authority" for SIS II, VIS and EURODAC in the long term, a new Regulatory Agency (the Agency for the operational management of large-scale information systems) was found to be the best solution as compared with entrusting Member States with operational tasks for part or all of the systems, FRONTEX with the three systems or EUROPOL with SIS II and the Commission with VIS and EURODAC.

The Agency Regulation was published in the Official Journal[85] and entered into force on 21 November 2011. The Agency will become fully operational on 1 December 2012. The selection procedure of its staff has started.

The Agency is funded from the general budget of the European Union. The budget foreseen for start-up activities of the Agency between 2011 and 2013 is 94,5 million EUR. The budget of the Agency mainly covers investments in the site, security and operational management of the SIS II, the VIS and EURODAC and administrative expenses. This amount is covered by the financial framework 2007-2013.

According to the Regulation of the European Parliament and the Council establishing an Agency for the operational management of large-scale systems in the area of freedom, security and justice, the Agency will be in charge of the operational management of the SIS II, the VIS, EURODAC and of developing and managing other large-scale information technology systems in the area of freedom, security and justice if so provided by relevant legislative instruments.

A RTP, whether fully centralised or based on a token/central repository, would be developed and managed by the Agency. Member States would be responsible for the development and management of their national components and their adaptation to the central system. For a token based system, the same standards could be used as for residence permits to guarantee that the information stored in a token could be used across Schengen States, and existing equipment installed at the borders and at the consulates could be exploited. A token based system would be developed by the Member States based on the standards mentioned above. A legal basis for the RTP needs to be adopted prior to any technical development.

ANNEX 7

FINAL RESULTS OF THE DATA COLLECTION HELD FROM 31 AUGUST TO 6 SEPTEMBER 2009

The tables in this annex details the results of the data collection exercise carried out under the coordination of the Czech and Swedish Presidencies, where all entries and exits at the external border of the Schengen area were recorded by the Member States during one week for the purpose of estimating the total size of travel flows at the external border, in total and divided by type of border (air/sea/land) and by traveller (EU citizens, and visa exempt/required third-country nationals).

|| AIR || Total

|| Entry || Exit ||

|| EU || Non VISA || VISA || EU || Non VISA || VISA || Air

Austria || 81.096 || 17.781 || 11.671 || 64.799 || 16.134 || 9.109 || 200.590

Belgium || 78.372 || 14.295 || 15.432 || 68.132 || 10.028 || 8.955 || 195.214

Czech Republic || 43.531 || 9.100 || 11.365 || 42.386 || 7.442 || 9.121 || 122.945

Denmark || 40.764 || 9.924 || 4.894 || 52.139 || 8.454 || 3.354 || 119.529

Estonia || 2.745 || 78 || 126 || 2.532 || 87 || 141 || 5.709

Finland || 17.662 || 5.128 || 4.042 || 19.497 || 4.703 || 2.901 || 53.933

France || 405.109 || 91.773 || 64.266 || 340.832 || 77.555 || 43.853 || 1.023.388

Germany || 343.836 || 106.716 || 106.242 || 296.300 || 91.998 || 69.345 || 1.014.437

Greece || 216.316 || 33.475 || 19.745 || 213.467 || 34.135 || 19.473 || 536.611

Hungary || 20.347 || 4.002 || 3.294 || 18.706 || 3.313 || 2.588 || 52.250

Iceland || 4.348 || 2.658 || 92 || 5.223 || 3.318 || 148 || 15.787

Italy || 94.293 || 23.353 || 17.517 || 58.347 || 19.087 || 11.917 || 224.514

Latvia || 12.946 || 1.850 || 911 || 12.096 || 1.660 || 1.118 || 30.581

Lithuania || 3.899 || 44 || 300 || 4.352 || 250 || 267 || 9.112

Luxembourg || 4.000 || 111 || 51 || 4.220 || 183 || 62 || 8.627

Malta || 15.255 || 864 || 793 || 16.729 || 865 || 978 || 35.484

Netherlands || 265.066 || 45.454 || 30.906 || 413.315 || 46.139 || 29.766 || 830.646

Norway || 20.838 || 2.298 || 1.628 || 24.042 || 2.167 || 1.452 || 52.425

Poland || 97.900 || 4.493 || 2.460 || 102.379 || 5.496 || 1.931 || 214.659

Portugal || 50.208 || 11.436 || 5.558 || 44.584 || 11.269 || 3.840 || 126.895

Slovakia || 14.316 || 405 || 108 || 11.946 || 262 || 54 || 27.091

Slovenia || 7.522 || 1.219 || 2.597 || 6.253 || 955 || 1.908 || 20.454

Spain || 661.325 || 29.184 || 36.080 || 661.387 || 24.609 || 31.290 || 1.443.875

Sweden || 43.177 || 4.165 || 4.436 || 45.416 || 4.560 || 3.542 || 105.296

Switzerland || 75.048 || 35.143 || 18.639 || 75.249 || 29.075 || 15.340 || 248.494

Total || 2.538.823 || 437.168 || 351.482 || 2.539.529 || 387.610 || 263.344 || 6.517.956

Total entry AIR || 3.327.473 || || || || || ||

Total exit AIR || 3.190.483 || || || || || ||

|| SEA || Total

|| Entry || Exit ||

|| EU || Non VISA || VISA || EU || Non VISA || VISA || Sea

Austria || 0 || 0 || 0 || 0 || 0 || 0 || 0

Belgium || 5.036 || 94 || 321 || 6.128 || 96 || 363 || 12.038

Czech Republic || 0 || 0 || 0 || 0 || 0 || 0 || 0

Denmark || 937 || 12 || 11 || 1.881 || 20 || 26 || 2.887

Estonia || 266 || 287 || 137 || 262 || 300 || 230 || 1.482

Finland || 582 || 15 || 45 || 461 || 19 || 23 || 1.145

France || 174.848 || 18.948 || 2.148 || 236.231 || 9.771 || 2.581 || 444.527

Germany || 15.615 || 1.019 || 9.542 || 12.813 || 658 || 7.376 || 47.023

Greece || 48.343 || 12.249 || 3.228 || 49.695 || 12.439 || 3.833 || 129.787

Hungary || 0 || 0 || 0 || 0 || 0 || 0 || 0

Iceland || 0 || 0 || 0 || 0 || 0 || 0 || 0

Italy || 23.574 || 5.012 || 3.826 || 10.417 || 1.077 || 1.714 || 45.620

Latvia || 449 || 464 || 322 || 424 || 544 || 307 || 2.510

Lithuania || 218 || 496 || 0 || 495 || 504 || 0 || 1.713

Luxembourg || 0 || 0 || 0 || 0 || 0 || 0 || 0

Malta || 315 || 43 || 138 || 42 || 20 || 111 || 669

Netherlands || 25.176 || 5.334 || 1.060 || 27.358 || 7.196 || 1.084 || 67.208

Norway || 0 || 0 || 0 || 0 || 0 || 0 || 0

Poland || 722 || 751 || 121 || 865 || 839 || 137 || 3.435

Portugal || 5.756 || 623 || 1.567 || 4.418 || 504 || 1.477 || 14.345

Slovakia || 0 || 0 || 0 || 0 || 0 || 0 || 0

Slovenia || 564 || 439 || 70 || 1.083 || 902 || 95 || 3.153

Spain || 135.830 || 63.919 || 7.459 || 67.934 || 24.199 || 10.226 || 309.567

Sweden || 2.121 || 653 || 729 || 2.198 || 2.422 || 717 || 8.840

Switzerland || 0 || 0 || 0 || 0 || 0 || 0 || 0

Total || 440.352 || 110.358 || 30.724 || 422.705 || 61.510 || 30.300 || 1.095.949

Total entry SEA || 581.434 || || || || || ||

Total exit SEA || 514.515 || || || || || ||

|| LAND || Total

|| Entry || Exit ||

|| EU || Non VISA || VISA || EU || Non VISA || VISA || Land

Austria || 0 || 0 || 0 || 0 || 0 || 0 || 0

Belgium || 0 || 0 || 0 || 21.686 || 2.301 || 848 || 24.835

Czech Republic || 0 || 0 || 0 || 0 || 0 || 0 || 0

Denmark || 0 || 0 || 0 || 0 || 0 || 0 || 0

Estonia || 39.640 || 755 || 4.515 || 38.051 || 841 || 5.030 || 88.832

Finland || 21.050 || 528 || 46.441 || 21.733 || 514 || 45.606 || 135.872

France || 150.853 || 15.678 || 3.170 || 186.855 || 13.087 || 3.855 || 373.498

Germany || 0 || 0 || 0 || 0 || 0 || || 0

Greece || 126.563 || 25.854 || 42.206 || 129.486 || 16.612 || 34.702 || 375.423

Hungary || 331.415 || 27.229 || 75.445 || 247.051 || 22.208 || 41.033 || 744.381

Iceland || 0 || 0 || 0 || 0 || 0 || 0 || 0

Italy || 0 || 0 || 0 || 0 || 0 || 0 || 0

Latvia || 21.543 || 124 || 4.862 || 20.397 || 112 || 5.609 || 52.647

Lithuania || 26.992 || 1.502 || 33.921 || 24.642 || 1.413 || 32.472 || 120.942

Luxembourg || 0 || 0 || 0 || 0 || 0 || 0 || 0

Malta || 0 || 0 || 0 || 0 || 0 || 0 || 0

Netherlands || 0 || 0 || 0 || 0 || 0 || 0 || 0

Norway || 255 || 154 || 637 || 257 || 199 || 672 || 2.174

Poland || 87.310 || 1.266 || 118.474 || 83.852 || 1.264 || 112.190 || 404.356

Portugal || 0 || 0 || 0 || 0 || 0 || 0 || 0

Slovakia || 18.075 || 440 || 3.777 || 15.895 || 477 || 2.471 || 41.135

Slovenia || 393.473 || 187.379 || 78.480 || 324.828 || 161.713 || 51.867 || 1.197.740

Spain || 400.584 || 324.724 || 5.629 || 415.409 || 324.654 || 5.048 || 1.476.048

Sweden || 0 || 0 || 0 || 0 || 0 || 0 || 0

Switzerland || 0 || 0 || 0 || 0 || 0 || 0 || 0

Total || 1.617.753 || 585.633 || 417.557 || 1.530.142 || 545.395 || 341.403 || 5.037.883

Total entry LAND || 2.620.943 || || || || || ||

Total exit LAND || 2.416.940 || || || || || ||

|| Passenger category

|| EU || Non VISA || VISA

|| Entry EU || Exit EU || Entry Non VISA || Exit non VISA || Entry VISA || Exit VISA

Austria || 81.096 || 64.799 || 17.781 || 16.134 || 11.671 || 9.109

Belgium || 83.408 || 95.946 || 14.389 || 12.425 || 15.753 || 10.166

Czech Republic || 43.531 || 42.386 || 9.100 || 7.442 || 11.365 || 9.121

Denmark || 41.701 || 54.020 || 9.936 || 8.474 || 4.905 || 3.380

Estonia || 42.651 || 40.845 || 1.120 || 1.228 || 4.778 || 5.401

Finland || 39.294 || 41.691 || 5.671 || 5.236 || 50.528 || 48.530

France || 730.810 || 763.918 || 126.399 || 100.413 || 69.584 || 50.289

Germany || 359.451 || 309.113 || 107.735 || 92.656 || 115.784 || 76.721

Greece || 391.222 || 392.648 || 71.578 || 63.186 || 65.179 || 58.008

Hungary || 351.762 || 265.757 || 31.231 || 25.521 || 78.739 || 43.621

Iceland || 4.348 || 5.223 || 2.658 || 3.318 || 92 || 148

Italy || 117.867 || 68.764 || 28.365 || 20.164 || 21.343 || 13.631

Latvia || 34.938 || 32.917 || 2.438 || 2.316 || 6.095 || 7.034

Lithuania || 31.109 || 29.489 || 2.042 || 2.167 || 34.221 || 32.739

Luxembourg || 4.000 || 4.220 || 111 || 183 || 51 || 62

Malta || 15.570 || 16.771 || 907 || 885 || 931 || 1.089

Netherlands || 290.242 || 440.673 || 50.788 || 53.335 || 31.966 || 30.850

Norway || 21.093 || 24.299 || 2.452 || 2.366 || 2.265 || 2.124

Poland || 185.932 || 187.096 || 6.510 || 7.599 || 121.055 || 114.258

Portugal || 55.964 || 49.002 || 12.059 || 11.773 || 7.125 || 5.317

Slovakia || 32.391 || 27.841 || 845 || 739 || 3.885 || 2.525

Slovenia || 401.559 || 332.164 || 189.037 || 163.570 || 81.147 || 53.870

Spain || 1.197.739 || 1.144.730 || 417.827 || 373.462 || 49.168 || 46.564

Sweden || 45.298 || 47.614 || 4.818 || 6.982 || 5.165 || 4.259

Switzerland || 75.048 || 75.249 || 35.143 || 29.075 || 18.639 || 15.340

Total || 4.596.928 || 4.492.376 || 1.133.159 || 994.515 || 799.763 || 635.047

|| Total || Total

|| Passenger category ||

|| EU || Non VISA || VISA || Entry || Exit || Total

Austria || 145.895 || 33.915 || 20.780 || 110.548 || 90.042 || 200.590

Belgium || 179.354 || 26.814 || 25.919 || 113.550 || 118.537 || 232.087

Czech Republic || 85.917 || 16.542 || 20.486 || 63.996 || 58.949 || 122.945

Denmark || 95.721 || 18.410 || 8.285 || 56.542 || 65.874 || 122.416

Estonia || 83.496 || 2.348 || 10.179 || 48.549 || 47.474 || 96.023

Finland || 80.985 || 10.907 || 99.058 || 95.493 || 95.457 || 190.950

France || 1.494.728 || 226.812 || 119.873 || 926.793 || 914.620 || 1.841.413

Germany || 668.564 || 200.391 || 192.505 || 582.970 || 478.490 || 1.061.460

Greece || 783.870 || 134.764 || 123.187 || 527.979 || 513.842 || 1.041.821

Hungary || 617.519 || 56.752 || 122.360 || 461.732 || 334.899 || 796.631

Iceland || 9.571 || 5.976 || 240 || 7.098 || 8.689 || 15.787

Italy || 186.631 || 48.529 || 34.974 || 167.575 || 102.559 || 270.134

Latvia || 67.855 || 4.754 || 13.129 || 43.471 || 42.267 || 85.738

Lithuania || 60.598 || 4.209 || 66.960 || 67.372 || 64.395 || 131.767

Luxembourg || 8.220 || 294 || 113 || 4.162 || 4.465 || 8.627

Malta || 32.341 || 1.792 || 2.020 || 17.408 || 18.745 || 36.153

Netherlands || 730.915 || 104.123 || 62.816 || 372.996 || 524.858 || 897.854

Norway || 45.392 || 4.818 || 4.389 || 25.810 || 28.789 || 54.599

Poland || 373.028 || 14.109 || 235.313 || 313.497 || 308.953 || 622.450

Portugal || 104.966 || 23.832 || 12.442 || 75.148 || 66.092 || 141.240

Slovakia || 60.232 || 1.584 || 6.410 || 37.121 || 31.105 || 68.226

Slovenia || 733.723 || 352.607 || 135.017 || 671.743 || 549.604 || 1.221.347

Spain || 2.342.469 || 791.289 || 95.732 || 1.664.734 || 1.564.756 || 3.229.490

Sweden || 92.912 || 11.800 || 9.424 || 55.281 || 58.855 || 114.136

Switzerland || 150.297 || 64.218 || 33.979 || 128.830 || 119.664 || 248.494

Total || 9.089.304 || 2.127.674 || 1.434.810 || 6.529.850 || 6.121.938 ||

|| || || || || || 12.651.788

|| AIR || Total || ||

|| Entry || Exit || || ||

|| EU || Non VISA || VISA || EU || Non VISA || VISA || Air || ||

Bulgaria || 79.034 || 5.448 || 11.407 || 96.899 || 5.943 || 16.206 || 214.937 || ||

Romania || 78.238 || 6.037 || 1.146 || 79.597 || 5.790 || 1.071 || 171.879 || ||

Cyprus || 109.944 || 1.532 || 18.863 || 108.887 || 1.313 || 9.402 || 249.941 || ||

|| || || || || || || || ||

|| SEA || Total || ||

|| Entry || Exit || || ||

|| EU || Non VISA || VISA || EU || Non VISA || VISA || Sea || ||

Bulgaria || 1.351 || 106 || 2.284 || 1.329 || 2 || 2.532 || 7.604 || ||

Romania || 570 || 782 || 8 || 632 || 661 || 2 || 2.655 || ||

Cyprus || 2.558 || 39 || 315 || 2.484 || 51 || 281 || 5.728 || ||

|| || || || || || || || ||

|| LAND || Total || ||

|| Entry || Exit || || ||

|| EU || Non VISA || VISA || EU || Non VISA || VISA || Land || ||

Bulgaria || 213.298 || 2.454 || 43.172 || 206.926 || 2.461 || 32.473 || 500.784 || ||

Romania || 293.755 || 6.675 || 30.410 || 340.900 || 2.752 || 39.830 || 714.322 || ||

Cyprus || 0 || 0 || 0 || 0 || 0 || 0 || 0 || ||

|| || || || || || || || ||

|| Passenger category || Total

|| EU || Non VISA || VISA || Passenger category

|| Entry EU || Exit EU || Entry Non || Exit non || Entry || Exit || EU || Non || VISA

|| || || VISA || VISA || VISA || VISA || || VISA ||

Bulgaria || 293.683 || 305.154 || 8.008 || 8.406 || 56.863 || 51.211 || 598.837 || 16.414 || 108.074

Romania || 372.563 || 421.129 || 13.494 || 9.203 || 31.564 || 40.903 || 793.692 || 22.697 || 72.467

Cyprus || 112.502 || 111.371 || 1.571 || 1.364 || 19.178 || 9.683 || 223.873 || 2.935 || 28.861

|| || || || || || || || ||

|| Total || || || || || ||

|| || || || || || ||

|| Entry || Exit || Total || || || || || ||

Bulgaria || 358.554 || 364.771 || 723.325 || || || || || ||

Romania || 417.621 || 471.235 || 888.856 || || || || || ||

Cyprus || 133.251 || 122.418 || 255.669 || || || || || ||

|| || || || || || || || ||

ANNEX 8

DATA TO BE STORED

The following alphanumeric data and biometrics would be stored either in a token or in a centralised database or in a Member States' national database to guarantee that border and visa authorities can always verify whether the person really is a registered traveller and whether (s)he still fulfils the requirements of the programme. For example, if the registered traveller does not have sufficient means of subsistence, the data in a token/central database/national database/central repository confirms that there is a person liable to pay applicant's subsistence costs during the stay.

1. the unique application number (unique identifier);

2. status information, indicating that access to the RTP has been requested;

3. the authority with which the application has been lodged, including its location;

4. the following data to be taken from the application form:

(a) surname(s); first name(s); date of birth, place of birth, nationality(ies); country of birth and gender;

(b) type, number (and in case of a fully centralised system three letter code of the issuing country) of the travel document(s), the authority which issued it and the date of issue and of expiry;

(c) place and date of the application;

(d) if applicable, details of the person liable to pay the applicant's subsistence costs during the stay, being:

(i) in the case of a natural person, the surname and first name, address of the person and telephone number;

(ii) in the case of a company or other organisation, the name and address of the company/other organisation, surname and first name of the contact person in that company/organisation and telephone number;

(e) main purposes of the journeys;

(f) the applicant's home address,

(g) the applicant's telephone number and e-mail address, if available;

(h) if applicable, the visa sticker number;

(i) if applicable, the residence permit number (and in the case of a fully centralised system the three letter code of the issuing country) ;

(j) in the case of minors, surname(s) and first name(s) of the applicant's parental authority or legal guardian,

5. fingerprints.

ANNEX 9

VETTING CRITERIA[86]

In the examination of an application, visa or border authorities should verify that the following entry conditions are fulfilled:

(a) the applicant does not present a risk of illegal immigration or a risk to the security of the Member States and the applicant intends to leave the territory of the Member States in due time;

(b) the applicant's travel document, visa or residence permit presented, if applicable, are valid and not false, counterfeited or forged;

(c) the applicant proves the need for or justifies the intention to travel frequently and/or regularly;

(d) the applicant has not previously exceeded the maximum duration of authorised stay in the territory of the Member States and he/she proves his/her reliability, in particular a genuine intention to leave the territory in due time;

(e) the applicant's justification of the purpose and conditions of the intended stays,

(f) the applicant proves his/her financial situation in the country of origin or residence and possesses sufficient means of subsistence both for the duration of the intended stay(s) and for the return to his/her country of origin or residence, or he/she is in a position to acquire such means lawfully;

(g) the applicant is not a person for whom an alert has been issued in the Schengen Information System (SIS);

(h) the applicant is not considered to be a threat to public policy, internal security, public health or the international relations of any of the Member States, in particular where no alert has been issued in Member States’ national databases on the same grounds.

ANNEX 10

TOTAL COSTS

1.         Cost Assessments

This Annex provides the cost estimates for the different options that are described in the present impact assessment.

An external contractor carried out the cost study in 2010[87], which aimed at getting an objective cost estimation, comparing various options and sub-options in search of the most cost-effective ones, while evaluating the different business alternatives. The assessment of cost effectiveness was related to the one-time costs for the development and to the yearly operational costs, which can decrease or invert savings in development costs in a very short period of time.

Based on the scenario-driven approach of the cost study and the cost models developed therein, it was possible to update the scenarios with modified options in line with ongoing discussions internally and with Member States.

2.         Methodology

The cost analysis study began by defining detailed scenarios and border-related specifications. Member States were involved in the preparation of the definition of the parameters in the cost study[88]. The IT-related cost factors were taken from current market prices.

To calculate the costs accurately, the following techniques were used:

· Sizing

– Hardware sizing based on simplified process models and forecasted numbers of registered travellers' travel events. Sizing in this context comes down to actually determine which of building blocks are required for which scenarios, thus calculating the actual "horsepower" needed to meet the required performance.

– Software development sizing based on information in the Feasibility Study and completed with Function Point Analysis when necessary.

– Network sizing based on predictions of the expected system load.

· Costing

– Parametric cost analysis techniques were used to estimate development efforts and maintenance costs to support the introduction of a new software product.

– Parametric cost estimation is based on the functional size of the solution, the level of re-usability of existing products and the proportion of "commercial of the shelf" (COTS) products that are used. Additional parameters are the hourly rates and skill levels of the development team as well as parameters associated with the development environment and project governance.

– Estimates of the costs of third party hardware, software and network products were based on list prices of popular and appropriate COTS products.

– For estimating operational costs a harmonised model was assumed, in which the average rates were used across the Member States. The same approach was chosen regarding the business hours throughout the European Union as well as the same number of holidays.

· Planning

– The initial planning was produced by the parametric costing tool "CostXpert". This includes in a first automated run specification, design, realisation, testing and implementation and the first phase of deployment, where any defects have been detected.

– Manual intervention and adjustment of the schedule became necessary, as "CostXpert" assumes unlimited resources to be available, which means that the planning needs to be adjusted to align it with the expected situation.

Based on these techniques for cost modelling, the different scenarios were established and calculated for the central side (Management Authority; EU budget) and the national side (Member States' authorities, national budget)

Moreover, the gathered experiences and lessons learnt from the development of EURODAC, VIS and SIS II were also used to evaluate the cost calculations and the scenarios to improve the reliability of the cost calculation.

3.         Facts and Figures used

General Parameters

For the cost calculation, a complete range of parameters (business parameters, technical parameters, cost parameters, data specifications, and parameters on the side of the Member States[89]) were used:

· Development of three years and five years of operation.

· Both the EES and the RTP should, as far as possible, take advantage of the existing and fully rolled out the VIS and the SIS.

· Maintenance rate of hardware (8 %) and software (20 %).

· Hourly rates for contractors, management authority staff and EU (27) and Schengen associated country staff, working hours per year.

· Costs for the token 1 EUR (without biometrics).

· For the network costs, the costs of the sTESTA network for the VIS were used.

Registered Traveller Programme

For the RTP, the following core parameters were used for the sizing of the system:

RTS Parameter || || 2013 || 2014 || 2015 || 2016 || 2017 || 2018 || 2019 || 2020

Yearly Registrations || (million) || 5.0 || 5.0 || 5.0 || 5.0 || 5.0 || 5.0 || 5.0 || 5.0

Registered traveller IN || (million) || 30 || 60 || 90 || 120 || 150 || 150 || 150 || 150

Registered traveller OUT || (million) || 30 || 60 || 90 || 120 || 150 || 150 || 150 || 150

Applications Consular Posts || (million) ||                       2.8 ||               2.8 ||               2.8 ||                 2.8 ||                 2.8 ||                 2.8 ||             2.8 ||                 2.8

Applications at external BCP || (million) ||              2.3 ||                       2.3 ||                       2.3 ||                       2.3 ||                       2.3 ||                       2.3 ||                       2.3 ||                       2.3

BCP Enrolments || (%) || 45% || 45% || 45% || 45% || 45% || 45% || 45% || 45%

Percentage of revocations/extensions || (%) || 5% || 5% || 5% || 5% || 5% || 5% || 5% || 5%

Average number or Rregistered travellers travels per yr || (n) || 6 || 6 || 6 || 6 || 6 || 6 || 6 || 6

The cost per hour is based on a weighted average of the cost in EU27 administrations and the cost in Associated countries and has been rounded.[90]

The amount of human resources released by the RTP at the external borders is not taken into account due to the fact that it cannot be exactly calculated nor estimated. It varies a lot between Member States and indeed between individual border crossing points. In the longer term, Member States will have net cost savings especially if Automated Border Control Systems are used at the busiest border crossing points. Immediately after the start of operations of the RTP, the real administrative burden for border authorities will be positive. In the consulates the administrative cost will be real, as acceptance of applications will not release any human resources there. On the other hand, an application for a multiple-entry visa and an application for RTP can be processed at the same time which will diminish the amount of extra work.

ANNEX 10.1

EU Cost Model: || Yearly operational costs || Total one time development costs

Token-Based RTP

No || || || European Union (EU) || Member States (MS)

1 || Management Authority || || ||

2 || Management Authority Hardware || || ||

3 || Management Authority Other (training, meetings) || || ||

4 || Management Authority Infrastructure || || ||

5 || Management Authority software || || ||

6 || Management Authority Admin || || ||

7 || Management Authority Office Space || || ||

8 || Management Authority Contractor Development || || ||

9 || Subtotal MA || || ||

10 || || || ||

11 || Member States *) || || ||

12 || Member States Hardware || 32.000 || || 23.094.000

13 || Member States Other (training, meetings) || 273.916 || || 2.739.162

14 || Member States Infrastructure || - || || -

15 || Member States software || 978.200 || || 41.874.100

16 || Member States Admin || 53.450.881 || || 40.205.855

17 || Member States Office Space || 14.541.600 || || 35.385.840

18 || Member States Contractor Development || 811.725 || || 8.117.246

19 || Costs of tokens || 25.000.000 || ||

20 || Subtotal MS || 95.088.322 || || 151.416.203

*) Member States means the Schengen area as of 19.12.2011 plus Bulgaria and Romania and was calculated as one entity. ANNEX 10.2

EU Cost Model: || Yearly operational costs || Total one time development costs

Centralised RTP

No || || || European Union (EU) || Member States (MS)

1 || Management Authority || || ||

2 || Management Authority Hardware || 1.032.000 || 4.152.000 ||

3 || Management Authority Other (training, meetings) || 502.145 || 502.145 ||

4 || Management Authority Infrastructure || 8.041.965 || 9.248.260 ||

5 || Management Authority software || 4.748.000 || 19.250.000 ||

6 || Management Authority Admin || 2.960.641 || 1.311.734 ||

7 || Management Authority Office Space || 9.000 || 27.000 ||

8 || Management Authority Contractor Development || 311.811 || 3.118.105 ||

9 || Subtotal MA || 17.605.562 || 37.609.244 ||

10 || || || ||

11 || Member States || || ||

12 || Member States Hardware || 24.000 || || 23.094.000

13 || Member States Other (training, meetings) || 285.756 || || 2.857.555

14 || Member States Infrastructure || - || || -

15 || Member States software || 1.878.200 || || 41.874.100

16 || Member States Admin || 58.906.097 || || 40.375.430

17 || Member States Office Space || 14.541.600 || || 35.385.840

18 || Member States Contractor Development || 845.876 || || 8.458.763

19 || Subtotal MS || 76.481.529 || || 152.045.688

ANNEX 10.3

EU Cost Model: || Yearly operational costs || Total one time development costs

Token together with central repository

No || || || European Union (EU) || Member States (MS)

1 || Management Authority || || ||

2 || Management Authority Hardware || 1.032.000 || 7.474.000 ||

3 || Management Authority Other (training, meetings) || 502.145 || 502.145 ||

4 || Management Authority Infrastructure || 8.041.965 || 9.248.260 ||

5 || Management Authority software || 8.398.000 || 19.250.000 ||

6 || Management Authority Admin || 1.960.641 || 2.658.448 ||

7 || Management Authority Office Space || 9.000 || 27.000 ||

8 || Management Authority Contractor Development || 372.801 || 3.728.008 ||

9 || Subtotal MA || 20.316.552 || 42.887.861 ||

10 || || || ||

11 || Member States || || ||

12 || Member States Hardware || 24.000 || || 23.094.000

13 || Member States Other (training, meetings) || 285.756 || || 2.857.555

14 || Member States Infrastructure || - || || -

15 || Member States software || 1.878.200 || || 41.874.100

16 || Member States Admin || 58.106.097 || || 53.830.027

17 || Member States Office Space || 14.541.600 || || 35.385.840

18 || Member States Contractor Development || 845.876 || || 7.417.173

19 || Costs of tokens || 5.000.000 || ||

20 || Subtotal MS || 80.681.529 || || 164.458.695

ANNEX 10.4 – Administrative costs

The Agency's administrative costs correspond to the categories 3 and 6 of the total one time development cost (EU) in Annexes 10.1-10.3. and to the same categories of total yearly operational costs (EU).

Member States' administrative costs correspond to the categories 13 and 16 of the total one time development cost (MS) in Annexes 10.1-10.3. and to the same categories of the total yearly operational costs (MS).

Policy option 1

· Administrative costs for Member States

The administrative costs related to the examination of applications which are not included in the Annexes 10.1. – 10.3. will be tangible. It is estimated that 5 million third-country nationals would apply for access to the RTP each year. Examination of one application would last 45 minutes, on average[91], including checking the supporting documents, capturing biometric data and conducting interviews, if applicable. In the abstract, the total time needed for examining and granting/refusing access to the RTP would be 2,81 million hours equivalent to 73,1 million EUR or 1 705 persons[92] across Member States. This cost is equal for both sub-options 1a (applications lodged at the border) and 1b (applications lodged at the consulates), and would therefore be borne entirely by either the border crossing points or the consulates. However, these costs would be covered by the fee (20 or 10 EUR).

In sub-option 1c - allowing the lodging of applications at the border crossing points as well as at the consulates – these costs, and the need for extra staff, would have to be borne roughly equally by the consulates and the border crossing points.

Policy option 2

· Administrative cost for the Agency:

Administrative costs for the Agency caused by a centralised system would be approximately 1,8[93] million EUR for establishing the system and 3,5 million EUR for the annual maintenance/operating the system.

Administrative costs for the Agency caused by a token/repository system would be around 3,2 million EUR for establishing the system and 2,7 million for the annual maintenance/operating the system.

· Administrative cost for Member States:

Administrative costs for Member States created by a token-based system would be approximately 43[94] million EUR for establishing the system and 54 million EUR[95] for the annual maintenance/operating the system.

Administrative costs for Member States arising from the development of a centralised system would be approximately 43 million EUR for establishing the system and 59 million EUR for the annual maintenance/operating of the system[96].

Administrative costs for Member States arising from the development of a token/repository system would be approximately 57 million EUR for establishing the system and 58 million EUR for the annual maintenance/operating of the system.

Policy options 3 and 4

· Administrative cost for the Member States:

With stricter vetting procedure all Member States would face a noticeable extra workload with these checks. One could estimate that a compulsory consultation would require 1 million background checks per each Member States per year. To check one person would take approximately 15 minutes (database checks, supporting documents etc) equivalent to 250 000 hours per Member States and 7 million hours around the EU per year. This would be equivalent to 182 million EUR.

[1]               COM(2013) 97 final (RTP).

[2]               COM(2011) 777 final, 15.11.2011. The work programme is published on the following website: http://ec.europa.eu/atwork/programmes/index_en.htm

[3]               COM(2013) 95 final (EES).

[4]               SEC(2008) 154, 13.2.2008.

[5]               A list of acronyms is provided in Annex 1.

[6]               SEC(2008) 153; http://eur-lex.europa.eu/SECMonth.do?year=2008&month=01, as well as the "Preparatory study to inform an Impact Assessment in relation to the creation of an automated entry/exit system at the external borders of the EU and the introduction of a border crossing scheme for bona fide travellers ('Registered Traveller Programme')" carried out by GHK and the "Entry/Exit Technical Feasibility study" carried out by Unisys. These studies are published on the following website: http://ec.europa.eu/home-affairs/doc_centre/borders/borders_schengen_en.htm#studies

[7]               OJ C 115/1, 4.5.2010. The Stockholm Programme is published on the following website: http://europa.eu/legislation_summaries/human_rights/fundamental_rights_within_european_union/jl0034_en.htm

[8]               COM(2010) 171 final, 20.4.2010. The action plan is published on the following website: http://europa.eu/legislation_summaries/human_rights/fundamental_rights_within_european_union/jl0036_en.htm

[9]               COM(2010) 385 final, 20.7.2010. The Communication is published on the following website: http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=COM:2010:0385:FIN:EN:PDF

[10]             Privacy by design means embedding personal data protection in the technological basis of a proposed instrument, limiting data processing to that which is necessary for a proposed purpose and granting data access only to those entities that "need to know".

[11]             Regulation (EU) No 1077/2011 of the European Parliament and of the Council of 25 October 2011 establishing a European Agency for the operational management of large-scale IT systems in the area of freedom, security and justice.

[12]             COM(2011) 680 final, 25.10.2011. The Communication is published on the following website: http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=COM:2011:0680:FIN:EN:PDF

[13]             Article 21 of Commission Regulation (EC, EURATOM) No 2342/2002 of 23.12.2002 laying down detailed rules for the implementation of Council Regulation (EC, Euratom) No 1605/2002 on the Financial Regulation applicable to the general budget of the EU, OJ L 357, 31.12.2002.

[14]             Member States replies are published on the following website: http://eu2012.dk/en/Meetings/Conferences/Feb/Konference-om-innovativ-graenseforvaltning. See also Council document 7166/12, presidency summary of findings.

[15]             Council document 7166/12, Presidency summary of findings.

[16]             European Parliament resolution of 10 March 2009 on the next steps in border management in the European Union and similar experiences in third countries (2008/2181(INI)). Resolution is published on the following website: http://www.europarl.europa.eu/sides/getDoc.do?type=TA&reference=P6-TA-2009-0085&language=EN.

[17]             C(2011)-0445. The EDPS opinion is published on the following website: http://www.edps.europa.eu/EDPSWEB/edps/Consultation/OpinionsC/OC2011

[18]             COM(2011) 248 final, 4.5.2011. The Communication is published on the following website: http://ec.europa.eu/home-affairs/news/intro/docs/1_EN_ACT_part1_v11.pdf

[19]             C2011-0860, 4.10.2011.

[20]             Frontex is a European Agency for the management of operational cooperation at the external borders of the Member States of the European Union. More information on Frontex can be found: http://www.frontex.europa.eu/

[21]             See for example ACI EUROPE Position on the use of automated means for border control in the airports, June 2009. http://kpi.aci-europe.org/upload/ACI%20EUROPE%20-%20position%20paper%20on%20USE%20OF%20AUTOMATED%20MEANS%20FOR%20BORDER%20CONTROL%20AT%20EUROPEAN%20%20AIRPORTS%20[06%202009].pdf, Roma/Lyon Migration Experts Sub-Working Group: G8 Best Practices of Biometric Usage in Travel Continuum and the position statement of the American Chamber of Commerce to the European Union on the Smart Borders, 23 of March 2012.

[22]             Council document 7226/1/09 REV 1 FRONT 12 COMIX 200 and the Commission document JLS D(2009) 8729.

[23]             See draft reports "ABC solutions based on Electronic Machine Readable Travel Documents (eMRTD) in EU Member States" and "ABC solutions based on Electronic Machine Readable Travel Documents (eMRTD) in third countries" prepared by Frontex in September 2011.

[24]             See draft reports "ABC solutions based on Electronic Machine Readable Travel Documents (eMRTD) in EU Member States" and "ABC solutions based on Electronic Machine Readable Travel Documents (eMRTD) in third countries" prepared by Frontex in September 2011.

[25]             OJ L 105, 13.4.2006, OJ L 158, 30.4.2004.

[26]             OJ L 105, 13.4.2006.

[27]             OJ L 405, 30.12.2006.

[28]             Based on the International Air Transport Association the ABC systems are used at 83 airports in 31 states.

[29]             For example, the Netherlands (Privium), France (PARAFES), the United Kingdom (Iris) and Germany (ABG) have this kind of programme.

[30]             Final results of the data collection exercise are in Annex 7.

[31]             http://ec.europa.eu/home-affairs/policies/borders/borders_visa_en.htm

[32]             The per cent varies remarkable from one year to another.

[33]             Excluding the UK airports as it did not participate in the data collection exercise.

[34]             http://www.edps.europa.eu/EDPSWEB/webdav/site/mySite/shared/Documents/Consultation/Opinions/2011/11-07-07_Migration_EN.pdf

[35]             Consulates include also Common Application Centres.

[36]             However, this does not mean that the person cannot travel to the EU. He/she could use the manual border check booth as nowadays.

[37]             See Eurocontrol's "long-term forecast for the next 20 years" published on 17 of December 2010, http://www.eurocontrol.int/statfor/gallery/content/public/forecast. Eurocontrol expects an increase from 400 million in 2009 to 720 million border crossings at the air borders in 2030. See also the World Trade Organisation (WTO) forecast: Tourism 2020 vision, http://www.wto.org/english/tratop_e(ser_e/omt.ppt and the travel forecast of Office of Travel and Tourism Industries (OTTI), http://tinet.ita.doc.gov/view/f-2000-99-001/index.html.

[38]             The Netherlands and the US have this kind of scheme called FLUX. See Annex 3 and also http://www.schiphol.nl/Travellers/AtSchiphol/Privium/Flux.htm.

[39]             Including the FLUX scheme.

[40]             The switch from SIS to SISII is not relevant as the implementation of the SISII will not bring any new elements to the border check procedure when implemented.

[41]             OJ L 286, 1.11.2011.

[42]             Travellers who have decided not to join the RTP are not and shall not be considered, due to their non-participation in the RTP, as higher risk travellers.

[43]             In the context of an RTP, a token can be described as a physical device given to the authorised user to prove his/her identity electronically. The token acts like an electronic key to access something, in this case to the ABC system.

[44]             See annex 8 for the data to be stored.

[45]             See annex 8 for the data to be stored.

[46]             The implementing measures would follow the same general principles as with the VIS meaning that for example the design of the physical architecture of the system including its communication infrastructure and the specifications for the resolution and use of fingerprints for biometric verification in the RTP would be decided in a comitology procedure.

[47]             Verification means the process of comparing a submitted biometric sample against the biometric reference template of a single enrolee whose identity is being claimed, to determine whether it matches the enrolee's template.

[48]             As resulted by the Visa Code; OJ L 243, 15.9.2009.

[49]             Based on replies of the three Member States that provided data the examination of a (multiple-entry) visa application lasts on average 45 minutes. This time includes capturing the biometric data. The procedures with a RTP application and a visa application are almost the same. A starting point for the calculation is that all multiple-entry visa holders submit an RTP application and a visa application at the same time.

[50]             Assuming that one person works 7,5 hour/day and 220 days in a year.

[51]             The cost for a token would vary between 1 and 5 euro and has been taken into account in relation to the costs for the relevant sub-options under policy option 2.

[52]             Final report on the cost analysis of entry/exit and RTP systems done by the external contractor on 19 of April 2010 (version 1.30) is published on the following website: http://ec.europa.eu/home-affairs/doc_centre/borders/borders_schengen_en.htm#studies

[53]             The Privium program in Netherlands has processed millions of border crossings for its 46 000 members; Flux pilot programme report, February 2010.

[54]             Final report on the cost analysis of entry/exit and RTP systems done by the external contractor on 19 of April 2010 (version 1.30) is published on the following website: http://ec.europa.eu/home-affairs/doc_centre/borders/borders_schengen_en.htm#studies

[55]             Several Member States have indicated in the External Borders Fund's Annual Programmes that they will start using the Automated Border Control systems at their external border crossing points. These Member States are reported in Annex 3 and in the Frontex's draft report on "ABC solutions based on eMRTD in EU Member States".

[56]             Finland has a pilot project running an ABC at the land border crossing point and Norway will launch a pilot.

[57]             For example, Portugal has a plan to implement ABC systems at its sea borders.

[58]             This estimate is based upon data from Member States. 18 Member States answered the question "how many border guards/police officers in total are performing border checks at the external border". There are an estimated 700-750 million passengers who enter or exit Member States per annum. In 2006, the average salary in EU-27 was 31 000 euro per year (Eurostat).

[59]             500 million would be applicable if all Member States would use ABC systems at all their border crossing points.

[60]             Savings 250 million euro/year – one time costs 207 million euro (the most expensive option; token with repository) – yearly recurring costs 101 million euro – costs of automation 5 million euro= -63 million euro after the first year of operation.

                Second year: cost savings 250 million euro – first year -63 million – yearly recurring costs 101 million euro – cost of automation 5 million euro= + 81 million euro.

[61]             40.000 border guards check per year 675 million travellers (entry and exit). One border guard is therefore able to check 16.875 travellers per year. With the release of 40% only 24.000 border guards are needed to check the flow of 675 million travellers equivalent to 28.125 travellers per border guard per year. Based on this new performance value per border guard, the existing and trained border guards will be able to check yearly a new total of 1.125 million travellers, which is an increase by 62%.

[62]             Final report on the cost analysis of entry/exit and RTP systems done by the external contractor on 19 of April 2010 (version 1.30) is published on the following website: http://ec.europa.eu/home-affairs/doc_centre/borders/borders_schengen_en.htm#studies

[63]             OJ L 286, 1.11.2011, p.1.

[64]             OJ L 158/77, 30.4.2004.

[65]             Border crossing time by using the existing automated system is compared against the time needed for third-country national holding a visa to cross the external border via airport by using the manual booth. At the land borders waiting time can be reduced even more.

[66]             All the data fields listed in Annex 8 would be needed as the vetting criteria would be the same as for multiple-entry visa holders. Furthermore, this would guarantee consistency between the VIS and the RTP and facilitate examination of a visa and a RTP application at the same time.

[67]             The US Federal Register Vol. 74 No. 222, November 19, 2009. US citizens, US nationals, and US permanent residents who are at least 14 years of age are eligible for participation in the Global Entry pilot. On April 23, 2009 citizens of the Netherlands who participate in Privium (Dutch programme) were also accepted in the programme. See also http://www.thetransnational.travel/news.php?cid=international-trusted-traveler-program-permanent.Nov-09.24. "The US Department of Homeland Security estimates that the average customs processing wait time for participants upon their arrival on international flights is seven minutes, a 70 percent reduction compared with non-members-though it varies by airport, airline, time of day and flight origin. Less than 1 percent of Global Entry passengers are waiting longer than 20 minutes compared with approximately 10 percent of all U.S. citizens and lawful permanent residents waiting longer than 20 minutes." The US has several other Trusted Traveller Programmes, for example SENTRI at the land borders and NEXUS together with Canada. The US Customs and Border Protection (CBP) receives about 800 applications a day equivalent to 300 000 per year for its Trusted Traveller Programmes.

[68]             Data were collected from all Schengen Member States, Romania, Bulgaria and Cyprus. Final results of the data collection exercise are in Annex 7.

[69]             Border crossings in Ceuta and Melilla are included.

[70]             For example, new aircraft types like BOEING Dreamliner and AIRBUS A 380 increase the pressure to manage passenger flows more efficiently at the airports.

[71]             Cars onboard ferries undergo similar checks as at the land border.

[72]             For example, Advanced Passenger Information (API) is available at the airports.

[73]             See also EU Schengen Catalogue on External borders control, Return and Readmission updated version of 19 March 2009. On page 24, the Catalogue refers to the infrastructure at border crossing points (lanes and booths) and number of personnel needed. "Adequate number of officers and border check equipment should be deployed to control passenger flows and respond to actual risk assessment. Adequate number depends inter alia: on constant control of passenger flow, night time, border situation and threat level, available equipment, environment".

[74]             Survey was conducted in 2006. Misense pilot started in October 2006 at Heathrow airport. UK survey is used as any other Member State has not carried out such a study for their citizens.

[75]             See draft report "ABC solutions based on Electronic Machine Readable Travel Documents (eMRTD) in third countries" prepared by Frontex.

[76]             Article 94(3) of the Schengen Convention.

[77]             Regulation (EC) No 1987/2006 and Regulation (EC) No 1986/2006.

[78]             Council Decision 2007/533/JHA.

[79]             Council Decision (EC) No 512/2004, 8.6.2004.

[80]             Council Regulation (EC) No 2725/2000, 11.12.2000 and (EC) 407/2002, 28.2.2002.

[81]             Council Regulation (EC) No 343/2003, 18.2.2003.

[82]             SEC(2009) 96, 26.1.2009, SEC(2009) 1246/6, 25.9.2009, SEC(2010) 954/10, 2.9.2010.

[83]             SEC(2011) 132 final and SEC(2011) 133 final, 2.2.2011.

[84]             In the management context, the SIS 1+ is not discussed as migration form SIS 1+ to SIS II is ongoing.

[85]             OJ L 286, 1.11.2011.

[86]             Vetting for family members of citizens of the Union shall be done by using the same criteria as used when examining their visa applications (OJ L 158, 30.4.2004 and OJ L 243, 15.9.2009).

[87]             Final report on the cost analysis of entry/exit and RTP systems done by the external contractor on 19 of April 2010 (version 1.30) is published on the following website: http://ec.europa.eu/home-affairs/doc_centre/borders/borders_schengen_en.htm#studies

[88]             E.g. through the exercise undertaken by the Swedish Presidency in the Frontiers Working Group at the end of August/beginning of September 2009 to count numbers of border crossings per category of traveller, etc.

[89]             The parameters and the values used can be found in the final report of the cost analysis prepared by the external contractor..

[90]             Average employment costs in the associated countries public administration: Eurostat: Average hourly labour costs, defined as total labour costs divided by the corresponding number of hours worked (32 EUR in 2005). The 2005 figure has been increased by 5 % (= 34 EUR). Average employment costs in the EU-27 public administration: Eurostat: Average hourly labour costs, defined as total labour costs divided by the corresponding number of hours worked (20,35 EUR in 2005). The 2005 figure has been increased by 5 % (= 22 EUR) based on Eurostat statistics "Unit labour Cost – Annual data". http://epp.Eurostat.ec.Europa.eu/portal/page/portal/national_accounts/data/database.

                Average employment costs in the European Commission is 122 000 EUR per year equivalent to 74 EUR per hour (220 working days, 7,5 hour/day).

[91]             Based on the three Member States answers the examination of a (multiple-entry) visa application lasts on average 45 minutes. This time includes capturing the biometric data. The procedures with a RTP application and a visa application are almost the same.

[92]             Assuming that one person works 7,5 hour/day and 220 days in a year.

[93]             See Annex 10.2. The 1,8 million corresponds to the summary of Management Authority total one time costs in categories 3 and 6. The same calculation rule is applicable for all the options and for yearly recurring costs.

[94]             See Annex 10.1. The 43 million corresponds to the summary of MS total one time costs in categories 13 and 16. The same calculation rule is applicable for all the options and for yearly recurring costs.

[95]             See Annex 10.1. The 54 million corresponds to the summary of MS total yearly recurring costs in categories 13 and 16. The same calculation rule is applicable for all the options.

[96]             See Annex 10.2.

Top