APP Guideline

Advance Passenger Processing System
Airline/CG Interface Specification
Author(s): Philip Gould, Richard Wood

CPS Systems Pty Ltd
Version: 6.3
22 October 2003
© CPS Systems Pty Ltd 2003

Commercial-in-Confidence
© 2003 CPS Systems Pty Limited. All Rights Reserved
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.
DOCUMENT FILING DETAILS

Location of File l:\bordersystems\etas-apc\intapp\int63.doc
Date of File 22 October 2003
AMENDMENT RECORD
Ensure dates entered here are fixed dates, not dates that will change with the saving and printing of the
document.
Ver Date Section Amended Description of significant changes,
affected by and/or significance of new version
0.1 08 Apr 98 All RW/JTL First draft for review by CPS Systems and airlines.
0.2 12 May 98 4 JTL Changes made to the Airline/RCS message format
1.0 26 Jun 98 4 RW Handling of chartered and unscheduled flights.
2.0 12 Nov 98 All JTL Introduction of Check-in Message Code (mostly country
independent). A section on various example messages for
different scenario/cases was also added. And beginning with
this version, it has been modified to make it a government-
neutral document.
2.1 20 Nov 98 5 JTL Addition of the Airline Private Data field in all the messages
between the Airline and RCS within the Transaction Group.
2.11 07 Jan 99 All IR/JVL Corrections were made to document formats and data
consistency.
2.20 15 Mar 99 5&B JTL Maximum length of the Passenger Error Message Text and
Error Message Text has been increased to 60 characters.
Action required for 8504, 8511, 8513 Check-in Message Code
expanded to include the words – DO NOT BOARD.
Modify the message of Error Code 5540. The slash was taken
away in the message text since the slash character was being
used as the field separator. New Error Codes 5563, 5564, 5565,
5566, 5567, 5568 and 5569 were added.
Error Code 5058 was deleted from this document.
2.30 21 May 99 2, 6, 7 & JTL New sections were added:
B ♦ HTH communication requirements for accessing the
Integrated APP System.
♦ Expected Passenger ID encoding location in the Express
Lane Passenger Card was added.
Error Codes 6065, 6066, 6067 and 6988 were added.
Action required for 8504 Check-in Message Code revised while
Check-in Message Code was made conditional in a CIRS and
CICX message.
Commercial-in-Confidence V6.3 (22-October-2003) Page 3

Ver Date Section Amended Description of significant changes,

affected by and/or significance of new version
2.4 24 Apr 00 5&8 JTL Correct the example given in 8.1.2.3.
Specify more clearly that the delimiter character to be used
after the transaction code must be the colon character instead of
the usual field delimiter such as slash.
2.5 18 May 00 7 JTL The 15-digit Expected Passenger ID is now to be encoded three
times on the following positions:
- Track 4, Block 1, Column 1
2.6 27 Jun 00 8 JTL Add an example of a complete message including message
header.
2.7 21 Jul 00 5&8 JTL Travel Document Type has been made an optional field in all
the messages. This is in fact stating what is currently in the
production system and has always been even in the examples
given in section 8.
Correct the example given in 8.2 which was using the incorrect
“PRX” Group Identifier. The correct Group Identifier is
“PCX”.
2.8 25 Sep 00 7 JTL Re-arrange section 7 to include a new topic on printing of
passenger details on the Passenger Card.
2.9 24 Oct 00 Title RDW Correction of copyright notices and formatting
Pages
3.0 17 Nov 00 Appndx JVL Correction to message code 8503 & 8512 descriptions “Not
A used in Australia”
3.1 21 Feb 01 8 JVL Correction of some of the examples.
3.2 12 Oct 01 8 RDW Add examples for data sharing
3.3 13 Nov 01 8 RDW Add further examples of data sharing when multiple
passengers.
4.0 27 Aug 02 All JVL Removed references to passenger arrival card.
5.0 22 Nov 02 All PJG Complete revision for Mandatory APP (Australia).
6.0 10 Feb 03 All RDW Revision for the full implementation of Mandatory APP for
Australia and the implementation of APP for New Zealand.
Generalisation of the interface to cater for multiple countries
for a single journey. Alter terminology: RCS becomes
Communications Gateway (CG), RPS becomes Application
Processor (AP).
6.1 04 Mar 03 3, 5, 6, RDW Section 3: Addition of more detail on error handling.
App A. Section 5: Addition of Check-in Port to CIRQ message,
correction of limits on Passenger Sequence Number values,
clarification of handling of Travel Document Type,
modification of values of Override Flag, addition of Passenger
Status code of “E”.
Section 6: Addition of Check-in Port to examples, removal of
8500 code from examples, correction of use of error codes.
Appendix A: Passenger Status defined for 8508, 8509

6.2 09 Apr 03 3, 5, 6, RDW Section 3: Reduce number of occurrences of PRS in CIRS

App A message to 10. Additional rules for handling CIRS message in
Table 10.
Section 5: Change to override flag handling in CIRQ message
(Table 19 – Override Codes). Clarification of Participating
Country code in Error Group of CIRS (Table 20) and CICC
(Table 22).
Section 6: Correction to example 10. Additional examples with
override codes used (Section 6.1.6).
Appendix A: Change to Passenger Status codes in Table 23.
6.3 22 Oct 03 2, 3, 4, 5, RDW Section 2: Additional information on categories of crew
6, App (Section 2.2). Further information on data requirements
A, B, D, (Section 2.6 inserted). Explanation of transit processing
E (Section 2.9 inserted).
Section 3: Modify sex code to handle unspecified (Table 8).
Correction of errors in description of override codes,
introduction of Passenger Status Code for Timeout and
explanation of automatic cancellation when inconsistent
responses between countries (Section 3.2.5 including Table 10).
Introduction of Passenger Status Code for Timeout and
explanation of inconsistent responses between countries
(Section 3.4.5 including Table 14).
Section 4: Minor adjustments to returned codes.
Section 5: Adjust notes for Check-in Flight Group Identifier
and Passenger Sequence Number, modify Passenger/Crew
Indicator to allow for positioning crew, modify validation of
document type vs. document number, clarify optionality of bio-
data elements, expand sex code to allow for unspecified (Table
19). Adjust notes for Passenger Sequence Number, modify
Passenger/Crew Indicator to allow for positioning crew, expand
sex code to allow for unspecified, add Passenger Status Code of
Timeout (Table 20). Adjust notes for Passenger Sequence
Number, modify Passenger/Crew Indicator to allow for
positioning crew, expand sex code to allow for unspecified
(Table 21). Adjust notes for Passenger Sequence Number,
modify Passenger/Crew Indicator to allow for positioning crew,
expand sex code to allow for unspecified, add Passenger Status
Code of Timeout (Table 22).
Section 6: Add more cross-references to Figures. Remove
redundant CHK data group from many examples. Remove
Examples 5 and 20. Correct or expand on Examples 9, 10, 15,
16, 19 and 24 (new numbers). Add examples for transits and
timeouts.
Appendix A: Update check-in message codes (Table 23).
Appendix B: Update error codes (Tables 24, 25).
Appendix D: Update contact details.
Appendix E: Replace expected movement record content with
specification of bio-data requirements for Australia and New
Zealand.


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.3 MESSAGE TYPE: MOVEMENT CANCELLATION (CICX) .............................................36
3.3.1 Purpose ........................................................................................................ 36


