Data Application for Ticketing Fees - Validating Carrier Record S4

DATA APPLICATION TICKETING FEES – VALIDATING CARRIER RECORD S4

The information contained in this document is the property of ATPCO. No part of this document may be reproduced, stored in a retrieval system, or transmitted in any form, or by any means; mechanical, photocopying, recording, or otherwise, without the prior written permission of ATPCO. Under the law, copying includes translating into another language or format. Legal action will be taken against any infringement.

DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

Contents

PART 1 – PRICING ...... 4 1. OVERVIEW ...... 4 1.1 Data Requirements ...... 6 1.2 Basic Processing Overview ...... 7 2. DEFINITIONS AND ASSUMPTIONS...... 8 2.1 Definitions ...... 8 2.2 Assumptions ...... 9 3. DETAILED FIELD PROCESSING ...... 10 4. PROCESSING...... 14 4.1 Application of Data for Record S4 ...... 17 4.1.1 Validating Carrier Code (bytes 3-5) ...... 18 4.1.2 Service Type Code (bytes 6-10) ...... 19 4.1.3 MCN (bytes 21-28) ...... 23 4.1.4 Sequence Number (bytes 29-35) ...... 24 4.1.5 Booking Fee Application (byte 36) ...... 25 4.1.6 Public/Private (byte 37) ...... 26 4.1.7 Travel Dates – Effective/Discontinue (bytes 38-49) ...... 27 4.1.8 Ticket Dates – First/Last (bytes 50-61) ...... 28 4.1.9 Passenger Type (bytes 63-65) ...... 29 4.1.10 Account Code Table No. 172 (bytes 71-78) ...... 30 4.1.11 Ticket Designator Table No. 173 (bytes 79-86) ...... 31 4.1.12 Security Table No. 183 (bytes 95-102) ...... 32 4.1.13 Journey Geographic Specification (bytes 111-138) ...... 33 4.1.13.1 Journey Geo Spec – Indicator (byte 111) ...... 35 4.1.13.2 Journey Geo Spec – Loc 1/Loc 2 (bytes 112-129) ...... 37 4.1.13.3 Journey Geo Spec – Loc 3 Travel Wholly Within (bytes 130-138) ...... 39 4.1.13.4 Journey Geo Spec – Loc 4 Via (bytes 139-147) ...... 40 4.1.14 Fare Basis/Frequent Flyer Status (bytes 150-173) ...... 41 4.1.14.1 Indicator (byte 150) ...... 42

Pending Page E.03.S4.001 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

4.1.14.2 Fare Carrier (bytes 151-153) ...... 43 4.1.14.3 Fare Basis/Frequent Flyer Status (bytes 159-173) ...... 45 4.1.15 Form of Payment Bin Number (bytes 176-181) ...... 52 4.1.16 Point of Card Issuance/Country Table No 162 (bytes 182-189) ...... 56 4.1.17 Card Usage (byte 190) ...... 57 4.1.18 Service Type Code – IATA Application Indicators (bytes 210-212) ...... 58 4.1.18.1 Refund/Reissue (byte 210) ...... 58 4.1.18.2 Commission (byte 211) ...... 58 4.1.18.3 Interline Settlement(byte 212) ...... 59 4.1.19 Service Fee (bytes 213-232) ...... 60 4.1.19.1 No Charge (byte 213) ...... 61 4.1.19.2 Specified Fee (bytes 214-224) ...... 63 4.1.19.3 Percent (bytes 225-231) ...... 64 4.1.19.4 Tax Included (byte 232) ...... 72 4.1.20 Maximum Charge (bytes 234-244) ...... 73 4.1.21 Commercial Name (bytes 262-271) ...... 75 5. TRAVEL SEGMENT INDICATORS ...... 76 6. CODING CONVENTIONS ...... 77 6.1 Exemptions/Exceptions ...... 77 6.2 Fare Basis ...... 77 6.3 Debit/credit/charge Card Form of Payment Fees ...... 78 6.4 Multiple account codes ...... 78 PART 2 – TICKETING...... 79 7. POST PRICE PROCESSING ...... 79 7.1 Ticketing ...... 79 7.2 Sales Data Reporting (HOT, CAT, RET, TCN) ...... 82 7.3 Summary of DISH and CAT Changes ...... 86 7.3.1 Net Remit Processing ...... 86 7.4 Ticket Exchange/ Reissue ...... 87 7.5 Electronic Ticket Processing ...... 88 7.5.1 Carrier Fee Data ...... 89

Pending Page E.03.S4.002 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

OVERVIEW OF THIS DOCUMENT

This document contains the data application for both pricing and ticketing of the Ticketing Fees.

Part 1 Details the data application for pricing. Examples are in the document titled Data Application – Examples – Record S4 Ticketing Fees.

Part 2 - Details the data application for ticketing. Examples are included in this document.

Pending Page E.03.S4.003 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

PART 1 – PRICING

1. OVERVIEW Record S4 provides applicable information for fees that are controlled by and accrue to the validating (ticketing) carrier. These fees are not interlineable; however, marketing carrier interline travel is permitted on the tickets that are validated against this record. In the initial release of the product, data in the S4 record applies for initial ticket issuance only and does not apply to revalidated, reissued or exchanged tickets with the exception of sub codes T90-T99 which apply to voluntary reissue tickets only. S4 fees do apply to those tickets that are issued in exchange for a document other than a ticket (e.g., MCO, airline credit voucher, etc.) Ticketing fees (OB fees) are based on the priced itinerary. If a fee is assessed based on data in Record S4, that fee should be reflected on a separate receipt and should not be shown on the face of the ticket.

Note that when used to specify Ticketing Fees (that is, the Service “Tax” Code field is value “OB”), the fields in Record S4 are matched to the ticketing entity without regard to which entity or entities created or modified the PNR or booked any air/train/bus segments.

This document details the data application for Record S4 only. The 100 Series Tables used in this record are Services Record 3s.

Services Record Zone Table No. 178 is based on Automated Rules Zone Table No. 978.

The data application for the following Services Record 100 Series tables (as applicable for Record S4) are contained in separate documents: • Account Code Table No. 172 • Ticket Designator Table No. 173 • Security Table No. 183 NOTE: Processing for Security Table No. 183 is very similar to processing for Automated Rules Security Table No. 983; however, several fields in Table 983 have either been made filler or been redefined for use in Table 183.

Pending Page E.03.S4.004 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

ATPCO assumes that any carrier utilizing Record S4 will ensure that all legal requirements are met regarding any resulting fees.

NOTE: Currently, this document only details the application of data for OB (Ticketing) fees (fees where the “Tax” code in bytes 6-7 is OB). OA (Booking) fees is a future possibility and may be added to the document once the industry reaches agreement on how to process OA fees.

Pending Page E.03.S4.005 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

1.1 Data Requirements In order to validate Record S4, it is essential to know the following:

• Validating carrier • Service being requested/performed • Possible services for which data in this record may apply • Whether the ticket being validated is an original or reissued ticket • Whether voluntary or involuntary reissued ticket • Departure date from the origin of the journey • Ticket issue date • Passenger Type Code • Account Code • Ticket Designator for each priced segment • Fare Basis and associated significant (primary) carrier for each priced segment • Passenger’s frequent flyer status for the Record S4 owning carrier • Whether or not the Record S4 owner’s frequent flyer mileage information is available • Point of sale (to include geographic locations, carrier, GDS, travel agencies, IATA travel agency numbers, department identifiers/codes, ERSP numbers, CRT address, and duty function code) • All ticketed points on the journey • Form of payment • Card’s BIN (first 6 digits of the debit/credit/charge card that is being used for payment) • Card Type (e.g. debit, credit being used for payment) as validated in the BIN subscription product • Amount being charged to each debit/credit/charge card form of payment • Card’s country of issuance • Card’s usage type (personal or business card)

Pending Page E.03.S4.006 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

1.2 Basic Processing Overview

Validation of Record S4 takes place after determination of Validating Carrier (as defined in the Service Fees Overview document) and after pricing of fare, taxes and all other fees is complete for original issue tickets/ reissue tickets (sub codes T90-T99 only)

Process Record S4 for the Validating Carrier. Determine which S4 Records to interrogate based on the Sub-code matching process. - For reissued tickets, process only sub codes T90-T99. - For form of payment sub-codes (FC or FD types), the card’s BIN must be processed first against the BIN answer table (Record A01) to determine which form of payment sub code to interrogate. Do any S4 records require interrogation?

Yes No

Attempt to match Record S4 (based on the match criteria) for each and every applicable unique Service Type Code (“Tax” Code and Sub Code combination). Is there a match?

Yes No

Apply the fee for the matched Service Type No fee applies for the Service Type Code (Tax Code and Sub-code) being Code (Tax Code and Sub-code). Continue No validating carrier fee processed. Continue processing to processing to another Record S4 with a applies for the ticket. different Tax Code and/or Sub-code another Record S4 with a different Tax Code and/or Sub-code

Pending Page E.03.S4.007 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

2. DEFINITIONS AND ASSUMPTIONS

The Record S4 fields have an AND relationship and all need to be validated in order to ascertain a match to the Record S4 sequence.

2.1 Definitions Term Definition Base Fare The amount that appears in the “fare” portion of the Fare Box on the ticket. This amount excludes amounts in any other boxes on the ticket. Booking Transaction One or more air segments booked (added) into a PNR resulting in a passenger initiated saved itinerary change. Includes “change segment” transactions (internal cancel and rebook). Does not include segment cancel transactions, schedule changes, or involuntary reroute transactions.

Destination Ultimate stopping place of the journey as shown on the ticket (the last airport listed in the “good for passage” portion of the ticket). Journey Turnaround The furthest intermediate stopover or fare break point on the journey, measured from journey origin. NOTE: Determination of whether a point is a stopover or fare break point is based on the designation in the fare calculation. NOTE: Journey Turnaround is a single point as defined above. Should the same city/airport occur more than once as ticketed points in the journey and one of them qualifies as the Journey Turnaround then all other are treated as VIA locations. One Way Journey When the journey is wholly domestic (all ticketed points on the journey are in the same country), then a OW journey is a journey where the destination point of the journey is not in the same point (same city) as the origin point of the journey. When the journey is international (at least two ticketed points are in different countries), then a OW journey is a journey where the destination point of the journey is not in the same country as the origin point of the journey. Round Trip Journey When the journey is wholly domestic (all ticketed points on the journey are in the same country), then a RT journey is a journey where the destination point of the journey is the same point (same city) as the origin point of the journey. When the journey is international (at least two ticketed points are in different countries), then a RT

Pending Page E.03.S4.008 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

Term Definition journey is a journey where the destination point of the journey is in the same country as the origin point of the journey. NOTE: A ticket consisting of a circle pacific or Round the World fare component is considered a Round Trip journey when the fare component destination is in the same country as the fare component origin. Service Type Code A code identifying the service for which a fee will be assessed. This code is made up of a generic “tax” (service) code and a more specific Sub-code to further define the service. Significant/Primary Carrier The marketing carrier on the governing/primary sector associated to the fare basis specified in this record. Travel Agency Any online or “brick and mortar” business entity that is recognized as a travel agency by the system processing the S4 records. Validate Compare. When used in this document to describe how to process the data, the term “validate” means to compare. For example, “validate the data against the ticket being processed” means to compare the data against the ticket being processed. Validating Carrier The carrier whose ticket stock was used to issue the ticket (plating carrier). This carrier is commonly the holder of the money for the ticket.

2.2 Assumptions If processing cannot resolve to an applicable Record S4 for the validating carrier on the ticket being processed, then the assumption is that there are no Ticketing Feesapplicable to that ticket for any Service Type Code (“Tax” Code and Sub-code).

Once processing resolves to an applicable Record S4, the fee specified in the record applies to the ticket. Once a sequence is matched for the journey and applied to the ticket, processing is complete for the Carrier / OB/ sub-code and does not read on, or attempt to find another sequence within the sub-code for this ticket.

Currently, data in the Record S4 only applies for initial ticket issuance and does not apply to revalidated, reissued or exchanged tickets. Exception to this are sub codes T90-T99 which apply to voluntary reissue tickets and do not apply to initial ticket issuance.

Pending Page E.03.S4.009 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

3. DETAILED FIELD PROCESSING

Byte Location Match / Action Definition / Processing Bytes 1-2 Key Match Indicates the Record Number for which the data is formatted. Record Type Bytes 3-5 Key Match Specifies the validating carrier. This is the carrier that owns and controls the Validating Carrier Code record. Bytes 6-10 Key Match/ Specifies the “Tax” Code and Sub-code applicable to this record. Service Type Code Match Bytes 12-20 N/A Filler Bytes 21-28 Action Indicates the subscription unit of work. This is used for data base maintenance MCN only. Bytes 29-35 Key Match/ Specifies the order in which the records must be processed within each unique Sequence Number Action “Tax” Code and Sub-code combination Byte 36 Match/Action Blank for OB. Booking Fee Application Byte 37 Action Specifies whether the data in the record is public or private for ATPCO Public/Private distribution and viewership. Bytes 38-49 Match Specify the first and last travel dates for which this record is effective. Travel Dates (Eff/Disc) Bytes 50-61 Match Specify the first and last ticketing dates for which the data in this record applies. Ticket Dates Byte 62 N/A Filler Bytes 63-65 Match Indicates that the data in this record only applies for the specified passenger type. Passenger Type Code Bytes 66-70 N/A Passenger – Filler

Pending Page E.03.S4.010 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

Byte Location Match / Action Definition / Processing Bytes 71-78 Match A table containing the Account Code(s) for which the record is applicable Account Code Table No. 172 Bytes 79-86 Match A table containing the qualifying Ticket Designator(s) for which the record is Ticket Designator Table No. applicable 173 Bytes 87-94 N/A Filler Bytes 95-102 Match A table containing the point of sale location(s) for which the record is applicable Security Table No. 183 Bytes 103-110 N/A Filler Byte 111 Match/Action Specifies whether the data in the following Loc 1 field identifies a journey origin Journey Geo Spec – Indicator or turnaround/destination point. Bytes 112-129 Match Indicates that the data in this record only applies when the journey origin and/or Journey Geo Spec – turnaround/destination points are in the specified location(s). Loc 1/Loc 2 Bytes 130-138 Match Indicates that the data in this record only applies when all ticketed points on the Journey Geo Spec – journey are wholly within the specified location(s). Travel Wholly Within Bytes 139-147 Match Indicates that travel between Loc 1 and Loc 2 must be via a specified location. Journey Geo Spec – Via Bytes 148-149 N/A Journey Geo Spec – Filler Byte 150 Match/Action Specifies whether the data in the Fare Carrier field (bytes 151-153) and Fare Fare Basis – Indicator Basis/Frequent Flyer Status field (byte 159-173) must match against every sector of the ticket or at least one sector of the ticket or whether the data in Fare Basis field/Freq Flyer Status (bytes 159-173) is a frequent flyer status.

