Challenges and opportunities of passenger data systems
Physical inspection of a traveller and a travel document is nowadays only part of the border controls on passengers arriving by air, or any other means of transport. In an increasing number of countries, the rest of the border control process relies on secure electronic data sent before the arrival of the passenger in the country of destination.
It all began in July 1988, when the United States (US) government invited, for the very first time, representatives from the airline industry to come together to discuss a new idea – that providing them with information about passengers while the flight was en route would not only enable relevant border agencies to perform risk-based targeted controls on passengers and the goods being carried, but also enable the flight to be processed effectively.
This resulted in the first voluntary transmission of advanced passenger information (API) on flights from Tokyo to San Francisco, Honolulu and Los Angeles in the summer of 1990. API consists of the traveller’s full name, gender, date of birth, nationality, country of residence, type of travel document, and the travel document number.
Following the 11 September 2001 terrorist attacks on US territory, the US and other countries deemed it necessary, in order to combat terrorism and serious crime, to go beyond the API requirements and require airlines to also transmit what is known as Passenger Name Record (PNR) data – the generic name given to records created by aircraft operators or their authorized agents for each journey booked by or on behalf of any passenger. PNR data can contain significant amounts of personal data, including full names, addresses, phone numbers and email addresses, travel itineraries, and more.
After the uptake of API implementation around the world in the 1990s and PNR in the 2000s, governments and industry working together developed standards on data requirements and data transmission procedures to respond to the danger of non-uniform implementation of passenger information systems.
Among other things, a patchwork of various approaches to passenger data exchange requirements and data transmission procedures was seen as creating delays, threatening the ability of transport operators to comply with national legislation, and leading to the unnecessary expenditure of hundreds of millions of US dollars as these operators sought to modify their systems to respond to non-harmonized programme requirements.
Despite the efforts to achieve harmonization, with the rapid proliferation of the use of advance data transmission around the world came a multiplication of systems and requirements; some were standardized and others merely a unilateral implementation of ideas that did not work in a global environment.
Just a few countries were pioneering the use of passenger data exchange as part of their border strategies at the beginning of the 21st century. Today, about 60 countries have data exchange provisions in effect, and experts anticipate that the number of countries requiring API or PNR or both will continue to increase rapidly over the next few years.
In 2014, most countries in the Asia/Pacific region and six countries in South America had announced plans to move to API or PNR or both. By 2020, it is not inconceivable that over 100 countries could be implementing data exchange requirements for flights to and from their territories. Before long, the entire world will join in.
To create greater awareness of what airlines are allowed to transmit or are capable of transmitting, and to ensure harmonization in the process that government and industry participants follow in implementing passenger data exchange regimes, the WCO, the International Air Transport Association (IATA) and the International Civil Aviation Organization (ICAO) have stepped up their communication and education efforts, which now include organizing events and information days.
This article is published in the context of these increased outreach efforts, with the aim of providing an overview of the issue.
API versus PNR
Passenger data is any information that has been collected and stored by an airline on a passenger’s identity or travel plans which is used by public authorities for the purposes of law enforcement or border control. This information can be divided into two main streams: API and PNR.
API is information about a person’s identity. Generated during check-in, it consists basically of the data provided routinely by travellers when they cross an international border – some controls require data provision where flights overfly international territory, but this is not the norm). API is normally obtained from an official travel document and is considered to be ‘verified’ information.
API is also extremely useful for checking databases of travellers who present a ‘known’ risk – those who have broken the law in the past, over-stayed their visas, or appear on a watchlist because border authorities wish to deny them entry – and for checking on people on whom information is already recorded – for example, a person who has registered for a ‘known traveller programme.’
PNR is information about a person’s travel reservation. It is created in airline reservation systems when a traveller makes a booking, and describes where and when the passenger intends to fly, how a reservation was made, and whether any additional services will be required during the journey. PNR is primarily collected by the airline for its own business purposes. Therefore, the amount and the nature of the information in individual PNR records can vary tremendously from airline to airline and from passenger to passenger.
In some cases, PNR contains as little information as a name, an itinerary, some generic contact information and a ticket indicator. In other cases, PNR will contain vast amounts of information, covering a wide range of issues relating to special services, such as meal requests, contact details and credit card information. This information is not considered to be ‘verified’. The name may not even correspond to the person’s actual name as stated in the passport because accuracy is not always necessary to complete a booking.
Once PNR is collected for business purposes it can be of interest to authorities as a risk assessment tool because the data contained in a passenger reservation may help in flagging certain people, including their relationships and travel patterns – information not previously known. PNR can also be useful in criminal investigations. Like API, PNR data is usually requested for international flights – requesting it for domestic flights is not the norm.
The WCO, IATA and ICAO fully support API and PNR data-exchange processes, when adopted in accordance with their agreed guidelines. The use of internationally standardized advance passenger information is contained in two WCO instruments:
- as a Recommended Practice in Specific Annex J1 (Travellers) of the Revised Kyoto Convention;
- as an objective of the Recommendation on the use of API and/or PNR for the risk assessment of travellers, published in June 2012.
When API was first introduced by the US in 1990, it was a new concept in international civil aviation, and therefore no standards, recommended practices or technical frameworks existed to guide the initiative’s development. All elements of the experimental programme, from data element requirements to communication protocols, were developed as the US programme explored and ultimately defined them. This was not a significant issue at the time, since participation was voluntary and the process was still new to everybody.
However, with the development of other national passenger data exchange programmes in the 1990s, the need to focus on a single, globally-agreed methodology became apparent. As a consequence, IATA and the WCO began work to develop a standard methodology to support advance submission of passenger data – including the creation of a new message format in accordance with the UN/EDIFACT construction rules – that was intended to establish a common approach to API systems, worldwide.
The results of this work – the WCO/IATA Guidelines for Advance Passenger Information, and the associated UN/EDIFACT Passenger Manifest (PAXLST) Message Implementation Guide – were published in 1993 following adoption by the WCO Council in June 1993. Recognizing the value that global harmonization of API systems would bring to international civil aviation, ICAO, in Standard 3.47.1, Chapter 3 of Annex 9 to the Convention on International Civil Aviation, referred to data being required in conformity with specifications for UN/EDIFACT PAXLST messages.
ICAO joined the WCO and IATA, and a ‘Contact Committee’ comprising the three organizations was formed. In order to help their respective members implement the API system, the three organizations jointly published the WCO/IATA/ICAO Guidelines on Advance Passenger Information in 2003, amending them in 2010 and 2013 respectively. The Guidelines include new provisions to address issues relating to security, data protection, mutual administrative assistance and ‘Interactive API’ – a more advanced method of passenger processing at airports.
Regarding PNR data requirements, ICAO’s Document 9944 Guidelines on PNR Data, adopted in 2005 and recently revised, contains a list of 19 categories of data that might be contained within an individual PNR. The guidelines contain a composite list of data elements that may be transferred between the operator and the receiving country, and establish uniform measures for PNR data transfer and the subsequent handling of that data.
For example, ICAO’s guidelines specify that since airlines only collect the data that is required to meet their obligations to their customers, individual PNR will not always have the data elements that countries might be interested in seeing and that, since this is not in the airlines’ control, penalties should not be imposed for inaccurate or incomplete data. The guidelines also advise countries to require airlines to transmit the information as late as possible prior to the flight departure to ensure complete data and to minimize the number of times PNR data is sent for the same flight.
Regarding the standard for PNR transmission, a PNRGOV message was created to enable data extracted from the reservations system and/or the departure control system of airlines to be provided to government in a standard form. PNRGOV standards are complementary to ICAO’s guidelines on PNR, and reflect the consensus achieved between the WCO, IATA and ICAO on matters concerning the reporting of passenger information to governments. The industry standard, namely the UN/EDIFACT Customs Response (CUSRES) message, has been adopted as the standard message to support government-to-airlines replies.
The WCO/IATA/ICAO API-PNR Contact Committee acts as the final clearing house for any changes to the reporting standards for both API and PNR. Once a change request is received, it is distributed to all members of the Contact Committee for their comments. If there are technical issues, the request is also sent to technical groups, such as the WCO Data Model Project Team and the WCO Information Management Sub-Committee, for their comments. However, the ultimate decision rests with the WCO/IATA/ICAO API-PNR Contact Committee which receives inputs from ICAO, the industry and WCO Members.
Before a new request is accepted, the Contact Committee will look at whether another country besides the requesting country supports the request, whether there is a business justification for it, whether it is technically possible to include the information in the standard message itself, and whether the information can be obtained in any other way.
Benefits of standard data requirements and transmission messages
When a government system is aligned with the standards then it is aligned with the processes airlines have already developed. Less time in particular will be required for both airlines and governments when testing message validation.
Airline staff easily understand the requirements as they already know the data elements and format to be used. Developing standard compliant systems will require fewer modifications that may impact on compliance abilities.
The costs for airlines and governments are lower. Requirements outside of the standards result in additional reprogramming with significant associated costs. Reinventing the wheel is an expensive proposition.
Harmonized systems involve predictable and common data elements. In the case of API, it is recommended to limit the data to that shown in the machine-readable part of the passport, as this information can be verified. Data requiring interrogation and manual capture is subject to errors.
PNR transmission-related challenges
PNRGOV is the agreed method for transmitting PNR data from airline systems to government systems. Countries that do not adopt PNRGOV and ask airlines to transmit what they have in their systems will receive a stream of data which their computer systems will not be able to use, unless they have developed a receiving filtering system that is more advanced than that any other country in the world has been able to achieve.
PNRGOV allows the data in a reservation to be identified by the receiving system, far more easily than a non-PNRGOV message would. However, PNRGOV is a standard message, not standard content, and therefore managing data variance and complexity is one of the challenges of implementing the message. Despite endorsed international standards for those messages:
- PNR information is commercial in nature and will vary depending on an airline’s internal processes;
- PNR data may be represented in many different formats, but still be compliant;
- PNR data may be in free text and may be duplicated;
- to create meaningful information, the mapping process must apply rules to the data intelligently – for example: Do not translate duplicates if field 1 = X then do A, if field 1 = Y then do B. If field 1 = X and field 2 = Z, then do C, etc.;
- without intelligent mapping, the simple transformation of data may generate confusing data and create problems for subsequent analysis.
Some countries that have implemented PNR highlight the significant time spent in testing the message with airlines. Therefore, countries wishing to implement such a system should seek assistance from those countries that have gained experience in implementing passenger data systems.
Besides technical issues, the transmission of passenger data raises privacy and data protection issues. Although the sharing of API between airlines and governments may not raise many privacy concerns (the nature of API data and the use to which it is put should conform to the national law of most countries), carriers are often limited in what PNR data may be shared with requesting authorities. Certain data is considered particularly sensitive and may be shared only in accordance with a country’s data privacy legislation.
For the most part, the debate over data privacy for PNR is being driven by the EU, but many countries also have restrictive provisions in place that airlines are often required to work through. Of particular interest to this issue is the ‘Joint Review Report on the implementation of the Agreement between the European Union and Australia on the processing and transfer of Passenger Name Record (PNR) data by air carriers to the Australian Customs and Border Protection Service’ published in July 2014 by the European Commission (EC) and available online.
Among other things, the report describes how Australian Customs minimizes access to personal data, removes and deletes sensitive data and any PNR data elements that it receives which are outside the 19 data elements listed in the Annex to the Agreement, ensures data security, as well as retains and deletes PNR data to comply with the Agreement’s provisions.
Benefits of API/PNR
The justification for the use of advance passenger information is rather simple in theory: the balance between the needs of Customs enforcement and the facilitation of legitimate travel can best be achieved if Customs enforcement is intelligence-based, and the use of API and/or PNR for risk assessment would greatly assist Customs administrations in developing and exploiting the best possible intelligence for controlling travellers.
The guidelines on API list benefits according to four categories of actors:
- passengers (shorter clearance times);
- carriers (enhanced security and reduced exposure to penalties for transporting passengers who are not properly documented);
- border control agencies (thorough and rigorous screening of inbound passengers, data capture saving, more effective allocation of resources and greater interagency cooperation);
- airport authorities (reduced need to expand or upgrade current facilities in response to increased traffic, greater passenger satisfaction with facilities and fewer complaints).
When it comes to PNR, most countries argue that PNR serves the purpose of supporting the fight against terrorism and other serious crimes that are transnational in nature. One of the parameters of the review undertaken by the EC to assess the implementation of agreements signed with foreign countries for sharing PNR data is to verify that the agreements actually serve these purposes. On all the reviews done so far – with Australia and the US – the EC assessment team have been positive.
It is also interesting to consult these reports to gain a general idea of how PNR data is processed in these two countries and of the methodology used. Indeed, none of the data retained in PNR records would reveal a specific threat or even a suspicious indicator of a threat on its own. Contrary to API data, which may produce a direct hit on a watchlist, PNR has no such straightforward content.
Recently, the debate on foreign fighters has brought the issue of passenger data submission to the fore. Countries wishing to implement a passenger data programme should have a clear idea of what their border risks are and what they want to use the data for. They should also familiarize themselves with existing international standards, include stakeholders early in the process, approach other countries about any data protection issues, check that appropriate legislation is in place, and seek assistance from experts.
Introductory presentations and videos, dynamic checklists and reference material to help design passenger data programmes that are harmonized, efficient and valuable.
- A section of the WCO Customs Risk Management Compendium (Volume 2)
- Restricted to WCO Members
- Content in two parts:
- Annex I: List of risk indicators for passengers
- Annex II: A manual which provides general information, specifies the meaning of each risk indicator, and includes examples, pictures and case studies