Somewhere between the pilot and the contract, every wallet pass project in Europe meets the same question: what about GDPR? It is the right question, and it usually arrives wrapped in a wrong assumption, that a pass is a little database of the customer traveling around on their phone.
It is not, and understanding what a pass actually contains is most of the compliance conversation. This article is a map, not legal advice; your data protection officer still gets the final word. But the map makes their job much easier.
What is actually on a pass
A wallet pass contains what it displays, and very little else:
- An identifier. A serial number and the code (QR, barcode, or NFC payload) that lets a till recognize the member. The identifier points at a record in your systems; it is a key, not the record.
- Display fields. Whatever the design shows: a name if you choose to show one, a points balance, a tier. You decide these fields, which means you decide how much personal data the pass surface carries. Many perfectly good passes show nothing personal at all beyond a first name, and some not even that.
- Update plumbing. The pass knows which service to ask for updates. That is an address, not a payload.
What a pass does not contain: purchase history, contact details (unless you put them in a display field), preferences, or anything the till "reads out" of the phone beyond the identifier. When a customer taps or scans, the terminal learns who to look up. Everything else stays where it always was.
Where the data actually lives
The personal data behind a loyalty program lives where it lived before wallets: in your CRM or your program backend. That system remains the system of record, and your existing GDPR posture around it, your lawful basis, your retention rules, your processor agreements, remains the load-bearing structure.
A pass platform sits between that system and the wallet, processing what it must to do its job: the identifier, the display fields, and the device registrations needed to deliver updates. In GDPR terms the merchant is the controller of the program data, and the pass platform processes it on the merchant's instructions, under a data processing agreement, like any other processor in the stack. Where the platform runs and stores that data is a fair and answerable question to put to any provider, and one you should ask.
The rights requests, in wallet terms
The classic GDPR requests translate cleanly once the map is clear:
- Access. The customer's data lives in your CRM, so access requests are served from there, exactly as before. The pass adds nothing hidden to disclose beyond what its fields display.
- Rectification. Fix the record in the system of record and the pass follows, because the pass renders from live data. A correction is an update like any other.
- Erasure. Delete the member in your systems and void the pass. A voided pass stops updating and stops identifying; the customer can remove it from their wallet, and the key it carried no longer opens anything. What must not happen is the reverse order, deleting the record while a live pass keeps pretending.
- Withdrawal from the program. The customer can also simply delete the pass themselves. Deleting a pass removes it from the wallet and its update registrations; it does not by itself delete their membership, which is worth stating plainly in your program terms.
Consent happens at enrollment, not in the wallet
Adding a pass to a wallet is an action the customer takes, but the program consent conversation happens at enrollment, on the signup surface, in the wording you define. The pass is the artifact of a membership; the membership's lawful basis is established where the member joins. That keeps the design honest: enrollment flows should say what the program collects and why, in your words, and the pass should then carry no surprises the enrollment did not mention.
This is also the reason short enrollment forms are a compliance feature, not just a conversion one. Data you never collect is data you never have to justify, secure, or delete. A program that needs an identifier and a name asks for less, risks less, and explains itself in a sentence.
The strategic read
Wallet passes are, on inspection, one of the more privacy-conservative surfaces a loyalty program can have: a key and a display, backed by data you already govern. The compliance work is real but familiar, because it is the same work your CRM already required, plus a processor agreement and a clear erasure path.
Stell is built on that division of labor. Your CRM stays the system of record, the pass carries the fields you chose and nothing more, and voiding a pass is a first-class operation, not a support ticket. The platform is where that split is enforced. If your DPO has questions, bring them to the demo; the honest answers are short, and short answers are what DPOs like best.