3.4 MESSAGE TYPE: MOVEMENT CANCELLATION CONFIRMATION (CICC)....................38
3.4.1 Purpose ........................................................................................................ 38
4 DIALOGUE TYPES ..............................................................................................43
4.1 CHECK-IN REQUEST (SIMPLE)...................................................................................43
4.2 CHECK-IN REQUEST (DUPLICATES)...........................................................................43
4.3 CHECK-IN REQUEST (ERROR: INCORRECT DATA SUPPLIED) .....................................44
4.4 CANCELLATION REQUEST (SIMPLE)..........................................................................44
4.5 CANCELLATION REQUEST (ERROR: NO MOVEMENT EXISTS)....................................45
4.6 CANCELLATION REQUEST (ERROR: INCORRECT DATA SUPPLIED) ............................45
5 MESSAGE FORMATS .........................................................................................47
5.1 OVERALL MESSAGE STRUCTURE ..............................................................................47
5.1.1 Rules for Layer 7.......................................................................................... 47
5.1.2 Rules for Body of Message........................................................................... 48
5.1.3 Rules for Layer 5 Address ............................................................................ 48
5.2 MESSAGE TYPE: CHECK-IN REQUEST (CIRQ) ..........................................................49
5.3 MESSAGE TYPE: CHECK-IN RESPONSE (CIRS) .........................................................55
5.4 MESSAGE TYPE: MOVEMENT CANCELLATION (CICX) .............................................60
5.5 MESSAGE TYPE: MOVEMENT CANCELLATION CONFIRMATION (CICC)....................64
6 MESSAGE EXAMPLES.......................................................................................69
6.1 CHECK-IN EXAMPLES ................................................................................................69
6.1.1 One Single Passenger (simple end-to-end journey)..................................... 69
EXAMPLE 1: Passenger located (OK to board) ................................................................. 69
EXAMPLE 2: Passenger not located or does not have a valid visa/ETA............................ 70
EXAMPLE 3: Passenger located (both governments responded) ....................................... 70
EXAMPLE 4: Special handling (airline can handle duplicate name).................................. 71
EXAMPLE 5: Error condition (passport format error)........................................................ 71
EXAMPLE 6: Error condition (system error) ..................................................................... 72
EXAMPLE 7: CIRQ message supplies complete passport details ...................................... 72
6.1.2 Multiple Passengers ..................................................................................... 73
EXAMPLE 8: All passengers successfully processed ......................................................... 73
EXAMPLE 9: Not all passengers processed successfully ................................................... 73
EXAMPLE 10: Some passengers not uniquely identified................................................... 74
6.1.3 Different Trans-Border and Expected Port (same scheduled flight) ........... 75
EXAMPLE 11: Different trans-border and expected port (same scheduled flight)............. 75
6.1.4 Different Trans-Border and Expected Port (different flights) ..................... 76
EXAMPLE 12: Different trans-border and expected port (different scheduled flights)...... 76
6.1.5 Unscheduled or Delayed Flight ................................................................... 77
EXAMPLE 13: Unscheduled flight: simple end-to-end journey......................................... 77
EXAMPLE 14: Unscheduled flight: different trans-border and expected port.................... 77
6.1.6 Overriding a Boarding Directive ................................................................. 79

EXAMPLE 15: Passenger requires override for one country.............................................. 79

EXAMPLE 16: Multiple passengers, one requiring override for both countries................. 80
6.1.7 Transit on Change of Flight......................................................................... 82
EXAMPLE 17: Passenger in transit during change of flight............................................... 82
6.1.8 Transit on Single Flight ............................................................................... 84
EXAMPLE 18: Passenger in transit on single flight ........................................................... 84
6.1.9 Timeout......................................................................................................... 85
EXAMPLE 19: Timeout on one government system .......................................................... 85
EXAMPLE 20: Timeout on both (all) government systems................................................ 85
6.2 MOVEMENT CANCELLATION EXAMPLES ...................................................................86
6.2.1 Cancel Movement for a Single Passenger ................................................... 86
EXAMPLE 21: Cancellation: passenger located ................................................................. 86
EXAMPLE 22: Cancellation: passenger not located........................................................... 86
EXAMPLE 23: Cancellation: error condition (passport format error) ................................ 87
6.2.2 Cancel Movements for Multiple Passengers................................................ 88
EXAMPLE 24: Cancellation: multiple passengers.............................................................. 88
6.3 COMPLETE MESSAGE SAMPLE (INCLUDING MESSAGE HEADER) ................................89
EXAMPLE 25: Complete CIRQ message........................................................................... 89
A. APPENDIX: CHECK-IN MESSAGE CODES...................................................92
B. APPENDIX: APP SYSTEM ERROR CODES ...................................................96
C. APPENDIX: MANUAL MAINTENANCE OF FLIGHT SCHEDULES.......104
D. APPENDIX: GUIDELINES FOR IMPLEMENTING INTEGRATED APP 108
E. APPENDIX: PASSENGER DATA REQUIREMENTS ..................................116

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
1.1 Purpose of this Document

The purpose of this document is to provide a specification of the messages and processing for
the Integrated APP Implementation.
The APP (Advance Passenger Processing) System provides a message-based interface

between an airline system and the Communications Gateway (CG), previously referred to as
the Request Capture System (RCS), which is the common communications hub of both the
Electronic Travel Authority (ETA) System and the APP System. This interface is known as
the Integrated APP Implementation.
1.2 Scope of this Document

There are two implementations of APP for airlines: Stand-alone and Integrated.
• Stand-alone APP is similar in appearance to the ETA system in that it provides

formatted screens for users to complete. It is also known as “Interim APP” in Australia.
• Integrated APP is a message-based interface, which an airline uses to allow its DCS to
interact with the APP System (via the CG).
The scope of this document is to assist the airlines in their implementation of the Integrated
APP option. It sets out the messaging requirements between the airline DCS and the CG in
Atlanta. It does not attempt to offer any advice on how an airline should integrate APP
transactions within its DCS, and therefore does not cover either the airline check-in process,
or the airline process for offloading passengers, and neither does it say anything about the
user interface for these processes.
Note on the Extension of the APP System to other Governments
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.3 Document Audience

This document is intended primarily for the following users:
• Information Technology department, relevant airline

• Passenger Services department, relevant airline
This document may also be useful for the following users:
• Immigration Department, APP-participating countries

• CG Development Team, SITA Atlanta
• AP Development Team, CPS Systems Pty Ltd.
1.4 Related Documents

• Specification for the Implementation of the IATA Host-to-Host Protocol
• Advance Passenger Processing Business System Design (note that this document is not
available to airlines)
• APP – Interim Training Manual (for Stand-alone APP)
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 john.leplaw@cps.com.au or philip.gould@cps.com.au

2 Concepts and Terminology
2.1 Overview of API and APP

Over the last two decades, various governments have attempted to improve border security
and facilitate passenger processing at the border with the use of passenger information
obtained in advance of passengers arriving at the border. Such passenger information is
known as Advance Passenger Information (API).
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.
2.2 Characteristics of APP

Basic Requirement
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.
Specifically, the APP System provides functions to:
• 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:
• Interactively check both individuals and travel documents

• Use pre-registered, validated data for API when available
• Capture API when passengers have not been pre-registered
• Handle both inbound and outbound passenger movements
• Handle both ends of an international journey and transit points (i.e. for two or more
governments) in a single transaction
• Handle multiple individual passengers in a single transaction (except for the screen-
based implementation option that can handle only one passenger per transaction)
• Handle multiple passengers on a single passport in a single transaction when the airline
has the capacity to accept the multiple passenger response (except for the screen-based
implementation option where the input data provided must uniquely identify a single
individual).
Special Travel Documents
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
The APP System handles various categories of passenger:
• Holders of passports from the APP country

• Holders of passports from a country with a special relationship to the APP country
• Visa-free passengers, who are not required to have pre-approved visas to travel to the
APP country
• Visaed passengers
• Special category passengers, many of whom are holders of the special travel documents
listed above.
• Different countries will have different requirements with respect to special categories of
traveller.

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.
Access to Passenger Data
The key used for identifying passengers as part of APP processing consists of the passport
number (i.e. travel document number), nationality and name.
2.3 Overall APP Architecture

The following diagram (Figure 1) shows the overall architecture of the APP System, and how
it functions as a link between airlines and governments.
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
Figure 1 – Overall APP Architecture

As the diagram shows the APP System exists as a “bridge” between airline systems and
government systems.
There is a Communications Gateway (CG) in Atlanta (previously known as the RCS –

Request Capture System), and there are Application Processors (AP) in different countries
(previously known as the RPS - Request Processing 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.
When an AP provides a positive boarding directive for a passenger, it then constructs an

expected movement record for the relevant government and sends this direct (as an individual
message) to the government system.
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).
2.4 Roles of the Airline DCS and the APP System

