ATPCO Sales Data ExchangeSystem Specification andImplementation GuideMay 2022 (pending) 2020 ATPCO. All rights

Sales Data Exchange System Specification and Implementation GuideSummary of ChangesSectionChange7Updated Record 1 table, line 667Updated Record 8 table, line 7223 February 2022

Sales Data Exchange System Specification and Implementation GuideContentsSection 1Introduction .6Section 1.1 Purpose.6Section 1.2 Responsible Party .6Section 1.3 Change Control .6Section 1.4 Examples .6Section 1.5 Industry Sales Record .6Section 2ATPCO Sales Data Exchange Overview .7Section 3Data Representation .8Section 3.1 Alphabetic and Alphanumeric Elements .8Section 3.2 Numeric Elements .8Section 3.3 Data Validation .8Section 3.4 Sequence Number.9Section 3.5 Dates .9Section 3.6 Signed Data Elements .9Section 3.7 Facsimile Data Elements .10Section 4File Structure .11Section 4.1 File Specifications.11Section 4.2 File Structure to ATPCO .12Section 4.3 File Structure from ATPCO .15Section 4.4 ATPCO File Sorting and Sequencing .15Section 4.5 Sales Data Test Files from ATPCO.16Section 5ATPCO Processing .17Section 5.1 ATPCO Record Flow .17Section 5.2 ATPCO Processing Cycle .18Section 5.3 ATPCO Value-Added Processing .18Section 5.4 Industry Sales Record Process .19Section 5.5 ATPCO Processing and Data Security .24Section 6Record Structure By Transaction .26Section 6.1 Passenger Tickets .26Section 6.2 Canceled Tickets .27Section 6.3 Conjunction Tickets .29Section 6.4 Miscellaneous Document Transactions .30Section 6.5 Refunds.31Section 6.6 Student Data Processing .32Section 7File Layouts .33Inbound File Header To ATPCO .35Outbound File Header From ATPCO .35Address Label .35Record 1—Base Sale Record .36Record 2—Marketing Record (Optional) . 39Record 3—Additional Sales Data Record.41Record 4—Financial Record .42Record 5—Itinerary Record .44Record 6—NFP Proration Record (Optional).47323 February 2022

Sales Data Exchange System Specification and Implementation GuideRecord 7—Form of Payment Record .50Record 8—Fare Calculation Record.51Record 9—Exchanged Document Information Record (Optional) . 52Record 10—Coupon Tax Information (Optional).54Record 11—Netting Values Records (Optional) .56Record 12—New: Additional Itinerary Information (Optional) . 57Record 15—EMD Coupon Detail Record (Optional) .59Record 16—EMD Service and Baggage Record (Optional) .62Record 17—EMD Service Description Record (Optional) .64Record 18—EMD Remarks Record (Optional) .65Record 24—Exchange Detail Record (Optional) .66Record 25—Discount by Coupon (Optional).68Record 26—Airline Miscellaneous Sales Receipt (Optional) .69Record 27—Prepaid Ticket Advice (Optional) .70Record 28—Refunds and Vouchers (Optional).71Record 29—Agency Miscellaneous Charge Order (Optional) . 72Record 30—Additional Payment/Net and Commission Information (Optional) . 73Record 31—PTA Purchasers Info (Optional) .74Record 32—Transaction Header Record (Optional) .75Record 80—Fare Break Information Record (Optional) .76Record 81—Coupon Related Information Record (Optional) . 78Record 82—Priceable Unit/Ticket Related Information Record (Optional). 81Record 83—Coupon Tax, Fee, Charge Information Record (Optional) . 82Record 85—Coupon Schedules Information Record (Optional) . 85Record 90 – Frequent Flyer Informational Record (Optional). 87Record 97—NFP ISC and Handling Fee Record (Optional).89Record 98—RASS Interlineable Tax Record (Optional).91Record 99—NFP Proration Error Record (Optional) .93Section 8Record and Element Construction Rules .94Section 8.1 Conjunction Tickets .94Section 8.2 Use of Coupon Blocks in Itinerary and Proration Records . 96Section 8.3 Voiding .97Section 8.4 Coding for Codesharing .99Section 8.5 Codeshare Processing . 100Section 8.6 Refund File Structure . 102Section 8.7 Industry Sales Record—Data Element Hierarchy . 103Section 8.8 ISR BSP Data Exception Logic . 104Section 8.9 ISR ARC Data Exception Logic. 105Section 8.10 Transaction Types Included in ISR Processing . 106Section 8.11 Supplier Treatment of Repeated Records . 107Section 8.12 Structured Fare Calculation Records . 107Section 8.13 Reporting Standards for Ticketing Fees . 108Section 9ATPCO Value-Added Processing. 109Section 9.1 Codeshare Functionality . 109Section 9.2 Central Addressing . 111Section 9.3 Sales Data Exchange Plus . 111Section 9.4 Net Remit Data Removal . 111Section 9.5 Sales Data File Filtering. 113Section 9.6 File Conversions and Formats . 113Section 9.7 Sales Data Merging (ISR) . 114Section 9.8 Billing Value Determination . 114Section 9.9 Integration of Canceled Transactions into Associated Sale (ISR) . 114Section 9.10 ISR Special Processing . 115423 February 2022

