EUROPEAN COMMISSION Strasbourg, 13.12.2022 SWD(2022) 422 final COMMISSION STAFF WORKING DOCUMENT



IMPACT ASSESSMENT REPORT

Accompanying the documents Proposal for a Regulation of the European Parliament and of the Council

on the collection and transfer of advance passenger information (API)

for enhancing and facilitating external border controls, amending Regulation (EU) 2019/817 and Regulation (EU) 2018/1726, and repealing Council Directive 2004/82/EC Proposal for a Regulation of the European Parliament and of the Council



on the collection and transfer of advance passenger information



for the prevention, detection, investigation and prosecution of terrorist offences and serious crime, and amending Regulation (EU) 2019/818 {COM(2022) 729 final} - {SEC(2022) 444 final} - {SWD(2022) 421 final} - {SWD(2022) 423 final}



Table of contents 1.Introduction: Political and legal context 2.Problem definition 3.Why should the EU act? 4.Objectives: What is to be achieved? 5.What are the available policy options? 6.What are the impacts of the policy options? 7.How do the options compare? 8.Preferred option 9.How will actual impacts be monitored and evaluated? Annex 1: Procedural information Annex 2: Stakeholder consultation Annex 3: Who is affected and how? Annex 4: Analytical methods – calculating the costs and savings Annex 5: Clear and mandatory set of API data Annex 6: Complementarities and differences between Advance Passenger Information (API) and Passenger Name Records (PNR) Annex 7: Streamlining the transmission of API data to the carrier interface with an API router





Glossary Term or acronym Meaning or definition API Advance Passenger Information CJEU Court of Justice of the European Union CRM Centralised Routing Mechanism EES Entry / Exit System ETIAS European Travel Information and Authorisation System eu-LISA European Union Agency for the Operational Management of Large-Scale IT systems in the Area of Freedom, Security and Justice FRA European Union Agency for Fundamental Rights GDPR General Data Protection Regulation iAPI Interactive API ICAO International Civil Aviation Organization IATA International Air Transport Association (IATA) LED Law Enforcement Directive MRZ Machine Readable Zone OCR Optical Character Recognition OSCE Organisation for Security and Cooperation in Europe PAXLST Passenger List Message PIU Passenger Information Unit PNR Passenger Name Record SARPs ICAO Standard and Recommended Practices SIS Schengen Information System SLTD Stolen and Lost Travel Documents database (Interpol) VIS Visa Information System WCO World Customs Organization UNSCR United Nations Security Council Resolution



1.Introduction: Political and legal context The last decades have witnessed an increase of people travelling by air. In 2019, the International Civil Aviation Organisation (ICAO) reported 4.5 billion passengers globally carried by air transport on scheduled services. The EU recorded about 1 billion passengers in the same year, 520 million flying from or to extra-EU countries, 335 million on intra-EU flights and 160 million on domestic flights. After a temporary decline due to COVID-19 related travel restrictions, the volume of passengers is expected to continue to increase in the coming years. An effective management of the Schengen external borders is a prerequisite to enhancing security in an area without border controls within the EU. It requires Member States to apply firm and uniform criteria on the controls on entry and exit at the Schengen external borders. All travellers, meaning third-country nationals, stateless persons and EU citizens crossing the Schengen external borders, are to be effectively and systematically checked against the relevant databases. To achieve this goal, the Schengen Borders Code was amended in 2016 and 2017. The fact that over half a billion passengers enter or leave the EU every year puts a strain on the external air borders of the EU. To ensure that systematic checks can be efficiently performed on every air passenger, there is a need to speed up border controls at airports and ensure the facilitation of passenger flows while at the same time maintaining a high level of security. The processing of Advanced Passenger Information (API) is an effective tool for border authorities to anticipate their workload and to perform adequate border controls. API informs competent authorities in advance of the volume and identity of air travellers, allowing for pre-checks of air travellers prior to their arrival at the external border. API is a set of information on passengers such as name, date-of-birth, passport details, attributed seat, the baggage details and the exact travel route, that air carriers collect during check-in (either online check-in or check-in at the airport) and transmit in advance (at departure of the plane) to competent authorities of the country of destination. The sources of this information are the passenger’s travel document and the boarding card. As first-line border guards are under time pressure to perform their checks on air passengers, the availability of API greatly facilitates their tasks. It allows border officials located in a back office to query API data against databases such as the Schengen Information System (SIS), Interpol systems and national databases and watchlists well in advance of the actual arrival of the passenger. In doing so, persons of interest can be identified in a timely manner, and relevant information can be passed on to first-line border guards for further follow-up upon arrival of the passenger Consequently, effective external border management requires that every person is pre-checked with API data ahead of the arrival at the external borders. At international level, the Convention on International Civil Aviation (Chicago Convention) stipulates that each State shall establish an API system and have appropriate legal authority to oblige carriers to comply with the related standards and recommended practices as adopted by ICAO. At EU level, the 2004 API Directive regulates the transmission of API data to Member States to improve external border controls. The Directive imposes an obligation on air carriers to transmit API data, upon request, to the border authorities of the country of destination prior to the flight’s take-off. The API Directive is without prejudice to Member States using API data also for law enforcement purposes – which constitutes a separate purpose distinct from border management – in accordance with national law. The API Directive was evaluated in 2020 to assess the transposition by Member States and set up of national systems to collect and use API data. That evaluation assessing the implementation of the API Directive showed that all Member States have transposed the API Directive and most have implemented systems to collect and use API data. The 2020 evaluation also found that the API Directive remained pertinent with regards to the objectives pursued, namely border management and the fight against irregular migration. It however noted limitations in the implementation of the Directive. The lack of legal precision provided by the Directive has resulted in a plethora of national interpretations, creating gaps in the collection and use of API data and therefore undermining the overall effectiveness of the Directive. The evaluation also indicated that due to differences in the use of API data for border management and law enforcement as two distinct purposes with different operational needs, the effective use of API data for law enforcement purposes would require a dedicated legal instrument. There is indeed a global consensus that API data is not only a key instrument for border management, but also an important tool for law enforcement purposes, notably to counter serious crime and terrorism. The 2020 evaluation set out that the processing of API data for law enforcement including terrorism is highly pertinent. At international level, since 2014, United Nations’ Security Council Resolutions have repeatedly called for the establishment and global roll-out of API systems for law enforcement purposes. Criminals make frequent use of the EU’s main airports as well as smaller regional airports operating low-cost airlines. Their capability to travel fast and long distance, by air, without being detected (notably within the EU), has become an essential modus operandus for cross border criminality. The same applies for terrorism, with most terrorist campaigns having a transnational character, with the involvement of cross-border contacts or travels outside the EU. In this latter context, preventing foreign terrorist fighters (FTFs) from travelling to the EU and returning from conflict zones remains a particular priority. In traveling to and from conflict zones, FTFs often resort to indirect or ‘broken travel’ routes that combine different type of itineraries, outside and within the EU. The analysis of air passenger data has proven crucial for preventing departures and detecting the return of FTFs. As shown by the report on the Passenger Name Record (PNR) Directive review, the joint processing of API and PNR data plays a vital role in identifying, preventing, detecting, and disrupting terrorism and other serious crimes, as it enables the confirmation of identity of travellers and greatly improves the reliability of PNR data (see Box 1 below). However, the current EU legal framework only regulates the collection of PNR data for fighting serious crime and terrorism but does not do so for API data, leading to a security gap notably with regard to intra-EU and domestic flights. Addressing this gap, the June 2021 strategy towards a fully functioning and resilient Schengen area called for an increased use of API data in combination with PNR data for intra-Schengen flights to significantly enhance internal security, in compliance with the fundamental right to the protection of personal data and the fundamental right to freedom of movement. Box 1: Advanced Passenger Information and Passenger Name Records Passenger data are usually composed of two types of data: Advance Passenger Information (API) and Passenger Name Records (PNR). When a passenger buys a ticket with an air carrier, a PNR will be generated by the reservation systems of air carriers. This includes some but not all personal data, but also the complete itinerary, payment details, contact-details and special requests of the passenger. This PNR data is sent to the Passenger Information Unit (PIU) of the country of destination and often the country of departure. API data is captured by the air carrier during check-in of the passenger (online check-in and at the airport). This data is stored in the carrier’s Departure Control System (DCS) and generally sent to competent border authorities as a complete ‘passenger list manifest’ containing all passengers on board (so called batch-API delivery) at departure of the plane.

