Table of contents 1.Introduction 2.Background to the intervention 3.Implementation / state of Play 4.Method 5.Analysis and answers to the evaluation questions 5.1.Relevance 5.2.Effectiveness 5.3.Efficiency 5.4.Coherence 5.5.EU Added Value 6.Conclusions Annex I: Procedural information Annex II: SYNOPSIS REPORT OF THE STAKEHOLDER CONSULTATION ANNEX III: METHODS AND ANALYTICAL TOOLS ANNEX IV: EVALUATION CRITERIA AND QUESTIONS ANNEX V – LIST OF SOURCES

Glossary Term or acronym Meaning or definition Advance Passenger Information (API) Information of an air passenger collected at check-in or at the time of online check-in. It includes biographic data of the passenger, ideally captured from the Machine Readable Zone (MRZ) of their travel documents, as well as some information related to their flight. API - batch An electronic communications system whereby required data elements are collected and transmitted to border control agencies prior to flight departure or arrival and made available on the primary line at the airport of entry. Border control The activity carried out at a border, in accordance with and for the purposes of Regulation (EU) 2016/399 (Schengen Borders Code) , in response exclusively to an intention to cross or the act of crossing that border, regardless of any other consideration, consisting of border checks and border surveillance. Border Crossing point Any crossing point authorised by the competent authorities for the crossing of external borders. Carrier A natural or legal person who provides passenger transport services by air. Carrier gateway Web service enabled system, to be introduced in accordance with Regulation 2018/1240 establishing European Travel Information and Authorisation System (ETIAS), allowing carriers to verify the authorisation status of third-country national (TCN) travellers. Charter flight/ Non-scheduled revenue flights (excluding on-demand flights) Charter flights and special flights performed for remuneration other than those reported under scheduled flights. They include any items related to blocked-off charters and exclude air taxi, commercial business aviation or other on-demand revenue flights. Centralised Routing Mechanism Central point to which air carriers may submit passengers and crew manifests and which can forward the passengers data to other information systems. Competent authorities Authorities responsible for carrying out checks on persons at external borders Entry / Exit System (EES) A system which registers entry and exit data and refusal of entry data of third-country nationals crossing the external borders of the Schengen States. European Travel Information and Authorisation System (ETIAS) An automated online system for identifying irregular migration, security or public-health risks associated with visa-exempt TCNs travelling to the EU prior to their arrival, somewhat comparable to the American ESTA or Canadian ETA. External borders The parts of a Schengen Member State’s border, including land borders, river and lake borders, sea borders and their airports, river ports, seaports and lake ports, that are not common borders with another Schengen Member State. Extra-EU flight Any scheduled or non-scheduled flight by an air carrier flying from a third country and planned to land on the territory of a EU Member State or flying from the territory of a EU Member State and planned to land in a third country, including in both cases flights with any stop-overs in the territory of Member States or third countries. Extra-Schengen flight Any scheduled or non-scheduled flight by an air carrier flying from outside the Schengen area and planned to land on Schengen area territory or flying from the territory of the Schengen area and planned to land outside the Schengen area, including in both cases flights with any stop-overs in the territory of the Schengen area or outside of it. Extra-EU/Schengen flights This term has been used in the document for any scheduled or non-scheduled flight by an air carrier flying from a third country planning to land in an EU Member State or on the Schengen area territory or flying from the territory of an EU Member State or the Schengen area and planned to land in a third country, including in both cases flights with any stop-overs in the territory of an EU Member State or the Schengen area or third countries. Implementing countries For the purposes of this evaluation, all 28 EU Member States (in 2019, i.e. the last year covered by this evaluation) plus the 3 Schengen associated countries implementing the API Directive (Switzerland, Iceland and Norway). Liechtenstein does not have an airport, therefore, even though bound by the Schengen acquis, was not included in this evaluation. Internal Borders Borders between Member States or Schengen associated countries Interactive API System (i-API) An electronic system that transmits, during check-in, API data elements collected by the aircraft operator to public authorities, who within existing business processing times for passenger check-in, return to the operator a response message for each passenger and/or crew member. Interoperability The ability of information systems to exchange data and enable sharing of information. Intra-EU flight Any scheduled or non-scheduled flight by an air carrier flying from the territory of an EU Member State planned to land on the territory of one or more of the Member States, without any stop-overs in the territory of a third country. Intra-Schengen flight Any scheduled or non-scheduled flight by an air carrier flying from one airport within the Schengen area planned to land at another airport within the Schengen area, without any stop-overs outside that area. Intra-EU/Schengen flights This term has been used in the document for any scheduled or non-scheduled flight by an air carrier flying from the territory of an EU Member State or the Schengen area territory planned to land on the territory of an EU Member State or the Schengen area, without any stop-overs in the territory of a third country. Passenger Any person, including persons in transfer or transit and excluding members of the crew, carried or to be carried in an aircraft with the consent of the air carrier, such consent being manifested by that person's registration in the passengers list. Passenger Information Unit (PIU) Units established or designated within the law enforcement authorities dealing with terrorist offences and serious crime at Member State level that collect, store and process PNR data. Passenger Name Record (PNR) A record of each passenger's travel details which contains information necessary to enable reservations to be processed and controlled by the booking and participating air carriers for each journey booked by or on behalf of any person, whether it is contained in reservation systems, departure control systems used to check passengers onto flights, or equivalent systems providing the same functionalities. Air carriers shall transfer PNR data 24 to 48 hours before the scheduled flight departure time and immediately after flight closure (i.e. once passengers have boarded the aircraft). PNR data have to include API data if collected by the air carriers. Personal data Any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person. Processing of personal data Any operation or set of operations which is performed on personal data or on sets of personal data, whether or not by automated means, such as collection, recording, organisation, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction. Roll-out/Pilot In the context of policy or practices, a test implementation of a programme, system or operational practice to assess whether it should be introduced more widely. Schengen area The Schengen area, i.e. the area without controls at internal borders, encompasses 22 EU Member States, all except for Bulgaria, Croatia, Cyprus, Ireland, Romania and the United Kingdom. Four countries that are not Member States. Iceland, Norway, Switzerland and Liechtenstein have joined the Schengen area (Schengen associated countries). Schengen associated countries The countries which without being a Member State apply the Schengen acquis and have joined the Schengen area (Iceland, Norway, Switzerland and Liechtenstein). Schengen Information System (SIS) A joint information system that enables the relevant authorities in each EU Member State, by means of an automated search procedure, to have access to alerts on persons and property for the purposes of border checks and other police and customs checks carried out within the Member State in accordance with national law and, for some specific categories of alerts, for the purposes of issuing visas, residence permits and the administration of legislation on aliens in the context of the application of the provisions of the Schengen Convention relating to the movement of persons. Single Window A facility that allows parties involved in trade and transport to lodge standardized information and documents with a single-entry point to fulfil all regulatory requirements. If information is electronic then individual data elements should only be submitted once. Stolen and Lost Travel Documents database (SLTD) A database maintained by Interpol containing around 84 million records of lost, stolen and revoked travel documents, such as passports, identity cards, visas and UN laissez-passer, as well as stolen blank travel documents. Systematic external border checks Systematic checks refer to the practice of checking information on third-country nationals crossing the external Schengen borders against Interpol’s Database of Lost and stolen travel documents (SLTD), national databases on lost and stolen documents and the SIS. Since April 2017, such checks have also become mandatory for EU citizens. Targeting Centre Capacity of Member States to conduct automated risk assessment of travellers based on the different travel intelligence (e.g. API, PNR, Visa Information System (VIS), EES, etc.) that can legally be used for border management and is based on tactical risk analysis. The aim is to detect unknown persons of interest (in comparison to known criminals on watch lists) before arrival at the border. Third Country For the purposes of this document, all countries that are not EU members nor Schengen associated countries. Third Country National Any person who is not a citizen of the European Union within the meaning of Art. 20(1) of TFEU and who is not a person enjoying the right of free movement under Union law, as defined in Art. 2(5) of Regulation (EU) 2016/399 (Schengen Borders Code). Visa Information System (VIS) System for the exchange of visa data between Schengen States, which enables authorised national authorities to enter and update visa data and to consult these data electronically. 1.Introduction Purpose and scope This evaluation assesses Council Directive 2004/82/EC of 29 April 2004 on the obligation of carriers to communicate passenger data (the ‘API Directive’) and its implementation in EU Member States and Schengen associated countries. The API Directive was adopted in 2004 with a transposition deadline of 5 September 2006 and was evaluated for the first time in 2012. It aims at improving border controls and combating illegal immigration by the transmission of advance passenger information (API) by air carriers to competent national authorities. It also gives Member States the possibility to use the data for law enforcement purposes. The key objective of the evaluation is to provide an understanding of whether the Directive’s provisions are still ‘fit-for-purpose’ 15 years after its adoption and 7 years after its first evaluation. Hence, this document assesses whether and how the Directive still addresses the needs of border control authorities, law enforcement authorities, airline carriers, passengers and other relevant stakeholders, in the light of the recent developments at EU Level, such as the implementation of the passenger name record (PNR) Directive and the expansion of the EU’s large-scale databases and their interoperability, the increase of the number passengers travelling by air, the migratory pressure and renewed terrorist threats. This evaluation is supported by an externally contracted study (hereafter: “Evaluation Study”), as well as by meetings and workshops with stakeholders and experts. It assesses the effectiveness, efficiency, relevance, coherence and EU-added value of the Directive as follows: ·Material scope: current state of legal transposition of the API Directive; practical implementation of the API Directive; baseline assessment and evaluation based on the five evaluation criteria as per the Better Regulation Guidelines. ·Geographical scope: 31 countries (hereinafter: “implementing countries”) – all 28 EU Member States and the 3 Schengen associated countries implementing the Directive (Switzerland, Iceland and Norway). Liechtenstein does not have an airport, therefore, even though bound to the Schengen acquis, was not included in this evaluation. ·Temporal scope: 2012 to 2019 (period since the first evaluation). 2.Background to the intervention Description of the intervention and its objectives Advance Passenger Information (API) is commonly understood as the information of an air passenger collected at check-in or at the time of online check-in. API information includes biographic data of the passenger, ideally captured from the Machine Readable Zone (MRZ) of their travel documents, as well as some information related to their flight. The API Directive is a 2004 Council Directive aiming at improving border controls and combating illegal immigration through the transmission of advance passenger data by carriers to the competent national authorities. By means of its transposition into national law, the Directive imposes an obligation on air carriers to transmit, upon request, passenger data to the Member State of destination prior to the flight’s take-off or shortly after take-off, if that flight is in-bound from a third country. It also gives to Member States the possibility of using API data for law enforcement purposes. The Directive was drafted with the spirit of ‘minimum harmonisation’, therefore it leaves to each implementing state the possibility to extend the obligations included in the Directive by means of national law. The European Council Declaration on combating terrorism adopted in March 2004, in the aftermath of the terrorist attacks in Madrid on 11 March 2004, called for an early conclusion of the proposed Council Directive, put forward at the initiative of Spain, on the obligation of carriers to communicate passenger data. The Directive was adopted without the opinion of the European Parliament under “exceptional circumstances”. In light of the above, and in the absence of any Impact Assessment or preparatory document preceding the tabling of the proposal for the Directive, the intervention logic below provides an overview of the Directive’s general and specific objectives and has been prepared by the contractor responsible for carrying out the external study. This tool serves to depict the chain of expected effects associated with the Directive. The intervention logic identifies two general objectives pursued by the Directive. These are: 1) improving the management and protection of the EU external border while facilitating clearance of legitimate passengers and 2) enhancing security of EU citizens. The Contractor detailed these two general objectives into four specific points (called ‘specific objectives’); two of them – improving border control and combatting illegal immigration - are referring to objectives explicitly listed in the text of the directive (art. 1). The other two points (law enforcement including in particular fighting terrorism) go beyond the objectives stated in the legal act but are linked with the Directive’s provisions on ensuring security check at the borders and enabling implementing countries to use API data for law enforcement purposes. In practice most Member Sates provided for such use of API data, which indicates the importance of this objective. It is also noted that recital 2, read in context of circumstances in which the Directive was brought forward by Member States, shows that fighting terrorism was one of the drivers for adopting the Directive.

