BEFORE THE

DEPARTMENT OF TRANSPORTATION

WASHINGTON, D.C.

Notice of IATA Traffic Conference

Actions Tentatively Exempted 

From Filing for Approval

Docket OST-2012-0058

NOTICE OF TIER 1 AGREEMENTS FILING

BY THE

INTERNATIONAL AIR TRANSPORT ASSOCIATION

4 July 2013

Communications with respect to this

Document should be sent to 

Douglas Lavin 

Regional Vice President – North America 

International Air Transport Association

1201 F Street, NW, Suite 650 

Washington, DC 20004 

(202) 628-9292
Summary DOCKET: DOT-OST-2012-0058 DOT ORDER: None Requested

Date: 4 July 2013

Filing fee/IATA Acct: Waived by Order 2012-4-18, Appendix 

A, Section D

US/UST involved Yes

Intended effective date: 1 June 2012

Meeting site, date: 33rd Passenger Services Conference 

(PSC), Singapore, 12-13 October 2011

Agreement(s)/Minutes PSC/RESO/151 bis dated 4 July 2013

PSC/MINS/038 dated 23 February 2012

Resolutions 003, 720a, 722, 722f, 722g, 

722h, 725a, 725b, 725d, 725f, 725g, 

725h, 726e, 728, 762, 763, 767, 780e and 

792.

Recommended Practices 1701a, 1701d, 

1701h, 1701i, 1701j, 1701k, 1706, 1706c, 

1707a, 1707b, 1708, 1715, 1719, 1719b, 

1720a, 1728, 1739, 1740c, 1745, 1790

and 1797.
NOTICE OF TIER 1 AGREEMENTS FILING

Pursuant to statements submitted by Member airlines of the International Air Transport 

Association (IATA), the undersigned has been constituted to be their attorney-in-fact for filing 

with the Department of Transportation copies of agreements adopted by the IATA Traffic 

Conferences.

On their behalf, and pursuant to the procedures specified in Order 2012-4-18 (13 April 

2012), I am filing with the Department, in Docket OST-2012-0058, this Notice, the subject 

agreements and supporting documentation. These agreements are Tier 1 agreements tentatively 

exempted by Order 2012-4-18 from Condition #2 to the Department’s approval of the Provisions 

for the Conduct of the IATA Traffic Conferences, which condition requires pre-implementation 

Department review. The intended effective date of the agreements is 1 June 2012. 

The subject agreements amend or establish Resolutions and/or Recommended Practices 

that do not address subject areas which the Department has indicated it still chooses to review 

under Condition #2. The text of the agreements and other conference documentation sent to 

airline Members of IATA accompany this Notice. The cover pages of the documentation clearly 

identify each affected Resolution and/or Recommended Practice and show whether the subject 

agreements are amendments or new agreements. Other pages provide the text of each subject 

agreement. Where an affected Resolution or Recommended Practice has previously been 

exempted from Condition #2 by Department action, the cover pages include the appropriate 

docket and order number. The cover pages include a summary to explain the nature and purpose 

of the subject amendments and/or agreements.
- 2 - 13461343.1

Respectfully submitted,

 /s/ Douglas Lavin

Douglas Lavin

Regional Vice President – North America

International Air Transport Association

Attorney-In-Fact
- 3 - 13461343.1

CERTIFICATE OF SERVICE

A copy of this notice has been served this day by first class or priority mail on the 

following person:

Chief, Transportation, Energy & Agriculture Section

Antitrust Division

Department of Justice 

Washington, D.C. 20530

A copy of this notice has been sent this day by email to John Kiser (John.Kiser@dot.gov) 

and to Della Davis (Della.Davis@dot.gov) of the Department of Transportation. 

 /s/ Douglas Lavin

Douglas Lavin

4 July 2013

Date Served
-

4- 13461343.1
MINUTES 

31st Joint ATA/IATA Passenger Services Conference (JPSC) 

33rd IATA Passenger Services Conference (PSC) 

Singapore 

12-13 October 2011 

International Air Transport Association 

Route de l’Aeroport 33 

PO Box 416 

CH - 1215 Geneva 15 Airport 

Switzerland 

Tel: +41 22 770 2724 

Fax +41 22 770 2662 

 www.iata.org E-Mail: bruyerep@iata.org 

M E M O R A N D U M 

PSC/MINS/038

TO: All Members, Passenger Services Conference - Accredited 

Representatives 

 All Members, Joint ATA/IATA Passenger Services Conference - 

Accredited Representatives (ATA members via Ms P. Edwards) 

COPY: IATA Strategic Partners 

FROM: Head, Passenger Interline Standards 

DATE: 23 February 2012 

SUBJECT: "PASSENGER WEEK 2011"

MINUTES

31st Joint ATA/IATA Passenger Services Conference (JPSC) 

33rd IATA Passenger Services Conference (PSC) 

 Singapore, 12-13 October 2011 

Please find attached the Minutes of the 31st Joint ATA/IATA Passenger Services 

Conference (JPSC) and the 33rd IATA Passenger Services Conference (PSC) as 

approved by the Chairman. 

The “book of finally adopted resolutions & RPs” referred to in these Minutes are issued 

under cover of Memorandum PSC/RESO/151 dated 23 February 2012. 

Michael Muller 

M I N U T E S 

31st Joint ATA/IATA Passenger Services Conference (JPSC) 

33rd IATA Passenger Services Conference (PSC) 

Singapore, 12-13 October 2011 

TABLE OF CONTENTS 

Agenda 

Item 

Subject Page 

Number 

ADMINISTRATION 

 

A1 Opening of Meeting 1 

A2 Examination of Credentials of Accredited Representatives 1 

A3 Approval of Minutes – JPSC/30 and PSC/32 1 

A4 Status of PSC Resolutions and RPs 2 

A5 Effectiveness Date of Amendments to Industry Standards 2 

A6 Any Other Business 2 

A7 Date and Place of Next Meeting 2 

 

POLICY 

P1 Report – Status of Industry Coding Systems 2 

P2 Ratification of Special Fees and Charges Codes (Resolution 

728) 

2 

P3 Report – Coding Working Group (Resolutions 762, 763 and 

767) 

3 

P4 Airline Designator and Accounting Code for an Indirect Air 

Carrier (Resolutions 762 and 767) 

3 

P4.1 Airline Designators for ULD Owners (Resolution 762) 3 
P5 Report – BSP Form Codes and Document Supply Chain 3 

P5.1 Changes to RP 1720a New Form Codes for EMD 4 

P5.2 Changes to RP 1720a New Form Codes 4 

P6 Report – Simplifying the Business (StB) 4 

P6.1 Report – Automated Baggage Rules Task Force (ABRTF) 4 

P6.2 Report – IATA e-services 4 

P6.3 Report – Fast Travel / Passenger Experience Working Group 

(PEMG) 

5 

P6.3.1 RP 1701a - Passenger Data Harmonization 5 

P6.3.2 RP 1701d - Self-Service Automated Document Check 5 

P6.3.3 RP 1701h - Security Checkpoint Access and Egress 5 

P6.3.4 RP 1701k - Self-Boarding 5 

P6.3.5 RP 1701j Automated and Self-Service Flight Rebooking for Irregular 

Operations 

6 

P6.3.6 RP 1701 l - International Traveler Scheme 6 

P6.3.7 RP 1706c – Common Use Self-Service (CUSS) 6 

P6.3.8 RP 1797 – Common Use Passenger Processing Systems (CUPPS) 6 

P6.3.9 Resolution 792 – Bar Coded Boarding Pass (BCBP) – Version 5 7 

P7 Co-ordination with the Commission of European Communities 

(CEC) on PSC Matters 

7 

P8 Elimination of Remaining Paper Tickets – Paper Out Strategy 7 

P8.1 Add Paragraph 2.2.6 to Resolution 780e 8 

P9 ZED-MIBA Forum – Sunset of Paper Tickets for Interline Staff 

Travel 

8 

P10 Report – Passenger Distribution Group (PDG) 8 
P11 Report - PCI DSS Working Group (PDWG) 8 

P12 Co-ordination with the US Department of Transportation (DoT) – 

Initiative for Self-Assessment 

8 

P13 US DoT – Enhancing Airline Passenger Protections Bill 9 

P14 Report – Involuntary Rerouting Working Group (IRWG) 9 

 

AIRPORT SERVICES 

 

B1 Report of the Airport Services Committee (ASC) 9 

B1.1 ASC Membership 9 

B1.2 ASC Election of Chairman 9 

B1.3 ATA Baggage Committee – Terms of Reference and Membership 9 

B2 Report of the IATA Ground Handling Council (IGHC) 9 

B3 Report – Fast Travel – Passenger Experience Management Group 

(Resolution 705) 

10 

B4 Report of the Baggage Working Group (BWG) 10 

B4.1 The New Baggage Steering Group 10 

B5 Report of the DCS Messages Working Group (DCSMWG) 10 

B6 Standardized Special Baggage Codes 10 

 

B7/P DCS Working Group Packaged Items 11 

B7.1/P Add Time and Date Variation to .O/ Element 11 

B7.2/P Editorial Issues in RP1706 – Add Baggage Information Message 

(BIM) 

11

B7.3/P Number of Services in Remarks Elements in DCS Messages 11 

B7.4/P Clarification of Name Fields in the SSR DOCS 11 

B7.5/P Report – OCI DSS Working Group (PDWG) 12 

B7.6/P SSR UPGR Upgrades 12 

B7.7/P Editorials for New PSC Resolutions Manual 12

B7.8/P Unique Passenger Per Segment Identifier 12 

B7.9/P Web Check –in Data on PNL / ADL 13 
 

B8/P Baggage Working Group Packaged Items 13 

B8.1/P Resolution 740 / RP 1740a Review 13 

B8.2/P RP 1740c review 13 

B8.3/P Creation of a BSM Testing Contact List 13 

B8.4/P Clarify and Correct Errors in RP 1745 re Batch BSM 14 

B8.5/P Amendments to RP 1745 Section 9 Baggage Manifest Message 

(BMM) 

14 

B8.6/P Amendments to RP 1745 Section 8 Baggage Control Messages 14 

B8.7/P Amendments to RP 1745 Section 7 Baggage Not Seen Message 

(BNS) 

14 

B8.8/P RP1739, Attachment ‘E’ – Add RP1800 Reference to ‘Common 

Automation Methods’ 

14 

B8.9/P Editorial Issues in RP 1745 – BNS,.H Missing in Example 

Messages 

15 

B8.10/P Editorial Issues in RP 1745 – Attachment E 15 

B8.11/P Editorial Issues in RP 1745 – Inconsistencies in .U Example 

Message 

15 

B8.12/P Editorial Issues in RP 1745 and other – Questionable reference to 

the ‘IATA Systems and Communication Reference Manual’ 

15 

B8.13/P Editorial Issues in RP1740c – References 15 

 

B9 Second City/Airport Code in PNL 16 

 

TICKETING 

 

T1 Report of the Ticketing Committee 

Selection of Committee Membership for the IATA Passenger 

Forms and Procedures Committee (PFPC) 

16 

 

T2/P Ticketing “Package” 16 

T2.1/P Remove the Condition on ET Coupon before Requesting Control 

of EMD-A Coupon 

17 

T2.2/P Disassociate when Carrier Not Part of the Itinerary Obtains Control 

of ETKT or EMD Coupon 

17 

T2.3/P Amendment to Definition of Coupon Status Indicator ‘C’ (CheckedIn) 

17 
T2.4/P Disassociation Upon COS to ‘E’, ‘P’, ‘R’, ‘X’ 17 

T2.5/P Remove Mandate to Request EMD Control 18 

T2.6/P Revise EMD Definitions in RP 1790 and ATA 10.90 18 

T2.7/P Revise ‘Consumed At Issuance’ Glossary Definition 

(Superseded by agenda items T2.21/P and T2.22/P) 

18 

T2.8/P Clarify Definition of System Update Message 18 

T2.9/P Add ‘In Connection With Qualifier’ to ET Neutral Display 

Response 

18 

T2.10/P Revise Ambiguous EMD Definitions 19 

T2.11/P Remove Mandate for Disassociation Prior to Coupon Status 

Update 

19 

T2.12/P Removal of XT from fare Calculation 19 

T2.13/P Revise Coupon Notification Coupon Status Indicator 19 

T2.14/P Amendment to System Update 19 

T2.15/P Amendment to Change of Status 20 

T2.16/P Unsolicited Airport Control to Marketing Carrier with Flown 

Information 

20 

T2.17/P Remove RFISC from EMD Refund Cancel response Message 20 

T2.18/P EMD Special Characters used in Reason for Issuance Sub-Code 

Description 

20 

T2.19/P EMD Mutual Exclusivity of Coupon Value and Fare Calculation 20 

T2.20/P EMD Product Characteristics 21 

T2.21/P EMD Update Glossary Definition of Consumed at Issuance 

Indicator 

21 

T2.22/P EMD Consumed at Issuance Indicator Glossary Definition 21 

T2.23/P Addition of Attribute Group and Attribute Sub-Group 21 

T2.24/P Inconsistency in EMD Coupon Status Definitions 21 

T2.25/P Unsolicited Billing Message 22 

T2.26/P EMD Create Dependency Between RFIC and RFISC 22 

T2.27/P Definition of Total Ticket Document Amount 22 

T2.28/P Add ABR MSC Information to the ET Record 22 

T2.29/P Resolution Editorials 23 
T2.30/P Current Surcharge Ticketing – RAWG Requests 23 

T2.31/P Current Surcharge Ticketing – Clean-Up 23 

T2.32/P Expiry of Neutral Paper Documents 23 

T2.33/P Delete Reference to Sundry Charges 24 

T2.34/P Single Source RBD Service 24 

T2.35/P Industry Implementation Strategy for Alphanumeric TFC Coding 24 

T3 Credit Card as FOID and PCI DSS Compliancy 24 

T4 Fee Calculation on EMD 24 

T5 Update to Resolution 728 25 

T6 Current Surcharge Ticketing – Reductions 25 

T7 Deletion of Carrier Fee Type OA 25 

T8 Corrections to Matrices for Carrier Fees 25 

T9 Removal of Tax Reporting Form From Resolution 728 25 

T10 Reporting of Taxes at Coupon Level 26 

T11 “Consumed at Issuance” Indicator 26 

 

RESERVATIONS 

 

R1 Report – ATA/IATA Reservations Committee (ResCom) 27 

R2 Report – Reservations Working Group (RESWG) 27 

R3 Remove Credit Cards as Form of Identification (FOID) 27 

R4 SSR Matrix 27 

R5 EMD-S and SVC – Number of Location Codes 27 

R6/P Reservations “Package” 28 

R6.1/P Allow HS to be Sent Without a Previously Received KD 28 

R6.2/P New SSR PCTC Example 28 

R6.3/P Advanced Passenger Information (API) Codes 28 

R6.4/P Advice of Electronic Ticket Number for Passive Segments Where 

a Passive Segment Notification Agreement Exists 

28 
R6.5/P Service PNR Message 29 

R6.6/P SSR UPGR Upgrades 29 

R6.7/P Visa Place of Issuance in SSR DOCO 29 

R6.8/P Add Military ID (M) to list of Travel Documents for SSR DOCS in 

AIRIMP 

29 

R6.9/P Establish procedures for accurate completion of SSR DOCS 29 

R6.10/P Clarification of Name Fields in the SSR DOCS 29 

R6.11/P SSR DOCx for Passive Segments 30 

R6.12/P Infant without a Seat and EMD issuance 30 

R6.13/P Update paragraph references in AIRIMP 30 

R6.14/P Editorial Repairs to AIRIMP 30 

R6.15/P Multiple services for one passenger in AIRIMP 30 

R6.16/P Bilateral SSRs 30

R6.17/P Seat Characteristics in Replies 31 

R6.18/P Additional Services 31 

R6.19/P Unsolicited Reply Messages 31 

R6.20/P Correct SSR DOCS Examples 31 

MISCELLANEOUS 

 

M1 Report – PSC Steering Group (PSCSG) 31 

M2 Report – PADIS Board (PADIS) 32 

M2.1 Report – PNRGOV Working Group 32 

M3 Report – Cargo Services Conference (CSC) 32 

M4 Report – Scheduling Services 32 

M4.1 Report – Schedules Information Standards Committee (SISC) 32 

M5 Report – Fraud Prevention Working Group (FPWG) 32 

M5.1 Circulation of Fraudulent Emails under IATA’s Name 32 

M6 Report – BSP Data Interchange Standards Group (BDISG) 32 

M7 Report – Strategic Partnerships 32 

M8 Report - Agency Solutions Technical Working Group (ASTWG) 33 

M9 Rescinding AIRDES (RP 1737) and Reconfirmation Procedures 

(RP 1762) 

33 

 

 Close of Meeting 33 

1 

MINUTES 

31st Joint ATA/IATA Passenger Services Conference (JPSC) 

33rd IATA Passenger Services Conference (PSC) 

Singapore, 12-13 October 2011 

ADMINISTRATION 

A1 Opening of Meeting 

1. The Chairman, Mrs. Patricia George, opened the 31st Joint ATA/IATA 

Passenger Services Conference (JPSC) and the 33rd IATA Passenger 

Services Conference (PSC) at 1400 hours on 12 October 2011. She 

introduced Rosalie Crabbe (UA), Chairperson of the ATA Passenger Council. 

The Chairman welcomed IATA’s new legal counsel, Mr Daniel Kanter, and 

she expressed her thanks to his predecessor, Mr Colin Flynn, who had 

recently taken up a senior position in the legal department of SQ. The 

attendance list is shown in Attachment A. 

2. The Chairman reminded the meeting of the importance of the industry 

standard-setting which took place under the auspices of the JPSC and its 

committees. These industry standards had enabled the Simplifying the 

Business strategy to be successful in areas such as Electronic Ticketing and 

other global industry projects and provided a solid foundation on which the 

Board of Governors would be able to base its recommendations for future 

industry projects. 

3. Conference noted the anti-trust warnings regarding discussion on 

competitively sensitive topics as well as meeting guidelines for the Chairman 

and delegates. 

A2 Examination of Credentials of Accredited Representatives 

4. Conference noted the list of IATA PSC accredited representatives and ATA 

Passenger Council representatives. 

Secretary note: towards the end of 2011 the ATA (Air Transport Association 

of America) re-branded itself as the A4A - Airlines for America. 

A3 Approval of Minutes – JPSC/30 and PSC/32 

5. Conference approved as published the Minutes from the 30th meeting of the 

JPSC and 32nd meeting of the PSC. 
2 

A4 Status of PSC Resolutions and RPs 

6. The Secretary, Mr Mike Muller (IATA), reported that he had received approval 

from the US Department of Transportation (DoT) for the Book of Finally 

Adopted Resolutions and RPs (BoF) from the 2008 meeting. He advised that 

IATA had not yet filed the BoF from the 2009 and 2010 meetings in 

anticipation of positive action on the IATA initiative to move to a selfassessment environment (refer to agenda item P12). 

A5 Effectiveness Date of Amendments to Industry Standards 

7. Conference confirmed that the general effective date of 1 June 2012 would 

apply to all amendments regarding Resolutions, RPs and AIRIMP unless 

otherwise agreed. 

A6 Any Other Business 

8. No other business was presented. 

A7 Date and Place of Next Meeting 

9. The Secretary advised that it is planned to hold the next meeting in 

conjunction with a commercial event to be held in TC2 in October 2012. Final 

confirmation of dates and venue will be advised. 

Secretary note: the 2012 meeting of the Joint A4A/IATA Passenger 

Services Conference (JPSC) will be held in Abu Dhabi during the week of 15 

October in conjunction with several other industry meetings as well as the 

commercial conference called the World Passenger Symposium. For an 

overview of these events, please refer to the “week-at-a-glance” document 

posted on the PSC private site (refer to folder “PSC 34”), access via: 

http://www.iata.org/workgroups/Pages/psc.aspx

Secretary note: for online information on future IATA meetings, refer to: 

www.iata.org/workgroups/calendar

POLICY 

P1 Report – Status of Industry Coding Systems 

10. Conference noted this report. 

P2 Ratification of Special Fees and Charges Codes (Resolution 728) 

11. Conference agreed to ratify the list of codes shown in Attachment B that had 

been assigned on a provisional basis since the last meeting of the JPSC in 

October 2010. 
3 

12. Mr Dave McEwen (IATA) advised that only 28 alpha/alpha codes remain 

available in the stock and consequently the entire industry needs to ensure 

that it would be able to handle alpha/numeric codes as soon as possible and 

no later than June 2012 (agenda item T2.35/P refers). 

P3 Report – Coding Working Group (Resolutions 762, 763 and 767) 

13. The Coding Working Group (CODEWG) had made a thorough review of the 

coding assignment processes with a view to updating Resolutions 762, 763 

and 767 to simplify and make more transparent the assignment procedures. 

Noting an abstention from Adria Airways, the PSC agreed to amend 

Resolutions 762, 763 and 767 as shown in the book of finally adopted 

Resolutions & RPs. The ATA Passenger Council adopted counterpart 

changes to Resolution 5.38 as shown in Section II of the ATA Minutes. 

14. Conference complimented Mr Karr Cannelin (formerly with Finnair) who had 

voluntarily made a significant contribution to the accuracy of IATA data 

regarding location identifiers. 

15. Conference agreed that the CODEWG should continue its mandate and in 

2012 focus on developing workable solutions for problematic metropolitan 

areas and multiple city locations. Volunteers were noted from JP, OS, LH, 

LY, SITA and UA. 

P4 Airline Designator and Accounting Code for an Indirect Air Carrier 

(Resolutions 762 and 767) 

16. Mr Jim Gallagher (PublicCharters.com) provided an overview of the business 

model of “indirect air carriers” and requested that Resolutions 762 and 767 be 

amended to allow access to IATA codes by such companies. This item failed 

due to lack of support. 

P4.1 Airline Designator for ULD Owners (Resolution 762) 

17. The Secretary noted that Resolution 762 allowed non-airline ULD owners to 

apply for an airline designator code on the condition that they are members of 

the Interline ULD Control User Group (IULDUG). However, since this group 

no longer exists, it was proposed that new criteria be established based on 

participation in the ULD area of the IATA strategic Partnership Program. The 

PSC agreed to amend Resolution 762 as shown in the book of finally adopted 

Resolutions & RPs. The ATA Passenger Council agreed to make counterpart 

changes to Resolution 5.38 as shown in Section II of the ATA Minutes. 

P5 Report – BSP Form Codes and Document Supply Chain 

18. Conference noted this report and Sabre’s comment that GDSs require plenty 

of advance notice for recycling of form codes. 
4 

P5.1 Changes to RP 1720a New Form Codes for EMD 

19. The Ticketing Committee (JPTC) proposed to reassign form codes for use 

with EMD and also proposed to release some form codes for use with OffPremise EMD. The PSC agreed to amend RP 1720a as shown in the book of 

finally adopted Resolutions & RPs. The ATA Passenger Council agreed to 

make counterpart changes to Resolution 20.04 as shown in Section II of the 

ATA Minutes. 

P5.2 Changes to RP1720a New Form Codes 

20. The Transport Clearing House (TCH) of Russia proposed to expand the 

definitions of form codes within the range of 61 to provide more details 

regarding type of tickets per sub-range. The PSC agreed to amend RP 1720a 

as shown in the book of finally adopted Resolutions & RPs. The ATA 

Passenger Council agreed to make counterpart changes to Resolution 20.04 

as shown in Section II of the ATA Minutes. 

P6 Report – Simplifying the Business (StB) 

21. Conference noted the report. Mr Eric Leopold (IATA) advised that a new 

initiative would be launched regarding airline distribution aiming to sell a wide 

range of airline products through all distribution channels, identifying customer 

trends and personalizing both offers and prices. Also another initiative would 

be launched regarding Passenger Facilitation to enable simple and common 

ways for passengers to provide advanced passenger data that different 

governments require. These two new projects would be supported by the 

goals towards sustainable profits and better service reflected on the StB Think 

Tank white paper as shown in Attachment C.

Secretary note: for more information on StB initiatives please refer to: 

http://www.iata.org/whatwedo/stb/Pages/index.aspx

P6.1 Report – Automated Baggage Rules Task Force (ABRTF) 

22. Conference noted this report and disbanded the ABRTF in view that they had 

completed their mandate to automate baggage rules. It was advised that any 

outstanding standards issues should be handled by existing IATA working 

groups and ATPCO. 

P6.2 Report – IATA e-services 

23. Conference noted this report and IATA gave heartfelt thanks to the system 

providers for all their support to airlines to achieve EMD capability. 
5 

P6.3 Report – Fast Travel / Passenger Experience Working Group (PEMG) 

24. Members were reminded that Conference had adopted IATA Resolution 

705/ATA 1.40 to establish the Passenger Experience Management Group 

(PEMG) to drive the development of standards to provide an end-to-end selfservice experience at airports. And that the “end-to-end” passenger process 

is described in IATA RP 1701/ATA 30.301 whereas individual RPs are 

published (or will be developed) in the 1701 series from 1701a to 1701n. 

Conference noted this report. 

P6.3.1 RP 1701a - Passenger Data Harmonization 

25. The Passenger Facilitation Working Group (PFWG) developed a global 

framework for aircraft operators to provide passenger data to States to 

enhance border security. Accordingly the PSC established RP 1701a 

(Passenger Data Harmonization) as shown in the book of finally adopted 

Resolutions & RPs. The ATA Passenger Council established counterpart RP 

30.301a as shown in Section II of the ATA Minutes. 

P6.3.2 RP 1701d - Self-Service Automated Document Check 

26. The Fast Travel Working Group (FTWG) proposed changes to the guidelines 

in RP 1701d (Self Service Automated Document Check) to reflect 

improvements in the accompanying implementation guide. The PSC agreed 

to amend RP 1701d as shown in the book of finally adopted Resolutions & 

RPs. The ATA Passenger Council agreed to make counterpart changes to 

RP 30.201d as shown in Section II of the ATA Minutes. 

P6.3.3 RP 1701h - Security Checkpoint Access and Egress 

27. The Passenger Facilitation Working Group (PFWG) developed guidelines in 

cooperation with the Airports Council International (ACI) to improve the 

passenger process at security checkpoint access and exit points (egress). It 

was proposed to publish these recommendations to provide a useful 

reference for airport terminal design and management of the passenger flow 

around security checkpoints. The PSC established RP 1701h (Security 

Checkpoint Access and Egress) as shown in the book of finally adopted 

Resolutions & RPs. The ATA Passenger Council established counterpart RP 

30.301h as shown in Section II of the ATA Minutes. 

P6.3.4 RP 1701k - Self-Boarding 

28. The Fast Travel Working Group (FTWG) proposed changes to the guidelines 

in RP 1701k (Self Boarding) to reflect improvements in the accompanying 

implementation guide. The PSC agreed to amend RP 1701k as shown in the 

book of finally adopted Resolutions & RPs. The ATA Passenger Council 

agreed to make counterpart changes to RP 30.201k as shown in Section II of 

the ATA Minutes. 
6 

P6.3.5 RP 1701j Automated and Self-Service Flight Rebooking for 

Irregular Operations 

29. The Fast Travel Working Group (FTWG) developed guidelines to address 

automated and self-service rebooking facilities for irregular operations. These 

guidelines would be for airlines to use on their own self-service machines or in 

a common use environment to facilitate self-service rebooking at airports. 

The PSC established RP 1701j as shown in the book of finally adopted 

Resolutions & RPs. The ATA Passenger Council established counterpart RP 

30.301j as shown in Section II of the ATA Minutes. 

30. Mr Jerry Foran (BA) reported that the adopted text had not been reviewed by 

the entire membership of the Ticketing Committee and Reservations 

Committee. The Chairman directed that the RP should be sent to the next 

meetings of the JPTC and ResCom for their review and comment. 

ACTION: JPTC and ResCom

P6.3.6 RP 1701i - International Traveler Scheme 

31. The Passenger Facilitation Working Group (PFWG) developed guidelines to 

promote the adoption of commonalities between national registered traveler 

schemes to foster interoperability for the benefit of passengers. The PSC 

established RP 1701i (International Traveler Scheme) as shown in the book of 

finally adopted Resolutions & RPs. The ATA Passenger Council established 

counterpart RP 30.301i as shown in Section II of the ATA Minutes. 

P6.3.7 RP 1706c – Common Use Self-Service (CUSS) 

32. The Common Use Working Group (CUWG) developed changes to RP 1706c 

to amend the procedures for using credit card numbers as a form of 

identification (FOID). This action was required to comply with PCI-DSS 

requirements. The PSC agreed to amend RP 1706c as shown in the book of 

finally adopted Resolutions & RPs. Noting an abstention from Southwest, the 

ATA Passenger Council agreed to make counterpart changes to RP 30.100 

as shown in Section II of the ATA Minutes. 

P6.3.8 RP 1797 – Common Use Passenger Processing Systems (CUPPS) 

33. The Common Use Working Group (CUWG) developed changes to RP 1797 to 

amend the procedures for using credit card numbers as a form of 

identification (FOID). This action was required to comply with PCI-DSS 

requirements. The PSC agreed to amend RP 1706c as shown in the book of 

finally adopted Resolutions & RPs. Noting an abstention from Southwest, the 

ATA Passenger Council agreed to make counterpart changes to RP 30.201 

as shown in Section II of the ATA Minutes. 
7 

P6.3.9 Resolution 792 – Bar Coded Boarding Pass (BCBP) – Version 5 

34. The Passenger Experience Management Group (PEMG) and the BCBP task 

force had identified the requirement to add a new element in the 2D bar code 

to manage passenger eligibility for “Fast Track” lanes at airports, 

independently from possibly already existing criteria (e.g. class of transport, 

frequent flyer status, etc.). The PSC agreed to amend Resolution 792 as 

shown in the book of finally adopted Resolutions & RPs. The ATA Passenger 

Council agreed to make counterpart changes to Resolution 20.205 as shown 

in Section II of the ATA Minutes. 

P7 Co-ordination with the Commission of European Communities (CEC) on 

PSC Matters 

35. Conference noted this report. 

P8 Elimination of Remaining Paper Tickets – Paper Out Strategy 

36. Members were reminded of the resolution adopted by the 60th IATA AGM held 

in Singapore in 2004 that endorsed action by the IATA Board of Governors to 

establish a program of cost reduction that became known as ‘Simplifying the 

Business’ and the agreement that the ‘priority area to be addressed is a 

transition to 100% electronic ticketing, targeting the phase-out of all paper 

tickets by 31 December 2007’. 

37. However, to date, the large majority of carriers still maintain some form of 

legacy paper ticketing (in their own offices and at airports) which is still used 

for both online and interline sales. This means that many carriers are obliged 

to maintain legacy paper infrastructure for what is rapidly becoming a 

decreasing part of their business with all of the incumbent costs. Carriers 

therefore cannot fully realize the benefits that operating in a 100% paperless 

environment would bring. For example, carriers still have the costs of the 

procurement and shipment of paper tickets by secure courier, maintenance of 

printers and legacy revenue accounting processes. 

38. Accordingly the Secretary proposed that Conference establish a deadline date 

of 1 April 2014 for the abolition of all remaining paper tickets, miscellaneous 

documents, excess baggage tickets and Flight Interruption Manifests (FIMs). 

This date was chosen in recognition of the deadline of 1 January 2014 for 

BSPs to use exclusively the EMD and the deadline date of 31 March 2012 for 

interline staff travel to be 100% paperless. 

39. Whereas Conference supported the concept of a deadline date, several 

airlines voiced concern at the date itself in view of merger activity and other 

issues which would prevent them from meeting such an aggressive deadline 

date. After some debate it was agreed that 1 April 2016 would be a realistic 

target date for the entire industry. Moreover Conference endorsed a proposal 

to request that the StB Steering Group recommend the launch of a business 

case to ensure appropriate resources are available to launch a project to 

oversee the rapid expansion of paperless carriers to meet the deadline date. 

ACTION: StB Steering Group
8 

40. In addition Conference instructed the JPTC to review all ticketing Resolutions 

and RPs with a goal to sunset paper ticket standards effective 1 April 2016. 

ACTION: JPTC

P8.1 Add Paragraph 2.2.6 to Resolution 780e 

41. The JPTC proposed that Resolution 780e be updated to align its provisions 

with those of Resolution 780. The PSC agreed to amend Resolution 780e as 

shown in the book of finally adopted Resolutions & RPs. 

P9 ZED-MIBA Forum – Sunset of Paper Tickets for Interline Staff Travel 

42. Conference noted this report and disbanded the ZMF/IATA Staff Travel 

Automated Solutions (ZISTAS) Working Group. 

P10 Report – Passenger Distribution Group (PDG) 

43. Members noted the Terms of Reference of a new group called the Passenger 

Distribution Group (PDG) as shown in Attachment D. Mr Eric Leopold (IATA) 

advised that there is an emerging vision for multi-channel airline distribution 

as described in goal one of the StB Think Tank white paper as shown in 

Attachment C. 

44. He reported that the first meeting of the PDG had agreed to develop a 

direction on how to develop standards and infrastructure for a new distribution 

model. Mr Patrick Graf (LX) enquired about any plans on how standards for 

the new distribution model would be developed. Mr Leopold replied that 

consideration would be given to more agile and quicker ways of creating 

standards, perhaps in a similar fashion to OpenTravel and OpenAXIS. 

P11 Report - PCI DSS Working Group (PDWG) 

45. Conference noted this report and agreed to extend the mandate of the PDWG 

for 12 more months. Volunteers to participate in the group were identified as: 

BA, DL, LH, SK and UA. 

P12 Co-ordination with the US Department of Transportation (DoT) – 

Initiative for Self-Assessment 

46. The Secretary reminded Conference that IATA had submitted an exemption 

from “Condition #2” (Docket OST-2010-0114) in May 2010. Whereas it was 

frustrating not to have had an Order issued after 17 months of waiting, he 

advised that recent dialogue with the US DoT had resulted in a promise that 

action would likely be taken before the end of 2011. The Secretary committed 

to advising all members as soon as an Order is issued. 

ACTION: Secretary
9 

P13 US DoT – Enhancing Airline Passenger Protections Bill 

47. Conference noted this report. Mr Jim Casey (ATA) reported that some 

elements had been given a delayed implementation date of 24 January 2012 

after interventions from ATA and IATA. 

P14 Report – Involuntary Rerouting Working Group (IRWG) 

48. Conference noted this report and agreed to extend the mandate by 12 

months with terms of reference as shown in Attachment E. 

49. Mr Johan Lodewijckx (KL) said that the work to establish a new proposed 

resolution to handle schedule changes was on-going and was definitely 

needed by the industry. As a result he requested Conference to extend the 

mandate of IRWG and looked forward to the face-to-face meeting in March 

after JPTC. 

AIRPORT SERVICES 

B1 Report of the Airport Services Committee (ASC) 

50. Conference noted this report which advised that all items in the JPSC agenda 

had been endorsed by the ASC through electronic means. 

B1.1 ASC Membership 

51. A copy of the ASC membership for 2012 is shown in Attachment F. New 

nominations to fill the vacant seats should contact the ASC Secretary Mr 

Andrew Price (pricea@iata.org). 

B1.2 ASC Election of Chairman 

52. Conference noted that the chair of the ASC remained vacant. There were no 

on-site volunteers for the position. Volunteers should contact the ASC 

Secretary Mr Andrew Price (pricea@iata.org). 

B1.3 ATA Baggage Committee – Terms of Reference and Membership 

53. Conference noted the ToR and the membership. 

B2 Report of the IATA Ground Handling Council (IGHC) 

54. Conference noted the report of the IGHC. 
10 

B3 Report – Fast Travel – Passenger Experience Management Group 

(Resolution 705) 

55. Conference noted that report for Fast Travel and the PEMG had been 

addressed in agenda item P6.3. 

B4 Report of the Baggage Working Group (BWG) 

56. Conference noted the report of the BWG and agreed to extend its mandate 

by a further 12 months so that it could develop the detail for the strategy 

developed by the Baggage Steering Group (refer to agenda item B4.1). The 

PSC agreed to amend the Terms of Reference as shown in Attachment G. 

B4.1 The New Baggage Steering Group (BSG) 

57. Conference agreed that the group should be formally established for a 

period of 1 year to start with. A vote was held for the vacant positions on the 

group, with South African Airlines and Lufthansa being elected to the 

membership. A copy of the BSG Terms of Reference and 2012 membership 

is shown in Attachment H. 

B5 Report of the DCS Messages Working Group (DCSMWG) 

58. Conference agreed to extend the mandate of the DCSMWG by 12 months 

and amend their Terms of Reference as shown in Attachment I. Conference 

also agreed to establish the Multi-channel Merchandise Sales and Delivery 

Task Force (MMSDTF) with Terms of Reference as shown in Attachment J in 

order to develop standards that would support the issuance of EMDs at 

check-in at the airport following requests from certain DCS systems. 

Volunteers for this new group were noted from Amadeus, AF, AY, DL, LH, 

SITA and UA. 

B6 Standardized Special Baggage Codes 

59. The ASC had endorsed a proposal from LH regarding the addition of 

several baggage codes in RPs 1747 and 1800 to facilitate sales of ancillary 

services. However, it was reported that the Reservations Committee had 

reviewed this item and determined that current procedures exist to transmit 

this kind of information. The item failed due to lack of support. 
11 

B7/P Packaged Items (DCSMWG) 

60. This “package” contained miscellaneous items documented in B7.1/P 

through B7.9/P which had been developed by the DCSMWG and endorsed by 

the ASC with no opposition noted. The Secretary advised that items B7.5/P 

had been removed from the package by SK. The PSC agreed to all proposed 

changes in agenda items B7.1/P through B7.9/P (except B7.5/P) as shown in 

the book of finally adopted Resolutions and RPs. 

B7.1/P Add Time and Date Variation to .O/ Element 

61. The ASC noted that when ground handling an international flight into the 

USA, the handling agent must send vetting messages to the US Government 

for the passenger’s trip. If the passenger has several onward connections, it is 

difficult for a DCS to calculate the time between flights to know whether more 

than one vetting message is needed for the trip. Accordingly it was proposed 

that the .O/ element should be modified to include departure and arrival times, 

as well as an optional date change indicator on the arrival time, so that the 

DCS can correctly calculate the timeframe. The PSC agreed to amend RPs 

1707a, 1707b, 1708, 1708a, 1715 and 1719b as shown in the book of finally 

adopted Resolutions & RPs. LH advised that they could not support any 

changes to DCS messages for at least the next three years due to system 

migration planned for 2014. 

B7.2/P Editorial Issues in RP1706 – Add Baggage Information Message 

(BIM) 

62. The ASC noted that the message type BIM is missing from the list in RP 

1706. The PSC agreed to amend RP 1706 as shown in the book of finally 

adopted Resolutions & RPs. 

B7.3/P Number of Services in Remarks Elements in DCS Messages 

63. The ASC noted that certain types of PNRs with unequal services and 

names are causing many errors on the DCS side when the PNL/ADL entries 

are misleading, causing deficiencies in customer service. Accordingly, it was 

proposed to change RP 1707b to bring consistency to the format that RES 

systems use when creating PNL/ADLs for PNRs of this nature. The PSC 

agreed to amend RP 1707b as shown in the book of finally adopted 

Resolutions & RPs. 

B7.4/P Clarification of Name Fields in the SSR DOCS 

64. SITA proposed to the Reservations Committee (ResCom) that AIRIMP be 

updated to reduce the amount of mismatches regarding passenger names 

exchanged for advance passenger information (API). This would be based on 

the chevron characters (<) in the machine readable zone (MRZ) of passports. 

DCSMWG was requested to make counterpart changes regarding the 

chevron to RP 1707b. The PSC agreed to amend RP 1707b as shown in the 

book of finally adopted Resolutions & RPs. 
12 

B7.5/P Report – PCI DSS Working Group (PDWG) 

65. IATA noted that credit card schemes prohibit the use of card numbers for 

any purpose other than for payment transactions. This was confirmed by 

several airlines at ResCom who agreed to remove credit cards as a form of 

identification (FOID) in AIRIMP (refer to agenda item R3). Accordingly the 

Secretary had scanned the DCS standards and identified one example of a 

credit card being used as a FOID and proposed changes to RP 1708. 

However, there was no support for this item which was declared defeated and 

referred to the next meeting of the DCSMWG. 

B7.6/P SSR UPGR Upgrades 

66. Delta proposed to ResCom the establishment of SSR code UPGR that 

would be sent with the Cancel/Rebook message for a passenger who wanted 

to be upgraded using the frequent flyer miles of somebody else. This was in 

recognition that code FQTU can only be used if the passenger to be upgraded 

is also the frequent flyer member. ResCom agreed to establish a new SSR 

code UPGR. Accordingly, the PSC agreed to add code UPGR to the 

PNL/ADL in RP 1708 and the PSM list of codes in RP 1715 as shown in the 

book of finally adopted Resolutions & RPs. 

B7.7/P Editorials for New PSC Resolutions Manual 

67. The ASC proposed several editorial updates to RP 1707b and RP 1708a. 

These were agreed by the PSC agreed as shown in the book of finally 

adopted Resolutions & RPs. 

B7.8/P Unique Passenger Per Segment Identifier 

68. AF advised that it would be beneficial to be able to identify a passenger on 

a flight segment and to guarantee the passenger’s uniqueness. AF proposed 

to add a key element to always match the relevant passenger on a given flight 

segment through various systems (e.g. GDS, DCS and other peripheral 

systems). This new element, originated in the GDS, would be transmitted on 

PNL/ADL and on PRL, moreover it could also be used to convey this unique 

reference on other DCS messages when necessary. 

69. Accordingly the ASC proposed the establishment of a new optional .U 

element to convey a unique identifier for a passenger travelling on a flight 

segment. This element would only be used when bilaterally agreed. The PSC 

agreed to this proposal for RPs 1707b, 1708, 1719 and 1719b as shown in 

the book of finally adopted Resolutions & RPs. 

ACTION: DCSMWG
13 

B7.9/P Web Check –in Data on PNL / ADL 

70. The ASC reported that several airlines had requested that a standard 

format and content be developed for sending data to DCS for passengers who 

had checked-in in advance (such as web based check-in). It was noted that 

there are already a number of different formats being used so it would be 

ideal to agree on an industry standard. The ASC proposed to modify the .R/ 

element in the PNL/ADL to be used on a bilateral basis. The PSC agreed to 

amend RP 1708 as shown in the book of finally adopted Resolutions & RPs. 

B8/P Packaged Items (BWG) 

71. This “package” contained miscellaneous items documented in B8.1/P 

through B8.13/P which had been developed by the BWG and endorsed by the 

ASC. The Secretary advised that items B8.1/P, B8.2/P and B8.3/P were for 

information only and B8.5/P was withdrawn from the package by IATA. The 

PSC agreed to all proposed changes in agenda items B8.4/P through B8.13/P 

(except B8.5/P) as shown in the book of finally adopted Resolutions and RPs. 

The ATA Passenger Council agreed to all counterpart changes as shown in 

Section II of the ATA Minutes. 

B8.1/P Resolution 740 / RP 1740a Review 

72. The baggage working group was requested to advise whether or not a review 

of currently used baggage label stock recommendations and resolutions was 

necessary in order to align the resolutions and standards with commercially 

available products. The Baggage Working Group did not feel that this 

alignment was needed. 

B8.2/P RP 1740c Review 

73. The baggage working group was asked to advise whether this recommended 

practice should be updated or removed from the Passenger Services 

Conference Resolutions Manual as the technology has not been widely 

adopted. The group advised that as some members were using the 

technology it should remain in place. 

B8.3/P Creation of a BSM Testing Contact List 

74. One of the major challenges in baggage handling is the correct reception and 

interpretation of baggage messages. The BWG has established this list of 

people who may be contacted in order to ensure the correct handling of 

messages between airlines. Conference noted this item. For an updated copy 

of this list please contact Mr Andrew Price (pricea@iata.org). 
14 

B8.4/P Clarify and Correct Errors in RP 1745 re Batch BSM 

75. This agenda item was to correct the handling of batch BSM messages making 

the .S element mandatory for each set of .N messages. The .G element was 

also added to the table of repeatable elements. The PSC agreed to amend 

RP 1745 as shown in the book of finally adopted Resolutions & RPs. The 

ATA Passenger Council agreed to make counterpart changes to Resolution 

30.45 as shown in Section II of the ATA Minutes. 

B8.5/P Amendments to RP 1745 Section 9 Baggage Manifest Message 

(BMM) 

76. The ASC proposed to change RP 1745 to align the element usage of the 

baggage manifest message with how these elements are used in RP 1800, 

removing the .K element, (default printer) .Y element (frequent traveler) and .L 

(automatic PNR address) elements, and adding the .S (reconciliation data) 

element. The PSC agreed to amend RP 1745 as shown in the book of finally 

adopted Resolutions & RPs. The ATA Passenger Council agreed to make 

counterpart changes to Resolution 30.45 as shown in Section II of the ATA 

Minutes. 

B8.6/P Amendments to RP 1745 Section 8 Baggage Control Messages 

77. The ASC proposed to change RP 1745 to align the element usage of the 

baggage control message with how these elements are used in RP 1800 to 

add the .H and .R elements. The PSC agreed to amend RP 1745 as shown 

in the book of finally adopted Resolutions & RPs. The ATA Passenger 

Council agreed to make counterpart changes to Resolution 30.45 as shown in 

Section II of the ATA Minutes. 

B8.7/P Amendments to RP 1745 Section 7 Baggage Not Seen Message 

(BNS) 

78. This change to RP 1745 was to align the element usage of the baggage 

not sent message with how these elements are used in RP 1800, to add the 

.H and .E elements, and remove the .L, .W and .Y elements. The PSC 

agreed to amend RP 1745 as shown in the book of finally adopted 

Resolutions & RPs. The ATA Passenger Council agreed to make counterpart 

changes to Resolution 30.45 as shown in Section II of the ATA Minutes. 

B8.8/P RP1739, Attachment ‘E’ – Add RP1800 Reference to ‘Common 

Automation Methods’ 

79. The ASC proposed to change RP 1739 for consistency’s sake to include the 

following reference: Common automation methods for passenger and 

baggage security reconciliation are described in RP 1800 and RP 1745. The 

PSC agreed to amend RP 1739 as shown in the book of finally adopted 

Resolutions & RPs. The ATA Passenger Council agreed to make counterpart 

changes to Resolution 30.45 as shown in Section II of the ATA Minutes. 
15 

B8.9/P Editorial Issues in RP 1745 – BNS, .H Missing in Example 

Messages 

80. The ASC proposed to change RP 1745 to add the .H field to the example 

message, aligning the example to the text of the RP. The PSC agreed to 

amend RP 1745 as shown in the book of finally adopted Resolutions & RPs. 

The ATA Passenger Council agreed to make counterpart changes to 

Resolution 30.45 as shown in Section II of the ATA Minutes. 

B8.10/P Editorial Issues in RP 1745 – Attachment E 

81. The ASC proposed to change RP 1745 to correct the reference to a BTM 

(baggage transfer message) to the BPM (Baggage Process Message). The 

PSC agreed to amend RP 1745 as shown in the book of finally adopted 

Resolutions & RPs. The ATA Passenger Council agreed to make counterpart 

changes to Resolution 30.45 as shown in Section II of the ATA Minutes. 

B8.11/P Editorial Issues in RP 1745 – Inconsistencies in .U Example 

Message 

82. The ASC proposed to change RP 1745 to remove inconsistencies in the 

examples in section 2.3.24. The PSC agreed to amend RP 1745 as shown in 

the book of finally adopted Resolutions & RPs. The ATA Passenger Council 

agreed to make counterpart changes to Resolution 30.45 as shown in Section 

II of the ATA Minutes. 

B8.12/P Editorial Issues in RP 1745 and other – Questionable reference to 

the ‘IATA Systems and Communication Reference Manual’ 

83. The ASC proposed to change RP 1745 to remove reference to the IATA 

Systems and Communication Reference Manual. The PSC agreed to amend 

RP 1745 as shown in the book of finally adopted Resolutions & RPs. The 

ATA Passenger Council agreed to make counterpart changes to Resolution 

30.45 as shown in Section II of the ATA Minutes. 

B8.13/P Editorial Issues in RP 1740c – References 

84. The ASC proposed to change to RP 1740c to remove the phrase “pending 

approval by the PSC in 2005” as the approval was given in 2005. The PSC 

agreed to amend RP 1740c as shown in the book of finally adopted 

Resolutions & RPs. The ATA Passenger Council agreed to make counterpart 

changes to Resolution 30.49 as shown in Section II of the ATA Minutes. 
16 

B9 Second City/Airport Code in PNL 

85. Members were referred to agenda item R5 (EMD-S and SVC – Number of 

Location Codes). It was noted that ticketing resolutions provide for either one 

or two locations, whereas a teletype message sent from a third party does not 

allow for more than one location. Accordingly it is concluded that it is 

necessary to make amendments to AIRIMP section 2.10.6 and examples in 

section 3.21.2 for the SVC element transmission to allow for 2 locations, 

corresponding to EMD origin and destination codes. 

86. Regarding DCS, the difference in format would only be the addition of an 

optional second city/airport code for the PNL. Accordingly it was proposed to 

add an example in RP 1708 to show an optional second city/airport code. 

The PSC agreed to amend RP 1708 as shown in the book of finally adopted 

Resolutions & RPs. 

TICKETING 

T1 Report of Ticketing Committee – Selection of Committee Membership for 

the IATA Passenger Forms and Procedures Committee (PFPC) 

87. Conference noted the report of the Joint Passenger Ticketing Committee 

(JPTC) as presented. Chairman thanked the Committee for its work done 

throughout the year. 

88. Conference was advised that the term of office for AC, AF, NH, AA, CO, 

SA UA and VS, were expiring and that eight Ticketing Committee members 

would need to be selected. The Chairman asked if there were any other 

Members that wished to be considered. 

89. There were a total of 8 nominations for the eight vacant positions. 

Accordingly AA, AC, AF, CO, LY NH, SA, and UA were elected by 

acclamation for a three year period. A copy of the updated membership is 

shown in Attachment K. Conference noted that all places are now taken. 

90. Conference also extended the mandate of the EMDWG and IRWG for a 

further 12 months. 

T2/P Ticketing “Package” 

91. This “package” contained miscellaneous items documented in T2.1/P 

through T2.35/P which had been approved at JPTC with no opposition noted. 

Agenda items T2.28/P, T2.32/P and T2.35/P were withdrawn from the 

package for further consideration. 

92. The PSC unanimously adopted agenda items T2.1/P through T2.34/P 

(except for T2.28/P, T2.32/P) as shown in the book of finally adopted 

Resolutions & RPs as detailed below. 
17 

93. Noting that T2.32/P and T2.34/P were for IATA action only, the ATA 

Passenger Council unanimously agreed to counterpart changes in items 

T2.1/P through T2.33/P (except for T2.28/P) as shown in Section II of the ATA 

Minutes. 

T2.1/P Remove the Condition on ET Coupon before Requesting Control 

of EMD-A Coupon 

94. The Ticketing Committee (JPTC) proposed to remove the condition that a 

carrier must have control of the electronic ticket flight coupon before 

requesting control of the associated EMD. The PSC agreed to amend 

Resolution 725f as shown in the book of finally adopted Resolutions & RPs. 

The ATA Passenger Council agreed to make counterpart changes to 

Resolution 20.63 as shown in Section II of the ATA Minutes. 

T2.2/P Disassociate when Carrier Not Part of the Itinerary Obtains 

Control of ETKT or EMD Coupon 

95. The Ticketing Committee (JPTC) proposed to amend Resolutions 722f and 

725f requiring the Validating Carrier of the ET to disassociate an EMD-A 

coupon(s) when control of the associated ET coupon(s) is passed to a carrier 

not part of the itinerary. The PSC agreed to amend Resolutions 722f and 725f 

as shown in the book of finally adopted Resolutions & RPs. The ATA 

Passenger Council agreed to make counterpart changes to Resolution 20.60 

and 20.63 as shown in Section II of the ATA Minutes. 

T2.3/P Amendment to Definition of Coupon Status Indicator ‘C’ 

(Checked-In) 

96. The Ticketing Committee (JPTC) proposed to align the definitions in all of 

the electronic ticket and EMD resolutions for the Coupon Status Indicator ‘C’. 

The PSC agreed to amend Resolutions 722f, 722g, 722h, 725f, 725g and 

725h as shown in the book of finally adopted Resolutions & RPs. The ATA 

Passenger Council agreed to make counterpart changes to Resolutions 

20.60, 20.61, 20.62, 20.63, 20.64 and 20.66 as shown in Section II of the ATA 

Minutes. 

T2.4/P Disassociation Upon COS to ‘E’, ‘P’, ‘R’, ‘X’ 

97. The Ticketing Committee (JPTC) proposed to amend Resolution 722f to 

indicate which carrier should disassociate the EMD-A coupon(s) when setting 

final status to ‘E’, ‘P’, ‘R’ or ‘X’ on the associated ET coupon(s) The PSC 

agreed to amend Resolution 722f as shown in the book of finally adopted 

Resolutions & RPs. The ATA Passenger Council agreed to make counterpart 

changes to Resolution 20.60 as shown in Section II of the ATA Minutes. 
18 

T2.5/P Remove Mandate to Request EMD Control 

98. The Ticketing Committee (JPTC) proposed to amend Resolution 722f to 

remove the requirement to request control of the EMD-A coupon(s) on receipt 

of the System Update request for association. The PSC agreed to amend 

Resolution 722f as shown in the book of finally adopted Resolutions & RPs. 

The ATA Passenger Council agreed to make counterpart changes to 

Resolution 20.60 as shown in Section II of the ATA Minutes. 

T2.6/P Revise EMD Definitions in RP 1790 and ATA 10.90 

99. The Ticketing Committee (JPTC) proposed to align the definitions in 

Recommend Practice 1790 with those in the EMD Resolutions. The PSC 

agreed to amend Recommended Practice 1790 as shown in the book of 

finally adopted Resolutions & RPs. The ATA Passenger Council agreed to 

make counterpart changes to Recommend Practice 10.90 as shown in 

Section II of the ATA Minutes. 

T2.7/P Revise ‘Consumed At Issuance’ Glossary Definition 

100. According to the decisions of the June 2011 Ticketing Committee this 

proposal was entirely replaced with agenda items T2.21/P and T2.22/P. 

T2.8/P Clarify Definition of System Update Message 

101. The Ticketing Committee (JPTC) proposed to clarify that the System 

Update message applied at coupon level. The PSC agreed to amend 

Resolutions 722f, 722h, 725f and 725h as shown in the book of finally 

adopted Resolutions & RPs. The ATA Passenger Council agreed to make 

counterpart changes to Resolutions 20.60, 20.62, 20.63 and 20.66 as shown 

in Section II of the ATA Minutes. 

T2.9/P Add ‘In Connection With Qualifier’ to ET Neutral Display Response 

102. The Ticketing Committee (JPTC) proposed to add the ‘In Connection 

With Qualifier’ in the display response and correct the number of characters 

for the ‘In Connection with Document Number’ to 14.The PSC agreed to 

amend Resolutions 722g and 725g as shown in the book of finally adopted 

Resolutions & RPs. The ATA Passenger Council agreed to make counterpart 

changes to Resolutions 20.61 and 20.64 as shown in Section II of the ATA 

Minutes. 
19 

T2.10/P Revise Ambiguous EMD Definitions 

103. The Ticketing Committee (JPTC) proposed to synchronize the EMD 

definitions in all of the ET and EMD Resolutions. The PSC agreed to amend 

Resolutions 722f, 722g, 722h, 725f, 725g and 725h as shown in the book of 

finally adopted Resolutions & RPs. The ATA Passenger Council agreed to 

make counterpart changes to Resolutions 20.60, 20.61, 20.62, 20.63, 20.64 

and 20.66 as shown in Section II of the ATA Minutes. 

T2.11/P Remove Mandate for Disassociation Prior to Coupon Status 

Update 

104. The Ticketing Committee (JPTC) proposed to remove the timing to 

disassociate an EMD-A coupon(s) when setting it to a final status of ‘E’, ‘R’, 

‘V’ or ‘Z’. The PSC agreed to amend Resolution 725f as shown in the book of 

finally adopted Resolutions & RPs. The ATA Passenger Council agreed to 

make counterpart changes to Resolution 20.63 as shown in Section II of the 

ATA Minutes. 

T2.12/P Removal of XT from fare Calculation 

105. The Ticketing Committee (JPTC) proposed to clarify that the code ‘XT’ 

cannot be used in the fare calculation of an ET. The PSC agreed to amend 

Resolutions 720a, 722, 722f and 722g as shown in the book of finally adopted 

Resolutions & RPs. The ATA Passenger Council agreed to make counterpart 

changes to Resolutions 110.15, 20.10, 20.60 and 20.61 as shown in Section II 

of the ATA Minutes. 

T2.13/P Revise Coupon Notification Coupon Status Indicator 

106. The Ticketing Committee (JPTC) proposed to make complete the 

definition of Coupon Status ‘N’ by adding coupon status indicators ‘G’ and ‘Z’. 

The PSC agreed to amend Resolutions 722f and 722h as shown in the book 

of finally adopted Resolutions & RPs. The ATA Passenger Council agreed to 

make counterpart changes to Resolutions 20.60 and 20.62 as shown in 

Section II of the ATA Minutes. 

T2.14/P Amendment to System Update 

107. The Ticketing Committee (JPTC) proposed to align the text in 

Resolution 722f for ‘System Update’ to the text in Resolution 725f. The PSC 

agreed to amend Resolution 722f as shown in the book of finally adopted 

Resolutions & RPs. The ATA Passenger Council agreed to make counterpart 

changes to Resolution 20.60 as shown in Section II of the ATA Minutes. 
20 

T2.15/P Amendment to Change of Status 

108. . The Ticketing Committee (JPTC) proposed to clarify when the 

Change of Status should be synchronized for the ET and EMD-A. The PSC 

agreed to amend Resolution 722f as shown in the book of finally adopted 

Resolutions & RPs. The ATA Passenger Council agreed to make counterpart 

changes to Resolution 20.60 as shown in Section II of the ATA Minutes. 

T2.16/P Unsolicited Airport Control to Marketing Carrier with Flown 

Information 

109. The Ticketing Committee (JPTC) proposed to add a process for the 

Operating Carrier to send an Unsolicited Airport Control message to the 

Marketing Carrier when the Marketing Carriers is not the Billing Carrier. The 

PSC agreed to amend Resolution 722f as shown in the book of finally 

adopted Resolutions & RPs. The ATA Passenger Council agreed to make 

counterpart changes to Resolution 20.60 as shown in Section II of the ATA 

Minutes. 

T2.17/P Remove RFISC from EMD Refund Cancel response Message 

110. The Ticketing Committee (JPTC) proposed to remove the RFISC from 

the Refund Cancel response message. The PSC agreed to amend Resolution 

725g as shown in the book of finally adopted Resolutions & RPs. The ATA 

Passenger Council agreed to make counterpart changes to Resolution 20.64 

as shown in Section II of the ATA Minutes. 

T2.18/P EMD Special Characters used in Reason for Issuance Sub-Code 

Description 

111. The Ticketing Committee (JPTC) proposed to prevent the use of 

special characters in the Reason for Issuance Sub-Code Description of the 

EMD. The PSC agreed to amend Resolution 722f as shown in the book of 

finally adopted Resolutions & RPs. The ATA Passenger Council agreed to 

make counterpart changes to Resolution 20.60 as shown in Section II of the 

ATA Minutes. 

T2.19/P EMD Mutual Exclusivity of Coupon Value and Fare Calculation 

112. The Ticketing Committee (JPTC) proposed to clarify that Coupon Value 

and Fare Calculation were mutually exclusive at the document level. The PSC 

agreed to amend Resolution 722f as shown in the book of finally adopted 

Resolutions & RPs. The ATA Passenger Council agreed to make counterpart 

changes to Resolution 20.60 as shown in Section II of the ATA Minutes. 
21 

T2.20/P EMD Product Characteristics 

113. The Ticketing Committee (JPTC) proposed to introduce new data 

elements that would capture product characteristics. The PSC agreed to 

amend Resolutions 722f, 725f and 725h as shown in the book of finally 

adopted Resolutions & RPs. The ATA Passenger Council agreed to make 

counterpart changes to Resolutions 20.60, 20.63 and 20.66 as shown in 

Section II of the ATA Minutes. 

T2.21/P EMD Update Glossary Definition of Consumed at Issuance 

Indicator 

114. The Ticketing Committee (JPTC) proposed to update the glossary 

definition for the ‘Consumed at Issuance Indicator’. The PSC agreed to 

amend Resolution 722f as shown in the book of finally adopted Resolutions & 

RPs. The ATA Passenger Council agreed to make counterpart changes to 

Resolution 20.60 as shown in Section II of the ATA Minutes. 

T2.22/P EMD Consumed at Issuance Indicator Glossary Definition 

115. The Ticketing Committee (JPTC) proposed to further update the 

glossary definition for the ‘Consumed at Issuance Indicator’ making it 

applicable to Resolution 725g/ATA 20.63 only. The PSC agreed to amend 

Resolution 722f as shown in the book of finally adopted Resolutions & RPs. 

The ATA Passenger Council agreed to make counterpart changes to 

Resolution 20.60 as shown in Section II of the ATA Minutes. 

T2.23/P Addition of Attribute Group and Attribute Sub-Group 

116. The Ticketing Committee (JPTC) proposed add additional data 

elements available from the Optional Services pricing record. The PSC 

agreed to amend Resolutions 722f, 725f, 725g and 725h as shown in the 

book of finally adopted Resolutions & RPs. The ATA Passenger Council 

agreed to make counterpart changes to Resolutions 20.60, 20.63, 20.64 and 

20.66 as shown in Section II of the ATA Minutes. 

T2.24/P Inconsistency in EMD Coupon Status Definitions 

117. The Ticketing Committee (JPTC) proposed to align the Coupon Status 

definitions across the EMD resolutions. The PSC agreed to amend 

Resolutions 725f, 725g and 725h as shown in the book of finally adopted 

Resolutions & RPs. The ATA Passenger Council agreed to make counterpart 

changes to Resolutions 20.63, 20.64 and 20.66 as shown in Section II of the 

ATA Minutes. 
22 

T2.25/P Unsolicited Billing Message 

118. The Ticketing Committee (JPTC) proposed to amend the Unsolicited 

Airport Control message to send billing information to the Marketing Carrier in 

a block space code-share scenario. The PSC agreed to amend Resolution 

725f as shown in the book of finally adopted Resolutions & RPs. The ATA 

Passenger Council agreed to make counterpart changes to Resolution 20.63, 

as shown in Section II of the ATA Minutes. 

T2.26/P EMD Create Dependency Between RFIC and RFISC 

119. The Ticketing Committee (JPTC) proposed to group certain RFISCs to 

a specific RFIC. The PSC agreed to amend Resolution 722f as shown in the 

book of finally adopted Resolutions & RPs. The ATA Passenger Council 

agreed to make counterpart changes to Resolution 20.60 as shown in Section 

II of the ATA Minutes. 

T2.27/P Definition of Total Ticket Document Amount 

120. The Ticketing Committee (JPTC) proposed to align the definitions of data 

elements related to the Total Ticket Document Amount. The PSC agreed to 

amend Resolution 722f as shown in the book of finally adopted Resolutions & 

RPs. The ATA Passenger Council agreed to make counterpart changes to 

Resolution 20.60 as shown in Section II of the ATA Minutes. 

T2.28/P Add ABR MSC Information to the ET Record 

121. This item was removed from the package of items referenced in 

agenda item T2/P. The Ticketing Committee (JPTC) proposed to introduce 

new data elements to the ET to be able to identify the carrier whose baggage 

rules have been applied in an itinerary. This would facilitate the interpretation 

of IATA Tariff Composite Resolution 302 which defines a hierarchy as to 

whose baggage rules will apply. 

122. A Member felt there remained too many regulatory issues that were 

unresolved that needed clarification particularly with the U.S. DoT. As a result, 

this Member felt that information would not be accurate and thereby increase 

the possibility of liability where incorrect baggage information was placed on 

the ET receipt. 

123. Following a deferred vote, with 1 Member remaining in opposition this 

item was declared defeated by the IATA PSC. However since voting rules for 

the ATA are different, this same proposal was agreed by the ATA Passenger 

Council to make changes to ATA Resolutions 110.15, 20.10, 20.12, 20.13, 

20.51, 20.52 and 20.60 as shown in Section II of the ATA Minutes. This item 

was subsequently referred back to the JPTC for review since now IATA and 

ATA resolutions would reflect different requirements. 

ACTION: JPTC
23 

T2.29/P Resolution Editorials 

124. The Ticketing Committee (JPTC) proposed a number of editorial 

amendments to Resolutions 722f and 725g. The PSC agreed to amend 

Resolutions 722f and 725g as shown in the book of finally adopted 

Resolutions & RPs. The ATA Passenger Council agreed to make counterpart 

changes to Resolution 20.60 and 20.64 as shown in Section II of the ATA 

Minutes. 

T2.30/P Current Surcharge Ticketing – RAWG Requests 

125. The Ticketing Committee (JPTC) proposed to include verbiage to cover 

new additional surcharge scenarios. The PSC agreed to amend Resolution 

722 as shown in the book of finally adopted Resolutions & RPs. The ATA 

Passenger Council agreed to make counterpart changes to Resolution 20.10 

as shown in Section II of the ATA Minutes. 

T2.31/P Current Surcharge Ticketing – Clean-Up 

126. The Ticketing Committee (JPTC) proposed to amend verbiage to cover 

additional surcharge scenarios not currently part of the existing resolutions. 

The PSC agreed to amend Resolution 722 as shown in the book of finally 

adopted Resolutions & RPs. The ATA Passenger Council agreed to make 

counterpart changes to Resolution 20.10 as shown in Section II of the ATA 

Minutes. 

T2.32/P Expiry of Neutral Paper Documents 

127. This item was removed from the package of items referenced under T2/P. 

The Ticketing Committee (JPTC) proposed to add a sunset date into 

Resolutions 725d and 725e which currently are used as a standard to support 

the issuance of the vMCO and vMPD in IATA BSPs, reflecting the IATA Board 

target for the wide introduction of the EMD in BSPs with all BSPs being 100% 

EMD no later than 31 December 2013. 

128. A Member felt that, whilst they were not against the concept in principle, 

they had a concern that not all GDSs would be fully ready in all BSPs to 

support this deadline. UA abstained by name and following a deferred vote, 

JL abstained on the condition that IATA consults with all members in 2012 to 

review EMD penetration and assess options for case-by-case workaround 

solutions for those airlines who are unable to meet the deadline of 31 

December 2013. The PSC agreed to amend Resolutions 725d and 725e as 

shown in the book of finally adopted Resolutions & RPs. 

ACTION: IATA
24 

T2.33/P Delete Reference to Sundry Charges 

129. The Ticketing Committee (JPTC) proposed to remove references to 

Sundry Charges in Recommended Practice 1790. The PSC agreed to amend 

Recommend Practice 1790 as shown in the book of finally adopted 

Resolutions & RPs. The ATA Passenger Council agreed to make counterpart 

changes to Resolution 10.90 as shown in Section II of the ATA Minutes. 

T2.34/P Single Source RBD Service 

130. The Ticketing Committee (JPTC) proposed to amend Recommended 

Practice 1728 to make it clear that ATPCO is the only source of RBD data. 

The PSC agreed to amend Recommended Practice 1728 as shown in the 

book of finally adopted Resolutions & RPs. 

T2.35/P Industry Implementation Strategy for Alphanumeric TFC Coding 

131. This item was removed from the package of items referenced under 

agenda item T2/P. The Ticketing Committee (JPTC) proposed to amend 

Resolution 728 to set a deadline by which all systems should be ready to 

accept alphanumeric coding of taxes, fees and charges. 

132. The original proposal was submitted with a deadline of 31 December 

2012. However IATA noted that, since the JPTC had met, there had been a 

substantial increase in the number of code allocations and, as such, it would 

be better to ensure that systems were ready no later than 30 June 2012. The 

PSC agreed to amend Resolution 728 as shown in the book of finally adopted 

Resolutions & RPs. The ATA Passenger Council agreed to make counterpart 

changes to Resolution 110.15 as shown in Section II of the ATA Minutes. 

T3 Credit Card as FOID and PCI DSS Compliancy 

133. The Ticketing Committee (JPTC) proposed to remove the option to use 

a credit card number as FOID as it was understood that this violates operating 

regulations of the card schemes. A Member advised that using the credit card 

was inherent in their ET process and could not support the entire removal of 

this provision from the resolution. It was clarified that, as long as the full card 

number was not transmitted, then this met the requirements of the PCI DSS 

rules. With three Members in opposition and 3 abstaining this item was 

declared defeated by the PSC Chairperson. There was no motion to vote by 

ATA carriers and this item was referred back to the JPTC. 

ACTION: JPTC
25 

T4 Fee Calculation on EMD 

134. The Ticketing Committee (JPTC) proposed to formalize the standard 

format for entering a fee calculation on an EMD. The PSC agreed to amend 

Resolutions 725a and 725b as shown in the book of finally adopted 

Resolutions & RPs. The ATA Passenger Council agreed to make counterpart 

changes to Resolution 110.25 as shown in Section II of the ATA Minutes. 

T5 Update to Resolution 728 

135. The Ticketing Committee (JPTC) proposed to remove the credit card 

product codes of all cards other than international or national brands 

acceptable in the BSP and remove the BIN numbers. The PSC agreed to 

amend Resolution 728 as shown in the book of finally adopted Resolutions & 

RPs. The ATA Passenger Council agreed to make counterpart changes to 

Resolution 110.16 as shown in Section II of the ATA Minutes. 

T6 Current Surcharge Ticketing – Reductions 

136. The Ticketing Committee (JPTC) proposed a new way of showing 

negative surcharges. Even though the current method of showing ‘LESS’ was 

not providing as much information as was available in pricing, a Member felt 

that, given the number of times this would occur, it was not worth making 

expensive changes to revenue accounting and prorate systems. With one 

Member in opposition this item was declared defeated by the IATA PSC 

Chairperson. There was no motion by ATA carriers and this item was sent 

back to JPTC for further evaluation. 

ACTION: JPTC

T7 Deletion of Carrier Fee Type OA 

137. The Ticketing Committee (JPTC) proposed to remove the Carrier Fee 

Type OA as it was suggested that it was not supported in the ATPCO optional 

services filing solution and no carrier had requested it to be implemented. A 

Member clarified that in fact they had requested for the automation of OA fees 

by ATPCO and therefore could not support the removal from the Resolution. 

With two Members in opposition this item was declared defeated by the IATA 

PSC Chairperson. There was no motion by ATA carriers. 

T8 Corrections to Matrices for Carrier Fees 

138. IATA management proposed to correct a number of omissions and 

typographical errors in the Carrier Fee data elements and matrices. The PSC 

agreed to amend Resolutions 722f, 722g, 722h, 725f, 725g and 725h as 

shown in the book of finally adopted Resolutions & RPs. The ATA Passenger 

Council agreed to make counterpart changes to Resolutions 20.60, 20.61, 

20.62, 20.63, 20.64 and 20.66 as shown in Section II of the ATA Minutes. 
26 

T9 Removal of Tax Reporting Form From Resolution 728 

139. IATA TTBS management proposed to remove the tax, fee, charge 

reporting from Resolution 728 as it no longer meets the requirements for 

reporting new TFC requests and changes to existing TFCs. The PSC agreed 

to amend Resolution 728 as shown in the book of finally adopted Resolutions 

& RPs. The ATA Passenger Council agreed to make counterpart changes to 

Resolution 110.16 as shown in Section II of the ATA Minutes. 

T10 Reporting of Taxes at Coupon Level 

140. The Coupon Tax Task Force (CCTF) on behalf of BDISG submitted an 

agenda item to the JPTC in June 2011 to request new data elements to 

support revenue accounting to identify taxes, fees and charges at the ticket 

coupon level. However it was not addressed by the JPTC since no firm 

proposal was submitted. It had been suggested by a Member that industry 

could not wait another year to have these data elements in place as TFCs 

were getting ever more complex. Accordingly this item was submitted direct to 

conference to agree to add a number of new data elements to the data 

elements glossary and related matrices in order to add further clarity to the 

reporting of taxes, fees and charges at the ticket coupon level. 

141. A Member felt that this issue was complex and the implications for 

such changes had not been fully thought through. As a result, this Member felt 

that this issue should have been reviewed first by the JPTC. After a deferred 

vote and with three abstentions the PSC agreed to amend Resolutions 722f, 

722g 722h, 725f, 725g and 725h as shown in the book of finally adopted 

Resolutions & RPs. The ATA Passenger Council, however with one 

opposing, three abstentions and two Members in agreement did not agree to 

make counterpart changes to Resolutions 20.60, 20.61, 20.62, 20.63, 20.64 

and 20.66. It was requested that this item be referred back to the JPTC for 

review and possible enhancements. 

ACTION: JPTC

T11 “Consumed at Issuance” Indicator 

142. Discussion at the JPTC and EMD Task Force revealed a concern that 

there is no automated mechanism for a GDS to send the ‘Consumed at 

Issuance Indicator’ for an EMD-S. Further discussion revealed that the only 

logical conclusion was that it would have to be the I.T. hosted solution 

provider that would be the only one able to set this indicator upon instruction 

from the Validating Carrier it hosts. As this was an important issue for EMD 

implementation, IATA Management was asked to prepare an agenda item 

directly to conference removing the data element from the issuance request 

message. This would make it clear that a GDS, when sending an issuance 

request message to the validating carrier, will not be required to send the 

indicator. 
27 

143. A Member felt it was premature to remove the indicator from the 

messaging matrices since it was not known how this indicator might be used 

in the future. Moreover that this issue should have nonetheless have had the 

opportunity to be reviewed by the JPTC. Following a deferred vote and, with 

one abstention, the PSC agreed to amend Resolutions 722f and 725g as 

shown in the book of finally adopted Resolutions & RPs. The ATA Passenger 

Council agreed to make counterpart changes to Resolutions 20.61 and 20.63 

as shown in Section II of the ATA Minutes. 

RESERVATIONS 

R1 Report - ATA/IATA Reservations Committee (ResCom) 

144. Conference noted this report. BA, EK, EY, IB, MS, SA and US were 

appointed to the IATA Reservations Committee as shown in Attachment AA. 

R2 Report - Reservations Working Group (RESWG) 

145. Conference noted this report and endorsed the work plan as shown in 

Attachment BB. Conference agreed to extend the mandate of RESWG for a 

further 12 months. 

R3 Remove Credit Cards as Form of Identification (FOID) 

146. ResCom proposed amendments to AIRIMP to delete examples of 

using a credit card as a form of identification (FOID) in order to comply with 

PCI-DSS standards. Ms Michelle Bryant (LH) advised that her airline would 

require a delayed effective date due to automated systems issues. However, 

Ms Elaine Rusen (SK) advised that her airline continued to require payment 

cards as FOID and therefore she could not accept the proposal as written. 

Noting opposition from SK and abstentions from KL, MS and UA, this item 

was declared defeated and sent back to the Reservations Committee 

(ResCom) for further study. 

ACTION: ResCom

R4 SSR Matrix 

147. Rescom proposed that the SSR matrix in AIRIMP be clarified to more 

clearly identify exceptions for processing, and additionally proposed a new 

section to explain exceptional processing of SSRs. Conference agreed to 

amend AIRIMP as shown in Attachment CC. The ATA Passenger Council 

agreed to counterpart changes in SIPP also as shown in Attachment CC. 
28 

R5 EMD-S and SVC – Number of Location Codes 

148. The EMD Task Force (EMDTF) proposed amending AIRIMP for the 

SVC element transmission to allow for two locations, corresponding to EMD 

origin and destination codes. Conference agreed to amend AIRIMP as shown 

in Attachment DD. The ATA Passenger Council agreed to counterpart 

changes in SIPP also as shown in Attachment DD.

R6/P Reservations “Package” 

149. This “package” contained miscellaneous items documented in R6.1/P 

through R6.20/P which had been approved at ResCom with no opposition 

noted. Conference unanimously adopted changes to AIRIMP in agenda items 

R6.1/P through R6.20/P as shown in Attachments EE through XX. The ATA 

Passenger Council unanimously agreed to counterpart changes to SIPP in 

agenda items R6.1/P through R6.20/P also as shown in Attachments EE 

through XX. 

R6.1/P Allow HS to be Sent Without a Previously Received KD 

150. ResCom proposed to amend AIRIMP to allow sending an SSR ASVC 

with an HS action code without a previously received ASVC KD. Conference 

agreed to amend AIRIMP as shown in Attachment EE. The ATA Passenger 

Council agreed to counterpart changes in SIPP also as shown in Attachment 

EE. 

R6.2/P New SSR PCTC Example 

151. ResCom proposed to update AIRIMP with an example in which an 

airline has elected to collect, in the PNR, passenger contact information as 

required by a legislative mandate such as the EC Regulation on “Investigation 

and Prevention of Accidents and Incidents in Civil Aviation”. Conference 

agreed to amend AIRIMP as shown in Attachment FF. The ATA Passenger 

Council agreed to counterpart changes in SIPP also as shown in Attachment 

FF. 

R6.3/P Advanced Passenger Information (API) Codes 

152. ResCom proposed to amend AIRIMP to clarify procedures for the use 

of SSR DOCO codes. Conference agreed to amend AIRIMP as shown in 

Attachment GG. The ATA Passenger Council agreed to counterpart 

changes in SIPP also as shown in Attachment GG. 
29 

R6.4/P Advice of Electronic Ticket Number for Passive Segments Where 

a Passive Segment Notification Agreement Exists 

153. ResCom proposed to amend AIRIMP to clarify procedures when a 

passive segment notification agreement exists by adding SSR RLOC to the 

example. Conference agreed to amend AIRIMP as shown in Attachment 

HH. The ATA Passenger Council agreed to counterpart changes in SIPP also 

as shown in Attachment HH. 

R6.5/P Service PNR Message 

154. ResCom proposed to amend AIRIMP to clarify the sequence of record 

locators in AIRIMP. Conference agreed to amend AIRIMP as shown in 

Attachment II. The ATA Passenger Council agreed to counterpart changes 

in SIPP also as shown in Attachment II. 

R6.6/P SSR UPGR Upgrades 

155. ResCom proposed to amend AIRIMP to add a new SSR code UPGR 

that would be sent with the Cancel/Rebook message for a passenger who 

wanted to be upgraded using the frequent flyer miles of somebody else or for 

any upgrade based on partner agreement. Conference agreed to amend 

AIRIMP as shown in Attachment JJ. The ATA Passenger Council agreed to 

counterpart changes in SIPP also as shown in Attachment JJ.

R6.7/P Visa Place of Issuance in SSR DOCO 

156. ResCom proposed to update AIRIMP to clarify examples regarding the 

place of issue of the visa. Conference agreed to amend AIRIMP as shown in 

Attachment KK. The ATA Passenger Council agreed to counterpart changes 

in SIPP also as shown in Attachment KK. 

R6.8/P Add Military ID (M) to List of Travel Documents for SSR DOCS in 

AIRIMP 

157. ResCom proposed to amend AIRIMP to show a separate code to 

distinguish military identification (ID) in view that such code is already being 

used by several governments. Conference agreed to amend AIRIMP as 

shown in Attachment LL. The ATA Passenger Council agreed to counterpart 

changes in SIPP also as shown in Attachment LL. 

R6.9/P Establish Procedures for Accurate Completion of SSR DOCS 

158. ResCom proposed to add a new section for AIRIMP regarding 

“irregular names”. Conference agreed to amend AIRIMP as shown in 

Attachment MM. The ATA Passenger Council agreed to counterpart 

changes in SIPP also as shown in Attachment MM. 
30 

R6.10/P Clarification of Name Fields in the SSR DOCS 

159. ResCom proposed to update AIRIMP to reduce the amount of 

mismatches regarding passenger names exchanged for advance passenger 

information (API). Conference agreed to amend AIRIMP as shown in 

Attachment MM. The ATA Passenger Council agreed to counterpart 

changes in SIPP also as shown in Attachment MM. 

R6.11/P SSR DOCx for Passive Segments 

160. ResCom proposed to amend AIRIMP to allow the transmission of SSR 

DOCx element in a Passive Segment Notification messages. Conference 

agreed to amend AIRIMP as shown in Attachment OO. The ATA Passenger 

Council agreed to counterpart changes in SIPP also as shown in Attachment 

OO. 

R6.12/P Infant without a Seat and EMD Issuance 

161. ResCom proposed to amend AIRIMP to clarify procedures when an 

infant without a seat is issued an EMD. The change would cater for instances 

when the name on the EMD and the associated ET may not be the actual 

user of the service. Conference agreed to amend AIRIMP as shown in 

Attachment PP. The ATA Passenger Council agreed to counterpart changes 

in SIPP also as shown in Attachment PP. 

R6.13/P Update Paragraph References in AIRIMP 

162. ResCom proposed some editorial amendments to AIRIMP. 

Conference agreed to amend AIRIMP as shown in Attachment QQ. The 

ATA Passenger Council agreed to counterpart changes in SIPP also as 

shown in Attachment QQ. 

R6.14/P Editorial Repairs to AIRIMP 

163. ResCom proposed to amend AIRIMP in order that the field in SSR 

construction rules for the “number in party” should be changed to “number of 

services”, as was adopted for the SSR ASVC. Conference agreed to amend 

AIRIMP as shown in Attachment RR. The ATA Passenger Council agreed to 

counterpart changes in SIPP also as shown in Attachment RR. 

R6.15/P Multiple Services for One Passenger in AIRIMP 

164. ResCom proposed to amend AIRIMP to align the verbiage used to 

describe “Unequal number of names/services” to use the term ‘number of 

services’. Conference agreed to amend AIRIMP as shown in Attachment 

SS. The ATA Passenger Council agreed to counterpart changes in SIPP also 

as shown in Attachment SS. 
31 

R6.16/P Bilateral SSRs 

165. ResCom proposed to add a new paragraph in AIRIMP to define the 

difference between a bilateral SSR and a non-bilateral SSR. Conference 

agreed to amend AIRIMP as shown in Attachment TT. The ATA Passenger 

Council agreed to counterpart changes in SIPP also as shown in Attachment 

TT. 

R6.17/P Seat Characteristics in Replies 

166. ResCom proposed to amend AIRIMP to allow systems to exchange 

seat location codes in reply messages when bilaterally agreed. Conference 

agreed to amend AIRIMP as shown in Attachment UU. The ATA Passenger 

Council agreed to counterpart changes in SIPP also as shown in Attachment 

UU. 

R6.18/P Additional Services 

167. ResCom proposed to amend AIRIMP to add examples describing 

when the seat has been confirmed through an interactive conversation. 

Conference agreed to amend AIRIMP as shown in Attachment VV. The ATA 

Passenger Council agreed to counterpart changes in SIPP also as shown in 

Attachment VV. 

R6.19/P Unsolicited Reply Messages 

168. ResCom proposed to add a new paragraph in AIRIMP to describe an 

Unsolicited Reply message. It was noted this will resolve many issues some 

are having with SSR DOCS. Conference agreed to amend AIRIMP as shown 

in Attachment WW. The ATA Passenger Council agreed to counterpart 

changes in SIPP also as shown in Attachment WW. 

R6.20/P Correct SSR DOCS Examples 

169. ResCom proposed to amend AIRIMP to make the SSR DOCS 

examples more accurate in accordance with government regulations. It was 

clarified these amendments do not require programming changes. 

Conference agreed to amend AIRIMP as shown in Attachment XX. The ATA 

Passenger Council agreed to counterpart changes in SIPP also as shown in 

Attachment XX. 
32 

MISCELLANEOUS 

M1 Report - PSC Steering Group (PSCSG) 

170. Conference noted this report. The position for TC3 was filled by All 

Nippon (NH). The Secretary noted that the position to represent TC1 remains 

vacant. An updated governance chart showing industry standards setting 

groups that report to the PSC is shown in Attachment L.

171. Updated area charts showing which groups (“areas of involvement”) 

are open to Strategic Partners are available from: 

http://www.iata.org/membership/sp/areas/Pages/index.aspx

(Refer to “Passenger Standards”, “Passenger Experience”, “Passenger Facilitation”, 

“Baggage Services”, “Common Use”, “EMD/e-services” and “Travel Partners”).

M2 Report - PADIS Board (PADIS) 

172. Conference noted this report and agreed to establish the Expert 

Advisory Task Force (EATF) with terms of Reference as shown in 

Attachment M. 

M2.1 PNRGOV Working Group 

173. Conference noted this report. 

M3 Report - Cargo Services Conference (CSC) 

174. Conference noted this report. 

M4 Report – Scheduling Services 

175. Conference noted this report. 

M4.1 Report - Schedules Information Standards Committee (SISC) 

176. Conference noted this report and agreed to disband the SSIM 

Appendix A/D/F/I Task Force (ADFITF) with consequential changes to the 

Terms of Reference for SISC as shown in Attachment N. 

M5 Report – Fraud Prevention Working Group (FPWG) 

177. Conference noted this report and an onsite document providing a 

summary of a conference call from September 2011 with members of the 

FPWG as shown in Attachment O. 
33 

M5.1 Circulation of Fraudulent Emails under IATA’s Name 

178. The Secretary reported that fraudsters had made attempts to collect 

money from users of IATA products and services. Accordingly all members 

were requested to take note of information and guidelines as shown in 

Attachment N. 

M6 Report – BSP Data Interchange Standards Group (BDISG) 

179. Conference noted this report. 

M7 Report – Strategic Partnerships 

180. Conference noted this report. 

M8 Report - Agency Solutions Technical Working Group (ASTWG) 

181. Mr Tim Powell (Sabre) advised that his company believed that this 

group provided a good forum for GDSs to address technical issues with 

airlines and their agents. Conference noted the report and extended its 

mandate by a further 12 months. 

M9 Rescinding AIRDES (RP 1737) and Reconfirmation Procedures (RP 1762) 

182. The Secretary proposed to rescind RP 1737 (AIRDES) because this 

system no longer exists. He also proposed to rescind RP 1762 

(Reconfirmation Procedures) because he believed that industry procedures 

were no longer required. 

183. The PSC agreed to rescind RP 1737 as shown in the book of finally 

adopted Resolutions & RPs. However, members had not had sufficient time 

to study the effects of rescinding RP 1762 and so requested the ResCom to 

investigate this issue and report back to the next Conference. 

ACTION: ResCom

Close of Meeting 

184. The Chairman recognized that Mr Stephan Corking (Amadeus) was 

participating in his last JPSC meeting. She thanked him for his strong support 

of PSC activities, especially ResCom and RESWG activities, and wished him 

well in his new position. The Chairman closed the meeting at 17.15 hours. 
34 
 JPSC/31 PSC

 Attachment: A Page: 1 of 3

Airline / Company Name First Name Last Name Job Title EmailAbacus International Kit Leong Director, Airline and Core Solutions Marketing kit@abacus.coAbacus International Sow Fung Leong Director, PSDD sowfung_leongAbacus International Pte Ltd Linda Chee Product Consultant linda_chee@abAdria Airways Djanino Bubola Area Manager djani.bubola@aAerolíneas Argentinas Marta Cristina Chiban BSP Travel Agencies Manager mchiban@aeroAir China Ltd. Weihong JiajingAir China Ltd. Hailong Yue Chief yuehailong@aiAir France Helene Millet New Distribution Processes hearnaudmilletAir Transport Association of America James Casey Vice President & Deputy General Counsel jcasey@airlineAir Transport Association of America Patty Edwards Managing Director, Passenger Services pedwards@airAlaska Airlines Rick NaggAll Nippon Airways Kuniko Hayakawa Assistant Manager ku.miyazaki@aAll Nippon Airways Mitsue Sato Assistant Manger, IT Strategy&Planning mitsue@ana.coAll Nippon Airways Etsuko Tada Senior Manager e.tada@ana.coAll Nippon Airways Sachie Terunuma Assistant Manager s.terunuma@aAll Nippon Airways Chiharu Tsuzuki Senior Manager c.tsuzuki@anaAmadeus Marc Adam Product Definition Analyst - Ticketing marc.adam@aAmadeus Stephen-Terence Corking Senior Manager, Development scorking@amaAmadeus Adrian Gorun Product Manager adrian.gorun@Amadeus Pascale Mansart Functional analyst pmansart@amAmerican Airlines Karen Churchill Manager, Airports karen.churchillARC (Airlines Reporting Corporation) Philip Myers Sr Product Manager pmyers@arccoARC (Airlines Reporting Corporation) Philip Myers Sr Product Manager pmyers@arccoARC (Airlines Reporting Corporation) Keith Venzke Senior Manager Industry Standards kvenzke@arccAustrian Airlines Marcus Lenk Head of Ticketing Steering marcus.lenk@aAXESS International Network Inc. Tomoko Igawa Senior Manager igawa.tomoko@British Airways PLC Jerry Foran Product Delivery Manager, Revenue Manageme jerry.foran@baCathay Pacific Airways Ltd Judy Tam Worldwide Reservations & Ticketing Manager - judy_tam@cath
Delta Air Lines Julie Bernard Project manager ETicketing julie.b.bernard@

Delta Air Lines Stephanie Yen Manager - Industry Affairs stephanie.yen@Egyptair Hisham Magdy Manager Aviation Affairs Development hisham_magdyEl Al Israel Airlines Ltd. Linda Grinfeld Deputy director IATA and Pricing linda@elal.co.iFinnair Oyj Päivi Rautanen Product Manager paivi.rautanen@Hainan Airlines Guo Jiajing Specialist of International Pricing Jiaj_guo@hnaiHainan Airlines Limin Tang Supervisor of International Pricing Lm_tang@hnaHP Lucia Gerber Product Manager lucia.gerber@hIATA Lisa Angiolelli Product Manager, Passenger Facilitation ANGIOLELLILIATA Paul Behan Head, Passenger Experience behanp@iata.oIATA Stephan Copart Project Manager, Fast Travel coparts@iata.oIATA Rosanna Iannantuono Manager, Mileage Products, PASS iannantuor@iaIATA Daniel Kanter Senior Legal Counsel, LEGAL kanterd@iata.oIATA Thomas Klein Product Manager, Passenger Segment Publicati kleint@iata.orgIATA Eric Leopold Director, Passenger leopolde@iataIATA David McEwen Manager, Passenger Interline Standards, PASS mcewend@iataIATA Mike Muller Head, Passenger Inteline Standards mullerm@iata.IATA Andrew Price Nead, Baggage Services pricea@iata.orIATA Alban Sato Manager, Interline Tariffs, PASS satoa@iata.orgIATA Marie Zitkova Manager, Messaging Standards, PASS zitkovam@iataIberia Airlines Concha De La Calle Manager Reservations & Distribution ccalle@iberia.eIberia Airlines Mary Jo Reviejo Reservations Analyst & Industry Relations mjreviejo@iberInfini Travel Information, Inc. Ken Morita Assistant Manager morita0241@inJapan Airlines Eri Miyake Manager eri.miyake@jalJapan Airlines Hikaru Yamauchi Director hikaru.yamaucKenya Airways Agnes Kwanya Manager Interline and Tariffs Agnes.KwanyaKLM Royal Dutch Airlines Johan Lodewijckx Manager IATA & Industry Affairs johan.lodewijckLOT Polish Airlines Elizabeth Dmowska IATA Rules and Regulations Adviser e.dmowska@loLOT Polish Airlines Dorota Wronska Pricing Manager d.wronska@lotLufthansa Michelle Bryant Manager Distribution Systems and IATA Industrymichelle.bryant

Malaysia Airlines Jaffar Derus Ahmad Vice President Airport Operations jderus@malaysMalaysia Airlines Hayati Dato Ali Executive Vice President-Airport Operations hayati@malaysMEA Salim Kharrat In Charge Agency & Procedure kharrats@meaPSC Chairman Patricia George PSC Chairman pageorge@waSabre Holdings Tim Powell Director Industry Affairs tim.powell@saSAS Christina Falck Manager Industry Affairs christina.falck@SAS Elaine Rusén Manager Industry Affairs elaine.rusen@Saudi Arabia Airlines Ayed Alotaibi Snr.Specialist Airport Services Programs AALOTAIBI@S
SITA John Meeks Mgr, Business and Market Intelligence john.meeks@s

South African Airways madelein vorster manager: ticketing support madeleinvorsteSouthwest Airlines Carole Barnett Mgr/API Airport Solutions carole.barnett@Swiss International Air Lines Ltd Patrick Graf Head of Revenue Management Solutions & Dist patrick.graf@s

TCH (Transport Clearing House) Anna Golenkina Technology Department, Head Golenkina@tchTCH (Transport Clearing House) Natalia Kisletsova External Relations Department, Head kisletsova@tchThai Airways International Ohm Planichaya Director ohm.p@thaiairThai Airways International Janpen Rana Chief, Sales and Marketing Procedures janpen.r@thaiaTravelport Caroline Wilkinson Product manager caroline.wilkinsUnisys John Kunitz Manager john.kunitz@unUnited Airlines Rosalie Crabbe Mgr. Accesible Programs and Industry Affairs rosalie.crabbe@US Airways, Inc. Heather Hamel Senior Analyst - Airport Policies & Procedures HEATHER.HAUS Airways, Inc. Deryl Purvis Senior Analyst DERYL.PURVVietnam Airlines Do Thi Nu VN executive ngocntm@vietnVietnam Airlines Nguyên Thi Munh NgrVietnam Airlines Uyen Vu Thi Deputy General Manager - Tariff & Ticketing uyenvt@vietnaVirgin Australia Simon Pitt Manager Revenue Simon.Pitt@vir
 JPSC/31 PSC/33 Oct 11 

 Attachment: B 

 Page: 1 of 4 

NEW TAX CODES 

As of September 2011 

CODE NAME COUNTRY REQUESTED

BY

DATE PURPOSE / DETAILS

 

-PU- AIRPORT 

DEVELOPMENT LEVY 

GAMBIA BRUSSELS 

AIRLINES 

29/10/10 INVESTMENT IN EXPANSION AND 

RENEWAL of AIRPORT 

INFRASTRUCTURE. 

 

-PX- AIRPORT SECURITY 

CHARGE 

NICARAGUA TACA 03/11/10 PROVISION OF SECURITY 

SERVICES. 

 

-PD- AVIATION SECURITY 

FEE 

PHILIPPINES SOUTH EAST 

ASIAN AIRLINES 

(SEAAIR) 

04/11/10 TO ENSURE ADEQUATE SECURITY 

MEASURES TO PREVENT 

HIJACKING AND ANTITERRORISM. 

 

-PZ- PASSENGER SERVICE 

CHARGE 

QATAR QATAR 

AIRWAYS 

08/11/10 PROVISION OF IMMIGRATION AND

SECURITY SERVICES TO PRESERVE 

AND ENHANCE FACILITATION AND

SECURITY. 

 

-QB- AIRPORT TAX ECUADOR LAN ECUADOR 20/12/10 USE OF TERMINAL FACILITIES AT 

 THE UIO AND GYE AIRPORTS.. 

-QI- AIRPORT AUXILIARY 

FACILITY TAX 

ECUADOR LAN ECUADOR 21/12/10 USE OF AUXILIARY FACILITIES IN 

THE TERMINAL AT THE UIO AND 

 GYE AIRPORTS. 

 

-QD- AIR TRANSPORT LEVY AUSTRIA AUSTRIAN 

AIRLINES 

22/12/10 IMPOST OF THE AUSTRIAN 

GOVERNMENT ON AIR 

PASSENGERS TO PROVIDE TAX 

REVENUES FOR THE EXCHEQUER. 

 
 JPSC/31 PSC/33 Oct 11 

 Attachment: B 

 Page: 2 

1

 Subsequently postponed

-QF- SOLIDARITY TAX GABOM GABON 

AIRLINES 

22/12/10 TO CONTRIBUTE TO NATIONAL 

SOLIDARITY FOR DEVELOPMENT 

 

-QJ- SECURITY CHARGE ZAMBIA KENYA AIRWAYS 13/01/11 PROVISION AND DEVELOPMENT 

 OF SECURITY SERVICES. 

 

-PQ-1 SECURITY CHARGE MADAGASCAR AIR 

MADAGASCAR 

13/01/11 PROVISION OF SECURITY SERVICES

THE 8 MALAGASY AIRPORTS. 

 

-TF- VALUE ADDED TAX SRI LANKA SRI LANKAN 

AIRLINES 

10/03/11 COLLECTION OF VAT. 

 

-QQ - AIRPORT SECUIRTY FEE GUATEMALA AMERICAN 

AIRLINES 

25/03/11 PROVISION OF SECURITY SERVICES

AT THE GUATEMALA AIRPORTS. 

 

-RR- AIRPORT TAX CONGO KENYA AIRWAYS 01/04/11 TO COVER THE COSTS OF 

A.N.A.C. SERVICES. 

-SS-1 AVIATION 

INFRASTRUCTURAL 

DEVELOPMENT FUND 

LEVY FEE (DOMESTIC) 

ZIMBABWE AIR ZIMBABWE 04/04/11 FOR AN INFRASTRUCTURE 

DEVELOPMENT AND EQUIPMENT 

MODERNIZATION PROGRAM 

BASED ON THE USER-TO-PAY 

CONCEPT. 

 

-RF- PASSENGER CHARGE SERBIA JAT 05/04/11 AIR TRANSPORT DEVELOPMENT. 

-RY- SALES TAX YEMEN YEMENIA 18/04/11 DOMESTIC TAX TO RAISE 

REVENUE FOR THE TREASURY. 

-YT- PASSENGER SERVICE 

CHARGE 

MAYOTTE AIR AUSTRAL 21/04/11 TO PROVIDE PASSENGER 

FACILITIES AT THE AIRPORT. 

 

-RP- AIRPORT 

DEVELOPMENT 

CHARGE 

SAINT LUCIA AMERICAN 

AIRLINES 

27/04/11 FOR THE PURPOSE OF MAKING 

PAYMENTS FOR THE DEBT 

SERVICE REQUIRED TO 

IMPLEMENT AIRPORT FACILITY 

IMPROVEMENT PROJECTS. 

 

-SM- INFRASTRUCTURE 

DEVELOPMENT 

CHARGE 

TOGO AIR FRANCE 23/05/11 FINANCE EXPANSION AND 

IMPROVEMENT OF THE 

GNASSINGBE EYADEMA AND 

LOMÉ AIRPORT. IN ADDITION, 

THE RDIA WILL BE USED TO 

FINANCE THE RESEARCH 

LOCATION FOR THE 

CONSTRUCTION OF A NEW 

AIRPORT AT LOMÉ. 

 

-TE- SECURITY CHARGE NIGERIA AIR NIGERIA 01/06/11 IMPROVE SECURITY SERVICES AT 

NIGERIAN AIRPORTS. 
 JPSC/31 PSC/33 Oct 11 

 Attachment: B 

 Page: 3 

-MM- PASSENGER SERVICE 

CHARGE 

MYANMAR MYANMAR 

AIRWAYS 

14/06/11 TO IMPROVE AIRPORT TERMINAL 

PASSENGER SERVICES 

 

-TP- PASSENGER SECURITY 

AND SAFETY FEE 

UNITED ARAB 

EMIRATES 

EMIRATES 

AIRLINES 

27/06/11 COVER ADDITIONAL COSTS FOR 

SECURITY AND SAFETY. 

 

-VA- PASSENGER 

CLEARANCE TAX 

PAPUA NIUGINI AIR NIUGINI 05/07/11 TO PREVENT THE ARRIVAL OF 

UNWANTED DETRIMENTAL PLANT 

AND ANIMAL PESTS, DISEASES 

AND WEEDS. 

-UC- PASSENGER AVIATION 

SERVICE CHARGE 

JAMAICA AIR JAMAICA 13/07/11 TO FINANCE AIR NAVIGATION 

SERVICES FOR OPERATIONS 

ORIGINATING AND 

TERMINATING IN JAMAICA AND 

THE PROVISION OF REGULATORY 

SERVICES. 

 

-UM- SECURITY CHARGE SOUTH AFRICA SAA 09/08/11 ACS CHARGE IS FOR SERVICES 

RENDERED BY AVIATION 

COORDINATION SERVICES (PTY) 

LTD TO PROVIDE / HOLD 

BAGGAGE SCREENING 

BAGGAGE RECONCILIATION 

AND CUTE SERVICES AT SOUTH 

AFRICAN AIRPORTS. 
 JPSC/31 PSC/33 Oct 11 

 Attachment: B 

 Page: 4 

CODES RESCINDED, WITHDRAWN OR EXPIRED 

CODES REINSTATED 

No codes were reinstated 

CODE NAME COUNTRY REQUESTED 

BY 

DATE PURPOSE / DETAILS 

-BS- TICKET TAX 

(INTERNATIONAL) 

BAHAMAS BAHAMASAIR 

HOLDING LTD. 

30 /10/11 LEVIED ON ALL TICKETS SOLD IN 

THE BAHAMAS WITH A 

DEPARTURE ENTITLING 

PASSENGER TO TRAVEL OUTSIDE 

THE BAHAMAS ON 

INTERNATIONAL FLIGHTS. 

 

-SS- AVIATION 

INFRASTRUCTURAL 

DEVELOPMENT FUND 

LEVY FEE (DOMESTIC) 

ZIMBABWE AIR ZIMBABWE 04/05/11 FOR AN INFRASTRUCTURE 

DEVELOPMENT AND EQUIPMENT 

MODERNIZATION PROGRAMME 

BASED ON THE USER-TO-PAY 

CONCEPT 

 

-JO- TICKET SALES TAX 

(INTERNATIONAL) 

JORDAN ROYAL 

JORDANIAN 

AIRLINES 

09/02/11 LEVIED ON EACH PASSENGER 

DEPARTING JORDAN, 

IRRESPECTIVE PLACE OF ISSUE 

AND PAYMENT OF THE TICKET. 

 

-PQ- SECURITY CHARGE MADAGASCAR AIR 

MADAGASCAR 

31/01/11 PROVISION OF SECURITY 

FACILITIES AT THE 8 MALAGASY 

AIRPORTS 

 

A road map to prepare 

for tomorrow’s passenger

Five goals towards sustainable profits 

and better service

Are you ready for tomorrow’s passenger? 

Air transport is today an integral part of the global economy. The industry moves people and goods across the 

globe quickly and efficiently, fostering economic development, greater human understanding and international 

trade. In the future, as economic interdependence grows so will the need for fast and secure transport. 

IATA’s Simplifying the Business program (StB), announced in 2004 in Singapore, was envisioned to address 

these challenges. And over the past seven years, it has demonstrated success, from the move to 100% electronic 

ticketing and 100% bar coded boarding passes to the widespread implementation of common-use self-service 

kiosks. This success was dependent on the mobilization of all industry stakeholders – including airlines, agents, 

airports, governments and ground handlers – towards a common goal of lowering cost and improving service 

and efficiency. 

But the industry continues to face the twin challenges of profitability and customer satisfaction. Global shocks 

have become a constant in our business, from increasing fuel prices to natural disasters. And from the shopping 

experience to long lines at security, travelers face numerous pain points in their journey.

The graphs below illustrate the challenge for the industry, and, in particular, for airlines. 

It’s time to build on the success of Simplifying the Business (StB) and define the next wave of projects that will 

allow the industry to save costs, improve service and prepare for tomorrow’s passenger. This white paper outlines 

the work of the StB think tank, which has proposed five goals in the areas of airline distribution, airport experience 

and system interoperability. The think tank, facilitated by IATA, consists of representatives from both airlines and 

system providers: Air Canada, Air France/KLM, Air New Zealand, British Airways, Emirates, Hewlett-Packard, 

IBM, L.E.K Consulting, and Oracle.

We look forward to your input.

Eric Leopold

Director, Passenger 

Source: IATA Source: IATA
THE FIVE GOALS

Goal 1: Airline products can be sold 

through all channels, identifying customers, 

and personalizing offers and prices.

Planning travel should be an exciting experience. 

But from a sense of initial euphoria at the thought 

of travelling somewhere new, today’s consumer is 

quickly confused by the dizzying array of travel options 

available to her. Take the example of a business 

traveler journeying from London to Austin, Texas. 

She starts to plan out her journey, but quickly realizes 

she needs to visit multiple websites to do so, from 

various airlines to hotels and car rental options. With 

10 windows open on her computer to try and identify 

the best fare, services and coordinate timings, she sits 

back and wonders, “Why can’t I just find everything 

in one place?” 

The Problem

In a recent IBM survey, none of the respondents 

indicated that they were able to complete their travel 

booking needs in one website visit. Travelers are 

bogged down by search and comparisons between 

products and services across the travel market. 

For example, how does a consumer know which airline 

offers door to door bag delivery? How can a consumer 

choose personalized service levels across all airline 

offerings if they can’t easily see what is on offer at 

one single location?

Not surprisingly, the increased number of choices 

available to travelers requires significant time 

investment in pre-booking search.

On their most recent trip...

• Almost 20% of travelers spent 5 or more hours 

shopping and / or booking 

• 25% of leisure travelers spent more than 4 hours 

shopping / booking

• Business travelers are more efficient, but ~40% of 

them spent more than 2 hours shopping / booking 

Beyond just taking a long time to book travel, there 

is a more fundamental issue: the current distribution 

channels do not cater for the personalized service that 

a 21st century consumer has come to expect. 

Instead, they drive commoditization of airline 

products. Price becomes top of list in terms of consumer 

preferences. This drives carriers to unbundle as many 

elements of the product as possible to have a low cost 

base product and then charging for many add-ons in 

order to maintain margins. 

Airline websites (direct channels) are more advanced, 

in terms of features and design, than systems used by 

agents (indirect channels). They enable the consumer 

to interact with the brand and experience the value of 

the product. For example corporate buyers can access 

customized options within their specific corporate deals. 

Individual consumers can access personalized options, 

after being identified by a frequent flyer number for 

example. 

The indirect channel however does not offer 

personalization for individual consumers. Through the 

push of content to airline distribution systems, the ability 

to mix and match options for the sophisticated 21st 

century consumer is limited. 

This misalignment between consumer buying 

preferences and the selling models used by airlines 

and other travel distribution companies limits innovation. 

Furthermore there is a lack of consumer related data 

and buying behavior patterns, which also restricts 

the ability of airlines to innovate based on consumer 

demand. 

The Solution

A consumer-centric approach that allows for more retail 

driven sales and distribution. 

Standards need to be developed to build an 

infrastructure that supports all travel industry related 

channels. That way, any airline website or agent system 

can display a complete range of services. Going back to 

our traveler, that means that she would have 
a choice of multiple channels, each one proposing 

a complete range of end-to-end services based on 

her preferences and their own brand proposition. 

For the industry, it will help to know who is 

buying the ticket so that personalized options 

can be presented to the consumer, regardless 

of the channel used. This would allow airlines 

to package their products in a meaningful way, 

based on buying patterns. It could also allow 

them to make more sophisticated offers to the 

consumer. Imagine the travel industry adopting the 

technology that online retail sales channels use in 

suggesting options to consumers based on their 

personal preferences. Airlines want to be able to 

launch fast new personalized offerings through 

all sales channels. 

Tracking who is interested in buying what, 

regardless of channel, also allows for innovation 

of new products and services. 

According to L.E.K. merchandizing revenues will 

amount to up to US$75bn in 2015 from US$23bn 

in 2010 estimated by Amadeus IdeaWorks. Airlines 

need consistent product distribution across all 

channels in order to achieve those results.

How we get there

Standards need to be developed in the areas of 

consumer data and interoperability of reservation 

systems. IATA could be in a position to facilitate 

the development of these standards amongst 

industry stakeholders. 

Goal 2: Passenger data is provided 

by passengers and validated by 

governments 

Let us return to our business traveler from 

London. After spending several hours on various 

booking websites she has an itinerary in place. 

Prior to her journey, she now needs to submit 

advance passenger information, as required by 

the US government. But if she gets confused by 

the varying requirements and makes a mistake, 

she might end up being denied boarding at 

the gate – a very unpleasant surprise for 

any passenger. 

The Problem

Today, harmonization between countries on the 

collection and distribution of passenger data is 

limited and, increasingly, required by more and 

more governments. Airlines are liable for fines when 

passengers are deemed inadmissible due to missing 

data or documentation. Passengers are confused 

due to the inconsistency of the information required 

depending on different regulations. 

In most cases airlines are required to collect relevant 

data before the passenger reaches the gate and 

this causes delays, slows the check in process, and, 

on occasion, results in denied boarding, as airlines 

may not be able to validate the information until the 

passenger reaches the gate. 

As a consequence, carriers have had to invest 

in their own computer systems to meet different 

government requirements, or contract with independent 

data processors. This has resulted in additional costs 

to carriers. 

The Solution

Elements of the required passenger information 

can be embedded into an electronic passport linked 

to biometrics and a visa validation service provided by 

governments, building one single data set. Ultimately 

the responsibility and ownership of data provision 

should be passed on to the passenger, and validated 

by governments. 

Information for passengers on the different government 

requirements could be held in a solution based on IATA 

Timatic which allows airlines and travel agents to check 

passenger immigration and health requirements, based 

on destination, transit points, nationality, residence and 

departure.

All travel vendors would be responsible for the 

collection of an agreed set of passenger data that 

is able to be sent on for verification to the relevant 

government agency.

How we get there

The industry needs to lobby governments and 

the International Civil Aviation Organization for a 

common approach on standards and liability issues. 

Infrastructure needs to be put in place to support and 

facilitate the distribution of passenger data on a global 

industry-wide basis. Governments should be persuaded 

to provide biometric and visa verification services as a 

responsibility of states.
Goal 3: Passengers can access realtime information relating to operational 

information on flight status, wait times 

and bags on any device in any location

So our passenger is ready to travel to Texas to take 

advantage of some warm winter weather. Twenty 

four hours before her scheduled departure time from 

London it starts to snow. She is receiving conflicting 

information from the news channels on television, 

the airport website and the airline website. She tries to 

contact the airline, but after spending a long time on hold 

she gives up. Since she booked her travel with an agent, 

the airline cannot push information to her as it does not 

have her contact details. She doesn’t know what to do. 

Should she show up at the airport or not? 

The Problem

Passengers suffer from uncertainty and stress 

associated with flight delays, cancellations and bag 

mishandling. Optimization of modern technology could 

go a long way to ease the pain, by allowing access 

to information in real-time. 

Today the lack of consumer contact information creates 

further frustrations for passengers, airline, and airport 

staff when dealing with irregular operations. The need 

to collect an agreed level of passenger contact data 

is required in the first instance, in order to be able to 

share the data and then provide value added solutions 

back to the consumer.

Social media and smart phones deliver immediate 

information to passengers that is not necessarily 

available to airline and airport staff managing customer 

service and expectations. So in some cases the 

passenger is getting more information about what’s 

happening than airline or airport staff. 

The Solution

A range of devices can be used to keep the customer 

informed. A message sent to a passengers’ smart/

mobile phone on flight delays or cancellations would 

allow the passenger to make reasonable decisions 

on their journey. Messages could also be sent on 

bag status. Finding out that your bag has not made 

the flight before you reach baggage claim manages 

expectations. Knowing that it will be delivered to 

your hotel translates to great customer service.

Touch screen kiosks at airports can be used to 

communicate more effectively with meaningful 

messages, relating to flight delays when unavoidable 

to due to extreme weather conditions for example. 

Easy wi-fi access in all airports would further 

enable dynamic communication. 

How we get there

Harmonization on data sharing across all industry 

stakeholders would improve service throughout the 

system. The creation of a best practice on passenger 

information collection would lead to proactive customer 

service and industry alignment. By reaching agreement 

and developing standards through negotiations with 

industry stakeholders, airlines, airports, security 

agencies, border control, and ground handlers on 

supporting infrastructure would serve as a solid 

base for future development.

Goal 4: The consumer 

ground experience is hassle free

Once the snow has cleared, our stressed-out passenger 

has managed to check-in for a flight to the US. But 

once she drops off her luggage, she proceeds to the 

security check to find a very long queue. Passengers are 

wondering if they need to take off their shoes or belts, 

or leave their laptops in their carry-on luggage. She 

wonders, “Why does this have to be so complicated?”

The Problem

The biggest pain point for passengers today is the 

hassle associated with airport controls. Passengers 

experience uncertainty and stress due to inconsistency 

of processes at airports which can be better integrated 

than they are today. There are long wait times, in 

addition to different procedures to be followed at 

different airports around the world. 

The Solution

Passport, visa, customs and immigration issues 

could be solved at booking; and off-airport document 

checks validated by governments could be similar 

to credit card validation. There are already existing 

standards for automated bag drop and check in – and 

using biometrics in conjunction with Checkpoint of the 

Future and immigration, the customer experience could 

be a simplified and hassle free experience.

The Checkpoint of the Future ends the one-size-fitsall concept for security. Passengers approaching 

the checkpoint will be directed to one of three lanes: 

‘‘Known travelers’’, ‘‘Normal’’, and ‘‘Enhanced security’’. 

The determination will be based on a biometric 

identifier in the passport or other travel document that 

triggers the results of a risk assessment conducted by 

government before the passenger arrives at the airport. 

The three security lanes will have technology to 

check passengers according to risk. “Known travelers” 

who have registered and completed background checks 

with government authorities will have expedited 
access. “Normal screening” would be for the majority 

of travelers. And those passengers for whom less 

information is available, who are randomly selected or 

who are deemed to be an “Elevated risk” would have 

an additional level of screening.

Existing self-service options which are already in 

place should work with the Checkpoint of the Future 

and immigration, aiming to improve security screening 

and introduce faster processing, making more efficient 

use of passenger data. 

How we get there

Governments, airports and airlines need to cooperate 

by sharing data with each other. The industry as a whole 

should start by lobbying governments on standards 

and infrastructure for data exchange. Airlines and 

airports need to work together to link all of the different 

components of processing the passenger through the 

airport and onto the aircraft to the final destination.

Goal 5: Seamless end to end customer 

journey through interoperability of travel 

partners

Our traveler boards the plane and her flight takes 

off for New York, her first point of entry into the US. 

When she lands in New York, she finds out that she 

needs to postpone her connecting flight to Austin for 

a day to attend a critical meeting in the city. Today, 

that means she needs to separately change her flight, 

hotel reservation, car rental reservation and any other 

experiences she may have booked in Austin. 

The Problem

Today, the primary identifier of a customer is a booking 

reference. And not just one. There might be several 

booking references that don’t talk to each other. So if 

a traveler needs to make a change, or book something 

else through a different travel agent, the systems can’t 

talk to each other. There is no concept of a master PNR 

that encompasses all aspects of a travel experience.

A booking reference given to a customer in a 

distribution system is not recognizable in the operating 

carrier’s host reservation system or through that airline’s 

customer facing systems. Increasing code share 

and interlining within airline alliances is increasing 

customer expectations for a seamless journey. With 

the growing importance of alliances, and the existence 

of many different proprietary airline host systems, the 

industry is missing standards for an inter-airline host 

system communication to enable alliances and partners 

to service their joint customers from whichever airline 

touch point in the journey the customer has reached.

Customers cannot experience a seamless integrated 

journey with reduced stress if travel partners are not 

connected. When a flight is changed, for example, 

the airport pick-up service may not be notified. The 

changes in the travel distribution landscape have 

forced many customers to assume the role of travel 

agents responsible for finding schedules that work well 

across travel modes and also monitoring connections 

between modes in transit. 

The Solution

To alleviate the stress factor of customers and the 

airlines that serve them, both could benefit from a 

service that addressed the disconnected nature of 

travel today by providing assurances mid journey 

that everything was on track, and if not, assurances 

that the problem had been resolved. If airlines had 

more information about the final destination of their 

passengers they would be in a better position to delight 

the customer with more information, better service, 

and choices on how to adjust when things change. 

Collaboration and connectivity are limited within 

segments of the travel industry, should a passenger 

need to transfer from one airline to another due to a 

change of plans. At the airport, it is good to know the 

possible length of the delay. It would be even better if 

the traveler was confident that changes to their airport 

pick-up had been made and that a late check-in at the 

hotel had been arranged.

How we get there

To achieve a seamless end to end customer journey 

through interoperability of travel partners, the industry 

needs standards for data exchange protocols. By 

reaching agreement through cooperation with travel 

partners, the future could be a single travel wallet for 

the entire journey, with all travel segments talking 

to each other, to the passenger, and being able to 

exchange information with the consumer at different 

points during his trip.

Checkpoint of the Future at IATA’s AGM in Singapore, 2011
CONCLUSION

Despite the difficulties she encountered, our traveler 

reaches Austin safely, and has the chance to explore 

new business opportunities, gain exposure to new 

people and places, and enjoy a break from the 

European winter. 

Where do we go next?

These ideas have been crystallized over a few 

months of interaction among the StB Think Tank. 

It’s now your turn. Join us and shape the future direction 

of the industry as we prepare for tomorrow’s passenger. 

Let us know what you think and how you think you can 

contribute to these goals. Share these ideas amongst 

your stakeholders. The think tank will have a session 

dedicated for feedback at the IATA World Passenger 

Symposium, on Friday 14 October. In addition, ongoing 

feedback is welcome and can be sent to passenger@

iata.org. 

As a next step and based on the feedback received, 

these ideas will be presented to the StB Steering Group 

and formulated into proposals for the December 2011 

IATA Board of Governors meeting. 

Tony Tyler, IATA’s Director General, believes 

passionately that “aviation is a force for good in the 

world, a force for progress, growth and wealth in both 

material and human spirit.” Let us work together to 

build a sustainable future for our industry. 

CONTRIBUTIONS 

The following airline delegates are members of 

the StB Think Tank and were appointed to propose 

a way forward for Simplifying the Business.

Patrice Ouellette

Director Customer Solutions 

& Innovations – Air Canada

Patrice Ouellette joined the e-Commerce/IT department 

in 2004 after spending the first 10 years of his career at Air 

Canada with the Airport department. He has performed many 

roles during that period from an agent check-in to General 

Manager Customer Service Eastern Canada, responsible 

for all the Air Canada operations at more than 10 airports. 

In 2005 he created the Customer Service Platform 

within Air Canada taking the responsibility for the self 

service applications and Customer facing Airport innovations. 

His team has lead the introduction of many innovations like 

mobile applications for smart phones, mobile check-in, the 

electronic boarding pass and a complete re-architecting of the 

Kiosk and Web Check-in Self Service product .The CSP team 

introduced self tagging in selected stations and smart drop a 

quick baggage drop off solution for airport. 

He is currently Director Customer Solutions and Innovations 

within the IT department. The role consists of developing new 

and maintaining actual customer facing application and at the 

same time promoting and often demonstrating the use of new 

and innovative technologies direct into the business. 

Matthias Koch 

Director Research and 

Development – Air France 

Director Research and Development Passenger Ground 

Experience in the Marketing Department of Air France 

and KLM, has been working in the airline industry for over 

twenty years. He has a strong background in the Marketing, 

Sales, Revenue Management, Pricing and Ground Services 

aspects of the airline business with a particular emphasis on 

Innovation and Product Development.

Working today on new business solutions and the future 

travel experience on the ground he is also a member of the 

Rob Broere 

Vice President IT – Passenger 

Services Systems & Passenger 

Experience – Emirates

Rob Broere, who originates from the Netherlands, started 

his career in 1981 at KLM working on the IT side of the RES/

DCS system. He has always been involved in the core airline 

systems and during his career of over 30 years supported 

many airlines across the world with their systems. He joined 

Emirates in 1995 and is as Vice President IT – Passenger 

Services Systems & Passenger Experience, responsible 

for the running and expanding the Passenger systems and 

driving forward the customer experience from an IT point of 

view. He combines his knowledge of the Airline Industry with 

the knowledge of what IT can do and uses that to support 

the airline driving forward the customer experience. In 2010 

he joined the IATA StB Steering Group and was appointed 

Chairman of both the Steering Group and IATA StB Think 

Tank with as aim driving forwards the industry.

Glen Morgan

Head of Service Transformation – 

British Airways 

Glenn is seen as a thought leader in the travel, aviation, & 

technology sectors, plugged into emerging digital trends and 

innovation in behavior and technology. If it's new, cutting edge 

and interesting, Glenn can tell you how to exploit it. Glenn has 

worked across range of industries where IT is a boardroom 

issue, including telecommunications, utilities, oil and gas, 

government, and airlines and prior to his current role, was 

Technology & Service Partner at British Airways Plc. 

As Head of Service Transformation, Glenn will develop and 

refine the business strategy by understanding market trends, 

develop external customer insight and business innovations, 

seek opportunities for competitive differentiation and reengineer 

and develop new sales and distribution channels. Prior to his 

current role, Glenn worked in Dubai, UAE for Emirates Airline. 

Glenn holds a Black Belt in Six Sigma from GE and is also a 

specialist Lean Practitioner.
IATA Simplifying the Business Steering Group and the recently 

created IATA Think Tank. Based today in Paris, Matthias has 

lived and worked in countries like Germany, Venezuela and 

Mexico.

Todd Grace

Strategy Manager – 

Air New Zealand 

Todd is currently working as a Strategy Manager in the 

area of Strategic Development at Air New Zealand. His role 

focuses on our airport business, in particular operations, 

service development and airport company commercial 

relationships. 

He is responsible for identifying areas for creating value 

in airports through effective use of technology, strategic 

partnerships and improved operating and customer service 

processes. It also focuses on managing the commercial 

relationship between the airline and the airports and inputting 

into the charging process as required by legislation. 

The role entails delivering travel solutions for our customers, 

and developing a suite of innovative products and services 

based on our customer’s needs. This has seen the development 

and implementation of Air New Zealand’s self service product 

for New Zealand airports including the use of mobile and NFC 

technology.

Strategic Partners

The following delegates were appointed by their 

companies, which are IATA Strategic Partners, to advise 

IATA on the implementation of strategic initiatives.

Daniel Friedli 

Hewlett Packard 

Daniel Friedli, a Swiss and Canadian national, joined 

the airline industry in 1998 as a TPF trainee for Atraxis, 

the Swissair IT subsidiary. After several years of TPF 

development in the Reservations and Ticketing areas, Daniel 

himself led training for TPF developers in South Africa for 

several months, passing on extensive domain knowledge. 

Transitioning to EDS with the rest of Atraxis, he started 

working on strategic and pursuit related projects. In that time, 

he also started his engagements in several IATA groups to 

help define industry standards. In 2006, Daniel decided to 

widen his domain knowledge and and move from the system 

provider side to the airline. He joined Swiss International 

Air Lines, albeit still on the IT side of things. At SWISS, 

Daniel focused on large, strategic projects such as the 

implementation of interline ETKT, Star Alliance collaboration 

as well as developing strategies around mobile device usage 

and the value and need of next generation PSS systems. In 

2010, Daniel decided to take a challenging role with HP at 

the forefront of defining HP’s new PSS product. In this role, 

he currently also represents HP at industry conferences and 

working groups such as the IATA StB Think Tank as well as 

in customer facing roles supporting the existing HP airline 

community as well as potential new business.

Eric Conrad

Leader IBM’s Global Travel & 

Transportation Industry – IBM

Eric Conrad leads IBM’s Global Travel & Transportation 

Industry comprising, Air Travel Related Services, Freight & 

Logistics, and rail.

Across his 25+ year career, the last 16 of which have been 

in Asia Pacific, Eric has gained extensive, direct experience 

in creating business value for Travel & Transportation clients, 

working across the United States, Europe, and in many Asian 

economies such as Malaysia, Singapore, Indonesia, Thailand, 

the Philippines, Vietnam, Korea, Japan, Hong Kong, China, 

Australia and India.

Working with some of the most prestigious global airlines, 

Eric has been able to create significant client benefits 

through major multi-year partnerships with IBM focused 

upon technology-driven transformation. His transformation 

work has effectively linked strategic planning to business 

and operational planning, all the way through to technology 

deployment.

Eric has an MBA in International Business (1st in Class) 

from the University of Connecticut, USA. He graduated with 

a Bachelor of Science ( Business Administration) from the 

University of Delaware, also in the USA .
John Thomas

Vice President – LEK

John Thomas is a Vice President at L.E.K. Consulting 

and heads L.E.K.’s global Aviation & Travel practice. John 

has more than 21 years experience in strategy, financial, 

commercial, operational and organizational consulting to 

the aviation industry and has worked with most of the 

leading airlines around the world (both legacy and LCC) on 

a broad range of major issues e.g. he has been instrumental 

in the adaptation of merchandising (ancillary revenue) to 

the airline industry, and has advised on many of the major 

merger and acquisition deals in the industry. 

John Thomas has also worked with OEMs, CNS/ATMs, 

airports, tour operators, travel destinations, cruise lines, 

hotels, resorts, loyalty programs, caterers, as well as having 

extensive experience in the GA and Corporate Aviation 

industries. He has worked with clients in North and South 

America, Europe, the Middle East and the Asia Pacific region.

Vijay Anand

Senior Director, Industries 

Business Unit – Oracle

Vijay Anand is the Senior Director at Oracle Corporation’s 

Industries Business Unit and the Global Industry Lead for 

Travel, Transportation & Logistics Industries. Vijay has over 

20 years of experience across Transportation Industries IT 

Solutions and Consulting. Prior to joining Oracle Corporation, 

he was part of SITA for 8 years in the capacity of Solutions 

Director. 

Vijay has a graduate degree in Science specializing in 

Physics (Applied Electronics) and MBA from Canadian 

School of Management, in addition to Project Management 

Professional (PMP) qualification. He is an active member 

of the Project Management Institute, American Association 

of Airport Professionals, Singapore Computer Society and 

Singapore Quality Institute. 

Copyright © 2011 Hewlett-Packard Development Company, L.P. 

In an instant-on world where everything is connected, the airline industry must 

elevate productivity and efficiency to remain competitive. With more than 

9,000 travel and transportation industry specialists, HP keeps your business 

flying high. We provide a wide array of technology products and services 

to help airlines, airports, travel services, and hospitality companies—even 

freight and logistics businesses—take off in new directions.

hp.com/enterprise/transportation

LIFT

your airline business to new levels.

WELCOME TO 

 INSTANT-ON AIRLINES.
to learn more, visit www.lek.com/industries/airlines

L.E.K. DELIVERS UNMATCHED VALUE 

TO THE WORLD’S LEADING AIRLINES 

Succeeding in aviation demands strategic vision, sound data and 

superior execution.

L.E.K. Consulting is the leading strategic advisor to the global airline industry. We 

understand the market’s unique challenges, and we don’t just advise. We partner with 

our clients to help them address their big challenges and make the best decisions.

We provide solid strategic answers that you can count on. And we have a strong track 

record of demonstrated success to prove it.

twitter.com/lek_consulting
Copyright © 2009, Oracle. All rights reserved. Oracle is a registered trademark of Oracle Corporation and/or its affiliates.

Other names may be trademarks of their respective owners.

20 of the 20

Top Airlines

oracle.com/goto/airlines

or call 1.800.ORACLE.1

Get Better Results With Oracle

Oracle Travel & Transportation

IND_Tra_TopAirlines_2305

www.iata.org
 JPSC/31 PSC/33 Oct 11 

 Attachment: D 

 Page: 1 of 1 

Passenger Distribution Group (PDG) 

Terms of Reference 

The Passenger Distribution Group is established by the Passenger Services 

Conference (PSC) to with the following terms of reference. 

Objectives 

• Set a vision for multi-channel airline distribution 

• Validate the strategy and industry business case and requirements 

• Act as an industry voice on airline distribution 

• Define key industry messages for distribution-related matters 

• Review progress of IATA projects in distribution 

• Act as a watch group on industry developments 

• Be the central provider of industry informational and statistical data 

Appointments 

• This is a group comprised of IATA member airlines; non-member airlines may 

receive a special appointment by IATA SVP IDFS 

• Delegates are airline director-level or above in charge of airline distribution or 

distribution system strategy; there are no alternates 

• Industry stakeholders may be invited to attend meetings upon invitation by 

IATA SVP IDFS 

Schedule 

• annual in-person meetings at IATA’s Head (Montreal), Executive (Geneva), or 

Regional offices 

• Regular calls (monthly or quarterly) 

• Meeting agendas shall be circulated in advance of each meeting for review 

and comments by delegates, the Chairmen of the PSC Steering Group and 

the StB Steering Group. Minutes shall be taken at each meeting and 

circulated among the delegates for review, comment, and approval. 

Technical sub-groups 

1. The PDG may create technical sub-groups to address specific issues and 

business requirements, for example requirements to develop new schemas or 

rules and tools. Such sub-groups will be coordinated with the secretariat of 

the PSC and/or the Passenger Agency Conference (PAConf). 

Administrative 

• The PDG will have a one year mandate (renewable as required) and will 

report to the PSC with any proposed technical improvements, 

recommendations and an industry standards implementation plan. 

• During the year the PDG will provide regular progress reports to the PSC 

Steering Group and the StB Steering Group 

• The group will coordinate its activities with other industry groups involved in 

airline distribution 

• The Secretary is the IATA Director Passenger (leopolde@iata.org) 
 JPSC/31 PSC/33 Oct 11 

 Attachment: E 

 Page: 1 of 1 

INVOLUNTARY REROUTING WORKING GROUP 

TERMS OF REFERENCE 

An Involuntary Rerouting Working Group (IRWG) is established with the following 

Terms of Reference: 

1. Perform a complete review of current IATA and ATA industry standards 

related to involuntary rerouting. 

2. Identify outdated and/or conflicting processes, within the IATA and ATA 

standards and perform a comparison between them. 

3. Identify the main differences to determine best practices from both resolutions 

4. Liaise with other industry groups with potential impact for gaining intellect 

including (but not limited to) revenue accounting, tariffs, reservations, airports. 

5. Develop a common approach for re-ticketing in the case of planned schedule 

changes. 

6. Prepare agenda item(s) as necessary to promote quick and efficient 

involuntary rerouting processes both unplanned (i.e. Irregular operations) 

scenarios and planned schedule changes. 

7. Report findings and/or proposals to the Ticketing Committee (JPTC). 

PARTICIPANTS 

Volunteers from the JPTC, RESWG and RAWG who have indicated their 

participation. 

REPORTING STRUCTURE/MANDATE RESTRICTION 

The working group will have a mandate for 1 year. All activity of the working group 

will be fully communicated to JPTC for discussion. A report will be submitted to the 

JPSC with recommendations and proposals. 
 JPSC/31 PSC/33 Oct 11 

 Attachment: F 

 Page: 1 of 1 

AIRPORT SERVICES COMMITTEE (ASC) MEMBERSHIP 2012 

Airport Services Committee (ASC) Membership 2012

Airline Traffic Conference Area Term of Office Expires 

 

Air France 1 2012 

Alitalia 2 2013 

American Airlines 1 2014 

British Airways 2 2012 

Delta Airlines 1 2014 

Egyptair 2 2013 

El Al 2 2013 

Iberia 2 2014 

Japan Airlines 3 2013 

KLM 2 2012 

Lufthansa 

(Vice Chairman) 2 2012 

South African Airways 2 2014

United Airlines 1 2012 

vacant

vacant 

vacant 

vacant 

Vacant 
 JPSC/31 PSC/33 Oct 11 

 Attachment: G 

 Page: 1 of 1 

ATA/IATA Baggage Working Group (BWG) 

Terms of Reference 

The Baggage Working Group (BWG) shall: 

• report to the Airport Services Committee (ASC); 

• Review and develop messages for baggage handling and bag tag 

construction (for example, but not limited to, Resolutions 740, 741, 

742, 742a, 743, 743a, 746, and RPs 1740a, 1740b, 1740c, 1740d, 

1740e, 1743d, 1743e, 1744, 1745, 1751, 1800); 

• Note that procedures regarding self-service processes pertaining to 

baggage will be handled by the PEMG (RP 1701 series); 

• Review and develop recommendations on baggage processes; 

• Review and improve relevant Resolutions and RPs with respect to 

reducing interline baggage mishandling as regards to baggage 

messages, and bag tag construction as described in Resolution 740; 

• Identify any cross-functional issues related to baggage messaging that 

need to be resolved outside the BWG, for example by the Passenger 

Experience Management Group (PEMG); 

• Align and cooperate with other industry working groups relating to 

baggage messaging issues; 

• Utilize electronic and/or other means of communication wherever 

possible and meet only when necessary. Such formal meetings should 

not exceed two per year; 

• Forward proposed amendments to current ATA/IATA Resolutions and 

Recommended Practices as well as new submissions to the ASC for 

adoption by the PSC; 

• Consist of representatives from ATA/IATA carriers, airports 

participating in the IATA Airport Advisor Programme and participants in 

the IATA Strategic Partners programme with an interest in baggage 

management. 

The IATA contact for BWG matters is the IATA Head, Baggage Services 

(pricea@iata.org) 
 JPSC/31 PSC/33 Oct 11 

 Attachment: H 

 Page: 1 of 2 

Baggage Steering Group (BSG) 

Terms of Reference 

The BSG is established by the PSC with the following terms of reference: 

To develop, maintain and communicate a baggage vision, taking from and 

adding to the Vision 2050 work of IATA and working closely with the PEMG; 

To be the owners of baggage processes, technology and data from the point 

of baggage acceptance by the airline (i.e. the point at which the airline takes 

physical control of the bag) to the point of return of the bag to the passenger; 

To determine a plan for the delivery of that vision at an industry level; 

To determine how industry wide measures and performance targets for 

baggage handling can be developed and captured. 

The group shall meet 4 times per year, using technology as appropriate to minimize 

travel, but at least 1 meeting will be face-to-face. 

Periods of membership 

Airlines are invited to join the group by the PSC. This group is set up to be small and 

dynamic, and thus membership is limited to 10 airlines. The representatives of each 

airline must be senior members of their airline’s management team. Airlines join the 

group for a period of 2 years, after which they may be re-elected for a further periods 

of 2 years up to a maximum of 6 years. 

Airports may be invited to join the group in an advisory capacity for a period of 2 

years with the same renewal conditions. Airport members are chosen from the IATA 

Strategic Partnership Programme by IATA as necessary. Airport membership is 

limited to 3 airports. 

Failure to attend more than 2 consecutive meetings will result in the representative 

being asked to step down, unless good cause is provided. 

The IATA contact for Baggage Steering Group is the IATA Head, Baggage Services 

(pricea@iata.org) 
 JPSC/31 PSC/33 Oct 11 

 Attachment: H 

 Page: 2 

BSG Membership 

Name Airline E‐Mail

    

Airlines    

Darphin, Mikaël Air France midarphin@airfrance.fr

Rick Nagy   Alaska Airlines   Rick.Nagy@AlaskaAir.com

Harvey Tate British Airways harvey.tat@ba.com

Cunningham, Dede   Continental Airlines dede.cunningham@coair.com

Hosford, D.   Delta Airlines <david.hosford@delta.com>

Schut, Jaap KLM Jaap.Schut@KLM.COM

Michael Harwerth Lufthansa German Airlines micha.harwerth@dlh.de

Scott Speers Qantas Airlines sspeers@qantas.com

TBA South African Airways   

Phil. Ryan   US Airways <Phil.Ryan@USAirways.com>

    

Airport Advisors    

Mark van Gaalen Amsterdam Schiphol Airport <gaalen@schiphol. nl>

John Shepperd   British Airports Authority john_shepperd@baa.com

David Bourgon   McCarran Las Vegas Airport <davidb@mccarran.com>
 JPSC/31 PSC/33 Oct 11 

 Attachment: I 

 Page: 1 of 1 

DCS Messages Working Group (DCSMWG) 

Terms of Reference 

Evolving standards that impact DCS messaging require that DCS experts meet with 

the following terms of reference, which set out the objectives and scope of the DCS 

Message Working Group (DCSMWG). 

The Working Group will: 

• review, amend, and synchronize DCS messages in Recommended Practices 

1707-1719d with the work in other, associated IATA passenger and baggage 

working groups, such as the Reservations Committee and the Joint ATA/IATA 

Passenger Ticketing Committee; 

• monitor and support industry security related activities to include APIS 

requirements and AVSEC/WG; 

• continue to refine and update the documentation of DCS messages in 

Recommended Practices 1707-1719d to fully utilize the DCS Message 

Dictionary and Message Directory documented in Recommended Practices 

1707, 1707a and 1707b; 

• continue to review the editorial process of the DCS messages and continually 

edit them for precision; 

• seek expanded airline participation in the DCSMWG by experts in all 

applicable channels; 

• report their progress to the Airport Services Committee (ASC) once a year 

and seek approval of their work for subsequent submission to each year’s 

PSC. 
 JPSC/31 PSC/33 Oct 11 

 Attachment: J 

 Page: 1 of 1 

Multi-channel Merchandise Sales and Delivery Task Force” (MMSDTF) 

Terms of Reference 

A new task force is established by the Passenger Services Conference (PSC). It is named 

the “IATA Multi-channel Merchandise Sales and Delivery Task Force” (MMSDTF). The 

objectives are to: 

1. Identify the business requirements for making sales of airline products and services 

(defined as “merchandise”) from multiple sources, such as agents, kiosks, internet, 

data devices, etc. 

2. Create standards that facilitate the sales of merchandise by a carrier’s own 

representatives and by third-party sales channels, such as brokers or third-party 

ground handlers. 

3. Consider functionality for product availability displays and product pricing. 

4. Consider product sales and delivery for the host carrier and interline partners. 

5. Create standards that facilitate the delivery of merchandise to all appropriate venues, 

including departure or arrival airports, in-flight, home delivery, or electronic fulfillment. 

6. Consider procedures for sales with immediate delivery and those that have later 

delivery. 

7. Consider procedures for sales and delivery that are flight-related (delivery on-board) 

and those that are not flight-related (delivery independent of a flight). 

8. Create standards for proof of purchase and for proof of delivery. 

9. Create standards for failure of delivery (including irregular operations), with a process 

for refund, subsequent re-use, re-booking or compensation. 

10. Create or modify standards for merchandizing lists (such as PNL/ADL, catering lists, 

store room, in-flight manifests) to advise appropriate offices/personnel for timely 

merchandise delivery and inventory control. 

11. Utilize available communications modes (such as XML, EDIFACT, and teletype) with 

the EMD source-application, appropriate for each functional scenario in sales, 

delivery and reporting. 

12. Utilize the industry’s structure for EMD (Electronic Miscellaneous Documents) as a 

sales and revenue record. 

13. Utilize the EMD as a tracking record for status and usage, such as ‘used, refunded, 

or expired’. 

14. Be mindful of new and emerging technologies and devices that can be utilized to 

make sales of airline merchandise. 

An invitation to participate in the MMSDTF shall be extended to cross-disciplinary personnel 

from airlines and Partner Companies who are experts in every aspect of airline 

merchandizing, sales and delivery, including: 

1. Departure control 

2. Revenue management and accounting 

3. Product marketing 

4. EMD source-application (such as RES) 

5. Airport operations 

The MMSDTF directs the business practices and general execution of airline merchandizing. 

The MMSDTF liaises with other, related working groups in the execution of new or amended 

standards and practices. Meetings take place at least twice a year, and more frequently, if 

needed. The group develops recommendations in the form of amended or new Resolutions 

and Recommended Practices. The MMSDTF reports directly to the Passenger Services 

Conference. 
 JPSC/31 PSC/33 Oct 11 

 Attachment: K 

 Page: 1 of 1 

TICKETING COMMITTEE (PFPC) MEMBERSHIP 

Airline 

Traffic 

Conference 

Area 

Year Term of Office Expires 

at Conclusion of Passenger 

Services Conference: 

 

Air Canada 1 2014 

Air France 2 2014 

All Nippon Airlines 3 2014 

American Airlines 1 2014 

British Airways 2 2013 

Continental 1 2014 

Delta Air Lines 1 2012* 

Egyptair 2 2013 

El Al 2 2014 

Emirates 2 2013 

Japan Airlines 3 2012* 

KLM 2 2013 

LAN 1 2012* 

Lufthansa 2 2013 

SAS 2 2012* 

South African Airways 2 2014 

United Airlines 1 2014 

US Airways 1 2013 

 

* Expires at the conclusion of PSC 2012 
Name of Project 1 
(JPSC 2011 Attachment M)

Expert Advisory T

Force

Advancing IATA Messaging sta

the passenger services a
Objectives and methodology

Ê Objectives

Ê Determine the industry requirements, drivers and barriers 

standardization activities, and recommend the scope and needed and the priorities for their development 

Ê technology, process, how deep, maintaining messag

objects, airline or IT vendor driven development, r

ela

standards organizations..

Ê Methodology

Ê IATA staff to write a white paper highlighting key question

industry approach to addressing them, the white paper w

an industry survey on key topics.

Ê The Task Force will review the white paper and, taking in

infor

mation gathered during the survey, r

ecommend actio
Expected timelines

2011

JPSC

Ex Expert vie pert vie

wwss

Recomme Recommendati ndations ons

WWhhite paper ite paper 

N

ame of Project

3 

09/11 09/11 10/11 10/11 11/11 11/11 12/11 12/11 01/12 01/12 02/12 02/12 03/12 03/12 04/12 04/12 05/12 05/12 06/12 06/12 07/12 07/12 

Expert 

Advisory TF

Publicity&

communications

Recruitment Recruitment Industr Industryy surv surveeyy

FFoorm

rm

Announce

survey

Meeting 1

Meeting 2

Standards 

development
Membership and skillsets

Ê 5 airlines

Ê Traditional network carrierÊ LCCÊ Asian (booming market) carrier

Ê 2 IT suppliers

Ê Legacy providerÊ Substantial but newcomer with no 

legacy

Ê 1-2 airportsÊ 1-2 standards experts 

Ê Internet/web technology, Ê Industry standar

d

s

Ê Airframer?

Ê Airline distributÊ Airline operatio

slots, ) 

Ê Airport operatioÊ Legacy systemÊ Large scale Ê Standards devÊ Internet/web teÊ Industry standaÊ SESAR and N

Architecture

Ê Corporate IT AÊ Industry standa

O

PENTRAVEL

Ê Aircraft commu
 JPSC/31 PSC/33 Oct 11 

 Attachment: N 

 Page: 1 of 1 

Schedules Information Standards Committee (SISC) 

Terms of Reference 

The Schedules Information Standards Committee (SISC) is established by the IATA 

Passenger Services Conference (PSC) with the following terms of reference: 

• Develop and maintain a set of common standards for the exchange of schedule 

data, including industry standard code sets for a variety of schedule related data 

elements; 

• Review and propose amendments to SSIM Appendix A (ATA/IATA Aircraft Types); 

Appendix D (Passenger Terminal Indicators); Appendix F (UTC — Local Time 

Comparisons) and Appendix I (Region Codes); 

• Disseminate and encourage the use of common schedule data handling 

procedures and standard formats for the exchange of schedule information as 

published in the Standard Schedules Information Manual (SSIM); 

• Liaise with other IATA committees and working groups, in particular the Schedule 

Policy Working Group (SPWG) as well as other organizations as appropriate to 

meet changing industry requirements and to further the objectives of the SISC; 

• The Joint Schedules Advisory Group (JSAG) will ensure formal liaison between the 

airport coordinator community and SISC; 

• SISC will provide an annual report to the PSC comprising all proposed and 

adopted changes to SSIM. In addition a written report of the work of SISC will be 

made to the Heads of Delegation Meeting of the regularly scheduled IATA 

Schedules Conferences; 

• The PSC will be responsible for final endorsement of proposed changes to SSIM; 

• Participation is by schedules specialists from IATA airlines and industry experts in 

the IATA Strategic Partnership programme; 

• A rapporteur will be established to provide liaison for non-IATA airlines 

participating in the Schedules Conference; 

Airport Coordinators participating in the IATA Schedule Conference are invited to 

participate in SISC. 
 JPSC/31 PSC/33 Oct 11 

 Attachment: O 

 Page: 1 of 3 

Executive Summary 

FPWG – Fraud Prevention Working Group 

Minutes of 21 September 2011 Conference Call 

Theme ‘Redefining and Reengineering IATA’s Fraud Prevention Activity’ 

Member Participants: UA/CO, BA, LH, NZ, AA, 

Partners: ARC 

IATA Staff from Passenger Interline Standards, Passenger Agency, Risk Management, 

Credit Card Services and Cargo. 

Objective: Reason for the Call 

It has been a considerable time since the FPWG had the opportunity to discuss industry 

fraud issues and this has not gone unnoticed by our Members. Many have felt frustrated 

by the lack of coordinated attention to fraud prevention activities at a global level. Since 

the advent of 100% ET and the closure of the TICKETS database, IATA activity has 

focused mainly on credit card fraud prevention which has been handled by IATA Card 

Services. 

IATA’s senior management has requested that we take a fresh look at redefining and 

re-energizing IATA's role in fraud prevention. Ultimately we may conclude that IATA's 

role should sit more within our financial services area rather than the passenger 

services area. 

Main Outcome & Conclusions 

Ò There has been no full time employee looking after IATA’s fraud prevention activity 

for a number of years 

Ò Perception in IATA that since 100% Electronic Ticketing fraud would go away which 

is not true 

Ò IATA is dealing with the credit card fraud issue quite well as there are resources for 

that and IATA has also encouraged use of the Perseuss system for credit card fraud 

information sharing 

Ò So much more fraud that is not being dealt with which has become diverse and has 

many guises and methods of operation. 
 JPSC/31 PSC/33 Oct 11 

 Attachment: O 

 Page: 2 

Ò Areas of fraud that are concerning Members at the moment are; 

o Internet based crime and e-commerce 

o Fake travel agency websites that purport to sell travel (often against cash 

payment) 

o Solicitation email scams (asking for tickets, payment of fake invoices) 

o Internal employee fraud 

o Frequent Flyer abuse and brokering schemes 

o Agency fare abuse 

o Cargo false claims, invoicing and air way bill tampering (falsifying weights) 

o Falsified or bogus baggage claims 

Ò Feeling that the fraud prevention community is isolating itself and has no natural 

place to communicate and share issues on global basis 

Ò Often internally different aspects of fraud are dealt with in the relevant business 

areas if at all. 

Ò No information exchange, extranets out of date, self-defeating since there is a 

feeling that no one is posting anything so no one looks at it 

Ò Biggest tool to prevent fraud is communication, alerts and information sharing and 

whilst Members have done things on regional basis, there has been no coordinated 

activity at the global level and Members felt they have largely been left on their own. 

Ò Members felt it would be good as a base step to document different types of fraud 

and break them down into separate distinct pieces, then determine who owns the 

issue to be resolved. 

Ò In the USA ARC reported they had seen a reduction in hacking and credit card fraud 

in favor of accessing the ticketing systems and taking cash payments. They had 

worked and continue to work with ticketing systems to prevent abuse. They also 

have their forums to discuss ‘fraud from everywhere’ 

Conclusion 

It is evident that there are many different flavors and guises of fraud with many different 

modes of operation. For some fraud, such as in the credit card area, there is clearly 

some strong activity but in other types of fraud there are different levels of expertise 

required. For example having the knowledge to know how to go to banks, internet 

service providers, and email companies to get them to close the fraudsters down. 
 JPSC/31 PSC/33 Oct 11 

 Attachment: O 

 Page: 3 

Profile of Future Activity 

Ò Members acknowledged that fraud prevention does not sit well anywhere within the 

IATA governance structure but felt that finance was possibly one area where it would 

be best placed, particularly if there was to be a wider remit including cargo and 

baggage. 

Ò IATA was asked if there was something that could be set up specifically to deal with 

frequent flyer brokerage fraud. There had been a sub group dealing with these 

issues in the past. 

Ò Fraud prevention needs to be coordinated with a global group and not just on 

regional basis. Globally the fraud prevention community needs to get together to 

discuss issues such as those raised in this paper 

Ò Someone needs to take the lead in coordination and facilitation. It is IATA Member 

carriers that are being hurt and as such IATA should not think they cannot do 

anything because it is not affecting an IATA agent. As it is IATA’s Members that are 

being affected it is in IATA’s remit to coordinate these activities. 

Ò Create a forum for the exchange of ideas and experiences and to look at how this 

whole topic can be divided up into appropriate pieces which can then be allocated 

within the IATA framework. 

Ò Making a list of all these areas of fraud will give an overall scope and it will soon be 

clear which are the big topics (we have one of them with credit card), that way they 

will not get mixed up with other types of fraud 

Ò A dedicated resource should be assigned to kick start the re-engineering process. 

Up to now there has been no coordination and Members have been left on their 

own. 

Ò Profile of any individual tasked with fraud prevention should be someone who has a 

fraud prevention background. They should have the skills to quantify the fraud and 

reach out to the different areas which then helps with defining what resources are 

needed. 

Ò The business case for resources can be developed by looking at recent surveys that 

have been published. 

Conclusion 

Members valued the start of this consultation process, in contrast to previous attempts 

at re-engineering. Fraud is varied and evolving and IATA needs to look at positioning 

itself to coordinate and lead this activity with a dedicated resource and look at 

positioning this in the appropriate business area. 
 JPSC/31 PSC/33 Oct 11 

 Attachment: AA 

 Page: 1 of 1 

IATA Reservations Committee Membership 

Airline TC area Year Term of Office Expires 

 

Air France (AF) 2 2013 

 

Air Canada 1 2013 

All Nippon Airways (NH) 3 2012 

British Airways (BA) 2 2014 

Delta Air Lines (DL) 1 2012 

Egyptair (MS) 2 2014

El Al (LY) 2 2012 

Emirates (EK) 2 2014 

Etihad (EY) 2 2014 

Finnair (AY) 2 2012 

Iberia (IB) 2 2014 

Japan Airlines (JL) 3 2012 

KLM (KL) 2 2012 

Lufthansa (LH) 2 2013 

Scandinavian Airlines System (SK) 2 2012 

South African Airways 2 2014 

United Airlines (UA) 1 2012 

US Airways (US) 1 2014
 JPSC/31 PSC/33 Oct 11 

 Attachment: BB  Page: 1 of 1 

Topic Progress Next Steps Action b

1 AIRIMP Audit and Clean-up Ongoing item 

Phase 1 is complete 

Future RESWG and ResCom meetings as appropriate. Suggestions: email to IATA. 

All 

2 TSA Secure Flight Program Add passives section to AIRIMP KL 3 Fixed Request Fixed 

Reply/Cancel as Free Text 

RESWG/14 agenda item 7 Secreta

4 SSRs Matrix Matrix updated to identify exceptions and 

new section 3.24 established 

More radical re-arranging of verbiage within AIRIMP to be studied. Draft has been developed by Amadeus 

SecretaAmadeu

5 Additional services – 

increase number in party 

Submitted to RESWG/14 by Amadeus Comments to be sent to Amadeus Amadeu

6 Bilateral SSRs Item finalized at RESWG/16 Secreta7 Credit Card as FOID Item finalized at RESWG/16 Secreta8 Service PNR Message RESWG/15 agenda item 12 was agreed Secreta9 Editorial Repairs to AIRIMP Item finalized at RESWG/16 Secreta10 Self Service Flight 

Rebooking for Involuntary Rerouting 

RESWG/15 agenda item 14. The Fast Travel Group is developing a RP for Self Service Flight Rebooking for Involuntary Rerouting and requested input from the Reservations Working Group 

SITA to liaise with the 2 groups to assist in the 

development of the RP 

SITA 

11 Explanation in AIRIMP of 

receiving KK reply messages on SSRs for which no previous request could have been sent 

AmadeuKLM 

12 Additional Services Changes to 3.21. to allow HS to be sent 

without a previously received KD 

Secreta

13 Fixed arm rest characteristic 

– Seat maps and requests 

ResCom/23 developed the LY proposal Find out what LY wants to do and find out what 

code can be used. Can consider mail vote. 

El Al 

14 Re-write 3.19 – advance 

boarding passes 

BA/1A 

15 Add Military ID (M) Check with ICAO to see if this code is 

planned for ICAO 9303 

IATA to check with ICAO Secreta
 JPSC/31 PSC/33 Oct 11 

 Attachment: CC 

 Page: 1 of 6 

2.11.6.7 SSR Matrix and ATA 105.175 

SSR Code Action Code Reply Automated 

Format 

Free Text in 

Request 

Free Text in 

Reply/Cancel 

Reference 

ADMD Not permitted Not permitted Not permitted Mandatory 

See 3.1.23 

Not permitted See 3.1.23 

ADPI Mandatory Not Permitted Not Permitted Mandatory Not 

Applicable 

See 3.13.4 

ADTK Not permitted Not permitted Not permitted Mandatory Not permitted Bilateral 

See3.1.14 

AOXY (4) Mandatory Mandatory Mandatory Optional Optional Bilateral See 

3.7.7 

ASVC Mandatory Mandatory Mandatory Mandatory 

Fixed 

Request 

Mandatory 

Fixed 

Reply/Cancel 

Bilateral See 

2.11.6.6 and 3.21 

ASVX Not permitted Not permitted Not permitted Not permitted Not permitted See 9 

AUTK Mandatory Required Not permitted Not permitted Optional Bilateral See 

3.11 

AVIH Mandatory Mandatory Mandatory Mandatory Optional 

AVML (1) Mandatory Mandatory Mandatory Not permitted Not permitted

BBML (1) Mandatory Mandatory Mandatory Not permitted Not permitted 

BIKE Mandatory Mandatory Mandatory Optional Optional 

BLML (1) Mandatory Mandatory Mandatory Not permitted Not permitted 

BLND Mandatory Mandatory Mandatory Optional Optional 

BSCT Mandatory Mandatory Mandatory Not permitted Not permitted 

BULK Mandatory Mandatory Mandatory Mandatory Optional 

CBBG Mandatory Mandatory Mandatory Mandatory Optional

CHLD Mandatory Optional Not permitted Not permitted Optional See 3.17 

CHML Mandatory Mandatory Mandatory Optional Optional 

CKIN Optional Optional Optional Mandatory Optional See 1.5.5.1 and 

1.5.5.2 and 

3.24.1

CLID Mandatory Optional Not permitted Not permitted Optional Bilateral See 

3.8.3 

COUR Mandatory Optional Mandatory Optional Optional 

CRUZ Mandatory Optional Mandatory Optional Optional Bilateral See 

2.11.6.5 3.24.4

DBML Mandatory Mandatory Mandatory Not permitted Not permitted 

DCRW Mandatory Optional Mandatory Optional Optional Bilateral See 

3.22.3

DEAF Mandatory Mandatory Mandatory Optional Optional 

DEPA Mandatory Mandatory Mandatory Optional Optional 

DEPU Mandatory Mandatory Mandatory Optional Optional

DOCA Mandatory Not permitted Optional Not permitted Not permitted See 3.13.3 

DOCO Mandatory Not permitted Optional Not permitted Not permitted See 3.13.2 

DOCS Mandatory Optional Optional Not permitted Not permitted See 3.13.1

DPNA Mandatory Mandatory Mandatory Mandatory Optional
 JPSC/31 PSC/33 Oct 11 

 Attachment: CC 

 Page: 2 

EPAY Mandatory Mandatory Not permitted Optional Optional Bilateral See 

3.14 

ESAN Mandatory Mandatory Mandatory Mandatory Optional Bilateral 

ETLP Not permitted Not permitted Not permitted Not permitted Not permitted Reserved for 

DCS RP1707b 

3.24.2 RP1708 

2.12.6.9 

RP1719d 3.1

EXST Mandatory Mandatory Mandatory Mandatory Optional 

FOID Mandatory Not Permitted Not Permitted Mandatory Not permitted Bilateral See 

3.10 

FPML (1) Mandatory Mandatory Mandatory Not permitted Not permitted

FQTR (3) Mandatory Optional Not permitted Optional Optional Bilateral See 

3.8.1 – Option 1 

FQTR (3) Mandatory Optional Mandatory Optional Optional Bilateral See 

3.8.2 – Option 2 

FQTS (3) Mandatory Optional Not permitted Optional Optional Bilateral See 

3.8.1 – Option 1 

FQTS (3) Mandatory Optional Mandatory Optional Optional Bilateral See 

3.8.2 – Option 2

FQTU (3) Mandatory Optional Not permitted Optional Optional Bilateral See 

3.8.1 – Option 1 

FQTU (3) Mandatory Optional Mandatory Optional Optional Bilateral See 

3.8.2 – Option 2 

FQTV (3) Mandatory Optional Not permitted Optional Optional Bilateral See 

3.8.1 – Option 1 

FQTV (3) Mandatory Optional Mandatory Optional Optional Bilateral See 

3.8.2 – Option 2

FRAG Mandatory Mandatory Mandatory Mandatory Mandatory 

FRAV Mandatory Not permitted Not permitted Not permitted Not permitted See 3.1.8, 3.2.4 

and 3.2.5 

GFML (1) Mandatory Mandatory Mandatory Not permitted Not permitted

GPST Mandatory Mandatory Mandatory Optional Optional See 3.1.9 and 

3.19.12 

GRPF Optional Optional Not permitted Optional Optional See 1.5 

GRPK Mandatory Optional Mandatory Mandatory Optional Bilateral 

GRPS Optional Optional Optional Optional Optional See 1.5, 3.2.8, 

3.5 and 3.6

HNML Mandatory Mandatory Mandatory Not permitted Not permitted 

INFT Mandatory Mandatory Mandatory Mandatory Optional See 2.6.15 and 

3.16 

IROP Mandatory Not permitted Not permitted Optional Not permitted Bilateral See 

3.18

KSML Mandatory Mandatory Mandatory Not permitted Not permitted 

LANG Mandatory Optional Mandatory Mandatory Optional See 3.24.2

LCML Mandatory Mandatory Mandatory Not permitted Not permitted 

LFML (1) Mandatory Mandatory Mandatory Not permitted Not permitted 

LSML (1) Mandatory Mandatory Mandatory Not permitted Not permitted 

MAAS Mandatory Optional Mandatory Mandatory Optional

MCOA Mandatory Not permitted Optional Mandatory Not permitted Bilateral 

MEDA Optional Optional Not permitted Mandatory Optional See 3.7.7 

MEQT Mandatory Mandatory Mandatory Mandatory Optional Bilateral See 

2.11.6.3 and 

2.11.6.4

MOML Mandatory Mandatory Mandatory Not permitted Not permitted 
 JPSC/31 PSC/33 Oct 11 

 Attachment: CC 

 Page: 3 

NAME Not permitted Not permitted Not permitted Mandatory Not permitted See 3.5.2 and 

3.6.3

NLML Mandatory Mandatory Mandatory Not permitted Not permitted 

NOML Mandatory Optional Mandatory Not permitted Optional See 3.1.22

NRSB Mandatory Not permitted Not permitted Not permitted Not permitted Bilateral, See 

3.22.1

NSSA Mandatory Mandatory Mandatory Not permitted Optional 

NSSB Mandatory Mandatory Mandatory Not permitted Optional

NSSR Mandatory Mandatory Mandatory Optional Optional Bilateral 

NSST Mandatory Mandatory Mandatory Optional Optional 

NSSW Mandatory Mandatory Mandatory Not permitted Optional 

OTHS Optional Optional Optional Mandatory Optional See 2.11.6.2 

3.24.2

PCTC Mandatory Not permitted Not permitted Optional Not permitted See 3.20 

PETC Mandatory Mandatory Mandatory Mandatory Optional 

POXY (4) Mandatory Mandatory Mandatory Optional Optional Bilateral See 

3.7.7 

PPOC Mandatory Mandatory Mandatory Optional Optional Bilateral 

RLOC Not permitted Not permitted Optional Mandatory Not permitted Bilateral See 

8.10 or 8.12

RQST Mandatory Mandatory Mandatory Mandatory Optional 

RVML (1) Mandatory Mandatory Mandatory Not permitted Not permitted 

SEAT Mandatory Mandatory Mandatory Mandatory Mandatory See 3.19 

SEMN Mandatory Optional Mandatory Mandatory Optional 

SFML Mandatory Mandatory Mandatory Not permitted Not permitted 

SLPR Mandatory Mandatory Mandatory Not permitted Not permitted 

SMSA Mandatory Mandatory Mandatory Not permitted Optional 

SMSB Mandatory Mandatory Mandatory Not permitted Optional

SMSR Mandatory Mandatory Mandatory Optional Optional Bilateral

SMST Mandatory Mandatory Mandatory Optional Optional 

SMSW Mandatory Mandatory Mandatory Not permitted Optional 

SPEQ Mandatory Mandatory Mandatory Mandatory Optional 

SPML (1) Mandatory Mandatory Mandatory Mandatory Optional 

STCR Mandatory Mandatory Mandatory Not permitted Optional

SVAN Mandatory Mandatory Mandatory Mandatory Optional Bilateral 

TKNA (2) Mandatory Not permitted Mandatory Mandatory Not permitted Bilateral See 

3.1.15, 3.1.19 

and 8.12 

TKNC (2) Mandatory Not permitted Mandatory Mandatory Not permitted Bilateral See 

3.1.19 and 8.12 

TKNE Mandatory Not permitted Mandatory Mandatory Not permitted Bilateral See 

3.1.16 and 3.1.17 

TKNM Mandatory Not permitted Mandatory Mandatory Not permitted Bilateral See 

3.1.15 

TKNR Mandatory Not permitted Mandatory Mandatory Not permitted See 3.1.15 and 

3.1.19.5 

TKNX Not permitted Not permitted Not permitted Not permitted Not permitted See 9 

TKTL Mandatory Not permitted Not permitted Not permitted Not permitted See 3.1.11 and 

3.1.12 

TLAC Not permitted Not permitted Not permitted Optional Not permitted See 3.12

TWOV Mandatory Optional Mandatory Optional Optional 

UMNR Mandatory Mandatory Mandatory Mandatory Optional See 2.6.20
 JPSC/31 PSC/33 Oct 11 

 Attachment: CC 

 Page: 4 

 

VGML (1) Mandatory Mandatory Mandatory Not permitted Not permitted 

VJML Mandatory Mandatory Mandatory Not permitted Not permitted 

VLML (1) Mandatory Mandatory Mandatory Not permitted Not permitted 

VOML Mandatory Mandatory Mandatory Not permitted Not permitted

WCBD Mandatory Mandatory Mandatory Optional Optional Bilateral 

WCBW Mandatory Mandatory Mandatory Optional Optional Bilateral

WCHC Mandatory Mandatory Mandatory Optional Optional 

WCHR Mandatory Mandatory Mandatory Optional Optional 

WCHS Mandatory Mandatory Mandatory Optional Optional

WCLB Mandatory Mandatory Mandatory Optional Optional Bilateral 

WCMP Mandatory Optional Mandatory Optional Optional Bilateral 

WCOB Mandatory Mandatory Mandatory Optional Optional Bilateral 

WEAP Mandatory Mandatory Mandatory Mandatory Optional See 3.1.21

XBAG Mandatory Mandatory Mandatory Mandatory Optional

 

..... 
 JPSC/31 PSC/33 Oct 11 

 Attachment: CC 

 Page: 5 

AIRIMP and SIPP 

3.24 EXCEPTIONAL SSR PROCESSING

3.24.1 Check-in Information

SSR CKIN may follow either the automated format rules (when passenger & segment 

associated) or the following formats may be used:

1. Where all members in the itinerary are requested to provide the service for all 

segments

SSR CKIN YY HK/CHECK TRAVEL DOCUMENTS

As HK is included in the request, the member does not need to reply.

2. Targeting only 1 member but for all segments pertaining to that member

 

 SSR CKIN BA CHECK TRAVEL DOCUMENTS 

As no action/status code was included in the element, no reply can be sent 

from the member.

Please also refer to 1.5.5.1/2 for details on cross referencing group bookings with 

SSR CKIN.

3.24.2 Provide other information to the member or the booking source

SSR OTHS may either follow the automated format rules or may use one of the 

following formats:

1. Sending free text information to all members in the itinerary

 SSR OTHS YY PASSENGER REFUSED TO PROVIDE PASSPORT DATA

As no action/status code is included in the message, no reply can be sent 

from the member.
 JPSC/31 PSC/33 Oct 11 

 Attachment: CC 

 Page: 6 

2. Targeting all segments for one member:

 SSR OTHS BA NN1 PASSENGER ESCORT

Should the request pertain to one or more (but not all) passengers in the 

itinerary, the following format would be used:

 SSR OTHS BA NN1 PASSENGER ESCORT-1MANSART/PASCALE MRS

 As the request includes an action code, the member should reply accordingly 

 SSR OTHS BA KK1 PASSENGER ESCORT

 Or

 SSR OTHS BA NO1 PASSENGER ESCORT/INVALID REQUEST

3.24.3 Languages spoken by the passenger

SSR LANG may either follow the automated format rules or may use the following 

format: 

SSR LANG UA HK/MIAJFK0026Y29OCT.PSGR SPEAKS ZULU ONLY

Should the request pertain to one or more (but not all) passengers in the itinerary, the 

following format would be used:

SSR LANG UA HK/MIAJFK0026Y29OCT-1MEEKS/JOHN MR.PSGR SPEAKS ZULU ONLY

In all cases, the number in party is replaced by an oblique.

3.24.4 Cruise Passenger

SSR CRUZ uses the following format:

SSR CRUZ DL HK/ATLMIA1125Y09MAY.CARNIVAL CRUISE

As the SSR is for all passengers in the itinerary, the number in party is replaced by 

the oblique character (/). 
 JPSC/31 PSC/33 Oct 11 

 Attachment: DD 

 Page: 1 of 3 

2.10.6 Additional Services: Non-Segment-Associated 

Requests and replies for additional services (non-segment associated) will use 

auxiliary service element SVC. Additionally, auxiliary service element SVC can be 

used to advise the member that an EMD has been issued for a service without 

having sent a previous request. 

2.10.6.1 Element Construction — Request 

Components Number 

and Type 

of 

Characters

Examples 

(a) Service Identifier 3 a SVC 

(b) Airline designator to whom the service is 

requested (3 character codes are preceded 

with an oblique) 

2 an or 3 a BA 

(c) Action code Refer to 3.21.1.2 2 a NN 

(d) Number of services requested 1 – 3 n 1 

(e) Primary Location Code 3 a MAD 

(f) Secondary Location Code (Optional) 3 a BIO

(See Chapter 3 

Additional Services –

Non-SegmentAssociated-Services)

(f)(g) Service date 2 n 3 a 17OCT 

(g)(h) Reason for Issuance Code (RFIC) (1) (2) 1 an /H 

(h)(i) Reason for Issuance sub code (RFISC) (2) 3 – 15 an /E23 

(i)(j) Commercial Name of Service (2) 1 – 30 an /LOUNGE ACCESS 

(j)(k) Name (preceded by NM-) Refer to name 

element paragraph 2.11.6.1(f) (2)

 /NM1BIGGIN/ANDREW 

(K)(l) EMD number including coupon number (if 

applicable) (2)

As defined /0061234567890C1 
 JPSC/31 PSC/33 Oct 11 

 Attachment: DD 

 Page: 2 

2.10.6.2 Construction — Reply

Components Number 

and Type 

of 

Characters

Examples 

(a) Service Identifier 3 a SVC 

(b) Airline designator 2 an or 3 a BA 

(c) Reply code Refer to 3.21.1.2 2 a KD 

(d) Number of services 1 – 3 n 1 

(e) Primary Location Code 3 a MAD 

(f) Secondary Location Code (Optional) 3 a BIO

(See Chapter 3 

Additional Services –

Non-SegmentAssociated-Services)

(f)(g) Service date 2 n 3 a 17OCT 

(g)(h) Reason for Issuance Code (RFIC) (1) (2) 1 an /H 

(h)(i) Reason for Issuance sub code (RFISC) (2) 3 – 15 an /E23 

(i)(j) Commercial Name of Service (2) 1 – 30 an /LOUNGE ACCESS 

(j)(k) Name (preceded by NM-) Refer to name 

element paragraph 2.11.6.1(f) (2)

 /NM1BIGGIN/ANDREW 

(K)(l) EMD number including coupon number (if 

applicable) (2)

As defined /0061234567890C1 

(l)(m) Free Text (preceded by a period) 1 – 90 an .LOUNGE AT GATE 

43 
 JPSC/31 PSC/33 Oct 11 

 Attachment: DD 

 Page: 3 

AIRIMP 3.21.2 (new examples) 

Example 5 — Message from booking source to Member requesting non-flight related 

services for two passengers, with two locations codes in the SVC element. 

MUCRM1A 

.HDQRM1P 

HDQ1P RT7D9K/8F6Q/38278505/ROM/1P/T/IT 

1MULLER/MIKEMR 1EDWARDS/PATTYMRS 

AF6107 J 10DEC TLSORY HK1 

ARNK 

AF0276 J 10DEC CDGNRT HK1 

AF0275 J 20DEC NRTCDG HK1 

ARNK 

AF6156 J 20DEC ORYTLS HK1 

SVC AF NN1 ORYCDG 10DEC/B/0BR/TRANSFER/NM-1MULLER/MIKEMR 

SVC AF NN1 CDGORY 20DEC/B/0BR/TRANSFER/NM-1EDWARDS/PATTYMRS 

Example 5(a) — Message from the Member to the booking source confirming the 

non-flight related services for one passenger with KD for one service as an EMD is 

required and with a KK for the other service as no EMD is required. Free text with 

additional information is included in the reply. 

HDQRM1P 

.MUCRM1A 

HDQ1P RT7D9K 

1MULLER/MIKEMR 1EDWARDS/PATTYMRS 

AF6107 J 10DEC TLSORY HK1 

ARNK 

AF0276 J 10DEC CDGNRT HK1 

AF0275 J 20DEC NRTCDG HK1 

ARNK 

AF6156 J 20DEC ORYTLS HK1 

SVC AF KD1 ORYCDG 10DEC/B/0BR/TRANSFER/NM-1MULLER/MIKEMR 

SVC AF KK1 CDGORY 20DEC/B/0BR/TRANSFER/NM1EDWARDS/PATTYMRS.COMPLEMENTARY 
 JPSC/31 PSC/33 Oct 11 

 Attachment: EE 

 Page: 1 of 1 

AIRIMP and SIPP 

3.21.1.2 Action/Reply/Advice/Status Codes 

Action codes 

NN – Service Requested 

HS – EMD issued for confirmed service (only to be used following KD)

XX – Service cancelled 
 JPSC/31 PSC/33 Oct 11 

 Attachment: FF 

 Page: 1 of 1 

AIRIMP and SIPP 

3.20 PASSENGER PROVIDED CONTACT INFORMATION 

3.20.1 A passenger provided contact name and telephone number can be sent in an 

SSR as required. SSR PCTC should be used to record the name and telephone 

number of a person other than the passenger to be contacted in the event of an 

emergency. 

 

[...] 

3.20.3 Passenger provided contact name may be an entity (such as a travel agency 

name) or a personal name. The contact should not be a person travelling on the 

covered flight.

... 

3.20.8 When the passenger provided contact has been solicited but the passenger 

refuses to provide one or one is not available, put two slashes after the HK and end 

the element, however passenger name and/or free text fields can be added, if 

needed. 

3.20.9 Examples: 

(a) [...] 

(b) element showing emergency contact

 SSR PCTC AF HK/JOHN BAKER/FR33122334455.TO BE CONTACTED IN CASE

 SSR PCTC AF///OF EMERGENCY

 SSR PCTC BA HK/MARY SMITH/US18433445566-1SMITH/JOHN.TO BE 

 SSR PCTC BA/// CONTACTED IN CASE OF EMERGENCY

(b) (c) element showing passenger provided contact solicited, but not available or 

refused, with free text and/or passenger name 

[...] 
 JPSC/31 PSC/33 Oct 11 

 Attachment: GG 

 Page: 1 of 1 

AIRIMP and SIPP 

7.1.16.2 SSR DOCO CODES 

7.1.16.2.1. Travel Document Type Codes Passenger Other Supplementary 

Information Code

Passenger Visa Visa Number...................................V 

Redress Number....................................................R

Known Traveler Number .........................................K
 JPSC/31 PSC/33 Oct 11 

 Attachment: HH 

 Page: 1 of 1 

AIRIMP and SIPP 

3.1.17.1 Where a Passive Segment Notification Agreement Exists (See 8.10) 

..... 

 TYORMNH 

 . HDQRM1F 240827 

 HDQ1F MSOCKK/8HH6/16311116/TYO/1F/T/JP/JPY 

 1TAMURA/TADASHIMR 

 NH006T21DEC NRTLAX PK1/1705 0945 

 SSR TKNE NH HK1 NRTLAX0006T21DEC.2051761069389C1 

 SSR RLOC NH NRTLAX0006T21DEC.XXFFDD

 

 

 
 JPSC/31 PSC/33 Oct 11 

 Attachment: II 

 Page: 1 of 1 

AIRIMP and SIPP 

8.4.6 Construction of SPR Messages 

The sequence of elements is as follows: 

(a) Address; 

(b) Communications Reference; 

(c) Message Identifier SPR; 

(d) Record Locator of this SPR sender;

(e) (d) Record Locator of the SPN or SPM originator; 

(e) Record Locator of this SPR sender;

(f) Record Locator of the SPN or SPM originator;

(g) Record Locator of this SPR sender;

(h) (f) Name(s); 

(i) (g) Air Segment(s); 

(j) (h) Auxiliary Segment(s); 

(k) (i) SSR(s); 

(l) (j) OSI(s). 
 JPSC/31 PSC/33 Oct 11 

 Attachment: JJ 

 Page: 1 of 2 

AIRIMP and SIPP 

2.11.6.7 SSR Matrix 

SSR 

Code 

Action Code Reply Automated 

Format 

Free Text 

in Request 

Free Text in 

Reply/Cancel 

Reference 

UMNR Mandatory Mandatory Mandatory Mandatory Optional See 2.6.20 

UPGR Mandatory Not permitted Mandatory Optional Not Permitted See 3.8.2.4

Bilateral

 

3.8.2.4 Upgrade Advisory to Partner Airline

Bilateral agreements between airlines may contain provision for SSR UPGR to be 

exchanged between two members together with the cancel/rebook, when one 

member has upgraded a passenger on the other member’s flight. In the bilateral 

agreement between the two members it is stated that the member sending the 

message takes full responsibility of the upgrade. The SSR informs the operating 

member that this is not a regular cancel/rebook and allows for special processing. 

This advisory may be used for any upgrade based on partner agreement.

Example 1 Message illustrating passenger Patell has been upgraded by DL on a 

KL Flight. SSR UPGR included without free text. 

Addressee ........................MUCRM1A

Originator .........................HDQRMDL 021715

Record Locator Sender .......HDQDL HGTHZZ/MSP/15252635/MSP/DL/A/US 

Name Element ..................1PATELL/ROHNAMR

Segment Element..............KL652M30MAR IADAMS XX1

Segment Element..............KL652C30MAR IADAMS LK1/1755 0740/1

Segment Element..............KL651M01APR AMSIAD HK1

Supplementary Element .....SSR UPGR KL HK1 IADAMS0652C30MAR

Example 2Message illustrating passengers Pylka and Mooers have been upgraded by KL 

on a DL Flight. SSR UPGR included with free text.

Addressee ........................HDQRMDL

Originator .........................MUCRM1A 091540

Record Locator Sender .......MUC1A DH87E0/AMSKL0200/6958423/AMS/KL/A/NL

Name Element ..................1PYLKA/BARBARAMRS 1MOOERS/SARAHMRS

Segment Element..............DL0239M30MAR AMSATL XX2

Segment Element..............DL0239C30MAR AMSATL LK2/1020 1410

Segment Element..............DL0238M01APR ATLAMS HK2

Supplementary Element .....SSR UPGR DL HK2 AMSATL0239C30MAR.COMMERCIAL UPGRADE

3.8.2.4 5 Frequent Traveler Accrual – Service Recognition (FQTS) 

....... 
 JPSC/31 PSC/33 Oct 11 

 Attachment: JJ 

 Page: 2 

7.1.8.2 Special Service Requirement (SSR) Codes 

Unaccompanied Minor UMNR 

Upgrade UPGR

7.2 Passenger Reservations Codes and Abbreviations (Decoding) 

 

UPD Request to Member for an update of block parameters 

UPGR Upgrade

Secretary note: add SSR to PNL/ADL in RP 1708 
 JPSC/31 PSC/33 Oct 11 

 Attachment: KK 

 Page: 1 of 1 

AIRIMP and SIPP 

3.13.2.4 Examples 

(a) Non-Automated Format (1) 

A passenger requiring two Visa documents for this PNR:

SSR DOCO BA HK1//V/9891404/LONDON/14MAR03/USA-1STEVENSON/JOHNMR 

SSR DOCO BA HK1//V/586D4FF/WASHINGTON/23AUG01/GBR-1STEVENSON/JOHNMR

SSR DOCO BA HK1//V/586D4FF/GB EMBASSY WASHINGTON/23AUG01/GBR-1STEVENSON/JOHNMR

..... 
 JPSC/31 PSC/33 Oct 11 

 Attachment: LL 

 Page: 1 of 1 

AIRIMP and SIPP 

3.13.1.1 Definitions 

The Following Documents have been defined by ICAO 9303 as travel documents:

(editor: add in alphabetical sequence) 

Military ID......................................................................................M 

7.1.16.1.1 Travel Document Type Codes 

(editor: add in alphabetical sequence) 

Military ID.......................................................................................M 

7.2. PASSENGER RESERVATIONS CODES AND ABBREVIATIONS (Decoding) 

(editor: add in alphabetical sequence) 

M..........................................................................................Military ID 
 JPSC/31 PSC/33 Oct 11 

 Attachment: MM 

 Page: 1 of 1 

AIRIMP and SIPP 

3.13.1.5 Irregular Names

(a) Single-name passenger

In cases where the passenger has a single name, record that in the SSR DOCS as the 

“Travel Document Surname” and insert FNU (first name unknown) in the “Travel 

Document First Given Name” field.

(b) Single-character name

The “Travel Document Surname” and/or the “Travel Document First Given Name” can 

be a single character.

(c) Hyphenated names

In cases where the passenger has a hyphenated name, replace the hyphen with a 

space in the “Travel Document Surname” and/or the “Travel Document First Given 

Name”. 

(d) Names with apostrophe

In cases where the passenger has an apostrophe in their name, delete the apostrophe 

when recording the name in the “Travel Document Surname” and/or the “Travel 

Document First Given Name”.
 JPSC/31 PSC/33 Oct 11 

 Attachment: NN 

 Page: 1 of 1 

AIRIMP and SIPP 

3.13.1 API — Passenger Travel Document Information 

The elements Travel Document Surname, Travel Document First Given Name and 

Travel Document Second Given Name must match the surname, first given name 

and second given name (if applicable) as shown in the official travel document. If the 

name is from the Machine Readable Zone (MRZ) of an official document, e.g. 

passport, the chevron character (<) in the MRZ should be interpreted as a space 

character. A double chevron (<<) should be interpreted as a change of field, e.g. 

from surname to given name. Spaces in the name fields of the SSR DOCS should 

not be removed and should be transmitted in messages to business partners and 

governments.
 JPSC/31 PSC/33 Oct 11 

 Attachment: OO 

 Page: 1 of 4 

AIRIMP and SIPP (Secretary note: this section is all new)

3.13.4 API – Passive Segments 

3.13.4.1 Where a passive segment notification agreement exists (See 8.10) 

SSR DOCS/DOCA/DOCO may be transmitted for Passive segments. If these SSR’s are sent 

with the initial transmission of PK/PL segment(s), the Action Code of the segment(s) will be 

PK or PL. If these SSR’s are sent after the initial transmission of PK/PL segments, the Action 

Code for these same segment(s) will be PU. If the Record Locator of the receiving system is 

known, it should be included as an OSI or SSR item, not in the Secondary Record Locator 

Line (See 2.5.2). 

Example 1 — Message illustrating SSR DOCS (non-automated format) sent as the initial 

transmission of PK segment for the total party, record locator unknown: 

Addressee ................................. ATLRMDL

Sender....................................... .HDQRM1S 240827

Record Locator Sender............. HDQ1S MSOCKK/8HH6/16311116/LAX/1S/T/US/USD

Name Element .......................... 1TAMURA/TADASHIMR

Segment Element...................... DL2756T01NOV ATLJFK PK1/1705 0945

Supplementary Element............ SSR DOCS DL HK1/////01APR80/M//TAMURA/TADASHI/TAKEHIKO

Example 2 — Message illustrating SSR DOCS (automated format) sent as the initial 

transmission of PL segment for two passengers within the party and the record 

locator using an SSR item: 

Addressee ................................. ATLRMDL

Sender....................................... .HDQRM1S 240827

Record Locator Sender............. HDQ1S MSOCKK/8HH6/16311116/LAX/1S/T/US/USD

Name Element .......................... 2VALVERDE/JOSEMR/ALBERTOMR 1SANTOS/MARIAMRS

Segment Element...................... DL2756T01NOV ATLJFK PL3/1705 0945

Supplementary Element............ SSR DOCS DL HK1 

ATLJFK2756T01NOV/P/SIN/S78654087/SIN/12JUL64/M/23OCT14 

Supplementary Element............ SSR DOCS DL ////VALVERDE/JOSE/JESUS-1VALVERDE/JOSEMR

(Continuation Line) 

Supplementary Element............ SSR DOCS DL HK1 

ATLJFK2756T01NOV/P/SIN/S78654051/SIN/01JUN81/M/10DEC15 

Supplementary Element............ SSR DOCS DL ////VALVERDE/ALBERTO/RODRIGUEZ1VALVERDE/ALBERTOMR 

(Continuation Line)

Supplementary Element............ SSR RLOC DL ATLJFK2756T01NOV.ABCDEF

(Record Locator Addressee) 

Example 3 — Message illustrating SSR DOCS (automated format) sent after the 

initial transmission of PK/PL segments for one passenger, record locator unknown: 

Addressee ................................. ATLRMDL

Sender....................................... .HDQRM1S 240827

Record Locator Sender............. HDQ1S MSOCKK/8HH6/16311116/LAX/AA/T/US/USD

Name Element .......................... 1VALVERDE/ALBERTOMR

Segment Element...................... DL2756T01NOV ATLJFK PU1 

Supplementary Element ........... SSR DOCS DL HK1 

ATLJFK2756T01NOV/P/SIN/S78654051/SIN/01JUN81/M/10DEC15

Supplementary Element............ SSR DOCS DL ////VALVERDE/ALBERTO/RODRIGUEZ1VALVERDE/ALBERTOMR

(Continuation Line) 
 JPSC/31 PSC/33 Oct 11 

 Attachment: OO 

 Page: 2 

Example 4 - Message illustrating SSR DOCS (non-automated format) and SSR 

TKNE sent as the initial transmission of PK segment for the total party, record locator 

unknown: 

Addressee ....................... ATLRMDL

Sender............................. .HDQRM1S 240827

Record Locator Sender ... HDQ1S MSOCKK/8HH6/16311116/LAX/1S/T/US/USD

Name Element................. 1VALVERDE/ALBERTOMR

Segment Element............ DL2756T01NOV ATLJFK PK1/1705 0945

Supplementary Element . SSR DOCS DL HK1 

ATLJFK2756T01NOV/P/SIN/S78654051/SIN/01JUN81/M/10DEC15

Supplementary Element .. SSR DOCS DL ////VALVERDE/ALBERTO/RODRIGUEZ1VALVERDE/ALBERTOMR

Supplementary Element . SSR TKNE DL HK1 ATLJFK2756T01NOV.2051761069389C1

Example 5 - Message illustrating SSR DOCO (automated format) and SSR TKNE 

sent after the initial transmission of PK/PL segments for one passenger, record 

locator unknown: 

Addressee ................................. ATLRMDL

Sender....................................... .MUCRM1A 240827

Record Locator Sender............. MUC1A RF87TG/CDGAF0200/1665874/PAR/AF/A/FR/EUR

Name Element .......................... 1ANTHONY/EDITHMRS

Segment Element...................... DL0021T01NOV CDGATL PU1

Supplementary Element............ SSR DOCO DL HK1 CDGATL0021T01NOV//V/9891404/PARIS/20SEP10 

Supplementary Element............ SSR DOCO DL ////US-1ANTHONY/EDITHMRS

(Continuation Line) 

Supplementary Element............ SSR TKNE DL HK1 CDGATL0021T01NOV1ANTHONY/EDITHMRS.2055231982461C1

3.13.4.2 Where no passive segment notification agreement exists (See 8.10) 

The message identifier PTN is used to allow the receiving system to recognize SSR 

DOCS/DOCA/DOCO and/or SSR TKNE has been sent for one or more passive 

segments in the message. 

Example 1 — Message illustrating SSR DOCS (non-automated format) sent for a 

confirmed segment for the total party, record locator unknown: 

Addressee ................................. ATLRMDL

Sender....................................... .HDQRM1S 240827

Message Identifier..................... PTN

Record Locator Sender............. HDQ1S MSOCKK/8HH6/16311116/LAX/1S/T/US/USD

Name Element .......................... 1TAMURA/TADASHIMR

Segment Element...................... DL2756T01NOV ATLJFK HK1/1705 0945

Supplementary Element............ SSR DOCS DL HK1/////01APR80/M//TAMURA/TADASHI/TAKEHIKO
 JPSC/31 PSC/33 Oct 11 

 Attachment: OO 

 Page: 3 

Example 2 — Message illustrating SSR DOCS (automated format) sent for a 

waitlisted segment for two passengers of the party and the record locator using an 

SSR item: 

Addressee ................................. ATLRMDL

Sender....................................... .HDQRM1S 240827

Message Identifier..................... PTN

Record Locator Sender............. HDQ1S MSOCKK/8HH6/16311116/LAX/1S/T/US/USD

Name Element .......................... 2VALVERDE/JOSEMR/ALBERTOMR 1SANTOS/MARIAMRS

Segment Element...................... DL2756T01NOV ATLJFK HL3/1705 0945

Supplementary Element............ SSR DOCS DL HK1 

ATLJFK2756T01NOV/P/SIN/S78654087/SIN/12JUL64/M/23OCT14 

Supplementary Element............ SSR DOCS DL ////VALVERDE/JOSE/JESUS-1VALVERDE/JOSEMR

(Continuation Line) 

Supplementary Element............ SSR DOCS DL HK1 

ATLJFK2756T01NOV/P/SIN/S78654051/SIN/01JUN81/M/10DEC15 

Supplementary Element............ SSR DOCS DL ////VALVERDE/ALBERTO/RODRIGUEZ1VALVERDE/ALBERTOMR

(Continuation Line) 

Supplementary Element............ SSR RLOC DL ATLJFK2756T01NOV.ABCDEF

(Record Locator Addressee) 

Example 3 — Message illustrating SSR DOCS (automated format) sent for a 

confirmed segment for the total party, record locator unknown: 

Addressee ................................. ATLRMDL

Sender....................................... .HDQRM1S 240827

Message Identifier..................... PTN

Record Locator Sender............. HDQ1S MSOCKK/8HH6/16311116/LAX/AA/T/US/USD

Name Element .......................... 1VALVERDE/ALBERTOMR

Segment Element...................... DL2756T01NOV ATLJFK HK1 

Supplementary Element............ SSR DOCS DL HK1 

ATLJFK2756T01NOV/P/SIN/S78654051/SIN/01JUN81/M/10DEC15

Supplementary Element............ SSR DOCS DL ////VALVERDE/ALBERTO/RODRIGUEZ-1 

VALVERDE/ALBERTOMR

(Continuation Line) 

Example 4 - Message illustrating SSR DOCS (non-automated format) and SSR 

TKNE sent for a confirmed segment for the total party, record locator unknown: 

Addressee ................................. ATLRMDL

Sender....................................... .HDQRM1S 240827 

Message Identifier..................... PTN

Record Locator Sender............. HDQ1S MSOCKK/8HH6/16311116/LAX/1S/T/US/USD

Name Element .......................... 1VALVERDE/ALBERTOMR

Segment Element...................... DL2756T01NOV ATLJFK HK1/1705 0945

Supplementary Element ........... SSR DOCS DL HK1 

ATLJFK2756T01NOV/P/SIN/S78654051/SIN/01JUN81/M/10DEC15

Supplementary Element............ SSR DOCS DL ////VALVERDE/ALBERTO/RODRIGUEZ1VALVERDE/ALBERTOMR

Supplementary Element ........... SSR TKNE DL HK1 ATLJFK2756T01NOV.2051761069389C1
 JPSC/31 PSC/33 Oct 11 

 Attachment: OO 

 Page: 4 

Example 5 - Message illustrating SSR DOCO (automated format) and SSR TKNE 

sent for a confirmed segment for the total party, record locator unknown: 

Addressee ................................. ATLRMDL

Sender....................................... .MUCRM1A 240827

Message Identifier..................... PTN

Record Locator Sender............. MUC1A RF87TG/CDGAF0200/1665874/PAR/AF/A/FR/EUR

Name Element .......................... 1ANTHONY/EDITHMRS

Segment Element...................... DL0021T01NOV CDGATL HK1

Supplementary Element............ SSR DOCO DL HK1 CDGATL0021T01NOV//V/9891404/PARIS/20SEP10 

Supplementary Element............ SSR DOCO DL ////US-1ANTHONY/EDITHMRS

(Continuation Line) 

Supplementary Element............ SSR TKNE DL HK1 CDGATL0021T01NOV1ANTHONY/EDITHMRS.2055231982461C1
 JPSC/31 PSC/33 Oct 11 

 Attachment: PP 

 Page: 1 of 1 

AIRIMP and SIPP 

2.11.6.1 Automated Format 

..... 

(k) Name(s) (if applicable) — enter ...... For infants not occupying a seat, the 

name association for the SSR Element should be that of the adult on whose 

lap the infant will be seated. ..... 

....... 

3.21.1.1 Rules of Usage 

.... 

(xi) For infants not occupying a seat, the name association for the SSR Element 

should be that of the adult on whose lap the infant will be seated.
 JPSC/31 PSC/33 Oct 11 

 Attachment: QQ 

 Page: 1 of 1 

AIRIMP and SIPP 

Change the reference in the following places: 

 2.10.6.1(j) ....Refer to name element paragraph 2.11.6.1(f) (k)

 2.10.6.2(j) ....Refer to name element paragraph 2.11.6.1(f) (k)

2.11.6.6(k) ....Refer to name element paragraph 2.11.6.1(f) (k)

2.11.7.1(d) ......of names in SSR elements as described in 2.11.6.1(f) (k)

3.5.1.13 .......separate names associated SSR items (see 2.11.6.1(f) (k)

3.6.2.16 ......Unequal number of names/services (see 2.11.6.1(f) (k) .... 
 JPSC/31 PSC/33 Oct 11 

 Attachment: RR 

 Page: 1 of 1 

AIRIMP and SIPP 

2.11.6 Construction of SSR 

.... 

2.11.6.1 Automated Format 

.... 

(e) Number in party of services (one, two or three digits without leading zeros): zeros)

.... 

(l) If applicable.... 

(e) Number in Party of services (without leading zeros) 1-3n 1 

2.11.6.2 Non-Automated Format 

.... 

(e) Number in party of services (a one, two or three digits without leading zeros): zeros)

.... 

Notes: 

.... 

2. Where specified.... 

(e) Number in Party of services (without leading zeros) 1-3n 1 
 JPSC/31 PSC/33 Oct 11 

 Attachment: SS 

 Page: 1 of 1 

AIRIMP and SIPP 

3.5.1.13 Unequal number of names/services 

JONES/B and BAKER/C require separate names associated SSR items (see 

2.11.6.1(f) “Construction and Sequence of Components: for rule). 

3.5.1.13 Multiple number of services for a passenger 

When a passenger requires a multiple number of the same service, the SSR contains 

the number of services; JONES/B and BAKER/C require multiple XBAG and AVIH 

services, respectively. They require separate name-associated SSR items (see 

2.11.6.1(k) for the rule.) 

..... 

3.6.2.16 Unequal number of names/services (see 2.11.6.1(f) “Construction and 

Sequence of Components”). 

3.6.2.16 Multiple number of services for a passenger 

When a passenger requires a multiple number of the same service, the SSR contains 

the number of services; JONES/B and BAKER/C require multiple XBAG and AVIH 

services, respectively. They require separate name-associated SSR items (see 

2.11.6.1(k) for the rule.) 
 JPSC/31 PSC/33 Oct 11 

 Attachment: TT 

 Page: 1 of 1 

AIRIMP and SIPP 

2.11.6.8 Standard and Bilateral SSR Definitions

Standard SSR codes must be able to be processed by any receiving member. This 

does not imply that the receiving member supports or accepts the service requested. 

When required, the appropriate advice code should be returned to the message 

sender.

Bilateral SSR codes are those that are agreed to be exchanged only between two 

members, or a CRS and one or more members.
 JPSC/31 PSC/33 Oct 11 

 Attachment: UU 

 Page: 1 of 3 

AIRIMP and SIPP 

2.11.6.4 Replies 

2.11.6.4.1 Automated format 

When replying to an automated format SSR Element, respond with appropriate 

Advice Code and repeat back the same components as received in the request 

message 2.11.6.1(a) through 2.11.6.1(k), as applicable. Component 2.11.6.1(l) (free 

text) may be returned or modified/added at the discretion of the sender. For “NSSA”, 

“NSSB”, “NSSW”, “SMSA”, “SMSB”, “SMSW”, with an Advice Code of “KK”, the 

component 2.11.6.1(l) is optional. When 2.11.6.1(l) is used, it must contain a seat 

number and when bilaterally agreed up to 5 zone and location codes can be added 

after the seat number.

[...] 

2.11.6.3 Examples of SSR Request Items (refer to 2.11.6.4 for appropriate reply) 

(a) Automated Format Examples 

[...] 

Example 23a — (bilateral) A request for contiguous seats 30E and 30F requested

1RAULOT/MARION 1PEYRE/FREDERIC

IB101Y20MAR SVQMAD HK2

SSR RQST IB NN2 SVQMAD0101Y20MAR.30E30F

Example 23b — (bilateral) A request for non contiguous seats 50B and 100A with the SSR SEAT in 

the non smoking zone.

1RAULOT/MARION 1PEYRE/FREDERIC

UA0001Y25FEB ORDHNL HK2

SSR SEAT UA NN2 ORDHNL 0001Y25FEB.50BN100AN

Example 23c — (bilateral) A generic seat request for a non-smoking window seat

1RAULOT/MARION 1PEYRE/FREDERIC

UA0001Y25FEB ORDHNL HK2

SSR NSST UA NN2 ORDHNL 0001Y25FEB.W

[...] 

2.11.6.4.3 Examples of SSR Replies (refer to 2.11.6.1 and 2.11.6.2 for appropriate request) 

(i) Automated Format 

[...] 
 JPSC/31 PSC/33 Oct 11 

 Attachment: UU 

 Page: 2 

Example 23a — (bilateral) Confirmation of contiguous seats in the non smoking zone where 30E is a 

window, exit row and leg space seat and 30F is an aisle, leg space seat 

1RAULOT/MARION 1PEYRE/FREDERIC

IB101Y20MAR SVQMAD HK2

SSR RQST IB KK2 SVQMAD0101Y20MAR.30ENWEL30FNAL

 

Example 23b — (bilateral) Confirmation of non contiguous seats in the non smoking section where 

50B is a non smoking seat, bulkhead, leg space and exit row and 100A is a non smoking seat, aisle 

and bulkhead seat.

1RAULOT/MARION 1PEYRE/FREDERIC

UA0001Y25FEB ORDHNL HK2

SSR SEAT UA KK2ORDHNL0001Y25FEB.50BNBLE100ANAB/RS

Example 23c — (bilateral) Confirmation of non contiguous seats in the non smoking section where 

50A is a non smoking seat, window, leg space and exit row and 50B is a non smoking seat, aisle and 

exit row seat.

1RAULOT/MARION 1PEYRE/FREDERIC

UA0001Y25FEB ORDHNL HK2

SSR NSST UA KK2ORDHNL0001Y25FEB.50ANWLE50BNAE

[...] 

3.19 PRE-RESERVED SEAT SELECTION AND BOARDING PASS 

NOTIFICATION

[...] 

3.19.4 Construction and Sequence of Components

(ii) when more than one seat number is included in the entry, the seat numbers will be 

included with no separation, 

(iii) when confirming a pre-reserved seat request, following the seat request, seat number may be 

followed by location codes (bilaterally agreed)

(iii) (iv) when unable to confirm a pre-reserved seat request, following the seating request, include 

the reason preceded by an oblique (may not be used in conjunction with a Transaction 

Identifier) 

[...] 

3.19.8 Reply Messages 

[...] 

3.19.8.4 When seats are confirmed, the Zone Code must follow each seat number and when 

bilaterally agreed can be followed by location code

[...] 

3.19.8.6 Examples of Reply Items 

[...] 
 JPSC/31 PSC/33 Oct 11 

 Attachment: UU 

 Page: 3 

Example 8 — (By bilateral agreement) A confirmation for pre-reserved rear-facing seats on BA flight 

4505, J class, on July 6, for all three Members of a PNR party, in the non-smoking section 

(Boarding pass inhibited): 

SSR SEAT BA KK3 LGWNAS4505J06JUL.07CN07DN07EN/RS

Example 9 — (By bilateral agreement) A confirmation for pre-reserved seats on UA flight 0001, Y 

class, on FEB 25 in the non-smoking section for a bulkhead, leg space and exit row seat

(boarding pass inhibited):

SSR SEAT UA KK1ORDHNL0001Y25FEB.50BNBLE/RS
 JPSC/31 PSC/33 Oct 11 

 Attachment: VV 

 Page: 1 of 1 

AIRIMP and SIPP 

3.21.1.4 Examples of Request and Reply Messages for Pre-Reserved seats 

in SSR SEAT elements in conjunction with SSR ASVC elements 

..... 

Example 7 (a) – Message from the booking source to the member advising a seat has been 

confirmed through an interactive conversation.

MUCRM1A

.SWIRM1G

BPR

SWI1G XDWGS2/H34Z/99999992/LON/1G/T/GB

1DRAKE/STEVEMR

BA0285K10JUN LHRSFO HK1

BA0284J20JUN SFOLHR HK1

SSRSEATBALK1 LHRSFO 0285K10JUN.29A/RS

SSRSEATBALK1 SFOLHR 0284J20JUN.28C/RS

Example 7 (b) – Message from the member to the booking source. The SSR SEAT is not 

included as the seat is already confirmed. SSR ASVC is sent with KD as EMD-A is required. 

SWIRM1G

.MUCRM1A

SWI1G XDWGS2

1DRAKE/STEVEMR

BA0285K10JUN LHRSFO HK1

BA0284J20JUN SFOLHR HK1

SSRASVCBAKD1 LHRSFO 0285K10JUN.A/0B5/SEAT/CHARGEABLE SEAT

SSRASVCBAKD1 SFOLHR 0284J20JUN.A/0B5/SEAT/CHARGEABLE SEAT
 JPSC/31 PSC/33 Oct 11 

 Attachment: WW 

 Page: 1 of 1 

AIRIMP and SIPP 

2.11.6.6 Unsolicited Reply Messages

A member may send a Reply Message to the booking source, without a previous received 

request message from the booking source. This way the member can synchronize the data 

directly entered into the members PNR with the booking source. This also applies to SSR 

Codes where replies are not permitted according to the SSR Matrix.

Example 1 – Passengers contacts UA directly advising UA of the mandatory Secure Flight 

Data. The Ticket will be issued by a Travel Agent. An unsolicited Reply Message is sent by 

UA informing the booking source about this data in order for them to be able to issue the 

ticket.

HDQRM1S

.HDQRMUA

HDQ1S HDI84J

VONWUPPERTAL/HEINO MR

UA0944Y10JUN ORDFRA HK1

UA0945Y20JUN FRAORD HK1

SSRDOCSUAKK1/////10SEP53/M//VONWUPPERTAL/HEINO

Example 2 – Passengers contacts UA directly to book a seat and to request a vegetarian 

meal. An Unsolicited Reply message is sent by UA to booking source.

HDQRM1S

.HDQRMUA

HDQ1S HDI84J

VONWUPPERTAL/HEINO MR

UA0944Y10JUN ORDFRA HK1

UA0945Y20JUN FRAORD HK1

SSRNSSTUAKK1 ORDFRA0944Y10JUN.10A

SSRNSSTUAKK1 FRAORD0945Y20JUN.12F

SSRVGMLUAKK1 ORDFRA0944Y10JUN

SSRVGMLUAKK1 FRAORD0955Y20JUN

2.11.6.67 Additional Services: Segment-Associated 

2.11.6.78 SSR Matrix 
 JPSC/31 PSC/33 Oct 11 

 Attachment: XX 

 Page: 1 of 1 

AIRIMP and SIPP 

3.13.1.4 Examples 

(a) Non-Automated Format (1) 

Mr. John Stevenson is travelling with an United States Permanent Resident Card number 

DA23145890 issued to a citizen from Singapore. 

Note:

This example has been split into two lines as the first line exceeds the maximum limit 

of 69 characters. Refer to section 2.11.5 — General Construction Rules. 

SSR DOCS AA HK1/IC/USA/ DA23145890/USASGP/12JUL64/M/12JUL04/STEVENSON/ 

SSR DOCS AA ///JOHN/RICHARD-1STEVENSON/JOHNMR 

Automated Format (2) 

Mr. John Stevenson is travelling with an United States permanent resident card 

number DA23145890 and a Singaporean Passport number S78654091. 

Note:

These example have been split into two lines as the first line exceeds the maximum limit of

69 characters. Refer to section 2.11.5 — General Construction Rules. 

SSR DOCS BA HK1MADLHR0455Y28JUN/P/SINSGP/S78654091/ SINSGP /12JUL64/M/23OCT05/ 

SSR DOCS BA ///STEVENSON/JOHN/RICHARD-1STEVENSON/JOHNMR 

SSR DOCS BA HK1LHRLAX0269Y01JUL/IC/US/ DA23145890/USSG/12JUL64/M/12JUL04/ 

SSR DOCS BA ///STEVENSON/JOHN/RICHARD-1STEVENSON/JOHNMR 

SSR DOCS BA HK1LAXAKL7302Y03JUL/P/ SINSGP/S78654091/ SINSGP/12JUL64/M/23OCT05/ 

SSR DOCS BA ///STEVENSON/JOHN/RICHARD-1STEVENSON/JOHNMR 

M E M O R A N D U M

PSC/RESO/151 bis

To: All Members, Passenger Services Conference - Accredited 

Representatives

Copy: IATA Strategic Partners

From: Head, Interline and Intermodal

Date: 4 July 2013

Subject: “PASSENGER WEEK 2011”

BOOK OF FINALLY ADOPTED RESOLUTIONS & RPs

31st Joint ATA/IATA Passenger Services Conference (JPSC)

33rd IATA Passenger Services Conference (PSC)

Singapore, 12-13 October 2011

Attached are the resolutions & recommended practices (RPs) which were adopted at the abovementioned Conference (except for RP 1708a). The Minutes of the Conference are issued 

separately under Memorandum PSC/MINS/038 dated 23 February 2012. 

The resolutions and RPs were originally circulated under cover of memorandum PSC/RESO/151 

dated 23 February 2012. Subsequently they were filed with Governments, where required, except 

for the United States Department of Transportation (DoT). The intended effective date was 1 June 

2012.

The delay in filing these resolutions and RPs with the DoT was in recognition of new procedures to 

create a “self-assessment” environment for PSC agreements. These new procedures were finally 

revealed at the PSC meeting in October 2012 (refer to agenda item P5 in the Minutes circulated 

under Memorandum PSC/MINS/042 dated 28 January 2013).

The DoT Order 2012-4-18 provides for a three-tiered system for filing and implementation of PSC 

agreements. This memorandum will be filed with the DoT using procedures for “Tier 1”. The 

changes for RP 1708a will be filed separately using the procedures for “Tier 2”.

Mike Muller

International Air Transport Association

Route de l'Aeroport 33

PO Box 416

CH - 1215 Geneva 15 Airport

Switzerland

Tel: +41 22 770 2731

Fax: +41 22 770 2896

OUTLINE OF CONTENTS

RESOLUTIONS & RECOMMENDED PRACTICES

ADOPTED AT:

33rd PASSENGER SERVICES CONFERENCE (PSC)

INTENDED EFFECTIVE DATE: 1 JUNE 2012

Resolution/RP Title

PSC(33)003 STANDARD RECISSION RESOLUTION

PSC(33)720a

[OST-2012-0058]

PASSENGER TICKET AND BAGGAGE CHECKISSUANCE AND HONORING PROCEDURES

(amending)

PSC(33)722

[OST-2012-0058]

TRANSITIONAL AUTOMATED TICKET (TAT)

(amending)

PSC(33)722f

[OST-2012-0058]

ELECTRONIC TICKET – AIRLINE

(amending)

PSC(33)722g

[OST-2012-0058]

ELECTRONIC TICKET – NEUTRAL

(amending)

PSC(33)722h

[OST-2012-0058]

ELECTRONIC TICKET – GROUND HANDLING

(amending)

PSC(33)725a

[OST-2012-0058]

MISCELLANEOUS CHARGES ORDER (MCO) –

ISSUANCE AND HONOURING PROCEDURES BY 

MEMBERS

(amending) 

PSC(33)725b

[OST-2012-0058]

MISCELLANEOUS CHARGES ORDER (MCO) –

ISSUANCE AND HONOURING PROCEDURES 

(AGENTS) 

(amending)

PSC(33)725d AUTOMATED MISCELLANEOUS CHARGES ORDER 

(MCO) NEUTRAL (COUPON-BY-COUPON)

(amending)

PSC(33)725f

[OST-2012-0058]

ELECTRONIC MISCELLANEOUS DOCUMENT –

AIRLINE

(amending)
PSC(33)725g

[OST-2012-0058]

ELECTRONIC MISCELLANEOUS DOCUMENT –

NEUTRAL

(amending)

PSC(33)725h

[OST-2012-0058]

ELECTRONIC MISCELLANEOUS DOCUMENT –

GROUND HANDLING

(amending)

PSC(33)726e

[OST-01-9575]

MULTIPLE PURPOSE DOCUMENT (MPD) – NEUTRAL, 

CARBONISED, MANUAL

(amending)

PSC(33)728

[OST-2012-0058]

CODE DESIGNATORS FOR PASSENGER TICKET 

AND BAGGAGE CHECK

(amending)

PSC(33)762 AIRLIINE DESIGNATORS

(amending)

PSC(33)763 LOCATION IDENTIFIERS

(amending)

PSC(33)767 ASSIGNMENT OF AIRLINE ACCOUNTING CODES 

AND AIRLINE PREFIXES

(amending)

PSC(33)780e

[OST-2012-0058]

IATA INTERLINE TRAFFIC PARTICIPATION 

AGREEMENT – PASSENGER

(amending)

PSC(33)792 BAR CODED BOARDING PASS (BCBP) – VERSION 4

VERSION 5

(amending)

PSC(33)1701a PASSENGER DATA HARMONIZATION

(new)

PSC(33)1701d SELF SERVICE AUTOMATED DOCUMENT CHECK

(amending)

PSC(33)1701h SECURITY CHECKPOINT ACCESS AND EGRESS

(new)

PSC(33)1701i INTERNATIONAL TRAVELER SCHEME

(new)

PSC(33)1701j

[OST-2012-0058]

AUTOMATED AND SELF-SERVICE FLIGHT 

REBOOKING FOR IRREGULAR OPERATIONS

(new)

PSC(33)1701k SELF BOARDING

(amending)
PSC(33)1706 FUNCTIONAL SPECIFICATION FOR STANDARD 

DEPARTURE CONTROL SYSTEM

(amending)

PSC(33)1706c COMON USE SELF SERVICE (CUSS)

(amending)

PSC(33)1707a

[OST-01-9575]

DATA FIELD DIRECTORY FOR DCS PASSENGER 

MESSAGES

(amending)

PSC(33)1707b

[OST-01-9575]

DATA ELEMENT DIRECTORY FOR DCS PASSENGER 

MESSAGES

(amending)

PSC(33)1708

[OST-02-13807]

PASSENGER NAME LIST (PNL) AND ADDITIONS AND 

DELETIONS LIST (ADL)

(amending)

PSC(33)1715

[OST-02-11798]

PASSENGER SERVICE MESSAGE (PSM)

(amending)

PSC(33)1719

[OST-01-9575]

PASSENGER FINAL SALES MESSAGE (PFS)

(amending)

PSC(33)1719b

[OST-02-13807]

PASSENGER RECONCILE LIST (PRL)

(amending)

PSC(33)1720a STANDARD THIRTEEN-DIGIT NUMBERING SYSTEM 

FOR TRAFFIC DOCUMENTS

(amending)

PSC(33)1728 RESERVATIONS AND TICKET CODING DIRECTORY

(amending)

PSC(33)1739 PASSENGER/ BAGGAGE RECONCILIATION 

PROCEDURES

(amending)

PSC(33)1740c RADIO FRQUENCY IDENTIFICATION (RFID) 

SPECIFICATIONS FOR INTERLINE BAGGAGE

(amending)

PSC(33)1745

[OST-02-13807]

BAGGAGE INFORMATION MESSAGES

(amending)

PSC(33)1790

[OST-2012-0058]

ADDITIONAL SERVICES

(amending)

PSC(33)1797

[OST-2012-0058]

COMMON USE PASSENGER PROCESSING 

SYSTEMS (CUPPS)

(amending)

SUMMARY OF CHANGES

RESOLUTIONS/RECOMMENDED PRACTICES FINALLY ADOPTED AT:

33rd PASSENGER SERVICES CONFERENCE (PSC)

INTENDED EFFECTIVE DATE:

1ST JUNE 2012

Resolution/

Recommended 

Practice

Summary of 

Resolution/RP

Summary of Amendment

RESOLUTION 003

STANDARD 

RECISSION 

RESOLUTION

Resolution rescinds a 

previously adopted 

Resolution.

RP 1737 – Automated Interline 

Revenue Date Exchange System 

(AIRDES) rescinded in view that this 

service no longer exists

RESOLUTION 720a

PASSENGER TICKET 

AND BAGGAGE 

CHECK – ISSUANCE 

AND HONOURING 

PROCEDURES

Provides governing rules on 

how to issue a ticket, and 

applicable conditions for the

honoring and re-issuance of 

tickets.

Clarifies that the combined tax code 

‘XT’ must not be used for the 

transmission of tax, fee, charge data in 

electronic tickets.

RESOLUTION 722

TRANSITIONAL 

AUTOMATED TICKET 

(TAT)

Provides governing rules on 

how to produce an 

“automated” ticket issued by 

airlines. It also provides the 

technical specifications and 

applicable conditions for the 

honoring of such tickets.

Ticketing of surcharges is revised to 

reflect new ways of filing single and 

multiple segment surcharges. 

Examples are added on how to ticket 

multiple surcharges.

Clarifies that the combined tax code 

‘XT’ must not be used for the 

transmission of tax, fee, charge data in 

electronic tickets.

RESOLUTION 722f

ELECTRONIC 

TICKET – AIRLINE

Provides governing rules and 

technical specifications on 

how to produce an Electronic 

Ticket (ET) issued by airlines. 

This allows ticketing to be 

performed without the 

issuance of paper tickets. 

Also included are the 

applicable conditions for the 

issuance and honoring of 

such tickets.

Various definitions for EMD, coupon 

status codes and messages are 

revised.

Clarifies that the combined tax code 

‘XT’ must not be present in the fare 

calculation of the ticket.

Procedures are added to clarify what 

should happen to an electronic ticket 

when an associated EMD is present.

Various data elements are added and 

amended.

Various amendments to the data 

elements matrix.
Resolution/

Recommended 

Practice

Summary of 

Resolution/RP

Summary of Amendment

RESOLUTION 722g

ELECTRONIC

TICKET –

NEUTRAL

Provides governing rules and 

technical specifications on 

how to produce an Electronic 

Ticket (ET) issued by travel 

agents. This allows ticketing 

to be performed without the 

issuance of paper tickets. 

Also included are the 

applicable conditions for the 

issuance and honoring of 

such tickets.

Definitions for EMD and coupon status 

codes are revised.

Clarifies that the combined tax code 

‘XT’ must not be present in the fare 

calculation of the ticket.

Various data elements are added and 

amended.

Various amendments to the data 

elements matrix.

RESOLUTION 722h

ELECTRONIC 

TICKET – GROUND 

HANDLING

Provides governing rules and 

technical specifications to be 

followed for the third party 

ground-handling of electronic 

tickets (ETs). This allows 

airlines to have their 

electronic tickets handled by 

third party ground handlers.

Various definitions are revised.

Clarifies that the combined tax code 

‘XT’ must not be present in the fare 

calculation of the ticket.

Various data elements are added and 

amended.

Various amendments to the data 

elements matrix.

RESOLUTION 725a

MISCELLANEOUS 

CHARGES ORDER 

(MCO) – ISSUANCE 

AND HONOURING 

PROCEDURES BY 

MEMBERS

Provides governing rules on 

how to issue and honor a

Miscellaneous Charges Order 

(MCO) issued be airlines.

Procedures for completing a fee 

calculation on an EMD are added.

RESOLUTION 725b

MISCELLANEOUS 

CHARGES ORDER 

(MCO) – ISSUANCE 

AND HONOURING 

PROCEDURES 

(AGENTS)

Provides governing rules on 

how to issue and honor a 

Miscellaneous Charges Order 

(MCO) issued be agents.

Procedures for completing a fee 

calculation on an EMD are added.

RESOLUTION 725d

AUTOMATED 

MISCELLANEOUS 

CHARGES ORDER 

(MCO) – NEUTRAL

(COUPON-BYCOUPON)

Provides technical 

specifications and print line 

specifications for the 

issuance of Miscellaneous 

Charges Order ‘automated’ 

issued by agents

The provision that this resolution shall 

expire 31 December 2013 is added.
Resolution/

Recommended 

Practice

Summary of 

Resolution/RP

Summary of Amendment

RESOLUTION 725f

ELECTRONIC 

MISCELLANEOUS 

DOCUMENT –

AIRLINE

Provides governing rules for 

the issuance and use of 

Electronic Miscellaneous 

Documents (EMD) by airlines.

The EMD is an electronic 

method to document the sale 

and usage of charges 

associated to various usage, 

e.g. excess baggage 

charges.

Various definitions for EMD, coupon 

status codes and messages are 

revised.

Clarifies that the combined tax code 

‘XT’ must not be present in the fare 

calculation of the ticket.

Procedures are added to clarify what 

should happen to an EMD-A when 

control is requested from a carrier who 

is not the operating carrier.

A new Unsolicited Billing message is 

added to support codeshare.

Various data elements are added and 

amended.

Various amendments to the data 

elements matrix.

RESOLUTION 725g

ELECTRONIC 

MISCELLANEOUS 

DOCUMENT –

NEUTRAL

Provides governing rules for 

the issuance and use of 

Electronic Miscellaneous 

Documents (EMD) by agents.

Various definitions for EMD, coupon 

status codes and messages are 

revised.

Various data elements are added and 

amended.

Various amendments to the data 

elements matrix.

RESOLUTION 725h

ELECTRONIC 

MISCELLANEOUS 

DOCUMENT –

GROUND HANDLING

Provides governing rules and 

technical specifications to be 

followed for the third party 

ground-handling of electronic 

miscellaneous documents 

(EMDs). This allows airlines 

to have their EMDs handled 

by third party ground 

handlers.

Various definitions for coupon status 

codes and messages are revised.

Various data elements are added and 

amended.

Various amendments to the data 

elements matrix.

RESOLUTION 726e

MULTIPLE PURPOSE 

DOCUMENT (MPD) –

NEUTRAL, 

CARBONISED, 

MANUAL

Provides governing rules on 

how to issue a Multiple 

Purpose Document (MPD) by 

agents. 

The provision that this resolution shall 

expire 31 December 2013 is added.
Resolution/

Recommended 

Practice

Summary of 

Resolution/RP

Summary of Amendment

RESOLUTION 728

CODE 

DESIGNATORS FOR 

PASSENGER TICKET 

AND BAGGAGE 

CHECK

Provides various coding 

structures in order to identify 

the type of fare and other 

conditions of travel for tickets 

and other documents.

The reporting form for taxes, fees and 

charges is deleted since this will be 

supplied directly by the IATA Ticket 

Tax Box Service.

Payment card listings are revised and 

the Bank Identification Number (BIN) 

numbering system is deleted.

RESOLUTION 762

AIRLINES 

DESIGNATORS

Provides the governing rules 

for the assignment and use of 

airline designators for the 

entire airline and travel and 

tourism industry.

Various editorial amendments to reflect 

more accurately the current code 

assignment procedures. Also a 

change to criteria for ULD owners in 

recognition of the disbandment of the 

Interline ULD Control User Group 

(IULDUG).

RESOLUTION 763

LOCATION 

IDENTIFIERS

Provides rules for the 

assignment of unique threeletter codes to identify

specific locations and 

metropolitan areas

Various editorial amendments to reflect 

more accurately the current code 

assignment procedures. 

RESOLUTION 767

ASSIGNMENT 

CRITERIA FOR 

AIRLINE 

ACCOUNTRING 

CODES AND AIRLINE

PREFIXES

Provides governing rules for 

the assignment and use of 

airline accounting codes and 

airline prefixes.

Various editorial amendments to reflect 

more accurately the current code 

assignment procedures.

RESOLUTION 780e

IATA INTERLINE 

TRAFFIC 

PARTICIPATION 

AGREEMENT –

PASSENGER

Provides the standard text for 

multi-lateral interline traffic 

agreements where only one 

airline is able to issue tickets.

New provision to allow an airline to 

provide advance notice to its interline 

partners that it will no longer accept 

paper tickets.

RESOLUTION 792

BAR CODED 

BOARDING PASS 

(BCBP) – VERSION 4

VERSION 5

Provides the governing rules 

and technical specifications 

for the issuance of a BarCoded Boarding Pass 

(BCBP).

Added a new element in the 2D bar 

code to manage passenger eligibility 

for “fast track” lanes at airports.

RP 1701a

PASSENGER DATA 

HARMONIZATION

One of the “passenger 

experience standards” that 

provides guidelines for the 

exchange of passenger data 

to enhance border security

Establishment of a global framework 

for aircraft operators to provide 

passenger data to States.

RP 1701d

SELF SERVICE 

AUTOMATED

DOCUMENT CHECK

One of the “passenger 

experience standards” that 

provides guidelines for self 

service document check 

capability

Updating of guidelines for self service 

document checking by passengers.
Resolution/

Recommended 

Practice

Summary of 

Resolution/RP

Summary of Amendment

RP 1701h

SECURITY 

CHECKPOINT 

ACCESS AND 

EGRESS

One of the “passenger 

experience standards” that 

provides best practice 

suggestions for airports 

regarding procedures at 

security checkpoints

Establishment of guidelines for the 

consideration of airports for security 

access and egress (act of exiting).

RP 1701i

INTERNATIONAL 

TRAVELER SCHEME

One of the “passenger 

experience standards” that 

encourages Governments to 

harmonize their registered 

traveler schemes

Establishment of guidelines to promote 

the adoption of commonalities between 

national registered traveler schemes.

RP 1701j

AUTOMATED AND 

SELF-SERVICE 

FLIGHT REBOOKING 

FOR IRREGULAR 

OPERATIONS

One of the “passenger 

experience standards” that 

provides guidelines for self 

service re-booking in cases of 

irregular operations

Establishment of guidelines for airlines 

to use on their own self-service 

machines or in a common use 

environment to facilitate self-service rebooking at airports.

RP 1701k

SELF BOARDING

One of the “passenger 

experience standards” that 

provides guidelines for self 

boarding

Updating of guidelines for self-service 

boarding by passengers.

RP 1706

FUNCTIONAL 

SPECIFICATION FOR 

STANDARD 

DEPARTURE 

CONTROL SYSTEM

Defines user requirements to 

assist airlines, manufacturers, 

airport authorities or vendors 

who provide standard 

Departure Control Systems 

(DCS)

Editorial update

RP 1706c

COMON USE SELF 

SERVICE (CUSS)

Provides a recommended 

practice outlining specification 

and standard for members 

who plan to operate shared 

self service devices in a 

common environment.

Various editorial updates to clarify 

procedures including truncation of 

credit card numbers when used as a 

form of identification to comply with 

PCI-DSS requirements

RP 1707a

DATA FIELD 

DIRECTORY FOR 

DCS PASSENGER 

MESSAGES

Provides definitions and 

formats for the automatic 

creation, transmission, receipt 

and interpretation of this 

group of messages.

Update to allow DCSs to correctly 

calculate the timeframe between flights 

to facilitate vetting by US authorities

RP 1707b

DATA ELEMENT 

DIRECTORY FOR 

DCS PASSENGER 

MESSAGES

Provides specifications and 

rules governing the use of 

DCS Passenger Messages. 

These messages are used to 

provide various pieces of 

information that support the 

“seamless” interline 

transportation of passengers.

Update to allow DCSs to correctly 

calculate the timeframe between flights 

to facilitate vetting by US authorities.

Addition of element to allow unique 

identifier for passengers.

Various editorial updates to clarify 

procedures
Resolution/

Recommended 

Practice

Summary of 

Resolution/RP

Summary of Amendment

RP 1708

PASSENGER NAME

LIST (PNL) AND 

ADDITIONS AND 

DELETIONS LIST 

(ADL)

Provides the definitions, 

formats and procedures for 

the creation, transmission 

and interpretation of 

Passenger Name Lists 

Messages and 

Additions/Deletion Lists 

Messages associated with 

the passenger data produced 

by an airline reservations 

system.

Update to allow DCSs to correctly 

calculate the timeframe between flights 

to facilitate vetting by US authorities 

Addition of element to allow unique 

identifier for passengers

Various editorial updates to clarify 

procedures

RP 1715

PASSENGER 

SERVICE MESSAGE 

(PSM)

Provides guidance on how to 

inform downline stations of 

disembarking and transiting 

passengers who require 

assistance or special 

handling

Update to allow DCSs to correctly 

calculate the timeframe between flights 

to facilitate vetting by US authorities

RP 1719

PASSENGER FINAL 

SALES MESSAGE 

(PFS)

The PFS message gives 

information to reservations 

systems about the final 

counts loaded on an aircraft 

at the departure station. List 

contains a numeric summary 

of passenger counts and may 

contain passenger names

Addition of element to allow unique 

identifier for passengers

RP 1719b

PASSENGER 

RECONCILE LIST 

(PRL)

The PRL is a list containing 

all passenger check-in details 

for actual boarded 

passengers of a flight 

departure.

Update to allow DCSs to correctly 

calculate the timeframe between flights 

to facilitate vetting by US authorities.

Addition of element to allow unique 

identifier for passengers

RP 1720a

STANDARD 

THIRTEEN-DIGIT 

NUMBERING 

SYSTEM FOR 

TRAFFIC 

DOCUMENTS

Provides guidelines regarding 

the numbering systems for 

airline and travel agent traffic 

documents

Updates to provide IATA with several 

new form codes to satisfy the rapid 

increase in use of electronic tickets 

and electronic miscellaneous 

documents.
Resolution/

Recommended 

Practice

Summary of 

Resolution/RP

Summary of Amendment

RP 1728

RESERVATIONS 

AND TICKET 

CODING 

DIRECTORY

Guidelines to encourage 

airlines to publish via the 

industry “Single Source RBD 

Service” the reservations 

booking designator and the 

class of service code they 

want to be used in their 

services in conjunction with a 

given fare basis code

Updated to reflect that ATPCO is the 

source of the ‘Single Source RBD 

Service’.

RP 1739

PASSENGER/ 

BAGGAGE 

RECONCILIATION 

PROCEDURES

Guidelines to ensure that 

baggage is transported with 

the passenger on board

Editorial update

RP 1740c

RADIO FRQUENCY 

IDENTIFICATION 

(RFID) 

SPECIFICATIONS 

FOR INTERLINE 

BAGGAGE

Provides specifications for the 

development of radio 

frequency identification 

(RFID) technology to more 

efficiently handle (e.g. 

sortation, reconciliation, etc.) 

baggage, utilizing the license 

plate concept defined in 

Resolution 740.

Editorial update

RP 1745

BAGGAGE 

INFORMATION 

MESSAGES

Provides the definitions, 

formats and specifications for 

all of the messages used in 

the baggage handling 

process.

Various editorial updates to clarify 

procedures

RP 1790

ADDITIONAL 

SERVICES

Guidelines to facilitate the 

reservations, sales and 

delivery of airline additional 

services

Definitions for the EMD are revised.

References to ‘Sundry Charges’ are 

deleted.

RP 1797

COMMON USE 

PASSENGER 

PROCESSING 

SYSTEMS (CUPPS)

Provides guidelines for 

CUPPS systems that enable 

airlines to share check-in 

desks or gate podiums for 

boarding processes

Various editorial updates to clarify 

procedures including truncation of 

credit card numbers when used as a 

form of identification to comply with 

PCI-DSS requirements

 RESOLUTION 003

STANDARD RECISSION RESOLUTION

PSC(33)003 Expiry: 2 June 2012

Type: B

M9

Resolved that, effective 1 June 2012, the following RP is rescinded:

RP 1737 - Automated Interline Revenue Data Exchange System (AIRDES)

Filing Period: Effective Date:

1 March - 1 June 2012

13 April 2012

RESOLUTION 720a

PASSENGER TICKET AND BAGGAGE CHECK — ISSUANCE AND

HONOURING PROCEDURES

(amending)

PSC(32 33)720a Expiry: Indefinite

Type: B

T2.12/P

....

15. TAX/FEE/CHARGE BOX1

15.2.5 If there are not enough tax/fee/charge boxes on the ticket to accommodate all 

tax, fee and charge entries, combine as many amounts as necessary into one amount. 

Enter the amount in one tax/fee/charge box preceded or followed by the code “XT”. 

Detail the combined taxes, fees and charges in the fare calculation area after the fare 

calculation entries or, optionally, in the “Endorsement/Restrictions” box. Effective no 

later than 1 February 2009 the tax code “XT” shall not be used for transmission of 

tax/fee/charge data in electronic tickets. This change shall not apply to electronic tickets 

issued prior to the date of system implementation.

Filing Period: Effective Date:

1 March - 1 June 2012

13 April 2012

RESOLUTION 722

TRANSITIONAL AUTOMATED TICKET (TAT)

(amending)

PSC(32 33)722 Expiry: Indefinite

Type: B

T2.31/P

3.16.7 Surcharge (other than stopover and/or transfer charge)

3.16.7.1 Single Segment

When a surcharge (other than stopover and/or transfer charge) is applicable to a 

specific segment, imprint ‘Q’ followed by the amount immediately after the segment to 

which it applies. The same process shall be followed for documenting a surcharge on 

an unticketed point contained within the specific segment.

Example:

NYC_LH_FRA_Q15.00AZ_ROM

The above example also applies when LON is a surcharged unticketed point between 

NYC and FRA.

T2.30/P

...

3.16.7.2 Multiple Segments

When a surcharge (other than a stopover and/or transfer charge) is applicable to 

several consecutive or non-consecutive segments, imprint ‘Q’ followed by the first and 

last cities of the segments to which the surcharge applies, in the direction of travel, and 

the amount. When the surcharge crosses multiple fare components, Tthis entry shall be 

made at the end of the itinerary preceding the total amount in NUCs. When the 

surcharge is contained within a single fare component, this entry shall be made at the 

end of the fare component to which the surcharge applies, preceding the fare 

component amount in NUCs.
Example:

WAS_AF_PAR_AF_LON_BA_BAH M780.00Q_WASBAH156.00NUC936.00

Example (within one fare component):

WAS_AF_PAR_AF_LON_BA_BAH_Q_WASBAH156.00M780.00NUC936.00

The above example may have been priced as:

WAS to BAH = 156.00

Or WAS to PAR equipment and LON to BAH equipment = 156.00

Example (crossing fare components):

WAS_TG_BKK_M1000.00_TG_WAS_M1000.00Q_WASWAS156.00NUC2156.0

0

Note: Sleeper/berth surcharge may optionally be collected on an MCO.

3.16.7.3 Multiple Surcharges

3.16.7.3.1 Where more than one surcharge applies to a single segment, they shall be 

shown separately directly after the segment to which they apply.

Example:

LON BB BKK Q75.00Q25.00CC TYO Q75.00M1000.00NUC1150.00

3.16.7.3.2 Where more than one surcharge applies on consecutive sectors imprint each 

separate ‘Q’ followed by the first and last ticketed cities, in the direction of travel, of 

each sector to which the surcharges apply followed by the amount. When the surcharge 

crosses multiple fare components, this entry shall be made at the end of the itinerary 

preceding the total amount in NUCs. When the surcharge is contained within a single 

fare component, this entry shall be made at the end of the fare component to which the 

surcharge applies, preceding the fare component amount in NUCs.

Example (within one fare component):

LON BB FRA BB BKK M1000.00CCFRA CC LON Q BKKLON100.00Q 

BKKLON75.00M1000.00 NUC2175.00END

Example (crossing fare components):

LON BB FRA BB BKK M1000.00CCFRA CC LON M1000.00Q_ 

LONLON100.00Q_LONLON75.00NUC2175.00END
T2.12/P

....

3.19 TAX/FEE/CHARGE1

3.19.1.5 If there are not enough “Tax/fee/charge” boxes on the ticket to accommodate 

all tax, fee and charge entries, combine as many amounts as necessary into one 

amount. Imprint the amount in one “Tax/Fee/Charge” box preceded or followed by the 

code “XT”. Detail the combined taxes, fees and charges in the fare calculation area after 

the fare calculation entries or, optionally, in the “Endorsements/Restrictions” box. 

Effective no later than 1 February 2009 the tax code “XT” shall not be used for 

transmission of tax/fee/charge data in electronic tickets. This change shall not apply to 

electronic tickets issued prior to the date of system implementation.

.....

Filing Period: Effective Date:

1 March - 1 June 2012

13 April 2012

RESOLUTION 722f

ELECTRONIC TICKET — AIRLINE

(amending)

PSC(32 33)722f Expiry: Indefinite

Type: B

T2.10/P

Section 3 – Definitions

...

3.5 ELECTRONIC MISCELLANEOUS DOCUMENT (EMD) - An electronic record 

issued by a Member or its authorized agent, in accordance with applicable tariffs, for 

residual value or for the collection of miscellaneous charges. An EMD must be either 

an EMD-A or an EMD-S. 

T2.3/P

.....

Section 5 – Technical Specifications

....

5.4 COUPON STATUS INDICATORS

....

5.4.2 C Checked-In – Indicates the passenger is entitled to board. has made 

his/her presence known to the Marketing or Operating Carrier 

personally or via electronic means (ei.ge. a self-service device). It may 

indicate that the customer has checked baggage and/or secured a 

boarding pass. The carrier holding airport control shall forward coupon 

status updates or return control to the Validating Carrier within 72 hours 

following the scheduled departure date/time for flight coupons with a 

current or future travel date, or within 72 hours following the date/time 

control is obtained for flight coupons with a past travel date.

.....
T2.13/P

5.4.8 N Coupon Notification — Indicates coupon data for a coupon(s) not showing a 

final status of E, F, G, P, J, R, or X, or Z and for which control of the coupon is not 

provided. 

T2.16/P

Section 5 – Technical Specifications

...

5.5 MESSAGES

...

5.5.3.5 Unsolicited Airport Control – A message generated by the Validating Carrier to 

the Marketing/Operating Carrier providing airport control of an ET flight coupon(s). This 

message may also be sent by the Operating Carrier, by including the Billing Carrier 

Indicator, to advise the Billing Marketing Carrier of the Flown Ticket/Coupon(s) 

information. Response acknowledges receipt and may provides “Response Comments”

regarding the ET flight coupon(s), or denies the request.

.....

T2.8/P

5.5.3.9 System Update — A request from a carrier to associate or disassociate an 

EMD-A coupon(s) to or from an ET coupon. Response either acknowledges or denies 

the request.

.....

T2.12/P

6.1.2 Tax and Special Fees/Charges codes shall be used as published in the IATA Airline 

Coding Directory, section titled “ISO Codes and IATA Currency Codes and

Ticket Codes for Taxes, Fees and Charges”. The tax/fee/charge code “XT” shall not be used 

for transmission of tax/fee/charge data in electronic tickets and shall not be present in the 

fare calculation of the ticket.

.....
T2.15/P

Section 6 - Procedures

...

6.4 CONTROL

.....

6.4.6 Change of Status 

When a carrier is being notified of a change of coupon status, only coupon(s) being 

changed shall be included in the ‘Change of Status’ message.

When the carrier holding control of the ET flight coupon(s) notifies the Validating Carrier 

of Coupon Status Indicator updates to FLOWN/USED via a ‘Change of Status’ 

message, the same Coupon Status Indicator shall be sent via a separate ‘Change of 

Status’ message for the corresponding EMD-A value coupon(s).

The intent of the association between the ET flight coupon(s) and the EMD-A value 

coupon(s) is to ensure the usage of the coupons is synchronized.

If an EMD-A coupon is not to be used, it shall be disassociated from the corresponding 

ET coupon using a System Update message for disassociation prior to sending a 

‘Cchange of Sstatus’ message to ‘FLOWN/USED’, for the corresponding ET coupon.

...
T2.5/P

6.4.7 Request Airport Control

The Marketing or Operating Carrier shall request Airport Control from the Validating 

Carrier via a “Request Airport Control” message using Transaction Action “B”.

When a carrier obtains control of an ET flight coupon(s) indicating a corresponding 

EMD-A value coupon(s), that carrier shall also request Airport Control of the 

corresponding EMD-A value coupon(s) from the Validating Carrier of the EMD-A via a 

“Request Airport Control” message using Transaction Action “B”.

T2.2/P

6.4.7.1 The Validating Carrier shall include in the “Response” message all sold coupon 

data, and current coupon data when different from sold, associated to the ticket, 

including conjunction tickets. Coupon data for which “Airport control” is not provided 

shall be included. (...)

6.4.7.1.1 When the carrier requesting control of an ET flight coupon(s) associated to an 

EMD-A value coupon(s) is not the Operating Carrier of the requested coupons, the 

Validating Carrier of the ET, if relinquishing control, shall disassociate the EMD-A value 

coupons from the ET flight coupon(s).

...

6.4.8 Unsolicited Airport Control

...

6.4.8.3 Only the Validating Carrier can relinquish control of an ET flight coupon to 

another carrier. A carrier may return control only to the Validating Carrier.

6.4.8.4 If control of an ET flight coupon(s) which has an EMD-A value coupon(s) 

associated to it is being passed to a carrier which is not the Operating Carrier of the 

requested coupons, the Validating Carrier of the ET shall indicate the associated EMDA value coupon(s) as disassociated in the "Unsolicited Airport Control" request.

If the "Unsolicited Airport Control" request is accepted by the carrier, or if no response is 

received, the Validating Carrier shall disassociate the EMD-A value coupon(s) from the 

ET flight coupon(s).

Note: Subsequent paragraphs to be renumbered.
T2.16/P

6.4.10.5.1 The Operating Carrier may also send an Unsolicited Airport Control message 

to the Marketing Carrier, when the Marketing Carrier is not the Billing Carrier, to provide 

flown coupon information.

...

T2.4/P

6.8 PRINT

...

6.8.2 Upon initiating a Print transaction, the carrier shall send a ‘System Update’ 

message to disassociate any remaining associated EMD-A value coupon(s) to the 

Validating Carrier of the EMD.

6.9 PRINT EXCHANGE

...

6.9.11 Upon initiating a Print Exchange transaction, the carrier shall send a ‘System 

Update’ message to disassociate any remaining associated EMD-A value coupon(s) to 

the Validating Carrier of the EMD.

6.10 EXCHANGE/REISSUE

...

6.10.5 Upon initiating an Exchange/Reissue transaction, the carrier shall send a 

‘System Update’ message to disassociate any remaining associated EMD-A value 

coupon(s) to the Validating Carrier of the EMD.

6.11 REFUND

...

6.11.4 Upon initiating a Refund transaction, the carrier shall send a ‘System Update’ 

message to disassociate any remaining associated EMD-A value coupon(s) to the 

Validating Carrier of the EMD.
T2.14/P

...

6.17 SYSTEM UPDATE

...

6.17.4 When the corresponding ET flight coupon(s) are other than final or suspend 

status, the receiving system shall not deny the System Update request. When the 

corresponding ET flight coupon(s) are at final or suspend status, the receiving system 

shall deny the system update request for association.

RESOLUTION 722f

Attachment ‘A’

ELECTRONIC TICKET AND MISCELLANEOUS DOCUMENTS

DATA ELEMENTS GLOSSARY

T2.23/P

...

ADDITIONAL SERVICES ATTRIBUTE GROUP – 3 ALPHANUMERIC

(Applicable to 725f, 725g and 725h only) 

A value which specifies the high-level group applicable to the service at the coupon 

level as defined by ATPCO .

ADDITIONAL SERVICES ATTRIBUTE SUB GROUP – 3 ALPHANUMERIC

(Applicable to 725f, 725g and 725h only) 

A value which specifies the Sub Group (within the specified Group) applicable to the 

service at the coupon level as defined by ATPCO.

...

ADDITIONAL SERVICES INDUSTRY CARRIER INDICATOR – 1 ALPHANUMERIC

(Applicable to 725f, 725g and 725h only) 

An indicator which specifies whether the service uses an industry-defined or carrierdefined Reason for Issuance Sub Code

I = Industry

C = Carrier
...

ADDITIONAL SERVICES SERVICE TYPE – 1 ALPHANUMERIC

(Applicable to 725f, 725g and 725h only) 

A value which specifies whether the service is for baggage allowance, baggage 

charges, flight, merchandise, reissue/refund or ticket.

A = Baggage Allowance

C = Baggage Charges

F = Flight

M = Merchandise

R = Reissue Refund

T = Ticket

Blank = no application

T2.29/P

CARRIER FEE DATA

A series of data elements representing...

...

Carrier Fee Tax Amount – 12 ALPHANUMERIC

The amount of the tax applied.

T2.21/P

T2.22/P

...

CONSUMED AT ISSUANCE INDICATOR — 1 ALPHANUMERIC

(Applicable to EMD-S only) (Applicable to 725g only) 

Indicates a coupon(s) of an EMD-S shall be considered ‘Flown/Used’ at issuance time 

as defined by the Marketing/Operating Carrier for an additional service. 

Y Consumed at Issuance

N Not Consumed at Issuance

Blank Not applicable

T2.19/P

...

COUPON VALUE — 9 ALPHANUMERIC

(applicable to 725f, 725g and 725h only) (Shall not apply be present for any coupon in 

the document when Fare Calculation aArea, fFare cCalculation aArea nNet aAmount, or

fFare cCalculation sSell aAmount data is present).

...

FARE CALCULATION AREA — 87 ALPHANUMERIC

(Repeatable field) (Shall not apply be present in the document when Coupon Value data 

is present)
T2.20/P

...

PRODUCT CHARACTERISTIC TYPE – 35 ALPHANUMERIC

(applicable to 725f, 725g and 725h) (repeatable field)

Designates an optional service product characteristic type (e.g. T-shirt size, color or prereserved seat number)

PRODUCT CHARACTERISTIC VALUE – 70 ALPHANUMERIC

(applicable to 725f/g/h) (repeatable field)

Text that describes the product sold (e.g. large, blue) for corresponding Product 

Characteristic Type.

T2.26/P

...

REASON FOR ISSUANCE CODE — 1 ALPHANUMERIC

(applicable to 725f/20.63, 725g/20.64 and 725h/20.66 only), (Refer RP1790/10.90), 

(stored in passenger name record)

A Primary single character code, which defines the reason for issuance. Defined 

Reason for Issuance Codes are listed below.

A Air Transportation – to be used for all air transportation related sub-codes (for 

example these include, but not limited to Charter, Involuntary Downgrading, 

Upgrading)

B Surface Transportation/Non Air Services – to be used for all surface 

transportation/non air services related sub-codes (for example these include, but 

not limited to Bus, Car Hire)

C Baggage – to be used for all baggage related sub-codes (for example these 

include, but not limited to Angling Equipment, Biking Equipment) 

D Financial Impact – to be used for all financial impact related sub-codes (for 

example these include, but not limited to Booking Reservation Change Fee, 

Refundable Balances)

E Airport Services – to be used for all airport services related sub-codes (for 

example these include, but not limited to Check-in, Lounge Access)

F Merchandise – to be used for all merchandise related sub-codes (for example 

these include, but not limited to T-shirt)

G Inflight Services – to be used for all inflight services related sub-codes (for 

example these include, but not limited to Sleeper Berth, Beverage)

...
T2.18/P

REASON FOR ISSUANCE SUB-CODE DESCRIPTION – 70 ALPHANUMERIC

(Repeatable field) (applicable to 725f, 725g, and 725h only)

Description of the service on the EMD at the coupon level. This description may differ 

based on the associated Reason for Issuance Code and the Fee Owner Airline 

Designator.

Note: this element must only contain characters which are alpha or numeric or a 

combination of both. Characters such as /, -, and . are not permitted.

T10

...

TAXES/FEE/CHARGE DATA AT THE TICKET COUPON LEVEL

....

Airport Code - 5 ALPHA

(Repeatable field)

The airport code identifying the airport to which the coupon tax applies

Applicable Amount – 11 ALPHANUMERIC

(Repeatable field)

The tax amount applicable to the coupon as published in the IATA TTBS or other 

applicable filing mechanism.. This amount is expressed in the Coupon Tax Currency 

Type

....

Currency Type– 4 ALPHANUMERIC

(Repeatable field)

The ISO currency code representing the currency code in which the Coupon Tax 

Applicable Amount was published or filed in

...

Reported Amount – 11 ALPHANUMERIC

(Repeatable field)

The tax amount applicable to a coupon expressed in the currency of payment. This is 

the reported amount converted from the Coupon Tax Applicable Amount at applicable 

daily Bank Exchange Rate

...

Segment Tax Airport Codes - 6 ALPHA

(Repeatable field)

The origin and destination airport codes identifying multiple segment taxes.
...

TOTAL TICKET/DOCUMENT AMOUNT – 12 ALPHANUMERIC T2.27/P

The sum of the base fare amount plus all applicable tax/fee/charge amount(s) preceded 

by the applicable ISO Currency Code or BT/IT.

The sum of the base or equivalent fare (or fee for EMD) amount as applicable plus all 

tax/fee/charge amounts preceded by the ISO Currency Code. The field may contain 

BT/IT preceded by the ISO Currency Code. Refer to PSC Resolution 722 for further 

information. The stated amount is exclusive of Carrier Fees (for example, 

OA/OB/OC/OD).

TOTAL TICKET/DOCUMENT NET AMOUNT – 12 ALPHANUMERIC

The sum of the base net fare amount plus all applicable tax/fee/charge amount(s) 

preceded by the applicable ISO Currency Code or BT/IT.

The sum of the base or equivalent net fare (or fee for EMD) amount as applicable plus 

all tax/fee/charge amounts preceded by the ISO Currency Code. The field may contain 

BT/IT preceded by the ISO Currency Code. Refer to PSC Resolution 722 for further 

information. The stated amount is exclusive of Carrier Fees (for example, 

OA/OB/OC/OD).

TOTAL TICKET/DOCUMENT SELL AMOUNT – 12 ALPHANUMERIC

The sum of the base net fare amount plus all applicable tax/fee/charge amount(s) 

preceded by the applicable ISO Currency Code or BT/IT.

The sum of the base or equivalent sell fare (or fee for EMD) amount as applicable plus 

all tax/fee/charge amounts preceded by the ISO Currency Code. The field may contain 

BT/IT preceded by the ISO Currency Code. Refer to PSC Resolution 722 for further 

information. The stated amount is exclusive of Carrier Fees (for example, 

OA/OB/OC/OD).
RESOLUTION 722f

Attachment ‘B’

MESSAGE CONSTRUCTION MATRIX – AIRLINE MESSAGES

T8

ELEMENT 

DESCRIPTION

Transaction CHAR. 

A, N 

OR 

A/N

DISPLAY UNSOLICITED 

AIRPORT 

CONTROL 

(INFORMATION 

– ATA ONLY)

HISTORY 

DISPLAY

REQUEST 

AIRPORT 

CONTROL

CHANGE 

OF STATUS

REDIRECT 

AIRPORT 

CONTROL

RESERVATION 

CHANGE

EMERGENCY 

LOCK

SYSTEM 

UPDATE

Action Code --

->

D, J T (I – ATA 

ONLY

H B C N A M U

RESOLUTION 

722 f

REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP

...

Carrier Fee 

Expiry Date 

(Applicable 

722g)

4 A/N

...

Carrier Fee 

Tax on Tax 

Currency Code

(Applicable 

722g)

3 A/N

...
T10

ELEMENT DESCRIPTION

Transaction NO CHAR.

A, N OR A/N DISPLAY

UNOLICITED 

AIRPORT 

CONTROL

HISTORY 

DISPLAY

REQUEST 

AIRPORT 

CONTROL

CHANGE OF 

STATUS

REDIRECT 

AIRPORT 

CONTROL

RESERVATION 

CHANGE

EMERGENCY 

LOCK

SYSTEM 

UPDATE

Action code -> D,J T (I-ATA only) H B C N A M U

RESOLUTION 722f REQ RES

P REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP

...

Tax/Fee/Charge Data at the 

Ticket Coupon Level

...

Coupon Tax Airport Code 5A C C C

Coupon Tax Reported Amount 11A/N C C C

Coupon Tax Currency Type 4AN C C C

Coupon Tax Applicable Amount 11A/N C C C

Segment Tax Airport Codes 6A C C C

Filing Period: Effective Date:

1 March - 1 June 2012

13 April 2012
RESOLUTION 722g

ELECTRONIC TICKET — NEUTRAL

(amending)

PSC(32 33)722g Expiry: Indefinite

Type: B

T2.10/P

Section 3 – Definitions

...

3.6 ELECTRONIC MISCELLANEOUS DOCUMENT (EMD) - aAn electronic record 

issued by a Member or its authorized agent, in accordance with applicable tariffs, for 

refundable value or for the collection of miscellaneous charges. An EMD must be either 

an EMD-A or an EMD-S.

....

T2.3/P

.....

Section 5 – Technical Specifications

....

5.4 COUPON STATUS INDICATORS

....

5.4.2 C Checked-in – Indicates the passenger is entitled to board. has made 

his/her presence known to the operating carrier personally or via 

electronic means (ei.ge. a self-service device). It may indicate that the 

customer has checked baggage and/or secured a boarding pass.

T2.12/P

....

Section 6 — Procedures

6.1 GENERAL

....

6.1.2 Tax and Special Fees/Charges codes shall be used as published in the IATA Airline 

Coding Directory section titled “ISO Codes and IATA Currency Codes and

Ticket Code for Taxes, Fees and Charges”. The tax/fee/charge code “XT” shall not be used 

for transmission of tax/fee/change data in electronic tickets and shall not be present in the 

fare calculation of the ticket.
T11

6.9 VOID ORIGINAL ISSUE OR EXCHANGE/REISSUE

...

6.9.3 Void Exchange/Reissue

...

6.9.3.5 When the Validating Carrier receives a Void message to cancel an ‘ET to EMDS Exchange/Reissue’ request and the EMD-S is already at used status as a result of the

presence of the Consumed at Issuance Indicator in the Issuance request, the Validating 

Carrier shall update the Coupon Status Indicator of the EMD-S value coupon from ‘F’ to 

‘V’ for Void and change the coupon status of the exchanged/reissued ET flight coupon 

to ‘O’ for ‘Open for Use’ and transmit a Settlement Authorization Code or deny the 

request.

.....
T10

RESOLUTION 722g

Attachment ‘B’

ELECTRONIC TICKET MESSAGE CONSTRUCTION MATRIX –NEUTRAL MESSAGES

....ELEMENT DESCRIPTION

Transaction NO CHAR.

A, N OR 

A/N

ISSUANCE 

(INFORMATIONATA ONLY)DISPLAY HISTORY 

DISPLAY

EXCHANGE/RE

ISSUE REFUND RESERVATION CHANGE

SYSTEM 

CANCEL

REFUND 

CANCEL VOID

Action code -> S (I-ATA ONLY) D H E R A X,Y Z V,W

RESOLUTION 722g/20.61 REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP

...

Tax/Fee/Charge Data at the Ticket Coupon Level

...........................................................

Coupon Tax Airport Code 5A C C C

Coupon Tax Reported Amount 11A/N C C C

Coupon Tax Currency Type 4AN C C C

Coupon Tax Applicable Amount 11A/N C C C

Segment Tax Airport Codes 6A C C C
T8

ELEMENT 

DESCRIPTION

Transaction CHAR. 

A, N 

OR 

A/N

ISSUANCE

(INFORMATION 

– ATA ONLY)

DISPLAY HISTORY 

DISPLAY

EXCHANGE/

REISSUE

REFUND RESERVATIONS 

CHANGE

SYSTEM 

CANCEL

REFUND 

CANCEL

VOID

Action Code --

->

S(I-ATA ONLY) D H E R A X,Y Z V,W

RESOLUTION 

722 G

REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP

...

Carrier Fee 

Amount

12 A/N C C C

Carrier Fee 

Application 

Code

2 A/N C C C

Carrier Fee 

Approval Code 

(Credit Card)

6 A/N C C C

Carrier Fee 

Code

3 A/N C C C

Carrier Fee 

Commercial 

Name

30 A/N C C C C

...

Carrier Fee 

Tax on Tax 

Currency Code

3 A/N C C C

Carrier Fee To 

Airport/City 

Code

5 A/N C C C

...

T2.9/P

ELEMENT DESCRIPTION

Transaction

NO CHAR

A, N OR A/N DISPLAY

Action code ---> D

RESOLUTION 722 G REQ RESP

...

In Connection With Coupon Number 1 N C

In Connection With Document Number 14 13 A/N C

In Connection With Qualifier 1 N C

......

Filing Period: Effective Date:

1 March - 1 June 2012

13 April 2012
RESOLUTION 722h

ELECTRONIC TICKET – GROUND HANDLING

(amending)

T2.3/P

PSC(32 33)722h Expiry: Indefinite

Type: B

.....

Section 3 – Definitions

....

3.2 COUPON STATUS INDICATORS

....

3.2.2 C Checked-In – Indicates that a the passenger is entitled to board. has 

been allocated a seat or accepted for standby on a specific flight, either 

in person by the Operating Carrier/Ground Handler or via electronic 

means e.g., self-service device. It may indicate that the passenger has 

checked baggage and/or secured a boarding pass.

....

T2.13/P

3.2.8 N Coupon Notification — Indicates coupon data for a coupon(s) not showing a 

final status of E, F, G, P, R, or X, or Z and for which control of the coupon is not 

provided. 

....

T2.10/P

Section 3 – Definitions

...

3.5 ELECTRONIC MISCELLANEOUS DOCUMENT (EMD) - An electronic record 

issued by a Member or its authorized agent, in accordance with applicable tariffs, for 

residual value or for the collection of miscellaneous charges. An EMD must be either 

an EMD-A or an EMD-S. 

....

T2.8/P

Section 5 – Technical Specifications

...

5.3 MESSAGES

...

5.3.3.7 System Update — A request from a Ground Handler to an Operating Carrier or 

from an Operating Carrier to a Ground Handler to associate or disassociate an EMD-A 

coupon(s) to or from an ET coupon. Response either acknowledges or denies the 

request.
RESOLUTION 722h

Attachment ‘B’

MESSAGE CONSTRUCTION MATRIX – GROUND HANDLING MESSAGES

T8

ELEMENT DESCRIPTION

Transaction CHAR. 

A, N 

OR 

A/N

DISPAY AIRPORT 

CONTROL 

REQUEST –

GROUND 

HANLDLING)

CHANGE OF 

STATUS

REDIRECT EMERGENCY 

LOCK

UNSOLICITED 

AIRPORT 

CONTROL –

GROUND 

HANDLING

SYSTEM 

UPDATE

Action Code ---> D G C N M K U

Resolution 722 h REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP

...

Carrier Fee Expiry Date 

(Applicable 722g)

4 A/N

...

Carrier Fee Tax on Tax 

Currency Code

(Applicable 722g)

3 A/N

...

T10

ELEMENT DESCRIPTION

Transaction CHAR. 

A, N 

OR A/N

DISPLAY

AIRPORT CONTROL 

REQUEST – GROUND 

HANDLING

CHANGE OF STATUS REDIRECT AIRPORT 

CONTROL EMERGENCY LOCK 

UNSOLICITED AIRPORT 

CONTROL – GROUND 

HANDLING

Action code -> D G C N M A

RESOLUTION 722h REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP

...

Tax/Fee/Charge Data at the Ticket 

Coupon Level

.................

Coupon Tax Airport Code (Applicable 

722f/722g) 5A

Coupon Tax Reported Amount 

(Applicable 722f/722g)

11A

N

Coupon Tax Currency Type (Applicable 

722f/722g) 4AN

Coupon Tax Applicable Amount 

(Applicable 722f/722g)

11A

N

Segment Tax Airport Codes (Applicable 

722f/722g) 6A

Filing Period: Effective Date:

1 March - 1 June 2012

13 April 2012
RESOLUTION 725a

MISCELLANEOUS CHARGES ORDER

(MCO) – ISSUANCE AND HONOURING PROCEDURES BY MEMBERS 

(amending)

PSC(24 33)725 Expiry: Indefinite

Type: A

T4

.....

Section 5 – Electronic Miscellaneous Documents

5.1. ELECTRONIC MISCELLANEOUS DOCUMENT (EMD) FEE CALCULATION

5.2 Fee Calculation shall be provided on an EMD for the entire EMD itinerary when 

there is no Coupon Value data element present.

5.3 All amounts shall be in the currency of payment 

5.4 When equipment constraints prohibit the parentheses, an asterisk(s) may be 

used.

5.5 Routing Sequence shall be shown as follows:

5.5.1 List city codes and carrier codes in alternating order, separated by a space.

Example:

LON_AF_PAR_LH_FRA

Note 1: The underlining shows where spaces are to occur, but the underlining shall not 

appear on the ticket.

Note 2: Three-letter airline designators shall appear in the Fee Calculation as set forth 

in Resolution 722, Attachment ‘C’, Key, paragraph 3.

Note 3: The carrier in the Fee Calculation should be the Marketing Carrier

5.5.2 Show all routing points that represent the beginning or end of a segment;

5.5.3 When multiple identical services apply for one coupon/portion of travel, the total 

for this coupon/portion of travel shall be shown in the Fee Calculation. In the below 

example there are 1 service charge of EUR66.00 on LHR-SIN coupon and 2 service 

charges of EUR66.50 each on SIN-SYD coupon.

Example:

LON_6X_SIN66.00_6X_SYD133.00EUR199.00END

5.5.4 Separate EMDs shall be issued when multiple non-identical services apply for 

one coupon/portion of travel. Service itineraries expressed in the Fee Calculation shall 

be shown sequentially.

5.6 Precede by the symbol “X/” any point on the routing at which no stopover is 

permitted.
T4

5.7 When there is a break in the service itinerary, replace the carrier code with an 

oblique and a hyphen “/-”.

Example:

BOS_BB_NYC66.00/-WAS_CC_FRA100.00END

5.8 When a fee covers multiple segments which include a surface sector, replace the 

carrier code with two obliques “//”.

Example:

BOS_BB_NYC//WAS_CC_FRA100.00END

5.9 Show the total sum of the Fee Calculation entries as the last entry, preceded by 

the ISO currency code of the currency of payment. 

5.10 END - denotes end of the Fee Calculation.

5.11 Items shall be separated by spaces except where alphabetic characters are 

followed by numerics or signs or vice versa. A space shall, however, be maintained 

between a location identifier and an airline designator whether or not the airline 

designator is a numeric-alpha designator. At such time as three-letter airline designators 

are implemented, the space preceding these designators shall be replaced by a period. 

5.12 Fee Calculation Examples

The following examples demonstrate the intended use of the Fee Calculation on an 

Electronic Miscellaneous Document.

This example shows two fees priced, one per segment:

LON_6X_SIN66.00_6X_SYD100.00EUR166.00END

This example shows one fee priced over more than one segment:

LON_6X_SIN_6X_SYD166.00EUR166.00END

This example shows two fees, both priced over more than one segment on a return 

itinerary:

LON_6X_SIN_6X_SYD166.00_6X_SIN_6X_LON166.00EUR332.00END

This example shows a break in service between two fees:

LON_6X_FRA100.00/-SIN_6X_SYD166.00EUR266.00END

This example shows a break in service between two fees sequentially priced over more 

than one segment (LON-SIN-SYD appears twice in the passenger itinerary):

LON 6X SIN 6X SYD100.00/-LON 6X SIN 6X SYD50.00GBP150.00END

Filing Period: Effective Date:

1 March - 1 June 2012

13 April 2012
RESOLUTION 725b

MISCELLANEOUS CHARGES ORDER

(MCO) – ISSUANCE AND HONOURING PROCEDURES (AGENTS)

(amending)

PSC(24 33)725b Expiry: Indefinite

Type: A

T4

.....

Section 5 – Electronic Miscellaneous Documents

5.1. ELECTRONIC MISCELLANEOUS DOCUMENT (EMD) FEE CALCULATION

5.2 Fee Calculation shall be provided on an EMD for the entire EMD itinerary when 

there is no Coupon Value data element present.

5.3 All amounts shall be in the currency of payment 

5.4 When equipment constraints prohibit the parentheses, an asterisk(s) may be 

used.

5.5 Routing Sequence shall be shown as follows:

5.5.1 List city codes and carrier codes in alternating order, separated by a space.

Example:

LON_AF_PAR_LH_FRA

Note 1: The underlining shows where spaces are to occur, but the underlining shall not 

appear on the ticket.

Note 2: Three-letter airline designators shall appear in the Fee Calculation as set forth 

in Resolution 722, Attachment ‘C’, Key, paragraph 3.

Note 3: The carrier in the Fee Calculation should be the Marketing Carrier

5.5.2 Show all routing points that represent the beginning or end of a segment;

5.5.3 When multiple identical services apply for one coupon/portion of travel, the total 

for this coupon/portion of travel shall be shown in the Fee Calculation. In the below 

example there are 1 service charge of EUR66.00 on LHR-SIN coupon and 2 service 

charges of EUR66.50 each on SIN-SYD coupon.

Example:

LON_6X_SIN66.00_6X_SYD133.00EUR199.00END

5.5.4 Separate EMDs shall be issued when multiple non-identical services apply for 

one coupon/portion of travel. Service itineraries expressed in the Fee Calculation shall 

be shown sequentially.

5.6 Precede by the symbol “X/” any point on the routing at which no stopover is 

permitted.
T4

5.7 When there is a break in the service itinerary, replace the carrier code with an 

oblique and a hyphen “/-”.

Example:

BOS_BB_NYC66.00/-WAS_CC_FRA100.00END

5.8 When a fee covers multiple segments which include a surface sector, replace the 

carrier code with two obliques “//”.

Example:

BOS_BB_NYC//WAS_CC_FRA100.00END

5.9 Show the total sum of the Fee Calculation entries as the last entry, preceded by 

the ISO currency code of the currency of payment. 

5.10 END - denotes end of the Fee Calculation.

5.11 Items shall be separated by spaces except where alphabetic characters are 

followed by numerics or signs or vice versa. A space shall, however, be maintained 

between a location identifier and an airline designator whether or not the airline 

designator is a numeric-alpha designator. At such time as three-letter airline designators 

are implemented, the space preceding these designators shall be replaced by a period. 

5.12 Fee Calculation Examples

The following examples demonstrate the intended use of the Fee Calculation on an 

Electronic Miscellaneous Document.

This example shows two fees priced, one per segment:

LON_6X_SIN66.00_6X_SYD100.00EUR166.00END

This example shows one fee priced over more than one segment:

LON_6X_SIN_6X_SYD166.00EUR166.00END

This example shows two fees, both priced over more than one segment on a return 

itinerary:

LON_6X_SIN_6X_SYD166.00_6X_SIN_6X_LON166.00EUR332.00END

This example shows a break in service between two fees:

LON_6X_FRA100.00/-SIN_6X_SYD166.00EUR266.00END

This example shows a break in service between two fees sequentially priced over more 

than one segment (LON-SIN-SYD appears twice in the passenger itinerary):

LON 6X SIN 6X SYD100.00/-LON 6X SIN 6X SYD50.00GBP150.00END

Filing Period: Effective Date:

1 March - 1 June 2012

13 April 2012
RESOLUTION 725d

AUTOMATED MISCELLANEOUS CHARGES ORDER (MCO) — NEUTRAL

(COUPON-BY-COUPON)

(amending)

PSC(32 33)725d Expiry: Indefinite 31 December 2013

 Type: B

T2.32/P

RESOLVED that:

Applicable to IATA BSPs: the provisions of this resolution shall apply in respect of imprinting 

on blank card or plain paper. No exchange value coupon is produced.

The provisions of this resolution shall expire 31 December 2013.

Filing Period: Effective Date:

1 March - 1 June 2012

13 April 2012

RESOLUTION 725f

ELECTRONIC MISCELLANEOUS DOCUMENT — AIRLINE

(amending)

PSC(32 33)725f Expiry: Indefinite

Type: B

T2.10/P

Section 3 – Definitions

...

3.5 ELECTRONIC MISCELLANEOUS DOCUMENT (EMD) - An electronic record 

issued by a Member or its authorized agent, in accordance with applicable tariffs, for 

residual value or for the collection of miscellaneous charges. An EMD must be either 

an EMD-A or an EMD-S.

.....

 T2.3/P

T2.24/P

Section 5 – Technical Specifications

...

5.4 COUPON STATUS INDICATORS

5.4.1 A Airport Control - Indicates a carrier or Ground Handler has secured the EMD 

value coupon(s) prior to use. 

....

5.4.2 C Checked-In – Indicates that the service(s) associated to an ET flight coupon 

has been recognized or acknowledged. the passenger has presented an EMD to the 

Marketing or Operating Carrier. (Oonly applicable to EMD-A).

...

5.4.6 I Irregular Operations - Indicates the carrier holding control is extending control 

beyond the normal 72 hour period provided for under Airport Control, Checked-In or 

Lifted/Boarded status. This extension may not exceed 7 days from original scheduled 

departure of the associated ET flight coupon (only applicable to EMD-A). 

...
5.4.10 R Refunded - Indicates the unused value of the EMD value coupon(s) has 

been returned/remitted to the passenger/purchaser. 

...

5.4.12 U Unavailable - Indicates the Validating Carrier has determined the EMD value 

coupon(s) is no longer available for use as issued. 

5.4.13 V Void - Indicates cancellation of the entire EMD sale or exchange/reissue

transaction within the Validating Carrier’s reporting period. 

5.4.14 Y Refund Taxes/Fees/Charges Only - Indicates the Validating Carrier has 

determined the EMD value coupon(s) is no longer available for use as issued ticketed. 

....

T2.8/P

Section 5 – Technical Specifications

...

5.5 MESSAGES

...

5.5.3 The following are EMD Messages:

...

5.5.3.4 System Update — A request from a carrier to associate or disassociate an 

EMD-A coupon(s) to or from an ET coupon. Response either acknowledges or denies 

the request. 

T2.25/P

5.5.3.5 Unsolicited Billing – A message generated by the Operating Carrier to advise 

the Billing Carrier of the Flown/Used EMD/Coupon(s) information when a special 

settlement agreement exists. This shall provide the Billing Carrier the information 

needed to settle the EMD/Coupon(s) with the Validating Carrier.

T2.11/P

Section 6 - Procedures

...

6.1 GENERAL

...
6.1.10 EMD-Associated

...

6.1.10.3 Prior to Upon coupon status updates to Closed, Exchanged/Reissued, Refund, 

Suspend or Void of an associated EMD-A record value coupon(s), the EMD-A record

value coupon(s) shall be disassociated from the corresponding ET record flight 

coupon(s) using a System Update message for disassociation. 

T2.1/P

T2.2/P

6.5 CONTROL

...

6.5.7 EMD-Stand-alone

6.5.7 When a carrier requesting control of an EMD-A value coupon(s) associated to ET 

an flight coupon(s) is not the Operating Carrier of the requested coupon(s), the 

Validating Carrier, if relinquishing control, shall disassociate the EMD-A value coupon(s) 

from the associated ET flight coupon(s) 

6.5.7.1 Any carrier may request control of an EMD value coupon(s) from the Validating 

Carrier in accordance with EMD bilateral agreements.

6.5.8 EMD-Associated

6.5.8.1 Any carrier holding control of an ET flight coupon(s) may request control of the 

corresponding EMD value coupon(s) from the Validating Carrier in accordance with 

EMD bilateral agreements.

Note: Subsequent paragraphs to be renumbered.
T2.25/P

...

6.5.11 Code Share

6.5.11.1 For special settlement arrangements where the Billing Carrier will settle the 

Flown/Used coupon(s) with the Validating Carrier, the Operating Carrier must include 

the Billing Airline Designator in the Change Of Status message to the Validating Carrier.

...

6.5.11.3 When the Operating Carrier receives the response message for the Change of 

Status Message including the Settlement Authorization code for the Billing Carrier, they 

will send an Unsolicited Airport Control Billing message to the Billing Carrier including 

the Settlement Authorization code received from the Validating Carrier. The Coupon 

Statuses shall be as received by the Operating Carrier and the EMD/Coupon(s) to be 

settled shall have F status and the Settlement Authorization code included. The 

Transaction Action is “L” for Unsolicited Billing message as shown in the Message 

Construction Matrix in Attachment B. 

....
T2.25/P

RESOLUTION 725f

Attachment ‘B’

ELECTRONIC MISCELLANEOUS DOCUMENT MESSAGE CONSTRUCTION 

MATRIX — AIRLINE MESSAGES






T2.23/P

ELEMENT 

DESCRIPTION

Transaction CHAR. 

A, N 

OR 

A/N

DISPLAY REQUEST AIRPORT 

CONTROL

CHANGE 

OF STATUS

SYSTEM 

UPDATE

Action Code ---> D, J B C U

RESOLUTION 725f REQ RESP REQ RESP REQ RESP REQ RESP

...

Additional Services 

Attribute Group

3 A/N O O

Additional Services 

Attribute Sub-Group

3 A/N O O

...

Additional Services 

Industry Carrier 

Indicator

1 A/N O O

...

Additional Services 

Service Type

1 A/N O O

...

T8

ELEMENT 

DESCRIPTION

Transaction CHAR. 

A, N 

OR 

A/N

DISPLAY REQUEST AIRPORT 

CONTROL

CHANGE 

OF STATUS

SYSTEM 

UPDATE

Action Code ---> D, J B C U

RESOLUTION 725 f REQ RESP REQ RESP REQ RESP REQ RESP

...

Carrier Fee Code

(Applicable 725g)

32 A/N

...

Carrier Fee Expiry Date 

(Applicable 725g)

4 A/N

Carrier Fee Fare 

Component Number

(Applicable 725g)

2 A/N

Carrier Fee Fare 

Component Rule Code

(Applicable 725g)

3 A/N

Carrier Fee Fare 

Component Rule 

Matching Fare Class

(Applicable 725g)

8 A/N

Carrier Fee Fare 

Component Rule 

Number

(Applicable 725g)

4 A/N

Carrier Fee Fare 

Component Tariff 

Number

(Applicable 725g)

3 N

...

Carrier Fee Form of 

Payment Credit Card 

Vendor Code

(Applicable 725g)

2 A/N

...

Carrier Fee Owner

(Applicable 725g)

3 A/N

...

Carrier Fee Tax on Tax 

Currency Code

(Applicable 725g)

3 A/N

...
T10

ELEMENT DESCRIPTION

Transaction NO CHAR.

A, N OR A/N DISPLAY REQUEST AIRPORT CONTROL CHANGE OF STATUS SYSTEM UPDATE

Action code -> D B C U

RESOLUTION 725f REQ RESP REQ RESP REQ RESP REQ RESP

...

Tax/Fee/Charge Data at the Ticket Coupon 

Level

................................................

Coupon Tax Airport Code 5A C C

Coupon Tax Reported Amount 11AN C C

Coupon Tax Currency Type 4AN C C

Coupon Tax Applicable Amount 11AN C C

Segment Tax Airport Codes 6A C C
T2.20/P

ELEMENT DESCRIPTION

Transaction CHAR. 

A, N 

OR 

A/N

DISPLAY REQUEST AIRPORT 

CONTROL

CHANGE 

OF STATUS

SYSTEM 

UPDATE

Action Code ---> D B C U

RESOLUTION 725f REQ RESP REQ RESP REQ RESP REQ RESP

...

Product Characteristic Type 35 A/N O O

Product Characteristic 

Value

70 A/N O O

...

Filing Period: Effective Date:

1 March - 1 June 2012

13 April 2012
RESOLUTION 725g

ELECTRONIC MISCELLANEOUS DOCUMENT — NEUTRAL

(amending)

PSC(32 33)725g Expiry: Indefinite

Type: B

T2.10/P

Section 3 – Definitions

...

3.7 ELECTRONIC MISCELLANEOUS DOCUMENT (EMD) - An electronic record 

issued by a Member or its authorized agent, in accordance with applicable tariffs, for 

refundable value or for the collection of miscellaneous charges. An EMD must be either 

an EMD-A or an EMD-S. 

....

T2.3/P

Section 5 – Technical Specifications

...

5.4 COUPON STATUS INDICATORS

5.4.1 A Airport Control - Indicates a carrier or Ground Handler has secured the EMD 

value coupon(s) prior to use. 

5.4.2 C Checked-In – Indicates that the service(s) associated to an ET flight coupon 

has been recognized or acknowledged. the passenger has presented an EMD to the 

Marketing or Operating Carrier. 

(Oonly applicable to EMD-A).

T2.24/P

5.4.3 E Exchanged/Reissued - Indicates the value of the EMD value coupon(s) has 

been used as in payment for a new transaction.

5.4.4 F Flown/Used - Indicates the EMD value coupon has been used and is now 

eligible for billing/revenue reporting. Status to be set by the carrier holding control only. 

5.4.5 I Irregular Operations - Indicates the carrier holding control is extending control 

beyond the normal 72 hour period provided for under Airport Control, Checked-In or 

Lifted/Boarded status. This extension may not exceed 7 days from original scheduled 

departure of the associated ET flight coupon (only applicable to EMD-A). 
5.4.7 O Open For Use - Indicates the EMD value coupon(s) is available for use

eligible for all coupon status updates. 

5.4.8 R Refunded - Indicates the unused value of the EMD value coupon(s) has been 

returned/remitted to the passenger/purchaser.

5.4.9 S Suspended - Indicates the Validating Carrier has restricted the use of the 

EMD value coupon(s). 

5.4.10 U Unavailable - Indicates the Validating Carrier has determined the EMD value 

coupon(s) is no longer available for use as issued ticketed.

5.4.11 V Void - Indicates cancellation of the entire EMD sale or exchange/reissue

transaction within the Validating Carrier’s reporting period. 

5.4.12 Y Refund Taxes/Fees/Charges Only - Indicates the Validating Carrier has 

determined the EMD value coupon(s) is no longer available for use as issued ticketed. 

....

T2.29/P

T11

Section 6 - Procedures

...

6.6 VOID

...

6.6.9.1 EMD-Stand-alone

... 

6.6.11 When the Validating Carrier receives a Void message to cancel an ‘EMD to 

EMD-S Exchange/Reissue’ request and the EMD-S is already at used status as a result 

of the presence of the Consumed at Issuance Indicator in the Issuance request, the 

Validating Carrier shall update the Coupon Status Indicator of the EMD-S value coupon 

from ‘F’ to ‘V’ for Void and change the coupon status of the exchanged/reissued EMD 

value coupon to ‘O’ for ‘Open for Use’ and transmit a Settlement Authorization Code or 

deny the request.

...

6.7 REFUND CANCEL

...

6.7.3 The data elements to be included in the ‘Refund Cancel’ message are shown in 

the Message Construction Matrix in IATA Resolution 722, Attachment ‘B.

...
6.8 SYSTEM CANCEL

...

6.8.2 The data elements to be included in the ‘System Cancel’ message are shown in 

the Message Construction Matrix in IATA Resolution 722, Attachment ‘B’.

...

6.8.7 EMD-Stand-alone

6.8.7.1 When the Validating Carrier receives a system cancel request and the EMD is 

already at used status as a result of the presence of the ‘Consumed at Issuance 

Indicator’ in the issuance request the Validating Carrier shall update the Coupon Status 

Indicator from ‘F’ to ‘V’ for Void. If the original request was an ‘Exchange/Reissue’ EMD 

message, the Validating Carrier shall update the Coupon Status Indicator of the 

exchanged/reissued EMD value coupon with ‘O’ for ‘Open For Use’, and if applicable, 

update the Coupon Status Indicator of the new EMD from ‘F’ to ‘V’ for Void.

....

RESOLUTION 725g

Attachment ‘B’

ELECTRONIC MISCELLANEOUS DOCUMENT MESSAGE

CONSTRUCTION MATRIX — NEUTRAL MESSAGES

T2.23/P

ELEMENT 

DESCRIPTION

Transaction CHAR. 

A, N 

OR 

A/N

ISSUANCE DISPLAY HISTORY 

DISPLAY

EXCHANGE/

REISSUE

REFUND SYSTEM 

CANCEL

REFUND 

CANCEL

VOID

Action Code --

->

S D H E R X,Y Z V,W

RESOLUTION 

725 G

REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP

...

Additional

Services 

Attribute Group

3 A/N O O O O O O

Additional 

Services 

Attribute SubGroup

3 A/N O O O O O O

...

Additional 

Services 

Industry 

Carrier 

Indicator

1 A/N O O O O O O

...

Additional 

Services 

Service Type

1 A/N O O O O O O

...
T8

ELEMENT 

DESCRIPTION

Transaction CHAR. 

A, N 

OR 

A/N

ISSUANCE DISPLAY HISTORY 

DISPLAY

EXCHANGE/

REISSUE

REFUND SYSTEM 

CANCEL

REFUND 

CANCEL

VOID

Action Code --

->

S D H E R X,Y Z V,W

RESOLUTION 

725 G

REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP

...

Carrier Fee 

Code

32 A/N

...

Carrier Fee 

Fare 

Component 

Number

2 A/N C C C

Carrier Fee 

Fare 

Component 

Rule Code

3 A/N C C C

Carrier Fee 

Fare 

Component 

Rule Matching 

Fare Class

8 A/N C C C

Carrier Fee 

Fare 

Component 

Rule Number

4 A/N C C C

Carrier Fee 

Fare 

Component 

Tariff Number

3 N C C C

...

Carrier Fee 

Owner

3 A/N C C C

...

Carrier Fee 

Tax on Tax 

Currency Code

3 A/N C C C

Carrier Fee To 

Airport City 

Code

5 A/N C C C

...
T11

ELEMENT 

DESCRIPTION

Transaction CHAR. 

A, N 

OR 

A/N

ISSUANCE DISPLAY HISTORY DISPLAY EXCHANGE/

REISSUE

REFUND SYSTEM 

CANCEL

REFUND 

CANCEL

VOID

Action Code --

->

S(I-ATA 

ONLY)

D H E R X,Y Z V,W

RESOLUTION 

725 G

REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP

...

Consumed At 

Issuance 

Indicator

1 A/N C C C

...

T10

ELEMENT DESCRIPTION

Transaction NO CHAR.

A, N OR A/N ISSUANCE DISPLAY HISTORY DISPLAY EXCHANGE/REISSUE REFUND SYSTEM CANCEL REFUND CANCEL VOID

Action code -> S D H E R X,Y Z V,W

RESOLUTION 725g REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP

...

Tax/Fee/Charge Data at the Ticket Coupon Level

...........................................................

Coupon Tax Airport Code 5A C C C

Coupon Tax Reported Amount 11AN C C C

Coupon Tax Currency Type 4AN C C C

Coupon Tax Applicable Amount 11AN C C C

Segment Tax Airport Codes 6A C C C
T2.9/P

ELEMENT DESCRIPTION

Transaction

NO CHAR

A, N OR A/N

Action code --->

RESOLUTION 725G

...

In Connection With Document Number 14 13 A/N

......

T2.20/P

ELEMENT 

DESCRIPTION

Transaction CHAR. 

A, N 

OR 

A/N

ISSUANCE DISPLAY HISTORY 

DISPLAY

EXCHANGE/

REISSUE

REFUND SYSTEM 

CANCEL

REFUND 

CANCEL

VOID

Action Code --

->

S D H E R X,Y Z V,W

RESOLUTION 

725 G

REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP

...

Product 

Characteristic 

Type

35 A/N O O O O O

Product 

Characteristic 

Value

70 A/N O O O O O

...

T2.17/P

ELEMENT 

DESCRIPTION

Transaction CHAR. 

A, N 

OR 

A/N

ISSUANCE DISPLAY HISTORY DISPLAY EXCHANGE/

REISSUE

REFUND SYSTEM 

CANCEL

REFUND 

CANCEL

VOID

Action Code ---

>

S(I-ATA 

ONLY)

D H E R X,Y Z V,W

RESOLUTION 

725 G

REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP

...

Reason for 

Issuance Sub 

Code

3 A/N M M C M M M C

...

Filing Period: Effective Date:

1 March - 1 June 2012

13 April 2012
RESOLUTION 725h

ELECTRONIC MISCELLANEOUS DOCUMENT — GROUND HANDLING

(amending)

PSC(32 33)725h Expiry: Indefinite

Type: B

T2.3/P

Section 3 – Definitions

...

3.2 COUPON STATUS INDICATORS

3.2.1 A Airport cControl - Indicates a carrier or Ground Handler has secured the 

EMD value coupon(s) prior to use. 

3.2.2 C Checked-In – Indicates that the service(s) associated to an ET flight coupon 

has been recognized or acknowledged. the passenger has presented an EMD to the 

Marketing or Operating Carrier and the delivery of the service has been accepted.

(Oonly applicable to EMD-A).

T2.24/P

3.2.3 E Exchanged/Reissued - Indicates the value of the EMD value coupon(s) has 

been used in payment for a new transaction. 

3.2.4 F Flown/Used - Indicates the value associated with the EMD value coupon has 

been used and is now eligible for billing/revenue reporting. Status to be set by the 

carrier holding control only. 

...

3.2.12 U Unavailable - Indicates the Validating Carrier has determined the EMD value 

coupon(s) is no longer available for use as issued ticketed. 

3.2.13 V Void - Indicates cancellation of the entire electronic sale record EMD sale or 

exchange/reissue transaction within the Validating Carrier’s reporting period. 

3.2.14 Y Refund Taxes/Fees/Charges Only - Indicates the Validating Carrier has 

determined the EMD value coupon(s) is no longer available for use as issued ticketed. 

5.4.15 3.2.15 Z Closed - Indicates the Validating Carrier has determined that the EMD 

value coupon(s) is not available for use. 
T2.10/P

Section 3 – Definitions

...

3.5 ELECTRONIC MISCELLANEOUS DOCUMENT (EMD) - An electronic record 

issued by a Member or its authorized agent, in accordance with applicable tariffs, for 

residual value or for the collection of miscellaneous charges. An EMD must be either 

an EMD-A or an EMD-S. 

....

T2.8/P

Section 5 – Technical Specifications

...

5.3 MESSAGES

...

5.3.3.4 System Update — A request from a Ground Handler to an Operating Carrier or 

from an Operating Carrier to a Ground Handler to associate or disassociate an EMD-A 

coupon(s) to or from an ET coupon. Response either acknowledges or denies the 

request.

....

RESOLUTION 725h

Attachment ‘B’

ELECTRONIC MISCELLANEOUS DOCUMENT MESSAGE

CONSTRUCTION MATRIX — GROUND HANDLING

T2.23/P

ELEMENT DESCRIPTION

Transaction CHAR. 

A, N 

OR 

A/N

DISPAY AIRPORT 

CONTROL 

REQUEST –

GROUND 

HANLDLING)

CHANGE OF 

STATUS

SYSTEM 

UPDATE

Action Code ---> D G C U

Resolution 725 h REQ RESP REQ RESP REQ RESP REQ RESP

...

Additional Services 

Attribute Group

3 A/N O O

Additional Services 

Attribute Sub-Group

3 A/N O O

...

Additional Services Industry 

Carrier Indicator

1 A/N O O

...

Additional Services Service 

Type

1 A/N O O

...
T8

ELEMENT DESCRIPTION

Transaction CHAR. 

A, N 

OR 

A/N

DISPAY AIRPORT 

CONTROL 

REQUEST –

GROUND 

HANLDLING)

CHANGE OF 

STATUS

SYSTEM 

UPDATE

Action Code ---> D G C U

Resolution 725 h REQ RESP REQ RESP REQ RESP REQ RESP

...

Carrier Fee Code

(Applicable 725g)

32 A/N

...

Carrier Fee Tax on Tax 

Currency Code

(Applicable 725g)

3 A/N

...
T10

ELEMENT DESCRIPTION

Transaction NO CHAR.

A, N OR A/N DISPLAY AIRPORT CONTROL REQUEST – GROUND HANDLING CHANGE OF STATUS SYSTEM UPDATE

Action code -> D G C U

RESOLUTION 725h REQ RESP REQ RESP REQ RESP REQ RESP

...

Tax/Fee/Charge Data at the Ticket Coupon 

Level

...

Coupon Tax Airport Code

(applicable 725f and 725g) 5A

Coupon Tax Reported Amount

(applicable 725f and 725g) 11AN

Coupon Tax Currency Type

(applicable 725f and 725g) 4AN

Coupon Tax Applicable Amount

(applicable 725f and 725g) 11AN

Segment Tax Airport Codes

(applicable 725f and 725g) 6A

T2.20/P

ELEMENT 

DESCRIPTION

Transaction CHAR. 

A, N 

OR 

A/N

DISPLAY REQUEST AIRPORT CONTROLGROUND HANDLINGCHANGE 

OF STATUS

SYSTEM 

UPDATE

Action Code - D G C U

RESOLUTION 725 

h

REQ RESP REQ RESP REQ RESP REQ RESP

...

Product 

Characteristic Type 

35 A/N O O

Product 

Characteristic 

Value

70 A/N O O

...

Filing Period: Effective Date:

1 March - 1 June 2012

13 April 2012
RESOLUTION 726e

MULTIPLE PURPOSE DOCUMENT (MPD) — NEUTRAL, CARBONISED, MANUAL

(amending)

PSC(32 33)726e Expiry: Indefinite 31 December 2013

 Type: B

T2.32/P

RESOLVED that:

In countries/Areas where a Billing and Settlement Plan (BSP) has been implemented the 

provisions of this resolution shall apply only in respect of MPDNMs supplied in a virtual 

format version distributed and issued via IATA BSPlink. The provisions of this resolution shall 

expire 31 December 2013.

Filing Period: Effective Date:

1 March - 1 June 2012

13 April 2012

RESOLUTION 728

CODE DESIGNATORS FOR PASSENGER TICKET AND BAGGAGE CHECK

(amending)

PSC(32 33)728 Expiry: Indefinite

 Type: B

T9

RESOLVED that:

....

4.2 Special Fees and Charges Codes

Special Fees and Charges Codes are assigned to identify taxes, fees and charges 

which are collected at the time of ticket issuance, entered in the “TAX/FEE/CHARGE” 

box, and are paid or payable to government agencies and airport authorities. When 

applying to IATA for a new Special Fees and Charges Code or applying to use an ISO 

code, or advising IATA about amendments to an existing code, the Application Form in 

Attachment “B” supplied separately by the IATA Ticket Tax Box Service (TTBS) shall be 

used. Only one code will be assigned for the same type Special Fee or Charge for 

multiple airports within a country. If the same type of Special Fee or Charge has 

different rules for domestic/international, separate Special Fees or Charges Codes may 

be assigned by IATA. For a full listing of ticket codes, refer to the IATA Airline Coding 

Directory.
T2.35/P

...

4.2.1 Format for Code Assignment.

Members and System Providers shall be ready to receive and process alphanumeric 

TFCs codes in accordance with the provisions of this resolution no later than 30 June 

2012.
T5

...

7. FORM OR PAYMENT CODE

(mandatory)

...

CREDIT CARD CODES (APLPHA) 1, 3

...

Commercial Company Credit Cards International Payment Cards

Access Air ZA 

American Express/Optima Card AX2

Australian Bankcard AB

Bank of Boroda “Bobcard” BB

Bank of Hawaii BH

Bank Card of Japan BC 

Canara Bank “Cancard” CD 

Carte Aurore AU 

Carte Blanche CB2

Citizens and Southern National Bank CS 

Cofinoga Credit Card CG

Comites ID

Connecticut Bank and Trust Company CU 

Diamond Credit MD 

Discover Card DS

Diners Club/American Torch Club/Sun Diners Club DC2

Empire Card MT

Fédération Nationale de l'Industrie Hotelière FH 

HiperCard HC

Japan Credit Bureau JC2

Mastercard CA2

Million Credit Service MC

Nativa NT

OTB Card OT

Presto PR

Select Credit SR

Shoppers Charge SC
Trust Card TC

Union Credit UD

United Debit Credit Center UI

VISA International VI2

Walker Bankcard WB

Airline Credit Cards

Air New Zealand Travel Card NZ2

Alia Personal Credit Card RJ2

Aloha Airlines Credit Card TS

American Airlines Personal Credit Card AA2

China Airlines “Dynasty Travel Card” DT

Delta Air Lines Credit Card DL

Garuda Executive Credit Card GA2

Japan Airlines JALCARD JL2

Lufthansa Senator Card LH2

Qantas Airways Charge Card QF2

Universal Air Travel Plan (UATP) TP

Merchandising and Banking Cards

Bankcard New Zealand BZ2

Discover Card/Bravo Card/Private Issue Card —

issued by Novus Card Products DS2

...

Airline Industry Issued Card(s) — Industry Identifier “1”

1XXX Universal Air Travel Plan (UATP) (XXX is numeric airline code of contractor 

19XX AirPlus — licensee of Air Travel Card (XX is airline identifier)

1800 PassAge Credit Card — licensee of Air Travel Card (issued by Japan Air 

Lines)

Airline Issued Personal Cards - Industry Identifier “2”

2001 American Airlines Personal Credit Card

2006 Delta Air Lines Credit Card 

2081 Qantas Airways Charge Card

2086 Air New Zealand Travel Card

2126 Garuda Executive Credit Card

2131 Japan Airlines JALCARD

2151 Alia Personal Credit Card

2220 Lufthansa Senator Card 

Travel and Entertainment Cards — Industry Identifier “3” 

300000 to Diners Club

305999

309500 to

309599
34XX American Express

35XX Japan Credit Bureau

360000 to Diners Club/Carte Blanche

369999

37XX American Express/Optima Card 

380000 to Diners Club/Carte Blanche 

399999

3889 Diners Club Cards issued to GSA Federal Agent Agencies

Banking Industry Cards — Industry Identifier “4”

4XXX HiperCard

4XXX VISA International 

Banking Industry Cards, Expansion —Industry Identifier “5”

5XXXXX Access (Master Card) 

5602 Bankcard New Zealand 

Merchandising and Banking Cards —Industry Identifier “6”

601100 to 601199 – 644000 to 659900 Discover Card/Private Issue Card — Issued by 

Novus Card Products

Petroleum Industry — Industry Identifier “7” 

Telecommunications and Other Future Industry — Industry Identifier “8” 

Industry Identifier “0” and “9” — reserved for future assignment by ISO

Note: Industry credit card identifier codes vary in length from two to six digits and the 

number of Xs following the initial code indicate the number of variable digits which may 

be used.
Payment instruments, domestic usage only

Credito Directo payment AM BSP Mexico domestic voucher 

Cards issued by BC BC BSP Korea specific2

Cabal CL BSP Argentina, domestic card

Cards issued by Kookmin CN BSP Korea specific2

Cards issued by KEB EB BSP Korea specific2

Cards issued by Hyundai HD BSP Korea specific2

Reserved for future use KA BSP Korea specific2

Reserved for future use KB BSP Korea specific2

Cards issued by Lotte LC BSP Korea specific2

Cards issued by Nonghyub NH BSP Korea specific2

Visa Naranja NV BSP Argentina, domestic card

OCA OC BSP Uruguay, domestic card

Domestic payment voucher OV BSP Spain domestic voucher 

Domestic payment voucher OY BSP Spain domestic voucher 

Domestic payment voucher PC BSP Spain domestic voucher 

Reserved for future use PR BSP Chile specific

Paga Todo payment PT BSP Mexico domestic voucher 

Domestic payment voucher RC BSP Spain domestic voucher 

Cards issued by Shinhan SH BSP Korea specific2

Cards issued by HANA SK BSP Korea specific2

Cards issued by Samsung SW BSP Korea specific2

Tierra del Fuego TF BSP Argentina, domestic card

Tarjeta Naranja TN BSP Argentina, domestic card

Nativa NT BSP Argentina domestic card

Reserved for future use HC BSP Brazil specific

______________________________________________________________________

_2 In South Korea, cards are not accepted by merchants on the basis of the card brand but on the basis of 

the issuer's name. Hence a merchant has to sign a card acceptance agreement with every issuer.

Filing Period: Effective Date:

1 March - 1 June 2012

13 April 2012
RESOLUTION 762

AIRLINE DESIGNATORS

(amending)

P3

PSC(30 33)762 Expiry: Indefinite

 Type: B

RESOLVED that, the following rules shall apply to the assignment and use of airline 

designators for the entire airline and travel and tourism industry:

For the purposes of this Resolution,

“AIRLINE” means: an enterprise operating aircraft for commercial purposes which (i) 

performs scheduled or non-scheduled air transport services, or both, which are 

available to the public for carriage of passengers, mail and/or cargo and (ii) is certified 

for such purposes by the civil aviation authority of the state in which it is established.

“PUBLISHED SCHEDULE” means: a listing of the timing of air services and other 

schedule information available to the public in standard air transport industry guides.

1. USE OF AIRLINE DESIGNATORS

1.1 Those companies assigned an airline designator are to use such designator for 

reservations, schedules, timetables, telecommunications, ticketing, cargo 

documentation, legal, tariffs and/or other commercial/traffic purposes. Codes for use in 

baggage handling applications are defined in Resolution 769.

1.2 Notwithstanding anything in this Resolution to the contrary, where an airline's cargo 

division becomes a subsidiary company and an agreement is made whereby that 

subsidiary cargo company will purchase/utilize allocated space on its parent passenger 

aircraft for cargo; the cargo company may also use the two-character designator of the 

parent company, if agreed by both parties.

2. USE OF TWO-CHARACTER AND THREE-LETTER DESIGNATORS

Carriers and CRSs recognize the necessity of processing three-letter airline/CRS 

designators at some future date. All organizations having an IATA assigned two 

character designator shall continue to use such designator until such time as ATA and 

IATA Members agree on a conversion date for the use of three-letter designators by 

such organizations. All organizations airlines receiving an IATA assigned two-character 

designator, shall notify IATA of their desired assigned three-letter ICAO designator, and 

subsequently IATA will reserve an available that designator. 
It is also recognized that IATA will deplete all available two-character designators and 

that three-letter designators will need to be also processed. Therefore, when IATA 

exhausts the available supply of two-character designators, airlines/CRSs will be placed 

on a waiting list for an available two-character designator. Until such time as a twocharacter designator becomes available, the airline/CRSs will use its assigned threeletter designator for the purposes defined in paragraph 1. When a two-character 

designator becomes available the airline/CRS will have the option of using the twocharacter designator or three-letter designator, but not both. If the airline/CRS chooses 

not to use the two-character designator, it will become available for reassignment. The 

airline/CRS must decide whether it wishes to use the two-character designator within 

thirty days of it becoming available. The Joint ATA Passenger Council/IATA Passenger 

Services Conference (JPSC) shall annually review the airline industry requirements for 

airline designators.

3. USE OF AIRLINE DESIGNATORS BY RAILWAY, FERRY AND BUS COMPANIES

Railway, ferry, and bus companies with requirements for a designator for passenger 

transportation, for use in reservations, schedules, timetables or, tariff publishing, may be 

assigned a three-letter designator. Until such time as three-letter designators can be 

handled by airlines and computer reservations systems, such non airline companies 

shall also be assigned a duplicated two-character numeric-alpha designator in a 

controlled environment (see paragraph 5) drawn from designators assigned to nonscheduled passenger or cargo airlines.

4. ASSIGNMENT CRITERIA FOR NEW APPLICANTS

4.1 The following new applicants for Airline designators shall be assigned as a twocharacter (two-letter alpha, if available, or numeric-alpha, alpha-numeric) designator to:

and a three-letter designator:

4.1.1 2 airlines which are parties to the ATA Interline Traffic Agreement — Passenger 

(Resolution 5.65), the IATA Interline Traffic Agreement — Passenger (Resolution 

780/780e), or the IATA Interline Traffic Agreement — Cargo (Resolution 660) However, 

if such airline does not intend to conclude an interline traffic agreement within 90 days 

of assignment, the two-character designator shall be recalled and it shall be assigned a 

three-letter designator; until such time as three-letter designators can be handled by 

airlines and Computer Reservation Systems, such airlines shall also be assigned a 

duplicated airline designator in a controlled environment;

or

4.1.2 1 airlines publishing and operating scheduled air service in accordance with the 

definition of a scheduled air service contained in IATA Recommended Practice 1008 in 

standard air transport guides. However, if such airline does not intend to conclude an 

interline traffic agreement within 90 days of assignment, the two-character designator 

shall be recalled and it shall be assigned a three-letter designator; until such time as 

three-letter designators can be handled by airlines and Computer Reservation Systems, 

such airlines shall also be assigned a duplicated airline designator in a controlled 

environment.
4.1.3 airlines not qualifying under 4.1.1 or 4.1.2, with a requirement for an airline 

designator to participate in an airline industry shared telecommunication facility shall be 

assigned a Banded Code for message addressing and a three-letter designator.

4.1.4 a new entrant which does not yet meet the definition of “airline” for purposes of 

this Resolution may be granted a provisional airline designator code assignment when 

written notification is received from the civil aviation authority of the state in which it is 

established advising that the enterprise is substantially meeting the state's requirements 

for the issuance of a licence to operate commercial air transport services;

4.1.4.1 such provisional assignment shall be valid for a non-renewable period of six (6) 

months. Failure of the enterprise to meet the definition of “airline” for purposes of this 

Resolution within six (6) months of provisional assignment of the airline designator code 

will result in the formal recall of the code. A non-refundable processing charge shall 

apply to requests for provisional assignments of airline designator codes, in addition to 

all fees otherwise applicable.

4.2 Non-scheduled passenger or non-scheduled cargo airlines not qualifying under 

4.1.1, or 4.1.2 as of 1 June 2012 or 4.1.3 with a requirement for an airline designator 

shall be assigned a three-letter designator; until such time as three-letter designators 

can be handled by airlines and Computer Reservation Systems, such airlines shall also

be assigned a duplicated airline designator in a controlled environment.

P4.1

4.3 Non-airline Unit Load Device (ULD) owners who participate in the Interline ULD 

Control User Group (IULDUG) ULD area of the IATA Strategic Partnership Program

(two-letter controlled duplication and a three-letter beginning with “X”). Non-airline ULD 

owners who do not participate in the IULDUG ULD area of the IATA Strategic 

Partnership Program will not be eligible for a unique or controlled duplicate (see 

paragraph 5) code but shall be assigned a Banded Code and a three-letter code

beginning with “X”).

4.4 Computer Reservations Systems (CRS) suppliers with a requirement for 

participation in airline industry shared telecommunication facilities. Such CRS suppliers 

shall only be assigned two-character numeric-alpha or alpha-numeric designators using 

the figure “1” and letters “A–Z”. Such designators can be used in interline reservations 

messages. They shall not be used to publish and operate air services, nor shall they be 

used for the interline transmission of PTAs, nor shall they be used for any other ticketing 

purpose, (except for the optional identification of the CRS controlling the PNR. This 

identification should be shown in the “Airline Data/Booking Reference/PNR” box on the 

ticket). These codes shall not be duplicated (see paragraph 5).

4.5 The two-character and three-letter airline designators shall be used for the purposes 

outlined in Paragraph 1, (except where expressly stated otherwise in this Resolution), 

and in accordance with the instruction issued by IATA. Notwithstanding anything in this 

Resolution, three-letter designators will not be used by airlines until such time as the 

Joint ATA Passenger Council/IATA Passenger Services Conference (JPSC) reaffirms 

the requirement for the use of such three-letter designators.
5. CONTROLLED DUPLICATION1

5.1 During the interim period, two-character designators may be duplicated in a 

controlled environment.

5.1.1 The following criteria shall apply to controlled duplicate designators: 

The same code will not be duplicated if the companies:

• publish passenger schedules; or

• publish cargo schedules; or

• participate in the industry shared telecommunication facilities except under 

Banding as defined in RP 1008; or

• at the time of assignment, it is known by IATA that the companies serve the 

same general geographic area.

5.1.2 In the event that one of the companies with a duplicated designator changes its 

status, and falls into one of the criteria listed above, the company which had the 

designator first shall continue to have the use of the code and IATA will change the 

designators of the other companies which shared the designator.

5.2 If an airline has nominated a predesignated point that airline's two-character 

designator will not be duplicated.

1

 Duplication means to assign the same designator to two or more companies.

6. DESIGNATORS NOT AVAILABLE FOR ASSIGNMENT

The following combinations shall not be assigned to individual airlines or companies 

qualifying for airline designator:

6.1 these designators are to be used for communications purposes only:

Commercial Category Designator

a. Car Rental Companies/ CR

Miscellaneous

b. Hotel/Motel Companies HL

c. Aeronautical Radio, Inc. (ARINC) XA

d. International Air Transport XB

Association (IATA)

e. Air Transport Association of XD

America (ATA)

f. Special Ground Handling Service XH

g. International Aeradio Ltd. (IAL) XI

h. SITA XS
i. Government Civil Aviation YA

Authorities

j. General Addressing YY

k. Computer Tests ZZ

l. Miscellaneous (reserved for industry 2X, 6X,

use) 7X, 8X

m. non-scheduled Air Transportation X2, X6

(Reserved for Banding — see

Paragraph 4.1.3)

n. General Aviation GN

6.2 When IATA starts assigning three-letter codes, the following combinations shall not 

be assigned to individual airlines or companies qualifying for an airline designator:

6.2.1 three-letter designators — CAF, COR, DPC, EEE, EXO, HDQ, NAC, NIL, PAN, 

PDM, QAA, QAB, QFP, QMK, QQQ, QTA, QTB, QTE, RDT, RET, RPT, RQR, RTA, 

RTC, RTP, RTX, SOS, STP, SVC, UNO, XCR, XHL, XXD, XXH, YXA to YZZ and ZXA 

to ZZZ, ATX, CAR, CCR, HHL, HTL, OSI, PTA, SSR, SUR, TTO, TUR, YYY, WWW;

6.3 .2.2 three-letter combinations with CZ, NN or ZC;

6.4 2.3 an airline's or CRS's three-letter designator shall not be the same as the location 

identifier for that airline's or CRS's head office location.

7. SUBMISSION OF REQUESTS FOR INFORMATION AND APPLICATION FORMS

Companies requesting the assignment of a designator or a change to an existing 

designator shall submit a request (using the application form which is published 

separately) to the IATA Office, as shown on the application form.

Information on application forms regarding code assignment is available from IATA as 

shown below, or download forms from 

http://www.iata.org/whatwedo/passenger/Pages/coding

Code Administration Co-ordinator

International Air Transport Association

800 Place Victoria

P.O. Box 113

Montreal, Quebec

Canada H4Z 1M1

Tel: +1 (514) 874 0202

Fax: +1 (514) 390 6773

Email: airlinecoding@iata.org

7.1 Publication of Codes

Information regarding valid codes can be found in the IATA Airline Coding Directory. This can 

be ordered from the IATA online store at: www.iataonline.com

For individual enquiries regarding coding and de-coding of airline designators, refer to: 

www.iata.org/codes
8. PROCESSING OF REQUEST

Upon receipt of a request for the assignment of an airline designator, the IATA Office 

will:

8.1 determine the eligibility of the applicant and, if eligible, will assign and authorize the 

use of an airline designator, coordinating assignments to avoid possible uncontrolled 

duplications;

8.2 introduce an effective date provide notification for the use of the airline designator 

so assigned by means of a circular letter an industry message to ATA/ IATA Members, 

CRSs and to the Airline Guides CRSs, data aggregators and subscribers of the IATA 

Coding Directory;

8.3 publish all assignments in the IATA Airline Coding Directory.

8.4 The order of priority in assigning two-character airline designators is as follows:

8.4.1 an airline which requires a change to its designator because of an operational 

problem caused by the designator it has been assigned, including conflicts associated 

with controlled duplicate designators;

8.4.2 an airline which has been assigned a three-letter airline designator and who has 

been placed on a waiting list for a two-character designator in accordance with 

Paragraph 2, will be offered a two-character designator according to the date the airline 

requested to be placed on that waiting list established for this purpose. If the airline 

refuses to accept the first two-character airline designator which becomes available, 

that airline will move to the bottom of this waiting list;

8.4.3 an airline which does not currently have an airline designator;

8.4.4 an airline which requests a voluntary change to its airline designator. Assignments 

will be made from a waiting list in order of the date the airline requested to be placed on 

this list.

9. CHANGES TO AIRLINE DESIGNATOR ASSIGNMENTS

9.1 Except as provided in Paragraph 9.2, airline designators shall not be changed 

without strong justification, including changes made in accordance with Paragraph 2 

and with regard to the priority as specified in Paragraph 8.

9.2 Two or more airlines already holding a unique two-character designator, except 

controlled duplicate designators, may voluntarily exchange such airline designators 

using IATA as an intermediary. IATA may establish fees for acting as an intermediary. 

When an airline designator is assigned or changed, IATA will establish its effective date 

and undertake to co-ordinate this assignment or change with all parties concerned.
9.3 The effective date of any change (except additions and deletions) to current airline 

designators, except controlled duplicate designators, shall not be less than ninety (90) 

days following the date on which the change is agreed.

9.4 When making a request for changes, airlines and CRSs shall ensure that such 

request is sent to the IATA Office shown on the Application form (which is published 

separately).

10. EXTENSION OF TWO-CHARACTER DESIGNATOR SYSTEM ANNUAL REVIEW

10.1 To encourage airlines who do not need a unique two character designator for 

operational reasons to surrender it, or to encourage airlines to move to banding, there 

will be an annual review process to determine continued eligibility for an airline 

accounting code and/or airline prefix, for which ATA and IATA may assess a fee in 

addition to any application or administration fee. IATA may assess a fee as part of the 

annual review process in addition to any assignment or administration fee. This fee 

shall apply to all non-IATA, non-ATA companies, except to members of the IATA 

Registered Supplier Strategic Partnerships Programme, IATA Travel Partners 

Programme and airlines assigned a Banded Code. 

10.2 Failure to complete and return the annual review form and/or pay any airline 

designator fee shall result in that airline designator being recalled by IATA for 

reassignment.

11. RECALLING OF AIRLINE DESIGNATORS

11.1 If at any time it is determined by ATA or IATA that an airline or non-airline company 

no longer qualifies for a designator under the criteria established in paragraph 4 of this 

Resolution, the designator will be recalled. A company will cease to use the designator 

upon notification by ATA or IATA of the recall of the designator.

11.2 The IATA Secretariat will advise the IATA/ATA Members, CRSs and other 

interested parties by way of a circular letter and in the regular transmittal of the IATA 

Airline Coding Directory of any changes in airline designators. provide notification of the 

airline designator so recalled by means of an industry message to CRSs, data 

aggregators and subscribers of the IATA Coding Directory. Recalled airline designators 

should not be reassigned for a minimum period of at least sixty (60) days.

11.3 An airline designator is not considered the property of the airline to which it is 

assigned. Once an airline no longer meets the criteria for the assignment of an airline 

designator, that designator is recalled. After 60 days from the date of recall, the 

designator may be reassigned. Should the carrier which has had its designator recalled 

demonstrate within 60 days of the recall that it does meet the criteria for an airline 

designator, that designator will be reallocated to it. If the carrier demonstrates that it 

satisfies the criteria for an airline designator more than 60 days from the date of the 

recall of its airline designator, it shall be considered a new applicant and IATA will 

assign an available airline designator. In these circumstances IATA can not guarantee 

to assign the original airline designator to the applicant.
For a copy of an application form for an airline designator contact the:

Code Administration Co-ordinator

International Air Transport Association

800 Place Victoria

P.O. Box 113

Montreal, Quebec

Canada H4Z 1M1

Tel: +1 (514) 390 6773

Fax: +1 (514) 874 9633

Tty: YMQTIXB

Email: codes@iata.org

www.iata.org/codes

12. ASSIGNMENT OF ADDITIONAL AIRLINE DESIGNATORS

12.1 When the commercial requirements of an airline are likely to lead to the exhaustion 

of its available range of flight numbers (including numbers used for code share flights 

marketed but not operated by such airline) within a forthcoming year, (an) additional 

airline designator(s) may be assigned to that airline by IATA Management for a 

specified period. In these circumstances, controlled duplicates cannot be used.

12.2 Applications for additional designators shall be submitted to the IATA office as per 

Paragraph 7 with a detailed justification to support the application.

GOVERNMENT RESERVATIONS

UNITED STATES

Order 77-12-32 dated 5 December 1977:

Resolution 762 is approved provided that ATA and IATA include interested non-member 

U.S. certificated air carriers in their administration of the two-letter airline designator 

system.

Filing Period: Effective Date:

1 March - 1 June 2012

13 April 2012
RESOLUTION 763

LOCATION IDENTIFIERS

(amending)

PSC(32 33)763 Expiry: Indefinite

Type: B

P3

RESOLVED that:

Members Airlines and CRSs shall use the location identifiers published in the IATA 

Airline Coding Directory. Assigned three-letter location identifiers are considered 

permanent. They shall not be duplicated with any other physical location. They shall not 

be changed without strong justification primarily concerning air safety. The following 

procedures shall apply for the assignment of three-letter location identifiers (city/airport 

codes) for airlines' purposes, other than Air Traffic Services1

1

applications. The following codes are not available for assignment: CPY, DDL, DPC, 

HDQ, IAT, NIL, NUC, QAA, QAB, QAF, QEN, QES, QQQ, QSP, QTA, QTB, QTQ, QTV, 

QUK, QXA, QXL, QXM, QXN, QXS, QXT, QXU, QZY, QZW, SOS, WWW, XXX, ZZW, 

ZZX, ZZY, ZZZ. The following codes are reserved for use as a fictitious points only in 

the text of a Schedule Exchange Data Message according to the IATA Standard 

Schedules Information Manual: QMX, QMY, QPX, QPY, QZX, XUD.

The following codes are reserved as fictitious points for use in Charge Card and Credit 

Card billings: XAA, XAE, XAF, XAO, XDF, XCA, XOT, XPC, XPE, XTD and XUP.

1. CRITERIA

1.1 Members Airlines and CRSs may only request the assignment of a unique threeletter code to identify one of the following locations:

1.1.1 an airport receiving scheduled air services by a Member an airline;

1.1.2 an airport receiving charter air services by a Member airline;

1.1.3 an alternate airport available for use by Member airlines;

1.1.4 an airline headquarters when HDQ or an existing city/airport code cannot be used;

1.1.6 1.1.2 a location which must be identified and published for intermodal 

transportation, served by a railway, ferry or bus company having an intermodal 

agreement with an airline. For the purposes of this Resolution, intermodal transportation 

means transportation provided by an airline and one or more other modes of 

transportation, documented on a single accountable traffic document, with a 

reservation, and distributed via an airline reservation system and/or CRS. Code 

assignment requests received from a CRS for railway, ferry or bus companies will may

be subject to a charge set by IATA (except IATA Strategic Partners).
1.1.5 1.1.3 a location which must be identified for airline communications routing or 

airline scheduling purposes or airline schedule exchange data messages and for which 

no existing airport or city code is available

1.2 To satisfy the criteria listed under 1.1.1, 1.1.2, and 1.1.3, 1.1.4 and 1.1.5, the 

following shall apply:

1.2.1 for scheduled service airport location identifiers, consult the current issue of the 

IATA Airline Coding Directory in order to avoid requesting an identifier which is already 

in use;

1.2.2 as a first choice, select an unassigned mnemonic using the first three letters of 

the location name; 

1.2.3 as a second choice, select an unassigned mnemonic preferably starting with the 

first letter of the location name.

1.3 Codes are assigned under 1.1.1, 1.1.2 and 1.1.3 as follows:

1.3.1 if only one airport serves an area, only one code will be assigned to both the 

airport and the area;

1.3.2 when an area is served by more than one airport, each airport will be assigned an 

individual code. The area will may be assigned a metropolitan area code which may be 

the same as the code of one of its airports or an a unique individual code; provided that 

the above criteria is without prejudice to currently existing unique metropolitan area

codes as published in the IATA Airline Coding Directory.

1.4 An airport will not be listed in or de-listed from the IATA Airline Coding Directory 

under a metropolitan area location identifier unless a specific request for such action is 

submitted to the IATA or ATA Head Office, as appropriate.

1.5 Creation/dismantling of a metropolitan area location identifier, or the listing/de-listing 

of an airport under a metropolitan area location identifier shall only be actioned if it is 

established by the IATA or ATA Secretariat that:

1.5.1 the operators of the airports concerned support such action;

1.5.2 a majority of responses from a poll of airlines operating scheduled air transport 

services serving all the airports concerned support such action. For the purpose of 

determining which airlines serve such airports, the IATA or ATA Secretariat as 

appropriate will consult the airport authorities concerned. For the purposes of compiling 

the list of airlines, the airport authorities are to include the teletype address and/or email address of the airlines presently operating scheduled air transport ser-vices or 

which have operated to the airport during the previous 12 month period.
1.5.3 In the event a majority of airlines do not support the proposed action to list an 

additional airport to an existing metropolitan area, IATA will inform the relevant national 

aeronautical authority. In such case the national aeronautical authority may, at its 

discretion, overturn the vote by advising IATA accordingly in writing and in that case the 

airport will be listed in the existing metropolitan area. If no reply is received within 90 

days it will be assumed that the national aeronautical authority supports the results of 

the poll.

1.6 For the purposes of conducting a poll, the following criteria shall apply:

1.6.1 the poll will be conducted not more than once per year for a given airport;

1.6.2 the poll will be sent by teletype and/or by e-mail to:

1.6.2.1 the Passenger Services Conference Accredited Representative of IATA Member 

airlines or the interline contact of Member airlines participating in the MITA but not 

represented in the Passenger Service Conference,

1.6.2.2 the interline contact for non-IATA airlines which are party to the IATA Multilateral 

Interline Traffic Agreements,

1.6.2.3 the chief executive (head office teletype address and/or by e-mail) of any other 

airline(s) indicated as concerned by the airport authority(ies) concerned;

1.6.2.4 all Accredited Representatives of the Passenger Services Conference and the 

Composite Tariffs Conference for their information;

1.6.3 a majority shall be considered as a simple majority of airlines responding to the 

poll, with non-responses and abstentions not counting in the poll.

1.6.4 Requests received from non-IATA and non-ATA airlines for listing an airport under 

a metropolitan area location identifier will be subject to a charge set by IATA.

1.7 The location name will be spelled using the “conventional” English name as 

published by the US Board on Geographic Names (BGN). If this does not exist, the 

BGN “approved” spelling will be used (refer to: http://geonames.usgs.gov/) Alternatively 

use the spelling of the national Civil Aviation Authorities of the country concerned.
2. NEW LOCATIONS OR CHANGES REQUESTS FOR INFORMATION AND 

APPLICATION FORMS

Members and CRSs requiring the assignment of a code for a new location or requiring a 

change to an existing code, shall submit a request using the application form (published 

separately, see below) to the IATA or ATA Head Office, as appropriate.

The location name will be spelled using the conventional English name. If this does not 

exist, the spelling will be as published by the US Board on Geographic Names (BGN).

Information on rules and criteria regarding code assignment is available from IATA as 

shown below, or download forms from 

http://www.iata.org/whatwedo/passenger/Pages/coding

Code Administration Co-ordinator

International Air Transport Association

800 Place Victoria

P.O. Box 113

Montreal, Quebec

Canada H4Z 1M1

Tel: +1 (514) 874 0202

Fax: +1 (514) 390 6773

Email: airlinecoding@iata.org

2.1 Publication of Codes

Information regarding valid codes can be found in the IATA Airline Coding Directory. 

This can be ordered from the IATA online store at: www.iataonline.com

For individual enquiries regarding coding and de-coding of location identifier codes, 

refer to: www.iata.org/codes

3. PROCESSING OF REQUESTS FOR NEW LOCATIONS OR A CHANGE OF 

AN EXISTING LOCATION PUBLICATION OF CODES

Upon receipt from a Member an airline or a CRS of a request for the assignment of a 

new location identifier or for a change o an existing location identifier, the appropriate 

Secretariat of the IATA or ATA Head Office will:

3.1 co-ordinate recommended changes or additions to location identifiers with ATA or 

IATA, as the case may be, o determine availability and to ensure conformity with the 

criteria shown in 1.2;

3.2 For new location identifiers, ATA and/or IATA will:

3.2.1 assign an available code,
3.2.2 establish an implementation date for each new location identifier that shall not be 

less than thirty (30) days from the date of assignment,

3.2.3 advise the new location identifier to all Members, CRSs and the Airline Guides

CRSs, data aggregators and subscribers of the IATA Airline Coding Directory.

3.3 For a change to an existing location identifier, ATA and/or IATA will:

3.3.1 assign the requested code for the location identifier,

3.3.2 establish an implementation date for a change of location identifier that normally 

shall not be less than thirty 30) days from the date of the notice to be issued by ATA 

and IATA,

3.3.3 advise the change of location identifier to all Members, CRSs and the Airline 

Guides CRSs, data aggregators and subscribers of the IATA Airline Coding Directory.

3.4 include all such amendments in the next issue of the IATA Airline Coding Directory.

Information regarding valid codes can be found in the IATA Airline Coding Directory. 

This can be ordered from the IATA online store at: www.iataonline.com

4. EMERGENCY ASSIGNMENT AND TEMPORARY AMENDMENT OF 

LOCATION DENTIFIERS

Notwithstanding any Paragraph in this Resolution 763, IATA or ATA management, as 

appropriate, may immediately assign new or amended location identifiers or may list/delist airports under existing metropolitan area location identifiers in the event that air 

safety, government action or a change in government policy strongly justifies such 

assignment or amendment. Such assignment or amendment must be supported and 

endorsed by the appropriate operator(s) of the airport(s), and shall become effective 

fourteen (14) days after its authorization by means of circular letter to all Members and 

CRSs and to the Airline Guides CRSs, data aggregators and subscribers of the IATA 

Airline Coding Directory. The implementation date will be specified in the circular. The 

appropriate Secretariat of the IATA or ATA Head Office, as appropriate, will include 

such assignment or amendment in the next issue of the Airline Coding Directory.

For a copy of an application form see www.iata.org/codes or send an email to: 

airlinecoding@iata.org

5. REQUESTS FROM NON-MEMBERS FOR ASSIGNMENT

Upon receipt of a request from a non-Member operating scheduled air services for the 

assignment of a location identifier, the appropriate Secretariat of the ATA/IATA Head 

Office shall do so in accordance with the provisions of this Resolution.
6 5. EFFECTIVENESS OF CHANGES ASSIGNMENTS

At any given time for any location, airlines should use only the one identifier which is 

effective on the date of travel to/from that location. The first date on which the new 

location identifier must be used for reservation purposes will be advised by IATA, but 

never less than sixty (60) days before the actual date of effectiveness of the changed 

location identifier. When making a recommendation for such changes, Members shall 

ensure that such notice is sent to the appropriate Secretariat of the IATA or ATA Head 

Office at least seventy (70) days before such effective date.

When airlines and CRSs request new assignments they shall ensure that such notice is 

sent to the appropriate Secretariat of the IATA or ATA Head Office at least seventy (70) 

days before such effective date. IATA systems will be updated with immediate effect on 

the requested effective date, and notification will be circulated to the airline industry no 

later than ten (10) days thereafter via an industry message to CRSs, data aggregators 

and subscribers of the IATA Coding Directory.

7 6. CANCELLATION OF CODES

When recommending the cancellation of an existing code, Members airlines and CRSs 

shall submit the proposal to the IATA or ATA Head Office, as appropriate, giving 

reasons to substantiate the recommendation. Co-ordinating action shall may be taken 

by IATA or ATA Head Office which shall authorise such cancellation by the same 

procedure as outlined in Paragraph 3 upon review of the proposal.

8 7. USE OF LOCATION IDENTIFIER CODES

A location identifier code is the property of IATA and not the airport to which it is 

assigned or of the company that requested the assignment. The assignment by IATA of 

a location identifier code shall not confer upon the recipient of such assignment any 

proprietary, intellectual property or commercial rights which are independent of or 

inconsistent with the purpose of this Resolution 763. Any commercial use of a location 

identifier code not authorized by IATA is strictly prohibited.

GOVERNMENT RESERVATIONS

ITALY

In accordance with the sentence and judgement No. 5668/02 of the “Tribunale Amministrativo 

Regionale del Lazio” (TAR), the Italian CAA requires that, in Italy, in case of a request for the 

de-listing of an airport from a metropolitan area consisting of only two airports and for the 

subsequent dismantling of such area, the following amended procedure applies:

1) Article 1.5.1 is modified insofar as the agreement of the operator of the airport for which delisting is requested shall suffice for appropriate action to be undertaken by IATA.

2) Article 1.5.3 is modified insofar as the “poll” to be undertaken by IATA shall be limited to the 

carriers having served the airport for which de-listing is requested during the previous 12-month 

period.

Filing Period: Effective Date:

1 March - 1 June 2012

13 April 2012
RESOLUTION 767

ASSIGNMENT OF AIRLINE ACCOUNTING CODES AND AIRLINE PREFIXES

(amending)

PSC(30 33)767 Expiry: Indefinite

Type: B

P3

RESOLVED that:

The following rules shall apply to the assignment and use of airline accounting codes 

and airline prefixes for the airline and travel and tourism industries.

For the purposes of this Resolution,

“AIRLINE” means: an enterprise operating aircraft for commercial purposes which (i) 

performs scheduled or non-scheduled air transport services, or both, which are 

available to the public for carriage of passengers, mail and/or cargo and (ii) is certified 

for such purposes by the civil aviation authority of the state in which it is established.

“PUBLISHED SCHEDULE” means: a listing of the timing of air services and other 

schedule information available to the public in standard air transport industry guides.

1. USE OF AIRLINE ACCOUNTING CODES AND AIRLINE PREFIXES

1.1 Airline accounting codes and airline prefixes are essential for the identification of 

passenger and cargo traffic documents, processing of passenger accounting 

transactions, cargo transactions and other commercial/traffic purposes.

1.2 The airline accounting code shall be used on all passenger traffic documents as the 

first three digits of the document number. This identifies the document as being issued 

by or on behalf of an airline or non-airline company other than a CRS. The airline 

accounting code shall also be used in accordance with the ATA and IATA instructions, 

Resolutions and Recommended Practices.

1.3 The airline prefix shall be used on all cargo traffic documents as the first three digits 

of the document number and form part of the shipment identification. This identifies the 

document as being issued by or on behalf of an airline. The airline prefix shall also be 

used in accordance with the ATA and IATA instructions, Resolutions and 

Recommended Practices.

1.4 Codes for use in all baggage handling applications are defined in Resolution 769.

1.5 Notwithstanding anything in this Resolution to the contrary, where an airline's cargo 

division becomes a subsidiary company and an agreement is made whereby that 

subsidiary cargo company will purchase/utilize allocated space on its parent passenger 

aircraft for cargo; the cargo company may also use the airline prefix of the parent 

company, if agreed by both parties.
2. ASSIGNMENT CRITERIA FOR AIRLINE ACCOUNTING CODES AND AIRLINE 

PREFIXES

2.1 Three numeric airline accounting codes or airline prefixes shall be assigned for the 

purposes described in Paragraph 1 to:

Computerized reservations system companies which provide ticketing services for the 

airline industry;

Airlines which have an interline traffic agreement with another airline and issue 

accountable interline traffic documents;

Airlines which are party to any of the following industry agreements/plans:

IATA Multilateral Interline Traffic Agreement – Passenger,

IATA Multilateral Interline Traffic Agreement – Cargo,

IATA Interline Traffic Participation Agreement – Passenger – Issuing Airlines 

only,

ATA Interline Traffic Agreement – Passenger,

ATA Interline Air Cargo Procedures Agreement,

IATA Billing and Settlement Plan (BSP), and issue Standard Interline Traffic 

Documents,

Airlines Reporting Corporation (ARC), and issue Standard Interline Traffic 

Documents,

IATA Cargo Accounts Settlement Systems (CASS), and issue air waybills,

Universal Air Travel Plan (UATP) UATP Agreement, as a Contractor Party; 

Airlines having bilateral interline traffic agreements with another airline and issue 

accountable interline traffic documents;

Airlines which have authorized forwarders to issue air waybills on their behalf;

Non-airline Unit Load Device (ULD) owners who participate in the Interline ULD Control 

User Group (IULDUG);

Computerized reservations system companies which provide ticketing services for the 

airline industry;

IATA Travel Partners which are participating carriers in airline computer reservations 

systems (CRSs) or IATA Billing and Settlement Plan (BSP) or Airlines Reporting 

Corporation (ARC) as of 1 July 1995, and issue accountable traffic documents.
2.2 When all three numeric airline accounting codes or airline prefixes are exhausted, 

new companies which qualify for an airline accounting code or airline prefix shall be 

assigned a three-letter airline accounting code or airline prefix in accordance with the 

provisions set forth under Paragraph 4 hereto. Companies which have been assigned 

three-letter airline accounting codes or airline prefixes, shall be placed on a waiting list 

for three-numeric airline accounting codes or airline prefixes which become available. 

Until such time as a three-numeric airline accounting code or airline prefix becomes 

available, the airline/company will use its assigned three-letter airline accounting code 

or airline prefix for the purposes defined in Paragraph 1. When a three-numeric airline 

accounting code or airline prefix becomes available, the airline/company will have the 

option of using the three-numeric or three-letter airline accounting code or airline prefix, 

but not both. The airline/company must decide whether it wishes to use the threenumeric airline accounting code or airline prefix within sixty days of its becoming 

available. If the airline/company chooses not to use the three-numeric airline accounting 

code or airline prefix, it will become available for reassignment to another 

airline/company.

The three-letter airline accounting code or airline prefix will be the same as the threeletter airline designator assigned/reserved by IATA under the provisions of Resolution 

762.

Notwithstanding anything in this Resolution, three-letter accounting codes will not be 

used by airlines until such time as the Joint ATA Passenger Council/IATA Passenger 

Services Conference reaffirms the requirement for the use of such three-letter 

accounting codes.

3. CLEARING HOUSE SUBSIDIARY LEDGER COMPANIES

With respect to the non-airline companies which participate in the IATA Clearing House 

or Airlines Clearing House ‘Subsidiary Ledger’, such companies shall be assigned, by 

the IATA Clearing House or Airlines Clearing House, a three character alphanumeric 

(not three-numeric or three-letter) accounting code. Such companies may not use the 

alpha-numeric accounting code for the purposes described in Paragraph 1.

4. ASSIGNMENT OF AIRLINE ACCOUNTING CODES AND AIRLINE PREFIXES

Airline accounting codes and airline prefixes shall be assigned by the Director –

Revenue Accounting of the Air Transport Association of America (ATA) or the IATA's 

Global Head, Passenger of the International Air Transport Association (IATA). ATA shall 

assign airline accounting codes and airline prefixes to airlines and non-airline parties 

whose headquarters are in the U.S.A., and IATA shall assign airline accounting codes 

and airline prefixes to airlines and non-airline parties whose headquarters are outside 

the U.S.A.
5. AIRLINE ACCOUNTING CODES AND AIRLINE PREFIXES NOT AVAILABLE FOR 

ASSIGNMENT

5.1 The following airline accounting codes shall not be assigned to individual airlines or 

non-airline companies qualifying for an airline accounting code for use on passenger 

traffic documents:

Code Assignee

777 BSP — Tour Operators/Hotels/Courier Companies/Insurance 

Companies

792 BSP — Car Rentals

793 BSP — Ships/Hovercraft

794 BSP — Bus Lines

799 BSP — Railways

888 Scheduled Airlines Traffic Offices Inc.

889 ARC

890 ARC

950 SITA

952 BSP — IATA Remittance and Settlement Adjustments

953 BSP

954 BSP

955 BSP

956 BSPlink agent

5.2 The following airline prefixes shall not be assigned to individual airlines for use on 

cargo traffic documents:

Code Assignee

888 Scheduled Airlines Traffic Offices Inc.

889 ARC

890 ARC

950 SITA

953 CASS

954 CASS

6. REQUESTING AN AIRLINE ACCOUNTING CODE OR AIRLINE PREFIX

REQUESTS FOR INFORMATION AND APPLICATION FORMS

6.1 An airline or non-airline company requesting assignment of an airline accounting 

code for passenger traffic purposes only, shall send a written request using the 

application form which is published separately to ATA or IATA, as appropriate, and 

provide documentary evidence that it is eligible to receive an airline accounting code 

under the provisions of Paragraph 2. Such application shall include a statement to the 

effect that the code shall not be used as an airline prefix for cargo traffic documents.
6.1.1 Upon receipt of a request for assignment of an airline accounting code and/or

airline prefix, ATA or IATA, as the case may be, shall:

verify the eligibility of the applicant;

be certain the applicant has not previously been assigned an airline accounting 

code and/or airline prefix by either ATA or IATA;

assign an airline accounting code and/or airline prefix from the available banks of 

airline accounting codes and airline prefixes, and notify the applicant in writing, of 

the code and/or prefix so assigned.

6.2 An airline requesting assignment of an airline prefix for cargo traffic purposes only, 

shall send a written request using the application form which is published separately to 

ATA or IATA, as appropriate, and provide documentary evidence that it is eligible to 

receive an airline prefix under the provisions of Paragraph 2. Such application shall 

include a statement to the effect that the prefix shall not be used as an airline 

accounting code for passenger traffic documents.

6.3 An Application fee in an amount to be determined by ATA and IATA, is required 

from airlines or non-airline companies requesting an airline accounting code or airline 

prefix assignment from ATA or IATA. Applicants shall therefore include a cheque for the 

applicable amount with their application.

Information on rules and criteria regarding code assignment is available from IATA as 

shown below, or download forms from 

http://www.iata.org/whatwedo/passenger/Pages/coding

Code Administration Co-ordinator

International Air Transport Association

800 Place Victoria

P.O. Box 113

Montreal, Quebec

Canada H4Z 1M1

Tel: +1 (514) 874 0202

Fax: +1 (514) 390 6773

Email: airlinecoding@iata.org

6.4 Publication of Codes

Information regarding valid codes can be found in the IATA Airline Coding Directory. 

This can be ordered from the IATA online store at: www.iataonline.com

For individual enquiries regarding coding and de-coding of airline accounting 

codes/airline prefixes, refer to: www.iata.org/codes
7. ACTION BY ATA OR IATA ANNUAL REVIEW

7.1 Upon receipt of a request for assignment of an airline accounting code and/or airline 

prefix, ATA or IATA, as the case may be, shall:

verify the eligibility of the applicant;

be certain the applicant has not previously been assigned an airline accounting 

code and/or airline prefix by either ATA or IATA;

assign an airline accounting code and/or airline prefix from the available banks of 

airline accounting codes and airline prefixes, and notify the applicant in writing, of 

the code and/or prefix so assigned.

7.2 .1 To encourage airlines or non-airline companies who do not need or no longer 

qualify for an airline accounting code and/or airline prefix, there will be an annual review 

process to determine continued eligibility for an airline accounting code and/or airline 

prefix, for which ATA and IATA may assess a fee in addition to any application or 

administration fee. This annual review and fee shall apply to all non-ATA and non-IATA 

companies and non members of the IATA Registered Suppliers/Industry Associates

Strategic Partnership Programme and IATA Travel Partners Programmes, except the 

non-airline companies which participate in the ATA or IATA Clearing Houses ‘Subsidiary 

Ledger’ covered in Paragraph 3.

7.3 .2 Failure to complete and return the Annual Review form and pay the annual fee 

for the airline accounting code and/or airline prefix, shall result in that airline accounting 

code and/or airline prefix being recalled by ATA or IATA.

8. RECALL OF AIRLINE ACCOUNTING CODES NUMBERS AND AIRLINE 

PREFIXES

8.1 If at any time, it is determined by ATA or IATA that an airline or non-airline company 

no longer qualifies for an airline accounting code and/or airline prefix under the criteria 

established in Paragraph 2 of this Resolution, the airline accounting code and/or airline 

prefix shall be recalled. Such airline or non-airline company shall cease to use such 

airline accounting code and/or airline prefix upon receipt of notification by ATA or IATA. 

IATA will provide notification of the accounting code and/or airline prefix so recalled by 

means of an industry message to CRSs, data aggregators and subscribers of the IATA 

Coding Directory.

8.2 Airline accounting codes and airline prefixes shall normally not be reassigned for at 

least a minimum period of 12 months after the date of recall or from the date interline 

traffic documents ceased to be issued, whichever is earlier. This does not apply to the 

alpha/numeric accounting codes assigned to Subsidiary Ledger companies participating 

in the IATA Clearing House.

8.3 If an airline or non-airline company later demonstrates that it again meets the criteria 

for an airline accounting code and/or airline prefix more than 12 months from the date of 

recall of its airline accounting code and/or airline prefix, it shall be considered as a new 

applicant. In these circumstances ATA or IATA cannot guarantee to assign the original 

airline accounting code and/or airline prefix.
9. NOTIFICATION OF AIRLINE ACCOUNTING CODE AND AIRLINE PREFIX 

ASSIGNMENTS/CANCELLATIONS PUBLICATION OF CODES

9.1 On the first day of each month immediately after assignment or recall of an airline 

accounting code or airline prefix, ATA or IATA, as the case may be, shall take the 

following action:

9.1.1 IATA shall notify ATA and the airline guides publishers of the codes and prefixes 

assigned or recalled;

9.1.2 ATA shall notify IATA and the airline guides publishers of the codes and prefixes 

assigned or recalled;

9.1.3 IATA shall publish all codes and prefixes assigned or recalled by ATA and IATA in 

the IATA Airline Coding Directory, at the time of the next regular edition, and issue 

monthly amendment bulletins;

9.1.4 ATA shall, at appropriate intervals, notify its Members of the airline accounting 

codes and airline prefixes assigned or recalled by ATA and IATA.

Information regarding valid codes can be found in the IATA Airline Coding Directory. 

This can be ordered from the IATA online store at: www.iataonline.com

10. CHANGE IN CORPORATE STATUS

In the event of change in the corporate status of an airline or non-airline company which 

has been assigned an airline accounting code and/or airline prefix, such as a name 

change, merger with another airline or company, etc. the airline or non-airline company 

so affected shall immediately notify ATA or IATA, as appropriate, so the published lists 

of code assignments can be amended accordingly. In the event of a merger of two or 

more airlines or non-airline companies which all have been assigned airline accounting 

codes and/or airline prefixes, the surviving airline or non-airline company shall use only 

one code and/or prefix, and the other code and/or prefix shall be recalled in accordance 

with Paragraph 8, upon notification from the surviving airline or non-airline company.

11. OWNERSHIP OF AIRLINE ACCOUNTING CODE AND AIRLINE PREFIX

An airline accounting code or airline prefix is not considered to be the property of the 

company to which it is assigned. Once the company no longer meets the criteria for the 

airline accounting code or airline prefix, that code or prefix shall be recalled in 

accordance with Paragraph 6 hereof.

Filing Period: Effective Date:

1 March - 1 June 2012

13 April 2012

RESOLUTION 780e

IATA INTERLINE TRAFFIC PARTICIPATION AGREEMENT - PASSENGER

(amending)

PSC(29 33)780e Expiry: Indefinite

Type: B

P8.1

...

Article 2 – Issuance of Tickets and MCOs

...

2.2.6 Whereas certain parties to this agreement issue paper tickets as defined in IATA 

Resolutions 720, 720a, 720b, 722, 722a, 722c and 722e, any Participating party which 

concurs with the Issuing Airline may refuse such paper tickets. However, the refusing 

party will provide at least 12 months notice to interline partners. The refusing party shall 

notify the IATA Director Passenger of which other party's paper tickets it refuses to 

accept, any specific exclusions to its policy (e.g. irregular operations, staff travel, nonET eligible itineraries) and will provide an effective date. The IATA Director, Passenger 

shall publish in the MITA Manual a list of such refusals and the corresponding effective 

dates.

Filing Period: Effective Date:

1 March - 1 June 2012

13 April 2012

RESOLUTION 792

BAR CODED BOARDING PASS) - VERSION 4 VERSION 5

(amending)

PSC(32 33)792 Expiry: Indefinite

Type: B

P6.3.9

RESOLVED that: 

Members may issue, either for online or interline carriage, a Boarding Pass with version 

4 version 5 of the Boarding Pass standard as described herein. All of the following 

specifications define the required characteristics of the elements and format of the Bar 

Code on the Boarding Pass or electronic (mobile) device or stored on the NFC chip.

....

1.1.2 USE OF ELECTRONIC (MOBILE) DEVICE BOARDING PASS

The data can be stored either in a Bar Code or in an NFC chip. The Bar Codes 

presented here are designed for use on an electronic (mobile) boarding pass. The NFC 

format presented here is designed for use on an NFC mobile device. Airport Boarding 

Gate Readers should be able to read the mobile Boarding Pass, either Bar Code 

symbologies or NCF NFC chip.

...
RESOLUTION 792

Attachment ‘A’

BCBP M FORMAT VERSION 4 VERSION 5

New Item 

number Element Description Field 

Size

Unique /

Repeated Data Type Formatting Ref no(s)

 1 Format Code 1 U f M is always used to represent either one or multiple segments a

5 Number of Legs Encoded 1 U N b

11 Passenger Name 20 U f Left justified and trailing blanks 14

253 Electronic Ticket Indicator 1 U f 65

7 Operating Carrier PNR Code 7 R f Left justified and trailing blanks c 

26 From City Airport Code 3 R a 56

38 To City Airport Code 3 R a 56

42 Operating Carrier Designator 3 R f Left justified and trailing blanks

 43 Flight Number 5 R NNNN[a] Leading zeros on numerics, followed by an alpha or a blank

46 Date of Flight (Julian date) 3 R N Leading zeros 4

71 Compartment Code 1 R a 17

104 Seat Number 4 R NNNa Leading zeros on numerics

 107 Check-In Sequence Number 5 R NNNN[f] Leading zeros on numerics and alpha or blank on last digit u

113 Passenger Status 1 R f 16

 6 Field Size of variable size field (Conditional + Airline item 4) 2 R f Right justified leading zeros. Represented in Hexadecimal value d

8 Beginning of version number 1 U > sign

 9 Version Number 1 U f Currently at 5 ...but extensible beyond 10 by using A to Z if needed f

 10 Field Size of following structured message – unique 2 U f Right justified leading zeros. Represented in Hexadecimal value g

15 Passenger Description 1 U f 49

12 Source of Check-in 1 U f h

14 Source of Boarding Pass Issuance 1 U f i

22 Date of Issue of Boarding Pass (Julian Date) 4 U N First digit for the year then 3 digits with leading zeros 4

16 Document Type 1 U f j

21 Airline Designator of Boarding Pass issuer 3 U f Left justified and trailing blanks o

23 Baggage Tag License Plate Number (s) 13 U f The 10 digit bag tag number, as per BSM specifications, Reso 740 and 3 digits 

identifying the number of consecutive tags

p

31 1st Non-Consecutive Baggage Tag License Plate Number 13 U f The 10 digit bag tag number, as per BSM specifications, Reso 740 and 3 digits 

identifying the number of consecutive tags

p

32 2nd Non-Consecutive Baggage Tag License Plate Number 13 U F The 10 digit bag tag number, as per BSM specifications, Reso 740 and 3 digits 

identifying the number of consecutive tags

p

 17 Field Size of Following Structured Message – repeated 2 R N Right justified leading zeros. Represented in Hexadecimal value k

142 Airline Numeric Code 3 R N Right justified leading zeros

143 Document Form/Serial Number 10 R f Right justified leading zeros

18 Selectee Indicator 1 R f i

108 International Documentation Verification 1 R f 22

19 Marketing Carrier Designator 3 R f Left justified and trailing blanks m

20 Frequent Flyer Airline Designator 3 R f Left justified and trailing blanks n

 236 Frequent Flyer Number 16 R f Depends on carriers and alliances, left justified and trailing blanks 42

89 ID/AD Indicator 1 R f 53

118 Free Baggage Allowance 3 R f 59

 254 Fast Track 1 R f t

4 For individual airline use Var R e

25 Beginning of Security Data 1 U ^ sign

28 Type of Security Data 1 U f

 29 Length of Security Data 2 U f Right justified leading zeros. Represented in Hexadecimal value q

30 Security Data Var U f r

Conditional Items Security Mandatory Items
RESOLUTION 792

Attachment ‘B’

 EXAMPLE 1 - M1 USING MANDATORY ELEMENTS ONLY M1 USING MANDATORY ELEMENTS AND SECURITY FIELDS

New Item 

number Element Description Field Size

Unique /

Repeated 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Notes

1 Format Code 1 U M

5 Number of Legs Encoded 1 U 1

11 Passenger Name 20 U D E S M A R A I S / L U C

253 Electronic Ticket Indicator 1 U E

7 Operating Carrier PNR Code 7 R A B C 1 2 3

26 From City Airport Code 3 R Y U L

38 To City Airport Code 3 R F R A

42 Operating Carrier Designator 3 R A C

43 Flight Number 5 R 0 8 3 4

46 Date of Flight (Julian date) 3 R 3 2 6 326 = November 22nd (2011 Calendar)

71 Compartment Code 1 R J

104 Seat Number 4 R 0 0 1 A

107 Check-In Sequence Number 5 R 0 0 2 5

113 Passenger Status 1 R 1

6 Field Size of variable size field (Conditional + Airline item 

4)

2 R 0 0

0 in Decimal = 00 in Hexadecimal

8 Beginning of version number 1 U

9 Version Number 1 U

10 Field Size of following structured message – unique 2 U

15 Passenger Description 1 U

12 Source of Check-in 1 U

14 Source of Boarding Pass Issuance 1 U

22 Date of Issue of Boarding Pass (Julian Date) 4 U

16 Document Type 1 U

21 Airline Designator of Boarding Pass issuer 3 U

23 Baggage Tag License Plate Number (s) 13 U

31 1st Non-Consecutive Baggage Tag License Plate 

Number

13 U

32 2nd Non-Consecutive Baggage Tag License Plate 

Number

13 U

17 Field Size of Following Structured Message – repeated 2 R

142 Airline Numeric Code 3 R

143 Document Form/Serial Number 10 R

18 Selectee Indicator 1 R

108 International Documentation Verification 1 R

19 Marketing Carrier Designator 3 R

20 Frequent Flyer Airline Designator 3 R

236 Frequent Flyer Number 16 R

89 ID/AD Indicator 1 R

118 Free Baggage Allowance 3 R

 254 Fast Track 1 R

4 For individual airline use Var R Airline specific

25 Beginning of Security Data 1 U ^

28 Type of Security Data 1 U 1

29 Length of Security Data 2 U 6 4 100 in Decimal = 64 in Hexadecimal

G I W V C 5 E H 7 J N T 6 8 4 F V N J 9

1 W 2 Q A 4 D V N 5 J 8 K 4 F 0 L 0 G E continued from previous row

Q 3 D F 5 T G B N 8 7 0 9 H K T 5 D 3 D continued from previous row

W 3 G B H F C V H M Y 7 J 5 T 6 H F R 4 continued from previous row

1 W 2 Q A 4 D V N 5 J 8 K 4 F 0 L 0 G E continued from previous row

Security Data Var

Conditional Items Mandatory Items

30 U

Security
 EXAMPLE 2 - 1 SEGMENT, ALL CONDITIONAL AND OPTIONAL DATA FILEDS FIELDS POPULATED

New Item 

number Element Description Field 

Size

Unique /

Repeated 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Notes

1 Format Code 1 U M

5 Number of Legs Encoded 1 U 1

11 Passenger Name 20 U D E S M A R A I S / L U C

253 Electronic Ticket Indicator 1 U E

7 Operating Carrier PNR Code 7 R A B 1 2 C 3

26 From City Airport Code 3 R Y U L

38 To City Airport Code 3 R F R A

42 Operating Carrier Designator 3 R A C

43 Flight Number 5 R 0 8 3 4

46 Date of Flight (Julian date) 3 R 3 2 6 326 = November 22nd (2011 Calendar)

71 Compartment Code 1 R J

104 Seat Number 4 R 0 0 3 A

107 Check-In Sequence Number 5 R 0 0 2 7

113 Passenger Status 1 R 1

 6 Field Size of variable size field (Conditional + Airline item 

4)

2 R 6 7

103 in Decimal = 67 in Hexadecimal

8 Beginning of version number 1 U >

 9 Version Number 1 U 5

10 Field Size of following structured message – unique 2 U 3 2 50 in Decimal = 32 in Hexadecimal

15 Passenger Description 1 U 1

12 Source of Check-in 1 U W

14 Source of Boarding Pass Issuance 1 U W

22 Date of Issue of Boarding Pass (Julian Date) 4 U 1 3 2 5 1325 = November 21st 2011

16 Document Type 1 U B

21 Airline Designator of Boarding Pass issuer 3 U A C

23 Baggage Tag License Plate Number (s) 13 U 0 0 1 4 1 2 3 4 5 6 0 0 2

31 1st Non-Consecutive Baggage Tag License Plate 

Number

13 U

0 0 1 4 1 2 3 4 6 7 0 0 1

32 2nd Non-Consecutive Baggage Tag License Plate 

Number

13 U

0 0 1 4 1 2 3 4 7 8 9 0 1

 17 Field Size of Following Structured Message – repeated 2 R 2 A

42 in Decimal = 2A in Hexadecimal

142 Airline Numeric Code 3 R 0 1 4

143 Document Form/Serial Number 10 R 1 2 3 4 5 6 7 8 9 0

18 Selectee Indicator 1 R Not applicable on that flight

108 International Documentation Verification 1 R 1

19 Marketing Carrier Designator 3 R A C

20 Frequent Flyer Airline Designator 3 R A C

236 Frequent Flyer Number 16 R 1 2 3 4 5 6 7 8 9 0 1 2 3

89 ID/AD Indicator 1 R

118 Free Baggage Allowance 3 R 4 P C

 254 Fast Track 1 R Y Fast Track elligible

4 For individual airline use Var R L X 5 8 Z Airline specific

25 Beginning of Security Data 1 U ^

28 Type of Security Data 1 U 1

29 Length of Security Data 2 U 6 4 100 in Decimal = 64 in Hexadecimal

G I W V C 5 E H 7 J N T 6 8 4 F V N J 9

1 W 2 Q A 4 D V N 5 J 8 K 4 F 0 L 0 G E continued from previous row

Q 3 D F 5 T G B N 8 7 0 9 H K T 5 D 3 D continued from previous row

W 3 G B H F C V H M Y 7 J 5 T 6 H F R 4 continued from previous row

1 W 2 Q A 4 D V N 5 J 8 K 4 F 0 L 0 G E continued from previous row

Mandatory Items Conditional Items - Flight Segment # 1 Security

30 Security Data Var U
EXAMPLE 3 - 1 SEGMENT, PARTIALLY POPULATED 

New Item 

number Element Description Field Size

Unique /

Repeated 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Notes

1 Format Code 1 U M

5 Number of Legs Encoded 1 U 1

11 Passenger Name 20 U G R A N D M A I R E / M E L A N I E

253 Electronic Ticket Indicator 1 U E

7 Operating Carrier PNR Code 7 R A B C 1 2 3

26 From City Airport Code 3 R G V A

38 To City Airport Code 3 R C D G

42 Operating Carrier Designator 3 R A F

43 Flight Number 5 R 0 1 2 3

46 Date of Flight (Julian date) 3 R 3 3 9 339 = December 5th (2011 Calendar)

71 Compartment Code 1 R C

104 Seat Number 4 R 0 0 2 F

107 Check-In Sequence Number 5 R 0 0 2 5

113 Passenger Status 1 R 1

 6 Field Size of variable size field (Conditional + Airline item 

4)

2 R 3 0

48 in Decimal = 30 in Hexadecimal

8 Beginning of version number 1 U >

 9 Version Number 1 U 5

10 Field Size of following structured message – unique 2 U 0 0 0 in Decimal = 00 in Hexadecimal

15 Passenger Description 1 U

12 Source of Check-in 1 U

14 Source of Boarding Pass Issuance 1 U

22 Date of Issue of Boarding Pass (Julian Date) 4 U

16 Document Type 1 U

21 Airline Designator of Boarding Pass issuer 3 U

23 Baggage Tag License Plate Number (s) 13 U

31 1st Non-Consecutive Baggage Tag License Plate 

Number

13 U

32 2nd Non-Consecutive Baggage Tag License Plate 

Number

13 U

 17 Field Size of Following Structured Message – repeated 2 R 2 A

42 in Decimal = 2A in Hexadecimal

142 Airline Numeric Code 3 R 0 5 7

143 Document Form/Serial Number 10 R 1 2 3 4 5 6 7 8 9 0

18 Selectee Indicator 1 R

108 International Documentation Verification 1 R

19 Marketing Carrier Designator 3 R A F

20 Frequent Flyer Airline Designator 3 R A F

236 Frequent Flyer Number 16 R 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6

89 ID/AD Indicator 1 R

118 Free Baggage Allowance 3 R

 254 Fast Track 1 R Y Fast Track elligible

4 For individual airline use Var R Airline specific

25 Beginning of Security Data 1 U ^

28 Type of Security Data 1 U 1

29 Length of Security Data 2 U 64 100 in Decimal = 64 in Hexadecimal

G I W V C 5 E H 7 J N T 6 8 4 F V N J 9

1 W 2 Q A 4 D V N 5 J 8 K 4 F 0 L 0 G E continued from previous row

Q 3 D F 5 T G B N 8 7 0 9 H K T 5 D 3 D continued from previous row

W 3 G B H F C V H M Y 7 J 5 T 6 H F R 4 continued from previous row

1 W 2 Q A 4 D V N 5 J 8 K 4 F 0 L 0 G E continued from previous row

Security Data Var

Mandatory Items Conditional Items - Flight Segment # 1 Security

30 U
EXAMPLE 4 - 2 SEGMENTS, ALL CONDITIONAL AND OPTIONAL DATA FILEDS FIELDS POPULATED

New Item 

number Element Description Field Size

Unique /

Repeated 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Notes

1 Format Code 1 U M

5 Number of Legs Encoded 1 U 2

11 Passenger Name 20 U D E S M A R A I S / L U C

253 Electronic Ticket Indicator 1 U E

7 Operating Carrier PNR Code 7 R A B C 1 2 3

26 From City Airport Code 3 R Y U L

38 To City Airport Code 3 R F R A

42 Operating Carrier Designator 3 R A C

43 Flight Number 5 R 0 8 3 4

46 Date of Flight (Julian date) 3 R 3 2 6 326 = November 22nd (2011 Calendar)

71 Compartment Code 1 R J

104 Seat Number 4 R 0 0 3 A

107 Check-In Sequence Number 5 R 0 0 2 7

113 Passenger Status 1 R 1

 6 Field Size of variable size field (Conditional + Airline item 

4)

2 R 5 A

90 in Decimal = 5A in Hexadecimal

8 Beginning of version number 1 U >

 9 Version Number 1 U 5

10 Field Size of following structured message – unique 2 U 2 5 37 in Decimal = 25 in Hexadecimal

15 Passenger Description 1 U 1

12 Source of Check-in 1 U W

14 Source of Boarding Pass Issuance 1 U W

22 Date of Issue of Boarding Pass (Julian Date) 4 U 1 3 2 5 1325 = November 21st 2011

16 Document Type 1 U B

21 Airline Designator of Boarding Pass issuer 3 U A C

23 Baggage Tag License Plate Number (s) 13 U 0 0 1 4 1 2 3 4 5 6 0 0 2

31 1st Non-Consecutive Baggage Tag License Plate 

Number

13 U

0 0 1 4 1 2 3 4 6 7 0 0 1

32 2nd Non-Consecutive Baggage Tag License Plate 

Number

13 U

 17 Field Size of Following Structured Message – repeated 2 R 2 A

42 in Decimal = 2A in Hexadecimal

142 Airline Numeric Code 3 R 0 1 4

143 Document Form/Serial Number 10 R 1 2 3 4 5 6 7 8 9 0

18 Selectee Indicator 1 R Not applicable on that flight

108 International Documentation Verification 1 R 1

19 Marketing Carrier Designator 3 R A C

20 Frequent Flyer Airline Designator 3 R A C

236 Frequent Flyer Number 16 R 1 2 3 4 5 6 7 8 9 0 1 2 3

89 ID/AD Indicator 1 R

118 Free Baggage Allowance 3 R 3 P C

 254 Fast Track 1 R Y Fast Track elligible for this segment

4 For individual airline use Var R L X 5 8 Z Airline specific

7 Operating Carrier PNR Code 7 R D E F 4 5 6

26 From City Airport Code 3 R F R A

38 To City Airport Code 3 R G V A

42 Operating Carrier Designator 3 R L H

43 Flight Number 5 R 3 6 6 4

46 Date of Flight (Julian date) 3 R 3 2 7 327 = November 23rd (2011 Calendar)

71 Compartment Code 1 R C

104 Seat Number 4 R 0 1 2 C

107 Check-In Sequence Number 5 R 0 0 0 2

113 Passenger Status 1 R 1

 6 Field Size of variable size field (Conditional + Airline item 

4)

2 R 2 E

46 in Decimal = 2E in Hexadecimal

 17 Field Size of Following Structured Message – repeated 2 R 2 A

42 in Decimal = 2A in Hexadecimal

142 Airline Numeric Code 3 R 0 1 4

143 Document Form/Serial Number 10 R 0 9 8 7 6 5 4 3 2 1

18 Selectee Indicator 1 R Not applicable on that flight

108 International Documentation Verification 1 R 1

19 Marketing Carrier Designator 3 R A C

20 Frequent Flyer Airline Designator 3 R A C

236 Frequent Flyer Number 16 R 1 2 3 4 5 6 7 8 9 0 1 2 3

89 ID/AD Indicator 1 R

118 Free Baggage Allowance 3 R 3 P C

 254 Fast Track 1 R N Fast Track NOT elligible for this segment

4 For individual airline use Var R W Q Airline specific

25 Beginning of Security Data 1 U ^

28 Type of Security Data 1 U 1

29 Length of Security Data 2 U 6 4 100 in Decimal = 64 in Hexadecimal

G I W V C 5 E H 7 J N T 6 8 4 F V N J 9

1 W 2 Q A 4 D V N 5 J 8 K 4 F 0 L 0 G E continued from previous row

Q 3 D F 5 T G B N 8 7 0 9 H K T 5 D 3 D continued from previous row

W 3 G B H F C V H M Y 7 J 5 T 6 H F R 4 continued from previous row

1 W 2 Q A 4 D V N 5 J 8 K 4 F 0 L 0 G E continued from previous row

Mandatory Items Conditional Items - Flight Segment # 1 Security

30 Security Data 100 U

Mandatory Items - Flight Segment # 2 Conditional Items - Flight Segment # 2
EXAMPLE 5 - 2 SEGMENTS, PARTIALLY POPULATED

New Item 

number Element Description Field Size

Unique /

Repeated 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Notes

1 Format Code 1 U M

5 Number of Legs Encoded 1 U 2

11 Passenger Name 20 U G R A N D M A I R E / M E L A N I E

253 Electronic Ticket Indicator 1 U E

7 Operating Carrier PNR Code 7 R A B C 1 2 3

26 From City Airport Code 3 R G V A

38 To City Airport Code 3 R C D G

42 Operating Carrier Designator 3 R A F

43 Flight Number 5 R 0 1 2 3

46 Date of Flight (Julian date) 3 R 3 3 9 339 = December 5th (2011 Calendar)

71 Compartment Code 1 R C

104 Seat Number 4 R 0 0 2 F

107 Check-In Sequence Number 5 R 0 0 2 5

113 Passenger Status 1 R 1

6 Field Size of variable size field (Conditional + Airline item 

4)

2 R 3 0

48 in Decimal = 30 in Hexadecimal

8 Beginning of version number 1 U >

 9 Version Number 1 U 5

10 Field Size of following structured message – unique 2 U 0 0

15 Passenger Description 1 U

12 Source of Check-in 1 U

14 Source of Boarding Pass Issuance 1 U

22 Date of Issue of Boarding Pass (Julian Date) 4 U

16 Document Type 1 U

21 Airline Designator of Boarding Pass issuer 3 U

23 Baggage Tag License Plate Number (s) 13 U

31 1st Non-Consecutive Baggage Tag License Plate 

Number

13 U

32 2nd Non-Consecutive Baggage Tag License Plate 

Number

13 U

 17 Field Size of Following Structured Message – repeated 2 R 2 A

42 in Decimal = 2A in Hexadecimal

142 Airline Numeric Code 3 R 0 5 7

143 Document Form/Serial Number 10 R 1 2 3 4 5 6 7 8 9 0

18 Selectee Indicator 1 R Not applicable on that flight

108 International Documentation Verification 1 R

19 Marketing Carrier Designator 3 R A F

20 Frequent Flyer Airline Designator 3 R A F

236 Frequent Flyer Number 16 R 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6

89 ID/AD Indicator 1 R

118 Free Baggage Allowance 3 R 2 0 K

 254 Fast Track 1 R Y Fast Track elligible for this segment

4 For individual airline use Var R

7 Operating Carrier PNR Code 7 R D E F 4 5 6

26 From City Airport Code 3 R C D G

38 To City Airport Code 3 R D T W

42 Operating Carrier Designator 3 R N W

43 Flight Number 5 R 0 0 4 9

46 Date of Flight (Julian date) 3 R 3 3 9 339 = December 5th (2011 Calendar)

71 Compartment Code 1 R F

104 Seat Number 4 R 0 0 1 A

107 Check-In Sequence Number 5 R 0 0 0 2

113 Passenger Status 1 R 1

 6 Field Size of variable size field (Conditional + Airline item 

4)

2 R 2 C

44 in Decimal = 2C in Hexadecimal

 17 Field Size of Following Structured Message – repeated 2 R 2 A

42 in Decimal = 2A in Hexadecimal

142 Airline Numeric Code 3 R 0 1 2

143 Document Form/Serial Number 10 R 0 9 8 7 6 5 4 3 2 1

18 Selectee Indicator 1 R 0

108 International Documentation Verification 1 R 1

19 Marketing Carrier Designator 3 R

20 Frequent Flyer Airline Designator 3 R

236 Frequent Flyer Number 16 R

89 ID/AD Indicator 1 R

118 Free Baggage Allowance 3 R 2 P C

 254 Fast Track 1 R Fast Track eligibility is not qualified

4 For individual airline use Var R

25 Beginning of Security Data 1 U ^

28 Type of Security Data 1 U 1

29 Length of Security Data 2 U 6 4 100 in Decimal = 64 in Hexadecimal

G I W V C 5 E H 7 J N T 6 8 4 F V N J 9

1 W 2 Q A 4 D V N 5 J 8 K 4 F 0 L 0 G E continued from previous row

Q 3 D F 5 T G B N 8 7 0 9 H K T 5 D 3 D continued from previous row

W 3 G B H F C V H M Y 7 J 5 T 6 H F R 4 continued from previous row

1 W 2 Q A 4 D V N 5 J 8 K 4 F 0 L 0 G E continued from previous row

U

Security

30 Security Data 100

Mandatory Items Conditional Items - Flight Segment # 1 Mandatory Items - Flight Segment # 2 Conditional Items - Flight Segment # 2
RESOLUTION 792

Attachment ‘C’

REFERENCES

Secretary note: the lines with  in front have been amended; the lines with  in front have been added. 

No Description Notes Set of Values

 m Marketing carrier Designator Airline code of the marketing carrier (can be same as operating carrier) Both two IATA caracter code or three IATA letter code can be used

No Description Notes Set of Values

 o Airline Designator of Boarding pass issuer Identifies the origin of the data encoded in the airline individual use 

field Both two IATA caracter code or three IATA letter code can be used

No Description Notes Set of Values

 s Fast Track Indicates if the passenger is elligible to Fast Track 'Y'': Yes, ''N'': No , Blank means it is unqualified 

(Field is omitted if not used) 

No Description Notes Set of Values

 t Operating Carrier Designator Airline code of the operating carrier Both two IATA caracter code or three IATA letter code can be used

No Description Notes Set of Values

 u

Check-In Sequence Number References obtained from the operating carrier for the flight Usually appears as 4 numerics and an optional alpha or a blank. However, 

"Infants" are a known exception where Alphanumerical (full ASCII set) 

values may appear, depending on individual Host Systems.

No Description Notes Set of Values



42

Frequent Flyer Number 2 characters of 3 letters airline designator followed by up the 13 

numerics or alphanumerics, or 16 numerics if the FFN is 16 digits.

Up to 16 Numerics or Alphanumeric's Depends on carriers and alliances, left justified and trailing blanks wit a 

maximum of 16 Alphanumeric's


RECOMMENDED PRACTICE 1701a

PASSENGER DATA HARMONIZATION

(new)

P6.3.1

PSC(33)1701a

RECOMMENDED that Aircraft Operators, States and Airports work together to 

exchange Passenger Data to enhance national, aviation and border security, and 

passenger facilitation. 

1. INTRODUCTION

States have long recognized that passenger data supplied by Aircraft Operators is a 

critical element of the State’s border control and risk management processes. 

A growing number of States require Aircraft Operators to provide Passenger Data 

related to certain travel and reservation information held in an Aircraft Operator’s 

reservation and/or departure control system. Various Passenger Data exchange 

requirements, often in different message formats, has resulted in the proliferation of 

sometimes conflicting national requirements.

2. SCOPE

This Recommended Practice on Passenger Data Harmonization is intended to provide 

a global framework on agreed Passenger Data elements and a standard way to transmit 

the Passenger Data elements between States and Aircraft Operators systems.

This Recommended Practice is not intended to cover the following aspects:

 Laws or Regulations

 Data Transmission protocol and/or timing

 Data Processing

 Filtering of Data

 Storage of Data

 Data Protection

These aspects are covered by ICAO Doc 9944, and are managed through a bilateral 

arrangement between the States and Aircraft Operators as defined by national 

legislation.
3. PURPOSE

The purpose of this Recommended Practice is to standardize Passenger Data 

collection and transmission to:

 minimize cost to the industry

 improve the quality of Passenger Data that States receive

 facilitate the identification of potentially high-risk passengers with the objective 

to improve national, aviation and border security

 facilitate the clearing of low risk travelers

The recommendations also seeks to assist States in determining data requirements 

and developing procedures in order to minimize unilaterally imposed data transfer 

that differs substantially from one State to another (or “that differ substantially 

between States”). 

4. PASSENGER DATA ELEMENTS

For States requesting Passenger Data in addition to specific travel document details, 

it is recommended that the message structure and content of PNRGOV developed 

by the PADIS Board and to be endorsed by ICAO in its Document 9944 be adopted. 

The PNRGOV message is designed to provide a consistent approach for all Aircraft 

Operators required to provide PNR information to States. In an effort to standardize 

the PNRGOV message structure, the PADIS Board has developed the “Principles, 

Functional and Business Requirements” document, which is intended to provide 

guidance to Aircraft Operators, system suppliers and States that are implementing 

the PNRGOV message. The information contained in the document should be 

utilized in conjunction with the PNRGOV EDIFACT Implementation Guide. 

4.1 PNRGOV Message Modifications 

Under an agreement between IATA and the World Customs Organization (WCO), 

maintenance of the PNRGOV message format, and control over the authorization of 

modifications to that message structure, will be assumed by the WCO. Coordination 

of actual amendments of the message structure itself will fall under the remit of the 

WCO API Contact Committee which is comprised of the WCO, IATA and ICAO 

Secretariats, as well as interested States. Any interested party may recommend 

modifications to the PNRGOV message structure by use of the existing WCO Data 

Modification Request (DMR). The change process is described in the Message 

Modifications Approved Revision Process PNRGOV Document. 

Filing Period: Effective Date:

1 March - 1 June 2012

13 April 2012
RECOMMENDED PRACTICE 1701d

SELF-SERVICE AUTOMATED DOCUMENT CHECK

(amending)

PSC(32 33)1701d

P6.3.2

Secretary note: the following text completely replaces the current text of RP 1701d

RECOMMENDED that, when Members offer automated Document Check capability 

in a dedicated or common environment, for the purposes of individual airline 

processes, the specification and standards as described in this Recommended 

Practice (RP) are applied.

1. INTRODUCTION

Airlines need to obtain and verify passenger data from Travel Documents in order to:

1. Perform a Positive ID check to verify that the passenger is who they present 

themselves to be

2. Verify that the passenger has the correct travel documents to be admitted to 

the country(s) they are travelling to or transiting through

3. Collect (or verify previously obtained) passenger data to be provided to 

government organizations in advance of the passengers arrival (API)

2. SCOPE

Document Check describes the specification and standards for Travel Document 

Data Capture and Document Check Applications to fulfill point 2 and facilitate point 3 

of the above. 

Member airlines, handling agents and airports will implement a Document Check 

process and/or facilities to include, but not be limited to, Document Check 

functionality. Future developments may include other functions, both business and 

technical. 

This Recommended Practice is solely concerned with Machine Readable Travel 

Documents where the passenger’s data can be extracted electronically by a device. 

While the Recommended Practice is not intended to cover the management and 

verification of other travel document requirements (i.e. non data requirements) the 

Document Check solution should identify these exceptions. These can include: 
• Travel Documents (Visas in particular) where the data cannot be extracted 

automatically, for example where the document is hand written

• Where a specified number of blank pages are required in the passport for 

entry

• Certain countries do not allow admission if there are entry stamps from 

others

• Certain countries require translation of the visa in multiple languages

• Manual, secondary inspections to verify fraudulent passport may be an airline 

process or state’s requirement 

• Babies / minors travelling on parent / guardian passports

• Marriage name / aliases that require manual verification 

• Countries that require proof that passengers meet health requirement such as 

vaccination certificates.

Such exclusions need to be recognized and managed separately as part of any 

implementation of a self-service solution.

3. PURPOSE

The purpose of Document Check is to automate the Passenger Travel Document 

Compliance Check process, thereby:

• minimizing improperly documented passenger fines

• saving staff and infrastructure costs associated with current manual process

• increase the penetration of self service kiosk check-in for complex route –

nationality combinations 

It is recommended that passengers travel document be captured during the self 

service check in process be used to automatically check that the passenger has 

correct Travel Documents to satisfy requirements for the departure, destination or 

transit countries. Airlines have a requirement to validate that each passenger has 

the correct documentation. This requirement is enshrined in most States’ legislation 

or immigration regulations. Where a passenger is carried who does not have correct 

travel documents for the transit or destination country, the airline will normally be 

fined and will have to carry the passenger back to the point of departure at the 

airlines own expense.

The passengers data can also be transmitted to the relevant authorities where 

required for API purposes. Increasingly, states are requiring Aircraft Operators to 

transmit passenger manifest and other relevant information to the destination country 

in advance of the aircraft arrival. However even when passenger’s data is 

transmitted to the relevant authorities and a positive response is returned, it does not 

replace the requirement to check that the passenger is in possession of the required 

Travel Documents.

The Document Check process is designed to enable the automatic capture of 

passengers’ data from their Travel Documents in a single process. 
The major benefits of Document Check are:

• Identify all improperly documented passengers thereby reducing associated 

fines and repatriation costs.

• Reduce passenger documentation compliance process and management 

costs.

• Reduce Passenger Service/operational staff and infrastructure required.

• Reduce staff training costs.

• Streamline and simplify boarding process, reducing flight delays

• Reduce system development and maintenance costs.

• Support the increased penetration of self-service check-in.

• Reduce passenger compensation for incorrect refusal to board.

• Enhance customer experience.

4. BUSINESS CASE

The financial benefit of implementing a Document Check solution will be different for 

each airline and will depend on:

• Number of international travelers carried by the airline.

• Route/nationality combinations.

• Efficiency of current passenger document compliance processes.

• Frequency and value of fines.

• Scope of the implementation.

• Cost of implementing Document Check solution.

While the many benefits of Document Check solution are detailed in the previous 

section, we have quantified the following factors in the business case:

1. Reduced passenger travel document compliance check costs

2. Reduced improperly documented passenger fines.

3. Increased penetration of self service kiosk check-in

5. DEFINITIONS 

For the purposes of this Recommended Practice, the following definitions apply;

5.1.Travel Document

An official identity document issued by a state or organization, which may be used by 

the rightful holder for international or domestic travel. Travel documents are 

normally Passports, National Identity Cards, and Visas, but can include a wide range 

of other documents such as: Driving Licences, Residence Cards and Refugee 

Documents.

5.2.Machine Readable Travel Document (MRTD)

Machine Readable Travel Document (e.g., passport, visa). Official document issued 

by a State or Organization which is used by the holder for international or domestic 

travel (e.g. passport, visa, official document of identity). The MRTD contains 

mandatory visual (eye readable) data and a separate mandatory data summary, 

intended for global use, reflecting essential data elements capable of being machine 

read. MRTD is defined in ICAO DOC 9303.
5.3.Self Service Data Capture

The action by which a passenger presents a Machine Readable Travel Document to 

the capture device for the purposes of automatically capturing Travel Document 

data.

5.4.Positive ID

Where the passenger presents their government issued ID to the aircraft operator

agent for verification.

5.5.Passenger Authentication

This is performed by comparing the data on the Boarding Token with that on the 

Travel Document

5.6.Document Check

Document Check ensures that the passenger has correct Travel Documents to 

satisfy the immigration requirements of the departure, destination and transit 

countries. The Document Check is based upon data extracted from the passengers 

Travel Document and itinerary details contained within the airlines systems.

5.7.Document Check Application

An application which automates Document Check 

5.8.Document Data Registration 

The process by which a passenger provides the airline with travel document data in 

any other method than Self Service Data Capture (e.g. keying the information on the 

airline web site, spelling the document information on the phone, etc..). This data can 

be used for Document Check and/or API purposes.

5.9.Passport 

An official government document that certifies a traveler’s identity and citizenship 

with a right to protection while abroad and a right to return to the country of 

citizenship.

5.10. API - Advance Passenger Information. 

Advanced Passenger Information or API as it is normally referred to, consists of 

passenger data which must be collected by airlines and communicated to the 

destination/transit country authorities. This data is communicated to the authorities 

using an Advanced Passenger Information System (APIS). This data normally 

consists of elements included in the passengers Travel Documents and itinerary, 

although some countries require additional information such as address where the 

passenger will be staying. Many countries require API and have their own proprietary 

APIS systems such as APP, AQQ, ESTA etc...

5.11. Self Service Check-In Application

An application used by the passenger to perform the check-in process at a selfservice device. This application is connected to the airline host systems.

5.12. Secure zone / airside check point

The point at which the check is made for the entitlement to enter the secure zone / 

airside.
5.13. Boarding token

Means the token used by the passenger to board the aircraft, for example BCBP 

(bar-coded boarding pass on paper or mobile), Machine Readable Travel Document 

(Passports, Visas, ID Cards), passenger biometrics, frequent flyer cards, etc.

5.14. Visa 

An official entry in a Passport or other Travel Document made by an official of a 

government to indicate that the bearer has been granted authority to enter or reenter the country or region concerned.

6. DOCUMENT CHECK PROCESS 

6.1.Eligibility

Only passengers holding Machine Readable Travel Documents are eligible to use 

Document Check.

6.2.Prerequisite

To use Document Check, the airline system / DCS, should include the functionality to 

keep track of the Document Check status. Passengers whose documents have been 

checked as per definition under 4.5, by a trusted source should be noted in the 

system.

6.3.Document Check Process Description

The standard process for Document Check can comprise three elements: 

• Document Data Registration

• Data Capture

• Document Check. 

6.3.1. Self Service Document Data Registration 

The process by which a passenger provides the airline with travel document data in 

any other method than Machine Readable capture (e.g. keying the information on 

the airline web site, spelling the document information on the phone, etc..).

6.3.2. Document Data Capture

The process by which a passenger presents their Machine Readable Travel 

Documents at a device to capture the data. This process should be required by the 

airline for each journey. 

It is recommended that full page document readers are used for that purpose. 

The device should also be RFID/NFC capable or upgradeable for potential future 

requirements such as e-Passports which utilize new data storage technologies. 

Should Document Data Registration be offered, the registered data should be 

compared with the data captured during Data Capture and both sets of data should 

be identical. Should the data not match, the Data Capture data should be used.
6.3.3. Document Check 

The process by which the MRTD captured data is processed along with the relevant 

itinerary data by a Document Check Application. 

The Document Check Application is an automated system that checks whether the 

passenger has sufficient Travel Documents to satisfy the immigration requirements 

of the departure, destination and transit countries. 

The possible results of Travel Data Check are:

• ‘Yes’ the passenger has correct travel document

• ‘No’ the passenger does not have correct travel documents because...

• ‘Conditional’, it is not possible to determine whether the passenger has 

correct documentation. Check ...

In the second two cases manual intervention is required by the airline or agent.

In any case, the system should immediately present an appropriate service message 

to the passenger.

6.4.API Process Description

The passengers Travel Document and itinerary data can also be used for API 

purposes

7. DOCUMENT CHECK PROCESS POINTS

7.1.Kiosk Check-In Passengers

It is recommended that the Document Check process is offered to passengers 

checking-in at a kiosk during the check-in transaction. The check-in kiosk should be 

equipped with an MRTD capture device and a relevant application to perform an 

automated Document Check

If the Document Check process (including travel data check) is successful, then the 

status of the passenger should be updated into the airline host system. 

The appropriate field in the BCBP could also be updated according to IATA 

Resolution 792. However, airline host data should always supersede BCBP data. 

7.2.Capability at airport for Off Airport Checked-In Passengers

It is recommended that self service Document Check capability is offered to 

passengers already checked-in off airport (e.g. online check-in and mobile check-in) 

by: 
• Providing a self service process point, which may be a kiosk or another device 

for that purpose only, either landside or airside (depending on airlines and 

local regulation processes) but prior to the boarding point. 

• At boarding as part of an automated process (e.g. Self Boarding) including 

both Document Check and boarding processes.

• Passengers checking bags could also have their data verified at the Fast Bag 

Drop location 

7.3.Signage

It is recommended that the following signage/icons are used by member airlines, 

airports or handling agents to advertise the simplified process availability at the 

airport.

This will create awareness, consistent passenger experience and help drive 

penetration of the Document Check globally.

8. TECHNICAL AND INFRASTRUCTURE ENVIRONMENT 

8.1.Product Functionality

To facilitate the Document Check process, it is recommended that the equipment 

deployed:

• should integrate an interactive screen to present instructions and information 

to the passenger

• must integrate an Machine Readable Travel Document capture device which 

can capture data from travel documents 

• should integrate 2D Bar Code capability to read the BCBP

• must utilize an appropriate application or module to perform Data Capture and 

Document Check

• should be interfaced to the airline host system to update the passenger 

status.

• could integrate a capture device to support other technologies such as RFID 

chip and NFC chip.

• could integrate a biometrics reader to perform Passenger Authentication when 

the passenger utilizes an e-Passport or a biometrics registration token.
8.2.Ergonomics

It is recommended to use a flat bed full page reader for Machine Readable Travel 

Document data capture. It is also recommended to use a single device capable of 

reading both MRTD and BCBP.

8.3.Data to be used for Document Check 

Data required to perform a Document Check as described in 5.3.3 should be 

extracted from the Travel Document and the itinerary data held with the airline 

systems or on the BCBP

To maximize positive results from the data verification system, it is recommended 

that where possible the following data is captured and used for the Document Check. 

Different data elements are required by different countries. If an element is missing, 

then the Document Check Solution may still be able to produce a positive response 

without manual intervention. Key elements which are normally required by all 

countries include Destination country, Nationality, Duration of Stay, Age/Date of 

Birth, Document Held, Document Expiry Date. 

Data required to perform a Document Check

Parameter Description Available from 

MRZ or BCBP

Destination 

Country

Final country/airport where the 

passenger will complete their journey



Departure 

Country

Country/airport where the passenger 

began their trip



Arrival Date Date on which the passenger will 

arrive in the destination country



Departure Date Date on which the passenger departs 

from the departure country

Duration of Stay The amount of time that the 

passenger will be spending in the 

destination country



Operating Carrier Two-letter code of the operating 

carrier the 



Return Onward 

Ticket

Whether the passenger has a return 

or onward ticket for all segments of 

the itinerary

Stay Type Purpose of stay

Destination Visa Whether passenger is holding a valid 

visa for destination country

Transit Points -

Only if transiting

Country(s)/airport(s) through which 

the traveler transits on the way to 

destination. Max 5 transit points

Transit Arrival 

Date & Time (if 

transiting)

Transit country arrival date/time

Transit Departure 

Date & Time (if 

transiting)

Transit country departure date/time
Transit Visa (if 

transiting)

Whether the passenger has a valid 

visa for transit country

Countries visited 

last 6 days

Countries Visited in the last 6 Days. 

Only required for Health regulations

Document Type Details of the passenger’s passport or 

passport-replacing travel document



Issue Date Date on which the travel document 

was issued

Expiry Date Date on which the travel document 

expires



Issuing Country Country that issued the travel 

document



Nationality Nationality country code 

Gender Gender 

Date of Birth Date of birth 

Passport Series Alpha characters of Passport Number 

Document 

Feature

Biometric, Digital Photo, or Machine 

Readable document features which 

impact regulations.

Country of Birth Country of birth code

Country of 

Residence

Country in which the passenger 

resides, either permanently or 

temporarily

Residency 

Document

Residency document held if traveler 

lives in a country different to their 

nationality

Grey = strongly recommended so as to maximize Yes/No responses. 

8.4.Off line travel data check

As most of the data needed to perform Document Check are located in both 

passengers Machine Readable Travel Document and BCBP, the Document Check 

process could be performed off-line where there is no direct access to the airline 

host system. In such cases the document requirements are verified locally and a 

message sent to the airline host system to update the passenger status using the 

messaging interface described in 7.4.1.

8.4.1. Messaging and Interface to airlines’ systems

Should a Document Check Application be used outside of the airline system 

environment, it is recommended that the interface between such system and the 

airline host system is handled through the IATA XML and EDIFACT existing 

standards. 

Filing Period: Effective Date:

1 March - 1 June 2012

13 April 2012

 RECOMMENDED PRACTICE 1701h

SECURITY CHECKPOINT ACCESS AND EGRESS

(new)

PSC(33)1701h

P6.3.3

All the content of this document is intended to be used as guidance material, to be 

considered by airports when applicable, subject to local requirements:

1. INTRODUCTION

 The recommendations that appear on this document are intended to be a 

useful reference for airport terminal design and management of the passenger 

flow around security checkpoint.

 The information provided comes from airports where the mentioned bestpractices have been implemented successfully.

 This document is not intended to be part of any regulation or mandate 

 This document is a joint effort of ACI and IATA.

2. SCOPE

The main focus of this best- practice guidance will be for security checkpoint access 

and egress.

2.1 Security checkpoint access:

 Pre- screening preparation zone and queuing space

 Divest tables and zones

 Tray feeding systems

2.2 Security checkpoint egress:

 Composure tables and zones

 Egress seating area

 Tray recovering systems
3 GEOMETRICAL CONFIGURATION 

3.1 Assumption

Default security checkpoint configuration:

• Configuration “2 X- RAYS to 1 WTMD” (Walk-Through Metal Detector)

• Centralized screening area

 The standard “2 X- RAYS to 1 WTMD” security checkpoint configuration has 

been pre- selected as best practice configuration, as it is widely used in 

average centralized airport screening areas all around the world, providing 

great efficiency and flexibility

 Airports that have implemented other Security checkpoint configurations (i.e. 

gate screening) may use the following information as an overall reference 

benchmark, depending on their local arrangements.

 It is important to mention that, for airports developing the one stop security 

concept for connecting passengers, the centralized security checkpoint area 

is the most efficient way to implement that concept.

3.2 Diagram
3.3 Dimensions

Following the previous schema, the ‘best practice‘ participant airports have the 

following dimensions – in centimeters (cm):

AVERAGE LOWER 

LIMIT

A Pre-screening and 

queuing

737 400

B Divest 247 100

C Composure 281 100

D Egress Seating 375 200

E 196 100

F 413 400

4 ACCESS

4.1 Pre-screening and queuing

4.1.1 2D Bar code scanning to provide access

2D bar code scanning is recommended to be conducted before entering the queue 

to determine passenger eligibility to access restricted area and/or segregated line.

4.1.2 Information on screening procedures

Information point, containing:

 Poster on regulation,

 Video explaining the process

 Information flyers available for passengers

 1 officer supervising the information procedures

4.1.3 Segregation of lines

Segregation of lines in at least two groups:

 Premium passengers / Frequent travelers

 Occasional travelers / Families with children

4.1.4 Queuing arrangements

 Provide tensa-barrier flexible queuing system

 1 supervisor / queuing manager on duty during peak times
4.1.5 Staff allocated to help passenger in pre-screening

 Customer Service ambassador to help and advise passengers

4.2 Divest tables and zones

4.2.1 Rectangular roller beds aligned with X-RAY feeding

 Roller beds could accommodate at least 3 passengers

4.2.2 Roller beds overlapped with tensa-barrier queuing

 Enable passenger divesting while moving along the queue

4.2.3 Staff allocated to control divesting and X-RAY feeding

 1 loader per X-RAY in-feed.



4.3 Tray feeding

Provide a mechanical system, integrated in the checkpoint infrastructure, for trays to 

be rolled back efficiently.

5 EGRESS

5.1 Composure tables and zones

5.1.1 Rectangular roller beds aligned with X-RAY out belt

 Provide roller beds and tables aligned – to accommodate at least 5 

Passengers 

 Secondary search table at 90° not to interfere with the flow 

5.1.2 Staff allocated to assist passengers

 2 Searchers – opposite sex – right behind the WTMD

 Private booths available for secondary search 

5.2 Egress seating area

 Tables for passengers to repack their hand luggage

 Seating possibilities to accommodate at least 2 passengers per X-RAY

5.3 Tray recovery

Provide a mechanical system, integrated in the checkpoint infrastructure, for trays to 

be rolled back efficiently.
6. OTHER CONSIDERATIONS

6.1 Ambience

It is very important to provide a good ambience, focusing at least on the following 

aspects:

 Cleanliness

 Light

 Temperature

6.2 Recommendations when shoe inspection is required

 Plastic slippers

 Soft floor covering

6.3 Courtesy and friendliness of staff

 Customer Service Training

 Language training

 Basic greetings: ”Good morning.. have a good flight”

6.4 Information on processing time

 It is very useful to inform the passenger about a standard waiting time, to gain 

predictability and reduce stress/hassle

7 MEASUREMENT OF PASSENGER PERCEPTION

It is highly recommended to measure the passenger perception of the security 

screening process, covering at lest these two aspects:

 Courtesy of security staff and perceived time at security

8 MEASUREMENT OF QUEUING TIME PERFORMANCE

It is highly recommended to have a performance indicator measurement process, to 

measure at least security checkpoint waiting tines and throughput, for security 

management to be able to allocate staff efficiently, according to the flow distribution. 

Filing Period: Effective Date:

1 March - 1 June 2012

13 April 2012

RECOMMENDED PRACTICE 1701i

INTERNATIONAL TRAVELER SCHEME

(new)

PSC(33)1701i

P6.3.6

RECOMMEND that Governments work together to develop commonalities between 

national registered traveler schemes to facilitate joining these together within wider 

multilateral initiatives. Where Governments offer registered traveler schemes, 

airlines underpin Government promotional activities and the facilities offered by 

airport operators support these schemes.

1. INTRODUCTION

1.1 A number of countries world-wide have established, or are in the process of 

establishing national, bilateral and multilateral registered traveler schemes. 

1.2 The concept of a registered traveler scheme is to provide pre-assessed lowrisk travelers with expedited passage through border controls.

1.3 These schemes deploy an automated process to:

• Check that the passenger is in possession of a genuine, valid travel document 

or token

• Verify the passenger’s biometric data against the travel document or token or 

a pre-existing biometric identifier supplied by the passenger during enrolment 

to ensure the travel document is presented by the rightful owner.

• Grant or deny admission according to pre-established specification.

2. SCOPE

2.1 Whilst each registered traveler scheme is unique, commonalities do exist; It is 

recommended that:

2.1.1 Operationally

• Registered traveler schemes may be separately developed and operated by a 

Government or jointly developed and operated between Government and 

Industry. 

• Where a charge is levied, the scheme should offer travelers a more bespoke 

service, i.e., web-based application including forms and the ability to schedule 

interviews

• The scheme should facilitate an increased efficiency in traveler clearance 

times

• Procedurally and practically clear for travelers to understand and operate
2.1.2 Eligibility

• The scheme should be open to nationals from more than one country 

• Age restrictions may apply 

• Membership should to be time limited, invariably linked to the length of the 

travel document. 

• Continued eligibility requires passing regular background checks.

2.1.3 Enrolment

• Enrolment is voluntary in all schemes

• All registered traveler schemes should collect biographic data and may 

request supplementary data 

• Each scheme will capture a minimum of one biometric

2.1.4 Background checks

• Regular background checks are conducted against national databases

• These may include biometric data and criminality checks.

3. PURPOSE

The purpose of a Registered Traveler Scheme is to allow travelers expedited 

passage through automated border controls following successful background checks 

and the recording of biometric data.

Governments should benefit from initiating a registered traveler scheme by 

enhancing security of the border through the use of biometrics, reducing illegal 

immigration, allowing more effective deployment of resources towards potentially 

higher-risk travelers and being able to obtain additional advanced information on 

travelers. Governments may also benefit in that additional sources of information 

may be utilized that they would not normally have access to in the identification of 

low-risk travelers.

Airlines may indirectly benefit from the additional vetting of travelers within the 

scheme, which offers greater security on the identity of the traveler and their 

admissibility by border control authorities. Where schemes incorporate direct transit 

points, airlines should additionally benefit from on-time departures where a 

passenger is transiting an airport and is required to make a border crossing, leading 

to cost efficiencies and the provision of better customer service.

Airport operators should expect a reduction in queue length and times which will 

facilitate a more efficient use of space and a possible deferment of infrastructure 

requirements and costs.

The vision is to ultimately create an International Traveler scheme which will bring 

registered traveler schemes together under one overall initiative. An International 

Traveler Scheme should enhance a passenger’s travel experience by granting them 

access to a range of registered traveler programs operated by participating countries 

where access would be otherwise unavailable. The Traveler should also benefit from 

a standardized application process, access to expedited automated border crossings 

and the creation of a more seamless journey. 

The recommendations also seek to assist Governments and Industry in designing 

data requirements for the implementation of a registered traveler scheme which may

facilitate multilateral agreements.
4. DEFINITIONS

For the purposes of this Recommended Practice, the following definitions apply;

4.1 Admission

The permission granted to a passenger to enter a State by the public authorities of 

that State in accordance with its national laws.

4.2 Automated Border Control (ABC)

An automated control system that authenticates travel documents and/or tokens and 

permits, or denies, admission to a traveler according to a pre-established 

specification.

The ABC may additionally verify the passengers’ biometric data against the travel 

document and/or token or a pre-existing database containing biometric data. It may 

also register the entry or exit of the country.

4.3 Biometrics

Biometrics are any means by which a person can be uniquely identified by 

evaluating one or more distinguishing biological traits. Unique identifiers include 

fingerprints, hand geometry, iris, retina, facial image, hand vein geometry, voice 

waves, DNA, and signatures.

4.4 International Traveler Scheme

An umbrella initiative that seeks to bring countries existing registered traveler 

schemes together.

4.5 Registered Traveler Scheme

A registered traveler scheme allows pre-assessed low-risk travelers expedited 

passage through automated border control system following successful background 

checks and the recording of biometric data.

4.6 Token

A personalized secure credential that permits the authorized traveler to gain 

admission via automated border controls, subject to passing background checks 

and, in some instances, producing a valid travel document.

4.7 Travel Document

A passport or other official document of identity issued by a State or organization, 

which may be used by the rightful holder for international travel.

5. DATA FIELDS

In an effort to facilitate multilateral agreements the following represents a composite 

list of the information Governments may request for the Registered Traveler Scheme 

application process. This list is not exhaustive.
Biographic Information

• Last, First and Middle names 

• Gender

• Date of birth

Governments may additionally request;

• Surname or Academic title, prefix or suffix

• Maiden Name

• Alias

• Height

• Eye Color

• Town/State/Province of birth

Nationality and Citizenship

• Country of birth

• Country of Citizenship

• Immigration Status

• Nationality

Travel Document

• Travel Document type and number

• Expiry date

• Date of issue

Governments may additionally request;

• Government issuing the document

• Visa information

• Information on other travel documents 

Contact Details 

The following contact fields are primarily utilized to contact fee-paying applicants;

• Country of primary residence

• Address if different from primary residence

• Commencement date for current address

• Full current address details 

• Previous address history where the above covers less than 5 years

• Mailing address if this differs from the current address

• Home, Business and Mobile Telephone Numbers

• Email Address

• Invoice Address

• Preferred language and method of communication whether email or mail
Employment

The following information may be requested to inform background checks;

• Employment status and commencement date

• Occupation

• Employer name, address and telephone number

• Additional employment history where the above covers less than 5 years

Travel History 

Governments may additionally request;

• Boarding Pass available at time of enrolment 

• Average number of flights per year

• Travel history over a specified period

Criminality, Immigration and Customs Offences

Whilst the following information is not widely requested, it is utilized by Governments 

to inform background checks;

• Criminal conviction details

• Waiver of Inadmissibility details

• Customs offences

• Immigration offences 

Membership and Payment Details

Those Governments operating fee-paying registered traveler schemes may seek to 

establish:

• Where Governments offer varying levels of membership, the type of 

membership the applicant requires

• Payment method and bank details 

Terms and Conditions

• All Governments seek to ascertain that the applicant understands the terms 

and conditions of the scheme before proceeding.

Filing Period: Effective Date:

1 March - 1 June 2012

13 April 2012

RECOMMENDED PRACTICE 1701j

AUTOMATED AND SELF-SERVICE FLIGHT REBOOKING FOR IRREGULAR 

OPERATIONS

(new)

PSC(33)1701j

P6.3.5

RECOMMENDED that, when Members plan to offer Self-Service Flight Rebooking 

for Irregular Operations capability in a dedicated or common use environment, for 

the purposes of individual airline processes, the specification and standards as 

described in this Recommended Practice are applied.

1. PURPOSE

Automated and self-service flight rebooking focuses on how irregular operations 

can be improved from a passenger processing perspective by introducing 

automated and self-service options.

It is a pre-requisite to use good management practices and tools in order to 

implement any service recovery measures particularly through self-service options. 

The resulting benefits include improved customer service for all passengers and 

decreased costs for airlines.

This Recommended Practice is meant to complement, but not supersede, currently 

agreed-upon industry standards (e.g. AIRIMP, IATA Resolutions 735d/735e/766, 

A4A 120.20) or other bilateral agreements and arrangements between or among 

airlines or alliances.

2. SCOPE

This Recommended Practice addresses only Irregular Operations. The timeframe 

and conditions for Irregular Operations are defined by individual airline policy.

This Recommended Practice is limited to automated flight rebooking systems that 

provide self-service options to passengers. These flight rebooking systems can be 

either fully automated to the extent possible (no manual intervention) or partially 

automated with the objective to minimize passenger contact with airline ground 

staff.

3. GLOSSARY

a. Automated Rebooking System – Fully or partially automated system meant to 

rebook passengers impacted by delayed or cancelled flights, especially during 

Irregular Operations. Automated rebooking systems enhance airline efficiency and 

enable more consistent passenger processing.

b. Interline – Used in conjunction with another word to describe anything 

involving two or more airlines, such as interline itinerary, interline reservation, 

interline stopover, interline point, interline transaction, etc.
c. Irregular Operations (IRROPS) – Irregular Operations (IRROPS) is identified 

by an airline or ground handler acting on behalf of an airline when a disruption 

causes a planned flight schedule to become inoperable or delayed affecting both 

passengers and resources. An Irregular Operation (IRROP) may be, but not 

limited, to a flight delay, cancellation, diversion due to weather, mechanical 

problem, landing restriction, air traffic congestion, accident/ aircraft damage, 

security concern, immigration issue, boarding delay, crew or other staff issues. 

d. ITBA – Interline ticket and baggage agreement.

e. Online – Used in conjunction with another word to describe anything involving 

carriage over the services of one airline to another service of the same airline, such 

as an on-line itinerary, on-line reservation, on-line stopover, on-line connection, etc. 

f. SSD – Self Service Device.

4. BILATERAL AGREEMENTS

This document recommends that carriers, where applicable, should follow 

procedures as outlined in IATA Resolutions 735d/735e/766, AIRIMP and A4A 

Resolution 120.20. Bilateral or alliance agreements may exist that supersede the 

above Resolutions. These bilateral or alliance agreements may offer airlines 

additional flexibility to their automated and manual rebooking systems by offering 

seamless availability; direct sales and access; and interactive sales in order to 

establish firm confirmations for passengers.

5. CARRIER NOTIFIED OF IRREGULAR OPERATIONS

a. Carriers may be notified of Irregular Operations in the following ways:

i.Internally, by automatically receiving flight status information for both potential 

and confirmed disruptions, delays and cancellations.

ii.Externally, by leveraging alliance/codeshare functionality and/or bilateral flight 

status notices. E.g. Type B messages, XML, etc.

6. IRREGULAR OPERATIONS MANAGEMENT:

The following table is an overview of how certain elements during Irregular 

Operations may be managed. Where applicable, distinctions between online, 

interline, delays, cancellations, and misconnects, will be made. Airlines may 

choose to follow these steps in accordance with their individual business rules.
Irregular Operations process

Note: Unless noted 

otherwise, the 

processes below apply 

to the following 

irregular operations 

conditions:

1) Online Delay

2) Online Cancellation

3) Online Misconnect

4) Interline Delay

5) Interline 

Cancellation

6) Interline Misconnect

Note:

Automatically load operational status of the flight 

into RES/DCS system

Appropriate notices, according to airline 

procedure, should also be given to various 

partners (e.g. airport authorities, 

codeshare/alliance partners, etc.)

PNR transferred to the carrier automated rebook 

system. Consideration should be given to 

separate RES and DCS systems as well as 

ground handlers according to individual airline 

policy

PNR transferred of passengers in jeopardy or who 

will misconnect (business rule to define priorities)

Rebook the passenger on the best available flight 

according to the airline’s individual business rules

Rebooking may be prioritize and/or optimized 

through various methods:

• Routing – Non-stop versus connecting 

itinerary, domestic versus international, originating 

versus connecting

• Journey time – Using the shortest possible 

routing

• SSRs – Certain SSRs may be handled 

differently or manually (special attention should be 

given that certain SSRs are properly associated 

with new itinerary)

• Frequent flyer program – Depending on 

airline, certain tiers may be prioritized

• Class of service – e.g. First class may be 

prioritized before economy

• Booking code – e.g. Y may be prioritized 

before M

• Ticket value (fare paid)

• Groups – May need to be handled differently 

or manually
Irregular Operations process

Note: Unless noted 

otherwise, the 

processes below apply 

to the following 

irregular operations 

conditions:

1) Online Delay

2) Online Cancellation

3) Online Misconnect

4) Interline Delay

5) Interline 

Cancellation

6) Interline Misconnect

Note:

• Booking channel – Passengers who booked 

through various booking channels may need to be 

handled differently or manually based on certain 

restrictions

• Passenger record checked/validated for 

MCT

Document Check – Ensure the passenger’s travel 

documents permits travel via the new routing 

booked to avoid passenger inconvenience and 

carrier fines

Check flight status prior to booking to ensure flight 

is on time or operable. Note: This step may not 

be possible for interline-booked itineraries

Notify passenger of new routing (see Passenger 

communication 7)

Reinstatement – Consideration needs to be made 

in case a flight is reinstated or reverts back to 

original ETD—system may either have an “undo” 

function or could be handled manually

Automated reinstatement 

may only be possible for 

online itineraries only. 

Other airline segments 

may need to be manually 

processed.

Passenger’s record (PNR or DCS) should indicate 

it has been handled or rebooked by automated 

rebook system (according to airline’s business 

rules)

Indicator may be possible 

for online itineraries only 

and not carry over to 

other airline segments.

Passenger’s record (PNR or DCS) needs to be 

ready for use through a self-service channel (e.g. 

self-service device, kiosk, online, mobile)

This step may not be 

possible for interlinebooked itineraries.

Passenger’s record may be made ready for use 

by: E-ticket synchronization, matching, reassociation, etc.

This step may not be 

possible for interlinebooked itineraries.

Ticket reissuance

Where applicable, refund or process for ancillary, 

optional, additional, baggage charges and 

compensation according to government regulation 

should be considered

This step may not be 

possible for interlinebooked itineraries.
Irregular Operations process

Note: Unless noted 

otherwise, the 

processes below apply 

to the following 

irregular operations 

conditions:

1) Online Delay

2) Online Cancellation

3) Online Misconnect

4) Interline Delay

5) Interline 

Cancellation

6) Interline Misconnect

Note:

Need to make provisions for sending government 

security messages (e.g. Flight cancellation, AQQ, 

Secure flight, etc.) according to the appropriate 

government’s requirements

Save seats – System may save seat preference 

(from DCS or PNR) during or after automated 

rebooking process

This step may not be 

possible for interlinebooked itineraries.

Check-in – System may automatically check-in 

passengers after rebooking process is complete. 

Consideration may need to be made for scenarios 

requiring through check-in

This step may not be 

possible for interlinebooked itineraries.

Check-in – Passengers may be required to checkin after rebooking process is complete. During 

check-in, passengers may be offered additional 

rebooking opportunities

This step may not be 

possible for interlinebooked itineraries.

Baggage should be rerouted or processed (see 

Baggage movements 11)

During rebooking process, affected or duplicated 

flight segments should be cancelled. It’s the 

airline’s individual business policy to determine 

duplicate flight segment handling (“protection”). 

E.g. Additional segments booked for delayed 

flights, alternate routings, etc.

Note: Rebook passenger on interline itinerary if 

applicable. There may need to be a special 

bilateral agreement required to allow automatic 

rebook of interline itineraries (as provided in 

AIRIMP). Preference should be given to alliance 

carrier rebook (as detailed in company policies 

and alliance agreements).

Note: Evaluate availability and apply business 

rules based on passenger status to make a 

decision on the rebooking choice (own or other 

airline). It is recommended to contact the new 

operating carrier to secure space.
Irregular Operations process

Note: Unless noted 

otherwise, the 

processes below apply 

to the following 

irregular operations 

conditions:

1) Online Delay

2) Online Cancellation

3) Online Misconnect

4) Interline Delay

5) Interline 

Cancellation

6) Interline Misconnect

Note:

Note: Request availability from other airline 

through various established methods (e.g. 

seamless availability; direct sales; direct access; 

interactive sales) in order to get firm confirmation 

of the availability. (Need to follow rules as defined 

by IATA Resolutions 766/735d, A4A Resolution 

120.20 and AIRIMP or as provided in procedures 

outlined through bilateral agreements).

7. PASSENGER COMMUNICATION 

During Irregular Operations, and especially after rebooking occurs, every effort 

should be made to notify passengers of flight changes.

If a customer is rebooked on an interline itinerary, consideration should be made 

that not all carriers share the same rules regarding handling or ancillary charges. 

Where possible, or mandated by regulation, notification should be made available 

to customer regarding these differences.

Messages should be sent to passengers during, but not limited to, the following 

scenarios:

a. Passenger rebooked to an earlier than scheduled departure.

b. Passenger rebooked to a later departure.

c. Flight cancellations.

Government requirements, regulations, or commercial agreements need to be 

observed where applicable (e.g. some governments require verbal or electronic 

updates at specified intervals).
Some delay types may require additional or special notification:

a. Weather/Air Traffic Control (ATC)

i. Advise the passenger of the reason for delay.

ii. May need to advise passenger to check-in within original cut-off times 

due to delay volatility.

b. Mechanical/inbound aircraft delay: 

i. Advise passengers of the reason for the delay. 

ii. Advise passengers that ETD is subject to change frequently and 

additional rebooking processes may be required. 

8. MESSAGING TYPES

a. If available, passengers should be contacted via their preferred method:

i. Email; phone; automated phone calls; interactive voice response (IVR); 

kiosk (SSD)/ SMS, etc.

b. Government privacy regulations should be observed as applicable.

c. Content of message should be as specific as possible and give direction on 

next steps and options including where to proceed for processing and checkin.

9. INTERNAL COMMUNICATIONS

a. Every effort should be made to communicate delays and cancellations with 

internal departments/stakeholders (e.g. gate agents) prior to passenger 

notification.

i. Ensures better preparation and alignment of resources (allows airlines 

to develop their “game plan”).

ii. Optimizes automated rebooking process.

iii. Enhances customer service by assuring that airline resources can 

anticipate the passenger’s issue.
10. SELF SERVICE DELIVERY 

a. Passengers whose PNRs have been rebooked and are in a check-in ready 

state, should be able to check-in via:

i. Common use or proprietary original carrier self-service device, mobile 

or web.

ii. OA self-service device, mobile or web.

iii. Phone (Interactive Voice Response – IVR).

b. Self-service devices could be located in various strategic locations to 

maximize passenger convenience (e.g. transit, airside areas).

11. BAGGAGE MOVEMENTS 

In some cases, baggage will be accepted prior to passenger encountering a delay 

or cancellation. During these circumstances, every attempt should be made to 

ensure passenger and baggage stay together (see IATA Recommended Practice 

1745/1800, A4A Recommended Practice 30.45/30.49, IATA Resolutions 735d/743a 

for further information).

12. MISCELLANEOUS

Miscellaneous considerations regarding, but not limited to, meal vouchers; 

overnight accommodations; CRM (Customer Relationship Manager) updates with 

passenger inconvenience info; privacy policies, etc., will be determined by 

individual airline policies or government regulations.

Filing Period: Effective Date:

1 March - 1 June 2012

13 April 2012
RECOMMENDED PRACTICE 1701k

SELF BOARDING

(amending)

PSC(32 33)1701k

Secretary note: the following text completely replaces the current text of RP 1701k

P6.3.4

RECOMMENDED that, when Members plan to operate Self Service Boarding in a 

dedicated or common use environment, for the purposes of individual airline 

processes the specification and standards as described in this Recommended 

Practice are applied.

1. INTRODUCTION/SCOPE

Self Boarding describes the specifications and standards for Self-Service boarding 

devices. Member airlines will implement a Self Boarding process to include, but not 

be limited to, self-boarding functionality. Future developments may include other 

functions, both business and technical.

2. PURPOSE

The Self Boarding concept is to provide passengers with the possibility to board the 

aircraft without agent assistance.

The major benefits of Self Boarding are:

• Extending customer control throughout the journey,

• Faster processing time at the gate,

• Allows agents to add value by focusing on exceptions and passengers 

with special needs,

• Leads to optimum use of airline and airport facilities,

• Shared running costs (when operated as common use)

3. DEFINITIONS

For the purposes of this Recommended Practice, the following definitions will apply;

3.1. Self Boarding Process

An airline offering the ability for a passenger to self-scan their boarding token to gain 

entry to the aircraft in a controlled manner.

Additional / Related Services: Offering the capability for flights requiring passenger 

authentication and/or document checks.
3.2. Controlled Manner

The method of control by which a passenger boards an aircraft. Those are listed in 

the following and may be applied as well in combination.

3.3. Automated barrier

An automated barrier is an access control device equipped with physical obstacles 

(doors, flaps, turnstile, etc.) and flow control functions (pictograms, displays, etc.).

3.4. Agent control

An agent supervising the boarding process

3.5. Visual / Audible indicators

Visual and audible indicators provide the passenger with information about the 

validity check of the boarding token at the boarding point.

3.6. Self Scanning

The action by which a passenger presents a boarding token to the boarding device 

for the purpose of self service boarding.

3.7. Passenger Authentication

This is performed by comparing the data on the boarding token with accepted forms 

of identification carried by the passenger and verified by an agent.

3.8. Verified identification

The process step whereby the passenger presents their government-issued ID for 

verification.

3.9. Document Check

Document check means the inspection step to verify that a passenger’s travel 

documents a comply with government requirements allowing entry to a destination 

country or passage through a transiting country.’.

3.10. Boarding Application

This is the computerized application used by the airline to perform the boarding 

process.

3.11. Passenger Boarding Token

The Self Boarding device may read different types of tokens, for example: BCBP 

(bar-coded boarding pass on paper or mobile phone), machine readable travel 

documents (passports, visas, ID cards), passenger biometrical data, frequent flyer 

cards, etc.

4. SELF BOARDING PROCESS

4.1. Eligibility

All passengers holding an electronic ticket with boarding token, not requiring 

additional processing at the gate are eligible to use the Self Boarding process. 
4.2. Exceptions and Special Treatment

• There are exceptions from the above stated group of eligible passengers such 

as: 

• Unaccompanied minors

• Passengers with special seat assignments

• Infants

• Disabled passengers requesting assistance 

• Passengers requiring a document check that should normally have been 

performed before the boarding process.

• Regulatory compliance that require additional checks prior to approved 

boarding

• Passengers with coupons to be collected

4.3. Process Description

The Self Boarding process is described in detail below. Principally, the process may 

be designed to be controlled by an agent, or alternatively with the use of automated 

barriers incorporating passenger detection.

4.3.1. Self Boarding with agent control

• Self-boarding device is initialized and connected to the boarding application of 

the respective airline

• Device readiness indicated to passenger

• Passenger scans their own boarding token

• Boarding token information is captured and sent to the airline system

• Result of boarding token check is sent to the Self Boarding device

• Device indicates the result to the passenger (boarding approval/rejection 

communicated via display, pictograms, etc.)

4.3.2. Self Boarding with automated barrier and passenger detection

• Self Boarding device is initialized and connected to the boarding application of 

the respective airline

• Device readiness indicates to passenger

• Passenger scans their own boarding token

• Boarding token information is captured and sent to the airline’s systems

• Result of boarding token check is sent to the Self Boarding device

• Device indicates the result to the passenger (boarding approval/rejection 

communicated via display, pictograms, etc.) and allows passenger to pass 

through the barrier and board the aircraft.

• After confirmation that the passenger has crossed the barrier passenger’s 

status is set to “boarded” in the boarding application

Note:

The use of an automated barrier should not mandate any modification at the DCS 

level of the airline and the self boarding device should behave in a similar way to a 

BGR (Boarding Gate Reader).

If DCS does not recognize the status answer given by the Self Boarding device then 

the automated barrier should handle the detection and alarm control internally.
4.3.3. Exceptions from the standard process

• There are several exceptions to the standard process. Those are listed in the 

following together with the appropriate advice to handle each situation.

• Infants, Unaccompanied Minors and disabled passengers requesting 

assistance may be handled within the pre-boarding phase. Hence it is 

recommended that at least one traditional boarding position staffed by an 

agent is maintained at the gate.

• In case passengers are holding coupons to be collected by boarding staff at 

the gate. To guarantee the collection of all coupons an electronic means, such 

as electronic miscellaneous documents, should be implemented for the 

collection of excess baggage coupons

• Passengers trying to get oversized hand luggage through the Self Boarding 

point should be intercepted by boarding staff. 

• Regarding the process with use of an automated barrier the following 

exceptions from the standard process might apply:

o In case of rejection due to an invalid ticket boarding should not be 

allowed, the agent will be alerted and agent intervention is required.

o In case of a fraud attempt e.g., two passengers trying to board using 

one boarding token should not be allowed. The agent will be alerted 

and agent intervention is required.

o Optional: In case of a seat change at short notice or in absence of the 

passenger, the passenger may be provided with a seat-assignment 

print at the Self Boarding point. This applies as well for situations such 

as waiting list acceptance and upgrades. This may be implemented by 

integrating a printer in an automated barrier or other device.

o Regulatory compliance requiring additional checks such as exit row 

seating qualifications. 

4.3.4. Self Boarding without Passenger Authentication

The above described processes apply for flights that do not require a passenger 

authentication at the gate.

4.3.5. Self Boarding with Passenger Authentication

In case of a flight requiring a name / document reconciliation (Passenger 

Authentication) one of the following procedures should be performed: 

• Verification of the passenger’s biometrics at the boarding point,

• Agent assisted Passenger Authentication at the boarding point (e.g.,. at the 

jetty entrance),

• Agent assisted Passenger Authentication at a central check point before the 

boarding point.
5. TECHNICAL ASPECTS AND INFRASTRUCTURE

5.1. Product functionality

5.1.1. Functional requirements

The Self Boarding device should contain the following modules:

Boarding token reader including 2D barcode reading capability.

Clear Visual Instructions: To support a continuous and fast passenger flow, it is 

essential to offer well-thought-out passenger guidance. Depending on the situation 

the passenger should be informed and supported by graphical displays and/or 

pictograms leading him into the desired direction or to desired actions (for example, 

to go contact an agent)..

Note:

In general, regarding response times the Self Boarding process should not last 

longer than the manual process. In addition the devices should be flexible so that a 

carrier can easily expand the number of Self Boarding lanes.

5.1.2. Optional functional requirements

There are several optional requirements that may be considered when designing a 

Self Boarding device.

5.1.2.1. Automated barrier with detection algorithm

A barrier is recommended in case the Self Boarding device is operated without 

dedicated agent supervision. Detection algorithms provide a uniqueness check to 

insure:

• A boarding token is only used once 

• Only one passenger can pass through the boarding point with a single 

boarding pass.

5.1.2.2. Receipt printer for boarding slips

As mentioned above a printer should be integrated to provide the passenger with 

new seat information in case of changes at short notice. When using an automated 

barrier, the barrier should open as soon as the seat assignment print has been 

retrieved by the passenger.

5.1.2.3. Passport scanner

Should a passport scanner be required, a full page flatbed scanner is recommended.

5.1.3. Gate ergonomics

The self boarding device should allow easy access for passengers carrying hand 

luggage. 
5.2. Airport and Technical Infrastructure within a Common Use 

Environment

Self Boarding devices may be used by several carriers in a common use 

environment. To facilitate such use the devices should conform to common use 

standards. Reusability, scalability, and ease of integration are the primary criteria. 

Use of open and established standards such as XML, J2EE and Web services as 

well as SOA (Service Oriented Architectures) is strongly recommended.

In a common use environment, the ability to switch from automated Self Service 

Boarding to traditional BGR mode and vice versa is necessary.

The Self Boarding initiative targets the use of Self Boarding devices by different 

carriers with different DCS/boarding applications. This enables airlines at airports 

with non-exclusive gate areas to offer Self Boarding to their customers.

5.2.1. Closed / Open gate area

Self Boarding devices may be used both at open and closed gate areas.

6. SIGNAGE

The signage for Self Boarding devices should be promoted at all sites. It is 

recommended that this signage includes the words “Self Boarding”.

It is recommended that proper signage is visible to instruct customers on the proper 

placement of their boarding token over the token reader/scanner to ensure efficient 

customer flow through the self boarding gate. 

It is recommended that the following signage/icons are used by member airlines, 

airports or handling agents to advertise the simplified self-service process availability 

at the airport.

This will create awareness, consistent passenger experience and help penetration of 

the service globally.

Filing Period: Effective Date:

1 March - 1 June 2012

13 April 2012
RECOMMENDED PRACTICE 1706

FUNCTIONAL SPECIFICATION FOR STANDARD DEPARTURE CONTROL 

SYSTEM

(amending)

PSC(MV78 33)1706

B7.2/P

....

8. DOCUMENTATION

.....

8.2 Messages

.....

RQM Request Information Message (AHM 783) 

BIM Baggage Information Messages (Recommended Practice 1745)

Filing Period: Effective Date:

1 March - 1 June 2012

13 April 2012

RECOMMENDED PRACTICE 1706c

COMMON USE SELF SERVICE (CUSS)

(amending)

PSC(27 33)1706c

P6.3.7

Secretary note: the following text completely replaces the current text of RP 1706c

RECOMMENDED that, when Members plan to operate shared Self Service Devices in 

a Common environment, such as an airport, for the purposes of individual airline 

processes, the specifications and standards as described in this Recommended 

Practice are applied.

1. INTRODUCTION/SCOPE

Common Use Self Service (CUSS) describes the specifications and standards for 

multiple airlines sharing one physical self-service Kiosk. Member airlines will develop 

a Common Use Self-Service Platform to include, but not be limited to, check-in 

functionality. Future developments may include other functions, both business and 

technical.

2. PURPOSE

The basic idea of the CUSS concept is to enable airlines to provide passenger 

services at a shared Kiosk. 

The major benefits of CUSS are:

o customer interaction with airline application at a single point of contact

o security of access

o optimum use of airline facilities with no need to dedicate special areas for 

different airlines

o shared running costs

o permits delivery of a proprietary check-in product, thus the airlines are not 

required to use systems provided by airport authorities or handling agents 

which might not be compatible with their host computer systems

o airports only have to provide space for the common Kiosk thus reducing the 

amount of space an airport needs to set aside for airline Kiosks.

3. DEFINITIONS

For the purposes of this Recommended Practice, the following definitions will apply;
3.1 Application Provider

An entity that is responsible for the provision and management of their applications 

accessible from a CUSS Kiosk, e.g. an airline.

3.2 Application Supplier

An entity that writes the application software for the Application Provider.

3.3 Architecture

This is the structure that will be employed to deliver CUSS, and to ensure 

consistency of operation (refer to the Technical Specifications published separately 

from this Recommend Practice in the “CUSS Manual”).

3.4 Common Software 

This software provides an interface between Hardware devices and the Kiosk/airline 

applications which use them. This will be referred to as middleware. It includes 

several layers, the top layer of which will be the Standard Interface Layer. 

3.4.1 CUSS Passenger Documents

The Kiosks may contain (as appropriate): 

Blank ATB Card Type 4 stock with a magnetic stripe and without a binding stub 

(Refer to IATA 722c and 722e/ A4A 20.51 and 20.201/)

General Purpose Printer (GPP) stock (Refer to /IATA 1706d A4A RP 30.102)

Blank baggage tag stock (Refer to IATA Resolution 740/A4A 30.35)

3.5 CUSS Platform 

This defined environment supports applications for one or more airlines and 

conforms to the standards as described in this Recommended Practice. 

3.6 CUSS Application (See also, "Kiosk Application")

A single certified business application that will run on multiple CUSS certified 

Platforms
3.7 Kiosk Application (See also, "CUSS Application")

The Kiosk Application is the essential part of the Kiosk system. It provides the 

functionality the Kiosk offers to the customers. It depends on the Kiosk Application 

whether a Kiosk can be used for check-in, ticketing, as a ticket vending machine or 

virtually anything else. There is no limitation about what and how many Kiosk 

Applications can be offered on a Kiosk system. 

3.8 Platform Provider

This is the entity that is responsible for ongoing provision and management of the 

Platform.

3.9 Platform Supplier(s)

This is the entity who provides any component of the Platform

3.10 Relationship Among Entities Involved in the CUSS System

3.11 Selection Interface Screen

This is the initial screen a customer will interact with prior to selecting an airline 

application. This will be provided by the Platform Provider.

3.12 Service Provider(s)

This is the entity that is responsible for maintaining the operational service 

performance of the Platform.

Application Provider

Application Provider

Application Provider

Platform Provider

Application Supplier

Platform Supplier

Service Provider

Service Level 

Agreement
3.13 Kiosk Enclosure

The physical assembly and ergonomics of the kiosk including devices and 

components, screens, millwork and/or encasement, mounting, service doors, and 

physical security and access controls.

4. CUSS PRODUCT STRATEGY

The CUSS product strategy is to deliver a common self service Platform to support 

individual airline processes at a shared Kiosk, e.g. check-in.

The key to the product strategy is an Open Architecture. This means that it should be 

possible to use any Hardware or software that conforms to CUSS standards included 

in the Technical Specifications published in the “CUSS Manual”.

This open strategy enables airlines to maintain their individual identity in terms of 

product offering.

The functionality described is not exclusive. Any future products and/or applications 

may be introduced as business needs change and will be subject to review and 

approval by the Passenger Experience Management Group (see section 6 titled 

“Passenger Experience Management Group”).

Initially this strategy is focused for implementation at airports but could be carried 

forward to other environments, e.g. bus terminals and railway stations.

The development of the CUSS product will initially be done with the cooperation of 

Member airlines, airport authorities and Software/Hardware manufacturers.

5. KIOSK PLATFORM/CUSS PRODUCT FUNCTIONALITY

The Kiosk Platform comprises, at minimum, the Hardware specified in Section 11.1 

titled “Minimum Kiosk Components”.

The CUSS product functionality shall be bilaterally agreed upon between the 

individual airline(s) and the Platform Provider and must adhere to the Certification 

process outlined in the “Certification Document”. This is published in the “CUSS 

Manual” separately from this Recommended Practice.

The Kiosk is envisaged to support a comprehensive range of airline processes and 

services. 

The support of a specific process and services for any airline is dependent on the 

software provided by the airline Application Provider.

Initial focus of the product will be on passenger check-in.

Devices within a Kiosk shall only be used by applications initiated and operated 

within the Kiosk or diagnostic software.

All physical components shall be equally accessible to all participating airlines 

according to bilateral agreements between airlines and Platform Providers. 
5.1 Data Security

This Recommend Practice and the CUSS Technical Specification recognize and 

acknowledge that the CUSS standard should facilitate, and not prevent, the PCI 

Data Security Standard compliance of the Kiosk provider as well as of the 

Application Providers. Just a few of the ways that can prevent compliance follow.

1. Storage of magnetic stripe data and/or equivalent data on the chip in the 

customer's network after authorization;

2. Applications that require customers to disable other features required by the 

PCI Data Security Standard, like anti-virus software or firewalls, in order to get 

the payment application to work properly; and

3. Vendors’ use of unsecured methods to connect to the application to provide 

support to the customer.

Secure kiosk enclosures and components, when implemented in a PCI DSScompliant environment, will minimize the potential for security breaches leading to 

compromises of full magnetic stripe data, card verification codes and values (CAV2, 

CID, CVC2, CVV2), PINs and PIN blocks, and the damaging fraud resulting from 

these breaches.

See the References paragraph for more information on PCI-DSS.

5.2 Form of Identification (FOID)

An addendum to the CUSS Technical Standard called “Separation of Card Reader 

Payment and Form of Identification Data” was published June 2011. 

This addendum modifies the CUSS specification to restrict how CUSS applications 

read payment card data from the kiosk. Card issuer operational regulations state:

A Merchant must not request or use a Primary Account Number (PAN) 

for any purpose other than as payment for goods and services.

The CUSS specification is amended to provide special access to payment card data. 

CUSS applications retain full access to the card data in cases where it is needed for 

payment processing. For all card transactions that are not for payment, the content 

of the payment card is truncated (obscured) so that it retains essential information 

such as the name, but no longer has a Primary Account Number and is hence not 

considered a payment card.

The adoption of this addendum is critical for card issuers, as a condition for 

continuing to accept payments at airline self-service kiosks. Implementing and 

deploying the changes specified in this Addendum are required for adherence to this 

Recommended Practice. 
6. PASSENGER EXPERIENCE MANAGEMENT GROUP

A Passenger Experience Management Group (refer to Resolution 706 [ATA 30.200] 

comprised of airlines will be responsible for managing the certification process and 

amending CUSS standards as published separately from this Recommended 

Practice, e.g. Technical Specifications published in the CUSS Manual. 

7. CUSS PRODUCT OPERATION

The product may operate in the following way:

Typical Check-in Flow

• Selection from Interface Checks airline links

screen Checks Hardware

• Passenger selects airline Airline application started via

touch screen and Kiosk Application

• Airline application launched Check passenger(s) in to flight (via airline

host) other airline services

• Airline application prints Travel documentation issued

• Airline application cleans up Calls back Selection Interface 

Screen

• Selection Interface Screen Checks tidy up

Checks Hardware OK 

For details refer to the Technical Specifications in the “CUSS Manual”.

7.1 Statistical Information

General rules:

• No data to be maintained on the Kiosk.

• No Proprietary Data to be retained by the Platform/Service Provider

• No Application Provider’s Proprietary Data to be accessed or made available to 

any other party

• The following types of statistical data will need to be provided:

- sufficient data to support and control a billing process for both Platform and 

Application Providers.

- general data available for all airlines using the Kiosk (deliverance, uptime, 

etc.)

- all data required by a Service Provider to complete their function
8. OWNERSHIP

The interface descriptions (as described in Technical Specifications) are owned by 

IATA and A4A and are maintained by the Passenger Experience Management 

Group (see Section titled “Passenger Experience Management Group”).

9. SERVICE LEVEL AGREEMENTS (SLAs) AND RESPONSIBILITIES

This section addresses various aspects of the Service Level Agreement (SLA) 

document where the Service Levels to be provided by the Platform Provider of 

CUSS and the Service Levels provided by the Application Provider are mutually 

agreed. The SLA will also include change management procedures. As a guideline, 

a sample SLA template is shown in the “CUSS Manual”. 

9.1 Platform Provider’s Responsibility

The Platform Provider will, as defined in the SLA, ensure that:

• the CUSS Kiosk is operational and serviceable during the specified operational 

hours

• the CUSS Platform is functioning and certified according to CUSS standards

• software levels and version control of the Platform are maintained at that site

• statistical and management information is available

• they notify the Application Provider of faults that cannot be resolved

• they have the ability to turn off an application if it is deemed to be causing other 

applications and/or the CUSS Kiosks to malfunction. If this is the case they will 

endeavor to inform the Application Provider in advance

• Kiosk locations are locally and mutually agreed

The Platform Provider will also demonstrate that its Kiosk Enclosure and Kiosk 

Platform comply with any applicable regulations or standards that apply to the site 

where the kiosk is deployed, including relevant Access, Data Privacy, and Data 

Security standards.

In addition, the Provider must deploy a platform that complies with and implements 

the CUSS FOID Addendum as described and by the date set in paragraph 5.2.

9.2 Application Provider’s Responsibility

The Application Provider is responsible for the application code, which must follow 

and pass the Certification process. 

If the Application Provider decides to use a dedicated Application Server, either at 

the CUSS site or a location that is under the control of the Application Provider, then 

that Application Provider is responsible for the maintenance and the upkeep of the 

Server. 
The Application Provider is responsible for any communication lines to and from the 

Application Provider’s mainframe or Server location.

The Application Provider must provide the correct protocol and interfaces to allow 

connection at the CUSS site as mutually and bilaterally agreed between the Platform 

Provider and the Application Provider.

The Application Provider shall ensure that when a Payment Card is read for any 

purpose other than payment, such as Form of Identification (FOID), the application 

shall include only the first 6 and the last 4 digits of the credit card number. All 

remaining digits shall be replaced with an X. E.g. 123456XXXXXX7890." 

This behavior follows the FOID Addendum to the CUSS Specification described in 

Paragraph 5.2 and allows compliance with Card Scheme Operating Regulations and 

IATA Resolutions 722-f-g-h & 725-f-g-h.

The Application Provider will also demonstrate that its Kiosk Application complies 

with any applicable regulations or standards that apply to the site where the kiosk is 

deployed, including relevant Access, Data Privacy, and Data Security standards.

9.3 Service Levels

Minimum Service Levels that the Platform Provider should provide will be locally and 

mutually agreed. All airlines involved at each site must be able to ensure that agreed 

standards do not compromise levels of customer service they have already built up 

or to which they aspire. 

9.4 Management Information and Availability Figures

The Platform Provider should be able to supply all Application Providers the 

Availability figures and access to the management tool used for real time status of 

the CUSS installation. 

9.4 Additional Responsibilities

The Platform Provider and Application may have additional local or site 

responsibilities not listed here. 

10. SIGNAGE

The signage for Kiosks to be promoted at all sites will include the words “Self 

Service”. 
11. KIOSK SPECIFICATIONS

11.1 Kiosk Components.

The following is the minimum specification for a CUSS Kiosk:

A computer

A card reader

Touch screen 

Facilities to support a keyboard and pointing device

Printer, which may be one or more of the following if the airlines at the 

location require them:

ATB reader/ATB printer with an Escrow and the latest AEA PECTAB 

and PECTAB extensions (refer to the Technical Specifications in the 

“CUSS Manual” published separately from this Recommend Practice).

General Purpose Printer with bar code printing capability.

Bag tag printer with specified fonts (refer to the Technical Specifications 

published separately from this Recommend Practice in the “CUSS Manual”).

Note: Further details including optional components to be found in the Technical 

Specifications published in the “CUSS Manual”.

11.2 Data Privacy

Recommended Practice 1774 (Protection of Privacy and Transborder Data Flows of 

Personal Data used in International Air Transport of Passengers and Cargo) is 

incorporated by reference herein.

Additional local or site Data Privacy regulations may also apply. 

11.3 Kiosk Ergonomics

Screen design

The Selection Interface Screen will be designed with an overall common navigation, 

look and feel. This interactive design utilizes suitable fonts and is graphically intuitive 

(refer to the Technical Specifications published in the “CUSS Manual”). 

Hardware Design and Kiosk Enclosure Considerations

The Kiosk must be designed in compliance with local laws. The devices should be 

easily visible and as close to the screen as possible. 

The design and placement of the Kiosk Enclosure and its integrated devices and 

components should comply with any applicable Data Privacy, Data Security, 

Accessibility, and other standards and regulations (see Paragraph 5.) 

11.4 Data Security

Additional local or site Data Security regulations may also apply. 
12. CERTIFICATION

The Platforms and applications must be certified in accordance with the procedures 

in the Certification Document published in the “CUSS Manual”.

13. CUSS MANUAL

IATA shall produce, update, and make available the CUSS Manual in electronic 

format which shall set forth, among other things, CUSS standards and Technical 

Specifications. As a condition to certification, Application and Platform Providers, 

shall be required to maintain a current subscription to the CUSS Manual. To enable 

it to defray the costs incurred in developing and maintaining the CUSS Manual, IATA 

shall establish an annual subscription fee for the CUSS Manual. Access to the CUSS 

Manual, and the fee to be charged, will be non-discriminatory, i.e., all interested 

parties, whether or not members of IATA, will be afforded access to the CUSS 

Manual on the same terms, and will pay an equal fee for such access.

14. GLOSSARY OF TERMS

AEA PECTAB – Parametric table as specified by the latest edition of the Association 

of European Airline (AEA) joint technical specifications. A parametric table defines 

the print and magnetic strip locations for the IATA ATB documents (or other 

documents in ATB format).

APPLICATION PROVIDER - See paragraph 3 “Definitions”

APPLICATION SUPPLIER - See paragraph 3 “Definitions”

ARCHITECTURE - See paragraph 3 “Definitions”

AVAILABILITY – The percentage of time, during kiosk hours of operation, where a 

kiosk is able to fulfill its functionality, and is available for operational use. There are 

some outages which affect availability of the CUSS kiosk that the Service Provider 

will not have control over. These outages will not be classed as an operational 

outage which will be penalized against the Service Provider

COMMON ENVIRONMENT e.g. an airport as defined in IATA RP 1797. 

CUSS APPLICATION - See paragraph 3 “Definitions”

PASSENGER EXPERIENCE MANAGEMENT GROUP - A Passenger Experience 

Management Group (PEMG) comprised of airlines will be responsible for managing 

the certification process and amending CUSS standards.
GPP – General Purpose Printer

KIOSK, KIOSK ENCLOSURE – The common term used to describe the repository 

of the hardware. See paragraph 3 “Definitions”

OPEN ARCHITECTURE - Means that it is possible to use any Hardware or software 

that conforms to CUSS standards.

PLATFORM - Comprises common Hardware, software and networking infrastructure 

required to run the CUSS Applications.

PLATFORM PROVIDER - See paragraph 3 “Definitions”

PLATFORM SUPPLIER (S) - See paragraph 3 “Definitions”

PROPRIETARY DATA – Data that originates from an Application Provider.

SERVICE PROVIDER (S) - See paragraph 3 “Definitions”

SELECTION INTERFACE SCREEN - See paragraph 3 “Definitions”

SERVICE LEVEL AGREEMENT (SLA) – A document where the service levels to 

be provided by the Platform Provider of CUSS and the service levels provided by the 

Application Provider are mutually agreed. See paragraph 9 "SLAs"

SOFTWARE - Code used to deliver specific functionality.

PCI-DSS – Payment Card Industry Data Security Standard
- REFERENCES

IATA Passenger Services Conference and A4A Passenger Council Resolutions

IATA A4A

------ 20.12 Automated Ticket/Boarding Pass – Version 1 (ATB1)

------ 20.13 Automated Ticket/Boarding Pass Version 1 (ATB1) Agents 

and Corp Travel

722c 20.51 Automated Ticket/Boarding Pass – Version 2 (ATB2)

722d 20.52 Off Premise Automated Ticket/Boarding Pass – Version 2 

(OPATB2) ----A4A Agents and Corp. Travel

722f 20.60 Electronic Ticket/Electronic Miscellaneous Documents –

Airline

722g 20.61 Electronic Ticket/Electronic Miscellaneous Documents –

Neutral

724 20.03 Passenger Ticket – Notice and Conditions of Contract

728 110.16 Code Designators for Passenger Ticket and Baggage 

Check

740 30.35 Form of Interline Baggage Tag

791 20.204 Specifications for Airline Industry Integrated Circuit Card 

(ICC)

Recommended Practices

IATA A4A

1008 100.15 Glossary of Commonly Used Air Passenger Terms

1706 ------ Functional Specification for Standard Departure Control 

System

1706a

1706c

30.200

30.100

Functional Specification for Passenger Self Service 

Systems

Common Use Self-Service (CUSS)

1706d

1706e

1720

30.101

30.102

-----

Non-ATB Document Specifications for Common Use SelfService Kiosks

Paper Specifications – Documents to be Printed by a 

General Purpose Printer (GPP) In A Common Use SelfService (CUSS) Kiosk

Seat Assignment Parameters

1724 20.03 General Conditions of Carriage (Passenger and Baggage)

1774 ----- Protection of Privacy and Transborder Data Flows of 

Personal Data Used in International Air Transport of 

Passengers and Cargo

1778 ----- Corporate Client Identification Service

1784 A4A 

Electronic 

Marketplace 

Committee 

RP

Electronic Reservation Services Providers (ERSPs)

1797 ------ Common Use Terminal Equipment (CUTE) systems
IATA Passenger Agency Conference /Airlines Reporting Corporation (ARC)

Resolutions/Governing Body

IATA

800z ----- Electronic Ticketing

898a Electronic Reservation Services Providers

Other

Electronic Reservation Services Providers Implementation guide

Electronic Ticketing Implementation Guide

Integrated Circuit Card Implementation Guide

PCI-DSS at http://www.pcisecuritystandards.org

Filing Period: Effective Date:

1 March - 1 June 2012

13 April 2012

RECOMMENDED PRACTICE 1707a

DATA FIELD DICTIONARY FOR DCS PASSENGER MESSAGES

(amending)

PSC(30 33)1707a

B7.1/P

RECOMMENDED that:

....

Data Field Name Example Format/Reference

...

arrival time 1100 see time

(can be followed by date variation)

. . .

date of birth 26MAY46 see date/full

date variation (negative) /M1 /Mn

date variation (positive) /1 /n

departure time 1400 see time

...

Filing Period: Effective Date:

1 March - 1 June 2012

13 April 2012

RECOMMENDED PRACTICE 1707b

DATA ELEMENT DICTIONARY FOR DCS PASSENGER MESSAGES

PSC(32 33)1707b

B7.8/P

1.3 STANDARD ELEMENTS USED IN DCS PASSENGER MESSAGES

Element

ID

Ref in

1707b

Element Title 1708

PNL

1708

ADL

1719

PFS

1719b

PRL

...

...

.T/ 3.30 (not in use)

reserved for E.T.

.U/ 3.31 (not in use) Unique 

passenger per 

segment identifier

O O O O

.V/ 3.32 (not in use)

...

...

B7.1/P

3.13 .I INBOUND CONNECTION ELEMENT 

.....

3.13.2 flight information:

.....

if date variation is used; otherwise optional) -1 /M1 date variation

date variation (conditional: mandatory

if arrival date of Inbound connection is

different from the departure date of the

inbound connection. Not allowed when

the date is the same. May be a 

value of minus 1, plus 1 or plus 2 -1, +1, or +2.)-1 /M1 date variation

reservations status HK status

Example:

.I/SR559F07MUC

.I/BA226Y09LHR1100

.I/NZ040X27AKL0651-1HK/M1HK
3.21 .O/ ONWARD CONNECTION(S) ELEMENT 

....

Construction Example Data Field Name

3.21.2 flight information:

 flight LH001 flight

.....

 departure time (optional) 1400 time

 arrival time (conditional: 0630 time

 mandatory if date variation exists;

 otherwise optional)

 date variation (conditional: 

 mandatory if arrival date 

 is different from departure date 

 of the onward connection. Not allowed when 

 the date is the same. May have a value

 of minus 1, plus 1 or plus 2.) /M1 date variation

 reservations status (optional) KL status

Examples:

.O/BA012C26LHR1500HK

.O2/NW001C27JFK1400HK

.O3/AA123Y27ATL 

.O/CO0964Y15NRTGUM20500125/1HK

.O2/CO0002Y16GUMHNL06301755/M1HK

.O/NZ0038Y29LHRAKL21050900/2HK

....

3.31 .U/ (NOT IN USE) PASSENGER SYSTEM IDENTIFIER PER SEGMENT 

(bilateral agreement)

This element conveys a unique passenger system identifier for each flight segment. 

The identifier is assigned by the sending system for purposes of data collection and 

statistical analysis.

It is composed of the following information:

 Unique passenger system identifier – a unique identifier is assigned to a 

passenger for each flight segment.

 Infant indicator – to indicate an infant (not occupying a seat); passenger ID on 

this element is for the adult accompanying this infant.

Once established, this unique reference will be the key to identify the passenger
Construction Example Data Field Name

3.31.1 element ID .U/ element ID

3.31.2 unique reference A98745632145678Z m[..25]

3.31.3 oblique / information separator

3.31.4 infant indicator I I

3.31.5 passenger identification -1HOLTON/TOMMR passenger ID

Examples:

.U/A456789A56478

.U/B12345698Z765889Q/I-1MONCEL/MARC

B7.4/P

....

3.40.1 API DOCS Element

This element lists Passenger primary travel documents. Where the components of a 

DOCS element are not provided, an oblique (/) is inserted to indicate an element is 

missing. This is not required when no further components are provided. The 

Passenger Identification Element may follow the final element entered.

The elements Travel Document Surname, Travel Document First Given Name and 

Travel Document Second Given Name must match the surname, first given name 

and second given name (if applicable) as shown in the official travel document. If 

the name is from the Machine Readable Zone (MRZ) of an official document, e.g. 

passport, the chevron character (<) in the MRZ should be interpreted as a space 

character. A double chevron (<<) should be interpreted as a change of field, e.g. 

from surname to given name. Spaces in the name fields of the SSR DOCS should 

not be removed and should be transmitted in messages to business partners and 

governments.

B7.7/P

....

Section 4 — Implementation Guidelines

This section is a compilation of guidelines to assist in the understanding of the 

purpose and use of DCS messages. The remarks in this section are contributed by 

individual IATA Members and by the DCSMWG (the IATA DCS Message Working 

Group). The items appear in no specific order, and the position of an item in this 

section does not reflect its importance or priority. Keywords can be referenced in RP 

1707a and RP 1707b.
4.1 A passenger name on any DCS message shall appear in the same format as it 

first appeared on the PNL/ADL. Names cannot be broken over one line of 64 

characters. Therefore, if a complete Name Element cannot fit on one line of a DCS 

message, it can be truncated according to individual message RP rules. Names 

cannot be re-formatted (such as using only a first initial instead of a full first name).

4.2 A Name Element and all of its related elements are not to be broken over Parts 

in any DCS message.

4.3 A Party/Group Identification (See RP 1707, 2.9.2) is assigned uniquely for one 

DCS message, for one use. The Identification for a “set” of names can be different 

on each subsequent list (such as first D2, then M2, then A2). The Identification's 

purpose is to keep names associated for their appearance on just one message. 

Furthermore, if a “set of names” appears more than once on one message, each 

appearance of the “set of names” is to have a unique Party/Group Identification. 

Example: when a “set of names” appears on one ADL in the section for Deletes and 

then again for Adds, such as:

ADL

....

DEL

1JONES/ARTHUR-D3 .L/382U22

1MILLER/JON-D3

1MILLER/JON-D3

1SMITH/ANN-D3

.....

ADD

1MILLER/JON-E2 .L/382U22

1SMITH/ANN-E2

....

This example shows clearly that a PNR of three (D3) are associated for the Delete, 

and that a PNR of two (E2) remains for the Add.

4.4 When adding a Group PNR to a PNL or ADL, the size of the group and the total 

number of named individual group members must be equal. The number used in the 

party/group identifier must be equal on the Group Name Element and each of the 

Name Element(s) for the individual group members. For example, on the PNL/ADL, 

a Group PNR of 50 must have a total of 50 individual names (and NONAMES), and 

the party/group identifier must be 50 for the Group Name Element and each of the 

individual Name Elements.

4.1 The discount codes of ID, DG. RG designate a passenger who is travelling on a 

free or deeply discounted ticket. The codes are amended with a number 1 or 2, such 

ID1 or RG2, with “1” meaning that the passenger is entitled to a firm booking and “2” 

meaning that the passenger is travelling on a space-available (SA) basis. Eight 

industry discount codes are identified in the IATA Passenger Services Conference 

(PSC) Manual in RP 1788 and are defined in the IATA Passenger Agency 

Resolution Manual. Only three have been adopted for use on the PNL/ADL:

ID — Industry Discount passenger, such as an airline employee;

DG — Discounted Government passenger, such as an official or military;

RG — Free or reduced fare transportation for IATA Passenger Sales Agents.
4.2 The acronym “PAD” means “Passenger Available for Disembarkation”. This 

refers to a passenger who is a candidate to be off-loaded if another passenger of a 

higher category or priority appears for boarding. Examples of PAD passengers is an 

ID2, DG2, or RG2 — reduced fare passengers who are travelling on a space 

available basis — such as a company employee on leisure travel. On a near-full 

flight, PAD passengers might not be accepted to board the aircraft until all revenue 

passengers are boarded, and when boarded, also can be asked to de-board if a late 

revenue passenger appears for boarding.

4.3 The construction rules for DCS messages say to include compartments or fare 

classes (RBD) in “descending order”. This means in “descending commercial value”, 

best-to-worst, such as first class, then business class, then economy class. The 

concept of “descending order” does NOT relate to alphabetical order or the physical 

seating position on the aircraft.

4.4 The elements included behind a passenger's name on any DCS message have 

no pre-set order for inclusion, unless specified in the RP for a specific DCS 

message. However, logic dictates a natural order in some cases, such as a .O/ 

followed by a .O2/, then a .O3/, etc., and a .R/ followed by a .RN/.

4.5 The DCS Recommended Practices use “local date”, meaning the calendar date 

at the station in question for a particular action, or when a flight is scheduled to land 

or depart at that station. The local date for a flight at any given station is independent 

of the date that the flight departed from any upline station or will land at any downline 

station, or the date at the computer site of the DCS.

4.6 A code share flight operation is a commercial agreement between partners that 

designates one carrier as the airline that actually provides the aircraft for the flight 

and is known as the “operating carrier” (OC) and sells seats under their own carrier 

code, and one or more other carriers who have an agreement to sell seats on the 

operating carrier under their own carrier code(s) and are known as the “marketing 

carrier(s)” (MC). In DCS, each passenger is checked-in for their marketing carrier 

flight number, but are added to the passenger load of the operating carrier. When 

each marketing carrier requires a DCS message with just the passengers booked on 

their marketing flight, this is called a “targeted message”. When the operating carrier 

requires all passengers booked on the operating flight, this is called a “complete 

message”.

4.7 A name element and all of its related elements are not to be broken over Parts in 

any DCS message.

4.8 The PNL includes passengers who have a status/advice code for the PNL flight 

of only confirmed, waitlisted,

or space available, according to the codes listed in the IATA AIRIMP, Sections 7 and 

8. A passenger on the PNL is assumed by DCS to be confirmed, unless a .WL/, 

.ID2/, .RG2/, or .DG2/ Element appears with the passenger entry. This rule for 

status/advice codes applies also to the .I/, .O/, and .M/ Elements. Cancelled 

passengers can appear in the Delete (DEL) category, if they had been included in a 

previous PNL/ADL as a confirmed, waitlisted or space available passenger.
4.9 DCS messages are constructed on the basis of either compartment or fare 

class/RBD (see RP 1707a), according to bilateral agreement when a Recommended 

Practice’s construction rules allow a choice.

4.10 The IATA Airline Coding Directory lists the Standard Communications Service 

codes (CSC) and the Standard Message Identifier codes (SMI) which can be used 

with type-B messages, including DCS passenger messages. When both codes are 

required on one message, the CSC must appear first, on its own line, followed by the 

SMI on the next line.

Example: Original Message Follow-on Correction Message

.... ....

ETL COR

.... ETL

....

4.11 A passenger name on any DCS message shall appear in the same format as it 

first appeared on the PNL/ADL. Names cannot be broken over one line of 64 

characters. Therefore, if a complete Name Element cannot fit on one line of a DCS 

message, it can be truncated according to individual message RP rules. Names 

cannot be re-formatted (such as using only a first initial instead of a full first name).

4.12 A Party/Group Identification (See RP 1707, 2.9.2) is assigned uniquely for one 

DCS message, for one use. The Identification for a “set” of names can be different 

on each subsequent list (such as first D2, then M2, then A2). The Identification's 

purpose is to keep names associated for their appearance on just one message. 

Furthermore, if a “set of names” appears more than once on one message, each 

appearance of the “set of names” is to have a unique Party/Group Identification. 

Example: when a “set of names” appears on one ADL in the section for Deletes and 

then again for Adds, such as:

ADL

....

DEL

1JONES/ARTHUR-D3 .L/382U22

1MILLER/JON-D3

1SMITH/ANN-D3

.....

ADD

1MILLER/JON-E2 .L/382U22

1SMITH/ANN-E2

....

This example shows clearly that a PNR of three (D3) are associated for the Delete, 

and that a PNR of two (E2) remains for the Add.

4.13 A Name Element and all of its related elements are not to be broken over Parts 

in any DCS message.
4.14 When adding a Group PNR to a PNL or ADL, the size of the group and the total 

number of named individual group members must be equal. The number used in the 

party/group identifier must be equal on the Group Name Element and each of the 

Name Element(s) for the individual group members. For example, on the PNL/ADL, 

a Group PNR of 50 must have a total of 50 individual names (and NONAMES), and 

the party/group identifier must be 50 for the Group Name Element and each of the 

individual Name Elements.

B7.3/P

...

4.15 Whenever possible follow the booking rules for multiple services defined in 

AIRIMP to clearly identify the receiving passenger. During the construction of a 

PNL/ADL reservations systems may encounter PNRs where the intended

recipient of multiple services is not clearly identified. This will happen when a 

PNR has an SSR element with a service count that is not equal to the number of 

names in the PNL/ADL surname element and there is no passenger 

identification on the SSR element. Example: a PNR with 1SMITH and an SSR 

HK2 or a PNR with 2SMITH 1JONES and an SSR HK4

Construct the PNL/ADL entries for such cases with these rules: 

(a) in the case where a PNR has an SSR with no passenger identification and 

the PNR has only one passenger surname element, create a .R/ element with 

the count as it is found in the SSR element.

Example1: a PNR with 1SMITH/A and an SSR SFML HK2 goes on the PNL/ADL 

as: 1SMITH/A .R/SFML HK2

Example2: a PNR with 2JONES/A/B and an SSR SFML HK3 goes on the

PNL/ADL as: 2JONES/A/B .R/SFML HK3

(b) in the case where a PNR has an SSR with no passenger identification and 

the PNR has multiple surname elements and the count of services in the SSR is 

equal to the total number of names, create the .R/ elements with individual 

counts equal to the individual surname counts.

Example: a PNR with 2SMITH/A/B 1WILKES/C and an SSR SFML HK3 goes on 

the PNL/ADL as: 2SMITH/A/B .R/SFML HK2 and 1WILKES/C .R/SFML HK1

(c) in the case where a PNR has an SSR element with no passenger 

identification and the PNR has multiple surname elements and the count of 

services in the SSR is greater than the total count of surnames, create the .R/ 

elements with counts equal to each surname’s count, with all remaining counts 

going to the first surname.

Example: a PNR with 2SMITH/A/B 1WILKES/C and an SSR SFML HK4 goes on 

the PNL/ADL as 2SMITH/A/B .R/SFML HK3 and 1WILKES/C .R/SFML HK1 

Filing Period: Effective Date:

1 March - 1 June 2012

13 April 2012

RECOMMENDED PRACTICE 1708

PASSENGER NAME LIST (PNL) AND ADDITIONS AND DELETIONS LIST (ADL)

(amending)

PSC(32 33)1708

B7.1/P

....

2.10.7 Example ......

....

2BROWN/JOHNMR/PRISCILLAMRS-A3 .I/SR559F07MUC

2SMITH/SAMUALMR/BARBARAMRS .I/BA021C07LHR01200+1HK/1HK

1SORENSON/RONMR .I/BA123Y07LHRCDG1100HK

...

2.11.7 Examples:

2BROWN/JOHNMR/PRISCILLAMRS-A3 .I/SR559F26MUC .O/BA439F27LHR

1SMITH/CAROLINA .O/BA012C26LHRLAX15101820HK

1STEENMEYER/HAROLD .O/LH001Y26HAM

. . .

1STRAND/JANEMISS-A3

1ZIMMERMAN/ANDREWMRS .O/BA012C26CDGLHR1500HK 

.O/AF0276Y26CDGNRT13300910/1HK

. . .

2.11.8.2 Examples of multiple Onward Connection Elements:

1MANNING/MARKMR .O/BA021C07LHR1200HK .O2/PA001J07JFK1400HK 

1WAGGONER/PAULMR .O/CO2345Y06SEA .O2/EF3456Y06NRT 

.O3/GH9990Y07MNL 

.O4/IJ5678Y08XMA 

1ZAHL/MOLLY .O/AF1234Y28CDGAMS14001530HK 

.O2/KL621Y28AMSATL16301950HK 

.O3/DL213Y28ATLMSP23000115/1HK
B7.6/P

....

2.12.6.2 Remarks Element for Frequent Traveler Information

2.12.6.2(a) The Remarks Element for frequent traveler information uses the AIRIMP 

standard codes for frequent traveler, such as FQTV, FQTR, FQTU, and FQTS. 

However FQTU should be used only for upgrade to frequent flyers whereas other 

upgrades should use UPGR.

B7.9/P

.....

2.12.6.10 Remarks Element for Checked-in Information (bilateral agreement)

2.12.6.10(a) This element is conditional, being used for already checked-in 

passengers.

2.12.6.10(b) The Remarks Element for Checked-in Information uses the code CHKD.

2.12.6.10(c) Construction rules

Field Example Data Field Name

(see RP 1707a/b)

element ID .R/ element ID

checked-in code CHKD code

space → information separator

status code and number HK1 status code

space → information separator

sequence number 1234 n[..4]

space → information separator

infant indicator (not occupying seat) I I

passenger ID -1TAYLOR/SIMONMR passenger ID

Note 1: If the infant indicator is not used, the space before the infant indicator is omitted.

Note 2: The appropriate seat .R/ element must be included if a seat has been allocated.

Example 1:

.R/SEAT HK1 21A-1TAYLOR/SIMONMR

.R/CHKD HK1 5678-1TAYLOR/SIMONMR

Example 2:

.R/CHKD HK1 5678-1TAYLOR/SIMONMR

Example 3:

Passenger travelling with infant not occupying a seat.

.R/SEAT HK1 21A-1TAYLOR/SIMONMR

.R/CHKD HK1 9101 I-1TAYLOR/SIMONMR

.R/INFT HK1 29MAR11 TAYLOR/KATIE-1TAYLOR/SIMONMR
B7.6/P

.....

2.12.7 Table of SSR Codes

The following SSR codes from the IATA AIRIMP are used in DCS messages in .R/ 

Remarks Elements. They are shown in this table in alphabetical order by code.

SSR Code See Description

Note

Number

AOXY Airline Supplied Oxygen

.....

UMNR Unaccompanied minor

UPGR Upgrade

B7.7/P

.....

WCLB 2 Wheelchair – Lithium ion battery to be transported 

by a passenger which will require advance 

notification/preparation. Weight and dimensions may be 

specified. Wheelchair and battery must be claimed and 

rechecked at each interline transfer point (by bilateral 

agreement)

B7.8/P

.....

2.25 .U/ PASSENGER SYSTEM IDENTIFIER PER SEGMENT (bilateral

agreement)

2.25.1 This element is optional and is included only when bilaterally agreed.

2.25.2 Only one passenger system identifier per passenger (including infants) may 

be included in a DCS message.

2.25.3 For construction rules, see RP 1707b, Unique passenger system identifier per 

segment element

Examples:

.U/A4567Q8956478

.U/B6549ZD874156564789LC-1MONCEL/MARC

.U/C66398VCD6574584156/I-1VINCENT/GERARD

2.25 2.26 END ELEMENT

2.25.1 2.26.1 This element is mandatory

2.25.2 2.26.2 For construction rules, see RP 1707b, End Element.

2.25.3 2.26.3 The Passenger Name List (PNL) ends with ENDPNL.

2.25.4 2.26.4 The Additions/Deletions List (ADL) ends with ENDADL.
B9

.....

Section 3 – Examples

.....

3.1.2 PNL Message Example (Part 2)

.....

2THOM/JANEDR/DEREKMR.L/DF9323

1VANDALEN/LIAMMR-E2 .R/SVC HK1 AGPQRL/B/9R7/SURFACE BUS/0742468246833C1

3VANDENHEUVEL/LIEFMR/PRITHVIMRS/WILLIEMMISS-F28

.....

3.1.3 PNL MESSAGE SORTED BY FARE CLASS EXAMPLE (Part 1 and Part 2)

1ANDERSON/RICHARDMR .L/K6F3DU .I/NW0038M20BOS0705/1HK

.R/SPML HK1 SERVE EVRY TWO HOURS LOW CALORIE LOW SODIUM HIGH

.RN/ FIBRE-1ANDERSON/RICHARDMR

.R/TKNE HK1 0121174084542/2-1ANDERSON/RICHARD

.R/FQTV NW 577418472-1ANDERSON/RICHARD

1ARDON/ARJANMR .L/7MPUVU .O/LH3502Q21ORD1325HK 

.O2/LH4666Q21AMSNRT1740/1HK

.R/TKNE HK1 0748331382698/1-1ARDON/ARJANMR

ENDPART1

=

NNNN
AMSKMKL

.HDQRMKL 211421

PNL

KL1779/21DEC AMS PART2

-HAM010T

1BIENEMAN/ANJAMRS-D2 .L/4VZPUU .I/KL0652M20IAD0655/1HK

.R/INFT HK1 09MAR07 BIENEMAN/LUKAS A

.R/TKNE HK1 0122106022870/2-1BIENEMAN/ANJAMRS

.R/CKIN PN1 REISSUE ET-INFANT TO PAPER TKT FOR WHOLE JOURNEY

.R/FQTV NW 100300416602

1BIENEMAN/CHRISTOPHERGMR-D2

.R/TKNE HK1 0122106026463/2-1BIENEMAN/CHRISTOPHERGMR

.R/CKIN PN1 REISSUE ET-INFANT TO PAPER TKT FOR WHOLE JOURNEY

.R/FQTV NW 225477512

1GERMANOVICH/KSENIAMISS .L/JVKQED .I/KL1000M21LHR0905HK

.R/TKNE HK1 0742462066629/2-1GERMANOVICH/KSENIAMISS

1MAJOR/BENJAMINMR .L/5TN62U .I/KL0662M20IAH0800/1HK

.R/TKNE HK1 0121086429725/2-1MAJOR/BENJAMINMR

1KRUSE/BJORNMR .L/A3ZNWU .I/NW0038H20BOS0705/1HK

.R/TKNE HK1 0121175220869/2-1KRUSE/BJORNMR

1KRUSE/MICHAELJOHANNMR .L/Z8CNTU .I/NW0038H20BOS0705/1HK

.R/TKNE HK1 0121175222481/2-1KRUSE/MICHAELJOHANNMR

.R/PCTC/JENS KRUSE/XX7812379523

.R/SEAT PN1 N /RS REQUEST NOTED FOR CHECK-IN

1MCDONOUGH/JOHNMR .L/47PVFD .I/KL1072M21MAN0830HK

.R/TKNE HK1 0748374236287/2-1MCDONOUGH/JOHNMR

1VANLEEUWEN/LISETTEMRS .L/QV3DXD .O/KL1778M22AMS0855HK

.R/TKNE HK1 0748399183138/1-1VANLEEUWEN/LISETTEMRS

.R/FQTV KL 1543463185/2

-HAM003V-PAD002

1CHUECA/ENRIQUE .L/JJQNNU .I/KL1664M21BCN0900HK

.R/TKNE HK1 0748379890174/2-1CHUECA/ENRIQUE

.R/NSST PN1 A REQUEST NOTED FOR CHECK-IN

1CULL/PHILIPMR .L/IRF7HU .I/KL1420M21BHX0825HK

.O/KL1776M22AMS0650HK .O2/KL1423M22BHX0950HK

.R/TKNE HK1 0748374281416/2-1CULL/PHILIPMR

1DESWAL/YASHWANTMRS .L/4F27GU .I/KL0872C21DEL0600SA

.ID2/IDZM5R2/2095 C/M

1EICHNERVOGT/EBERHARD-H2 .L/VTZKFU .I/NW0034H20SEA0750/1HK

.R/TKNE HK1 0122110765010/2-1EICHNERVOGT/EBERHARD

1RAMCHARAN/SANTOSHMR .L/3CT8GD .I/KL0872C21DEL0600SA .ID2/F2

-HAM000W

ENDPNL

=

NNNN

Filing Period: Effective Date:

1 March - 1 June 2012

13 April 2012

RECOMMENDED PRACTICE 1715

PASSENGER SERVICE MESSAGE (PSM)

(amending)

PSC(32 33)1715

B7.6/P

....

2.6 SSR/OSI/AUX CODES AND COUNTS ELEMENT

2.6.1 This element is conditional.

.....

2.6.5 Following are the allowable SSR/OSI/AUX codes for the PSM (as taken from 

RP 1708, PNL/ADL):

ASVC Additional Services—Segment-associated (See AIRIMP for format)

.....

UMNR Unaccompanied minors

UPGR Upgrade
B7.1/P

....

Section 3 — Examples

3.1 EXAMPLE OF PSM MESSAGES SENT FOR A FLIGHT ORY-GVA-ATH

3.1.1 PSM from ORY sent to GVA including SSR/OSI/AUX items and SI text

GVAKRAF

.ORYKMAF 272215

PSM

....

MAAS

-ATH 3PAX/6SSR

BLND 000F 002Y

MAAS 000F 002Y

MEDA 000F 001Y

STCR 000F 001Y

F CLASS NIL

Y CLASS 3PAX/6SSR

1BROWNE/TEDMR 14D

MAAS TWO BROKEN LEGS. NURSE NELSON. PLEASE TRY TO CLEAR 

AMBULANCE TO MEET AIRCRAFT AIRSIDE

MEDA

STCR

1GREEN/MARILYNMRS 28D

SQ1234W28ATHNRT23251800/1HK

BLND

1GREEN/ROBERTMR 28C

BLND SEEING EYE DOG NAMED CHARLIE

MAAS

SI

ATTN HANDLING/PAX COMPLAINTS TO BE EXPECTED AT ARRIVAL DUE 

DISEMBARKING AIRCRAFT TWICE AFTER BOARDING BECAUSE OF TEC 

PROBLEMS/ SEND STAFF TO GATE TO MEET PAX

ENDPSM

=

NNNN

Filing Period: Effective Date:

1 March - 1 June 2012

13 April 2012
RECOMMENDED PRACTICE 1719

PASSENGER FINAL SALES MESSAGE (PFS)

(amending)

PSC(30 33)1719 

B7.8/P

....

1.4 COMPONENTS

...

Security Information Continuation Element .SN/MORE INFORMATION

Unique passenger system identifier per segment element .U/B654789QS45R12

End element ENDPART11

....

2.19 .U PASSENGER SYSTEM IDENTIFIER PER SEGMENT (bilateral 

agreement)

2.19.1 This element is optional and is included only when bilaterally agreed.

2.19.2 Only one passenger system identifier per passenger (including infants) may 

be included in a DCS message.

2.19.3 For construction rules, see RP 1707b, passenger system identifier per 

segment element

Examples:

.U/A4567Q8956478

.U/B6549ZD874156564789LC-1MONCEL/MARC

.U/C66398VCD6574584156/I-1VINCENT/GERARD

Secretary Note: please renumber accordingly next elements

Filing Period: Effective Date:

1 March - 1 June 2012

13 April 2012

RECOMMENDED PRACTICE 1719b

PASSENGER RECONCILE LIST (PRL)

(amending)

PSC(30 33)1719b

B7.8/P

....

1.4 COMPONENTS

...

Security Information Continuation Element .SN/MORE INFORMATION

Unique passenger system identifier per segment element .U/B654789QS45R12

End element ENDPART11

.....

2.20 .U PASSENGER SYSTEM IDENTIFIER PER SEGMENT (bilateral 

agreement)

2.20.1 This element is optional and is included only when bilaterally agreed.

2.20.2 Only one passenger system identifier per passenger (including infants) may 

be included in a DCS message.

2.20.3 For construction rules, see RP 1707b, passenger system identifier per 

segment element

Examples:

.U/A4567Q8956478

.U/B6549ZD874156564789LC-1MONCEL/MARC

.U/C66398VCD6574584156/I-1VINCENT/GERARD

Secretary Note: please renumber accordingly next elements
B7.1/P

...

Section 3 — Examples

3.1 EXAMPLE OF A PRL; PART ONE OF A MULTI-PART PRL

QK ATLLSNW HDQRMNW MKCZKNW

.CDGKMAF NW/231429 GAT

PRL

....

1TOCHER/LMR

.L/2UILIZ

.I/AF5553C23ABZCDG22350515/1HK

.R/DOCS HK1/P/GBR/093083698/GBR/09APR58/M/05JAN15/TOCHER/GORDON

.R/DOCA HK1/R/GBR

.R/DOCA HK1/D//HOTEL DOLCE/NORWALK/CONNECTICUT

.R/FQTV AF8574212845/P

.R/SEAT HK1 04A

-DTW265Y

1BOOT/RICHARDJ

.L/NQUF8O

.W/K/1/20

.N/AF214975/1/SFONRT

.O/NW347Y3024DTWSFO15551810

.O2/NW015Y24SFONRT19202210/1HK

.R/DOCS 

HK1/P/GBR/706013638/GBR/12APR74/M/13APR16/BOOT/RICHARDJOHN

.R/DOCO HK1//V/011905166

.R/DOCA HK1/R/USA

.R/DOCA HK1/D/USA/471 38TH STREET AVE APT C/SANTA CRUZ/CALIFORNIA

.R/FQTV NW100203546936 .R/TKNE HK1 0122134872230/1

.R/SEAT HK1 18C

Filing Period: Effective Date:

1 March - 1 June 2012

13 April 2012
P5.1

RECOMMENDED PRACTICE 1720a

STANDARD THIRTEEN-DIGIT NUMBERING SYSTEM FOR TRAFFIC 

DOCUMENTS

(amending)

PSC(32 33)1720a

....

Stock Provider 

Party

Type of Form

No. of 

Coupons

IATA 

Resolution / 

Recommended 

Practice

ATA A4A

Resolution

Airline 

Code

1 2 3

Form Code

4 5 6

Serial Number

7 8 9 10 11 

12 13

Number 

of 

Digits in

Serial 

Number

Method of

Check Digit 

Calculation

(see below)

...

Agency (BSP) 1,2Multiple 

Purpose 

Document

Off-Premise 

Electronic 

Miscellaneous 

Document 

(OPEMD)

2 Coupon

_

726b

725g

190 7 2

3

Agency (BSP 

1,2

Virtual Multiple 

Purpose 

Document 

Off-Premise 

Electronic 

Miscellaneous 

Document 

(OPEMD)

CouponbyCoupon 

(Paperless

)

_

725g 261 7 2

3

Agency (BSP 

1,2

Virtual Multiple 

Purpose 

Document 

Off-Premise 

Electronic 

Miscellaneous 

Document 

(OPEMD)

CouponbyCoupon 

(Paperless

)

_

725g 271 7 2

3

Reserved for 

future industry 

allocation

Agency 

(BSP)1, 2

Not assigned

Off-Premise 

Electronic 

Ticket (OPET)

722g 302 7 Not 

assigned

3

Reserved for 

future industry 

allocation

Agency 

(BSP)1, 2

Not assigned

ATB 

Miscellaneous 

Charges Order

725d 304 7 Not 

assigned

3

Agency (BSP 1,2

Agency (US 

ASP) 1, 2

Multiple 

Purpose 

Document

Electronic 

Miscellaneous 

Document

1 Coupon

_

726e

-

20.64 306 7 1

3

Agency (BSP 

1,2

Agency (US 

ASP) 1, 2

Multiple 

Purpose 

Document

Electronic 

Miscellaneous 

Document

2 Coupon

_

726b

-

20.64 308 7 1

3
P5.2

Stock 

Provider 

Party

Type of Form No. of 

Coupons

IATA

Resolution/

Recommended Practice

ATA A4A

Resolution

Airline

Code

1 2 3

Form

Code

4 5 6

Serial Number

7 8 9 10 11 12 13

Number of

Digits in

Serial umber

Method of Check

Digit Calculation

(See below)

Agency 

(CCS-TCH)7

Various Tickets Various - - - - - 61 - - - - - - - 8 Various

Agency 

(CCS-TCH)7

Off-Premise Electronic Ticket 

(OPET) 

– 722g - - - - 610 - - - - - - - 7 3

Agency 

(CCS-TCH)2, 7

Passenger Ticket 2 Coupon 721 - - - - 611 - - - - - - - 7 1

Agency 

(CCS-TCH)7

Off-Premise Electronic Ticket 

(OPET)

– 722g - - - - 612 - - - - - - - 7 3

Agency 

(CCS-TCH) 1, 2, 7

Off-Premise Transitional Automated 

Ticket (OPTAT) 

4 Coupon 722a - - - - 613 - - - - - - - 7 2

Agency 

(CCS-TCH)7

Off-Premise Electronic Ticket 

(OPET)

– 722g - - - - 614 - - - - - - - 7 3

Agency 

(CCS-TCH)7

Off-Premise Electronic 

Miscellaneous Document (OPEMD)

– 725g - - - - 615 - - - - - - - 7 3

Agency 

(CCS-TCH)7

Off-Premise Electronic 

Miscellaneous Document (OPEMD)

– 725g - - - - 616 - - - - - - - 7 3

Agency 

(CCS-TCH)2, 7

Passenger Ticket 2 Coupon 721 - - - - 617 - - - - - - - 7 1

Agency 

(CCS-TCH)7

Off-Premise Electronic 

Miscellaneous Document (OPEMD)

– 725g - - - - 618 - - - - - - - 7 3

Agency 

(CCS-TCH)2, 7

Miscellaneous Charges Order 1 Coupon 725 - - - - 619 - - - - - - - 7 1 

Method of check digit calculation:

1. METHOD 1 IS FOR PRE-NUMBERED DOCUMENTS and includes the coupon number and 10-digit form code and serial number. Does not include the airline code.

2. METHOD 2 IS FOR COMPUTER NUMBERED TAT AND MPD DOCUMENTS and includes only the 10-digit form code and serial number. Does not include the 

coupon number or the airline code.

3. METHOD 3 IS FOR COUPON-BY-COUPON DOCUMENTS and includes the coupon number, airline code and 10-digit form code and serial number.

____________________________________________________________________________________________________

1 Computer generated ticket serial number. All other Passenger Traffic Documents have a preprinted ticket serial number.

2 Standard neutral ticket. Airline name and code are not preprinted. 

7 CCS-TCH – The Control Council of Settlement - Transport Clearing House
Stock Provider 

Party

Type of Form

No. of 

Coupons

IATA 

Resolution / 

Recommended 

Practice

ATA A4A

Resolution

Airline 

Code

1 2 3

Form Code

4 5 6

Serial Number

7 8 9 10 11 

12 13

Number 

of 

Digits in

Serial 

Number

Method of

Check Digit 

Calculation

(see below)

Reserved for 

future industry 

allocation

Agency 

(BSP)1, 2

Not assigned

Off-Premise 

Electronic 

Ticket (OPET)

722g 550 7 Not 

assigned

3

Agency 

(BSP)2

Airline

Miscellaneous 

Document 

(Domestic Only)

Electronic 

Miscellaneous 

Document

Various

_

725f 20.63 553 7 3

Agency 

(BSP)2

Airline

Miscellaneous 

Document 

(Domestic Only)

Electronic 

Miscellaneous 

Document

Various

_

725f 20.63 555 7 3

Agency 

(BSP)2

Airline

Miscellaneous 

Document 

(Domestic Only)

Electronic 

Miscellaneous 

Document

Various

_

725f 20.63 556 7 3

Agency 

(BSP)2

Airline

Miscellaneous 

Document 

(Domestic Only)

Electronic 

Miscellaneous 

Document

Various

_

725f 20.63 557 7 3

Reserved for 

future industry 

allocation

Agency (BSP)

Not assigned

Off-Premise 

Electronic 

Ticket (OPET)

722g 906 7 Not 

assigned

3

Reserved for 

future industry 

allocation

Agency (BSP)

Not assigned

Off-Premise 

Electronic 

Ticket (OPET)

722g 952 7 Not 

assigned

3

Filing Period: Effective Date:

1 March - 1 June 2012

13 April 2012

RECOMMENDED PRACTICE 1728

RESERVATIONS AND TICKET CODING DIRECTORY

(amending)

PSC(20 33)1728

T2.34/P

WHEREAS, the relationship between the fare basis code, the reservation booking 

designator and the class of service code is complex.

IT IS RECOMMENDED that:

In order to ensure correct interline pricing, reservation and, ticket coding, and revenue 

accounting, Members publish via the industry “Single Source RBD Service” (also known 

as the ATPCO Chart 1 and Chart 2), the reservations booking designator and the class 

of service code they want to be used in their services, in conjunction with a given fare 

and rule applied to a fare component within an itinerary.

The “Single Source RBD Service” will provides daily up to hourly updates for distribution 

to automated booking systems subscribing to ATPCO’s product, and is also available as 

a paper product on a monthly basis. A copy of the booking code charts and an 

explanation of how to read the information contained therein is published separately. A 

guide to instructing information in ATPCO’s Chart 1 and Chart 2 and the data 

application for subscribers to process the data is also published separately. More 

information on tThe “Single Source RBD Service” can be contacted at teletype 

GVARZXBfound at http://www.atpco.net/atpco/products/rbd_dc.shtml. 

Filing Period: Effective Date:

1 March - 1 June 2012

13 April 2012

RECOMMENDED PRACTICE 1739

PASSENGER/BAGGAGE RECONCILIATION PROCEDURES

(amending)

PSC(MV78 33)1739

B8.8/P

RECOMMENDED PRACTICE 1739

Attachment ‘E’

PASSENGER/BAGGAGE RECONCILIATION PROCEDURES

COMMON AUTOMATION METHODS ARE UNDER DEVELOPMENT 

Common automation methods for passenger and baggage security reconciliation are 

described in RP 1800 and RP 1745. 

Split table and Insert spaces 

Reconciliation System 

Assumptions 

Definitions Baggage Association 

Assumptions

...

Split table and Insert spaces 

Various Methods to 

Associate Passengers to 

Baggage in Reconciliation 

Systems 

Various Methods... Various Methods...

...

Filing Period: Effective Date:

1 March - 1 June 2012

13 April 2012

RECOMMENDED PRACTICE 1740c

RADIO FREQUENCY IDENTIFICATION (RFID) SPECIFICATIONS FOR INTERLINE 

BAGGAGE

(amending)

PSC(29 33)1740c

B8.13/P

14. REFERENCES 

RP 1800 Automated Baggage Handling based on the IATA Licence Plate 

Concept (pending PSC approval in November 2005) 

Filing Period: Effective Date:

1 March - 1 June 2012

13 April 2012

RECOMMENDED PRACTICE 1745

BAGGAGE INFORMATION MESSAGES

(amending)

PSC(32 33)1745

B8.12/P

1.2 COMMUNICATIONS

Depending on the protocol used, the communications portion of the message may 

contain an Address Element and a Communications Reference element. While many 

Members use Type-B messages, especially for in-house communications, when 

interfacing to 3rd party systems or where data is required to be received more quickly, it 

may be necessary to transmit messages using other protocols such as Type-A, Edifact, 

X.25, etc. In these situations the IATA manual, 'Systems and Communications 

Reference' should be consulted along with direct dialogue between the airline and the 

operator of the automated baggage system. In these situations a direct dialogue 

between the airline and the operator of the automated baggage system is 

recommended.

.....

1.2.2 Communications Reference Element

This element identifying the sender of the message, is governed by the IATA's Systems 

and Communications Reference manual. If the message is a Type-B, the date and time 

is usually included by the communication software. Messages sent using other 

protocols will be dependent on whether the protocol requires a communications 

element.

Example of a Type-B: 

 HDQKMUS 231800
B8.5/P

2.2

...

BMM

...

Table in section 2.2

S Reconciliatio

n Data

S/Y/23/A/C/234/333/Y/Y

/A

N/

A

C C C N/

A

N/

A

N/

A

N/

A

N/

A

N/

A

ON/

A

N/

A

...

B8.11/P

2.3.24 .U LOADING DATA; 8 to 53 characters

 Construction Example Format

2.3.24.1 Element Identifier: full stop(.), 'U' .U .a

2.3.24.2 Separator: oblique (/) / /

2.3.24.3 Stowage Device ID AVE12345NW ammffff(f)mm(a)

.....

2.3.24.24 End of Element Delimiter <≡

Examples:

 .U/AVE12345NW/11R/T/Y/NRT/Y/NW009/04MAR/SEL<≡

 .U//AFTRT/X/F/DEN<≡

.U/T//MIA//AA614<≡

.U/CAR1357KL//M<≡
B8.4/P

.....

4.6 MULTIPLE USE OF DATA ELEMENTS

Multiple use of elements may be accomplished by following the structure of the BSM

and the sequencing of elements. The primary elements are the .F element (Outbound 

Flight Information) the .N element (Baggage Details), and the .I element (Inbound Flight 

Information) for a terminating or transfer BSM. The structure of the mandatory and 

conditional elements depends on whether the BSM is for an originating, transfer or 

terminating flight. Optional elements, which are related to mandatory elements are 

inserted in the order shown in 4.5. The .V element may occur once however elements 

.O, .N, .P, .G, .E and .R may be repeated multiple times, but only .O, .N, .E and .R may 

be used consecutively.

The following schematic illustrates the multiple use of elements in a BSM.

Element Description

.F Outbound Flight (LAX-NRT)

.I Inbound Flight (ORD-LAX)

.O Onward Flight (NRT-SIN)

.O Onward Flight (SIN-SYD)

.N Baggage Tag Details

.S Reconciliation Data

.W Pieces and Weight Data

.P Passenger Name

.G Ground Transport; Delivery address

.G Remainder of delivery address

.Y Frequent Traveler Number

.C Corporate or Group Name

.L Automated PNR Address

.T Baggage Tag Printer ID

.K Default Message printer

.E Baggage Exception Data

.R Internal Airline Data

.R Internal Airline Data

.X Baggage Security Screening

.N Baggage Tag Details

.S Reconciliation Data

.W Pieces and Weight Data

.P Passenger Name

.G Ground Transport; Delivery address

.G Remainder of delivery address
.Y Frequent Traveler Number

.C Corporate or Group Name

.L Automated PNR Address

.T Baggage Tag Printer ID

.K Default Message printer

.E Baggage Exception Data

.R Internal Airline Data

.R Internal Airline Data

.X Baggage Security Screening

B8.7/P

Section 7 - BAGGAGE NOT SEEN MESSAGE (BNS)

...

7.5 ELEMENT SEQUENCE SUMMARY

The following shows the sequence of elements in a BNS.

Element Requirement Definition

BNS Mandatory Standard Message Identifier

.V Mandatory Version and Supplementary Data

.F Mandatory Outbound Flight Information

.O Conditional Onward Flight Information

.N Mandatory Baggage Tag Details

.H Optional Handling Location

.P Conditional Passenger Name

.L Conditional Automated PNR Address

.W Optional Pieces Weight, Dimensions and Type 

Data

.Y Conditional Frequent Traveler Number

.C Conditional Corporate or Group Name

.E Conditional Baggage Exception Data

.R Optional Internal Airline Data

ENDBNS Mandatory End of Message Identifier
7.6 MULTIPLE USE OF DATA ELEMENTS

Multiple use of elements may be accomplished by following the structure of the 

BNS, the sequence of Its elements and the addressing for distributing the BNS. 

The prime elements are the .F (Outbound Flight Information),the .O (Onward 

Flight Information), and the following .N elements (Baggage Tag Details) which 

may be linked to the following .P element (Passenger Name). There may be only 

one .F and one set of .O elements for each BNS. Each .F element will be

followed by all .O elements. Each .N is the foundation for the other optional and 

conditional elements that follow. Optional and conditional elements which are 

related to the .N are inserted in the order shown in 7.5.

NOTE: .N elements without related optional elements (i.e., .P) must appear last.

The following schematic illustrates the multiple use of elements in the 

BNS.

Elements Description

.F Outbound Flight Information (US783)

.O Onward Flight Information (BA223)

.O Onward Flight Information (BA351)

.N Baggage Tag Details #1 (for passenger #1 in .P element)

.P Passenger Name #1 (associated to .N element #1)

.L Automated PNR Address (for passenger #1)

.W Pieces and Weight Data (for bag(s) #1)

.Y Frequent Traveler Number (for passenger #1)

.C Corporate or Group Name (for passenger #1)

.N Baggage Tag Details #2 (for passenger #2 in .P element)

.P Passenger Name #2 (associated to .N element #2)

.E Baggage Exception Data

.R Internal Airline Data (for passenger #2)
.R Internal Airline Data (for passenger #2)

.N Baggage Tag Details (for passenger #3 in .P element)

.P Passenger Name #3 (associated to .N element #3)

.E Baggage Exception Data

.N Baggage Tag Details #4 (for passenger #4 in .P element)

.P Passenger Name #4 (associated to .N element #4)

.N Baggage Tag Details #5 (no additional data supplied)

.N Baggage Tag Details #6 (no additional data supplied)

Note: See 7.9.2 for examples of multiple usage in the BNS Message.

7.7 CONDITIONAL ELEMENTS AND DATA ITEMS

7.7.1 Version and Supplementary Data (.V element)

The Message Reference Number is conditional upon the sender of the 

message requesting an acknowledgement, in which case a Message Reference 

Number is required. Additionally, a separator (oblique) is required in place of a 

Part Number, unless the message is partitioned, in which case the Part Number 

would follow the separator.

7.7.2 The Onward Flight Information element (.O) becomes mandatory when data is 

available.

7.7.3 Passenger Name element (.P) becomes mandatory when data is available.

7.7.4 Automated PNR Address element (.L) becomes mandatory when data is 

available.

7.7.5 The Number of Checked Bags in the .W element (Pieces and Weight Data) is 

mandatory when using the Checked Weight data item.

7.7.6 Frequent Traveler Number element (.Y) becomes mandatory when data is 

available.
7.7.64 Corporate or Group Name element (.C) becomes mandatory when data is 

available.

7.7.5 Baggage Exception Data (.E)

The .E element becomes mandatory when the data is available.

7.8 CONSTRUCTION OF ELEMENTS AND DATA ITEMS IN THE BAGGAGE NOT 

SEEN MESSAGE

Use Elements and Data Items Example

(M) STANDARD MESSAGE IDENTIFIER BNS

(M) VERSION AND SUPPLEMENTARY DATA

 (M) Element Identifier .V

 (M) Data Dictionary Version Number /1

 (M) Baggage Source Indicator T

 (M) Local Airport Code CDG

 (O) Part Number /PART1

 (C) Message Reference Number /1234567890

 (O) Acknowledgement Request /A

 (O) Encryption /123ABC456Z

(M) OUTBOUND FLIGHT INFORMATION

 (M) Element Identifier .F

 (M) Airline and Flight Number /AF912

 (M) Date /30APR

 (M) Destination or Transfer Airport Code /AMS

 (M) Class of Travel of Baggage /C

(C) ONWARD FLIGHT INFORMATION 

 (M) Element Identifier .O

 (M) Airline and Flight Number /KL601

 (M) Date /30APR

 (M) Destination or Transfer Airport Code LAX

 (O) Class of Travel of Baggage /M

(M) BAGGAGE TAG DETAILS

 (M) Element Identifier .N

 (M) Baggage Tag Number /0037123456

 (M) Number of Consecutive Tags 002
(O) HANDLING LOCATION

(M) Element Identifier .H

(C) Handling Terminal /T4

(C) Handling Bay/Pier /GREEN

(C) Handling Gate/Stand /D46

(C) PASSENGER NAME

 (M) Element Identifier .P

(M) Separator (oblique) /

 (O) Number Passengers With This Surname 2

 (M) Passenger’s Surname TENHAVE

 (O) Given Name and/or Initials, and/or Title /AMS

 (O) Additional Given Name and/or Initials,

and/or Title /JMS

(C) AUTOMATED PNR ADDRESS

 (M) Element Identifier .L

 (M) Automated PNR Address /U52I91

(O) PIECES WEIGHT, DIMENSIONS AND TYPE DATA

 (M) Element Identifier .W

 (M) Pieces/Weight Indicator /K

 (M) Number of Checked Bags /1

 (O) Checked Weight /10

 (O) Unchecked Weight /3

(C) Unit /CM

 (O) Length of the bag /68

 (O) Width of the bag /54

 (O) Height of the bag /24

(O) Baggage type code /02HWX 

(C) FREQUENT TRAVELER NUMBER

 (M) Element Identifier .Y

(M) Frequent Traveler ID Number /KL662503

(O) Tier Information /GOLD

(C) CORPORATE OR GROUP NAME

 (M) Element Identifier .C

 (M) Corporate or Group Name /AJAX TOUR
(C) BAGGAGE EXCEPTION DATA

(M) Element Identifier .E

(M) Exception Type /SPEQ

(O) INTERNAL AIRLINE DATA

 (M) Element Identifier .R

 (M) Free Text /FREE TEXT AREA

(M) END OF MESSAGE IDENTIFIER ENDBNS

7.9 EXAMPLE MESSAGES

7.9.1 Type-B Baggage Not Seen Message, sent to the final destination, transfer point 

and tracing system.

AMSLLKL LAXLLKL AMSLLAF 

ATLWMXS<≡ Message sent to

.CDGBRAF 311840<≡ Message sent by AF 

BNS<≡ Message type (BNS)

.V/1TCDG////123ABC4567Z<≡ Transfer bags at CDG with Encryption

.F/AF912/30APR/AMS/C<≡ Outbound flight info. (AF912 to AMS)

.O/KL601/30APR/LAX/M<≡ Onward flight info. (KL601 to LAX)

.N/0037123456002<≡ 2 missing bags, starting with tag number

0037123456

.H/T4/GREEN/D46 Handling location T4/ Handling pier 

GREEN/Handling gate D46

.P/CLOVER/LMR<≡ Passenger name

.L/U52I91<≡ PNR Address

.W/K/3/38/11<≡ Number of bags and weight

.Y/BSJ2238<≡ Frequent Traveler Number

.C/AJAX TOUR<≡ Tour Information

.R/LATE CHECKIN<≡ Internal Airline Data

ENDBNS<≡ End of Message Identifier
B8.9/P

7.9.2 Example of Multiple Use of Elements

AMSLLAF AMSLLKL LAXLLKL

LAXLLUA SMFLLLUA ATLWMXS Message sent to

.CDGBRAF 171250 Message sent by AF

BNS<≡ Message Type (BNS)

.V/1TCDG////123ABC456Z<≡ Transfer bags at CDG with Encryption

.F/AF912/30APR/AMS/C<≡ Outbound to AMS on AF912 C-Class

.O/KL601/30APR/LAX/M<≡ Onward to LAX on KL601 M-Class

.O/UA887/30APR/SMF/M<≡ Onward to SMF on UA887 M-Class

.N/0027123450002<≡ 1. 2 Bag Tags starting with 

0027123450

.N/0027123453001<≡ 2. 1 Bag Tag - 0027123453

.P/TENHAVE/AMS<≡ Passenger name

.Y/BSJ2238<≡ Frequent Traveler Number

.E/AVIH Live Animal in Kennel

.R/PAX ENROUTE TO HER 

.R/WEDDING-URGENT<≡ Internal Airline Data

.N/2001987654001<≡ 3. 1 Bag Tag - (no other information 

available for this bag) 

ENDBNS<≡ End of Message Identifier

B8.6/P

8.7.2 Flight Open Message

...

8.7.2.4 Partitioning of Messages

A FOM may not be partitioned.

8.7.2.5 Element Sequence Summary

The following shows the sequence of elements in the FOM.

Element Requirement Definition

BCM Mandatory Standard Message Identifier

 FOM Mandatory Secondary Level Message Identifier

 .V Mandatory Version and Supplementary Data

 .F Mandatory Outbound Flight Information

.H Optional Handling Location

.R Optional Internal Airline Data

 ENDBCM Mandatory End of Message Identifier

...
8.7.2.8 Construction of Elements and Data Items In The Flight Open Message

Use Element and Data Item Example

(M) STANDARD MESSAGE IDENTIFIER BCM

(M) SECONDARY LEVEL MESSAGE IDENTIFIER FOM

(M) VERSION AND SUPPLEMENTARY DATA

(M) Element Identifier .V

(M) Data Dictionary Version Number /1

(M) Baggage Source Indicator T

(M) Local, Transfer or Terminating Airport Code FRA

(N) Part Number – show only oblique; no data /

(C) Message Reference Number /1234567890

(O) Acknowledgement Request /A

(O) Encryption /123ABC456Z

(M) OUTBOUND FLIGHT INFORMATION

(M) Element Identifier .F

(M) Airline and Flight Number /LH3348

(M) Date /20MAR

(O) Destination or Transfer Airport Code /GVA

(O) HANDLING LOCATION

(M) Element Identifier .H

(C) Handling Terminal /T4

(C) Handling Bay/Pier /GREEN

(C) Handling Gate/Stand /D46

(O) INTERNAL AIRLINE DATA

(M) Element Identifier .R

(M) Free Text /DELAYED INBOUND

(M) END OF MESSAGE IDENTIFIER ENDBCM
B8.5/P

Section 9 - BAGGAGE MANIFEST MESSAGE (BMM)

...

9.5 Element Sequence Summary

The following shows the sequence of elements in a BMM.

Element Requirement Definition

 BMM Mandatory Standard Message Identifier

 .V Mandatory Version and Supplementary Data

.K Optional Default Message Printer

.I Mandatory Inbound Flight Information

.U Conditional Loading Data

.F Conditional Outbound Flight Information

.H Optional Handling Location

.N Mandatory Baggage Tag Details

.S Optional Reconciliation Data.

.W OptionalConditional Pieces Weight, Dimensions and Type Data

.Q Conditional Load Sequence Number

.O Conditional Onward Flight Information

.P Conditional Passenger Name

.Y Optional Frequent Traveler Number

.C Optional Corporate or Group Name

.L Conditional Automated PNR Address

.E OptionalConditional Baggage Exception Data

.R Optional Internal Airline Data

.X OptionalConditional Baggage Security Screening

 ENDBMM Mandatory End of Message Identifier

9.6 Multiple Use of Elements

Multiple use of elements may be accomplished by following the structure of the BMM 

and the sequence of its elements. The prime element is the .I (Inbound Flight 

Information). This provides the foundation for the .U element (Loading Data) and the .N 

element (Baggage Details) that follow it, which in turn can be linked to the following .P 

element (Passenger Name). As the .U element is conditional, a .N element may follow 

the .I element directly. Optional elements, which are related to the mandatory elements, 

are inserted in the order shown in Section 9.5. Except for the .V, .and the .K elements, 

all elements may occur multiple times, but only the .N,.O, .E and .R may be used 

consecutively.
Note: Bags with passenger names must appear before bags without passenger names 

(see example in 9.9.).

The following schematic illustrates the multiple use of elements in the BMM.

Element Description

.K Default Message Printer

.I Inbound Flight Information

.U Loading Data

.F Outbound Flight Information

.H Handling Location

.N Baggage Details

.S Reconciliation Data

.W Pieces and Weight Data

.Q Loading Sequence Number

.O Onward Flight Information

.O Onward Flight Information

.P Passenger Name

.Y Frequent Traveler Number

.C Corporate or Group Name

.L Automated PNR Address

.E Baggage Exception Data

.E Baggage Exception Data

.R Internal Airline Data

.R Internal Airline Data

.X Baggage Security Screening

.N Baggage Details

.Q Loading Sequence Number

.P Passenger Name

.E Baggage Exception Data

.E Baggage Exception Data

.X Baggage Security Screening

.U Loading Data (new .U element)

.F Outbound Flight Information

.H Handling Location

.N Baggage Details

.Q Loading Sequence Number

.P Passenger Name

.R Internal Airline Data

.R Internal Airline Data

.X Baggage Security Screening

.F Outbound Flight Information

.N Baggage Details
.Q Loading Sequence Number

.P Passenger Name

.R Internal Airline Data

.R Internal Airline Data

.X Baggage Security Screening

Note: See 9.9 for an example of multiple usage in a BMM.

...

9.7.6 The Passenger Name element (.P) is used when the Passenger name is known.

9.7.7 Baggage Exception Data (.E)

The .E element becomes mandatory when the data is available.

9.7.8 Pieces, Weight, Dimensions and Type Data (.W)

The .W element becomes mandatory when the data is available.

9.7.9 Baggage Security Screening (.X)

The .X element becomes mandatory when the data is available.

9.8 Construction of Elements and Data Items in the Baggage Manifest 

Message

Use Elements and Data Items Example

 (M) STANDARD MESSAGE IDENTIFIER BMM

(M) VERSION AND SUPPLEMENTARY DATA

(M) Element Identifier .V

(M) Data Dictionary Version Number /1

(M) Baggage Source Indicator T

(M) Local or Transfer Airport Code LHR

(O) Part Number /PART1

(C) Message Reference Number /1234567890

(O) Acknowledgement Request /A

(O) Encryption /123ABC456Z

(O) DEFAULT MESSAGE PRINTER

(M) Element Identifier .K

(M) Baggage Message Default Printer ID /3D1C08
(M) INBOUND FLIGHT INFORMATION

(M) Element Identifier .I

(M) Airline and Flight Number /BA117

(M) Date /03OCT

(M) Originating Airport Code /LHR

Use Elements and Data Items Example

(C) LOADING DATA

(M) Element Identifier .U

(C) Stowage Device ID /AVE12345BA

(C) Aircraft Compartment Or Loading Location /11R

(O) Type Of Baggage In Container/Location /T

(O) Classes of Travel of Baggage /F

(O) Destination or Transfer Airport Code of the Container /SEL

(O) Sealed Container Indicator /Y

(O) Connection Airline Code and Flight Number /NW009

(C) Connection Departure Date /04OCT

(C) Destination or transfer Airport Code of the Container /NRT

(C) OUTBOUND FLIGHT INFORMATION

(M) Element Identifier .F

(M) Airline and Flight Number /UA203

(M) Date /03OCT

(M) Destination Or Transfer Airport Code /DEN

(O) Class Of Travel Of Baggage /J

(O) HANDLING LOCATION

(M) Element Identifier .H

(C) Handling Terminal /T4

(C) Handling Bay/Pier /GREEN

(C) Handling Gate/Stand /D46

(M) BAGGAGE TAG DETAILS

(M) Element Identifier .N

(M) Bag Tag Number /0085123456

(M) Number Of Consecutive Tags 002
(O) RECONCILIATION DATA

 (M) Element Identifier .S

 (M) Authority To Load /Y

 (O) Seat Number /10A

 (O) Passenger Status /C

 (O) Sequence Number /098

 (O) Security Number /888

 (O) Passenger Profile Status /Y

(O C) PIECES WEIGHT, DIMENSIONS AND TYPE DATA

(M) Element Identifier .W

(M) Pieces/Weight Indicator /K

(C) Number Of Checked Bags /1

(O) Checked Weight /38

(O) Unchecked Weight /5

(C) Unit /CM

(O) Length of the bag /68

(O) Width of the bag /54

(O) Height of the bag /24

(O) Baggage type code /02HWX

(C) LOAD SEQUENCE NUMBER

(M) Element Identifier .Q

(M) Load Sequence Number /095

(C) ONWARD FLIGHT INFORMATION

(M) Element Identifier .O

(M) Airline and Flight Number /UA999

(M) Date /03OCT

(M) Destination Or Transfer Airport Code /SLC

(O) Class Of Travel Of Baggage /J

(C) PASSENGER NAME

(M) Element Identifier .P

(M) Separator (oblique) /

(O) Number Of Passengers With This Surname 2

(M) Passenger’s Surname GROBET

(O) Given Name and/or Initials and/or Title /M

(O) Additional Given Name and/or Initials and/or Title /J
(O) FREQUENT TRAVELER NUMBER

(M) Element Identifier .Y

(M) Frequent Traveler ID Number /KL662503

(O) Tier Information /GOLD

(O) CORPORATE OR GROUP NAME

(M) Element Identifier .C

(M) Corporate or Group Name /IATA BALLET

(C) AUTOMATED PNR ADDRESS

(M) Element Identifier ./L

(M) Automated PNR Address /6Y21AS

(O) BAGGAGE EXCEPTION DATA

(M) Element Identifier .E

(M) Exception Type /GRP

(O) INTERNAL AIRLINE DATA

(M) Element Identifier .R

(M) Free Text /FREE TEXT AREA

(O C) BAGGAGE SECURITY SCREENING

(M) Element Identifier .X

(M) Baggage Status /CLR

(O) Security Method /XRAY

(O) Autograph /TRANSFER

(M) END OF PART or ENDPART1 or

END OF MESSAGE IDENTIFIER ENDBMM

9.9 Example Messages

9.9.1 Loaded Bags (Type-B Message) – Sent to BA’s handling Agent in SEL from 

BA Baggage Handling System in LHR (1 bag in 1 container on flight) 

Routing:

BA117/23JAN/LHR/SEL

JL955/24JAN/SEL/NRT

SELKMXH<≡ To address

.LHRBRXH 231840<≡ From address

BMM<≡ BMM – Standard Message 

Identifier

.V/1TSEL/PART1/555333702//123ABC456Z<≡ Transfer bag in SEL; Multi part with Encryption
.K/3D2C08<≡ Message Printer ID

.I/BA117/23JAN/LHR<≡ Inbound flight BA117

.U/AVE1234JL/024L/T/Y/SEL/Y/JL955/234JAN/NRT<≡ Loading Information

.F/JL955/24JAN/NRT<≡ Outbound Flight JL955

.H/T1<≡ Handling Location

.N/0125123456001<≡ Bag tag number; Number of

consecutive tags

.Q/001<≡ Loading sequence

.P/1CHAN/T<≡ Passenger’s name

.X/CLR<≡ Screening description

ENDBMM<≡ End of Message Identifier

9.9.2 Example of Multiple Usage of Elements

Routing:

BA111/23JAN/LHR/SIN

QF006/24JAN/SIN/SYD

BMM<≡ BMM – Secondary Message 

Identifier

.V/1TSIN<≡ Terminating and/or transfer bags 

at SIN

.K/3D2C08<≡ Message printer ID

.I/BA111/23JAN/LHR <≡ Inbound flight BA111

.U/AVE1234BA//M/F/SIN/Y/QF6/24JAN/SYD<≡ I. Loading 

information

.F/QF006/24JAN/SYD/Y<≡ A. Outbound Flight QF006

.N/0125064717001<≡ 1. 1st tag number and 

number of tags

.Q/006<≡ a. Loading sequence

.P/1NORMAN/G<≡ b. Passenger’s Name

.Y/BA85521<≡ c. Freq.Traveler Number.

.N/0125064912001<≡ 2. 1st tag number and 

number of tags

.Q/083<≡ a. Loading sequence

.P/1ZELLER/F<≡ b. Passenger’s name

.Y/US7444591<≡ c. Freq. Traveler Number.

.X/CLR/XRAY<≡ d. Baggage Security

Screening 

.N/0125064917001<≡ 3. 1st tag number and 

number of tags

.Q/117<≡ a. Loading sequence

.P/1SCHUT/KCWMRS<≡ b. Passenger’s Name

.Y/US744591<≡ c. Freq. Traveler Number.

.X/CLR/XRAY<≡ d. Baggage Security

Screening

 
.N/0125067239001<≡ 4. 1st tag number and number 

of tags

.Q/127<≡ a. Loading sequence

.U//11R/M//SIN<≡ B. Loading information

.N/0125065209001<≡ 1. 1st tag number and number 

of tags

.Q/36<≡ a. Loading sequence

.P/1JACKLIN/T<≡ b. Passenger’s Name

.Y/QF003664<≡ c. Freq. Traveler Number.

.X/CLR<≡ d. Baggage Security

Screening 

ENDBMM<≡ End of Message Identifier

9.9.3 Example of BMM including information about unaccompanied baggage 

(UNAC)

BMM<≡ BMM –Standard Message 

Identifier

.V/1TSEL/PART1/555333702//1234ABC456Z<≡ Transfer bag in SEL; Multi part 

with encryption

.K/3D2C08<≡ Message printer ID

.I/BA117/23JAN/LHR<≡ Inbound flight BA117

.U/AVE1234JL/024L/T/Y/SEL/Y/JL955/24JAN/NRT<≡ Loading 

information

.F/JL955/24JAN/NRT<≡ Outbound flight JL955

.H/T1<≡ Handling location

.N/0125123456001<≡ Bag tag number; Number of 

consecutive tags

.Q/001<≡ Loading sequence

.P/1CHAN/T<≡ Passenger’s Name

.E/UNAC<≡ Unaccompanied baggage to be 

collected by the passenger or the 

airline/handling agent

.X/CLR<≡ Screening description

ENDBMM<≡ End of Message Identifier

...
B8.10/P

Attachment ‘E’

BAGGAGE SOURCE MESSAGE (BSM) FOR SORTATION AND 

RECONCILIATION AND BAGGAGE PROCESS MESSAGE (BPM) FOR 

RECONCILIATION

• BSM data sent to sortation and reconciliation systems

• BTM BPM data sent from a reconciliation system to carrier host

• Baggage Itinerary: LH430 FRA-ORD

Filing Period: Effective Date:

1 March - 1 June 2012

13 April 2012

LH

Host

FRA

Reconciliation

System

FRA

Sortation

System

BSM BSM

BPM
RECOMMENDED PRACTICE 1790

ADDITIONAL SERVICES

(amending)

PSC(30 33)1790 Expiry: Indefinite

Type: B

T2.6/P

2. DEFINITIONS

...

Electronic Miscellaneous Document (EMD) means an electronic record issued by a 

Member or its authorized agent, in accordance with applicable tariffs, for residual value 

or for the collection of miscellaneous charges. An EMD must be either an EMD-A or an 

EMD-S. 

Electronic Miscellaneous Document Associated – EMD-A means an EMD issued for 

the collection of miscellaneous and excess baggage charges that are to be lifted with an 

ET flight coupon(s). The association between an EMD value coupon(s) and the 

corresponding ET flight coupon(s) requires that the coupon status of both remain 

synchronized. 

The intent of the association between the ET flight coupon(s) and the EMD-A value 

coupon(s) is to ensure the usage of the coupon is synchronized.

T2.33/P

11. REVENUE ACCOUNTING

.....

For the purposes of revenue accounting and interline billing, APTCO optional Services 

issued on an EMD do not constitute ‘Sundry Charges’ as provided in

Resolution 727a.

Filing Period: Effective Date:

1 March - 1 June 2012

13 April 2012

RECOMMENDED PRACTICE 1797

COMMON USE PASSENGER PROCESSING SYSTEMS (CUPPS)

PSC(29 33)1797

P6.3.8

RECOMMENDED THAT:

Members use the procedures and specifications for Common Use Passenger 

Processing Systems (CUPPS) as set forth in Attachments ‘A’, ‘B’ and ‘C’.

(Attachments ‘A’, ‘B’ and ‘C’ are published separately – contact Manager Airport and 

Inflight Services, email: milesC@iata.org).

Secretary note: the following text is completely new.

When an organization plans to operate shared passenger processing systems in an 

airport or other common environment, for the purposes of supporting multiple airline 

processes, the specifications and standards as described in this Recommended 

Practice shall be applied.

Common Use Passenger Processing Systems (CUPPS) describes the range of 

services, specifications, and standards enacted to enable multiple airlines, service 

providers, or other users to share physical check-in or gate podium positions (whether 

simultaneously or consecutively). The CUPPS scenario assumes a circumstance 

whereby an airline or employee other service provider interacts with a passenger for 

check-in and boarding processes. This Technical Specification describes agent 

platforms that will accommodate, but not be limited to, check-in and boarding activities. 

Future developments may provide for other functions, both business and technical.

Table 0.1 shows the CUPPS foundational principles.
Table 0.1: CUPPS Foundational Principles

Principle Description

Platform 

Independence

Differences in legacy CUTE Platforms lead to 

additional application complexities and CUTE 

vendor-specific versions that must be maintained 

over time.

Business Process 

Facilitation 

CUPPS provides a flexible Platform that 

facilitates Application functionality that may be 

used for a variety of business functions.

“Minimum, Defined” CUPPS Platforms must provide the functionality 

defined as required in the CUPPS Technical 

Specification.

Affordability CUPPS provides the tools and technologies that 

may lead to additional economies of scale and 

economies of scope.

Predictability CUPPS provides enhanced predictability in terms 

of deployment and overall platform and 

application maintenance (duration, cost, etc.)

Serviceability CUPPS provides the tools and technologies to 

increase efficiencies of application upgrades and 

maintenance.

1. Overview

This section provides an overview of the benefits of CUPPS, its strategy as a product, 

the management oversight of the ongoing CUPPS activities, and migration strategies.

1.1 Benefits of CUPPS

A CUPPS implementation will enable airlines to provide passenger services in the 

context of a shared check-in, gate podium, or kiosk. 

The major benefits of CUPPS are:

 Efficient use of expensive facilities on- and off-airport, thereby reducing the need 

for facility expansion.

 Flexibility for accommodating flight segment additions or deletions by carriers in 

the use of space.

 The ability for an application provider to maintain a single CUPPS-compliant 

application that will be seamlessly functional on any CUPPS platform, regardless 

of the particular platform provider.

 A platform that can easily accommodate various peripheral devices in support of 

business processes.

 An enabler for improved customer service.

 A flexible architecture to easily accommodate alterations in the passenger 

processing flow.

 An accommodation of the flow of data between emerging and evolving airport 

and airline systems, as mutually agreed upon between the platform provider and 

application provider.
 Improved flexibility for system upgrades and new versions of software and 

hardware.

 Enhanced ease of access to new markets, with overall predictability of cost 

magnitudes from a technology deployment standpoint.

1.2 CUPPS Product Strategy

The CUPPS product strategy is to deliver a common use platform to support individual 

and shared airline processes at a shared workstation at check-in, gate, and other 

positions, while maintaining the ability for users to maintain their brand images. The key 

to the product strategy is an open architecture system where it is possible to use 

virtually any hardware or software that complies with CUPPS standards included in the 

CUPPS Technical Specification (CUPPS-TS).

The functionality described is not exclusive; any future products and/or applications, as 

appropriate, may be introduced as business needs change. 

The initial CUPPS strategy is focused on implementation in both the agent-assisted 

check-in and boarding environments on-airport and potentially in kiosk environments. 

CUPPS could also be carried forward to provide services at other venues such as rental 

car agencies, bus terminals, seaports, and railway stations.

The development of the CUPPS product will initially be done collaboratively with the 

cooperation of airlines and airports, platform providers, and platform suppliers.

1.3 CUPPS vs. CUTE Summary

There are many differences between the legacy CUTE environment and the new 

CUPPS forward-looking environment. 

Table 0.1 below provides a summary of the major differences.

Table 0.1: CUTE vs. CUPPS Summary

CUTE CUPPS

Proprietary peripheral interfaces per 

supplier.

Unified peripheral interface across 

suppliers

Varying support for various peripherals 

and varying functionality provided.

Unified support for each device 

category with defined basic 

functionality

Built-in AEA support including ATB-II 

with propriety supplier-specific 

extensions.

Elimination of proprietary device 

firmware in favor of current formats 

supporting barcodes; no ATB-II 

operations.

Proprietary management interfaces 

with varying levels of functionality.

Unified approach to system 

management, including remote 

administration capabilities.

Legacy CUTE may utilize a mixture of

workstation operating systems and 

All CUPPS workstations will use a 

defined operating system and network 
network protocols. protocol (including network services).

Legacy CUTE implementations 

provided a mixture of low- and highlevel peripheral interface technologies 

that were largely incompatible and 

supplier-specific.

CUPPS defines a standard high-level 

interface standard between 

applications and the platform.

1.4 CUPPS Platform Standards

The CUPPS platform comprises, at minimum, the hardware and software components 

defined in the CUPPS-TS. The CUPPS platform is envisaged to support a 

comprehensive range of airline and airport passenger processes and services. Initial 

focus of the product will be on passenger check-in (which could include baggage checkin) and boarding. Devices within a CUPPS platform shall only be used by applications 

initiated and operated within the platform or diagnostic software.

Application providers are responsible for the delivery of particular application 

functionality required to support the business processes of its users.

All physical components located at a particular airport shall be equally usable by all 

participating users.

1.5 CUPPS Management Oversight

The CUPPS Recommended Practice includes promotion of a framework to encourage 

competition, including among vendors, suppliers, carriers, and airports, and to 

encourage introduction of new technology and ideas. CUPPS is designed to increase 

efficiency though recommended practices published in a living document that 

acknowledges changes in technology and industry without compromising introduction of 

new technology or competition. The CUPPS RP is designed to foster competition and 

innovation through an open process that encourages all potential competitors to 

participate.
In order to facilitate the overall success of the initiative and to enhance the economic 

benefit to the industry, the three organizations with direct ownership interest in the 

recommended practice (IATA, A4A and ACI) have established the Passenger 

Experience Management Group (PEMG) to oversee the CUPPS group by setting its 

direction and priorities..

1.6 CUTE to CUPPS Migration

With any next-generation standard or product, a mechanism must be provided to 

migrate from the previous standard or product to the next-generation standard. This 

section provides the migration considerations for moving from CUTE to CUPPS.

Given the wide array of variations between CUTE implementations combined with the 

differences that exist due to the local business and operational scenarios at each CUTE 

location, there is no one migration strategy that is applicable across suppliers. 

Therefore, each platform provider and/or platform supplier that proposes a CUPPS 

solution must provide a reasonable and realistic migration strategy. 

Note: CUTE suppliers are required to provide support for their existing CUTE platforms 

for a period of three years from the date of first publication of the CUPPS Technical 

Specification

Table 0.2 shows the general considerations that each supplier’s migration strategy will 

likely address. Not every item will be applicable for a given situation nor will the list 

presented in 

Table 0.2 constitute the entire list of considerations that every site must contemplate. 

These reflect examples of major considerations.

Table 0.2: CUTE to CUPPS Migration Considerations

Consideration Impact

Potential operating 

system changes

For applications built on a non-supported operating system, 

applications must be ported or rewritten for the CUPPS 

supported operating systems.

Application changes Legacy CUTE applications must be adapted to work with the 

CUPPS platform.

Elimination of 

proprietary device 

firmware

Applications and business processes that rely on proprietary 

device firmware must be adapted to E-Tickets and barcode 

technologies. Proprietary peripheral interfaces are eliminated 

in favor of a standard high-level interface.

CUPPS suppliers are not required to provide solutions to any or all of the considerations 

given in 

Table 0.2 nor are the suppliers prohibited from providing functionality that is outside of 

the CUPPS specification. It is understood that CUPPS suppliers will continue to offer 

solutions to customers based on mutually agreeable terms and conditions. 
2. CUPPS Technical Documentation Summary

Major deliverables of the CUPPS process will be the creation and adoption of the 

CUPPS-TR and CUPPS-TS, which are overviewed below. The CUPPS-TR provides a 

formal requirements document used to guide the CUPPS-TS. CUPPS-TS provides 

definitions for the functionality and performance of the CUPPS platform and defines the 

functionality and performance of the interfaces between the application and platform. 

The CUPPS-TS will not, however, specify an implementation for that functionality or 

interface. CUPPS suppliers are free to implement their CUPPS products as the supplier 

deems appropriate provided that they meet the functionality and interfaces defined in 

CUPPS-TS. The CUPPS-TS also addresses the minimum operational characteristics 

for CUPPS applications.

2.1 General

The general considerations for CUPPS are provided below.

2.1.1 Access to the CUPPS-TR and CUPPS-TS

In accordance with the Governance terms of reference, ACI, A4A, and IATA shall 

produce, update, and make available the CUPPS-TR and CUPPS-TS in electronic 

format which shall set forth the standards and specifications for CUPPS. As a condition 

to certification, application providers and platform providers shall be required to maintain 

a current subscription to the CUPPS-TR and CUPPS-TS. To enable them to defray the 

costs incurred in developing and maintaining the CUPPS-TR and CUPPS-TS, ACI, 

A4A, and IATA may establish an annual subscription fee for the documents. Access to 

these documents, and the fee to be charged, will be non-discriminatory, i.e. all 

interested parties, whether or not members of ACI, A4A, or IATA, will be afforded 

access to the documents on the same terms, and will pay an equal fee for such access.

2.1.2 CUPPS Technical Documentation Ownership

The requirements, functional requirements, specifications, and interface descriptions as 

described in CUPPS-TR and CUPPS-TS are owned by ACI, A4A, and IATA and are 

maintained by the CUPPS Management Group.

2.1.3 Data Privacy

The rules governing the safeguards placed on data acquisition, retention, and 

accessibility are defined below. Table 3.1 provides a summary comparison of Public 

Data, Personal Data, and Proprietary Data.

Additionally CUPPS recognizes and acknowledges that it should facilitate, and not 

prevent, the end customers' PCI Data Security Standard compliance. Examples of 

practices that can prevent compliance include:

 Storage of magnetic stripe data and/or equivalent data on the chip in the 

customer's network after authorization.

 Applications that require customers to disable other features required by the PCI 

Data Security Standard, such as anti-virus software or firewalls, in order to get 

the payment application to work properly.

 Vendors’ use of unsecured methods to connect to the application to provide 

support to the customer.
Secure devices, when implemented in a PCI DSS-compliant environment, will minimize 

the potential for security breaches leading to compromises of full magnetic stripe data, 

card verification codes and values (CAV2, CID, CVC2, CVV2), PINs and PIN blocks, 

and the damaging fraud resulting from these breaches.

The Application Supplier/Provider shall ensure that when a Payment Card is read for 

any purpose other than payment, such as Form of Identification (FOID), the application 

shall include only the first 6 and the last 4 digits of the credit card number. All remaining 

digits shall be replaced with an X. E.g. 123456XXXXXX7890." 

This behavior is in compliance with Card Scheme Operating Regulations and IATA 

Resolutions 722-f-g-h & 725-f-g-h.

For more information on PCI DSS and for the current version please visit: 

www.pcisecuritystandards.org

Table 0.3: Comparison of Data Privacy Rules

Data Type Acquisition Retention Accessibility

Public Acquired as desired Period defined by 

the PP 

Available to all users or 

interfaced systems

Personal Only as allowed and 

appropriate

Only as allowed 

and appropriate

Only as allowed and 

appropriate

Proprietary Only as allowed and 

appropriate

Only as allowed 

and appropriate

Only as allowed and 

appropriate

Usage and/or 

Performance

Automatically as 

CUPPS is used

Period defined by 

the PP

To using entity (PP, PS, 

AS, and User)

2.1.4 Public Data

Public Data have no access controls placed on them. Public Data may be requested by 

and revealed to any CUPPS user or interfaced system. Public Data may be acquired 

and/or retained for a period to be defined by the PP.

2.1.5 Personal Data

Acquisition, retention, and accessibility of Personal Data must be provided in 

accordance with Recommended Practice 1774 (Protection of Privacy and Trans-border 

Data Flows of Personal Data used in International Air Transport of Passengers and 

Cargo) and regulations defined by the applicable legal jurisdictions.

2.1.6 Proprietary Data

Acquisition of, retention of, and accessibility of Proprietary Data is to be provided in 

accordance with the rules defined by the originator of the Proprietary Data. In the 

absence of superseding rules, the default rule implemented by CUPPS must be that 

Proprietary Data is acquired, retained, and accessed only with the permission of the 

originator of the data. 
2.1.7 Usage and/or Performance Data

Acquisition, retention, and accessibility of Usage and/or Performance Data are to be 

provided in accordance with the CUPPS-TS. In the absence of superseding rules, the 

default rule implemented by CUPPS must be that Usage Data is:

 Acquired automatically by CUPPS.

 Retained for a period defined by, and at the discretion of, the platform provider.

 Accessed only by:

o The using entity, i.e. the entity using CUPPS whose activity was recorded 

by the platform. A using entity must not be able to access another using 

entity’s data. 

o The platform provider. 

o The platform supplier.

2.12 CUPPS Logical System Architecture

Unlike CUTE, whose logical system architecture varied across suppliers, CUPPS 

provides a unified logical architecture. The logical system architecture is overviewed 

below. Further information regarding the logical architecture will be available in the 

CUPPS-TS.

Note that this section provides information only on the logical architecture of CUPPS. 

Since each CUPPS supplier is free to implement the CUPPS system as the supplier 

deems appropriate, it is not possible to define the physical architecture of a particular 

supplier’s implementation of CUPPS.

2.2.1 CUPPS Logical System Architecture Summary

Figure 0.1 shows a summary view of the logical architecture of a CUPPS 

implementation. Each block in the diagram is described below. Airline application 

server(s) or host system(s) communicate to the airline CUPPS application using a 

mutually supported communications protocol. The architecture and functionality of the 

airline back-end systems or airline application are outside of the scope of CUPPS and 

are therefore not discussed.

The CUPPS application communicates with the CUPPS platform utilizing the interface 

defined in the CUPPS-TS. Applications may only access CUPPS-defined peripherals 

via the interface defined in the CUPPS-TS. Direct access to a CUPPS-defined 

peripheral device is not allowed. Applications may access workstation components 

(see Table 0.5) via basic operating system services.

The airline system manager or the platform provider’s system manager components 

may communicate with a CUPPS platform using the management interface defined in 

CUPPS-TS.
Figure 0.1: CUPPS Logical System Architecture Summary

Figure 0.2 shows a detailed view of the logical architecture.

Note: Figure 0.1 and 

Figure 0.2 are presented here for illustrative purposes only. Refer to the CUPPS-TS for 

actual architectural definitions.}
Figure 0.2: Logical System Architecture Detail

2.3 Network

The network infrastructure for a CUPPS implementation will provide functions described 

below. Technical specifications for these functions are described more fully in CUPPSTS. It is understood that the provider of the network infrastructure may not be the same 

entity as the provider of CUPPS. If a different entity provides the network, then Table 

0.2 below represents examples of service requirements that CUPPS expects.
Table 0.4: Network Standards

Function Description

BC/DR The network underlying CUPPS should provide Business 

Continuity/Disaster Recovery functionality, ensuring 

redundancy and resiliency.

DHCP Dynamic Host Configuration Protocol may be used to 

manage network address allocation.

DNS DNS provides name-to-IP and IP-to-name address lookup 

functionality for computer addresses and names. DNS 

used by CUPPS must support multiple zone-to-zone 

transfers and multiple partial zone-to-zone transfers.

Login/Logon A standardized login scheme will be used to gain access 

to network resources.

MQoS Networks used for CUPPS must meet a MQoS standard.

NAPT NAPT hides the internal structure of the network by 

mapping all addresses on the network to a single address 

using different network ports.

NAT NAT translates one range of network addresses onto 

another range.

SNMP SNMP provides a standard for remote management of 

network devices.

Standardized 

Procedures

CUPPS networks must be managed with a set of 

standardized procedures, e.g. ITIL, ISO, etc.

VPN A VPN provides for a secure tunnel between two points 

on a network. VPNs are often used to tunnel from a 

workstation on an external network into a corporate 

private network.

Wireless Wireless infrastructure may be made available for use by 

the airlines, airports, and/or the general public. 

Appropriate security measures must be undertaken to 

ensure access is controlled and data is kept secure for 

CUPPS. NB: Reference to PCI-DSS solutions within this 

document do not refer to wireless infrastructure.

2.4 Hardware

The CUPPS hardware standards are overviewed below. The details of the hardware 

requirements for CUPPS are defined in the CUPPS-TS.

2.4.1 Workstations

The CUPPS Technical Specification shall provide the standard device abbreviations, 

descriptions, interface language(s) (e.g. AEA), function requirements (e.g. speed and 

resolution), and requirements levels (e.g. “defined, required”, “defined, not required”). 

Choices of specific hardware are left to the individual CUPPS supplier.
2.4.2 Vendors

Workstation hardware may be provisioned from any vendor provided that the hardware 

meets the requirements for a given implementation. The vendors that are appropriate 

for a given implementation will vary depending upon the local implementation details 

and local preferences.

Table 0.5 shows the minimum components, e.g. the internal components that make up 

the workstation and its operating system, used by CUPPS workstations. A CUPPS 

interface will not be defined for these components. These components are directly 

accessed by either CUPPS or COTS applications. 

Table 0.5: Required Workstation Components

Function Description

Computer The computer and its internal components.

Keyboard A standard 101+-key keyboard is required for each end-user 

workstation per local configurations.

Pointing Device A pointing device is required for each workstation. 

Touch Screen A touch screen is required to support the check-in and 

boarding functionality required by airlines and airports.

Windows Operating 

System Services

Windows provided print spooler, file access, memory 

management, etc.

Workstation Ergonomics

The workstations should be designed to maximize utilization of limited counter-top 

surfaces (e.g. trackball versus mouse, etc.). The counter design should be configured 

in conjunction with ergonomically placed peripherals, to minimize time/motion activities 

in issuing/reading documents.

Consideration will be given to the occupational requirements related to accommodation 

for physical challenges and overall occupational health and safety. 

A repository will be established for counter design documents related to common use 

installations. This repository will tentatively be held by Airports Council International –

World. 

2.4.3 Servers

Server hardware may be provisioned from any vendor provided that the hardware 

meets the requirements for a given implementation. The vendors that are appropriate 

for a given implementation will vary depending upon the local implementation details 

and local preferences.
2.5 Software

CUPPS software will be designed as described below.

2.5.1 Workstations

Table 0.6 shows the CUPPS software and design considerations for end-user 

workstations. The CUPPS-TS shall define the exact requirements for each of these 

functions. 

The “workstation” requirements given below do not imply or require any particular 

implementation by a CUPPS supplier other than these functions must be accessible via 

the defined interfaces from every CUPPS workstation in a given implementation. 

CUPPS suppliers are free to implement a software architecture that implements the 

standard CUPPS interfaces as they deem appropriate. 

Table 0.6: CUPPS Platform Workstation Software Components

Function Description 

Alerts Platforms must provide security alert distribution by authorized 

administrators 

Application 

Management 

CUPPS platforms must implement application management 

functionality appropriate to support the CUPPS platforms.

Application 

Requirements 

Applications must be well-behaved, with no unreasonable 

performance impacts, security risks to the platform or local 

network.

Authentication Platforms must provide authentication services for users onto 

the workstation and local network resources.

COTS Software COTS applications must be well-behaved and must not pose 

any unreasonable performance or security impacts to the 

platform or local network. 

Event 

Management 

Platform must implement an event management functions for 

application and platform events.

Hardware 

Abstraction Layer 

(HAL) 

Platforms must provide a HAL that shields applications from 

the supplier, firmware, and connectivity of the peripheral. 

IATA Message 

Interface 

To facilitate integration with airport systems, platforms must 

provide the capability to send and receive IATA defined 

message formats. 

Logging Platforms must provide a logging interface appropriate for 

application support and debugging purposes.

Menus Platforms must provide a menu system with appropriate 

security. 

Operating System Workstations must use an operating system as defined in the 

CUPPS-TS.

Performance Platform performance must meet or exceed defined 

parameters. 

Permissions Platforms must manage and secure access to the platform, 

network resources, and user or airline data.
Platform 

Management 

Platforms must provide management functionality to facilitate 

the administration, support, and usage.

Software 

Distribution

Platforms must provide a mechanism to distribute software

Storage Platforms must provide an interface for secure storage of data 

in or persistent areas.

Supplier CUPPS applications work across CUPPS implementations.

World-Wide 

Naming Standards 

A world-wide naming convention for the naming of CUPPS 

workstations and peripherals.

2.5.2 Servers

Table 0.7 shows the CUPPS software and design considerations used on application or 

platform servers. The CUPPS-TS shall define the exact requirements for each of these 

functions.

The “server” requirements given below do not imply or require any particular 

implementation by a CUPPS supplier. CUPPS suppliers are free to implement a 

software architecture that implements the standard CUPPS interfaces as they deem 

appropriate.

Table 0.7: CUPPS Platform Server Software Components

Function Description 

CUPPS Platform 

Functionality

CUPPS suppliers may implement software 

components on the CUPPS servers as they deem 

appropriate.

Operating System(s) CUPPS suppliers are free to implement any 

operating system on the server hardware that 

satisfies CUPPS-TS.

2.6 Logo Repository

IATA may maintain a repository of carrier-approved logos, for use by approved IATA 

associates or ACI member airports to enable the associates to find the latest approved 

version of carrier approved logos (or others, such as those used by ground handlers) for 

use on systems including CUPPS, AIDX, etc. It is recommended that the repository 

contain a variety of logos for each carrier, with descriptions for proper use (for a light 

background, for a dark background, for small logos on individual lines of AIDX displays, 

etc.). Additionally, each logo should be made available in a format scalable to a variety 

of display sizes so that the logo can be viewed without distortion. Every effort should be 

made to provide enough information about each logo and its intended use, so as to 

reasonably ensure the logo will be correctly displayed.
3. Roles and Responsibilities

This section addresses the roles and responsibilities of the various CUPPS parties, as 

they pertain to overall system provision and maintenance.

To ensure a consistent interpretation of the material below, please note these 

definitions:

 Supplier A supplier is the entity that creates the system. Suppliers market their 

products and services to providers.

 Provider A provider is the entity that acquires the system from a supplier and 

provides it to the user community.

3.1 Platform Provider’s Responsibility

The platform provider will, as defined in the SLA, ensure that:

 The CUPPS platform is operational and usable during the specified operational 

hours.

 The CUPPS platform is functioning and certified according to CUPPS standards.

 Software levels and version control of the platform are maintained for the site.

 Statistical and management information is available.

 Notification is made to the application provider of faults that cannot be resolved.

 That the ability exists to disable an application if it is deemed to be causing other 

applications and/or the CUPPS platform to malfunction. If this is the case they 

will endeavor to inform the application provider in advance.

 CUPPS workstation locations are to be locally and mutually agreed upon.

3.2 Application Provider’s Responsibility

The application provider is responsible for the application code, which must follow and 

pass the Certification and Deployment process as defined in the CUPPS-TS. 

If the application provider decides to use a dedicated application Server, either at the 

CUPPS site or a location that is under the control of the application provider, then that 

application provider is responsible for the maintenance, administration, and support of 

the Server. 

The application provider is responsible for any communication lines to and from the

application provider’s server(s).

The application provider must provide the correct protocol and interfaces to allow 

connection at the CUPPS site as mutually agreed between the platform provider and 

the application provider. 

3.3 Establishment of Service Levels

Minimum Service Levels, in the form of a Service Level Agreement (SLA) will be locally 

and mutually agreed upon between the platform provider, the platform supplier, and the 

application supplier. As a guideline, a sample SLA template is included in the CUPPSTS. 
3.4 Management Information and Availability Figures

The platform provider should be able to supply all application providers the Availability 

figures and access to the management tool used for real time status of the CUPPS 

installation.

3.5 Certification and Deployment

The platform and applications must be certified and deployed in accordance with the 

procedures in the Certification and Deployment section of the CUPPS-TS.

4. Applicable Industry Standards

CUPPS adheres to, references, and acknowledges the standards shown below.

Table 0.1: IATA Recommend Practices Reference

IATA A4A Title

1008 100.1

5

Glossary of Commonly Used Air Passenger Terms

1706 n/a Functional Specification for Standard Departure Control System

1706

e

30.10

2

Paper Specifications Documents to be Printed by a General 

Purpose Printer (GPP) In A Common Use Self-Service (CUSS) 

Kiosk

1720 n/a Seat Assignment Parameters

1724 20.03 General Conditions of Carriage (Passenger and Baggage)

1740

a

30.42 Form of Interline Baggage Tag

1796 30.76 Baggage System Interface

1774 n/a Protection of Privacy and Transborder Data Flows of Personal 

Data Used in International Air Transport of Passengers and 

Cargo

1778 n/a Corporate Client Identification Service

1784 * Electronic Reservation Services Providers (ERSPs)

1797 n/a Common Use Terminal Equipment

* A4A Electronic Marketplace Committee RP

Table 0.2: IATA/ARC Resolutions Reference

IAT

A

A4A Title

740 30.4

2

Form of Interline Baggage Tag

800

z

n/a Electronic Ticketing

898

a

n/a Electronic Reservation Services 

Providers
Table 0.3: IATA/ATA Resolutions Reference

IATA A4A Title

722e ATB Standard 

722f 20.60 Electronic Ticket Airline

722g 20.61 Electronic Ticket Neutral

722h 20.62 Electronic Ticket Ground Handling

724 20.03 Passenger Ticket Notice and Conditions of Contract

728 110.1

6

Code Designators for Passenger Ticket and 

Baggage Check

725f 20.63 Electronic Miscellaneous Documents Airline

725g 20.64 Electronic Miscellaneous Documents Neutral

740 30.35 Form of Interline Baggage Tag

791 20.20

4

Specifications for Airline Industry Integrated Circuit 

Card (ICC)

Table 0.4: Other Document References

Reference

Electronic Reservation Services Providers Implementation guide

Electronic Ticketing Implementation Guide

Integrated Circuit Card Implementation Guide

Workstation Ergonomics ACI

Logo Repository IATA

Payment Card Industry Data Security Standards

5. Abbreviations and Glossary

ACI

Airports Council International

AEA 

Association of European Airlines. 

AIDX 

Aviation Information Data Exchange.

Application Provider 

An Application Provider is an entity that provides and manages applications accessible 

from a CUPPS workstation. An Application Provider is often an airline, but may also be 

another organization that provides customer handling services, or any other entity 

whose end-users utilize software on a CUPPS workstation.
Application Supplier 

An Application Supplier is an entity that creates application software. The Application 

Supplier writes the application software on behalf of, and provides related services to, 

the Application Provider. An Application Supplier may be a technology firm contracted 

by an Application Provider, or an internal technology organization within an Application 

Provider. 

A4A

Airlines for America (formerly the ATA - Air Transport Association)

COTS 

Commercial Off-The-Shelf.

CUPPS 

Common Use Passenger Processing Systems.

CUPPS Application 

A CUPPS Application is a single business application that runs on a CUPPS Platform. 

A CUPPS Application conforms to the application standards defined in the CUPPS 

Technical Specification.

CUPPS Certified 

A CUPPS Certified Platform, Application or Device has successfully completed all three 

steps (Technical Compliance, Integration and Beta Testing) of the Certification process.

CUPPS Compliant 

A CUPPS Compliant Platform, Application or Device has successfully completed the 

Technical Compliance Testing phase of the Certification process. 

CUPPS Platform 

A CUPPS Platform is an IT environment that supports applications for one or more 

Application Providers (usually airlines or other entities operating in an airport 

environment). A CUPPS Platform conforms to the platform standards defined in the 

CUPPS Technical Specification.

CUTE 

Common Use Terminal Equipment.

DHCP 

Dynamic Host Configuration Protocol.

DNS 

Domain Name System.

GUI 

Graphical User Interface.

HAL 

Hardware Abstraction Layer.
IATA 

International Air Transport Association.

ICAO

International Civil Aviation Organization.

IEEE 

Institute of Electrical and Electronics Engineers.

IETF 

Internet Engineering Task Force. 

ITIL 

Information Technology Infrastructure Library.

JAR 

Java Archive.

LAN 

Local Area Network.

MQoS

Minimum Quality of Service.

NAPT

Network Address Port Translation. 

NAT 

Network Address Translation.

OCR 

Optical Character Recognition or Optical Character Reader.

PAT 

See NAPT.

Platform Provider 

A Platform Provider is an entity that acquires a CUPPS Platform from a Platform 

Supplier and offers it to the user community. A Platform Provider is responsible to 

manage, maintain and administer the implemented Platform in a production 

environment.

Platform Supplier

A Platform Supplier is an entity that creates the CUPPS Platform. 

RFC 

Request For Comments; Request for Change.

SLA 

Service Level Agreement.
SNMP 

Simple Network Management Protocol.

TCP/IP 

Transmission Control Protocol over Internet Protocol.

VPN 

Virtual Private Network.

6. References

AEA. AEA Technical Specifications 2007. AEA, 2007.

IATA. Common Use Self Service (CUSS).

IATA. Passenger Services Conference Manual.

ICAO. Document 9303: Machine Readable Travel Documents. Tech. Rep.

Filing Period: Effective Date:

1 March - 1 June 2012

13 April 2012