Info Article

Information Article

(*Particularly with respect to an Accident Airline’s ‘Passenger Manifest Verification’ Process)

Relevance:

Air carrier (airline etc.) provided ‘Advance Passenger Information’ (API) and ‘Passenger Name
Record’ (PNR) data are increasingly being required by governments around the world (typically by
‘border control’ and related ‘security’ authorities e.g. ‘homeland security’) to assist in countering the
threat of international criminal activities - particularly terrorism

As a valuable ‘knock-on’ effect, use of such API and PNR data can also (separately) provide important
inputs in the vital task of speedily and accurately identifying air accident victims - and possibly also
their (non-flying) family and relatives

Use of API data for this latter purpose is relatively new

In contrast, PNR data for this ‘same purpose’ has always been available, but its application
(interpretation) has been notoriously work intensive / time consuming - for a number of reasons.
The increasing use of PNR for border control and security purposes has required a standardised
transmission format of same to be developed. This latter should, in turn, assist in more effective and
efficient utilisation of PNR data - as related to the air accident situation

Use of API & PNR Data to assist in Identification of Air Accident Victims etc. - 2015 - (Reviewed 2019) 1
 Info Article

Introduction

This information article has two objectives:

Firstly, to gain an outline and contemporary (up to date) understanding of what is meant (in aviation
and other appropriately related contexts e.g. international border control; international security
etc.) by the terms ‘Advance Passenger Information - API’ and ‘Passenger Name Record - PNR’

The second objective is to apply this understanding to the vital task of attempting to identify victims
(and possibly their ‘non-flying’ family & friends also) - in the context of a post-catastrophic aircraft
accident type situation (and similar impact aviation crises)

Background

The following extract from an * ICAO Sep 2013 ‘working paper’ - might serve to set the scene:

* International Civil Aviation Organisation (a body of the United Nations)

‘………………………..By 2016 airlines will be transporting 800 million more people than they did in 2011,
reaching a total of around 3.6 billion passengers. Keeping [country] borders secure while limiting
costs of same will be a growing challenge. To do this [to assist in meeting this challenge], more and
more States [countries] are turning towards the use of airline provided passenger data such as
Advance Passenger Information (API) and Passenger Name Record (PNR)

API and PNR can provide an efficient and effective way to acquire and pre-assess traveller info for
immigration, customs & security purposes, but involves source systems which are typically in use /
ownership by / of ** airlines (and / or airline associated entities such as Amadeus, Sabre, Travelport
[Galileo and Wordspan] etc. - all coming under the generic heading of ‘Global Distribution Systems -
GDS’)

The International Air Transport Association (IATA) and its member airlines understand the need for
electronic transmission of such data to States, in order to expedite passenger flows and to also meet
legitimate border control / other security needs - and are cooperating with States’ ‘public authorities’
worldwide (on this matter) accordingly

** Traditionally such airline ‘systems’ comprise a ‘Computer Reservation System - CRS’ and a ‘Departure
Control System - DCS’

They have historically not been easily compatible with the data receiving systems in use by immigration,
customs, security etc. in different countries - without significant and costly adaptation - which has already
raised the question of ‘who will pay for this?’

Much work has been accomplished on this (and associated matters) to date (2015) - by both government
organisations and the aviation industry - with more still to come. ICAO and WCO have been and still are also
very significantly involved (see next paragraph)

Use of API & PNR Data to assist in Identification of Air Accident Victims etc. - 2015 - (Reviewed 2019) 2
 Info Article

Cooperation between ICAO, World Customs Organisation (WCO) and IATA has helped achieve a
strong global framework for such [API and PNR] data transmission. A number of dedicated
‘Standards and Recommended Practices’ now exist in ‘ICAO Annex 9 - Facilitation’, as well as solid
and extensive guidelines for API and PNR data transmission

In 2015 * 49 countries required API data and 10 more had similar requests in the pipeline

16 countries required access to PNR data, with another 29 due to follow suit. Unfortunately, the
associated requirements in many of these countries do not comply with international Standards and
Guidelines as used in the aviation industry

* Believed to be around 60 countries for API in 2016 and increasing rapidly. Similarly, the number of countries
requesting PNR data has also increased significantly from the figures given above e.g. all EU countries are
expected to require airline provided PNR data from early 2016 (over and above those small number of EU
countries which unilaterally already [mid 2015] do so)

Non-standard passenger data requirements can affect [adversely impact upon] all parties. For States
requiring passenger data, non-standard requests often lead to delays in compliance by the (aviation)
industry - or to actual flight delays when non-standard information must be manually captured

For the airlines, non-standard requests consume unnecessary time and resources, as available data
needs to be modified to new systems and individual authorities’ needs. In addition, airlines become
liable when complying with non-standard requests which contradict national laws on data privacy of
other States. This in turn affects those States and their citizens…………………………’

Situation as at mid-2015

The significant amount of work already gone into making the transmission of API and PNR data (to
States so requiring it as already described above) more effective, efficient, expedient and
standardised is to be applauded - especially as it also often needs to ‘fit around’ conflicting State
requirements concerning matters such as personal ‘privacy’ and ‘data protection’

For example, the European Union (some countries excepted e.g. UK) as an entity had long resisted
the PNR matter, using individual privacy and data protection as mitigations for such resistance

It took the terrorist attacks in Paris in early January 2015 to concentrate EU minds on this matter -
and it is likely that the EU will now ‘come on board’ by the end of 201 5 i.e. accede (subject to certain
safeguards) to all EU countries adopting the need to acquire and use PNR data for border control /
security purposes