Pending Page E.03.S4.011 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

Byte Location Match / Action Definition / Processing Bytes 151-153 Match The 2-character alpha-numeric carrier code specifying the significant (primary) Fare Carrier carrier of the fare basis in the Fare Basis field. When this field is value blank, the significant (primary) carrier must be the Validating Carrier code in bytes 3-5. Bytes 154-158 N/A Filler Bytes 159-173 Match Depending on the value of the Fare Basis – Indicator (byte 150), specifies the Fare Basis/Frequent Flyer Fare Basis or Frequent Flyer status of the passenger as defined by the Record S4 Status owner.. Bytes 174-175 N/A Filler Bytes 176-181 Match Indicate that the data in this record only applies when the ticket is being Form of Payment Bin Number purchased using a debit/credit/charge card that has the specified bin number. Bytes 182-189 Match Indicates that the data in this record only applies when the payment card is issued Point of Issuance/Country in any one of the listed countries. Table Number Byte 190 Match Indicates that the data in this record only applies when the form of payment is Card Usage either a personal credit/debit card (value “P”) or a corporate/business card (value “C”). Bytes 191-202 N/A Filler Bytes 203-209 N/A Identifies the user that submitted the batch for processing and the associated batch Batch ID/Number number. Bytes 210-212 Action Identifies whether the fee for the Service Type Code is refundable, Service Type Code – IATA commissionable, and/or interlineable. Applies to all tickets. Application Indicators Byte 213 Action Indicates there are no service fee charges applicable to the ticket matching this No Charge record. Bytes 214-224 Action Identifies a specified fee applicable to the ticket that matches this record. Service Fee Amount/Currency/Decimal

Pending Page E.03.S4.012 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

Byte Location Match / Action Definition / Processing Bytes 225-231 Action Identifies that the fee applicable to the ticket is a percentage of the amount Service Fee – Percent charged to a debit/credit/charge card form of payment or the amount of the base fare on the ticket, depending upon the Service Type. Byte 232 Action Specifies whether or not the fee includes sales and value added taxes. Tax Included Bytes 233 N/A Filler Bytes 234-244 Action Indicates that when the fee for this record is expressed as a Percent, the fee must Maximum Charge – be no higher than the amount expressed in the Maximum Charge fields. Amount/Currency/Decimal Bytes 245-251 N/A Maximum Charge – Filler Bytes 252-261 N/A Filler Bytes 262-271 Action Indicates a Commercial Name applicable to the Service Type Code in the record. Commercial Name The information in the field is for display purposes only. Bytes 272-281 N/A Filler

Pending Page E.03.S4.013 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

4. PROCESSING Processing validates each original issue ticket/voluntary reissue ticket against the Ticketing Fees Record Records are read in low to high sequence order within carrier and Service Type Code (“Tax” Code and Sub-code). Processing will attempt to match a record based on the match fields identified in the previous section. The relationship among all match fields is AND. Processing must match all match criteria in order to match the record.

For each passenger’s ticket in a PNR, processing must attempt to match data in Record S4. When multiple tickets exist for a passenger in a single Passenger Name Record (PNR) involve conjunctive tickets issued due to an itinerary requiring more than 4 coupons, data in Record S4 is only processed for the first ticket issued for each passenger. In all other cases involving the issuance of multiple tickets for a single passenger, each ticket must be processed against Record S4.

Example 1: Two passengers in the same PNR with multiple tickets on multiple validating carriers • 4 tickets are issued for Passenger A: 2 validated on carrier XX and 2 validated on carrier ZZ - Each set of two tickets are conjunctive due to that portion of the itinerary requiring more 4 coupons • 4 tickets are issued for Passenger B: 2 validated on carrier XX and 2 validated on carrier ZZ - Each set of two tickets are conjunctive due to that portion of the itinerary requiring more 4 coupons

Result: Process Record S4 only for the following tickets: • 1st ticket issued for Passenger A validated on carrier XX • 1st ticket issued for Passenger A validated on carrier ZZ • 1st ticket issued for Passenger B validated on carrier XX • 1st ticket issued for Passenger B validated on carrier ZZ

When processing each passenger ticket against S4, all information relative to the ticket must be known including all forms of payments used.

The following processing applies for each passenger’s first ticket per validating carrier: 1. Process Record S4s in sequential order within each unique Carrier-Service Type Code (defined as both the “Tax” code and Sub- code)

Pending Page E.03.S4.014 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

a. If the ticket being validated matches a Record S4 for a Service Type Code: i. Apply the service fee data in the matched record. Do not continue processing to any other records with the same Service Type Code. ii. Continue processing other Record S4s with a different Service Type Code. b. If the ticket being validated does not match a Record S4 for the Service Type Code: i. No service fee applies for that Service Type Code. ii. Continue processing other Record S4s with a different Service Type Code. 2. Once processing has attempted to match Record S4s for every unique Service Type Code for the validating carrier, apply all applicable service fees to the ticket being validated.

Example 2: • 2 tickets are issued for Passenger A: both are validated on carrier XX and the itinerary could have been on one ticket. Result: Process Record S4 for each ticket: • 1st ticket issued for Passenger A validated on carrier XX • 2nd ticket issued for Passenger A validated on carrier XX

When processing each passenger ticket against S4, all information relative to the ticket must be known including all forms of payments used.

The following processing applies for each ticket on carrier XX: 1. Process Record S4s in sequential order within each unique Carrier-Service Type Code (defined as both the “Tax” code and Sub- code) a. If the ticket being validated matches a Record S4 for a Service Type Code: i. Apply the service fee data in the matched record. Do not continue processing to any other records with the same Service Type Code. ii. Continue processing other Record S4s with a different Service Type Code. b. If the ticket being validated does not match a Record S4 for the Service Type Code: i. No service fee applies for that Service Type Code. ii. Continue processing other Record S4s with a different Service Type Code.

Pending Page E.03.S4.015 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

2. Once processing has attempted to match Record S4s for every unique Service Type Code for the validating carrier, apply all applicable service fees to the ticket being validated.

Open Sectors When open sectors exist, these sectors will be validated against Record S4. Processing will validate as much information as possible (which may include geographic data and dates) and may apply a fee if there is enough information to ascertain that the fee would apply when the sector is confirmed. Note that open sectors do not include ARNKs. ARNKs are not processed against Record S4.

Surface/ARNK Sectors Surface sectors can be either embedded surface sectors or fare construction surface sectors. Only those surface sectors that are embedded and marked in the fare calculation area as a transfer are not used in the determination of the journey destination or journey turnaround point.

For the journey LON CPH ….MMA STO with a surface between CPH and MMA The fare calculation is: LON X/CPH X/MMA STO

Neither CPH nor MMA is used to determine journey destination or turn around point.

Pending Page E.03.S4.016 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

4.1 Application of Data for Record S4 This section provides a detailed explanation of the data application for each field in Record S4. Refer to the Data Application – Examples – Record S4 Ticketing Fees document for examples illustrating the data application.

The section numbers for the fields below match the corresponding section numbers for the fields in the Data Application – Examples – Record S4 Ticketing Fees document.

Pending Page E.03.S4.017 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

4.1.1 Validating Carrier Code (bytes 3-5) This field specifies the owner of the Ticketing Fee. Only codes found in the IATA Airline Code Directory are permitted. If the validating carrier for the ticket (the first three digits of the resulting ticket number translated to the two-digit alphanumeric carrier code) matches the Validating Carrier Code in bytes 3-5, then processing matches the record (provided a match is also made to all other match fields). If the validating carrier for the ticket does not match the Validating Carrier Code in bytes 3-5, then processing no matches the record and continues to the next record.

Permitted values in this field are the standard industry alpha-numeric airline designator values. They are not the airline “stock” codes. (For example, for American Airlines, the value in this field will be AA and will not be 001.)

Refer to the Service Fees Overview document for Validating Carrier default selection logic.

Refer to the example(s) under this same section number in the Data Application – Examples – Record S4 Ticketing Fees document.

Note: When a BSP airline acting as the General Sales Agent (GSA) is selected as the validating carrier, then the GSA is considered the validating carrier for the purposes of matching the data in bytes 3-5. The airline on whose behalf the GSA is acting is not considered the validating carrier.

Pending Page E.03.S4.018 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

4.1.2 Service Type Code (bytes 6-10) The Service Type fields consist of the following: Field Explanation Applicable Values Service “Tax” Code High-level identification of the type of service OB = Ticketing fee

Sub-code Specific identification of the type of fee applicable to this Refer to the ATPCO Services Sub-code record. The Sub-code further defines the Service “Tax” Code. Appendix

The definition of the Service “Tax” Code and Sub-code are industry defined. That is, like Fare Types, a code is established per one carrier’s request, after which it can be used by all carriers.

Processing must match the Sub-code definition in order to match the record. The list of valid Sub-codes and their definition is provided in the ATPCO Services Sub-Code Appendix B. Below is detailed explanation on matching Sub Codes.

Matching “OB” Sub Codes

There will be three types of fees for OB; (1) Form of payment, (2) Ticketing charges, and (3) Requested Services. The first character of the Sub Code will identify the type of fee. “F” = Form of payment “T” = Ticketing fee “R” = Requested Service

The second and third characters will vary depending on whether the Sub Code is an F type, T type, or R type.

If the Sub Code is a T type, the combination of the second and third character uniquely defines the Sub Code which can be numeric, numeric/alpha, or alpha/numeric. The second and third characters have no defined ATPCO-meaning. If the carrier’s S4 data consists of more than one Ticketing Fee Type Sub Codes, the process must attempt to match a sequence from each unique T Type Sub Code. The T type sub codes are automatic match and processing must read each unique T type sub code independently. When a sequence match is found within the current Sub code being processed apply the fee of matching sequence then continue processing sequences of next unique Ticketing Fee Type Sub Code.

Pending Page E.03.S4.019 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

Ticketing Fee Type Sub Code Example: 1) Carrier XX has a T01 sequence that specifies a fee when ticket is sold in GB Carrier XX has a T02 sequence that specifies a fee when ticket is sold in GB by a travel agent.

An XX ticket sold in GB by a travel agent will match both T01 and T02 sub codes and apply both charges subject to other conditions present in the sequence.

2) Carrier XX has a T90 sequence that specifies a reissue ticket fee when ticket is sold in GB

A reissued XX ticket sold in GB will match T90 sub code subject to other conditions present in the sequence.

If the Sub Code is an F type, the second character shall either be a letter “C” which means credit card or charge cardor “D” which means debit card. Processing must determine if the card is to be processed as a debit or credit by validating the card’s BIN against the Bin Table(Record A01). If a system identifies the card’s BIN as debit then it will match “D”. Otherwise, if the card type is not debit(BIN’s card type is either C(Credit), G(Charge), Blank(Unknown)) or if the BIN does not exist in the BIN table, then it shall be processed as a credit, therefore match “C”. The third character shall be a numeric defining the first number of the card or a letter “A” that signifies any numbered debit/credit/charge card. The bin number in the S4 record will be utilized to further define the specific credit card/debit card fee such as MasterCard or Bank of America Visa.

Form of Payment Type Sub Code Example:

According to the BIN Table Record A01, the following BINs have these types:

BIN Type Bytes 4-9 Byte 40 ------412345 D 542310 D 474478 D 475569 C

Pending Page E.03.S4.020 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

1) Carrier XX has an FC4 sequence that specifies a fee for tickets purchased using credit card with a number starting with “4” and they also have an FDA sequence that specifies a fee for tickets purchased using any debit card.

An XX ticket was purchased using a Visa card number 4744 7800 1234 5678. System determines from the BIN Table Record A01 that the card’s BIN 474478 is of type Debit and process the FDA sequence. No match FC4.

An XX ticket was purchased using a Visa card number 4755 6900 1234 5678. System determines that this card is of type Credit because the A01 record indicates that this BIN is not debit, therefore process FC4. No match FDA.

An XX ticket was purchased using a Master card number 5423 1000 1234 5678. System determines that this card is of type Credit because there was no matching A01 record for BIN 542310. FC4 sequences will not be processed since the card does not start with “4”. Do not process FDA.

2) Carrier ZZ has an FD4 sequence that specifies a fee for tickets purchased using debit card with a number starting with “4” and they also have an FCA sequence that specifies a fee for tickets purchased with any credit card.

A ZZ ticket was purchased using a Visa card number 4744 7800 1234 5678. System determines from the BIN Table Record A01 that the card’s BIN 474478 is of type Debit, therefore, process the FD4 sequence. No match FCA.

A ZZ ticket was purchased using a Visa card number 4755 6900 1234 5678. System determines that this card is of type Credit because the A01 record indicates that this BIN is not debit, therefore process the FCA sequence. No match FD4.

A ZZ ticket was purchased using a Master card number 5423 1000 1234 5678. System determines that this card is of type Credit because there was no matching A01 record for BIN 542310. FC4 sequences will not be processed since the card does not start with “4”. No match FDA.

Pending Page E.03.S4.021 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

If the Sub Code is an R type, the charge is for a Requested Service such as Overnight Delivery, Courrier Service, Paper Tickets, or some other service that is being requested for the passenger. Each R type sub code is uniquely defined (see Appendix B). The Requested Sub Code types are only interrogated for application when the input command (i.e. agent entry, webpage entry, etcetera) specifies the Sub Code. R-type Sub Codes are match criteria to the type of service being requested on the input command, and do not necessarily reflect the actual services delivered. Charges for multiple Requested Services may be collected for a single ticket.

Requested Services Type Sub Code Example:

Carrier XX has an R01 sequence specifying that a charge will be applied for the requested service of an Overnight Delivery. Carrier XX has an R05 sequence specifying that a charge will be applied for a paper ticket being issued.

An XX ticket where overnight delivery was requested for a paper ticket (also a requested service) will match carrier XX sequences R01 and R05. Both charges will be applied to the ticket.

Resulting Service Type Code Once processing matches a Record S4 and applies any applicable fee, the resulting Service Type Code consists of the data in the “Tax” Code (bytes 6-7) and Sub Code (bytes 8-10). The resulting Service Type Code or textual translations may appear on the face of the receipt. For BSP (non-US Travel Agency) reporting, with the implementation of Version 20.1 of the Data Interchange Standards Handbook (DISH), the Sub Code will be reported in bytes 3-5 of the Tax Miscellaneous Fee Type field (TMFT) with the corresponding amount in the following Tax Miscellaneous Fee Amount field (TMFA). Prior to implementation of Version 20.1, only the 2 alphanumeric code of the ticketing fee will appear in this field for reporting purposes.