The intervention logic further identifies the following operational objectives: 1)Facilitating performance of border checks 2)Facilitating clearance of legitimate travellers 3)Identifying individuals entering the Member State 4)Pre-identify persons of particular interest and persons who might warrant enhanced examination at the border 5)Helping with clearance of low risk passengers The intervention logic makes clear that where the outputs are met, the Directive should generate a number of outcomes that address the drivers that prompted the decision to take the initiative in the first place. The expected outcomes include: faster and more effective border checks, improved identification and arrest of suspected individuals, improved risk analysis. Assuming these outcomes are achieved, the Directive should ultimately lead to an improved level of border management and control, improved enforcement of migration acquis and enhanced security of the EU. The intervention logic also identifies the external factors affecting the Directive including for example increases in the number of passengers; increased security threats and technological innovations and takes into account the policy context in which the Directive operates. Baseline and points of comparison The baseline of this evaluation is the situation as described in the study “Evaluation on the implementation and functioning of the obligation of carriers to communicate passenger data set up by Directive 2004/82”, carried out in 2012, which had inter alia highlighted the following elements: ·Most of the competent authorities considered that the objectives of their API system or legislation were fully in line with those of the Directive. Competent authorities also identified law enforcement as a perceived need at the time of transposing the Directive. ·The implementation of API systems has helped to improve border controls; for instance, through API systems, competent authorities have been able to: oIdentify specific flights for which enhanced border checks are necessary (i.e. as compared to other flights) because the higher prevalence of non-EU nationals in those flights is known before landing; oBetter preparation for the control of specific passengers by identifying them via API data in advance of their arrival; this helps to accelerate border checks because passengers requiring secondary checks can be separated from the other passengers and reallocated to separate lanes without the other passengers queuing and waiting; oAnticipate certain situations and the type of controls to be performed; oCheck API data against other databases, and thus shorten the time for controls and checks at the external borders. ·Instances of late or partial implementation of API systems, or in some cases failure to implement API systems at all, were observed. In the countries implementing API systems in 2012, the systems’ technical and operational capabilities varied, and the operational procedures underlying the API systems were inconsistent. This created some incoherence and uncertainty in the way in which API systems were operated. ·Possible issues of coherence in the future, with the adoption of other instruments (e.g. on PNR) were detected. In order to facilitate the comparison between the baseline and the current situation, a brief summary of the 2012 state of play has been provided when assessing each evaluation criteria. 3.Implementation / state of Play

The current regulatory landscape on API At EU level, the API Directive regulates the collection and transmission of API data in all EU Member States (including those Member States applying the Schengen acquis in full and those which do not yet apply the Schengen acquis in full, such as Bulgaria, Cyprus, Croatia and Romania) and Schengen associated countries (Norway, Iceland, Liechtenstein and Switzerland). It places an obligation on air carriers to transmit, upon request, passenger data to the implementing country of destination prior to the flight’s take-off or shortly after take-off, if that flight is in-bound from a third country. The primary objective of the Directive is to facilitate border control and to prevent irregular migration, but the Directive also recognises that API data can be used for law enforcement purposes, leaving to national legislation to regulate this use. The Directive only sets minimum standards for the implementing countries to request API data and implementing countries are free to request similar data from other transport carriers, such as maritime or rail transport carriers. At international level, Annex 9 of the Convention on International Civil Aviation (Chicago Convention) as well as the WCO/IATA/ICAO API Guidelines are the main international regulatory instruments on API. Besides, UN Security Council Resolutions 2178(2014), 2309(2016), 2396(2017) and 2482 (2019) call upon UN Member States to require airlines operating in their territories to transfer API to national authorities to detect departures or attempted entry or transit of suspects with the aim to counter terrorism. Since February 2018, the establishment of national API systems is an ICAO standard, making it mandatory for all Contracting States to the Chicago Convention. In addition, the OSCE Ministerial Council has adopted, on 8 December 2016, a Decision on enhancing the use of API, whereby OSCE participating States commit, inter alia, to establishing a national API system. At EU level, in addition to the API Directive, Directive 2016/681 on the use of Passenger Name Record (PNR) for the prevention, detection, investigation and prosecution of terrorist offences and serious crime was adopted in 2016 (hereafter: the PNR Directive). The PNR Directive requires air carriers to transfer PNR data collected in the normal course of their business to the Member States’ Passenger Information Units (PIUs). Annex I of the PNR Directive includes API among the data to be transferred by carriers as far as collected for their own business purposes. The PNR Directive also requires Member States to adopt the necessary measures to ensure that carriers transfer any available API data collected in the course of their business, to the PIU, in which case “the provisions of the PNR Directive shall apply to those API data” (Article 8(2)). The transposition of the API Directive The API Directive was transposed at different paces in different Member States. While today all implementing countries have transposed the Directive, as shown in figure 2, only 9 countries had transposed the Directive within the deadline of 5 September 2006. It should be noted that many implementing countries, despite having transposed the Directive, did not have an API system in place for many years; in fact the Directive does not impose on implementing countries an obligation to request any data. It only requires airlines to collect and transmit the data upon request of the implementing country. Overall, the API Directive was adequately transposed. Article 1 on the objectives and Article 6 on data processing contain provisions that triggered most cases of incorrect or incomplete transposition or transposition going beyond the Directive’s provision. Article 1 sets out the twofold objective of the API Directive, namely, 1) combating irregular migration, 2) improving border control. Half of the implementing countries have nonetheless adopted an implementing approach that goes beyond those two requirements. Firstly, five implementing countries have enshrined the fight against terrorism as an objective of their API system. The API Directive allows for the use of API data for law enforcement purposes. Recital (2) of the Directive also makes a reference to a Council Declaration on terrorism adopted following the Madrid terrorist attacks. Secondly, several countries have made use of the possibility offered by Article 6(1) subpara 5 to collect API data for law enforcement purposes. This is for example the case of Cyprus, where API data may also be used to investigate offences leading to an imprisonment sentence of 1 year or more (3 years or more in Slovakia), and in Austria, where API data can be transmitted to another law enforcement authority in case of suspicion of a criminal offense. Slovenia has recently opted for this legal choice (2017) and is currently amending its related laws. In the United Kingdom, the national transposing regulation goes beyond the objectives of the API Directive by including law enforcement and intelligence as one of the ultimate goals. Figure 4 below (found on p.13) provides an overview of the practical implementation and purposes for the use of API data. Article 6 emerged as the most problematic provision of the API Directive in terms of transposition into the national legal frameworks. This provision sets out the rules applicable to the processing of the API data collected. Due to the references made to data protection rules, this provision is particularly important but also complex to implement. For the sake of clarity, the analysis of the compliance of national legislations with data retention requirements is presented separately (see page 19: “Transposition and implementation - a data protection perspective”). The implementation of the API Directive In recent years, the implementation of the PNR Directive, together with the international commitments made by contracting states in ICAO and OSCE, have given a strong impetus to the use of API data in the EU. As shown in Figure 3 above, in 2012, 18 out of 30 implementing countries had API systems in place (only pilots in some cases), in 2019, 25 out of the 31 implementing countries had fully functioning API systems in place. Two implementing countries still were running pilot systems (Belgium and Slovakia) and four implementing countries (Cyprus, Greece, Iceland, Norway) did not have an API system but were planning to establish one post 2019. Liechtenstein did not have an API system in place and does not plan on setting one up as it does not have an airport. Therefore, it is not included among the “implementing countries”, despite being a Schengen associated country. Purpose