This specification defines the message formats for the following transactions and responses
generated between an airline DCS and the APP System:
• Passenger check-in request

• Passenger check-in request response (boarding directive)
• Cancellation of expected movement
• Cancel expected movement response
Information may be returned from the government systems at both ends of an international
journey and at transit points.
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:
• All screen-based transaction input and output.

• All logic associated with the generation of the data into the defined interface messages
and interpretation of return messages.
• Error and contingency handling when error status messages are returned by the
interface.
• Production of any printed documents that may be required to support the airline’s
check-in operations and subsequent processing of the passenger by border authorities
remains the responsibility of the airline. Specifically, if endorsement of a boarding pass
is part of the airline’s procedures, then the airline DCS must perform this function.

2.5 Data Requirements

As part of APP, advance passenger information (API) is supplied to the border agencies of
one or more governments. This API takes the form of an Expected Movement Record
(EMR), the format of which varies for different governments. The data items in the EMR
may be divided into two categories:
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.
2.6 Passenger Data Requirements for APP

The APP System delivers data on intending travellers to a participating government at the
time a passenger checks in for a flight. For this operation to be effective at check-in, the APP
System would ideally already hold data on the passenger. Such data would be in the form of
a database of passports and visas for the country concerned. Where such data exists, the
check-in agent need only enter enough data to identify the passenger in the database (typically
passport number, nationality, family name or part thereof). The system can then supply the
remainder of the passenger data from the database. This pre-registered data is likely to be of
higher quality than, for example, data collected in the process of making airline reservations.
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 Flight Models

The flight data requirements of the APP System are based upon a flight model that may
involve up to three separate flights and four separate ports. Note that these concepts are as
used by border authorities, and the discussion of them here does not imply that providing all
of this data is a requirement of an airline.
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
Figure 2 – APP Flight Model (Inbound)

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
Figure 3 - APP Flight Model (Outbound)
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)
Table 1 – Port Definitions

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)
Table 2 – Flight Definitions
2.8 Flight Data Requirements for APP

To simplify and minimise the flight data that must be entered by check-in staff or provided by
airline systems, and to facilitate the handling of APP for more than one country on an
international journey, the concept of the International Flight is used. The International Flight
is defined as the flight which takes the passenger from the country at the start of an
international journey to the country at the end of an international journey and for which APP
transactions must be generated eg. the Los Angeles to Sydney flight in Figure 2.
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.
Table 3 – Rules for Flight Data
2.9 Transit Passengers

Governments using the APP System may require airlines to process transit passengers through
the system.
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.
Two types of transit passenger can be handled.
• Transit at Start or End of International Flight

When a passenger will arrive in an APP-participating country on one flight and leave on
another flight without entering the country or after entering the country under transit
rules, this situation must be explicitly indicated to the APP System.
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.
For example, a passenger is intending to travel on flight EK410 from Dubai to

Auckland via Singapore and Sydney. The passenger’s ticket and the check-in process
are related to the Dubai to Auckland flight and not to Singapore or Sydney.
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.

2.10 Special Circumstances
2.10.1 Unscheduled Flights
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.
Rules for Handling Unscheduled Flights

Unscheduled flights can be handled using the Integrated APP Implementation. The following
rules apply:
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.
Table 4 - Rules for Handling Unscheduled Flights

Alternative Handling for Unscheduled Flights

If the airline DCS implementation of Integrated APP cannot handle unscheduled flights using
the Scheduled/Unscheduled flight flag on a CIRQ message as described above or the
unscheduled flight transits an intermediate country which is an APP participant, use the
following procedure:
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.
Table 5 - Alternative Method of Handling Unscheduled Flights
NOTE on Stand-alone APP Implementation
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).

2.10.2 Code Share Flights
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.
Rules for Handling Code Share Flights

Code share flights can be handled using the Integrated APP Implementation. The following
rules apply:
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.
Table 6 - Rules for Handling Code Share Flights
2.10.3 Data Sharing Between APP Countries
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 Message Type: Check-in Request (CIRQ)
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 message is used under two different circumstances:
• To notify the details of one or more passengers checking in for a flight.

• In some cases, the initial Check-in Request (CIRQ) Message will result in a Check-in
Response (CIRS) message indicating that one or more of the sets of passenger data
input has identified more than one passenger on the visa or passport database. In these
cases, the Check-in Request (CIRQ) Message is also used to indicate which of the
passengers are actually travelling. (See further the section on Dialogue Types below,
section 4).
3.1.2 Message Structure
The following diagram (Figure 4) shows the overall structure of the CIRQ message:
Check-in Request CIRQ

Transaction Field count: 6
CIRQ Header Instances: 1
(Mandatory)
CHK INT EXO/EXD TBO/TBD PRQ

Check-in International Expected Trans-border Passenger
Flight Flight Flight Flight Request
(Optional) (Mandatory) (Conditional) (Conditional) (Mandatory)
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
Figure 4 - Overall Structure of CIRQ Message

3.1.3 Message Construction
The body of the message contains the data groups listed in Table 7.
Data group Group Number of Notes

ID occurrences
Transaction None Always 1 Includes the transaction indicator (CIRQ) to identify the function
being performed.
Check-in CHK 0 or 1 While this data group is technically optional, border control
Flight authorities prefer it to be supplied. It is the flight on which the
passenger is checking in when advance passenger information is
collected.
International INT Always 1 The flight on which the passenger is crossing the international
Flight border.
Expected EXO or 0,1 or 2 Data group EXO refers to the outbound flight. It is required only if
Flight EXD the government of the country is a participant in APP and the
passenger is not processed through the border at the origin of the
International Flight.
Data group EXD refers to the inbound flight. It is required only if
the government of the country is a participant in APP and the
passenger is not processed through the border at the destination
of the International Flight.
Trans-Border TBO or 0,1 or 2 TBO refers to the outbound flight. It is required only if the
Flight TBD government of the country is a participant in APP and the
International Flight is an unscheduled flight for which the Trans-
Border port is not the origin of the International Flight.
TBD refers to the inbound flight. It is required only if the
government of the country is a participant in APP and the
International Flight is an unscheduled flight for which the Trans-
Border port is not the destination of the International Flight.
Passenger PRQ 1 to 5 Includes biodata and document data for each passenger. Note
Request (see the note that with endorsees on passports, more than one passenger may
below on be associated with one data group.
numbers)
Table 7 – Message Construction for Check-In Request (CIRQ)
3.1.4 Message Processing
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.
Note on the number of passengers in the CIRQ message
In theory, the format of the CIRQ message would allow data on up to 999 passengers to be
provided in a single message. However, the limitation on message size between the 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).
3.1.5 Recommended Airline Implementation
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.
Table 8 - Rules for Implementing CIRQ Message

Note on flight dates
The APP System only allows transactions on flights within the following time window:
[- 2 days] TODAY [+ 10 days]
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 Message Type: Check-in Response (CIRS)
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.
See further the section on Dialogue Types below (section 4).
The following diagram (Figure 5) shows the overall structure of the CIRS message:
Check-in Response CIRS

CIRS Transaction Field count: 2
Header Instances: 1
(Mandatory)
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
Figure 5 - Overall Structure of CIRS Message

The body of the message contains the data groups listed below in Table 9.

ID occurrences
Transaction None Always 1 Includes the transaction indicator (CIRS) to identify the function
being performed.
Passenger PRS 0 to 10 The expanded data retrieved from the database of a government
Response system. There may be more than one of these data groups per
passenger when several countries involved in an International
Flight are APP System participants.
NOTE: There The data group allows for two types of status code:
must be either
at least one Check-in Message Code and Passenger Status Code which
PRS or one indicate whether or not the passenger is known to the government
ERR group in system and the action to be taken for the passenger (i.e. the
the message. directive).
Passenger Error Code which indicates specific data problems with
the passenger data supplied.
Error ERR 0 or 1 Serious errors that preclude further processing of passengers for
one of the participating countries are included in this data group.
Each error is related to the participating government system.
Table 9 – Message Construction for Check-In Response (CIRS)
The following notes apply to the further processing of response messages:
Case Situation
Case 1 The passenger has been matched in the database and the Check-in Message Code indicates the
action specified by the government for that passenger. An expected movement has been created.
The DCS can continue to process the passenger for boarding.
Case 2 The passenger has not been matched in the database and the Check-in Message Code indicates the
action specified by the government for that passenger. The passenger is eligible to board. An
expected movement has been created. The DCS can continue to process the passenger for
boarding.
Case 3 The passenger has 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.
I Insufficient data is available for an assessment to be made. It must be captured before