The same standards are expected to be used for the ARC CAT, RET, SPRF, and TCN/ISR files. These other sales data sources will also require the same upgrade as the move to Version 20.1 described above, although note that this is not a dependency for the implementation of the S4 record

Refer to the example(s) under this same section number in the Data Application – Examples – Record S4 Ticketing Fees document.

Pending Page E.03.S4.022 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

4.1.3 MCN (bytes 21-28) The Maintenance Control Number (MCN) indicates the subscription unit of work and is used for database maintenance only.

Pending Page E.03.S4.023 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

4.1.4 Sequence Number (bytes 29-35) This field specifies the order in which the records should be read within each unique Service Type Code (defined as both the Service “Tax” Code and Sub-code). Once a match is made to a sequence, processing will apply the data in the sequence and will not read on to another sequence for the same unique Service Type Code (Service “Tax” Code and Sub-code) for the ticket being validated. Processing will continue to other sequences with a different Service Type Code (different Service “Tax” Code and/or Sub-code) for the ticket being validated.

Refer to the example(s) under this same section number in the Data Application – Examples – Record S4 Ticketing Fees document.

Pending Page E.03.S4.024 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

4.1.5 Booking Fee Application (byte 36) This field only applies for OA (Booking) fees and is not applicable for OB (Ticketing) fees. The data application for this field will be documented once the industry agrees upon OA fee processing.

Pending Page E.03.S4.025 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

4.1.6 Public/Private (byte 37) This field specifies that the data in the record is public or private for the purposes of ATPCO data distribution and subscriber (e.g., GDS) display. Following is an explanation of the applicable values:

Value blank: Specifies that the data in the record is public. • Distribution: there are no restrictions on ATPCO data distribution. ATPCO will distribute the data to any subscriber who requests to receive the data. • Display: there are no restrictions on the locations/entities the subscriber permits to display the data. Subscribers can permit anyone with access to their system to display the data.

Value P: Specifies that the data in the record is private. • Distribution: there are restrictions on ATPCO data distribution. ATPCO will only distribute the data to subscribers that the Record S4 owner (validating carrier specified in bytes 3-5) specifically authorizes to receive the data. • Display: there are restrictions on the locations/entities the subscriber permits to display the data. Subscribers will only permit the record owning carrier (Validating Carrier, byte 3-5) and the locations/entities specified in Security Table 183 (bytes 95-102) to display the data.

Refer to the example(s) under this same section number in the Data Application – Examples – Record S4 Ticketing Fees document.

Pending Page E.03.S4.026 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

4.1.7 Travel Dates – Effective/Discontinue (bytes 38-49) These fields are the standard ATPCO record Effective and Discontinue dates and specify the First and/or Last Travel Dates for the record. Processing matches these dates against the departure date from the origin of the journey. If the departure date from the origin of the journey is within the specified dates, then processing matches the record (provided a match is also made to all other match fields). If the departure date from the origin of the journey is not within the specified dates, then processing no matches the record and continues to the next record.

A date will always be present in the First Travel (Effective) Date field (bytes 38-43). The Last Travel (Discontinue) Date field (bytes 44-49) may contain a specific date or may contain 999999 signifying there is no restriction on the Last Travel (Discontinue) date (subject to the remaining data within the record).

Refer to the example(s) under this same section number in the Data Application – Examples – Record S4 Ticketing Fees document.

Pending Page E.03.S4.027 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

4.1.8 Ticket Dates – First/Last (bytes 50-61) These fields specify the First and/or Last Ticket Dates for the record. Validation of these dates is against the ticket issue date for the ticket being processed against the record. (Note that data in this record is only applicable for initial ticket issuance and is not applicable for reissued tickets). If the ticket issue date is within the specified dates on the S4 record, then processing matches the record (provided a match is also made to all other match fields). If the ticket issue date is not within the specified dates, then processing no matches the record and continues to the next record.

Value 999999 may be present in either or both of these fields and signifies there is no restriction on the First and/or Last Ticket date respectively allowing the record to be matched regardless of the ticket issue date (subject to the remaining data within the record).

If the First Ticket Date field (bytes 50-55) is value 999999, then the date of data receipt is the first date on which the ticket can be issued in order to match the record. If the Last Ticket Date field (bytes 56-61) is value 999999, then the date, if one exists, in Last Travel Date field (bytes 44-49) also serves as the last date on which a ticket can be issued in order to match the record.

Refer to the example(s) under this same section number in the Data Application – Examples – Record S4 Ticketing Fees document.

Pending Page E.03.S4.028 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

4.1.9 Passenger Type (bytes 63-65) This field specifies the Passenger Type Code (PTC) required to match the record. Validation of this field is against the passenger type in the input command that priced the ticket (the requested passenger type). It is also matched against the data stored as part of the passenger’s requested qualifying information and is not matched against the actual fare. If the data in this field matches the ticketed (requested) passenger, then processing matches the record (provided a match is also made to all other match fields). If data in this field does not match the ticketed (requested) passenger, then processing no matches the record and continues to the next record.

PTC mapping applies. The ticketed (requested) PTC must be within the confines (map up to) the PTC on the Record S4 being processed. For example, Record S4 value CNN matches to any child/infant passenger type on the input command. Edits prevent PTC ADT in this field.

When this field is value Blank, there are no passenger type requirements for the application of the fee being processed; the fee applies to all passenger types (subject to the remaining data within the record). All PTCs match (map up to) value Blank in Record S4.

Refer to the example(s) under this same section number in the Data Application – Examples – Record S4 Ticketing Fees document.

Pending Page E.03.S4.029 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

4.1.10 Account Code Table No. 172 (bytes 71-78)

When Service “Tax” Code (bytes 6-7) is value “OB’, Account Code Table No. 172 specifies the Account Code(s) that must be used in the pricing or combined pricing/ticketing command in order to match the S4 Record.

When Table 172 is a value greater than 00000000, process Table 172 according to the Data Application – Table 172 – Account Code Table document. The single account code or any of the multiple account codes used in the pricing or combined pricing/ticketing command must match at least one occurrence of the specified Table ID and Table Number in order to match the Record S4. If the single account code or any of the multiple account codes on the input command matches at least one occurrence of the Table 172 Table Number, then processing matches the record (provided a match is also made to all other match criteria). If the single account code or all of the multiple account codes on the input command do not match at least one occurrence of the Table 172 Table Number, then processing no matches the record. The multiple account codes can be processed in any order.

When Table 172 is value 0000000 there are no Account Code restrictions for the Record S4 being processed (subject to the remaining match criteria in the record). Data in this field matches to an input command with any Account Code(s) or matches to an input command with no Account Codes present.

Refer to the Data Application – Table 172 – Account Code Table document for details. Refer to the example(s) under this same section number in the Data Application – Examples – Record S4 Ticketing Fees document.

Pending Page E.03.S4.030 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

4.1.11 Ticket Designator Table No. 173 (bytes 79-86)

When Service “Tax” Code (bytes 6-7) is value “OB’, Ticket Designator Table No. 173 specifies the Ticket Designator(s) that must be used in the pricing or combined pricing/ticketing command in order to match the S4 Record.

When Table 173 is a value greater than 00000000, process Table 173 according to the Data Application – Table 173 – Ticket Designator Table document. The Ticket Designator used on the pricing or combined pricing/ticketing command must match at least one occurrence of the specified Table ID and Table Number in order to match the Record S4. If the Ticket Designator on the input command matches at least one occurrence of the Table 173 Table Number, then processing matches the record (provided a match is also made to all other match criteria). If the Ticket Designator on the input command does not match at least one occurrence of the Table 173 Table Number, then processing no matches the record.

When Table 173 is value 0000000 there are no Ticket Designator restrictions for the Record S4 being processed (subject to the remaining match criteria in the record). Data in this field matches to an input command with any Ticket Designator(s) or matches to an input command with no Ticket Designators present

Refer to the Data Application – Table 173 – Ticket Designator Table document for details.

Refer to the example(s) under this same section number in the Data Application – Examples – Record S4 Ticketing Fees document.

Pending Page E.03.S4.031 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

4.1.12 Security Table No. 183 (bytes 95-102) When Service “Tax” Code (bytes 6-7) is value “OB’, Security Table No. 183 specifies at which locations sale occurs in order to match the record. Refer to Data Application – Security Table No. 183 for details.

When Table 183 is a value greater than 00000000, process Table 183 according to the Data Application – Security Table No. 183 document. Processing will attempt to match the sales location to determine a match to the Record S4. If the sales location matches at least one of the referenced Table 183 records, then processing matches the S4 record (provided a match is also made to all other match criteria). If the sales location does not match any of the referenced Table 183 records , then processing no matches the S4 record. NOTE: For Record S4, edits require that Table 183 View/Book/Ticket byte 49 be value 1 specifiying that the location that matches Table 183 is the display and sales location. Note that if a public S4 record has a Table 183, display data from Table 183 but sales location is restricted to the information specified in Table 183.

When Table 183 is value 00000000, there are no restrictions on the sales location. Processing will match the record for any sales location (provided a match is also made to all other match criteria).

Refer to the Data Application – Security Table No. 183 document for details.

Refer to the example(s) under this same section number in the Data Application – Examples – Record S4 Ticketing Fees document.

Pending Page E.03.S4.032 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

4.1.13 Journey Geographic Specification (bytes 111-138) The Journey Geographic Specification fields consist of the following fields: • Indicator (byte 111) • Loc 1 – Journey Origin or Journey Turnaround/Destination Point (bytes 112-120) • Loc 2 – Journey Origin or Journey Turnaround/Destination Point (bytes 121-129) • Loc 3 – Travel Wholly Within (bytes 130-138) • Loc 4 – Travel Via Loc (bytes 139-147)

These fields identify the geographic restrictions for the journey which must be met in order to match the Record S4. Validation of these fields is against the entire journey (inbound and outbound travel). The relationship among the Journey Geographic Specification fields is AND. Processing must match all conditions in order to match the record.

Loc1(bytes 112-120) and Loc2(bytes 121-129) specify the journey origin and turnaround/destination points (depending upon whether the journey is RT or OW). Data in the Indicator field (byte 111) specifies whether Loc 1 is a journey origin point or either a journey origin or turnaround/destination point.

Pending Page E.03.S4.033 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

The journey turnaround point is defined as the furthest stopover or fare break point, measured from the origin of the journey. Processing should measure using the following steps:

• Measure using the non-stop TPM (Ticketed Point Mileage) between the origin of the journey and the stopover/fare break point. o When a single TPM exists between the points being measured, use the TPM regardless of the global. o When multiple TPMs exist between the points being measured, apply Global direction in determining the correct TPM to use. o When more than one global direction applies to the points being measured, use the highest TPM that applies for one of the global directions.

• If there are no TPMs, calculate TPMs as MPM (Maximum Permitted Mileage) divided by 1.2 (MPM/1.2). o When a single MPM exists between the points being measured, use the MPM regardless of the global. o When multiple MPMs exist between the points being measured, apply Global direction in determining the correct MPM to use. o When more than one global direction applies to the points being measured, use the highest MPM that applies for one of the global directions.

• If MPMs do not exist, use GCM (Great Circle Mileage).

Pending Page E.03.S4.034 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

4.1.13.1 Journey Geo Spec – Indicator (byte 111) This field specifies the journey origin or journey turnaround/destination1 application of the location specified in the following Loc 1 field (bytes 112-120). Following is an explanation of the applicable values:

Value A: Indicates that Loc 1 specifies the journey origin.

When Loc 1 and Loc 2 are present, then Loc 1 validates against the journey origin and Loc 2 validates as follows: • For RT journeys, Loc 2 validates against the journey turnaround • For OW journeys, Loc 2 validates against the journey destination (last point on the ticket).

When Loc 1 is present and Loc 2 is blank, then Loc 1 validates against the journey origin. For RT journeys, there is no restriction on the journey turnaround (subject to the remainder of the data in the record). For OW journeys, there is no restriction on journey destination.

Value Blank: Indicates that Loc 1 specifies either the journey origin or journey turnaround/destination.

When Loc 1 and Loc 2 are present:

For RT journeys, at least one of the following must occur: • Loc 1 must validate against the journey origin and Loc 2 must validate against the journey turnaround OR • Loc 1 must validate against the journey turnaround and Loc 2 must validate against the journey origin

For OW journeys, at least one of the following must occur: • Loc 1 must validate against the journey origin and Loc 2 must validate against the journey destination OR • Loc 1 must validate against the journey destination and Loc 2 must validate against the journey origin

1 Turnaround or destination dependent upon whether the journey is one way or round trip as defined in Section 2.1Definitions, of this document.

Pending Page E.03.S4.035 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

Loc 1 and Loc 2 share a Between/And relationship. If processing is unable to validate Loc 1 against the journey origin and Loc 2 against the journey destination or turnaround, then processing should “flip” the locations and attempt to validate Loc 1 against the journey destination (OW) or turnaround (RT) and Loc 2 against the journey origin.

When Loc 1 is present and Loc 2 is Blank:

For RT journeys, at least one of the following must occur: • Loc 1 must validate against the journey origin and there is no restriction on the journey turnaround OR • Loc 1 must validate against the journey turnaround and there is no restriction on the journey origin

For OW journeys, at least one of the following must occur: • Loc 1 must validate against the journey origin and there is no restriction on the journey destination OR • Loc 1 must validate against the journey destination and there is no restriction on the journey origin Loc 1 has a From/To application. If processing is unable to validate Loc 1 against the journey origin, then processing should attempt to validate Loc 1 against the journey destination (OW) or turnaround (RT).

When Loc 1 and Loc 2 are Blank, there is no restriction on the journey origin and journey destination (OW) or turnaround (RT), subject to the remainder of the data in the record.

Refer to the example(s) under this same section number in the Data Application – Examples – Record S4 Ticketing Fees document.

Pending Page E.03.S4.036 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

4.1.13.2 Journey Geo Spec – Loc 1/Loc 2 (bytes 112-129)

The geographic location data in Loc 1 and Loc 2 may be defined as an Area, Zone, Country, State, City, or via use of User Zone Table No. 178 which permits the specification of multiple locations to create a user defined zone.

When these fields are blank, there are no restrictions on the journey origin and turnaround/destination points, subject to the remainder of the data in the record.

