Guidance for Customs Administrations

How to Build an
Advance Passenger Information (API) /
Passenger Name Record (PNR)
Programme
[July 2017]

Page 1 of 16
Annex to II
doc. PM0067E1

Contents
1. INTRODUCTION .......................................................................................................................... 3
2. PURPOSE ...................................................................................................................................... 4
3. UNDERSTANDING AIR TRAVEL ............................................................................................... 4
4. INTERNATIONAL STANDARDS AND REFERENCE MATERIAL .......................................... 5
What is API .................................................................................................................................... 5
What is PNR ................................................................................................................................... 5
International Standards ................................................................................................................ 5
5. LEGISLATIVE FOUNDATION .................................................................................................... 6
6. PRIVACY ........................................................................................................................................ 8
7. FUNDING ...................................................................................................................................... 9
8. PROJECT MANAGEMENT CHECKLIST ................................................................................... 9
9. SYSTEM DEVELOPMENT ........................................................................................................ 10
Data collection and transmission options ................................................................................... 10
Data processing and display ........................................................................................................ 11
“Push” vs “Pull” methodology ...................................................................................................... 11
System configuration and architecture ....................................................................................... 11
Preparation of business and technical documentation ............................................................... 11
System security and user access ................................................................................................. 12
Continuity and disaster recovery plan ........................................................................................ 12
10. INDUSTRY ENGAGEMENT .................................................................................................... 12
11. PROGRAMME COMPLIANCE ................................................................................................. 13
12. CREATING/IMPLEMENTING A PASSENGER INFORMATION UNIT (PIU) ..................... 13
Infrastructure ............................................................................................................................... 13
Human Resources ........................................................................................................................ 14
Scope of Functions........................................................................................................................ 14
Training ........................................................................................................................................ 15
Interagency Cooperation .............................................................................................................. 15
Cross-border Coordination ........................................................................................................... 15
13. REPORTING .............................................................................................................................. 16
14. CONCLUSION........................................................................................................................... 16

Page 2 of 16
For the purposes of this document, any reference to Border Control Agencies includes;
Customs, Immigration, Police, and all other border enforcement agencies.

1. INTRODUCTION
Statistics show that there is a steady rise in the volume of commercial air travellers from year to
year as more destinations become more accessible and the frequency of flights increases. More
and more countries are therefore looking to improve their risk management capabilities by
providing border control agencies, including customs, immigration and law enforcement, with
key information on air travellers in advance of their travel to or departure from the country.

The ability by border control agencies to identify persons of concern in advance of their arrival
or departure is considered significant in supporting a government’s commitment to ensuring the
safety and security of its citizens. It is also a key component of any risk management programme
and can help facilitate travel for low-risk passengers.

For most border control agencies, routine examination of all passengers and their possessions has
become an impractical method of securing the border. Taking into account the resources
available, control agencies now prefer a more selective approach based on intelligence analysis,
behavioural patterns, risk management, and other efficient methods of targeting, while also
leaving some room for the use of random selection. It is widely recognized that using such
selection methods produces better results than unsystematic or intensive inspections.

Air travel security has changed dramatically over the past decade. Overnight, Advance
Passenger Information (API) and Passenger Name Record (PNR) programmes went from being a
voluntary initiative in some countries to being a priority for many. The importance of API, in
particular, has long been recognized by ICAO in its Standards and Recommended Practices
(SARPs) found in Annex 9 ― Facilitation to the Convention on International Civil Aviation (the
“Chicago Convention”). In September 2014, the UN Security Council passed Resolution 2178,
which, at paragraph 9, calls on states to require airlines operating in their territories provide
advance passenger information to the appropriate national authorities to help identify individuals
with links to terrorism and report on their movements.

While API is used more broadly for general border control purposes, PNR is primarily used for
identifying individuals who are or may be involved in or linked to terrorism, organized crime or
other serious crimes.

According to the International Air Transport Association’s (IATA) World Tracker, in June 2016,
more than 60 countries had an API programme in place and 14 countries had an operational PNR
programme. The ever-present threat of terrorist attacks means that many more countries are now
also looking to establish these programmes.

Page 3 of 16
Annex to II
doc. PM0067E1

2. PURPOSE
This document has been developed to set out the elements to be considered at a strategic level
when setting out to “build” an API and/or PNR programme.

This document is intended for use by representatives of countries that have not yet begun to
develop an API and/or PNR programme, or by those that are in the process of developing or
making improvements to their API and/or PNR programmes. The document will outline the
recommended steps to consider as you begin the journey towards increasing your country’s
cross-border security by applying improved risk assessment methodologies.

An API and/or PNR programme requires both the establishment of procedures for obtaining
advance information on travellers, as well as the development and implementation of automated
tools to assist border control agencies in analysing this information. This document will touch
upon these procedures and give a preliminary overview of the finer details that are outlined in the
WCO “Guidance for Customs administrations on the use of Passenger Name Record (PNR) /
Advance Passenger Information (API)” document.

3. UNDERSTANDING AIR TRAVEL

The decision to develop an API and/or PNR programme is a big one, and a significant amount of
preliminary information needs to be taken into consideration. In an effort to begin to determine
the level of effort that will be required to successfully implement an API and/or PNR programme
in your country, it is first recommended that you look into the following details. In order to
determine the magnitude or scale of the programme you wish to develop, you should first
identify:

a) the number of international flights operating daily/annually into/out of your country

b) the number of air carriers that operate in your country;
c) the number of international passengers flying into/out of your country daily/annually;
d) the airports that manage international flights;
e) whether the programme will include inbound and outbound flights;
f) whether the programme will include domestic flights;
g) whether a legislative/regulatory framework already exists;
h) whether the programme will include non-commercial (private and corporate) carriers
as well;
i) source countries for international flights and any legal/privacy requirements they may
have (e.g., European Union); and
j) the number of times and the intervals at which you will require aircraft operators to
provide API and/or PNR data, to ensure the most accurate and up-to-date information
will be used for risk assessment.

Page 4 of 16
Once you have determined the scope of the programme you wish to develop, this analysis will be
a critical tool that will help to inform the discussions you will have with your internal and
external partners and stakeholders. Engaging with WCO and International Civil Aviation
Organization (ICAO) members that have already implemented an API and/or PNR programme to
obtain information on lessons learned and seek assistance or guidance as you move forward will
be very helpful.

