The ownership of travel data is up for grabs.

A PNR has never had one true owner

A passenger name record was designed, decades ago, to be a working document, not a title deed. It exists so that an airline, a GDS, and a travel agent can coordinate a booking, and it was never built with a field for "owner" because the concept did not seem to matter while the only parties reading it were the ones who created it. That design decision has aged badly. The same record now gets read, enriched, and re-sold by parties who did not exist when the format was standardised, and the absence of an ownership field has quietly become the absence of an ownership answer.

The commercial consequence is that four different organisations can each build a genuine, revenue-generating business on the same underlying trip, an OTA's remarketing engine, a GDS's data products division, an airline's revenue management system, a loyalty programme's co-brand card partnership, without any one of them needing the others' permission, because none of them is technically wrong about what they are allowed to do with the copy of the data they hold. The traveller, who generated the data in the first place, is not meaningfully a party to any of these arrangements.

This would be a purely academic problem if the data stayed put. It does not. Every one of those four parties has, over the last five years, expanded what it does with the record: enrichment against third-party identity graphs, cross-sell to adjacent verticals, training data for a recommendation model, and now, context for an AI agent acting on the traveller's behalf. Ownership ambiguity that was tolerable when the record sat quietly in a database becomes a live liability once the record is actively feeding five different systems that were never designed to reconcile with each other.

Five hands on every booking record

The distribution channel is the first hand, and usually the one the traveller believes they have a relationship with: the OTA or the airline's own site that took the booking, holds the payment relationship, and owns the customer-service conversation. This is the party a traveller thinks of as the data's home, and it is usually the party with the weakest actual claim to it once the booking is made, because most of what happens to the record next happens somewhere it does not control.

The GDS or NDC aggregator is the second, and the one with the longest institutional memory of the record: it hosts the PNR, mediates every subsequent change and cancellation, and in the traditional EDIFACT world effectively controls the canonical copy that every other party's copy is a snapshot of. NDC was supposed to change this by letting the airline hold the offer and order directly, which is precisely why the aggregators have not adopted it enthusiastically on their own initiative.

The supplier, airline or hotel, is the third, and the party with the strongest operational claim: they are legally responsible for the passenger manifest, the guest register, and the regulatory reporting that comes with actually delivering the service, which gives them a data retention obligation independent of what any commercial agreement says about ownership.

The loyalty programme is the fourth, often technically a different legal entity from the airline or hotel brand it sits under, and the party building the deepest longitudinal profile: years of stays, spend, and preference data that outlives any individual booking and is frequently the actual commercial asset being protected when a company insists it "owns" traveller data at all.

The agent is the fifth and newest hand, whether a corporate travel platform's booking assistant or the kind of consumer-facing agentic tool covered in our piece on what actually ships in agentic booking: a system that needs standing, broad read access to a traveller's preferences, history, and active bookings to be useful, and that access grant is a new attack surface and a new liability every time it is issued, independent of how carefully the four parties before it have governed their own copies.

Why the fight reopened now

NDC was pitched to the industry as a distribution upgrade, richer content, better merchandising, a modern API instead of an EDIFACT string. Underneath that pitch sat a deliberate re-architecture of who holds the offer and order data at all: instead of a GDS-hosted PNR that every party reads from a shared record, NDC lets the airline hold its own offer and order data and expose it to whoever it chooses, on terms it sets. That is a genuine transfer of control away from the aggregators that hosted the data for decades, which is precisely why GDS adoption of NDC has been so much slower and more contested than the airlines pushing it would like.

The EU's Data Act, in force from September 2025, changed the regulatory backdrop underneath this fight by giving users of connected products and services, a category broad enough to reach a meaningful share of travel technology, enforceable rights to access and port data generated by their own use of a service, and by placing new obligations on data holders to share that data on fair terms rather than treating it as a proprietary moat by default. It sits alongside GDPR's existing data portability right, but where GDPR was framed around personal data protection, the Data Act is framed around competition and access, which is exactly the framing that makes a GDS's or an OTA's data monetisation business harder to defend as simply "our data."

Agentic AI adds a third pressure that is less about new law and more about new exposure: every agent that needs to act on a traveller's behalf needs an access grant wide enough to be useful, and a grant that wide is a new place for a data-sharing dispute, a breach, or a regulator's inquiry to start, independent of whether the agent's own conduct was the problem. A traveller who revokes consent from an OTA has no straightforward way to know whether that revocation also reaches the loyalty programme, the GDS, and the three AI agents the OTA quietly grants read access to behind the scenes, and that gap is the specific thing the Data Act and its national enforcement bodies are now positioned to ask about.

The engineering discipline behind defensible ownership

Fixing this is not a data protection officer signing a new addendum to five vendor contracts, and treating it as a paperwork exercise is the most common mistake we see. A contract that says a party "may only use data for booking fulfilment" is unenforceable in practice if the underlying system has no way to distinguish a fulfilment read from an enrichment read. The fix, as with the illusion of choice in booking flows, has to happen in the data architecture, not the legal appendix sitting on top of it.

