Airline-GG Interface Specification-V7.1 PDF

iBorders Advance Passenger
Processing System
Airline/GG Interface Specification
V7.1
May 2019
© SITA 2019
Commercial-in-Confidence
© 2019 SITA. All Rights Reserved
The contents of this document constitute confidential and proprietary information of SITA and may not
be used, copied, stored or disclosed otherwise than in accordance with the express provisions of the
agreement entered into with the owner and pursuant to which this document has been provided or, in
the absence of any such agreement or provisions, then only in accordance with the express written
consent of the owner.
Any breach or threatened breach of the above terms or of the owner’s intellectual property rights will
result in action to restrain the breach and a claim for damages.
Disclaimer
Every effort has been made to make this document as complete and as accurate as possible. Any
problems or perceived difficulties with the document should be reported to SITA prior to reliance on
the document. SITA does not warrant that this document is error-free or is suitable for the reader’s
purposes and the reader should rely on their own skill, expertise and judgment in utilizing this
document. The information in this document is subject to change without notice.
Advance Passenger Processing System Airline/GG Interface Specification
Table of Contents
Disclaimer .................................................................................................................. 2
List of Figures ............................................................................................................ 7
List of Tables ............................................................................................................. 7
1. Introduction ..................................................................................................... 9
1.1 Purpose of this Document ............................................................................................. 9

1.2 Scope of this Document ................................................................................................ 9
1.3 Readership .................................................................................................................. 10
1.4 Related Documents..................................................................................................... 10
1.5 Contacts ...................................................................................................................... 11
2. Message Types ............................................................................................. 12
2.1 Message Type: Check-in Request (CIRQ).................................................................. 12

2.1.1 Purpose ............................................................................................................................. 12
2.1.2 Message Structure ............................................................................................................ 13
2.1.3 Message Construction ...................................................................................................... 13
2.1.4 Message Processing ......................................................................................................... 14
2.1.5 Recommended Airline Implementation ............................................................................. 15
2.2 Message Type: Check-in Response (CIRS) ............................................................... 20

2.2.1 Purpose ............................................................................................................................. 20
2.2.6 Message Structure Scenarios ........................................................................................... 27
2.3 Message Type: Movement Cancellation (CICX) ......................................................... 29

2.3.1 Purpose ............................................................................................................................. 29
2.4 Message Type: Movement Cancellation Confirmation (CICC) ................................... 32

2.4.1 Purpose ............................................................................................................................. 32
2.4.6 Message Structure Scenarios ........................................................................................... 36
2.5 Message Type: Manifest Request (CIMR) .................................................................. 37

2.5.1 Purpose ............................................................................................................................. 37
2.6 Message Type: Manifest Request Acknowledgement (CIMA) .................................... 41
Commercial-in-Confidence V7.1 (May 2019)

Page 3
2.6.1 Purpose ............................................................................................................................. 41

2.7 Message Type: Manifest Enquiry (CIME) ................................................................... 43

2.7.1 Purpose ............................................................................................................................. 43
2.8 Message Type: Manifest Status (CIMS) ..................................................................... 45

2.8.1 Purpose ............................................................................................................................. 45
2.9 Message Type: Passenger Status Request (CICO) ................................................... 47

2.9.1 Purpose ............................................................................................................................. 47
2.10 Message Type: Passenger Status Response (CIUR) ............................................. 50

2.10.1 Purpose ............................................................................................................................. 50
2.11 Message Type: Gate Pass Request (CIGR) ........................................................... 52

2.11.1 Purpose ............................................................................................................................. 52
2.12 Message Type: Gate Pass Response (CIGS) ......................................................... 53

2.12.1 Purpose ............................................................................................................................. 53
3. Dialogue Types ............................................................................................. 55
3.1 Check-in Request (Simple) ......................................................................................... 55

3.2 Check-in Request (Duplicates) ................................................................................... 55
3.3 Check-in Request (Error: Incorrect Data Supplied)..................................................... 56
3.4 Cancellation Request (Simple).................................................................................... 56
3.5 Cancellation Request (Error: No Movement Exists).................................................... 56
3.6 Cancellation Request (Error: Incorrect Data Supplied) ............................................... 56
3.7 Manifest Request ........................................................................................................ 57
3.8 Manifest Request (Error: Incorrect Data Supplied) ..................................................... 57
3.9 Manifest Enquiry ......................................................................................................... 58
3.10 Manifest Enquiry (Error: Incorrect Data Supplied) ................................................... 58

Page 4
3.11 Passenger Status Request ...................................................................................... 59

3.12 Passenger Status Request (Two Blocks of Passengers) ........................................ 59
3.13 Passenger Status Request (Error: Incorrect Data Supplied) ................................... 60
3.14 Gate Pass Request ................................................................................................. 60
3.15 Gate Pass Request (Error: Incorrect Data Supplied) .............................................. 60
4. Message Formats.......................................................................................... 61
4.1 Overall Message Structure.......................................................................................... 61

4.1.1 Rules for Layer 7 ............................................................................................................... 61
4.1.2 Rules for Body of Message ............................................................................................... 62
4.1.3 Rules for Layer 5 Address................................................................................................. 63
4.2 Message Type: Check-in Request (CIRQ).................................................................. 64

4.3 Message Type: Check-in Response (CIRS) ............................................................... 78
4.4 Message Type: Movement Cancellation (CICX) ......................................................... 83
4.5 Message Type: Movement Cancellation Confirmation (CICC) ................................... 90
4.6 Message Type: Manifest Request (CIMR) .................................................................. 94
4.7 Message Type: Manifest Request Acknowledgement (CIMA) .................................... 98
4.8 Message Type: Manifest Enquiry (CIME) ................................................................. 100
4.9 Message Type: Manifest Status (CIMS) ................................................................... 102
4.10 Message Type: Passenger Status Request (CICO) .............................................. 104
4.11 Message Type: Passenger Status Response (CIUR) ........................................... 107
4.12 Message Type: Gate Pass Request (CIGR) ......................................................... 110
4.13 Message Type: Gate Pass Response (CIGS) ....................................................... 113
5. Message Examples ..................................................................................... 115
5.1 Check-in Examples ................................................................................................... 115

5.1.1 One Single Passenger (simple end-to-end journey) ....................................................... 115
5.1.2 Multiple Passengers ........................................................................................................ 119
5.1.3 Different Trans-Border and Expected Ports (same scheduled flight) .............................. 121
5.1.4 Different Trans-Border and Expected Ports (different flights) ......................................... 122
5.1.5 Overriding a Boarding Directive ...................................................................................... 123
5.1.6 Transfer from One International Flight to Another........................................................... 125
5.1.7 Transit on Single Flight ................................................................................................... 126
5.1.8 No response from government systems ......................................................................... 127
5.1.9 No response from back-end systems.............................................................................. 128
5.1.10 Additional Data Requirements for the USA ..................................................................... 129
5.1.11 Domestic Flights.............................................................................................................. 131
5.1.12 Overflight ......................................................................................................................... 132
5.2 Movement Cancellation Examples ............................................................................ 134

5.2.1 Cancel Movement for Single Passenger ......................................................................... 134
5.2.2 Cancel Movements for Multiple Passengers ................................................................... 135
5.2.3 Cancel Movement for Single Passenger (inbound to USA) ............................................ 136
5.3 Manifest Examples .................................................................................................... 137

5.3.1 Manifest Request and Enquiry ........................................................................................ 137
5.3.2 Flight Closeout and Cancellation .................................................................................... 138
5.4 Passenger Status Requests...................................................................................... 139

5.4.1 Passenger Status Request ............................................................................................. 139
5.5 Gate Pass ................................................................................................................. 142

5.5.1 Gate Pass Request for Domestic Flight .......................................................................... 142

Page 5
5.6 Complete Message Sample (including message header)......................................... 143

A. Check-in Message Codes........................................................................... 144
B. Appendix: APP System Error Codes ........................................................ 174
B.1 GG Error Codes ........................................................................................................ 174

B.2 AP Error Codes ......................................................................................................... 180
C. Manual Maintenance of Flight Schedules................................................. 185
C.1 Purpose ..................................................................................................................... 185

C.2 Security Access......................................................................................................... 185
C.3 Procedures ................................................................................................................ 185
C.3.1 Display a Flight Schedule................................................................................................ 185
C.3.2 Load a Flight Schedule ................................................................................................... 186
C.3.3 Delete a Flight Schedule ................................................................................................. 187
D. Guidelines for Implementing Integrated APP........................................... 188
D.1 General ..................................................................................................................... 188

D.2 Communications Links .............................................................................................. 188
D.3 Development Phase .................................................................................................. 189
D.4 System Testing Phase .............................................................................................. 189
D.5 Acceptance Testing Phase ....................................................................................... 190
D.6 Cutover to Production ............................................................................................... 191
D.7 SITA HTH Questionnaire for New Connections ........................................................ 192
D.8 Contact Details .......................................................................................................... 193
D.9 Overview of the Implementation Process.................................................................. 195
E. Passenger Data Requirements .................................................................. 196
F. Document Control....................................................................................... 200

Page 6
List of Figures
Figure 1- Overall Structure of CIRQ Message ...................................................................................... 13
Figure 2 - Overall Structure of CIRS Message ..................................................................................... 21
Figure 3 - Overall Structure of CICX Message ..................................................................................... 29
Figure 4 - Overall Structure of CICC Message ..................................................................................... 32
Figure 5 - Overall Structure of CIMR Message ..................................................................................... 37
Figure 6 - Overall Structure of CIMA Message ..................................................................................... 41
Figure 7 - Overall Structure of CIME Message ..................................................................................... 43
Figure 8 - Overall Structure of CIMS Message ..................................................................................... 45
Figure 9 - Overall Structure of CICO Message ..................................................................................... 47
Figure 10 - Overall Structure of CIUR Message ................................................................................... 51
Figure 11 - Overall Structure of CIGR Message ................................................................................... 52
Figure 12 - Overall Structure of CIGS Message ................................................................................... 54
Figure 13 - Flight BA033 (KUL-SYD) .................................................................................................. 115
Figure 14 - Flight QF016 (BKK-MEL-SYD) ......................................................................................... 121
Figure 15 - Multi-Leg Journey (ORD-LAX-SYD-MEL) ........................................................................ 122
Figure 16 - Multi-Flight Journey (BKK-SYD-LAX) ............................................................................... 125
Figure 17 - Transit on Single Fight (BKK-SYD-LAX) .......................................................................... 126
Figure 18 - Travel to the USA (MEL-SYD-LAX-ORD)......................................................................... 129
Figure 19 - International Journey with Domestic Travel in the USA (LAX-ORD) ................................ 131
Figure 20 - Overflight of the USA (SYD-YVR) .................................................................................... 132
Figure 21 - Domestic Journey in the USA (LAX-ORD) ....................................................................... 142
Figure 22 - Implementation Process for Integrated APP .................................................................... 195
List of Tables
Table 1 - Message Construction for Check-In Request (CIRQ)............................................................ 14
Table 2 - Rules for Implementing CIRQ Message ................................................................................ 18
Table 3 - Message Construction for Check-In Response (CIRS) ......................................................... 21
Table 4 - Rules for Implementing CIRS Message................................................................................. 26
Table 5 - Message Construction for Movement Cancellation (CICX) ................................................... 30
Table 6 - Rules for Implementing CICX Message................................................................................. 31
Table 7 - Message Construction for Movement Cancellation Confirmation (CICC).............................. 33
Table 8 - Rules for Implementing CICC Message ................................................................................ 36
Table 9 - Message Construction for Manifest Request (CIMR) ............................................................ 38
Table 10 - Rules for Implementing CIMR Message .............................................................................. 40
Table 11 - Message Construction for Manifest Request Acknowledgement (CIMA) ............................ 42
Table 12 - Message Construction for Manifest Enquiry (CIME)............................................................ 43

Page 7
Table 13 - Rules for Implementing CIME Message .............................................................................. 44

Table 14 - Message Construction for Manifest Status (CIMS).............................................................. 46
Table 15 - Message Construction for Passenger Status Request (CICO)............................................ 48
Table 16 - Rules for Implementing CICO Message .............................................................................. 50
Table 17 - Message Construction for Passenger Status Response (CIUR) ......................................... 51
Table 18 - Message Construction for Gate Pass Request (CIGR) ....................................................... 52
Table 19 - Rules for Implementing CIGR Message .............................................................................. 53
Table 20 - Message Construction for Gate Pass Response (CIGS)..................................................... 54
Table 21 - Rules for Implementing Layer 7 of a Message .................................................................... 61
Table 22 - Data Items in Layer 7 of the APP Message ......................................................................... 62
Table 23 - Rules for Body of Message.................................................................................................. 62
Table 24 - Layer 5 Addresses for APP Messages ................................................................................ 63
Table 25 - Message Layout for Check-in Request (CIRQ) ................................................................... 77
Table 26 - Message Layout for Check-in Response (CIRS) ................................................................. 82
Table 27 - Message Layout for Movement Cancellation (CICX)........................................................... 89
Table 28 - Message Layout for Movement Cancellation Confirmation (CICC) ..................................... 93
Table 29 - Message Layout for Manifest Request (CIMR).................................................................... 97
Table 30 - Message Layout for Manifest Request Acknowledgement (CIMA) ..................................... 99
Table 31 - Message Layout for Manifest Enquiry (CIME) ................................................................... 101
Table 32 - Message Layout for Manifest Status (CIMS) ..................................................................... 103
Table 33 - Message Layout for Passenger Status Request (CICO) ................................................... 106
Table 34 - Message Layout for Passenger Status Response (CIUR) ................................................ 109
Table 35 - Message Layout for Gate Pass Request (CIGR)............................................................... 112
Table 36 - Message Layout for Gate Pass Response (CIGS) ............................................................ 114
Table 37 - Check-in Message Codes.................................................................................................. 173
Table 38 - GG Error Codes ................................................................................................................. 179
Table 39 - AP Error Codes.................................................................................................................. 184
Table 40 - Passenger Data Requirements.......................................................................................... 199

Page 8
1. INTRODUCTION
1.1 PURPOSE OF THIS DOCUMENT
The purpose of this document is to provide a specification of the messages and processing
for the Integrated APP Implementation.
The APP (Advance Passenger Processing) System provides a message-based interface

between an airline system and the Government Gateway (GG) which is the common
communications hub of both the Electronic Travel Authority (ETA) System and the APP
System. This interface is known as the Integrated APP Implementation.
1.2 SCOPE OF THIS DOCUMENT

There are two implementations of APP for airlines: Stand-alone and Integrated.
• Stand-alone APP provides formatted screens for users to complete.
• Integrated APP is a message-based interface, which an airline uses to allow
its Departure Control System (DCS) to interact with the APP System (via the
GG). There are two message versions that can be used for Integrated APP:
o Host to Host text-based messages.
o SOAP web services messages.
The scope of this document is to assist the airlines in their implementation of the Integrated
APP option. It does not attempt to offer any advice on how an airline should integrate APP
transactions within its DCS, and therefore does not cover either the airline check-in process,
or the airline process for offloading passengers, and neither does it say anything about the
user interface for these processes.
This document sets out the messaging requirements between the airline DCS and the GG for
the Host to Host version of the service. A separate document is available that describes the
SOAP web services message formats. That document replaces sections 2, 4 and 5 of this
document with new message definitions and examples of the new messages. The
Recommended Airline Implementation sections in section 2 and all message codes in
Appendices A and B are still applicable to the web services interface. Airlines wishing to
implement the new message types should contact SITA to request the documentation.
The interface messages specified in this document have the capability to capture the data
necessary for compliance with U.S. Customs and Border Protection (CBP) requirements for
reporting on passengers using UN/EDIFACT manifests through the Advance Passenger
Information System (APIS) and reporting using the APIS Quick Query (AQQ) system. This
encompasses the reporting requirements for passengers and crew and the gate pass
requirements of the Secure Flight program in the USA as implemented through the AQQ
system.
Some of the transactions described in this document are not available for all APP countries.
Airlines should check with each government for the transactions that are required.
This document does not include an overview of the APP System or the concepts on which it
is based.

Page 9
Note on Message Versions:

Message version 25 and later provide full compliance with the requirements for AQQ and
Secure Flight for the USA and e-Borders for the UK.
Changes have been made in later versions of the message to support specific
requirements from other governments and airlines must check with the governments they
fly to so that they ensure they are using the required message version.
In Section 4 – Message Formats data elements that have been introduced for versions
later than Version 21 have been shaded as follows:
Version 24 in green
Version 25 in blue
Version 26 in orange
Version 27 in purple
Version 28 in red
Version 29 in yellow
Message Version 21 users are not required to send shaded data elements in messages to
the GG and will not receive shaded data elements in messages from the GG.
All other sections of this specification assume the latest version of the message, with no
notes included for variations from Message Version 21 e.g. message descriptions in
Sections 2.1, 2.2 and 2.3, and all examples in Section 5.
1.3 READERSHIP
This document is intended primarily for the following users:
• Passenger Services and Information Technology personnel of airlines.
This document may also be useful for the following users:

• Immigration authorities.
• Government Gateway Development Team.
• Application Processor Development Team.
1.4 RELATED DOCUMENTS

• Implementing IATA Host to Host Exchanges with SITA ATLDC Applications,
Version 1.2, 27 September 2009
• Advance Passenger Processing System, Stand-alone APP User Manual,
version 7.0 February 2017
• Message Implementation Guideline for Airlines UN/EDIFACT
PAXLST/CUSRES Message Sets v3.5, 2099001-UN-IMPLEMENTATION-
GUIDE-3.5, 3 January 2011.
• APP Web Services Message Specification Airline to GG, version 1.0
November 2018.

Page 10
1.5 CONTACTS
All comments regarding this document should be directed to:
Person name Julie Kalitis
Organisation name SITA
Phone +61-(0)2-9911-7464
Fax +61-(0)2-9911-7505
Email julie.kalitis@sita.aero

Page 11
2. MESSAGE TYPES
There are twelve message types: two for check-in (request from the airline and response
from the APP System), two for cancellations (cancellation request from the airline and
response from the APP System), four for requesting manifests and enquiring upon the status
of manifests, two for requesting changes to the status of passengers notified through
asynchronous status updates being received from government systems, and two for
requesting a gate pass. Each of the twelve message types is described in detail below.
2.1 MESSAGE TYPE: CHECK-IN REQUEST (CIRQ)
2.1.1 Purpose
This message is used to request a boarding directive from a government. It does this by
sending passenger document and flight data from the airline DCS to the GG. The message
can be used to provide data for up to five passengers to government systems for countries at
both ends of an international journey, for countries at transit points or for countries which are
overflown by the flight. The message can also be used to request a boarding directive for
passengers on domestic flights.
The message is used under two different circumstances:

• To notify one or more governments of the details of one or more passengers
checking in for a flight.
• In some cases, the initial Check-in Request (CIRQ) Message will result in a
Check-in Response (CIRS) message indicating that one or more of the sets of
passenger data input has identified more than one passenger on the visa or
passport database. In these cases, the Check-in Request (CIRQ) Message is
also used to indicate which of the passengers are actually travelling. (See
further the section on Dialogue Types below, section 3.2).

Page 12
2.1.2 Message Structure

The following diagram (Figure 1) shows the overall structure of the CIRQ message:
Check-in Request CIRQ

Transaction
CIRQ Header
Field count: 6
Instances: 1
(Mandatory)
CHK INT One of these is DOM EXO/EXD PRQ

Check-in International required Domestic Expected Passenger Field count: 24-35
Flight Flight (INT or DOM) Flight Flight Request Instances: 1-5
(Optional) (Conditional) (Conditional) (Conditional) (Mandatory)
Field count: 10
Field count: 4 Instances: 0-1 Field count: 10 Field count: 6
Instances: 0-1 Instances: 0-1 Instances: 0-2 PTI
Passenger
Travel Itinerary Field count: 10
OVR Instances: 0-9 (per pax)
(Conditional)
Overflight
(Optional) Field count: 5
Instances: 0-5
PAD
Passenger
Additional Data Field count: 14
(Conditional) Instances: 0-5 (per pax)
Figure 1- Overall Structure of CIRQ Message
2.1.3 Message Construction

The body of the message contains the data groups listed in Table 1.
Data group Group Number of Notes
ID occurrences
Transaction None Always 1 Includes the transaction indicator (CIRQ) to identify the
function being performed.
Check-in CHK 0 or 1 While this data group is technically optional, border control
Flight authorities prefer it to be supplied. It is the flight on which
the passenger is checking in when advance passenger
information is collected.
International INT 0 or 1 The flight on which the passenger is crossing the
Flight international border and for which check-in is being
performed.
There must be one International Flight data group or one
Domestic Flight data group in the message. This data
group is present when the movement of interest is an
international movement.
Overflight OVR 0 to 5 A flight sector from one country to another which overflies a
third country. The sector must be one of the sectors of the
International Flight. The Overflight data groups associated
with an International Flight follow immediately after the
International Flight data group.

Page 13
Domestic DOM 0 or 1 The flight on which the passenger flies from one airport to
Flight another in the same country and for which check-in is being
performed.
group is present when the movement of interest is a
domestic movement.
Expected EXO 0,1 or 2 Data group EXO refers to the outbound flight. It is required
Flight or only if the government of the country is a participant in APP
EXD and the passenger is not processed through the border at
the origin of the International Flight.
Data group EXD refers to the inbound flight. It is required
only if the government of the country is a participant in APP
and the passenger is not processed through the border at
the destination of the International Flight.
EXO and EXD data groups should never be present for a
domestic flight transaction.
Passenger PRQ 1 to 5 Includes biodata and document data for each passenger.
Request (see the note Note that with endorsees on passports, more than one
below on passenger may be associated with one data group.
numbers)
Passenger PTI 0 to 9 Includes data on a single direction segment in the
Travel (per passenger’s PNR.
Itinerary passenger)
Passenger PAD 0 to 5 Includes additional data that is required by countries on the
Additional (per flight, e.g. address at destination and second travel
Data passenger) document information required by the USA.
Only one PAD segment is allowed per country that requires
the information.
Table 1 - Message Construction for Check-In Request (CIRQ)
2.1.4 Message Processing

When a message is received from an airline across the SITA network, the GG:
• Determines which governments involved in the transaction are participants in
the APP System.
• Translates the airline message into formats recognised by the participating
government(s).
• Forwards the message(s) to the participating government(s).
• Receives response(s) from the participating government(s).
• Collates the responses into a single message for return to the airline DCS.
Refer to Check-In Response (CIRS) below.

Page 14
Note on the number of passengers in the CIRQ message

In theory, the format of the CIRQ message would allow data on up to 999 passengers to
be provided in a single message. However, the limitation on message size between the
GG and the government systems means that the maximum number of passengers in the
response message is actually 15. This is because the maximum size of a HTH message
on the SITA network is slightly over 3,000 characters.
Since there may be responses for several passengers for one set of input data (i.e. a list
of duplicates where there are endorsees on a passport), the number of input data sets
must be limited to 5 (five).
2.1.5 Recommended Airline Implementation

It is strongly recommended that airlines implement the CIRQ message in the following way:
No Rule Notes
1 The CIRQ message has been designed to When implementing APP for one or more
satisfy the passenger data capture countries, airlines should ensure that the
requirements of all participating APP specific data requirements are fully
countries. The requirements vary by understood. Contact details for the
country and are listed for each country in Immigration authorities and for SITA are given
Appendix E. in Appendix D.
2 Use a passport reader to obtain passenger This method should minimise data input
biodata from the machine-readable zone errors.
(MRZ) of the passport wherever possible
during check-in.
3 Incorporate all of the MRZ data in the first If the passenger is not known to the APP
CIRQ message so that the full passenger System but is in fact visa free for the country
data is available to the APP System without concerned, the biodata will be captured at this
the need for any further dialogue. point and sent to the government in the
expected movement record.
See Example 7 below for an example of full
data being supplied (section 5.1.1).
4 The CIRQ message can refer to either an International flights may involve up to five
international flight or a domestic flight. countries requiring the provision of APP data.
International flights are specified using the The countries may include the origin,
INT data group and (optionally) Overflight destination or transit countries of the flight and
(OVR) data groups. overflight countries.
Domestic flights are specified using the
DOM data group. Overflights should not be
used in conjunction with domestic flights.
5 A CIRQ message should not include a mix This situation occurs only when there are two
of passengers or crew which will result in or more passengers or crew in a CIRQ
the generation of different messages to message and the passengers or crew hold
different countries. This can occur when different types of documents.
passengers or crew in a CIRQ message For example, if two passengers in a single
hold different types of travel documents and CIRQ message hold different types of
not all countries involved in the journey can documents and one country involved in the
process all the documents in the message. journey can process both types of documents
but another country involved in the journey
cannot.

Page 15
6 If the passenger is an endorsee on a This enables the passenger to be uniquely

passport, the passenger’s full bio-data is identified without further interaction with the
required. check-in agent.
7 The CIRQ message allows for a Sex
indicator of M (Male), F (Female), or U or X
(Unspecified). In the MRZ of ICAO-
standard passports, “unspecified” is
indicated by a null field i.e. the “<”
character. This must be translated to “U” or
“X” in the CIRQ message.
8 The rules for Expected Flights and Ports are
as follows:
§ The Expected Flight must be a
domestic segment of a scheduled
domestic or international flight
§ For EXO, the Expected Port must
be in the same country as the
Board Point of the International
Flight.
§ For EXD, the Expected Port must
be in the same country as the Off
Point of the International Flight.
§ For EXO, the Expected Flight must
be from the Expected Port to the
Board Point of the International
Flight.
§ For EXD, the Expected Flight must
be from the Off Point of the
International Flight to the Expected
Port.

Page 16
9 When a passenger is arriving at an airport There are a number of cases where

at the end of an international flight and is passengers who may expect to be able to
boarding another flight to leave the country transit without entering a country may be
without crossing the primary line, they can required to enter the country, so transit rules
be flagged as Transfer at Destination. This will not apply. The airline needs to be aware
means that the passenger will be assessed of the possibilities at the specific airports. For
under the rules for transiting the country example:
rather than the rules for entering the § Passengers arriving in Australia at
country. However, the airline must be sure Sydney Airport and who will be
that the transit rules apply for the particular boarding a flight to depart Australia
case. within 8 hours may be permitted to
transit without a visa. However,
Sydney Airport closes overnight, and
passengers are not permitted to stay
at the airport. Therefore, if they intend
to arrive late at night and leave early
the next morning, even within 8 hours,
they must still qualify for entry to
Australia as they must leave the
airport overnight. These passengers
should not be flagged as Transfer at
Destination.
§ Similarly, passengers whose baggage
was not through-checked onto their
flight departing Australia will need to
cross the primary line to retrieve their
baggage and check-in on the
departing flight. These passengers
must also satisfy entry conditions.
They should not be flagged as
Transfer at Destination.
10 The Passenger Reference may be provided The Passenger Reference may include the
by the airline and must be unique. PNR Record Locator. However, this is
insufficient for uniqueness as there may be
multiple passengers and multiple flights in the
PNR, and PNR Record Locators are reused
after all flights in a PNR have been completed.
The Passenger Reference may be recorded
by government systems and used by those
systems for further transactions involving the
specific journey for the passenger.
Consequently, the Passenger Reference
should be stored by the airline such that the
data associated with the passenger and the
journey can be identified and accessed.
11 When Passenger Additional Data (PAD) Each PAD data group must include the
data groups are included in a CIRQ Passenger Sequence Number of the
message, the order of the PRQ and PAD passenger to which it applies and the country
data groups in the message must be: PRQ to which it applies and must occur in the order
data group for first passenger, PAD data specified.
groups for first passenger in the order of
countries on the flight, then repeat for each
subsequent passenger in the message.

Page 17
12 When the Passenger Additional Data (PAD) The minimum data requirement for the PAD
data group is applicable for a country, then data group is the first four data items i.e. up to
the PAD data group must be provided even and including Country for Additional Data. The
if there is no data on the passenger remainder of the data items may be null. An
supplied in the PAD data group. example where this may apply is a USA citizen
travelling to the USA for whom no additional
travel document details are provided, no
address details are required and Passenger
Redress Number and Known Traveller
Number are not provided.
13 The system will accept any code for an The system will determine if the code provided
additional document type. The airline should is accepted by each country involved in the
provide the code as it is stated on the journey.
provided document.
14 The Passenger Travel Itinerary (PTI) data The flight segments reported may be domestic
group is currently only relevant for airlines segments within the country at either end of
using the AQQ capabilities of the APP the International Flight or other international
System. flights.
When the airline is aware of itinerary The order of the flight segments should be the
segments within the passenger’s PNR in order in the PNR.
addition to the International Flight, these
must be reported in the Passenger Travel
Itinerary (PTI) data group.
15 The APP System provides for the An airline requiring this capability should
submission of transactions for flights that contact SITA. Refer to Appendix D for contact
are not recorded in the Flight Schedules i.e. information.
Unscheduled Flights. Unscheduled flights can only be used in CIRQ
The use of this capability is not and CICX transactions and not in CIMR, CIME
recommended and is only available on or CICO transactions.
request. Airlines are encouraged to add Unscheduled flights can only be used for INT
unscheduled flights to the Flight Schedules or DOM flight segments for point-to-point
and then treat the flights as scheduled flights, because boarding directives for
flights. The function to add a flight to the intermediate countries will not be received.
schedules is described in Appendix C. They cannot be used for Expected Flights.
16 For the USA and the UK, when the principal In this case, the Travel Document Type in the
travel document for a passenger or crew Passenger Request (PRQ) data group should
member is a document other than a be set to ‘O’ Other and information on the
passport, specific rules apply. document should be included in the
Passenger Additional Data (PAD) data group.
17 If there is more than one passenger in a The unique number can assist airlines in
CIRQ message, it is recommended that reconciling information on passengers in the
each passenger is submitted with a different CIRS message with information in the original
Passenger Sequence Number. CIRQ message. It can also assist in problem
resolution.
18 Flight dates and times must be the same as The APP System uses the flight dates and
the scheduled flight date and time and must times to match against the standard airline
be in the local port time. schedules, which are in the local port time.
Flight dates and times must not be adjusted if
the flight is delayed otherwise the system will
not be able to locate the correct flight
schedule.
Table 2 - Rules for Implementing CIRQ Message

Page 18
Note on flight dates

