advance passenger processing system airline/cg...

Author(s): Philip Gould, Richard Wood CPS Systems Pty Ltd

Version: 6.3 22 October 2003

© CPS Systems Pty Ltd 2003 Commercial-in-Confidence

Advance Passenger Processing System

Airline/CG Interface Specification

© 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 affected

Amended by

Description of significant changes, 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 & B

JTL New sections were added: ♦

♦

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)


Ver Date Section affected

Amended by

Description of significant changes, 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 - Track 4, Block 2, Column 1 - Track 4, Block 3, 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 Pages

RDW Correction of copyright notices and formatting

3.0 17 Nov 00 Appndx A

JVL Correction to message code 8503 & 8512 descriptions “Not 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, App A.

RDW Section 3: Addition of more detail on error handling. 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, App A

RDW Section 3: Reduce number of occurrences of PRS in CIRS 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, 6, App

A, B, D, E

RDW Section 2: Additional information on categories of crew (Section 2.2). Further information on data requirements (Section 2.6 inserted). Explanation of transit processing (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.2.2 Message Structure........................................................................................ 31 3.2.3 Message Construction.................................................................................. 32 3.2.4 Message Processing ..................................................................................... 32 3.2.5 Recommended Airline Implementation ........................................................ 33

3.3 MESSAGE TYPE: MOVEMENT CANCELLATION (CICX) .............................................36 3.3.1 Purpose ........................................................................................................ 36



3.3.2 Message Structure........................................................................................ 36 3.3.3 Message Construction.................................................................................. 36 3.3.4 Message Processing ..................................................................................... 37 3.3.5 Recommended Airline Implementation ........................................................ 37

3.4 MESSAGE TYPE: MOVEMENT CANCELLATION CONFIRMATION (CICC)....................38 3.4.1 Purpose ........................................................................................................ 38 3.4.2 Message Structure........................................................................................ 38 3.4.3 Message Construction.................................................................................. 39 3.4.4 Message Processing ..................................................................................... 39 3.4.5 Recommended Airline Implementation ........................................................ 40

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 [email protected] or [email protected]



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.

RCSCommunications

Gateway(ATL)

AirlineDeparture

ControlSystem

Airportcheck-inagent

Country A BorderControlSystem

expected movements

boarding requests, cancellations

boarding directives, cancellation acknowledgements

RPSCountry A

Application Processor

RPSCountry B

Application Processor

expected movements

boarding requests

boarding requests

boarding directives

Country B BorderControlSystem

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 data

This data relates to the passport and biodata for the passenger.

Flight data

This data relates to the international movement being undertaken by the 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.

Expected Port

Trans-Border Port

Check-in Port

Sydney

Melbourne

Los Angeles

Vancouver

Trans-Border Flight

Check-in Flight

Expected Flight

Figure 2 – APP Flight Model (Inbound)



Below in Figure 3 there is an example of the ports and flights for outbound passengers.

Expected Port

Trans-Border Port

Sydney

Melbourne

Los Angeles

Check-in Port

PerthCheck-in Flight

Expected Flight

Trans-Border Flight

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 inbound view

AU outbound view

Check-in port

The port at which a passenger commences an international movement and at which advance passenger information for the passenger is collected.

This will be a foreign port (eg. YVR)

This will be an Australian port (eg. PER)

Trans-border port

The Trans-border Port is defined as: The first port in a country at which a passenger arrives when travelling to that country, or 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.

This will be an Australian port (eg. SYD)

This will be an Australian port (eg. SYD)

Expected port

The port at which a passenger will be cleared by Customs and Immigration for movement into or out of a country.

This will be an Australian port (eg. MEL)

This will be an Australian port (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 inbound view

AU outbound view

Check-in flight

The flight on which a passenger leaves the Check-in Port. This may or may not be an international flight.

A flight leaving a foreign port (where the passenger embarked) (eg. YVR-LAX)

A flight from an Australian port (where the passenger embarked) (eg. PER-MEL)

Trans-border flight

The flight on which a passenger crosses a country’s border. By definition this is an international flight: For a passenger travelling to Australia, this will be 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.

A flight from a foreign port to an Australian port (eg. LAX-SYD)

A flight from an Australian port to a foreign port (eg. SYD-LAX)

Expected flight

The flight associated with the Expected Port. This may or may not be an international flight: For a passenger travelling to Australia, this will be the flight arriving at the Expected Port. For a passenger travelling from Australia, this will be the flight departing from the Expected Port.

A flight arriving at an Australian port (where the passenger will undergo inbound immigration processing) (eg. SYD-MEL)

A flight leaving an Australian port (where the passenger will undergo outbound immigration processing) (eg. MEL-SYD)

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 the Note on Flight Dates below (following Table 8) for the rules on past or future dates.

In most cases, the other data required for the expected movement is derived from this International Flight data by the APP System.

3 For unscheduled International Flights where the Trans-Border port is different from the origin and/or destination of the International Flight, information on the Trans-Border Flight is mandatory. Note that this could apply to both ends of the nternational movement.

This information is not needed for these cases: Scheduled flights. Unscheduled flights where Trans-Border ports are the same as the origin and/or destination of the International Flight.

4 If the passenger is not processed at the primary line at the origin or destination of the International Flight, information on the Expected Flight is mandatory. (This scenario means there is another flight involved in the international movement). Note that this could apply to both ends of the international movement.

This information is not needed for these cases: The passenger is processed at the primary line at the origin or destination of the International Flight

5 When the International Flight transits an intermediate country between the origin and destination countries, the APP System determines the Expected Flight and Port and the Trans-border Flight and Port for both inbound and outbound movements for the country.

This can only be done when the flight is a scheduled flight. Refer to Section 2.10.1 for information on handling of unscheduled flights.

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 Flights

When a flight is delayed so that that it may be confused with a flight of the 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 Flights

By their nature, charter flights are also not listed in the airline schedules, since 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 Scheduled/Unscheduled Flight flag set to U[unscheduled], and complete data on the International Flight.

The APP System will recognise this as an unscheduled flight, and not look up the schedules to validate this data.

2 If the flight is anything other than a simple International Flight (where trans-border and expected ports are the same), the airline must include the additional flight data.

If the full flight data is not supplied in this case, the APP System will not be able to provide the correct data to the government.

3 This approach can only be effectively used when the International Flight does not transit an APP-participating country between the origin and destination countries of the flight.

There is no provision in the messages for providing information on intermediate countries. Under these circumstances, the 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 the APP System. 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).

See Appendix C for full details on how to carry out this procedure.

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 travelling on a scheduled flight).

If the unscheduled flight has 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 being handled in this way.

For Australia, contact EOC using 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, ensure that the actual flight number is used, rather than any code share number.

If a code share number is submitted, no problem will occur within APP, but the code share flight number will be 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:

Figure 4 - Overall Structure of CIRQ Message

Check-in RequestCIRQ

CHKCheck-in

Flight(Optional)

CIRQTransaction

Header(Mandatory)

INTInternational

Flight(Mandatory)

EXO/EXDExpected

Flight(Conditional)

TBO/TBDTrans-border

Flight(Conditional)

PRQPassengerRequest

(Mandatory)

Field count: 4Instances: 0-1

Field count: 10Instances: 1







3.1.3 Message Construction

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

Data group Group ID

Number of occurrences

Notes

Transaction None Always 1 Includes the transaction indicator (CIRQ) to identify the function being performed.

Check-in Flight

CHK 0 or 1 While this data group is technically optional, border control authorities prefer it to be supplied. It is the flight on which the passenger is checking in when advance passenger information is collected.

International Flight

INT Always 1 The flight on which the passenger is crossing the international border.

Expected Flight

EXO or EXD

0,1 or 2 Data group EXO refers to the outbound 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 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 Flight

TBO or TBD

0,1 or 2 TBO refers to the outbound 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 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 Request

PRQ 1 to 5 (see the note below on numbers)

Includes biodata and document data for each passenger. Note that with endorsees on passports, more than one passenger may be associated with one data group.

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 biodata from the machine readable zone (MRZ) of the passport wherever possible during check-in.

This method should minimise data input errors.

2 Incorporate all of the MRZ data in the first CIRQ message so that the full passenger data is available to the APP System without the need for any further dialogue.

If the passenger is not known to the APP System, but is in fact visa free for the country concerned, the biodata will be captured at this point and sent to the 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 passenger’s given name or DOB is also required.

This enables the passenger to be uniquely identified 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:

Figure 5 - Overall Structure of CIRS Message

Check-in ResponseCIRS

PRSPassengerResponse

(Conditional)

CIRSTransaction

Header(Mandatory)

ERRError

Group(Conditional)


Field count: Variable (5+)Instances: 0-1


Error code andmessage text

One of theseis required(either PRSor ERR) Field count: 3

Instances: 1-many



3.2.3 Message C

e data groups listed below in Table 9.

onstruction

The body of the message contains th

Data group Group ID


Notes

T Al Includes the transaction indica S) to identify the function being performed.