As another example, an organisation known as the ‘Passenger Name Record Government Working
Group - PNRGOV’ has been working (with IATA) for some years now on standardising data messaging
formats for transmitting PNRs. (For more information on PNRGOV - see page 27)

Use of API & PNR Data to assist in Identification of Air Accident Victims etc. - 2015 - (Reviewed 2019) 3
 Info Article

‘API Required’ States (Countries) as at mid-2015

It has been difficult to definitively provide an accurate, complete and current list of States requiring
API information. However, the following (starts immediately below) is the most complete list that
the author of this information article was able to come up with - as at May 2015. (If any reader(s)
can provide more accurate / current / complete data, then they are requested to please contact the
author accordingly by email at ‘[email protected]’. All information gratefully received)

Advance Passenger Information (API) Countries (estimated 57 of them) - as at mid-2015

 Algeria
 Angola
 Antigua and Barbuda
 Australia
 Austria
 Bahrain
 Bangladesh
 Barbados
 Bermuda
 Brazil
 Canada
 China
 Costa Rica
 Cyprus
 Czech Republic
 Dominica
 Egypt
 Germany
 Grenada
 Guyana
 India
 Indonesia
 Iran
 Ireland
 Italy
 Jamaica
 Japan
 Kenya
 S Korea
 Kuwait
 Maldives
 Malta
 Mexico
 Morocco

Use of API & PNR Data to assist in Identification of Air Accident Victims etc. - 2015 - (Reviewed 2019) 4
 Info Article

 Netherlands
 New Zealand
 Pakistan
 Qatar
 Romania
 Russian Federation
 S Africa
 St Kitts & Nevis
 St Lucia
 St Vincent & the Grenadines
 Spain
 Sri Lanka
 Switzerland
 Syria
 Tanzania
 Thailand
 Trinidad & Tobago
 Tunisia
 UAE
 Uganda
 UK
 USA + US Territories (both for landing and overflight purposes)
 Zambia

‘PNR Required’ States (Countries) - as at mid-2015

It has been even more difficult to definitively provide a current list of States requiring PNR
information. (If any reader(s) can provide more information on this matter, then they are requested
to please contact the author accordingly by email at ‘[email protected]’. All information
gratefully received)

As a ‘best guess’ - countries such as Australia, Canada, UK and the USA are all currently involved.
Within the EU, countries such as France, Belgium, Denmark, the Netherlands and Sweden are
believed to be involved to one degree or another. Elsewhere up to around 40 or so other countries
are also believed to be involved or are in the process of becoming so involved

More Information

For readers so interested, more information on the border control and security aspects of API and
PNR use is included in a series of attachments to this information article - starting on page 17

Use of API & PNR Data to assist in Identification of Air Accident Victims etc. - 2015 - (Reviewed 2019) 5
 Info Article

Deliberately Blank

Use of API & PNR Data to assist in Identification of Air Accident Victims etc. - 2015 - (Reviewed 2019) 6
 Info Article

Background

Immediately below is an extract from Chapter 3 (‘Types of Family Assistance’) of ICAO Doc 9973 -
‘Manual on Assistance to Aircraft Accident Victims and their (non-flying i.e. not on board the
accident flight) Families’:

‘……………………….Following an aircraft accident, the most immediate form of information required is

conformation of whether or not the person(s) about whom a family is concerned - was involved in
that accident…………………….’

To achieve the above, the ‘accident airline’ needs to corroborate (by using various information
sources available to it) that the ‘official’ * list of passengers on board the accident flight is as accurate
and complete as is possible………………..…….by attempting to identify and remedy any inaccuracies /
deficiencies in such list, insofar as is possible so to do - considering actual circumstances ‘on the day’

* - In aviation terminology a ‘passenger list’ is more commonly known as a ‘passenger manifest’

How this is achieved is commonly known as a passenger manifest verification (or confirmation /
reconciliation) process

A significant number of information sources might (repeat - might) be available ‘on the day’ when
trying to corroborate the passenger list. However, the only sources referred to within the scope of
this information article (the document you are reading now) are API and PNR data

Note - the quality (‘completeness’ and accuracy etc.) of airline passenger manifests around the world varies
immensely - from being just about 100% accurate and complete on most occasions at one extreme - to being
non-existent on most occasions - at the other. This situation is not expected to change anytime soon! There
are many reasons for this - but they are outside the scope of this information article

Passenger Manifest Verification (PMV-1)

Note - at the risk of stating the obvious, the first thing to ‘take on board’ here is that API data will only be
available (for input to the PMV process) in circumstances where the accident flight was operating a sector on
which API data was required. As at mid-2015 around 60 of the world’s (approximately) 193 countries (i.e. less
than one third) required API data from airlines carrying passengers to and / or from their countries. However,
this number is expected to grow (possibly quite quickly) with time

Use of API & PNR Data to assist in Identification of Air Accident Victims etc. - 2015 - (Reviewed 2019) 7
 Info Article

The concept and application of ‘Advance Passenger Information (API)’ has been around for some
time now - but has latterly become increasingly relevant and useful in the ‘fight against crime’,
particularly terrorism - and usually in the context of border control and similar (immigrations and
customs etc.) - including what might be generically termed ‘homeland security’

A consequential ‘spin-off’ of this security related requirement is that the same information can be
used by airlines to assist in the identification of air accident victims and, in certain jurisdictions (e.g.
the USA), possibly also the details of an ‘emergency contact person’ - as had been nominated by a
victim - at some point prior to the departure of the accident flight

Perhaps the best way to demonstrate how this information is collected by an air carrier might be to
look at an example of an ‘API required’ 2015 information webpage belonging to a de-identified but
real, (scheduled / passenger) international airline:

Example

‘………………………….ABCX Airways (de-identified airline)

What is Advance Passenger Information & why do I need it?

In order to enhance safety and security, the border control (immigration and similar) authorities of
many countries require all airlines to provide passenger passport (and possibly additional)
information, prior to departure of any inbound or outbound flights to / from such countries. API data
is required in addition to any Visa and similar travel related requirements

Currently these countries include:

List of ‘API required’ countries on the ABCX Airways flight network would have been included here

Please be aware that information requirements are subject to change at any time

Use of API & PNR Data to assist in Identification of Air Accident Victims etc. - 2015 - (Reviewed 2019) 8
 Info Article

Required passenger information for all API countries is as follows (note that additional information
requirements vary by country):

 Full name
 Passport number, issuing country and expiration date
 Gender
 Date of birth
 Nationality

If travelling to the United States of America, the following additional API details are required

For Permanent Resident Card Holders only:

Permanent Residence Card number

For non-US Citizens without a Permanent Residence Card:

a) Country of residence
b) Destination address in the USA, including street, city, state and zip code. If you are staying at
a hotel, provide the complete hotel name as well as the street, city, state and zip code

Example:

Address: Downtown Hilton Hotel - (be as specific as possible)

City: Houston; State: Texas; ZIP Code: 99999

If you are not sure of the correct ZIP Code, you may enter 99999

If you are transferring to a cruise ship on the day you arrive in the USA, provide the name of
the cruise ship and your port of embarkation. Example:

Address: Transit to MV Princess of the Seas

City: New York; State: New York; ZIP Code: 99999

If you are planning to pick up a rental car and if the address of the first night stay is not
known, you may provide the general itinerary. Example:

Address: Touring the Grand Canyon area

City: Grand Canyon; State: Arizona; ZIP Code: 99999

If you are returning on the same day, provide the address of a location where you will be
spending time during your visit to the USA

If you are transferring to another flight in the USA (which goes outside the USA) - and such
flight is scheduled to depart later than eight hours after your scheduled flight arrival time in
the USA - provide your departure flight number and departure airport name and address

Use of API & PNR Data to assist in Identification of Air Accident Victims etc. - 2015 - (Reviewed 2019) 9
 Info Article

If you do not have an address for the first night in the USA, provide information about where
you expect to be staying in as much detail as possible

If you are travelling with children and infants, you must provide a US address for each of
them

c) Name and telephone number of a contact person in the USA

Passengers who refuse to supply this information prior to travel will not be allowed entry to the USA
and therefore will not be accepted for travel at check-in. It is important that the information is
accurate to avoid delays at the airports both on departure and arrival into the USA. US Citizens, Legal
Permanent Residents (LPRs), transit passengers and departing passengers are exempt from the U.S.
address requirement

In addition to the Advance Passenger Information above, the USA requires your next of kin contact
details - in case of an emergency. This will include the latter person's name and telephone number
Note - the author of this information article (the one you are reading now) believes (possibly incorrectly) that the
information documented immediately above regarding ‘next of kin contact details’ is an advisory requirement only, in that
the question is asked (typically by the carrying airline) - but that the information need not be provided if the passenger so
declines. A further variation of this is that it is mandatory for US citizens only to provide this ‘next of kin’ information - with
other passengers having the choice not so to do

Readers who can provide more definitive information on this matter are requested to please contact (email at:
‘[email protected]’) the author accordingly (providing ‘official’ references where possible)

End of Example

By default, API data will be held in one or both of an airline’s Computer Reservation System (CRS)
and Departure Control System (DCS) - or equivalent system(s). Consequently, it will be relatively
simple and quick for an airline to make such information available to its emergency response team
following e.g. a catastrophic aircraft accident involving that airline

This team can then use the API information to provide an input into its passenger manifest
verification process (and other associated requirements) for the accident flight

Some (a small number) of airlines having their own emergency response management ‘systems’,
simply need to enter flight number and date into such system to obtain (download) just about
everything held by the airline concerning the accident flight - including API (and PNR) data i.e. it can
all be available within literally seconds of the airline learning about the accident

From an airline emergency response planning viewpoint, it is a pity that only the USA currently (i.e.
as at 2015) seems to also mandate for additional information to be required when collecting
associated (pre-departure) API data - as shown in the example further above

This is because such provision of ‘next of kin’ / equivalent details would be of particular value to the
accident airline, to accident victims - and to (non-flying [i.e. not on accident flight]) family, relatives
& friends of such victims

Use of API & PNR Data to assist in Identification of Air Accident Victims etc. - 2015 - (Reviewed 2019) 10
 Info Article

Passenger Manifest Verification (PMV-2)

Introduction

Passenger Name Record (PNR) data is the generic term given to electronic records created by the
aviation and travel industry (travel agents etc.) each time a passenger books (reserves) and / or buys
an * air ticket

* Note - PNRs can also be used to record flight-related information e.g. car-hire, hotel bookings etc.

PNRs typically contain information provided by the passenger, by the airline, by the travel agent, by
the tour operator, by other appropriate persons etc. - which is used (operationally & commercially)
by the different parties involved, to facilitate the passenger’s travel; for record keeping purposes etc.

The intent of a PNR as originally conceived (and so used until relatively recently) was not to facilitate
border control and security. However, PNR information today (2015) may include elements which
require reporting as part of API

Passengers are able to make flight bookings / reservations in various ways, most commonly through
direct contact with the air carrier via its website and / or via its telephone reservations centre and /
or via travel agents etc. A passenger or a travel agent may make a reservation for a flight even if a
(required) visa, travel authorisation (including via API) is still to be submitted