The first discipline is a consent object that is a first-class, queryable record, not a timestamp buried in a terms-of-service acceptance log. Every grant of access, to an OTA, a loyalty programme, an AI agent, needs to be a structured record with a scope, an expiry, and a revocation path that actually propagates, not a one-time checkbox that is assumed to hold indefinitely across every downstream system that ever touched the data.

The second is purpose-bound access, enforced technically rather than contractually: an AI agent booking a flight change gets a scoped token that can read the active itinerary and nothing else, not a standing credential to the traveller's entire seven-year history because that was the easiest integration to ship. This is the same discipline the guardrail layer in agentic booking already requires for tool calls; applying it to data access rather than transaction execution is a natural extension, not a new invention.

The third is a lineage ledger: a record of which system a given field of data originated in, which systems have since read or copied it, and when. Without this, a Data Act access request or a GDPR erasure request cannot actually be fulfilled with confidence, because nobody can say with certainty where every copy of the record currently lives, and "we think we deleted it everywhere" is not a defensible answer to a regulator asking for proof.

The fourth is a canonical profile with attributed writes: one traveller identity that every party's updates flow into and are tagged against, rather than five disconnected shadow profiles that quietly drift out of sync and produce the specific failure mode travellers already experience constantly, being asked for the same preference information for the fourth time because none of the five hands on their data actually share a single source of truth.

The commercial argument nobody budgets for

The case for leaving data governance ambiguous always rested on the same short time horizon as the illusion of choice in booking flows: every party gets to keep monetising its copy of the data without the friction of reconciling it with anyone else's claim, and the cost of that ambiguity, an unfulfillable erasure request, a breach that cannot be scoped because nobody can say who held what, a Data Act access request answered six weeks late, lands on a compliance team's desk long after the product decisions that created the exposure were made and long after the people who made them have moved to the next initiative.

Nobody currently owns the record cleanly enough to defend that ownership under cross-examination. That is not a compliance footnote. It is the actual state of the industry's most valuable asset.

Run the comparison over eighteen months rather than a single audit cycle and the businesses that invested early in consent objects, purpose-bound access, and lineage tracking are the ones who can answer a Data Act request, a GDPR erasure request, or a partner's data-sharing renegotiation in days rather than months, which increasingly is the actual competitive edge in a category where the underlying booking technology has otherwise become close to a commodity across competitors.

There is also a partnership dimension that rarely makes it into the initial business case: a loyalty programme or a corporate travel platform that can prove clean data lineage is a materially easier counterparty for a bank co-brand deal, a corporate account renewal, or an M&A data-room review than one that cannot, because every one of those transactions now includes a data governance diligence step that a genuinely tangled five-hands architecture will fail, or pass only with expensive manual reconstruction under deadline pressure.

Four questions before you claim you own your traveller's data

First, if a traveller revokes consent with you today, can you name every downstream system, partner, and AI agent that revocation needs to reach, and can you confirm it actually reached all of them. If the honest answer stops at "we've told our biggest partners," the smaller integrations you have lost track of are exactly where a regulator or a journalist will look first.

Second, could you produce, within the statutory window, a complete record of what data you hold on a specific traveller, where each field originated, and who else has a copy. If assembling that answer today would require a cross-team fire drill rather than a query, your lineage layer is theoretical, not operational.

Third, does every AI agent or automated integration with access to traveller data hold a scoped, time-bound credential, or does at least one of them hold a standing credential issued years ago because it was the fastest way to ship the integration at the time. Find that credential before an incident finds it for you.

Fourth, if two of your data partners each claim ownership of the same enrichment derived from a shared booking, who actually wins, and is that answer written down anywhere before the dispute happens rather than negotiated for the first time during it. If the honest answer is "we'd figure it out," that is the gap to close first, because it is the one every other answer in this piece assumes is already settled.

What this looks like in practice

A hotel loyalty programme came to us after a routine partner renegotiation surfaced an uncomfortable fact: three separate systems, the booking engine, the loyalty platform, and a marketing automation tool bolted on two years earlier, each held a slightly different version of the same guest preference profile, and none of the three had a record of which one was authoritative when they disagreed. The renegotiation stalled for six weeks while two commercial teams argued over whose data set to trust, a cost nobody had budgeted for because nobody had treated data lineage as a commercial risk until it directly blocked a deal.

We did not consolidate the three systems into one, which the client's existing vendor relationships made impractical on the timeline available. We built a lineage layer above all three: every write to any guest field was tagged with its source system and timestamp, a conflict-resolution rule set determined which source won when two disagreed, and a single canonical read API let every downstream consumer, including the marketing tool, query one consistent answer instead of three competing ones.

The partner renegotiation that had stalled closed within two weeks of the lineage layer going live, because the client could finally produce a single, defensible answer to "what do you actually know about this guest" on demand. A data subject access request that had previously taken the compliance team close to three weeks to assemble by hand now resolves in under two days. None of this required picking a winner among the three underlying systems, which is usually the fight that stalls this kind of project before it starts; it required making the disagreement between them visible and resolvable instead of silent and compounding, the same sequencing discipline we describe in why travel APIs are the new competitive battleground, where the fix lived in the contract and the data model long before it ever reached a partner-facing interface.