Daniel's been pulling at the thread of what actually happens when you book a flight — not the seat selection and the credit card form, but the data records that get minted the moment you hit purchase. He wants to know what a PNR actually is, what the airline's internal booking code is, and what that thirteen-digit e-ticket number means. Where does each one live, and when they disagree, which one wins? Which identifier is the thing that decides whether a human being gets on an airplane? And then — this is where it gets interesting — he wants to follow that record outward to the passenger manifest, specifically how the name field gets carried, because the name is where the whole thing breaks. Transliteration, maiden names, hyphens, middle names that exist on the passport but never made it into the booking. Who's doing the comparison at each checkpoint and how much tolerance do they have? The question underneath all of it is why an industry that settles billions on exact numeric identifiers still uses a human name as the key that has to match.
So let's start inside the systems, not at the counter. A booking is not a single record. It's a constellation of identifiers scattered across at least three different layers — the airline's own reservation system, the global distribution system or GDS that sits between airlines and travel agents, and the interline settlement layer that handles the money. And each layer has its own idea of what "the booking" is.
Three layers, three identifiers. Walk me through the one everyone knows — the six-character code on the confirmation email.
The PNR. Passenger Name Record. It lives in the airline's reservation system, or in the GDS if you booked through a travel agent or an online travel agency that sits on top of a GDS like Sabre or Amadeus. The six-character alphanumeric code — something like HX4B2K — that's the record locator. It's a key, not the record itself. Think of it as a session ID. You give the airline that code, they pull up the PNR, and inside the PNR is everything: your itinerary, your name, your contact details, seat assignments, special meal requests, whether you've checked in. It's a container.
And the container itself — is it standardized? Does every airline's PNR look the same?
Broadly, yes, because the GDS systems enforce a structure. A PNR has mandatory elements — name, itinerary, contact — and optional ones like frequent flyer number, special service requests. But here's the thing: the PNR is not a financial document. It's a reservation. You can have a PNR with no ticket attached to it — that's a held booking, the thing that expires after twenty-four hours if you don't pay. The PNR says "this person intends to fly." It does not say "this person has paid."
So the PNR is the intention. The ticket is the receipt.
And that brings us to the second identifier — the airline's internal booking code. This one is messier because it's not standardized across carriers. Some airlines use a numeric code, some use a longer alphanumeric string. It lives in the airline's departure control system — the system that actually runs the flight on the day of operations. The PNR feeds into it, but the internal booking code is what the gate agent's screen is really looking at when they scan your boarding pass. It's the operational record.
And the thirteen-digit e-ticket number — that's the third one, and I'm guessing that's where the money lives.
That's the financial instrument. The e-ticket number is issued by IATA, and it's structured: a three-digit airline code plus a ten-digit serial number. So zero-one-six is United Airlines, zero-zero-one is American, one-two-five is British Airways. That number lives in the airline's e-ticketing database, and it's what gets used for interline settlement — when you fly on a ticket issued by one airline but operated by another, the e-ticket number is how they settle the revenue between them through IATA's Billing and Settlement Plan, or BSP. In the US, there's a parallel system called ARC.
So we've got three identifiers: the record locator that the passenger sees, the internal booking code that operations uses, and the e-ticket number that finance uses. Which one is canonical when they disagree?
Depends on what you're asking. For revenue and settlement, the e-ticket number is the authority. If the e-ticketing database says you paid, you paid — even if the PNR somehow got corrupted. For the itinerary and passenger identity, the PNR is canonical — it's the source of truth for where you're going and who you are. The record locator is just the key to get into the PNR. It's not authoritative itself.
So the code on the confirmation email — the one everyone screenshots and saves — is basically a URL.
A URL that expires, yes. And that's the first misconception most people have. They think the record locator is the booking. It's not. It's a pointer. If the PNR gets purged or merged or split — and PNRs do get split, for example when one passenger on a booking changes their itinerary — your record locator might point to something different than what you expect.
Which brings us to Daniel's real question. Which of these actually decides whether you fly?
None of them, directly. The e-ticket number proves you paid. If there's no e-ticket number attached to your PNR, you're not flying — the system won't issue a boarding pass. But having a valid e-ticket number doesn't get you on the plane either. The thing that gates boarding is the name match between your PNR and your passport. The name is the de facto decision point.
So an industry that runs on exact thirteen-digit numbers for settlement puts the go/no-go decision on a human name. A string. Free text.
Often free text. That's the second big misconception — people assume their name is stored as structured data, given name here, surname there. In a lot of reservation systems, it's a single field. The PNR stores the name as one string, and the system parses it — sometimes correctly, sometimes not. And that parsing has to survive being copied into the passenger manifest, transmitted to border authorities, and matched against a passport that was issued by a completely different system in a different country with different naming conventions.
Let's trace that data flow. What actually gets copied out of the PNR into the manifest?
The passenger manifest — technically the API, Advance Passenger Information, or the APP, Advance Passenger Processing, depending on the jurisdiction — is a message the airline sends to the destination country's border authority before the flight departs. It contains name, date of birth, passport number, nationality, and seat number. Sometimes gender. The name field in that message is carried as a single string — the same string that was in the PNR. There's no structured separation of given name and surname in the standard API transmission format. It's just... the name.
So whatever the booking agent typed, or whatever the website parsed from the passenger's input, that's what gets sent to the border authority.
And now we hit the name matching problem from both sides. Let me start with the passport side. The machine-readable zone on a passport — the two lines of text at the bottom — uses a constrained Latin character set. ICAO, the international civil aviation organization, specifies that the MRZ can only contain A through Z, zero through nine, and the less-than sign as a separator. No diacritics. No hyphens. No apostrophes. No spaces in the name field — spaces get converted to less-than signs.
So if your name is José Muñoz, the MRZ reads... what?
JOSE MUNOZ. The accent gets stripped, the tilde gets stripped. If your name is Anne-Marie, it becomes ANNEMARIE. No hyphen. If your name is O'Connor, it becomes OCONNOR. The MRZ is a brutal, lossy encoding of your actual name.
And the reservation system, meanwhile, might have accepted the accented characters. Or the hyphen. Or the apostrophe.
It might have. Or it might have rejected them. Different airline systems handle this differently. Some accept Unicode, some strip to ASCII, some allow hyphens but not apostrophes. And the passenger has no way of knowing what the system did to their name when they booked. They typed "José Muñoz" into the website, the website showed "José Muñoz" on the confirmation page, but what actually got stored in the PNR might be "JOSE MUNOZ" or "JOSE MUNOZ" with some mangled character encoding or — and this happens — "JOSE MUNOZ" with the accented characters replaced by question marks.
Question marks. In a name field that has to match a passport.
Question marks. And now layer on the naming convention collisions. Maiden name versus married name — the passport might say one thing because it was issued before a marriage, the booking might say another because the passenger used their married name out of habit. Double-barrelled surnames — the passport MRZ says SMITHJONES but the booking says Smith-Jones, and the matching algorithm has to decide if that's the same person. Hyphenated given names are even worse because some cultures treat the hyphen as significant and some don't.
And then there's ordering. Surname first, given name first.
This is where it really falls apart. Chinese names, Korean names, Japanese names — the family name comes first. A passenger named Wang Wei has the surname Wang and the given name Wei. The passport MRZ reflects this correctly because ICAO standards require the surname to be at the beginning of the name field, separated from given names by a double less-than sign. So the MRZ reads WANG WEI, with the structure encoded in the separators.
But the reservation system might not know that.
The reservation system asks for "first name" and "last name." A Chinese passenger booking on a US airline website sees "first name" and thinks — reasonably — that means their given name, Wei. They type Wei in the first name field and Wang in the last name field. The PNR now stores the name as Wei Wang. The passport MRZ says Wang Wei. The API message sends Wei Wang to the border authority. And now an automated system has to decide whether Wei Wang and Wang Wei are the same person.
And the system doesn't know which culture's naming convention to apply because the PNR doesn't store that metadata.
It doesn't. There's no field for "name ordering convention." There's no flag that says "this is a Chinese name, family name first." The system just has two strings and a matching algorithm.
Middle names. Daniel mentioned those specifically.
Middle names are a nightmare. The passport has the full legal name — first, middle, last. The booking might have only first and last because the website didn't require the middle name, or the passenger didn't think to include it, or the booking system truncated the name field. The MRZ includes middle names concatenated with the given name, so John David Smith becomes JOHNDAVID SMITH in the MRZ. But the PNR might just say John Smith. The matching algorithm sees JOHNDAVID versus JOHN and has to decide — is this the same person or not?
We've got character set collisions, transliteration losses, hyphen handling, ordering reversals, and missing middle names. Who's actually doing the comparison at each checkpoint, and how much tolerance do they have?
Three checkpoints, three different tolerance levels. The first is the check-in agent — a human being. They have the most discretion. If the name on the booking says "Jon Smith" and the passport says "Jonathan Smith," the agent can see that it's the same person and override the system. If there's a minor typo — "Jhon" instead of "John" — the agent can make a judgment call. They're trained to handle these edge cases, and they have the authority to accept a name that doesn't exactly match.
And the second checkpoint?
The airline's departure control system. This is automated. When you check in online or at a kiosk, the system is comparing the name you entered against the name in the PNR and the name in the API transmission. It uses fuzzy matching algorithms — things like Soundex, which encodes names phonetically, or Levenshtein distance, which measures how many character changes are needed to turn one string into another. The system flags mismatches but can be overridden by an agent. The tolerance here is configurable — each airline sets its own threshold for what constitutes a match.
The third checkpoint is the one with no sense of humor.
The destination border authority. US Customs and Border Protection, for example, has near-zero tolerance for name mismatches. They receive the API message before the flight departs, and they run it against their watchlists and their own databases. If the name on the manifest doesn't match the name on the passport — even a minor discrepancy — they can deny boarding. Not deny entry at the destination. Deny boarding at the point of departure. The airline gets a "do not board" message, and the passenger never leaves.
The airline is on the hook for the cost of rebooking and any fines.
Airlines face significant penalties for carrying passengers with mismatched documentation. In some jurisdictions, the fine is per passenger and it's substantial — tens of thousands of dollars. So the airline has a strong incentive to catch mismatches before departure, which is why the check-in agent's discretion has limits. They can accept "Jon" for "Jonathan," but they're not going to accept "Wang Wei" for "Wei Wang" without documentation proving the passenger is the same person.
The paradox Daniel's pointing at is real. Interline settlement runs on exact thirteen-digit numeric identifiers — the e-ticket number has to match perfectly or the money doesn't move. But the passenger identity check runs on a human name that's been through a woodchipper of character set conversions, transliterations, and cultural naming convention collisions. Why hasn't the industry moved to something more reliable?
Part of it is legacy systems. The PNR format dates back to the nineteen sixties and seventies, when airline reservation systems were built on mainframes. The name field was designed for a world where most passengers had simple Anglo names and flew domestically. The system was never redesigned for a global passenger base with diverse naming conventions.
But it's been fifty years. They've had time.
They've had time, but they haven't had a forcing function. Replacing the PNR format would require every airline, every GDS, and every border authority to upgrade simultaneously. That's hundreds of systems, many of them running on code that nobody fully understands anymore. The cost and risk of a coordinated migration are enormous, and the current system — for all its flaws — mostly works. Most passengers fly without name-related issues.
Mostly works. Mostly.
Mostly. But when it fails, it fails hard. A passenger with a hyphenated name who booked through a travel agent in a different country, whose passport was issued under a maiden name, and whose middle name was omitted from the booking — that passenger is going to have a very bad day at the airport. And those edge cases are not rare. They're common enough that every check-in agent has stories.
The cost isn't just passenger frustration. It's denied boardings, rebooking fees, hotel rooms, missed connections, lost revenue.
The industry doesn't publish aggregate numbers on name-mismatch denials, but anecdotally — and I've talked to enough gate agents over the years — it's a daily occurrence at any major international airport. A few passengers per flight, flagged for name issues. Most get resolved at the counter. Some don't.
The system works because humans are in the loop, not because the data architecture is sound.
The tolerance at each checkpoint — the agent's discretion, the fuzzy matching algorithms, the override capability — those are patches on top of a fundamentally fragile data model. The name field was never designed to be a secure identifier. It was designed to be a label.
A label that now has to serve as a security credential.
That's the tension. The name is simultaneously the most human-readable identifier and the least reliable one. It's full of ambiguity — cultural, linguistic, typographical — and yet it's the key that gates access to a multi-billion-dollar industry's core product.
Let me ask you something. Why not just use the passport number as the primary identifier? It's unique, it's machine-readable, it's already in the PNR.
Passport numbers change. When you renew your passport, you get a new number. If you booked a flight six months ago with your old passport number, and you show up at the airport with your new passport, the numbers don't match. The name is the only stable identifier across passport renewals.
The name is the least bad option among a set of bad options.
The name is the only option that persists across the entire lifecycle of a traveler's relationship with the system. Passport numbers change. Frequent flyer numbers change if you switch programs. Even date of birth can be mis-entered. The name — however mangled — is the one thing that follows you from booking to boarding to border control.
That's almost poetic. The most fragile identifier is also the most durable.
It's the duct tape holding the whole thing together.
Alright, before we go further down this road, Hilbert's been sitting at the desk making faces at everything I've said. What've you got?
Hilbert: I'm going to argue the other side of this, and I want to be clear — I think the name matching system is a mess. But I also think you're both missing why it's a mess that works. The tolerance at each checkpoint isn't a patch on a broken design. It's the design. The system was built for human judgment because human judgment is the only thing that can handle the infinite variety of human names.
Go on.
Hilbert: You're framing the name as a fragile key that breaks under edge cases. I'm saying the name is a flexible key that bends instead of breaking. If we replaced the name with a purely numeric identifier — a universal passenger ID, say — you'd eliminate the transliteration problem, sure. But you'd create a new problem: every passenger would need to provide that ID at booking, and if they got it wrong, there's no human override. A typo in a numeric ID is a hard fail. A typo in a name can be resolved by an agent who looks at your face and your passport and says "yeah, that's you."
That's a fair point. The flexibility prevents false denials. A rigid system would reject more legitimate passengers.
Hilbert: The idea that we could move to biometrics — facial recognition, fingerprints — assumes universal adoption across every airline and every border authority in the world. That's not happening. Not in our lifetimes. The name is the only universal identifier we have, and the system's tolerance for variation is what makes it usable across two hundred countries with different languages, different scripts, and different naming conventions.
But the tolerance isn't consistent. A check-in agent in Frankfurt might accept "Mueller" for "Müller," but an automated system at US CBP might not. The passenger doesn't know which tolerance level applies until they're already at the airport.
Hilbert: That's a real problem. I'm not saying the system is perfect. I'm saying the alternative you're implying — a fully automated, rigid matching system — would be worse. It would generate more false denials, not fewer. The current system's messiness is a feature because it allows for the reality that humans are messy.
I'll concede that the flexibility has value. But I'll hold on this: the lack of a structured name field is not a design choice. It's a legacy artifact. The PNR format wasn't designed to be flexible — it was designed in an era when nobody thought about these edge cases. The flexibility we have now was bolted on later, through agent training and fuzzy matching algorithms, because the underlying data model couldn't handle the real world.
Hilbert: That's probably true. But the fact that it was accidental doesn't make it useless. A lot of resilient systems are accidents that turned out to work.
I think we're landing in the same place from different angles. The system works because humans are in the loop, but the reason humans have to be in the loop is that the data architecture is fundamentally inadequate for the task it's being asked to perform.
Hilbert: I can live with that. The architecture is inadequate, and the human layer compensates. The question is whether the compensation is sustainable as passenger volumes grow and border security tightens.
That's the open question. As more countries move toward automated border control — e-gates, facial recognition, pre-clearance — the human override becomes less available. The tolerance shrinks. And the name field, which was always the weak point, becomes the single point of failure.
The cutting-room floor detail I can't stop thinking about: the less-than sign. ICAO uses the less-than character as a separator in the MRZ because it's not used in any natural language name. But if your name actually contains a less-than sign — and apparently there are a handful of people in the world with names that include mathematical symbols — the system has no way to represent you. You're literally unencodable in the international standard for machine-readable travel documents.
There's a philosophical question buried in all of this. We've built a global system that assumes names are simple strings, and then we've spent decades patching it to handle the fact that names are anything but. At what point does the patching become more expensive than rebuilding?
The rebuild would require every country, every airline, and every reservation system to agree on a single standard for representing human names. Given that we can't even agree on which side of the road to drive on...
Yeah. The patchwork is probably permanent.
This has been My Weird Prompts. Thanks to our producer Hilbert Flumingtop for keeping the show running. Find us at my weird prompts dot com. We'll be back soon.
