Christopher HornekPassenger Data Exchange ExpertICAO Doc 9303 Compliance Programme Project Manager

Passenger Data

EURNAT Facilitation Implementation seminar , 20-23 April 2021

Passenger Data Single Window A facility that allows parties involved in

passenger transport by air to lodge standardized passenger information (i.e. API, iAPI and/or PNR) through a single data entry point to fulfil all regulatory requirements relating to the entry and/or exit of passengers that may be imposed by various agencies of the Contracting State

Note.― The Passenger Data Single Window facility to support API/iAPI transmissions does not necessarily need to be the same facility used to support PNR data exchange.”

Operating Airline

Sing

le W

indo

w P

orta

l

GDS

Marketing Airline

Immigration

Customs

Transport Security

MoI / NCB

Bord

er D

atab

ase

MFA Visa

INTERPOL

Passport Control

Single Window

Single Window SARPs• *Std 9.1: shall create Single Window facility for each data

category (API/iAPI and/or PNR);

• RP. 9.1.1: should consider creating a Passenger Data Single Window facility for both data categories combined.

What is API?• API consists of biographical data about passengers, plus information

concerning the flight involved that is transmitted to a border agency in a PAXLST message before, or as the aircraft departs.

• The data is generated during airline check-in by the Departure Control System (DCS).

• API may apply to airlines operating into a country, in some cases, departing from a country or for flights which overfly a territory but do not depart or arrive in the territory itself.

• In some cases, the same data is also required for crew members.

What is PNR?• Consists of reservation data recorded by airline and/or other

commercial reservation systems for each journey booked by or on behalf of any passenger.

• PNR data are used by airlines for their own commercial and operational purposes. This data can be sent to States in a PNRGOV message to fulfil border and national security purposes.

• PNR data content varies from airline to airline and even from passenger to passenger. PNR contains only as much as the airline or booking agency collects in the process of its travel bookings.

API vs. PNR API: Information about a

person’s identity. Used for

For front-line Immigration, Customs

and Security watch-lists

Messages: PAXLST (batch or interactive), CUSRES (iAPI)

Messaging Standards:UN/EDIFACT (no XML)

PNR: Information about a person’s travel reservation.

For risk assessment & analysis

To help identify contraband, smuggling, etc.

Messages: PNRGOV, GOVREQ, ACKRES

Messaging Standards:PADIS-based EDIFACT & XML

“SIMPLE MESSAGE”

“COMPLEXMESSAGE”

Advance Passenger Information

Benefits of API• Provides information about a person’s identity. • Helps identify people you know about.

• For instance, people on a watchlist.• Border Integrity: Helps to improve border control and to combat

irregular immigration more effectively.• Facilitation: Leads to a faster processing of bona fide travelers

and improves citizens’ perception of security.

Benefits of API• Efficiency: Allows for the reduction of the workload of border

management officers through the use of technology and automated means.

• International Information Sharing: Complements existing data vetting processes, such as checking passenger passports against watch lists and INTERPOL databases (e.g. INTERPOL Stolen and Lost Travel Documents database).

API Stakeholders• Passport Control (immigration);

• Customs;

• Aviation Security;

• Counter-Terrorism/National Security;

• Counter-Narcotics.

WCO/IATA/ICAO Guidelines on API• API Data Elements

API Data Relating to the Flight (Header Data)• Airline Code and Flight Number• Scheduled Local Departure Dates/Times• Scheduled Local Arrival Dates/Time• Last Place/Port of Call for Aircraft• Place/Port of Initial Arrival for Aircraft (AMS-YUL-YYZ-YVR)• Subsequent Place(s)/Port(s) of Call within the Country (YYZ)• Number of Passengers and Number of Crew Members

API Biographic Data Elements in MRZ

14

--See also ICAO Annex 9 Standard 9.101. Travel Document Number2. Issuing State or Organization3. Travel Document Type4. Expiration Date of Document5. Surname/Given names(s) of holder (one field)6. Nationality7. Date of Birth8. Sex of holder

Additional Data Elements Normally Found in Airline Systems

Easily captured, of great value• Seating Information• Baggage Information• Traveller Status• Place/Port of Original Embarkation (passenger)• Place/Port of Clearance (Immigration)• Place/Port of Onward Foreign Destination (AMS-YUL-BOS)• Passenger Name Record Locator Number

