ATPCO Fare Filing: Fares, Rules & Footnotes—A Practitioner's Guide

If you build airline retail or pricing systems, ATPCO fare filing isn’t “legacy noise”—it’s the rulebook most of the ecosystem still plays by. Even if you’re racing toward dynamic Offers & Orders, the filed world powers interline, agency distribution, and servicing. Understanding it well makes modernization safer and faster.

1) Why this still matters

• It encodes policy, not just prices. Advance purchase, seasonality, who can buy, how you can combine—filed data describes the product you intend to sell, consistently, in every channel.
• It keeps you interoperable. GDSs, pricers, and settlement rely on shared semantics; filed fares are the lingua franca across carriers.
• It protects servicing and compliance. Refunds, changes, taxes, and disclosures lean on what you filed. Skip it, and you invite ADMs and disputes.

Modern pitfall: jumping straight to dynamic pricing without a bridge to filed fares. You’ll ship faster—and break more—than you expect.

2) How fare data flows

1. Authoring. Pricing/RM define base fares, attach rules and footnotes, and prepare batches.
2. ATPCO processing & distribution. Validation, normalization, and distribution to subscribed systems (GDS, pricing engines, tax engines, data lakes). This is a source of timing/latency mismatch.
3. Shopping & pricing. Engines combine itinerary + inventory (RBD) + your filed data to form priceable candidates.
4. Ticketing & settlement. Fare basis, endorsements, amounts, and references make it onto the ticket/EMD and drive reissues, refunds, proration, and clearing.

Reality check: Every hop (authoring → ATPCO → cache → seller) is a chance for your price to drift from host inventory. Design for it.

3) The core building blocks

• Fare record (base fare). Market, direction (OW/RT), currency, tariff, rule number, footnotes, dates, public/private flag, etc.
• Fare basis code. Short-hand label customers never see fully; the rules clarify its meaning.
• Rule number. Points to reusable rule content (categories).
• Footnotes. A way to share or scope conditions across multiple fares without duplicating data.
• RBD mapping. The inventory class a fare requires (e.g., Y, M, J). If the bucket closes, the fare isn’t usable.
• Optional Services & Branded Fares. Filed separately; used to define brand attributes and ancillaries in a standard way.
• Constructed, Cat 25/Cat 35. Build fares from parts (add-ons), transform bases, or carry negotiated/private amounts.

4) Rule categories (plain English)

Categories are just named chunks of logic. Here are the heavy hitters you’ll actually implement:

5) Footnotes, without the mystery

Footnotes are a scoping tool. A fare references a footnote code; that code maps to rows of category data that apply only when that footnote is present. The engine merges “base rule” + “footnote rows” before evaluation.

Tip: cache a compiled rule keyed by hash(ruleNumber + sortedFootnotes) to avoid re-merging on every quote.

6) Routing vs MPM (and construction)

• Routing numbers. A fare can point to a routing that spells out allowable paths (via cities, carriers, sometimes equipment). Think of it as a tiny grammar the itinerary must match.
• Maximum Permitted Mileage (MPM). Mileage-based validity: you’re good if the flown (with allowed tolerance) fits within the published cap for that market.

Constructed pricing stitches fare halves (e.g., domestic add-on + international half). After construction, run HIP (Higher Intermediate Point) and circle trip checks so you don’t under-collect versus an intermediate city.

7) YQ/YR, Cat 12, and taxes

• Carrier-imposed surcharges (YQ/YR). Filed separately and applied under conditions (market, cabin, etc.). They’re not the base fare but commonly shown with it.
• Category 12 surcharges. Rule-driven fees (e.g., specific DOW/season) that get applied before tax.
• Taxes. Driven by tax points and jurisdiction rules; accuracy matters for settlement. Use an authoritative tax feed/engine; don’t home-roll.

Rounding: Obey currency and market rounding rules; keep unrounded audit values.

8) A realistic pricing workflow

Input: O&D, dates, pax types, cabin, corp codes, itinerary shape

1. Get availability (RBD per segment).
2. Build candidate itineraries (time, connection, alliance constraints).
3. Fetch fare candidates by market/cabin/effective dates/POS.
4. Compile rules (base + footnotes) into a fast structure.
5. Fast filters: Cat 2/3/5/15 to shrink the set early.
6. Map itinerary to fare components; validate routing or MPM.
7. Deep checks: Cat 6/7, Cat 8/9, Cat 10, HIP/circle trip.
8. Add Cat 12 surcharges, then YQ/YR, then taxes via tax engine.
9. Normalize currency & rounding; emit a detailed pricing trace.