The APP System only allows check in and cancellation (CIRQ and CICX) transactions on
flights with a departure date from 2 days before the current date to 10 days after the
current date (local time).
For example, if the current date is 10 June, flights with a departure date between 8 June
and 20 June can be submitted for processing.
Any transaction for a flight which is outside this date range will be rejected.

Page 19
2.2 MESSAGE TYPE: CHECK-IN RESPONSE (CIRS)
2.2.1 Purpose
This message is used to send a response to a Check-in Request (CIRQ) from the GG to the
airline DCS. The message can be used to provide data for one or more passengers from
government systems for countries at both ends of an international journey, for countries at
transit points, or for countries which are overflown by the flight. There are several different
cases:
Case Situation
Case 1 When a set of passenger data has been uniquely matched on the database on
a government system and a corresponding directive for the passenger can be
returned (normally “OK to Board”) together with an Expected Passenger ID.
Case 2 When a set of passenger data has not been matched on the database on a
government system but due to visa-free or other special arrangements, the
directive “OK to Board” for the passenger can be returned together with an
Expected Passenger ID.
Case 3 When a set of passenger data has been matched on the database on a
government system and the government determines that the passenger should
not be allowed to board (“Do not Board”).
Case 4 When a set of passenger data has been matched with multiple entries on the
database on a government system and the airline user must select which
passengers are boarding.
Note: To be able to handle multiple passengers, the DCS must set the value of
the Handle Multiple Response flag to “Y” in both the CIRQ and CICX
messages.
Case 5 When an error has been detected in a set of passenger data and must be
corrected before further processing for the passenger.
Case 6 When an error is identified that precludes any further processing of the original
message.
For further information, see the section on Dialogue Types below (section 3).

Page 20

The following diagram (Figure 2) shows the overall structure of the CIRS message:
Check-in Response CIRS

CIRS Transaction
Header
Field count: 2
Instances: 1
(Mandatory)
PRS ERR
Passenger Error Field count: 5
Response Group Instances: 0-25
(Conditional) One of these (Conditional)
is required
(either PRS
Field count: 30 or ERR)
Instances: 0-25
Figure 2 - Overall Structure of CIRS Message

The body of the message contains the data groups listed below in Table 3.
ID occurrences
Transaction None Always 1 Includes the transaction indicator (CIRS) to identify the
Passenger PRS 0 to 25 The expanded data retrieved from the database of a
Response government system. There may be more than one of these
data groups per passenger when several countries involved
in an International Flight are APP System participants.
The data group allows for two types of status code:
§ Check-in Message Code and Passenger Status
Code which indicate whether or not the passenger
is known to the government system and the action
to be taken for the passenger (i.e. the directive).
§ Passenger Error Code which indicates specific data
problems with the passenger data supplied.
Error ERR 0 to 5 Serious errors that preclude further processing of
passengers for one of the participating countries are
included in this data group. There may be one Error Group
for each participating country involved in the transaction.
Table 3 - Message Construction for Check-In Response (CIRS)

Page 21

The following notes apply to the further processing of response messages:
Case Situation
Case 1 The passenger has been matched in the database and the Check-in Message Code
indicates the action specified by the government for that passenger. An expected
movement has been created. The DCS can continue to process the passenger for
boarding.
Case 2 The passenger has not been matched in the database and the Check-in Message
Code indicates the action specified by the government for that passenger. The
passenger is eligible to board. An expected movement has been created. The DCS
can continue to process the passenger for boarding.
Case 3 The passenger has been matched in the database and the Check-in Message Code
indicates the action specified by the government for that passenger. An expected
movement has not been created. The airline should ensure that the passenger has
appropriate documentation and provide an override, or contact the government
returning the denied message code to remedy the problem.
Case 4 The passenger has been matched with multiple records in the database. Expected
movements have not been created for any of the passenger details returned. The
check-in agent must select which passengers are to be boarded and send a Check-in
Request (CIRQ) message back to the GG to indicate the selection. This second
Check-in Request (CIRQ) message should ensure uniqueness of the passenger data
for the selected passengers by including full biodata. If the Check-in Request (CIRQ)
messages are not generated back to the GG, then expected movement records will not
be created for those passengers.
Case 5 An error detected by the government system in a set of passenger data must be
corrected before further processing of the passenger. Processing for other passengers
may continue.
Case 6 In this case, a detected error means that there can be no further processing for
passengers for this country. The error condition must be corrected. This case
generally only applies to system errors.

The CIRS message may include one or more Passenger Response (PRS) data groups
which may indicate that processing has completed normally for passengers or that there
have been errors related to particular passengers. It may also include an Error Group
(ERR) notifying a serious error from one or more countries.
The Passenger Response (PRS) data group includes a Passenger Status Code returned for
each passenger by each country. This code indicates the action that can be taken for each
passenger. The possible values of the code are:
B All the data required to assess the passenger is available. The passenger has
been given clearance to board. An expected movement has been generated if
the Passenger Status returned by all countries has this value.
D All the data required to assess the passenger is available, but the directive
from the country indicates that the passenger is not to be permitted to board.
No expected movement has been generated. After consultation with a
government authority or a determination by the check-in agent that the
passenger conforms to the requirements of a special category of traveller

Page 22
according to the regulations of the country, the boarding directive may be

overridden by the check-in agent.
X All the data required to assess the passenger is available, but the directive
from the country indicates that the passenger is not to be permitted to board.
No expected movement has been generated. This directive may not be
overridden by the check-in agent.
U Unable to determine the status of the passenger. The identity of the

passenger cannot be uniquely determined because multiple records have
been found matching the data supplied or because of database
inconsistencies. More specific bio-data must be supplied before the
passenger can be assessed by the system. If this does not remedy the
situation, advice must be sought from government agencies.
I Insufficient data is available for an assessment to be made. It must be

captured before the passenger can be assessed by the system.
T The APP System for the country has not responded within the timeout period
specified. No directive from the country can be returned to the check-in agent.
E An error condition has been detected. All error conditions must be corrected
before processing can be completed for the passengers represented in the
message.
The actions recommended above must be performed under the control of the DCS as
follows:
• Display error conditions to the user and allow the user to correct the error
conditions.
• Deal with the inability of the system to uniquely identify a passenger or when
there is insufficient data to assess the passenger by capturing further
passenger data and resending the CIRQ message.
• Override a directive from a government system by resending the CIRQ
message with the Override Flag set to “A” or “G” followed by the country code
of the country to which the override applies e.g. “GAU” indicates a “G” override
is to be sent to Australia (refer to Table 25). Overrides may be submitted for
more than one country in a single CIRQ message e.g. “GAUANZ” indicates a
“G” override is to be sent to Australia and an “A” override is to be sent to New
Zealand.

Page 23
It is strongly recommended that airlines implement the CIRS message as follows:

No Rule Notes
1 Within a CIRS message, the primary
order of Passenger Response (PRS)
segments will be the order of Passenger
Request (PRQ) segments in the CIRQ
message.
Within the data for an individual
passenger, the order of PRS segments for
the applicable countries will be the origin
country, transit countries in the order of
the flight, destination country and
overflight countries in the order specified
in the CIRQ message.
2 If the CIRS message includes an Error These errors are normally of a serious nature
Group (ERR), the error message is e.g. APP System unavailable, and resubmission
displayed to the user for correction and by the user may not remedy the problem.
resubmission.
3 If the CIRS message includes a These errors are normally of a less serious
Passenger Response (PRS) data group nature.
that includes an error message, the error
message is displayed to the user for
correction and resubmission.
4 The CIRS message includes a Passenger Before deciding to proceed with passenger
Status Code returned by each country for processing without receiving directives from a
each passenger. government, the check-in agent must:
§ If the CIRS message for one or § Ensure that this is not a transient
more countries returns a status of problem by attempting the transaction
“T”, the APP Systems for those again.
countries are not responding i.e. § Contact government agencies of each
timing out. country affected, inform them of the
§ If the problem persists, situation and obtain permission to
processing can continue. The continue boarding passengers.
rules in paragraph 5 below should The government systems of countries
be followed. unaffected by the timeouts will continue to
receive the correct data on expected passenger
movements.
5 The combination of Passenger Status The only circumstance when a passenger may
Codes (not including occurrences of be boarded is when all countries respond with a
Timeout “T” which are ignored) status of “B”. In all other circumstances, the
determines the action that can be taken. check-in agent must take further action.
§ If all values are “B”, boarding for Before overriding a directive from a government
the passenger may continue. system, the check-in agent must:
§ If at least one country has § Be satisfied that the passenger belongs
returned a status of “I” or “U”, but to a special category according to the
no country has returned a status regulations of each country that
of “X”, the additional passenger returned a status of “D”; or
data must be captured so an § Contact government agencies of each
assessment may be completed. country that returned a status of “D”
A CIRQ message is then and obtain clearance to board the
retransmitted. If this does not passenger.
correct the problem, a
government agency should be
contacted for advice.

Page 24
No Rule Notes
§ If at least one country has
returned a status of “D” and all
others have returned a status of
“B”, and the check-in agent is
satisfied that the passenger
should be permitted to board due
to special circumstances, a CIRQ
message is retransmitted with the
Override Flag set to “A” or “G”
followed by the appropriate
country codes.
6 In cases where some countries return a This is a reconciliation issue for the participating
Passenger Status Code of “B” and others government and the airlines do not need to take
do not return “B”, the expected any special action.
movements generated for countries that
returned a “B” are automatically
cancelled. The response to the airline
does not wait for confirmation of the
automatic cancellation. In cases of
system malfunction, these automatic
cancellations may not be successful, but
the airline will not be aware of this
situation.
7 Store the Expected Passenger ID from This ID can be used subsequently in a
the CIRS message against the passenger Movement Cancellation (CICX) message if the
in the DCS. This identifier will only be passenger does not fly (or if the entire flight is
returned if all countries involved in the cancelled).
passenger’s journey have returned a For the USA, the Passenger Reference should
positive directive and an expected be used for this purpose.
movement has been generated to
government systems.
8 The Passenger Status Codes for each If a particular passenger is cleared for travel
passenger should be assessed while others in the transaction are not, no
independently of other passengers in the further processing is required for the passenger
transaction to determine if any future that has been cleared. It is not necessary to
action is necessary for the passenger. resend transactions for that passenger. Only
Where a “B” is returned for a passenger passengers not cleared for travel need to be
from all countries, no further transactions processed further.
need to be submitted for the passenger.
9 The Passenger Status Code returned in The relationships in Table 37 are indicative only
the CIRS message should be used for and refinements of business rules by a
assessing a response, not a local table government may lead to changes or to a
that relates Check-in Message Codes to Check-in Message Code being associated with
Passenger Status Codes. more than one possible Passenger Status
Code.
10 Airlines should wait for at least 35 The GG waits for 29 seconds for responses
seconds before timing out an enquiry sent from all governments before timing out the
to the GG. enquiry. Airlines need to wait a little longer than
this.
11 The return of Check-in Message Code This message code notifies the check-in agent
8508 (Repeated – OK to Board) to the when the same passport is inadvertently used
airline’s DCS indicates that the for more than one passenger, as sometimes
transaction for the passport and happens when a group is being checked in for a
passenger bio-data has already been flight.

Page 25
No Rule Notes
performed and an OK to Board or The message code will only be returned if the
equivalent response has been returned. airline is configured to receive it, otherwise the
Check-in Message Code 8501 (OK to Board) or
equivalent will be returned and the check-in
agent will not be warned of duplicate
transactions.
An airline should carefully consider how its DCS
will use this code and ensure that check-in
agents are fully aware of the correct procedures
before it requests the code to be returned to its
DCS.
Where this message has been received for a
check-in transaction, the check-in agent should
ensure that reversing check-in for the
passenger does not cancel the original
expected movement.
12 Some APP countries have implemented While the APP interface with airlines is common
checks to ensure that a Government (G) for all countries, the contact points for
Override will be accepted by their APP authorisation of overrides differ. When
System only after a government officer implementing APP for a country, airlines must
has explicitly authorised use of the ensure that check-in agents are aware of the
override and has recorded that procedures for that country.
authorisation on the APP System.
13 If there are multiple passengers in a This becomes particularly important if there are
single transaction and the Passenger multiple responses for a single passenger e.g.
Sequence Number is different for each when there are two passengers on the same
passenger in the CIRQ message, the passport with similar names.
Passenger Sequence Number can be
used to reconcile the content of the CIRQ
and CIRS messages.
14 It is important that airlines allow To ensure that correct procedures are followed,
passengers to board flights only after a there should be tight integration of the
positive boarding directive has been Departure Control System with the APP System
received from the APP System. This will so that a boarding pass cannot be printed
minimise the likelihood of penalties for unless a positive directive has been received.
carrying inadmissible passengers. To identify incomplete processing of through-
checked passengers, there should also be
automated checks at boarding gates.
To ensure that boarding operations are not
delayed in the rare cases when the APP
System is not responding, or a passenger must
be boarded without a positive directive,
supervisors should be permitted to override
these controls.
Table 4 - Rules for Implementing CIRS Message

Page 26
2.2.6 Message Structure Scenarios

The following examples of the structure of CIRS message are based on a flight from New
Zealand to Australia to South Africa (all APP countries), for two passengers (Pax A and Pax
B):
1. If the GG detects a validation error in the CIRQ message, the CIRS message
will be structured as follows:
ERR(from GG).
2. If all countries return an error free response, the CIRS message will be
structured as follows:
PRS(Pax A for NZ)

PRS(Pax A for AU)
PRS(Pax A for ZA)
PRS(Pax B for NZ)
PRS(Pax B for AU)
PRS(Pax B for ZA).
3. If AU returns an error response in a 6-1 message for Pax A and ZA returns an

error response in a 6-1 message for Pax B, the CIRS message will be
PRS(Pax A for NZ)

PRS(Pax A for AU with error codes)
PRS(Pax A for ZA)
PRS(Pax B for NZ)
PRS(Pax B for AU)
PRS(Pax B for ZA with error codes).
4. If NZ and AU return normal responses but ZA times out, the CIRS message
will be structured as follows:
PRS(Pax A for NZ)

PRS(Pax A for AU)
PRS(Pax A for ZA with timeout indicated in Passenger Status)
PRS(Pax B for NZ)
PRS(Pax B for AU)
PRS(Pax B for ZA with timeout indicated in Passenger Status).
5. If NZ returns a normal response, AU returns an error response in a 6-1

message for Pax A and Pax B and ZA times out, the CIRS message will be
PRS(Pax A for NZ)

PRS(Pax A for AU with error codes)
PRS(Pax A for ZA with timeout indicated in Passenger Status)
PRS(Pax B for NZ)
PRS(Pax B for AU with error codes)

Page 27
PRS(Pax B for ZA with timeout indicated in Passenger Status).
6. If AU returns an error response in a 9-1 message and ZA returns an error

response in a 6-1 message for Pax B, the CIRS message will be structured as
follows:
PRS(Pax A for NZ)

ERR(for AU)
PRS(Pax A for ZA)
PRS(Pax B for NZ)
PRS(Pax B for ZA with error codes).
7. If NZ returns an error response in a 9-1 message, AU returns a normal

response and ZA returns an error response in a 9-1 message, the CIRS
message will be structured as follows:
ERR (for NZ)

PRS(Pax A for AU)
ERR(for ZA)
PRS(Pax B for AU).

Page 28
2.3 MESSAGE TYPE: MOVEMENT CANCELLATION (CICX)
2.3.1 Purpose
This message is used to notify the APP System that one or more expected movements
previously generated are to be cancelled.

The following diagram (Figure 3) shows the overall structure of the CICX message:
Movement Cancellation CICX

CICX Transaction Field count: 6
Header Instances: 1
(Mandatory)
INT One of these is DOM PCX

International required Domestic Movement
Flight (INT or DOM) Flight Cancellation
(Conditional) (Conditional) (Mandatory)
Field count: 10
Instances: 0-1 Field count: 10 Field count: 23
Instances: 0-1 Instances: 1-10
OVR
Overflight Field count: 5
(Optional) Instances: 0-5
Figure 3 - Overall Structure of CICX Message

ID occurrences
Transaction None Always 1 Includes the transaction indicator (CICX) to identify the
International INT 0 or 1 The flight on which the passenger was originally checked in
Flight for crossing the international border.
group is present when the movement of interest is an
international movement.
Overflight OVR 0 to 5 A flight sector from one country to another which overflies a
third country. The sector must be one of the sectors of the
International Flight. The Overflight data groups associated
with an International Flight follow immediately after the
International Flight data group.

Page 29

ID occurrences
Domestic DOM 0 or 1 The flight on which the passenger flies from one airport to
Flight another in the same country and for which check-in was
originally performed.
group is present when the movement of interest is a
domestic movement.
Passenger PCX 1 to 10 Includes biodata and document data for each passenger.
Cancellation Note that only one passenger may be associated with one
data group.
Table 5 - Message Construction for Movement Cancellation (CICX)

• Determines which governments involved in the transaction are participants in
the APP System.
• Translates the airline message into formats recognised by the participating
government(s).
• Forwards the message(s) to the participating government(s).
• Receives response(s) from the participating government(s).
• Collates the responses into a single message for return to the airline DCS.
Refer to Movement Cancellation Confirmation (CICC) below.
Note on the number of passengers in the CICX message

In theory, the format of the CICX message would allow data on up to 999 passengers to
be provided in a single message. However, the limitation on message size between the
GG and the government systems means that the maximum number of passengers in the
response message is actually 15. This is because the maximum size of a HTH message
on the SITA network is slightly over 3,000 characters.
Since there may be additional data in the response (eg. error messages) for one set of
input data, the number of input data sets must be limited to 10 (ten).

Page 30

It is strongly recommended that airlines implement the CICX message in the following way:
No Rule Notes
1 If a passenger is processed through the Otherwise incorrect expected movement
APP System and does not actually board details will be sent to government systems.
the flight, the movement should be
cancelled by this transaction.
2 Provide the Expected Passenger ID in See Example 25 for an example of this
the PCX data group. This is sufficient data being supplied (section 5.2.1).
data for the GG to uniquely identify the
relevant passenger.
For the USA, the Passenger Reference
should be used for this purpose.
3 Do not supply data which is insufficient to There is no provision for selecting
allow the passenger to be uniquely passengers from a list returned by the GG.
identified. If the data supplied for a passenger does
not allow the passenger to be uniquely
identified, an error condition is generated
for the passenger.
4 The CICX message can refer to either an International flights may involve up to five
international flight or a domestic flight. countries requiring the provision of APP
International flights are specified using data. The countries may include the origin,
the INT data group and (optionally) destination or transit countries of the flight
Overflight (OVR) data groups. and overflight countries.
Domestic flights are specified using the
DOM data group. Overflights should not
be used in conjunction domestic flights.
5 A CICX message should not include a
mix of passengers and crew.
6 A CICX message should not include a This situation occurs only when there are
mix of passengers or crew which will two or more passengers or crew in a CICX
result in the generation of different message and the passengers or crew hold
messages to different countries. This different types of documents.
can occur when passengers or crew in a For example, if two passengers in a single
CICX message hold different types of CICX message hold different types of
travel documents and not all countries documents and one country involved in the
involved in the journey can process all journey can process both types of
the documents in the message. documents but another country involved in
the journey cannot.
7 The APP System provides for the An airline requiring this capability should
submission of transactions for flights that contact SITA. Refer to Appendix D for
are not recorded in the Flight Schedules contact information.
i.e. Unscheduled Flights. Unscheduled flights can only be used in
The use of this capability is not CIRQ and CICX transactions and not in
recommended and is only available on CIMR, CIME or CICO transactions.
request. Airlines are encouraged to add Unscheduled flights can only be used for
unscheduled flights to the Flight INT or DOM flight segments for point-to-
Schedules and then treat the flights as point flights, because boarding directives
scheduled flights. The function to add a for intermediate countries will not be
flight to the schedules is described in received. They cannot be used for
Appendix C. Expected Flights.
Table 6 - Rules for Implementing CICX Message

Page 31
2.4 MESSAGE TYPE: MOVEMENT CANCELLATION

CONFIRMATION (CICC)
2.4.1 Purpose
This message is used to send a response to a Movement Cancellation (CICX) from the GG
to the airline DCS.
The message is used to return a mix of the following types of information:

Case Situation
Case 1 When a set of passenger data has been uniquely matched against expected movements
in a government system and a corresponding acknowledgement for the passenger can
be returned.
Case 2 When a set of passenger data has not been matched against expected movements in a
government system and a corresponding acknowledgement for the passenger cannot be
returned.
Case 3 When an error has been detected in a set of passenger data and must be corrected
before further processing for the passenger concerned.
Case 4 When an error that precludes any further processing of the original message for a
specific country is identified.

The following diagram (Figure 4) shows the overall structure of the CICC message:
Cancellation Confirmation
CICC CICC
Transaction Field count: 2
Header Instances: 1
(Mandatory)
PCC ERR
Passenger Error Field count: Variable (5+)
Cancellation Group Instances: 0-5
Response One of these (Conditional)
(Conditional) is required
(either PCC Error code and Field count: 3
or ERR) message text Instances: 1-many
Field count: 28
Instances: 0-50
Figure 4 - Overall Structure of CICC Message

Page 32

ID occurrences
Transaction None Always 1 Includes the transaction indicator (CICC) to identify the
Passenger PCC 0 to 50 The expanded data retrieved from the database of a
Cancellation government system. There may be more than one of these
Response data groups per passenger when several countries involved
in an International Flight are APP System participants.
The data group includes two types of status code:
§ Check-in Message Code and Passenger Status
Code which indicate whether or not the passenger
is known to the government system and the action
to be taken for the passenger.
§ Passenger Error Code which indicates specific data
problems with the passenger data supplied.
Error ERR 0 to 5 Serious errors that preclude further processing for the
passengers for one of the participating countries are
included in this data group.
There may be one Error Group for each participating
country involved in the transaction.
Table 7 - Message Construction for Movement Cancellation Confirmation (CICC)

Case Situation
Case 1 When a set of passenger data has been uniquely matched against expected
movements in a government system and the movement(s) have been cancelled.
A corresponding acknowledgement (Check-in Message Code 8505 for Australia) for the
passenger is returned, and the DCS can continue to process the passenger for off-
loading.
Case 2 The passenger has not been matched against expected movements, and therefore an
expected movement has not been cancelled.
The Check-in Message Code indicates the action specified by the government for that
passenger, and the DCS can continue to process the passenger to remedy the
problem.
Case 3 An error detected by the government system in a set of passenger data must be
corrected before further processing of the passenger. Processing for other passengers
may continue.
Case 4 In this case, a detected error means that there can be no further processing for the
passengers for this country. The error condition must be corrected. This case
generally only applies to system errors.

Page 33

The CICC message may include one or more Passenger Cancellation Response (PCC) data
groups which may indicate that processing has completed normally for passengers or that
there have been errors related to particular passengers. It may also include an Error Group
(ERR) notifying a serious error from one or more countries.
The Passenger Cancellation Response (PCC) data group includes a Passenger Status Code
returned for each passenger by each country. This code indicates the status of the
transaction for the passenger and the action that must be taken. The possible values of the
code are:
C The movement has been successfully cancelled. No further action is

necessary for this passenger.
N An expected movement record could not be found matching the passenger

and flight details provided. This status would not be returned if a movement
has been cancelled previously and a duplicate transaction was submitted
(the Passenger Status Code would be “C” in that case). The user should
check the data submitted and resubmit the transaction. If the problem
persists, the user should abandon attempts to cancel the expected
movement.
T The APP System for the country has not responded within the timeout period
specified. No directive from the country can be returned to the check-in
agent.
E An error condition has been detected. All error conditions must be corrected
before processing can be completed for the passengers represented in the
message.
The actions recommended above must be performed under the control of the DCS as
follows:
• Display error conditions to the user and allow the user to correct the error
conditions.
• To deal with the inability of the system to identify a previous expected
movement, the DCS must capture further passenger data and resend the
CICX message.

Page 34
It is strongly recommended that airlines implement the CICC message in the following way:
No Rule Notes
1 Within a CICC message, the primary order
of Passenger Cancellation Response
(PCC) segments will be the order of
Passenger Cancellation (PCX) segments
in the CICX message.
Within the data for an individual
passenger, the order of PCC segments for
the applicable countries will be the origin
country, transit countries in the order of
the flight, destination country and
overflight countries in the order specified
in the CICX message.
2 If the CICC message includes an Error These errors are normally of a serious nature
Group (ERR), the error message is eg. APP System unavailable, and resubmission
displayed to the user for correction and by the user may not remedy the problem.
resubmission.
3 If the CICC message includes a These errors are normally of a less serious
Passenger Cancellation Response (PCC) nature.
data group that includes an error
message, the error message is displayed
to the user for correction and
resubmission.
4 The CICC message includes a Passenger If the timeout problem persists for a significant
Status Code returned by each country for period of time and a number of cancellation
each passenger. messages have not been correctly processed,
§ If the CICC message for one or the check-in agent must contact government
more countries returns a status of agencies of each country affected and inform
“T”, the APP Systems for those them of the situation.
countries are not responding i.e. The government systems of countries
timing out. unaffected by the timeouts will continue to
§ Processing can continue. receive the correct data on expected movement
cancellations.
5 When a cancellation of an expected The third case may result in a reconciliation
movement involves more than one issue for the participating governments but the
country, the responses from the various airlines do not need to take any special action
countries could be all successful (8505), unless it becomes a frequent occurrence.
all unsuccessful (8506) or a mix. The
recommended action is:
§ All successful. Continue with no
special action.
§ All unsuccessful. Identify the
probable data input error that
caused this result and retry the
transaction.
§ Mix of successful and
unsuccessful. This may be
caused by the way the
government originally processed
the check-in transaction. The
check-in agent cannot readily
remedy this issue. Continue with
no special action.

Page 35
6 If the Expected Passenger ID from the This will provide a full record within the DCS of
CIRS message was stored against the both successful APP transactions (those with a
passenger in the DCS, overwrite this ID value for Expected Passenger ID) and
with a value (eg. “Cancelled”) to record the successful cancellations (those marked
fact that the movement has successfully “Cancelled”).
been cancelled.
7 The message definition provides for Currently, however, none of the government
multiple responses from a single country systems for participating countries support this
for any passenger. capability. For a successful cancellation, a
single movement record matching the
passenger data in the CICX message must be
identified.
Table 8 - Rules for Implementing CICC Message
2.4.6 Message Structure Scenarios

The structure of the CICC message will follow the principles of the structure of the CIRS
message described in Section 2.2.6.

Page 36
2.5 MESSAGE TYPE: MANIFEST REQUEST (CIMR)
2.5.1 Purpose
This message is used to request the generation of manifests for a country involved in an
international flight, a domestic flight or an overflight.
The functionality associated with this message is currently supported only by the USA, the
UK, South Africa, Qatar, Saudi Arabia, the UAE and Korea. While the message format is
common to all countries, the requirements of the different governments vary.
Full or incremental passenger and/or crew manifests can be requested. Alternatively, the
message can be used to notify the closure of a flight for check-in of passengers or crew, the
cancellation of a flight, or post-departure flight closeout. Not all options are supported by all
governments that accept the message.

The following diagram (Figure 5) shows the overall structure of the CIMR message:
Manifest Request CIMR

CIMR Header Instances: 1
(Mandatory)
INM MRQ
International FLT Manifest
Flight Flight Request
One of these
is required
(either INM
Field count: 5 or FLT) Field count: 6 Field count: 5
Instances: 0-1 Instances: 0-1 Instances: 1
Figure 5 - Overall Structure of CIMR Message

Page 37

ID occurrences
Transaction None Always 1 Includes the transaction indicator (CIMR) to identify the
International INM 0 or 1 The flight on which the passengers or crew are crossing the
Flight international border.
Either an INM data group or an FLT data group must be
present but both data groups may not be present in a single
message. The FLT data group with the INT flight type is
equivalent to the INM data group.
Flight FLT 0 or 1 The international flight on which passengers or crew are
crossing the border, or a domestic flight or an overflight.
Manifest MRQ Always 1 The type of manifest required for the country of origin or the
Request next country of the international flight or for a domestic flight
or an overflight. Full or incremental passenger and/or crew
manifests may be selected or, alternatively, flight close,
flight cancellation or post-departure flight closeout may be
notified.
Table 9 - Message Construction for Manifest Request (CIMR)

• Determines if the government specified in the transaction is a participant in the
APP System and is configured to process manifest requests.
• Translates the airline message into a format recognised by the participating
government.
• Forwards the message to the participating government.
• Receives a response from the participating government.
• Creates a response for return to the airline DCS. Refer to Manifest Request
Acknowledgement (CIMA) below.
The candidates for inclusion in a manifest generated as a result of the request will be all
passengers or crew on the flight to or from the specified country. For inbound flights, it will
include all passengers or crew on the flight, including those transiting on the same flight and
those transferring to another outbound flight. For outbound flights, it will include all
passengers or crew on the flight, including those who arrived in the country on the same
flight and those who are transiting the country after arriving on a different flight. For domestic
flights or overflights it will include all passengers or crew.

Page 38
When the manifest request is related to a flight to or from the UK or Korea, or a flight to,
from, within or overflying the USA, the system will generate a manifest message which either
notifies that the flight has been cancelled, or provides information on all passengers or crew
on the flight or on passengers or crew who were successfully processed through the APP
System for the flight but did not board the flight.
When the manifest request is related to a flight to or from South Africa, Qatar, Saudi Arabia,
or the UAE, the system will generate a manifest message which notifies that the flight has
been closed. It will not send data on passengers or crew to the government as this will have
already been transmitted to the government as a result of processing of APP Check-in and
Cancellation transactions.