Additional Data not normally found in Airline systems

Not easily captured, perhaps better captured by the State directly through an online process• Visa Number• Issue Date of the Visa• Place of Issuance of the Visa• Other Document Number Used for Travel• Type of Other Document Used for Travel• Primary Residence• Destination Address• Place of Birth

Two methods of API Transmission1. Batch/Legacy API2. Interactive API

Batch API• Simplest form of API to implement• Batch API is designed originally for the control of arriving

passengers by the destination or transit country• All passenger details (crew potentially in a separate message) are

transmitted as a single data file, or “batch”• Data is usually transmitted upon closure of the flight boarding

process, government intervention is limited to the time of arrival• Data quality validation is limited, and no-real time correction can

be requested

Interactive API• More complex and costly form of API to implement• All passenger details are transmitted in real-time on a per

passenger basis as check-in is taking place, government intervention is immediate (response message)

• Receiving State must determine if any issues are preventing the passenger from entering the destination country, leaving the origin country or boarding an aircraft

• Enhances aviation security and reduces the number of inadmissible passengers

ICAO Annex 9 API SARPs

Adherence to the Standards Std. 9.5: States shall not require non-standard data elements as

part of API, iAPI and / or PNR.

Std. 9.6: States that are considering to deviate from the standard shall submit a request to the WCO/IATA/ICAO Contact Committee in conjunction with the WCO’s Data Maintenance Request (DMR) process via a review and endorsement process.

API Mandatory Standard *Std. 9.7: Each Contracting State shall establish an Advance

Passenger Information (API) system. Note 1 UN security council, “Resolution 2178” (2014), paragraph 9;

“[c]alls upon Member States to require that airlinesoperating in their territories provide advancepassenger information to the appropriate nationalauthorities in order to detect the departure fromtheir territories, or attempted entry into or transitthrough their territories, by means of civil aircraft,of individuals designated by the Committeeestablished pursuant to resolutions 1267 (1999)and 1989 (2011) (“the Committee”),…”

API Legal Basis Standard *Std. 9.8: The API system of each Contracting State shall be

supported by appropriate legal authority (such as, inter alia, legislation, regulation or decree) and be consistent with internationally recognized standards for API.

Note 1: Brief description of APINote 2: Information on UN/PAXLST message of UN/EDIFACTNote 3: Non-applicability to general aviationNote 4: The UN/EDIFACT PAXLST msg is defined by WCO/IATA/ICAO guidelines

Machine Readable Zone main source of data content *Std. 9.10: When specifying the identifying information on

passengers to be transmitted, Contracting States shall require only data elements that are available in machine readable form in travel documents conforming to the specifications contained in Doc 9303. All information required shall conform to specifications for UN/EDIFACT PAXLST messages found in the WCO/IATA/ICAO API Guidelines.

Second travel document (data quality) Std. 9.11: States shall not penalise or hold aircraft operators

responsible for inconsistencies in passenger data exchange in regards to a second travel document, e.g.:

• Dual nationals;

• Laissez-passer;

• … etc.

API Operational Provisions RP 9.12: Contracting States should seek to minimize the

number of times API data is transmitted for a specific flight.

Std. 9.13: If a Contracting State requires API data interchange, then it shall seek, to the greatest extent possible, to limit the operational and administrative burdens on aircraft operators, while enhancing passenger facilitation.

API Operational Provisions RP 9.14: refrain from imposing fines and penalties on

operators for errors caused by a systems failure;

Std. 9.15: not require a passenger manifest in paper form, if already requiring electronic transmission through an APIS.

Summary of API SARPs in Annex 9• Consider the needs of all agencies (Single Window)• Batch API is mandatory• Legal Basis must be in place• PAXLST Message format• UN/EDIFACT Transmission Protocol• Passport data according to ICAO Doc 9303 (MRTD)• Data elements according to WCO/IATA/ICAO Guidelines on API• Technical specifications:

– Batch - PAXLST Message Implementation Guide

Summary of iAPI SARPs in Annex 9• Consider the needs of all agencies (Single Window)• Introduction of iAPI is a Recommended Practice• Legal Basis must be in place• Adherence to the WCO/IATA/ICAO Guidelines on API and

UN/EDIFACT Transmission Protocol is a Recommended Practice

