Key Takeaways
- 17.2 remains the industry baseline – the first truly stable, industrialized NDC version built around offer and order structure. Airlines have invested so deeply in it that migration is a complex ecosystem exercise, not just a technical one.
- Resellers and aggregators bear the normalization burden, not just across NDC versions, but across the multiple variants a single airline provider may run within a single version.
- Interline is the hardest unsolved problem. It is not a technical gap alone. It requires renegotiating 40 years of contractual, settlement, and messaging frameworks between airlines.
- TPConnects has been ahead of the curve on every major NDC shift – certified on 15.2 in 2015, deliberately skipping 17.2 to prioritize ONE Order, and currently on 24.4 for its corrections to penalty payment and order item handling.
Why the Industry Is Still on 17.2
Since you were at the beginning of the NDC initiative, you probably know or have some versions of why many pioneers of NDC, like British Airways and American Airlines, still operate on their first material version of the NDC API, which is 17.2?
In my view, the main reason is that 17.2 was the first truly stable and industrialized baseline. It aligns the key factors of the offer and order structure.
If you look back at history, there were versions like 16.2 and 15.2 prior to 17.2. They were not focused on the offer and order structure. 17.2 is purely structured on offer and order, and it was built with the structure of order management and the servicing workflows.
Beyond that, it also supports the versioning capability. Sellers and retailers can communicate through that process, and there are a lot of commercial processes built on top of the 17.2 workflow.
This is the baseline for all airlines and has become integrated with all their ecosystems. That is the main reason airlines have invested heavily in this version, and migration to the next version carries a degree of complexity.
The urgency is growing now because a lot more standards have come. Furthermore, one of the most stable versions the industry has seen is 17.2. What is more, IATA currently supports 13 different versions of the NDC schema simultaneously.
What should resellers know about different versions, or do they just not need to care about them at all?
From a reseller’s perspective, resellers actually play a very important role in the normalization of it.
This is absolutely critical.
Though the industry talks about different versions, the same provider who works for an airline may offer different versions, and within those same versions, they have multiple variants for different airlines.
So, from the reseller’s perspective, it becomes difficult to normalize even within the same provider.
They have to handle multiple workflows for the same providers across different shopping, seat maps, and ancillary flows – be it piece-based baggage or weight-based baggage – and deal with servicing automation and reliability across all of those. So, from a retailer’s perspective, their job is really about the normalization layer. With so many API versions available, aggregators and resellers play a very critical role in normalizing the seller to see it in a consistent way.
The Versions That Actually Moved The Industry
Looking back, how do you think, which industry releases were the genuine breakthroughs? And what did they bring in?
I would highlight three versions in particular.
The first is 17.2, because it is the baseline for the offer and order. It introduced the offer and order capability and solidified the whole reshopping and servicing workflow. That is why it is the industrial baseline version.
The next is 20.2. The reason I call 20.2 a standard or guidelines version is that it is where the ONE Order schema really materialized. In 17.2, it was purely offer and order. But in 20.2, IATA brought in not just selling and retailing, but also order accounting and service delivery – the ONE Order part of it.
20.2 relies mainly on the ONE Order capability. The next stable version the whole industry has seen after 17.2 is 21.3. It combines both the selling capabilities and the ONE Order servicing plus delivery capabilities altogether.
21.3 is a very stable implementation, and most importantly, it has backward compatibility supporting all future versions from 21.3 as the baseline. Most recently, 24.1 – which is called next-gen NDC – has brought everything together: offer, order, disruptions, service, settlement, and delivery all in one comprehensive package. 24.1 is going to be another next-gen NDC breakthrough.
The Interline Problem That Needs To Be Solved
Let’s step back to 22.2, which added the settlement capabilities here. As far as I know, they are not widely adopted yet here. Why is it so?
There are several reasons. When we talk about ONE Order, there needs to be a system change – and we are not talking about just one or two systems.
For everyone to adapt to the order world and move away from the PNR world, all their order accounting platforms – which today are airlines’ revenue accounting platforms – have to switch to order-based accounting, where they have only orders and order items, not tickets or EMDs. That is a significant change to go through.
That is not going to happen over one or two years. The whole industry is transforming along with that. If you look at TPConnects, we have done a lot of work with providers.
We built ONE Order capability with Moriba and Lufthansa Systems, and other providers in the delivery space. There are a lot of constraints in the downline systems to adapt to that, and that is changing.
As far as I know, one of the issues with NDC is that it practically doesn’t support interlining. So again, as far as I remember, one of the 21 versions also brought new capabilities, but they don’t work fully. Can you explain why this doesn’t work the way it is expected?
Though NDC exists in the retailing space today, the one complexity the whole industry has to work through in a significant way is interline.
Interline is not just a retailing capability – it is making one airline a retailer for its supplier airline.
There are a lot of contractual things, rate parities, and settlement considerations involved. None of this was standardized before 20.2. The framework we call the META agreement in the interline world has been converted to the seller-retailer agreement in 21.3. The airline will actually do the retailing with its supplier.
They call an internal API in real time for offer generation in the supplier and retailer space, rather than using the old EDIFACT messages or availability messages. Because the standard is complex and very GDS-driven for indirect interlining, airlines are now looking at direct-connect interlining.
That is why it is taking a while – we had to re-establish 40 years of contractual frameworks plus messaging concepts. I do see IATA driving a vision to bring interline forward, and there are a lot of workshops underway that I am personally involved with at IATA. I see a lot of progress these days.
The model is essentially a one-to-one connection. Each airline connects to another airline and gets the supplier catalog.
So what are the available products that they are selling?
Each of them will have a repository of their partners’ products and will call in real time: “Do you have price and availability? Can I sell?” The retailing airline constructs the whole offer on behalf of all suppliers.
Within that offer, a settlement value agreed upon between the parties is encapsulated. While the offer is processed, real-time order accounting happens. They do not have to wait for the entire DPC and settlement process to prorate values between two airlines.
With one-to-one connectivity, everything is fully aligned with the bilateral settlement value between supplier and retailer.
When a new airline wants to jump into NDC, does it start with the most current version?
Yes. Even if it is now 24.4, it starts not with earlier versions but with 21.3.
Even 24.1 and today’s 25.2 are created from the foundation of 21.3 as a baseline version. Whatever version you pick is essentially a subset of 21.3. 24.1 is nothing but the sixth iteration of 21.3, renamed as 24.1.
And then it started emerging from that.
What 25.2 Is Really About
I also saw 25.2 in the list of available versions, but it is not implemented yet by anyone.
Not yet. As TPConnects, our latest version is 24.4.
We just recently got certified with 24.4, and 25.2 has just been released.
The main focus is on the payment catalog and something new called digital identity, because suppliers and retailers need a framework to identify each party in the chain. I am a seller, I go to a retailer, and the retailer goes to the supplier.
The whole distribution chain is actually encapsulated into a digital identity, put into the distribution chain. It’s called a verifiable credential. Same as blockchain in the payment mode.
It’s exactly how you identify the seller, the retailer, and the suppliers using the digital identity. Some of these extra things, like digital identity, and more enhancements on the service deliverable, and then the settlement value for the order accounting, all get normalized, including the multiple FOPs in the retailing and a few areas of disruptions, penalties, and the servicing structure. All this is updated in twenty-five dot two, more like in the one other perspective, and then the supplier retailer perspective.
As I mentioned earlier about interline, this version is also bringing more stable messaging between the supplier and the retailer. And it seems that when we talked about digital identity, the 21-something version also began to better identify different parties in the distribution chain.
This is an expansion of that capability. In the previous 17.2 baseline version, it used to be just party, sender, and receiver.
That was not sufficient to properly model the distribution chain. Whether the end seller is a corporate travel agency, a website, or a mobile app, there is a chain of activities going from the retailing airline to the seller, the aggregator, and then to the travel agency.
This distribution chain is an open-nested combination way of identifying who the seller is and how to identify the travel agency and which travel agent is making the changes, which is very helpful for the whole digital identity perspective. Today, Digital I.D. was introduced, which is very helpful both for the travel agency and for the travel agent. So that way we could well authenticate the travel agent and authorize the permissions for each of the travel agent who is making a booking.
Digital ID is going to play a major role. TPConnects is currently doing a POC on ONE Order, and One ID with IATA – our tagline for this concept is “ONE Order, One ID.” The One ID is going to make the differentiation for the supplier-retailer space as well as for sellers and the broader travel community.
Speaking of ONE Order, it seems that it was version 18.2 that pushed the needle forward to make a step towards the ONE Order scene, but currently, it seems that it’s not fully realized what is happening in this matter.
For ONE Order to come into place, downline systems have to make changes to receive or transmit the messages.
In the order accounting use case – one of the mature use cases today – the message that order management has to send is the Order Sales Information Notification, which contains all receivable and payable information sent to order accounting.
There are also settlement and clearance messages that order accounting processes for counterparties, whether suppliers or vendors. All these downline systems, not just the airline platforms but all related platforms, also have to adapt to these changes. So 18.2 was the baseline for ONE Order.
Today, 24.4 – which is very mature on the order accounting perspective – is being rolled out in many airlines. Some major airlines have already adapted to the Order Sales Information Notification. There is also a service delivery message update coming, equivalent to today’s passenger information.
PNL messages, check-in messages, and all these ancillary messages are converting to a ONE Order standard. When all this comes in place, tickets and EMDs are no longer required because all references change to the order item level. For each item, you have multiple service products, each with its own delivery tracking.
There is no longer a need for external reference numbers like EMDs or tickets. This enables airlines to make a lot of ancillary sales in the interline or codeshare space, because today, airlines cannot do interline ancillary or seat map display. Those complexities are being eased out by these standards.
This enables the free flow for an airline to do full sales in ONE Order message. The current 24.4 has brought in the standards for through check-in and baggage pass, and I am sure many more airlines will adapt to ONE Order messages in the coming years.
But does the NDC schema enable group bookings?
NDC schemas are not created to actually make a restriction, saying that you can make a booking only for nine.
The latest concept that we are working on is that in the old world, it’s always homogeneous, meaning you have to make a booking all tightly coupled to be homogeneous. You will get a price for the whole group of passengers. Today, there is no such limitation.
You can price for as many passengers as needed across different segment levels or brand levels. You can mix – economy on the outbound, and business or flexible economy on the return. You can mix and match different offers in any combination. There is no passenger limit and no restriction on mixing cabins or brands in NDC.
So you can easily use offer and order for group bookings beyond nine passengers?
Yes, today TMCs have started using NDC, which was not the case seven or eight years ago. All TMCs today are flowing into NDC channels, and in three to four years.
Once the whole workflow is streamlined behind the group booking, possibly the revenue release or the seat allocation, there is a workflow behind the group booking.
If that is formalized, I definitely foresee that TMCs and corporates are waiting to do the group booking without making all the manual or the offline, you know, process flows.
So all will be fully integrated in the API workflow with the platform distribution itself.
Read More: NDC Challenged for Airlines: Why It Takes So Long to Transform
What NDC capabilities are most underused now?
There are notifications, service logical flows, and some of the waivers and refund limits – these are not well-adapted at this stage. But the area I see the most untapped potential is ancillaries.
Airlines could connect third-party ancillaries and vendor ancillaries dynamically, not just limiting to their own airline ancillaries. The whole ancillary catalog could be opened up.
That’s what I see from my perspective that would still be underutilized.
What forces airlines to upgrade their NDC API version to invest in this move?
In my opinion, I see four factors.
The first is servicing performance. There were legacy issues in the past, and today it is all about true reshop – with real-time penalty calculations and real-time price differences displayed. That is on the servicing capability.
Another one is the commercial needs. Ancillaries and transparent rules for the order should be displayed. So this way they will be able to see the latest versions which have more commercial needs to it.
The roadmap alignment is also important. Airlines have to invest some of the part into their offer order driving factors as the latest version of 24.4, which gives more of their offer and order adaptability.
Last but not least is the partner pressure.
When key aggregators or corporates require the flows and definitely that airline has to actually make a move to do their upgrades, you know. So it’s always coming from the customer’s first perspective. When their aggregators are a larger audience of TMCs, everybody asks, why don’t you still be in something that why don’t you move on to 21.3, which gives us more benefits.
The partner pressure brings in the airlines to update the version. And what experts highlight is that many airlines don’t completely move from one version to another, but they just make it something like back 14 years. They just implement a couple of functionalities with the new schema, and all other things operate on the previous schema, for example.
So, is it good practice? How do you think of and what to do with it?
Upgrading versions is not just a technical exercise – it is a whole ecosystem. Airlines may have a lot of rules of engines built very tightly coupled to their previous APIs. So that makes them feel they have to do a partial migration, keeping one version for prime bookings and another for servicing.
Most airlines are thinking of having prime bookings in an upgraded version while keeping servicing in the older version, which creates something of a burden from the reseller’s perspective of having multiple APIs. But yes, it is all moving toward modern retailing. I think they are using this as a transition approach to move from legacy 17.2 to 21.3 or the latest 24 versions.
We can see it today – prime bookings happening in 21.3 and servicing in 17.2, with order management kept as the middleman making the exchange between APIs.
I see that TPConnects has been consistent – you are on 18.2 and 24.4, with no 17.2. Did you deprecate it or never work with it?
Great question. If I have to talk about TPConnects’ history, we are the first one to have a 15.2 API certified with IATA, which was in 2015. And then we adapted the 16.2 API, after that, we waited. We knew that a change was going to be a change happening in here because we knew there was a one-order resolution passed in there.
So we skipped 17.2 to focus on the ONE Order messages – that is why we jumped from 16.2 to 18.2, which supports ONE Order messages. We did an airline POC with ONE Order accounting at that time. 18.2 was a very stable version. We are now on 24.4, which also has a logical reason – there are a lot of corrections to penalty payment instructions and order items in 24.4, addressing feedback from 21.3. That is the major reason we chose 24.4 in our Astra platform. It is more stable.
Where NDC Goes From Here
How do you see the evolution of the NDC schema? What new features and directions is 2025 going to bring?
Speaking about offer and order – not really focusing on what NDC messages exist behind the screen, but offer, order, and settlement deliveries will be the key driving factor for airlines.
You may have also noticed that biometric passports and ePassports are now available. The real question is how much personalization an offer can bring for each seller, each frequent flyer, and how much value ancillaries can generate through dynamic bundling and dynamic price optimization – generating offers based on data science, not static fare rules.
That is the direction: a dynamic, not static, offer generated across sellers available. All these standards are coming in through the Digital ID concept – you just use your face as your credential; you do not have to carry anything, you simply walk through.
Airlines have to adopt a lot of the available technologies today, and that is exactly possible only through offer and order with the latest schemas.
How do you think – when tickets and EMDs will fully give way to ONE Order? When will it actually happen?
It took ten years for the whole travel industry to implement e-tickets. The whole technology is now evolving at a faster pace.
I would say maybe by 2028 to 2030, we would see the whole transformation effectively used. And the most complex part – interline – I think that will also fall in place around 2028 to 2030. The next five years are going to be interesting for everybody.
__________
Where does your organization stand on the NDC journey? Explore how schema evolution, ONE Order, and Digital ID are reshaping airline distribution, and what the decisions made today mean for the next decade.