The following charts provide an explanation of the relationship among the values in the Indicator, Loc 1, and Loc 2 fields based on RT and OW Journeys:

For RT Journeys (see definition) Ind Loc 1 data Loc 2 data Loc 1 Validation Loc 2 Validation A Present Present Validate against Journey Origin Validate against Journey Turnaround point A Present Blank Validate against Journey Origin No restriction on Journey Turnaround point Blank Present Present Validate against Journey Origin or Journey Validate against Journey Origin or Journey Turnaround Point as follows: Turnaround Point as follows: a. Validate against Journey Origin a. Validate against Journey Turnaround b. Validate against Journey Turnaround b. Validate against Journey Origin NOTE: If Loc 1 validates against Journey Origin and Loc 2 validates against Journey Turnaround, then Loc 1 and Loc 2 are matched. Otherwise processing should “flip” the locations: If Loc 1 validates against Journey Turnaround, and Loc 2 validates against Journey Origin, then Loc 1 and Loc 2 are matched. Blank Present Blank Validate against Journey Origin or Journey Turnaround Point as follows: a. Validate against Journey Origin a. No restriction on Journey Turnaround point b. Validate against Journey Turnaround b. No restriction on Journey Origin Blank Blank Blank No restriction on Journey Origin or Journey No restriction on Journey Origin or Journey Turnaround point, subject to the remainder of Turnaround point, subject to the remainder of the data in the record the data in the record

Pending Page E.03.S4.037 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

For OW Journeys (see definition) Ind Loc 1 data Loc 2 data Loc 1 Validation Loc 2 Validation A Present Present Validate against Journey Origin Validate against Journey Destination point A Present Blank Validate against Journey Origin No restriction on Journey Destination point Blank Present Present Validate against Journey Origin or Journey Validate against Journey Origin or Journey Destination Point as follows: Destination Point as follows: a. Validate against Journey Origin • Validate against Journey Destination b. Validate against Journey Destination • Validate against Journey Origin NOTE: If Loc 1 validates against Journey Origin and Loc 2 validates against Journey Destination, then Loc 1 and Loc 2 are matched. Otherwise processing should “flip” the locations: If Loc 1 validates against Journey Destination, and Loc 2 validates against Journey Origin, then Loc 1 and Loc 2 are matched. Blank Present Blank Validate against Journey Origin or Journey Destination Point as follows: a. Validate against Journey Origin a. No restriction on Journey Destination point b. Validate against Journey Destination b. No restriction on Journey Origin Blank Blank Blank No restriction on Journey Origin or Journey No restriction on Journey Origin or Journey Destination point, subject to the remainder of Destination point, subject to the remainder of the data in the record the data in the record

Refer to the example(s) under this same section number in the Data Application – Examples – Record S4 Ticketing Fees document.

Pending Page E.03.S4.038 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

4.1.13.3 Journey Geo Spec – Loc 3 Travel Wholly Within (bytes 130-138) This field specifies that all ticketed points on the journey must be within a specified location in order to match the record. Validation is against all ticketed points on the journey, including the journey origin, journey turnaround, and journey destination points. If all ticketed points on the journey match the Travel Wholly Within data, then processing matches the record (provided a match is also made to all other match criteria). If at least one ticketed point on the journey does not match the Travel Wholly Within data, then processing no matches the record and continues to the next record.

The geographic location data may be defined as an Area, Zone, Country, State, or via use of User Zone Table No. 178 which permits the specification of multiple locations to create a user defined zone. Edits will prevent a city or airport code from being entered in this field; however this edit will not be performed on a Table 178. Loc 3 may be coded when Loc 1 is blank or non-blank and when both Loc 1 and Loc 2 are blank or non-blank. Note that ATPCO is not editing the validity of the associated data in Loc 1, Loc 2 and Loc 3. If the data is not logical, then processing will no match the Record S4 and continue to the next record. (For example, it is possible that Loc 1 may be US, Loc 2 may be zone 210 and Loc 3 may be Area 3. This data will result in a no match to the record and processing should continue to the next record.)

This field may contain data when Loc 1 and Loc 2 are blank.

When this field is blank, there are no Travel Wholly Within restrictions on the journey (subject to the remainder of the data in the record.)

Refer to the example(s) under this same section number in the Data Application – Examples – Record S4 Ticketing Fees document.

Pending Page E.03.S4.039 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

4.1.13.4 Journey Geo Spec – Loc 4 Via (bytes 139-147) This field specifies a point that must be on the journey in order to match the record. Validation is against any ticketed point on the journey, with the exception of the journey origin, journey turnaround, and journey destination points. If at least one ticketed point on the journey (other than the journey origin, turnaround, and destination points) matches the Via Loc data, then processing matches the record (provided a match is also made to all other match criteria). If no ticketed point on the journey (other than the journey origin, turnaround, and destination points) matches the Via Loc data, then processing no matches the record and continues to the next record.

When Loc 1, Loc 2, and Loc 4 contain data, then Loc 1 and Loc 2 must match the journey origin and journey turnaround/destination points and Loc 4 must match against at least one ticketed point on the journey excluding the journey origin and turnaround/destination points. Loc 4 does not have to match against a ticketed point on both the outbound and inbound portions of the journey.

Should the journey origin, turnaround and/or destination cities occur in the journey more than once, the cities are considered via points where they are not specifically the journey origin, destination or point of turnaround point.

The geographic location data may be defined as an Area, Zone, Country, State, City, or via use of User Zone Table No. 178 which permits the specification of multiple locations to create a user defined zone.

When this field is blank, there are no Via Loc restrictions on the journey (subject to the remainder of the data in the record.)

Refer to the example(s) under this same section number in the Data Application – Examples – Record S4 Ticketing Fees document.

Pending Page E.03.S4.040 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

4.1.14 Fare Basis/Frequent Flyer Status (bytes 150-173)

The Fare Basis/Frequent Flyer Status fields consist of the following: • Indicator (byte 150) • Fare Carrier (bytes 151-153) • Fare Basis/Frequent Flyer Status (bytes 159-173)

These fields identify a Fare Basis(or any fare basis) and the associated significant (primary) carrier(s) required on the ticket in order to match the record. Alternatively, Indicator(byte 150) and Fare Basis/Frequent Flyer Status(bytes 159-173) fields are used to specify the passenger’s frequent flyer status.

The relationship among the Fare Basis/Frequent Flyer Status (bytes 150-173) fields is AND. Processing must match both the Fare Carrier and the Fare Basis field, as specified by the Indicator field, in order to match the record (subject to the remaining match criteria in the record).

A detailed explanation of each field is provided below.

Pending Page E.03.S4.041 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

4.1.14.1 Indicator (byte 150)

This field specifies whether the data in the Fare Carrier (bytes 151-153) and the Fare Basis/Frequent Flyer Status field (bytes 159- 173) must match against every sector of the ticket or at least one sector of the ticket or whether Fare Basis/Frequent Flyer Status field contains the passenger’s frequent flyer status. Following is an explanation of the applicable values:

Value A: Must match all coupons. In order to match the Record S4, the Fare Carrier and the Fare Basis must match against every coupon of the ticket. If processing matches the Fare Carrier and the Fare Basis against every sector of the ticket, then processing matches the record (provided a match is made to all other match fields). If processing cannot match the Fare Carrier and the Fare Basis against every sector of the ticket, then processing no matches the record.

If the Fare Basis is blank and the Fare Carrier is specified, every sector of the ticket must match the Fare Carrier specified and it can be any fare basis.

Value S: Must match at least one coupon. In order to match the Record S4, the Fare Carrier and the Fare Basis must match against at least one coupon of the ticket. Both must match against the same sector. If processing matches the Fare Carrier and the Fare Basis against at least one sector of the ticket (against the same sector), then processing matches the record (provided a match is made to all other match fields). If processing cannot match the Fare Carrier and the Fare Basis against at least one same sector, then processing no matches the record.

If the Fare Basis is blank and the Fare Carrier is specified, at least one coupon of the ticket must match the Fare Carrier specified and it can be any fare basis.

Value F: Indicates that the value specified in Fare Basis/Frequent Flyer Status field (byte 159-173) is a Frequent Flyer status.

Value Blank: No application.

Refer to the example(s) under this same section number in the Data Application – Examples – Record S4 Ticketing Fees document.

Pending Page E.03.S4.042 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

4.1.14.2 Fare Carrier (bytes 151-153)

This field indicates that the significant carrier (primary carrier) for the Fare Basis in bytes 159-173 must be the Validating Carrier (Record S4 owner) and/or (an)other carrier(s). When the Fare Basis in bytes 159-173 is a joint fare, either carrier involved in the joint fare must match against this field.

Fare Carrier field is value Blank When Fare Carrier (bytes 151-153) is value Blank and data is present in the Fare Basis/Frequent Flyer Status field (bytes 159- 173), then the significant carrier (primary carrier) for the specified Fare Basis must be the Validating Carrier (Record S4 owner). The application is dependent upon the Indicator value in Record S4 byte 150, as follows: • When Indicator byte 150 is value S, then at least one coupon must be the Validating Carrier’s specified fare basis (that is, at least one coupon of the ticket must be on the Fare Basis specified in bytes 159-173 where the significant (primary) carrier of the Fare Basis is the Validating Carrier (Record S4 owner)). • When Indicator byte 150 is value A, then all coupons on the ticket must be the Validating Carrier’s specified Fare Basis (that is, every coupon of the ticket must be on the Fare Basis specified in bytes 159-173 and the significant (primary) carrier for each fare on the ticket must be the Validating Carrier (Record S4 owner)). • When Indicator byte 150 is value F, Fare Carrier field has no application.

When Fare Carrier (bytes 151-153) value Blank and the Fare Basis/Frequent Flyer Status field (bytes 159-173) is value Blank, then there are no restrictions on the Fare Basis and associated significant (primary) carriers on the ticket (subject to the remaining data in the record). (Edits require that Fare Carrier (bytes 151-153) be value Blank when the Fare Basis is value Blank.)

Fare Carrier field is any non-blank value When Fare Carrier (bytes 151-153) is not value Blank, the significant carrier (primary carrier) for the Fare Basis in bytes 159- 173 or any Fare Basis (value blank in Fare Basis bytes 159-173) must be the carrier specified in Fare Carrier (bytes 151-153). The Validating Carrier (Record S4 owner) is not assumed to be a possible significant (primary) carrier and must be specified in Fare Carrier (bytes 151-153) in another Record S4 sequence if the intent is that the Validating Carrier or the carrier specified in the current Record S4 sequence must be the significant carrier.

The application of Fare Carrier (bytes 151-153) is dependent upon the Indicator value in Record S4 byte 150, as follows:

Pending Page E.03.S4.043 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

• When Indicator byte 150 is value S, then at least one coupon of the ticket must meet all of the following criteria: o Must be on the Fare Basis specified in bytes 159-173 or any Fare Basis (value blank in Fare Basis bytes 159-173); and o The significant (primary) carrier for the fare basis must match against the carrier specified in Fare Carrier (bytes 151- 153) • When Indicator byte 150 is value A, then every coupon of the ticket must meet all of the following criteria: o Must be on the Fare Basis specified in bytes 159-173 or any Fare Basis (value blank in Fare Basis bytes 159-173); and o The significant (primary) carrier for each fare on the ticket must match against the carrier specified in Fare Carrier (bytes 151-153). • When Indicator byte 150 is value F, Fare Carrier field has no application.

The method for determining the significant (primary) carrier is not addressed in this document. Determination of the significant (primary) carrier is at the discretion of the pricing system (e.g. systems will determine the significant carrier based upon how they determine the significant carrier for a fare, such as based on IATA resolutions).

Refer to the example(s) under this same section number in the Data Application – Examples – Record S4 Ticketing Fees document.

Pending Page E.03.S4.044 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

4.1.14.3 Fare Basis/Frequent Flyer Status (bytes 159-173) This field identifies any fare basis (value blank) or the resulting Fare Basis/Family or Fare Basis/Family + Ticket Designator combination (the FBTD field on the e-ticket record) or the passenger’s Frequent Flyer status as defined by the Record S4 owning carrier that must be present on the priced/ticketed itinerary in order to match the record. The application of this field is dependent upon the Indicator value in byte 150 as follows:

• When Indicator byte 150 is value S and Fare Basis is not blank, then at least one coupon of the ticket must match the specified Fare Basis (resulting fare must match the Fare Basis Code/Family) and the significant (primary) carrier of the Fare Basis must match the data in Fare Carrier (bytes 151-153) in order to match the record. (Note that when Fare Carrier is value Blank, the significant carrier must be the Validating Carrier.) If there is no coupon of the ticket that matches the Fare Basis and is owned by the carrier specified in Fare Carrier (bytes 151-153) then processing no matches the record.

• When Indicator byte 150 is value A and Fare Basis is not blank, then every coupon of the ticket must match the specified Fare Basis (resulting fare must match the Fare Basis Code/Family) and the significant (primary) carrier for each fare on the ticket must match the data in Fare Carrier (bytes 151-153). (Note that when Fare Carrier (bytes 151-153)is value Blank, the significant carrier must be the Validating Carrier.) If all coupons of the ticket do not match the Fare Basis and/or all fares are not owned by the carrier specified in Fare Carrier (bytes 151-153) (or, if Fare Carrier (bytes 151-153)is value Blank, by the Validating Carrier), then processing no matches the record.

• When Indicator byte 150 is value S and Fare Basis is blank, then at least one coupon of the ticket must be on a fare component with the significant (primary) carrier in Fare Carrier (bytes 151-153) in order to match the record. If there is no coupon of the ticket that has the primary carrier specified in Fare Carrier (bytes 151-153) then processing no matches the record.

• When Indicator byte 150 is value A and Fare Basis is blank, then every coupon of the ticket must be on a fare component with the significant (primary) carrier in Fare Carrier (bytes 151-153) in order to match the record. If all fares of the ticket are not owned by the carrier specified in Fare Carrier (bytes 151-153) then processing no matches the record.

• When Indicator byte 150 is value F, then the value specified in bytes 159-173 is a Frequent Flyer status as defined by the owning carrier of the Record S4. The status is expressed as a “level” where value 1 in the field signifies the highest (e.g. most elite), value 2 signifies the second highest, etc. Data in this field represents the minimum status required to match the record.

Pending Page E.03.S4.045 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

Fare Basis matching

When matching the Fare Basis, processing should first attempt to match to the priced fare basis/ticket designator (match in the pricing system). If this information is unknown, then processing should next attempt to match to the fare basis/ticket designator box on the e- ticket record.