As regards to the purposes of API data collection, based on the interviews carried out during the Evaluation Study, 29 implementing countries collect (or are planning to collect) API data with the aim of combatting irregular migration; 29 implementing countries for the purpose of improving border control; 21 implementing countries for law enforcement purposes and 15 for fighting against terrorism. Scope Concerning the scope of API data collection, i.e. the type of flights and the type of carriers covered, the API Directive gives flexibility to implementing countries to limit the API data collection to certain airports, flights and carriers. Regarding the airports, 22 implementing countries out of the 31 consulted (74%) collected API data for all relevant airports, i.e. airports with extra-EU/Schengen flights, while four did not collect API data for all airports handling such flights. The rationale for limited coverage ranged from the relatively small size of the airports, low volume of international air traffic, location (only capital cities covered) and airports with low-risk routes according to border control authorities' analysis. Regarding the flights covered, the majority of implementing countries receive or are planning to receive API data for all inbound extra-EU/Schengen flights to their territory, while seven implementing countries collect or are planning to collect data only on selected flights. Flights for which data are not typically collected include charter flights. The rationale for only selecting certain flights is based on risk analysis usually involving the border control and migration authorities. In Germany, for example, risk routes are flights departing in a country or airport that has been identified by the border control authority as posing a certain risks, e.g. in relation to terrorism or irregular migration. Article 3(1) of API Directive limits its scope to inbound flights from third countries. However, several implementing countries request API data also for other flights: twelve implementing countries request data for outbound flights and eight implementing countries for intra-EU/Schengen flights. Three implementing countries reported requesting API data for domestic flights . The collection of API information on outbound extra-EU/Schengen flights and on intra-EU/Schengen flights is linked to the scope of the PNR Directive. Under Article 2(1) of the PNR Directive, EU Member States may decide to apply the Directive also to intra-EU flights. Currently, 24 EU Member States have both fully transposed the PNR Directive and communicated to the Commission that they intend to apply it to intra-EU flights. Implementing countries which collected API data on intra-EU flights did so based on the PNR Directive and for law enforcement purposes, and only where air carriers collect the data in the normal course of their business. Out of four implementing countries that do not yet apply the Schengen acquis in full (Bulgaria, Croatia, Cyprus and Romania) , only Bulgaria reported to request API data on intra-EU flights from air carriers and confirmed to apply the provisions of the API Directive to these flights. As for the scope of the API data collection in terms of air carriers, API data is being requested (or planning to be requested) from all air carriers in 19 countries whilst in 12 implementing countries it is requested for selected air carriers only. In some implementing countries, API data collection has also been mandated for other modes of transport – i.e. in ten implementing countries API is being collected from waterborne carriers; in four from trains and in one from coaches/buses. Data fields Looking at the data fields, Article 3(2) of the API Directive provides for a list of API passenger data (number and type of travel document, nationality, full names, and date of birth) and flight data (border crossing point of entry, code of transport, departure and arrival time, total number of passengers carried and initial point of embarkation). The list is non-exhaustive and implementing countries can request additional data elements in line with national legislation. API data is also included under point 18 of Annex I of the PNR Directive which lists API data elements additional to those listed in Art.3(2) of the API Directive, which include gender, departure and arrival date of transportation, name of the airline, flight number, country of issuance and expiry date of the travel document. All implementing countries request the full names of the passenger. With the exception of Iceland, all implementing countries require the travel document number, document type, nationality, date of birth (DOB) and arrival time. With the exception of Estonia, all implementing countries request data concerning the departure time. In addition to the data fields provided in the API Directive, 24 request additional data elements. Most common additional data fields include country of issuance of the travel document, gender, flight number and airline, with a range from 14 to 24 implementing countries. Other less commonly reported data fields include expiry date of travel document (9 instances), points of transit (4), seat and baggage information (4), dates of departure and arrival (3), crew data (2), place of birth(1) and duration of flight (1). Four (4) countries suggested adding visa number to the API data list to avoid ambiguous situations when travel documents with different numbers have been used. Currently, visa number is used by one (1) Member State. Other Member States suggested collecting additional data elements, such as: information on the person's entire journey and ticket information. Gender, issuing state or organisation of the official travel document and expiration date of the validity of the official travel document are amongst the data elements not mentioned in the API Directive but contained in the MRZ. Relevant EU instruments and internationally recognised standards, recommend including MRZ data fields in the instrument governing the API data collection and processing. Doing so would increase the quality of the data captured. Finally, data elements such as seat and baggage information are seen as essential for advance screening of passengers by some of the Member States, and are already part of a standard WCO/IATA/ICAO Passenger List Message (PAXLST), a data format used by carriers to transfer API data when transferred separately from the PNR message. Organisational set-up and governance The main authorities involved in the implementation of API systems include Border Management Authorities, Ministries of Interior and Data Protection Authorities; the main organisational focal points which collect and/or process API are ‘single window’, ‘Passenger Information Units’ and ‘Targeting Centres’, described below. In terms of receiving API data by national authorities, international standards prescribe the ‘single window’ approach. According to ICAO, the single window concept should apply to each form of passenger data that an airline is obliged to transmit to the requesting authority, i.e. Advance Passenger Information (API), interactive API (iAPI) and/or Passenger Name Record (PNR). Implementing countries should designate an authority to receive all forms of passenger data in one single entry point and then distribute this data to all those national authorities with the legal remit to receive and use this data. This is expected to increase effectiveness not only in terms of border security, but also alleviate duplicative costs for the airline industry as well as each individual agency that might have legal authority to view the data. Nearly half of the implementing countries (13) use the single window model.