PNRs may be created from one year maximum before intended departure date - up to and including
the day of departure itself (i.e. for immediate travel). Information contained within the PNR may
change between time of creation and time of travel

The amount and the nature of the information in a PNR can vary from airline to airline, travel agent
to travel agent and even passenger to passenger e.g. a PNR may contain as little information as a
name - or may contain e.g. full address, contact details, credit card information and other
significant data pertaining to the booking

The basic information provided in PNR may include any / all of: (for full details see page 14)

 PNR Locator Code (Booking reference number & other, similar terminology)
 Passenger name (first, last and gender)
 Details of intended travel itinerary
 Method of payment, which may include (partially masked) credit card & similar information
 Special Service Requests (SSR) such as preferred seating, assistance for persons with reduced
mobility, meal requests for children / infants etc.
 Frequent flyer / traveller (loyalty scheme) number / reference
 Travel document information, which may include biographic information, as part of the
obligation for airlines to provide API information to the border authorities in countries of
departure and / or destination
 Additional remarks or comments (if any)

Use of API & PNR Data to assist in Identification of Air Accident Victims etc. - 2015 - (Reviewed 2019) 11
 Info Article

An example of a ‘real’ PNR (with explanatory annotations included [which would not appear on the
original PNR of course]) is shown below:

Example - PNR

Image above © 1991-2015 Edward Hasbrouck / Reproduced herein with copyrighter’s permission.
http://hasbrouck.org/articles/PNR.html

Using PNR Data in the Passenger Manifest Verification (PMV) Process

PNR data is potentially of considerable value to the PMV process. However, it has historically not
been effectively exploited by many airlines (as part of their emergency response [aircraft accident]
planning efforts) as info shown in PNRs (in practical ‘day to day’ use) is typically rather haphazard
and non-standard - and may thus be difficult to interpret / understand by most airline emergency
responders

However, one airline (for which the author of this info article was the ‘emergency planning
manager’) addressed this problem by planning to use a team of its reservations staff (PNR experts)
to ‘decode / translate’ PNRs (into plain language) for passengers on an accident flight

Use of API & PNR Data to assist in Identification of Air Accident Victims etc. - 2015 - (Reviewed 2019) 12
 Info Article

The resulting plain language ‘translation’ would then have bene fed directly to the team undertaking
the PMV process

The main problem here is the time factor involved - e.g. imaging decoding 600+ PNRs for a full, hi-
density seating Airbus A-380! Nevertheless it MUST be done, because of the potential importance of
such data to the PMV process

As mentioned, a major problem here is lack of consistency / standardisation of PNR data as used by
‘inputters’ around the world - whether they be aviation or other travel industry staff (such as travel
agents). As we have noted further above, a PNR can contain as little as just a name

Some improvement to the above situation has eventuated in relatively recent times because of the
requirement (for border control and security purposes) of an increasingly large number of countries
to be provided (by airlines etc.) with PNR data

In order to accomplish this it had been necessary to standardise the PNR message transmission
format - which improves (to a degree) the time factor issues associated with decoding the PNR, into
the plain language format required by airline emergency responders

Note (for information purposes only)

Law enforcement (Border Force [Customs; Immigration etc.]; Homeland Security etc.) authorities may use PNR
data in several ways:

 Re-active: use in investigations, prosecutions, unravelling of networks after a crime has been
committed. In order to allow law enforcement authorities to go back sufficiently in time, a
commensurate period of retention of the PNR data by law enforcement authorities is necessary

 Real-time: use prior to the arrival or departure of passengers in order to prevent a crime, watch or
arrest persons before a crime has been committed or because a crime has been or is being
committed. In such cases PNR data are necessary for running against pre-determined assessment
criteria in order to identify previously ‘unknown’ suspects and for running against various databases
of persons and objects sought

 Pro-active: use of PNR data for analysis and creation of assessment criteria, which can then be used
for a pre-arrival and pre-departure assessment of passengers. In order to carry out such an analysis of
relevance for the prevention, detection, investigation and prosecution of terrorist offences and
serious crime, a commensurate period of retention of the PNR data by law enforcement authorities is
necessary

Use of API & PNR Data to assist in Identification of Air Accident Victims etc. - 2015 - (Reviewed 2019) 13
 Info Article

Extract from ICAO Doc 9445 - Guidelines on Passenger Name Record (PNR) Data 1st Ed 2010

PNR DATA ELEMENTS

An operator’s system(s) may include the below Component Data Elements

following data elements
PNR name details Passenger name, family name, given name/initial,
title, other names on PNR
Address details Contact address, billing address, emergency
contact, email address, mailing address, home
address, intended address [in State requiring PNR
data transfer]
Contact telephone number(s) [Telephone details]
Any collected API data Any collected API data, e.g. name on passport,
date of birth, sex, nationality, passport number
Frequent flyer information Frequent flyer account number and elite level
status
PNR locator code File locater number, booking reference and
reservation tracking number
Number of passengers on PNR [Number]
Passenger travel status Standby information
All date information PNR creation date, booking date, reservation
date, departure date, arrival date, PNR first travel
date, PNR last modification date, ticket issue
date, “first intended” travel date, date of first
arrival [in State requiring PNR data transfer], late
booking date for flight
Split/divided PNR information Multiple passengers on PNR, other passengers on
PNR, other PNR reference, single passenger on
booking
All ticketing field information Date of ticket issue/purchase, selling class of
travel, issue city, ticket number, one-way ticket,
ticket issue city, automatic fare quote [ATFQ]
fields
Data groups or categories Component data elements
All travel itinerary for PNR PNR flight itinerary segments/ports, itinerary
history, origin city/board point, destination city,
active itinerary segments, cancelled segments,
layover days, flown segments, flight information,
flight departure date, board point, arrival port,
open segments, alternate routing unknown
[ARNK] segments, non-air segments, inbound
flight connection details, on-carriage information,
confirmation status