ransaction None ways 1 tor (CIR

Passenger Response

PRS 0 to 10

OTE: TNm

here ust be either t least one

.

t

everal countries involved in an International

wn to the government (i.e. the

aPRS or one ERR group in the message

The expanded data retrieved from the database of a governmensystem. There may be more than one of these data groups per passenger when sFlight are APP System participants. The data group allows for two types of status code: Check-in Message Code and Passenger Status Code which indicate whether or not the passenger is knosystem and the action to be taken for the passenger directive). Passenger Error Code which indicates specific data problems with the passenger data supplied.

Error ERR

ating government system.

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 particip

Table 9 – Message Const

3.2.4 Me

rther processing of response messages:

ruction for Check-In Response (CIRS)

ssage Processing

The following notes apply to the fu

Case Situation

Case 1 The passenger has been matched in the database and the Check-in Message Code indicates the ified by the government for that passenger. An expected movement has been created. n continue to process the passenger for boarding.

o process the passenger for

Case 3 the n

he DCS can continue to process the passenger to remedy the problem but cannot board

Case 4

d send a Check-in Request (CIRQ) message back to the CG

est

Case 5

rs.

action specThe DCS ca

Case 2 The passenger has not been matched in the database and the Check-in Message Code indicates theaction specified by the government for that passenger. The passenger is eligible to board. An expected movement has been created. The DCS can continue tboarding.

The passenger has not been matched in the database and the Check-in Message Code indicatesaction specified by the government for that passenger. An expected movement has not beecreated. Tthe passenger until this is completed.

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 anto indicate the selection. This second Check-in Request (CIRQ) message should ensure uniquenessof the passenger data for the selected passengers by including full biodata. If the Check-in Requ(CIRQ) messages are not generated back to the CG, then expected movement records will not be created for those passengers.

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 thiscountry. The error condition must be corrected. This case generally only applies to system erro



3.2.5 Rec

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.

ommended Airline Implementation



• To deal with the inability of the system to uniquely identify a passenger or when there is must capture further passenger data

errides may be submitted for more than one country

insufficient data to assess the passenger, the DCSand 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). Ovin 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 (ERR), the errous

rrors are normally of a serious nature eg. APP y

the CIRS message includes an Error Group These er message is displayed to the

er for correction and resubmission. System unavailable, and resubmission by the user manot remedy the problem.

2 If Rerto

the CIRS message includes a Passenger esponse (PRS) data group that includes an ror message, the error message is displayed the user for correction and resubmission.

These errors are normally of a less serious nature.

3 TStatus Code rpa

ng i.e. timing out.

If the problem persists, processing can

d with passenger processing nment, the

affected, inform them of the situation and obtain permission to continue boarding passengers.

he CIRS message includes a Passenger eturned by each country for each

Before deciding to proceewithout receiving directives from a gover

ssenger.

If the CIRS message for one or more countries returns a status of “T”, the APP Systems for those countries are not respondi

check-in agent must:

Ensure that this is not a transient problem by attempting the transaction again.

Contact government agencies of each country

continue. The rules in paragraph 4 below should be followed.

The government systems of countries unaffected by the timeouts will continue to receive the correct data on expected passenger movements.

4 T(nartaken.

contacted for advice.

of “D” and all others have returned a status

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.

, the check-in agent must take further action.

, the check-in agent must:

Be satisfied that the passenger belongs to a ons of

or

Contact government agencies of each country that

he combination of Passenger Status Codes ot including occurrences of Timeout “T” which e ignored) determines the action that can be

The only circumstance when a passenger may be boarded is when all countries respond with a status of “B”. In all other circumstances

If all values are “B”, boarding for the passenger may continue.

Before overriding a directive from a government system

If at least one country has returned a status of “I” or “U”, but no country has returned a status of “X”, the additional passenger data must be captured so an assessment may

special category according to the regulatieach country that returned a status of “D”;

be completed. A CIRQ message is then retransmitted. If this does not correct the problem, a government agency should be

returned a status of “D” and obtain clearance to board the passenger.

If at least one country has returned a status

of “B”, and the check-in agent is satisfied that the passenger should be permitted to



5 In cases where some countries return a Passenger Status Code of “B” and others do not return “B”, the expected movements generated for countries that returned a “B” are

This is a reconciliation issue for the participating government and the airlines do not need to take any special action.

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

This identifier will only be returned if all countries involved in the passenger’s journey have

systems.

(CICX) if the passenger does not fly (or if the entire flight is cancelled).

Store the Expected Passenger ID from the CIRS message against the passenger in the DCS.

This ID can be used subsequently in a Movement Cancellation message

returned a positive directive and an expected movement has been generated to government

7 The Passenger Status codes for each passenger should be assessed independently of other passengers in the transaction to determine if any future action is necessary for the transactions for that passenger. Where a “B” is returned for a passenger from all countries, no further transactions need to be submitted for the passenger.

If a particular passenger is cleared for travel while others in the transaction are not, no further processing is required for the passenger that has been cleared. It is not necessary to resendpassenger. Only passengers not cleared for travel need to be processed further.

8 The Passenger Status returned in the CIRSmessage should be used for assessing a response, not a local table that relates Check-in Message Cod

es to Passenger Status codes. g

han one possible Passenger

The relationships in Table 23 are indicative only and refinements of business rules by a government may lead to changes or to a Check-in Message code beinassociated with more tStatus code.

9 Airliout

e es from all

nee

nes should wait for 25 seconds before timing an enquiry sent to the CG.

Thgovernments before timing out the enquiry. Airlines

d to wait a little longer than this.

CG waits for 20 seconds for respons

Table 10 - Rules for Implementing CIRS Message



3.3

3.3.1

This that one or more expected movements previ

3.2

The f the overall structure of the CICX message:

Overall Struc



Message Type: Movement Ca

Purpose

message is used to notify the APP Systemously generated are to be cancelled.

ncellation (CICX)

3. Message Structure

ollowing diagram (Figure 6) shows

Figure 6 - ture of CICX Message

Data group Group ID


Notes

Transaction None Always 1 Includes the transaction indicator (CICX) to identify the function being performed.


INT Always 1 The flight on which the passenger is crossing the international border and on which they were originally checked in.

Movement Cancellation

PCX 1 to 10 Includes biodata and document data for each passenger. Note that only one passenger may be associated with one data group.

Table 11 – Message Construction for Movement Cancellation (CICX)

MovCIC

ement CancellationX

CICXnsactioneaderndatory)

TraH

(Ma

INTInternational

Flight(Mandatory)

PCXMovement

Instances: 1 Instances: 1-10

Cancellation(Mandatory)

Field count: 22Field count: 10


MovCIC

ement CancellationX

CICXnsactioneaderndatory)

TraH

(Ma

INTInternational

Flight(Mandatory)

PCXMovement

Instances: 1 Instances: 1-10

Cancellation(Mandatory)

Field count: 22Field count: 10





When a message is received from an airline across the SITA network, the CG:

hich governments involved in the transaction are participants in the APP

ormats recognised by the participating AP(s).

o the AP(s) of the participating government(s).

• Collates the responses into a single message for return to the airline DCS. Refer to

• Determines wSystem.

• Translates the airline message into f

• Forwards the message(s) t

• Receives response(s) from the AP(s) of the participating government(s).

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 a one dditional data in the response (eg. error messages) for set of input data, the number of input data sets must be limited to 10 (ten).

plementation

in the following way:

3.3.5 Recommended Airline Im

It is strongly recommended that airlines implement the CICX message

N Rule Noo tes

1 ocessnd ot a rd the

the movement should be cancelled by thn.

e If a passenger is prSystem a

ed through the APP ctually boa does n flight,

is

Otherwise incorrect expected movement details will bsent to government systems.

transactio

2 ovide the Expected Passenger ID in thoup. s su ta for the

identif nger

is data

Pr e PCX See Example 21 below for an example of thdata gruniquely

This iy the re

fficient dalevant passe

CG to .

being supplied (section 6.2.1). [The value of the ID inthe example is 000000002128666].

3 Do not supply data which is insufficient to allow th

There is no provision for selecting passengers from a iquely

identified, an error condition is generated for the passenger.

e passenger to be uniquely identified. list returned by the CG. If the data supplied for apassenger does not allow the passenger to be un

Table 12 - Rules for Implementing CICX Message



3.4 Message Type: Movement Cancellation Confirmation (CICC)

is mthe airline DCS.

3.4.1 Purpose

Th essage is used to send a response to a Movement Cancellation (CICX) from the CG to

The message is used to return a mix of the following types of information:

Case Situation

Ca When a set of passenger data has been uniquely matched against expected movemese 1 nts in a

Case 2 xpected movements in a government system and a corresponding acknowledgement for the passenger cannot be returned.

ic country is

C message:

Figure 7 - Overall Structure of CICC Message

government system and a corresponding acknowledgement for the passenger can be returned.

When a set of passenger data has not been matched against e

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 specifidentified.


The following diagram (Figure 7) shows the overall structure of the CIC

Cancellation Confirmation CICC

TransactionHeader

(Mandatory)CICC

PCCPassenger

(Conditional)

CancellationResponse

ERRError

count: 28

Group(Conditional)

FieldInstances: 0-10


Error cmessage text

ode and

One of theseis required(either PCCor ERR)

Field count: Variable (5+)

Field count: 3Instances: 1-many

Instances: 0-1

Cancellation Confirmation CICCTransaction

Header(Mandatory)

Field count: 2Instances: 1CICC

ERRError

Group(Conditional)


Error cmessage text

PCC

ode and

One of theseis required(either PCCor ERR)

Field count: Variable (5+)

Field count: 3Instances: 1-many

Passenger

(Conditional)

Instances: 0-1CancellationResponse





Data group Group ID


Notes

Transaction None Always 1 Includes the transaction indicator (CICC) to identify the function being performed.

Passenger ellatonse

PCC 0 to 10

The expanded data retrieved from the database of a government system. There may be more than one of these data groups per passenger when several countries involved in an International

with ssenger data supplied.

CancResp

ion

NOTE: There must be either

Flight are APP System participants. The data group includes two types of status code:

at least one PCC or one

Check-in Message Code and Passenger Status Code which indicate whether or not the passenger is known to the government system and the action to be taken for the passenger. ERR group in

the message. Passenger Error Code which indicates specific data problemsthe pa

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 DC

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.

S can continue to process the passenger to remedy the problem.



3.4.5 Recommended Airline Implementation

Response (PCC) data groups which may indicate that processing has completed normally for passengers or that th en ela icular passengers. It may also include an Error Group (ERR) notifying a serious error from one or more countries.

The Passenger Cancellation Response ( p includes a Passenger Status code r eac sen each cof ger and the action that mu

C The movement h es sary for this passenger.

N An expected mov d d flight details provided. opreviously and a duplicate trans Passenger Status would be “C” in that case). The user shotransaction. If the problem pers expected movement.

T The APP Sy t period specified. N -in agent.

An error condition has been detected. All error conditions must be corrected before processing can be completed for the passengers represented in the message.

ust be performed under the control of the DCS as follows:

rror conditions.

To de e inability of the system to identify a previous expected movement, the CS

The CICC message may include one or more Passenger Cancellation

ere have be errors r ted to part

PCC) data groueturned foror the passen