Sales Data Exchange System Specification and Implementation GuideSection 9.11 Credit Card BIN Processing . 117Section 9.12 File Copy . 117Section 9.13 Duplicate Ticket Removal . 117Section 9.14 Conjunction Handling. 118Section 9.15 Backup Recovery . 118Section 9.16 Data Security Including Credit Card Data Masking . 118Section 9.17 Passenger Name Record (PNR) Encryption. 118Section 9.18 FNUM generation associated with BT/IT tickets . 119Section 10Glossary. 120523 February 2022

Sales Data Exchange System Specification and Implementation GuideSection 1Section 1: IntroductionIntroductionThe Airline Tariff Publishing Company (ATPCO) Sales Data Exchange Service—also commonly knownas ISR (Industry Sales Record) which includes TCN (Transmission Control Number), BSP (BillingSettlement Plan) and CAT data inputs—is a clearing house service open to all carriers (both air andground transportation), financial institutions (for example, credit card companies), and system providersregardless of size or nationality. The system provides data switching services between customers thathave contracted bilaterally for the exchange of data.Section 1.1PurposeThe purpose of this specification is to provide documentation of the exchange format for those parties (orfuture parties) participating in the ATPCO Sales Data Exchange.This format is an attempt to document all known (worldwide) data requirements that carriers will need toexchange in the near future. No one system provider can supply all the elements proposed in thisspecification, so individual contracting parties will need to document the level of compliance to thespecification. However, it is expected that system providers will supply the mandatory and optional dataelements described in Section 3.3.This specification provides for codesharing encoding and proration of coupons by external systems.Coding and specifications for these enhanced features will be documented as these systems aredeveloped.Section 1.2Responsible PartyThe information contained in the Sales Data Exchange System Specification and Implementation Guide issubject to constant review and is updated periodically. It is the responsibility of ATPCO to keep thedocument current. To assist in this process, direct inquiries and comments to [email protected] 1.3Change ControlA summary of changes will be published at the beginning of each revised publication of the ATPCO SalesData Exchange System Specification and Implementation Guide.Section 1.4ExamplesAll examples depicted in this specification guide are fictitious and are not intended to represent any actualbusiness relationship or agreement.Section 1.5Industry Sales RecordThe Industry Sales Record is a daily process that uses sales data transactions from the TCN, ARC CAT,and BSP HOT data files and combines these formats into a single data feed. The data is compiled field byfield and could result in one field being populated from the TCN, and one from ARC/BSP. An indicator inthe Record 1 Data Foundation (FNDT) will list the data sources considered during the compilation of theISR. When there is data for the same field from multiple data sources, the hierarchy or priority of the datafield will be used to populate the field. This hierarchy can be found in Section 8.7. The ARC (US agencysales) and BSP (non-US agency sales) files should be mutually exclusive.Note that all data elements and records relating only to ISR (that is, not present in TCN-only ISR or in theTCN standalone product) are shaded gray throughout the guide. These records and elements are shownin the record layouts in Section 7 and their element details listed in the Glossary (Section 10).All new customers will join the Sales Data Exchange as ISR receivers. Further details on the ISR processcan be found in Section 5.4.623 February 2022