Use of API & PNR Data to assist in Identification of Air Accident Victims etc. - 2015 - (Reviewed 2019) 14
 Info Article

Form of payment (FOP) information All FOP [cash, electronic, credit card number and
expiry date, prepaid ticket advice (PTA),
exchange], details of person/agency paying for
ticket, staff rebate codes
All check-in information* Generally available only after flight close-out:
check-in security number, check-in agent I.D.,
check-in time, check-in status, confirmation
status, boarding number, boarding indicator,
check-in order
All seat information Seats requested in advance; actual seats only
after flight close-out*
All baggage information* Generally available from DCS only after flight
close-out: number of bags, bag tag number(s),
weight of bag(s), all pooled baggage information,
head of pool, number of bags in pool, bag carrier
code, bag status, bag destination/ offload point
Travel agent information Travel agency details, name, address, contact
details, IATA code
Received-from information Name of person making the booking
Go-show information* Generally available only after check-in and flight
close-out: go-show identifier
No-show information* Only available after flight close-out: no-show
history
General remarks All information in general remarks section
Free text/code fields in OSI, SSR, SSI, All IATA codes
remarks/history

* These elements are contained in the DCS and are not available prior to departure

A recommendation has been made to the World Customs Organization (WCO) to consider
incorporating these elements in future API messaging. Depending on the airline system these
elements may or may not be part of a PNR

Note - for latest information the reader should check for the latest version of the above (2010) document

Use of API & PNR Data to assist in Identification of Air Accident Victims etc. - 2015 - (Reviewed 2019) 15
 Info Article

Deliberately Blank

Use of API & PNR Data to assist in Identification of Air Accident Victims etc. - 2015 - (Reviewed 2019) 16
 Info Article

Attachments to Information Article

Use of API & PNR Data to assist in Identification of Air Accident Victims etc. - 2015 - (Reviewed 2019) 17
 Info Article

Attachment A

Air Transport & Travel Industry

Principles, Functional and Business Requirements PNRGOV - Version 13.1

(Approved and published by the WCO/IATA/ICAO API Contact Committee)

October 2013

(Selected extracts only follow below):

1.3 Background

The PNRGOV message has been developed under the auspices of the PADIS Board. The message
structure and the contents of the message are designed to provide a consistent approach for all
airlines required to provide PNR information to States. Although not mandated for usage, currently it
is envisaged that the message may provide the opportunity to rationalize data provision in the
future. Within this document, Governments are referred to as States and Airlines as Carriers.

PRINCIPLES

In order to provide a consistent approach to the provision of the PNRGOV message and the data that
it might contain, a number of principles have been identified and should be adhered to, where
possible

1. Messages are constructed in accordance with the PNRGOV structure as documented in the
current PNRGOV Implementation Guide

The Carrier will provide to the State that PNR data which is available within the Carrier’s system(s).
This has been defined by ICAO as: “States should not require an operator to provide PNR data that
are not already collected or held in the operator's reservation or departure control systems. The
specific data elements that might be available from an aircraft operator's system will also depend on
the type of air transport services provided by the operator.”