In addition, early engagement with the aircraft operators that operate in your country, and their
related associations, is extremely beneficial in seeking their perspective and finding out more
about their respective business models and the time that they may require to become compliant
with an API and/or PNR programme in your country.

4. INTERNATIONAL STANDARDS AND REFERENCE MATERIAL

What is API

Elements of Advance Passenger Information can be obtained from the machine-readable area of
a passport. Aircraft operators collect API data as passengers check in. Advance Passenger
Information (API) includes the name, date of birth, gender, citizenship, and travel document data
(e.g. passport number). In addition to this biographical information, other basic travel
information, including the number of checked baggage items and their weight and the seat
number may also be captured.

What is PNR

A Passenger Name Record (PNR) is the generic name given by the air transport industry to the
record created by aircraft operators or their authorized agents for each journey booked by or on
behalf of any passenger, either directly, using the aircraft operator’s reservation system, or
indirectly, using a sales organization’s reservation system. The specific PNR data that is
collected varies from one aircraft operator to the next. It includes: in addition to API data, type of
ticket, date of travel, travel itinerary, payment information, frequent flyer information, etc. PNR
data is captured for the first time when a flight reservation is booked and may be modified
several times from that point until the departure of the flight.

With an increasing number of border control agencies requiring air carriers to provide passenger
data, there is a need to reinforce the global data format standards that have been developed and
approved jointly by the WCO, ICAO, and IATA in order to maintain a good level of
standardization and ensure ongoing compliance.

International Standards

Page 5 of 16
Annex to II
doc. PM0067E1

The use of international standard message formats for the provision of API and PNR information
helps to make automated processes more streamlined and reduces the need for aircraft operators
and states to manage multiple individual data provision specifications.

To facilitate the submission of pre-arrival and pre-departure passenger information by aircraft

operators to border control agencies, ICAO, the WCO and IATA establish and maintain
regulatory global standards on API and PNR data, as part of the work carried out by the
WCO/IATA/ICAO API/PNR Contact Committee.

This Contact Committee meets annually to review, maintain and address proposed enhancements
to the API (PAXLST) and PNR (PNRGOV) message formats. A formal Data Maintenance
Request (DMR) process has been established by the WCO in order to address all proposed
enhancements to the API and PNR standard formats.

The establishment of global standards is essential in order to guarantee uniformity in the

API/PNR data that aircraft operators must submit to border control agencies. These standards
ensure that API and PNR systems are implemented in a cost-effective manner and increase data
quality through the use of internationally defined codes.

Message format details and specifications for the API (PAXLST) message and the PNR
(PNRGOV) message can be found on the WCO website at www.wcoomg.org.

In addition, “ICAO Doc 9944, PNR Guidelines” will assist you in understanding what PNR data
is and how it can be transmitted. This document can be found at www.icao.int.

5. LEGISLATIVE FOUNDATION
In preparation for the development of an API and/or PNR programme it is necessary to review
the legislative foundation that you currently have in place and identify if there is a gap that needs
to be addressed with new legislation to support an API and/or PNR programme.

The border control agency responsible for the API and/or PNR programme will play an integral
role in enhancing your country’s national security. Your API and/or PNR programme will be
designed to protect your citizens, by helping border control agencies identify travellers who may
pose a high level of risk to the safety and security of the country. Therefore, it is vital to develop
a national legislative framework to ensure border control agencies have the authority to collect
and process API and PNR data. Experience has shown that most aircraft operators will not
provide API and/or PNR information if they are not required to do so by law.

This legislative foundation will identify the requirements for aircraft operators on providing
specific API and PNR passenger information regarding all individuals on board an aircraft, in
advance of the aircraft’s arrival or departure. In addition to identifying required passenger
information, your legislation may also contain the timing intervals at which API and/or PNR

Page 6 of 16
information must be sent to you for processing (i.e., inbound, outbound, multiple updated
versions of traveller information, crew requirements, etc.) and requirements related to the quality
of the data and the way in which it is provided.

As well as your own country’s legislative foundation, the WCO and ICAO also have specific
guidelines and requirements for API and PNR passenger information that aircraft operators and
states are expected to comply with. The following documents outline the requirements for
technical data formats and guidelines for API and PNR.

API:

- Guidelines on Advance Passenger Information (API)

o Appendix IIA: Passenger List Message (PAXLST) Implementation Guide
o Appendix IIB : API Response Message (CUSRES)
http://www.wcoomd.org/en/topics/facilitation/instrument-and-tools/tools/api-pnr.aspx

- Management Summary on Passenger-related Information (‘Umbrella Document’)

http://www.icao.int/Security/FAL/Documents/Umbrella_Document.2013Dec03.pdf

PNR:

- Annex 9 to the Convention on International Civil Aviation (Facilitation)

http://www.icao.int/Security/FAL/Pages/Annex9.aspx
- Guidelines on Passenger Name Record (PNR) Data (Doc 9944)
https://www.iata.org/iata/passenger-data-toolkit/assets/doc_library/04-
pnr/New%20Doc%209944%201st%20Edition%20PNR.pdf

- Air Transport & Travel Industry: Principles, Functional and Business Requirements
PNRGOV
- Passenger and Airport Data Interchange Standards: EDIFACT Implementation
Guide, PNR Data Pushed to Other Authorities, PNR GOV Message
- Passenger and Airport Data Interchange Standards: XML Implementation Guide,
PNR Data Pushed to Other Authorities, PNR GOV Message
http://www.wcoomd.org/en/topics/facilitation/instrument-and-tools/tools/api-pnr.aspx

As mentioned earlier, Annex 9 to the Chicago Convention contains Standards and

Recommended Practices (SARPs) on API and PNR. Annex 9’s Standards have a conditional
binding force on ICAO’s Member States.

Page 7 of 16
Annex to II
doc. PM0067E1

For example, some of the existing Standards are as follows:

- Each Contracting State that introduces an Advance Passenger Information (API)

