The Architectural Bottleneck of Legacy Distribution
For over forty years, the global airline ticket distribution ecosystem has functioned on an architecture designed during the mainframe era of the 1970s and 1980s. Under the traditional Global Distribution System (GDS) framework, airlines distribute their schedules through Innovata or OAG, publish published fare rules to ATPCO (Airline Tariff Publishing Company), and transmit seat availability statuses through EDIFACT (Electronic Data Interchange for Administration, Commerce and Transport) messaging.
This pipeline creates severe operational and commercial constraints. Fares must fit within exactly 26 discrete alphabetic booking codes (from Y and J down to restrictive deep-discount buckets like Q or V). Furthermore, the pricing calculations and fare rule evaluations take place inside the GDS datacenter, entirely decoupled from the carrier's live revenue management models.
When an airline attempts to sell an ancillary product—such as extra legroom seating, priority boarding, Wi-Fi access, or bespoke baggage tiers—the traditional EDIFACT messaging protocol struggles. Ancillaries require cumbersome Electronic Miscellaneous Documents (EMDs), requiring multiple asynchronous commands that frequently fail in automated travel agency environments.
Under legacy GDS: Travel Seller asks GDS -> GDS prices the ticket using filed ATPCO rules -> Airline confirms segment. Under NDC: Travel Seller asks Airline via NDC API -> Airline constructs the custom Offer -> Travel Seller confirms Order.
The NDC Architecture: Offers & Orders Lifecycle
IATA's New Distribution Capability fundamentally changes the flow of data by establishing direct XML and JSON messaging channels between airlines and travel sellers (or through GDS aggregators operating as NDC conduits).
The NDC transaction lifecycle revolves around two primary abstractions: the Offer and the Order. Instead of an agency terminal piecing together a reservation from disparate fare filings, the airline's internal Offer Management System dynamically determines the exact price and bundle based on contextual attributes (frequent flyer tier, route seasonality, booking channel, and ancillary availability).
Once the traveler selects an offer, the transaction transitions to the Order Creation phase, in which the airline's Order Management System generates a persistent, stateful order containing both flight services and physical ancillary fulfillments.
| Workflow Dimension | Traditional EDIFACT Distribution | IATA NDC Architecture |
|---|---|---|
| Fare Construction | Calculated inside GDS using ATPCO filed tables | Calculated dynamically inside Airline Offer Engine |
| Ancillary Retailing | Detached via EMD-A / EMD-S coupons | Natively bundled in primary AirShopping response |
| Pricing Granularity | 26 fixed fare classes (A to Z letters) | Continuous pricing curve (infinite price points) |
| Personalization | Zero contextual awareness (anonymous passenger) | Personalized offers via Frequent Flyer authentication |
| Average Search Latency | 150ms - 600ms (High-performance caching) | 1,800ms - 4,500ms (Live airline pricing compute) |
NDC API Payload Anatomy: AirShopping & OrderCreate
The standard NDC protocol relies on structured XML (such as IATA NDC 21.3) or modern REST/JSON wrappers. The primary entry point for flight availability is the AirShopping request. Below is a simplified representation of how modern travel platforms interact with an airline's NDC endpoint:
Notice how the response payload provides a unified OfferID. This OfferID is cryptographically signed and time-bounded by the airline, guaranteeing price stability for a configured TTL (e.g., 20 minutes) while preventing fare alteration.
{
"data": {
"type": "flight-offer",
"id": "OFFER_LH_98241_CONFIRM",
"source": "NDC_Lufthansa_v21_3",
"expiresAt": "2026-10-06T12:20:00Z",
"itineraries": [{
"duration": "PT8H45M",
"segments": [{
"departure": { "iataCode": "FRA", "at": "2026-11-10T10:15:00" },
"arrival": { "iataCode": "JFK", "at": "2026-11-10T13:00:00" },
"carrierCode": "LH",
"number": "400",
"aircraft": { "code": "359" }
}]
}],
"price": {
"currency": "EUR",
"total": "684.50",
"base": "510.00",
"taxes": "174.50"
},
"ancillariesIncluded": [
{ "type": "BAGGAGE", "quantity": 1, "weight": "23KG" },
{ "type": "SEAT_SELECTION", "category": "STANDARD" },
{ "type": "WIFI", "tier": "MESSAGING_UNLIMITED" }
]
}
}Engineering Challenges: Latency, Caching, and Disruption Management
While NDC offers unprecedented commercial freedom to airlines, it introduces significant technical hurdles for Online Travel Agencies (OTAs) and booking engines. The most prominent challenge is latency. In a legacy GDS environment, query caches deliver thousands of itinerary options in under 400 milliseconds. With NDC, querying twenty individual airline endpoints requires fan-out parallel HTTP execution, often inflating search response times beyond 3 seconds.
Furthermore, caching NDC results is notoriously hazardous. Because NDC offers are dynamically generated and expire rapidly, caching flight results can lead to high 'look-to-book' attrition and price-surge errors during final checkout.
Servicing and disruption management (IRROPS) represent the final major hurdle. When a flight is cancelled or delayed, legacy GDS automated queue systems allow travel agencies to execute exchanges via standardized CAT-31 rules. In NDC, agency servicing APIs are frequently immature, requiring manual human intervention or proprietary airline portal logins.