It is strongly recommended that airlines implement the CIMR message in the following way:
No Rule Notes
1 Manifests may only be requested if the Prior to using this function, airlines should
government is configured to generate contact the appropriate government agency to
them. ensure that the facility is available and to agree
on the conditions under which it can be used.
Currently the message is supported by the
government systems for the USA, the UK,
Korea, South Africa, Qatar, Saudi Arabia and
the UAE.
2 A manifest may be requested for only one If a manifest is required for more than one
country at a time. country for a given flight eg. for both the origin
country and the destination country for a flight,
then two Manifest Request (CIMR) messages
must be generated, one for each country.
For example, for a flight from LHR to JFK where
both the US and UK governments require a
manifest, the carrier should send the first
manifest request message and wait for the
manifest response to be returned before
sending the next manifest request message.
Therefore:
§ Carrier sends a CIMR for the UK to the
GG,
§ Carrier waits for a CIMA response for
the UK CIMR,
§ Carrier sends a CIMR for the US to the
GG
§ Carrier waits for a CIMA response for
the US CIMR.
3 A manifest may be requested only for the
country of origin of the flight or the next
country in which the flight lands.
4 Generation of the CIMR message should If the flight is reopened, the manifest can be
be linked to the closing of the flight to generated in full when the flight is again closed
further check-in. or the incremental manifest can be generated.
The latter approach, however, may not correctly
record passengers as having been off-loaded
from the flight.

Page 39
5 The INM data group may be used to notify Only one INM data group or one FLT data group
details of an international flight. may be included in a message. It is
The FLT data group may be used to notify recommended that the FLT data group be used
details of an international flight, a as this caters for all types of flight.
domestic flight or an overflight.
6 For the interface to the US CBP AQQ Airlines using this function should check
System, acknowledgement of the request processing rules with the appropriate
is not sent to the airline until the APP government authority.
System receives an acknowledgement Generation of the manifest can be checked
from the AQQ System. using the Manifest Enquiry (CIME) message.
Implementation for other countries may be
different. Acknowledgement of this
message by the APP System may not be
an acknowledgment that the manifest has
been generated and delivered. It may
only be an acknowledgement of the
queuing of the request.
7 The APP System does not provide for the
submission of transactions for flights that
are not recorded in the Flight Schedules
i.e. Unscheduled Flights.
Table 10 - Rules for Implementing CIMR Message
Note on flight dates

The APP System only allows manifest transactions on flights with a departure date from 2
days before the current date to 10 days after the current date (local time).
For example, if the current date is 10 June, flights with a departure date between 8 June
and 20 June can be submitted for processing.
Any transaction for a flight which is outside this date range will be rejected.

Page 40
2.6 MESSAGE TYPE: MANIFEST REQUEST

ACKNOWLEDGEMENT (CIMA)
2.6.1 Purpose
This message is used to send a response to the DCS to acknowledge that a Manifest
Request (CIMR) message has been received and to indicate the result of the initial
processing of the request.

Case Situation
Case 1 When passengers have been checked in for a flight, a manifest has been requested and
the request has been processed. A Manifest Response Code of 8700 (Request
processed) will be returned.
Case 2 When no passengers have been checked in for a flight, a manifest is requested and the
request has been processed but rejected as there are no passengers on the manifest. A
Manifest Response Code of 8701 (Request rejected) will be returned.
Case 3 When an error has been detected in the request. A Manifest Response Code of 8701
(Request rejected) will be returned.

The following diagram (Figure 6) shows the overall structure of the CIMA message:
Manifest Request Acknowledgement CIMA

CIMA Header Instances: 1
(Mandatory)
ERR
MAK Error Field count: Variable (5+)
Manifest Group Instances: 0-1
Response One of these (Conditional)
(either MAK Error code and Field count: 3
Field count: 6
Instances: 0-1
Figure 6 - Overall Structure of CIMA Message

Page 41

ID occurrences
Transaction None Always 1 Includes the transaction indicator (CIMA) to identify the
Manifest MAK 0 to 1 An acknowledgement that the participating government has
Response NOTE: There received the Manifest Request (CIMR) message and the
must be result of processing of the message. If a government has
either one rejected the request, this rejection will be flagged in the
MAK or one message and an error code will be returned.
ERR group in
the message.
Error ERR 0 or 1 Serious errors that preclude further processing of the
manifest request are included in this data group. Each
error is related to the participating government system.
Table 11 - Message Construction for Manifest Request Acknowledgement (CIMA)

Case Situation
Case 1 No further action is required immediately. An enquiry may be made later to confirm that
data for all passengers has been generated in manifests sent to the participating
government.
Case 2 Even though there are no further passengers to generate in a manifest, the request will
be processed. An error condition will not be returned.
Case 3 An error detected by the government system in the request must be corrected before
further processing of the request.

Page 42
2.7 MESSAGE TYPE: MANIFEST ENQUIRY (CIME)
2.7.1 Purpose
This message is used to enquire upon the status of manifests for a given international flight,
domestic flight or overflight.

The following diagram (Figure 7) shows the overall structure of the CIME message:
Manifest Enquiry CIME

CIME Header Instances: 1
(Mandatory)
INM MEN
International FLT Manifest
Flight Flight Enquiry
One of these
is required
(either INM
Field count: 5 or FLT) Field count: 6 Field count: 5
Figure 7 - Overall Structure of CIME Message

ID occurrences
Transaction None Always 1 Includes the transaction indicator (CIME) to identify the
Manifest MEN Always 1 The country for which the manifest status is required.
Request
Table 12 - Message Construction for Manifest Enquiry (CIME)

Page 43

APP System and is configured to process manifest requests.
government.
• Creates a response for return to the airline DCS. Refer to Manifest Status
(CIMS) below.

It is strongly recommended that airlines implement the CIME message in the following way:
No Rule Notes
1 A manifest enquiry may be submitted for If a manifest for more than one country is
only one country at a time. required for a given flight eg. for both the origin
country and the destination country for a flight,
then two Manifest Enquiry (CIME) messages
must be generated, one for each country, to
determine the complete status of manifests.
2 A manifest enquiry may be submitted only
for the country of origin of the flight or the
next country in which the flight lands.
3 Depending upon implementation for a There may be a delay in delivery of a manifest
country, acknowledgement of this due to queuing and communications problems.
message by the APP System is not a
confirmation that the manifest has been
received by the government system. It
may only be an acknowledgement of the
generation and queuing of the manifest for
transmission to the government system.
5 It would be beneficial for airlines to This will ensure that a complete manifest has
compare the result of the manifest enquiry been generated.
with the number of passengers or crew
checked in for the flight with a destination
of the country for which the manifest was
generated.
Table 13 - Rules for Implementing CIME Message

Page 44
2.8 MESSAGE TYPE: MANIFEST STATUS (CIMS)
2.8.1 Purpose
This message is used to send a response to a Manifest Enquiry (CIME) from the GG to the
airline DCS.

Case Situation
Case 1 When passengers have been checked in for a flight, a manifest has been requested and
the request has been accepted and queued. The response to the enquiry will include the
current status giving the number of passengers checked in for the flight and the number
generated in manifests.
Case 2 When an error has been detected in the request. An error code will be returned.

The following diagram (Figure 8) shows the overall structure of the CIMS message:
Manifest Status CIMS

CIMS Header Instances: 1
(Mandatory)
ERR
MST Error Field count: Variable (5+)
Manifest Group Instances: 0-1
Status One of these (Conditional)
(either MEN Error code and Field count: 3
Field count: 9
Instances: 0-1
Figure 8 - Overall Structure of CIMS Message

Page 45

ID occurrences
Transaction None Always 1 Includes the transaction indicator (CIMS) to identify the
Manifest MST 0 to 1 For the country specified in the Manifest Enquiry (CIME)
Status NOTE: There message, this data set will return statistics on the number of
must be expected movements for passengers and crew that have
either one been processed for the specified flight, and the number of
MST or one passengers and crew who have been included in manifests.
ERR group in If an error occurs during processing, this is indicated with
the message. an error code and error message.
manifest enquiry are included in this data group. Each error
is related to the participating government system.
Table 14 - Message Construction for Manifest Status (CIMS)

Case Situation
Case 1 Once the response to the enquiry has been returned, no further action is required
immediately.
Case 2 An error detected by the government system in the enquiry must be corrected before
further processing of the enquiry.

Page 46
2.9 MESSAGE TYPE: PASSENGER STATUS REQUEST (CICO)
2.9.1 Purpose
This message is used to request information on changes to the status of passengers for
whom previous Check-in Requests were submitted for a given flight.
To cater for the possibility that there may be a large number of passengers on the flight for
whom status update information must be provided, the enquiry/response protocol provides
for a series of interactions between the airline and the GG, each returning the status changes
for a block of passengers.
The functionality associated with this message is currently only supported for use with the
APIS Quick Query (AQQ) System operated by U.S. Customs and Border Protection (CBP).

The following diagram (Figure 9) shows the overall structure of the CICO message:
Passenger Status Request CICO

CICO Header Instances: 1
(Mandatory)
INM FLT PSQ

International Flight Passenger
Flight One of these (Conditional) Status
(Conditional) is required Request
(either INM (Mandatory)
or FLT)
Field count: 5 Field count: 6 Field count: 4
Figure 9 - Overall Structure of CICO Message

Page 47

ID occurrences
Transaction None Always 1 Includes the transaction indicator (CICO) to identify the
Passenger PSQ Always 1 The country for which the status information is required and
Status a paging indicator for managing requests for subsequent
Request blocks of passengers (where applicable).
Table 15 - Message Construction for Passenger Status Request (CICO)

APP System and is configured to process passenger status requests.
government.
• Creates a response for return to the airline DCS. Refer to Passenger Status
Response (CIUR) below.

Page 48

It is strongly recommended that airlines implement the CICO message in the following way:
No Rule Notes
1 A passenger status request may be If changes to passenger status are required for
submitted for only one country at a time. more than one country for a given flight eg. for
both the origin country and the destination
country for a flight, then two Passenger Status
Request (CICO) messages must be generated,
one for each country.
3 The response to the Passenger Status The provision of multiple blocks of passenger
Request (CICO) message is the data is handled by the Page Reference data
Passenger Status Response (CIUR). It item in the Passenger Status Request (CICO)
has provision for including information on message. In the initial request message, this
a maximum of 20 passengers in each indicator will be set to 1. If the Passenger
response message. In cases where there Status Response (CIUR) indicates there is
are more than 20 passengers for whom further data available, the Page Reference in
data must be provided to the airline, the subsequent CICO messages must be
response message will indicate that more incremented to 2, 3, etc until the CIUR message
data is available. The airline must indicates there is no further data to be provided.
specifically request the provision of the A given page of data may be requested again if
next block of passenger data until a it has not been correctly received by the DCS,
response indicates that there is no further by retransmitting the CICO message with the
data to be provided. same Page Reference. However, the DCS may
only request the transmission of the same page
again or the next page. It may not request
retransmission of an earlier page.
4 Passenger status updates can be It is recommended that airlines perform this
requested at any time during the check-in function as early as possible in the check-in
process and can be requested any process to facilitate any necessary off-loading of
number of times. passengers.
Note, however, that processing of a subsequent
CICO message will return data on all status
updates for the flight, including updates that
have already been returned to the DCS as the
result of an earlier request.
5 If there is no passenger status update The CIUR message will be constructed
information to be provided, the CIUR normally, but will contain no passenger
message will still be generated, but will information and the Page Continuation Indicator
contain no status information. will indicate that there is no further data to
provide.

Page 49
6 When the status of a passenger is altered The airlines must either:

from OK to Board to Contact CBP or Do § Off-load the passenger and send a
Not Board, the airline must take action to Movement Cancellation (CICX)
resolve the issue. message; or
§ Contact CBP to resolve any issues. If
CBP agrees that the passenger may
board the flight, the airline must send
another Check-in Request (CIRQ)
message for the passenger to ensure it
receives an OK to Board response from
CBP.
Table 16 - Rules for Implementing CICO Message
2.10 MESSAGE TYPE: PASSENGER STATUS RESPONSE (CIUR)
2.10.1 Purpose
This message is used to send a response to a Passenger Status Request (CICO) from the
GG to the airline DCS.

Case Situation
Case 1 When passengers have been checked in for a flight and changes in the status of up to 20
passengers have been received from the government system, the response to the first
CICO message will include the status changes for the passengers and an indication that
there is no more data to be provided.
Case 2 When passengers have been checked in for a flight and changes in the status of more
than 20 passengers have been received from the government system, the response to
the first (or subsequent) CICO message will indicate that there is more data to be
provided.
Case 3 When an error has been detected in the request. An error code will be returned.

The following diagram (Figure 10) shows the overall structure of the CIUR message:

Page 50
Passenger Status Response CIUR

CIUR Header Instances: 1
(Mandatory)
ERR
PST Error Field count: Variable (5+)
Passenger Group Instances: 0-1
Status One of these (Conditional)
(either PST Error code and Field count: 3
Field count: Variable (8+)
Instances: 0-1
Figure 10 - Overall Structure of CIUR Message

ID occurrences
Transaction None Always 1 Includes the transaction indicator (CIUR) to identify the
Passenger PST 0 to 1 For the country specified in the Passenger Status Request
Status NOTE: There (CICO) message, this data set will return information on
must be passenger status updates.
either one
PST or one
ERR group in
the message.
request are included in this data group. Each error is
related to the participating government system.
Table 17 - Message Construction for Passenger Status Response (CIUR)

Case Situation
Case 1 The airline will process the status updates according to its business rules and check-in
procedures. Since the response has indicated that there is no further status update
information available, no further action is required immediately.
Case 2 The airline will process the status updates according to its business rules and check-in
procedures. Since the response has indicated that there is further status update
information available, the airline will generate another message requesting the next
block of passenger information.
Case 3 An error detected by the government system in the request must be corrected before
further processing of the request.

Page 51
2.11 MESSAGE TYPE: GATE PASS REQUEST (CIGR)
2.11.1 Purpose
This message is used to request permission to issue a gate pass for a person entering the
secure area of an airport to accompany a passenger to a boarding gate.
The functionality associated with this message is currently supported only by the USA as part
of the Secure Flight program.

The following diagram (Figure 11) shows the overall structure of the CIGR message:
Gate Pass Request CIGR
CIGR Header Instances: 1
(Mandatory)
GPR
Gate Pass Field count: 18
Request Instances: 1-5
(Mandatory)
Figure 11 - Overall Structure of CIGR Message

ID occurrences
Transaction None Always 1 Includes the transaction indicator (CIGR) to identify the
function being performed and the country, airline, airport
and date for which the gate pass is required.
Gate Pass GPR 1 to 5 The bio-data and document data for the person for whom
Request the gate pass is requested, and the booking reference for
the passenger.
Table 18 - Message Construction for Gate Pass Request (CIGR)

APP System and is configured to process gate pass requests.
government.

Page 52

• Creates a response for return to the airline DCS. Refer to Gate Pass
Response (CIGS) below.

It is strongly recommended that airlines implement the CIGR message in the following way:
No Rule Notes
1 A gate pass may only be requested if the Prior to using this function, airlines should
APP System for a government is contact the appropriate government agency to
configured to support the function. ensure that the facility is available and to agree
on the conditions under which it can be used.
Currently the message is supported by the
government system for the USA only.
2 A gate pass may be requested for only
one country at a time.
Table 19 - Rules for Implementing CIGR Message
2.12 MESSAGE TYPE: GATE PASS RESPONSE (CIGS)
2.12.1 Purpose
This message is used to send a response to the DCS to acknowledge that a Gate Pass
Request (CIGR) message has been received and to indicate the result of the processing of
the request.

Case Situation
Case 1 When a person has been checked and a gate pass can be issued. A Check-in Message
Code of 8580 (Cleared) will be returned.
Case 2 When a person has been checked and a gate pass cannot be issued. A Check-in
Message Code of 8581 (Not cleared) will be returned.
Case 3 When a person has been checked and a gate pass can be issued but the person must
be subject to additional security checks. A Check-in Message Code of 8582 (Selectee)
will be returned.

Page 53

The following diagram (Figure 12) shows the overall structure of the CIGS message:
Gate Pass Response CIGS

CIGS Header Instances: 1
(Mandatory)
ERR
GPS Error
Gate Pass Group
Response Field count: Variable (5+)
One of these (Conditional) Instances: 0-1
Field count: 7 (Conditional) is required
Instances: 0-5
(either GPS Error code and
or ERR) message text Field count: 3
Instances: 1-many
Figure 12 - Overall Structure of CIGS Message

ID occurrences
Transaction None Always 1 Includes the transaction indicator (CIGS) to identify the
Gate Pass GPS 0 to 5 An acknowledgement that the participating government has
Response NOTE: There received the Gate Pass Request (CIGR) message and the
must be result of processing of the message. If the government has
either at least rejected the request, this rejection will be flagged in the
one GPS or message and an error code will be returned.
one ERR
group in the
message.
Error ERR 0 or 1 Serious errors that preclude further processing of the Gate
Pass Request are included in this data group. Each error is
related to the participating government system.
Table 20 - Message Construction for Gate Pass Response (CIGS)

Case Situation
Case 1 The Gate Pass can be issued.
Case 2 The Gate Pass cannot be issued.
Case 3 The Gate Pass can be issued but the person will undergo a more thorough security
check before being permitted to enter the secure area of the airport.

Page 54
3. DIALOGUE TYPES
All communication between the DCS and the GG consists of a request from the DCS
followed by a response from the GG. All dialogues are therefore initiated by the DCS.
Some dialogues are longer than this simple two-part question and answer structure, and the
examples below are provided to clarify how these dialogues can occur.
3.1 CHECK-IN REQUEST (SIMPLE)

This is the simplest and most common APP dialogue. A check-in request is made for one or
more passengers, and a boarding directive is received for each of these passengers. Note
that the directive may be positive (“OK to Board”) or negative (“Do not Board”).
Dialogue Structure
Message Message from DCS Message from GG
no
1 CIRQ (data for one or more pax)
2 CIRS (with a directive for each pax).
Note that this directive may be positive or
negative.
3.2 CHECK-IN REQUEST (DUPLICATES)

If there are endorsees on a passport, and insufficient data is supplied to uniquely identify a
passenger, the APP System will either send all of the duplicates, or will ask the check-in
agent to supply more data for the passenger. (The flag which determines this choice is the
Handle Multiple Response flag which occurs in both the CIRQ and CICX messages).
Dialogue Structure
no
2 CIRS (eg. code 8507 “Duplicate Name”)
3 CIRQ (including data which
uniquely identifies each pax)
4 CIRS (a directive for each pax)

Page 55
3.3 CHECK-IN REQUEST (ERROR: INCORRECT DATA SUPPLIED)

If a check-in transaction is attempted with incorrect data, an error code will be included in the
response. When the request is resubmitted with correct data, and the passenger(s) can be
correctly identified and/or assessed, the response will contain a directive for each passenger.
Dialogue Structure
no
2 CIRS (eg. code 6003 “Invalid Nationality Code”)
3 CIRQ (corrected data)
4 CIRS (a directive for each pax)
3.4 CANCELLATION REQUEST (SIMPLE)

The cancellation transaction should be used where a passenger is not going to board a
flight, but has already been APP processed, and has been given a “positive” directive to
board.
Note that this dialogue type should only occur following a successful check-in request, and
that therefore for each passenger involved there will have been two requests (CIRQ and
CICX) and two responses (CIRS and CICC).
Dialogue Structure
no
1 CICX (data for one or more pax)
2 CICC (an acknowledgement for each pax)
3.5 CANCELLATION REQUEST (ERROR: NO MOVEMENT EXISTS)

This dialogue type will occur when the check-in agent mistakenly believes that a passenger
who has already been APP processed has an expected movement record that needs to be
cancelled. If, however a negative directive such as “Do not Board” is received for a
passenger, no expected movement record is created by the APP System.
Dialogue Structure
no
2 CICC (eg. code 8506 “No Record”)
3.6 CANCELLATION REQUEST (ERROR: INCORRECT DATA

SUPPLIED)
This type of dialogue will occur when the check-in agent does not supply the correct data to
identify a passenger who has already been APP processed and has an expected movement
record that needs to be cancelled.

Page 56
Dialogue Structure
no
2 CICC (eg. code 8506 “No Record”)
3 CICX (corrected data)
4 CICC (an acknowledgement for each pax)
3.7 MANIFEST REQUEST

A manifest request is made for a specified flight for a specified country. Acceptance of the
request indicates that the request has been queued for further processing. It does not
indicate that there are passengers or crew for whom check-in transactions have been
processed and who will be included in a manifest. Nor does it indicate that a manifest has
been generated and sent to the government system.
Dialogue Structure
no
1 CIMR (data for one flight for one
country)
2 CIMA (an acknowledgement that the manifest
request has been processed). It may or may not
mean that the manifest has actually been
generated and received by the government
authority. Refer to Table 10 for further
information.
3.8 MANIFEST REQUEST (ERROR: INCORRECT DATA SUPPLIED)

If a manifest request is attempted with incorrect data, an error code will be included in the
response. When the request is resubmitted with correct data, the response will contain an
acknowledgement that the request has been accepted and queued.
Dialogue Structure
no
1 CIMR (data for one flight for one
country)
2 CIMA (eg. error code 5656 “Country does not
require manifests”)
3 CIMR (corrected data)
4 CIMA (an acknowledgement that the manifest
request has been processed).

Page 57
3.9 MANIFEST ENQUIRY

A manifest enquiry is made for a specified flight for a specified country. The response
indicates the number of passengers and/or crew that have been checked in for the flight and
the number that have been generated in manifests.
Dialogue Structure
no
1 CIME (data for one flight for one
country)
2 CIMS (an indication of the number of passengers
and/or crew checked in and generated in
manifests)
3.10 MANIFEST ENQUIRY (ERROR: INCORRECT DATA SUPPLIED)

If a manifest enquiry is attempted with incorrect data, an error code will be included in the
response. When the enquiry is resubmitted with correct data, the response will contain the
manifest status.
Dialogue Structure
no
1 CIME (data for one flight for one
country)
2 CIMS (eg. error code 5656 “Country does not
require manifests”)
3 CIME (corrected data)
4 CIMS (an indication of the number of passengers
and/or crew checked in and generated in
manifests)

Page 58
3.11 PASSENGER STATUS REQUEST

A passenger status request is made for a specified flight for a specified country. The
response provides unsolicited updates to passenger status that have been received from the
government for that flight and indicates that there is no further data available.
Dialogue Structure
no
1 CICO (data for one flight for one
country)
2 CIUR (changes to the status of passengers for
whom check-in transactions have previously been
submitted for that flight)
3.12 PASSENGER STATUS REQUEST (TWO BLOCKS OF

PASSENGERS)
A passenger status request is made for a specified flight for a specified country. The
response provides unsolicited updates to passenger status that have been received from the
government for that flight and also indicates that data on more passengers is available. The
airline submits a request for more information. The next response provides information on
more passengers but indicates that no further information is available.
Dialogue Structure
no
country)
whom check-in transactions have previously been
submitted for that flight; indication that data is
available on more passengers)
country, request for second block
of passenger data)
4 CIUR (a further block of changes to the status of
passengers for whom check-in transactions have
previously been submitted for that flight;
indication that no further data is available)

Page 59
3.13 PASSENGER STATUS REQUEST (ERROR: INCORRECT DATA

SUPPLIED)
A passenger status request is made for a specified flight for a specified country but fails
validation checks and an error code is included in the response. When the request is
resubmitted with correct data, the response will contain the requested information.
Dialogue Structure
Message no Message from DCS Message from GG
country)
2 CIUR (eg. error code 5593 “International flight
not in airline schedules”)
3 CICO (corrected data)
whom check-in transactions have previously
been submitted for that flight)
3.14 GATE PASS REQUEST

A gate pass request is submitted for one or more persons for a specified flight, airport and
date. Acceptance of the request for a person indicates that a gate pass can be issued for
that person.
Dialogue Structure
1 CIGR (data for one or more
persons)
2 CIGS (a response to the gate pass request).
The response for each person in the request
indicates whether or not a gate pass can be
issued for the person.
3.15 GATE PASS REQUEST (ERROR: INCORRECT DATA

SUPPLIED)
If a gate pass request is attempted with incorrect data, an error code will be included in the
response. When the request is resubmitted with correct data, the response message will
contain the appropriate responses for the requests.
Dialogue Structure
1 CIGR (gate pass request for one
or more persons)
2 CIGS (eg. error code 6046 “Check-in port
required”)
3 CIGR (corrected data)
4 CIGS (responses to the gate pass requests).

Page 60
4. MESSAGE FORMATS
4.1 OVERALL MESSAGE STRUCTURE
When an airline chooses to implement Advance Passenger Processing (APP) integrated with
its Departure Control System (DCS), data will be exchanged between the DCS and the GG
using messages that conform to SITA’s version of the IATA Host-to-Host Protocol (HTH).
Within the HTH standard, the following rules will apply:
4.1.1 Rules for Layer 7

Airlines must implement Layer 7 of the message in the following way:
No Rule Notes
1 Comply with the specification
Implementing IATA Host to Host
Exchanges with SITA ATLDC
Applications, Version 1.1, as produced by
SITA ATLIS, taking special note of the
Layer 7 requirements in communicating
with SITA ATLIS.
2 Include the data listed in Table 22 below.
Note that four of the data elements are
mandatory, two are optional and the
remainder are not used by the APP
system.
3 Include sufficient data to ensure that the Identification of the user’s location is a crucial
source of the transaction can be identified. aspect of the APP System.
Although some of the Layer 7 data is optional or
is not used, the airline must be able to identify
the source of the transaction
Table 21 - Rules for Implementing Layer 7 of a Message
Data item Data Mandatory/ Usage notes

type/size optional
GFI/Type A(1) Mandatory “V”
Airline Code X(3) Mandatory IATA Airline Code
eg. DL.
City Code X(4) Mandatory IATA City Code or Pseudo City Code
eg. ATL.
Department Code X(3) Not used
FCC X(1) Not used
Screen Size N(5) Optional This field is not required for Integrated APP since
no data is directly displayed on the user screen by
the APP System
eg. 24080.
Ticketing Printer N(6) Not used
Number
Airfare Agent ID N(4) Not used

Page 61
Airfare/Ticketing N(2) Not used

Security
Target Airline Code X(3) Not used
IATA Number X(8) Optional Although this data is optional, the airline must be
able to identify the source of the transaction
eg. 12345678.
Country Code A(2) Mandatory IATA Country Code
eg. US.
Table 22 - Data Items in Layer 7 of the APP Message
4.1.2 Rules for Body of Message

Airlines must implement the body of the message in the following way:
No Rule Notes
1 Comply with the specific usage set out in The rules specified in this document are
the tables below for data items in the body designed to be applicable to multiple
of the message. governments and to be applicable for generating
This usage is determined by the advance passenger information for both ends of
government implementing Advance an international journey and transit points.
Passenger Processing.
2 Comply with the maximum length Longer fields may be truncated during
specified in the tables below for data items processing.
in the body of the message.
3 Use slash (/) as the delimiter character to It is necessary that the information in the data
separate data items. items does not contain the delimiter character.
4 Use only the colon (:) character as the [eg. “CIRQ:”, “CIRS:”, “CICX:”, “CICC:”]
delimiter character after the Transaction
Code.
5 Indicate null data items as two [eg. “//”]
consecutive delimiter characters.
6 Transmit all fields, including trailing empty Even trailing optional empty fields must be
fields. transmitted.
7 Follow the rules for grouping of data items Data items are arranged in groups, each
in the body of the message. including a particular type of data. A group
identifier will precede each group. Some groups
will be mandatory in a message while others will
be optional. Within a group each data item must
be present (but may be null).
8 Country codes used for Passport Country Note that the ICAO 3-character code set has
Code (Nationality), Issuing State and one code of length one character i.e. “D” –
Country of Birth should be provided as Germany. The 3-character code “DEU” is also
ICAO 3-character codes. accepted for Germany.
The system currently accepts IATA 2-
character country codes for some airlines,
but this option will be phased out. It
should not be used.
Table 23 - Rules for Body of Message

Page 62
4.1.3 Rules for Layer 5 Address

In order to access the appropriate version of the Integrated Advance Passenger Processing
application, airlines must implement Layer 5 addressing in the message with the following
value:
Production Version Demo/Test Version
5APPXS 5APTXS
Table 24 - Layer 5 Addresses for APP Messages

Page 63
4.2 MESSAGE TYPE: CHECK-IN REQUEST (CIRQ)

The following table provides the layout for the CIRQ message. A field number within each data group is supplied only for ease of reference,
and these numbers are not used within the messages. Refer to Appendix E for details of the data requirements specific to the various APP-
participating countries.
Data group No Data item Data Mandatory Value Notes
type/ /
size optional
Transaction 1 Transaction A(4) Mandatory “CIRQ” Must be followed by colon.
Code
2 Airline Private X(14) Optional Free for use by the airline for reference This data is returned to the airline in the response
Data purposes. message (CIRS). For example, it could be used
to store the Airline Source Transaction ID.
3 User ID X(6) Mandatory Airline user identifier
4 Handle Multiple A(1) Mandatory Y= the user location can handle If “Y”, the GG will return duplicate names (if
Response duplicate names (endorsees). applicable) for the user to select one.
N= the user location cannot If “N”, the GG will return only an error code (if
handle duplicate names. applicable).
5 Transaction A(1) Optional Blank = Check-in Transaction
Type Qualifier P = Pre-Check-in Vetting
B = Boarding Gate Check
6 Message N(3) Mandatory Indicates the format of the following Set to ”21” if only unshaded data items will be
Version message. sent and received.
Set to “24” if unshaded data items and data items
shaded in green will be sent and received.
shaded in green and blue will be sent and
received.
shaded in green, blue and orange will be sent and
received.
shaded in green, blue, orange and purple will be
sent and received.
Commercial-in-Confidence V7.1 (May 2019) Page 64

shaded in green, blue, orange, purple and red will
be sent and received.
shaded in green, blue, orange, purple, red and
teal will be sent and received.
Check-in 1 Check-in Flight A(3) Conditional “CHK” Must be provided if the Check-in Flight is not the
Flight Group Identifier same as the International Flight.
2 Check-in Flight N(2) Conditional Number of fields which follow in this Set to 2 for current message definition.
Group Field data group. Conditional (required if this group is present)
Count
3 Check-in Port X(5) Conditional IATA Airport Code eg. SYD
Conditional (required if this group is present)
4 Check-in Flight X(8) Conditional Airline and flight number. eg. BA031
International 1 International A(3) Conditional “INT” Either an “INT” group or a “DOM” group must be
Flight Flight Group present.
Identifier
2 International N(2) Conditional Number of fields which follow in this Set to 8 for current message definition.
Flight Group data group. Conditional (required if this group is present)
Field Count
3 Scheduled/ A(1) Conditional S = Scheduled Flight “Unscheduled” means delayed, charters, etc.
Unscheduled U = Unscheduled Flight (The “Unscheduled” option is not generally
Flight supported. Refer to Table 2 for information on
exceptions.)
4 International X(8) Conditional Airline and flight number eg. BA031
Flight Conditional (required if this group is present)
5 International X(5) Conditional IATA Airport Code eg. SIN
Flight Origin Conditional (required if this group is present)
6 International X(5) Conditional IATA Airport Code eg. SYD
Destination

7 International N(8) Conditional CCYYMMDD Date of departure from the International Flight
Flight Date Origin.
eg. 20021105
8 International N(6) Conditional HHMMSS Time of departure from the International Flight
Flight Time Origin.
eg. 124500
Conditional (mandatory for unscheduled flights)
9 International N(8) Conditional CCYYMMDD Date of arrival at the International Flight
Flight Arrival Destination.
Date eg. 20021105
10 International N(6) Conditional HHMMSS Time of arrival at the International Flight
Time eg. 134500
Domestic 1 Domestic Flight A(3) Conditional “DOM” Either an “INT” group or a “DOM” group must be
Flight Group Identifier present.
2 Domestic Flight N(2) Conditional Number of fields which follow in this Set to 8 for current message definition.
Group Field data group. Conditional (required if this group is present).
Count
exceptions.)
4 Domestic Flight X(8) Conditional Airline and flight number eg. AA427
5 Domestic Flight X(5) Conditional IATA Airport Code eg. JFK
Origin Conditional (required if this group is present)
6 Domestic Flight X(5) Conditional IATA Airport Code eg. ATL
Destination Conditional (required if this group is present)