h pas ger by untry. This code indicates the status of the transaction st be taken. The possible values of the code are:

as been succ

ement recor This status w

sfully cancelled. No further action is neces

could not be found matching the passenger anuld not be returned if a movement has been cancelled action was submitted (the uld check the data submitted and resubmit the ists, the user should abandon attempts to cancel the

stem for the country has not responded within the timeouo directive from the country can be returned to the check

E

The actions recommended above m

• Display error conditions to the user and allow the user to correct the e

• al with thD 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 (ERR), the error message is displayed to the user for correction and resubmission.

These errors are normally of a serious nature eg. ASystem unavailable, and resubmission by the user manot remedy the problem.

PP y

2 If the CICC message includes a Passenger These errors are normaCancellation Response (PCC) data group that includes an error message, the error message is displayed to the user for correction and resubmission.

lly of a less serious nature.

3 The CICC message includes a Passenger Spa

If the CICC message for one or more

If the timeout problem persists for a significant period of

contact government agencies of each country affected

e

tatus Code returned by each country for each ssenger.

time and a number of cancellation messages have not been correctly processed, the check-in agent must

countries returns a status of “T”, the APP Systems for those countries are not responding i.e. timing out.

Processing can continue.

and inform them of the situation. The government systems of countries unaffected by thtimeouts will continue to receive the correct data on expected movement cancellations.

4 Winfr ld be all successful (8505), all unsu essful (8506) or a m

country originally processed the check-in

d to take any special action unless it becomes a frequent occurrence.

hen a cancellation of an expected movement volves more than one country, the responses om the various countries cou

cc

This may result in a reconciliation issue for the participating governments but the airlines do not nee

ix. 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

transaction. The check-in agent cannot readily remedy this issue. Continue with no special action.

5

the DCS, overwrite this ID with a value (eg. “Cancelled”) to record the fact that the movement has successfully been cancelled.

of both th a value for

Expected Passenger ID), and successful cancellations (those marked “Cancelled”).

If the Expected Passenger ID from the CIRS message was stored against the passenger in