Sales Data Exchange System Specification and Implementation GuideSection 2Section 2: OverviewATPCO Sales Data Exchange OverviewThe ATPCO Sales Data Exchange is a switching center (clearing house) and a value-added service (seelist of Value-Added processes in Section 5.3 and further descriptions in Section 9) for settlement, revenueaccounting, marketing, credit card, and ticketing data transmitted between carriers. The following schemaillustrates the flow of data.GDSAndThird PartyTicketingSystemsGDSAgencyTCNVersion 4.05HostedCarrierDirectReservations(eg. Sabre,Amadeus)Other Value AddProcessing(see Section 9)Third rectReservationsFrom CarrierCarrierInternalSystemsBSPAgency Data FromCarrierARCUS Agency Datafrom CarrierThird PartyDataTransmissionBSP/ARC AgencyData from iiNetNeutralFareProrationProcessCredit CardCompanySystemsBSP/ARC AgencyData from DPCFigure 2-A: Business Partners and Data Flow for ATPCO Sales Data ExchangeThe system was designed to support the bilateral agreements established between recipients of the dataand system providers supplying the data.For TCN 4.05–generated records that use an address label as described in Section 4.2, OpenAddressing, and are a part of the ATPCO codesharing service, ATPCO reports counts to the systemprovider and the marketing carrier (see Section 9.1).For transactions generated from BSP HOT or ARC CAT data, ATPCO addresses the ticketing transactionto the validating carrier, all marketing carriers in the itinerary, and all operating carriers determined by theATPCO Codeshare Process (see Section 9.1).723 February 2022

Sales Data Exchange System Specification and Implementation GuideSection 3Data RepresentationSection 3.1Alphabetic and Alphanumeric ElementsSection 3: Data RepresentationAlphabetic and alphanumeric elements shall contain left-aligned strings of characters with trailing blanks.If there is no entry, the entire element is blank. Facsimile fields must be reported precisely as they weregenerated by the ticketing system.Section 3.2Numeric ElementsNumeric elements shall be right aligned with leading zeros. If there is no entry, the entire element is filledwith zeros. When the data has passed through the Net Remit Data Removal process (see Section 9.2),the entire element is filled with nines.In numeric value amount elements, the decimal point shall be defined by the CUTP, which relates tothese specific elements. The Glossary (Section 10) lists all numeric values expressed in this way andrefers to the appropriate CUTP within the transaction.No element shall be packed.Low values and special characters should not be provided.Section 3.3Data ValidationSection 3.3.1 Mandatory, Conditional, and Optional StatusThe following conventions apply to data element descriptions:Where an element is annotated with status M in the Glossary (Section 10), the data is mandatory forproper processing and must be provided at all times. Mandatory elements may also includecross-edit conditions that provide for correct formatting of the data.A mandatory element that is within a non-mandatory record must be provided when the conditions forproviding that record are met. If the record is not provided, the mandatory element will also not beprovided.Where an element is annotated with status O in the Glossary (Section 10), the data will be providedwhenever available to the system provider.A data element will never be expressed as “Conditional.” It is either required in all cases (mandatory)or not required in all cases (optional).Certain records have associated conditions; for example, the Record 6 (Proration Record) is suppliedon the condition that the sale has been prorated. An element may be mandatory within aconditional record. Elements may also be optional within a mandatory record. See the Glossary(Section 10) for further detail at the element level.Section 3.3.2 Application of Cross-EditsWhere an element or a record has an associated cross-edit, the data should conform to the check asdescribed. These cross-edits are used at the record and data element levels to audit and report on dataquality standards within reported files.823 February 2022