system under its national legislation shall adhere to international recognized standards
for the transmission of Advance Passenger Information.
- 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.
- Contracting States shall ensure that only those data elements that have been
incorporated into the UN/EDIFACT PAXLST message are included in the national
programme’s requirements or follow the WCO’s Data Maintenance Request (DMR)
process for any deviation from the standard.

6. PRIVACY
API data is collected by aircraft operators to ensure aviation safety and security, and to meet the
requirements of border control agencies, while PNR data is collected by aircraft operators for
their own business purposes and then shared with states. Once the data is acquired by the aircraft
operator, it is stored in the automated reservation and departure control systems of the carrier or
a third party service provider.

An API and/or PNR programme is designed to enhance the security of a country. To achieve
such objectives, a state must first focus on how to obtain and collect passenger information. In
many countries, passenger information is considered sensitive data and must be handled
appropriately. Once a passenger’s personal information has been collected, controls may also
need to be set up in order to manage the use, access, retention, disclosure and deletion of
passenger data. In addition, further special handling procedures may be needed to protect aircraft
operators’ confidential business practices and information.

If it is expected that passenger information will be shared with other internal or external
agencies, Information Sharing Arrangements or Memoranda of Understanding (MOUs) may be
required with different control agencies in your country or abroad and with aircraft operators,
and it is therefore important to account for this when planning your development timeline.

Identifying the scope of your API and/or PNR programme will help you to determine which
passenger data elements will need to be collected. It is possible that not all of the available
elements from the API and PNR data sets that have been approved by the air industry, the WCO
and ICAO will be required to meet the needs of your programme.

Page 8 of 16
7. FUNDING
The development of an API and/or PNR programme will involve initial costs and require
ongoing funding and resources to ensure that the programme can be developed and maintained in
line with the security and risk management objectives of the country and its border control
agencies.

It is recommended that you conduct a cost benefit analysis to identify the options available and
enable you to decide whether to build and maintain the technical and operational solutions in-
house or to engage an external provider. It is possible to include a mixture of in-house and
external solutions.

With the push to have all countries develop an API and/or PNR programme, in some cases
funding is being arranged at state level and may include funds from outside sources.

However, in other cases, the development of an API and/or PNR programme is needed to meet
the objectives of more than one government agency and funding may be sought from internal
sources. For example, if the customs, immigration and air transportation functions are
undertaken by separate entities within your government, and they will all benefit from an API
and/or PNR programme, then funding to build the programme may come from multiple sources.
A “Single Window” concept, whereby the data is collected once and distributed to multiple
domestic recipient agencies, can be beneficial for a multi-agency programme.

8. PROJECT MANAGEMENT CHECKLIST

Ensuring that you have a well-structured approach to establishing and implementing an API
and/or PNR programme, with due attention paid to how its objectives can be met, will mean that
you will be much better placed to ensure successful implementation.

The following steps provide an overview of what to consider when building and implementing
an API and/or PNR programme:

1) Appoint a Project Manager.

2) Take the budget into consideration and appoint project team members from
participating departments and organizations.
3) Determine the benefits and objectives of the programme to be implemented. This
includes developing a project strategy and business case.
4) Define the scope and legal basis of the programme to be implemented.
5) Review and analyse international documentation, industry standards and regulatory
guidance.
6) Define IT requirements, including whether the development will be done in-house or
by a third party provider.
7) Plan a realistic project timeframe, including policy making steps.
8) Develop a communications plan.

Page 9 of 16
Annex to II
doc. PM0067E1

9) Begin to engage and consult with internal and external stakeholders and partners and
convene periodical meetings.
10) Design and develop business and technical processes. Once developed, begin
operational and system testing to ensure that what has been developed meets
programme objectives.
11) Complete all training, provide for ongoing service support and prepare for go-live.
12) Conduct a post-implementation review to ensure deliverables and objectives were
met, and then close the implementation project.

The following gives you items to think about once your system has been developed and
implemented:

1) Evaluate and plan for data quality assurance and compliance.

2) Plan and budget for a process to enable regular upgrades and system enhancements.
3) Future possibility of expansion to other modes of transport (land, rail or maritime), or
other programmes (Interactive API).

9. SYSTEM DEVELOPMENT

Before you can start developing the technical system, you need to identify the business
requirements that the automated system is being built to meet.

This section, as well as sections 10, 11, 12 and 13 provide a more detailed outline of the business
and technical components that are necessary to meet the objectives of the project and will also
help you to identify technical system requirements.

Data collection and transmission options

By now, you should have decided whether you will be developing an API and/or PNR
programme. You now need to determine how you are going to collect the passenger information
from aircraft operators. The choice of whether to build a direct interface in-house or to engage
with a third party service provider can be determined by a number of factors including cost,
timeframe, objectives and available in-house technical expertise.

There are multiple Electronic Data Interchange (EDI) techniques available for acquiring
passenger information, and many states use more than one. Message Queue (MQ) is currently the
safest and most reliable method, however others are available:

- Web-based applications or services

- E-mail
- Type B
- FTP/SFTP
- MATIP
- Contract with a third party service provider

Page 10 of 16
Section 4, above, specifically outlines the use of industry standards for the provision and
acquisition of API and PNR data. The use of the PAXLST and PNRGOV industry standard
message formats contributes significantly to reducing the timeframe involved in developing the
programme. Many aircraft operators and states worldwide have already adopted these standards,
and consulting them about lessons they have learned will assist you in your research and
development.

Data processing and display

In addition to building an IT solution used to acquire passenger information, you will also need
an IT solution that displays the passenger information to enable border control agencies to
analyse the data for risk assessment purposes. Any information you receive will need to be
cleansed in line with requirements or restrictions on sensitive data and to ensure that the data is
displayed in a more user-friendly format

Data protection and privacy legislation already exists in many countries in order to protect a
person’s right to privacy. For this reason, it is critically important that data protection be
considered when automating the collection, processing and display of passenger information.

“Push” vs “Pull” methodology

Traditionally, countries would obtain PNR data by accessing aircraft operator reservation
systems and “pulling” (screen scraping) passenger information and saving it to their risk
assessment applications. As a result of privacy concerns, however, there has been a shift to the
“push” method for data acquisition. The “push” method requires aircraft operators to “push”
passenger information, using industry standard formats, to the requiring country by using their
own IT solution. Doc 9944 recommends that a State consider the adoption of the “push” method.