Nearly half of the implementing countries (14) reported that they processed API data together with PNR data (mainly API data collected as per the provisions of the PNR Directive). In accordance with Art. 4(1) of the PNR Directive, Member States shall establish or designate an authority competent for the prevention, detection, investigation or prosecution of terrorist offences and of serious crime or a branch of such an authority, to act as its passenger information unit (‘PIU’). The PIU may, however, have different branches in one Member State and Member States may also establish one PIU jointly. The remaining implementing countries answered negatively as to the common processing of API/PNR data. A key question is whether implementing countries have established Targeting Centres for processing API data. A ‘Targeting Centre’ is understood as the capacity for implementing countries to conduct automated risk assessment of travellers based on the different travel intelligence collected (e.g. API, SIS, VIS, EES, etc.) that can legally be used for border management and based on tactical risk analysis. The aim is to detect unknown persons of interest (in comparison to known criminals on watch lists) before they come to the border. Such capacities are already functioning in a few third countries, such as the United States and Canada, but there are few of these capacities in the European Union, the oldest being the National Border Targeting Centre (NBTC) in the United Kingdom. At present, thirteen implementing countries have set up Targeting Centres (although the set-up of these Targeting Centres varies across countries), whilst eighteen countries do not have a functioning Targeting Centre. In implementing countries which have set up Targeting Centres, this role is typically carried out by the ‘Passenger Information Units’ (PIUs). Across implementing countries, there is quite a variety of organisational structures. For example, in Ireland, the PIU is the targeting centre and receives, processes and analyses both the API and PNR data. While the API data is normally checked against the migration related databases, the PNR data is being checked for terrorism and serious crime related threats. Another example is the Netherlands, where API and PNR are processed separately by different authorities – i.e. API Centre and PIU (Pi-NL). API data is processed by the Border Authorities which fall under the Ministry of Defence, PNR data is processed by PIU (Pi-NL), which is an independent unit hosted by the Ministry of Defence, but falls under the responsibility of the National Coordinator for security and counter-terrorism. Sanctions Article 4 of the API Directive provides that implementing countries shall impose sanctions to carriers and indicates that either the maximum amount of such sanctions should be not less than EUR 5 000; or the minimum amount not less than EUR 3 000. In addition to financial sanctions, the Directive provides that implementing countries can impose other types of sanctions for carriers which infringe very seriously the obligations arising from the provisions of this Directive. These sanctions are immobilisation, seizure and confiscation of the means of transport, or temporary suspension or withdrawal of the operating licence. Implementing countries indicated that occasionally they have issues with accuracy or completeness of data transmitted by carriers. There have been two general approaches to managing air carriers in regard to transmission of API data: (1) engaging with carriers without resorting to sanctioning and enforcement actions, and (2) more straightforward approach to aggressive enforcement sanctioning non-compliance. In both cases, the statistical information presented by implementing countries indicates that the rates of incorrect data transmission, as well as the instances of incorrect or incomplete data have been declining over time. Seventeen implementing countries out of the examined thirty-one, have not imposed any sanctions to carriers, while, in fourteen countries, fines have been imposed for the violation of obligations related to the transmission of API data. The absence of sanctions imposed seems to be the consequence of effective coordination between airlines and national authorities receiving the data. In this sense, as soon as the authorities observe any lacks/defects/invalidate data, they directly contact the relevant airline to get clarity or to collect the proper data. As a result, most defects are solved directly without restoring to sanctions. This approach is also in line with Annex 9 to the Convention on International Civil Aviation, whereby the Contracting States ‘should refrain from imposing fines and penalties on aircraft operators for any errors caused by a systems failure’ in transmitting API data to authorities. Rather than imposing sanctions, Annex 9 foresees mitigation measures and necessary system maintenance to be undertaken in case of such failure. More specifically, Annex 9 states that the Contracting States and aircraft operators should provide operational and technical support to analyse and respond to any system outage or failure continuously. Also, the document calls for implementing appropriate notification and recovery procedures for both planned and unexpected system outages. Out of the 28 carriers which responded to the industry survey, 10 have been sanctioned by implementing countries. Consulted air carrier representatives feel that some implementing countries are not always working in partnership with carriers – e.g. authorities might fine the airline without prior notice when the airline is not even aware that there is a problem with the data. Moreover, sanctions are often seen as too severe and inconsistent between countries. Transposition and implementation - a data protection perspective When describing the implementation of the API Directive, particular attention should be given to whether the practical implementation is in line with the data protection requirements put forward by the Directive and the applicable EU and national data protection legislation. The 2012 evaluation already showed that ten implementing countries allowed the authorities to store the data for longer than 24 hours. None of them, except one, mentions that the data can be kept for longer than 24 hours only for ‘statutory purposes’. Even more, Member States which keep data beyond the deadlines provided in the Directive, do not apply appropriate safeguards. Only one implementing country anonymised API data when retained for longer than 24 hours, while many implementing countries restricted access to API data by making use of data security tools. Furthermore, in 2012, only a few of the implementing countries with an operational API system had implemented systematic monitoring of compliance of national API systems with data protection standards and API systems were rarely inspected by data protection authorities. The current state of play of the transposition and implementation of the API Directive shows that the API data collection pursue multiple objectives in several implementing countries. The variety of purposes for collecting data inevitably adds complexity to ensuring compliance with the data protection framework. Indeed, while most implementing countries transposed the obligation to transmit data to competent authorities as prescribed by the API Directive, there are significant differences in the organisational structures established to collect API data, as well as a variety of processes used for the collection and transmission of data. The implementation of API systems showed that, depending on the ‘model’ set up by implementing countries, authorities which receive, process and analyse API data vary greatly. In most implementing countries, border control authorities are the main authorities receiving data and having direct access to data. Other authorities (law enforcement authorities) have indirect access and need to justify the need for accessing the data. In this context, a few implementing countries do not receive data in an electronic format which, from a data protection perspective, represents a challenge as to how to efficiently ensure the restrictions regarding access to data and traceability of accesses and transmissions to other authorities. In implementing countries adopting a ‘single window’ model and where the PIU acts as the targeting centre, data protection standards follow the PNR Directive, as the PIU’s Data Protection Officer is in charge of ensuring that API data is received and accessed by other national authorities following the relevant data protection requirements (e.g. keeping an access log). In this context, border authorities receive API data indirectly and their processing of API data generally respects the limit of 24 hours set in the API Directive. However, the implementation of the requirement to delete API data within 24 hours was problematic in several implementing countries, because of faulty transposition of this obligation in the national legislation, or because of overlaps with obligations coming from the PNR Directive, or both elements at the same time. As a result, in a few implementing countries, the 24 hour limitation set out in the API Directive was deleted from national legislation, which creates either a legal grey area as to which retention requirements should be applicable and/or leads to the sole application of the requirements set in the PNR Directive, despite the fact that API data and PNR data are different sets of data. Additionally, implementing countries have generally made use of the possibility included in the API Directive to store API data for longer than 24 hours where this is necessary for the exercise of “statutory functions”. Most implementing countries have not defined a time limit in this case. Passengers are informed of their rights by air carriers generally at the time of booking and/or via data privacy notices on their websites. The completeness of information varies from air carrier to air carrier. Generally, national air carriers provide more extensive information on data protection rights. As in the 2012 evaluation, the monitoring of the compliance of API systems with data protection requirements was not systematic. 4.Method Short description of methodology

Most of the methodological steps of this evaluation were carried out with the support of an external contractor who reported on their findings and recommendations in their study on evaluation on the implementation and functioning of the obligation of carriers to communicate passenger data set up by Directive 2004/82 – Final Report, March 2020 . The results of the report were discussed and analysed by the API evaluation Inter-Service Steering Group and lead to the conclusions highlighted in this paper. The methodology consisted of the following steps: 1)Inception: ensure understanding between the external contractor and the Inter-Service Steering Group, agree on objectives and timing, carry out initial desk review and consultations, develop data collection tools and risk mitigation strategy. 2)Data collection and stakeholder consultations: establish the baseline of the analysis, carry out national research, desk research, stakeholder consultations (including Public Consultation) and industry e-survey. 3)Analysis: assess and compile the results of research, surveys and consultations, evaluate and assess findings and discuss them at an expert workshop. 4)Synthesis: conclude on the results of the evaluation study, considering other inputs coming from stakeholders, and develop conclusions on each evaluation criterion. Throughout all the steps, a range of methodological tools and techniques were used. These included: more than 30 interviews; targeted consultations with different stakeholders using online surveys and one workshops involving various experts; in addition, the Commission conducted a public consultation the results of which were made available to the contractor carrying out the external study. A wide range of stakeholders were consulted as part of the evaluation. These included: national authorities; carriers and industry; technological providers, NGOs and EU Agencies. A more detailed description of the consultations is described in the Synopsis Report in Annex II. A more elaborate description of the methodologies applied and the stakeholder consultations are provided in Annexes II and III. Deviations from the Evaluation Roadmap While the Evaluation Roadmap that was published in December 2018 indicated that the evaluation should have been completed in the last quarter of 2019, the actual completion date was in the second quarter of 2020. This was due to the fact that the public consultation was launched later than initially anticipated. In order to allow enough time to process and analyse the outcomes, the Commission opted to extend the evaluation timeframe into 2020. Limitations and robustness of findings The main limitations encountered during this evaluation were the following: 1)Limited literature and “evaluative” evidence (i.e. evidence on what works well, desirable outcomes, etc.) 2)Unavailability of documents related to the preparation of the legislative proposal (the Directive was adopted in 2004 - pre-Lisbon Treaty and with no opinion from the European Parliament or an impact assessment) 3)Quantitative data (such as on number of hits) and budgetary data not readily available in implementing countries 4)Limited responsiveness of some stakeholders This was mitigated as follows: 1)Comprehensive primary data collection and analysis compensated for the lack of a substantial body of literature 2)Support via Permanent Representations to facilitate contacts with stakeholders in implementing countries