Sales Data Exchange System Specification and Implementation GuideSection 3.4Section 3: Data RepresentationSequence NumberThe Sequence Number provides the receiver of data from ATPCO (that is, it is not used for incoming filesfrom system providers to ATPCO) with an integrity test to ensure that all records are received. With thestart of a transmission, the Sequence Number is set to 00000001 and increased by increments of 1 foreach record.In cases where not all sequences, as identified in the record header total count, are received, thenoperations evaluation must be performed and the data may need to be resent or retransmitted fromATPCO.Section 3.5DatesDate data elements are represented by various formats, such as these:Four-digit numeric dates shall be in the format of MMYY, whereMM is the two-digit number of the month, andYY is the last two digits of the yearExample: 1112 is November 2012, as in data element Expiry Date (EXDA)Five-character alphanumeric dates shall be in the format DDMMM, whereDD is the day of the month, andMMM is the first three letters of the month in English.Example: 12NOV is 12 November, as in data element Flight Date (FTDA)Eight-digit numeric dates shall be in the format of YYYYMMDD, whereYYYY is the four-digit year,MM is the two-digit number of the month, andDD is the day of the month.Example: 20121112 is 12 November 2012, as in data element Date of Issue (DAIS)Section 3.6Signed Data ElementsData elements are unsigned. The sign of the data element must be determined by the Transaction Code(TRNC). For example, a ticket sale (TKTT) implies positive amounts for the Fare (FNUM), EquivalentFare (EQFN), and Tax/Fee/Charge (TMFA) data elements, and negative amounts for deductions such ascommission (COAM, EFCO). A refund incorporates negative amounts for Fare, Equivalent Fare, andTax/Fee/Charge data elements, and positive amounts for deductions such as commission. Theremittance amount (REMT)—that is, the final settled amount between the agency and the airline—may bepositive or negative for any given transaction.923 February 2022

Sales Data Exchange System Specification and Implementation GuideSection 3.7Section 3: Data RepresentationFacsimile Data ElementsData elements that are defined as facsimiles contain data exactly as printed on the document or asentered by the ticketing agent for electronic tickets. ATA and IATA Ticketing Resolutions govern theformat of the data element. The concept of facsimile fields does not strictly govern the creation ofelectronic tickets because there is no print routine for this ticket type; however, these fields are generatedby the system provider and may be used for the printing of itinerary receipts or in display routines.Transaction Code(TRNC)TKTT(OPTAT)TKTT(OPATB)XXGLOSSARY OURXX1023 February 2022

Sales Data Exchange System Specification and Implementation GuideSection 4Section 4: File StructureFile StructureSection 4.1File SpecificationsMedium:Electronic transmissionRecord Size:442 bytes fixed length for the Input TCN Record sent to ATPCO136 bytes fixed length for the Input BSP HOT Record sent to ATPCO136 bytes fixed length for the Input ARC CAT Record sent to ATPCO400 bytes fixed length for the Output ISR/TCN Record from ATPCO to the subscriber.Block Size:27,600 bytes (the last block on any file transmitted may contain fewer bytes [fewer records]than described since it is not padded to fill the block).Availability:Files are available once a day, 7 days a week, via electronic transmission only.Security:Private Circuit (including iiNet)SSL FTP is requiredSecure ZipMasked Credit Card dataContact ATPCO at [email protected] for complete PCI ComplianceRequirements1123 February 2022

