Passenger Data Christopher Hornek - EURNAT Facilitation Implementation seminar , 20-23 April 2021 ICAO Doc 9303 Compliance Programme Project Manager
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
Passenger Data Christopher Hornek Passenger Data Exchange Expert ICAO Doc 9303 Compliance Programme Project Manager 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.”
Single Window Passport
Control
Operating Airline Immigration MFA Visa
Single Window Portal
Border Database
GDS Customs
Marketing Airline
I
Transport Security N
T
E
R
MoI / NCB P
O
L
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 PNR: Information about a
person’s identity. Used for person’s travel reservation.
For front-line For risk assessment &
Immigration, Customs analysis
and Security watch-lists To help identify contraband,
smuggling, etc.
“SIMPLE
“COMPLEX
MESSAGE”
MESSAGE”
Messages: PAXLST (batch or
interactive), CUSRES (iAPI) Messages: PNRGOV, GOVREQ,
ACKRES
Messaging Standards:
UN/EDIFACT (no XML) Messaging Standards:
PADIS-based EDIFACT & XML
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 --See also ICAO Annex 9 Standard 9.10 1. Travel Document Number 2. Issuing State or Organization 3. Travel Document Type 4. Expiration Date of Document 5. Surname/Given names(s) of holder (one field) 6. Nationality 7. Date of Birth 8. Sex of holder 14
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 NumberAdditional 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 BirthTwo methods of API Transmission 1. Batch/Legacy API 2. 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 airlines
operating in their territories provide advance
passenger information to the appropriate national
authorities in order to detect the departure from
their territories, or attempted entry into or transit
through their territories, by means of civil aircraft,
of individuals designated by the Committee
established 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 API Note 2: Information on UN/PAXLST message of UN/EDIFACT Note 3: Non-applicability to general aviation Note 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 GuideSummary 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 Definition Defined 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
Reservation System PNR
API
Departure Control
SystemAirlines with integrated systems
Reservation
Passenger data
+
Departure Control SystemBatch API Message Sequencing
-48 -24 -23 0
CLM = Close out MessageBatch API & PNR Message Sequencing
-48 -24 -23 0
CLM = Close out MessageiAPI & PNR Message Sequencing
-48 -24 -23 0
FCO = Final Close Out message
CLM = Close out MessageICAO 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 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
PNR Data Elements Frequent 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 Elements 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
PNR 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 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 Elements 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
PNR Data Elements 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 (stand-by without reservation) No-show information - Only available after flight close-out: no-show history
PNR Data Elements General 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
You can also read