• Passport data according to ICAO Doc 9303 (MRTD)• Technical specifications:

– iAPI - CUSRES Message Implementation Guide

Passenger Name Record (PNR) Data

PNR DefinitionDefined by ICAO PNR Guidelines (ICAO Doc 9944)• PNR is the generic name given to records created by aircraft

operators or authorized agents for all the segments of a journey.• PNR is commercial data supplied by or on behalf of the passenger

concerning all the flight segments of a journey. • Includes changes to requested seating, special meals and

additional services requested.• PNR data are captured in many ways. Reservations may be

created by various marketing organizations with pertinent details of the PNR then transmitted to the operating carrier(s).

Benefits of PNR• Traditionally developed for Customs to identify contraband and

smuggling routes • To prevent terrorism and organized crime as well as a wide range

of law enforcement measures.• For risk assessment and analysis, helps States to identify

unknown or suspicious people, trends or patterns, such as unknown travel routing and connections among individuals (including non-travellers), as well as between individuals and entities.

ICAO PNR Guidelines – Doc 9944• PNR data are captured into reservation systems many days or weeks in

advance of a flight. This can be up to approximately a year in advance of departure. Information in reservation systems is therefore dynamic and may change continually from the time when the flight is open for booking.

• Passenger and flight information in the DCS is, on the other hand, available only from when the flight is “open” for check-in (up to 48 hours prior to departure). Departure control information for a flight will be finalized only upon flight closure and may remain available for 12 to 24 hours after the arrival of a flight at its final destination.

PNR Stakeholders• Customs;

• Passport Control (immigration);

• Counter-Terrorism/National Security;

• Counter-Narcotics;

• Aviation Security;

Integrated vs. Segregated Systems• Some DCS systems are programmed such that details

emerging from check-in (i.e. seat assignment and/or full baggage information) can be overlaid into the existing PNR for each passenger – integrated system

• However, that integrated capability is limited — States have to accommodate both systems

• In a segregated system, check-in data is not fed back into the PNR

Integrated vs. Segregated Systems• Reservations may be accepted directly by the aircraft operator

and the complete PNR stored in the operator’s automated reservations systems. Some operators may also store subsets of the PNR data in their own automated departure control systems (DCS), or provide similar data subsets to contracted ground handling service providers, to support airport check-in functions.

Integrated vs. Segregated Systems• In each case, operators (or their authorized agents) will have

access to and be able to amend only those data that have been provided to their system(s). Some DCS systems are programmed such that details emerging from check-in (i.e. seat and/or baggage information) can be overlaid into the existing PNR for each passenger. However, that capability is limited — covering less than 50 per cent of operating systems today

Airlines with segregated systems

PNR

API

Reservation System

Departure ControlSystem

Airlines with integrated systems

Passenger data Reservation

+Departure Control System

-48 -24 -23 0

CLM = Close out Message

Batch API Message Sequencing

-48 -24 -23 0

CLM = Close out Message

Batch API & PNR Message Sequencing

-48 -24 -23 0

FCO = Final Close Out messageCLM = Close out Message

iAPI & PNR Message Sequencing

ICAO Annex 9 API SARPs

PNR Baseline Commitment *Std. 9.24: Each Contracting State shall:

a) develop a capability to collect, use, process and protect PNR data …supported by appropriate legal and administrative framework… and be consistent with all Standards contained in Section D, Chapter 9, Annex 9;

b) align its PNR programme with ICAO PNR Guidelines and WCO/ICAO/IATA guidance materials; and

c) adopt and implement the PNRGOV message for airline to-government PNR data transferal to ensure global interoperability.

PNR Purpose Limitation *Std. 9.25: with full respect for human rights and fundamental

freedoms, State shall:a) clearly identify in their legal framework the PNR data to be

used in their operations; b) clearly set the purposes for using PNR data…”proportional”,

including in particular law enforcement and border security purposes to fight terrorism and serious crime;

c) limit disclosure of PNR data to other authorities in the same State or in other Contracting States…

PNR Safeguards and redress mechanisms *Std. 9.26: States shall:

a) prevent unauthorised access, disclosure and use of PNR data and include penalties in legal and admin framework;

b) ensure safeguards apply to all without unlawful differentiation;

c) take measures to ensure individuals are informed about collection, processing and protection of PNR data;