Sales Data Exchange System Specification and Implementation GuideSection 4.2Section 4: File StructureFile Structure to ATPCOSection 4.2.1 TCN File StructureThe file structure of TCN transmissions inbound to ATPCO Sales Data Exchange consists of oneTransmission Header Record followed by detail ticket records.TransmissionTransmissionHeaderRecordHeader RecordAddressDetail TicketDetail TicketRecord#1Record #1AddressDetail TicketDetail TicketRecord#2Record #2AddressDetail TicketDetail TicketRecord#3Record #3AddressDetail TicketDetailtoTicketRecord#nRecord to #nFigure 4-A: Input Records into ATPCO Sales Data ExchangeOn the inbound transmission to the ATPCO Sales Data Exchange from a system provider, carrier, orticketing system, the first record must always be the Transmission Header Record. This TransmissionHeader Record contains information to allow ATPCO to identify the type and origin of data and providesfor additional controls.After the Transmission Header Record, the rest of the transmission can be considered a simple postalsystem. ATPCO addresses the recipient carriers in the Address Label and attaches the ticketing data.ATPCO generates and propagates ticketing records by encoding the Address Label to codesharing andalliance partners upon instructions from the marketing carrier. An envelope is considered a completeticketing transaction addressed to one or more addressee. ATPCO, upon receiving the envelope, readsthe addressees and sends a copy of the envelope to each. The Address Label has the ability to send theenvelope to up to 14 different carriers. As ATPCO retransmits the envelope, it drops the Address Label.The system provider, carrier, or ticketing system can distribute their data by using either the addressing ofthe Address Label or ATPCO’s Open Addressing. ATPCO’s codesharing service has secondaryresponsibility for addressing the Address Label on certain tickets, if there is proper authority from themarketing carrier (initiated by the presence of a signed TCN Codeshare and Data Agreement). Thesystem provider, carrier, or ticketing system is responsible for identifying carriers eligible to receive theticketing data (validating carrier, any carrier in the routing, possible codesharing or alliance carriers, andany carrier participating as the credit card vendor, or the accounting carrier). The system providerpopulates the 42-byte Address Label with codes of eligible carriers with whom they have a bilateralagreement and attaches the Address Label to the data in the envelope.1223 February 2022

Sales Data Exchange System Specification and Implementation GuideSection 4: File CARRIER#1#2#3#4#5#6#7#8#9#10#11#12#13#14The ATPCO record formatwill begin in column 43 whendata is sent to ATPCO.Each of the receivingcarriers will receive only therecord format and not theAddress Label.1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 3 3 3 3 3 3 3 3 4 4 4 4 4 4 4 4 4 4 5 5 5 5 5 5 5 5 51 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8Figure 4-B: Carrier Address on Front of ATPCO RecordAll subscribers identified in this 42-byte label receive a copy of the ticketing information contained in theattached record. The 3-byte elements contain the two- or three-character Carrier Code representingvalidating carriers, carriers who take part in the itinerary, or carriers who are contractors of the creditcards. Each of the subscribers represented in Bytes 1 through 42 must be a party to the ATPCO SalesData Exchange.Open AddressingOpen Addressing opens the address envelope and includes all marketing airlines specified on any of theflight coupons within the Record 5 of the Industry Sales Record so that they will also get a copy of thissales transaction. Performing Open Addressing once at ATPCO eliminates the dependency on thecarrier-supplied addressing envelope, allowing for distribution to all marketing carriers in the itinerary.Open Addressing expands coverage for all customers without requiring additional development effortfrom carriers who supply data.The marketing carriers identified in the Open Addressing process are in addition to any airline orcompany that was supplied as part of the original sales transaction address envelope. Sales transactionswill be generated only for carriers that participate in the ATPCO Sales Data Exchange process.All standard Sales Data Exchange processes will be performed on transactions generated from OpenAddressing, such as codeshare and private data masking.The Open Addressing process will occur by default for all carrier-supplied sales, unless the supplyingairline requests otherwise. With this implementation, airlines no longer have to complete the addressingenvelope on the sales transaction unless they are addressing transactions to a company other than themarketing or operating carriers on the ticket (for example, credit card companies). ATPCO requests thatcarriers continue to send the credit card company on the address envelope.1323 February 2022

Sales Data Exchange System Specification and Implementation GuideSection 4: File StructureSection 4.2.2 BSP/ARC File StructureISR customers may choose to transmit BSP HOT and ARC CAT data files to ATPCO for onwardprocessing to their interline partners, and in some cases, for their own internal processing in an industrystandard format. These files must be sent by the validating carrier to ATPCO in the same format that theywere received from IATA or ARC. This format is specifie

Sabre, Amadeus) Carrier Internal Systems Carrier Direct Reservations From Carrier BSP Agency Data From Carrier ARC US Agency Data from Carrier Third Party Data Transmission BSP/ARC Agency Data from iiNet BSP/ARC Agency Data from DPC Other Value Add Processing (see Section 9) ATPCO Neutral Fare Proration Process Third Party Processing Systems