A guest arrives late, their booking came through an OTA, and the local registration portal requires passport details before the deadline. It is tempting to assume the platform already has everything you need. But can OTAs share passport data with a host? Usually, not automatically – and relying on an assumption can leave a compliance gap at exactly the wrong moment.
Online travel agencies (OTAs) hold guest information for their own booking and fraud-prevention purposes. That does not mean they are permitted, required, or technically configured to pass passport numbers, document images, nationality details, or dates of birth to every accommodation provider. What you receive depends on the OTA, the booking channel, the country, the property type, the guest’s consent, and the legal basis for the data processing.
For hosts and property managers, the practical rule is simple: treat OTA booking data as a useful starting point, not as a complete guest-registration record.
Can OTAs share passport data with accommodation providers?
They can sometimes share limited identity information where their terms, systems and applicable data-protection rules allow it. However, passport data is high-risk personal information in a hospitality setting. An OTA should only disclose it when there is a clear purpose, a lawful basis, appropriate security controls and a defined role for each party.
In many bookings, the host receives the lead guest’s name, contact details, stay dates, party size and reservation reference. This may be enough to manage the reservation, but it is often not enough to meet local traveller-registration or police-reporting requirements. Authorities may require the identity details of every guest, including document type, document number, date of birth, nationality and place of residence.
An OTA may also collect information differently by market. A platform might request a passport number for a specific check-in flow, but not make that field available to hosts. Another may offer an integration that transfers selected fields, while a third may make no document data available at all. The answer is never a universal yes or no.
A booking platform is not your compliance system
OTAs are built to facilitate bookings. Their data-sharing settings are designed around their own privacy notices, commercial agreements and product features. Local accommodation rules, meanwhile, can be far more specific about what a property operator must collect, retain and submit.
That division matters. If your property is legally responsible for guest registration, you remain responsible for completing it even if an OTA does not supply the required fields. A reservation confirmation is not proof that your guest book is complete, and a guest’s account verification on a platform is not necessarily the identity check required by local law.
Why passport data needs particular care
A passport number can expose a guest to fraud or identity theft if handled badly. A passport image may contain a photograph, signature, machine-readable zone and other data that you do not actually need. Collecting more than the authority requires creates unnecessary risk and makes your GDPR obligations harder to manage.
For most hosts, the goal is not to retain a copy of every passport. It is to collect the precise data required for registration, verify the document where required, submit the record through the correct channel, and retain it only for the statutory period.
Under UK GDPR principles and equivalent European rules, this means working with purpose limitation, data minimisation, storage limitation and security in mind. You need a documented reason for collecting the information. You need to tell guests what you collect and why. And you need controls that prevent staff, owners or third parties from accessing data they do not need.
A guest agreeing to house rules is not, by itself, a reliable basis for collecting a passport scan. Where a law requires accommodation providers to register visitors, the lawful basis will commonly relate to a legal obligation rather than consent. The exact position depends on the jurisdiction, so check the rules that apply to each property rather than copying a process from another country.
What hosts should ask an OTA before relying on its data
Start with the practical question: which fields are passed to your property, through which route, and at what point in the booking journey? The answer may differ between the OTA extranet, a channel manager, an API connection and a property-management system.
You should also establish whether guest data covers only the booker or every person staying. Group bookings are a common failure point. The lead guest’s name may arrive with the reservation, while the remaining travellers have not supplied any details at all.
Then consider the data-protection position. Read the relevant platform terms, privacy documentation and integration specifications. Clarify whether the OTA is acting independently as a controller for its own purposes, whether it shares data with you as another controller, and whether any additional agreement applies to the transfer. Do not assume that access in an extranet means you are authorised to export, retain or reuse every item shown there.
Finally, test the process. Create a controlled booking or inspect real reservation records across your channels. Check what arrives, whether fields are correctly mapped, and whether the data reaches your registration workflow early enough to meet local reporting deadlines.
Build a workflow that does not depend on OTAs
The most reliable approach is to request the missing registration details directly from guests through a secure, purpose-built check-in process. Send the request after booking and before arrival, explaining that the information is required for accommodation registration and will be handled securely.
Avoid asking guests to send passport photographs through ordinary email, messaging apps or unprotected forms. These methods create scattered copies, make access difficult to control and leave staff manually rekeying information. They also increase the chance of data being sent to the wrong person or stored beyond its permitted retention period.
A better workflow captures required fields in one controlled place, validates the information, matches it to the reservation and records when it was submitted. If a guest has not completed the form, the system should flag the booking before arrival rather than leaving reception or the host to discover the gap at check-in.
For operators with multiple properties, this becomes especially valuable. Each region may ask for different fields, use a different authority portal or require submission on a different schedule. A single process should adapt to the property’s legal requirements without making staff remember separate spreadsheets, passwords and cut-off times.
Keep the guest experience clear
Compliance requests are more likely to be completed when they are short, specific and sent at the right moment. Tell guests that the information is required by local accommodation regulations, identify the data needed, and give them a secure route to provide it.
Do not promise that information will be deleted immediately if the law requires you to retain a guest register for a set period. Be transparent about the retention period instead. Clear wording reduces questions, protects trust and helps guests distinguish a legitimate registration request from a phishing attempt.
Secure handling is part of compliance
Collecting the right data is only half the job. The record must be protected in transit, at rest and throughout its retention period. Access should be role-based, especially where cleaners, co-hosts, owners, front-desk staff and external managers all work with the same properties. Not everyone who can see a booking calendar should be able to view passport details.
You also need an auditable trail. If an authority asks when a record was collected or submitted, you should be able to show the relevant dates without searching inboxes or paper files. When the retention period ends, the data should be securely removed according to your policy and any applicable legal requirements.
GuestAdmin helps operators centralise this workflow by taking booking data from OTAs and other sources, collecting missing guest details securely, preparing required records and submitting them on the prescribed schedule. The point is not to gather every possible piece of personal data. It is to keep the required data accurate, protected and ready when the authority needs it.
A practical decision rule for each booking
When an OTA reservation arrives, first identify what details have actually been provided. Next, compare those fields with the requirements for the property’s jurisdiction and the guests on that booking. If anything is missing, request it directly through your approved registration process. Then submit and archive the completed record in line with the relevant rules.
This approach avoids two costly mistakes: assuming the OTA has already handled your legal obligation, and collecting excessive document data simply because it might be useful later. It also works whether your bookings come from one platform, several OTAs, direct reservations or a connected property-management system.
The right question is not whether an OTA might have a guest’s passport data. It is whether your property has the lawful, secure and complete information required to register that stay. Build for that answer, and late arrivals become a routine workflow rather than a compliance emergency.