the passenger can be assessed by the system.
T The APP System for the country has not responded within the timeout period
specified. No directive from the country can be returned to the check-in agent.
E An error condition has been detected. All error conditions must be corrected before
processing can be completed for the passengers represented in the message.
The actions recommended above must be performed under the control of the DCS as follows:
• Display error conditions to the user and allow the user to correct the error conditions.

• 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.
It is strongly recommended that airlines implement the CIRS message as follows:

No Rule Notes
1 If the CIRS 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 CIRS message includes a Passenger These errors are normally of a less serious nature.
Response (PRS) data group that includes an
error message, the error message is displayed
to the user for correction and resubmission.
3 The CIRS message includes a Passenger Before deciding to proceed with passenger processing
Status Code returned by each country for each without receiving directives from a government, the
passenger. check-in agent must:
If the CIRS message for one or more Ensure that this is not a transient problem by
countries returns a status of “T”, the APP attempting the transaction again.
Systems for those countries are not
responding i.e. timing out.
Contact government agencies of each country
affected, inform them of the situation and obtain
If the problem persists, processing can permission to continue boarding passengers.
continue. The rules in paragraph 4 below The government systems of countries unaffected by the
should be followed. timeouts will continue to receive the correct data on
expected passenger movements.
4 The combination of Passenger Status Codes The only circumstance when a passenger may be
(not including occurrences of Timeout “T” which boarded is when all countries respond with a status of
are ignored) determines the action that can be “B”. In all other circumstances, the check-in agent
taken. must take further action.
If all values are “B”, boarding for the Before overriding a directive from a government
passenger may continue. system, the check-in agent must:
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.
Table 10 - Rules for Implementing CIRS Message

3.3 Message Type: Movement Cancellation (CICX)
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:
Movement Cancellation CICX

CICX Transaction Field count: 6
Header Instances: 1
(Mandatory)
INT PCX
International Movement
Flight Cancellation
(Mandatory) (Mandatory)
Field count: 10 Field count: 22

Instances: 1 Instances: 1-10
Figure 6 - Overall Structure of CICX Message

ID occurrences
Transaction None Always 1 Includes the transaction indicator (CICX) to identify the function
being performed.
International INT Always 1 The flight on which the passenger is crossing the international
Flight border and on which they were originally checked in.
Movement PCX 1 to 10 Includes biodata and document data for each passenger. Note
Cancellation that only one passenger may be associated with one data group.
Table 11 – Message Construction for Movement Cancellation (CICX)

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.
Note on the number of passengers in the CICX message
In theory, the format of the CICX message would allow data on up to 999
passengers to be provided in a single message. However, the limitation on
message size between the 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.
Table 12 - Rules for Implementing CICX Message

3.4 Message Type: Movement Cancellation Confirmation (CICC)
3.4.1 Purpose
This message is used to send a response to a Movement Cancellation (CICX) from the CG to
the airline DCS.
The message is used to return a mix of the following types of information:
Case Situation
Case 1 When a set of passenger data has been uniquely matched against expected movements in a
government system and a corresponding acknowledgement for the passenger can be returned.
Case 2 When a set of passenger data has not been matched against expected movements in a government
system and a corresponding acknowledgement for the passenger cannot be returned.
Case 3 When an error has been detected in a set of passenger data and must be corrected before further
processing for the passenger concerned.
Case 4 When an error that precludes any further processing of the original message for a specific country is
identified.
The following diagram (Figure 7) shows the overall structure of the CICC message:
Cancellation Confirmation CICC

Transaction Field count: 2
CICC Header Instances: 1
(Mandatory)
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
Figure 7 - Overall Structure of CICC Message


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

Cancellation Confirmation (CICC)
The following notes apply to the further processing of response messages:
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.
Table 14 - Rules for Implementing CICC Message

[This page deliberately left blank]

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.
4.1 Check-in Request (Simple)

This is the simplest and most common APP dialogue. A check-in request is made for one or
more passengers, and a boarding directive is received for each of these passengers. Note that
the directive may be positive (“OK to Board”) or negative (“Do not Board”).
Dialogue Structure
Message Message from DCS Message from 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.
4.2 Check-in Request (Duplicates)

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

4.3 Check-in Request (Error: Incorrect Data Supplied)

If a check-in transaction is attempted with incorrect data, an error code will be included in the
response. When the request is resubmitted with correct data, and the passenger(s) can be
correctly identified and/or assessed, the response will contain a directive for each passenger.
Dialogue Structure
no
2 CIRS (eg. error code 8516 “Insufficient Data”)
3 CIRQ (corrected data)
4 CIRS (a directive for each pax)
4.4 Cancellation Request (Simple)

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

4.5 Cancellation Request (Error: No Movement Exists)

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

This type of dialogue will occur when the check-in agent does not supply the correct data to
identify a passenger who has already been APP processed and has an expected movement
record that needs to be cancelled.
Dialogue Structure
no
2 CICC (eg. error code 8506 “No Record” )
3 CICX (corrected data)
4 CICC (an acknowledgement for each pax)


5 Message Formats
5.1 Overall Message Structure

When an airline chooses to implement Advance Passenger Processing (APP) integrated with
its Departure Control System (DCS), data will be exchanged between the DCS and the CG
using messages that conform to SITA’s version of the IATA Host to Host Protocol (HTH).
Within the HTH standard, the following rules will apply:
5.1.1 Rules for Layer 7
Airlines must implement Layer 7 of the message in the following way:
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.
Table 15 - Rules for Implementing Layer 7 of a Message
Data item Data Mandatory/ Usage notes

type/size optional
Airline Code X(3) Mandatory IATA Airline Code.
Country Code A(2) Mandatory IATA Country Code.
City Code X(5) Mandatory IATA City Code or Pseudo City Code.
IATA Agency X(8) Optional Although this data is optional, the airline must be able to identify
Identifier the source of the transaction.
Screen Size N(5) Not This field is not required for Integrated APP since no data is
required directly displayed on the user screen by the APP System.
Table 16 –Layer 7 Data Items in the APP Message

5.1.2 Rules for Body of Message
Airlines must implement the body of the message in the following way:
No Rule Notes
1 Comply with the specific usage set out in the 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).
Table 17 – Rules for Body of Message
5.1.3 Rules for Layer 5 Address
In order to access the appropriate version of the Integrated Advance Passenger Processing
application, airlines must implement Layer 5 addressing in the message with the following
value:
Production Version Demo/Test Version

5APPXS 5APTXS
Table 18 – Layer 5 Addresses for APP Messages

5.2 Message Type: Check-in Request (CIRQ)

The following table (Table 19 – Message Layout for Check-in Request) provides the layout for the CIRQ message. A field number within each
data group is supplied only for ease of reference, and these numbers are not used within the messages.
Data group No Data item Data Mandatory/ Value Notes

type/ optional
size
Transaction 1 Transaction Code A(4) Mandatory “CIRQ” Must be followed by colon.
2 Airline Private X(14) Optional Free for use by the airline for reference This data is returned to the airline in the response
Data purposes. message (CIRS). For example, it could be used to
store the Airline Source Transaction ID.
3 User ID X(6) Mandatory Airline user identifier
4 Handle Multiple A(1) Mandatory “Y” = the user location can handle duplicate If “Y”, the CG will return duplicate names (if applicable)
Response names (endorsees). for the user to select one.
“N” = the user location cannot handle If “N”, the CG will return only an error code (if
duplicate names. applicable).
5 Unused data item A(1) Not required Field no longer used (Previously was Print
Arrival/Departure Card)
6 Message Version N(3) Mandatory Indicates the format of the following Set to “20” for messages conforming to this
message. specification.
Check-in 1 Check-in Flight A(3) Conditional “CHK” Must be provided if the Check-in Flight is not the same
Flight Group Identifier as the International Flight.
2 Check-in Flight N(2) Conditional Number of fields which follow in this data Set to 2 for current message definition.
Group Field Count group. Conditional (required if this group is present)
3 Check-in Port X(5) Conditional IATA Airport Code eg. SYD
Conditional (required if this group is present)
4 Check-in Flight X(8) Conditional Airline and flight number. eg. BA031
Conditional (required if this group is present)