7 Domestic Flight N(8) Conditional CCYYMMDD Date of departure from the Domestic Flight Origin.
Date eg. 20021105
8 Domestic Flight N(6) Conditional HHMMSS Time of departure from the Domestic Flight Origin.
Time eg. 124500
9 Domestic Flight N(8) Conditional CCYYMMDD Date of arrival at the Domestic Flight Destination.
Arrival Date eg. 20021105
10 Domestic Flight N(6) Conditional HHMMSS Time of arrival at the Domestic Flight Destination.
Arrival Time eg. 134500
Overflight 1 Overflight Group A(3) Conditional “OVR” May only be present if an “INT” group is present.
(repeating) Identifier
2 Overflight Group N(2) Conditional Number of fields which follow in this Set to 3 for current message definition.
Field Count data group. Conditional (required if this group is present)
3 Airport of Origin X(5) Conditional IATA Airport Code eg. ACA (Acapulco)
of Overflight Conditional (required if this group is present)
Segment
4 Airport of X(5) Conditional IATA Airport Code eg. YVR (Vancouver)
Destination of Conditional (required if this group is present)
Overflight
Segment
5 Country A(2) Conditional IATA Country Code eg. US
Overflown Conditional (required if this group is present)
Expected 1 Expected Flight A(3) Conditional EXO = Expected Flight data for A separate Expected Flight Group may be present
Flight Group Identifier country of origin of for each end of an international movement.
(repeating) international movement. Conditional (if the passengers do not embark on
EXD = Expected Flight data for or disembark from the International Flight at the
country of destination of port where they clear Customs and Immigration
international movement. i.e. the Expected Port, this data group is required).
2 Expected Flight N(2) Conditional Number of fields which follow in this Set to 4 for current message definition.
Count

3 Expected Port X(5) Conditional IATA Airport Code. Conditional (required if this group is present)
4 Expected Flight X(8) Conditional Airline and flight number. Conditional (required if this group is present)
5 Expected Date N(8) Conditional CCYYMMDD Conditional (required if this group is present)
6 Expected Time N(6) Conditional HHMMSS Conditional (required if this group is present)
Passenger 1 Passenger A(3) Mandatory “PRQ”
Request Request Group
(repeating) Identifier
2 Passenger N(2) Mandatory Number of fields which follow in this Set to 22 for Message Version 21 compatibility.
Request Group data group. Set to 26 for Message Version 24 compatibility.
Field Count
Set to 33 for Message Version 25 compatibility.
Set to 35 for Message Version 27 and Version 28
compatibility.
Set to 36 for Message Version 30 compatibility
3 Passenger N(3) Mandatory The sequence number of the A maximum of five occurrences of this data group
Sequence passenger in the message. can be included in each message. The value of
Number the Passenger Sequence Number can be in the
range 1 to 999.
4 Pax/Crew A(1) Mandatory P = Passenger Code “P” may be used for flights to all countries to
Indicator C = Operating crew indicate a Passenger.
X = Positioning crew Codes “C” and “X” may be used for flights for all
countries except the USA to indicate a Crew
The following codes are required to
member.
more accurately describe crew for
flights to or from the USA: For flights to or from the USA, the following codes
must be used for Crew. The codes are translated
F = Flight Crew
to the codes “CR1” to “CR5” for transmission to
A = Flight Attendant the USA, and to the codes “P”, “C”, or “X” for
O = Airline Operations Management transmission to other countries:
N = Non-crew F = Flight Crew (“CR1”, “C”)
D = Deadhead Crew A = Flight Attendant (“CR2”, “C”)
O = Airline Operations Management (“CR3”, “C”)
N = Non-crew (“CR4”, “P”)
D = Deadhead Crew (“CR5”, “X”)

5 Passport A(3) Conditional Nationality of passenger. eg. NZL
Country Code (see Notes) Country code (ICAO [3-character Note that the ICAO 3-character code set has one
code]). code of length one character i.e. “D” – Germany.
Code “DEU” is also accepted for Germany.
Mandatory for all cases except Pre-Check-in
Vetting for the USA.
6 Issuing State A(3) Conditional Country code (ICAO [3-character Optional for a check-in enquiry. May be required
(see Notes) code]). by some countries if the passenger is not
previously known so data must be captured, and
the passenger holds a travel document that
indicates Issuing State.
Note that the ICAO 3-character code set has one
code of length one character i.e. “D” – Germany.
7 Passport ID X(20) Conditional Passport or other travel document eg. N364028
number Conditional (required if Document Type is “P”,
must be blank if Document Type is “N”).
Should be provided if available.
A minimum of 3 characters must be provided for
the USA.
8 Passport Check X(1) Optional Value taken from MRZ
Character
9 Travel A(2) Optional Passport or other document type. For Check-in: Defaults to “P” if not given.
Document Type Recommended document types are: For Pre-Check-in Vetting: Defaults to “N if not
P = Passport given.
O = Other travel document For Version 24, if the flight involves the USA and if
N = No travel document “O” is used, information on the travel document
should be provided in the Passenger Additional
I = Identity Card
Data (PAD) data group.
Some countries may accept other
For Version 26, two characters may be provided.
types.
Carriers should check to ensure that the
document type provided is accepted by the
countries involved in the journey.

10 Document Sub- A(1) Optional Where a special passport is used, this Some countries accept specific types of passports
Type is the type of passport: for travel. For these countries, the type of
D = Diplomatic Passport passport used by the traveller should be indicated.
S = Special Passport Should only be used in conjunction with primary
type P.
M = Service/Mission documents
11 Travel N(8) Conditional CCYYMMDD Eg. 20080328
Document (see Notes) Optional for a check-in enquiry. May be required
Expiry Date by some countries if the passenger is not
previously known so data must be captured, and
the passenger holds a travel document that
indicates Expiry Date.
12 Travel N(8) Optional CCYYMMDD E.g. 20080328
Document Issue Optional. May be required by some countries.
Date
13 Supplementary A(2) Optional Code to identify the type of an Not currently used.
Document Type additional/ alternative document being
used.
14 Supplementary X(14) Optional Number of the supplementary Not currently used.
Document ID document.
15 Supplementary X(1) Optional Value taken from MRZ Not currently used.
Doc. Check
Character
16 Family Name X(40) Mandatory Family name. Full name if less than 4 characters, otherwise at
May contain A-Z, hyphen, apostrophe least 4 characters of the full name. Must include
or space. spaces between multiple names.
If the passenger is not previously known, the full
family name will need to be provided.
For countries where the passports have only one
long name eg. Malaysia, the “family name” will
need to be differentiated from the “given names”.
If the family name is longer than 40 characters,
the first 40 characters should be entered.

