What this covers
Two requirements sit at the heart of any serious loyalty programme, and at first glance they point in opposite directions. The first is immutability: points are a liability, redemptions move money-equivalent value, and finance and audit need a record that cannot be silently altered or deleted. The second is the right to erasure — GDPR Article 17 — under which a person can ask you to delete their personal data, and you generally must.
A naive reading puts these in direct collision: how do you delete someone from an append-only ledger you have promised never to mutate? The resolution is to recognise that the two requirements are about different things. Erasure is about personal data — who someone is. The ledger is about financial facts — what happened. Separate those cleanly and the conflict dissolves.
1. The conflict: immutability vs. erasure
An immutable ledger is the correct foundation for loyalty (see our build-vs-buy guide for why). Every earn, conversion, redemption, expiry, void, and adjustment is an append-only entry; the balance is derived, never overwritten. That immutability is exactly what makes the system auditable and trustworthy — and exactly what makes “delete this customer” look impossible.
But Article 17 does not actually require you to destroy the fact that a transaction occurred. It requires that you can no longer identify the person behind it, and that their personal data is rendered inaccessible. A loyalty event of “+120 points, order ORD-10293, 2026-06-27” is not personal data once it can no longer be tied to a name, an email, or any other identifier. The trick is architectural: make identity removable without touching the financial record.
2. Why “just delete the row” fails
Teams that try to satisfy erasure by issuing DELETE statements discover the approach is both too much and too little.
Too much: deleting ledger rows destroys financial integrity and breaks reconciliation — the very thing the ledger exists to protect. You can no longer prove what you issued versus what you redeemed.
Too little: a DELETE on the primary database does not reach the places personal data has spread. Personal data leaks into database backups and point-in-time snapshots, read replicas, search/reporting indexes, message-bus payloads, application logs, and warehouse exports. Chasing a person through all of those, including historical backups, is slow, error-prone, and frequently incomplete — and “we mostly deleted them” is not a defensible position.
The lesson the hard way: any design where erasure means hunting personal data across every system that ever touched it will eventually miss a copy. You need a model where one action makes the data irrecoverable everywhere at once.
3. How cryptographic erasure works
Cryptographic erasure (also called crypto-shredding) inverts the problem. Instead of deleting data, you ensure the data was only ever stored encrypted, and then you destroy the key. Ciphertext without its key is indistinguishable from random noise — in every backup, replica, and export simultaneously.
The robust pattern is envelope encryption with per-subject keys:
- Each customer's personal fields (name, email, phone, date of birth) are encrypted with a unique data encryption key (DEK) — AES-256.
- Each DEK is itself encrypted (“wrapped”) by a per-tenant key encryption key (KEK) held in a hardware-backed key vault, never in the application database.
- To erase a customer, you destroy or render unusable the key material that protects their DEK. The encrypted PII that remains in the database, in last night's backup, and in any replica is now permanently undecryptable.
Because the protection travels with the ciphertext, you do not need to physically reach every copy. The copies still exist as bytes, but they are inert. That is what makes the approach both complete and operationally sane.
4. Why it satisfies GDPR Article 17
Regulators have increasingly accepted that erasure does not always mean physical destruction of every byte; rendering personal data permanently inaccessible and irreversible can constitute erasure. Cryptographic erasure, done properly, achieves exactly that: once the key is gone, no one — not you, not an attacker, not a future you with a subpoena — can reconstruct the personal data. What remains is anonymised: financial facts with no path back to a person.
To stand up to scrutiny, the implementation has to be honest about a few things: the key destruction must be real and irreversible (including any key backups), the encryption must be strong and correctly applied to all personal fields, and you must be able to evidence when and how a given subject's key was destroyed. A defensible programme issues a record of erasure — in our case a Termination/erasure certificate noting the date of key destruction and what became irrecoverable.
This article is engineering guidance, not legal advice. Whether a specific implementation satisfies Article 17 for your circumstances is a question for your DPO and counsel. Build it correctly and have it reviewed.
5. Keeping the ledger intact
The reason crypto-erasure works for loyalty specifically is that a well-designed ledger holds almost no personal data to begin with. A ledger entry needs a signed amount, a type, a reference to what caused it, a timestamp, and a link to an internal account identifier — none of which is personal data. The personal data lives in the customer profile, encrypted under that customer's DEK.
When you destroy the key:
- The profile (name, email, …) becomes irrecoverable.
- The ledger is untouched: balances still reconcile, finance can still audit issuance versus redemption, and aggregate reporting still works.
- The internal account identifier is now a pseudonym pointing at nothing — an orphaned key with no door.
You have satisfied the person's right to be forgotten and preserved the integrity of the financial record. Both requirements, met, without compromise.
6. The pitfalls that quietly defeat it
Cryptographic erasure is only as good as your discipline about where personal data is allowed to travel. Each of these silently re-introduces an identifiable copy that the key destruction will not cover:
- PII in logs. An
INFOline that prints an email defeats the whole model. Personal data must be kept out of application logs by construction. - PII on the event bus. If events carry raw personal data, every consumer and every replayable topic is now an unencrypted copy. Keep the bus PII-free — carry a hashed identifier, not the email — and enforce it (a schema gate in CI, not a code-review hope).
- PII in exports / the warehouse. Once personal data lands in a tenant's warehouse, it is outside your erasure boundary. Exclude PII from feeds by default, or forward only hashed/consented identifiers.
- Plaintext search indexes. Reporting and search stores that hold decrypted personal fields are copies the key destruction misses. Index on non-personal fields or tokens.
- Key backups you forgot about. If the KEK is backed up somewhere the destruction does not reach, the data is not actually irrecoverable. “Destroy the key” has to mean all copies of the key.
The throughline: cryptographic erasure pairs with a PII-minimisation discipline. The encryption makes the data destroyable; keeping personal data from sprawling into logs, events, indexes, and exports is what keeps that single act of key-destruction sufficient.
7. A checklist before you rely on it
- Personal fields are encrypted with a per-subject DEK (not one global key).
- DEKs are wrapped by a KEK in a hardware-backed vault, separate from the data.
- The ledger holds no personal data — only signed amounts, types, references, timestamps, and internal IDs.
- The event bus is PII-free, enforced automatically.
- Logs, search indexes, and exports are free of raw personal data.
- Key destruction is real and reaches every key copy, and is evidenced (date, scope, certificate).
- The whole design has been reviewed by your DPO/counsel.
Get those right and the immutability-versus-erasure dilemma stops being a dilemma. You keep an audit-grade ledger forever, and you can make any individual unidentifiable on request, permanently, with a single operation.
This is not a roadmap for LoyaltyOS — it is how the platform is built: per-customer AES-256 DEKs wrapped by per-tenant KEKs in Azure Key Vault, a PII-free event bus enforced by a schema-registry CI gate, HMAC identity resolution, and cryptographic erasure that leaves the immutable ledger intact. The Trust Center documents the controls; the links below are the next step.