Determining whether to use the “pull” or “push” methodology will depend on your objectives
and business requirements, as well as other factors that may favour you choosing one method
over the other (i.e., data privacy and legal directives).

System configuration and architecture

To ensure that the appropriate infrastructure is in place to support a new API and/or PNR
programme, you must first look at any existing hardware, software and databases that your
country may have that can be used or developed further. This will make it easier to decide which
additional hardware and software products you need.

Since there are multiple IT solutions available to choose from, budget, timeframes and the
programme objectives must be considered when setting out the definitive requirements for the
architecture of your system.

Preparing business and technical documentation

Page 11 of 16
Annex to II
doc. PM0067E1

Once you have chosen your IT solution, you should start to document business and technical
requirements. These requirements will specify exactly what the expected outcomes are to be
from a business perspective (identify high-risk passengers while facilitating travel for low-risk
passengers) and from a technical perspective (automated risk assessment).

This documentation will significantly assist you in preparing test cases and packages that will be
used internally to ensure that the business and technical objectives of the project have been met.

System security and user access

The very nature of an API/PNR programme means that access to passenger information is very
often restricted to only those individuals that require this information to perform their day-to-day
activities.

For this reason it is necessary to have strict individual user access profiles established for each
person that has access to passenger information. With these user access profiles, an audit trail
can also be established to ensure that data protection commitments are being upheld.

Continuity and disaster recovery plan

Although programmes are built on the premise that they will be available 24/7, 365 days a year,
you should also put in place some precautionary procedures to follow in the event of a system
outage or loss of passenger information. These system and support procedures should include
manual back-up processes and the ability to retrieve back-up data to stabilize the programme.

The impact that a system outage or slow-down may have on aircraft operators’ ability to remain
compliant with legislative requirements should also be taken into consideration.

10. INDUSTRY ENGAGEMENT

At an early stage in the analysis, development and implementation of your programme, in
addition to your internal consultations and discussions, it is highly recommended that you
develop and maintain an ongoing communication strategy with aircraft operators and other
external industry partners, including other countries, international organizations (WCO, ICAO,
IATA) and service providers. In order to manage engagement with industry, it may be beneficial
to use the “Carrier Account Management” model, whereby support personnel are assigned to
specific air carriers and maintain an ongoing relationship with them.

Through these consultations you will gain invaluable information on lessons learned by aircraft
operators, service providers (vendors), and other countries who have already implemented an
API and/or PNR programme. In addition, they will be able to provide you with an insight into
cutting-edge technology, and provide you with more technical information on how to implement
an API and/or PNR programme.

Page 12 of 16
As the infrastructure of your programme begins to take shape, one-on-one consultation with each
aircraft operator that will be affected by your new programme requirements will allow you to
learn more about their business model. This, in turn, will enable you to establish a testing
strategy, create technical guidance for aircraft operators, decide on a realistic timeline, and
develop an action plan that will help to bring aircraft operators on board at a specified time in a
way that meets your project needs and fits in with your planned timeframe.

11. COMPLIANCE
The success of any API and/or PNR programme is dependent on the quality and quantity of
passenger data that is received, processed and used for risk assessment. Many countries have
implemented legislation and regulations that set out data provision requirements alongside
penalty and mitigation regimes that may/will be imposed on aircraft operators, if the quality and
quantity of passenger information is not maintained.

Data quality has quickly become a high priority for both states and aircraft operators. States
require high quality data in order to identify high risk passengers and many aircraft operators
strive to ensure continued high quality data in order to avoid penalties and fees, but also to
ensure the safety of their aircraft, crew and passengers and to avoid errors in the targeting
process as a result of poor quality data.

In addition, incentive programmes may be considered for highly compliant aircraft operators
who continually meet the obligations of your API and/or PNR programme. This would ensure
continued compliance and may encourage those less compliant to strive for a higher level of
conformity.

12. CREATING/IMPLEMENTING A PASSENGER INFORMATION UNIT (PIU)

To support an effective API and/or PNR programme a PIU must be established to support the
legislative framework that has been implemented by your country. The PIU has the critical task
of identifying high risk passengers, based on the passenger information received from aircraft
operators.

Targeting officers will need to be trained to identify, interpret, research and analyse a significant
volume of diverse and complex information to determine the level of risk posed by a passenger
and pursue appropriate action. Below is a high-level overview of what is needed to build and
support a PIU. It is strongly encouraged that you discuss more detailed requirements for setting
up a PIU with other countries that already have a well-established programme.

Infrastructure

When establishing a PIU it is necessary to identify the best physical location to conduct risk
assessment activities. It may be feasible to have just one national PIU or you may wish to set up
PIUs across national airports. Either way you must ensure that the day-to-day objectives of

Page 13 of 16
Annex to II
doc. PM0067E1

detecting and interdicting high-risk passengers at the earliest point in the travel continuum can be
met.

The facility may also require the following:

- IT systems and on-site security
- Heating/air conditioning
- Transport options (train, bus, parking facilities)
- Housing for other government agencies (police, border control, etc.).

Human Resources

Based on the scope of the programme you are implementing, you will need staff to fill the
targeting officer, support and management positions in the PIU. For example, if your programme
operates on a 24/7, 365 days a year basis, then it is possible that you will need three times the
number of staff needed for a normal 8 hour working day.

The positions that these staff occupy may range from office support to senior management
levels, and cleaning and maintenance staff. Of critical importance is the need to create a unit of
specialized targeting officers and it is recommended that these individuals come from a cross-
section of agencies that will allow them to deal with customs, immigration and police issues. If
the programme is to be integrated with programmes or databases from other agencies within your
government, it may be necessary to include staff from those agencies in your human resource
and infrastructure planning as well.

The PIU must have a clear governance structure detailing, among other aspects, how different
partner agencies will cooperate to successfully manage the PIU.

To ensure that the programme can be established and well maintained, resource and staffing
requirements need to be well documented when determining your initial and ongoing budget
requirements.

Scope of Functions

To ensure the PIU can meet its objectives, it may be best to separate the PIU into different
functioning and operational areas. These areas may include:

- technical and infrastructure support;

- programme support (legislation and policy);
- recruitment and training;
- communication, including stakeholder and client engagement;
- inbound/outbound passenger risk assessment;
- data quality and compliance; and
- corporate and stakeholder reporting.

Page 14 of 16
Training

The development of training materials is required to ensure that internal staff and the newly
appointed targeting officers can process passengers using the automated IT solutions that have
been put in place and to guarantee that the operational requirements that are needed to support
the development, implementation and the ongoing maintenance of the programme are in place.

In addition, it is recommended that technical specifications and training materials be developed

for aircraft operators. This material will assist them in their development activities that will allow
them to comply with your programme. The material can also be used by aircraft operators to
train their staff on the legislative and operational requirements of your API and/or PNR
programme.

Of significant importance is the need to have an ongoing training programme in place for new
and existing targeting officers that will allow them to stay on top of new developments and
understand new trends and areas of concern.

Interagency Cooperation

To provide for a very effective programme that supports the prevention, detection and
prosecution of terrorist acts and serious crime, cooperation with other agencies may be required.
Early engagement will significantly contribute to a successful and robust API and/or PNR
programme.

The integrity of an API and/or PNR programme can be further enhanced if passenger
information can be verified and validated against other enforcement programmes within your
state.

Cross-border Coordination

As you start to develop an API and/or PNR programme, there are significant benefits to
coordinating with other cross-border states on the technical and operational components of your
programme. For example, if a bordering state already has an established API and/or PNR
programme, it is likely that their business model is similar to yours and learning from their
experiences could be very useful when defining the scope of your own programme.

If the bordering state does not have an established API and/or PNR programme, by coordinating
your research and development, you may find savings.

In addition, during the research stage and while finalizing the legislative infrastructure necessary
to support an API and/or PNR programme, the need for sharing information with other states
should be discussed and appropriate data sharing and data protection requirements included if
necessary. The sharing of passenger information between states can further support an API
and/or PNR programme and help to confirm or disprove the level of risk presented by a

Page 15 of 16
Annex to II
doc. PM0067E1

passenger. Additionally, the benefit of sharing passenger information between states significantly
helps to support the safety and security of the citizens and the border of that state.

13. REPORTING

Preparing reports is extremely useful in being able to gauge the success and integrity of your
programme. Reports can be used to identify trends and areas of interest based on the results of
risk assessment that has been completed over a period of time, and to allocate resources in areas
of high risk. For example, producing statistics on the number of flights or travellers that have
arrived in your country can help to ensure that you have the proper infrastructure in place and
that sufficient resources are being deployed to manage current/increasing volumes of air travel.

Reports can also be developed to provide specific details or summaries of passenger risk
assessments (e.g., number of targets issued, number of passengers subject to enforcement actions
/ arrest, number of penalties/fees issued, etc.). Aircraft operator compliance reports can also be
generated to identify areas of concern related to data integrity. These reports will allow you to
work with aircraft operators on areas where there is a need for improvement.

In addition, reports can be developed to monitor and ensure the integrity of your IT solutions so
that you can continue to maintain a high level of performance. For example, calculating
processing times can highlight where there are system performance issues. Reports can also
provide statistics on what the peak times are for incoming messages and thus determine when
system performance is critical. Tracking system interruptions and outages will help you to better
analyse your system’s performance and identify when aircraft operators may not be compliant.

14. CONCLUSION

This document has provided a very high-level overview of the key elements that need to be
researched, analysed, documented and developed in order to “build” an API and/or PNR
programme. From an initial concept or idea to the migration of aircraft operators onto your
system, this document will serve as an introductory document to the “How to “use” an API /
PNR Programme” document, which will provide further guidance on how to process the
incoming data.

Throughout this document there have been references to existing documentation, standards and
API and/or PNR programmes. If you are considering building an API and/or PNR programme
you are strongly encouraged to read the documentation that is available on the WCO, ICAO and
IATA websites. Familiarizing yourself with the technical industry message standards will serve
you well as you begin your discussions with aircraft operators and other air industry partners.
There are multiple lessons to be learned from colleagues in other countries that have already
implemented an API and/or PNR programme, and in some cases an Interactive API programme.
Learning from them will prove to be invaluable, especially when looking to develop a PIU.

*
* *

Page 16 of 16
 Annex III to
doc. PS0067E1

ICAO WCO IATA

Management Summary on Passenger-related Information

[‘Umbrella Document’ version 2.0 – July 2017]

Published by the International Civil Aviation Organisation (ICAO), the World Customs
Organisation (WCO) and the International Air Transport Association (IATA)

Introduction

1. The purpose of this document is to provide a high-level executive brief that describes
and distinguishes between the different sources and systems for passenger-related
information that is required to be provided by international aircraft operators to border
control agencies. General aviation operations are excluded from the scope of this
executive brief, although the term “aircraft operators” is used throughout the
document for the sake of consistency. Consequently, this document should not be
considered a foundation for the evolution of API and PNR requirements for
application to all international air transport.

2. A growing number of States require aircraft operators to provide information on

passengers that intend to travel to, from or overfly their territory. The information
usually exists in the aircraft operator’s reservation system and departure control
system operated by the aircraft operator. Some States also require passenger related
information from other modes of transport.

3. 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, together with the need for more efficient passenger flows at airports,
it is necessary to develop more intelligent and efficient methods to check passengers
and their baggage. 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 or number) of checks at immigration or cross border desks and baggage claim
areas.

4. Mainly as part of increased border controls, passenger-related information, available

in the systems of the aircraft operators, are being used by border control authorities to
manage in advance the cross border movement of persons and goods. Security-
related controls are increasingly applied even before the passenger boards the
aircraft at the beginning of the journey. In any case, such controls have to 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. Without substituting for border
controls these measures also facilitate the flow of low-risk passengers at airports.

5. The use of passenger related information is often challenged by persons and

organizations that are concerned about the protection of the privacy of personal

III/1.
Annex to III
doc. PM0067E1

information. API data is generally not required for aircraft operator processes, thus it
is only collected and stored in case of a legal requirement. In most jurisdictions, it is
only permissible to use passenger-related information for law enforcement purposes,
when ensuring proper guarantees for the protection of such information that
authorities receive. This ensures that the privacy of the passenger is safeguarded and
misuse is prevented.