type/ optional
size
International 1 International Flight A(3) Mandatory “INT”
Flight Group Identifier
2 International Flight N(2) Mandatory Number of fields which follow in this data Set to 8 for current message definition.
Group Field Count group.
3 Scheduled/ A(1) Mandatory “S” = Scheduled Flight “Unscheduled” means delayed, charters, etc.
Unscheduled “U” = Unscheduled Flight
Flight
4 International Flight X(8) Mandatory Airline and flight number eg. BA031
5 International Flight X(5) Mandatory IATA Airport Code eg. SIN
Origin
6 International Flight X(5) Mandatory IATA Airport Code eg. SYD
Destination
7 International Flight N(8) Mandatory CCYYMMDD eg. 20021105
Date
8 International Flight N(6) Conditional HHMMSS eg. 105500
Time Conditional (required for unscheduled flight)
9 International Flight N(8) Conditional CCYYMMDD eg. 20021105
Arrival Date Conditional (required for unscheduled flight)
Arrival Time Conditional (required for unscheduled flight)
Expected 1 Expected Flight A(3) Conditional “EXO” = Expected Flight data for country of A separate Expected Flight Group may be present for
Flight Group Identifier origin of international movement. each end of an international movement.
(repeating) “EXD” = Expected Flight data for country of Conditional (if the passengers do not embark on or
destination of international movement. disembark from the International Flight at the port
where they clear Customs and Immigration i.e. the
Expected Port, this data group is required).
2 Expected Flight N(2) Conditional Number of fields which follow in this data Set to 4 for current message definition.
Group Field Count group. Conditional (required if this group is present)


type/ optional
size
3 Expected Port X(5) Conditional IATA Airport Code. Conditional (required if this group is present)
4 Expected Flight X(8) Conditional Airline and flight number. Conditional (required if this group is present)
5 Expected Date N(8) Conditional CCYYMMDD Conditional (required if this group is present)
6 Expected Time N(6) Conditional HHMMSS Conditional (required if this group is present)
Trans-Border 1 Trans-Border A(3) Conditional “TBO” = Trans-Border Flight data for A separate Trans-Border Flight Group may be present
Flight Flight Group country of origin of international movement for each end of an international movement.
(repeating) Identifier “TBD” = Trans-Border Flight data for Conditional (if the international flight is not a scheduled
country of destination of international flight and the Trans-Border Ports are not the origin
movement and/or destination of the International Flight, this data
group is required)
2 Trans-Border N(2) Conditional Number of fields which follow in this data Set to 3 for current message definition.
Flight Group Field group. Conditional (required if this group is present)
Count
3 Trans-Border Port X(5) Conditional IATA Airport Code. Conditional (required if this group is present)
4 Trans-Border N(8) Conditional CCYYMMDD Conditional (required if this group is present)
Date
5 Trans-Border N(6) Conditional HHMMSS Conditional (required if this group is present)
Time
Passenger 1 Passenger A(3) Mandatory “PRQ”
Request Request Group
(repeating Identifier
2 Passenger N(2) Mandatory Number of fields which follow in this data Set to 22 for current message definition.
Request Group group.
Field Count
3 Passenger N(3) Mandatory The sequence number of the passenger in A maximum of five occurrences of this data group can
Sequence the message. be included in each message. The value of the
Number Passenger Sequence Number can be in the range 1 to
999.


type/ optional
size
4 Pax/Crew A(1) Mandatory “P” = Passenger
Indicator “C” = Operating crew
“X” = Positioning crew
5 Passport Country A(3) Mandatory Nationality of passenger. eg. NZL
Code Country code (ICAO [3-character code] or Note that the ICAO 3-character code set has one code
IATA [2-character code]). of length one character i.e. “D” – Germany.
6 Issuing State A(3) Conditional Country code (ICAO [3-character code] or Optional for a check-in enquiry. Required if the
(see Notes) IATA [2-character code]) passenger is not previously known so data must be
captured, and the passenger holds a travel document
that indicates Issuing State.
Note that the ICAO 3-character code set has one code
of length one character i.e. “D” – Germany.
7 Passport ID X(14) Conditional Passport or other travel document number eg. N364028
Conditional (required if Document Type is “P”, must be
blank if Document Type is “N”).
It should be provided if available.
8 Passport Check X(1) Optional Value taken from MRZ
Character
9 Travel Document A(1) Optional “P” = Passport (Default) Defaults to “P” if not given.
Type “O” = Other travel document
“N” = No travel document
10 Travel Document N(8) Conditional CCYYMMDD Eg. 20080328
Expiry Date (see Notes) Optional for a check-in enquiry. Required if the
passenger is not previously known so data must be
captured, and the passenger holds a travel document
that indicates Expiry Date.
11 Supplementary A(2) Optional Code to identify the type of an additional/ Not currently used.
Document Type alternative document being used.


type/ optional
size
12 Supplementary X(14) Optional Number of the supplementary document. Not currently used.
Document ID
13 Supplementary X(1) Optional Value taken from MRZ Not currently used.
Doc. Check
Character
14 Family Name X(24) Mandatory Family name. Full name if less than 4 characters, otherwise at least 4
characters. Can include spaces between names.
If the passenger is not previously known, the full family
name will need to be provided.
For countries where the passports have only one long
name eg. Malaysia, the “family name” will need to be
differentiated from the “given names”.
If the family name is longer than 24 characters, the first
24 characters should be entered.
15 Given Names X(24) Optional Given name(s). Can include spaces between names.
(see Notes) If the given names are longer than 24 characters, the
first 24 characters should be entered.
Optional for a check-in enquiry. Required if the
passenger is not previously known so data must be
captured and the passenger has given names. Should
be supplied if available.
16 Date of Birth N(8) Conditional CCYYMMDD Optional for a check-in enquiry. Required if the
(see Notes) passenger is not previously known so data must be
captured. Should be supplied if available.
17 Sex A(1) Conditional “M” = Male Optional for a check-in enquiry. Required if the
(see Notes) “F” = Female passenger is not previously known so data must be
captured. Should be supplied if available.
“X” = Unspecified
18 Country of Birth A(3) Optional Country code (ICAO [3-character code] or Note that the ICAO 3-character code set has one code
Code IATA [2-character code]). of length one character i.e. “D” – Germany.


type/ optional
size
19 Holder/ A(1) Optional Blank for passport holder
Endorsee “S” = Endorsee
20 Transit at Origin A(1) Optional “Y”, “N”. Set to “Y” if passenger is in transit at origin of
If not given, treated as “N”. International Flight.
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)
Table 19 – Message Layout for Check-in Request (CIRQ)

5.3 Message Type: Check-in Response (CIRS)

The following table (Table 20 – Message Layout for Check-in Response) provides the layout for the CIRS message. A field number within each
data group is supplied only for ease of reference, and these numbers are not used within the messages.
If passenger information is present in the response, the order of the passenger data will be by Passenger Sequence Number, with the outbound
country response first, followed by transit country responses in their order on the flight, followed by the inbound country response.

type/ optional
size
Transaction 1 Transaction Code A(4) Mandatory “CIRS” Must be followed by colon.
2 Airline Private X(14) Optional Airline reference Any data that was originally given in the CIRQ will be
Data echoed back here.
Passenger 1 Passenger A(3) Conditional “PRS” Conditional (required if no ERR data group is present)
Response Response Group
(repeating) Identifier
Response Group group.
Field Count
3 Passenger N(3) Mandatory The sequence number of the passenger in Corresponds to the sequence number in the CIRQ
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.