This will provide a full record within the DCSsuccessful APP transactions (those wi

Table 14 - Rules for Implementing CICC Message



[This page deliberately left blank]



4 Dialogue Types ll communication between the DCS and the CG consists of a request from the DCS llowed by a response from the CG. All dialogues are therefore initiated by the DCS.

ome dialogues are longer than this simple two-part question and answer structure, and the xamples below are provided to clarify how these dialogues can occur.

.1 Check-in Request (Simple)

ogue. A check-in request is made for one or ore 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

Afo

Se

4

This is the simplest and most common APP dialm

Message no

Message from DCS Message from CG

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 Message no


1 CIRQ (data for one or more pax) 2 CIRS (eg. error code 8507 “Duplicate Name” ) 3 CIRQ (including data which uniquely

identifies each pax)

4 CIRS (a directive for each pax)



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

Dialogue Structure

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.

Message no


1 CIRQ (data for one or more pax) 2 CIRS (eg. error code 8516 “Insufficient Data”) 3 CIRQ (corrected data) 4 CIRS (a directive for each pax)

4.4 Ca cellation Request (Simpl

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 l have been two requests (CIRQ and

CICX) and two responses (CIRS and CICC).

n e)

that therefore for each passenger involved there wil



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.

Structure DialogueMessage no


1 CICX (data for one or more pax) 2 CICC (eg. error code 8506 “No Record” )

4.6 Cancellation Request (Error: Incorrect Data Supplied)

t record that needs to be cancelled.

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 movemen



1 CICX (data for one or more pax) CICC (eg. error co2 de 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 data in accordance with Table 16 below.

These five fields in Layer 7 are currently also required by the ETA System.

2 Include sufficient data to ensure that the source of the transaction can be identified. For example, the field Airline Private Data could be used to send data identifying the source.

Identification of the user’s location is a crucial aspect of the APP System. Although some of the Layer 7 data is optional, the 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 type/size

Mandatory/optional

Usage notes

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 Identifier

X(8) Optional Although this data is optional, the airline must be able to identify the source of the transaction.

Screen Size N(5) Not required

This field is not required for Integrated APP since no data is 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 tables below for data items in the body of the message. This usage is determined by the government implementing Advance Passenger Processing.

The rules specified in this document are designed to be applicable to multiple governments and to be applicable for generating advance passenger information for boends of an international journey and transit points.

th

2 Comply with the maximum length specified in the tables below for data items in the body of

Longer field

the message.

s may be truncated during processing.

3 Use slash (/) as the delimiter character to separate data items.

Obviously, it is necessary that the information in the data items does not contain the delimiter character.

4 Use only the colon (:) character as the delimiter [eg. “CIRQ:”, “CIRS:”, “CICcharacter after the Transaction Code.

X:”, “CICC:”]

5 Indicate null data item o consecutive [eg. “//”] s as twdelimiter characters.

6 fields. empty fields must be transmitted. Transmit all fields, including trailing empty Even trailing optional

7 Follow the rules for grouping of data items in the body of the message.

Data items are arranged in groups, each including a particular type of data. A group identifier will preceeach group. Some groups will be mandatory in a message while others will be optional. Within a geach data ite

de

roup m must be present (but may be null).

Table 17 – Rules for Body of Message

5.1.3 Rules

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 valu

for Layer 5 Address

In

e:

Produ n ction Versio Demo/Test Version

5APPXS 5APTXS

Table 1 er 58 – Lay Addresses for APP Messages



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

5.2 Message TyThe following table (Table 19 – Message Layout for Check-in Request) provid mber h ch data group is supplied only for ease of bers are not us

pe: Check-in Request (CIRQ)

reference, and these numes theed wit

layhin

out fo the m

r the essag

CIRQes.

message. A field nu wit in ea

Data group No Data item Data type/ size

Mandatory/ optional

Value Notes

1 Tr d o “CIRQ” e f loansaction Co e A(4) Mandat ry Must b ollowed by co n.

2 Airline Pr Data

) l Fr y the airlin erepurpo

Th ata t e ex , ou u o

st he e ction I

ivate X(14 Optiona ee for use bses.

e for ref nce is dmessag

ore t

is retu (CIRS Airline

rned to). For Sourc

he airliample

Transa

ne in it c

the resld be

D.

ponsesed t

3 User ID o Airlin dentifier X(6) Mandat ry e user i

4 Handle M e Respons

o “Y” = location le name orsees). “N” = the user location c andle dup s.

If he n te nam able) e

If “N”, the n error (if applicable).

ultiple

A(1) Mandat ry the user s (end

licate name

can h

ann

and

ot h

duplicate “Y”, t CG wifor the user to select on

CG wi

ll retur

ll retur

duplica.

only an

es (if

code

applic

5 Unused d em uired o lon use y was /Dep e C

ata it A(1) Not req Field nArrival

ger artur

d (Previouslard)

Print

Transaction

6 Message on ory Indicates the ingmess

“20” f es ming t catio

Versi N(3) Mandat format of the follow age.

Set to specifi

or mn.

sages confor o this

1 Check-in t Group Id r

nal “CHK e pro d if in Fligh ot the same Inter nal

Flighentifie

A(3) Conditio ” Must bas the

videnatio

the Check- Flight.

t is n

2 Check-in t Group Fi unt

nal Numb fie this data group

2 for ent finitionional uire u pr t)

Fligheld Co

N(2) Conditio er of .

lds which follow in Set to Condit

curr(req

message ded if this gro

. esenp is

3 Check-in X(5) nal IATA Airport D ional uire u present)

Port Conditio Code eg. SYCondit (req d if this gro p is

Check-in Flight

4 Check-in Flight X(8) nal Airline and flig 031 ional uire up is present)

Conditio ht number. eg. BACondit (req d if this gro


Data roup g No Data item Data type/

Mandatory/ optional

size

Value Notes

1 International Flight Group Identifier

A(3) Mandatory “INT” International Flight

2 Inte ght Group Field Count

N M Number of fields w ow in this data group.

Set to 8 for current mess inition. rnational Fli (2) andatory hich foll age def

3 Scheduled/

Flight

Mandatory “S” = Scheduled Flight Unscheduled Flight

“Unscheduled” means delayed, charters, etc. Unscheduled

A(1) “U” =

4 International Flight X(8) Mandatory flight number Airline and eg. BA031

5 International Flight X(5) Mandatory IATA Airport Code Origin

eg. SIN

6 ht

International FligDestination

X(5) Mandatory IATA Airport Code eg. SYD

7 International Flight Date

N(8) Mandatory CCYYMMDD eg. 20021105

8 International Flight Time

N(6) Con HHMMSS heduled flight)

ditional eg. 105500 Conditional (required for unsc

9 International Flight Arrival Date

N(8) Con nal Conditional (required for unscheduled flight)

ditio CCYYMMDD eg. 20021105

10 ht N(6) Con nal HHMMSS ght)

International FligArrival Time

ditio eg. 223000 Conditional (required for unscheduled fli

1 r

A(3) Conditional Expected Flight data for country of al movement. light data for country of

destination of international movement.

esent for of an international movement.

nal (if the passengers do not embark on or port

clear Customs and Immigration i.e. the

Expected Flight Group Identifie

“EXO” =origin of internation“EXD” = Expected F

A separate Expected Flight Group may be preach endConditiodisembark from the International Flight at the where they Expected Port, this data group is required).

Expected Flight (repeating)

2 Expected Flight Group Field Count

N(2) Conditional Number of fields which follow in this data group.

Set to 4 for current message definition. Conditional (required if this group is present)




Mandatory/ optional

Value Notes

3 Airport Code. onditional (required if this group is present) Expected Port X(5) Conditional IATA C

4 Exp X(8) Conditional Airline and flight number. Conditional (required if this group is present) ected Flight

5 nal nt) Expected Date N(8) Conditio CCYYMMDD Conditional (required if this group is prese

6 N(6) Conditional HHMMSS Conditional (required if this group is present) Expected Time

1 Group

Identifier

ht data for onal movement

ght data for ational

be present for each end of an international movement.

(if the international flight is not a scheduled rans-Border Ports are not the origin

estination of the International Flight, this data uired)

Trans-BorderFlight

A(3) Conditional “TBO” = Trans-Border Fligcountry of origin of internati“TBD” = Trans-Border Flicountry of destination of internmovement

A separate Trans-Border Flight Group may

Conditional flight and the Tand/or dgroup is req

2

Count

ich follow in this data r current message definition. Conditional (required if this group is present)

Trans-Border Flight Group Field

N(2) Conditional Number of fields whgroup.

Set to 3 fo

3 -Border Port X(5) Conditional IATA Airport Code. Conditional (required if this group is present) Trans

4 D (required if this group is present) Trans-Border Date

N(8) Conditional CCYYMMD Conditional

Trans-Border Flight (repeating)

quired if this group is present) 5 Trans-Border Time

N(6) Conditional HHMMSS Conditional (re

1 Passenger Request Group Identifier

A(3) Mandatory “PRQ”

2

Field Count

Passenger Request Group

N(2) Mandatory Number of fields which follow in this data group.

Set to 22 for current message definition.

Passenger Request (repeating

3 Passenger Sequence Number

N(3) Mandatory er in the message.

an

e range 1 to

The sequence number of the passeng A maximum of five occurrences of this data group cbe included in each message. The value of the Passenger Sequence Number can be in th999.




Mandatory/ optional

Value Notes

4 w

Pax/Crew Indicator

A(1) Mandatory “P” = Passenger “C” = Operating cre“X” = Positioning crew

5 Passport Country assenger. de (ICAO [3-character code] or one code Code

A(3) Mandatory Nationality of pCountry coIATA [2-character code]).

eg. NZL Note that the ICAO 3-character code set has of length one character i.e. “D” – Germany.

6 A(3) Conditional (see Notes)

the

3-character code set has one code ny.

Issuing State Country code (ICAO [3-character code] or IATA [2-character code])

Optional for a check-in enquiry. Required if passenger is not previously known so data must be captured, and the passenger holds a travel document that indicates Issuing State. Note that the ICAOof length one character i.e. “D” – Germa

7 X(14) Conditional rt or other travel document number Conditional (required if Document Type is “P”, must be

Passport ID Passpo eg. N364028

blank if Document Type is “N”). It should be provided if available.

8 Passport Check X(1) Optional Value taken from MRZ Character

9 Document A(1) Optional “P” = Passport (Default) ther travel document

“N” = No travel document

Defaults to “P” if not given. TravelType “O” = O

10 cument N(8) Conditional CCYYMMDD Eg. 20080328 d if the

passenger is not previously known so data must be captured, and the passenger holds a travel document

Travel DoExpiry Date (see Notes) Optional for a check-in enquiry. Require

that indicates Expiry Date.

11 ntary ent Type

A(2) Optional tify the type of an additional/ alternative document being used.

SupplemeDocum

Code to iden Not currently used.




Mandatory/ optional

Value Notes

12 ntary ID

) pplementary document. ot currently used. SupplemeDocument

X(14 Optional Number of the su N

13 Supplementary Doc. Check

X(1) Optional Not currently used.

Character

Value taken from MRZ

14 Name X(24) Mandatory mes.

family

y name” will need to be

rs, the first should be entered.

Family Family name.

Full name if less than 4 characters, otherwise at least 4 characters. Can include spaces between naIf the passenger is not previously known, the fullname will need to be provided. For countries where the passports have only one long name eg. Malaysia, the “famildifferentiated from the “given names”. If the family name is longer than 24 characte24 characters

15 Given Names X(24) Optional (see Notes)

Given name(s). n 24 characters, the

ed. ptional 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

Can include spaces between names. If the given names are longer thafirst 24 characters should be enterO

be supplied if available.

16 Date of Birth N(8) Conditional (see Notes)

Optional for a check-in enquiry. Required if the passenger is not previously known so data must be

uld be supplied if available.

CCYYMMDD

captured. Sho

17 A(1) (see Notes)

“M” = Male “F” = Female “X” = Unspecified

Sex Conditional Optional for a check-in enquiry. Required if the passenger is not previously known so data must be captured. Should be supplied if available.

18 Country of Birth Code

A(3) Optional Country code (ICAO [3-character code] orIATA [2-character code]).

3-character code set has one code haracter i.e. “D” – Germany.

Note that the ICAO of length one c




Mandatory/ optional

Value Notes

19 Holder/ Endorsee

A(1) Optional Blank for passport holder “S” = Endorsee

20 Transit at Origin A(1) Optional “Y”, “N”. If not given, treated as “N”.

er is in transit at origin of International Flight. Set to “Y” if passeng

21 at A(1) Optional “Y”, “N”. ated as “N”.

Set to “Y” if passenger is in transit at destination of Transit Destination If not given, tre International Flight.

22 Override Codes A(15) Optional Format is: CxxCxxCxxCxxCxx Where: “xx” = IATA country code for the country to

which the preceding override code applies.

“C” = Override code for the country which

ues 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.

follows. Permissible val

This field may be used to provide override codes for up to five countries in a single transmission. The rules for use of overrides may vary by country, but all will use the same set of override codes.

23 PNR Source X(3) Conditional Airline code (IATA [2-character]) uired by some countries on Conditional (may be reqinternational flight)

24 PNR Locator X(6) nal Conditio Conditional (may be required by some countries on international flight)

Table sag r Check-in Request (C 19 – Mes e Layout fo IRQ)



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 ren ese n within the messages.

If passenger inform in espo order senger data will be by Passe und country response first, followed by transit country responses ht, followed by ntry response.

refe ce, and th umbers are not used

ation is present the r nse, the of the pas nger Sequence Number, with the outbo the inbound couin their order on the flig


Mandatory/ optional

Value Notes

1 Transaction Code A(4) Mandatory “CIRS” Must be followed by colon. Transaction

2 Airline Private Data

X(14) Optional Airline Any data that was originally given in the CIRQ will be echoed back here.

reference

1 Passenger Response Group Identifier

A(3) Conditional Conditional (required if no ERR data group is present) “PRS”

2 Passenger Response Group Field Count

N(2) Mandatory Set to 27 for current message definition. Number of fields which follow in this data group.

3 Passenger N(3) Mandatory The se umber of the passenger in Corresponds to the sequence number in the CIRQ Sequence Number

quence ne. the messag message.

4 character IATA Country Code of the participating country generating the passenger response.

ParticipatingCountry

A(2) Mandatory 2 eg. AU

Passenger Response (repeating)

5 Pax/Crew Indicator

A

“X” = Positioning crew

(1) Mandatory “P” = Passenger “C” = Operating crew



Data oup gr No Data item Data type/ size

Mandatory/ optional

Value Notes

6 Passport Country Code

A(3) Mandatory Nationality of passenger. Country code (ICAO [3-character code] or IATA [2-character code]).

eg. NZL Note that the ICAO 3-character code set has one code of length one character i.e. “D” – Germany.

7 Issuing State A(3) Optional Country code (ICAO [3-character code] or IATA [2-character code])

Note that the ICAO 3-character code set has one coof length one character i.e. “D” – GermShould be included if known.

de any.

8 Passport ID X(14) Optional Passport or other travel document number eg. N364028 Should be included if known.

9 Passport Check Character

Value taken from MRZ X(1) Optional

10 T Passport document


ravel Document Type

A(1) Mandatory “P” =“O” = Other travel

11 N(8) Optiona CCYYMMDD Should be included if known.

Travel DocumentExpiry Date

l eg. 20080328

12 ary SupplementDocument Type

A(2) Optional Code to identify the type of an additional/ alternative document being used.

Not currently used.

13 Supp y D

X(14) Optional Number of the supplementary document. Not currently used. lementarDocument I

14 ntary X(1) Optional m MRZ y used. SupplemeDoc. Check Character

Value taken fro Not currentl

15 Family Name X(24) or

Optional Should be included if known.

X(60)

Family or full name of the passenger

16 es X(24) Optional ame field is more ngth.

Should be included if known. Given Nam Will be Null if Family Nthan 24 characters in le

17 Date of Birth N(8) Optional CCYYMMDD Should be included if known.




Mandatory/ optional

Value Notes

18 e included if known. Sex A(1) Optional “M” = Male “F” = Female “X” = Unspecified

Should b

19 h one code

” – Germany.

Country of BirtCode

A(3) Optional Country code (ICAO [3-character code] or IATA [2-character code]).

Should be included if known. Note that the ICAO 3-character code set hasof length one character i.e. “D

20 Endorsee “S” = Endorsee

uded if known. Holder/ A(1) Optional Blank for passport holder Should be incl

21 y for the passenger. ill have the value of "0000" should there be any error detected in the passenger data that was supplied or here was a timeout.

Check-in Message Code

N(4) Mandator Check-in message code W

t




Mandatory/ optional

Value Notes

22 enger Status

y ssenger with respect to the ess for this country:

ata is available, ment has been

D = All required data is available, no expected movement has been

ctive is “Do Not Board” nt, may be overridden by

expected movement has been 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.

the passenger and what PP country in field 4.

PassCode

A(1) Mandator Status of pacheck-in procB = All required d

expected movegenerated, directive is “OK to Board” or equivalent.

generated, direor equivalecheck-in agent.

X = All required data is available, no

Indicates the overall status of action can be taken for the A

23 Expected Passenger ID

N(15) Conditional Unique passenger identifier. Will only have a value if the passenger has been given a positive boarding directive by all countries.

24 Passenger Error Code 1

N(4) Conditional Error code for error condition identified. Conditional (on error condition)

25 Passenger Error Message Text 1

X(60) Conditional Error message for error condition identified. Corresponds to Passenger Error Code 1 in previous field.


N(4) Conditional Error Code for error condition identified. Conditional (on error condition)




Mandatory/ optional

Value Notes

27 ) ed. Passenger Error Message Text 2

X(60 Conditional Error message for error condition identifi Corresponds to Passenger Error Code 2 in previous field.


N(4) Conditional fied. Conditional (on error condition)

Error Code for error condition identi


X(60) Conditional Erro Corresponds to Passenger Error Code 3 in previous field.

r message for error condition identified.

1 Error Group Identifier

A(3) Conditional Conditional (required if no PRS data group is present) “ERR”

2 Error Group Field Count

N(2) Conditional Numgrou

i.e. the number of Participating Country fields, Error Code fields and Error Message Text fields. Conditional (required if this group is present).

ber of fields which follow in this data p.

e fields are repeated for each error mess

The following thre age returned.

3 Participating Country

A(2) Conditional coun

eg. AU 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.

IATA Country Code of the participating try generating the error response.

4 Error Code N(4) Conditional entified. eg. 6003 Error code for error condition idConditional (required if country code is present).

Error Group (contains a repeating sub-group)

ion identified. evious field.

Conditional (required if country code is present).

5 Error MessageText

X(60) Conditional Error message for error condit eg. Invalid Nationality Code Corresponds to Error Code in pr

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 ach data grou s s r e ref d th mp i upplied only fo ase of erence, an ese numbers are not used within the essages. e


Mandatory/ Optional

Value Notes

1 A(4) Mandatory “CICX” be followed by colon. Transaction Code Must

2 e ) ee for use by the airline for reference purposes. message (CICC). For example, it could be used to

Airline PrivatData

X(14 Optional Fr This data is returned to the airline in the response

store the Airline Source Transaction ID.

3 User Id X(6) Mandatory e user identifier Airlin

4 Handle Multiple Response

A(1) Mandatory “Y” = the user location can handle duplicate names (endorsees).

duplicate names.

licable) for the user to select one.

will return only an error code (if applicable).

“N” = the user location cannot handle If “N”, the CG

If “Y”, the CG will return duplicate names (if app

5 ata longer used (previously was Print Unassigned ditem

A(1) Not required Field noArrival/Departure Card Number)

Transaction

6 Message Version N(3) Mandatory Indicates the format of the following message

Set to “20” for messages conforming to this specification.

1 Flighter

InternationalGroup Identifi

A(3) Mandatory “INT”

2 International Flight unt

N(2) Mandatory Number of fields which follow in this data Group Field Co group.

Set to 8 for current message definition.

3 Scheduled/ Unscheduled Flight

A(1) Mandatory “S” = Scheduled Flight “U” = Unscheduled Flight

“Unscheduled” means delayed, charters, etc.

4 International Flight X 1 (8) Mandatory Airline and flight number eg. BA03


5 International Flight Origin

X(5) Mandatory IATA Airport Code eg. SIN




Mandatory/ Optional

size

Value Notes

6 International Flight Destination

X(5) Mandatory IATA Airport Code eg. SYD

7 Inter ght Date

N M CCYYMMDD eg. 20021105 national Fli (8) andatory

8 International Flight N(6) Conditional HHMMSS eg. 105500 scheduled flight) Time Conditional (required for un

9 ght al International FliArrival Date

N(8) Condition CCYYMMDD eg. 20021105 Conditional (required for unscheduled flight)

10 International Flight ime

N(6) Conditional HHMMSS Conditional (required for unscheduled flight) Arrival Teg. 223000

1 n

Group Identifier

A(3) Mand y Passenger Cancellatio

ator “PCX”

2 Passenger

p Field Count

N(2) Mandatory hich follow in this data roup.

Set to 20 for current message definition. Cancellation Grou

Number of fields wg

3 Sequence Number

ger in ge.

roup can each message. The value of the

Passenger Sequence Number can be in the range 1 to 999.

Passenger N(3) Mandatory The sequence number of the passenthe messa

A maximum of ten occurrences of this data gbe included in

4 ) ata is not

supplied)

Expected Passenger ID

N(15 Conditional Unique passenger identifier. Should be included if known. Conditional (required if passenger biod

Passenger Cancellation (repeating)


A(1) Mandatory “P” = Passenger “C” = Operating crew “X” = Positioning crew




Mandatory/ Optional

Value Notes

6 nger. CAO [3-character code] or

cter code]). Note that the ICAO 3-character code set has one code

haracter i.e. “D” – Germany.

Passport CountryCode

A(3) Mandatory Nationality of passeCountry code (IIATA [2-chara

eg. NZL

of length one c

7 g State A(3) Optional Country code (ICAO [3-character code] or IATA [2-character code])

Note that the ICAO 3-character code set has one code of length one character i.e. “D” – Germany.

Issuin

8 Passport ID X(14) other travel document number ”).

Conditional Passport or eg. N364028 Conditional (required if Document Type is “PIt should be provided if available.

9 Passport Check X(1) Optional Value taken from MRZ Character

10 T nt A(1) Optional “P” = Passport (Default) Other travel document


ravel DocumeType “O” =

Defaults to “P” if not given.

11 ment Travel DocuExpiry Date

N(8) Optional CCYYMMDD eg. 20080328

12 ype

A(2) Optional Used to identify the type of an additional/ Not currently used. Supplementary Document T alternative document being used.

13 tary t ID

X(14) Optional ber SupplemenDocumen

Document num Not currently used.

14 Supplementary X(1) Optional Value taken from MRZ. Not currently used. Doc. Check Character

15 Family Name X(24) Conditional Family name ired if Expected Passenger Id is provided. therwise, full name if less than 4 characters,

otherwise at least 4 characters.

Not requO

16 Given Names X(24) Optional Can include spaces. Not used if Expected Passenger Id is provided.

Given name(s)

17 Date of Birth N(8) Optional CCYYMMDD Not used if Expected Passenger Id is provided.




Mandatory/ Optional

Value Notes

18 if Expected Passenger Id is provided. Sex A(1) Optional “M” = Male “F” = Female “X” = Unspecified

Not used

19 h one code

character i.e. “D” – Germany.

Country of BirtCode


Not used if Expected Passenger Id is provided. Note that the ICAO 3-character code set hasof length one

20 Holder/ Endorsee

A(1) Optional Blank for passport holder “S” = Endorsee

Not used if Expected Passenger Id is provided.

21 et to “Y” if passenger is in transit at origin of International Flight.

Transit at Origin A(1) Optional “Y”, “N”. Default is “N”. S

22 ation

transit at destination of International Flight.

Transit at Destin

A(1) Optional “Y”, “N”. Default is “N”. Set to “Y” if passenger is in

Table 21 – Message L t Cancellation (CICX) ayout for Movemen



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 umber within each data group is sup onl e of re d these numbers are not us

If passenger information is present in the will be by Passenger Sequence Number, with the outbound country response first, followed by transit country responses i the flight, followed by the inbound country response.

plied y for eas ference, an ed within the messages.

response, the order of the passenger datan their order on

n


Mandatory/ optional

Value Notes

1 n Code A(4) Mandatory Must be followed by colon. Transactio “CICC” Transaction

Data

) will be 2 Airline Private X(14 Optional Airline reference Any data that was originally given in the CICX echoed back here.

1

up Identifier

al nt) PassengerCancellationResponse Gro

A(3) Condition “PCC” Conditional (required if no ERR data group is prese

2 Passenger Cancellation Response Group Field Count

group. Set to 26 for current message definition. N(2) Mandatory Number of fields which follow in this data

3 Passenger Sequence Number

N(3) Mandatory The sequence number of the passenger in the message.

Corresponds to sequence number in the CICX message.

4 Participating Country

A(2) Mandatory 2 Character IATA Country Code of the participating country generating the passenger response.

eg. AU

Passenger Cancellation Response (repeating)


A(1) Mandatory “P” = Passenger “C” = Operating crew “X” = Positioning crew




Mandatory/ optional

Value

size

Notes

6 Passport Country Code

A(3) Mandatory Nationality of passenger. Country code (ICAO [3-character code] or

eg. NZL Note that the ICAO 3-charact

IATA [2-character code]). of length one character i.e. “D” – Germany. er code set has one code

7 Issuing State A(3) Optional Country code (ICAO [3-character code] or IATA [2-character code])

Note that the ICAO 3-character code set has one codof length one character i.e. “D” – German

e y.

8 Pas X O Passport or othe ument number eg. N364028 Should be included if known.

sport ID (14) ptional r travel doc

9 ken from MRZ Passport CheckCharacter

X(1) Optional Value ta

10 nt y “O” = Other travel document

No travel document

Travel DocumeType

A(1) Mandator “P” = Passport

“N” =

11 te

N(8) Optional CCYYMMDD eg. 20080328 Should be included if known.

Travel DocumentExpiry Da

12 ary ative document being used.

SupplementDocument Type

A(2) Optional Used to identify the type of an additional/ altern

Not currently used.

13 ry

X(14) Optional Document number Not currently used. SupplementaDocument Id

14 tary k

SupplemenDoc. ChecCharacter

X(1) Optional Value taken from MRZ. Not currently used.

15 24) or X(60)

e included if known. Family Name X( Optional Family or full name of the passenger Should b

16 Given Names ) assenger. Should be included if known. X(24 Optional Given name(s) of the p

17 Date of Birth N(8) Optional Should be included if known. CCYYMMDD



No Data item Data type/ size

Mandatory/ optional

Value Data group Notes

18 e included if known. Sex A(1) Optional “M” = Male “F” = Female “X” = Unspecified

Should b

19 h one code

character i.e. “D” – Germany.

Country of BirtCode


Should be included if known. Note that the ICAO 3-character code set hasof length one

20 Holder/Endorsee A(1) Optional Blank for passport holder “S” = Endorsee

Should be included if known.

21 N(4) Conditional Check-in message code for the passenger. Will have the value of "0000" should there be any error etected in the passenger data that was supplied or

there was a timeout.

Check-inMessage Code d

22 Passenger Status Code

A(1) Mandatory pect to the try:

N = Not found

Indicates the overall status of the passenger and what action can be taken for the APP country in field 4.

Status of passenger with rcheck-in process for this coun

es

C = Cancelled

T = Timeout E = Error condition detected.

23 r al condition identified. condition) Passenger ErroCode 1

N(4) Condition Error Code for error Conditional (on error

24 r xt 1

) al condition identified. senger Error Code 1 in previous field.

Passenger ErroMessage Te

X(60 Condition Error message for error Corresponds to Pas

25 Passenger Error N(4) Conditional Error Code for error condition identified. Conditional (on error condition) Code 2


Conditional Error message for error condition identified. Corresponds to Passenger Error Code 2 in previous field.

X(60)

27 Passenger Error nal tified. Code 3

N(4) Conditio Error Code for error condition iden Conditional (on error condition)




Mandatory/ optional

Value Notes

28 enger Error Message Text 3

) al ge for error condition identified. ror Code 3 in previous Pass X(60 Condition Error messa Corresponds to Passenger Erfield.

1 Error Group Identifier

A(3) Conditional Conditional (required if no PCC data group is present) “ERR”

2 Error Group Field Count

N(2) Conditional

Number of fields which follow in this data group.

i.e. the number of Participating Country fields, Error Code fields and Error Message Text fields. Conditional (required if this group is present).

The followin repeated for each error message returned. g three fields are

3 Participating A(2) Conditional IATA Country Code of the participating ne occurrence required if this s Country country generating the error response.

Conditional (at least ogroup is present). The field may be null if the error wadetected by the CG and is therefore not specific to a given country.

4 Error Code N(4) Conditional ror condition identified. Conditional (required if country code is present). Error code for er

Error Group (contains a repeating sub-group)

5 Error Message Text

X(60) Conditional for error condition identified. Corresponds to Error Code in previous field. Conditional (required if country code is present).

Error message

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.

Australia

Kuala LumpurMalaysia

Sydney

033 (KUL-SYD) Figure 8 – Flight BA

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


CIRQ:/123456/N//20/INT/8/S/BA033/KUL/SYD/19981030//// 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 te the

differences in the names from the two different sources. movement record has been sent to each of the participating governments. No



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]


CIRS:/PRS/27/1/AU/P/USA/USA/Z4351213//P/20011114////SMITH/ SAMANTHA/19640912/F/USA//8507/U////////PRS/27/1/AU/P/USA/USA/ Z4351213//P/20011114////SMITH/BELINDA/19940421/F/USA//8507/U////////

The AP response contains details for both Belinda and Samantha Smith (who are on the same

nment.

Note that in the response both passengers have the same Passenger Sequence Number (1). tiple passengers.

passport format error)

passport), and code 8507 (“Duplicate name”) for both. At this stage no expected movementrecords have been sent to the participating gover

The check-in agent should now follow the message flow for checking-in mul(See Section 6.1.2 below).

EXAMPLE 5: Error condition (


CIRQ:/123456/N//20/INT/8/S/BA033/KUL/SYD/19981030//// 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 at”).

re to ensure that the passport number is correctly entered.

for an American passport, and has sent error code 6033 (“Invalid passport number formNo expected movement record has been sent to the government.

The check-in agent should resubmit the request, taking ca



EXAMPLE 6: Error condition (system error)


CIRQ:/123456/N//20/INT/8/S/BA033/KUL/SYD/19981030//// 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 processedThe 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 incCharacter indicating that the passport details were read from th

ludes the Passport Check e 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


CIRQ:/123456/N//20/INT/8/S/BA033/KUL/SYD/19981030//// PRQ/22/1/P/USA//Z4351213///////SMIT/////////// PRQ/22/2/P/USA//Z4354753///////SMIT///////////

Details of two passengers (with the same family name, but with different passports) are submitted by the airline.



CIRS:/PRS/27/1/AU/P/USA/USA/Z4351213//P/20011114////SMITH/ SAMANTHA/19640912/F/USA//8501/B/345234///////PRS/27/2/AU/P/ USA/USA/Z4354753//P/20011114////SMITH/ANDREW JACKSON/ 19620511/M/USA//8501/B/345235///////

Both passengers have been found in the visa database by the AP, and both have been given code 8501 (“OK to Board”). An expected movement record has been sent to the participating

EXAMPLE 9: Not all passengers processed successfully

government for each passenger.


CIRQ:/123456/N//20/INT/8/S/BA033/KUL/SYD/19981030//// PRQ/22/1/P/USA//Z4351213///////SMIT/////////// PRQ/22/2/P/USA//Z43547///////SMIT///////////

Details of two passengers (with the same family name, but with different passports) are submitted by the airline.



CIRS:/PRS/27/1/AU/P/USA/USA/Z4351213//P/20011114////SMITH/ SAMANTHA/19640912/F/USA//8501/B/345234///////PRS/27/2/AU/P/USA// Z43547//P/////SMIT//////0000/E//6033/INVALID PASSPORT NUMBER FORMAT/////



The AP has been able to process o8501 (“OK to Board”). An expect

ne passenger successfully (Samantha Smith) and gives code ed movement record has been sent to the participating

sing the other passenger, and error code 6033 is given (“Invalid passport number format”). No expected movement record has been sent to the participating

bmit the request, taking care to orrectly entered.

government for this passenger.

An error occurred in proces

government for this passenger. The check-in agent should resuensure that the passport number is c

EXAMPLE 10: Some passengers not uniquely identified


CIRQ:/123456/N//20/INT/8/S/BA033/KUL/SYD/19981030//// PRQ/22/1/P/NZL//Z4351213///////SMIT/////////// PRQ/22/2/P/NZL//Z4354888///////SMIT///////////

Details of two passengers (with the same family name, but with different passports) are submitted by the airline. The airlithan one passenger in the respons

ne has indicated that it cannot accept responses for more e 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 n sent to the participating

e”). No nt for these passengers.

The check-in agent should submit a request for the other passport, this time providing enough

code 8501 (“OK to Board”). An expected movement record has beegovernment 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 namexpected movement record has been sent to the participating governme

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.

Australia

Check-in PortThailand

Bangkok

Sydney

Expected Port

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

schedules) that QF016 flies BKK-MEL-SYD, and that MEL is therefore the trans-border port

and disembarking in Sydney.

[The CG sends 5-1 message to AP-AU which includes the fact (obtained from the airline

for the flight. AP-AU responds with 6-1 message]



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.

Sydney

Melbourne

Los AngelesChicago

Figure 10 – M L) ulti-Leg Journey (CHI-LAX-SYD-ME

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

CHI. AP-AU responds with 6-1 message]

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



The AP has confirmed that the passenger has a visa and has given code 8501 (“OK to Board”). An expected movement record has been sent to the participating government for this passenger listing CHI as the check-in port, SYD as the trans-border port, and MEL as the expected port.



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]



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

details as advised by the airline. passenger, including the full flight

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//Z4351213///////SMIT///////////

The airline submits a request for a passenger on an international flight flagged as “Unscheduled”, and with the flight numthe date and time of departure and

ber QF016D showing “D” for delayed. Full details of arrival are included. Since the flight actually has the route

or a

BKK-MEL-SYD (in which MEL is the trans-border port, and SYD is the expected port fthis passenger), the airline has also provided (in the “TBD” [trans-border destination] datgroup) 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]





