Walk into any airline distribution conversation in Lagos, Nairobi, Riyadh, or Dubai and you will hear NDC, GDS, EDIFACT, and now MCP used almost interchangeably. They are not interchangeable. They solve different problems, sit at different layers of the distribution stack, and confusing them leads to bad commercial decisions, the kind where an airline budgets for “NDC adoption” without understanding it does not replace their GDS relationship, or a sponsor pitches “AI distribution” as if MCP and NDC are competing standards rather than operating at entirely different layers.
Here is what each term actually does, and where the confusion usually starts.
EDIFACT is the old messaging language. NDC is the new one.
EDIFACT (Electronic Data Interchange For Administration, Commerce and Transport) is the decades-old messaging standard underneath most PNR creation, ticketing, and fare filing. It is not a company, a channel, or a product. It is a format, the electronic grammar airlines and GDSs have used to talk to each other for years.
NDC is IATA’s newer XML-based standard designed to replace that grammar with something richer. Where EDIFACT struggles to carry dynamic pricing, bundled ancillaries, or personalized offers, NDC was built to carry exactly that. NDC was also designed as the commercial foundation for modern Offer and Order management, allowing airlines to move away from the traditional separation between fares, tickets, and ancillary services toward a single retailing model. The confusion starts when people treat NDC as a sales channel. It is not a channel. It is a data standard that channels (GDSs, aggregators, direct connects) can choose to support.
Despite its limitations, EDIFACT remains deeply embedded across airline reservation systems, GDS workflows, corporate booking tools, and agency back-office systems. Replacing it requires coordinated investment across the entire distribution ecosystem, which is why most airlines today operate both EDIFACT and NDC simultaneously rather than choosing one or the other.
GDS is a channel. NDC is not a replacement for it.
A GDS (Global Distribution System, namely Amadeus, Sabre, and Travelport) is the intermediary infrastructure connecting airlines to travel agencies. This is where the “NDC will kill the GDS” narrative goes wrong. NDC does not eliminate the need for a distribution intermediary. It changes what kind of content moves through that intermediary, and in some cases shifts which intermediary an airline chooses to use.
The GDSs themselves have built NDC capability into their own systems. So an airline can run NDC content through a GDS, through an NDC aggregator instead, or direct to agencies. The standard and the channel are separate decisions.
Aggregators are not GDSs, and they are not NDC itself either.
Companies like Verteil, TPConnects, and AirGateway sit in the layer between airlines and agencies, consolidating NDC (and often non-NDC) content from multiple carriers into a single API. They exist because connecting individually to dozens of airlines’ NDC APIs is operationally heavy for most agencies. An aggregator is a business model and a piece of middleware. NDC is the standard it is built to handle. Conflating the two means assuming every aggregator handles distribution the same way, when their value differences are mostly about coverage, normalization quality, and how many non-NDC fallback sources they carry.
APIs are the transport. NDC is the language.
This is the layer most often skipped, and it is where a lot of the confusion above actually originates. Airlines expose their content through APIs, application programming interfaces, the technical pipes that let one system request data from another. NDC defines what information moves through those pipes and how it is structured. An airline can have hundreds of APIs, only some of which are NDC-compliant. Likewise, an API does not become NDC simply because it delivers airline content. A carrier can build a perfectly functional proprietary API that has nothing to do with the NDC schema at all. The pipe and the language spoken through it are two different things.
MCP is not a travel distribution standard. It is an AI interoperability protocol now showing up in this conversation.
This is the newest source of confusion, and the one most likely to mislead non-technical readers. MCP (Model Context Protocol) was built for AI agents to query and act on external systems, originally outside travel entirely. MCP has not become a travel industry standard. Rather, it is beginning to appear in discussions about AI-powered travel because it provides a standardized way for AI agents to interact with external systems. Several travel technology companies are experimenting with how AI assistants could use MCP to access airline content, but widespread production adoption remains in its early stages.
MCP is not a competitor to NDC in the sense of replacing the underlying data standard. NDC still defines how offer and order data is structured. MCP is closer to a new access layer on top, one that could change who or what is doing the querying (an AI agent instead of a human agent or a GUI). Where this lands in the next two to three years, particularly for African and Gulf carriers still building out core NDC capability, is unresolved. Treating it as a near-term replacement for NDC misreads both how immature MCP-in-travel still is and how much foundational NDC work most carriers in these markets have left to do.
Two terms worth clearing up while we are here.
LCC and PRASK get misused in distribution conversations too, usually as shorthand for things they do not actually measure. LCC (Low-Cost Carrier) describes a business model, not a distribution strategy. Plenty of LCCs run sophisticated direct and NDC distribution; plenty of full-service carriers still lean heavily on legacy GDS/EDIFACT flows. The two are independent variables.
PRASK (Passenger Revenue per Available Seat Kilometer) is a unit economics metric, not a distribution metric. It measures revenue efficiency per unit of capacity. Distribution channel mix affects PRASK indirectly, through cost of sale and the type of demand each channel captures, but PRASK itself says nothing about which channels, standards, or intermediaries a carrier is using.
Why this matters more in Africa and the Gulf, not less
In mature markets, this terminology confusion is mostly an internal nuisance. In markets where carriers are making first-time decisions about NDC investment, aggregator partnerships, and now early conversations about AI-driven distribution, conflating these terms has real budget and sequencing consequences. An airline that thinks “going NDC” means “leaving the GDS” may walk away from infrastructure it still needs. A carrier that hears “MCP” and assumes it needs to solve for AI agents before finishing basic NDC offer management is solving the wrong problem first.
The fix is not complicated. It is precision about what layer of the stack each term actually describes, and a willingness to say “that is not quite right” when these get blurred together in a sponsor deck, a panel discussion, or a budget meeting.