type/ optional
size
7 Issuing State A(3) Optional Country code (ICAO [3-character code] or Note that the ICAO 3-character code set has one code
IATA [2-character code]) of length one character i.e. “D” – Germany.
Should be included if known.
8 Passport ID X(14) Optional Passport or other travel document number eg. N364028
Character
10 Travel Document A(1) Mandatory “P” = Passport
11 Travel Document N(8) Optional CCYYMMDD eg. 20080328
Expiry Date Should be included if known.
12 Supplementary A(2) Optional Code to identify the type of an additional/ Not currently used.
13 Supplementary X(14) Optional Number of the supplementary document. Not currently used.
Document ID
14 Supplementary X(1) Optional Value taken from MRZ Not currently used.
Doc. Check
Character
15 Family Name X(24) Optional Family or full name of the passenger Should be included if known.
or
X(60)
16 Given Names X(24) Optional Will be Null if Family Name field is more Should be included if known.
than 24 characters in length.
17 Date of Birth N(8) Optional CCYYMMDD Should be included if known.


type/ optional
size
18 Sex A(1) Optional “M” = Male Should be included if known.
“F” = Female
19 Country of Birth A(3) Optional Country code (ICAO [3-character code] or Should be included if known.
Code IATA [2-character code]). Note that the ICAO 3-character code set has one code
20 Holder/ A(1) Optional Blank for passport holder Should be included if known.
21 Check-in N(4) Mandatory Check-in message code for the passenger. Will have the value of "0000" should there be any error
Message Code detected in the passenger data that was supplied or
there was a timeout.


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


type/ optional
size
Code 3
Error Group 1 Error Group A(3) Conditional “ERR” Conditional (required if no PRS data group is present)
(contains a Identifier
repeating
2 Error Group Field N(2) Conditional Number of fields which follow in this data i.e. the number of Participating Country fields, Error
sub-group)
Count group. Code fields and Error Message Text fields.
Conditional (required if this group is present).
The following three fields are repeated for each error message returned.
3 Participating A(2) Conditional IATA Country Code of the participating eg. AU

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

5.4 Message Type: Movement Cancellation (CICX)

The following table (Table 21 – Message Layout for Movement Cancellation) provides the layout for the CICX message. A field number within
each data group is supplied only for ease of reference, and these numbers are not used within the messages.

type/ Optional
size
Transaction 1 Transaction Code A(4) Mandatory “CICX” Must be followed by colon.
2 Airline Private X(14) Optional Free for use by the airline for reference This data is returned to the airline in the response
Data purposes. message (CICC). For example, it could be used to
store the Airline Source Transaction ID.
3 User Id X(6) Mandatory Airline user identifier
4 Handle Multiple A(1) Mandatory “Y” = the user location can handle duplicate If “Y”, the CG will return duplicate names (if applicable)
Response names (endorsees). for the user to select one.
“N” = the user location cannot handle If “N”, the CG will return only an error code (if
duplicate names. applicable).
5 Unassigned data A(1) Not required Field no longer used (previously was Print
item Arrival/Departure Card Number)
6 Message Version N(3) Mandatory Indicates the format of the following Set to “20” for messages conforming to this
message specification.
International 1 International Flight A(3) Mandatory “INT”
Flight Group Identifier
2 International Flight N(2) Mandatory Number of fields which follow in this data Set to 8 for current message definition.
Group Field Count group.
3 Scheduled/ A(1) Mandatory “S” = Scheduled Flight “Unscheduled” means delayed, charters, etc.
Unscheduled “U” = Unscheduled Flight
Flight
4 International Flight X(8) Mandatory Airline and flight number eg. BA031
5 International Flight X(5) Mandatory IATA Airport Code eg. SIN
Origin


type/ Optional
size
6 International Flight X(5) Mandatory IATA Airport Code eg. SYD
Destination
7 International Flight N(8) Mandatory CCYYMMDD eg. 20021105
Date
Time Conditional (required for unscheduled flight)
9 International Flight N(8) Conditional CCYYMMDD eg. 20021105
Arrival Date Conditional (required for unscheduled flight)
Arrival Time Conditional (required for unscheduled flight)
Passenger 1 Passenger A(3) Mandatory “PCX”
Cancellation Cancellation
(repeating) Group Identifier
Cancellation group.
Group Field Count
3 Passenger N(3) Mandatory The sequence number of the passenger in A maximum of ten occurrences of this data group can
Sequence the message. be included in each message. The value of the
Number Passenger Sequence Number can be in the range 1 to
999.
4 Expected N(15) Conditional Unique passenger identifier. Should be included if known.
Passenger ID Conditional (required if passenger biodata is not
supplied)


type/ Optional
size
8 Passport ID X(14) Conditional Passport or other travel document number eg. N364028
Conditional (required if Document Type is “P”).
It should be provided if available.
Character
10 Travel Document A(1) Optional “P” = Passport (Default) Defaults to “P” if not given.
Expiry Date
12 Supplementary A(2) Optional Used to identify the type of an additional/ Not currently used.
13 Supplementary X(14) Optional Document number Not currently used.
Document ID
14 Supplementary X(1) Optional Value taken from MRZ. Not currently used.
Doc. Check
Character
15 Family Name X(24) Conditional Family name Not required if Expected Passenger Id is provided.
Otherwise, full name if less than 4 characters,
otherwise at least 4 characters.
16 Given Names X(24) Optional Given name(s) Can include spaces. Not used if Expected Passenger
Id is provided.
17 Date of Birth N(8) Optional CCYYMMDD Not used if Expected Passenger Id is provided.


