Daniel's been digging into something that sounds simple but isn't. Everyone says "passenger manifest" like it's one list — the names of everyone on the plane. He wants to know what it actually is as a data artifact. And his question is: which manifest? Because there are at least two distinct transmissions. One is Advance Passenger Information — API — drawn from the passport and the machine-readable zone. The other is the PNR, the Passenger Name Record, pulled from the commercial reservation system. And they're not the same thing at all.
He's asking us to take them apart field by field. What does each one carry? For the PNR, that means the commercial residue — payment method, who else is on the booking, the special meal request, the frequent flyer number, the travel agency, and whatever an agent typed into the free-text remarks field. Then the wire format — what it looks like on the wire, who built it, how old it is. The timing — when does each transmission fire, and does it re-fire if something changes? Who receives them — destination state, departure state, overflown states, and what happens on a codeshare where the marketing carrier and the operating carrier are different companies with different legal obligations. And finally, retention — how long do governments keep it, and what does the airline itself hold onto afterward?
This is a great question. It's one of those things where the phrase gets used so loosely that the actual machinery underneath becomes invisible. And the machinery is fascinating — and old. Really old.
So let's take the manifest apart. Starting with what actually gets sent, and why there are two of them.
The core thing to understand is that these two transmissions serve completely different masters. API is a border-control tool. It's about identity verification — matching you against watchlists before you even board. PNR is a law-enforcement and intelligence tool. It's about patterns — who you travel with, how you paid, what you ate, whether your booking looks like someone who's about to cause problems.
API is "who you are." PNR is "what you did."
API comes from the machine-readable zone of your passport — the MRZ. That's those two lines of text at the bottom of the photo page, the ones that look like gibberish when you squint at them. It's a fixed, standardized set of fields: full name, date of birth, gender, nationality, passport number, issuing state, and expiry date. Sometimes it includes your seat number if that's been assigned by the time the transmission fires. That's it. No commercial data, no payment info, no meal preferences. It's the minimum the border needs to run you through the system.
And the legal basis for API is international — ICAO, the International Civil Aviation Organization, sets the standards. It's baked into the Chicago Convention framework. Every state that's a party to that has basically agreed that this is how you identify passengers crossing borders.
Right. PNR is a different animal entirely. It's not drawn from your passport. It's drawn from the airline's reservation system — the commercial database where your booking lives. And it contains everything the airline knows about you as a customer. The booking reference, the ticket number, how you paid — cash, credit card, the last four digits — the travel agency that made the booking, your frequent flyer number, any special meal requests, the names of everyone else on the same booking, and then the free-text remarks field where an agent can type... anything.
The remarks field is the part that makes me uneasy. It's unstructured, unstandardized, and it's where agents type notes like "passenger was agitated at check-in" or "VIP — escort required" or just a string of internal codes that only make sense inside that airline's system. And that gets transmitted to governments.
And that's the thing — PNR is not standardized the way API is. ICAO has guidelines — Doc 9944 lays out a framework for what PNR data can be collected and how it should be handled — but the actual legal authority comes from bilateral agreements and national laws. The EU has its PNR directive. The US has CBP regulations. Canada has its own framework under CBSA. Each one defines the fields slightly differently, sets different retention periods, and has different rules about who can access it and for what purpose.
So API is the international standard with a clear legal home in the Chicago Convention. PNR is a patchwork of bilateral deals and domestic laws, all layered on top of a commercial data structure that was never designed for law enforcement.
And that's where the tension lives.
Now let's get into the weeds. What's actually in each transmission, and how does it get from the airline to the government?
Let me walk through the API fields first, because they're the clean ones. The machine-readable zone on your passport — that's ICAO Document 9303, by the way, which defines the format of travel documents globally — contains your surname and given names, your date of birth in a YYMMDD format, your gender as a single letter, your nationality as a three-letter country code, your passport number, the issuing state, and the expiry date. When you check in, the airline's departure control system reads that MRZ — either from the physical passport scan or from the data you entered online — and packages it into an API message.
And your seat number if it's assigned.
If it's assigned. Sometimes the API fires before seat assignment happens, especially on airlines that sell seat selection separately. In that case, the seat field is blank or filled with a placeholder. But the core identity fields are always there — they have to be, because the whole point is to let the destination country run you against their watchlists before the aircraft doors close.
Now the PNR fields. This is where it gets messier.
Much messier. A typical PNR contains the booking reference — that's the six-character alphanumeric code you get in your confirmation email — plus the ticket number, which is a separate ten- or thirteen-digit number. Then the itinerary: flight numbers, dates, origin, destination, and any connecting flights. Then the passenger details: name, contact information — phone, email — and any special service requests. That's where the meal request lives. Vegetarian, kosher, halal, diabetic, gluten-free — all of that is in the PNR.
Which means a government receiving PNR data can infer religion and health conditions.
Yes. And that's exactly why privacy advocates have fought PNR collection for years. The meal code doesn't say "this person is Muslim," but a pattern of halal meal requests on multiple flights is a pretty strong signal. Same with kosher meals, same with diabetic meals. It's not explicit identity data, but it's behavioral residue that reveals protected characteristics.
Then there's the payment information.
Payment method, billing address, and often the last four digits of the credit card. Sometimes the full card number, depending on the airline's system and what the bilateral agreement allows. Plus the travel agency that made the booking — including online travel agencies like Expedia or Booking dot com — and any corporate travel desk. The frequent flyer number, which links this booking to your entire travel history with that airline. And the companion names — everyone on the same booking reference, which reveals your travel companions even if they're not family members.
And then the remarks field.
The remarks field. This is the wild west. It's a free-text field in the reservation system where agents can type notes. It might say "passenger requested wheelchair" or "upgraded due to overbooking" or "VIP — meet at gate." It might contain internal codes — OSI, Other Supplementary Information, is a common one — that signal things to other departments. It might contain misspellings, abbreviations, or cryptic shorthand that only makes sense to the agent who typed it. And all of it gets transmitted to the destination government.
So you've got structured identity data from the passport, and then this rich, messy commercial dossier from the reservation system. Two completely different data artifacts, both called "the manifest" in casual conversation.
And they travel over completely different pipes, using a format that's older than most people listening to this podcast.
Let's talk about the wire format. Daniel specifically asked who built it and how old it is.
It's EDIFACT. UN/EDIFACT — Electronic Data Interchange for Administration, Commerce, and Transport. It was developed by the United Nations Centre for Trade Facilitation and Electronic Business, UN/CEFACT, in the late nineteen eighties. We're talking 1987, 1988. This is the era of fax machines and dial-up modems.
Thirty-nine years ago, give or take.
And it's still what moves passenger data between airlines and governments today. API uses a specific EDIFACT message type called PAXLST — Passenger List. PNR uses PNRADD or PNRACK — Passenger Name Record Add and Acknowledge. These are text-based messages with segment tags and data elements separated by plus signs and colons. They look like someone fed a database into a typewriter.
I've seen one. It's not pretty.
It's not meant to be pretty. It's meant to be machine-readable and extremely reliable over low-bandwidth connections. And it is — EDIFACT messages are compact, deterministic, and they work over basically any transport layer. But they're also rigid, hard to extend, and completely alien to anyone who's grown up with JSON or XML.
And there is a push toward XML-based standards now.
There is. ICAO has been promoting something called PNRGOV, which is an XML-based format for PNR data exchange. It's more flexible, easier to parse with modern tools, and it handles the messy stuff — like free-text remarks and special service requests — better than EDIFACT does. But the transition is slow. Airlines have decades of investment in EDIFACT-based systems. Governments have EDIFACT parsers that work. Nobody wants to be the first to break something that functions.
The classic "it works, don't touch it" problem.
Multiplied by the fact that you're coordinating between hundreds of airlines and hundreds of governments, each with their own upgrade cycles and budget constraints. EDIFACT is going to be with us for a long time.
Now the timing. When does each transmission actually fire?
API fires at check-in or departure, typically thirty to sixty minutes before the aircraft pushes back. The exact timing varies by country — some require it at check-in closure, some at door closure, some at wheels-up. But the principle is the same everywhere: the destination government wants to run the passenger list against its watchlists before the plane leaves the ground. If someone on the list is flagged, the government can issue a "do not board" instruction.
And if something changes after the initial transmission — someone swaps seats, or a standby passenger gets cleared — does it fire again?
Yes. API re-fires if the passenger list changes. If someone checks in late, or a seat assignment changes, or a passenger is offloaded, the airline sends an updated PAXLST message. The system is designed to keep the government's view of the passenger list in sync with what's actually on the aircraft.
PNR is different — it goes after departure.
PNR is transmitted after the flight has departed, often within twenty-four hours. Some agreements require it within thirty minutes of departure, some allow up to forty-eight hours. The logic is different from API. API is about stopping someone from boarding. PNR is about analyzing travel patterns after the fact — building a picture of who's moving where, with whom, and how they're paying for it.
And does PNR re-fire?
It can, but it's rarer. If the booking is modified after the flight — say, a refund is processed, or a frequent flyer number is added retroactively — the airline might send an update. But the post-departure window is the main event. After that, the PNR is in the government's hands, and any updates are at the margins.
So API is pre-departure, real-time, operational. PNR is post-departure, analytical, investigative. Two completely different rhythms.
And then there's the codeshare complication. Daniel asked about this specifically, and it's where the whole thing gets genuinely tangled.
Walk me through it.
On a codeshare, you buy a ticket from one airline — the marketing carrier — but the flight is operated by a different airline — the operating carrier. You might book through United, but the metal is Lufthansa. Your reservation lives in United's system. Your PNR is created there. But when you show up at the airport, you check in with Lufthansa. Lufthansa's departure control system reads your passport and generates the API message.
So the PNR is held by one company and the API is sent by a different company.
And they have to coordinate. The operating carrier needs enough PNR data from the marketing carrier to populate the API message correctly — at minimum, the passenger name and the passport details. But the full PNR, with all the commercial residue, may never be transferred to the operating carrier at all. So when the destination government comes asking for the PNR after the flight, it has to go to the marketing carrier — who may be in a completely different jurisdiction.
Which raises the question of who's legally obligated to send what.
And the answer depends on the bilateral agreements in play. The operating carrier is almost always responsible for API, because they're the ones checking passports at the gate. PNR responsibility can fall on either carrier, or both, depending on the agreement. Some countries require the marketing carrier to transmit PNR directly, even if they never touched the passenger. Others accept it from the operating carrier if they have it. And in some cases, both carriers send overlapping data, which creates duplication and confusion on the receiving end.
It's a data handoff problem dressed up as an aviation regulation problem.
And it's one of those things that mostly works until it doesn't. When a passenger is flagged after the fact and the government can't figure out which carrier has the complete PNR, you get delays, finger-pointing, and occasionally someone slipping through the cracks entirely.
We've got the data and the pipes. But who's on the receiving end, and what do they do with it?
The destination state is the primary recipient for both API and PNR. In the US, that's Customs and Border Protection — CBP. In Canada, it's the CBSA. In the EU, each member state has a Passenger Information Unit — a PIU — that receives and analyzes PNR data. That's a requirement under the 2017 EU PNR directive.
The departure state sometimes gets API too, for outbound checks.
Right. Some countries run exit controls — they want to know who's leaving, not just who's arriving. Russia does this. China does this. The US doesn't, at least not systematically, though there are circumstances where API is shared with the departure state under specific agreements.
And overflown states?
Typically they get neither. If you're flying from London to Dubai and you overfly half a dozen countries, none of them receive your API or PNR data as a matter of routine. The legal principle is that overflight doesn't constitute entry, so there's no border to control.
But there's an exception.
There's always an exception. The United States, for example, has arrangements that allow it to request PNR data for flights that overfly US airspace but don't land. This is tied to the no-fly list and broader counter-terrorism efforts. It's controversial — other countries see it as an extraterritorial reach — but it exists. And the legal basis is... let's call it creative.
If you're flying from Toronto to Mexico City and your flight path crosses over Texas, CBP could theoretically pull your PNR.
Theoretically. In practice, it depends on the airline's agreements and whether they've been served with a legal demand. But the capability is there.
Now retention. How long do they keep it?
This varies enormously. CBP retains PNR data for up to fifteen years. That's under their 2020 rule, which extended the previous retention period. For the first five years, the data is "active" — fully accessible for analysis. After that, it's masked and moved to a dormant database for another ten years, accessible only with supervisory approval.
Fifteen years is a long time.
It's a long time. The EU's PNR directive mandates five years — six months active, then four and a half years masked. Canada's CBSA keeps API for three and a half years and PNR data under a similar framework. Australia keeps PNR for five years. Each country sets its own clock.
And the airlines themselves?
Airlines retain PNR data for commercial purposes — typically five to seven years, though it varies. They need it for accounting, for loyalty program management, for dispute resolution. API data is retained for operational needs — usually a shorter period, maybe one to three years, though the legal basis for airline retention of API is murkier because it's not their data in the same way PNR is.
The airline created the PNR. It's their commercial record. API is government-mandated data they're required to collect and transmit — it's not really theirs.
Right. And that distinction matters when you start asking who can access what, and under what authority. The airline owns the PNR and is compelled to share it. The API is created because the government demands it, and the airline is just the pipe.
Let's talk about the privacy dimension. You mentioned meal requests earlier.
The meal request is the canary in the coal mine for PNR privacy concerns. It's not travel data. It's not identity data. It's a consumer preference that happens to reveal protected characteristics. And it's being collected, stored, and analyzed by governments for purposes completely unrelated to whether you got the vegetarian pasta.
The EU Court of Justice has weighed in on this.
Several times. The most significant was the 2017 opinion that led to the PNR directive being shaped the way it is — with the masking requirements, the independent oversight by PIUs, and the prohibition on using PNR data to infer racial or ethnic origin, political opinions, religion, health, or sexual orientation. The directive says you can't use the data for that. But the data is still in there. The meal code is still in the PNR. The prohibition is on the analysis, not on the collection.
Which is a distinction that works great on paper.
Less great when you have an analyst looking at a screen who can see the halal meal code and draw their own conclusions, regardless of what the rules say. The oversight is supposed to catch that, but oversight is only as good as the people doing it and the resources they have.
The free-text remarks field makes this even harder to control.
It's a data quality nightmare and a privacy nightmare rolled into one. Remarks are unstructured, often misspelled, full of abbreviations and internal codes that vary by airline and even by airport. Automated systems struggle to parse them reliably. But they're also the most valuable field for intelligence purposes, because they contain the stuff that doesn't fit in a structured field — the agent's impression, the unusual request, the flag that something seemed off.
A single line like "pax insisted on last-minute cash upgrade" could trigger a completely different risk assessment than the same booking without that remark.
The remark might mean nothing. The passenger might have just preferred to pay cash. But once it's in the system, it's part of the record, and it follows you for years.
Where is this heading? EDIFACT is ancient, the privacy tensions aren't going away, and the volume of air travel keeps growing. What does the future look like?
There's a push toward real-time API — transmitting passenger data continuously rather than in a single batch before departure. The idea is that governments could monitor passenger movements more dynamically, updating risk assessments as the flight progresses. But that blurs the line between API and PNR in ways that make privacy advocates very nervous. If API becomes a live feed, and PNR is attached to it, you've essentially created a real-time surveillance stream for every passenger on every flight.
The legal frameworks aren't built for that.
Not even close. The current system is built on a clear separation — pre-departure identity check versus post-departure behavioral analysis. If you collapse that into a single real-time feed, you need a whole new legal basis, new oversight mechanisms, and new retention rules. And getting dozens of countries to agree on that is... let's say it's not happening quickly.
The EDIFACT-to-XML migration is probably the easier half of the modernization puzzle.
Even that's taking decades.
Before we wrap, Hilbert's got a bone to pick with where this is heading.
Hilbert: I've been listening from the desk, and I've been chewing on something since about the middle of the episode. You two have been building this implicit case that PNR's commercial residue — the meal requests, the remarks, the payment details — is an overreach. That the system collects too much, keeps it too long, and infers too much from data that was never meant for government hands. I want to push back on that.
Hilbert: The data is already in the airline's system. Governments aren't collecting anything new — they're accessing a record that already exists, created by the passenger through their own choices. You chose the halal meal. You gave the agent your frequent flyer number. You paid with a credit card that leaves a trail. None of this is being extracted from you without your knowledge — you handed it over voluntarily when you booked the ticket.
Hilbert: The retention periods — fifteen years sounds long, but terrorist plots unfold over years. The nine-eleven hijackers' travel patterns were only visible in hindsight, across multiple bookings, multiple airlines, multiple years. If you purge the data after two years, you lose the ability to connect those dots. The EU's PIU model — independent units with oversight, masking requirements, audit trails — that's a genuine effort to balance security and privacy. It's not perfect, but it's not a surveillance free-for-all either.
I'll concede the data-existence point. The airline already has it. The government isn't planting bugs in the check-in kiosk.
The PIU model is better than nothing. Independent oversight, masking after six months — that's a real constraint.
But the meal request is still the line for me. It's not travel data. It's not identity data. It's a behavioral signal that reveals religion or health status, and it's being collected without a warrant, without individualized suspicion, and retained for years. The fact that I chose the vegetarian option voluntarily doesn't mean I consented to a government analyst drawing inferences from it five years later.
Hilbert: The inference is the problem, not the collection. And the EU directive explicitly prohibits using PNR data to infer religion or health. The rules are there.
The rules prohibit the inference. They don't prohibit the collection. And once the data is in the system, the inference is one analyst's curiosity away. Oversight is supposed to catch that, but oversight is retrospective — it catches the problem after it happens.
Hilbert: That's a real risk. I'm not dismissing it. But the alternative is what — stripping the meal code out of the PNR before transmission? That sounds clean, but it means modifying a commercial record before it reaches the government, which creates its own problems. Who decides what gets stripped? Under what authority? And what happens when the stripped field turns out to be relevant to a genuine investigation? We're trading one set of problems for another.
I think that's where we land. It's not a clear win for either side. The data exists, the security case is real, the privacy risk is real, and the oversight mechanisms are genuine but incomplete. Nobody's fully right here.
That's the tension we're left with — and it's not going anywhere soon.
The one misconception I want to nail down before we close: people think a passenger manifest is a single list. It's not. It's two separate transmissions, with different content, different timing, different legal bases, and different purposes. If you hear "manifest" and picture a clipboard with names on it, you're missing the entire architecture.
The architecture is what matters — because the architecture determines who sees what, when, and for how long.
The open question for me is whether the two transmissions eventually merge. As API moves toward real-time and PNR gets attached to it, the legal separation between pre-departure identity checks and post-departure behavioral analysis starts to blur. If that line disappears, we need a whole new framework — and I'm not sure anyone's ready to build it.
The passenger manifest, as it exists right now, is a mirror of how states see us. Not as individuals, but as data points in a risk matrix. The fields tell you what they care about. The timing tells you when they care about it. And the retention periods tell you how long they think they might need to care about you in the future.
Thanks to Hilbert Flumingtop for producing, and for pushing back on the privacy angle — it needed the push.
This has been My Weird Prompts. If you want to send us your own tangled question, email the show at show at my weird prompts dot com.
We'll be back soon.