d) ensure that AOs inform customers about PNR transfer;e) provide for administrative and judicial redress mechanisms;f) provide mechanisms for individuals to obtain access and to

request, if necessary, corrections, deletions or notations.

PNR Redress mechanisms RP. 9.27: Subject to necessary and proportionate restrictions,

Contracting States should notify individuals of the processing of their PNR data and inform them about the rights and means of redress afforded to them as defined in their legal and administrative framework.

PNR Automated processing Std. 9.28: Contracting States shall:

a) base the automated processing of PNR data on objective, precise and reliable criteria that effectively indicate the existence of a risk, without leading to unlawful differentiation; and

b) not make decisions that produce significant adverse actions affecting the legal interests of individuals based solely on the automated processing of PNR data.

PNR Independent oversight *Std. 9.29: Contracting States shall designate one (or more)

competent domestic authority(ies) as defined in their legal and administrative framework with the power to conduct independent oversight of the protection of PNR data and determine whether PNR data are being collected, used, processed and protected with full respect for human rights and fundamental freedoms.

PNR Data content, non-filtering & sensitive data Std. 9.30: Contracting States shall:

a) not require AOs to collect PNR data that is not required as part of their normal business operating procedures nor to filter the data prior to transmission; and

b) not use PNR data revealing…sensitive aspects of an individual…other than in exceptional and immediate circumstances... In circumstances where such information is transferred, Contracting States shall delete such data as soon as practicable.

PNR Data retention & depersonalization *Std. 9.31: Contracting States shall:

a) retain PNR data for a set period necessary and proportionate for the purposes for which the PNR data is used;

b) depersonalise retained PNR data, which enable direct identification of the data subject, after set periods*;

c) only re-personalise or unmask PNR data when used in connection with an identifiable case, threat or risk for the purposes identified in 9.25 (b); and

d) delete or anonymise PNR data at the end of the retention period*.

*except when used in connection with an identifiable ongoing case, threat or risk purposes identified in 9.25 (b).

PNR Data retention & depersonalization RP. 9.32: Contracting States should retain PNR data for a

maximum period of five years after the transfer of PNR data, except when required in the course of an investigation, prosecution, or court proceeding.

RP. 9.33: Contracting States should depersonalise PNR data within six months of and no later than two years after the transfer of PNR data.

PNR Operational considerations Std. 9.34: Contracting States shall:

a) as a rule use the 'push' method, in order to protect the personal data that is contained in the operators' systems;

b) …limit the operational and administrative burdens on aircraft operators, while enhancing passenger facilitation;

c) not impose fines and penalties on aircraft operators for any unavoidable errors caused by a systems failure; and

d) minimise the number of times the same PNR data is transmitted for a specific flight.

PNR Global framework Std. 9.35: Contracting States shall:

a) not inhibit or prevent the transfer of PNR data provided the receiving State’s PNR data system is compliant with Annex 9; and

b) retain the ability to introduce or maintain higher levels of protection of PNR data and to enter into additional arrangements with other Contracting States in particular to:

- promote collective security; - achieve higher levels of protection of PNR data, including on

data retention;- establish more detailed provisions relating to the transfer of

PNR data, provided those measures do not otherwise conflict with Annex 9.

PNR Global framework Std. 9.36: States shall demonstrate compliance with the PNR

Standards to all States ASAP upon request.

RP. 9.36.1: Contracting States should allow other Contracting States, compliant with the PNR Standards, to receive PNR data, at least provisionally, while engaging in consultations, as necessary.

PNR Global framework

RP. 9.37: Where Contracting States have determined they must inhibit, prevent or otherwise obstruct the transfer of PNR data, or that they might penalize an aircraft operator, they shall do so with transparency and with the intent of resolving the situation which caused that determination.

PNR Global framework RP. 9.38: Contracting States establishing a PNR programme, or

making significant changes to an existing programme, pursuant to these SARPs should proactively notify other Contracting States maintaining air travel between them prior to receiving data, including whether they are complying with these SARPs, to encourage or facilitate rapid consultation where appropriate.

RP. 9.39: While attempting to resolve PNR data transfer disputes, Contracting States should not penalize aircraft operators.

Passenger Name Record (PNR) Data• Extra Material for studying

PNR Guidelines – Doc 9944• Airline industry systems are programmed to transfer the entire contents of a

