ATPCO sits at the center of global fare distribution. Airlines file prices, rules, and service data with it, and it relays that data to every major GDS from a single point.
The internal mechanics — how filings are indexed, keyed, and retrieved — are not public. What is public is the record structure: S5 defines a service, S7 defines when it applies. The open question is how that structure translates into the dynamic offers airlines are moving toward.
Ask a traveler how a fare gets from an airline’s pricing desk to their screen and you’ll usually get a shrug, or a guess about “the airline’s website.” The real path runs through a single company most passengers have never heard of.
ATPCO — the Airline Tariff Publishing Company — is where airlines file their fares, rules, and ancillary service data. It is also the point from which that data fans out to every major Global Distribution System. One submission, many channels.
That consolidation is why a fare filed on a Tuesday can surface in a travel agency’s system on Wednesday without the airline negotiating separately with each distributor.
The arrangement is older than most people assume. ATPCO has filed fares electronically under US Department of Transportation authority since the late 1980s, and electronic filing is now mandatory for fare tariffs. That regulatory spine is easy to forget when the conversation turns to “modern retailing.”
Which is the tension this article is about. Airlines want to sell dynamically — assembling an offer at the moment of search rather than filing it in advance.
The filing system underneath was built for the opposite. Understanding why the transition is slow means understanding what a fare record actually is.
How a fare actually reaches your screen
A fare is not a number sitting in a table. It is a package: a price, a set of conditions, and a list of what the passenger gets for it. Airlines submit that package — price and attributes together — to ATPCO in standardized data formats. ATPCO then distributes it to the GDSs, which is why a single filing can surface on an airline’s own site, a corporate booking tool, and an online travel agency without three separate submissions.
The scope of what moves through that pipe is wider than most travelers realize. Baggage allowances, taxes, and voluntary change rules are all handled through established, industry-agreed automated pricing standards.
A change fee that applies only to a specific fare class on a specific route is not a note in a PDF — it is structured data with a defined place to live.
Regulation sits underneath all of it. DOT granted ATPCO final approval to begin official electronic fare filings in December 1989.
A 1996 Federal Register notice — Docket No. 50355, Notice No. 12 — set the rules permitting international passenger fares and passenger-rule tariffs to be filed electronically, provided the formats were approved, and names the company as the first applicant cleared to do so. Today, Subpart R of Part 221 makes electronic filing mandatory for fare tariffs and associated data, and rule filings submitted electronically have to follow a DOT-approved format.
S5 and S7: the two halves of a single service
Under the legacy filing model, a service is described in two separate records. The Services record — S5 — is where the service sub-code gets assigned. Its descriptive and implementation attributes run from EMD type and SSR code to display category, booking method, reason-for-issuance code, service type, text, and commercial name, along with the maintenance dates that govern when the thing can be displayed, sold, and ticketed.
The Provisions record — S7 — answers a different question. Not what the service is, but who it applies to, and where, when, and under which passenger or fare conditions. Conditions covering passenger, market, cabin, and fare sit here, as do refund, purchasing, and settlement rules.
Baggage quantity is one example: an S7 provision can state how many pieces are included or set a total weight, name the item types allowed in formatted text, and define how a charge is calculated — per item, per kilogram, or as a percentage of the fare.
Keeping the two apart is deliberate. It lets an airline change a condition without redefining the service, and it lets the same service definition be reused across markets. It also means that answering a simple question — does this passenger get a free bag on this itinerary — requires the system to join two records at the moment of sale.
That join can happen at ticketing and again at check-in, when allowances and charges are worked out against cabin, passenger, journey, fare, weight, and piece conditions.
| Data element | Legacy S5/S7 representation | Product Catalog / dynamic-offer representation |
|---|---|---|
| Service identity | S5 assigns a service sub-code and service-type information. | ATPCO describes Product Catalog as a structured repository of airline products and services. |
| Commercial description | S5 can contain a commercial name and descriptive text for the service. | Product Catalog is intended to carry product attributes needed by airlines and sales channels. |
| Reason and ticketing implementation | S5 can contain RFIC, SSR code, display category, EMD type, and booking-related information. | Public description says product attributes are available to dynamic-offer participants; no one-to-one mapping published. |
| Eligibility by passenger, fare, and cabin | S7 provisions can vary a service by passenger information, fare information, cabin, and other conditions. | ATPCO says Product Catalog translates filed data into a standardized catalog; eligibility schema not published. |
| Journey or market applicability | S7 provisions define where and when a service applies, including market and journey conditions. | Product Catalog supports standardized exchange across traditional and dynamic systems; exact field mapping not documented. |
| Baggage quantity | S7 provisions can specify included pieces or total weight, with formatted text identifying permitted item types. | ATPCO’s Product Catalog documentation provides no public field-level representation for baggage quantity data. |
| Charge calculation | S7 can encode charge applications such as per item, per kilogram, or fare-percentage applications. | Retrieved Product Catalog documentation does not publish dynamic-schema fields or calculation semantics for this data. |
| Effective and maintenance dates | S5 includes maintenance dates for display, selling, and ticketing. | Retrieved documentation does not identify the corresponding catalog field or its date-resolution behavior. |
| Source: ATPCO product-preview document republished by Yumpu.com; ATPCO | ||
Superdeals cover departures from North America, Europe and Australia.
Flight deals most people never see
Air Traveler Club monitors thousands of routes for pricing anomalies that traditional search engines miss. With ATC Superdeals members save up to 80% on each flight vs. regular fares.
Too good to be true? Check it out yourself. It's free.
Delivered weekly. Unsubscribe anytime.
Where the public record stops
Here is the honest boundary. ATPCO publishes field-level applicability — what an S5 record can contain, what an S7 provision can vary. It does not publish its internal database indexes, lookup keys, or retrieval algorithms.
Those are the parts that determine how fast a query resolves and how the system behaves under load, and they are not in the public material.
The same limit applies to the migration story. No complete field-by-field equivalence table between legacy records and Product Catalog entries is published, and neither are the transformation rules applied to each legacy record. Nor does ATPCO disclose the internal logic for validation and conflict resolution.
That gap has a practical consequence. When standard filing interfaces cannot handle a particular fare structure or feeder class, airlines turn to third-party fare filing services — outside specialists who encode the data by hand. It is a workaround, not a feature, and it exists precisely because the standard interfaces have edges.
Which carriers have needed it, and for which structures, is not something the public sources establish.
Why separating product from price is the hard part
The Product Catalog’s stated purpose is narrow and consequential: separate product definitions from pricing so that offers can be assembled more flexibly than static filings allow. In the legacy model, price and attributes travel together — a complete offer is what gets filed. In a dynamic model, they cannot.
The product has to be defined once and priced at the moment of search, which means the two halves have to be addressable independently.
That is an architectural change, not a formatting one. S5 and S7 already split service definition from applicability, but both records are still filed in advance and retrieved as a set. A catalog that supports dynamic assembly has to let a pricing engine reach for a product definition without dragging its conditions along, then apply conditions afterward.
ATPCO’s own framing points to coexistence rather than replacement: the catalog converts already-filed data and lets traditional fare systems keep running alongside dynamic ones. Whether the catalog holds up as more offers are assembled dynamically is the part no public document answers.
Reporting by
Key terms
- S5 (Services record)
- S5 is the Services record in ATPCO’s legacy filing structure, the place where a service sub-code is assigned. It carries a service’s descriptive and implementation attributes, including EMD type, SSR code, display category, booking method, reason-for-issuance code, service type, text, commercial name, and the maintenance dates that govern when the service can be displayed, sold, and ticketed. Because S5 is filed in advance, its attributes are fixed at filing time — the constraint a dynamic-offer model has to work around rather than remove.
- S7 (Provisions record)
- S7 is the Provisions record, the half of the filing pair that carries the conditions determining when a service applies. Passenger, market, cabin, fare, refund, purchasing, and settlement conditions all live on S7, along with journey and market applicability. Those conditions can be applied by systems both when a ticket is issued and again at check-in, which is why the same filed service can produce different allowances at different points in a trip.
- Subpart R of Part 221
- Subpart R of Part 221 is the section of US Department of Transportation regulations that governs electronic filing of fare tariffs. It makes electronic filing mandatory for fare tariffs and associated data, and requires rule filings submitted electronically to follow a DOT-approved format. That mandate is why ATPCO’s filing pipeline works as a regulated utility: airlines cannot route around it, even as they push toward offers assembled at search time.
- Product Catalog
- ATPCO’s Product Catalog is a standardized repository of airline products and services. It is built to support exchange with both traditional fare systems and dynamic ones, and to convert data airlines have already filed into catalog form. What ATPCO does not publish is a complete field-by-field equivalence table between legacy records and catalog entries — the gap this article turns on.
Questions? Answers.
What is the difference between an S5 record and an S7 record in ATPCO’s filing system?
S5 is the Services record: it assigns the service sub-code and carries descriptive and implementation attributes such as EMD type, SSR code, display category, and booking method. S7 is the Provisions record, which carries the conditions determining when a service applies — passenger, market, cabin, fare, refund, purchasing, and settlement conditions among them.
Does ATPCO publish the internal indexes, lookup keys, or transformation rules behind its fare records?
No. Public material covers field-level applicability and how records are assembled, but ATPCO’s internal database indexes, lookup keys, and retrieval algorithms are not disclosed. The same applies to the migration path: no complete field-by-field equivalence table between legacy records and Product Catalog entries is published, and neither are the transformation rules applied to each legacy record.
When did ATPCO begin filing fares electronically under US Department of Transportation authority?
DOT granted ATPCO final approval to begin official electronic fare filings in December 1989. A 1996 Federal Register notice — Docket No. 50355, Notice No. 12 — set the rules permitting international passenger fares and passenger-rule tariffs to be filed electronically, provided the formats were approved.
Can S7 conditions be applied at check-in as well as at ticketing?
Yes. S7 conditions can be applied by systems both when a ticket is issued and at check-in, to work out allowances and charges — covering cabin, passenger, journey, fare, weight, and piece conditions.