type/ Optional
size
18 Sex A(1) Optional “M” = Male Not used if Expected Passenger Id is provided.
“F” = Female
19 Country of Birth A(3) Optional Country code (ICAO [3-character code] or Not used if Expected Passenger Id is provided.
20 Holder/ A(1) Optional Blank for passport holder Not used if Expected Passenger Id is provided.
21 Transit at Origin A(1) Optional “Y”, “N”. Default is “N”. Set to “Y” if passenger is in transit at origin of
International Flight.
22 Transit at A(1) Optional “Y”, “N”. Default is “N”. Set to “Y” if passenger is in transit at destination of
Destination International Flight.
Table 21 – Message Layout for Movement Cancellation (CICX)

5.5 Message Type: Movement Cancellation Confirmation (CICC)

The following table (Table 22 – Message Layout for Movement Cancellation Confirmation) provides the layout for the CICC message. A field
number within each data group is supplied only for ease of reference, and these numbers are not used within the messages.
If passenger information is present in the response, the order of the passenger data will be by Passenger Sequence Number, with the outbound
country response first, followed by transit country responses in their order on the flight, followed by the inbound country response.
type/ optional
size
Transaction 1 Transaction 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
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.


type/ optional
size
8 Passport ID X(14) Optional Passport or other travel document number eg. N364028
Character
10 Travel Document A(1) Mandatory “P” = Passport
Expiry Date Should be included if known.
12 Supplementary A(2) Optional Used to identify the type of an additional/ Not currently used.
13 Supplementary X(14) Optional Document number Not currently used.
Document Id
14 Supplementary X(1) Optional Value taken from MRZ. Not currently used.
Doc. Check
Character
15 Family Name X(24) Optional Family or full name of the passenger Should be included if known.
or
X(60)
16 Given Names X(24) Optional Given name(s) of the passenger. Should be included if known.
17 Date of Birth N(8) Optional CCYYMMDD Should be included if known.


type/ optional
size
18 Sex A(1) Optional “M” = Male Should be included if known.
“F” = Female
19 Country of Birth A(3) Optional Country code (ICAO [3-character code] or Should be included if known.
20 Holder/Endorsee A(1) Optional Blank for passport holder Should be included if known.
“S” = Endorsee
21 Check-in N(4) Conditional Check-in message code for the passenger. Will have the value of "0000" should there be any error
Message Code detected in the passenger data that was supplied or
there was a timeout.
22 Passenger Status A(1) Mandatory Status of passenger with respect to the Indicates the overall status of the passenger and what
Code check-in process for this country: action can be taken for the APP country in field 4.
C = Cancelled
N = Not found
T = Timeout
E = Error condition detected.
Code 1
Code 2
Code 3


type/ optional
size
Error Group 1 Error Group A(3) Conditional “ERR” Conditional (required if no PCC data group is present)
(contains a Identifier
repeating
sub-group) 2 Error Group Field N(2) Conditional Number of fields which follow in this data i.e. the number of Participating Country fields, Error
Count group. Code fields and Error Message Text fields.
Conditional (required if this group is present).
The following three fields are repeated for each error message returned.
3 Participating A(2) Conditional IATA Country Code of the participating 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).
Table 22 – Message Layout for Movement Cancellation Confirmation (CICC)


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.
6.1 Check-in Examples
6.1.1 One Single Passenger (simple end-to-end journey)
The following seven examples relate to a single passenger on a simple end-to-end journey and
are illustrated by Figure 8.
Malaysia
Kuala Lumpur
Australia
Sydney
Figure 8 – Flight BA033 (KUL-SYD)
EXAMPLE 1: Passenger located (OK to board)

Airline to CG (CIRQ Message)
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.]
CG to Airline (CIRS 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.
EXAMPLE 2: Passenger not located or does not have a valid visa/ETA

PRQ/22/1/P/USA//Z4351213///////SMIT///////////
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.
EXAMPLE 3: Passenger located (both governments responded)

[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///////////
[CG sends 5-1 message to AP-MY and AP-MY 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.

EXAMPLE 4: Special handling (airline can handle duplicate name)

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]
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).
EXAMPLE 5: Error condition (passport format error)

PRQ/22/1/P/USA//351213///////SMIT///////////
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.

EXAMPLE 6: Error condition (system error)

PRQ/22/1/P/USA//351213///////SMIT///////////
CIRS:/ERR/3/AU/6999/AP ERROR: PL-SQL FAILED/
A serious error (code 6999) occurred on the AP, and the passenger request was not processed.
The check-in agent should resubmit the request.
EXAMPLE 7: CIRQ message supplies complete passport details

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.
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.
This is therefore the recommended implementation of the CIRQ message.

6.1.2 Multiple Passengers
The following three examples relate to multiple passengers in the same check-in request and
are illustrated by Figure 8.
EXAMPLE 8: All passengers successfully processed

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.
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.
EXAMPLE 9: Not all passengers processed successfully

PRQ/22/1/P/USA//Z4351213///////SMIT///////////
PRQ/22/2/P/USA//Z43547///////SMIT///////////
submitted by the airline.
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.
EXAMPLE 10: Some passengers not uniquely identified

PRQ/22/1/P/NZL//Z4351213///////SMIT///////////
PRQ/22/2/P/NZL//Z4354888///////SMIT///////////
submitted by the airline. The airline has indicated that it cannot accept responses for more
than one passenger in the response to an enquiry on a passenger.
CIRS:/PRS/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.

6.1.3 Different Trans-Border and Expected Port (same scheduled flight)
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
Australia Expected Port
Sydney
Melbourne
Trans-Border Port
Figure 9 – Flight QF016 (BKK-MEL-SYD)
EXAMPLE 11: Different trans-border and expected port (same scheduled flight)
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]
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.

6.1.4 Different Trans-Border and Expected Port (different flights)
The following example relates to a single passenger on a multi flight journey and is illustrated
by Figure 10.
Chicago
Los Angeles
Sydney
Melbourne
Figure 10 – Multi-Leg Journey (CHI-LAX-SYD-MEL)
EXAMPLE 12: Different trans-border and expected port (different scheduled

flights)
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]
SAMANTHA/19640912/F/USA//8501/B/2128666///////
passenger listing CHI as the check-in port, SYD as the trans-border port, and MEL as the
expected port.

6.1.5 Unscheduled or Delayed Flight
The following two examples relate to a single passenger on unscheduled flights and are
illustrated by Figure 8.
EXAMPLE 13: Unscheduled flight: simple end-to-end journey

CIRQ:/123456/N//20/INT/8/U/BA033D/KUL/SYD/19981101/081500/
19981101/195500/PRQ/22/1/P/USA//Z4351213///////SMIT///////////
The airline submits a request for a passenger on an international flight flagged as

“Unscheduled”, and with the flight number BA033D showing “D” for delayed. Full details of
the date and time of departure and arrival are included.
[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]
SAMANTHA/19640912/F/USA//8501/B/2128666///////
passenger, including the full flight details as advised by the airline.
EXAMPLE 14: Unscheduled flight: different trans-border and expected port

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///////////
The airline submits a request for a passenger on an international flight flagged as

“Unscheduled”, and with the flight number QF016D showing “D” for delayed. Full details of
the date and time of departure and arrival are included. Since the flight actually has the route
BKK-MEL-SYD (in which MEL is the trans-border port, and SYD is the expected port for
this passenger), the airline has also provided (in the “TBD” [trans-border destination] data
group) the date and time for MEL.
[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]

SAMANTHA/19640912/F/USA//8501/B/2128666///////
passenger, including the full flight details as advised by the airline.

6.1.6 Overriding a Boarding Directive
The following two examples relate to overriding boarding directives from one or more
countries and are illustrated by Figure 8.
EXAMPLE 15: Passenger requires override for one country

PRQ/22/1/P/USA//Z4351213///////SMIT///////////
SAMANTHA TAYLOR SMITH//19640912/F/USA//8501/B////////
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.
PRQ/22/1/P/USA//Z4351213///////SMIT////////GAU///

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
PRQ/22/1/P/USA//Z4351213///////SMIT///////////
PRQ/22/2/P/USA//Z4354753///////SMIT///////////
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.

PRQ/22/1/P/USA//Z4354753///////SMIT////////AMYGAU///
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.

6.1.7 Transit on Change of Flight
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
Los Angeles USA
QF302
QF107
Australia
Sydney
Transit Airport
Figure 11 – Multi-Flight Journey (BKK-SYD-LAX)
EXAMPLE 17: Passenger in transit during change of flight

[Note: This example assumes that only Australia is an APP country]
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.
SAMANTHA/19640912/F/USA//8501/B/2128666///////
The AP has confirmed that the passenger is permitted to transit Australia and has given code
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.
SAMANTHA/19640912/F/USA//8501/B/2128777///////
The AP has confirmed that the passenger is permitted to board the flight and has given code
government indicating that the passenger will be departing after having been in transit in
Sydney.

6.1.8 Transit on Single Flight
The following example relates to a passenger in transit on a single international flight and is
Check-in Port
Thailand
Bangkok
Los Angeles USA
TG398
TG398
Australia
Sydney
Transit Airport
Figure 12 – Transit on Single Fight (BKK-SYD-LAX)
EXAMPLE 18: Passenger in transit on single flight

[Note: This example assumes that only Australia is an APP country]
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.
SAMANTHA/19640912/F/USA//8501/B/2128888///////
The AP has confirmed that the passenger is permitted to transit Australia and has given code
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.
EXAMPLE 19: Timeout on one government system

PRQ/22/1/P/USA//Z4351213///////SMIT///////////
[CG sends 5-1 message to AP-AU and AP-AU does not respond.]
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.
EXAMPLE 20: Timeout on both (all) government systems

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.]
CIRS:111/ERR/3//5057/NO RESPONSE FROM APP SYSTEM. PLEASE TRY

AGAIN LATER.
The CG responds with an error message indicating that both (all) government systems timed
out.

6.2 Movement Cancellation Examples
6.2.1 Cancel Movement for a Single Passenger
The following four examples relate to cancellation of APP for a single passenger and are
EXAMPLE 21: Cancellation: passenger located

Airline to CG (CICX Message)
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.]
CG to Airline (CICC Message)
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.
EXAMPLE 22: Cancellation: passenger not located

/P/USA//Z4351213///////SMIT////////
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).
EXAMPLE 23: Cancellation: error condition (passport format error)

/P/USA//Z43512///////SMIT////////
family name (in part), but without the Expected Passenger ID.
(“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).

6.2.2 Cancel Movements for Multiple Passengers
The following example relates to cancellation of APP for multiple passengers and is
EXAMPLE 24: Cancellation: multiple passengers