3)Where quantitative data was not available, alternative proxy data or qualitative evidence was provided in the analysis 4)Approximations and assumptions where data was not available have been clearly outlined. Despite the above, the findings of this evaluation picture clearly the current situation with regards to the use of API Directive. A general caveat: issues as “secure borders” or “accuracy of border checks”, or even the costs for a public administration to run a border check, can often only be estimated and might depend on perception. In its evaluation report, the contractor made sure to refer to opinions every time hard data was not available, and the same is done in this report. 5.Analysis and answers to the evaluation questions This evaluation builds on the study “Evaluation of Council Directive 2004/82/EC on the obligation of carriers to communicate passenger data” and it assesses the directive according to five criteria listed and described below. More information on each criterion, as well as on the source of each piece of information, can be found in the study itself. The evidence gathered in the study has been reviewed and analysed together with other sources of data in order to complete the picture for each criteria and to give a definite answer to each evaluation question. 5.1.Relevance The main question addressed in this paragraph is whether the objectives of the API Directive are pertinent to the needs of the stakeholders, and to which extent the intended benefits respond to problems and issues. This paragraph also looks at how well the Directive is adapted to future economic, technological, scientific, social, political and/or environmental advances. 2012 baseline situation on relevance ·In 2012, the Directive was assessed against the needs related to combatting irregular migration and improving border control, which are the two objectives defined in art. 1. More specifically, in relation to combating irregular migration, implementing countries highlighted the need of identifying persons banned from entering Schengen, identifying persons destroying their travel documents mid-flight in order to subsequently claim asylum, identifying document forgeries, etc. With regard to border control, implementing countries mentioned specific national needs, such as ensuring a smooth traffic flow at the air border crossing points, implementing a ‘Smart Border’ system, enhancing passenger experience, receiving information before the border crossing points in order to enhance the preparedness of border checks, etc. ·Implementing countries’ competent authorities with a longstanding tradition of fighting against terrorism also identified law enforcement as a perceived need at the time of transposing the Directive. ·The perceived national needs at the time of transposition largely align with the objectives of the Directive. Almost all implementing countries recognised the objectives of the Directive as relevant to national needs at the time of transposition, which also matched to the current national needs as identified by national stakeholders. Yet for a few implementing countries, one of the main reasons for transposing and / or implementing the Directive was to comply with the Immigration and Asylum acquis as part of accession to the Schengen area with no particular national needs, problems or issues identified a priori. 2019 key findings on relevance ·The rationale for collecting API data is still valid across all stakeholders. ·The objectives of the API Directive listed in the text of the Directive (improving border control and combating irregular immigration) remain highly pertinent to the needs of the relevant stakeholders, as confirmed by the vast majority of consulted stakeholders across different stakeholder groups. ·Law enforcement including the fight against terrorism (identified as ‘specific objectives’ under the intervention logic) also remain, in the view of the stakeholders, highly pertinent to their needs. ·Amongst the main external factors driving the need for collecting API are the increase of passenger flows as well as the level of professionalisation and internationalisation of criminal groups and their cross-border activities. These factors are both likely to keep playing a role in the future. ·Collecting API data is also relevant to facilitate legitimate travel which is currently not per se an objective of the Directive. The objectives of the API Directive remain highly pertinent to the needs of the relevant stakeholders, as confirmed by the vast majority of consulted stakeholders across different stakeholder groups. Interviewed implementing countries’ competent authorities confirmed that the needs and problems tackled by collecting API data relate precisely to the objectives identified in the API Directive, i.e. border control management, combating against irregular migration, law enforcement including the fight against terrorism. This is also corroborated with the responses to the Public Consultation: ·85% of respondents strongly agreed or agreed that the API Directive is relevant to enhancing internal security; ·83% of respondents strongly agreed or agreed that the API Directive is relevant to improving border control; ·78% of respondents strongly agreed or agreed that the API Directive is relevant to fighting crime such as terrorism; ·75% of the respondents strongly agreed or agreed that the API Directive is relevant for combatting irregular migration

In addition, according to stakeholders, the use of API data can contribute to speed up border checks, and as such is considered a useful travel facilitation tool, in particular in light of the increase of air travel and the growth of the number of passengers. In recent years, the number of passengers in air travel has increased significantly in all regions of the world. In the last 6 years, the total number of air passengers taking off or landing in the European Union has increased by over 25% - i.e. from 830 million in 2012 to over 1 billion in 2017 – with around 40% of those passengers being international extra-EU passengers. Although the COVID-19 crisis, which emerged outside of the temporal scope of this evaluation, is having a substantial impact on the volume of travellers, a recent survey of commercial airlines worldwide, indicates that the majority of respondents expect flights activities to recover within 2 years, thus suggesting a likely continuation of the long-term trend in passenger growth. Considering the increase of the number of passengers, Border Control Authorities are faced with a significantly increased workload in identifying and clearing passengers, often with limited resources. At the same time, the professionalisation and internationalisation of organised crime and new and heightened security risks, including the threat of terrorism, are developments which necessitate new and innovative measures using new information technologies, such as API systems. The deployment of information technology can be harnessed to ensure that details of arriving passengers are received in advance of the arrival of the flight and thus, allowing the Border Control Agencies adequate time to utilise their resources more efficiently. The table above summarises the rationale for collecting API data by stakeholder type. Extent to which the objectives, scope, and definitions set out in the Directive are still deemed to be suitable and fit for purpose As demonstrated above, there is a strong rationale for collecting API data. However, the evaluation study highlighted a number of issues related to the API Directive as a legal instrument. Regarding the Directive’s objectives, it should be noted that only two objectives out of the four identified in the intervention logic are explicitly mentioned in Article 1 of the Directive (i.e. border control and combating illegal immigration). Although the Directive was adopted as a response to a terrorist attack, the legislator defined its objectives in terms of improving border controls and combating irregular migration, limiting themselves to mentioning the added value of passenger data in combating terrorism in a recital and leaving the whole law enforcement component to the national legislator in Article 6(1). In terms of its scope, definitions and provisions, the main issues identified include inter alia: ·Use of API for law enforcement purposes: Unlike the PNR Directive which details the serious offences and crimes for which PNR data can be used, the API Directive does not define “law enforcement” and hence, API data can be used very broadly, i.e. for any law enforcement purpose. This reduces the foreseeability of data processing for the data subjects and leads to diverging practices in different implementing countries. ·Data elements: Article 3(2) of API Directive provides a non-exhaustive list of data elements which leaves each implementing country the right to request additional data in line with national legislation. These data elements are inconsistent with the elements in the Machine Readable Zone (MRZ) of the passenger’s identity document and with the API data elements specified in Annex I of the PNR Directive as well as in the international standards specified by the WCO/IATA/ICAO. This raises questions on the overall relevance of the data-set, and the diverging practices in different implementing countries lead to a burden for air carriers. ·Types of flights: The API Directive does not specify whether API data should be collected on all types of flights, as a result of which, flight coverage varies among implementing countries. Implementing countries requesting API data from selected flights do so on the basis of risk analysis and/or policy priorities. The risk-based approach may help saving technical and human resources related to API data collection for both carriers and border control authorities. However, the risk-based approach could result in security gaps as API data is not collected for certain routes considered low risk. ·Type of carriers: The API Directive does not specify or define the types of air carriers for which API should be collected; as a result in the majority of implementing countries, API is not collected for charter and non-scheduled flights; however, while the majority of proprietary systems developed by international airlines providing scheduled service rely upon the use of UN/EDIFACT PAXLST messaging transmitted via existing airline communication networks to comply with API data provision requirements, other entities, such as Charter Carriers, Air Taxi operators, and Executive Air Carriers operate using a differing business model and may not have the technical infrastructure in place to transmit API data with the PAXLST format (WCO/IATA/ICAO Guidelines). This could also be the case for other modes of transport. ·Geographical scope: The “API Directive” defines external borders as “the external borders of the Member States with third countries” (Article 2.b). This provision has led to different interpretations of the Directive’s geographical scope of application: -1) The Directive’s obligations apply to flights coming from outside the European Union (according to this interpretation, carriers operating flights which depart from a Schengen Associate Country are required to supply information on passengers when they are flying into an EU Member State). -2) The Directive’s obligations apply to flights coming from outside the Schengen area, irrespective of whether the country of origin belongs to the EU or not. -3) The Directive’s obligations apply to flights coming from outside the Schengen area, only if the country of origin does not belong to the EU. In addition, some implementing countries and air carriers did raise the question as to the extent to which the Directive would apply in the event of reintroduction of internal border controls by one or several members of the Schengen zone.

5.2.Effectiveness The main question addressed in this paragraph is how successful the EU intervention has been in achieving or progressing towards its objectives and corresponding intended impact. 2012 baseline situation on effectiveness ·National authorities considered that API systems contributed to the achievement of the objectives they were set up to address: ·The reduction of irregular migration by improving risk-based profiling of international passengers and increasing the rate of detection of persons identified as irregular migrants; ·The improvement of border control practices primarily in helping border management authorities to better prepare for the control of specific passengers through advance screening of their API data. ·Better preparedness of law enforcement at the EU external border by helping to identify persons posing security risks and other persons including victims of human trafficking and smugglers. 2019 Key findings on effectiveness ·The findings from 2012 are largely confirmed. ·The implementation of the API Directive by implementing countries has contributed to its objectives: (i) improving border control; (ii) combating irregular migration ·It also contributed to the ‘specific objectives’ identified in the intervention logic: (iii) law enforcement, including in particular (iv) fight against terrorism. The lack of harmonisation in the implementation of the Directive is an obstacle to effectiveness. For example, from the airlines’ point of view, the most significant challenge is the lack of standards in the set-up of API systems and the transmission of API data. Impact on improving border controls The implementation of API systems has overall been effective for border control purposes and has been positively assessed by stakeholders. By obtaining passenger data in advance of arrival (as soon as the passengers have boarded the aircraft at the airport of departure), border management authorities have additional time to allocate resources and examine possible issues with passengers or their documents and identify those who may require secondary checks upon arrival. However, the extent to which such results have materialised differ significantly across implementing countries and is difficult to quantify in terms of reduced border crossing time as the resources are essentially adapted (to the extent possible) for the known number of problematic cases. In addition, the average processing time for passengers is influenced by other external factors: the introduction of systematic verification and authentication of the travel-document, the systematic border checks in SIS, Interpol’s Stolen and Lost Travel Documents (SLTD), and national systems (Regulation 2017/458), and the overall increase in the volume of air passengers. Impact on combating irregular migration in Member States/EU The API systems have supported implementing countries authorities in tackling irregular migration. As passenger flows have increased over the years, API systems have been required to process increasing amounts of data used for identifying potential irregular migrants. API systems improved the implementing countries’ capabilities to tackle irregular migration, by providing additional time for analysis of information and optimising second-line response by border guards. Impact on law enforcement, including fight against terrorism The use of API data is perceived as necessary for internal security and to counter the threat from terrorism. According to stakeholders, the risks of such threats to the European Union remain high, and the added value of API data could be of paramount importance. API systems have had a clear impact on the improvement of internal security, especially when used in conjunction with PNR data. Based on the stakeholders’ replies, it is confirmed that overall the Directive has achieved its objectives. Factors contributing to or impeding the intended objectives of the Directive Since 2012, Member States have seen an increased value in using API data for border controls and law enforcement purposes. The factors that stimulated the increased use and appreciation of API data include: ·Increased volume of air-travel: the increase in the number of air passenger further increased the need for the use API for the border guards to handle efficiently the increased volumes. This need became particularly paramount in the context of the introduction of Regulation 2017/458 (the so called “Systematic Checks Regulation), where the use of API is specifically mentioned. ·Migratory crisis: external threats from irregular migration during the 2013-2017 migration crisis brought in a renewed appreciation and need for the use of API data.