(See ICAO's Doc 9944 Section 2.4 Laws or Regulations), and by how and by whom the passengers’
reservations were finalized

13. Emergency Lock procedures (i.e. process to control data release following an emergency or
incident involving a particular flight) are based upon bilateral agreements between States and
Carriers. System providers may be required to implement the capability to override data
transmission restrictions put in place during an emergency lock

14. While not currently mandated, the underlying principle guiding development of the PNRGOV
message is to provide a standard message structure that may be utilized by States and Carriers

Use of API & PNR Data to assist in Identification of Air Accident Victims etc. - 2015 - (Reviewed 2019) 18
 Info Article

Deliberately Blank

Use of API & PNR Data to assist in Identification of Air Accident Victims etc. - 2015 - (Reviewed 2019) 19
 Info Article

Attachment B

ICAO / WCO / IATA

Management Summary - Passenger Related Information

[‘Umbrella Document’ - December 2013]

Introduction

The purpose of this document is to provide a high-level executive brief describing and distinguishing
between the different sources and systems for passenger-related information required to be
provided by ‘air carriers’ to ‘border control agencies’ - of certain countries to which air carriers
operate

A growing number of states (countries) require airlines to provide information on passengers

intending to travel to their territory. The information usually exists in the air carrier’s reservation
and departure control systems. Some states also require passenger related information from other
modes of transport (e.g. passenger ships)

Taking into account:

 The increasing number of air passengers

 The increase in security related measures
 The environmental and efficiency-driven innovations which result in bigger airplanes - and
 The need for more efficient passenger flows at airports

………………. it is now necessary to develop more intelligent and efficient methods to ‘check’ passengers
and their baggage (in a security / criminal type context etc.). This means that decisions to check
passengers will have to be made more on the basis of pre-flight risk analysis instead of generally
increasing level of checks at immigration or cross border desks and baggage claim areas

Mainly as part of increased security controls, passenger related information (available in airline
‘systems’) is being increasingly used by border control authorities in the cross border movement of
persons and goods. Security-related controls are often applied even before passengers board their
flights. Ultimately, however, such controls must be applied before the arrival of the passenger in the
country of destination, in order to perform risk-based targeted controls of persons and goods. These
measures will also facilitate the flow of low-risk passengers at airports

The use of passenger related information is often challenged by persons and organisations
concerned about the protection of personal information privacy. In most jurisdictions, the use of
passenger-related information for law enforcement purposes is not permissible - without proper
guarantees for the protection of such information. Such guarantees are intended to guard against
misuse and ensure proper privacy safeguards

Use of API & PNR Data to assist in Identification of Air Accident Victims etc. - 2015 - (Reviewed 2019) 20
 Info Article

Passenger Related Information

The flow of passenger-related information from air carriers to border control authorities can be
divided into three main streams:

1. Passenger Name Record (PNR - also see page 22)

A reservation can be made from approximately 360 days before departure - up to the
moment that the check-in process closes, the latter typically being some 1-3 hours before
departure (depending on the airport and route)

Passengers who make a reservation and do not travel on the reserved flight are called ‘No-
show passengers’. Passengers who do not make a reservation, who wish to travel and who
can be accommodated on the desired flight are called ‘Go-show passengers’

2. Passenger Information from the Departure Control System (DCS - also see page 22)

Approximately 48 to 36 hours before scheduled flight departure, PNR’s for a particular flight
are * transferred from the air carrier’s Computer Reservation System (CRS) to its Departure
Control System (DCS)

In the latter the operational handling of the passenger and baggage handling aspects of the
flight will now take place e.g. intake of baggage and issuing of boarding passes at passenger
check-in. It is common practice for the passenger list (passenger manifest) to be forwarded
from the departure airport to the destination airport - for the same operational purposes

* Some air carriers use a single system incorporating both CRS and DCS functions – which are capable of
‘talking’ to each other

3. Advance Passenger Information (API - see page 24) from the DCS

As API data is not generally required for airline processes, it will (normally) only be collected,
stored and managed - typically in order to comply with some external (to the airline) ** legal
/ equivalent requirement

** For example, EU-based Airlines are bound by strict privacy legislation and are therefore only
allowed to collect and disclose API data in case of a legal obligation

There are typically four methods employed to collect the required API information -
depending on the required timeframe associated with the provision of this data:

 At the time that a reservation is made by the passenger and / or his travel agent etc.
(manually entered into the API / equivalent section of the reservation record [PNR])

 On internet self-check-in (manually entered into the API section of the DCS)

Use of API & PNR Data to assist in Identification of Air Accident Victims etc. - 2015 - (Reviewed 2019) 21
 Info Article

 At airport / similar ‘kiosk’ type self-check-in (*** automated - using the machine
readable zone of the passenger’s passport) ………………..….or by the airline agent at the
check-in counter (automated - using the machine readable zone of the passenger’s
passport)

*** For non-machine readable travel documents - the data must be entered manually

 On boarding - by the airline agent at the boarding gate (automated - using the
machine readable zone of the passenger’s passport)

Despite the existence of these collection points, passenger registration at the moment of
reservation is operationally the best moment; manually entered information has the risk
that incorrect data is supplied (e.g. a zero instead of a null). The best option (from a data
quality perspective) is collection of machine readable information, via an automated process

More on Passenger Name Record (PNR)

It is only relevantly recently that PNR derived information is starting to be used by government
agencies around the world to analyse and make, where appropriate, the necessary (usually security
and or criminally related) interventions.

Such PNR information can be provided by airlines by sending the information electronically (“Push”
method) or allowing the appropriate government agencies s to access the parts of their reservation
systems where the PNR information is stored (“Pull” method)

However, internationally there is an agreement to utilise the “Push” method in preference -

predicated in the main on data protection and privacy type issues (with the ‘pull’ method,
government agencies would effectively have unhindered access to airline systems)

The actual message format (known as ‘PNRGOV’) used for transmission of PNR data to the
appropriate government agencies (typically border control authorities and similar) is being
developed by using relevant international messaging standards to ensure interoperability

More on Passenger Information contained in a Departure Control System (DCS)

The information included in PNR records may not only relate to reservation information but could
also contain information gathered at check-in when the passenger presents himself to the airline
representatives at the airport. Check-in procedures are normally undertaken via an airline’s DCS -
the latter being specifically designed to perform airport handling and related functions

Check-in generally describes the procedure by which an airline is alerted to and manages a
confirmation that a passenger intends to actually board and travel on a reserved flight - as intended

This procedure may vary significantly between different airline business models - and may include
e.g. conventional check-in at airport counters; self-service check-in such as via internet, mobile
telephone & airport kiosks; ‘through check-in’ when travelling on a sequence of connecting flights
for which participating air carriers have commercial arrangements in place, including code-share
agreements etc.

Use of API & PNR Data to assist in Identification of Air Accident Victims etc. - 2015 - (Reviewed 2019) 22
 Info Article

Note that conventional agent check-in at airport counters may diminish over time as self-service
options become increasingly more utilised

Given that DCS systems are normally deployed in airport environments to facilitate functions
associated with airport activity - check-in records are created close to departure date / time,
normally not earlier than approximately 48 hours before, although this time will vary by airline
business model

The processes implemented by airlines will vary and some might split check-in formalities into
distinct steps, which may be performed separately and several hours apart, for example, web check-
in the night before baggage is checked-in at the airport. Where appropriate, the check-in process
may involve:

 Seat allocation or confirmation of a previously requested seat assignment

 Recording information such as number of pieces and / or weight of baggage which is assigned to
the hold of the aircraft
 Collection of API (personal biographic information) as necessary to comply with any API
programme of the country / countries involved in the journey for which check-in is performed
 Confirmation or action re any special requests
 Some but not all systems may indicate whether passengers form part of a group or party

Airport check-in provides the airline a first opportunity to view the passengers’ travel documents

Passengers who elect to perform self-service check-in (either through the use of internet or a self-
service kiosk at the airport) are still required to physically submit their travel document(s) for
inspection by the airline representative at the airport, even in circumstances where API data has
already been provided through the self-service check-in process. This is necessary to ensure that
passengers are properly documented for their journey and are the rightful document holders - and
to protect the airline against potential liability charges (for not so doing) imposed by some countries

Passengers using self-service check-in will normally have their travel documents examined by an
airline representative when depositing luggage. At this stage some airlines may elect to also validate
the accuracy of API data previously supplied by the passenger - or now collect API data as
appropriate and where required

Furthermore, some countries may request airlines to collect copies of travel documents with regards
to flights to certain high-risk destinations. These are also usually collected at the same time

Transfer passengers and those travelling without checked luggage would be seen by an airline
representative at some point before and / or during the boarding process

In some cases airlines conduct further checks during the boarding process in order to satisfy security
procedures, including baggage reconciliation i.e. that hold baggage and its owner must travel
together. This does not necessarily involve the collection of information, but might include
automatic system functions that change a check-in record status from e.g. ‘checked-in’ to ‘boarded’

Use of API & PNR Data to assist in Identification of Air Accident Victims etc. - 2015 - (Reviewed 2019) 23
 Info Article

Check-in (seat assignment) and / or the collection of API data might also be performed during the
boarding process, where appropriate. This would normally include transit passengers connecting
from another flight where check-in was not performed due to technical restrictions between air
carrier systems. Another reason might be that API data was not previously collected because a data
sharing agreement had not been in place - typically due to technical or legal reasons

It is perhaps noteworthy that where seat assignment is offered by airlines as a service component,
seat numbers may change several times for various operational reasons or upon passenger request -
both before and after boarding has taken place. Furthermore, passengers may not necessarily
occupy their assigned seat once on board and the aircraft doors ‘closed’

In many countries it is a requirement that either a general declaration or passenger manifest is

provided by the inbound airline / aircraft operator. The data contained within these documents can
include a ‘declaration of health’, crew and passenger numbers and place of origin

More on Advance Passenger Information (API)

A definition of an ‘API System’ can be found in Annex 9 to the ICAO Convention i.e.

‘………………An electronic communications system whereby required data elements are collected and
transmitted to border control agencies prior to flight departure or arrival, and made available on the
primary line at the airport of entry………………..’

API includes personal biographic identification details obtained from the passport or other travel
document of a passenger - together with basic flight information. The identification details can be
obtained manually or from the machine readable zone of a ‘Machine Readable Travel Document’
(MRTD) e.g. appropriately designed passports. The standards for the machine readable zones in
travel document are explained in ICAO Doc 9303

The notion of an API system was conceived by the Customs and Immigration services of certain
countries that had identified the need to address the growth of air passenger traffic, which had
begun to put their resources under severe pressure, resulting in lengthy delays in the processing of
arriving passengers at airports

In order to facilitate such travellers, a system was established by which a passenger’s personal
biographic identification data could be sent to the authorities at the destination airport - upon
departure of the flight from the previous airport. This data could then be processed (cross-checked
[profiling & risk assessment]) against appropriate computer databases - before arrival of the
passengers at that destination

This was envisioned as a means of addressing the twin objectives of improved compliance and faster
clearance of low-risk passengers i.e. the ‘arrival’ authorities should have procedures and resources in
place for examining and analysing this data before flight arrival

Use of API & PNR Data to assist in Identification of Air Accident Victims etc. - 2015 - (Reviewed 2019) 24
 Info Article

This latter approach is now being gradually superseded by more demanding measures in light of
increasing threats to security e.g. API data may be collected and transmitted during the booking
process itself - even if this takes place up to one year before the flight is to be taken

A standardized API system should include the following key elements:

 Be user-friendly, seamless and where appropriate facilitate the travel of passengers as a result of
API data analysis
 Contain (as an important part of the required API data) information from the machine readable
zone of travel documents (for ref - see ICAO Document 9303)
 Account for the interests of key stakeholders
 All relevant data requirements of the requesting border agency must be taken into account
 The data requirements should originate from one representative agency of the requesting
Control Authority
 Control Authorities should work together to respect the data requirements of different Control
Authorities and (to the extent possible) should minimise the impact upon air carriers of
providing different data to different Control Authorities on individual flights
 Management of contractors and costs should take place in a collective way to ensure unilateral
systems are capable of operating in bilateral and multilateral environments, taking account of
domestic and international recognised standards to achieve a harmonised environment
 With respect to the message format for transmission of API, systems should be developed to use
the UN / EDIFACT messaging standard to ensure that interoperability is achieved. However, this
should not be seen as constraining the ability to adopt other internationally agreed message
format standards in the longer term
 API systems should seek to minimize the impact on existing air carrier system and technical
infrastructure
 An API system should be capable of round-the-clock operation, with contingency procedures in
place to minimize disruption to air carrier operations in the event of system failure
 Control Authorities choosing to introduce API systems should adopt the principles contained in
this document. However, nothing in this document is to be construed as contradictory to
national legislation or regulations

Use of API & PNR Data to assist in Identification of Air Accident Victims etc. - 2015 - (Reviewed 2019) 25
 Info Article

Deliberately Blank

Use of API & PNR Data to assist in Identification of Air Accident Victims etc. - 2015 - (Reviewed 2019) 26
 Info Article

Attachment C1

World Customs Organisation (WCO)

API Guidelines & PNR Reporting Standards

Physical inspection of a traveller and a travel document is nowadays only a small part of border
controls on passengers arriving by air. The rest of the border control process relies on secure
electronic data, some being provided at the time the passenger buys a ticket and some at the time
the passenger boards an aircraft

Controls in any case have to be applied before the arrival of the passenger in the country of
destination, to enable relevant border agencies to perform risk-based targeted controls on
passengers and the goods they are carrying

The flow of passenger-related information from carriers (airlines) to border control authorities can
be divided into two main streams: Advance Passenger Information (API) and Passenger Name Record
(PNR)

API data is generated during check in. The API Guidelines were initially developed in 1993 by the
WCO in cooperation with the International Air Transport Association (IATA). Subsequently, the
International Civil Aviation Organization jointed the process and a ‘Contact Committee’ comprising
the three organizations was formed. In order to help their respective members implement the API
system, the three organizations have jointly published the WCO/IATA/ICAO Guidelines on Advance
Passenger Information in 2003, 2010 and now in 2013

The Guidelines include new provisions to address issues such as security, data protection, mutual
administrative assistance and ‘Interactive API’, a more advanced method of passenger processing at
airports

Passenger Name Record data is generated during the booking or buying of an air ticket. Since 2010,
the WCO/IATA/ICAO API Contact Committee has been working on updating the electronic reporting
standards for PNR. Work related to the ‘PNRGOV’ message for reporting PNR information to
government is carried out by a joint industry-government working group led by IATA, called the
PNRGOV Working Group

The ‘communication’ shown on the next page highlights the achievements of this joint-industry
government body, which works under the umbrella of IATA and the WCO/IATA/ICAO API Contact
Committee. It also underscores the significant contribution of the participating governments
towards the development of the PNRGOV standards

The API Contact Committee acts as the final clearing house for any changes to the reporting
standards for both API and PNR. PNRGOV standards are complementary to ICAO’s guidelines on PNR
(ICAO Doc 9445), and are reflective of the consensus achieved between the WCO, IATA and ICAO on
matters concerning the reporting of passenger information to governments

Use of API & PNR Data to assist in Identification of Air Accident Victims etc. - 2015 - (Reviewed 2019) 27
 Info Article

Attachment C2

Attention Airline Industry Colleagues (November 2013)

PRNGOV - Standard Message Format for Reporting PNR Information to Governments

Over the past several years a group of dedicated members from various Airlines, States, and airline
Industry Service Providers have collaborated in working towards the standardization of Passenger
Name Record (PNR) data

The main objective of the group was to identify a manner in which PNR data can be standardized
and incorporated into the acquisition and provision of passenger data that would be most beneficial
to all stakeholders. In addition, these standards must continue to support the World Customs
Organization (WCO), the International Civil Aviation Organization (ICAO) and the International Air
Transport Association (IATA) guidelines - as well as being able to meet individual State legislative
requirements on the acquisition and provision of PNR data

With the administrative lead and support of IATA, this group which is now known as the Passenger
Name Record Government (PNRGOV) Working Group has recently finalized and gained WCO and
ICAO approval for a PNR message standard that is quickly gaining popularity worldwide. The use of a
standard message format for the provision of PNR data streamlines the process and assists in
decreasing the need for Airlines and States to manage multiple individual data provision
specifications

To obtain more detailed information on the progress that has been made with the PNRGOV Working
Group please contact IATA (at lATA Site Registration) to register to obtain access to the PNRGOV
website, where all meeting minutes and progress to date can be obtained

With the increase in border control agencies requiring airlines to provide passenger data, there is a
need to reinforce the global standards that have been jointly developed to maintain a level of
standardisation and ongoing compliance. To date, numerous airlines have already begun to send
PNR data utilizing the PNRGOV message format with great success

With its growing interest, it is anticipated that within the next few years more airlines and States will
be accepting and processing the PNRGOV message. Currently (November 2013) nine countries
require PNR data and another 25 are preparing to engage in a PNR data collection program in the
near future. The PNRGOV message will provide a consistent standard method for the provision of
PNR data from airlines to border control agencies

Use of API & PNR Data to assist in Identification of Air Accident Victims etc. - 2015 - (Reviewed 2019) 28
 Info Article

Information and specifications of the PNRGOV message can be found on the WCO website at
WCOOMD.ORG. These specifications coupled with the ICAO Doc 9944 PNR Guidelines, will assist you
in understanding what PNR data is and the method in which it can be distributed

We look forward to assisting you further as you analyse your PNR data requirements and determine
if the PNRGOV message format would benefit your organization. Should you have any questions or
would like to discuss data acquisition or provision in greater detail we encourage you to contact any
one of the following representatives from the ICAO Member States or IATA

Australia Customs and Border Protection Service (ACBPS) / Michael Odgers, Director, Industry
Engagement / [email protected]

Canada Border Services Agency (CBSA) / Kathy Therien, Senior Program Advisor, API/PNR /
[email protected]

United States Customs and Border Protection (USCBP) / Robert Neumann, Acting Director, Traveller
Entry Programs / [email protected]

United Kingdom Border Force / Ian Neill, Acting Director Border Systems Programme /
[email protected]

We look forward to further streamlining air passenger data processing and working with you to
standardize the collection and acquisition of PNR data.

Sincerely,

(Signatures follow below)

Use of API & PNR Data to assist in Identification of Air Accident Victims etc. - 2015 - (Reviewed 2019) 29
 Info Article

Deliberately Blank

Use of API & PNR Data to assist in Identification of Air Accident Victims etc. - 2015 - (Reviewed 2019) 30