6. Adoption of Resolutions 2178 (2014) and 2309 (2016) by the UN Security Council,
which encouraged States to require airlines to provide passenger related Advance
Passenger Information, will see the increase of passenger information regimes
globally. Requirements based on standards enable seamless, cost efficient and timely
implementation.

Passenger-related information

7. The flow of passenger-related information from the aircraft operators to border control
authorities can be divided into three main streams:

1. Passenger Name Record (PNR)

a. Reservation Data
A reservation can be made from approximately 360 days before departure
until such time prior to departure the aircraft operator has decided they can
no longer operationally process new passengers and ensure an on time
departure (depending on the airport and route). Approximately 48 to 24
hours before departure all PNRs are transferred from the aircraft operator
Reservation System to the Departure Control System (DCS) 1. In the DCS
the operational handling of the flight will take place, at check-in (e.g. intake of
baggage and issuing of boarding passes).

b. Passenger Manifest
From information available, the passenger manifest can be generated. When
States require a passenger manifest, the information requirements are
limited (ICAO Annex 9, Standard 2.13 and Appendix 2). This passenger
manifest can be sent digitally or in hard copy. Some aircraft operators
forward the passenger manifest to the airport of destination for operational
purposes (passenger and baggage handling). Annex 9, Standard 3.48.7
requires that States requiring passenger data to be transmitted electronically
shall not also require a passenger manifest in paper form.

2. Advance Passenger Information (API)