·Terrorism: the spade of terrorist attacks across the EU has also contributed to increase the recognition of the use of API data. ·International impetus: in recent years the UN has repeatedly called on States to require airlines operating in their territories to transfer API to national authorities to detect departures or attempted entry or transit of suspects with the aim to counter terrorism. In addition, since February 2018, the establishment of national API systems is an ICAO standard, making it mandatory for all Contracting States to the Chicago Convention. Finally, the OSCE Ministerial Council adopted on 8 December 2016, a Decision on enhancing the use of API, whereby OSCE participating States commit, inter alia, to establish a national API system. ·Increased use of the Schengen Information System (SIS): The quality and volume of data in SIS has increased exponentially. The number of alerts in SIS has grown from 50 million in 2013 to 82 million in 2018, transforming the system into a valuable instrument for EU security and border management. ·Introduction of the PNR Directive: When implementing the PNR Directive, EU Member States have included API data into PNR sets whenever available, as foreseen in the PNR Directive. API data has proved to be a necessary element to enhance the reliability of PNR data significantly. According to stakeholders, a number of issues have and continue to limit the effective use of API: ·Data Quality: API data is most useful if it is "verified". Incorrect or incomplete data, e.g. due to manual entry related errors, can lead to a waste of resources. With self-check-in (on-line, airport kiosks) process, these issues have been exacerbated. ·The time limitation of 24 hours – Some Stakeholders claim that this limits some of the possible analysis that could be done for border control purpose. Not all PIU/API units operate on a 24/7 basis. Therefore, data arriving on a weekend night may not be processed until the next day. In some Member States, the use of API data only on selected routes may have a ‘displacement’ effect – therefore making criminals change behaviour or use low-risk flights. ·The limited collection of API data for in-bound extra-Schengen flights limits the potential effects of the use of API data. ·The separate analysis of API and PNR is also a limitation that diminishes considerably the effective use of API – the joint analysis could also contribute to border control efforts in addition to law-enforcement. ·The API dataset imposes certain limitations to the analytical value of the data. For instance, seating information and data with regard to luggage, which most carriers already collect, could add value to the analysis in combatting illegal migration and or customs control. ·The differences between implementing countries in the use of API data for law enforcement including counter terrorism also shows that there is still room for further development to enhance the effectiveness of the API Directive. ·The differences observed in each implementing countries’ organisational structures and API governance create a challenge for carriers, that have to deal with a number of different interlocutors in different countries. ·The absence of API data of the crew has been highlighted by some stakeholders as a possible factor limiting the effectiveness of the measure. ·The implementing countries have diverging approaches on which systems or databases to query. While the SIS and national watch-lists are often cited, this is not a uniform and systematic practice. Impact of the Directive on the stakeholders As highlighted by the evaluation study on the basis of surveys and interviews with stakeholders, the implementation of API systems has affected three key stakeholder groups: competent national authorities, carriers and passengers. The API Directive had a more pronounced impact on the work and resources of national authorities and airlines, with more limited impact on passengers. Impact on carriers As regards carriers and their industries, the majority of industry respondents report additional costs related to the implementation of their API systems. Additional challenges stem from the need to ensure the correctness of personal data. Different technological solutions and organisational set-ups across implementing countries further complicated the compliance or lead to increased costs for carriers, even if not all implementing countries chose to sanction carriers. In comparison to the baseline, there is no significant difference in terms of observed or perceived impacts.

Impact on passengers Overall, the impact the API Directive had on passengers was mixed: a reduction of waiting time for passengers was observed, but not all stakeholders have perceived it as such, as demonstrated by the high number of blank replies (46%) in the corresponding question. It should be noted that the waiting time at border gates for passengers is not only affected by the use of API: for example, while the use of API had a positive impact on processing time during systematic checks, the average processing time for passengers since 2017 has increased due to external factors: the introduction of systematic verification and authentication of the travel-document, the systematic border checks in SIS, Interpol’s Stolen and Lost Travel Documents (SLTD), and national systems (Regulation 2017/458), and the overall increase in the volume of air passengers. Another impact on passengers concerns data privacy and the collection of personal data; however the European Passenger Federation indicated that it has not received complaints in relation to API data collection and processing. Their main explanation of this fact was that most likely passengers were not aware of their data being used for this purpose. This might also be due to the fact that API data is not perceived by passengers as sensitive information, as it concerns data included in travel documents and boarding passes, which are in any case shown to border authorities at the border checks. Impact on national authorities There have been several impacts of the Directive on the activities of competent national authorities. One of these relates to the costs incurred due to the set-up and running of targeting centres or the collecting and processing of API data. These costs are discussed in more detail in Section 5.3 (Efficiency) below. The main positive impact has been the increased analytical and investigative capacity of law-enforcement and border authorities, which has translated in increased number of suspected persons identified / and apprehended. Another positive impact is the increased capacity of border guards to clear passengers at the EU external borders, which leads to the facilitation of border control, increased security and better cooperation with other Member States. 5.3.Efficiency The main question addressed in this paragraph is the extent to which the API Directive has achieved its objectives at a proportionate cost. The analysis comprises: a)an assessment of the nature and scale of costs (including both capital and operating expenditures) associated with the implementation of the API Directive; b)an assessment of the nature and scale of benefits; and c)a comparative assessment of costs and overall outcomes / impacts. The analysis does not include the assessment of the necessity and proportionality of the measure as such. 2012 baseline situation on efficiency Costs of the API Directive 1.In 2012, the implementation of API systems entailed varying levels of costs for implementing countries authorities. These differences were partly explained by the cost items included in the calculation of total costs but also the type of API systems developed and the extent to which the systems were implemented. Irrespective of these differences, most implementing countries authorities indicated that API systems have not had a significant impact on their operating budgets, which were judged to have been negligible. 2.The related compliance costs for carriers, on the other hand, ranged from less than EUR 0.5 million to over EUR 2 million on average per carrier per annum. These costs were seen as substantial by the airline industry. The perception among air carriers was that API systems diverted internal resources from day-to-day commercial activities. In addition to system-related costs, carriers had incurred non-compliance costs in the form of sanctions. Benefits of the API Directive 3.Key benefits of the Directive as reported by national authorities were: -Enhanced border controls: border control authorities viewed the impact of the collection and use of API data positively, for instance it enabled a faster reaction time against suspect irregular migrants and criminals. Border procedures were also reported to have been improved in the case of certain implementing countries, while second line checks procedures were found to be clearer. -Increased ability to combat illegal migration: API systems had contributed to curbing irregular migration by targeting suspect irregular migrants better. API systems were also perceived as having brought about an improved knowledge of migration routes and, to some extent, had contributed to an increase in the number of refusals of entry. -A greater number of arrests or increased detention: some implementing countries reported instances whereby API data checks allowed border control and/or law enforcement authorities to act against international passengers (presenting a threat to border security), such as deportation and / or arrest. Moreover, API data has been used in combination with other information and evidence for the prevention, detection and investigation of crimes. 4.Carriers, specifically air carriers, did not consider that the implementation of API systems brought about direct business benefits. Having to comply with the API Directive requirements implied that resources were diverted away from commercial activities. Overall cost efficiencies 5.The overall efficiency with respect to outcomes associated with API data collection was difficult to measure due to the lack of systematic data that could be used for the assessment. However, national authorities consulted believed that API systems have had an impact at a reasonable cost. None of the authorities thought that API was not cost efficient at all, but the perceptions of overall efficiency ranged from very low to very high. 6.From the perspective of carriers, the Directive was not considered cost efficient as it was not perceived as having improved timeliness of flights or general carrier security. Many carriers also felt that having to implement API systems diverted them away from undertaking core business activities, bringing about costly changes to customer practices. 2019 Key findings on efficiency Costs of the API Directive 7.Additional costs derived from the implementation of API systems primarily include: direct costs for implementing countries authorities in terms of setting up and running API systems, compliance costs for carriers, and non-compliance costs (in the event of breaches). 8.The overall costs involved in the implementation of API systems varied substantially across the different implementing countries. This can be attributed to different needs and preferences exhibited by Member States, which in turn contributed to differing approaches to implementation and, hence costs. 9.Carriers (specifically air carriers), considered that the overall costs entailed by the implementation of API systems were significant and would not have been incurred had their implementation not been mandated. API-related set-up costs, comprising the acquisition of an appropriate API (data capture) system or the adaptation of the existing IT infrastructure, averaged to less than EUR 0.5 million among air carriers. Recurring expenses were also generally estimated at less than EUR 0.5 million a year. The main cost items reported were API data transmission costs, and general system maintenance costs. Failure(s) to comply with API Directive requirements have resulted in sanctions for some air carriers, representing lost revenue or investment (had the money been channelled towards other business operations). Benefits of the Directive 10.National authorities recognised that the implementation of API systems has helped drive positive operational outcomes, notably in the area of border control and management. -As such, used in conjunction with other border surveillance tools, API systems were perceived to having helped improve the (early) detection of ‘high-risk’ individuals, thereby increasing national authorities’ ability and readiness to identify these individuals, and allowing for better management and deployment of resources on arrival. -By furthering a more efficient, risk-based approach to enforcement, it was also considered that API systems may have brought about positive, knock-on effects, notably a reduction in the time taken for border checks and, hence, clearance / ‘wait’ times for low-risk passengers. However, the evidence pertaining to actual waiting times was mixed. 11.It was further recognised that API systems have had a positive influence on national efforts to fight irregular migration and to improve law enforcement and internal security. It was recognised that API systems remained a necessary tool ensuring effective security checks at the borders preventing the entry of people who could have posed the threat (including due to suspicion of involvement in terrorism). Overall cost efficiencies 12.National authorities perceived that the overall costs incurred from the implementation of API systems have been proportionate and are justified, considering the extent of resources used and the nature and level of benefits / impacts achieved to date. 13.Carriers, notably air carriers, considered that the costs incurred from the implementation of API systems are only partially or not at all justified, given that (direct) benefits have been minimal for them. In addition, some air carriers were critical of the extent of variation in API-related requirements across implementing countries, which they felt created uncertainties, leading to an increased propensity for non-compliance and, consequently, a greater likelihood of enforcement actions being taken against them. The main limitations encountered when assessing the efficiency of the Directive in quantitative terms concern the absence of quantifiable data allowing measuring the benefits deriving from the Directive as well as the substantial differences in costs observed in implementing countries. Overall the research shows that, while national authorities consider the costs incurred to be proportionate to the benefits, air carriers do not share the same view, which confirms the outcome of the previous evaluation exercise. As to whether the same results could have been achieved at a lower cost, stakeholders indicated a number of measures that might have reduced their costs in implementing the Directive. These are: ·Use of standardised requirements to increase coherence across implementing countries as well as data quality, and facilitate data collection/transmission thus avoiding sanctions. ·Use of technical solutions, such as a centralised routing mechanisms, reducing the number of messages that carriers have to transmit.