Data in this field is specified as either an exact match to the Fare Basis or Fare Basis + Ticket Designator or as a wildcard match via use of a Hyphen (‘-’) and/or Asterisk (‘*’). If a hyphen and/or asterisk is present, then processing applies the wildcard matching described below. If neither a hyphen nor an asterisk are present, then processing must validate an exact match to the Fare Basis and Ticket Designator.

Wildcard Matching In addition to alphanumerics, the following characters can also be present in bytes 159-173:

Slash (‘/’) Up to two slashes (‘/’) may be present in this field in order to identify ticket designator(s). When a single slash is present, the slash and any alphanumerics following the slash match against the last ticket designator in the Fare Basis (refer to Wildcards below). Match processing for a slash in bytes 159-173 against the Fare Basis is the same as the match processing for an alphanumeric in bytes 159-173 against the Fare Basis. For example, QHXAP/CH in bytes 159- 173 matches QHXAP/CH in the Fare Basis Box, but does not match QHXAPCH in the Fare Basis Box. QHXAP/ID/CH in bytes 159-173 matches QHXAP/ID/CH in the Fare Basis Box, but does not match QHXAPID/CH or QHXAP/CH in the Fare Basis Box. Edits prohibit a slash as the first or last character in the field. NOTE: The presence of two ticket designators may not be supported by all subscribers. Carriers should contact subscribers directly to determine if this is supported.

Hyphen (‘-’) A hyphen is a wildcard value that is used to represent any alphanumeric characters in the fare class portion of the Fare Basis. Processing of the hyphen against the fare class portion is the same as processing the hyphen for the fare family match against Automated Rules Record 2. The hyphen can never be used to match a slash nor used to match the ticket designator/s.

Asterisk (‘*’) An asterisk is a wildcard value that is used to represent any alphanumeric characters in the ticket designator. Up to 2 asterisks are permitted. Edits only permit an Asterisk wildcard in bytes 159-173 when preceded (directly or indirectly) by a Slash. An asterisk is never used to match the fare class portion of the Fare Basis.

Pending Page E.03.S4.046 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

Refer to the rules on the following pages for applying the wildcard match process.

Rules for Applying the Wildcard (Hyphen/Asterisk) Match

• The hyphen will not be used to replace a number when the immediately following or preceding character in the Fare Basis on the ticket is also a number. Examples: B-E70 does not match BE701, BE710 or BE170 BE-70 matches BEX70, BE1X70, but does not match BEX170 B-E70/CH does not match BE701/CH, BE710/CH, or BE170/CH

• When a hyphen is present with no slash, processing will only match Fare Bases that have no ticket designator. Examples: -E70 matches BE70, YNWE70 and Q123E70NR, but does not match BE70/CH, BAP/E70 or BAP/E70/CH Q-CH matches QAPCH, but does not match Q/CH, QAPCH/ID90, and QAP/CH Q- matches QAP7 but does not match QAP7/ID90, Q/CH, and QAP/CH

• The hyphen represents any single or consecutive alphanumeric string, except a slash Examples: -CH matches QEECH, but does not match YAPCH/ABC or QEE/CH -E70/CH matches BE70/CH and Q123E70/CH, but does not match YAP/E70/CH or YAP/BE70/CH -/CH matches QEE7M/CH, but does not match QEE, QEE//CH, QEE/ABC/CH, or QEECH Q-/CH matches QAP7/CH, but does not match QAP/ID90/CH or QAPCH B-AP/CH matches BXAP/CH and BH123AP/CH, but does not match BXNR/AP/CH

In addition to the above rules, the following rules apply for hyphens:

• When the hyphen is in the beginning of an alphanumeric string: If there is no slash: o There is an assumed hyphen at the end. Example: –E70 matches BE70NR and BE70NR50, but does not match BAP/E70NR or BE70NR/CH o The hyphen must be replaced with at least one character and cannot be left blank Example: –HE70 does not match HE70NR

Pending Page E.03.S4.047 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

If there is at least one slash: o There is an assumed hyphen at the end, but prior to the slash. Example: –E70/CH matches BE70NR/CH but does not match BE70/CH33, BE70NR//CH, or BE70N4/ABC/CH

o The hyphen must be replaced with at least one character and cannot be left blank Example: –HE70/CH does not match HE70NR/CH

• When the hyphen is in the middle of an alphanumeric string: If there is no slash: o There is an assumed hyphen at the end. Example: Q-AP matches QHXAP and QHXAPCH, but does not match QHEE/AP, QHAP/CH, or QEE/AP/CH o The hyphen does not have to be replaced by any characters. Example: Y-AP matches YAP and YHXAP

If there is a slash: o There is an assumed hyphen at the end, but prior to the slash. Example: Q-AP/CH matches QHXAP7M/CH but does not match QHAP/ID/CH or QAPNR/CH33 o The hyphen does not have to be replaced by any characters. Example: Y-AP/CH matches YAP/CH and YHXAP/CH

• When the hyphen is at the end of an alphanumeric string: If there is no slash: o The hyphen does not have to be replaced by any characters. Example: Y- matches Y and YR

If there is a slash: o The hyphen does not have to be replaced by any characters. Example: Y-/CH matches Y/CH and YR/CH

Pending Page E.03.S4.048 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

• When a single slash is present with no asterisk, the slash and all characters after the last slash are an exact match to the ticket designator. There is no implied wildcard at the end. Example: –AP/CH matches QAPNR/CH but does not match QAPNR/CH33 or QAPNR/ID/CH

• When two slashes are present, the last slash and all characters after the last slash are an exact match to the last ticket designator. There is no implied wildcard at the end of a slash or at the end of the ticket designator. Examples: Y–//CH matches YAP//CH and Y//CH, but does not match YAPNR/CH33 or YAP/ID/CH Y-/ID/CH matches Y/ID/CH and YAP/ID/CH, but does not match YAP/ID90/CH or YAP/ID90/CH33

• When an asterisk is present, the asterisk may be replaced by any single or string of alphanumeric characters in the ticket designator, including a slash. If the asterisk is preceded by at least one alphanumeric character, it can be but does not have to be replaced. If the asterisk directly follows the slash, it must be replaced. Examples: –AP/CH* matches QAPNR/CH, QAPNR/CH33, QAP/CH/ABC or QAP/CH, but does not match QAP/ID/CH Y/* matches Y/CH, Y//CH and Y/ID/CH, but does not match Y Y//* matches Y//CH33, but does not match Y, Y/CH, or Y/ID/CH. Y/*/* matches Y/ID/CH, but does not match Y, C/CH, OR Y//CH Y–//CH* matches YAP//CH and YAP//CH33, but does not match YAP/CH33 or YAP/ID/CH Y-/ID/CH* matches Y/ID/CH, YAP/ID/CH, and YAP/ID/CH33, but does not match YAP//CH or YAP/ID90/CH33 Y-/ID*/CH* matches Y/ID/CH, YAP/ID90/CH, YAP/ID90/CH33, and YAP/ID/CH33, but does not match YAP//CH

• The asterisk will not be used to replace a number when the immediately following or preceding character in the ticket designator is also a number Example: B-/AB3* matches BAP/AB3X, but does not match BEE/AB35

• Generic wildcard matching: o -//* matches all Fare Bases with ‘//’ (slashes must be adjacent). Example: matches YAP//CH, but does not match YAP, YAP/CH, and Y/ID/CH o -/* matches all Fare Bases with one or more ticket designators. Example: matches YAP/CH, YAP//CH, and YAP/ID/CH, but does not match YAP

Pending Page E.03.S4.049 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

When this field is value Blank, there are no restrictions on the Fare Basis (subject to the remaining data within the record). Value Blank matches any Fare Basis and/or Ticket Designator combination.

Refer to the example(s) under this same section number in the Data Application – Examples – Record S4 Ticketing Fees document.

Frequent Flyer status matching

Validation of this field is against the passenger’s Frequent Flyer number in the ticket. Subscribers must message the frequent flyer number to the Record S4 owner and that carrier needs to message back the level (e.g. 1, 2, etc.) that corresponds to the number. It is the responsibility of the Record S4 owner (and not the responsibility of the pricing system) to decode the frequent flyer information into the applicable level. This may involve messaging the carrier whose frequent flyer number is being input (e.g. if the Record S4 owner is the validating carrier, then they may need to communicate with the marketing carrier in order to decode the frequent flyer level).

• If a response is received from the Record S4 owner, then the subscriber is able to process the level information in this field. o If the frequent flyer status number received from the Record S4 owner is equal to or lower than the status number in this field (meaning that the passenger is the correct level or a more elite status), then processing matches the record (provided a match is also made to all other match fields). Example: The Record S4 owner indicates that the customer’s frequent flyer level is 2. This will match a Record S4 Byte 159-173 value 2 through 9 (or when no frequent flyer status indicated).

o If the frequent flyer status number received from the Record S4 owner is not equal to the status number in this field or the status number received from the Record S4 owner is higher than the status number in this field, then processing no matches the record and continues to the next record. Example: The Record S4 owner indicates that the customer’s frequent flyer level is 4. This will not match a Record S4 Byte 159-173 value 1 through 3. This will match a Record S4 byte 159-173 value 4 through 9 (or when no frequent flyer status indicated).

• If no response is received from the Record S4 owner, the subscriber will assume an automatic no match to this field. Processing will no match the record and continue to the next record with the same Service Type Code.

Pending Page E.03.S4.050 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

When this field is value 9, this means that processing will match to a frequent flyer status of any level. The customer for whom the service is being priced must be a frequent flyer of any level. When frequent flyer status is not indicated, there are no Frequent Flyer Status restrictions. Processing will match the sequence regardless of whether the passenger has or does not have a specific level (e.g. is or is not a frequent flyer).

Refer to the example(s) under this same section number in the Data Application – Examples – Record S4 Ticketing Fees document.

Pending Page E.03.S4.051 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

4.1.15 Form of Payment Bin Number (bytes 176-181)

Processing will attempt to match the data in this field against the first six characters of debit/credit/charge card forms of payment being used for the ticket being processed that matches the Sub-code (bytes 8-10).

If multiple forms of payment are used: . At least one debit/credit/charge card form of payment must match data in the Form of Payment Bin Number field in order to match the record (all forms of payment being used do not have to match the record). If more than one match the S4 sequence, then the data applies to all matched form of payments. . The passenger/system must specify the amount to be charged against all but one of the forms of payment. Any residual amount due in excess of the passenger/system-specified amount(s), including any remaining fare, tax, and fee amounts, will be accumulated and charged to the form of payment for which an amount has not been supplied by the passenger/system. . Record S4 Form of Payment Fees should always be the last fee applied to the ticket. Processing should first apply to all Record S4 OB (ticketing) fees that are not Form of Payment Fees (e.g. not FC- types and not FD- types), all Record S1 (Carrier- Imposed (YQ/YR) fees, and all OC (optional services) fees prior to applying any Record S4 OB Form of Payment fees. If more than one Form of Payment fee exists, then it is at the subscriber’s discretion which of them to apply first.

In the Record S4, it is possible to identify a specific type of debit/credit/charge card or any debit/credit/charge card by the Sub-code definition (The Sub-code definition is provided in the ATPCO Services Sub-code Appendix B) and use the Form of Payment Bin Number (bytes 176-181) to further specify the debit/credit/charge card such as by debit/credit/charge card issuer, e.g. VISA credit card may have a Bin Number “40****” (credit card number starts with 40), Citibank VISA debit card may have a Bin Number “41****” (debit card number starts with 41).

Sub-code: Since the Sub-code is a match field to the Record S4, processing will have to match the Sub-code definition in order to match the record. For example, Sub-code FCA might denote any credit card form of payment or FDA as any debit card form of payment, Sub-Code FC4 a credit card form of payment with a number starting with “4” or FD4 a debit card form of payment with a number starting with 4, Sub-Code FC5 a credit card form of payment with a number starting with “5” or FD5 a debit card form of payment with a number starting with 5. Alternatively, the Sub-code may not refer to form of payment (e.g., Sub-Code T01 maybe a fee for CTO ticketing regardless of the form of payment).

Pending Page E.03.S4.052 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

Form of Payment Bin Number: This six-character numeric field identifies the category of the entity that issued the debit/credit/charge card (e.g., travel and entertainment, banking and financial), the card brand (e.g., VISA), the card issuer (e.g., Bank of America, Barclay’s Bank) and the type of card (e.g., debit, credit, gift). See Appendix A for information on how the financial industry assigns bin numbers. Value ‘*’ (asterisk) may be used as a wildcard in the second through sixth bytes of this field in order to provide the ability to only specify the first one to five digits of the card. For example, Sub-code FC1 with BIN value 12**** may be entered to indicate that at least one form of payment must be a credit card with a Bin Number starting with 12, Sub-code FC1 with BIN value 1234** to indicate any credit card starting with 1234, or Sub-code FD1 with BIN value 1***** to indicate any debit card starting with 1.

Processing of the Form of payment Sub-code and Form of Payment Bin Number fields are dependent upon each other as follows: . When the Sub-code is FCA and the Form of Payment Bin Number does not contain data, at least one credit card form of payment must match the credit card form of payment defined by the Sub-code. . When the Sub-code is FCA and the Form of Payment Bin Number contains data, at least one credit card form of payment must match both the Sub-code and the Form of Payment Bin Number. . When the Sub-code specifies the starting number of a credit card form of payment such as “FC4” and the Form of Payment Bin Number contains data such as “40****”, a credit card form of payment with a number starting with “4” matches the Sub- code and the bin number of that credit card form of payment must match the Form of Payment Bin Number field. . When the Sub-code is FDA and the Form of Payment Bin Number does not contain data, at least one debit card form of payment must match the debit card form of payment defined by the Sub-code. . When the Sub-code is FDA and the Form of Payment Bin Number contains data, at least one debit card form of payment must match both the Sub-code and the Form of Payment Bin Number. . When the Sub-code specifies the starting number of a debit card form of payment such as “FD4” and the Form of Payment Bin Number contains data such as “40****”, a debit card form of payment with a number starting with “4” matches the Sub-code and the bin number of that debit card form of payment must match the Form of Payment Bin Number field.

Note: ATPCO will not edit the Sub-Code against the valid value for the Bin Number.For example, Sub-code FC4 may have data coded in Bin Number = “12****”. Processing for this sequence will automatically result to NO MATCH. . When the Sub-code does not specify a form of payment such as “T01” or “R01”,edit requires the Form of Payment Bin Number must be blank, there are no form of payment requirements for matching the S4 record; any form(s) of payment will match the record (subject to the remaining data within the record).

Pending Page E.03.S4.053 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

Record S4s are processed in sequential order (from lowest to highest sequence number) within a unique Service Type Code (“Tax” Code and Sub-code). Once a match is made to a sequence, processing does not continue to another sequence for the same Service Type Code. If multiple debit/credit/charge card forms of payment are used, different Sub-codes for the different debit/credit/charge card forms of payment should be used to make sure both debit/credit/charge card forms of payment fees are applied.

Example 1: Service Type Code Sequence Number Application/Definition OBFC4 0001000 Form of Payment fee for a credit card number starting with “4”= 100.00 AUD OBFC5 0001000 Form of Payment fee for a credit card number starting with “5” = 75.00 AUD

For this example, assume that VISA credit card numbers start with “4” and MasterCard credit card numbers start with “5”. If payment is made using both Visa and MasterCard credit cards, processing will match OBFC4 Sequence 0001000 (provided all other match criteria in the record are met) and apply the 100.00 AUD fee. Processing will continue to see if other Service Type Codes apply and will match OBFC5 Sequence 0001000 (provided all other match criteria in the record are met) and apply the Master Card credit card 75.00 AUD fee as it has a different Service Type Code from the Visa credit card fee.

Example 2: Service Type Code Sequence Number Application/Definition OBFCA 0001000 Form of Payment fee for any credit card = 100.00 AUD OBFCA 0002000 Form of Payment fee for any credit card = 75.00 AUD

For this example, assume that VISA credit card numbers start with “4”. If payment is made using two VISA credit cards, processing will match OBFCA Sequence 0001000 (provided all other match criteria in the record is met) and apply the 100.00 AUD fee. Processing will not continue to sequence 0002000 because it is the same Service Type Code as sequence 1000.

Example 3 Service Type Code Sequence Number Application/Definition OBFD4 0001000 Form of Payment fee for a debit card number starting with “4”= 100.00 AUD OBFD5 0001000 Form of Payment fee for a debit card number starting with “5” = 75.00 AUD

Pending Page E.03.S4.054 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

For this example, assume that VISA debit card numbers start with “4” and MasterCard debit card numbers start with “5”. If payment is made using both Visa and MasterCard debit cards, processing will match OBFD4 Sequence 0001000 (provided all other match criteria in the record are met) and apply the 100.00 AUD fee to the VISA debit card. Processing will continue to see if other Service Type Codes apply and will match OBFD5 Sequence 0001000 (provided all other match criteria in the record are met) and apply the Master Card debit card 75.00 AUD fee as it has a different Service Type Code from the Visa debit card fee.

Example 4: Service Type Code Sequence Number Application/Definition OBFDA 0001000 Form of Payment fee for any debit card = 100.00 AUD OBFDA 0002000 Form of Payment fee for any debit card = 75.00 AUD

For this example, assume that VISA debit card numbers start with “4”. If payment is made using two VISA debit cards, processing will match OBFDA Sequence 0001000 (provided all other match criteria in the record is met) and apply the 100.00 AUD fee. Processing will not continue to sequence 0002000 because it is the same Service Type Code as sequence 1000.

Refer to the example(s) under this same section number in the Data Application – Examples – Record S4 Ticketing Fees document.

Pending Page E.03.S4.055 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

4.1.16 Point of Card Issuance/Country Table No 162 (bytes 182-189)

If a table number exists, processing should evaluate data in the table against the debit or credit card forms of payment. When the Sub Code is one of the debit or credit F-type Sub Codes, and a Point of Card Issuance Table number exists, the country of issuance for the card must match one of the country codes in the table. The country of issuance for the card can be found by processing the card BIN number against the BIN Answer Table Record A01.

For Example:

According to the BIN Table Record A01, the following BINs have these types and Points of Card Issuance:

BIN Type POCI Bytes 4-9 Byte 40 Bytes 113-114 ------412345 D US 542310 D GB 474478 C ES 475569 C US

1) Carrier XX has an FCA sequence that specifies a fee for tickets purchased using any credit cards issued in Spain. An XX ticket was purchased using a Visa card numbered 4744 7800 1234 5678. System determines from the BIN Answer Table Record A01 that the card’s BIN 474478 is of the type Credit and was issued in Spain. Match the sequence (assuming all other appropriate fields also match).

