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