The AP has confirmed that the passenger has a visa and has given code 8501 (“OK to government for this

tails as advised by the airline. Board”). An expected movement record has been sent to the participatingpassenger, including the full flight de



6.1.6 Overriding a Boarding Directive

APP countries]

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 [NOTE: This example assumes that both Australia and Malaysia are






CIRS:111/PRS/27/1/MY/P/USA/USA/Z4351213//P/20011114//// SAMANTHA TAYLOR SMITH//19640912/F/USA//8501/B//////// PRS/27/1/AU/P/USA/USA/Z4351213//P/20011114////SMITH/SAMANTHA/ 19640912/F/USA//8502/D////////

The passenger has been given 8501 (“OK to Board”) by Malaysia but 8502 (“Do Not Board”) by Australia. The Passenger Status returned by Australia is “D” indicating that data is available for the passenger and that the directive may be overridden after further assessment of the case. No expected movement has been generated for Australia and the expected movement originally generated for Malaysia has been cancelled.

The airline has contacted the Australian authorities and has obtained permission for uplifting the passenger. The transaction is submitted again with an override code applicable for Australia.


CIRQ:111/123456/N//20/INT/8/S/BA033/KUL/SYD/19981030//// PRQ/22/1/P/USA//Z4351213///////SMIT////////GAU///






CIRS:111/PRS/27/1/MY/P/USA/USA/Z4351213//P/20011114//// SAMANTHA TAYLOR SMITH//19640912/F/USA//8501/B/18745/////// PRS/27/1/AU/P/USA/USA/Z4351213//P/20011114////SMITH/SAMANTHA/ 19640912/F/USA//8517/B/18745///////

The passenger has been given 8501 (“OK to Board”) by Malaysia and 8517 (“OverridAccepted”) by Australia. An expected movement record has been sent to each of the

e

tries PP countries]