17 Given Names X(40) Optional Given name(s). Must include spaces between multiple names.
(see Notes) May contain A-Z, hyphen, apostrophe If the given names are longer than 40 characters,
or space. the first 40 characters should be entered.
To separate the first and middle given If there is no given name or it is not known, enter
names, the hash character (#) may be a hyphen (-).
used. Use of this feature is only Optional for a check-in enquiry. Required if the
necessary for provision of data to the passenger is not previously known so data must
USA. be captured and the passenger has given names.
Should be supplied if available.
If the hash character (#) is used to separate the
first and middle given names, it is not returned in
the Given Names field in the response to the
airline.
18 Date of Birth N(8) Conditional CCYYMMDD Mandatory for Pre-Check-in Vetting for the USA.
(see Notes) If the month and day are not known, Optional for a check-in enquiry. Required if the
use CCYY0000. passenger is not previously known so data must
If the day is not known, use be captured. Should be supplied if available.
CCYYMM00.
19 Sex A(1) Conditional M = Male Mandatory for Pre-Check-in Vetting for the USA.
(see Notes) F = Female Optional for a check-in enquiry. Required if the
U = Unspecified passenger is not previously known so data must
be captured. Should be supplied if available.
X = Unspecified
20 Country of Birth A(3) Optional Country code (ICAO [3-character Note that the ICAO 3-character code set has one
Code code]). code of length one character i.e. “D” – Germany.
21 Holder/ A(1) Optional Blank for passport holder
Endorsee S = Endorsee
22 Transfer at A(1) Optional Y or N. Set to “Y” if passenger is transferring at origin of
Origin If not given, treated as “N”. International Flight ie. transferring from one
international flight to another without entering the
country at the origin of the international flight.

23 Transfer at A(1) Optional Y or N. Set to “Y” if passenger is transferring at
Destination If not given, treated as “N”. destination of International Flight ie. transferring
from one international flight to another without
entering the country at the destination of the
international flight.
24 Override Codes A(15) Optional Format is: This field may be used to provide override codes
CxxCxxCxxCxxCxx for up to five countries in a single transmission.
The rules for use of overrides may vary by
Where:
country, but all will use the same set of override
“C” = Override code for the codes.
country which follows.
“xx” = IATA country code for
the country to which the
preceding override code
applies.
Permissible values of override code
are:
“A” = Override based on a
decision by the airline using
published rules.
“G” = Override based on
specific uplift approval from a
government agency.
25 PNR Source X(3) Conditional Airline code (IATA [2-character]) Conditional (may be required by some countries
on flight route)
26 PNR Locator X(10) Conditional Conditional (may be required by some countries
on flight route)
Must be given if PNR Source is given.
Must not be given if PNR Source is not given.
27 e-Ticket Number X(35) Conditional Conditional (may be required by some countries
on flight route)
28 Country of A(3) Conditional Country code (ICAO [3-character eg. NZL
Residence code]). Conditional (may be required by some countries
on flight route)

29 Traveller X(5) Conditional IATA Airport Code eg. SYD
Itinerary: Conditional (may be required by some countries
Port/place on flight route)
where
transportation
began
30 Traveller X(5) Conditional IATA Airport Code eg. SFO
Itinerary: Final Conditional (may be required by some countries
port/place of on flight route)
destination
31 Passenger X(25) Conditional Any combination of alphanumeric Conditional (may be required by some countries
Reference characters. on flight route)
Mandatory for flights to or from the USA.
32 Data Verification A(1) Conditional Blank = Data has not been verified. Conditional (may be required by some countries
Flag V = Data has been verified. on flight route)
33 Home Address: X(60) Conditional Conditional (may be required by some countries
Number & on flight route)
Street For USA, must be provided for crew.
34 Home Address: X(60) Conditional Conditional (may be required by some countries
City on flight route)
For USA, must be provided for crew.
35 Home Address: X(20) Conditional For the USA, this is the State Code. Conditional (may be required by some countries
State on flight route)
36 Home Address: X(20) Conditional For the USA, this is the Zip Code. Conditional (may be required by some countries
Postal Code on flight route)
37 Place of Birth: X(60) Conditional Conditional (may be required by some countries
City on flight route)
38 Place of Birth: X(20) Conditional For the USA, this is the State Code. Conditional (may be required by some countries
State on flight route)

Passenger 1 Passenger A(3) Conditional “PTI” For some countries, a separate Passenger Travel
Travel Travel Itinerary Itinerary data group must be present for each
Itinerary Group Identifier single direction segment included in the
(repeating) passenger’s PNR
If known, must be supplied for the USA.
2 Passenger N(2) Conditional Number of fields which follow in this Set to 8
Travel Itinerary data group. Conditional (required if this group is present)
Group Field
Count
3 Passenger N(3) Conditional The sequence number of the Conditional (required if this group is present)
Sequence passenger in the message to which
Number this data applies.
4 Passenger X(8) Conditional Airline and flight number. eg. BA031
Travel Itinerary Conditional (required if this group is present)
Flight
5 Passenger X(5) Conditional IATA Airport Code eg. SYD
Departure Port
6 Passenger N(8) Conditional CCYYMMDD Conditional (required if this group is present)
Travel Itinerary
Departure Date
7 Passenger N(6) Optional HHMMSS Should be provided if known.
Travel Itinerary
Departure Time
8 Passenger X(5) Conditional IATA Airport Code eg. MEL
Arrival Port
9 Passenger N(8) Conditional CCYYMMDD Conditional (required if this group is present)
Travel Itinerary
Arrival Date
10 Passenger N(6) Optional HHMMSS Should be provided if known.
Travel Itinerary
Arrival Time
Passenger 1 Passenger A(3) Conditional “PAD” Conditional (may be required by some countries
Additional Additional Data on international flight)
Data Group Identifier

(repeating) 2 Passenger N(2) Conditional Number of fields which follow in this Conditional (required if this group is present)
Additional Data data group.
Set to 12 for Message Version 24 and 25
Group Field
Count compatibility.
Set to 15 for Message version 28 compatibility.
3 Passenger N(3) Conditional The sequence number of the Conditional (required if this group is present)
Sequence passenger in the message. Must correspond to the Passenger Sequence
Number Number in the Passenger Request (PRQ) data
group to which this PAD data group applies.
4 Country for A(2) Conditional Country Code (IATA [2-character eg. US
Additional Data code]). Conditional (required if this group is present)
Country Code of the country for which the
additional data must be supplied.
There may be more than one Passenger
Additional Data group per passenger, depending
upon the requirements of the countries on the
5 Additional X(2) Conditional The document type of the additional Conditional (may be required by country to which
Travel travel document should be provided as additional data applies).
Document: it is stated on the travel document. Different countries accept different types of travel
Document Type documents. Airlines should check with the country
they are providing data for to confirm the validity
of the travel document.
6 Additional A(1) Optional Where a special passport is used, this Some countries accept specific types of passports
Travel is the type of passport: for travel. For these countries, the type of
Document: D = Diplomatic Passport passport used by the traveller should be indicated.
Document Sub- Should only be used in conjunction with primary
S = Special Passport
Type type P
7 Additional X(20) Conditional eg. N364028
Travel Conditional (may be required if Additional Travel
Document: Document Type is provided)
Document
Should be provided if specified on the additional
Number
travel document.

8 Additional A(3) Conditional Country code (ICAO [3-character eg. NZL
Travel code]). Conditional (may be required if Additional Travel
Document: Document Type is provided).
Country of
Should be provided if specified on the additional
Issuance
travel document.
9 Additional N(8) Conditional CCYYMMDD Conditional (may be required if Additional Travel
Travel Document Type is provided).
Document: Should be provided if specified on the additional
Expiration Date travel document.
Document Issue Optional. May be required by some countries.
Date
11 Address: X(60) Conditional Conditional (may be required by country to which
Number and additional data applies).
Street For USA, should be provided for inbound non-US
citizens.
12 Address: X(60) Conditional Conditional (may be required by country to which
City additional data applies).
For USA, should be provided for inbound non-US
citizens.
13 Address: X(20) Conditional For the USA, this is the State Code. Conditional (may be required by country to which
State additional data applies).
citizens.
14 Address: X(20) Conditional For the USA, this is the Zip Code. Conditional (may be required by country to which
Postal Code additional data applies).
citizens.
15 Address: A(3) Conditional Country code (ICAO [3-character Conditional (may be required by country to which
Country code]). additional data applies).
citizens.
16 Passenger X(13) Optional Government agency reference number.
Redress
Number

17 Known Traveller X(25) Optional Customer reference number.
Number
Table 25 - Message Layout for Check-in Request (CIRQ)

4.3 MESSAGE TYPE: CHECK-IN RESPONSE (CIRS)

The following table provides the layout for the CIRS message. A field number within each data group is supplied only for ease of reference, and
these numbers are not used within the messages.
If passenger information is present in the response, the order of the passenger data will be by Passenger Sequence Number, with the outbound
country response first, followed by transit country responses in their order on the flight, followed by the inbound country response.
Data group No Data item Data Mandatory/ Value Notes
type/ optional
size
Transaction 1 Transaction A(4) Mandatory “CIRS” Must be followed by colon.
Code
2 Airline Private X(14) Optional Airline reference Any data that was originally given in the CIRQ will
Data be echoed back here.
Passenger 1 Passenger A(3) Conditional “PRS” Conditional (required if ERR data group is not
Response Response present)
(repeating) Group Identifier
Response data group. Set to 28 for Message Version 24 compatibility.
Group Field
Count Set to 28 for Message Version 25 compatibility.
Set to 30 for Message Version 27 and Version 28
compatibility.
3 Passenger N(3) Mandatory The sequence number of the Value 1 to 999.
Sequence passenger in the message. Padded with leading zeros.
Number
Corresponds to the sequence number in the CIRQ
message.
4 Participating A(2) Mandatory 2-character IATA Country Code of the eg. AU
Country participating country generating the
passenger response.
5 Pax/Crew A(1) Mandatory P = Passenger
Indicator C = Operating crew
X = Positioning crew

6 Passport A(3) Optional Nationality of passenger. eg. NZL
Country Code Country code (ICAO [3-character Note that the ICAO 3-character code set has one
7 Issuing State A(3) Optional Country code (ICAO [3-character Note that the ICAO 3-character code set has one
Included if known.
8 Passport ID X(20) Optional Passport or other travel document eg. N364028
number Included if known.
9 Passport Check X(1) Optional Value taken from MRZ
Character
10 Travel A(1) Mandatory Passport or other document type.
Document Type Recommended document types are:
P = Passport
O = Other travel document
N = No travel document
I = Identity Card
types.
11 Document Sub- A(1) Optional Type of passport:
Type D = Diplomatic Passport
S = Special Passport
12 Travel N(8) Optional CCYYMMDD eg. 20080328
Document Included if known.
Expiry Date
Document Issue Included if known.
Date
14 Supplementary A(2) Optional Code to identify the type of an Not currently used.
Document Type additional/ alternative document being
used.

15 Supplementary X(14) Optional Number of the supplementary Not currently used.
Document ID document.
16 Supplementary X(1) Optional Value taken from MRZ Not currently used.
Doc. Check
Character
17 Family Name X(40) Optional Family or full name of the passenger Included if known.
18 Given Names X(40) Optional Given name(s) of the passenger. Included if known.
19 Date of Birth N(8) Optional CCYYMMDD Included if known.
If the month and day are not known,
use CCYY0000.
If the day is not known, use
CCYYMM00.
20 Sex A(1) Optional M = Male Included if known.
F = Female
U = Unspecified
X = Unspecified
21 Country of Birth A(3) Optional Country code (ICAO [3-character Included if known.
Code code]). Note that the ICAO 3-character code set has one
22 Holder/ A(1) Optional Blank for passport holder Included if known.
23 Check-in N(4) Mandatory Check-in message code for the Will have the value of "0000" should there be any
Message Code passenger. error detected in the passenger data that was
supplied or there was a timeout.

24 Passenger A(1) Mandatory Status of passenger with respect to the Indicates the overall status of the passenger and
Status Code check-in process for this country: what action can be taken for the APP country in
field 4.
B = All required data is available,
expected movement has been
generated, directive is “OK to
Board” or equivalent.
D = All required data is available, no
generated, directive is “Do Not
Board” or equivalent, may be
overridden by check-in agent.
X = All required data is available, no
generated, directive is “Do Not
Board” or equivalent, may not be
overridden by check-in agent.
U = Unable to determine status of
passenger. More bio-data must
be provided.
I = Not all required data is available.
Must be captured.
T = Timeout.
E = Error condition detected.
25 Expected N(15) Conditional Unique passenger identifier. Will only have a value if the passenger has been
Passenger ID given a positive boarding directive by all countries.
26 Passenger Error N(4) Conditional Error code for error condition identified. Conditional (on error condition)
Code 1
27 Passenger Error X(60) Conditional Error message for error condition Corresponds to Passenger Error Code 1 in
Message Text 1 identified. previous field.
28 Passenger Error N(4) Conditional Error Code for error condition Conditional (on error condition)
Code 2 identified.
30 Passenger Error N(4) Conditional Error Code for error condition Conditional (on error condition)
Code 3 identified.

32 Additional free X(80) Conditional Additional information from government system to
form text supplement the passenger status information.
Error 1 Error Group A(3) Conditional “ERR” Conditional (required if PRS data group is not
(repeating) Identifier present)
(contains a 2 Error Group N(2) Conditional Number of fields which follow in this i.e. the number of Participating Country fields,
repeating Field Count data group. Error Code fields and Error Message Text fields.
sub-group) Conditional (required if this group is present).
The following three fields are repeated for each error message returned.
3 Participating A(2) Conditional IATA Country Code of the participating eg. AU

Country country generating the error response. Conditional (at least one occurrence required if
this group is present). The field may be null if the
error was detected by the GG and is therefore not
specific to a given country.
4 Error Code N(4) Conditional Error code for error condition identified. eg. 6003
Conditional (on error condition).
5 Error Message X(60) Conditional Error message for error condition eg. Invalid Nationality Code
Text identified. Corresponds to Error Code in previous field.
Table 26 - Message Layout for Check-in Response (CIRS)

4.4 MESSAGE TYPE: MOVEMENT CANCELLATION (CICX)

The following table provides the layout for the CICX message. A field number within each data group is supplied only for ease of reference, and
these numbers are not used within the messages.
type/ Optional
size
Transaction 1 Transaction A(4) Mandatory “CICX” Must be followed by colon.
Code
Data purposes. message (CICC). For example, it could be used
3 User Id X(6) Mandatory Airline user identifier
4 Handle A(1) Mandatory Y = the user location can handle If “Y”, the GG will return duplicate names (if
Multiple duplicate names (endorsees). applicable) for the user to select one.
Response N = the user location cannot handle If “N”, the GG will return only an error code (if
duplicate names. applicable).
5 Transaction A(1) Optional Blank = Cancellation Transaction
Type Qualifier P = Pre-Check-in Vetting Cancellation
B = Boarding Gate Cancellation
6 Message N(3) Mandatory Indicates the format of the following Set to ”21” if only unshaded data items will be
Version message sent and received.
received.
International 1 International A(3) Conditional “INT” Either an “INT” group or a “DOM” group must be
Identifier
Flight Group data group. Conditional (required if this group is present)
Field Count

exceptions.)
Destination
7 International N(8) Conditional CCYYMMDD Date of departure from the International Flight
Flight Date Origin.
eg. 20021105
Flight Time Origin.
eg. 124500
Date eg. 20021105
Time eg. 134500
Domestic 1 Domestic A(3) Conditional “DOM” Either an “INT” group or a “DOM” group must be
Identifier
2 Domestic N(2) Conditional Number of fields which follow in this Set to 8 for current message definition.
Flight Group data group. Conditional (required if this group is present).
Field Count

exceptions.)
4 Domestic X(8) Conditional Airline and flight number eg. AA427
5 Domestic X(5) Conditional IATA Airport Code eg. JFK
6 Domestic X(5) Conditional IATA Airport Code eg. ATL
Destination
7 Domestic N(8) Conditional CCYYMMDD Date of departure from the Domestic Flight Origin.
Flight Date eg. 20021105
8 Domestic N(6) Conditional HHMMSS Time of departure from the Domestic Flight Origin.
Flight Time eg. 124500
9 Domestic N(8) Conditional CCYYMMDD Date of arrival at the Domestic Flight Destination.
Flight Arrival eg. 20021105
Date
10 Domestic N(6) Conditional HHMMSS Time of arrival at the Domestic Flight Destination.
Flight Arrival eg. 134500
Time
Overflight 1 Overflight A(3) Conditional “OVR” May only be present if an “INT” group is present.
(repeating) Group
Identifier
2 Overflight N(2) Conditional Number of fields which follow in this Set to 3 for current message definition.
Count

3 Airport of X(5) Conditional IATA Airport Code eg. ACA (Acapulco)
Origin of Conditional (required if this group is present)
Overflight
Segment
4 Airport of X(5) Conditional IATA Airport Code eg. YVR (Vancouver)
Destination of Conditional (required if this group is present)
Overflight
Segment
5 Country A(2) Conditional IATA Country Code eg. US
Overflown Conditional (required if this group is present)
Passenger 1 Passenger A(3) Mandatory “PCX”
Cancellation Cancellation
(repeating) Group
Identifier
Cancellation data group. Set to 21 for Message Version 24 compatibility.
Group Field
Count Set to 21 for Message Version 25 compatibility.
3 Passenger N(3) Mandatory The sequence number of the A maximum of ten occurrences of this data group
range 1 to 999.
4 Expected N(15) Conditional Unique passenger identifier. Conditional (required if passenger biodata is not
Passenger ID supplied).
Should be included if known.

5 Pax/Crew A(1) Mandatory P = Passenger Code “P” may be used for flights to all countries to
Indicator C = Operating crew indicate a Passenger.
X = Positioning crew Codes “C” and “X” may be used for flights for all
countries except the USA to indicate a Crew
The following codes are required to
member.
more accurately describe crew for
flights to or from the USA: For flights to or from the USA, the following codes
must be used for Crew. The codes are translated
F = Flight Crew
to the codes “CR1” to “CR5” for transmission to
A = Flight Attendant the USA, and to the codes “P”, “C”, or “X” for
O = Airline Operations Management transmission to other countries:
N = Non-crew “F” = Flight Crew (“CR1”, “C”)
D = Deadhead Crew “A” = Flight Attendant (“CR2”, “C”)
“O” = Airline Operations Management (“CR3”, “C”)
“N” = Non-crew (“CR4”, “P”)
“D” = Deadhead Crew (“CR5”, “X”)
6 Passport A(3) Mandatory Nationality of passenger. eg. NZL
8 Passport ID X(20) Conditional Passport or other travel document eg. N364028
number Conditional (required if Document Type is “P”,
must be blank if Document Type is “N”).
Should be provided if available.
9 Passport X(1) Optional Value taken from MRZ
Check
Character

10 Travel A(1) Optional Passport or other document type.
Document Recommended document types are:
Type P = Passport
I = Identity Card
types.
Document
Expiry Date
12 Supplementar A(2) Optional Used to identify the type of an Not currently used.
y Document additional/ alternative document being
Type used.
13 Supplementar X(14) Optional Document number Not currently used.
y Document ID
14 Supplementar X(1) Optional Value taken from MRZ. Not currently used.
y Doc. Check
Character
15 Family Name X(40) Conditional Family name Not required if Expected Passenger Id is provided.
May contain A-Z, hyphen, apostrophe Otherwise, full name if less than 4 characters or at
or space. least 4 characters of the full name. Must include
spaces between multiple names.
16 Given Names X(40) Optional Given name(s) of the passenger Must include spaces between multiple names.
May contain A-Z, hyphen, apostrophe Not used if Expected Passenger Id is provided.
or space. If there is no given name or it is not known, enter
To separate the first and middle given a hyphen (-).
names, the hash character (#) may be If the hash character (#) is used to separate the
used. Use of this feature is only first and middle given names, it is not returned in
necessary for provision of data to the the Given Names field in the response to the
USA. airline.

17 Date of Birth N(8) Optional CCYYMMDD Not used if Expected Passenger Id is provided.
use CCYY0000.
CCYYMM00.
18 Sex A(1) Optional M = Male Not used if Expected Passenger Id is provided.
F = Female
U = Unspecified
X = Unspecified
19 Country of A(3) Optional Country code (ICAO [3-character Not used if Expected Passenger Id is provided.
Birth Code code]). Note that the ICAO 3-character code set has one
20 Holder/ A(1) Optional Blank for passport holder Not used if Expected Passenger Id is provided.
21 Transfer at A(1) Optional Y or N. Default is “N”. Set to “Y” if passenger is transferring at origin of
Origin International Flight ie. transferring from one
international flight to another without entering the
country at the origin of the international flight.
22 Transfer at A(1) Optional Y or N. Default is “N”. Set to “Y” if passenger is transferring at
Destination destination of International Flight ie. transferring
from one international flight to another without
entering the country at the destination of the
23 Passenger X(25) Conditional Any combination of alphanumeric Conditional (may be required by some countries
Reference characters. on international flight).
Mandatory for flights to or from the USA.
Table 27 - Message Layout for Movement Cancellation (CICX)

4.5 MESSAGE TYPE: MOVEMENT CANCELLATION CONFIRMATION (CICC)

The following table provides the layout for the CICC message. A field number within each data group is supplied only for ease of reference,
and these numbers are not used within the messages.
If passenger information is present in the response, the order of the passenger data will be by Passenger Sequence Number, with the outbound
country response first, followed by transit country responses in their order on the flight, followed by the inbound country response.
type/ optional
size
Transaction 1 Transaction A(4) Mandatory “CICC” Must be followed by colon.
Code
2 Airline Private X(14) Optional Airline reference Any data that was originally given in the CICX will
Passenger 1 Passenger A(3) Conditional “PCC” Conditional (required if ERR data group is not
Cancellation Cancellation present)
Response Response
(repeating) Group
Identifier
2 Passenger N(2) Mandatory Number of fields which follow in this Set to 26 for current message definition.
Cancellation data group.
Response
Group Field
Count
3 Passenger N(3) Mandatory The sequence number of the Value 1 to 999.
Sequence passenger in the message. Padded with leading zeros.
Number
Corresponds to sequence number in the CICX
message.
4 Participating A(2) Mandatory 2-character IATA Country Code of the eg. AU
Country participating country generating the
passenger response.
5 Pax/Crew A(1) Mandatory P = Passenger
Indicator C = Operating crew
X = Positioning crew

6 Passport A(3) Mandatory Nationality of passenger. eg. NZL
8 Passport ID X(20) Optional Passport or other travel document eg. N364028
number Included if known.
9 Passport X(1) Optional Value taken from MRZ
Check
Character
10 Travel A(1) Mandatory Passport or other document type.
Document Recommended document types are:
Type P = Passport
I = Identity Card
types.
Document Included if known.
Expiry Date
12 Supplementar A(2) Optional Used to identify the type of an Not currently used.
y Document additional/ alternative document being
Type used.
13 Supplementar X(14) Optional Document number Not currently used.
y Document Id
14 Supplementar X(1) Optional Value taken from MRZ. Not currently used.
y Doc. Check
Character
15 Family Name X(40) Optional Family or full name of the passenger Included if known.
16 Given Names X(40) Optional Given name(s) of the passenger. Included if known.

17 Date of Birth N(8) Optional CCYYMMDD Included if known.
use CCYY0000.
CCYYMM00.
18 Sex A(1) Optional M = Male Included if known.
F = Female
U = Unspecified
X = Unspecified
19 Country of A(3) Optional Country code (ICAO [3-character Included if known.
Birth Code code]). Note that the ICAO 3-character code set has one
20 Holder/Endors A(1) Optional Blank for passport holder Included if known.
ee S = Endorsee
21 Check-in N(4) Conditional Check-in message code for the Will have the value of "0000" should there be any
Message passenger. error detected in the passenger data that was
Code supplied or there was a timeout.
22 Passenger A(1) Mandatory Status of passenger with respect to the Indicates the overall status of the passenger and
Status Code check-in process for this country: what action can be taken for the APP country in
C = Cancelled field 4.
N = Not found
T = Timeout
E = Error condition detected
23 Passenger N(4) Conditional Error Code for error condition Conditional (on error condition)
Error Code 1 identified.
24 Passenger X(60) Conditional Error message for error condition Corresponds to Passenger Error Code 1 in
Error Message identified. previous field.
Text 1
Text 2

Text 3
Error 1 Error Group A(3) Conditional “ERR” Conditional (required if PCC data group is not
(repeating) Identifier present)
(contains a 2 Error Group N(2) Conditional Number of fields which follow in this i.e. the number of Participating Country fields,
repeating Field Count data group. Error Code fields and Error Message Text fields.
sub-group) Conditional (required if this group is present).
3 Participating A(2) Conditional IATA Country Code of the participating Conditional (at least one occurrence required if
Country country generating the error response. this group is present). The field may be null if the
4 Error Code N(4) Conditional Error code for error condition identified. Conditional (on error condition).
5 Error Message X(60) Conditional Error message for error condition Corresponds to Error Code in previous field.
Text identified. Conditional (on error condition).
Table 28 - Message Layout for Movement Cancellation Confirmation (CICC)

4.6 MESSAGE TYPE: MANIFEST REQUEST (CIMR)

The following table provides the layout for the CIMR message. A field number within each data group is supplied only for ease of reference,
type/ optional
size
Transaction 1 Transaction A(4) Mandatory “CIMR” Must be followed by colon.
Code
Data purposes. message (CIMA). For example, it could be used
4 Message N(3) Mandatory Indicates the format of the following Set to “21” if only unshaded data items will be
received.
shaded in green, blue and yellow will be sent and
received.
International 1 International A(3) Conditional “INM” Either an “INM” group or a “FLT” group must be
Identifier The International Flight specified in this message
is the same as the flight specified in the CIRQ
message, but the data set is reduced.
Conditional (required if this data group is present)
2 International N(2) Conditional Number of fields which follow in this Set to 3 for message version 21, 24 and 25
Flight Group data group. compatibility.
Field Count Conditional (required if this data group is present)
Set to 8 for or Message Version 26 compatibility.

Flight Conditional (required if this data group is present)
Flight Origin Conditional (required if this data group is present)
5 International N(8) Conditional CCYYMMDD eg. 20021105
Flight Date Conditional (required if this data group is present)
Unscheduled U = Unscheduled Flight Defaults to S if not provided.
Flight
Flight Conditional (mandatory for unscheduled flights)
Destination
Flight Time Origin.
eg. 124500
Date eg. 20021105
Time eg. 134500
Flight 1 Flight Group A(3) Conditional “FLT” Either an “INM” group or a “FLT” group must be
Identifier present.
The Flight specified in this message is the same
as the flight specified in the CIRQ message but
the data set is reduced.
2 Flight Group N(2) Conditional Number of fields which follow in this Set to 4 for Message Version 21, 24 and 25
Field Count data group. compatibility.

Set to 9 for or Message Version 26 compatibility.
3 Flight X(8) Conditional Airline and flight number eg. BA031
4 Flight Origin X(5) Conditional IATA Airport Code eg. SIN
5 Flight Date N(8) Conditional CCYYMMDD eg. 20021105
6 Flight Type A(3) Conditional “INT” = International Conditional (required if this data group is present)
“DOM” = Domestic
“OVR” = Overflight
Unscheduled U = Unscheduled Flight Defaults to S if not provided.
Flight
Flight Conditional (mandatory for unscheduled flights)
Destination
Flight Time Origin.
eg. 124500
Date eg. 20021105
Time eg. 134500
Manifest 1 Manifest A(3) Mandatory “MRQ” There must be one occurrences of this data
Request Request Group group, related to the country in which the flight
Identifier commences, the country in which the flight
terminates, a country in which the flight lands in
transit or a country of overflight of the flight.

2 Manifest N(2) Mandatory Number of fields which follow in this Set to 3 for current message definition.
Request Group data group.
Field Count
3 Country A(2) Mandatory 2-character IATA Country Code of the eg. AU
Requiring participating country.
Manifest
4 Passenger A(1) Mandatory N = Manifest not required N no action required.
Manifest I = Incremental manifest required I will result in the generation of a manifest for
Requirement only those passengers or crew who have not
F = Full manifest required
5 Crew Manifest A(1) Optional been included in a previous manifest for the
C = Flight closeout
Requirement flight.
X = Flight cancel
F will result in the generation of a manifest for
P = Flight closeout (post-departure) all passengers or crew regardless of who
S = Flight summary has been included in a previous manifest for
the flight.
C will result in the generation of a manifest for
all passengers who boarded the flight or who
were checked in successfully but did not
board the flight, depending upon the option
implemented by the AP.
X will result in the generation of a special
purpose manifest that notifies the
cancellation of the flight.
P will result in the generation of a post-
departure manifest for all passengers or
crew who boarded the flight or who were
checked in successfully but did not board the
flight, depending upon the option
implemented by the AP.
S will result in generation of a Boarding Pass
Printing Report (BPPR) and transmission of
this report to the airline using a mechanism
agreed with the airline.
Defaults to “N” if not provided.
Table 29 - Message Layout for Manifest Request (CIMR)

4.7 MESSAGE TYPE: MANIFEST REQUEST ACKNOWLEDGEMENT (CIMA)

The following table provides the layout for the CIMA message. A field number within each data group is supplied only for ease of reference,
type/ optional
size
Transaction 1 Transaction A(4) Mandatory “CIMA” Must be followed by colon.
Code
2 Airline Private X(14) Optional Airline reference Any data that was originally given in the CIMR will
Manifest 1 Manifest A(3) Conditional “MAK” Conditional (required if ERR data group is not
Group Identifier There may be one occurrences of this data group,
related to either the country from which the
International Flight is departing or to the next
country in which the International Flight is landing.
Response data group.
Group Field
Count
3 Country A(2) Mandatory 2-character IATA Country Code of the e.g. AU
Requiring participating country generating the
Manifest response.
4 Manifest N(4) Mandatory 8700 = Request processed Receipt of response 8700 may or may not mean
Response Code 8701 = Request rejected that the manifest has actually been generated and
received by the government authority. Refer to
Table 10 for further information.
If the request is rejected, the error condition is
indicated by the following error code and
message.
Text identified.

Error 1 Error Group A(3) Conditional “ERR” Conditional (required if MAK data group is not
(contains a Identifier present)
repeating 2 Error Group N(2) Conditional Number of fields which follow in this i.e. the number of Participating Country fields,
sub-group) Field Count data group. Error Code fields and Error Message Text fields.
Conditional (required if this group is present).

Table 30 - Message Layout for Manifest Request Acknowledgement (CIMA)

4.8 MESSAGE TYPE: MANIFEST ENQUIRY (CIME)

The following table provides the layout for the CIME message. A field number within each data group is supplied only for ease of reference,
type/ optional
size
Transaction 1 Transaction A(4) Mandatory “CIME” Must be followed by colon.
Code
Data purposes. message (CIMS). For example, it could be used
4 Message N(3) Mandatory Indicates the format of the following Set to “21” if only unshaded data items will be
received.
Identifier The International Flight specified in this message
is the same as the flight specified in the CIRQ
message but the data set is reduced.
Flight Group data group. Conditional (required if this data group is present)
Field Count

Identifier present.
2 Flight Group N(2) Conditional Number of fields which follow in this Set to 4 for current message definition.
Field Count data group. Conditional (required if this data group is present)
Manifest 1 Manifest A(3) Mandatory “MEN” There must be one occurrences of this data
Enquiry Enquiry Group group, related to the country in which the flight
Identifier commences, the country in which the flight
terminates, a country in which the flight lands in
transit or a country of overflight of the flight.
Enquiry Group data group.
Field Count
Requiring participating country.
Manifest
Table 31 - Message Layout for Manifest Enquiry (CIME)

4.9 MESSAGE TYPE: MANIFEST STATUS (CIMS)

The following table provides the layout for the CIMS message. A field number within each data group is supplied only for ease of reference,
type/ optional
size
Transaction 1 Transaction A(4) Mandatory “CIMS” Must be followed by colon.
Code
2 Airline Private X(14) Optional Airline reference Any data that was originally given in the CIME will
Manifest 1 Manifest Status A(3) Conditional “MST” Conditional (required if ERR data group is not
Status Group Identifier present)
There may be one occurrences of this data group,
related to either the country from which the
International Flight is departing or to the next
2 Manifest Status N(2) Mandatory Number of fields which follow in this Set to 7 for current message definition.
Group Field data group.
Count
Requiring participating country generating the
Manifest response.
4 Passenger N(4) Mandatory Number of passengers for whom
Count (APP) expected movements have been
generated for the flight.
5 Crew Count N(4) Mandatory Number of crew for whom expected
(APP) movements have been generated for
the flight.
6 Passenger N(4) Mandatory Number of passengers in manifests
Count generated for the flight.
(Manifest)
7 Crew Count N(4) Mandatory Number of crew in manifests
(Manifest) generated for the flight.
8 Error Code N(4) Conditional Error code for error condition Conditional (on error condition)
identified.

Text identified.
Error 1 Error Group A(3) Conditional “ERR” Conditional (required if MST data group is not

4 Error Code N(4) Conditional Error code for error condition Conditional (on error condition).
identified.
Table 32 - Message Layout for Manifest Status (CIMS)

4.10 MESSAGE TYPE: PASSENGER STATUS REQUEST (CICO)

The following table provides the layout for the CICO message. A field number within each data group is supplied only for ease of reference,
type/ optional
size
Transaction 1 Transaction A(4) Mandatory “CICO” Must be followed by colon.
Code
2 Airline Private X(14) Optional Free for use by the airline for This data is returned to the airline in the response
Data reference purposes. message (CIUR). For example, it could be used
4 Message N(3) Mandatory Indicates the format of the following Set to “24” if data items shaded in green will be
Set to “25” if data items shaded in green and blue
will be sent and received.
Identifier The Flight specified in this message is the same
Flight Group data group. Conditional (required if this data group is present)
Field Count

type/ optional
size
Identifier present.
2 Flight Group N(2) Conditional Number of fields which follow in this Set to 4 for current message definition.
Field Count data group. Conditional (required if this data group is present)
Passenger 1 Passenger A(3) Mandatory “PSQ” There may be only one occurrences of this data
Status Status Request group, related either to the country from which the
Request Group Identifier International Flight is departing or to the next
2 Passenger N(2) Mandatory Number of fields which follow in this Set to 2 for current message definition.
Status Request data group.
Group Field
Count
3 Country A(2) Mandatory 2-character IATA Country Code of the eg. US
Providing participating country.
Passenger
Status

type/ optional
size
4 Page Reference N(3) Mandatory The page reference specifies the page number of
the response message, which is requested by the
airline DCS. eg. 1.
For a new request, this value is always set to ‘1’.
Table 33 - Message Layout for Passenger Status Request (CICO)

4.11 MESSAGE TYPE: PASSENGER STATUS RESPONSE (CIUR)

The following table provides the layout for the CIUR message. A field number within each data group is supplied only for ease of reference,
type/ optional
size
Transaction 1 Transaction A(4) Mandatory “CIUR” Must be followed by colon.
Code
2 Airline Private X(14) Optional Airline reference Any data that was originally given in the CICO will
Passenger 1 Passenger A(3) Conditional “PST” Conditional (required if ERR data group is not
Status Status Group present)
(contains a Identifier
repeating 2 Passenger N(2) Conditional Number of fields which follow in this ie. equal to 6 plus 4 multiplied by the number of
sub-group) Status Group data group. passengers for whom status information is
Field Count returned.
3 Participating A(2) Conditional 2-character IATA Country Code of the eg. US
Country participating country providing the Conditional (required if this data group is present)
passenger status updates.
7 Page Reference N(3) Conditional eg. “001”.
8 Page A(1) Conditional This indicator specifies whether there Conditional (required if this data group is present)
Continuation is more data to be sent to the airline
Indicator DCS.
Y = Yes
N= No

The following four fields are repeated for each passenger returned. The sub-group can be repeated up to 20 instances.
9 Passenger N(3) Conditional The sequence number of the A maximum of 20 occurrences of passenger data
range 1 to 999.
Padded with leading zeros.
Conditional (required for each passenger for
whom data is returned)
10 Passenger X(25) Conditional Any combination of alphanumeric Must be the same as the Passenger Reference
Reference characters. supplied for the passenger in the CIRQ message.
Conditional (required for each passenger for
11 Check-in N(4) Conditional Check-in message code for the Represents the updated status for the passenger.
Message Code passenger. Conditional (required for each passenger for
12 Passenger A(1) Conditional Status of passenger with respect to Indicates the overall status of the passenger and
Status Code the check-in process for this country: what action can be taken for the APP country in
B = Directive is “OK to Board” or field 3.
equivalent. Conditional (required for each passenger for
D = Directive is “Do Not Board” or whom data is returned)
equivalent.
Error 1 Error Group A(3) Conditional “ERR” Conditional (required if PST data group is not

3 Participating A(2) Conditional IATA Country Code of the participating eg. AU, US.
4 Error Code N(4) Conditional Error code for error condition eg. 6010
identified. Conditional (on error condition).
5 Error Message X(60) Conditional Error message for error condition eg. Invalid Country Code
Table 34 - Message Layout for Passenger Status Response (CIUR)

4.12 MESSAGE TYPE: GATE PASS REQUEST (CIGR)

The following table provides the layout for the CIGR message. A field number within each data group is supplied only for ease of reference,
type/ optional
size
Transaction 1 Transaction A(4) Mandatory “CIGR” Must be followed by colon.
Code
2 Airline Private X(14) Optional Free for use by the airline for This data is returned to the airline in the response
Data reference purposes. message (CIGS). For example, it could be used
4 Message N(3) Mandatory Indicates the format of the following Set to “25” for messages conforming to this
Version message. specification.
5 Participating A(2) Mandatory IATA country code of the participating
Country country to which the request is
directed.
6 Carrier Code X(3) Mandatory Carrier on which the accompanied eg. AA
passenger is boarding the flight.
Airline code (IATA [2-character])
7 Airport Code X(5) Mandatory Airport at which accompanied eg. JFK
passenger is boarding the flight.
Airport code (IATA [3-character])
8 Validity Date N(8) Mandatory Date for which the Gate Pass is valid.
CCYYMMDD
Gate Pass 1 Gate Pass A(3) Mandatory “GPR”
Request Request Group
(Repeating) Identifier
2 Gate Pass N(2) Mandatory Number of fields which follow in this Set to 16 for current message definition.
Request Group data group.
Field Count

3 Request N(3) Mandatory The sequence number of the request A maximum of five occurrences of this data group
Sequence in the message, can be included in each message. The value of
Number the Request Sequence Number can be in the
range 1 to 999.
4 Nationality A(3) Optional Nationality of person. eg. NZL
Country code (ICAO [3-character Note that the ICAO 3-character code set has one
5 Travel A(3) Conditional Country code (ICAO [3-character eg. NZL
Document: code]). Conditional (should be provided if specified on the
Issuing State travel document.)
6 Travel X(20) Conditional eg. N364028
Document: Conditional (should be provided if specified on the
Number travel document.)
7 Travel A(1) Optional P = Passport Defaults to “N” if not given.
Document: Type O = Other travel document Note that this default differs from the default of “P”
N = No travel document (Default) for other transactions.
8 Travel A(2) Conditional For “other” travel documents, the Conditional (may be required by country to which
Document Type document type of the travel document additional data applies).
Qualifier should be provided as it is stated on Different countries accept different types of travel
the travel document. documents. Airlines should check with the country
they are providing data for to confirm the validity
of the travel document.
9 Travel N(8) Conditional CCYYMMDD Conditional (should be provided if specified on the
Document: travel document.)
Expiry Date
10 Family Name X(40) Mandatory Family name. For countries where the passports have only one
May contain A-Z, hyphen, apostrophe long name eg. Malaysia, the “family name” will
or space. need to be differentiated from the “given names”.
If the family name is longer than 40 characters,
the first 40 characters should be entered.

11 Given Names X(40) Mandatory Given name(s). Must include spaces between multiple names.
May contain A-Z, hyphen, apostrophe If the given names are longer than 40 characters,
or space. the first 40 characters should be entered.
To separate the first and middle given If there is no given name or it is not known, enter
names, the hash character (#) may be a hyphen (-).
used. Use of this feature is only
necessary for provision of data to the
USA.
12 Date of Birth N(8) Mandatory CCYYMMDD
use CCYY0000.
CCYYMM00.
13 Sex A(1) Mandatory M = Male
F = Female
U = Unspecified
X = Unspecified
14 PNR Source X(3) Conditional Airline code (IATA [2-character]) Conditional (may be required by some countries.)
15 PNR Locator X(10) Conditional 5-6 alphanumeric characters. Conditional (may be required by some countries.)
Must be given if PNR Source is given.
Must not be given if PNR Source is not given.
16 Passenger X(25) Conditional Any combination of alphanumeric Conditional (may be required by some countries.)
Reference characters. Mandatory for the USA.
17 Passenger X(13) Optional Government agency reference number.
Redress
Number
18 Known Traveller X(25) Optional Customer reference number.
Number
Table 35 - Message Layout for Gate Pass Request (CIGR)

4.13 MESSAGE TYPE: GATE PASS RESPONSE (CIGS)

The following table provides the layout for the CIGS message. A field number within each data group is supplied only for ease of reference,
type/ optional
size
Transaction 1 Transaction A(4) Mandatory “CIGS” Must be followed by colon.
Code
2 Airline Private X(14) Optional Airline reference Any data that was originally given in the CIGR will
3 Participating A(2) Mandatory IATA country code of the participating
Country country to which the request is
directed.
Gate Pass 1 Gate Pass A(3) Conditional “GPS” Conditional (required if ERR data group is not
(repeating) Group Identifier
2 Gate Pass N(2) Conditional Number of fields which follow in this Set to 5 for current message definition.
Response Field data group. Conditional (required if this data group is present)
Count
3 Request N(3) Conditional The sequence number of the request Value 1 to 999.
Sequence in the message, Corresponds to the sequence number in the CIGR
Number message.
Padded with leading zeros.
4 Passenger X(25) Conditional Any combination of alphanumeric Corresponds to the Passenger Reference in the
Reference characters. CIGR message.
5 Gate Pass N(4) Conditional Message code in response to the Will have the value of "0000" should there be any
Message Code request. error detected in the data that was supplied or
Refer to Appendix A, Table 37, for there was a timeout.
possible values. Conditional (required if this data group is present)
6 Error Code N(4) Conditional Error code for error condition Conditional (on error condition)
identified.

Text identified.
Error 1 Error Group A(3) Conditional “ERR” Conditional (required if GPS data group is not
3 Participating A(2) Conditional IATA Country Code of the participating eg. AU, US.
4 Error Code N(4) Conditional Error code for error condition eg. 6010
identified. Conditional (on error condition).
5 Error Message X(60) Conditional Error message for error condition eg. Invalid Country Code
Table 36 - Message Layout for Gate Pass Response (CIGS)

5. MESSAGE EXAMPLES
The examples here show only the relevant parts of the message. They do not show the
required HTH Layer 7 message header and trailer. A sample complete message with the
required message header can be found below in Section 5.6.
Unless otherwise stated, all examples in this section assume that only Australia is an APP
country.
5.1 CHECK-IN EXAMPLES
5.1.1 One Single Passenger (simple end-to-end journey)

The following seven examples relate to a single passenger on a simple end-to-end journey
and are illustrated by Figure 13.
Malaysia
Kuala Lumpur
Australia
Sydney
Figure 13 - Flight BA033 (KUL-SYD)
5.1.1.1 Example 1: Passenger located (OK to board)
Airline to GG (CIRQ Message)

CIRQ:/123456/N//25/INT/8/S/BA033/KUL/SYD/20161212////
PRQ/33/1/P/USA//Z4351213///////SMIT//////////////////////

Page 115
[GG sends 5-1 message to AU and AU responds with 6-1 message.]
GG to Airline (CIRS Message)
CIRS:/PRS/28/001/AU/P/USA/USA/Z4351213//P/20250630////SMITH/
SAMANTHA/19640912/F/USA//8501/B/2128666////////
The passenger has been given 8501 (“OK to Board”). An expected movement record has
been sent to the participating government.
5.1.1.2 Example 2: Passenger not located or does not have a valid visa

PRQ/33/1/P/USA//Z4351213///////SMIT//////////////////////
CIRS:/PRS/28/001/AU/P/USA//Z4351213//P/////SMIT//////8502/D/////////
The passenger has been given 8502 (“Do Not Board”). An expected movement record has
not been sent to the participating government.
5.1.1.3 Example 3: Passenger located (both governments responded)
[NOTE: This example assumes that both Australia and Malaysia are APP countries.]
CIRQ:111/123456/N//25/INT/8/S/BA033/KUL/SYD/20161212////
PRQ/33/1/P/USA//Z4351213///////SMIT//////////////////////
[GG sends 5-1 message to MY and MY responds with 6-1 message.]
CIRS:111/PRS/28/001/MY/P/USA/USA/Z4351213//P/20250630//// SAMANTHA
TAYLOR SMITH//19640912/F/USA//8501/B/18743////////
PRS/28/001/AU/P/USA/USA/Z4351213//P/20250630////SMITH/
SAMANTHA/19640912/F/USA//8501/B/18743////////
The passenger has been given 8501 (“OK to Board”) by both countries. An expected
movement record has been sent to each of the participating governments. Note the
differences in the names from the two different sources.

Page 116
5.1.1.4 Example 4: Special handling (airline can handle duplicate name)
CIRQ:/123456/Y//25/INT/8/S/BA033/KUL/SYD/20161212////
PRQ/33/1/P/USA//Z4351213///////SMIT//////////////////////
SAMANTHA/19640912/F/USA//8507/U/////////PRS/28/001/AU/P/USA/
USA/Z4351213//P/20250630////SMITH/BELINDA/19940421/F/USA//
8507/U/////////
The response contains details for both Belinda and Samantha Smith (who are on the same
passport), and code 8507 (“Duplicate Name”) for both. At this stage no expected movement
records have been sent to the participating government.
Note that in the response both passengers have the same Passenger Sequence Number (1).
The check-in agent should now follow the message flow for checking-in multiple passengers.
(See Section 5.1.2 below).
5.1.1.5 Example 5: Error condition (passport format error)
PRQ/33/1/P/USA//351213///////SMIT//////////////////////
CIRS:/PRS/28/001/AU/P/USA//351213//P/////SMIT//////0000/E//
6033/INVALID PASSPORT NUMBER FORMAT//////
AU has recognised (using internal rules) that the passport number is incorrectly formatted for
an American passport, and has sent error code 6033 (“Invalid passport number format”). No
expected movement record has been sent to the government.
The check-in agent should resubmit the request, taking care to ensure that the passport
number is correctly entered.
5.1.1.6 Example 6: Error condition (system error)
PRQ/33/1/P/USA//351213///////SMIT//////////////////////

Page 117
CIRS:/ERR/3/AU/6999/AP ERROR: PL-SQL FAILED/
A serious error (code 6999) occurred and the passenger request was not processed. The
check-in agent should resubmit the request.
5.1.1.7 Example 7: CIRQ message supplies complete passport details
CIRQ:NZ1123/123456/N//25/INT/8/S/BA033/KUL/SYD/20161212////
PRQ/33/1/P/USA/USA/Z4351213/E/P/20250630////SMITH/SAMANTHA/
19640912/F/USA//////////////////
The airline message contains complete passport details, and includes the Passport Check
Character indicating that the passport details were read from the MRZ by an OCR-B reader.
CIRS:NZ1123/PRS/28/001/AU/P/USA/USA/Z4351213/E/P/20250630////
SMITH/SAMANTHA/19640912/F/USA//8501/B/2128666////////
The passenger has been given code 8501 (“OK to Board”). An expected movement record
has been sent to the participating government.
IMPORTANT NOTE:
When airlines are implementing APP, the above example should be taken as the model of
how to populate the CIRQ message.
By sending complete passport details in the CIRQ message, the airline will allow some
governments (eg. New Zealand) to process first-time, visa-free travellers who are not
registered in their system.
This is therefore the recommended implementation of the CIRQ message.

Page 118
5.1.2 Multiple Passengers

The following three examples relate to multiple passengers in the same check-in request and
are illustrated by Figure 13.
5.1.2.1 Example 8: All passengers successfully processed
PRQ/33/1/P/USA//Z4351213///////SMIT//////////////////////
PRQ/33/2/P/USA//Z4354753///////SMIT//////////////////////
Details of two passengers (with the same family name, but with different passports) are
submitted by the airline.
SAMANTHA/19640912/F/USA//8501/B/345234////////PRS/28/002/AU/P/
USA/USA/Z4354753//P/20230515////SMITH/ANDREW JACKSON/
19620511/M/USA//8501/B/345235////////
Both passengers have been found in the visa database by the AP, and both have been given
code 8501 (“OK to Board”). An expected movement record has been sent to the
participating government for each passenger.
5.1.2.2 Example 9: Not all passengers processed successfully
PRQ/33/1/P/USA//Z4351213///////SMIT//////////////////////
PRQ/33/2/P/USA//Z43547///////SMIT//////////////////////
submitted by the airline.
SAMANTHA/19640912/F/USA//8501/B/345234////////PRS/28/002/AU/P/
USA//Z43547//P/////SMIT//////0000/E//6033/INVALID PASSPORT NUMBER
FORMAT//////
AU has been able to process one passenger successfully (Samantha Smith) and gives code
8501 (“OK to Board”). An expected movement record has been sent to the participating
government for this passenger.

Page 119
An error occurred in processing the other passenger, and error code 6033 is given (“Invalid
passport number format”). No expected movement record has been sent to the participating
government for this passenger. The check-in agent should resubmit the request, taking care
to ensure that the passport number is correctly entered.
5.1.2.3 Example 10: Some passengers not uniquely identified
PRQ/33/1/P/NZL//Z4351213///////SMIT//////////////////////
PRQ/33/2/P/NZL//Z4354888///////SMIT//////////////////////
submitted by the airline. The airline has indicated that it cannot accept responses for more
than one passenger in the response to an enquiry on a passenger.
CIRS:/PRS/28/001/AU/P/NZL//Z4351213///////SMIT//////8507/U/////////P
RS/28/002/AU/P/NZL//Z4354888//P/20250630////SMITH/
SAMUEL JACKSON/19320721/M/NZL//8501/B/345236////////
AU has processed one of the passengers normally (Samuel Jackson Smith) and given code
government for this passenger.
AU found two different visa records for the other passport, meaning that there is an endorsee
on the passport. It has therefore returned the code 8507 (“Duplicate Name”). No expected
movement record has been sent to the participating government for these passengers.
The check-in agent should submit a request for the other passport, this time providing
enough data to uniquely identify the holder.

Page 120
5.1.3 Different Trans-Border and Expected Ports (same scheduled flight)

The following example relates to a single passenger on a flight with two legs and is illustrated
by Figure 14.
Check-in Port
Thailand
Bangkok
Australia Expected Port
Sydney
Melbourne
Trans-Border Port
Figure 14 - Flight QF016 (BKK-MEL-SYD)
5.1.3.1 Example 11: Different trans-border and expected ports (same scheduled
flight)
CIRQ:/123456/N//25/INT/8/S/QF016/BKK/SYD/20161212////
PRQ/33/1/P/USA//Z4351213///////SMIT//////////////////////
The airline sends a request showing that passenger SMITH is boarding QF016 in Bangkok
and disembarking in Sydney.
[The GG sends 5-1 message to AU which includes the fact (obtained from the airline
schedules) that QF016 flies BKK-MEL-SYD, and that MEL is therefore the trans-border port
for the flight. AU responds with 6-1 message.]
SAMANTHA/19640912/F/USA//8501/B/2128666////////
AU has confirmed that the passenger has a visa and has given code 8501 (“OK to Board”).
An expected movement record has been sent to the participating government for this
passenger listing BKK as the check-in port, MEL as the trans-border port, and SYD as the
expected port.

Page 121
5.1.4 Different Trans-Border and Expected Ports (different flights)

The following example relates to a single passenger on a multi flight journey and is illustrated
by Figure 15.
Chicago
Los Angeles
Sydney
Melbourne
Figure 15 - Multi-Leg Journey (ORD-LAX-SYD-MEL)
5.1.4.1 Example 12: Different trans-border and expected ports (different scheduled
flights)
CIRQ:/123456/N//25/CHK/2/ORD/UA841/INT/8/S/QF012/LAX/SYD/20161212///
/EXD/4/MEL/QF022/19981101/2205/PRQ/33/1/P/USA//Z4351213///////
SMIT//////////////////////
The airline submits a request showing different check-in, international and expected flights
for a passenger (UA841, QF012, and QF022 respectively).
[GG sends 5-1 message to AU which includes the fact that the APP check-in request was
done in ORD. AU responds with 6-1 message.]
SAMANTHA/19640912/F/USA//8501/B/2128666////////
AU has confirmed that the passenger has a visa and has given code 8501 (“OK to Board”).
Expected movement record has been sent to the participating government for the passenger
with ORD as check-in port, SYD as trans-border port, and MEL as expected port.

Page 122
5.1.5 Overriding a Boarding Directive

The following two examples relate to overriding boarding directives from one or more
countries. The journey is illustrated by Figure 13.
5.1.5.1 Example 13: Passenger requires override for one country
PRQ/33/1/P/USA//Z4351213///////SMIT//////////////////////
TAYLOR SMITH//19640912/F/USA//8501/B/////////
SAMANTHA/19640912/F/USA//8510/D/////////
The passenger has been given 8501 (“OK to Board”) by Malaysia but 8510 (“Contact BOC”)
by Australia. The Passenger Status returned by Australia is “D” indicating that data is
available for the passenger and that the directive may be overridden after further assessment
of the case. No expected movement has been generated for Australia and the expected
movement originally generated for Malaysia has been cancelled.
The airline has contacted the Australian authorities and has obtained permission for uplifting
the passenger. The transaction is submitted again with an override code applicable for
Australia.
PRQ/33/1/P/USA//Z4351213///////SMIT////////GAU//////////////

SAMANTHA/19640912/F/USA//8517/B/18745////////
The passenger has been given 8501 (“OK to Board”) by Malaysia and 8517 (“Override
Accepted”) by Australia. An expected movement record has been sent to each of the
participating governments.

Page 123
5.1.5.2 Example 14: Multiple passengers, one requiring override for both countries
PRQ/33/1/P/USA//Z4351213///////SMIT//////////////////////
PRQ/33/2/P/USA//Z4354753///////SMIT//////////////////////
SAMANTHA/19640912/F/USA//8501/B/18743////////
PRS/28/002/MY/P/USA/USA/Z4354753//P/20250630////SMITH/ ANDREW
JACKSON/19620511/M/USA//8502/D/////////
PRS/28/002/AU/P/USA/USA/Z4354753//P/20250630////SMITH/ ANDREW
JACKSON/19620511/M/USA//8510/D/////////
The first passenger has been given 8501 (“OK to Board”) by both countries and expected
movements have been generated. No further action is necessary for the passenger.
The second passenger has been denied boarding by both countries, but both these
directives may be overridden after further assessment of the case. No expected movements
have been generated for the passenger.
The airline has determined that there is no reason for the passenger to be denied boarding
from Malaysia and is able to provide an airline override. The airline has contacted the
Australian authorities as instructed by the directive and obtained permission for uplifting the
passenger. The transaction is submitted again with override codes applicable for Malaysia
and Australia.
PRQ/33/1/P/USA//Z4354753///////SMIT////////AMYGAU//////////////
CIRS:111/PRS/28/001/MY/P/USA/USA/Z4354753//P/20250630////
SMITH/ANDREW JACKSON/19620511/M/USA//8517/B/18777////////
PRS/28/001/AU/P/USA/USA/Z4354753//P/20250630////SMITH/ANDREW
JACKSON/19620511/M/USA//8517/B/18777////////

Page 124
The passenger has been given 8517 (“Override accepted”) by both countries. An expected
movement record has been sent to each of the participating governments.
5.1.6 Transfer from One International Flight to Another

The following example relates to a passenger transferring to another international flight at the
start or the end of an international flight and is illustrated by Figure 16.
Check-in Port
Thailand
Bangkok
Los Angeles USA
QF302
QF107
Australia
Sydney
Transit Airport
Figure 16 - Multi-Flight Journey (BKK-SYD-LAX)
5.1.6.1 Example 15: Passenger transferring to another flight
CIRQ:/123456/N//25/INT/8/S/QF302/BKK/SYD/20161212////
PRQ/33/1/P/USA//Z4351213///////SMIT///////Y///////////////
The airline sends a request showing that passenger SMITH is boarding QF302 in Bangkok
and is disembarking in Sydney but is transferring to another international flight at the
destination of this international flight.
Note that a traveller cannot transit a country if they travel on a domestic flight within that
country in between the two international flights. If this occurs, the second international flight
must be processed after the traveller has arrived in the intermediate country as many
countries check the last known location of the traveller to confirm that they are travelling in a
valid direction.
SAMANTHA/19640912/F/USA//8501/B/2128666////////

Page 125
AU has confirmed that the passenger is permitted to transit Australia and has given code
government indicating that the passenger will be transferring in Sydney.
CIRQ:/123456/N//25/INT/8/S/QF107/SYD/LAX/19981031////
PRQ/33/1/P/USA//Z4351213///////SMIT//////Y////////////////
If the airline wants to through-check the passenger, the airline sends a request showing that
passenger SMITH will be boarding QF107 in Sydney and disembarking in Los Angeles, but
will be transferring in Sydney at the origin of the outbound international flight.
[GG sends 5-1 message to AU and AU responds with 6-1 message]
SAMANTHA/19640912/F/USA//8501/B/2128777////////
AU has confirmed that the passenger is permitted to board the flight and has given code
government indicating that the passenger will be departing after having transferred in
Sydney.
5.1.7 Transit on Single Flight

The following example relates to a passenger in transit on a single international flight and is
illustrated by Figure 17.
Check-in Port
Thailand
Bangkok
Los Angeles USA
TG398
TG398
Australia
Sydney
Transit Airport
Figure 17 - Transit on Single Fight (BKK-SYD-LAX)

Page 126
5.1.7.1 Example 16: Passenger in transit on single flight
CIRQ:/123456/N//25/INT/8/S/TG398/BKK/LAX/20161212////
PRQ/33/1/P/USA//Z4351213///////SMIT//////////////////////
The airline sends a request showing that passenger SMITH is boarding TG398 in Bangkok
bound for Los Angeles. The GG uses the airline schedules to determine that the flight
transits Sydney.
[GG sends 5-1 message to AU and AU responds with 6-1 message]
SAMANTHA/19640912/F/USA//8501/B/2128888////////
AU has confirmed that the passenger is permitted to transit Australia and has given code
government indicating that the passenger will be transiting Sydney.
5.1.8 No response from government systems

The following two examples are illustrated by Figure 13 and relate to no response being
received by the GG when one or more government systems are involved.
5.1.8.1 Example 17: No response from one government system
PRQ/33/1/P/USA//Z4351213///////SMIT//////////////////////
[GG sends 5-1 message to AU and AU does not respond.]
PRS/28/001/AU/P/USA//Z4351213//P///////////0000/T/////////
The passenger has been given 8501 (“OK to Board”) by Malaysia but the Australian system
has not responded within the timeout period. No expected movement has been generated
for Australia and the expected movement generated for Malaysia has not been cancelled.
5.1.8.2 Example 18: No response from both (all) government systems

Page 127
PRQ/33/1/P/USA//Z4351213///////SMIT//////////////////////
[GG sends 5-1 message to MY and MY does not respond.]
[GG sends 5-1 message to AU and AU does not respond.]
CIRS:111/ERR/3//5057/NO RESPONSE FROM ETA-APP SYSTEM. PLEASE TRY

AGAIN LATER.
The GG responds with an error message indicating that both (all) government systems have
not responded within the timeout period.
5.1.9 No response from back-end systems

For some countries, processing of an APP transaction depends upon the availability and
timely response of a back-end system. The US CBP AQQ System is an example. Such a
system may not respond within the agreed timeout period. The following two examples are
illustrated by Figure 13 and relate to no response being received from a back-end system.
5.1.9.1 Example 19: No response from one back-end system when multiple countries
involved
PRQ/33/1/P/USA//Z4351213///////SMIT//////////////////////
[GG sends 5-1 message to AU and AU responds with 6-1 message but the response
indicates a back-end system has not responded to provide the information necessary for a
decision.]
PRS/28/001/AU/P/USA//Z4351213//P///////////0000/T/////////
The passenger has been given 8501 (“OK to Board”) by Malaysia but the back-end system
on which the Australian system is dependent has not responded within the timeout period.
No expected movement has been generated for Australia and the expected movement

Page 128
generated for Malaysia has not been cancelled. Note that this response is the same as for
Example 17 above.
5.1.9.2 Example 20: No response from back-end system when only one country
involved
[NOTE: This example assumes that only Australia is an APP country.]
PRQ/33/1/P/USA//Z4351213///////SMIT//////////////////////
[GG sends 5-1 message to AU and AU responds with 6-1 message but the response
indicates a back-end system has not responded to provide the information necessary for a
decision.]
CIRS:111/PRS/28/001/AU/P/USA//Z4351213//P///////////0000/E// 6979/NO
RESPONSE FROM GOVERNMENT SYSTEM. PLEASE TRY AGAIN LATER.//////
The GG responds with an error message indicating that the back-end system did not
respond within the timeout period. Note that this response is different from Example 17 in
that it is treated an error condition (6979) rather than a timeout.
5.1.10 Additional Data Requirements for the USA

The following examples relate to passengers travelling to the USA and are illustrated by
Figure 18.
Chicago
Los Angeles
Sydney
Melbourne
Figure 18 - Travel to the USA (MEL-SYD-LAX-ORD)
5.1.10.1 Example 21: Single passenger inbound to the USA

Page 129
[NOTE: This example assumes that both Australia and the USA are APP countries.]
The passenger’s journey commences in Melbourne with a domestic flight to Sydney, the
international flight is Sydney to Los Angeles and the passenger is continuing to Chicago on a
domestic flight. The passenger is a visitor and has no residency status in the USA. There is
no additional travel document information but address at destination is required.
CIRQ:111/123456/N//25/INT/8/S/UA045/SYD/LAX/20161212////
PRQ/33/1/P/AUS/AUS/F4351213///20100605////SMITH/ROGER JOHN/
19480123/M/NZL/////UA/G45WE2/AUS/MEL/ORD/UAG45WE20003////////
PTI/8/1/QF405/MEL/20161212/071500/SYD/20161212/083000/
PTI/8/1/UA462/LAX/20161212/133000/ORD/20161212/204500/
PAD/12/1/US/////2318 WASHINGTON BLVD/ANN ARBOR/MI/48101///

[GG sends 5-1 message to US and US responds with 6-1 message.]
CIRS:111/PRS/28/001/AU/P/AUS/AUS/F4351213//P/20100605////
SMITH/ROGER JOHN/19480123/M/NZL//8501/B/2129999////////
PRS/28/001/US/P/AUS/AUS/F4351213//P/20100605////SMITH/
ROGER JOHN/19480123/M/NZL//8501/B/2129999////////
The passenger has been given 8501 (“OK to Board”) by both the Australian and USA
systems. An expected movement has been generated for Australia and the USA system has
either submitted an AQQ transaction to U.S. CBP or has stored the movement record for
inclusion in a manifest.
5.1.10.2 Example 22: Multiple passengers inbound to the USA
[NOTE: This example assumes that both Australia and the USA are APP countries.]
The passengers’ journey commences in Melbourne with a domestic flight to Sydney, the
international flight is Sydney to Los Angeles and the passengers are continuing to Chicago
on a domestic flight. The first passenger is a visitor and has no residency status in the USA.
There is no additional travel document information but address at destination is required.
The second passenger is an alien resident in the USA who is continuing to Ottawa from
Chicago. The additional travel document information is required but no address information
is required.
CIRQ:111/123456/N//25/INT/8/S/UA045/SYD/LAX/20161212////
PTI/8/1/QF405/MEL/20161212/071500/SYD/20161212/083000/
PTI/8/1/UA462/LAX/20161212/133000/ORD/20161212/204500/
PAD/12/1/US/////2318 WASHINGTON BLVD/ANN ARBOR/MI/48101///
PRQ/33/2/P/AUS/AUS/E6598765///20070706////JONES/MARY EDITH/
19550112/F/GBR/////UA/G45WE2/USA/MEL/YOW/UAG45WE20006////////

Page 130
PTI/8/1/QF405/MEL/20161212/071500/SYD/20161212/083000/
PTI/8/1/UA985/LAX/20161212/144500/YOW/20161212/222000/
PAD/12/2/US/A/53774873/USA/20100830///////
ROGER JOHN/19480123/M/NZL//8501/B/2128976////////
PRS/28/002/AU/P/AUS/AUS/E6598765//P/20070706////JONES/
MARY EDITH/19550112/F/GBR//8501/B/2128977////////
PRS/28/002/US/P/AUS/AUS/E6598765//P/20070706////JONES/
MARY EDITH/19550112/F/GBR//8501/B/2128977////////
Both passengers have been given 8501 (“OK to Board”) by both the Australian and USA
systems. Expected movements have been generated for Australia and the USA system has
either submitted AQQ transactions to U.S. CBP or has stored the movement records for
inclusion in a manifest.
5.1.11 Domestic Flights

The following example relates to a passenger travelling on a domestic flight in the USA and
is illustrated by Figure 19.
Chicago
Los Angeles
Sydney
Melbourne
Figure 19 - International Journey with Domestic Travel in the USA (LAX-ORD)

Page 131
5.1.11.1 Example 23: Single passenger on domestic flight in USA
[NOTE: This example assumes that the USA requires processing of domestic passengers
eg. for Secure Flight.]
The passenger is travelling from Los Angeles to Chicago on a domestic flight. Prior to
checking in for this flight, the passenger travelled from Melbourne to Sydney on a domestic
flight, then on an international flight from Sydney to Los Angeles. The passenger is a visitor
and has no residency status in the USA. There is no additional travel document information
and the address at destination is not required as it would have been reported on the inbound
movement. However, the PAD data group is still required.
CIRQ:111/123456/N//25/DOM/8/S/UA462/LAX/ORD/20161212////
PTI/8/1/QF405/MEL/20161212/071500/SYD/20161212/083000/
PTI/8/1/UA535/SYD/20161212/103000/LAX/20161212/061500/
PAD/12/1/US///////////
CIRS:111/PRS/28/001/US/P/AUS/AUS/F4351213//P/20100605////
The passenger has been given 8501 (“OK to Board”) by the USA system.
5.1.12 Overflight
The following example relates to a passenger travelling on a flight which is overflying the
USA and is illustrated by Figure 20.
Vancouver
Sydney
Melbourne
Figure 20 - Overflight of the USA (SYD-YVR)

Page 132
5.1.12.1 Example 24: Single passenger on overflight of USA
[NOTE: This example assumes that Australia is an APP country and that the USA requires
processing of overflight passengers eg. for Secure Flight.]
The passenger is travelling from Melbourne to Sydney on a domestic flight and then on an
international flight from Sydney to Vancouver. During the Sydney to Vancouver flight, the
passenger is overflying USA air space. There is no additional travel document information
and the address at destination is not required. However, the PAD data group is still required.
CIRQ:111/123456/N//25/INT/8/S/QF444/SYD/YVR/20161212////
OVR/3/SYD/YVR/US/
19480123/M/NZL/////QF/RED54G/AUS/MEL/YVR/QFRED54G0004////////
PTI/8/1/QF405/MEL/20161212/071500/SYD/20161212/083000/
PAD/12/1/US///////////

ROGER JOHN/19480123/M/NZL//8501/B/2129999////////
The passenger has been given 8501 (“OK to Board”) by both the Australian and USA
systems.

Page 133
5.2 MOVEMENT CANCELLATION EXAMPLES
5.2.1 Cancel Movement for Single Passenger

The following three examples relate to cancellation of APP for a single passenger and are
5.2.1.1 Example 25: Cancellation: passenger located
Airline to GG (CICX Message)
CICX:/123456/N//25/INT/8/S/BA033/KUL/SYD/20161212////PCX/21/1/000000
002128666/P/USA/USA/Z4351213///////SMIT/////////
The airline submits a cancellation request with the passenger’s passport number, nationality,
family name (in part), and the Expected Passenger ID.
[GG sends 5-2 message to AU which responds with 6-2 message including the full
passenger biodata.]
GG to Airline (CICC Message)
CICC:/PCC/26/001/AU/P/USA/USA/Z4351213//P/////SMITH/SAMANTHA/
19640912/F/USA//8505/C///////
AU has confirmed that the cancellation was successful by giving code 8505 (“Cancelled”).
An additional movement record has been sent to the participating government for this
passenger, flagged as a cancellation.
5.2.1.2 Example 26: Cancellation: passenger not located
CICX:/123456/N//25/INT/8/S/BA033/KUL/SYD/20161212////PCX/21/1//P/USA
//Z4351213///////SMIT/////////
family name (in part), but without the Expected Passenger ID.
[GG sends 5-2 message to AU which responds with 6-2 message carrying the code 8506
(“No Record”).]
CICC:/PCC/26/001/AU/P/USA//Z4351213//P/////SMIT//////8506/N///////
AU has been unable to process the cancellation because a previous successful APP
transaction for this passenger cannot be found. The check-in agent should check the details
and resubmit the cancellation (preferably supplying the Expected Passenger ID, which is
proof that a previous successful APP transaction occurred).

Page 134
5.2.1.3 Example 27: Cancellation: error condition (passport format error)
//Z43512///////SMIT/////////
family name (in part), but without the Expected Passenger ID.
(“Invalid passport number format”).]
CICC:/PCC/26/001/AU/P/USA//Z43512//P/////SMIT//////0000/E/
6033/INVALID PASSPORT NUMBER FORMAT/////
AU has been unable to process the cancellation because it has detected that the passport
number for this passenger does not conform to the valid number format for this nationality.
The check-in agent should resubmit a cancellation for the passenger, taking care to ensure
that the passport number is correct (or preferably supplying the Expected Passenger ID).
5.2.2 Cancel Movements for Multiple Passengers

The following example relates to cancellation of APP for multiple passengers and is
5.2.2.1 Example 28: Cancellation: multiple passengers
//Z4351213///////SMIT/SAMANTHA////////PCX/21/2//P/USA//Z4351213/////
//SMITH/BELINDA////////
The airline submits a cancellation request for two passengers with the same passport
number, nationality and family name (in part), but with different given names and without the
Expected Passenger IDs.
(“Cancelled”) and the full biodata for each passenger.]
CICC:/PCC/26/001/AU/P/USA//Z4351213//P/////SMITH/SAMANTHA/
19640912/F/USA//8505/C///////PCC/26/002/AU/P/USA//Z4351213//P/////SM
ITH/BELINDA/19940421/F/USA//8505/C///////

Page 135
AU has confirmed that the cancellation was successful by giving code 8505 (“Cancelled”).
An additional movement record has been sent to the participating government for each
passenger, flagged as a cancellation.
5.2.3 Cancel Movement for Single Passenger (inbound to USA)

The following example relates to cancellation of APP for a single passenger and is illustrated
by Figure 18.
5.2.3.1 Example 29: Cancellation: passenger located
[NOTE: This example assumes that Australia does not process outbound APP transactions
and the USA processes inbound APP transactions.]
CICX:/123456/N//25/INT/8/S/UA045/SYD/LAX/20161212////PCX/21/1//P/USA
/USA/Z4351213///////SMIT////////UAG66WX20004/
family name (in part) and the Passenger Reference required by the USA.
[GG sends 5-2 message to US which responds with 6-2 message including the full
passenger biodata.]
CICC:/PCC/26/001/US/P/USA/USA/Z4351213//P/////SMITH/SAMANTHA/
19640912/F/USA//8505/C///////
The AP has confirmed that the cancellation was successful by giving code 8505
(“Cancelled”).

Page 136
5.3 MANIFEST EXAMPLES
5.3.1 Manifest Request and Enquiry

The following examples relate to the request for a manifest for passengers checked in for the
flight illustrated by Figure 13 and a subsequent enquiry on the status of the requested
manifest.
5.3.1.1 Example 30: Manifest Request
Airline to GG (CIMR Message)
CIMR:/123456/25/INM/3/BA033/KUL/20161212/MRQ/3/AU/F/N/
The airline submits the request for a manifest for passengers bound for Australia (but not for
crew). The manifest will include all passengers on the flight to Australia, even if they are
transiting Australia on this flight or are transferring to another flight out of Australia.
[GG sends 5-3 message to AU which responds with 6-3 message.]
GG to Airline (CIMA Message)
CIMA:/MAK/4/AU/8700///
AU has confirmed that the request has been accepted and queued by giving code 8700
(“Request processed”). This response may or may not mean that the manifest has actually
been generated and received by the government authority. Refer to Table 10 for further
information.
5.3.1.2 Example 31: Manifest Request: error condition (international flight not in
schedules)
CIMR:/123456/25/INM/3/BA033/SIN/20161212/MRQ/3/AU/F/N/
The airline submits the request for a manifest for passengers bound for Australia (but not for
crew). However, the request incorrectly indicates the origin of the flight as SIN instead of
KUL and the flight cannot be found in the airline schedules.
[GG sends 5-3 message to AU which responds with 6-3 message carrying the error code
5593 (“International flight not in airline schedules”).]
CIMA:/ERR/3//5593/INTERNATIONAL FLIGHT NOT IN AIRLINE SCHEDULES/
The user will need to correct the data in the request and retransmit the request.

Page 137
5.3.1.3 Example 32: Manifest Enquiry
Airline to GG (CIME Message)
CIME:/123456/25/INM/3/BA033/KUL/20161212/MEN/1/AU/
The airline submits the enquiry on manifests for passengers and crew bound for Australia on
a particular flight.
[GG sends 5-4 message to AU which responds with 6-4 message.]
GG to Airline (CIMS Message)
CIMS:/MST/7/AU/153/9/153/0///
AU has indicated that both passengers (153) and crew (9) have been checked in through the
APP System. At the time of the enquiry, only the passengers have been generated in
passenger manifests. The generation of the crew in crew manifests has not been completed.
5.3.1.4 Example 33: Manifest Enquiry: error condition (international flight not in
schedules)
Airline to GG (CIME Message)
CIME:/123456/25/INM/3/BA033/SIN/20161212/MEN/1/AU/
The airline submits the enquiry on manifests for passengers and crew bound for Australia on
a particular flight. However, the request incorrectly indicates the origin of the flight as SIN
instead of KUL and the flight cannot be found in the airline schedules.
[GG sends 5-4 message to AU which responds with 6-4 message carrying the error code
5593 (“International flight not in airline schedules”).]
GG to Airline (CIMS Message)
CIMS:/ERR/3//5593/INTERNATIONAL FLIGHT NOT IN AIRLINE SCHEDULES/
The user will need to correct the data in the enquiry and retransmit the enquiry.
5.3.2 Flight Closeout and Cancellation

The following examples relate to requests for flight closeout and flight cancellation for the
flight illustrated by Figure 18.
5.3.2.1 Example 34: Flight Closeout
CIMR:/123456/25/INM/3/UA045/SYD/20161212/MRQ/3/US/C/N/

Page 138
The airline submits a flight closeout request for passengers bound for the USA (but not for
crew). The manifest will include all passengers on the flight to the USA or those checked in
but not boarded, depending upon the processes on the AP.
[GG sends 5-3 message to US which responds with 6-3 message.]
CIMA:/MAK/4/US/8700///
US has confirmed that the request has been accepted and queued by giving code 8700
(“Request processed”). Depending upon the implementation for a country,
acknowledgement of this message may not be an acknowledgment that the manifest has
been generated and delivered. Refer to Table 10 for further information.
5.3.2.2 Example 35: Flight Cancellation
CIMR:/123456/25/INM/3/UA045/SYD/20161212/MRQ/3/US/X/N/
The airline submits a flight cancellation request for passengers bound for the USA (but not
for crew). The manifest will include all passengers previously checked in for the flight or
simply an indication that the flight has been cancelled, depending upon the processes on the
AP.
CIMA:/MAK/4/US/8700///
US has confirmed that the request has been accepted and queued by giving code 8700
(“Request processed”). Depending upon the implementation for a country,
acknowledgement of this message may not be an acknowledgment that the manifest has
been generated and delivered. Refer to Table 10 for further information.
5.4 PASSENGER STATUS REQUESTS
5.4.1 Passenger Status Request

The following examples relate to requests for passenger status updates for the flight
5.4.1.1 Example 36: Passenger Status Request (Single Page)
Airline to GG (CICO Message)
CICO:/123456/25/INM/3/UA045/SYD/20161212/PSQ/2/US/1/

Page 139
The airline submits a request for changes to passenger status for passengers checked in for
a flight to the USA. The response will include those passengers for whom the status has
changed since they were originally checked in.
GG to Airline (CIUR Message)
CIUR:/PST/14/US/UA045/SYD/20161212/001/N/001/UA124A53004/8501/B/002/
UA4371D4005/8541/B/
US has indicated that the status of the first listed passenger has been updated to 8501 (“OK
to Board”) and that the status of the second listed passenger has been updated to 8541
(“Selectee”). There are no further updates available at this time.
5.4.1.2 Example 37: Passenger Status Request (Multiple Pages)
a flight to the USA. The response will include those passengers for whom the status has
changed since they were originally checked in.
CIUR:/PST/86/US/UA045/SYD/20161212/001/Y/001/UA124A53004/8501/B/002/
UA4371D4005/8541/B/003/UA994A53010/8501/B/004/
UA454AS2003/8501/B/....../020/UA53YT31006/8541/B/
US has indicated that the statuses of 20 passengers have changed and that information is
available on more passengers.
The airline submits a request for information on the second block of passengers.
CIUR:/PST/14/US/UA045/SYD/20161212/002/N/001/UA444B55004/8501/B/002/
UA74ER32005/8541/B/
The second block of passenger data has been returned with information on two more
passengers and the system has indicated that there is no more data available.

Page 140
5.4.1.3 Example 38: Passenger Status Request: error condition

(international flight not in schedules)
CICO:/123456/25/INM/3/UA045/MEL/20161212/PSQ/2/US/1/
a flight to the USA. However, the request incorrectly indicates the origin of the flight as MEL
instead of SYD and the flight cannot be found in the airline schedules.
CIUR:/ERR/3//5593/INTERNATIONAL FLIGHT NOT IN AIRLINE SCHEDULES/
The user will need to correct the data in the request and retransmit the request.
5.4.1.4 Example 39: Passenger Status Request: no passenger data available
CICO:/123456/25/INM/3/UA045/MEL/20161212/PSQ/2/US/1/
a flight to the USA. However, there are no passengers for the flight for whom the status has
been updated.
CIUR:/PST/6/US/UA045/MEL/20161212/001/N/
This situation is not treated as an error condition. The flight information is returned but there
is no passenger data in the message.

Page 141
5.5 GATE PASS

5.5.1 Gate Pass Request for Domestic Flight
The following example relates to a request for a gate pass for a person accompanying a
passenger to the departure gate for a US domestic flight and is illustrated by Figure 21.
Chicago
Los
Angeles
Sydney
Melbourne
Figure 21 - Domestic Journey in the USA (LAX-ORD)
5.5.1.1 Example 40: Single gate pass
[NOTE: This example assumes that the USA requires processing of gate passes for persons
accompanying domestic passengers eg. for Secure Flight.]
The passenger is travelling from Los Angeles to Chicago and is accompanied by a person
who requires a gate pass.
Airline to GG (CIGR Message)
CIGR:111/123456/25/US/UA/LAX/20161212/
GPR/16/1/AUS/AUS/F4351213/P/P/20100605/SMITH/ROGER JOHN/
19480123/M/UA/G45WE2/UAG45WE20001///
GG to Airline (CIGS Message)
CIGS:111/US/GPS/5/001/UAG45WE20001/8580///
The person has been given 8580 (“Gate Pass can be issued”) by the USA system.

Page 142
5.6 COMPLETE MESSAGE SAMPLE (INCLUDING MESSAGE

HEADER)
5.6.1.1 Example 41: Complete CIRQ message
Below is an example of a complete CIRQ message, including the Layer 5 and Layer 7
message headers, from ZZ airline:
562E0D56 484C472E 57412F45 31415054 5A5A2F49

V . . V H L G . W A / E 1 A P T Z Z / I
35415054 58532F50 30303039 0D56475A 0D565A5A

5 A P T X S / P 0 0 0 9 . V G Z . V Z Z
2F53464F 2F2F2F2F 2F2F2F2F 2F55530D 02434952

/ S F O / / / / / / / / / U S . . C I R
513A3031 2F50452F 4E2F2F32 342F494E542F 382F

Q : 0 1 / P E / N / / 2 4 / I N T / 8 /
532F5A5A 30303031 2F53464F 2F535944 2F313939

S / Z Z 0 0 0 1 / S F O / S Y D / 2 0 1
39303630 332F2F2F 2F505251 2F32362F 3030312F

7 0 6 0 3 / / / / P R Q / 2 6 / 0 0 1 /
502F5553 2F2F3233 35363233 3536312F 2F2F2F2F

P / U S / / 2 3 5 6 2 3 5 6 1 / / / / /
2F2F484F 4C594649 454C442F 4A4F484E 2F313935

/ / H O L Y F I E L D / J O H N / 1 9 5
37303131 322F4D2F 2F2F2F2F 2F2F2F2F 2F2F2F2F

7 0 1 1 2 / M / / / / / / / / / / / / /
2F2F2F2F 2F2F03
/ / / / / / .

Page 143
A. CHECK-IN MESSAGE CODES

The table below (Table 37) lists the possible message codes to be generated by the GG on check-in (or cancellation) together with the short
message (limited to 21 characters) that is to be displayed on the user’s screen in Stand-alone APP. The table also gives an expanded
description of the meaning of the message and the action to be taken.
Msg Brief Action required by Notes Used by … Pax
Code description airline Status
(max 21 Code
chars)
MM
OM
TW
QA
SG
AU
BH
UK
KR
SA
US
AE
NZ
ZA
TH
LA
8501 OK TO Allow the passenger An expected passenger Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y B
BOARD to board. movement has been
created.
AQQ/ESTA response code
0:
Watch list cleared.
CBSA iAPI response code
A: Prescribed IRPA travel
document on file
8502 DO NOT Do not allow the An expected movement Y Y Y Y Y Y Y Y D
BOARD passenger to board. record has not been
created. However, all the
required data is available
for the passenger and the
directive may be
overridden after reference
to published guidelines
(Override Code “A”) or after
contact with government
agencies (Override Code
“G”).
B: Prescribed IRPA travel
document not on file.


(max 21 Code
chars)
MM
OM
TW
QA
SG
AU
BH
UK
KR
SA
US
AE
NZ
ZA
TH
LA
8503 BOARD IF Check the An expected passenger Y Y Y Y Y Y Y Y Y B
DOCS OK passenger’s movement has been
documents and allow created. No record for the
the passenger to passenger could be found
board if the normal on the government
checks confirm the database. The passenger
passenger’s eligibility can be allowed to board if
to travel. their documents comply
with the normal
requirements for travel.
8505 CANCELLED (Confirmation that A previous movement has Y Y Y Y Y Y Y Y Y Y Y Y Y Y C
cancellation was been cancelled (i.e. where
successful). passenger previously
received “OK to Board” or
equivalent for this flight).
8506 NO RECORD (Advice that An attempt was made to Y Y Y Y Y Y Y Y Y Y Y Y Y N
cancellation was not cancel a previous
successful). movement (for this flight)
but no record can be found
to cancel.
8507 DUPLICATE Do not allow the There is more than one Y Y Y U
NAME passenger to board. person on the passport
Retry APP for this matching the data
passenger using provided. Need to include
additional data. full bio-data for the person
(eg. family name, given
names, date of birth, sex).


(max 21 Code
chars)
MM
OM
TW
QA
SG
AU
BH
UK
KR
SA
US
AE
NZ
ZA
TH
LA
8508 REPEATED – Ensure that the An expected movement Y Y B
1
OK TO correct travel record has not been
BOARD document information created for this transaction
has been submitted because the system
for the passenger. determined that an
equivalent expected
movement has already
been generated.
The check-in agent should
ensure that reversing the
passenger check-in does
not cancel the original
expected movement.
8509 BORDER Do not allow the An expected movement Y2 X
CLOSED passenger to board. record has not been
The government has created. This code will be
closed the border. returned if the government
has closed the border in
the event of an emergency.
8510 CONTACT Do not allow the An expected movement Y2 D
BOC passenger to board. record has not been
for the passenger. The
check-in agent must seek
advice from BOC (Border
Operations Centre) in
Canberra, Australia (Tel:
+61-1300 368 126).


(max 21 Code
chars)
MM
OM
TW
QA
SG
AU
BH
UK
KR
SA
US
AE
NZ
ZA
TH
LA
8516 INSUFFI- Do not allow the Data on the passenger has Y Y Y Y Y Y Y Y Y Y Y Y Y Y I
CIENT DATA passenger to board. not been found in the
Provide the full set of government databases.
passport and personal Full data for the passenger
data for the must be captured before a
passenger. decision can be made.
AQQ/ESTA response
codes 4X, 4Z (for USA).
X: Re-submit Required -
Insufficient data - need
more information
8517 OVERRIDE Allow the passenger The override submitted has Y Y Y Y Y Y Y Y Y Y Y Y Y B
ACCEPTED to board. been accepted. An
expected passenger
movement has been
created.
8519 BRD WITH Allow the passenger The passenger cannot be Y Y Y B
OWT to board as long as permitted to board unless
they have an onward they possess a ticket for an
ticket. onward journey. An
expected movement record
has been created.


(max 21 Code
chars)
MM
OM
TW
QA
SG
AU
BH
UK
KR
SA
US
AE
NZ
ZA
TH
LA
NZIS passenger to board. record has not been
advice from the Advance
Passenger Screening
(APS) Support Office, INZ,
Auckland, New Zealand
(Tel: +64-9-277-0634).
GDNPR passenger to board. record has not been
advice from the GDNPR.
8540 DO NOT Do not allow the All the required data is Y2 D
BOARD passenger to board. available for the
passenger. The check-in
agent must seek advice
from CBP.
1:
Watch list inhibited.


(max 21 Code
chars)
MM
OM
TW
QA
SG
AU
BH
UK
KR
SA
US
AE
NZ
ZA
TH
LA
8541 SELECTEE Do not allow A boarding pass may be Y Y B
passenger to board issued. However, further
until further security security checks are
checks have been required before the
performed. passenger can be
permitted to board and
there must be a
mechanism for ensuring
that those checks are
performed. If the
passenger is not permitted
to board, the movement
must be cancelled.
2:
Watch list selectee.
8560 Not used Do not board until An expected movement Y2 D
(AQQ not travel authority has record has not been
implemented been issued created.
with Stand- AQQ/ESTA response code
alone APP) 0X:
Watch list cleared.
Insufficient ESTA data.
8561 Not used Allow the passenger An expected movement Y2 B
(AQQ not to board record has been created.
implemented AQQ/ESTA response code
with Stand- 0Z:
alone APP) Watch list cleared. ESTA
not applicable.


(max 21 Code
chars)
MM
OM
TW
QA
SG
AU
BH
UK
KR
SA
US
AE
NZ
ZA
TH
LA
with Stand- 0A:
alone APP) Watch list cleared. ESTA
approved.
8563 Not used Conditional An expected movement Y2 B
(AQQ not If passenger holds a record has been created.
implemented valid US non- AQQ/ESTA response code
with Stand- immigrant visa or 0B:
alone APP) some other Watch list cleared. No
acceptable US entry ESTA data filed.
document, passenger
can board. Otherwise
they must complete
an ESTA registration
prior to boarding, or
the check-in
transaction must be
cancelled.


(max 21 Code
chars)
MM
OM
TW
QA
SG
AU
BH
UK
KR
SA
US
AE
NZ
ZA
TH
LA
(AQQ not If passenger holds a record has been created.
with Stand- immigrant visa or 0C:
alone APP) some other Watch list cleared, ESTA
acceptable US entry requires additional US
document, passenger Travel document
they must obtain a
valid US entry
document or
successfully complete
the check-in
transaction must be
cancelled.
8565 Not used Do not allow An expected movement Y2 D
(AQQ not passenger to board. record has not been
implemented created.
alone APP) 11:
Watch list inhibited. ESTA
inhibited.
(AQQ not passenger to board record has not been
alone APP) 2X:
Watch list selectee.


(max 21 Code
chars)
MM
OM
TW
QA
SG
AU
BH
UK
KR
SA
US
AE
NZ
ZA
TH
LA
8567 Not used Allow passenger to An expected movement Y2 B
(AQQ not board with extra record has been created.
implemented security checks. AQQ/ESTA response code
with Stand- 2Z:
alone APP) Watch list selectee. ESTA
not applicable.
8568 Not used Allow passenger to An expected movement Y2 B
(AQQ not board with extra record has been created.
implemented security checks. AQQ/ESTA response code
with Stand- 2A:
alone APP) Watch list selectee. ESTA
approved.
(AQQ not Extra security checks record has been created.
implemented required. AQQ/ESTA response code
with Stand- If passenger holds a 2B:
alone APP) valid US non- Watch list selectee. No
immigrant visa or ESTA filed.
some other
acceptable US entry
document, passenger
they must complete
the check-in
transaction must be
cancelled.


(max 21 Code
chars)
MM
OM
TW
QA
SG
AU
BH
UK
KR
SA
US
AE
NZ
ZA
TH
LA
(AQQ not Extra security checks record has been created.
implemented required. AQQ/ESTA response code
with Stand- If passenger holds a 2C:
alone APP) valid US non- Watch list selectee. US
immigrant visa or Travel Document Required.
some other
acceptable US entry
document, passenger
they must obtain a US
entry document or
the check-in
transaction must be
cancelled.
8571 Not Used Allow the passenger An expected movement Y2 B
with 3Z:
Standalone
APP) Known passenger number
accepted, ESTA not
applicable
8572 Not Used Allow the passenger An expected movement Y2 B
(AQQ not to board record has been created
with 3A:
Standalone
accepted, ESTA approved


(max 21 Code
chars)
MM
OM
TW
QA
SG
AU
BH
UK
KR
SA
US
AE
NZ
ZA
TH
LA
8573 Not Used Conditional An expected movement Y2 B
(AQQ not If passenger holds a record has been created
with immigrant visa or 3B:
Standalone some other Known passenger number
APP) acceptable US entry accepted, no ESTA data
document, passenger filed.
they must complete
the check-in
transaction must be
cancelled.
8574 Not Used Conditional An expected movement Y2 B
(AQQ not If passenger holds a record has been created
with immigrant visa or 3C:
Standalone some other
acceptable US entry accepted, ESTA requires
document, passenger additional US Travel
can board. Otherwise Document
they must obtain a
valid US entry
document or
the check-in
transaction must be
cancelled.


(max 21 Code
chars)
MM
OM
TW
QA
SG
AU
BH
UK
KR
SA
US
AE
NZ
ZA
TH
LA
8575 Not Used Do not allow the An expected movement Y2 D
(AQQ not passenger to board identifier has not been
implemented created
with AQQ/ESTA response code
Standalone 3X:
APP)
Known passenger number
accepted, Insufficient
ESTA data.
8580 Not used Gate Pass can be AQQ/ESTA response code Y2 B
(AQQ not issued. 0Z:
implemented Person cleared for gate
with Stand- pass. ESTA not
alone APP) applicable.
8581 Not used Gate Pass cannot be AQQ/ESTA response code Y2 D
(AQQ not issued. 1Z:
implemented Person not cleared for gate
with Stand- pass. ESTA not applicable.
alone APP)
8582 Not used Conditional AQQ/ESTA response code Y2 B
(AQQ not Gate pass can be 2Z:
implemented issued. Extra security Selectee. ESTA not
with Stand- checks required. applicable.
alone APP)
8583 Not used Do not allow the An expected movement Y2 D

alone APP) 1A:
approved.


(max 21 Code
chars)
MM
OM
TW
QA
SG
AU
BH
UK
KR
SA
US
AE
NZ
ZA
TH
LA
alone APP) 1B:
Watch list inhibited. No
ESTA data filed.
alone APP) 1C:
Watch list inhibited. US
Travel document required.
alone APP) 1X:
Watch list inhibited.
alone APP) 1Z:
not applicable.


(max 21 Code
chars)
MM
OM
TW
QA
SG
AU
BH
UK
KR
SA
US
AE
NZ
ZA
TH
LA
DHA passenger to board. record has not been
advice from the DHA.
QATAR GOVT passenger to board. record has not been
advice from the Qatar
Government.
8610 Not used Allow the passenger 75-Not found Contact the Y2 B
(Not to board immigration office at 82-32-
implemented 740-7241~2
with Stand-
alone APP)
8611 Not used Allow the Passenger Y2 B
(Not to board due to time-
implemented out.
with Stand-
alone APP)
8612 Not used Do not allow the 61-Passport expired! Y D
(Not passenger to board. Contact the Passport
implemented service at 82-32-740-2770
with Stand-
alone APP)


(max 21 Code
chars)
MM
OM
TW
QA
SG
AU
BH
UK
KR
SA
US
AE
NZ
ZA
TH
LA
8612 Not used Do not allow the 62-Departure prohibited, Y D
(Cont) (Not passenger to board. Contact the immigration
implemented office at 82-32-740-7247~8
with Stand-
alone APP)
Not used Do not allow the 63-Overstayed... and so Y D
(Not passenger to board. on! Contact the immigration
with Stand-
alone APP)
Not used Do not allow the 64-Resident passport Y D
(Not passenger to board. expired! Contact the
implemented Passport service at 82-32-
with Stand- 740-2770
alone APP)
Not used Do not allow the 65-Resident passport Y D
(Not passenger to board. expired! Contact the
implemented Passport service at 82-32-
with Stand- 740-2770
alone APP)
Not used Do not allow the 66-Single passport reused! Y D
(Not passenger to board. Contact the immigration
with Stand-
alone APP)
Not used Do not allow the 71-Check the overseas Y D
(Not passenger to board. travel permit! Contact the
with Stand-
alone APP)


(max 21 Code
chars)
MM
OM
TW
QA
SG
AU
BH
UK
KR
SA
US
AE
NZ
ZA
TH
LA
8612 Not used Do not allow the 74-Nullified or suspended Y D
(Cont) (Not passenger to board. passport! Contact the office
implemented at 82-32-740-7247~8
with Stand-
alone APP)
Not used Do not allow the 99-Outbound Prohibited Y D
(Not passenger to board.
implemented
with Stand-
alone APP)
Not used Do not allow the 99-Inbound Prohibited Y D
(Not passenger to board.
implemented
with Stand-
alone APP)
Not used Do not allow the 52-Passport or Transport Y D
(Not passenger to board. Qualifier is Expired
implemented
with Stand-
alone APP)
Not used (Not Do not allow the Free text may be sent in Y D
implemented passenger to board. the text segment (30) of the
with Stand- CIRS message.
alone APP)
8613 Not used Do not allow the 67-No entry data! Contact Y2 B
(Not passenger to board the immigration office at
implemented until further screening 82-32-740-7247~8
with Stand- has been performed.
alone APP)


(max 21 Code
chars)
MM
OM
TW
QA
SG
AU
BH
UK
KR
SA
US
AE
NZ
ZA
TH
LA
8613 Not used Do not allow the 72-Check the re-entry Y2 B
(cont) (Not passenger to board permit! Contact the
implemented until further screening immigration office at 82-32-
with Stand- has been performed. 740-7247~8
alone APP)
Not used Do not allow the 73-No Passport data! Y2 B
(Not passenger to board Contact the immigration
implemented until further screening office at 82-32-740-7247~8
with Stand- has been performed.
alone APP)
SAUDI GOVT passenger to board. record has not been
advice from the Saudi
Arabian Government.
UAE GOVT passenger to board. record has not been
advice from the UAE
Government.


(max 21 Code
chars)
MM
OM
TW
QA
SG
AU
BH
UK
KR
SA
US
AE
NZ
ZA
TH
LA
8635 VISA NOT Do not allow the An expected movement Y2 D
FOUND passenger to board. record has not been
Resubmit with valid created.
visa details.
If the traveller has the
details of a valid visa, a
new request should be
submitted including the
visa details.
OMAN GOVT passenger to board. record has not been
advice from the Oman
Government.
THAI GOVT passenger to board. record has not been
advice from the Thailand
Government.
MYANMAR passenger to board. record has not been
GOVT created. However, all the
advice from the Myanmar
Government.


(max 21 Code
chars)
MM
OM
TW
QA
SG
AU
BH
UK
KR
SA
US
AE
NZ
ZA
TH
LA
8690 OK to Board Allow the passenger An expected movement B
to board record has been created.
Z: Prescribed IRPA
document not applicable or
not required – passenger is
exempt from the document
requirement.
implemented
alone APP) 0V:
Watchlist: Cleared
Document Validation: Visa
on file
(AQQ not passenger to board, record has not been
implemented Re-submit required created
with Stand- when visa has been
alone APP) filed.
0N:
Watchlist: Cleared
Document Validation: No
visa on file


(max 21 Code
chars)
MM
OM
TW
QA
SG
AU
BH
UK
KR
SA
US
AE
NZ
ZA
TH
LA
implemented
alone APP) 0U:
Watchlist: Cleared
Document Validation: US
document on file
with Stand- when US document
alone APP) has been filed.
0D:
Watchlist: Cleared
US document on file
implemented created
with Stand-
alone APP) AQQ/ESTA response code
0R:
Watchlist: Cleared
Document Validation:
Recommended No board


(max 21 Code
chars)
MM
OM
TW
QA
SG
AU
BH
UK
KR
SA
US
AE
NZ
ZA
TH
LA
8705 Not used Re-submit required. An expected movement Y2 D
(AQQ not record has not been
implemented created
with Stand-
0T:
Watchlist: Cleared
Timeout
implemented until status has been created
with Stand- obtained.
0P:
Watchlist: Cleared
Pending
implemented created
with Stand-
1V:
Watchlist: Inhibited
on file


(max 21 Code
chars)
MM
OM
TW
QA
SG
AU
BH
UK
KR
SA
US
AE
NZ
ZA
TH
LA
implemented created
with Stand-
1N:
visa on file
implemented created
with Stand-
1U:
document on file
implemented created
with Stand-
1D:
US document on file


(max 21 Code
chars)
MM
OM
TW
QA
SG
AU
BH
UK
KR
SA
US
AE
NZ
ZA
TH
LA
implemented created
with Stand-
1R:
implemented created
with Stand-
1T:
Timeout
implemented created
with Stand-
1P:
Pending


(max 21 Code
chars)
MM
OM
TW
QA
SG
AU
BH
UK
KR
SA
US
AE
NZ
ZA
TH
LA
(AQQ not to board with extra record has been created
implemented security checks.
alone APP) 2V:
Watchlist: Selectee
on file
alone APP) filed.
2N:
Watchlist: Selectee
visa on file
alone APP) 2U:
Watchlist: Selectee
document on file


(max 21 Code
chars)
MM
OM
TW
QA
SG
AU
BH
UK
KR
SA
US
AE
NZ
ZA
TH
LA
2D:
Watchlist: Selectee
US document on file
implemented created
with Stand-
2R:
Watchlist: Selectee
implemented created
with Stand-
2T:
Watchlist: Selectee
Timeout


(max 21 Code
chars)
MM
OM
TW
QA
SG
AU
BH
UK
KR
SA
US
AE
NZ
ZA
TH
LA
2P:
Watchlist: Selectee
Pending
alone APP) 3V:
Watchlist: Known pax
number accepted
on file
alone APP) filed.
3N:
number accepted
visa on file


(max 21 Code
chars)
MM
OM
TW
QA
SG
AU
BH
UK
KR
SA
US
AE
NZ
ZA
TH
LA
alone APP) 3U:
number accepted
document on file
3D:
number accepted
US document on file
implemented created
with Stand-
3R:
number accepted