Below a more detail description of costs and benefits related to the API Directive. Overview of costs associated with the implementation of API Directive The API Directive brought about important costs, especially for public authorities and carriers. A typology of the costs incurred by each affected group is set out below. Direct costs For carriers specifically, direct costs resulted primarily from compliance activities. One-off, set-up costs have stemmed from capital investments into the acquisition of an appropriate API (data capture) system or the update / adaptation of the existing IT infrastructure. Most carriers outsourced the set-up to a third-party, hence incurring additional costs (e.g. consultancy fees). Furthermore, (some) air carriers explained that the overall process of collecting and transmitting API data to public authorities is managed by a third-party technological solutions provider, in which case initial set-up costs were reported to have been minimal. However, most likely, the provision of API-related services by service providers would have entailed an increase in licence / service fees. These payments are likely to occur on a recurring basis. Other ongoing, operating expenses for carriers include staff costs. Ad hoc non-compliance costs Contravening national (API) laws can result in sanctions for carriers. Where such remedial actions have been carried out, they were perceived by some (air) carriers to have been important, notably in terms of their magnitude. Remedial enforcement actions, such as financial sanctions, can be contested in court. Appeals may however present additional (and potentially important) costs for appellants. Enforcement costs Public authorities (e.g. border control authorities) faced one-off set-up costs, notably as a result of the acquisition or development of their respective API system (and associated IT infrastructure). Ongoing operating expenses mainly comprise system maintenance costs staff costs, and other running costs. In some cases, public authorities incurred judicial costs (e.g. adjudication, dispute resolution, or litigation costs), for the review of an enforcement action or as part of appeals initiated by industry. Indirect costs Legislation, such as the API Directive, may present ‘implicit economic’ costs or ‘opportunity’ costs for regulated parties. These represent the monetary value of what regulated parties forego for channelling resources away from their day-to-day operations to compliance activities. Any cost incurred as a result of complying with the API Directive thus represents an opportunity cost to carriers. As attested by air carriers, compliance costs would not have been incurred had the Directive not been implemented. The financial and human resources spent on compliance could have been used for other business activities. Specific costs for national authorities Implementation costs of API systems vary substantially across the different national authorities. Implementing countries also have allocated different level of (financial and human) resources to the implementation of API systems. Factors influencing the costs to national authorities include: (1) the (selected) type of API system / technological solution; (2) the type of flights or the number of routes (e.g. inbound/outbound/both; extra-EU/intra-EU/both; etc.) for which API data is collected; (3) the type of checks, assessments and analyses that are undertaken on API data; and (4) the extent to which the implementing countries’ respective API systems are integrated with other existing border management systems. One-off costs As indicated previously, set-up costs (or one-off development costs) were found to vary across implementing countries. In some implementing countries, notably Germany, Switzerland and Lithuania, the average set-up costs were in the order of approximately EUR 2 million. Similarly, Greece, though having not yet implemented an API system, has an allocated budget of almost EUR 1 million to do so over the next five years. In contrast, at the lower end of the spectrum, estimated costs ranged from as low as EUR 50,000 in Finland to an average of about EUR 200,000 in the Czech Republic and Sweden respectively. Finally, the costs reported by the Italian and Dutch authorities were of a much greater magnitude (when compared to other Member States), averaging to about EUR 9 million. System specificities and/or implementation particularities may help explain the extent of variation observed in costs reported by implementing countries. Those with higher cost levels, such as Germany, have reported investing in customised API solutions that have seemingly required extensive resources, both internally and externally. Other implementing countries, such as Switzerland, have opted for API solutions that can support more complex (automated) data verification or (data) quality assurance operations. Furthermore, some implementing countries, such as Lithuania, have “single-window” systems in place. These typically support API and PNR transmissions and may have been more costly to develop (owing to their complexity). MS Features of API system Cost item Frequency Set-up cost 2012 2013 2014 2015 2016 2017 2018 2019 Jan-May CH 14.Introduced in 2011; fully implemented and operational since 2015 15.API system developed in-house; maintenance undertaken in-house 16.API data is collected at 3 BCPs 17.Initial investments 18.One-off 2,700 NA NA NA NA NA NA NA NA 19.Operating / running costs 20.Recurring n/a 360 368 237 251 280 341 294 132 21.Ongoing development costs 22.Recurring n/a 163 82 143 160 109 123 59 3 CZ 23.First introduced in 2008; fully implemented in 2012 24.The development of the API system was outsourced to an external supplier; maintenance is undertaken by external personnel / third party 25.API data is collected at five air BCPs 26.Acquisition of API infrastructure / IT system 27.One-off 200 NA NA NA NA NA NA NA NA 28.Operating / running costs 29.Recurring NA NA 40 40 40 40 40 40 40 DE 30.Introduced in April 2008; fully operational since then 31.In-house development; Maintenance by an external provider 32.As of 2019, API data is being collected at close to 80 air BCPs 33.Set-up/development costs 34.Operational costs 35.One-off 36.Recurring 1,000 NA 150 NA 250 NA 100 NA 150 NA 150 NA 210 NA 150 NA 65 DK 37.Fully operational in 2017; currently being integrated with PNR. 38.API data is collected at 10 air BCP to air carriers on all flights 39.Set-up costs 40.Operational costs 41.One-off 42.Recurring NA NA NA NA NA NA NA NA NA NA NA NA 310 NA 360 NA NA 150 EL 43.API system not developed yet 44.One-off NA NA NA NA NA NA NA NA 900 LT 45.First introduced in 2016; a single-window model (gathering both API and PNR data) implemented in 2017 46.API data is collected at four air BCPs 47.API system developed in-house; maintenance is also in-house 48.Initial investments 49.One-off NA NA NA NA NA NA 1,785 NA NA NL 50.First introduced in 2009; fully implemented in 2017 51.API data collection mandated to air carriers on inbound extra-EU/Schengen flights 52.API system developed partly in-house and via a third-party; maintenance both in-house and external personnel 53.API data is collected at six air BCPs 54.Initial investments 55.One-off NA NA NA NA NA NA 10,000 NA NA SE 56.Fully implemented in 2018 57.API data collection mandated to air carriers on inbound extra-EU/Schengen flights 58.API system developed in-house; technological solution purchased from a third-party 59.Staff costs (involved in API system set-up) 60.Staff costs 61.One-off 62.Recurring NA NA NA NA NA NA NA NA NA NA NA NA 343 NA NA 170 NA 170