9) Keeping prices honest

• Determinism. Same dataset + same itinerary → same price. Hash the compiled rule set and surface it.
• Availability vs price drift. Detect when required RBD shut after quote; reprice on commit and flag staleness.
• HIP under-collection. Regression tests for multi-city and constructed scenarios.
• Tax drift. Daily diffs against the authoritative tax engine; alert on variance beyond tolerance.

10) Caching what actually helps

Cache compiled rules and light metadata, not whole priced itineraries. Invalidate by ATPCO deltas, expose dataset timestamps, and publish a “staleness” metric with each response.

11) Frequent failure modes

12) Engineering patterns that work

12.1 Normalize your internal model

Fare { id, O, D, dir, fareBasis, primaryRBD, tariff, ruleNumber,
       effective, expire, travelStart[], travelEnd[], private, ccy, amount, ptcs[], footnotes[] }

CompiledRule { key, ruleNumber, footnoteSet[], categories{...}, provenance{versions...} }

Availability { segmentKey -> { RBD: seats, updatedAt } }

PricingTrace { itinerarySig, fareComponents[], appliedCats[], surcharges[], taxes[], datasetVersion }

12.2 Evaluation strategy

• Cheap first. Cat 2/3/5/15 as early filters.
• Then shape. Apply routing/MPM once the itinerary is known.
• Then cross-fare. Combinability, HIP, circles after components are built.
• Service again later. Re-evaluate penalties/refunds at reissue time; keep the original snapshot.

13) Bridging to Offers & Orders

• Bridge service. Produce an Offer that either references a filed fare basis or a true dynamic bundle, but returns a unified schema.
• Lineage. For filed offers include fareBasis, ruleRefs, and dataset version; for dynamic include algorithm ID/inputs.
• Interline reality. Partners often still expect filed attributes—carry a dual representation until the network moves.
• Explainability. If you “nudge” a filed ladder with continuous pricing, store the base and the delta, clearly.

14) Where continuous pricing fits

• Use the filed fare as an anchor; apply a controlled, auditable adjustment.
• Respect tax computation rules and re-calculate accordingly.
• Set guardrails per market; on uncertainty, fall back to filed.

15) What to monitor

• Data freshness. Last ATPCO load, delta lag, compile backlog.
• Discrepancy sampling. Spot-check priced vs host.
• Category pass/fail rates. Spikes reveal data regressions.
• Latency budget. Stage-by-stage timings and cache hit ratio.
• Servicing success. How often change/refund automation works vs manual fallback.

16) A short implementation checklist

• Map lineage: fare → rule(s) → footnote(s) → compiled categories.
• Define an itinerary signature (airport + flight + date + cabin).
• Hash compiled rules into the response for reproducibility.
• Separate cheap filters from routing/HIP/Cat 10 work.
• Emit a human+machine pricing trace.
• Regression test HIP/circles and constructed cases.
• Detect availability drift and stale datasets.
• Keep a rollback plan for bad loads.
• Set allowed deviation from the filed ladder for continuous pricing.
• Automate tax-engine updates with comparisons.
• Expose an error taxonomy (e.g., ROUTING_FAIL, ADV_PURCHASE_FAIL, TAX_ENGINE_ERROR).

17) Mini glossary

• ATPCO: Industry platform distributing fares, rules, taxes, optional services to subscribed systems.
• Fare basis code: Encodes fare family and conditions; rules provide the full meaning.
• RBD: Inventory booking class (Y, M, J…); required seat bucket for a fare.
• HIP: Higher Intermediate Point—prevents charging less than an intermediate fare on the path.
• MPM: Maximum Permitted Mileage—cap on mileage for a market used in fare construction/validation.
• YQ/YR: Carrier-imposed surcharges (distinct from government taxes).
• Cat 25 / Cat 35: Fare-by-Rule transformations; negotiated/private fares.

18) Sources & further reading

• ATPCO: What are ATPCO fare rules categories?
• ATPCO: Branded Fares & Optional Services overviews.
• IATA: Maximum Permitted Mileage (MPM) manual and mileage suite.
• Travelport & Amadeus support docs on Cat 25, YQ/YR, mileage, and HIP.
• Industry primers on HIP and fare construction logic.

These are concept primers. For operational details, use your licensed documentation and data feeds.

19) Disclaimer

Back to all blogs