(max 21 Code
chars)
MM
OM
TW
QA
SG
AU
BH
UK
KR
SA
US
AE
NZ
ZA
TH
LA
implemented created
with Stand-
3T:
number accepted
Timeout
3P:
number accepted
Pending
0E:
Watchlist: Cleared for
Security Screening
EVUS on File


(max 21 Code
chars)
MM
OM
TW
QA
SG
AU
BH
UK
KR
SA
US
AE
NZ
ZA
TH
LA
1E:
EVUS on File
2E:
Watchlist: Selectee
EVUS on File
LAOS GOVT passenger to board. record has not been
advice from the Laos
Government.


(max 21 Code
chars)
MM
OM
TW
QA
SG
AU
BH
UK
KR
SA
US
AE
NZ
ZA
TH
LA
SINGAPORE passenger to board. record has not been
GOV created. However, all the
advice from the
Singaporean Government.
Notes:
1
Use of this Check-in Message Code is configurable by airline. It will only be returned to an airline DCS if requested by the airline.
2
This Check-in Message Code is exclusive to the country indicated.
Table 37 - Check-in Message Codes

B. APPENDIX: APP SYSTEM ERROR CODES

B.1 GG ERROR CODES
The table below (Table 38) contains error codes originating from the GG for both ETA and
APP processes. New error codes are highlighted in blue italics.
Error Description
Code
5001 Valid family name required
5002 Valid given names or ‘-‘ required
5003 Valid nationality required
5004 Valid document number required
5006 Valid date of birth required
5007 Valid country of birth required
5008 Valid sex code required
5010 Document number must be blank if document type is ‘N’
5011 Valid crew type required
5051 More input lines expected
5056 Illegal Message Type/Sub-Type received from AP
5057 No response from ETA-APP System. Please try again later.
5060 Must have at least 12 lines to use ETA System
5067 Not allowed as primary transaction
5068 Screen less than 14 lines. Use command line.
5100 Invalid selection for additional citizenship
5101 Required if other citizenship held
5102 Must be blank if no other citizenship held
5103 Invalid citizenship country code
5104 At least one address line is required
5105 Address contains invalid characters
5106 Invalid telephone country code
5107 Incomplete home telephone number
5108 Invalid telephone area code
5109 Invalid telephone number
5110 Incomplete business telephone number
5111 Incomplete mobile telephone number
5112 Email address contains invalid characters
5200 Invalid country of residence
5201 Invalid traveler origin
5202 Invalid traveler destination
5203 Invalid passenger reference
5204 Invalid country for additional data
5205 Invalid additional travel document type
5206 Invalid additional travel document number
5207 Invalid additional travel document country of issuance