/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.
(“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.

6.3 Complete Message Sample (including message header)
EXAMPLE 25: Complete CIRQ message

Below is an example of a complete CIRQ message, including the Layer 5 and Layer 7
message headers, from ZZ airline:
562E0D56 484C472E 57412F45 31415054 5A5A2F49
V . . V H L G . W A / E 1 A P T Z Z / I
35415054 58532F50 30303039 0D56475A 0D565A5A

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

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

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

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

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

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

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

7 0 1 1 2 / M / / / / / / / / .


APPENDIX A
CHECK-IN MESSAGE CODES

A. Appendix: Check-in Message Codes

The table below (Table 23) lists the possible message codes to be generated by the CG on check-in (or cancellation) together with the short
message (limited to 22 characters) that is to be displayed on the user’s screen in Stand-alone APP. The table also gives an expanded description
of the meaning of the message and the action to be taken.
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.
Table 23 - Check-in Message Codes


APPENDIX B
APP SYSTEM ERROR CODES

B. Appendix: APP System Error Codes

1. CG Error Codes
The table below (Table 24) contains error codes originating from the CG.
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
Table 24 – CG Error Codes
Notes on Error Codes:
1. These are all errors which may be passed back to the airline in CIRS or CICC
messages.
2. The airline system should display the code to the user.
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.

2. AP Error Codes (Australia and New Zealand)

The table below (Table 25) contains error codes originating from the Australian and New
Zealand APs.
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
Table 25 – AP Error Codes (AU and NZ)
Notes on Error Codes:
1. These are all errors which may be passed back to the airline in CIRS or CICC
messages.
2. The airline system should display the code to the user.
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

C. Appendix: 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.
1. Display a Flight Schedule
a) Command format:
TIETAYT D/{flight number} [INPUT]
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
FROM TO DEPT. ARR.
CNS AU KIX JP 1230 1915
**** END OF SCHEDULE ****

2. Load a Flight Schedule
a) Command format:
TIETAYT A/{flight no}/{effective date}/{discontinue date}/{frequency}/
{origin port}/{local departure time}/{local arrival time}+1/{arrival port 1}/

{local departure time}+1/{local arrival time}+1/{arrival port 2} [INPUT]
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.

3. Delete a Flight Schedule
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

D. Appendix: 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.
2. CPS Systems assigns an Implementation Manager as a single point of contact to

coordinate an airline’s implementation of APP. Currently this role is performed by
Mr John Leplaw.
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.
Note on APP and ETAS

If an airline is currently ETA capable and will be accessing APP via the same host
communications environment, the same SITA link can be used for both ETAS and APP
access. There is therefore no need for any duplication of communications links.

2. If the airline needs to install a new SITA circuit for APP access, 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.

d) System Testing Phase

1. The airline is notified of the procedures involved in satisfying government requirements
for acceptance testing.
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.
e) Acceptance Testing Phase

1. Prior to the acceptance test phase it is recommended that the airline activate a network
layer connection from their production environment. This will identify any production
network connectivity issues that can be resolved well before cutover to production.
2. When an airline has tested the application satisfactorily it contacts the 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.
5. All post-cutover APP issues determined to be non-airline related should be escalated to

the CPS Implementation Manager for investigation.

g) SITA HTH Questionnaire for New Connections

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

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

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

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

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

h) Contact Details
CPS Implementation Manager

Mr. John Leplaw Email: jl@cps.com.au
Telephone: +61-2-9909 3022
Facsimile: +61-2-9953 8083
SITA Implementation Coordinator

Mr. Kenneth Hulse Email: Kenneth.Hulse@sita.aero
Telephone: +1-770-612 2388
Facsimile: +1-770-303 3639
Australian APP Coordinator (DIMIA)

Mr. Adrian Kelson Email: Adrian.kelson@immi.gov.au
Telephone: +61-2-6264 1124
Facsimile: +61-2-6264 1879
New Zealand APP Coordinator (NZIS)

Lee Wilson Email: Lee.Wilson@nzis.dol.govt.nz
Telephone: +64 -9-918 4447
Facsimile: +64 -9-914 4119
i) Overview of the Implementation Process

The diagram on the next page (Figure 13) provides a summary of the implementation process.

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
Cutover Airline changes

CPS provides message header
airline with parameter
access to (switching
production transactions to
system. production
system).
Production
Airline carries out
live APP
END
transactions for
flights.
Figure 13 – Implementation Process for Integrated APP

APPENDIX E
PASSENGER DATA REQUIREMENTS

E. Appendix: Passenger Data Requirements

The passenger data provided to a government by APP can come from two sources:
• from the government system itself (if a record is already held on the passenger)
• from the airline (by capturing all the required data at check-in, or earlier).
Governments differ in what passenger data they require.
The following table lists 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.
Table 26 – Passenger Data Requirements (AU and NZ)

APP Guideline

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

APP Guideline

Uploaded by

Copyright:

Available Formats

Advance Passenger Processing System

Airline/CG Interface Specification

Author(s): Philip Gould, Richard Wood

© CPS Systems Pty Ltd 2003

DOCUMENT FILING DETAILS

Commercial-in-Confidence V6.3 (22-October-2003) Page 3

Ver Date Section Amended Description of significant changes,

Commercial-in-Confidence V6.3 (22-October-2003) Page 4

6.2 09 Apr 03 3, 5, 6, RDW Section 3: Reduce number of occurrences of PRS in CIRS

Commercial-in-Confidence V6.3 (22-October-2003) Page 5

Commercial-in-Confidence V6.3 (22-October-2003) Page 6

Commercial-in-Confidence V6.3 (22-October-2003) Page 7

3.3.2 Message Structure........................................................................................ 36

Commercial-in-Confidence V6.3 (22-October-2003) Page 8

EXAMPLE 15: Passenger requires override for one country.............................................. 79

Commercial-in-Confidence V6.3 (22-October-2003) Page 9

Commercial-in-Confidence V6.3 (22-October-2003) Page 10

1.1 Purpose of this Document

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

1.2 Scope of this Document

• Stand-alone APP is similar in appearance to the ETA system in that it provides

Note on the Extension of the APP System to other Governments

Commercial-in-Confidence V6.3 (22-October-2003) Page 11

1.3 Document Audience

• Information Technology department, relevant airline

• Immigration Department, APP-participating countries

1.4 Related Documents

Commercial-in-Confidence V6.3 (22-October-2003) Page 12

2 Concepts and Terminology

2.1 Overview of API and APP

2.2 Characteristics of APP

Specifically, the APP System provides functions to:

Commercial-in-Confidence V6.3 (22-October-2003) Page 13

• Interactively check both individuals and travel documents

The APP System handles various categories of passenger:

• Holders of passports from the APP country

Commercial-in-Confidence V6.3 (22-October-2003) Page 14

Access to Passenger Data

2.3 Overall APP Architecture

Figure 1 – Overall APP Architecture

There is a Communications Gateway (CG) in Atlanta (previously known as the RCS –

Commercial-in-Confidence V6.3 (22-October-2003) Page 15

When an AP provides a positive boarding directive for a passenger, it then constructs an

2.4 Roles of the Airline DCS and the APP System

• Passenger check-in request

• All screen-based transaction input and output.

Commercial-in-Confidence V6.3 (22-October-2003) Page 16

2.5 Data Requirements

2.6 Passenger Data Requirements for APP

Commercial-in-Confidence V6.3 (22-October-2003) Page 17

2.7 Flight Models

Figure 2 – APP Flight Model (Inbound)

Commercial-in-Confidence V6.3 (22-October-2003) Page 18

Figure 3 - APP Flight Model (Outbound)

Table 1 – Port Definitions

Commercial-in-Confidence V6.3 (22-October-2003) Page 19

Table 2 – Flight Definitions

2.8 Flight Data Requirements for APP

Commercial-in-Confidence V6.3 (22-October-2003) Page 20

Table 3 – Rules for Flight Data

2.9 Transit Passengers

Two types of transit passenger can be handled.

• Transit at Start or End of International Flight

Commercial-in-Confidence V6.3 (22-October-2003) Page 21