2) Carrier ZZ has an FDA sequence that specifies a fee for tickets purchased using any debit cards issued in the European Union. The sequence includes a Point of Card Issuance Table that contains this list of country codes: AT, BE, DK, FI, FR, DE, GR, LU, NL, PT, RO, ES, SW, GB. A ZZ ticket was purchased using a Mastercard card numbered 5423 1000 1234 5678. System determines from the BIN Answer Table Record A01 that the card’s BIN 542310 is of the type Debit and was issued in Great Britain. Match the sequence (assuming all other appropriate fields also match).

Pending Page E.03.S4.056 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

4.1.17 Card Usage (byte 190)

When the Sub Code is one of the debit or credit Sub Codes, and Card Usage is coded, the value in Card Usage field must match the Card Usage of the BIN number matched in the BIN Answer Table Record A01.

For Example:

According to the BIN Table Record A01, the following BINs have these Types and Card Usage values.

BIN Type Card Usage Bytes 4-9 Byte 40 Byte 115 ------412345 D C 542310 D P 474478 C C 475569 C C

1) Carrier XX has an FCA sequence that specifies a fee for tickets purchased using any business or corporate credit cards. An XX ticket was purchased using a Visa card numbered 4744 7800 1234 5678. System determines from the BIN Answer Table Record A01 that the card’s BIN 474478 is of the type Credit and usage “C”. Match the sequence (assuming all other appropriate fields also match).

2) Carrier ZZ has an FDA sequence that specifies a fee for tickets purchased using any personal debit cards. A ZZ ticket was purchased using a Mastercard numbered 5423 1000 1234 5678. System determines from the BIN Answer Table Record A01 that the card’s BIN 542310 is of the type Debit and usage “P”. Match the sequence (assuming all other appropriate fields also match).

3) Carrier ZZ has an FDA sequence that specifies a fee for tickets purchased using any debit cards (card usage byte 190 is blank). A ZZ ticket was purchased using a Mastercard numbered 5423 1000 1234 5678. System determines from the BIN Answer Table Record A01 that the card’s BIN 542310 is of the type Debit and usage “P”. Match the sequence (assuming all other appropriate fields also match).

Pending Page E.03.S4.057 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

4.1.18 Service Type Code – IATA Application Indicators (bytes 210-212)

Once processing matches all match criteria in the Record S4 being processed, these fields specify whether or not any applicable fee for the Service Type in the record is refundable, commissionable, and/or interlineable.

While the Service Type “Tax” Code and Sub-code fields (bytes 6-10) are match fields and Record S4s are processed sequentially within each unique “Tax” and Sub-code combination, the IATA Application indicators are not match fields. Rather the IATA Application Indicators fields strictly provide additional information and have no impact on the match process or sequential processing of the record. Once processing matches a Record S4 and applies any applicable fee, the resulting Service Type Code consists of the data in the “Tax” Code and Sub-code fields (bytes 6-10). The resulting Service Type Code will appear on the face of the receipt as follows: “Tax” Code, then Sub-code..

An explanation of applicable fields is provided in the following sections.

4.1.18.1 Refund/Reissue (byte 210) This field specifies whether or not any applicable fee in the matched Record S4 is refundable. An explanation of applicable values follows:

Value N: No. The fee is not refundable and assumed consumed upon purchase. It is not carried forward on any reissue transactions.

NOTE: The Service Fees Working Group agreed that these fees are not refundable and not reissuable for the initial development phase.

Refer to the example(s) under this same section number in the Data Application – Examples – Record S4 Ticketing Fees document.

4.1.18.2 Commission (byte 211) This field specifies whether or not any applicable fee in the matched Record S4 is commissionable. An explanation of applicable values follows:

Value N: No. The fee is not commissionable.

Pending Page E.03.S4.058 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

NOTE: The Service Fees Working Group agreed that these fees are not commisionable for the initial development phase.

Refer to the example(s) under this same section number in the Data Application – Examples – Record S4 Ticketing Fees document.

4.1.18.3 Interline Settlement(byte 212) This field specifies whether or not any applicable fee in the matched Record S4 is interlineable. An explanation of applicable values follows:

Value N: No. The fee is not interlineable.

NOTE: The Service Fees Working Group agreed that Ticketing Fees in Record S4 are not interlineable

Refer to the example(s) under this same section number in the Data Application – Examples – Record S4 Ticketing Fees document.

Pending Page E.03.S4.059 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

4.1.19 Service Fee (bytes 213-232) The Service Fee fields consist of the following fields: • No Charge (byte 213) • Specified Fee (bytes 214-224) • Percent (bytes 225-231) • Tax Included (byte 232)

Once processing matches all match criteria in the Record S4 being processed, these fields identify any applicable Service Fee. The Service Fee must be expressed as one and only one of the following: No Charge (byte 213), Specified Fee (bytes 214-224) or Percent (bytes 225-231).

An explanation of applicable fields is provided in the following sections.

Pending Page E.03.S4.060 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

4.1.19.1 No Charge (byte 213) This field dictates that the specified ticketing conditions in the record are not subject to any Ticketing Fees. Following is an explanation of applicable values:

Value X: No Ticketing Fees apply for this Service Type Code. This free service is not reflected on the passenger’s receipt.

Once a match is made to a Record S4, No Charge value X indicates that there is no fee for the Service Type Code (no fee for the specific “Tax” Code and Sub-code). The free service will not be reflected on the passenger’s receipt. Processing will continue to another record S4 with a different Service Type Code.

When No Charge is value X, edits require the following values in the fields specified below: • Specified Fee Amount (bytes 214-220) must be value 0000000 • Specified Fee Currency (bytes 221-223) must be value Blank • Specified Fee Decimal (byte 224) must be value 0 • Percent (bytes 225-231) must be value 0000000

Value Y: No Ticketing Fees apply for this Service Type Code. This free service is reflected on the passenger’s receipt.

Once a match is made to a Record S4, No Charge value Y indicates that there is no fee for the Service Type Code (no fee for the specific “Tax” Code and Sub-code). The free service will be reflected on the passenger’s receipt. Processing will continue to another record S4 with a different Service Type Code.

When No Charge is value Y, edits require the following values in the fields specified below: • Specified Fee Amount (bytes 214-220) must be value 0000000 • Specified Fee Currency (bytes 221-223) must be value Blank • Specified Fee Decimal (byte 224) must be value 0 • Percent (bytes 225-231) must be value 0000000

Value Blank: No application. Any fees applicable to the matched Record S4 are found in the Specified Fee (bytes 214-224) or Percent (bytes 225-231) fields.

Pending Page E.03.S4.061 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

Refer to the example(s) under this same section number in the Data Application – Examples – Record S4 Ticketing Feesdocument.

Pending Page E.03.S4.062 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

4.1.19.2 Specified Fee (bytes 214-224) This field indicates a specific fee amount, decimal, and currency. The Specified Fee data may be expressed in any currency (that is, it does not have to be in the currency of the country of sale). If the currency in Specified Fee matches the currency of the country of payment, the matched fee will be applied. If not, then processing will convert the Specified Fee amount/currency to the currency of the country of payment using the Bankers Selling Rate (BSR). Rounding procedures dictated by IATA Resolution 024d for ‘other charges’ apply.

Edits require that when No Charge (byte 213) and Specified Fee Currency (bytes 211-213) are value Blank, then Percent (bytes 225- 231) must be value 000.0001-999.9999. An edit also will ensure that that the number in the Decimal field (byte 224) is the correct number of decimal places for the currency in the Currency field (bytes 221-223) per the IATA Resolution 024d. When a Specified Fee is present, the fee applies per ticket. Note that when applying the data “per ticket” a conjunctive ticket is considered only one ticket (e.g. one journey with 12 segments is considered one ticket).

Refer to the example(s) under this same section number in the Data Application – Examples – Record S4 Ticketing Fees document.

Pending Page E.03.S4.063 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

4.1.19.3 Percent (bytes 225-231) This field indicates that the fee is a percentage. The application of the percentage depends upon whether the fee is a Debit/credit/charge Card Form of Payment fee or another type of fee. Debit/credit/charge Card Form of Payment fees will have “Tax” Code (bytes 6-7) value OB and are identified by the Sub-code (bytes 8-10) definition (as defined in the ATPCO Services Sub-code Appendix) and/or the Form of Payment Bin Number (bytes 176-181). The application of the Percent fee based on a Debit/credit/charge Card Form of Payment Fee and a Non- Form of Payment Fee is described below.

Debit/credit/charge Card Form of Payment Fee The Percent applies against all debit/credit/charge cards that match the data in the Sub-code (bytes 8-10), Credit Card Form of Payment Bin Number (bytes 176-181) fields (applies against the matched credit card). Processing will apply the percentage to the total amount being charged against the matched credit card (exclusive of any credit card fees). The following rules apply:

• Record S4 Form of Payment Fees should always be the last fee applied to the ticket. Processing should first apply to all Record S4 OB (ticketing) fees that are not Form of Payment Fees, all Record S1 - Carrier-Imposed (YQ/YR) Fees, and all OC (optional services) fees prior to applying any Record S4 OB Form of Payment fees. If more than one Form of Payment fee exists, then it is at the subscriber’s discretion which of them to apply first.

• The Percent fee is only applied to the amount to be charged against a debit/credit/charge card, exclusive of any Debit/credit/charge Card Form of Payment fee. The Percent is not against any Debit/credit/charge Card Form of Payment Fee that may ultimately be charged to the debit/credit/charge card (this includes debit/credit/charge card fees that are Specified Fees and Percent Fees). (Refer to examples below.)

• When multiple forms of payment are used, it is required that the passenger/system will specify the amount to be charged against all but one of the forms of payment. Any debit/credit/charge card fees will be accumulated and charged to the form of payment for which an amount has not been supplied by the passenger/system.

Example 1: Ticket = $1000.00 (includes all taxes and fees except credit card fees) Passenger requests to pay with one credit card as follows: $1000 plus the credit card fee is charged against the credit

Pending Page E.03.S4.064 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

Example 2: Ticket = $1000.00 (includes all taxes and fees except debit card fees) Passenger requests to pay with one debit card as follows: $1000 plus the debit card fee is charged against the debit

Example 3: Ticket = $1000.00 (includes all taxes and fees except credit card fees) Passenger requests to pay with 3 credit cards as follows: $500 against the 1st credit card $100 against the 2nd credit card Remaining amount against the 3rd credit card

The 3rd credit card will be charged the remaining $400 for the ticket plus any applicable credit card fees applied to the 1st, 2nd, and/or 3rd credit card.