Page 174
5208 Invalid additional travel document expiration date

5209 Invalid address number and street
5210 Invalid address city
5211 Invalid address state
5212 Invalid address postal code
5213 Valid First Name required
5214 Invalid message format
5215 Invalid transaction type qualifier
5216 Invalid check-in port
5217 Domestic flight number not provided or format invalid
5218 Domestic flight departure date invalid
5219 Domestic flight departure date outside allowable range
5220 Valid domestic flight departure time required
5221 Valid domestic flight arrival date required
5222 Valid domestic flight arrival time required
5223 Invalid country for gate pass request
5224 Invalid carrier for gate pass request
5225 Invalid country for overflight
5226 Invalid airport for gate pass request
5227 Invalid place of birth city
5228 Invalid place of birth state
5229 Invalid itinerary flight number
5230 Invalid itinerary flight departure port
5231 Invalid itinerary flight departure date
5232 Invalid itinerary flight departure time
5233 Invalid itinerary flight arrival port
5234 Invalid itinerary flight arrival date
5235 Invalid itinerary flight arrival time
5236 Invalid passenger redress number
5237 Invalid known traveller number
5239 Type of flight must be INT, DOM or OVR
5240 Invalid data verification flag
5241 Invalid gate pass validity date
5242 Gate pass validity date outside allowable range
5243 Invalid request sequence number
5244 Invalid document type for gate pass request
5245 Too many gate pass requests in message
5246 Invalid message content
5247 Flight is not an international flight
5248 Domestic flight not in airline schedules
5249 Airports not in same country
5250 Overflight ports not valid for international flight
5251 Country specified not valid for overflight

Page 175
5252 Expected flight not international flight

5253 Country requiring manifest not valid for flight
5254 Country providing status not valid for flight
5255 Airport and country for gate pass not consistent
5256 Transaction not required by any APP country
5257 Invalid action code
5258 Airline not certified for unscheduled flights
5259 Invalid characters in input data
5260 More than five countries in transaction
5261 Domestic flight origin invalid
5262 Domestic flight destination invalid
5263 Overflight segment origin invalid
5264 Overflight segment destination invalid
5265 Overflight flight number not provided or invalid format
5266 Overflight segment departure date invalid
5267 Overflight segment departure date outside allowable range
5268 Invalid additional address country code
5269 Cannot close more than one flight segment
5501 Function code required
5502 Function code invalid
5503 Flight already open for this location
5504 Flight not open for this location
5505 No matching open flights for this location
5506 Flight number required
5507 Invalid flight number format
5508 Departure date required
5509 Invalid departure date
5510 Departure date outside allowable range
5511 Board point airport code required
5512 Board point airport invalid
5513 Off point airport code required
5514 Off point airport invalid
5515 Already at top of list
5516 Already at bottom of list
5517 Invalid item selection string
5518 Selected item not on list
5519 No open flights. Open or specify flight.
5520 More than one open flight. Provide more details.
5521 More than one matching flight. Provide more details.
5522 No matching flights
5523 Not authorised to access APP System
5524 Document information not supplied
5525 Mandatory data groups not present in message
5526 User Id required

Page 176
5527 Invalid check-in flight number format

5528 International flight number not provided or format invalid
5529 International flight origin invalid
5530 International flight destination invalid
5531 International flight departure date invalid
5532 International flight departure date outside allowable range
5533 Expected port code invalid
5535 Invalid expected flight number format
5536 Expected flight not in schedules
5537 Expected flight date invalid
5538 Expected flight date outside allowable range
5539 Passenger sequence number invalid
5540 Pax or Crew Indicator invalid
5541 Passport check character does not match passport number
5542 Supplementary document type invalid
5543 Supplementary document check character does not match
5544 Invalid Date of Birth
5545 Date of Birth outside allowable range
5546 Invalid Sex
5547 Country of birth invalid
5548 Holder-endorsee flag invalid
5549 Both airports in same country
5550 Countries not participating in APP System
5551 Check-in location not authorised to process transaction
5552 Flight not in airline schedules
5557 Trans-border date invalid
5558 Trans-border port code invalid
5560 Document type invalid
5563 No overrides are valid in APP at this time
5564 Only passports are valid for APP at this time
5565 APP not required for transfers at this time
5566 APP not required for Document Types ‘O’ or ‘N’ at this time
5567 Countries can only process document type ‘P’
5568 Inconsistent requirements for persons in message
5569 Participating countries cannot process these transactions
5571 Given names contain invalid characters
5572 Issuing state invalid
5573 Document expiry date invalid
5574 Transfer at origin flag invalid
5575 Transfer at destination flag invalid
5576 PNR source invalid
5577 Access to APP System via on-line is not available at present
5578 No expected movement to cancel
5579 Data capture not required at this time

Page 177
5580 Override codes and countries inconsistent with passenger status

5581 Handle multiple response flag invalid
5582 Message version not supported
5583 Scheduled-unscheduled flight flag invalid
5584 Valid international flight time required
5585 Valid international flight arrival date required
5586 Valid international flight arrival time required
5587 Expected flight time invalid
5588 Trans-border flight time invalid
5589 Override code or country invalid
5590 Expected passenger identifier invalid
5591 Valid issuing state required
5592 PNR record locator required if PNR source given
5593 International flight not in airline schedules
5594 Country not configured to provide data requested
5595 Country not on international flight
5596 Page reference required
5597 Invalid page reference
5600 Effective date required
5601 Invalid effective date
5602 Effective date outside allowable range
5603 Discontinue date required
5604 Invalid discontinue date
5605 Discontinue date outside allowable range
5606 Invalid frequency
5607 Origin airport code required
5608 Origin airport invalid
5609 Departure time required
5610 Departure time invalid
5611 Arrival time required
5612 Arrival time invalid
5613 Arrival airport code required
5614 Arrival airport invalid
5615 Flight Schedule already loaded
5616 PNR record locator invalid
5617 Slash appears after the Expiry Date field, but should not
5618 Slash appears after the Off Point field, but should not
5619 PNR record locator must be blank if PNR source is blank
5620 Trans-border port country not consistent with int flight
5621 Too many passenger data groups in message
5622 Expected Flight not within origin or destination country
5623 Expected Flight not consistent with International Flight
5624 Invalid Flight Type
5625 Matching flight schedule not found

Page 178
5626 Carrier code required

5627 Invalid carrier code format
5628 No schedules found for carrier.
5629 New schedule inconsistent with existing schedule
5650 Message does not contain valid manifest request
5651 Country not origin or next country in which flight lands
5652 Passenger manifest requirement invalid
5653 Crew manifest requirement invalid
5654 Country does not require manifests of the specified type
5655 Specified flight is not international flight
5656 Country does not require manifests
5657 Airline not authorised to use message version
5658 Invalid field count
5659 Screen version not supported
5660 Screen does not contain valid manifest request
Notes on GG Error Codes:

These are all errors which may be passed back to the airline in CIRS, CICC, CIMA, CIMS,
CIUR or CIGS messages.
The airline system should display the code to the user.
Depending on the nature of the error the user may retry the transaction, and if the error
remains, it should be reported to the SITA Help Desk.
Table 38 - GG Error Codes

Page 179
B.2 AP ERROR CODES

The table below (Table 39) contains error codes originating from the Application Processors
of the participating countries. The tables include all messages used by these systems, for
both ETA and APP processes. New error codes are highlighted in blue italics.
Error Description
Code
6000 Validation error – unknown field
6001 Invalid family name format.
6002 Given names format invalid.
6003 Invalid nationality code.
6004 Invalid sex code
6005 Invalid visa type
6006 Invalid middle name
6007 Invalid airline code
6009 Invalid expiry date
6010 Invalid country code
6013 Invalid evidence number
6015 Invalid date of birth
6016 Date of birth outside allowable range
6017 Expiry date outside allowable range
6018 Invalid arrival date
6019 Arrival date outside allowable range.
6020 Invalid country code for country of birth.
6022 ETA not implemented for airline.
6029 Maximum number of dependents exceeded
6033 Invalid passport number format.
6036 Invalid scroll direction.
6037 Invalid scroll hours.
6039 Invalid board airport code
6040 Valid credit card holder name required
6041 Valid credit card expiry date required
6042 Valid credit card number required
6043 Currently in Australia. Ineligible to apply
6045 Invalid movement type code. Must either be ‘ST’ or ‘IT’
6046 Check-in port invalid.
6047 Check-in flight required.
6048 Check-in date invalid.
6049 Check-in time invalid.
6050 Trans-border port not a valid airport code.
6051 Trans-border flight not given.
6052 Trans-border date invalid.
6053 Trans-border time invalid.
6054 Expected port not a valid airport code.
6055 Expected flight required.

Page 180
6056 Expected date invalid.

6057 Expected time invalid.
6058 Passenger sequence number required.
6059 Pax/Crew indicator invalid. Must either be ‘P’, ‘C’ or ‘X’ only.
6060 Expected direction invalid. Must either be ‘I’, ‘O’ or ‘T’ only.
6061 Supplementary document type invalid.
6062 Travel document type invalid.
6063 Endorsement code invalid. Must either be ‘ ‘ (a space) or ‘S’.
6064 Neither travel nor supplementary document information was sent.
6065 Invalid multiple response flag
6066 Invalid Print Arrival/Departure Card flag
6067 Invalid User Id
6068 Expected Passenger ID is null
6069 Expected Passenger ID is not numeric
6070 Expected Passenger ID is not unique
6071 Invalid transaction source flag
6072 Invalid departure port
6073 Invalid departure flight
6074 Invalid departure date
6075 Invalid departure time
6076 Invalid issuing state code
6077 Invalid transfer flag
6078 Invalid override flag
6079 Invalid international flight board point
6080 Invalid international flight off point
6081 Invalid message version
6082 Override code supplied not valid in these circumstances
6083 Invalid travel document number and type combination
6084 Invalid country of birth code used
6085 Invalid crew id
6086 Invalid crew rating
6087 Invalid issuing state
6088 Invalid date of issue
6089 Invalid issuing authority
6090 Date of issue outside allowable range
6091 Issuing state required for document type Other
6092 Override not authorised
6093 Invalid domestic departure port
6094 Invalid domestic service number
6095 Invalid domestic departure date
6096 Invalid domestic departure time
6097 Invalid domestic arrival port
6098 Invalid domestic arrival date
6099 Invalid domestic arrival time

