Cross-border data flows: why a booking in Bali touches five jurisdictions

A traveler in Chicago opens Expedia, books four nights at a boutique resort in Ubud, Bali, owned by a French hospitality group, and pays with a US credit card. That single click just moved personal data through at least five legal jurisdictions, each with its own rules about who owns that data, where it can be stored, and who is liable if it leaks.

Nobody in the transaction chain necessarily broke a law. But nobody necessarily checked either. That is the compliance gap this lesson maps.

The five jurisdictions, traced

Follow the data, not the money.

1. The traveler's location (US). The booking originates from a US IP address. US state laws like the California Consumer Privacy Act (CCPA), enforced by the California Privacy Protection Agency, may apply if the traveler is a California resident, regardless of where the hotel sits.

1. The OTA's jurisdiction. Online Travel Agencies (OTAs) like Expedia or Booking.com are typically incorporated in the US or Netherlands. Their privacy policy sets the first contractual layer, but it does not override stricter local law where the guest or hotel is based.

1. The GDS processing layer (Singapore, in this scenario). A Global Distribution System (GDS), such as Amadeus, Sabre, or Travelport, routes the reservation, room inventory, and payment metadata between OTA and property. If the GDS's regional data center sits in Singapore, Singapore's Personal Data Protection Act (PDPA), overseen by the Personal Data Protection Commission (PDPC), governs how that data is handled while it sits there.

1. The hotel owner's jurisdiction (France). If the resort's parent company is headquartered in France or the EU, the General Data Protection RegulationGeneral Data Protection RegulationEU regulation governing how organizations collect, store and use personal data, with fines tied to global revenue for breaches.View full definition → (GDPR) can attach to the parent entity's data processing decisions, even for a hotel physically located outside the EU. GDPR has extraterritorial reachreachThe number of unique people exposed to your message in a given period. Unlike impressions, reach counts each person once, no matter how often they see it.View full definition →: it follows the data controller, not just the data subject.

1. The destination country (Indonesia). Indonesia's Personal Data Protection Law (UU PDP, passed 2022, enforcement phased through 2024) and sector-specific tourism data rules from the Ministry of Tourism govern data collected on Indonesian soil, including guest ID scans required at check-in under local hospitality regulation.

Five jurisdictions. One reservation. Zero centralized owner of the compliance question.

Why this isn't just a legal curiosity

For a data or operations professional, this matters for three concrete reasons.

Contradictory obligations can collide. GDPR requires a documented legal basis to transfer EU-linked personal data outside the European Economic Area (EEA), typically via Standard Contractual Clauses (SCCs) or an adequacy decision. Indonesia's UU PDP has its own cross-border transfer conditions. If the GDS in Singapore replicates guest data to a backup server in a sixth country, someone needs to have pre-cleared that transfer under both regimes, not just one.

Liability follows the weakest link, not the strongest brand. If Amadeus (GDS) suffers a breach exposing guest passport numbers, the French hotel group and the US OTA both face exposure, because GDPR and CCPA hold data controllers, not just processors, accountable for vendor failures. A 2023 case pattern seen across the EU: hotel groups have received regulatory inquiries for breaches that technically occurred at a third-party booking engine (see the European Data Protection Board's guidance on controller/processor liability).

Tourism-specific rules add a layer generic privacy law does not cover. Indonesia, Thailand, and several other destinations require hotels to log guest passport or ID data for police and immigration reporting. That is a mandatory local data collection duty sitting on top of, and sometimes in tension with, GDPR's data minimization principle (collect only what is strictly necessary).

Mapping the chain: a practical framework

Before a booking flow launches or a GDS contract renews, run a jurisdiction map. Four questions, one row per data-touching party:

This is not an academic exercise. It is the actual worksheet a Data Protection Officer (DPO) or compliance lead should complete for any new distribution partnership.

A simplified data flowdata flowAn automated sequence of steps that moves data from source to destination: ingestion, transformation, validation, and loading, so it arrives clean and ready to use.View full definition → check, in pseudocode

For teams building or auditing booking pipelines, the logic is close to this:

for each data_field collected at booking:
    identify origin_jurisdiction (guest residence)
    identify controller_jurisdiction (hotel parent HQ)
    identify processor_jurisdictions (OTA, GDS, PMS, payment gateway)
    if origin_jurisdiction has cross-border transfer restriction:
        check for valid transfer mechanism (SCC, adequacy decision, consent)
    if processor_jurisdiction requires local data residency:
        flag if data leaves that region without safeguard
    log retention_period against local mandatory minimum AND GDPR maximum

The point of formalizing this, even loosely, is that "we didn't know the GDS mirrored to a US server" is not a defense regulators accept.

Checks and audits worth running quarterly

A governance framework is only as good as the checks behind it. For hospitality data teams, four recurring audits matter most:

1. Vendor data map refresh. GDS providers and channel managers change server regions without always notifying clients. Re-confirm data residencydata residencyThe requirement that data is physically stored and processed in a specific country or region, often driven by law or contract.View full definition → annually in vendor contracts, not just at signing.

2. Retention audit against the strictest applicable rule. If GDPR says delete after contract purpose ends (typically interpreted as a defined retention schedule, often 3 to 7 years for financial records) but Indonesian immigration rules require ID retention for a fixed local period, the system needs field-level retention logic, not a single blanket policy.

3. Consent and legal basis trace. For EU-linked guests, confirm the booking flow captured a valid legal basis (contract necessity, not just "consent" buried in terms) as required under GDPR Article 6, per guidance from the European Data Protection Board.

4. Cross-border transfer documentation. Confirm SCCs or equivalent mechanisms exist for every processor step that crosses a border, and that the paperwork is retrievable, not just referenced in a master services agreement no one has re-read since signing.

None of these require a large legal team. They require a named owner, a recurring calendar entry, and a shared jurisdiction mapmapUsing software to automate repetitive marketing tasks and campaigns, enabling personalisation at scale across channels like email, web, and social.View full definition → that gets updated when vendors change infrastructure.

Key Takeaways

• A single booking can trigger multiple, sometimes conflicting, data laws (GDPR, PDPA, CCPA, local tourism rules) based on the traveler's residence, the OTA's base, the GDS processing location, the hotel parent's HQ, and the destination country.
• GDPR's extraterritorial reach means an EU-headquartered hotel group can be liable for data practices at a resort located entirely outside the EU.
• Liability typically follows the data controller (often the hotel brand or OTA), not just the processor (GDS, PMS vendor) where a breach technically occurs.
• Build and maintain a jurisdiction map: for each vendor in the booking chain, document incorporation location, data storage location, and the specific law that attaches, then re-verify it at least annually.
• Run quarterly checks on vendor data residency, field-level retention rules, documented legal basis for data collection, and cross-border transfer paperwork (SCCs or equivalents), since these are the specific artifacts regulators request during an inquiry.