Professional Documents
Culture Documents
APP Guideline
APP Guideline
The services and products described in this document are furnished under a contract, agreement or licence.
All information described is confidential and proprietary. The services and products may only be used in
accordance with the terms of the contract, agreement or licence.
No part of this document, or related software, may be reproduced or transmitted in any form or by any means,
electronic or mechanical, including photocopying, recording, or information storage and retrieval systems, for
any purpose, except as permitted or provided for by the contract, agreement or licence, or as is reasonably
required in performing the actions necessary for the agreement, contract or licence, or with the express written
permission of CPS Systems Pty Limited.
Advance Passenger Processing System Airline/CG Interface Specification
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.
TABLE OF CONTENTS
1 INTRODUCTION..................................................................................................11
1.1 PURPOSE OF THIS DOCUMENT ...................................................................................11
1.2 SCOPE OF THIS DOCUMENT .......................................................................................11
1.3 DOCUMENT AUDIENCE .............................................................................................12
1.4 RELATED DOCUMENTS..............................................................................................12
1.5 CONTACTS ................................................................................................................12
2 CONCEPTS AND TERMINOLOGY..................................................................13
2.1 OVERVIEW OF API AND APP ....................................................................................13
2.2 CHARACTERISTICS OF APP .......................................................................................13
2.3 OVERALL APP ARCHITECTURE .................................................................................15
2.4 ROLES OF THE AIRLINE DCS AND THE APP SYSTEM ................................................16
2.5 DATA REQUIREMENTS ..............................................................................................17
2.6 PASSENGER DATA REQUIREMENTS FOR APP ............................................................17
2.7 FLIGHT MODELS .......................................................................................................18
2.7.1 Ports ............................................................................................................. 18
2.7.2 Flights .......................................................................................................... 20
2.8 FLIGHT DATA REQUIREMENTS FOR APP...................................................................20
2.9 TRANSIT PASSENGERS...............................................................................................21
2.10 SPECIAL CIRCUMSTANCES ........................................................................................23
2.10.1 Unscheduled Flights..................................................................................... 23
Definitions ........................................................................................................................... 23
Rules for Handling Unscheduled Flights............................................................................. 23
Alternative Handling for Unscheduled Flights .................................................................... 24
2.10.2 Code Share Flights....................................................................................... 25
Definitions ........................................................................................................................... 25
Rules for Handling Code Share Flights ............................................................................... 25
2.10.3 Data Sharing Between APP Countries ........................................................ 25
3 MESSAGE TYPES ................................................................................................27
3.1 MESSAGE TYPE: CHECK-IN REQUEST (CIRQ) ..........................................................27
3.1.1 Purpose ........................................................................................................ 27
3.1.2 Message Structure........................................................................................ 27
3.1.3 Message Construction.................................................................................. 28
3.1.4 Message Processing ..................................................................................... 28
3.1.5 Recommended Airline Implementation ........................................................ 29
3.2 MESSAGE TYPE: CHECK-IN RESPONSE (CIRS) .........................................................31
3.2.1 Purpose ........................................................................................................ 31
3.2.2 Message Structure........................................................................................ 31
3.2.3 Message Construction.................................................................................. 32
3.2.4 Message Processing ..................................................................................... 32
3.2.5 Recommended Airline Implementation ........................................................ 33
3.3 MESSAGE TYPE: MOVEMENT CANCELLATION (CICX) .............................................36
3.3.1 Purpose ........................................................................................................ 36
List of Figures
FIGURE 1 – OVERALL APP ARCHITECTURE .......................................................................................... 15
FIGURE 2 – APP FLIGHT MODEL (INBOUND) ........................................................................................ 18
FIGURE 3 - APP FLIGHT MODEL (OUTBOUND) ..................................................................................... 19
FIGURE 4 - OVERALL STRUCTURE OF CIRQ MESSAGE ......................................................................... 27
FIGURE 5 - OVERALL STRUCTURE OF CIRS MESSAGE ......................................................................... 31
FIGURE 6 - OVERALL STRUCTURE OF CICX MESSAGE ......................................................................... 36
FIGURE 7 - OVERALL STRUCTURE OF CICC MESSAGE ......................................................................... 38
FIGURE 8 – FLIGHT BA033 (KUL-SYD)............................................................................................... 69
FIGURE 9 – FLIGHT QF016 (BKK-MEL-SYD) ..................................................................................... 75
FIGURE 10 – MULTI-LEG JOURNEY (CHI-LAX-SYD-MEL) ................................................................ 76
FIGURE 11 – MULTI-FLIGHT JOURNEY (BKK-SYD-LAX) ................................................................... 82
FIGURE 12 – TRANSIT ON SINGLE FIGHT (BKK-SYD-LAX) ................................................................ 84
FIGURE 13 – IMPLEMENTATION PROCESS FOR INTEGRATED APP ...................................................... 114
List of Tables
TABLE 1 – PORT DEFINITIONS ............................................................................................................... 19
TABLE 2 – FLIGHT DEFINITIONS ............................................................................................................ 20
TABLE 3 – RULES FOR FLIGHT DATA .................................................................................................... 21
TABLE 4 - RULES FOR HANDLING UNSCHEDULED FLIGHTS ................................................................. 23
TABLE 5 - ALTERNATIVE METHOD OF HANDLING UNSCHEDULED FLIGHTS ........................................ 24
TABLE 6 - RULES FOR HANDLING CODE SHARE FLIGHTS ..................................................................... 25
TABLE 7 – MESSAGE CONSTRUCTION FOR CHECK-IN REQUEST (CIRQ) ............................................. 28
TABLE 8 - RULES FOR IMPLEMENTING CIRQ MESSAGE ....................................................................... 29
TABLE 9 – MESSAGE CONSTRUCTION FOR CHECK-IN RESPONSE (CIRS)............................................. 32
TABLE 10 - RULES FOR IMPLEMENTING CIRS MESSAGE ...................................................................... 35
TABLE 11 – MESSAGE CONSTRUCTION FOR MOVEMENT CANCELLATION (CICX) .............................. 36
TABLE 12 - RULES FOR IMPLEMENTING CICX MESSAGE ..................................................................... 37
TABLE 13 – MESSAGE CONSTRUCTION FOR MOVEMENT CANCELLATION CONFIRMATION (CICC) ... 39
TABLE 14 - RULES FOR IMPLEMENTING CICC MESSAGE ..................................................................... 41
TABLE 15 - RULES FOR IMPLEMENTING LAYER 7 OF A MESSAGE ........................................................ 47
TABLE 16 –LAYER 7 DATA ITEMS IN THE APP MESSAGE..................................................................... 47
TABLE 17 – RULES FOR BODY OF MESSAGE ......................................................................................... 48
TABLE 18 – LAYER 5 ADDRESSES FOR APP MESSAGES ....................................................................... 48
TABLE 19 – MESSAGE LAYOUT FOR CHECK-IN REQUEST (CIRQ)........................................................ 54
TABLE 20 – MESSAGE LAYOUT FOR CHECK-IN RESPONSE (CIRS)....................................................... 59
TABLE 21 – MESSAGE LAYOUT FOR MOVEMENT CANCELLATION (CICX).......................................... 63
TABLE 22 – MESSAGE LAYOUT FOR MOVEMENT CANCELLATION CONFIRMATION (CICC)................ 67
TABLE 23 - CHECK-IN MESSAGE CODES ............................................................................................... 93
TABLE 24 – CG ERROR CODES .............................................................................................................. 99
TABLE 25 – AP ERROR CODES (AU AND NZ)..................................................................................... 102
TABLE 26 – PASSENGER DATA REQUIREMENTS (AU AND NZ) .......................................................... 116
1 Introduction
The changes to the Airline/CG interface embodied in this version of the interface
specification provide for use of APP for countries which allow visa free entry eg. New
Zealand, where APP is expected to be implemented during 2003.
It is strongly advised that an airline integrate APP with its DCS in a way which is generic,
and allows for the participation of multiple countries (with differing regulations and
requirements) in any given passenger transaction.
CPS Systems can provide advice and guidance in this area, and enquiries from airlines are
welcomed.
1.5 Contacts
All comments regarding this document should be directed to:
Person name John Leplaw or Philip Gould
Organisation name CPS Systems Pty. Ltd.
Phone +61-2-9909-3022
Fax +61-2-9953-8083
Email [email protected] or [email protected]
The first major use of API was through the Advance Passenger Information System (APIS)
implemented by the United States Customs Service (USCS). Through this system, airlines
can supply API to the USCS. The information has been limited to data elements related to the
passenger (mainly data in the passenger’s passport) and flight data. It is transmitted to the
USCS in a flight manifest after the flight closes. With APIS, there is no interactive capability
by which USCS can prevent a passenger from boarding a flight.
While the United States has been using the APIS system for the receipt of API data, Australia
implemented an interactive system called Advance Passenger Processing (APP) which, apart
from delivering similar API to that required by APIS, also delivers other significant
advantages in the areas of on-line document and alert checks against government databases
with commensurate boarding directives. This is linked to the Electronic Travel Authority
System (ETAS) that is delivered by the same infrastructure as APP.
The APP System assists airline check-in staff to comply with government requirements when
processing passengers boarding international flights. Compliance may involve checking the
authority of the passenger to board the flight and provision of API to governments.
• Receive flight and passenger bio-data supplied by the check-in agent and determine
whether the passenger may board an international flight
• Immediately return a directive to the check-in agent on the status of the passenger
• Immediately generate expected movement data for governments when passengers are
cleared for boarding
• Cancel a movement when a passenger, who was previously cleared for boarding, fails to
travel.
Related Requirements
In achieving the basic functionality requirements, the APP System is able to:
While the majority of passengers travel using passports as their travel document, some
travellers make use of a variety of other types of document that are accepted by some
countries eg. Certificate of Identity, Refugee Travel Document, United Nations and Red Cross
travel documents, Seaman’s Book, and Military ID.
Different countries will have different requirements with respect to the acceptability of the
various types of travel document.
Categories of Passenger
Crew
The APP System handles processing of transactions for crew as well as passengers. Crew are
classified as operating crew or positioning crew. Government safety inspectors travelling on
aircraft are classified as operating crew.
The key used for identifying passengers as part of APP processing consists of the passport
number (i.e. travel document number), nationality and name.
expected
Country A
movements
Border
Control
System
boarding
boarding RPS
requests
requests, Country A
cancellations Application
Processor
Airline RCS
Departure Communications boarding
Control Gateway directives
System (ATL)
RPS
Airport boarding Country B
check-in directives, boarding Application
agent cancellation requests Processor
acknowledgements
Country B
Border
expected Control
movements System
Each airline carrying out APP is connected (via its DCS) to the CG which operates as a hub,
and each participating government has its border control system(s) connected to the relevant
AP. On the AP is located the relevant government data which is needed to determine a
passenger’s immigration status in that country. This data includes visas, passports, alerts, etc.
In carrying out APP, airlines submit boarding requests to the system for passengers on certain
international flights, and in return they receive boarding directives from the one or more
governments involved. If a positive boarding directive is received for a passenger, and then
for some reason that passenger does not fly, the airline should cancel the APP transaction.
One option with APP is data sharing, whereby governments may agree to provide verified
passenger biodata to another APP participating country when a passenger is travelling
between the two, and only one of the countries already knows about the traveller. (See below,
section 2.10.3 for further detail on this).
The APP System does not provide functionality associated with the airline check-in user
interface. The airline must design and develop this based on its own requirements. However,
the DCS must provide the following:
Passenger This data relates to the passport and biodata for the passenger.
data
Flight This data relates to the international movement being undertaken by the
data passenger. This may be a journey inbound to, outbound from or transiting an
APP-participating country. The flight data may include information on a
series of flights and ports on the international movement.
When the government database does not hold data on a particular passenger, it is possible that
another country along the flight may have the data. If there is a data-sharing agreement in
place between those two governments, then the APP System can supply the data from one
country to the other.
If none of the countries involved holds the required data for a passenger or data sharing
agreements are not in place, and if API is mandatory for one or more of those countries, then
there is no alternative but to have the check-in agent capture the missing data.
Provision is made in the APP System for handling the passenger data set described in
Appendix E. This Appendix indicates whether the data items are mandatory or optional for
the countries currently using the APP System when data is captured for passengers previously
unknown to a government.
2.7.1 Ports
Below in Figure 2 there is an example of the ports and flights for inbound passengers.
Check-in Port
Vancouver
Check-in Flight
Los Angeles
Trans-Border Flight
Trans-Border Port
Sydney
Expected Flight
Melbourne
Expected Port
Below in Figure 3 there is an example of the ports and flights for outbound passengers.
Los Angeles
Trans-Border Flight
Check-in Port
Trans-Border Port
Perth Sydney
Check-in Flight
Expected Flight
Melbourne
Expected Port
Definitions of the ports involved in an international movement are given below in Table 1
based on the specific examples shown in Figure 2 and Figure 3. These examples use
Australia as the APP-participating country.
Port Definition AU AU
inbound view outbound view
Check-in The port at which a passenger commences an international This will be a This will be an
port movement and at which advance passenger information for foreign port Australian port
the passenger is collected. (eg. YVR) (eg. PER)
Trans- The Trans-border Port is defined as: This will be an This will be an
border The first port in a country at which a passenger arrives when Australian port Australian port
port travelling to that country, or (eg. SYD) (eg. SYD)
The last port in a country from which a passenger departs
when travelling from that country.
The passenger need not leave the aircraft or the flight at the
Trans-border Port.
Expected The port at which a passenger will be cleared by Customs This will be an This will be an
port and Immigration for movement into or out of a country. Australian port Australian port
(eg. MEL) (eg. MEL)
2.7.2 Flights
The definitions of the flights involved in an international movement are given in Table 2.
Flight Definition AU AU
inbound view outbound view
Check-in The flight on which a passenger leaves the Check- A flight leaving a A flight from an
flight in Port. This may or may not be an international foreign port Australian port (where
flight. (where the the passenger
passenger embarked)
embarked) (eg. PER-MEL)
(eg. YVR-LAX)
Trans- The flight on which a passenger crosses a A flight from a A flight from an
border country’s border. By definition this is an foreign port to an Australian port to a
flight international flight: Australian port foreign port
For a passenger travelling to Australia, this will be (eg. LAX-SYD) (eg. SYD-LAX)
the flight arriving at the Trans-border Port.
For a passenger travelling from Australia, this will
be the flight departing from the Trans-border Port.
Expected The flight associated with the Expected Port. This A flight arriving at A flight leaving an
flight may or may not be an international flight: an Australian port Australian port (where
For a passenger travelling to Australia, this will be (where the the passenger will
the flight arriving at the Expected Port. passenger will undergo outbound
undergo inbound immigration
For a passenger travelling from Australia, this will immigration processing)
be the flight departing from the Expected Port. processing) (eg. MEL-SYD)
(eg. SYD-MEL)
The basic data provided by the check-in agent or airline system describes the International
Flight (flight, departure date, board point and off point).
The APP System has access to published airline schedules and can expand the International
Flight data provided by the airline to the full data set required for the expected movement
record to be sent to the border authorities.
The airline rules for flight information in the Integrated APP Implementation are as follows:
No Rule Notes
1 Information on the Check-in Flight is optional. This information is very desirable however,
and should be provided where possible.
2 Information on the International Flight is mandatory. See In most cases, the other data required for
the Note on Flight Dates below (following Table 8) for the the expected movement is derived from this
rules on past or future dates. International Flight data by the APP System.
3 For unscheduled International Flights where the Trans- This information is not needed for these
Border port is different from the origin and/or destination of cases:
the International Flight, information on the Trans-Border Scheduled flights.
Flight is mandatory.
Unscheduled flights where Trans-Border
Note that this could apply to both ends of the nternational ports are the same as the origin and/or
movement. destination of the International Flight.
4 If the passenger is not processed at the primary line at the This information is not needed for these
origin or destination of the International Flight, information cases:
on the Expected Flight is mandatory. (This scenario The passenger is processed at the primary
means there is another flight involved in the international line at the origin or destination of the
movement). International Flight
Note that this could apply to both ends of the international
movement.
5 When the International Flight transits an intermediate This can only be done when the flight is a
country between the origin and destination countries, the scheduled flight. Refer to Section 2.10.1 for
APP System determines the Expected Flight and Port and information on handling of unscheduled
the Trans-border Flight and Port for both inbound and flights.
outbound movements for the country.
When a passenger arrives in an APP-participating country on one flight and leaves on the
same aircraft or on another flight, the visa requirements often differ from when the same
passenger is intending to enter the country. The APP System must be able to recognise the
nature of the passenger’s journey so it can determine the correct directive to be returned.
For example, a passenger is intending to travel on flight QF2 from Bangkok to Sydney
and is transferring to flight NZ102 from Sydney to Auckland, without intending to
remain in Australia for more than the time between the flights. In this example, it is
assumed that both Australia and New Zealand use the APP System.
When the passenger is checked in for the flight from Bangkok to Sydney, regardless
of whether this check-in is performed in Bangkok or elsewhere i.e. through-check,
the airline must flag the passenger as “Transit at Destination” i.e. transiting at the
destination of the flight for which they are being checked in. The message to the
Australian APP System will reflect that the arriving passenger is in transit.
When the passenger is checked in for the flight from Sydney to Auckland, regardless
of whether this check-in is performed in Sydney, or in Bangkok or elsewhere i.e
through-check, the airline must flag the passenger as “Transit at Origin” i.e.
transiting at the origin of the flight for which they are being checked in. The
message to the Australian APP System will reflect that the departing passenger was
in transit. The message to the New Zealand APP System will reflect that the
arriving passenger is intending to enter New Zealand.
The response from the Australian APP System and the reporting to the Australian
government will take into account that the passenger is in transit.
• Intermediate Transit
When a passenger arrives in an APP-participating country on a flight and leaves on the
same flight, the APP System does not need to be explicitly informed of the transit as it
can determine the intermediate transit point of the flight from the airline schedules.
Without any specific notification from the airline, the APP System will recognise that
the flight transits Singapore and Sydney, and that Australia and New Zealand are APP-
participating countries. The message to the Australian APP System will reflect that the
passenger in transiting on flight EK410. The message to the New Zealand APP System
will reflect that the arriving passenger is intending to enter New Zealand.
The response from the Australian APP System and the reporting to the Australian
government will take into account that the passenger is in transit.
Definitions
An unscheduled flight is a flight that does not appear on the standard (OAG) airline
schedules, or else is a scheduled flight which has been seriously delayed. In both cases,
border authorities which have implemented APP have primary line processing procedures in
place to handle passengers from these flights.
Delayed When a flight is delayed so that that it may be confused with a flight of the
Flights same flight number on a subsequent day, airlines often alter the flight number.
For example, flight QF002 on 17-Sep delayed until the next day may be
renumbered as QF8002 on 18-Sep to avoid confusion with QF002 on 18-Sep.
Charter By their nature, charter flights are also not listed in the airline schedules, since
Flights they are either “one-off” events, or else follow a short-term schedule which
may not be published by OAG.
No Rule Notes
1 For each passenger, submit a CIRQ message with the The APP System will recognise this as an
Scheduled/Unscheduled Flight flag set to U[unscheduled], unscheduled flight, and not look up the
and complete data on the International Flight. schedules to validate this data.
2 If the flight is anything other than a simple International Flight If the full flight data is not supplied in this
(where trans-border and expected ports are the same), the case, the APP System will not be able to
airline must include the additional flight data. provide the correct data to the
government.
3 This approach can only be effectively used when the There is no provision in the messages for
International Flight does not transit an APP-participating providing information on intermediate
country between the origin and destination countries of the countries. Under these circumstances, the
flight. alternative approach outlined in Table 5
below should be used.
No Rule Notes
1 Use the command TIETAYT A to load a flight schedule directly onto See Appendix C for full details on
the APP System. how to carry out this procedure.
OR:
Report the problem to the APP Help Desk (i.e. SITA Gabriel Help
Desk) and request the loading of a flight (or series of flights).
2 Confirm that the new schedule has successfully been loaded. Use the command TIETAYT D,
OR obtain confirmation from the
Help Desk.
3 For each passenger, submit a CIRQ message (as if they were If the unscheduled flight has
travelling on a scheduled flight). already been loaded, there will
be no problem, even if the flag
on the message is set to
S[cheduled].
4 Advise the appropriate border authorities that an unscheduled flight is For Australia, contact EOC using
being handled in this way. SITATEX or telephone.
For NZ, contact the APS Support
Office by telephone.
The Stand-alone APP Implementation makes use of published airline flight schedules
(OAG) both to verify that a flight exists (when a flight is being opened) and to derive
additional flight data (eg. scheduled arrival date and time).
It should be noted that unscheduled flights cannot therefore be handled using the Stand-
alone APP Implementation.
Once again however, this problem could be overcome by arranging for the flight(s) to be
loaded directly onto the APP System (using the TIETAYT command - see Appendix C).
Definitions
Airlines often share aircraft on a flight. Each airline will have access to a portion of the seats
on the flight and will sell the seats under its own “marketing flight number”. This means that
a flight may have a mix of passengers on different “marketing flights” where one of those
flight numbers is the actual operating flight number.
For example, Air New Zealand flight NZ103 from Auckland to Sydney may also have a
marketing flight number of QF8103 for Qantas. The passengers arriving on the aircraft in
Sydney would therefore report themselves at the primary line as a mix of NZ103 and QF8103
passengers.
Generally government border agencies within an APP-participating country require the actual
flight number be used rather than a mix of actual and marketing flight numbers, and this is
therefore what airlines should use in carrying out APP transactions.
The airline schedules available to the APP System via the Official Airline Guide (OAG) list
all flights including code shares, and also distinguish between code share and actual flights.
No Rule Notes
1 When submitting APP check-in transactions, If a code share number is submitted, no problem will occur
ensure that the actual flight number is used, within APP, but the code share flight number will be
rather than any code share number. reported to the government without “translation”. This may
cause problems for the border authorities in reconciling
expected movements with actual movements.
With very few exceptions, every traveller to Australia, apart from Australian and New
Zealand citizens, requires a visa. Consequently, by accessing the Australian Government’s
visa and passport databases, the APP System implemented for Australia can compile data on
all passengers in advance of their travel to Australia.
When a country implementing APP does not have a similar universal visa policy, data on
some passengers will not be available from existing government databases and must be
captured at check-in. However, for efficient implementation of APP, it is essential that the
requirement for data capture be minimised. One way of achieving this is to provide for data
sharing by governments at either end of an international journey. In many cases, the country
from which a passenger is departing will have data on the passenger even when the country to
which they are travelling does not.
A generic approach to data sharing has been included in the design of the APP System. By
acting as an intermediary between the systems of two governments using APP, the APP
System can obtain data on a passenger from the system of one government and supply it to
the system of the other government. This can be achieved without any special action by an
airline checking in a passenger. Of course, such data sharing arrangements may only be put
in place with the agreement of both governments.
Airlines will not need to take any special action to receive the benefits of data sharing
between governments.
3 Message Types
There are four message types: two for check-in (request from the airline and response from
the APP System), and two for cancellations (cancellation request from the airline and
response from the APP System). Each of the four message types is described in detail below.
3.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 CG. The message
can be used to provide data for one or more passengers to government systems at both ends of
an international journey or at transit points.
The following diagram (Figure 4) shows the overall structure of the CIRQ message:
Field count: 4 Field count: 10 Field count: 6 Field count: 5 Field count: 24
Instances: 0-1 Instances: 1 Instances: 0-2 Instances: 0-2 Instances: 1-5
The body of the message contains the data groups listed in Table 7.
When a message is received from an airline across the SITA network, the CG:
• Determines which governments involved in the transaction are participants in the APP
System.
• Translates the airline message into formats recognised by the participating AP(s).
• Forwards the message(s) to the AP(s) of the participating government(s).
• Receives response(s) from the AP(s) of the participating government(s).
• Collates the responses into a single message for return to the airline DCS. Refer to
Check-In Response (CIRS) below.
During the processing by the CG and the AP, a large number of data validity and integrity
checks are performed on the data supplied. The processing and checks performed are
described in detail in the Advance Passenger Processing Business System Design.
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 CG
and the AP 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).
It is strongly recommended that airlines implement the CIRQ message in the following way:
No Rule Notes
1 Use a passport reader to obtain passenger This method should minimise data input errors.
biodata from the machine readable zone (MRZ) of
the passport wherever possible during check-in.
2 Incorporate all of the MRZ data in the first CIRQ If the passenger is not known to the APP System, but
message so that the full passenger data is is in fact visa free for the country concerned, the
available to the APP System without the need for biodata will be captured at this point and sent to the
any further dialogue. government in the expected movement record.
See Example 7 below for an example of full data
being supplied (section 6.1.1).
3 The CIRQ message allows for a Sex indicator of
M (Male), F (Female) 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 “X” in the CIRQ message.
4 If the passenger is an endorsee on a passport, the This enables the passenger to be uniquely identified
passenger’s given name or DOB is also required. without further interaction with the check-in agent.
The APP System only allows transactions on flights within the following time window:
This means that the earliest date on which an APP transaction can be performed (i.e.
sending a CIRQ or a CICX message) is two days before today (i.e. local time), and the
latest date is 10 days after today (local time).
Any transaction for a flight which is outside this date range will be rejected.
3.2.1 Purpose
This message is used to send a response to a Check-in Request (CIRQ) from the CG to the
airline DCS. The message can be used to provide data for one or more passengers from
government systems at both ends of an international journey. 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 not been matched on the database on a government system but a
corresponding directive for the passenger can be returned ( “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.
The following diagram (Figure 5) shows the overall structure of the CIRS message:
PRS ERR
Passenger Error Field count: Variable (5+)
Response Group Instances: 0-1
(Conditional) One of these (Conditional)
is required
(either PRS
Field count: 29 or ERR) Error code and Field count: 3
Instances: 0-10 message text Instances: 1-many
The body of the message contains the data groups listed below in Table 9.
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 not 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 DCS can continue to process the passenger to remedy the problem but cannot board
the passenger until this is completed.
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 CG
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 CG, 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 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.
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 uniquely identify a passenger or when there is
insufficient data to assess the passenger, the DCS must capture further passenger data
and resend the CIRQ message.
• To override a directive from a government system, the DCS must resend 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 eg. “GAU” indicates a “G” override is to be sent
to Australia (refer to Table 19). Overrides may be submitted for more than one country
in a single CIRQ message eg. “GAUANZ” indicates a “G” override is to be sent to
Australia and an “A” override is to be sent to New Zealand.
If at least one country has returned a status Be satisfied that the passenger belongs to a
of “I” or “U”, but no country has returned a special category according to the regulations of
status of “X”, the additional passenger data each country that returned a status of “D”; or
must be captured so an assessment may Contact government agencies of each country that
be completed. A CIRQ message is then returned a status of “D” and obtain clearance to
retransmitted. If this does not correct the board the passenger.
problem, a government agency should be
contacted for advice.
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.
5 In cases where some countries return a This is a reconciliation issue for the participating
Passenger Status Code of “B” and others do not government and the airlines do not need to take any
return “B”, the expected movements generated special action.
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.
6 Store the Expected Passenger ID from the CIRS This ID can be used subsequently in a Movement
message against the passenger in the DCS. Cancellation message (CICX) if the passenger does
This identifier will only be returned if all countries not fly (or if the entire flight is cancelled).
involved in the passenger’s journey have
returned a positive directive and an expected
movement has been generated to government
systems.
7 The Passenger Status codes for each If a particular passenger is cleared for travel while
passenger should be assessed independently of others in the transaction are not, no further processing
other passengers in the transaction to determine is required for the passenger that has been cleared. It
if any future action is necessary for the is not necessary to resend transactions for that
passenger. Where a “B” is returned for a passenger. Only passengers not cleared for travel
passenger from all countries, no further need to be processed further.
transactions need to be submitted for the
passenger.
8 The Passenger Status returned in the CIRS The relationships in Table 23 are indicative only and
message should be used for assessing a refinements of business rules by a government may
response, not a local table that relates Check-in lead to changes or to a Check-in Message code being
Message Codes to Passenger Status codes. associated with more than one possible Passenger
Status code.
9 Airlines should wait for 25 seconds before timing The CG waits for 20 seconds for responses from all
out an enquiry sent to the CG. governments before timing out the enquiry. Airlines
need to wait a little longer than this.
3.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 6) shows the overall structure of the CICX message:
INT PCX
International Movement
Flight Cancellation
(Mandatory) (Mandatory)
The body of the message contains the data groups listed in Table 11.
When a message is received from an airline across the SITA network, the CG:
• Determines which governments involved in the transaction are participants in the APP
System.
• Translates the airline message into formats recognised by the participating AP(s).
• Forwards the message(s) to the AP(s) of the participating government(s).
• Receives response(s) from the AP(s) of the participating government(s).
• Collates the responses into a single message for return to the airline DCS. Refer to
Movement Cancellation Confirmation (CICC) below.
During the processing by the CG and the AP, a large number of data validity and integrity
checks are performed on the data supplied. The processing and checks performed are
described in detail in the Advance Passenger Processing Business System Design.
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 CG and the AP 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).
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 APP Otherwise incorrect expected movement details will be
System and does not actually board the flight, sent to government systems.
the movement should be cancelled by this
transaction.
2 Provide the Expected Passenger ID in the PCX See Example 21 below for an example of this data
data group. This is sufficient data for the CG to being supplied (section 6.2.1). [The value of the ID in
uniquely identify the relevant passenger. the example is 000000002128666].
3 Do not supply data which is insufficient to allow There is no provision for selecting passengers from a
the passenger to be uniquely identified. list returned by the CG. If the data supplied for a
passenger does not allow the passenger to be uniquely
identified, an error condition is generated for the
passenger.
3.4.1 Purpose
This message is used to send a response to a Movement Cancellation (CICX) from the CG to
the airline DCS.
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 7) shows the overall structure of the CICC message:
PCC ERR
Error Field count: Variable (5+)
Passenger
Group Instances: 0-1
Cancellation
Response One of these (Conditional)
(Conditional) is required
(either PCC Error code and Field count: 3
Field count: 28 or ERR) message text Instances: 1-many
Field count:
Instances: 28
0-10
Instances: 0-10
The body of the message contains the data groups listed in Table 13.
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.
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 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 CIRQ message.
It is strongly recommended that airlines implement the CICC message in the following way:
No Rule Notes
1 If the CICC message includes an Error Group These errors are normally of a serious nature eg. APP
(ERR), the error message is displayed to the System unavailable, and resubmission by the user may
user for correction and resubmission. not remedy the problem.
2 If the CICC message includes a Passenger These errors are normally of a less serious nature.
Cancellation Response (PCC) data group that
includes an error message, the error message is
displayed to the user for correction and
resubmission.
3 The CICC message includes a Passenger If the timeout problem persists for a significant period of
Status Code returned by each country for each time and a number of cancellation messages have not
passenger. been correctly processed, the check-in agent must
contact government agencies of each country affected
If the CICC message for one or more
and inform them of the situation.
countries returns a status of “T”, the APP
Systems for those countries are not The government systems of countries unaffected by the
responding i.e. timing out. timeouts will continue to receive the correct data on
expected movement cancellations.
Processing can continue.
4 When a cancellation of an expected movement This may result in a reconciliation issue for the
involves more than one country, the responses participating governments but the airlines do not need
from the various countries could be all to take any special action unless it becomes a frequent
successful (8505), all unsuccessful (8506) or a occurrence.
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 AP of a
country originally processed the check-in
transaction. The check-in agent cannot
readily remedy this issue. Continue with no
special action.
5 If the Expected Passenger ID from the CIRS This will provide a full record within the DCS of both
message was stored against the passenger in successful APP transactions (those with a value for
the DCS, overwrite this ID with a value (eg. Expected Passenger ID), and successful cancellations
“Cancelled”) to record the fact that the (those marked “Cancelled”).
movement has successfully been cancelled.
4 Dialogue Types
All communication between the DCS and the CG consists of a request from the DCS
followed by a response from the CG. 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.
Dialogue Structure
Message Message from DCS Message from CG
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.
Dialogue Structure
Message Message from DCS Message from CG
no
1 CIRQ (data for one or more pax)
2 CIRS (eg. error code 8507 “Duplicate Name” )
3 CIRQ (including data which uniquely
identifies each pax)
4 CIRS (a directive for each pax)
Dialogue Structure
Message Message from DCS Message from CG
no
1 CIRQ (data for one or more pax)
2 CIRS (eg. error code 8516 “Insufficient Data”)
3 CIRQ (corrected data)
4 CIRS (a directive for each pax)
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
Message Message from DCS Message from CG
no
1 CICX (data for one or more pax)
2 CICC (an acknowledgement for each pax)
Dialogue Structure
Message Message from DCS Message from CG
no
1 CICX (data for one or more pax)
2 CICC (eg. error code 8506 “No Record” )
Dialogue Structure
Message Message from DCS Message from CG
no
1 CICX (data for one or more pax)
2 CICC (eg. error code 8506 “No Record” )
3 CICX (corrected data)
4 CICC (an acknowledgement for each pax)
5 Message Formats
No Rule Notes
1 Populate Layer 7 of the message header with These five fields in Layer 7 are currently also required
data in accordance with Table 16 below. by the ETA System.
2 Include sufficient data to ensure that the source Identification of the user’s location is a crucial aspect of
of the transaction can be identified. the APP System.
For example, the field Airline Private Data could Although some of the Layer 7 data is optional, the
be used to send data identifying the source. airline must be able to identify the source of the
transaction
3 Comply with the Specification for the
Implementation of the IATA HTH Protocol as
produced by SITA ATLIS for the actual detailed
Layer 7 requirements in communicating with
SITA ATLIS.
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 The rules specified in this document are designed to be
tables below for data items in the body of the applicable to multiple governments and to be applicable
message. for generating advance passenger information for both
This usage is determined by the government ends of an international journey and transit points.
implementing Advance Passenger Processing.
2 Comply with the maximum length specified in Longer fields may be truncated during processing.
the tables below for data items in the body of
the message.
3 Use slash (/) as the delimiter character to Obviously, it is necessary that the information in the
separate data items. data items does not contain the delimiter character.
4 Use only the colon (:) character as the delimiter [eg. “CIRQ:”, “CIRS:”, “CICX:”, “CICC:”]
character after the Transaction Code.
5 Indicate null data items as two consecutive [eg. “//”]
delimiter characters.
6 Transmit all fields, including trailing empty fields. Even trailing optional empty fields must be transmitted.
7 Follow the rules for grouping of data items in the Data items are arranged in groups, each including a
body of the message. 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).
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:
21 Transit at A(1) Optional “Y”, “N”. Set to “Y” if passenger is in transit at destination of
Destination If not given, treated as “N”. International Flight.
22 Override Codes A(15) Optional Format is: This field may be used to provide override codes for up
CxxCxxCxxCxxCxx to five countries in a single transmission. The rules for
Where: use of overrides may vary by country, but all will use
the same set of override codes.
“xx” = IATA country code for the country to
which the preceding override code
applies.
“C” = Override code for the country which
follows.
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.
23 PNR Source X(3) Conditional Airline code (IATA [2-character]) Conditional (may be required by some countries on
international flight)
24 PNR Locator X(6) Conditional Conditional (may be required by some countries on
international flight)
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.
The following three fields are repeated for each error message returned.
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 Code A(4) Mandatory “CICC” Must be followed by colon.
2 Airline Private X(14) Optional Airline reference Any data that was originally given in the CICX will be
Data echoed back here.
Passenger 1 Passenger A(3) Conditional “PCC” Conditional (required if no ERR data group is present)
Cancellation Cancellation
Response Response Group
(repeating) Identifier
2 Passenger N(2) Mandatory Number of fields which follow in this data Set to 26 for current message definition.
Cancellation group.
Response Group
Field Count
3 Passenger N(3) Mandatory The sequence number of the passenger in Corresponds to sequence number in the CICX
Sequence the message. message.
Number
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
The following three fields are repeated for each error message returned.
3 Participating A(2) Conditional IATA Country Code of the participating Conditional (at least one occurrence required if this
Country country generating the error response. group is present). The field may be null if the error was
detected by the CG and is therefore not specific to a
given country.
4 Error Code N(4) Conditional Error code for error condition identified. Conditional (required if country code is present).
5 Error Message X(60) Conditional Error message for error condition identified. Corresponds to Error Code in previous field.
Text Conditional (required if country code is present).
6 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 6.3.
The following seven examples relate to a single passenger on a simple end-to-end journey and
are illustrated by Figure 8.
Malaysia
Kuala Lumpur
Australia
Sydney
CIRQ:/123456/N//20/INT/8/S/BA033/KUL/SYD/19981030////
PRQ/22/1/P/USA//Z4351213///////SMIT///////////
[CG sends 5-1 message to AP-AU and AP-AU responds with 6-1 message.]
CIRS:/PRS/27/1/AU/P/USA/USA/Z4351213//P/20011114////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.
CIRQ:/123456/N//20/INT/8/S/BA033/KUL/SYD/19981030////
PRQ/22/1/P/USA//Z4351213///////SMIT///////////
[CG sends 5-1 message to AP-AU and AP-AU responds with 6-1 message.]
CIRS:/PRS/27/1/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.
CIRQ:111/123456/N//20/INT/8/S/BA033/KUL/SYD/19981030////
PRQ/22/1/P/USA//Z4351213///////SMIT///////////
[CG sends 5-1 message to AP-MY and AP-MY responds with 6-1 message.]
[CG sends 5-1 message to AP-AU and AP-AU responds with 6-1 message.]
CIRS:111/PRS/27/1/MY/P/USA/USA/Z4351213//P/20011114////
SAMANTHA TAYLOR SMITH//19640912/F/USA//8501/B/18743///////
PRS/27/1/AU/P/USA/USA/Z4351213//P/20011114////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.
CIRQ:/123456/Y//20/INT/8/S/BA033/KUL/SYD/19981030////
PRQ/22/1/P/USA//Z4351213///////SMIT///////////
[CG sends 5-1 message to AP-AU and AP-AU responds with 6-1 message]
CIRS:/PRS/27/1/AU/P/USA/USA/Z4351213//P/20011114////SMITH/
SAMANTHA/19640912/F/USA//8507/U////////PRS/27/1/AU/P/USA/USA/
Z4351213//P/20011114////SMITH/BELINDA/19940421/F/USA//8507/U//
//////
The AP 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 6.1.2 below).
CIRQ:/123456/N//20/INT/8/S/BA033/KUL/SYD/19981030////
PRQ/22/1/P/USA//351213///////SMIT///////////
[CG sends 5-1 message to AP-AU and AP-AU responds with 6-1 message]
CIRS:/PRS/27/1/AU/P/USA//351213//P/////SMIT///////0000/E/6033/
INVALID PASSPORT NUMBER FORMAT/////
The AP 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.
CIRQ:/123456/N//20/INT/8/S/BA033/KUL/SYD/19981030////
PRQ/22/1/P/USA//351213///////SMIT///////////
[CG sends 5-1 message to AP-AU and AP-AU responds with 6-1 message]
A serious error (code 6999) occurred on the AP, and the passenger request was not processed.
The check-in agent should resubmit the request.
CIRQ:NZ1123/123456/N//20/INT/8/S/BA033/KUL/SYD/19981030////
PRQ/22/1/P/USA/USA/Z4351213/E/P/20011114////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.
[CG sends 5-1 message to AP-AU and AP-AU responds with 6-1 message]
CIRS:NZ1123/PRS/27/1/AU/P/USA/USA/Z4351213/E/P/20011114////
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.
The following three examples relate to multiple passengers in the same check-in request and
are illustrated by Figure 8.
CIRQ:/123456/N//20/INT/8/S/BA033/KUL/SYD/19981030////
PRQ/22/1/P/USA//Z4351213///////SMIT///////////
PRQ/22/2/P/USA//Z4354753///////SMIT///////////
Details of two passengers (with the same family name, but with different passports) are
submitted by the airline.
[CG sends 5-1 message to AP-AU and AP-AU responds with 6-1 message]
CIRS:/PRS/27/1/AU/P/USA/USA/Z4351213//P/20011114////SMITH/
SAMANTHA/19640912/F/USA//8501/B/345234///////PRS/27/2/AU/P/
USA/USA/Z4354753//P/20011114////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.
CIRQ:/123456/N//20/INT/8/S/BA033/KUL/SYD/19981030////
PRQ/22/1/P/USA//Z4351213///////SMIT///////////
PRQ/22/2/P/USA//Z43547///////SMIT///////////
Details of two passengers (with the same family name, but with different passports) are
submitted by the airline.
[CG sends 5-1 message to AP-AU and AP-AU responds with 6-1 message]
CIRS:/PRS/27/1/AU/P/USA/USA/Z4351213//P/20011114////SMITH/
SAMANTHA/19640912/F/USA//8501/B/345234///////PRS/27/2/AU/P/USA//
Z43547//P/////SMIT//////0000/E//6033/INVALID PASSPORT NUMBER
FORMAT/////
The AP 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.
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.
CIRQ:/123456/N//20/INT/8/S/BA033/KUL/SYD/19981030////
PRQ/22/1/P/NZL//Z4351213///////SMIT///////////
PRQ/22/2/P/NZL//Z4354888///////SMIT///////////
Details of two passengers (with the same family name, but with different passports) are
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.
[CG sends 5-1 message to AP-AU and AP-AU responds with 6-1 message]
CIRS:/PRS/27/1/AU/P/NZL//Z4351213///////SMIT//////8507/U////////
PRS/27/2/AU/P/NZL//Z4354888//P/20011114////SMITH/
SAMUEL JACKSON/19320721/M/NZL//8501/B/345236///////
The AP has processed one of the passengers normally (Samuel Jackson Smith) and given
code 8501 (“OK to Board”). An expected movement record has been sent to the participating
government for this passenger.
The AP 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.
The following example relates to a single passenger on a flight with two legs and is illustrated
by Figure 9.
Check-in Port
Thailand
Bangkok
Sydney
Melbourne
Trans-Border Port
EXAMPLE 11: Different trans-border and expected port (same scheduled flight)
Airline to CG (CIRQ Message)
CIRQ:/123456/N//20/INT/8/S/QF016/BKK/SYD/19981030////
PRQ/22/1/P/USA//Z4351213///////SMIT///////////
The airline sends a request showing that passenger SMITH is boarding QF016 in Bangkok
and disembarking in Sydney.
[The CG sends 5-1 message to AP-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. AP-AU responds with 6-1 message]
CIRS:/PRS/27/1/AU/P/USA/USA/Z4351213//P/20011114////SMITH/
SAMANTHA/19640912/F/USA//8501/B/2128666///////
The AP 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.
The following example relates to a single passenger on a multi flight journey and is illustrated
by Figure 10.
Chicago
Los Angeles
Sydney
Melbourne
CIRQ:/123456/N//20/CHK/2/CHI/UA841/INT/8/S/QF012/LAX/SYD/19981030/
///EXD/4/MEL/QF022/19981101/2205/PRQ/22/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).
[CG sends 5-1 message to AP-AU which includes the fact (obtained from the Layer 7
address) that the APP check-in request was done in CHI. AP-AU responds with 6-1 message]
CIRS:/PRS/27/1/AU/P/USA/USA/Z4351213//P/20011114////SMITH/
SAMANTHA/19640912/F/USA//8501/B/2128666///////
The AP 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 CHI as the check-in port, SYD as the trans-border port, and MEL as the
expected port.
The following two examples relate to a single passenger on unscheduled flights and are
illustrated by Figure 8.
CIRQ:/123456/N//20/INT/8/U/BA033D/KUL/SYD/19981101/081500/
19981101/195500/PRQ/22/1/P/USA//Z4351213///////SMIT///////////
[CG sends 5-1 message to AP-AU including all of these details, having noted that the flight is
flagged as “Unscheduled” (and therefore not consulting the airline schedule database as
would normally occur). AP-AU responds with 6-1 message]
CIRS:/PRS/27/1/AU/P/USA/USA/Z4351213//P/20011114////SMITH/
SAMANTHA/19640912/F/USA//8501/B/2128666///////
The AP 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, including the full flight details as advised by the airline.
CIRQ:/123456/N//20/INT/8/U/QF016D/BKK/SYD/19981101/081500/
19981101/225500/TBD/3/MEL/19981101/195500/PRQ/22/1/P/USA//Z435
1213///////SMIT///////////
[CG sends 5-1 message to AP-AU including all of these details, having noted that the flight is
flagged as “Unscheduled” (and therefore not consulting the airline schedule database as
would normally occur). AP-AU responds with 6-1 message]
CIRS:/PRS/27/1/AU/P/USA/USA/Z4351213//P/20011114////SMITH/
SAMANTHA/19640912/F/USA//8501/B/2128666///////
The AP 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, including the full flight details as advised by the airline.
The following two examples relate to overriding boarding directives from one or more
countries and are illustrated by Figure 8.
CIRQ:111/123456/N//20/INT/8/S/BA033/KUL/SYD/19981030////
PRQ/22/1/P/USA//Z4351213///////SMIT///////////
[CG sends 5-1 message to AP-MY and AP-MY responds with 6-1 message.]
[CG sends 5-1 message to AP-AU and AP-AU responds with 6-1 message.]
CIRS:111/PRS/27/1/MY/P/USA/USA/Z4351213//P/20011114////
SAMANTHA TAYLOR SMITH//19640912/F/USA//8501/B////////
PRS/27/1/AU/P/USA/USA/Z4351213//P/20011114////SMITH/SAMANTHA/
19640912/F/USA//8502/D////////
The passenger has been given 8501 (“OK to Board”) by Malaysia but 8502 (“Do Not Board”)
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.
CIRQ:111/123456/N//20/INT/8/S/BA033/KUL/SYD/19981030////
PRQ/22/1/P/USA//Z4351213///////SMIT////////GAU///
[CG sends 5-1 message to AP-MY and AP-MY responds with 6-1 message.]
[CG sends 5-1 message to AP-AU and AP-AU responds with 6-1 message.]
CIRS:111/PRS/27/1/MY/P/USA/USA/Z4351213//P/20011114////
SAMANTHA TAYLOR SMITH//19640912/F/USA//8501/B/18745///////
PRS/27/1/AU/P/USA/USA/Z4351213//P/20011114////SMITH/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.
EXAMPLE 16: Multiple passengers, one requiring override for both countries
[NOTE: This example assumes that both Australia and Malaysia are APP countries]
CIRQ:111/123456/N//20/INT/8/S/BA033/KUL/SYD/19981030////
PRQ/22/1/P/USA//Z4351213///////SMIT///////////
PRQ/22/2/P/USA//Z4354753///////SMIT///////////
[CG sends 5-1 message to AP-MY and AP-MY responds with 6-1 message.]
[CG sends 5-1 message to AP-AU and AP-AU responds with 6-1 message.]
CIRS:111/PRS/27/1/MY/P/USA/USA/Z4351213//P/20011114////
SAMANTHA TAYLOR SMITH//19640912/F/USA//8501/B/18743///////
PRS/27/1/AU/P/USA/USA/Z4351213//P/20011114////SMITH/SAMANTHA/
19640912/F/USA//8501/B/18743///////
PRS/27/2/MY/P/USA/USA/Z4354753//P/20011114////SMITH/
ANDREW JACKSON/19620511/M/USA//8502/D////////
PRS/27/2/AU/P/USA/USA/Z4354753//P/20011114////SMITH/
ANDREW JACKSON/19620511/M/USA//8502/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 decided that there is no reason for the passenger to be denied boarding from
Malaysia and has contacted the Australian authorities and obtained permission for uplifting
the passenger. The transaction is submitted again with override codes applicable for Malaysia
and Australia.
CIRQ:111/123456/N//20/INT/8/S/BA033/KUL/SYD/19981030////
PRQ/22/1/P/USA//Z4354753///////SMIT////////AMYGAU///
[CG sends 5-1 message to AP-MY and AP-MY responds with 6-1 message.]
[CG sends 5-1 message to AP-AU and AP-AU responds with 6-1 message.]
CIRS:111/PRS/27/1/MY/P/USA/USA/Z4354753//P/20011114////
SMITH/ANDREW JACKSON/19620511/M/USA//8517/B/18777///////
PRS/27/1/AU/P/USA/USA/Z4354753//P/20011114////SMITH/ANDREW
JACKSON/19620511/M/USA//8517/B/18777///////
The passenger has been given 8517 (“Override accepted”) by both countries. An expected
movement record has been sent to each of the participating governments.
The following example relates to a passenger in transit at the start or the end of an
international flight and is illustrated by Figure 11.
Check-in Port
Thailand
Bangkok
QF302
QF107
Australia
Sydney
Transit Airport
CIRQ:/123456/N//20/INT/8/S/QF302/BKK/SYD/19981030////
PRQ/22/1/P/USA//Z4351213///////SMIT///////Y////
The airline sends a request showing that passenger SMITH is boarding QF302 in Bangkok
and disembarking in Sydney but is in transit in Sydney at the destination of this international
flight.
[CG sends 5-1 message to AP-AU and AP-AU responds with 6-1 message]
CIRS:/PRS/27/1/AU/P/USA/USA/Z4351213//P/20011114////SMITH/
SAMANTHA/19640912/F/USA//8501/B/2128666///////
The AP has confirmed that the passenger is permitted to transit Australia and has given code
8501 (“OK to Board”). An expected movement record has been sent to the participating
government indicating that the passenger will be transiting Sydney.
CIRQ:/123456/N//20/INT/8/S/QF107/SYD/LAX/19981031////
PRQ/22/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 in transit in Sydney at the origin of the outbound international flight.
[CG sends 5-1 message to AP-AU and AP-AU responds with 6-1 message]
CIRS:/PRS/27/1/AU/P/USA/USA/Z4351213//P/20011114////SMITH/
SAMANTHA/19640912/F/USA//8501/B/2128777///////
The AP has confirmed that the passenger is permitted to board the flight and has given code
8501 (“OK to Board”). An expected movement record has been sent to the participating
government indicating that the passenger will be departing after having been in transit in
Sydney.
The following example relates to a passenger in transit on a single international flight and is
illustrated by Figure 12.
Check-in Port
Thailand
Bangkok
TG398
TG398
Australia
Sydney
Transit Airport
CIRQ:/123456/N//20/INT/8/S/TG398/BKK/LAX/19981030////
PRQ/22/1/P/USA//Z4351213///////SMIT///////////
The airline sends a request showing that passenger SMITH is boarding TG398 in Bangkok
bound for Los Angeles. The CG uses the OAG to determine that the flight transits Sydney.
[CG sends 5-1 message to AP-AU and AP-AU responds with 6-1 message]
CIRS:/PRS/27/1/AU/P/USA/USA/Z4351213//P/20011114////SMITH/
SAMANTHA/19640912/F/USA//8501/B/2128888///////
The AP has confirmed that the passenger is permitted to transit Australia and has given code
8501 (“OK to Board”). An expected movement record has been sent to the participating
government indicating that the passenger will be transiting Sydney.
6.1.9 Timeout
The following two examples relate to timeouts occurring on one or more government systems
and are illustrated by Figure 8.
CIRQ:111/123456/N//20/INT/8/S/BA033/KUL/SYD/19981030////
PRQ/22/1/P/USA//Z4351213///////SMIT///////////
[CG sends 5-1 message to AP-MY and AP-MY responds with 6-1 message.]
[CG sends 5-1 message to AP-AU and AP-AU does not respond.]
CIRS:111/PRS/27/1/MY/P/USA/USA/Z4351213//P/20011114////
SAMANTHA TAYLOR SMITH//19640912/F/USA//8501/B/2129999///////
PRS/27/1/AU/P/USA//Z4351213//P///////////0000/T////////
The passenger has been given 8501 (“OK to Board”) by Malaysia but the Australian system
has timed out. No expected movement has been generated for Australia and the expected
movement generated for Malaysia has not been cancelled.
CIRQ:111/123456/N//20/INT/8/S/BA033/KUL/SYD/19981030////
PRQ/22/1/P/USA//Z4351213///////SMIT///////////
[CG sends 5-1 message to AP-MY and AP-MY does not respond.]
[CG sends 5-1 message to AP-AU and AP-AU does not respond.]
The CG responds with an error message indicating that both (all) government systems timed
out.
The following four examples relate to cancellation of APP for a single passenger and are
illustrated by Figure 8.
CICX:/123456/N//20/INT/8/S/BA033/KUL/SYD/19981030////PCX/20/1/
000000002128666/P/USA/USA/Z4351213///////SMIT////////
The airline submits a cancellation request with the passenger’s passport number, nationality,
family name (in part), and also the Expected Passenger ID.
[CG sends 5-2 message to AP-AU which responds with 6-2 message including the full
passenger biodata.]
CICC:/PCC/26/1/AU/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”). An additional movement record has been sent to the participating government
for this passenger, flagged as a cancellation.
CICX:/123456/N//20/INT/8/S/BA033/KUL/SYD/19981030////PCX/20/1/
/P/USA//Z4351213///////SMIT////////
The airline submits a cancellation request with the passenger’s passport number, nationality,
family name (in part), but without the Expected Passenger ID.
[CG sends 5-2 message to AP-AU which responds with 6-2 message carrying the code 8506
(“No record”)]
CICC:/PCC/26/1/AU/P/USA//Z4351213//P/////SMIT//////8506/N/////
//
The AP 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).
CICX:/123456/N//20/INT/8/S/BA033/KUL/SYD/19981030////PCX/20/1/
/P/USA//Z43512///////SMIT////////
The airline submits a cancellation request with the passenger’s passport number, nationality,
family name (in part), but without the Expected Passenger ID.
[CG sends 5-2 message to AP-AU which responds with 6-2 message carrying the code 6033
(“Invalid passport number format”)]
CICC:/PCC/26/1/AU/P/USA//Z43512//P/////SMIT//////0000/E/6033/
INVALID PASSPORT NUMBER FORMAT/////
The AP 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).
The following example relates to cancellation of APP for multiple passengers and is
illustrated by Figure 8.
CICX:/123456/N//20/INT/8/S/BA033/KUL/SYD/19981030////PCX/20/1/
/P/USA//Z4351213///////SMIT/SAMANTHA///////PCX/20/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.
[CG sends 5-2 message to AP-AU which responds with 6-2 message carrying the code 8505
(“Cancelled”) and the full biodata for each passenger.]
CICC:/PCC/26/1/AU/P/USA//Z4351213//P/////SMITH/SAMANTHA/
19640912/F/USA//8505/C///////PCC/26/2/AU/P/USA//Z4351213//P///
//SMITH/BELINDA/19940421/F/USA//8505/C///////
The AP 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.
APPENDIX A
Passenger
Message Brief description Code used by Code used by
Action required by airline Notes Status
code (max 22 chars) Australia? New Zealand?
Code
8501 OK TO BOARD Allow the passenger to board. An expected passenger movement has YES YES B
been created.
8502 DO NOT BOARD Do not allow the passenger to An expected movement record has not YES YES D
board. 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”).
8505 CANCELLED (Confirmation that cancellation A previous movement has been cancelled YES YES C
was successful). (i.e. where passenger previously received
“OK to Board” or equivalent for this flight).
8506 NO RECORD (Advice that cancellation was not An attempt was made to cancel a previous YES YES N
successful). movement (for this flight) but no record can
be found to cancel.
8507 DUPLICATE NAME Do not allow the passenger to There is more than one person on the YES YES U
board. Retry APP for this passport matching the data provided. Need
passenger using additional data. to include additional biodata (eg. a given
name or the date of birth).
Passenger
Message Brief description Code used by Code used by
Action required by airline Notes Status
code (max 22 chars) Australia? New Zealand?
Code
8510 CONTACT EOC Do not allow the passenger to An expected movement record has not YES NO D
board been created. However, all the required (exclusive)
data is available for the passenger. The
Check-in agent must seek advice from
EOC (Entry Operations Centre, DIMIA) in
Canberra, Australia (Tel: +61-2-6264-
4483). If permission to board the
passenger is given, an override code of “G”
must be used.
8516 INSUFFICIENT DATA Do not allow the passenger to Data on the passenger has not been found YES YES I
board. Provide the full set of in the government databases. Full data for
passport and personal data for the the passenger must be captured before a
passenger. decision can be made.
8517 OVERRIDE ACCEPTED Allow the passenger to board. The override submitted has been accepted. YES YES B
An expected passenger movement has
been created.
8519 BRD WITH OWT Allow the passenger to board as The passenger cannot be permitted to NO YES B
long as they have an onward board unless they possess a ticket for an (exclusive)
ticket. onward journey from New Zealand. An
expected movement record has been
created.
8520 CONTACT NZIS Do not allow the passenger to An expected movement record has not NO YES D
board been created. However, all the required (exclusive)
data is available for the passenger. The
Check-in agent must seek advice from the
Advance Passenger Screening (APS)
Support Office, NZIS, Auckland, New
Zealand (Tel: +64-9-277-1250). If
permission to board the passenger is given,
an override code of “G” must be used.
APPENDIX B
Error
Description
Code
5001 Valid family name required
5002 Valid given names or ‘-‘ required
5003 Valid nationality required
5004 Valid document number required
5005 Valid document expiry date required
5006 Valid date of birth required
5007 Valid country of birth required
5008 Valid sex code required
5009 Valid document type required
5010 Document number must be blank if document type is “N”
5051 More input lines expected
5056 Illegal Message Type/Sub-Type received from AP
5057 No response from APP System (xx/tt/yy). Please try again later.
5067 Not allowed as primary transaction
5068 Too many check-in locations open
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
Error
Description
Code
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
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
5534 Expected port country not consistent with international flight
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/Crew Indicator invalid
5541 Document check character does not match Document Number
5542 Supplementary document type invalid
5543 Supplementary document check character does not match document number
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 airport not authorised to process transaction
5552 Flight not in airline schedules
5554 Check-in port code invalid
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
Error
Description
Code
5565 APP not required for transits at this time
5566 APP not required for document types ‘O’ or ‘N’ at this time
5571 Given names contain invalid characters
5572 Issuing state invalid
5573 Document expiry date invalid
5574 Transit at origin flag invalid
5575 Transit 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
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
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
Error
Description
Code
5615 Flight already loaded
5616 PNR record locator invalid
1. These are all errors which may be passed back to the airline in CIRS or CICC
messages.
3. 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.
Error Used By
Description
Code AU NZ
6000 Validation error – unknown field Yes Yes
6001 Invalid family name format Yes Yes
6002 Given names format invalid Yes Yes
6003 Invalid nationality code Yes Yes
6004 Invalid sex code Yes Yes
6005 Invalid visa type Yes
6006 Invalid middle name Yes
6007 Invalid airline code Yes
6009 Invalid expiry date Yes Yes
6010 Invalid country code Yes
6013 Invalid evidence number Yes
6015 Invalid date of birth Yes Yes
6016 Date of birth outside allowable range Yes Yes
6017 Expiry date outside allowable range Yes Yes
6018 Invalid arrival date Yes
6019 Arrival date outside allowable range Yes
6020 Invalid country code for country of birth Yes Yes
6022 ETA not implemented for airline Yes
6033 Invalid passport number format Yes Yes
6036 Invalid scroll direction Yes
6037 Invalid scroll hours Yes
6040 Valid credit card holder name required Yes
6041 Valid credit card expiry date required Yes
6042 Valid credit card number required Yes
6045 Invalid movement type code. Must either be 'AP', ‘ST’ or ‘IT’. Yes Yes
6046 Check-in port required Yes Yes
6047 Check-in flight required Yes Yes
6048 Check-in date invalid Yes Yes
6049 Check-in time invalid Yes Yes
6050 Trans-border port not a valid airport code Yes Yes
6051 Trans-border flight not given Yes Yes
6052 Trans-border date invalid Yes Yes
6053 Trans-border time invalid Yes Yes
6054 Expected port not a valid airport code Yes Yes
6055 Expected flight required Yes Yes
Error Used By
Description
Code AU NZ
6056 Expected date invalid Yes Yes
6057 Expected time invalid Yes Yes
6058 Passenger sequence number required Yes Yes
6059 Pax/Crew indicator invalid. Must be ‘P’, ‘C’ or ‘X’ only. Yes Yes
6060 Expected direction invalid. Must be ‘I’, ‘O’ or ‘T’ only. Yes Yes
6061 Supplementary document type invalid Yes Yes
6062 Travel document type invalid Yes Yes
6063 Endorsement code invalid. Must either be ‘ ‘ (a space) or ‘S’. Yes Yes
6064 Neither travel nor supplementary document information was sent Yes
6065 Invalid multiple response flag Yes Yes
6066 Invalid Print Arrival/Departure Card flag Yes Yes
6067 Invalid User Id Yes Yes
6068 Expected Passenger ID is null Yes Yes
6069 Expected Passenger ID is not numeric Yes Yes
6070 Expected Passenger ID is not unique Yes Yes
6071 Invalid transaction source flag Yes Yes
6072 Invalid departure port Yes Yes
6073 Invalid departure flight Yes Yes
6074 Invalid departure date Yes Yes
6075 Invalid departure time Yes Yes
6076 Invalid issuing state code Yes Yes
6077 Invalid transit flag Yes Yes
6078 Invalid override flag Yes Yes
6079 Invalid international flight board point Yes Yes
6080 Invalid international flight off point Yes Yes
6081 Invalid message version Yes Yes
6082 Override code supplied not valid in these circumstances Yes Yes
6900 System maintenance in progress. Please try again later. Yes Yes
6910 Invalid message format. Error code 2 will be the field number in Yes Yes
error.
6920 Unknown AP error – Error number not known Yes Yes
6980 Duplicate Message ID Yes Yes
6981 Unknown Message Type/Sub-type Yes Yes
6982 Message ID active. Need to use previous logical transaction Yes Yes
Message ID.
6983 Invalid Message ID. Need to use previous logical transaction Yes Yes
Message Id.
6984 System error with alert check Yes Yes
6985 Duplicate Message ID. Message ID has been used by another Yes Yes
User.
6987 No History or scrolling outside range Yes Yes
Error Used By
Description
Code AU NZ
6998 AP Error: PRO*C Failed Yes Yes
6999 AP Error: PL/SQL Failed Yes Yes
1. These are all errors which may be passed back to the airline in CIRS or CICC
messages.
3. 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 in Atlanta.
APPENDIX C
MANUAL MAINTENANCE
OF FLIGHT SCHEDULES
Purpose
This is a special facility for the APP System only. By use of a command line interface, an
airline can add unscheduled flights to the airline schedules held on the APP Communications
Gateway (i.e. the CG located in Atlanta).
Security Access
Any authorised airline user who has normal APP transaction access can use this facility.
Procedures
There are three procedures: display an existing flight schedule, load a new flight schedule and
delete a flight schedule.
a) Command format:
b) Example input:
TIETAYT D/AO7913 [INPUT]
Key to example
TIETAYT Name of the function
D Required option (D for Display)
A07913 Flight Number
c) Example output:
SCHED. FOR AO7913 EFF. 10/27/02-10/25/03 FREQ. 1234567
a) Command format:
TIETAYT A/{flight no}/{effective date}/{discontinue date}/{frequency}/
b) Example input:
TIETAYT A/SQ888/01JUN02/30OCT02/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)
01JUN02 The effective date SYD The first arrival port
30OCT02 The discontinue date 1115 The local departure time from this port
13567 The frequency (1=Monday, 7=Sunday, etc) 1305 The local arrival time at the next port
LAX The origin port MEL The second arrival port
c) Notes on Usage
i) Any number of intermediate ports can be provided for a flight, but most unscheduled
international flights will have only origin and destination ports.
ii) The date variation element is required only if the date differs from the date of
departure from the origin port.
iii) When normal airline schedules are updated on the APP System, any manually
maintained flight schedules will be overwritten and thus deleted. This update occurs
once a week (Friday morning 03:00hrs, Atlanta time). An airline must therefore
repeat the process of loading a schedule if it is needed beyond this weekly cycle.
iv) An airline can only load and display flights which are operated by itself or its code
share partners.
a) Command format:
TIETAYT X/{flight no}/{effective date}/{discontinue date}/{frequency}
[INPUT]
b) Example input:
TIETAYT X/SQ888/01JUN02/30OCT02/13567
[INPUT]
Key to example
TIETAYT Name of the function
X The required option (X for Delete)
SQ888 The flight to be deleted
01JUN02 The effective date
30OCT02 The discontinue date
13567 The frequency (1=Monday, 7=Sunday, etc)
APPENDIX D
GUIDELINES FOR
IMPLEMENTING
INTEGRATED APP
a) General
1. The implementation approach used for APP is one that airlines are familiar with. See
Figure 13 below for a diagram which shows an overview of this process.
3. The CPS Implementation Manager coordinates a team of technical staff (both CPS
Systems and SITA) to assist with the implementation.
4. The CPS Implementation 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 CPS Implementation 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, including both the Communications Gateway (CG) in Atlanta and
the Application Processor (AP) in Sydney.
7. Airlines are able to conduct unlimited 24*7 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.
b) 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.
2. If the airline needs to install a new SITA circuit for APP access, CPS Systems 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
requirements. CPS Systems 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. CPS Systems will advise SITA’s Implementation Coordinator in Atlanta that a new
airline is implementing APP. For new circuit connections the SITA Implementation
Coordinator will forward the Airline/CG 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 Implementation Coordinator
in Atlanta prior to APP Test System access being granted. (See section (g) below for a
sample of this).
5. When the airline has returned the completed questionnaire and Airline Agreement to
SITA in Atlanta, SITA will provide APP Test System access to that airline and will
advise the airline when this access is available.
The SITA Implementation Coordinator will also provide to the airline contact details of
SITA technical staff in Atlanta who can assist with network and APP application
connection issues. From this point the airline may commence testing to the APP
Communications Gateway (CG) in Atlanta and the APP Applications Server (AP) in
Sydney.
c) Development Phase
1. The government agrees a schedule with airlines, and then provides the CPS
Implementation Manager with the rollout schedule.
2. The CPS Implementation 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 CPS Implementation Manager makes weekly email
contact with the airlines to monitor project progress and to offer assistance if required.
The CPS Implementation 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.
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 CPS
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 in Atlanta).
4. The airline can conduct unlimited testing on a 24*7 basis. All problems encountered or
queries about APP functionality during testing should be forwarded to the CPS
Implementation Manager for resolution.
5. When test transactions have been sent, the CPS Implementation 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.
2. When an airline has tested the application satisfactorily it contacts the CPS
Implementation Manager and requests permission to cutover to production.
3. The CPS Implementation 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 CPS Implementation Manager within 48 hours whether the
test has been successful. When a formal signoff has been received from the government
representative, the CPS Implementation Manager will authorise SITA to provide APP
Production System access for that airline. The CPS Implementation 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”.
Approval for this testing will be requested through the CPS Implementation 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 CPS Implementation Manager before the airline
can cutover to production.
f) 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
CPS Implementation 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 CPS Implementation Manager arranges for the airline’s parameters to be loaded in
the production Communications 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 CPS Implementation Manager monitors the airline’s cutover progress, providing
regular status updates to the government.
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:
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:
h) Contact Details
Decision
Airline decides to
Government CPS provides
implement APP,
advises CPS of Interface
START and agrees
the airline's specification to
timetable with
rollout schedule. airline.
government.
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
NO
System
Testing Airline
CPS provides
undertakes Airline is ready for
airline with
testing with acceptance
access to test
support from testing?
system.
CPS.
YES
NO
Acceptance
Testing Airline
CPS provides
undertakes
Acceptance sign- acceptance
acceptance
off by Government testing
testing with
and CPS? specification to
support from
airline.
CPS.
YES
Production
Airline carries out
live APP
END
transactions for
flights.
APPENDIX E
The following table lists all of the data fields in the PRQ data group of the CIRQ message and
shows which fields must be provided to the government systems of Australia and New
Zealand. The differences between the two 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 on the government database, then it must be
captured by the airline according to the rules in Table 26 below.
PRQ Data Item Field in Mandatory for Mandatory for
Ref. MRZ? New Zealand? Australia?
4 Pax/Crew Indicator Yes Yes
2
5 Passport Country Code (Nationality) Yes Yes Yes
2 3
6 Issuing State Yes Yes No1, 3
2 3
7 Passport ID/Document ID Yes Yes Yes3
8 Passport/Document Check Character Yes2 No No
9 Travel Document Type Yes Yes
2 3
10 Travel Document Expiry Date Yes Yes No1, 3
11 Supplementary Document Type [Not currently used]
12 Supplementary Document ID [Not currently used]
13 Supplementary Doc Check Character [Not currently used]
14 Family Name Yes2 Yes Yes
2 4
15 Given Names Yes Yes Yes4
16 Date of Birth Yes2 Yes Yes
2
17 Sex Yes Yes Yes
18 Country of Birth Code No No
19 Holder/Endorsee No No
Notes:
1
While this data item is not required for Australia, for uniformity of processing between countries, it is
recommended that it be provided in all cases.
2
If a passport reader is being used, it is recommended that all these data items be supplied in the CIRQ
message.
3
Required if passenger holds travel document and data item is on document.
4
Mandatory if passenger has given names.