A Passenger Name Record (PNR) is the reservation file created the moment you book a flight through a Global Distribution System like Amadeus, Sabre, or Travelport. It's not the same thing as Advance Passenger Information (API), the more limited dataset (name, passport number, nationality, date of birth) that most people associate with border checks. A PNR is broader and messier, because it's a working operational record built by airline reservation systems and travel agents, not a purpose-built government dataset.
What's Actually in the File
The standard PNR includes the traveler's name, itinerary and travel dates, ticketing and payment information (including the last digits of the card used), contact details, frequent-flyer number, seat assignment, baggage information, and any special service requests, which is where things get uncomfortable: SSR codes cover meal preferences (which can reveal religious observance), wheelchair or medical equipment needs, and unaccompanied minor status. There's also a General Remarks field, essentially free text, where a travel agent or airline representative can add notes: who else is traveling with you, a corrected phone number, a note about a connecting flight for a family member on a different booking. That field isn't standardized, isn't consistently reviewed, and has been the source of documented data-quality and privacy complaints precisely because it can contain more personal detail than the traveler ever explicitly provided.
API is a name-and-document match against a watchlist. PNR is behavioral: who you're traveling with, how you paid, whether the trip was booked last-minute, whether you requested a specific meal, and whether you've flown the same route before. It's the record that makes pattern analysis possible, not just identity verification.
Who Actually Receives It, and When
Under the US EU PNR Agreement (in force since 2012, periodically renewed and challenged in EU courts) and equivalent bilateral agreements with the UK, Canada, and Australia, airlines operating flights to or from those jurisdictions are required to transmit PNR data to the relevant border and customs authority, typically 72 hours before departure and again shortly before the flight closes. In the US, that's Customs and Border Protection, which is legally authorized to retain PNR data for up to 15 years in an active analytical database, after which it moves to a dormant, more restricted-access status rather than being deleted. The EU's own PNR Directive, which came out of the 2016 Paris and Brussels attacks and required member states to build domestic Passenger Information Units, mandates a shorter active retention window before data is masked, though the exact figures and the underlying legality have been repeatedly contested at the Court of Justice of the European Union, most notably in a 2022 ruling that found aspects of the bulk, undifferentiated retention model disproportionate under EU fundamental rights law, without striking the framework down entirely.
This is structurally similar to the intelligence-sharing question we cover in our piece on the Five Eyes alliance, in that PNR data collected under one country's legal authority routinely gets shared onward through bilateral and multilateral agreements to partner governments, under retention and use conditions that are harder for the traveler to audit than the original collection itself.
| Dataset | What it contains | Typical retention |
|---|---|---|
| API (Advance Passenger Information) | Name, DOB, nationality, passport number | Shorter, purpose-limited to the specific entry |
| PNR (Passenger Name Record) | Full itinerary, payment fragment, co-travelers, special requests, free-text remarks | Years, moving from active to dormant status rather than deletion |
The Aggregation Problem
A single PNR is mundane. The privacy concern is what happens when years of them sit in the same analytical system, linkable by name, frequent-flyer number, or payment card fragment. That's enough to reconstruct a travel pattern: who you habitually fly with, whether your travel correlates with someone else's, whether a trip was booked with unusual urgency (a factor several border agencies explicitly weight as a risk indicator), and whether your route history clusters around a particular region over time. None of this requires reading a single message you sent; it's derived entirely from metadata generated by the act of booking a flight, the same underlying principle behind the broader case we make in our piece on metadata surveillance: the pattern of behavior is often more revealing than any single data point inside it.
You never see most of a PNR. The free-text remarks field, the risk-scoring your itinerary is run against, and the years of retention after your trip ends are all invisible from the booking confirmation email in your inbox.
The Risk-Scoring Layer Most Travelers Never See
In the US, PNR data feeds directly into CBP's Automated Targeting System (ATS), which assigns each traveler a risk score based on itinerary patterns, payment characteristics, and comparison against prior travel history, before a single officer reviews the file. ATS has existed in some form since the 1990s for cargo screening and was extended to passengers after 2001; a 2007 Department of Homeland Security disclosure confirmed that ATS-generated risk assessments are retained for up to 40 years, considerably longer than the underlying PNR record itself. The scoring methodology is not public, which means a traveler flagged for secondary screening generally has no way to learn which factor in their booking, a one-way ticket, a cash payment, a last-minute itinerary change, actually triggered it. This is the automated-decision-making problem in a specific, high-consequence setting: the data collection (PNR transmission) is at least disclosed in international agreements, while the downstream scoring built on top of it operates with far less transparency.
What You Can Actually Do About It
There's no consumer-facing opt-out from PNR transmission for international travel; it's a condition of the airline's operating license in the relevant jurisdiction, not a service you can decline. What you do control is how much extraneous detail enters the record in the first place. Booking directly with an airline rather than through a third-party aggregator reduces the number of intermediary systems that see and can retain a copy. Declining optional profile linkages (loyalty program tie-ins that connect a booking to a broader travel history, or letting a corporate travel system auto-populate special-request fields) limits what ends up in the remarks field. And under both the EU's GDPR-based access rights and equivalent US Privacy Act provisions for records CBP holds, travelers can request a copy of their own retained PNR data, which is worth doing at least once if you want to see concretely what's actually in the file rather than relying on the general description above.
None of this is something an encrypted messaging app touches directly, PNR data is generated by the booking transaction itself, not by anything you communicate afterward. Where Haven fits is in the conversation around the trip: coordinating logistics, sharing an itinerary with family, discussing a sensitive reason for travel, without that content becoming a second data trail sitting on a server somewhere, in addition to the one the booking already created.