As API data is not generally required for aircraft operator processes, it will
normally be collected and stored only in case of a legal requirement 2. Depending
on the timeframe of collecting the data, two methods are employed:
a. the data can be entered manually:
i. at the moment of reservation by the travel agent or by the passenger
entered in the reservation record;
ii. at the moment of check-in by the passenger on the internet or mobile
application check-in (entered into the API section of the DCS;
b. the data can be entered automatically from the machine readable zone of
the travel document, if available:

1
A number of aircraft operators use one system, which accommodates both PNR and DCS information.
2
EU based aircraft operators are bound by strict privacy legislation and are therefore only allowed to collect and disclose API
data in case of a legal obligation

III/2.
 Annex III to
doc. PS0067E1

i. by the passenger at the kiosk check-in;

ii. by the aircraft operator agent at the desk check-in;
iii. at the moment of boarding(for exceptions) by the aircraft operator
agent.

The registration by the passenger at the moment of reservation is operationally

the best moment. Manually entered information has the risk that incorrect
information is supplied (e.g. a zero instead of the letter ‘O’). The best option from
a data quality perspective is the collection of the machine-readable information
via an automated process.

Passenger Name Record (PNR)

8. PNR information is the generic name given to records created by the aircraft
operators for each flight a passenger books. PNR records contain information
provided by the passenger and information used by the aircraft operator for their
operational purposes. PNR information may include elements of API. PNR provides a
mechanism for all the different parties within the aviation industry (including travel
agents, aircraft operators and handling agents at the airports) to identify each
passenger using a common format, and have access to all information relevant to
his/her journey; departure and return flights, connecting flights (if any) and special
services required on board the flight.

9. The amount and the nature of the information in a PNR record can vary from aircraft
operator to aircraft operator and from passenger to passenger, often depending on
how the reservation was made. A PNR may contain as little information as a name, or
may contain full address, contact details, credit card information and all data
pertaining to the booking.

10. A passenger or a travel agent may make a reservation for a flight with an aircraft
operator even if a visa application or travel authorization has not been submitted.
Passengers are able to make reservations in various ways, most commonly through
direct contact with the aircraft operator via its website, mobile application, telephone
reservations office, travel agents or via aircraft operator partners. Not all of the
available PNR information involved in this reservation process is routinely transferred
to the aircraft operator’s PNR system.

11. PNR records are created at a time when a passenger requests a reservation on a
flight or series of flights, typically from one year before intended departure date up to
the day of departure for immediate travel. Information contained within the PNR may
increase or be amended between time of creation and time of travel.

12. The basic information of a PNR may include:

a. passenger name (first, last and title);
b. details of the intended travel;
c. method of payment details, which may include (partial masked) credit card
information;
d. special Service Requests (SSR) such as preferred seating, assistance for
persons with reduced mobility etc., as requested by the passenger;
e. Contact information;
f. frequent flyer number;
g. travel document information, which may include biographic information, as part of
the obligation for aircraft operators to provide API information to the border
control authorities in the country of departure or destination;
h. additional remarks or comments (if any).

III/3.
Annex to III
doc. PM0067E1

13. PNR information is used by governments to conduct analysis that helps to identify
possible high-risk individuals that may have been otherwise unknown to government
authorities and make, where appropriate, the necessary interventions. PNR
information can be provided by aircraft operators by sending the information
electronically (“Push” method) or allowing the appropriate authorities to access the
parts of their reservation systems where the PNR information is stored (“pull”
method). However, internationally there is an agreement to utilize the “Push” method,
for data privacy reasons.

14. To ensure interoperability, relevant international messaging standards have been

used to develop a push method message format called PNRGOV. PNRGOV is the
international standard that must be used for the transmission of PNR information to
the appropriate government authorities.

15. The information included in PNR records may not only relate to reservation
information but also information gathered at check-in when the passenger presents
himself to the aircraft operator representatives at the airport. Check-in Procedures are
normally undertaken using the DCS of aircraft operators or the contracted handling
agent, designed specifically to perform airport handling functions.

16. Check-in generally describes a procedure by which an aircraft operator is alerted to a

confirmation that a passenger intends to utilize the seat for which a reservation is held
and to actually board and travel as intended. This procedure may vary significantly
between different aircraft operator business models and airports. This may include
self-service check-in by internet, mobile telephone, airport kiosk or through-check
when travelling on a sequence of connecting flights for which participating aircraft
operators have commercial arrangements in place, including code-share agreements.
Conventional agent check-in at the airport is decreasing as self-service options
become more available and utilized.

17. Given that DCS systems are normally deployed in airport environments to facilitate
functions associated with airport activity, check-in records are created very close to
departure, normally not earlier than approximately 48 hours, although this time will
vary by aircraft operator system business model.

18. The processes implemented by aircraft operators vary and some separate 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 at the airport.
Where appropriate, and dependent on each airline’s business practice, the check-in
process may involve:
a. seat allocation or confirmation of a previously requested seat assignment;
b. recording information such as number of pieces or weight of baggage which is
assigned to the hold of the aircraft;
c. collection of API (biographic information), to comply with any API program of the
country/countries involved in the journey for which check-in is performed;
d. confirmation or action of any special requests;
e. some but not all systems may indicate whether passengers form part of a group
or party.

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

III/4.
 Annex III to
doc. PS0067E1

20. When necessary (for exceptions) check-in (seat assignment) and/or the collection of
API data can be performed during the boarding process. Examples may include:
a. passengers who are in transit and connecting from another flight where check-in
was not performed due to technical restrictions between aircraft operator systems;
b. API data was not previously collected because a data sharing agreement is not in
place due to technical or legal reasons.
It is perhaps noteworthy that, where seat assignment is offered by aircraft operators 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.
Passengers may not occupy their assigned seat once on board.

Advance Passenger Information (API)

21. To facilitate the growth of air passenger traffic, API systems were developed by
border services. The scope of the use of these API systems is widening as it is
increasingly used for security measures. Identification Data of passengers are sent to
authorities in advance (before the arrival of passengers) and can be processed
against computer databases before the arrival of the passengers, resulting in faster
clearance of low-risk passengers, improved compliance and reduced inspection time.

22. API includes identification details from the passport or other travel document of the
passenger together with basic flight information. For the majority of the travellers, the
identification details can be obtained from the machine-readable zone of Machine
Readable Travel Documents (MRTDs), e.g. passports. The specifications for the
machine-readable travel documents are found in ICAO Document 9303.

23. Aircraft operators are responsible for the accuracy, completeness and timeliness of
transmission of API data. However, the accuracy of submitted API data will be
affected by the time of transmission required by a government authority. Passenger
API data may be collected at time of reservation or entered manually by the
passenger during self-serve web or mobile check-in. If the authority requires the API
data to be transmitted at time of check-in, the travel document information of these
passengers will not have been verified, as an aircraft operator representative has yet
to examine the travel documents. Passengers using self-service check-in will
normally have their travel documents examined by an aircraft operator representative
when depositing luggage or at the gate prior to boarding if the passenger has no
luggage. At this stage aircraft operators may elect to validate the accuracy of API
data previously supplied by the passenger and, if necessary, correct and resubmit the
validated API data to the authorities.

24. A definition of Advance Passenger Information (API) System can be found in Annex 9
to the (ICAO) Convention on International Civil Aviation (“Chicago Convention”):

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.

25. A standardized API system should include the following key elements:
a. an API system should be user-friendly, seamless and facilitate the travel of
passengers as a result of API data analysis;
b. an API system should, as an important part of the required API data, contain the
data from the machine readable zone of travel documents (refer ICAO Document
9303);
c. an API system should take into account the interests of key stakeholders;

III/5.
Annex to III
doc. PM0067E1

d. 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 Border Control Authority;
e. border Control Authorities should work together to respect the data requirements
of different Control Authorities;
f. governments should ensure that data is transmitted from an aircraft to a
government single window to avoid multiple requests from a government. The
single window will perform an analysis of the data and enable other government
agencies to have access to that data where the appropriate data sharing
agreements and legal grounds are in place;
g. management of contractors and costs in a collective way to ensure unilateral
systems are capable of operating in bilateral and multilateral environments, taking
account of international recognised standards to achieve a harmonised
environment;
h. with respect to the message format for transmission of API and interoperability
with aircraft operators, per the Guidelines on Advance Passenger Information
(API) published by WCO/ICAO/IATA, systems should be developed to support the
use of the UN/EDIFACT PAXLIST messaging standard. However, this should not
be seen as constraining the ability to adopt other internationally agreed standards
in the longer term;
i. API systems should seek to minimize the impact on existing aircraft operator
systems and technical infrastructure;
j. an API system should be capable of round-the-clock operation, with contingency
procedures in place to minimize disruption to aircraft operator operations in the
event of system failure.

26. Border Control Authorities choosing to introduce API systems should adopt the
guidelines contained in this document. However, nothing in this document is to be
construed as contradictory to national legislation or regulations.

Interactive API (iAPI)

27. The API approach is being gradually superseded by more demanding approaches in
light of increased threats to security. For example in some States, a more
sophisticated form of API is being deployed as an instrument to confront potential
risks posed by aircraft operator passengers, especially in regard to aviation security,
immigration requirements, drug trafficking and other threats to national security. This
form of API called interactive API (iAPI) is an additional means of enhancing border
security. A distinguishing feature of iAPI is that it provides for passenger-by-
passenger real-time interactive interchange of electronic messaging between the
aircraft operator and the border control authority in the country of departure or
destination. At the instant a passenger checks-in to a flight, passenger information
flows from the aircraft operator’s DCS to the border control authorities, who in turn
transmit (in real time) an electronic message response to the aircraft operator
permitting or preventing the boarding of the passenger. This type of system is
referred to as “Board/No Board”, “Red Light/Green Light System” and “Authority to
Carry”. The aircraft operator does not issue a boarding pass until a response is
received from the government.

28. A definition of interactive API (iAPI) can be found in Annex 9 to the Chicago
Convention:

An electronic system that transmits, during check-in, API data elements collected
by the aircraft operator to public authorities who, within existing business

III/6.
 Annex III to
doc. PS0067E1

processing times for passenger check-in, return to the operator a response

message for each passenger and/or crew member.

29. iAPI of benefit to aircraft operators as it reduces the exposure of the aircraft
operators to penalties and removal and detention costs associated with bringing
improperly documented passengers into the country of destination. iAPI may improve
data quality issues as a result of the passenger-by-passenger real-time exchange of
data.

30. Implementation of iAPI poses certain technical challenges in terms of system

availability, training of ground handling staff, outage management, and reliability of
electronic message transmissions, managing service levels, and maintaining data
quality by systems operated by both the aircraft operator and State.

31. The WCO/IATA/ICAO Guidelines on Advance Passenger Information are intended to

address the structure and processes relating to iAPI systems developed internally by
a State, or which are developed by a commercial service provider based on the
State’s technical specifications. The WCO/IATA/ICAO Guidelines are not intended to
address systems developed entirely by commercial service providers and then
marketed to a State as a turn-key data exchange solution.

Use of passenger-related information by immigration authorities

32. Immigration authorities are responsible for facilitating the legitimate entry and exit of
passengers and to prevent illegal immigration. With the use of passenger related
information, border control authorities can make a decision if a passenger can be
allowed to enter or leave a country before the passenger has presented himself to the
border control authorities. This can limit the number of physical inspections and
facilitate the flow of passengers at an airport.

Use of passenger-related information by customs authorities

33. In most countries the customs authority is responsible for monitoring the cross border
movement of goods and to prevent the entering of prohibited, restricted and regulated
goods. Part of that responsibility includes inspection of carry-on and checked-in
baggage. Passenger information has proved to be useful when following a risk-based
approach in identifying high-risk passengers and to secure and facilitate the entry and
exit of the baggage of passengers with minimal intrusive inspections.

Legal basis

34. The obligation for passengers and aircraft operators to provide passenger-related
information must be based on legal provisions, which should include rules for the
collection, use and storage of passenger related information, together with measures
to protect the information and safeguard privacy.

35. On an international level, basic rules for the use of API, iAPI and PNR are developed
in ICAO Annex 9─Facilitation to the Convention on International Civil Aviation (Chicago
Convention, 1944) and the Revised Kyoto Convention of the WCO. For API, Standard
3.48 of Annex 9 obliges each Contracting State that introduces an API system under
its national legislation, to adhere to international recognized standards for the
transmission of API. Recommended Practice 3.48.8 has a similar recommendation, for
iAPI systems.

III/7.
Annex to III
doc. PM0067E1

36. The Revised Kyoto Convention states in Recommended Practice 8 of Specific Annex
J, Chapter 1 that Customs, in co-operation with other agencies and trade, should
seek to use internationally standardized advance passenger information, where
available, in order to facilitate the Customs control of travellers and the clearance of
goods carried by them.

37. On PNR information, Recommended Practice 3.49 of Annex 9 states that Contracting
States requiring PNR access should align their data requirements and their handling
of such data to guidelines contained in ICAO Document 9944.

PNR Guidelines

38. The PNR Guidelines were developed by ICAO in close cooperation with IATA and the
WCO. Currently, the PNR Guidelines include an explanatory text for the use of PNR
information and an Annex with a maximum list of PNR data. The first version of the
PNR Guidelines was published in 2006. The latest edition of the PNR Guidelines was
published in 2010 as ICAO document 9944. The cooperation between the three
organizations was consolidated by the creation of the Contact Committee for the
WCO/IATA/ICAO Guidelines on Advance Passenger Information (API) and
Passenger Name Record (PNR) Data. Their goal is to secure uniformity in the
interpretation and the application, to monitor the implementation and to consider any
amendment to these guidelines.

API Guidelines

39. The API Guidelines were developed in 1993 under the auspices of the WCO and
IATA. In 2003, ICAO joined the development of the API Guidelines. Further versions
of the API Guidelines have been published in 2010 and 2013. The API Guidelines
comprise an explanatory section for the use of API, including iAPI details. The
Guidelines also consist of a maximum list of API data elements, an Annex with the
internationally recognised electronic UN/EDIFACT message (PAXLST) and an
implementation guide for the PAXLST message. The iAPI response message details
for an UN/EDIFACT message (CUSRES) are also included in a separate Annex to
the API Guidelines.

Electronic exchange of passenger related information

40. The electronic exchange of passenger related information is a prerequisite for the
efficient application of API, iAPI and PNR information. However, various data
exchange requirements, often in different message formats and at various times,
have resulted in the proliferation of sometimes conflicting national requirements,
causing unnecessary cost and compliance burdens for aircraft operators.
Standardized messages for API, iAPI and PNR are necessary to be able to efficiently
exchange information between aircraft operators and border control authorities.

41. PAXLST and CUSRES requirements, used in API and iAPI transmissions are in the
approved UN/EDIFACT (United Nations rules for Electronic Data Interchange For
Administration, Commerce and Transport) format. New message formats for
transmission of PAXLST and CUSRES should be approved so as to function as
internationally recognized standardized messaging. The PNRGOV message has
been developed for reporting PNR data. This message is based on EDIFACT rules
and syntax. The message is supported by an aircraft operator industry directory
identified as the PADIS directory.

III/8.
 Annex III to
doc. PS0067E1

42. The UN/EDIFACT rules comprise a set of internationally agreed standards,

directories and guidelines for the electronic interchange of structured data, and in
particular that related to trade in goods and services between independent,
computerized information systems. The PAXLST message is the standardized
message for API and iAPI messages. The CUSRES message is the standardised
response message for iAPI. The PNRGOV message is the standardised message for
PNR information.

43. The standardised messages are also being supplemented by modern message
techniques, such as international XML standards or web-based applications.

International cooperation

44. The developments on API and PNR are discussed and coordinated within each of the
three organizations WCO, IATA and ICAO. Interested governments and other
stakeholders, including aircraft operators , take part in these discussions with the aim
to further develop common Guidelines and to maintain the standardised messages.
More specifically, the work related to the maintenance of the API PAXLST and iAPI
CUSRES message and the PNRGOV message is carried out by the contact
committee for the WCO/IATA/ICAO guidelines on advance passenger information
(API) and passenger name record (PNR) data.

NB: This document does not address state requirements for crew-related information.

III/9.
Annex to III
doc. PM0067E1

Structure of the Passenger Information Guidelines and Messages

Umbrella document:
Management Summary on Passenger-
related information: PNR, API and iAPI

ICAO/WCO/IAT WCO/IATA/ICA
A O
PNR API
Guidelines and Guidelines and
li t f t d d li t f t d d

PNRGOV PAXLST and

Message CUSRES
Messages

PNRGOV PAXLST/CUSR
Message ES
Implementation Message
Guide Implementation
(MIG) G id

XML XML
Schema Schema

______________

III/10.