Both API and PNR contain information pertaining to the passenger and the flight on which he or she will arrive or depart. Both the PNR data and the API data contain a common reference (a six character booking reference) to enable consolidation of both data sets and therefore combined processing. While, API data are considered as ‘verified’ information as it corresponds to information on the travel document, and which can also be used by law enforcement authorities in order to identify suspects and persons sought, PNR data is unverified information provided by passengers. The PNR data of a certain passenger usually do not contain all potential PNR elements, but only those actually provided by the passenger and/or necessary for the booking. 2.Problem definition The 2020 evaluation of the API Directive, and the consultation process carried out for the purposes of this impact assessment, have revealed a number of gaps and inconsistencies in the way Member States process API data both for border management and for law enforcement purposes. These gaps and inconsistencies can be clustered into two main problems: The first problem concerns shortcomings in the use of API for pre-checks of persons before they cross the Schengen external borders. The second problem relates to the suboptimal use of API data for law enforcement purposes and the security gaps this creates. The following table presents the main problems and underlying drivers. Problems Drivers Not every person crossing the Schengen external borders is pre-checked with API data 1.No obligation on Member States’ authorities to request API data from carriers, not aligned with international obligations regarding the establishment of API systems 2.Inconsistent practices in Member States driven by the design of the legal provisions, in particular: ·No clear criteria on which flights API data should be collected ·Non-exhaustive list of data fields to be collected, not aligned with international standards on API (WCO/IATA/ICAO API Guidelines) ·No specification of the method to collect API data There are security gaps in the processing of air passenger data for law enforcement purposes –Security gap regarding flights where only PNR data is collected (i.e. not on intra-EU and domestic flights) –No clear EU rules on the use of API for law enforcement purposes, particularly on the retention period of the data, data elements and flight coverage, leading to uneven safeguards in terms of passengers’ protection of personal data 2.1.Not every person crossing the Schengen external border is pre-checked with API data 2.1.1.What is the problem? The API Directive is a tool supporting the application of the Schengen Borders Code by making external border checks more efficient. Effective external border management requires that every person is pre-checked with API data ahead of the arrival at the Schengen external borders. While the 2020 evaluation of the API Directive observed that Member States have implemented national API systems, it also observed that Member States make insufficient use of the possibility of API data processing to enhance border management. The way the API Directive is implemented by Member States varies greatly, driven by the flexibility that the Directive’s requirements provide. As a consequence, not every person crossing the Schengen external border is pre-checked with API data. The percentage of passengers for which API is collected and used as a tool for border management varies substantially amongst Member States. At aggregated level, for all Member States combined, this figure is estimated at 65% for inbound flights. In addition, there is an estimated use of API data for 25 % of all outbound flights for law enforcement purposes under national law. Chart 1: Member States and share of passengers on whom API data is collected on inbound and outbound flights Source: Data gathered from surveys sent to national authorities for the preparation of the external study supporting an impact assessment: Potential effects of different possible measures on advance passenger information and collected in autumn 2020. This patchwork of flight coverage creates a situation where it is easy for individuals that want to avoid checks to bypass routes where API data is consistently collected and instead fly and enter the Schengen area via travel routes where API data is less or not used. Once transmitted by air carriers, API data enables border guards to perform pre-checks on the identity of passengers and the validity of the travel document used against the databases provided for in the Schengen Borders Code. The Schengen Borders Code indicates that border checks on persons must be performed by checking the information contained in the travel document against relevant international (Interpol’s SLTD, EU (Schengen Information system) and national databases, also on the basis of advance passenger data. To add to the problem, the 2020 evaluation also demonstrated that when and where API data is collected by Member States, their national authorities do not use the API data in a consistent way to ensure effective external border management. For example, not all Member States use the API data for pre-checks against the databases set out in the Schengen Borders Code. Finally, there is a data quality issue. An effective use of API data requires the data to be accurate and complete. If identity data is not reliable and verified, which sometimes is not the case today, cross-checks in databases will not yield reliable operational results. The collection and transmission of API data is should be aligned with international API data standards to would ensure compliance of the API requirements by the air industry. 2.1.2.What are the problem drivers? This problem is driven by differences in the approaches of the Member States towards the collection and processing of API data. There is no legal obligation on Member States to request and use API data. The flexibility left to national authorities for the collection and processing of API data led to divergent practices, where a few Member States collect API data systematically while others do not. This is the main driver of passengers not being pre-checked with API data ahead of their arrival at the Schengen external borders. The API Directive only puts the obligation on carriers to transmit API data if requested by Member States. However, while all Member States have legally transposed the Directive, not all Member States have taken measures to request air carriers to transmit API data. Two Member States have not even set up a national system for the collection and use of API data. In a context where the API Directive leaves it to the discretion of Member States whether or not to request API data, no infringement procedures could be initiated to enforce the processing of API data.

Moreover, even where Member States make use of the possibility under the API Directive to request air carriers to transmit API data, the Directive sets only limited criteria for the collection, transmission and processing of API data as regards the flight coverage for the collection of data, the data elements to be collected, or the means to capture the data. This leads to very diverging practices. Firstly, flight coverage varies among Member States, as the API Directive does not indicate the scope of flights for which API data should be collected. The Directive offers the possibility to request API data on flights crossing the external borders without providing any guidance or criteria on how to select the flights for the collection of API data. Only a few Member States collect API data on all flights from third countries (see Chart 1 above). The majority of Member States collect data on selected flights only, in most cases covering over 50% of the passengers but in some cases only a small percentage. Several Member States also request API data from carriers departing to third countries for law enforcement purposes. This patchwork of flight coverage creates a situation where it is easy for individuals that want to avoid checks to bypass routes where API data is consistently collected and instead fly and enter the Schengen area via travel routes where API data is less or not used. Secondly, the API Directive includes a mandatory but non-exhaustive list of API data fields covering passenger data and flight information. While these elements are mandatory, Member States can request additional data fields in line with national legislation. Most Member States make use of this possibility. This in turn represents an additional burden on air carriers that need to comply with a different set of requirements depending on the routes on which they transport passengers and the Member State requesting data. Particularly on this point, industry stakeholders stressed the need for a future API instrument to take into account the evolutions in the international guidelines concerning API data collection since the adoption of the Directive, as developed in ICAO, the International Air Transport Association (IATA) and the World Custom Organisation (WCO) API guidelines (see Annex 5). Thirdly, as online check-in became a common practice in the past 20 years, API data from a travel document is increasingly manually transcribed or “self-declared” by passengers. This can lead to incomplete or incorrect data transmitted to national authorities (e.g. misspellings in the surname and last names, use of the automatic pre-filling function of forms leading to errors). Incomplete or erroneous API data can create loopholes in the depth and type of checks that national authorities can perform, negatively affecting the time needed to carry out checks in databases (e.g. more resources needed to manually review the results of automated checks). Incomplete or erroneous API data can impact passengers because of ‘false-positive’ automatic matches. Good quality data, both in the query as well as in the database, leads to exact matches that prevents passengers from being subjected to incorrect, unnecessary interviews. Where API data is incomplete (e.g. missing date-of-birth, missing gender, missing travel document number) or incorrect (misspelled name, mix-up of numbers), it may lead to matches that may need to be confirmed or inferred by physical secondary checks on the person and the travel document. The need to ensure that API data collected is accurate and complete is closely linked to the means or methods used by airlines to ensure that API data collected corresponds to the information displayed on travel documents. The API Directive does not prescribe the means for collecting API data from passengers. As opposed to manually transcribed information, a more automated collection of the data would lead to less quality issues and a more efficient use of API data, also contributing to the reduction of the time invested by competent national authorities in their interaction with carriers. 2.1.3.How likely is the problem to persist if no action is taken? Without EU action, the problem will continue to exist and is likely to exacerbate due to the increase of airline traffic and online check-in. This will deepen the fragmentation and discrepancies in the use of API data across Member States. Indeed, if the current rules continue to apply without change, Member States will retain discretion to implement national systems in different manners, leading to different practices as to the use of API data for the pre-checks at the Schengen external borders. This hampers the achievement of the objectives ultimately pursued, that is, improving external border controls. At the same time, this will also continue to represent a burden on carriers which are confronted with divergent requirements from EU Member States, linked to the lack of harmonisation and limitations in the implementation of the applicable API rules. 2.2.There are security gaps in the processing of air passenger data for law enforcement purposes 2.2.1.What is the problem? The combined use of API and PNR data is an effective tool for law enforcement authorities to detect terrorists and other serious criminals. However, due to the asymmetric material and geographic scopes of API and PNR Directives (see Annex 6), EU law does not ensure that this tool is as effective as it should be, leading to security gaps. More specifically, API data substantially increases the reliability and effectiveness of PNR data as a tool for the fight against serious crimes and terrorism in the EU. The joint processing of API data and PNR data enables the competent national authorities to confirm the identity of passengers. The joint processing of API data and PNR data also informs the competent national authorities whether a passenger has actually travelled and boarded a plane, thereby confirming the travel pattern of suspected individuals. The use of API data alone would be considered insufficient in the fight against serious crime and terrorism: information on the identity of a passenger without the reservation details (e.g. complete travel itinerary, accompanying passengers, date and modality of ticket reservation or contact details) would not allow establishing or proving links necessary for criminal investigations of serious crime and counter-terrorism cases. Conversely, based on Member States’ operational experience, API data – when collected in an automated way – contains information on the identity of the passenger that is more reliable than PNR data used in isolation. For example, on intra-EU flights where API data is not collected, a comparison of a passenger’s PNR data against a database such as the Schengen Information System can generate up to 40 ‘false-positive’ automatic matches due to the absence of personal identifiable information such as the date of birth. This prevents the competent national authorities from making effective use of passenger data for the fight against serious crime and terrorism. Moreover, booking information without reliable information on passenger’s identity would not allow competent authorities to determine whether a person has actually travelled, boarded a plane and made use of the booking. API data also helps confirming which booking was effectively used in cases where individuals suspected of serious crimes or terrorism offences made separate bookings (practice of ‘broken travel’ observed in drug trafficking and counter-terrorism cases). Consequently, only the joint processing of API data and PNR data enables Passenger Information Units, as set under the PNR Directive, to fully ‘capitalise’ on air passenger data to fight serious crime and terrorism effectively.

Under the current applicable EU legal framework, competent authorities are able to obtain effective operational results only on flights where both API and PNR data are collected, namely on extra-EU flights. Competent law enforcement authorities cannot benefit from the results of the joint processing of API data and PNR data for passengers travelling on flights within the EU for which PNR data is transmitted. This creates an important security gap in the processing of air passenger data. To address this gap, the European Commission’s strategy towards a fully functioning and resilient Schengen area of June 2021 identified the collection of API data on intra-EU flights as an additional means to enhance internal security without interfering with travel flows within the EU. 2.2.2.What are the drivers of the problem? At present, air carriers do not collect nor transmit API data on flights operating within the EU. The main driver for this problem is the current legal framework. The API Directive primarily regulates the processing of API data for external border management purposes, and therefore does not address the collection nor the transmission of API data for intra-EU and domestic flights. A collection of API data passengers for border management purposes on flights between Member States could amount to an internal border check, contrary to the Schengen Borders Code. Under the PNR Directive, on flights where API data is also collected by air carriers and therefore available in their systems, API data constitutes an element of the PNR data that air carriers transfer to the Passenger Information Unit. This is, however, only the case for those inbound and outbound flights where Member States request the transfer of API data under the API Directive. Consequently, air carriers do not collect API data for intra-EU and domestic flights and that data is not included in the PNR messages transferred for these flights. The API Directive does not prevent the processing of API data for law enforcement purposes as for provided in national legislation and subject to data protection requirements. However, the implementation of this possibility across Member States is problematic. –The evaluation of the API Directive showed that the law enforcement purpose is construed widely in national legislation, ranging from administrative offences, enhancing internal security and public order, to fight against terrorism and safeguarding national interests. The API Directive evaluation also indicated that an effective use of API data for law enforcement would require a dedicated legal instrument for this distinct purpose. –The variety of purposes for collecting API data adds complexity to ensuring compliance with the EU’s data protection framework. The requirement to delete API data within 24 hours is established only in the case of the use of API data for the main purpose of the Directive, namely external border management. It is not clear whether this requirement also applies in respect of processing conducted for law enforcement purposes. –The lack of criteria for the use of API data for law enforcement purposes, namely the API data set that can be requested from carriers for law enforcement purposes, since some Member States (on inbound and outbound flights) currently request API data going beyond the non-exhaustive list included in the API Directive, create additional hindrances for air carriers. –Likewise, the API Directive gives no indications of the flights for which API data can be requested nor to which authority API data should be transmitted or conditions of access to such data for law enforcement purposes. The lack of express EU-wide criteria on the use of API for law enforcement purposes leads to security gaps. 2.2.3.How likely is the problem to persist? Without action at EU level, the current situation where the use of the API data for law enforcement purposes is mainly left to national legislation will remain. Diverging practices as to the use of API for those purposes will continue to have an adverse impact on the levels of internal security in the EU, will continue to hinder air industry activities and potentially interfere with passengers’ protection of personal data. This will also continue to create challenges for air carriers having to comply with different obligations across the EU in terms of requirements to transmit API and PNR data. Air carrier associations expressed the wish to see the revision of the API Directive to clarify and harmonise the conditions for the collection of API data for law enforcement purposes. To compensate for a lack of identity information on passengers on intra-EU and domestic flights, certain Member States introduced so-called “conformity-checks” prior to boarding. These entail a visual comparison of the name and surname of the boarding pass against the name and surname of the travel document, at the gate, to ensure that the passenger is the holder of the travel document. Also as a means to offset the increasing use of online check-in on flights operated between Member States, conformity checks were introduced to address the issue of self-declared or ‘unverified’ nature of PNR data/reservation information and to increase certainty on who is boarding the plane. Implemented partly as an aviation security measure and partly as a measure to fight terrorism based on national law, conformity checks are an imperfect solution for several reasons. If implemented correctly, such checks only confirm the name and last name of a passenger. They do not allow the confirmation of other identity data (e.g. date of birth, number of travel document, gender). Conformity checks bring significant negative organisational impacts for air carriers, disturbing travel flows at airports where they are implemented (e.g. disturbing automated boarding processes, extension of boarding time, lack of technical solutions to change names at the boarding gate) as well as significant additional costs. 3.Why should the EU act? 3.1Legal basis As indicated in the 2020 evaluation of the API Directive, the effective use of API data for law enforcement purposes would require a dedicated legal instrument, i.e. an instrument separate from the current API Directive focusing on external border management. Thus, it appears a priori that, for legal reasons, two separate legal instruments would be required to regulate the processing of API data for external border management and for law enforcement as two distinct purposes. For the collection, transmission and use of API data for border management purposes, the legal basis would be the same as the one of the current API Directive, namely Articles 77(2)(b) and 79(2)(c) of Treaty on the Functioning of the European Union (TFEU). The instrument on the processing of API data for border management purposes would continue to be part of to the Schengen acquis. The API data would continue to be processed by the competent border authorities. For the collection and transmission of API data for law enforcement purposes, the legal basis would be the same as the one of the PNR Directive, namely Articles 82(1) (d) and 87(2)(a) of the TFEU. The API data would be transmitted to national authorities (Passenger Information Units) to complement and reinforce the processing of PNR data under the PNR Directive, which is not part of the Schengen acquis. Moreover, the collection and further use of API data for law enforcement purposes would be triggered by security needs and not by the crossing of borders as such. Consequently, the separate API legal instrument for law enforcement purposes would not be part of the Schengen acquis. The API data would be processed by the Passenger Information Units of these Member States, i.e. the units set up under the PNR Directive, by way of joint processing of API data and PNR data.

3.2. Subsidiarity: Necessity of EU action The principle of subsidiarity applies since this is an area of shared competence. According to the principle of subsidiarity laid down in Article 5(3) TEU, action at EU level should be taken only when the aims envisaged cannot be achieved sufficiently by Member States alone and can therefore, by reason of the scale or effects of the proposed action, be better achieved by the EU. Member States alone would not be able to effectively tackle the problems identified in chapter 2. The need for common rules on the processing of API data for border management is linked to the creation of the Schengen area and the establishment of common rules governing the movement of persons across the Schengen external borders (Schengen Borders Code). In this context, the decisions of one Member State affect other Member States, therefore it is necessary to have common and clear rules and operational practices in this area. Efficient external border controls require a coherent approach across the entire Schengen area, including on pre-checks with API data. Likewise, Member States alone would not be able to effectively tackle the problems related to the processing of API data for law enforcement purposes. Since the API Directive is a Schengen external border instrument, it cannot regulate the capture and transmission of API data on intra-EU and domestic flights. In absence of API data that would complement the PNR data for these flights, Member States have implemented a variety of different measures that seek to compensate the lack of identity data on the passengers. This includes physical conformity checks to verify identity data between travel document and boarding card (see section 2.2.3) that generate new issues without solving the underlying problem of not having API data. Action at EU level on API data would therefore be required to address effectively the problems identified in this impact assessment, in accordance with the principle of subsidiarity, as also called for in the June 2021 Commission’s Strategy towards a fully functioning and resilient Schengen area notably with regard to law enforcement purposes. In addition to the need to reinforce the Schengen area as a political priority of the Union, the need for EU action on API at this point in time also stems from recent legislative developlents on Schengen external border management: –The 2019 Interoperability Regulation will enable systematic checks of persons crossing the Schengen external borders against all available information in EU centralised information systems for security, border and migration management. Establishing a centralised transmission of API data at EU level is a logical continuation of this concept. –At the Schengen external borders, the use of API data would effectively complement the imminent implementation of the European Travel Information and Autorisation System (ETIAS) and of the Entry Exit System (EES) (see also annex 7). The use of API data would remain necessary for external border management as it informs border guards in advance whether a traveller has effectively boarded a plane and is about to enter the Schengen area, thus facilitating the border check that will take place once that traveller arrives at the Schengen external border. 3.3. Subsidiarity: Added value of EU action The Treaty on the Functioning of the European Union (TFEU) explicitly empowers the Union to develop a common policy on the checks to which persons crossing external borders are subject, this is a clear objective to be pursued at EU level. At the same time, this is an area of shared competence between the EU and the Member States. The 2020 evaluation showed that the API Directive has had a number of positive effects in those Member States that had established a national API system when implementing the Directive and request API data from air carriers. This would not have been realised by Member States acting alone. Using the international standards alone to establish national API systems in the Member States would have been possible without the API Directive but it may not have resulted in a coordinated outcome. However, as indicated in chapter 2, the evaluation of the Directive also showed that the EU legal current framework leads to inconsistent and diverging practices in the Member States on API data requiring further EU action in this area, including with a separate legal instrument on law enforcement. As illustrated by the effectiveness of existing EU instruments for external border management or law enforcement, such as the Schengen Information System, EU action can bring significant added value to Member States in these areas. Likewise, EU action in response to the problems identified in chapter 2 is expected to address these problems in an effective, efficient and proportionate manner, thereby bringing added value for the management of the Schengen external borders and for internal security in the Union. 4.Objectives: What is to be achieved? 4.1. General objectives Based on the problem analysis, the general objectives of this initiative are twofold: 1.To enhance Schengen external border management by ensuring that every person crossing the Schengen external border by air undergoes similar and necessary checks prior to entering or leaving the Schengen area. 2.To enhance the EU’s internal security by ensuring that Member States’ law enforcement authorities have access to air passenger data that is necessary to prevent and fight terrorism and serious crime. 4.2. Specific objectives Without overhauling the objectives of the current API Directive in terms of border management, the specific policy objectives of the initiative are: 1.To enhance pre-checks at the Schengen external borders: Collecting API data at Schengen external borders enables national authorities to cross-check passenger data systematically against information contained in national, EU and international databases, and to do so before a passenger actually arrives at the border crossing point. Receiving API data in advance will introduce efficiencies in the whole process of border checks, providing additional time for analysis of information and thus contributing to the reduction of false-positive matches. It helps border guards to better organise their work at border crossing points, and to better target operations where needed. 2.To facilitate the flow of bona-fide travellers at the Schengen external borders: API data facilitates the clearance of low-risk passengers. Better preparation for the control of specific passengers by identifying them via API data in advance of their arrival helps to accelerate border checks as passengers requiring secondary checks can be separated without the other passengers queuing and waiting, thus also reducing waiting times.

3.To effectively combat serious crime and terrorism with API data complementing PNR data: API data collected by automated means will uniquely and reliably identify a specific passenger that at some point in time is of particular interest for competent authorities investigating serious crime and terrorism. To allow for the joint processing of API data and PNR data as an effective tool to counter serious crime and terrorism, every PNR data transferred to Passenger Information Units should hence be complemented with complete and correct API data, while respecting the fundamental right to the protection of personal data and the fundamental right to freedom of movement. 5.What are the available policy options? This chapter sets out the available policy options, which include the baseline. The focus is on options requiring a regulatory intervention as the problems identified in this impact assessment are driven by the limitations of the current legal framework. A number of policy options were discarded at an early stage and are described below. 5.1.What is the baseline from which options are assessed? The baseline is a ‘no policy change’ scenario. With regard to API data collection for pre-checks at the external borders, the baseline scenario would maintain the current legal framework and provisions of the API Directive. Under the current Directive, air carriers have the obligation to send, upon request of the Member States’ authorities, API data on inbound flights crossing the Schengen external borders. Member States have the flexibility to collect API data on a list of selected incoming flights, following a risk-based approach. Therefore, not all Member States collect API data on all inbound extra-Schengen flights. Several Member States have extended the scope of API collection beyond the provisions of the Directive and also collect data for outbound extra-Schengen flights (see section 2.1). The API Directive contains only a minimum list of data elements that air carriers will have to transmit if requested by competent authorities, and Member States may request additional data other than those mentioned in the Directive. Accordingly, air carriers would continue to be faced with diverging requests and will continue to invest resources to comply with the different individual requirements set by Member States depending on the set up of their national API systems, with multiple transmissions of passenger data to multiple competent national authorities. In turn, national authorities will continue to invest ressources and individual connections with air carriers to effectively receive API data. Under the current legal framework, Passenger Information Units do not receive API data on selected intra-EU flights. 5.2. Description of the policy options Based on the problem definition and objectives described above, the available policy options can be grouped in three areas of intervention, namely: (1) scope of collection of API data for external border management, (2) scope of collection of API data for law enforcement purposes, and (3) a horizontal aspect on the means to improve the quality of data and the capturing of API that would apply to both purposes, i.e. external border management and law enforcement purposes. Given the need for two separate legal instruments for the processing of API data for external border management and for law enforcement as two distinct purposes (see section 3.1), the available options for each envisaged instrument need to be assessed separately. This is not only because the two separate legal instruments would have different purposes (external border management vs. law enforcement), different legal bases, different national authorities processing the API data (border authorities vs. Passenger Information Units) and different geographical scopes (see above). It is also because the different purposes of border management and law enforcement lead to different assessments in terms of necessity and proportionality of the envisaged intervention. The corresponding policy options are set out in Table 2 below. In addition, the initiative would have the following components that are technical and non-controversial in nature and therefore not assessed in this impact assessment: –As regards the types of flights, the initiative would cover all commercial flights, scheduled and non-scheduled (including charter flights and business aviation). –The collection of data would involve all passengers and crew members, regardless of their nationality. –A full set of API data would include identity information as contained in the travel document, as well as flight information, and seating and luggage information (see Annex 5). –API data would be transmitted through one single entry point at EU level (the carrier interface, see Annex 7).

5.2.1. Options concerning the scope of collection of API data for Schengen external border management There are two policy options for extending the scope of API data to enhance the management of the Schengen external borders: Policy option 1.1: API data collection on all extra-Schengen inbound flights This policy option provides for the systematic collection of API data on all extra-Schengen inbound flights for the purpose of Schengen external border management. This means there will be no prioritisation of flights or collecting API data on selected flights under this policy option. This policy option sets an obligation on Member States applying the Schengen acquis and on Schengen Associated Countries to collect and request API data on all flights coming from outside the Schengen area, in contrast to the current situation where the collection of API data is subject to risk and operational assessments by national authorities. Competent border authorities will use API data for pre-checks against the databases set out in the Schengen Borders Code. Therefore, under this policy option, air carriers would be obliged to collect and transmit API data for all extra-Schengen inbound flights. As the current 24-hour retention period of the data is too short for competent border authorities to carry out pre-checks effectively (e.g. due to long haul flights), this policy option would provide for the retention of API data by competent border authorities for 48h. Such retention would be proportionate because the data would not be retained for longer than what is necessary to carry out pre-checks. The processing of API data by air carriers and competent national authorities under this policy option would have to comply with the General Data Protection Regulation. Policy option 1.2: API data collection on all extra-Schengen inbound and outbound flights This policy option provides for the systematic collection of API data on all extra-Schengen inbound and outbound flights for the purpose of external border management. There would be no prioritisation of flights, or API data collection on selected flights, under this policy option. The API Directive neither requires nor excludes the possibility to collect API data on outbound flights. Some Member States already request API data on such flights for law enforcement purposes. Moreover, API data is collected by air carriers on certain outbound flights as such flights qualify as inbound flights for third countries requesting API data. Therefore, under this policy option, air carriers would be obliged to collect and transmit API data for all extra-Schengen inbound and outbound flights. The API data of all air passengers entering and leaving the Schengen area would be transmitted to competent border authorities for their processing. This policy option would therefore set a new obligation to Member States applying the Schengen acquis and on Schengen Associated Countries to collect and request API data on all flights entering and leaving the Schengen area. Competent border authorities would receive this data to check air passengers against those databases referred to in the Schengen Borders Code. The processing of API data air carriers and competent national authorities under this policy option would have to comply with the General Data Protection Regulation. 5.2.2. Options concerning the scope of collection of API data for law enforcement purposes The policy options set out in this section address the collection and transmission of API data for law enforcement purposes to allow for the joint processing of API data and PNR data. Consequently, these policy options align the purposes of API data collection to the purposes of the PNR Directive, namely to detect, investigate and prosecute terrorist offences – as defined in the Directive on combating terrorism and serious crime – as listed in Annex I of the PNR Directive. For these policy options, ‘law enforcement purposes’ refers to the prevention, detection, investigation and prosecution of terrorist offences and serious crimes. The scope of the policy options set out in this section is limited to regulating the collection of API data by air carriers and the subsequent transmission of the API data to competent authorities, namely the Member States’ Passenger Information Units (PIUs) set up under the PNR Directive. The Passenger Information Units that would receive and process the API data by way of joint processing of API data and PNR data in accordance wih the PNR Directive which already provides the Passenger Information Units with a legal basis to process API data they receive. The applicable rules on API data processing for the detection, investigation and prosecution of terrorist offences and serious crime, as well as the safeguards for the protection of fundamental rights, in particular the right the protection of personal data, would be those provided by the PNR Directive. Importantly, this would include the requirements and safeguards for the processing of data that the Court of Justice of the EU (CJEU) articulated in the Ligue des droits humains case in the light of the Charter of Fundamental Rights of the EU (‘the Charter’). Given the close interrelationship between PNR data and API data and the fact that the Court’s interpretation was mostly based on the Charter, the policy options set out in this section would be subject to the requirements articulated in this ruling. Given the sensitivities around the processing of API data for all extra-EU, intra-EU and domestic flights, this will be assessed in a dedicated policy option 2.2. Policy option 2.1: API data collection on all extra-EU inbound and outbound flights

This policy option provides for the systematic collection of API data on all extra-EU inbound and outbound flights for law enforcement purposes. This policy option sets an obligation on Member States to request and collect API data on all flights entering or leaving the EU. There would be no prioritisation of flights under this policy option. Therefore, under this policy option, air carriers would be obliged to collect API data for all extra-EU inbound and outbound flights and transmit it to the Passenger Information Units of the Member States concerned. Consequently, the API data of all air passengers entering or leaving the EU would be processed under this policy option. This policy option would ensure that API data is available to Passenger Information Units for the joint processing of API data and PNR data for all flights entering or leaving the EU, supporting them in their risk analysis of all travellers entering and leaving the EU. The collection of API data for law enforcement purposes under this policy option would be triggered by security needs – as reflected in the PNR Directire that requires the collection of PNR data for all extra-EU inbound and outbound flights – and not by the crossing of external borders. Consequently, for law enforcement purposes, extra-EU inbound and outbound flights can be assessed under one policy option. The processing of API data by air carriers under this policy option would have to comply with the General Data Protection Regulation Under this policy option, the subsequent processing of API data by the Passenger Information Units takes place under the requirements and safeguards set by the PNR Directive, as interpreted by the CJEU in the Ligue des droits humains case. Under this policy option, any subsequent processing of the data by national law enforcement authorities (other than the Passenger Information Units) would have to comply with the conditions for processing set in the PNR Directive and also with the the Law Enforcement Directive. Policy option 2.2: API data collection on all extra-EU inbound and outbound flights, intra-EU and domestic flights for which PNR data is collected This policy option provides for the collection of API data on all extra-EU flights, both inbound and outbound flights, and on selected intra-EU and domestic flights for law enforcement purposes, namely on those flights for which PNR data is collected under the PNR Directive. This policy option sets an obligation on Member States to request and collect API data on all extra-EU, intra-EU and domestic flights on which they collect PNR data. Consequently, when they select intra-EU and domestic flights for which they request air carriers to transmit PNR data, there would be a selection of flights under this policy option following the threat assessment that Member States have to carry out , in accordance with the requirements and safeguards of the PNR Directive in this regard, as interpreted by by the CJEU in the Ligue des droits humains case in the light of the Charter. Therefore, under this policy option, air carriers would be obliged to collect API data for all extra-EU flights, intra-EU and domestic flights for which they transmit PNR data, and transmit that API data to the Passenger Information Units of the Member States concerned. Consequently, only the API data of air passengers on these selected flights intra-EU and domestic flights would be processed. This policy option would ensure that API data is available to Passenger Information Units for the joint processing of API data and PNR data for all extra-EU, intra-EU and domestic flights for which Member States already collect PNR data in accordance with their risk assessments. More specifically, the collection of API data on intra-EU and domestic flights would be triggered by security needs, i.e. the same security needs that made Member States apply the option of PNR data processing for intra-EU and domestic flights under the PNR Directive. It should be clear that the collection of API data under this policy option would not be triggered by the crossing of internal borders in the absence of internal border checks, since it would apply both to selected intra-EU and domestic flights. The policy option would be consistent with the December 2021 proposal to revise the Schengen Borders Code which clarifies that the Schengen Borders Code would not prevent the use of passenger data such as API data for pre-checks against databases on passengers for security purposes on connections between Member States in case this would be allowed by applicable law. The processing of API data on intra-EU and domestic flights by air carriers under this policy option would have to comply with the General Data Protection Regulation. Under this policy option, the subsequent processing of API data by the Passenger Information Units takes place under the requirements and safeguards set by the PNR Directive, as interpreted by the CJEU in the Ligue des droits humains case, notably what is specified in that case regarding the processing of PNR data for intra-EU flights (see box 2 below). Under this policy option, any subsequent processing of the data by national law enforcement authorities would have to comply with the conditions for processing set in the PNR Directive and also with the the Law Enforcement Directive. Box 2: The collection of PNR data on (all or selected) intra-EU flights In the recent Ligue des droits humains case, the the CJEU considered that the (possible) collection of PNR data on intra-EU flights by Member States should not go beyond what is strictly necessary: - PNR data collection on all intra-EU flights is only possible where a Member State establishes that there are sufficiently solid grounds for considering that it is confronted with a genuine and present or foreseeable terrorist threat. Such collection should be limited in time and the decision taken by a Member State to collect PNR data on all flights must be open to effective review (by a court or by an independent administrative body). - in the absence of a genuine and present or foreseeable terrorist threat, Member States may not collect PNR data on all intra-EU flights. In such cases, PNR data collection PNR data collection for those flights is possible on selected intra-EU flights relating, for example, to certain routes or travel patterns or to certain airports for which there are, according to the assessment of the Member State concerned, indications that would justify that application. Data collection on selected intra-EU flights should also be regularly reviewed by the Member State in accordance with changes in the circusmstances that justified their selection. 5.2.3. Options concerning the quality and capture of API data The policy options sets out in this section provide horizontal means to improve the quality and capturing of API data that would apply to the collection of API data on any applicable flight and for any purpose, thus affecting both the collection of API data for Schengen external border management and and the collection of such data for law enforcement purposes. A first step to improving the quality of API data is to make it compulsory for air carriers to collect the same complete set of API data elements. This initiative would therefore introduce a closed list of API data, mandatory on all flights where API data is requested. This is to align the API data elements to the identity data found in the Machine Readable Zone (MRZ) of a passport, the default travel document, or an identity card (see box 3). Box 3 : Machine Readable Zone (MRZ) The MRZ is an ICAO standard that enables cameras to take a picture of these ‘precise black’ characters and transform them into a digital format, a process known as Optical Character Recognition (OCR). When successfully using OCR, the data is correct and complete. EU rules for the issuance of passports and travel documents by Member States provide that these documents must contain a machine-readable biographic information, in compliance with ICAO standards. In addition, the Regulation on the strengthening the security of identity cards of Union citizens and of residence documents issued to Union citizens and their family members provides that identity cards issued as of 2023 shall also contain a machine readable zone on national identity cards issued to EU citizens.

Policy option 3.1: API data collection by either automated and manual means This policy option provides for measures to improve the quality of API data by clarifying by which methods API data would be captured. This would entail the capture of API data from the MRZ through automated means, such as devices using technologies (e.g. OCR). Where other travel documents have been used, such as national identity cards, collection of API data could also be considered, provided they have an MRZ as per ICAO standards. This policy option therefore foresees a range of methods to capture API data: –Scanning the MRZ: For passengers agreeing to do so, online check-in would imply passengers using electronic devices to scan the MRZ of their travel document. More specifically, the passenger would use a secure app on a smartphone or webcam to take (a) picture(s) of the travel document during the on-line check-in process. The carrier’s IT-systems would perform the OCR and transmit complete and correct identity data as part of API message. –Provision of API data at the airport: For those passengers not wanting or not being able to use the above method during on-line check-in, the travel document’s MRZ would be read by a member of staff by automated means during check-in or boarding at the airport, or by automated means at a self-service kiosk at the airport, without any additional fees for such service. –Online or web-check-in: Those passengers not wanting or not being able to use the above-mentioned methods would still be able to enter manually their data. Consequently, this policy option provides for the establishment of clearer definition of data quality thresholds, which, if detected and unmet, would result in financial sanctions for the air carriers. Each of these different methods would imply different levels of carrier liability and therefore different levels of sanctions. For instance, the level of data accuracy and completeness is higher where data is collected by automated means involving a scan of the travel document’s MRZ, therefore resulting in less missing data fields or errors inducive of sanctions. Policy option 3.2: API data collection by automated means only Compared to the previous policy option, this policy options provides for mandating automated collection of API data only: –Scanning the MRZ: For passengers agreeing to do so, online check-in would imply passengers using electronic devices to scan the MRZ of their travel document. More specifically, the passenger would use a secure app on a smartphone or webcam to take (a) picture(s) of the travel document during the on-line check-in process. The carrier’s IT-systems would perform the OCR and transmit complete and correct identity data as part of API message. –Traditional check-in at the airport: For those passengers not wanting or not being able to use the above method during on-line check-in, the travel document’s MRZ would be read by a member of staff by automated means during check-in or boarding at the airport, or by automated means at a self-service kiosk at the airport, without any additional fees for such service. The possibilities of manual entry at check-in and online manual self-declaration of API data by the passenger would be eliminated. Traditional assisted airport check-in would still be possible for passengers not wanting or not able to use electronic devices to scan the MRZ. Air carrier staff performing the check-in at the counter would have to be equipped with MRZ scanners or other solutions to ensure the automated collection of the MRZ. This policy option would mean that no fines could be imposed by national authorities on air carriers for errors in the collection of API data. Where air carriers collect API data exclusively by automated means, there are no possibilities of errors in that collection. 5.3.Policy options discarded at an early stage Following the stakeholder consultations and the activities carried out in preparation of this impact assessment (Annex 2), the following options were discarded. 5.3.1. API data collected on transit flights for advanced border checks As opposed to direct flights, transit (or connecting) flights enable passengers to reach the final destination through two or more flights, after a brief stop-over at the airport. One single ticket is issued and the passenger does not change planes or airlines. In such cases, the advance passenger data is sent by the air carrier to the final destination country that will effectively perform the entry border check of passengers. For example, a flight from New York to Ankara with a stop in Frankfurt, will not lead to API data being delivered to Germany. The passenger would not enter the Schengen area in Frankfurt and would not undergo an entry check at the external borders. 5.3.2. API data transmitted for law enforcement purposes on all intra-EU flights

This option would create a new obligation on Member States to systematically request API data on all intra-EU flights for law enforcement purposes, including on flights where PNR data would not be processed by Member States. On those flights where no PNR data is processed, the added value of processing API data alone for law enforcement purposes would be limited (see also section 2.2). In addition, considering the requirements and safeguards articulated in the recent in the Ligue des droits humains case, the transfer of API data on all intra-EU flights would be a serious interference with passengers’ fundamental right to the protection of personal data (Article 8 of the Charter) that would only be justified in the situation of a genuine and present or foreseeable terrorist threat. In the absence of such a threat, the transfer of API data on all intra-EU flights would therefore not meet the necessity and proportionality requirements. Moreover, the Court also provided guidance on the fact that the collection of PNR data linked to cross-border travel within the EU could deter the exercise of the fundamental right to freedom of movement (Article 45 of the Charter) and therefore constitute a restriction of that freedom. Considering this guidance, the transfer of API data on all intra-EU flights would not be compliant with the freedom of movement. While the idea of transmitting API data on all intra-EU flights was discussed with stakeholders during consultations, this policy option must be discarded following this ruling. 5.3.3. API data collected from other means of transport (maritime, rail, bus) The Schengen Borders Code provides that, as regards maritime operators, crew and passenger information must be transmitted by maritime carriers to border authorities as a list containing the information required in the FAL form 5 (crew list) and FAL form 6 (passenger list) of the Convention on Facilitation of International Maritime Traffic (FAL Convention), as well as visa or residence permit numbers, where applicable. These data must be transmitted at least 24 hours prior to the scheduled arrival of the vessel. Therefore, EU and international obligations already exist on maritime transport operators to collect and transmit in passenger information in advance to border authorities of Member States on incoming and outgoing routes. In this context, any additional requirement to transmit ‘API’ data in a separate instrument, would be redundant and create considerable burden on maritime operators. Contrary to air and maritime transport sectors, there are no international standards nor EU obligations for the collection of passenger data from land transport operators such as rail or bus. Rail transport has specific characteristics in terms of infrastructure, passenger journey and density of networks. Such observations can also be extended to the bus transport sector, composed of a variety of small to medium sized companies. Compared to the air transport sector, the collection of passenger data is more challenging as the issuing of nominative tickets is not a standard practice. To introduce a systematic collection and use of API data for rail and/or bus transport would require heavy investments in the physical infrastructure of operators, with substantial consequences on their economic model and on passengers. At national level, some Member States have implemented, based on national law, requirements to collect passenger data on rail connections with third countries. Such national practices will not be affected by this initiative. 5.3.4. API data collected for contact tracing for health purposes The recent COVID-19 pandemic led to reflecting how passenger data could support the protection of public health and prevent the spread of infectious diseases. During stakeholder consultations carried out for this impact assessment (see Annex 2), the Commission services explored opportunities to expedite the cross-border contact tracing of passengers and therefore create synergies with other instruments under which air carriers communicate passenger data to national authorities, including API and PNR Directives. For contact tracing purposes, information from passengers including contact details such as phone number(s), email address, or a physical address are the relevant data elements that are required to ensure necessary follow-up actions by the authorities. Among the collection of passenger data regulated at EU level, PNR data contain information that may help tracing routes of passengers coming from risk areas and track passengers that have been sitting in the proximity of infected passengers thanks to the availability of seat and other contact information in the PNR data set. However, the PNR Directive currently allows the processing of PNR data only for the fight against terrorism and serious crime, with no exceptions, as confirmed by the recent judgment of the CJEU in the Ligue des droits humains. As a tool allowing to identify passengers, API data will not contain contact details of passengers. A possible future revised PNR instrument could conceivably contribute to contact tracing to the extent that this is seen as operationally justified and legally and technically possible. That would have to be assessed separately. 6.What are the impacts of the policy options? This chapter assesses the impact of the policy options identified in section 5.2 against a series of categories, in line with the Better Regulation Guidelines. The baseline scenario is unsuited to address the problems identified in chapter 2, and will therefore not be further assessed. The social impacts assessed in this chapter focus on implications for the security for both the EU and travellers and on impacts on travel facilitation. Where applicable, and in addition to the specific assessment of the impact on the fundamental right to freedom of movement (see below), the section on social impacts will include an assessment of the practical implications of the collection of API for intra-EU and domestic flights on the exercise of free movement and compliance with the free movement acquis. The economic impacts of the policy options assessed in this chapter will concern impacts on national authorities and air carriers. The selected impacts are assessed quantitatively and qualitatively based on a number of key assumptions (see annexes 3 and 4). The costs will fall to the EU budget and Member State authorities operating the systems. The proposed measures are not expected to have a significant impact on small and medium sized enterprises. This chapter also assesses the policy options in terms of their impact on the exercise of fundamental rights protected by the Charter, with a focus on the right to the protection of personal data as guaranteed by Article 8 of the Charter. This chapter also addresses other fundamental rights enshrined in the Charter, namely the right to freedom of movement (Article 45), the freedom to conduct a business (Article 16), the right to an effective remedy (Article 47) and non-discrimination (Article 21). No significant environmental impacts are expected from this initiative. The initiative is not expected to have an impact on the volume of air travel. The identified policy options will as such not affect the emissions of greenhouse gases in the atmosphere by air transport operators, or the anticipated demand for air passenger transportation. 6.1.Social impacts The social impacts of the initiative are twofold: (a) there are important (positive) implications for external border management and hence for security in the EU at large, and (b) there is an impact on the speed and convenience of travelling and more broadly on air travel facilitation.

Policy option 1.1 – API data collection for border management purposes on all extra-Schengen inbound flights This option would ensure that all travellers are pre-checked in a consistent way upon arrival at external borders. This would positively impact external border management and hence security in the EU at large, as it permits the identification of passengers who would not be allowed to enter the territory of a Member State and/or using false travel documents. Complementing the implementation of the European Travel Information and Authorisation System and of the Entry Exit system, where air carriers need to determine whether a third country national holds the necessary authorisations to enter the Schengen area (see section 3.2), API data is the tool which informs border guards in advance whether a traveller, regardless of its nationality, is about to arrive at the Schengen external border by air travel. It provides competent border authorities with a tool to effectively and efficiently cross-check all passengers by organising in advance their border control activities, thus facilitating and accelerating the entry of all passengers to the Schengen area. Policy option 1.2 – API data collection for border management purposes on all extra-Schengen inbound and outbound flights This option would ensure that all travellers are pre-checked in a consistent way upon arrival and upon departure from the Schengen area. Collecting API data on passengers entering and leaving the Schengen area would have a limited impact on external border management. More specifically, collecting API data on passengers leaving the Schengen area would not have an impact on external border management as these passengers would have passed the Schengen external border check at the moment of transmission of API data. Consequently, the impact on travel facilitation would be neutral (the positive effects of the entry of passengers on inbound flights counterbalanced by the limited facilitation of passengers of this policy option on outbound flights). Policy option 2.1 - API data collection for law enforcement purposes on all extra-EU inbound and outbound flights This option would have a strong positive impact on the robustness of the EU internal security architecture. Making high quality, verified API data systematically available to Passenger Information Units on all extra-EU inbound and outbound flights would boost the effectiveness of their PNR processing and enhance considerably the fight against serious crime and terrorism. The joint processing of API data and PNR data would provide a tool for law enforcement authorities to track the movements of known suspects and to identify suspicious travel patterns of unknown individuals who may be involved in criminal and terrorist activities. This would close an important gap in the use of passenger data for law enforcement purposes and complement the PNR Directive. In terms of passengers' convenience and travel facilitation the impact of this option is neutral. Policy option 2.2 - API data collection for law enforcement purposes on all extra-EU flights, intra-EU and domestic flights for which PNR data is collected By closing a gap on intra-EU and domestic flights where the absence of API data undermines the reliability of PNR data processing in the fight against serious crime and terrorism, this option would represent an important contribution to the EU’s internal security. It would again boost the quality and effectiveness of PNR processing (up to the extent that this is applied by Member States for intra-EU and domestic flights), much more effectively than the implementation of ‘conformity checks’ by individual Member States (see section 2.2.3). As no consistent security checks on intra-EU and domestic flights are being performed today due to the absence of API data on those flights, this option would address a very important security gap, and would have a very significant positive impact on internal security. Notably, it would allow for the combined processing of API and PNR data on selected intra-EU and domestic flights as an effective tool to counter serious crime and terrorism, providing a tool for law enforcement authorities to track the movements of known suspects and to identify suspicious travel patterns of unknown individuals who may be involved in serious criminal and terrorist activities when they travel within the EU. This would close an important security gap in the use of passenger data for law enforcement purposes and complement the PNR Directive which allows Member States to collect PNR data on selected intra-EU and domestic flights. As API data is currently not collected for intra-EU and domestic flights, this option would have an impact on travel convenience and facilitation. This impact is however limited. The (self-) capturing of API data is an integrated component of the check-in process, which takes very little effort and time, especially when supported by automated means (see policy options 3.1 and 3.2). In that respect, the practicalitites of the (self) capturing of API data must be designed in a way that mitigates any risk of a chilling effect on the freedom of movement. To that end, passengers not willing or able to scan their travel document electronically must have the possibility to provide their API data at a check-in desk, a self-service kiosk or during boarding at the airport see option 3.2 below). Policy option 3.1 - API data collection by either automated or manual means As regards impacts on security, this option represents a potential improvement as compared to the baseline scenario. Manual entry of data from travel documents during online check-in would continue to be possible, leading to a continued probability of mistakes being made. In terms of passengers’ convenience and travel facilitation, this option provides travellers with a full range of solutions to accommodate different levels of digital literacy, allowing them to collect information contained in their travel document in various ways. Policy option 3.2 - API data collection by automated means only This option would have a clear positive impact on security, as the collection of API data through automated means only would significantly increase the accuracy and completeness of data received by the authorities. Under this option travellers would no longer be able to manually insert their API information during online or web-check-in. This would however be mitigated (for those passengers not willing or able to scan their travel document electronically) by the possibility to provide their API data at a check-in desk, a self-service kiosk or during boarding at the airport, hence mitigating any risk of a chilling effect on the freedom of movement. 6.2. Economic impacts When assessing the economic impacts of the initiative a distinction is to be made between (1) the impact on Member States, and (2) the impacts on air carriers. Assumptions and calculations underpinning the assessment presented in this section are presented in more detail in Annex 4. Policy option 1.1 – API data collection for border management purposes on all extra-Schengen inbound flights The economic impact of this option on competent authorities in Member States applying the Schengen acquis and the Schengen Associated Countries would depend on the number of routes that national API systems already cover. This situation varies greatly between Member States. Also, the size of a Member State, the number of airports and the overall volume of inbound flights would influence the costs of this option for a specific Member State. Either way, national API systems would need to be modified to receive and process additional data flows that were not previously collected, such as passenger data from charter and business flights. A quantification of these additional costs and upgrades of existing systems is very difficult (Member States were unable to provide estimates when requested). Based on available estimates for setting up national API systems, the costs for necessary adaptations to deal with an increased volume of API data for inbound flights can however be estimated at an average EUR 0,5 million per Member State, or EUR 13,5 million in total.

As for the costs for air carriers, the starting point is that commercial air carriers transporting passengers to the EU are already requested to send API data on most flights. Most large commercial airlines already have the capacity to collect such data via automated means, systems or applications. In contrast, those operating non-scheduled flights (charter flights and business aviation) may not be equipped with IT systems to systematically collect API data. However, solutions such as collecting and transmitting API data via web applications are currently being used and made available by national authorities. As explained in Annex 4, one of the main cost elements for air carriers lies in the transmission costs of API data. An obligation to transmit API data systematically on all inbound flights represents an increase in the volume of data transmitted and therefore result in additional costs of transmission of API data. At present, air carriers can be requested to transmit API data twice: to competent border authorities and to Passenger Information Units. With this initiative API data would be transmitted to a single point, namely the carrier interface accompanied by an API router, which would substantially reduce the transmission costs for air carriers. Accordingly, the net additional annual API transmission costs for air carriers on inbound flights for border management purposes would in future be lower than today. Whereas currently API data is transmitted for around 65% of inbound travellers, twice, under this initiative this would be done for 100% of passengers, but only once. This results in a net saving for the airline industry of EUR 2,53 million per year. Policy option 1.2 – API data collection for border management purposes on all extra-Schengen inbound and outbound flights Like for option 1.1, the economic impact on competent authorities in Member States applying the Schengen acquis and the Schengen Associated Countries would depend on the number of routes that national API systems already cover, and therefore the overall volume of outbound flights from the country concerned in addition to the inbound flights. Most Member States do not yet collect API data on outbound flights (see Chart 1). Building on similar estimates as used for option 1.1, the costs for necessary adaptations by Member States for collecting and processing API data on outbound flights would be an average of EUR 2 million per Member State, or EUR 54 million in total. These costs would add up to the estimates for collecting an processing API Data on inbound flights, therefore the total costs for Member States’ authorities would amount to a total of EUR 67.5 million. Regarding the economic costs of this option for air carriers, it must be born in mind that the EU’s outbound flights are inbound flights for third countries, for which API is already being collected, or will be collected soon, in line with international obligations. In practice, the burden for acquiring API data for these flights is therefore already present for air carriers and is not different than for acquiring API data on inbound flights. As for the actual transmission of this data to competent border authorities and to Passenger Information Units on both inbound and outbound flights , this initiative would incur costs on air carriers. As under option 1.1, this would be partly offset by the introduction of the carrier interface accompanied by an API router. The net actual transmission costs for air carriers on inbound and outbound flights for border management purposes is estimated at EUR 1.68 million per year. Policy option 2.1 - API data collection for law enforcement purposes on all extra-EU inbound and outbound flights The national authorities set to use API data for law enforcement purposes on all extra-EU flights are the Passenger Information Units, which are established in all Member States. These authorities already receive and process API data as a PNR complement on all flights for which such data is being collected under national legislation. The proposed initiative measures would increase the volume of API data processed, but as this is part and parcel of PNR data processing the associated costs cannot be calculated. However, as the API data-set is smaller than the PNR data-set currently processed by PIUs on extra-EU and intra-EU flights, the assumption is that PIUs would incur only a negligible amount of additional costs. This option would only produce an net cost of EUR 4,21 million for air carriers in the case that 1.1 is retained. In the case option 1.2 is chosen as API data would have been already collected and transmitted for border management purposes on inbound and outbound flights no cost is incurred. Policy option 2.2 - API data collection for law enforcement purposes on all extra-EU, intra-EU and domestic flights for which PNR data is collected Like under option 2.1, the recipients of API data collected on all extra-EU (both inbound and outbound flights) and on intra-EU flights would be the Member States’ Passenger Information Units (PIUs). As API data is not being collected today on selected flights within the EU, the proposed initiative would effectively lead to an increase of the amount of API data that would be received and would need to be processed. However, as this processing is again part of PNR data and the associated cost for this increased data handling would therefore be very small, if not negligible. Commercial airlines do not currently collect nor transmit API data on intra-EU flights. This means that under this option air carriers may need to bring changes to their IT systems in order to be able to do so. This applies notably to the air carriers that exclusively operate within the EU. The corresponding total costs for the industry are estimated at EUR 75 million. In case it would be decided by airlines to pass these costs on passengers, this would correspond to a price increase of 5 cents of the plane ticket, if spread over a period over three years. In addition to these one-off investment costs, this option would also involve transmission costs for air carriers. Net transmission costs of information exclusively transmitted for law enforcement purposes for all extra and intra EU as well as for domestic flights depend on the option chosen for border management purposes. They are estimated at EUR 20,35 million per year in case option 1.1 is chosen (EUR 16.14 million recurrent costs for the transmission of API data on intra-EU and domestic flights and EUR 4.21 million recurrent costs on outbound flights), and at EUR 16,13 million in case option 1.2 is chosen. If airlines would shift this transmission cost to consumers it would increase the ticket price by 1,8 cents (see annex 3). Policy option 3.1 - API data collection by either automated or manual means Under this option, national authorities of Member States – both border management authorities and PIUs – would benefit from the improved API data quality and harmonisation of data sets: more accurate data would lead to more efficient processes and cross-checks against other databases. The economic impact can therefore be rated as positive, albeit it is impossible to quantify this in financial terms. As regards the impact on airlines, they could – under this option – chose to bring modifications to their online check-in systems if they wish to collect API data using automated means. Under this policy option, they would however still be subjected to fines in case of erroneous transmissions. The total amount of potential sanctions incurred by air carriers in the EU is estimated at up to EUR 80 million per year. Policy option 3.2 - API data collection by automated means only As explained in the section on social impacts, this option is expected to cater for an even higher level of data quality than option 3.1. As the probability of errors in the transmission of API data would be significantly reduced, Member States’ authorities would likely need less (human) resources to check the quality of the data and save time in engaging with air carriers for fines. The again justifies a positive (and actually higher) economic rating, without however being able to quantify this.

Under this option airlines would be obliged to make available online check-in systems and collect API data, using automated means only. Many airlines have already put such systems and functionalities in place, yet further investments may still be needed to further roll out this approach throughout the organisation. Other airlines may still need to make modifications and adaptions to their systems. Whereas the costs of the required efforts may therefore be unevenly distributed between airlines, it is estimated that the required one-off costs for the industry as a whole is in the range of EUR 50 million. Collecting API data with automated means only also generates important savings for the airline industry. It would increase the efficiency of their passenger handling workflow, thereby reducing the accompanying costs. It would also reduce the risk for air carriers to be exposed to sanctions for non-compliance and transmission of erroneous data. As mentioned above, these fines could correspond to a maximum amount of up to EUR 80 million per year. Airline industry* One-off Recurrent Member States One-off Recurrent eu-LISA One-of Recurrent Option 1.1** Inbound extra-Schengen flights 0 – 2,53 13,5 0 34 1.4 Combined with… Option 2.1 inbound and outbound extra-EU flights 0 4,21 0 0 Option 2.2 inboud, outbound extra-EU and intra-EU and domestic flights 75 20,35 0 0 Option 1.2** Outbound extra-Schengen flights 0 1,68 67.5 0 Combined with… Option 2.1 inbound and outbound extra-EU flights 0 0 0 0 Option 2.2 inboud, outbound extra-EU and intra-EU and domestic flights 75 16,13 0 0 Option 3.1 0 n.a. n.a. n.a n.a n.a. Option 3.2 50 n.a. n.a n.a. n.a n.a. * Due to limited availability of data, the assumptions and calculations include costs for both scheduled and non-scheduled air carriers. ** ** The reported net costs of the different policy options for law enforcement (2.1 and 2.2) depend on the choice made for border management (1.1 or 1.2.) Therefore both options 2.1 and 2.2 are reported twice: once under the option 1.1, and a second time under option 1.2. For instance, if option 1.2 and option 2.2 were chosen, net costs for the airline industry would amount to EUR 1,61 million for border management and EUR 27,05 million for law enforcement. 6.3. Fundamental rights, including the protection of personal data The policy options described in section 5.2 provide for the processing of personal data of passengers and hence limit the exercise of the fundamental right to the protection of personal data as guaranteed by Article 8 of the Charter and Article 16 of the TFEU. As underlined by the CJEU, the right to the protection of personal data is not an absolute right, but any limitation must be considered in relation to its function in society and comply with the criteria set out in Article 52(1) of the Charter. Personal data protection is also closely linked to respect for private and family life protected by Article 7 of the Charter. Policy option 2.2 provides for the collection of data linked to cross-border travel within the EU, and hence could deter the exercise of the right to freedom of movement as guaranteed by Article 45 of the Charter. As with the right to the protection of personal data, any limitation of the exercise of the right to freedom of movement must comply with the criteria set out in Article 52(1) of the Charter. Furthermore, account should be taken of the freedom to conduct a business, enshirened in Article 16 of the Charter, wherer policy options 2.2, 3.1 and 3.1 would impose new obligations on air carriers that could deter the exercise of their freedom to conduct a business. This, too, is a fundamental right the exercise of which may be limited in accordance with Article 52(1) of the Charter. Consequently, in so far as they limit the exercise of fundamental rights such as those mentioned above, the policy options need to comply with the conditions set out in Article 52(1) of the Charter. The opportunities offered by the policy options presented need to be balanced with the obligation to ensure that any limitation of the exercise of fundamental rights that may derive from them respects the essence of those rights and remains limited to what is strictly necessary to genuinely meet the objectives of general interest recognised by the EU pursued, subject to the principle of proportionality. Both the objectives of ensuring effective border controls and of effectively combating serious crime and terrorism are objectives of general interest within the meaning of Article 52(1) of the Charter. Furthermore, there is no reason to consider that the essence of the fundamental rights at stake would not be respected. Accordingly, this chapter will assess the policy options focusing on the requirements of necessity and proportionality. Policy option 1.1 – API data collection on all extra-Schengen inbound flights Right to the protection of personal data Necessity: The obligation to collect and process API data on all inbound flights to the Schengen area would effectively respond to the objective of ensuring that pre-checks are carried out on all air passengers travelling to the Schengen area. In terms of alternative approaches, the collection of API data for external border management based on national risk assessments – i.e. only on selected flights – would be less intrusive on the right to the protection of personal data as less data subjects would be affected. However, this approach would not respond effectively to the objective pursued to enhance pre-checks at external borders as it would risk missing out on hits, alerts or other security threats at external borders. Non-legislative measures such as recommendations or best practices would also not be an effective means to achieve the objective as the current framework does not oblige Member States to collect API data. Consequently, the policy option is limited to what is strictly necessary to achieve the above mentioned objective. It covers all passengers crossing the external borders upon entry to respond to the need for a coordinated approach to the management and security of external borders. While no decisions will be taken by competent border authorities solely based on API data or the results of the cross-checks with other databases, this policy option effectively enables border authorities to organise their activities in advance and facilitate the entry of bona fide passengers. To do so, API data collected must be limited to information contained in the passenger’s passport, all of which are necessary to carry out pre-checks upon arrival at the borders against those databases set out in the Schengen Borders Code. Proportionality: This policy option affects all passengers who are travelling by air to the Schengen area. This constitutes additional data subjects affected compared with the current situation where API data is collected only on a share of those passengers. The policy option does not impose a disproportionate burden on the persons affected by this option. The interference with the right to the protection of personal data is limited to what is strictly necessary to achieve the objective of pre-checks of persons prior to their arrival at external borders.. Limiting the passenger’s identity data to information contained in the passenger’s passport constitutes an important safeguard and an improvement to the current rules which allow for additional data to be collected from passengers. Policy option 1.2 – API data collection on all extra-Schengen inboud and outbound flights Right to the protection of personal data

Necessity: This option would address an objective of general interest, namely to enhance EU border management by ensuring that every person crossing the Schengen external borders – at arrival and departure – is pre-checked. However, as the full API data set is generated once the passengers are on board of a plane, on outbound flights, the border guards would only receive the API data after the physical exit checks of the travellers and examination of their passports, and hence too late to support the work of the border guards. Consequently, the policy option does not effectively respond to the objective. As a result, the policy option does not pass the necessity test, and will therefore not be assessed in terms of its proportionality. Policy option 2.1 – API data collection for law enforcement purposes on all extra-EU inbound and outbound flights Right to the protection of personal data Necessity: This policy option is genuinely effective to achieve the specific objective of effectively fighting serious crime and terrorism and hence enhance internal security, as it allows for the joint processing of API data and PNR data for flights entering and leaving the EU. In doing so, this policy option improves the quality of the data processed by Passenger Information Units and hence significantly reduces the risk of false matches due to data quality issues. This option also provides additional legal certainty regarding the criteria for the collection and transmission of API data for law enforcement purposes. The purposes of the processing of API data would be for the prevention, detection, investigation and prosecution of serious crimes as defined by the PNR Directive. This requires the processing of the same set of API data as those collected for border management purposes, i.e. information contained in the passenger’s passport, as this data is necessary to identify the traveller and to confirm the travel and flight details. Alternatives to this policy option would be less effective to achieve the objective of fighting serious crime and terrorism with API data complementing PNR data. The collection of API data only on selected extra-EU flights would imply that competent law enforcement authorities would not be able to combine API and PNR data for all passengers, thus maintaining the risk of security gaps on flights coming to or departing from the EU. Consequently, this policy option is limited to what is strictly necessary to achieve the above mentioned objective. Proportionality: This policy option provides uniform criteria for the collection and transmission of API data for law enforcement purposes on EU inbound and outbound flights, responding effectively to a need identified in section 2.2 and solving part of the problem resulting from the absence of EU-wide rules on the collection and use of API data for law enforcement purposes. To limit the interference of this policy measure on the rights of passengers to what is strictly necessary, a number of safeguards are required: First, the processing of API data by Passenger Information Units must be restricted to a closed and limited list of API data from air carriers to fight terrorism and serious crime, i.e. to the data contained in the passenger’s passport. Beyond that, no additional identity data shall be collected from passengers. Second, the further processing of the API data by the Passenger Information Unit, by way of joint processing of API with PNR data, must comply with the provisions of the PNR Directive as interpreted by the ruling of the CJEU in the Ligue des droits humains case, including on the retention period of the data, access to data and safeguards on the processing of data when cross-checked with other databases. Weighing up the intensity of the interference with the fundamental right to the protection of personal data with the legitimacy of the objectives to fight agains