Page 181
6100 Expired card

6101 Invalid card number
6102 EFT currently unavailable. Try again later
6103 Credit card payment not authorised
6104 Invalid selection for additional citizenship
6105 Required if other citizenship held
6106 Must be blank if no other citizenship held
6107 Invalid citizenship country code
6108 At least one address line is required
6109 Address contains invalid characters
6110 Invalid telephone country code
6111 Incomplete home telephone number
6112 Invalid telephone area code
6113 Invalid telephone number
6114 Incomplete business telephone number
6115 Incomplete mobile telephone number
6116 Email address contains invalid characters
6117 Email address format invalid
6118 At least one telephone number is required
6119 Nationality or citizenship codes repeated
6200 Invalid In-Country 1 port code
6201 Invalid In-Country 1 date
6202 Invalid In-Country 1 time
6215 Invalid Pax Manifest flag
6216 Invalid Crew Manifest flag
6217 Inbound - Trans-border and In-Country 1 details do not match
6218 Manifest not found
6219 Outbound - Trans-border and last In-Country details do not match
6220 Invalid Flight Origin Port Code
6221 Foreign port not a valid airport code
6222 Foreign date invalid
6223 Foreign time invalid

Page 182
6224 Invalid Passenger Redress Number

6225 Invalid PNR Locator
6226 Invalid PNR Source
6227 Invalid Passenger Reference
6228 Invalid Known Traveller Number
6229 Invalid Page Reference
6230 Selected Manifest Request Option not supported
6231 No movements found for this flight
6232 Invalid Last Foreign Port code
6233 Invalid Last Foreign Country code
6234 Invalid Flight Segment
6235 Invalid eTicket Number
6250 Active Check-in transaction already exists for this document
6300 Internal KIS Server Error
6400 No valid status for passenger
6888 AP Access Denied
6900 System maintenance in progress. Please try again later.
6901 Message Type 1, Subtype 2. Agency cannot reverse an application it did not make.
6910 Invalid message format. Error code 2 will be the field number in error.
6920 Unknown AP error – Error number not known.
6921 Invalid Passenger Address City
6922 Invalid Passenger Address Postal Code
6923 Invalid Passenger Address State
6924 Invalid Passenger Address Street
6930 Invalid country of residence
6931 Invalid country of issuance
6932 Invalid additional travel document type
6933 Invalid additional travel document expiry date
6934 Invalid passenger itinerary
6941 Invalid document issue date
6942 Invalid additional travel document number
6943 Invalid additional travel document issuing country
6944 Invalid additional travel document issue date
6970 Nationality ineligible for ETA
6971 Nationality ineligible for ETA Type of Travel
6972 Sea crew may not apply for CTA
6973 Sea crew already holds MCV
6975 Nationality ineligible for CTA
6978 System error with alert check.
6979 No response from government system. Please try again later.
6980 Duplicate Message ID.
6981 Unknown Message Type/Sub-type.
6982 Message ID active. Need to use previous logical transaction Message ID.
6983 Invalid Message ID. Need to use previous logical transaction Message Id.

Page 183
6984 System error with alert check.

6985 Duplicate Message ID. Message ID has been used by another User.
6986 Not an ETA application
6987 No History or scrolling outside range
6988 Too many pax in transaction
6989 History details – no corresponding ETA
6990 Arrival date outside range for visa class
6991 Passport expires before intended arrival date
6992 Credit card transaction reversal error
6993 Message Type 1, Subtype 2. Credit card manager error
6995 Message Type 2, Subtype 3. Application does not require payment
6997 Message Type 2, Subtype 2. Cannot grant ETA for this application
6998 AP Error: PRO*C Failed.
6999 AP Error: PL-SQL Failed.
Notes on AP Error Codes:

These are all errors which may be passed back to the airline in CIRS, CICC, CIMA, CIMS,
CIUR or CIGS messages.
The airline system should display the code to the user.
Depending on the nature of the error the user may retry the transaction, and if the error
remains, it should be reported to the SITA Service Desk.
Error code 6888 is used internally on the AP and is not returned to the GG.
Table 39 - AP Error Codes

Page 184
C. MANUAL MAINTENANCE OF FLIGHT

SCHEDULES
C.1 PURPOSE
This is a special facility for the APP System only. An airline can add unscheduled flights to
the airline schedules held on the APP Government Gateway using a command line interface.
C.2 SECURITY ACCESS

Airlines must be enabled to use this facility.
C.3 PROCEDURES
There are three procedures: display an existing flight schedule, load a new flight schedule
and delete a flight schedule.
Display a Flight Schedule
Command format
TIETAYT D/{flight number} [INPUT]
Example input
TIETAYT D/AO7913 [INPUT]
Key to example
TIETAYT Name of the function
D Required option (D for Display)
A07913 Flight Number
Example output
SCHEDULE FOR AO7913 / QF0201 J MANUAL LOAD
1. EFF 10/27/16-10/25/17 FREQ. 1234567
FROM TO DEPT. ARR.
CNS AU KIX JP 1230 1915
**** END OF SCHEDULE ****
Note: Flight AO7913 in the example output is a code share flight of operating flight QF0201.
J indicates that this flight is a passenger flight, while MANUAL LOAD indicates that the flight
has been loaded using the TIETAYT function rather than from the OAG schedules.

Page 185
Load a Flight Schedule
Command format
TIETAYT A/{flight no}[/{flight type}]/{effective date}/{discontinue date}/
{frequency}/{origin port}/{local departure time}/{local arrival time}+1/
{arrival port 1}/{local departure time}+1/{local arrival time}+1/
{arrival port 2} [INPUT]
{flight type} is an optional field. If it is not given, the associated delimiter must not be
included. Possible values are: J = Passenger, F= Cargo, M=Mail only.
Example input
TIETAYT A/SQ888/J/01JUN16/30OCT16/13567/
LAX/1235/1047+1/SYD/
1115+1/1305+1/MEL [INPUT]
Key to example
TIETAYT Name of the function 1235 The local departure time from the origin
port
A The required option (A for Add) 1047 The local arrival time at the next port
SQ888 The flight to be added +1 The date variation, if any (for a time)
J Type of flight - passenger SYD The first arrival port
01JUN16 The effective date 1115 The local departure time from this port
30OCT16 The discontinue date 1305 The local arrival time at the next port
13567 The frequency (1=Monday, 7=Sunday, MEL The second arrival port
etc)
LAX The origin port
Notes on Usage
1. The flight type is optional. If not given, it defaults to Passenger.
2. When a command is longer than a single input line on the screen,

continuation is indicated by ending the input line after the slash (/) at the end
of a data field and commencing the subsequent input line with a hyphen (-).
For example:
TIETAYT A/SQ888/J/01JUN16/30OCT16/13567/LAX/1235/1047+1/SYD/
-1115+1/1305+1/MEL

Page 186
3. Any number of intermediate ports can be provided for a flight, but most
unscheduled international flights will have only origin and destination ports.
4. The date variation element is required only if the date differs from the date of
departure from the origin port. The date variation element can be either “+” or
“*” to indicate the following day or “-“ to indicate the previous day.
5. Once a flight schedule is manually loaded, the information is used until the
flight discontinue date has been reached or the flight has been marked as
deleted.
6. A manually loaded flight will always override data from the OAG.
7. An airline can only load and display flights which are operated by itself or its
code share partners.
Delete a Flight Schedule
Command format
TIETAYT X/{flight no}/{effective date}/{discontinue date}/{frequency}
[INPUT]
Example input
TIETAYT X/SQ888/01JUN16/30OCT016/13567
[INPUT]
Key to example
TIETAYT Name of the function
X The required option (X for Delete)
SQ888 The flight to be deleted
01JUN16 The effective date
30OCT16 The discontinue date
13567 The frequency (1=Monday, 7=Sunday, etc)

Page 187
D. GUIDELINES FOR IMPLEMENTING INTEGRATED

APP
D.1 GENERAL
1. The implementation approach used for APP is one that airlines are familiar
with. See Section D.9 below for a diagram which shows an overview of this
process.
2. SITA assigns an Airline Engagement Manager as a single point of contact to

coordinate an airline’s implementation of APP.
3. The SITA Airline Engagement Manager coordinates a team of technical staff

to assist with the implementation.
4. The SITA Airline Engagement Manager coordinates all of the necessary

communications and systems support required by the airline during the
communications interface connection and application testing phases.
5. The SITA Airline Engagement Manager maintains regular contact with the
airline to monitor the development, connection and testing phases.
6. A test system infrastructure is used. This provides a fully functional duplicate

of the production system.
7. Airlines are able to conduct unlimited testing and are able to request
assistance via email at any time. The APP support team responds to these
enquiries within a maximum of one working day.
8. The test system provides sufficient capacity for concurrent testing by all
participating airlines. Airlines can access both test and production systems
via the same communications link, eliminating the need for any unnecessary
hardware and expense when the airline switches over to production.
D.2 COMMUNICATIONS LINKS

1. The airline’s host system must have access to a SITA communications link
before it can communicate with the APP System. The airline must implement
SITA’s “IATA Host-to-Host (HTH) Protocol” on its APP link.
Note on APP and ETAS
If an airline is currently ETA-capable and will be accessing APP via the
same host communications environment, the same SITA link can be used
for both ETAS and APP access. There is therefore no need for any
duplication of communications links.
2. If the airline needs to install a new SITA circuit for APP access, the SITA
Airline Engagement Manager will arrange for a SITA representative to contact
the airline to assist with this process. The SITA representative (Account
Manager) will generally be located in the same country as the requesting
airline and will be familiar with the ordering process and any local

Page 188
requirements. The SITA Airline Engagement Manager will forward a copy of

the HTH Protocol Specification to the airline’s technical representative on
request.
3. The SITA Account Manager will consult with the airline’s technical
representative to determine what connection attributes are required eg.
physical interface, protocol, bandwidth, site details and required timeframe.
The SITA Account Manager will submit the circuit connection request and will
regularly monitor the installation progress to ensure timely delivery.
4. The SITA Airline Engagement Manager will be advised that a new airline is
implementing APP. For new circuit connections the SITA Airline Engagement
Manager will forward the Airline/GG interface parameter questionnaire and the
SITA Airline Agreement document to the airline’s technical representative.
Both documents need to be completed and returned to the SITA Airline
Engagement Manager prior to APP Test System access being granted. (See
section D.7 below for a sample of this).
5. When the airline has returned the completed questionnaire and Airline
Agreement to SITA, SITA will provide APP Test System access to that airline
and will advise the airline when this access is available.
The SITA Airline Engagement Manager will also provide to the airline contact
details of SITA technical staff who can assist with network and APP
application connection issues. From this point the airline may commence
testing to the Government Gateway (GG).
D.3 DEVELOPMENT PHASE

1. The government agrees a schedule with airlines, and then provides the SITA
Airline Engagement Manager with the rollout schedule.
2. The SITA Airline Engagement Manager contacts each airline representative to

discuss the development plan timelines, provide specifications and answer
any technical issues that the airlines may have.
3. During the development phase the SITA Airline Engagement Manager makes
regular email contact with the airlines to monitor project progress and to offer
assistance if required.
D.4 SYSTEM TESTING PHASE

1. The airline is notified of the procedures involved in satisfying government
requirements for acceptance testing.
The SITA Airline Engagement Manager will forward to the airline’s technical
representative the document Advance Passenger Processing System Test
Cases. This document is designed to facilitate airline testing, although unit
and integrated testing by the airline need not be limited to the biodata
contained in this document. Note that each APP country will have a separate
set of test cases.

Page 189
2. The same test database can be a perpetual database for use by all
participating airlines before and after cutover. The contents of the database
are such that it tests and triggers conditions and exceptions against the
government database and alert lists.
3. When an airline is ready to commence testing its APP application the SITA
Implementation Manager arranges for the necessary entries to be made in the
Airline Access Tables on the test system. (An airline cannot access the APP
System without the correct parameters being loaded in the Access Tables).
4. The airline can conduct unlimited testing on a 24x7 basis. All problems
encountered or queries about APP functionality during testing should be
forwarded to the SITA Implementation Manager for resolution.
5. When test transactions have been sent, the SITA Airline Engagement
Manager uses database tools to verify that the airline transactions conform to
the requirements of the APP System specification, in particular the Layer 7
addressing.
D.5 ACCEPTANCE TESTING PHASE

1. Prior to the acceptance test phase it is recommended that the airline activate
a network layer connection from their production environment. This will
identify any production network connectivity issues that can be resolved well
before cutover to production.
2. When an airline has tested the application satisfactorily it contacts the SITA
Airline Engagement Manager and requests permission to cutover to
production.
3. The SITA Airline Engagement Manager then arranges with the government a
suitable time when all parties are available to conduct the end-to-end
acceptance test.
4. During the acceptance test the airline is asked to process via APP check-in
each passenger listed in the test database. Expected Movement Records
generated as a result of airline acceptance testing are then passed to the
government for validation against the test data in the government test system.
5. Once the airline has completed the APP acceptance test, the authorised
government representative will notify the SITA Airline Engagement Manager
within 48 hours whether the test has been successful. When a formal signoff
has been received from the government representative, the SITA Airline
Engagement Manager will authorise SITA to provide APP Production System
access for that airline. The SITA Airline Engagement Manager will advise the
airline when Production System access has been granted.
6. The airline may elect, with the prior approval of the government, to conduct
limited and controlled testing of APP transactions on the Production System
prior to the airline “going live”.

Page 190
Approval for this testing will be requested through the SITA Airline
Engagement Manager. Airlines that conduct this type of testing must use real
passenger biodata, not fictitious or offensive biodata. Following the testing,
APP movement cancellation transactions should be processed for all
passengers processed during the test.
7. All issues resulting from the acceptance test must be resolved and a sign-off
received by the government representatives and the SITA Airline Engagement
Manager before the airline can cutover to production.
D.6 CUTOVER TO PRODUCTION

1. Once government approval has been received for an airline to move to
production status, and the airline is ready for the production rollout of APP,
they will advise the SITA Airline Engagement Manager of their planned
cutover date and will provide a rollout schedule one week prior to cutover.
The rollout schedule will detail the airline’s APP flight schedules and rollout
dates.
2. The SITA Airline Engagement Manager arranges for the airline’s parameters
to be loaded in the production Government Gateway access tables.
3. Migrating from test to production is a simple process. The airline makes a

simple parameter change in the airline’s Host-to-Host message header, and
this allows terminal traffic to switch from test to production.
4. The SITA Airline Engagement Manager monitors the airline’s cutover

progress, providing regular status updates to the government.
5. All post-cutover APP issues determined to be non-airline related should be

escalated to the SITA Airline Engagement Manager for investigation.

Page 191
D.7 SITA HTH QUESTIONNAIRE FOR NEW CONNECTIONS

The following are the relevant airline requirements for use of the SITA - IATA Host to Host
Protocol (HTH) for APP (and also for ETAS).
Airline Host System Connection Parameter – Questionnaire

1 Which character does the user want to use for the TABSET (Leave blank for none)
2 Is the User's system capable of handling question marks “?” (Yes/No)
3 Is the User's system capable of handling lower case alpha (Yes/No)
characters
4 Should we include the Start Of Entry (SOE) in output messages to (Yes/No)
your system
We would like to brief you on what we expect from your system at the Host-to-Host
communications level. In order to match all the technical and functional requirements of the
project the following is required:
1. The Host-to-Host communication with ATLDP should be based on the

standard document named "Specifications for the Implementation of the IATA
Host-to-Host Protocol".
2. Your Airline should be configured on the Host-to-Host link with a specific

session on the ATLDP Development System. In order to coordinate this,
please contact ATLDC.ENGINEERING.SUPPORT.TEAM@SITA.AERO
3. In data received from your host we are specifically looking for the following
fields included in the Layer 7 portion of the HTH message header:
Airline Code Your specific 2 letter IATA code

City Code The IATA city code of the location where the airline terminal originated the
transaction.
Screen Size Minimum number of lines & characters per line of the terminal originating the
transaction.
IATA Number The IATA ID of the inquiring terminal site. For a Travel agent this should be
the IATA Number of that agency. For an airline system, a user location
reference must be supplied uniquely identifying the office generating the
transaction. This may be specific to an airline system.
Country Code IATA code of the Country where the inquiring terminal is located.

Page 192
D.8 CONTACT DETAILS

SITA Service Desk
SITA Service Desk Email: ssd.amm.gsl@sita.aero
Telephone: +1 514 282 6128
Australia APP Coordinator (Department of Home Affairs)

APP Website Email: appwebsite@border.gov.au
New Zealand APP Coordinator (INZ)

Mr Lee Wilson Email: lee.wilson@dol.govt.nz
Telephone: +64 9 277 1255
Facsimile: +64 9 256 1333
Bahrain APP Coordinator (GDNPR)

Mr Thabit Al-Sherooqi Email: alshrooqit@gdnpr.gov.bh
Telephone: +973 1753 6143
US APP Coordinator (SITA)

Mr Simon Glenister Email: simon.glenister@sita.aero
Telephone: +441483 521295
UK APP Coordinator (SITA)

Telephone: +441483 521295
South Africa APP Coordinator (SITA)

Mr Tarek Rajab Email: tarek.rajab@sita.aero
Telephone: +965 2241 2547
Qatar APP Coordinator (SITA)

Mr Tarek Rajab Email: tarek.rajab@sita.aero
Telephone: +965 2241 2547
Korea APP Coordinator (SITA)

Telephone: +441483 521295

Page 193
Saudi Arabia APP Coordinator (SITA)

Mr Ihab Hassib Email: ihab.hassib@sita.aero
Telephone: +971 4 315 1340
UAE APP Coordinator (SITA)

Mr Ihab Hassib Email: ihab.hassib@sita.aero
Telephone: +971 4 315 1340
Canadian API/PNR Programme Co-ordinator

API/PNR Programme Email: api-pnr@cbsa-asfc.gc.ca
Call Toll Free: 1.866.427.4767 from 08:00
to 16:00 ET weekdays.
Call After Hours: 1.613.219.8452 from
16:00 to 8:00 ET weekdays, and 24 hours
on weekends and Canadian holidays.

Page 194
D.9 OVERVIEW OF THE IMPLEMENTATION PROCESS

The diagram below (Figure 22) provides a summary of the implementation process.
APP SYSTEM
AIRLINE IMPLEMENTATION PROCESS
Decision
Airline decides to Government SITA provides

implement APP, and advises SITA of Interface
START
agrees timetable with the airline's specification to
government. rollout schedule. airline.
Comms
Links
SITA assists Airline has
airline with NO necessary HTH
comms links network services?
YES
Development NO
& Testing
Airline carries out
Airline is ready for
development (ie.
system testing?
changes to DCS)
YES
System NO
Testing
SITA provides
Airline undertakes Airline is ready for
airline with
testing with acceptance
access to test
support from SITA. testing?
system.
YES
Acceptance NO
Testing
Airline undertakes SITA provides
Acceptance sign-
acceptance testing acceptance testing
off by Government
with support from specification to
and SITA?
SITA. airline.
YES
Cutover
Airline changes
SITA provides airline message header
with access to parameter (switching
production system. transactions to
production system).
Production
Airline carries out
live APP
END
transactions for
flights.
Figure 22 - Implementation Process for Integrated APP

Page 195
E. PASSENGER DATA REQUIREMENTS

The passenger data provided to a government by APP can come from two sources:
• from the government system itself (if a record is already held on the
passenger); or
• from the airline (by capturing all the required data at check-in, or earlier).
Governments differ in what passenger data they require.
The following table lists the data fields in the PRQ and PAD data groups of the CIRQ
message and shows which fields must be provided to the government systems of the
countries participating in APP. Rows where the requirements are different between countries
are shaded.
Note that the presence of the data items in this table does not imply that the airlines must
capture the data items at check-in. The rules for APP processing are:
1. If the passenger data provided in the check-in enquiry for a passenger can be
matched with data in the government database, the government data is used
(after being checked for completeness).
2. If the passenger data cannot be found in the government database, then it

must be captured by the airline according to the rules in Table 40 below.

Page 196
Data Data Item Field Mandatory (M) /Optional (O) /Conditional (C) for …
Group in
Ref. MRZ?
AU NZ BH SA US 5 UK ZA QA KR AE TW OM MM TH LA SG
PRQ
4 Pax/Crew Indicator No M M M M M M M M M M M M M M M M
5 Passport Country Yes1 M M M M M M M M M M M M M M M M
Code (Nationality)
6 Issuing State Yes1 C8 C2 C2 C2 M C2 C2 C2 M C2 C2 C2 C2 C2 C2 C2
7 Passport Yes1 C3 C3 C3 C3 C3 C3 C3 C3 C3 C3 C3 C3 C3 C3 C3 C3
ID/Document ID
8 Passport/Document Yes1 O O O O O O O O O O O O O O O O
Check Character
9 Travel Document No M M M M M M M M M M M M M M M M
Type
11 Travel Document Yes1 O C3 O O M O O M12 M O O O O O O O
Expiry Date
13 Supplementary Doc No [Not currently used]
Type
ID
Check Character
16 Family Name Yes1 M M M M M M M M M M M M M M M M
17 Given Names Yes1 M4 M4 M4 M4 M4 M4 M4 M4 M4 M4 M4 M4 M4 M4 M4 M4
18 Date of Birth Yes1 M M M M M M M M M M M M M M M M
19 Sex Yes1 M M M M M M M M M M M M M M M M
20 Country of Birth Code No C8 O O O O O O O O O O O O O O O
21 Holder/Endorsee No O O O O O O O O O O O O O O O O

Group in
Ref. MRZ?
25 PNR Source No O M O O O9 O O O O9 O O O O O O O
26 PNR Locator No O M O O O9 M O O O9 O O O O O O O
27 Country of Residence No O O O O M O O O M O O O O O O O
30 Passenger Reference No O O O O M7 M O O M7 O O O O O O O
32 Home Address: No O O O O C11 O O O C11 O O O O O O O
Number & Street
33 Home Address: City No O O O O C11 O O O C11 O O O O O O O
34 Home Address: State No O O O O C11 O O O C11 O O O O O O O
35 Home Address: No O O O O C11 O O O C11 O O O O O O O
Postal Code
36 Place of Birth: City No O O O O C11 O O O C11 O O O O O O O
37 Place of Birth: State No O O O O C11 O O O C11 O O O O O O O
PAD
5 Additional Travel No O O O O C6 O O O C6 O O O O O O O
Doc: Document Type
Doc: Document
Number
Doc: Country of
Issuance
Doc: Expiration Date
11 Address: No O O O O C6 O O O C6 O O O O O O O
Number and Street
12 Address: City No O O O O C6 O O O C6 O O O O O O O
13 Address: State No O O O O C6 O O O C6 O O O O O O O

Group in
Ref. MRZ?
14 Address: Postal Code No O O O O C6 O O O C6 O O O O O O O
15 Passenger Redress No O O O O C6 O O O C6 O O O O O O O
Number
16 Known Traveller No O O O O C6 O O O C6 O O O O O O O
Number
Notes:
1
If a passport reader is being used, it is recommended that all these data items be supplied in the CIRQ message.
2
Required only when the Travel Document Type is “Other”.
3
Required if passenger holds travel document and data item is on document.
4
Mandatory. If passenger does not have Given Names, must be set to hyphen (-).
5
Based on requirements for APIS reporting in UN/EDIFACT manifests.
6
Required under some circumstances.
7
Required for AQQ for the USA. This field corresponds to the Passenger Name Record locator (PNR) and Sequence Number (SEQ)
specified in the AQQ message Carrier – Clear Passenger Request.
8
Required if passenger does not have a visa in effect and is not known to Australia but can be permitted to board under existing
government regulations.
9
Required if known. Either both PNR Source and PNR Locator must be provided or both must be blank.
10
Not required but will be used if provided.
11
Required for AQQ for the USA for crew only. Not required for passengers.
Table 40 - Passenger Data Requirements

F. DOCUMENT CONTROL
This information is maintained to summarise changes to this document between released controlled
versions of the document, and to retain a history of significant changes during the development and
approval process.
Note that this table has been truncated to only include changes from v6.80 of this document. If a history
prior to this version is required, please contact the person named in section 1.5.
Ver Date Section Amended Description of significant changes, and/or

affected by significance of new version
6.80 3 Aug 16 All JK Minor edits throughout for clarity and consistency.
App E Changed data requirements for NZ to include TD Expiry
Date as mandatory if available.
Added new countries to Appendix E.
4.2 Created version 27 of CIRQ message to include
Document Issue Date.
Clarification of acceptable data for additional travel
2.1.5
document types.
6.81 6 Oct 16 App A JK Appendix A:
Added new codes for USA
6.82 21 Dec 16 App A JK Appendix A:
App D Added new code for UAE. Corrected some USA codes.
Appendix D:
Updated contact details for API Coordinator Canada.
6.83 26 Sep 17 4.2 JK Section 4.2:
5.1.6.1 Created version 28 of the CIRQ message to include
App A Country in the Address fields for Additional Passenger
Data.
App B
Section 5.1.6.1:
Added note clarifying the use of transfer messages.
Appendix A:
Updated valid Check-in message responses for
Thailand.
Appendix B:
Additional error codes for invalid additional address
country and invalid manifest requests.

Page 200
Ver Date Section Amended Description of significant changes, and/or

affected by significance of new version
6.84 Sep 18 2.1.5 JK Section 2.1.5
4.6 Added note regarding timezones to use for flight dates
App A and times.
App E Clarification on flight dates allowed for processing.
Section 4.6:
Created version 29 of the CIMR message, allowing for
submission of manifest requests for unscheduled
flights.
Appendix A:
Added codes for Laos
Appendix E:
Made Passenger Reference field mandatory for the UK
7.0 Oct 18 1.2 JK Section 1.2:
1.4 Added references to Web Services messaging
4.2 functionality.
4.4 Updated Note section to clarify message versions and
usage.
App A
Section 1.4:
App E
Added document reference to Web Services Message
Specification.
Section 4.2 and 4.4:
Added B = Boarding Gate Check as an option for the
Transaction Type Qualifier field.
Appendices A and E:
Added codes and data requirements for Singapore.
7.1 May 19 4.2 JK Section 4.2:
App B New message version including eTicket number.
Appendix B:
New error code for invalid eTicket number.

Page 201

Airline-GG Interface Specification-V7.1 PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Airline-GG Interface Specification-V7.1 PDF

Încărcat de

Drepturi de autor:

Formate disponibile

iBorders Advance Passenger

1.1 Purpose of this Document ............................................................................................. 9

2.1 Message Type: Check-in Request (CIRQ).................................................................. 12

2.2 Message Type: Check-in Response (CIRS) ............................................................... 20

2.3 Message Type: Movement Cancellation (CICX) ......................................................... 29

2.4 Message Type: Movement Cancellation Confirmation (CICC) ................................... 32

2.5 Message Type: Manifest Request (CIMR) .................................................................. 37

2.6 Message Type: Manifest Request Acknowledgement (CIMA) .................................... 41

Commercial-in-Confidence V7.1 (May 2019)

2.6.1 Purpose ............................................................................................................................. 41

2.7 Message Type: Manifest Enquiry (CIME) ................................................................... 43

2.8 Message Type: Manifest Status (CIMS) ..................................................................... 45

2.9 Message Type: Passenger Status Request (CICO) ................................................... 47

2.10 Message Type: Passenger Status Response (CIUR) ............................................. 50

2.11 Message Type: Gate Pass Request (CIGR) ........................................................... 52

2.12 Message Type: Gate Pass Response (CIGS) ......................................................... 53

3.1 Check-in Request (Simple) ......................................................................................... 55

Commercial-in-Confidence V7.1 (May 2019)

3.11 Passenger Status Request ...................................................................................... 59

4.1 Overall Message Structure.......................................................................................... 61

4.2 Message Type: Check-in Request (CIRQ).................................................................. 64

5.1 Check-in Examples ................................................................................................... 115

5.2 Movement Cancellation Examples ............................................................................ 134

5.3 Manifest Examples .................................................................................................... 137

5.4 Passenger Status Requests...................................................................................... 139

5.5 Gate Pass ................................................................................................................. 142

Commercial-in-Confidence V7.1 (May 2019)

5.6 Complete Message Sample (including message header)......................................... 143

B.1 GG Error Codes ........................................................................................................ 174

C.1 Purpose ..................................................................................................................... 185

D.1 General ..................................................................................................................... 188

Commercial-in-Confidence V7.1 (May 2019)

Commercial-in-Confidence V7.1 (May 2019)

Table 13 - Rules for Implementing CIME Message .............................................................................. 44

Commercial-in-Confidence V7.1 (May 2019)

The APP (Advance Passenger Processing) System provides a message-based interface

1.2 SCOPE OF THIS DOCUMENT

Commercial-in-Confidence V7.1 (May 2019)

Note on Message Versions:

This document may also be useful for the following users:

1.4 RELATED DOCUMENTS

Commercial-in-Confidence V7.1 (May 2019)

Commercial-in-Confidence V7.1 (May 2019)

2.1 MESSAGE TYPE: CHECK-IN REQUEST (CIRQ)

The message is used under two different circumstances:

Commercial-in-Confidence V7.1 (May 2019)

2.1.2 Message Structure

Check-in Request CIRQ

CHK INT One of these is DOM EXO/EXD PRQ

Figure 1- Overall Structure of CIRQ Message

2.1.3 Message Construction

Commercial-in-Confidence V7.1 (May 2019)

Table 1 - Message Construction for Check-In Request (CIRQ)

2.1.4 Message Processing

Commercial-in-Confidence V7.1 (May 2019)

Note on the number of passengers in the CIRQ message

2.1.5 Recommended Airline Implementation

Commercial-in-Confidence V7.1 (May 2019)

6 If the passenger is an endorsee on a This enables the passenger to be uniquely

Commercial-in-Confidence V7.1 (May 2019)

9 When a passenger is arriving at an airport There are a number of cases where

Commercial-in-Confidence V7.1 (May 2019)

Commercial-in-Confidence V7.1 (May 2019)