participating governments.

EXAMPLE 16: Multiple passengers, one requiring override for both coun[NOTE: This example assumes that both Australia and Malaysia are A


CIRQ:111/123456/N//20/INT/8/S/BA033/KUL/SYD/19981030//// PRQ/22/1/P/USA//Z4351213///////SMIT/////////// PRQ/22/2/P/USA//Z4354753///////SMIT///////////




CIRS:111/PRS/27/1/MY/P/USA/USA/Z4351213//P/20011114//// SAMANTHA TAYLOR SMITH//19640912/F/USA//8501/B/18743/////// PRS/27/1/AU/P/USA/USA/Z4351213//P/20011114////SMITH/SAMANTHA/ 19640912/F/USA//8501/B/18743/////// PRS/27/2/MY/P/USA/USA/Z4354753//P/20011114////SMITH/ ANDREW JACKSON/19620511/M/USA//8502/D//////// PRS/27/2/AU/P/USA/USA/Z4354753//P/20011114////SMITH/ ANDREW JACKSON/19620511/M/USA//8502/D////////

The first passenger has been given 8501 (“OK to Board”) by both countries and expected

these directives nts have been

alaysia 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.

movements have been generated. No further action is necessary for the passenger.

The second passenger has been denied boarding by both countries, but bothmay be overridden after further assessment of the case. No expected movemegenerated for the passenger.

The airline has decided that there is no reason for the passenger to be denied boarding fromM




CIRQ:111/123456/N//20/INT/8/S/BA033/KUL/SYD/19981030//// PRQ/22/1/P/USA//Z4354753///////SMIT////////AMYGAU///




CIRS:111/PRS/27/1/MY/P/USA/USA/Z4354753//P/20011114//// SMITH/ANDREW JACKSON/19620511/M/USA//8517/B/18777/////// PRS/27/1/AU/P/USA/USA/Z4354753//P/20011114////SMITH/ANDREW JACKSON/19620511/M/USA//8517/B/18777///////

The passenger has been given 8517 (“Override accepted”) by both countries. An expected movement record has been sent to each of the participating governments.



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.

Australia


Transit Airport

Sydney

Bangkok

Los Angeles USA

QF302

QF107

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.




The AP has confirmed that the passenger is permitted to transit Australia and has given code 8501 (“OK to Board”). An expected movement record has been sent to the participating government indicating that the passenger will be transiting Sydney.




CIRQ:/123456/N//20/INT/8/S/QF107/SYD/LAX/19981031//// PRQ/22/1/P/USA//Z4351213///////SMIT//////Y/////

If the airline wants to through-check the passenger, the airline sends a request showing that passenger SMITH will be boarding QF107 in Sydney and disembarking in Los Angeles, but will be in transit in Sydney at the origin of the outbound international flight.




The AP has confirmed that the passenger is permitted to board the flight and has given code 8501 (“OK to Board”). An expected movement record has been sent to the participating government indicating that the passenger will be departing after having been in transit in Sydney.



6.1.8 Transit on Single Flight

passenger in transit on a single international flight and is The following example relates to aillustrated by Figure 12.

Australia

Bangkok


Transit Airport

Sydney

Los Angeles USA

TG398

TG398

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.




The AP has confirmed that the passenger is permitted to transit Australia and has given code 8501 (“OK to Board”). An expected movement record has been sent to the participating government indicating that the passenger will be transiting Sydney.



6.1.9 Timeout

The following two examples relate to timeouts occurring on one or more government systems and are illustrated by Figure 8.

EXAMPLE 19: Timeout on one government system [NOTE: This example assumes that both Australia and Malaysia are APP countries]




[CG sends 5-1 message to AP-AU and AP-AU does not respond.]


CIRS:111/PRS/27/1/MY/P/USA/USA/Z4351213//P/20011114//// SAMANTHA TAYLOR SMITH//19640912/F/USA//8501/B/2129999/////// PRS/27/1/AU/P/USA//Z4351213//P///////////0000/T////////

The passenger has been given 8501 (“OK to Board”) by Malaysia but the Australian system

h (all) government systems [NOTE: This example assumes that both Australia and Malaysia are APP countries]

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 bot



[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

r a Single Passenger

r a single passenger and are

assenger located

6.2.1 Cancel Movement fo

The following four examples relate to cancellation of APP foillustrated by Figure 8.

EXAMPLE 21: Cancellation: p

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 passfamily name (in part), and also the Expected Passenger ID.

port number, nationality,

which responds with 6-2 message including the full [CG sends 5-2 message to AP-AUpassenger 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

EXAMPLE 22: Cancellation: passenger not located

for this passenger, flagged as a cancellation.


CICX:/123456/N//20/INT/8/S/BA033/KUL/SYD/19981030////PCX/20/1//P/USA//Z4351213///////SMIT////////

The airline submits a cancellation request with the passenger’s passport number, nationality,

which responds with 6-2 message carrying the code 8506

family name (in part), but without the Expected Passenger ID.

[CG sends 5-2 message to AP-AU(“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 ck-in agent should check the details

and resubmit the cancellation (preferably supplying the Expected Passenger ID, which is ).

transaction for this passenger cannot be found. The che

proof that a previous successful APP transaction occurred

EXAMPLE 23: Cancellation: error condition (passport format error)


CICX:/123456/N//20/INT/8/S/BA033/KUL/SYD/19981030////PCX/20/1//P/USA//Z43512///////SMIT////////

The airline submits a cancellation request with the passenger’s passport number, nationality, family name (in part), but without the Expected Passenger ID.

[CG sends 5-2 message to AP-AU which responds with 6-2 message carrying the code 6033 (“Invalid passport number format”)]


CICC:/PCC/26/1/AU/P/USA//Z43512//P/////SMIT//////0000/E/6033/ INVALID PASSPORT NUMBER FORMAT/////

The AP has been unable to process the cancellation because it has detected that the passpornumber for this passenger does not conform to the valid number format for this nationality

t .

to ensure that The check-in agent should resubmit a cancellation for the passenger, taking care 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 illustrated by Figure 8.

EXAMPLE 24: Cancellation: multiple passengers


CICX:/123456/N//20/INT/8/S/BA033/KUL/SYD/19981030////PCX/20/1//P/USA//Z4351213///////SMIT/SAMANTHA///////PCX/20/2//P/USA// Z4351213///////SMITH/BELINDA///////

The airline submits a cancellation request for two passengers with the same passport number,

ds with 6-2 message carrying the code 8505 for each passenger.]

nationality and family name (in part), but with different given names and without the Expected Passenger IDs.

[CG sends 5-2 message to AP-AU which respon(“Cancelled”) and the full biodata


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)

lete CIRQ message Below is an example of a complete CIRQ message, including the Layer 5 and Layer 7

31415054 5A5A2F49

5A5A

F2F2F2F 2F55530D 02434952

513A3031 2F50452F 4E2F2F32 302F494E542F 382F

0 / I N T / 8 /

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

EXAMPLE 25: Comp

message headers, from ZZ airline:

562E0D56 484C472E 57412F45

V . . V H L G . W A / E 1 A P T Z Z / I

35415054 58532F50 30303039 0D56475A 0D56

5 A P T X S / P 0 0 0 9 . V G Z . V Z Z

2F53464F 2F2F2F2F 2

/ S F O / / / / / / / / / U S . . C I R

Q : 0 1 / P E / N / / 2

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



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.

Message code

Brief description (max 22 chars) Action required by airline Notes Code used by

Australia? Code used by New Zealand?

Passenger Status Code

8501 OK TO BOARD Allow the passenger to board. An expected passenger movement habeen created.

YES YES B s

8502 DO NOT BOARD Do not allow the passenger to board.

An expected movement record has nobeen created. However, all the requirdata is available for the passenger anddirective may be overridden after referto published guidelines (Override codeor after contact with government agenc(Override code “G”).

YES YES D t ed the ence “A”) ies

8505 CANCELLED (Confirmation that cancellation was successful).

A previous movement has been cance(i.e. where passenger previously rece“OK to Board” or equivalent for this flig

YES YES C lled ived ht).

8506 NO RECORD (Advice that cancellation was not successful).

An attempt was made to cancel a prevmovement (for this flight) but no recordbe found to cancel.

YES YES N ious can

8507 DUPLICATE NAME Do not allow the passenger to board. Retry APP for this passenger using additional data.

There is more than one person on the passport matching the data provided. to include additional biodata (eg. a givename or the date of birth).

YES YES U Need n


Mes ge saco e d

Brief description (max 22 chars) Action required by airline Notes Code used by

Australia? Code used by New Zealand?

Passenger Status Code

8510 CONTACT EOC Do not allow the passenger to board

An expected movement record has not been created. However, all the required

YES (exclusive)

NO D

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 give erride code of “G” must be used.

n, an ov

8516 INSUFFICIENT DATA board. Provide the full set of

the

nd ent databases. Full data for

a

Do not allow the passenger to

passport and personal data for passenger.

Data on the passenger has not been fouin the governmthe passenger must be captured before decision can be made.

YES YES I

8517 OVERRIDE ACCEPTED Allow the passenger to board. YES YES B The override submitted has been accepted. An expected passenger movement has been created.

8519 BRD WITH OWT Allow the passenger to board as long as they have an onward ess a ticket for an

NO YES (exclusive)

B

ticket.

The passenger cannot be permitted to board unless they possonward journey from New Zealand. An expected movement record has been created.

8520 CONTACT NZIS

the passenger. The the

ssenger is given, an override code of “G” must be used.

(exclusive) Do not allow the passenger to board

An expected movement record has not been created. However, all the required data is available for Check-in agent must seek advice from Advance Passenger Screening (APS) Support Office, NZIS, Auckland, New Zealand (Tel: +64-9-277-1250). If permission to board the pa

NO YES D

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 code riginating from the CG.

s o

Error Code Description

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




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




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




5615 Flight already loaded 5616 PNR record locator invalid

Table 24 – CG Error Codes

Notes o or Cn Err odes:

1. are S or CICC These all errors which may be passed back to the airline in CIRmessages.

2. rline the user. The ai system should display the code to

3. ding may retry the transaction, and if the Depen on the nature of the error the user error rema SITA Help Desk. ins, it should be reported to the



2. AP Error Codes (Australia and New Zealand)

The table below (Table 25) contains error codes originating from the Australian and New Zealand APs.

Used By Error Code Description

AU NZ 6000 Validation error – unknown field Yes Yes 6001 Invalid family name format Yes Yes 6002 Given names format invalid Yes Yes 60 es 03 Invalid nationality code Yes Y60 sex code Yes Yes 04 Invalid6005 Invalid visa type Yes 60 Yes 06 Invalid middle name 6007 Invalid airline code Yes 60 Yes Yes 09 Invalid expiry date 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




AU NZ 6056 Expected date invalid Yes Yes 6057 Expected time invalid Yes Yes 6058 Passenger sequence number required Y es Yes6059 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

error. Yes Yes

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 logi

Message ID. cal transaction Yes Yes

6983 Invalid Message ID. Need to use previous logical transaction Message Id.

Yes Yes

6984 System error with alert check Yes Yes 6985 Duplicate Message ID. Message ID has been used by another

User. Yes Yes

6987 No History or scrolling outside range Yes Yes




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)

Note rs on E ror Codes:

1. se S CC The are all errors which may be passed back to the airline in CIR or CImessages.

2. a to the user. The irline system should display the code

3. e or the user may retry the transactio d ifDep nding on the nature of the err n, an the error SITA Help Desk in Atlantaremains, it should be reported to the .



APPENDIX C

NCE

MANUAL MAINTENAOF 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 A

Security Access Any authorised airline user who has normal APP transaction access can use this facility.

Procedures There are three proc ight schedule and delete a flight sched

1. Display a Flight Schedule

a) Command format:

TIETAYT D/{flight number} [INPUT]

tlanta).

edures: display an existing flight schedule, load a new flule.

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:

flight no}/{effective date}/{discontinue date}/{frequency}/ TIETAYT A/{

{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

age y ediate ports can be provided for a flight, but most unscheduled er ill have only origin and destination ports.

he n element is required only if the date differs from the date of departure from the origin port.

line schedules are updated on the APP System, any manually This update occurs

ust therefore hedule if it is needed beyond this weekly cycle.

play flights which are operated by itself or its code

c) Notes on Usi) An