Example 4: Ticket = $1000.00 (includes all taxes and fees except credit/debit card fees) Passenger requests to pay with 2 credit cards and 1 debit card as follows: $500 against the 1st credit card $100 against the 2nd credit card Remaining amount against the 3rd debit card

The 3rd debit card will be charged the remaining $400 for the ticket plus any applicable credit card fees applied to the 1st, 2nd credit cards, and debit card fees applicable for the 3rd debit card.

• If the matched credit card is charged more than once for the same ticket (e.g., it is “swiped” more than one time for the same ticket), the percent applies to the total cumulative amount being swiped against the matched debit/credit/charge card,

Pending Page E.03.S4.065 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

exclusive of any debit/credit/charge card fees. The percent is not applied against any debit/credit/charge card fee that may ultimately be charged to the debit/credit/charge card (this includes debit/credit/charge card fees that are Specified Fees and Percent Fees).

Example 1 Service Type Code Sequence Number Record S4 data/definition OBFC4 1000 Visa Form of Payment Fee = 3%

Ticket = $1000.00 (includes all taxes and fees except credit card fees) Passenger requests to pay with 2 Visa credit cards as follows: $500 against the 1st Visa credit card Remaining amount against the 2nd Visa credit card

Processing matches OBFC4 sequence 1000 for Visa cards. Percentage service fees are calculated as follows: 1st Visa card: $500 x 3% = 15.00 2nd Visa card: $500 x 3% = 15.00

Final charge against each credit card: 1st Visa card: $500.00 2nd Visa card: $530.00 (includes $15.00 fee for the 1st card and $15.00 fee for the 2nd card)

Example 2 Service Type Code Sequence Number Record S4 data/definition OBFD4 1000 Visa Form of Payment Fee = 3%

Ticket = $1000.00 (includes all taxes and fees except credit card fees) Passenger requests to pay with 2 Visa debit cards as follows: $500 against the 1st Visa debit card Remaining amount against the 2nd Visa debit card

Processing matches OBFD4 sequence 1000 for Visa cards. Percentage service fees are calculated as follows: 1st Visa card: $500 x 3% = 15.00

Pending Page E.03.S4.066 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

2nd Visa card: $500 x 3% = 15.00

Final charge against each debit card: 1st Visa card: $500.00 2nd Visa card: $530.00 (includes $15.00 fee for the 1st card and $15.00 fee for the 2nd card)

• If there are multiple debit/credit/charge card forms of payment that match different Debit/credit/charge Card Form of Payment percent fees, the applicable percent for each card is applied to the amount being swiped against the card, exclusive of any debit/credit/charge card fees. The percent is not applied against any debit/credit/charge card fee that may ultimately be charged to the debit/credit/charge card (this includes debit/credit/charge card fees that are Specified Fees and Percent Fees).

Example 1 Service Type Code Sequence Number Record S4 data/definition OBFC4 1000 Fee for credit card with number starting with “4” = 3% OBFC3 1000 Fee for credit card with number starting with “3” = 5%

For the following scenarios, assume that Visa credit card number starts with “4” and American Express credit card number starts with “3”

Scenario 1 Ticket = $1000.00 (includes all taxes and fees except credit card fees) Passenger requests to pay with 2 credit cards as follows: $500 against a Visa credit card Remaining amount against an American Express credit card

Processing matches OBFC4 sequence 1000 for the Visa card and OBFC3 sequence 1000 for the American Express card. Percentage service fees are calculated as follows: Visa card: $500 x 3% = 15.00 American Express card: $500 x 5% = 25.00

Pending Page E.03.S4.067 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

Final charge against each credit card: Visa card: $500.00 American Express card: $540.00 (includes $15.00 fee for the Visa card + $15.00 fee for the American Express card)

Scenario 2 Ticket = $1000.00 (includes all taxes and fees except credit card fees) Passenger requests to pay with 2 credit cards as follows: $500 against an American Express credit card Remaining amount against a Visa credit card

Processing matches OBFC4 sequence 1000 for the Visa card and OBFC3 sequence 1000 for the American Express card. Percentage service fees are calculated as follows: American Express card: $500 x 5% = 25.00 Visa card: $500 x 3% = 15.00

Final charge against each card: American Express card: $500.00 Visa card: $540.00 (includes $15.00 fee for the Visa card + $15.00 fee for the American Express card)

Scenario 3 Ticket = $1000.00 (includes all taxes and fees except credit card fees) Passenger requests to pay with 3 credit cards as follows: $500 against a Visa credit card $400 against an American Express credit card Remaining amount against a MasterCard credit card

Processing matches OBFC4 sequence 1000 for the Visa card and OBFC3 sequence 1000 for the American Express card. Processing does not match any Record S4s for the MasterCard. Percentage service fees are calculated as follows: Visa card: $500 x 3% = 15.00 American Express card: $400 x 5% = 20.00

Pending Page E.03.S4.068 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

Final charge against each credit card: Visa card: $500.00 American Express card: $400.00 MasterCard: $135.00 (includes $15.00 fee for the Visa card + $20.00 fee for the American Express card)

Example 2 Service Type Code Sequence Number Record S4 data/definition OBFC4 1000 Visa Form of Payment Fee = 3% OBFC3 1000 American Express Form of Payment Fee = $10.00

Ticket = $1000.00 (includes all taxes and fees except credit card fees) Passenger requests to pay with 2 credit cards as follows: $500 against an American Express credit card Remaining amount against a Visa credit card

Final charge against each credit card: American Express card: $500.00 Visa card: $525.00 (includes $15.00 fee for the Visa card + $10.00 fee for the American Express card)

Pending Page E.03.S4.069 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

Example 3 Service Type Code Sequence Number Record S4 data/definition OBFC4 1000 Visa Form of Payment Fee = 3% OBFD3 1000 American Express Form of Payment Fee = $10.00

Ticket = $1000.00 (includes all taxes and fees except credit card fees) Passenger requests to pay with 1 credit card and 1 debit card s as follows: $500 against an American Express debit card Remaining amount against a Visa credit card

Processing matches OBFC4 sequence 1000 for the Visa card and OBFD3 sequence 1000 for the American Express debit card. Percentage service fees are calculated as follows: American Express card: $10.00 (specified fee) Visa card: $500 x 3% = $15.00

Final charge against each credit card: American Express card: $500.00 Visa card: $525.00 (includes $15.00 fee for the Visa card + $10.00 fee for the American Express card)

Ticketing Fees that are not Form of Payment Fees The Percent applies against the amount in the Equivalent Fare Paid field in the e-ticket record. If the Equivalent Fare Paid field is blank, then the Percent applies against the amount in the Base Fare field in the e-ticket record and in the case of a reissue ticket, calculate percent against the base fare of the new ticket. This excludes amounts in any other fields in the e-ticket record (refer to the definition in Section 2.1 of this document). For net remit tickets, the Base Fare equals the selling amount. Processing will apply these fees prior to applying any Debit/credit/charge Card Form of Payment Fees. Rounding procedures dictated by IATA Resolution 024d for taxes apply.

When Percent is value 000.0001-999.9999, the fee is a simple calculation of multiplying the percent by the amount identified above (no subtraction is implied).

Pending Page E.03.S4.070 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

When Percent is value 000.0000, this field has no application. Any fee data is found in the Specified Fee fields (bytes 214-224) or the No Charge (byte 213) fields. Edits require that when No Charge (byte 213) is blank and Percent (bytes 225-231) is value 000.0000, then Specified Fee Currency (bytes 211-213) must contain data.

The fee resulting from the percentage calculation should be rounded according to the current IATA tax rounding procedures. If rounding procedures for multiple fees (“taxes”) are not specified in these procedures, then when multiple fees exist, each fee should be rounded separately and then totaled.

Refer to the example(s) under this same section number in the Data Application – Examples – Record S4 Ticketing Fees document.

Pending Page E.03.S4.071 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

4.1.19.4 Tax Included (byte 232) This field specifies whether or not sales and value added taxes are included in the fee (either specified or percentage). Following is an explanation of applicable values:

Value X: The fee amount includes sales and value added taxes. Processing will not add further tax to the fee. The fee amount as entered in the Record S4 Fee fields is the reported fee amount for passenger receipt and revenue accounting purposes. For example, if Tax Included field is X, the fee amount is EUR10 therefore the amount to be collected from the customer is EUR 10. It is up to the carrier collecting the fee to determine and remit the applicable taxes.

Value Blank: The fee amount does not include sales and value added taxes. Processing will compute all applicable taxes3 and add the sum to the fee amount to determine the total amount to be collected from the customer. The fee amount as entered in the Record S4 Fee fields is the reported fee amount for passenger receipt and revenue accounting purposes. For example, if Tax Included field is value blank, the fee amount is EUR10 and applicable taxes are EUR1.00 and EUR2.20, then the reported fee amount is EUR10.00, the reported tax amounts are EUR1.00 and EUR2.20 and the amount to be collected from the customer is EUR13.20.

Refer to the example(s) under this same section number in the Data Application – Examples – Record S4 Ticketing Fees document.

Pending Page E.03.S4.072 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

4.1.20 Maximum Charge (bytes 234-244) The Maximum Charge fields indicate that when the service fee for this record is expressed as a percentage, the total OB fee for the subcode must not exceed the amount in the Maximum Charge fields. The Maximum Charge is expressed as a specified amount, currency, and decimal. The Maximum Charge data may be expressed in any currency (that is, it does not have to be in the currency of the country of payment). If the currency in Maximum Charge fields does not match the currency of the country of payment, processing will convert the Maximum Charge amount/currency (as necessary) to the currency of the country of payment using the Bankers Selling Rate (BSR). Rounding procedures dictated by IATA Resolution 024d for taxes apply.

When the Service Fee is expressed as a Percent (Percent bytes 225-231 is greater than or equal to 000.0001) and data is present in the Maximum Charge fields (Maximum Charge Currency bytes 241-243 contains data), processing will take the following steps:

1. Calculate the Resulting Fee for this Record S4 based on the processing described in “Section 4.1.18.3 Percent” of this document.

2. After the Resulting Fee is calculated based on the percent data, compare the Resulting Fee to the Maximum Charge. NOTE: Processing may have to convert the Maximum Charge to the currency of the country of payment in order to perform the comparison. If so, the conversion will be done (as specified above) using the Bankers Selling Rate (BSR). Rounding procedures dictated by IATA Resolution 024d for taxes apply. a. If the Resulting Fee is greater than the Maximum Charge, apply the Maximum Charge as the service fee for this Record S4. The fee applies per ticket. Note that when applying the data “per ticket,” a conjunctive ticket is considered only one ticket (e.g. one journey with 12 segments is considered one ticket). b. If the Resulting Fee is less than or equal to the Maximum Charge, apply the Resulting Fee as the service fee for this Record S4.

When the Service Fee is expressed as a Percent and data is not present in the Maximum Charge fields (Maximum Charge Amount is value 0000000, Maximum Charge Currency is value Blank, and Maximum Charge Decimal is value 0), there is no Maximum Charge for this Record S4. Processing will calculate the Resulting Fee for this Record S4 based on the processing described in “Section 4.1.18.3 Percent” of this document and apply the Resulting Fee as the service fee for this Record S4.

Pending Page E.03.S4.073 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

If the Service Fee is not expressed as a Percent (Percent bytes 225-231 is value 000.0000), the Maximum Charge fields have no application (and edits will require that Maximum Charge Amount be value 0000000, Maximum Charge Currency be value Blank, and Maximum Charge Decimal be value 0). There is no Maximum Charge for this Record S4.

Refer to the example(s) under this same section number in the Data Application – Examples – Record S4 Ticketing Fees document.

Pending Page E.03.S4.074 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

4.1.21 Commercial Name (bytes 262-271) This field indicates a commercial name for the Service Type Code in the record. When this field is populated, the data is for display purposes only and has no impact on matching and charging the applicable fee.

Pending Page E.03.S4.075 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

5. TRAVEL SEGMENT INDICATORS Travel Segment Indicators (TSIs) are not applicable in Record S4.

Pending Page E.03.S4.076 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

6. CODING CONVENTIONS

6.1 Exemptions/Exceptions

• For any situation where a Ticketing Fee does not apply (e.g. situation/passenger that is exempt from a fee), the data should be specified as “no charge” (value X or Y in byte 213) in a sequence number that is lower than the sequences with a charge.

6.2 Fare Basis

• If the intent is to exclude a fee or charge a lower fee when the entire journey is on a specific Fare Basis, the charged data (more expensive fees) should be sequenced prior to the less expensive fees (charges before exclusions) as follows:

Example Intent: A wholly first class ticket (F class) has no fees. If any sector of the ticket is an excursion fare, the fee is 15.00. If any sector of the ticket is an advance purchase fare, the fee is 5.00.

Data is entered as: Sequence Number Fare Basis Indicator Fare Basis Fee 1000 X (at least one sector) -EE (excursion) 15.00 2000 X (at least one sector) -AP (adv. purch) 5.00 3000 X (at least one sector) F- (first class) 0.00

• Use the Fare Basis field to differentiate journeys consisting of a single Round the World fare component vs. journeys consisting of a combination of multiple fare components.

Pending Page E.03.S4.077 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

6.3 Debit/credit/charge Card Form of Payment Fees

• If the intent is to charge a separate fee for each type of debit/credit/charge card used as form of payment, the cards must be distinguished by different Sub-codes. For example, if there is a fee for a Visa credit card and an American Express credit card, then they must be expressed using a Sub-code for Visa credit card form of payment and a Sub-code for American Express credit card form of payment, respectively. Otherwise, if they each are expressed using the same Sub-code and only differentiated by Bin Number, processing will only match one Record S4 for a unique “Tax” Code and Sub-code pair and only apply one fee for that “Tax” Code and Sub-code pair. The same concept applies when specifying fees for debit cards.

• If the intent is to charge a single fee for any debit/credit/charge card form of payment, then a generic Sub-code may be used that is just defined as a generic debit/credit/charge card form of payment fee(FCA or FDA). There is no need to distinguish card types by Bin Number. If the intended result is to charge the highest fee, the debit/credit/charge card with the highest fee must have the lowest sequence number within the SubCode.

6.4 Multiple account codes

• If the intent is to charge the highest fee when a passenger can qualify for multiple account codes, assign a lower sequence number to the account code with the highest fee.

• If the intent is to charge the lowest fee when passenger can qualify for multiple account codes, assign a lower sequence number to the account code with the lowest fee.

Pending Page E.03.S4.078 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

PART 2 – TICKETING

7. POST PRICE PROCESSING

