Cross-Border Data Transfers Under PDPL: When Your POS Sends Data Abroad
Most POS systems route Saudi transaction data to servers outside the Kingdom. Under PDPL Article 29, this is a cross-border transfer that requires an adequacy assessment or explicit consent — or it's a violation. Here's what that means for your business.
Most point-of-sale systems used in Saudi Arabia run on international cloud infrastructure. The software sits on servers in Ireland, the United States, Singapore, or somewhere else entirely. When a customer pays at the counter and shares a phone number to collect loyalty points, that data often leaves the Kingdom before the receipt finishes printing.
Under the Personal Data Protection Law (PDPL), that is not merely an architectural detail. It is a compliance event.
What PDPL Article 29 Actually Requires
Article 29 of the PDPL governs transfers of personal data outside Saudi Arabia. Cross-border transfers are not banned outright. They must be justified, and the standard for that justification is demanding.
Three bases can legitimize a transfer:
An adequate destination. The receiving country or organization must offer a level of protection that SDAIA considers adequate, comparable to Saudi standards. Many international hosting jurisdictions have not been formally assessed by SDAIA. If your POS vendor's data center sits in a country with no adequacy determination, this basis is not available to you.
Explicit consent. The individual must be told that their data is being transferred outside the Kingdom, to which country, and for what purpose, and must consent specifically to that transfer. A generic loyalty sign-up form does not clear this bar. Consent must be specific, informed, and documented.
Contractual necessity or public interest. The transfer must be strictly necessary to perform a contract with the individual, or required for a public interest purpose recognized under Saudi law. Retail customer data routed to an overseas data center for routine processing rarely meets that test.
If none of these bases applies, the transfer is a violation.
What This Looks Like in Saudi Retail
Many merchants have no idea their POS data leaves the Kingdom at all. The software is hosted abroad, the transaction is processed abroad, and the receipt record, including customer name, phone number, and purchase history, is stored abroad.
Patterns that commonly create cross-border exposure:
POS software hosted on servers located outside Saudi Arabia
Loyalty programs that store customer phone numbers and profiles on foreign infrastructure
Digital receipt archives and purchase histories retained overseas
Reporting and analytics processed on international platforms
Backups and disaster recovery copies held in another jurisdiction
Each of these is a cross-border transfer that needs a valid legal basis under the PDPL. Without an adequacy determination, documented explicit consent, or qualifying contractual necessity, the transfer is non-compliant.
Enforcement Is Already Underway
PDPL enforcement is active. SDAIA has issued 48 formal enforcement decisions since the grace period ended in September 2024, and cross-border transfer practices fall squarely within the scope of what the regulator can examine and penalize.
SDAIA is also licensing accredited PDPL auditors. The next phase of enforcement will be structured audits rather than reactive complaint handling, which means data residency questions will be asked before a customer ever files a grievance.
How Wateer Removes the Exposure
Wateer's architecture was built to keep Saudi customer data inside the Kingdom.
Every receipt issued through Wateer is stored and processed on Saudi-based infrastructure. No transaction data is routed to servers outside Saudi Arabia. Merchants issuing receipts through Wateer inherit a zero cross-border transfer position, so the adequacy assessment, consent framework, and vendor renegotiation that would otherwise be required simply do not arise.
For retailers currently running international cloud POS systems, cross-border compliance is solvable, but the options are limited: renegotiate data residency terms with your vendor, which standard contracts often do not permit; build an explicit consent mechanism that meets the PDPL's specificity requirements, which is complex and needs ongoing maintenance; or move to infrastructure that keeps data in the Kingdom by default.
The receipt layer is usually the easiest place to start. That is where Wateer begins.
Sources & References
Related reading
Want to see Wateer on your system?
Talk to Sales