int number of intermnational flights w

ii) T date variatio

iii) When normal airmaintained flight schedules will be overwritten and thus deleted.once a week (Friday morning 03:00hrs, Atlanta time). An airline mrepeat the process of loading a sc

iv) An airline can only load and disshare 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

GRATED APP

INTE



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 diag of this process.

2. CPS Systems assigns an Im ngle point of contact to coordinate an airline’s implementation of APP. Currently this role is performed by Mr John Leplaw.

3. The CPS Implementa ical staff (both CPS Systems and SITA) t

4. The CPS Implementat ssary communications and systems support requ ons interface connection and application testi

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.

ram which shows an overview

plementation Manager as a si

tion Manager coordinates a team of techno assist with the implementation.

ion Manager coordinates all of the neceired by the airline during the communicati

ng phases.

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. the airline needs to install a new SITA circuit for APP access, CPS Sysrrange for a SITA representative to contact the airline to assist with this

If tems will a 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

Systems will forward a copy of the HTH Protocol Specification to al representative on request.

rotocol,

ess

meter questionnaire and the

access to that airline and will

f st with network and APP application

P) in

c) 1. The government agrees a schedule with airlines, and then provides the CPS

ut schedule.

2. The CPS Implementation Manager contacts each airline representative to discuss the

3. During the development phase the CPS Implementation Manager makes weekly email nes to monitor project progress and to offer assistance if required.