Ticketing standards require that any Validating Carrier Fees should not be presented on the ‘face’ of the ticket, as this is reserved for fare information and any taxes, fees, or charges accruing to a government or airport authority. As such ATPCO worked with both the Joint Passenger Ticketing Committee and with the BSP Data Interchange Standards Group to ensure that a ticketing and reporting solution would be available for validating carrier fees. The solution is only applicable to Electronic Tickets, and the Electronic Ticket Receipt is utilized for disclosure of this Ticketing Fee and any commensurate taxes to the passenger.

A solution was required which reported the ticketing fee outside the ticket face, but within the financial amount fields reported with the ticket. This would ensure that all financial amounts could still be reconciled. As such the ticketing fee is ‘below the line’ in terms of reporting, but is used in calculation of the total form of payment amount chargeable to the passenger. For ease of agency reporting (BSP HOT and ARC CAT files), the existing tax fields will be used for reporting the relevant ticketing fee.

7.1 Ticketing This section of the data application deals with driving the ticket to issuance after the appropriate service fees have been applied in pricing the product.

The following factors need to be considered when driving the ticketing process:

Normal ticket, prime sale, attracts service fees Exchange ticket sale Net remit ticket sale

The key to correctly ticketing the fee is that the codes which have been established in pricing will never be driven to the ‘face’ or facsimile of the ticket. Therefore any ‘print’ or display of the ticket ‘face’ of the travel document – as noted in the example below – would only include the fare, any regular ticket taxes/fees/charges, and a total amount.

Pending Page E.03.S4.079 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

Any Validating Carrier Fees are required to be delivered on a receipt to the passenger, with clear explanation of what the charges relate to. OB charges must be separately characterized from the fare and tax amounts. This may be achieved by providing a separate receipt, or separating the charges on one receipt. The format of this receipt is not defined by resolution. NOTE: If the service is “free” (no charge applies), then Record S4 No Charge byte 213 specifies whether or not the free service should be reflected on the receipt.

The following example shows how a ticket would be driven with OB, including a tax on OB Service Fee. Assume that the following Service Fees and Tax apply:

OBFC3 = 10.00 USD

XX tax on OBFC3 = 5.00 USD

Passenger’s Electronic Ticket Receipt *

FLT BB 100 IAD to LON Departs 6:30 pm Arrives 6:00 am +1day FLT AA 101 LON to IAD Departs 3:00 pm Arrives 6:00 pm

FARE USD3435.00 EQUIV. FARE PD. TAX/FEE/CHARGE USD13.00GB TAX/FEE/CHARGE TAX/FEE/CHARGE DEBIT/CREDIT/CHARGE USD10.00OBFC3 This Invoice Receipt serves as a Valid VAT CARD SERVICE FEE Receipt. VAT (Code XX) of 50% has been SERVICE FEE TAX USD5.00XX charged on Service Fee OBFC3 GRAND TOTAL USD3463.00USD *The above receipt is provided for illustrative purposes only and in no way reflects how the data should or will appear on the receipt.

Pending Page E.03.S4.080 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

Printed Electronic Ticket (per IATA Ticketing Resolutions)

FARE USD3435.00 FARE CALCULATION EQUIV. FARE PD. WAS BB LON AA WAS 3435.00NUC3435.00 TAX/FEE/CHARGE USD13.00GB TAX/FEE/CHARGE TAX/FEE/CHARGE TOTAL USD3448.00

Note that in line with the specifications for ticketing and service fees, the following attributes apply:

1) The ticket ‘face’ (or related document, itinerary receipt, or exchange/ print to paper) does not have any reference to OB in either the tax/fee/charge boxes or in the sum total amount at the bottom of the ticket. 2) The ‘Receipt’ for the ticketing fees paid, although not a representation of an actual receipt which is formatted at the discretion of the collecting carrier, clearly shows the fare plus taxes and the total amount, followed by the ticketing fee charged (and any taxes applicable to the ticketing fee and the sum total of all collections from the customer. 3) In this case there is a tax on tax (for example, VAT) which is also only referred in the ‘Receipt’ document.

Also note the proposal that the Invoice Receipt should serve as a valid VAT Invoice when printed, and as such must display clearly that such VAT has been charged, at which rate, and on what base amount it has been charged. Local legislation related to wording requirements for the correct display of Value Added Tax amounts or related charges should be factored into the display and print routine of the ticketing system, and is expected to vary by country. Note that multiple rates of VAT are not reflected in the revenue accounting records, but the total amount of VAT is shown and may have been arrived at by applying different rates to fare, fees, etc.

Pending Page E.03.S4.081 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

7.2 Sales Data Reporting (HOT, CAT, RET, TCN)

Current sales data reporting in the form of HOT, CAT, RET, and TCN uses the following fields to display tax amounts and tax ‘types’ (codes). There is no technical limit on the number of taxes which can be reported in these fields, and as such the GDS ticketing limitation tends to drive the upper limit. This is currently around 21, but will be extended to 99 for all ticketing systems from 1st January 2008.

An extract of the data elements from the ISR/TCN Specification is presented below:

Pending Page E.03.S4.082 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

The Ticketing Fees solution utilizes these existing data elements, but orders the tax records so that the Ticketing Fees and any applicable taxes levied on the Ticketing Fee follow in order the ticketing fee entries. This permits carriers/systems to easily separate Ticketing Fee and Tax amounts from the total amount in order to ascertain the subtotal fare and tax amount.

Pending Page E.03.S4.083 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

The below example illustrates the ordering of the same Service Fees and taxes within the reporting file.

Source Data Element Population TCN/ RET/ HOT/ CAT FARE USD 3435.00 Facsimile Elements TAXA USD 13.00GB TAXA Blank TAXA Blank TOTL USD 3448.00

TCN only FNUM/ CUTP 00000343500/ USD TCN/ RET/ HOT/ CAT TMFT/ TMFA GB/ 00000001300 Financial Elements (Prior to DISH 20.1) TMFT/ TMFA OB / 00000001000 TMFT/ TMFA XX/ 00000000500 FPAM (sum) 00000346300 TDAM 00000346300 Financial Elements (DISH 20.1) TMFT/ TMFA OBFC3bbb/ 00000001000 * TMFT/ TMFA XX/ 00000000500 FPAM (sum) 00000346300 TDAM 00000346300

Financial Elements (DISH 20.2) TMFT/ TMFA OBFC30bb/ 00000001000 * TMFT/ TMFA XX/ 00000000500 FPAM (sum) 00000346300 TDAM 00000346300 * Note that the only change between reporting in DISH20.1 and DISH20.2 is that the pricing indicator appears in byte 6 of the TMFT for 20.2 and later versions. In DISH 20.1 and earlier versions, byte 6 of the TMFT would be blank.

Pending Page E.03.S4.084 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

Prior to implementation of DISH 20.1, the eight-character (TMFT) is populated with the following Ticketing Fee fields when reporting a ticketing fee: . Service “Tax” Code (bytes 6-7) in TMFT positions 1-2 . blanks in positions 3-8

With the implementation of DISH 20.2 as the latest BSP standard, the eight character Tax Miscellaneous Fee Type field (TMFT) is populated with the following elements: . Service “Tax” Code (bytes 6-7) in TMFT positions 1-2 . Sub-code (bytes 8-10) in TMFT positions 3-5 (last character for Sub-code expansion) . Where applicable, TMFT position 6 will display the identifier reflecting the method of pricing for the carrier fee (0 = System priced without manual intervention, 1 = Priced with manual intervention) . TMFT positions 7-8 will be reserved for future use The implication of using these existing elements is that no changes will be required to settlement systems (BSP, ARC) to process these elements.

Note that the one major change to current practice is that the Form of Payment Amount (FPAM) and the Ticket Document Amount (TDAM) no longer add up to the ticket face total. They add up to a grand total amount comprising the complete customer collection, and therefore also represent the true agency remittance for the delivered product.

If an airline does not wish to charge any of these fees, then this solution requires no work for that airline.

If an airline does wish to charge these types of fees, they would need to create the new receipt as well as be able to identify OB code as Service Fees in their revenue accounting tax processing, At a more detailed level, the Validating Carrier may also wish to sub- divide by Service Fee Sub-Code in the revenue accounting process.

Pending Page E.03.S4.085 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

7.3 Summary of DISH and CAT Changes

The changes described above have been agreed by the BSP Data Interchange Standards Group (BDISG) in May 2006, and as such this group addressed the following items:

1) Correct structuring of the TMFT field as described allowing pass through of these elements by the DPC 2) Net remit methods to allow for correct net remittance when a commissionable fee is present in the transaction 3) Greater clarification of the ordering of the codes in TMFA as described above (TFC’s first in the sales file, followed by Service Fees and Taxes on Service Fees)

7.3.1 Net Remit Processing

As the solution designed incorporates the ticketing fee in the Tax Type and Tax Amount fields for BSP Reporting, Net Remittance is unaffected. The reporting of an OB ticketing fee on a ticket would be exactly the same as reporting any other tax. This has been verified by BDISG1 (see 8.3 above).

Pending Page E.03.S4.086 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

7.4 Ticket Exchange/ Reissue

When a Ticket Reissue is effected by an agent, the Ticketing Fees are deemed to have been consumed at the time of original issue, and so the Ticketing Fee from the original should not be considered in any way related to the financial transaction for the newly issued ticket in the case of Ticketing Fees. The following general rules apply:

1) The Service Fee for a transaction service is separate from the ticket charge, and therefore is applicable to each new issuance. 2) The Service Fee cannot be carried forward on the exchange reissue ticket either in part payment for the fare or for further Service Fees (if the fee is Ticketing Fee) 3) The Service Fee from the original issue will not be displayed in any way on the reissued reported sale transaction, either as a value or as a paid (PD) tax. 4) All new Service Fees attributable to the customer at the point of reissue or exchange will be reported in exactly the same way as described above.

Pending Page E.03.S4.087 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

7.5 Electronic Ticket Processing

A solution has been passed by the Joint Passenger Services Conference effective June 2006 which allows for the reporting of off-ticket Carrier Fee data for electronic tickets. The details of the data elements allowed can be found in IATA Resolution 722f, as well as in ATA Resolution 20.60. There is a great deal of granularity allowed within these fields, which are shown in Section 8.5.1. This will be sent to the Validating Carrier in the issuance message transaction. No further messaging is required because there is no requirement to interline or to refund the Ticketing Fee.

Once again this is on the understanding that the OB will be receipted to the customer but have no place on the printed face of the ticket from the electronic ticket (see above).

Currently the Resolutions do not allow for interlining or refunding of these fees. This is in concordance with the design of the S4 record, which is non-interlineable and non-refundable at this time.

These data elements include:

• Carrier Fee Type (OB) and Carrier Fee Code (Service Fee Sub Code) • Carrier Fee Amount and Currency • Airports from and to (as required) • Form of Payment details • Carrier Fee Tax Code and Amount • Carrier Fee Tax on Tax Code and Amount

Pending Page E.03.S4.088 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

7.5.1 Carrier Fee Data

ELECTRONIC TICKET MESSAGE CONSTRUCTION MATRIX - NEUTRAL MESSAGES NOTES: 1. Mandatory when used to cancel an 'Exchange/Reissue' Message 4. If a paper ticket is issued, the coupon status indicator ' T' is mandatory. 2. See Resolution for required combinations of 'Search Criteria' 5. This data element shall not be sent in an ' Information' Message (Section titled 'Display' under 'Procedures') 6. This data element applies to the new ticket. All other data elements in the Response Message apply to the 3. Used by the Validating Carrier to locate the document(s) being exchanged ticket coupon being exchanged.

A= Alphabetic Characters Only N=Numeric Characters Only A/N=Alphabetic and Numeric Characters Allowed C = Conditional (must provide if available/applicable) M = Mandatory (must provide at all times) O = Optional @ = Element Added in this Revision  = Element Changed in this Revision  = Deleted Element in this Revision Data Element No. Char- Issuance – Display History Exchange/ Reservation Refund Refund SYSTEM Void acters Information Display Reissue Change Cancel CANCEL A, N OR A/N Transaction Transaction Transaction Transaction Transaction Transaction Transaction TRANSAC Action Code Action Code Action Code Action Code Action Code Action Code TRANSAC Action Codes TION D H E A R Z V And W ACTION TION CODES ACTION CODES S AND I (I applicable X And Y to ATA only) 20.61/722g - 2007 MANUAL REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP CARRIER FEE DATA: Carrier Fee Type 2 A/N C C C © Carrier Fee Code 3 A/N C C C Carrier Fee Amount 12 A/N C C C Carrier Fee Application Code 2 A/N C C C Carrier Fee From Airport/City Code 5 A/N C C C Carrier Fee To Airport/City Code 5 A/N C C C Carrier Fee Form of Payment Type 24 A/N C C C Carrier Fee Form of Payment Credit Card 2 A C C C

Vendor Code Carrier Fee Form of Payment Credit Card 25 A/N C C C Account Number

Pending Page E.03.S4.089 Revised March 2017 Effective 3 December 2017 DATA APPLICATION FOR TICKETING FEES - VALIDATING CARRIER RECORD S4

A= Alphabetic Characters Only N=Numeric Characters Only A/N=Alphabetic and Numeric Characters Allowed C = Conditional (must provide if available/applicable) M = Mandatory (must provide at all times) O = Optional @ = Element Added in this Revision  = Element Changed in this Revision  = Deleted Element in this Revision Data Element No. Char- Issuance – Display History Exchange/ Reservation Refund Refund SYSTEM Void acters Information Display Reissue Change Cancel CANCEL A, N OR A/N Transaction Transaction Transaction Transaction Transaction Transaction Transaction TRANSAC Action Code Action Code Action Code Action Code Action Code Action Code TRANSAC Action Codes TION D H E A R Z V And W ACTION TION CODES ACTION CODES S AND I (I applicable X And Y to ATA only) 20.61/722g - 2007 MANUAL REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP REQ RESP Carrier Fee Approval Code (Credit Card) 6 A/N C C C Carrier Fee Expiry Date 4 N C C C Carrier Fee Tax Code 2 A/N C C C Carrier Fee Tax Amount 12 A/N C C C Carrier Fee Tax Currency Code 3 A C C C Carrier Fee Tax Application Code 2 A/N C C C Carrier Fee Tax on Tax Code 2 A/N C C C Carrier Fee Tax on Tax Amount 12 A/N C C C Carrier Fee Tax on Tax Currency Code 3 A/N C C C Carrier Fee Tax on Tax Application Code 2 A/N C C C

Pending Page E.03.S4.090 Revised March 2017 Effective 3 December 2017