Source: ICF – Evaluation Study. Notes: (1) 2011 is the baseline year; (2) 2019 figures are provided for the months January to May; (3) all figures have been rounded to the nearest thousand; (4) figures provided in local currencies have been converted into euros (at the market rate prevailing at the time of writing); (5) ‘NA’ denotes ‘not applicable;’ (6) ‘n/a’ denotes ‘not available’ Recurring costs Operating expenses also appear to vary substantially across implementing countries. As it can be reasonably expected, Member States that accommodate larger passenger flows tend to incur higher year-on-year running costs. Germany, for instance, faces on average EUR 200,000 every year in running / maintenance costs. In other smaller implementing countries, however, recurring expenses were almost on par with those observed in larger implementing countries. As such, on average, Denmark, Sweden and Switzerland face about EUR 250,000 costs every year. This could however be explained by certain contextual factors, notably higher labour costs in these countries. Currently, Switzerland has the highest (estimated) hourly labour costs (in Europe) at almost EUR 55.0 per hour, followed by Denmark and Sweden at almost EUR 45.0 and EUR 40.0 per hour respectively. Staff costs, typically accounting for a large part of recurring costs, could thus explain the significance of overall operating costs observed in these implementing countries. Specific costs for carriers One-off costs Carriers generally considered the implementation costs of API systems as significant. They further recognised that such costs would not have been incurred had their implementation not been mandated. API-related set-up costs were estimated at less than EUR 0.5 million. As stated previously, initial set-up costs primarily resulted from the adaptation of air carriers’ existing IT systems / infrastructure to ensure that they were are in line with the requirements of the API Directive. Among a few larger carriers, however, initial set-up costs were contained and less burdensome. These carriers explained that the API Directive did not entail direct costs for them per se since third parties, notably technology service providers (e.g. Amadeus, SITA, etc.), were liable for undertaking the necessary changes and adapting their existing product offering to incorporate the capture of API data. Some costs were nonetheless borne by the air carriers in question, though these were generally perceived to have been minimal. Recurring costs API-related operating costs were generally estimated at less than EUR 0.5 million a year. For one mid-sized air carrier, for instance, annual operating costs range from EUR 9,100 to EUR 13,600 and relate primarily to fees paid to an external service provider for the transmission of API data to authorities on their behalf. A cost breakdown by carrier size is less clear, though one could expect costs to be proportional to the number of API transmissions. Larger carriers, i.e. those serving multiple routes and/or offering an extensive array of flights, are therefore likely to be facing higher transmission costs and overall recurring costs respectively. In addition to the above, air carriers argue that the existing set up creates a competitive disadvantage for air transport as compared to other modes of transport, due to the burden for air passengers and industry associated costs (compared to maritime, train and coaches/buses operators). Other costs Some of the larger carriers consulted expressed concerns about ad hoc costs, specifically those driven by sanctions. These air carriers were mainly critical of the lack of a consistent approach among different implementing countries in defining and interpreting breaches (or, in other words, clearly communicating expectations for the minimum acceptable level of (API) data quality). Differing approaches in enforcement were thus perceived to be hampering compliance efforts and increasing the risk of non-adherence and potential corrective actions being imposed by national authorities. It was believed that the overall cost to / impact on carriers (of the differences observed in enforcement regimes across Europe) to be the revenue lost (where financial sanctions were imposed) as well as the burden associated with having to abide by different rules across the implementing countries. An estimate of the latter was not gathered during this research. There is nonetheless evidence pertaining to the (monetary) size of financial sanctions, which has been in the order of EUR 4,000 on average, per breach (i.e. where API transmissions were incomplete or not received by national authorities), in some Member States (including Austria, the Netherlands, and Poland). Sanctions have generally been higher in Germany, where they reached an average of EUR 6,000 per breach. By law, German authorities are able to impose sanctions of up to EUR 50,000, much higher than other Member States (where the permitted maximum averages to about EUR 5,000), which could help explain the higher sanction levels generally observed. Benefits of implementing API systems Operational benefits The implementation of API systems helped drive positive operational outcomes, notably in the area of border control and management. API systems constitute an effective border management tool for national authorities and it is recognised that they have contributed to improved border control activities, notably by increasing the relevant authorities’ preparedness and readiness, in terms of identifying high-risk individuals ahead of their arrival and by expediting the process of passenger checks upon arrival. With API systems in place, national authorities are able to screen passenger lists and detect any suspicious individuals ahead of flight arrivals. The API data received is used to query various systems, in particular SIS, allowing for a ‘fuzzy’ or ‘approximate’ search. Such a ‘fuzzy’ search will require more time and may result in false-positives that need to be evaluated. The very short physical border-control process does therefore not allow such ‘fuzzy’ searches. Evidence pertaining to the proportion of ‘suspicious individuals’ identified through API data checks at implementing countries’ external borders is limited and the number of hits vary substantially across countries, owing to various contextual differences, such as the type of national databases used, the decisions on what type of data against which API data are matched, etc. Nevertheless, a shared perception among consulted stakeholders is that API data have allowed national authorities to identify and analyse risks posed by certain passengers more efficiently. By furthering a more efficient, risk-based approach to enforcement, it was also considered that API systems may have brought about positive, knock-on effects, notably a reduction in the time taken for border checks and, hence, clearance / ‘wait’ times for low-risk passengers. Wider policy and societal benefits API systems are considered to have had a positive influence on national efforts to fight irregular migration and other associated criminal activities and to enhance law enforcement and internal security. However, the full scale of benefits realised on the ground is difficult to estimate. This is because API systems constitute one of the numerous tools used in combination by national authorities in the areas of migration control and law enforcement.

The API Directive is considered to helping combat irregular migration, notably by increasing the capacity of border control authorities to identify fraudulent documents and the capacity of law enforcement authorities to identify high-risk passengers and detect and prevent migration crime. The Croatian and Latvian authorities estimate the impacts of the collection of API data on the identification and arrest/detainment of high-risk individuals to having been quite or highly important. Furthermore, the evidence gathered indicates that API data checks can allow implementing countries to increase security at their borders, for example by identifying and refusing entry to passengers judged suspicious or ‘high-risk.’ In Finland (see Figure 6 overleaf), for instance, of the 10,400 passengers who were refused entry over the period 2014-19, about 150 passengers (or almost 2 per cent) were identified through API data checks. The implementation of the API Directive was further considered to be necessary for implementing countries’ actions targeted at increasing/preserving internal security and public order. Implementing countries report they use, and consider API necessary for fighting terrorism. As such, the ability to match API data against national/EU/foreign counter-terrorism and counter-organised crime databases was recognised to providing relevant authorities with necessary information and better targeting security checks at the borders The quantification of such benefits is however difficult to undertake. API systems are widely and commonly used in conjunction with other border surveillance and law enforcement tools, making it difficult to isolate their impacts on wider societal outcomes, such as internal security. 5.4.Coherence The main questions addressed in this paragraph are, on the one hand whether, a) the objectives and purposes of API systems in Member States are consistent with the Directive, b) The Directive is coherent with other relevant EU legislation. On the other hand, we also assess the coherence of the Directive with the international regulatory framework on passenger information (e.g. the Chicago Convention). 2012 baseline situation on coherence ·The objectives outlined in related EU legislation, national legislation, as well as those driving the implementation of API systems, were considered compatible with those of the API Directive. ·However, in practice, the national implementation by some implementing countries was not fully in line with Data Protection legislation. The main data protection issues identified related to the length of time for which API is retained and the purpose for which it was used and the number and position of persons who had access to the data. In addition, some national legislation did not fully and accurately transpose data protection obligations on the storage and deletion of the data. ·The 2012 evaluation also anticipated potential coherence issues arising with the introduction of the then proposal for a PNR Directive. Potential coherence issues mentioned were around similar data elements and the distinction between the main purposes of both Directives. 2019 Key findings on coherence ·The objectives of the national API systems are aligned with the objectives of the API Directive, although as a result of the Directive’s minimum requirements, the implementation of API systems shows a fragmented picture. ·There are several discrepancies between the API Directive and the PNR Directive causing operational challenges in practice. The main coherence issue relates to the lack of clarity on the use of API data for law enforcement purposes and the differences in data protection frameworks in the API and PNR Directives, specifically regarding data retention periods. ·The ETIAS/EES/(VIS) Regulations contain requirements for carriers (air, sea, land (but not trains) to query these central systems with personal data captured from the travel document(s) in order to determine if the carrier should let the person board (OK) or not (Not OK). This query contains (nearly) the same data as the d