requirements. CPSthe airline’s technic

3. The SITA Account Manager will consult with the airline’s technical representative to determine what connection attributes are required eg. physical interface, pbandwidth, site details and required timeframe. The SITA Account Manager willsubmit the circuit connection request and will regularly monitor the installation progrto 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 paraSITA 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 Systemadvise the airline when this access is available.

The SITA Implementation Coordinator will also provide to the airline contact details oSITA technical staff in Atlanta who can assiconnection issues. From this point the airline may commence testing to the APP Communications Gateway (CG) in Atlanta and the APP Applications Server (ASydney.

Development Phase

Implementation Manager with the rollo

development plan timelines, provide specifications and answer any technical issues that the airlines may have.

contact with the airli



d) System Testing Phase The airline is notified of the procedures involved in satisfying government requirementfor acceptance testing.

The CPS Implementation Manager will forward t

1. s

o the airline’s technical representative the document “Advance Passenger Processing System Test Cases”. This document is

2. he contents of the database are such that it tests and triggers

conditions and exceptions against the government database and alert lists.

3. e ut

4. onduct unlimited testing on a 24*7 basis. All problems encountered or queries about APP functionality during testing should be forwarded to the CPS

5. mplementation Manager uses database tools to verify that the airline transactions conform to the requirements of the APP

e) tance Testing Phase . Prior to the acceptance test phase it is recommended that the airline activate a network

onment. This will identify any production n be resolved well before cutover to production.

cutover to production.

4. During the acceptance test the airline is asked to process via APP check-in each

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

designed to facilitate airline testing, although unit and integrated testing by the airline need not be limited to the biodata contained in this document.

The same test database can be a perpetual database for use by all participating airlines before and after cutover. T

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 AirlinAccess Tables on the test system. (An airline cannot access the APP System withothe correct parameters being loaded in the Access Tables in Atlanta).

The airline can c

Implementation Manager for resolution.

When test transactions have been sent, the CPS I

System specification, in particular the Layer 7 addressing.

Accep1

layer connection from their production envirnetwork connectivity issues that ca

2. When an airline has tested the application satisfactorily it contacts the CPS Implementation Manager and requests permission to

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.

passenger listed in the test database. Expected Movement Records generated as a resultof airline acceptance testing are then passed to the government for validation against the



representative, the CPS ImplementatioProduction System access for that airl

n Manager will authorise SITA to provide APP ine. The CPS Implementation Manager will

6. the prior approval of the government, to conduct limited and

7. y e the airline

1. ived for an airline to move to production status, and the airline is ready for the production rollout of APP, they will advise the

P

. The CPS Implementation Manager arranges for the airline’s parameters to be loaded in the production Communications Gateway access tables.

akes a simple

4.

5.

advise the airline when Production System access has been granted.

The airline may elect, with 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.

All issues resulting from the acceptance test must be resolved and a sign off received bthe government representatives and the CPS Implementation Manager beforcan cutover to production.

f) Cutover to Production Once government approval has been rece

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 APflight schedules and rollout dates.

2

3. Migrating from test to production is a simple process. The airline mparameter change in the airline’s Host to Host message header, and this allows terminaltraffic to switch from test to production.

The CPS Implementation Manager monitors the airline’s cutover progress, providing regular status updates to the government.

All post-cutover APP issues determined to be non-airline related should be escalated to the CPS Implementation Manager for investigation.



g) The following are the relevant airline requirements for use of the SITA - IATA Host to Host Protocol (HTH) for APP (and also for ETAS).

Airli

1 ter does the user want to use for the TABSET

(Leave blank for none)

SITA HTH Questionnaire for New Connections

ne Host System Connection Parameter – Questionnaire

Which charac

2 Is the User's system capable of handling question marks “?” (Yes/No)

3 es/No)

Is the User's system capable of handling lower case alpha characters (Y

4 Should we include the Start Of Entry (SOE) in output messages to your system (Yes/No)

e would like to brief you on what we expect from your system at the Host-o-Host communications level. In order to match all the technical and functional requirements of the project the following is required:

on with ATLDP should be based on the the

2

[email protected]

ion of the HTH message header:

Airline Code Your specific 2 letter IATA code

Wt

1 The Host-to-Host communicatistandard document named "Specifications for the Implementation of IATA Host-to-Host Protocol".

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.T

3 In data received from your host we are specifically looking for the following fields included in the Layer 7 port

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 rminal 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.

Number The IATA ID of the inquiring te

Country Code IATA code of the Country where the inquiring terminal is located.



h) Contact Details

CPS Implementation Manager

Email: [email protected]

Telephone: +61-2-9909 3022

Mr. John Leplaw

Facsimile: +61-2-9953 8083

SITA Implementation Coordinator


Telephone: +1-770-612 2388

Mr. Kenneth Hulse

Facsimile: +1-770-303 3639

Aus n APP Coordinator (DIMIA) tralia


Telephone: +61-2-6264 1124

Mr. Ad ian Kelson r

Facsimile: +61-2-6264 1879

New Zealand APP Coordinator (NZIS)


Telephone: +64 -9-918 4447

Lee son Wil

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



Production

CommsLinks

Decision

Cutover

SystemTesting

AcceptanceTesting

Development& Testing

SITA assistsairline with

comms links

START

Airline hasnecessary HTH

network services?

END

Airline decides toimplement APP,

and agreestimetable with


Figure 13 – Implementation Process for Integrated APP

government.

CPS providesInterface

specification toairline.

Governmentadvises CPS of

the airline'srollout schedule.

Airline carries outdevelopment (ie.changes to DCS)

CPS providesacceptance

testingspecification to

airline.

Airline is ready forsystem testing?

Airline is ready foracceptance

testing?

CPS prairline with

access to testsystem.

ovides Airlineundertakestesting with

support fromCPS.

Airlineundertakesacceptancetesting with

support fromCPS.

Acceptance off by Govern

and CPS?

sign-ment

CPS providesairline withaccess toproduction

system.

Airline changesmessage header

parameter(switching

transactions toproductionsystem).

Airline carries outlive APP

transactions forflights.

NO

NO

YES

Y

NO

ES

YES

YES

NO


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 th roup of the CIRQ message and shows which fields must be prov s of Australia and New Zealand. The differences between the two countries are shaded.

Note that the presence of the data items in this t imply that the airlines must captur

1. I ed 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.

e data fields in the PRQ data gided to the government system

table does noe the data items at check-in. The rules for APP processing are:

f the passenger data provided in the check-in enquiry for a passenger can be match

PRQ Ref.

Data Item Field in MRZ?

Mandatory for New Zealand?

Mandatory for Australia?

4 Pax/Crew Indicator Yes Yes 5 Passport Country Code (Nationality) Yes2 Yes Yes 6 Issuing State Yes2 Yes3 No1, 3

7 Passport ID/Document ID Yes2 Yes3 Yes3

8 Passport/Document Check Character Yes2 No No 9 Travel Document Type Yes Yes 10 Travel Document Expiry Date Yes2 Yes3 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 15 Given Names Yes2 Yes4 Yes4

16 Date of Birth Yes2 Yes Yes 17 Sex Yes2 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)