PNR to States and do not want to filter out data which may want to be considered sensitive. Thus, States need to set up their own data filtering and protection systems to deal with sensitive data.

• The airline industry cannot guarantee the accuracy of PNR data, as reservation data is filled with self-asserted and unverified data collected for commercial purposes during time of booking.

• Reservation systems are also changing and can include other elements of a passenger’s travel routing, such as a hotel reservation or rental car booking.

PNR Guidelines – Doc 9944• A PNR is built up from data that have been supplied by or on behalf of the

passenger concerning all the flight segments of a journey. This data may be added to by the operator or his authorized agent, for example, changes to requested seating, special meals and additional services requested.

• PNR data are captured in many ways. Reservations may be created by international sales organizations (global distribution systems (GDS) or computer reservation systems (CRS)) with pertinent details of the PNR then transmitted to the operating carrier(s).

PNR Guidelines – Doc 9944• Reservations may be accepted directly by the aircraft operator and the

complete PNR stored in the operator’s automated reservations systems. Some operators may also store subsets of the PNR data in their own automated departure control systems (DCS), or provide similar data subsets to contracted ground handling service providers, to support airport check-in functions.

• In each case, operators (or their authorized agents) will have access to and be able to amend only those data that have been provided to their system(s). Some DCS systems are programmed such that details emerging from check-in (i.e. seat and/or baggage information) can be overlaid into the existing PNR for each passenger. However, that capability is limited — covering less than 50 per cent of operating systems today.

PNR Guidelines – Doc 9944• Aircraft operators specializing in charter air services often do not hold PNR

data. In some cases, for example, where they use a DCS, they will have a limited PNR record but only once the flight has closed.

• Supplemental or “requested service” information may be included in the PNR. This type of information may concern special dietary and medical requirements, “unaccompanied minor” information, requests for assistance, and so on.

• Some information, such as the internal dialogue or communication between airline staff and reservation agents, may be stored in the PNR, in particular in the “General remarks” field. The remarks may include miscellaneous comments and shorthand.

PNR Guidelines – Doc 9944• PNRs may include many of the separate data elements described in the list of

possible elements contained in ICAO 9944. However, in practice aircraft operators capture only a limited number of data as key elements for the creation of a PNR.

• An airline operating system may have a limited capability of incorporating data elements registered in the DCS (e.g. all check-in information, all seat information, all baggage information and “go-show” and “no-show” information) into a PNR. Accordingly, the structure of individual PNRs and the amount of data they contain will vary widely.

PNR Guidelines – Doc 9944• The number and nature of the fields of information in a PNR will vary

depending on the reservation system used during the initial booking, or other data collection mechanism employed (e.g. the DCS), the itinerary involved and also upon the special requirements of the passenger.

• The possible fields and subfields of PNR data may expand to more than sixty items, as listed in Appendix 1 to ICAO Doc 9944. PNR data fields are subject to change based on operational requirements and technological developments.

PNR Guidelines – Doc 9944• PNRs should not contain any information that an aircraft operator does not

need to facilitate a passenger’s travel, e.g. racial or ethnic origin, political opinions, religious or political beliefs, trade-union membership, marital status or data relating to a person’s sexual orientation. Contracting States should not require aircraft operators to collect such data in their PNRs.

• PNRs may contain data, e.g. meal preferences and health issues as well as free text and general remarks, legitimately entered to facilitate a passenger’s travel. Some of these data may be considered sensitive and require appropriate protection. It is particularly important that carriers and States protect these data.

PNR Data Elements• Guidelines on Passenger Name Record (PNR) Data

(ICAO Doc 9944)

PNR Data ElementsPNR 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

PNR Data ElementsFrequent flyer information – Frequent flyer account number and elite level status

PNR locator code – 6-digit file locater number, booking reference and reservation tracking number

Number of passengers on PNR – Number

Passenger travel status – Standby information

PNR Data ElementsAll 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

PNR Data ElementsAll 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

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

PNR Data ElementsAll 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

PNR Data ElementsTravel 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 (stand-by without reservation)

No-show information - Only available after flight close-out: no-show history

PNR Data ElementsGeneral remarks - All information in general remarks section

Free text/code fields in Other Service Information (OSI), Special Service Requests (SSR), Special Service Information (SSI), remarks/history - All IATA codes