Fragmentation of the market and the NDC challenge

Why NDC struggles to scale

The IATA Business Reference Architecture gives our industry a guide for how offers and orders move from offer to delivery. NDC helps create richer, more flexible offers, while ONE Order replaces old fulfilment records with a single order record. Both are linked through the larger Offer Order Settle Deliver (OOSD) framework.

The model seems simple in theory, but it has become complicated in practice. NDC and ONE Order are standards that have schemas, and MAR (Modern Airline Retailing) is an architecture based on the AIDM (Airline Industry Data Model). The whole system is called OOSD, but the growing number of schema versions has added complexity. For example, versions like 17.2 and 18.2 are still widely used, while some airlines are moving to 20.1 or 21.3.6. These versions differ in message structure, support for new product types, and personalisation features. Some airlines use older versions, others have the latest, and many use custom versions to meet their needs.

NDC was meant to simplify retailing. The version sprawl risks making it more complex than ever for vendors to deliver consistent capability.

For airlines, it’s a matter of choosing a version. For technology providers, especially those connecting Departure Control with Order Management Systems (OrMS), it is a constant balancing act. Each version needs its own testing and validation. Differences in schema, endpoints, and service definitions need to be aligned. These issues affect both the cost and speed of rolling out new retail features.

The problem gets even bigger in interline and multi-vendor settings. For example, imagine Airline X operating a codeshare flight with Airline Y and Airline Z: their Departure Control System may need to process NDC 17.2 messages for Y, 21.3.6 for Z, and a modified 20.1 for internal use, all in the same day. Juggling these moving parts without mistakes or delays turns a straightforward process into a complex one. This kind of fragmentation takes away the predictability that the reference architecture is meant to offer.

To help the industry adopt NDC and ONE Order faster, there should be a clear policy for version lifecycles. Airlines need support to move to new versions without keeping old ones forever. Vendors should be able to retire older versions as the industry progresses. Without this, the architecture could end up blocking the changes it was meant to enable.

Modularity and the next frontier in retailing

The industry’s first challenge was selling flights. NDC now makes it possible to offer better deals, personalised bundles, and more flexible pricing. Once an order is placed, OrMS takes over and sends data to the Delivery System, such as Departure Control.

But if the OrMS is too rigid, it can slow things down. The real opportunity is not just selling before departure, but also adding and fulfilling new products at any point in the journey, even after the passenger has travelled.

A modular Offer-Order Management (OOMS) lets airlines keep selling to customers even after the flight is sold.

An OrMS should be a flexible hub that can add retail options at any time. It should work with different Offer Management Systems and allow order items from any source. This includes airport services like lounge access and fast-track security, in-flight extras such as Wi-Fi and premium meals, and many post-flight or destination offers. These could be event tickets, excursions, chauffeur services, branded products, or local experiences.

Reaching this level of flexibility depends on using the right integration patterns. Technical teams can use APIs for communication, microservices for modularity, and event-driven architecture for real-time updates between systems. These approaches help airlines quickly add new products, connect with different partners, and provide a smooth retail experience across platforms.

For Departure Control, this is essential, as it’s where the customer's experience begins. If the OrMS can only send fixed service types, or if adding a new extra takes months of work or approval, we miss the chance to offer these services at key times like check-in, boarding, or arrival. This leads to lost revenue, less happy customers, and weaker loyalty.

True modularity means the entire process, from offer to delivery, can handle new products smoothly. OMS should accept new content quickly, the Delivery System should process it without changing schemas, and the customer should experience it as a natural flow of their trip.

If we can do this, Departure Control will be more than just the last step. It will become a real-time retail platform, helping airlines boost revenue, improve the travel experience, and build their brands long after the sale.