The standards that exist, and what they were built for
The travel industry already has standards. NDC for airlines. OpenTravel for hotels and activities. FAPI 2.0 for payment security. So when the Activity Travel Protocol appears, the first question from any standards-aware operator is a fair one: why does the industry need another one?
The answer is not that the existing standards are wrong. It is that they were built for a different era — and that the Activity Travel Protocol is designed to work with them, not against them.
NDC — IATA's New Distribution Capability — transformed airline distribution. Before NDC, airlines and travel agents were connected by proprietary GDS interfaces that had not changed substantively since the 1970s. NDC gave them a modern, XML-based standard for pricing, availability, and booking. It was a genuine breakthrough, and it remains the foundation of airline distribution today.
OpenTravel did the same for hotels. The OpenTravel Alliance's message schemas cover availability, reservations, and a range of ancillary services. The hotel industry built its channel management infrastructure on OpenTravel, and that infrastructure works.
Both standards solved the problem they were designed to solve: connecting a single supplier type to a distribution channel, for a single product, in a transaction that begins and ends in one exchange. Query. Price. Book. Confirm. That model is not wrong. It is just not sufficient for what the AI era is bringing.
What the existing standards were not designed to handle
A complex activity booking is not a transaction. It is a lifecycle. A ski week in Nagano involves a hotel, a ski school, a taxi operator, equipment rental, and a mountain rescue registration. Each of those is a separate supplier. Each has different obligations to the traveller. Each needs to trust the others. And the booking does not end when the confirmation is sent — it continues through departure, arrival, activity fulfilment, and safe return home.
None of the existing standards model this. NDC has no concept of multi-supplier orchestration. OpenTravel has no workflow layer — it describes catalogue and reservation data, not the state of a booking as it moves through a complex itinerary. Neither standard was designed for AI agents making binding commercial commitments on behalf of travellers, or for the duty of care obligations that arise when a traveller is mid-journey and something goes wrong.
This is not a criticism of NDC or OpenTravel. They solved the problems that existed when they were written. The problem that exists now is different — and it requires a different layer.
The Activity Travel Protocol builds on existing standards, not over them
The Activity Travel Protocol's relationship to existing standards is one of deliberate coexistence. Where a standard is strong, the protocol adopts it. Where a standard is compatible but partial, the protocol aligns with it. Where the landscape is still forming, the protocol monitors and participates.
NDC bridge for air components
When a complex itinerary includes an air segment — as most multi-day trips do — the protocol maps that component to NDC-compatible representations. An operator that has already built on NDC does not need to abandon that investment. The air component participates in the protocol's Booking Object through a defined bridge, and the existing NDC integration continues to function.
OpenTravel alignment for accommodation and activity data
The protocol's schema layer is designed for compatibility with OpenTravel 2.0 message structures where they exist. Hotel and accommodation components in a Booking Object can be represented using OpenTravel-compatible data, reducing the migration burden for operators already working in that schema.
FAPI 2.0 for financial-grade API security
The protocol uses Financial-grade API 2.0 as its security standard for API interactions involving payment and booking confirmation. This is the same standard used by open banking implementations globally — battle-tested, regulator-recognised, and already familiar to the financial services teams at major OTAs.
A2A for AI agent communication
The protocol has adopted Google's Agent-to-Agent protocol as the standard for inter-agent communication at the discovery layer. As AI agents become first-class participants in travel booking — which is already happening — having a standards-based communication layer between agents matters. The protocol does not build a proprietary agent communication mechanism when an emerging standard exists for exactly this purpose.
Adoption does not mean starting over
The practical implication for an OTA or operator evaluating the Activity Travel Protocol is this: the standards you have already built on are not obstacles to adoption. They are part of the foundation.
NDC integrations remain valid for air components. OpenTravel-compatible data structures work within the protocol's schema layer. FAPI 2.0 security implementations transfer directly. The protocol adds the missing layer — the workflow, the multi-supplier orchestration, the duty of care tracking, the AI agent participation model — without requiring existing investments to be unwound.
This is how standards are supposed to work. Each layer builds on the one beneath it. NDC solved airline distribution. OpenTravel solved hotel and activity catalogue. The Activity Travel Protocol solves the booking lifecycle for complex, multi-supplier, AI-era travel. These are not competing answers to the same question. They are successive answers to successive questions.
The standards landscape for AI-native travel is still forming. The protocol's positions on specific standards are maintained as a living document — not locked into a blog post written at a point in time. For the current picture, activitytravel.pro/positions/ is the authoritative reference.