Customer transaction records captured on the platform are pseudonymous, not anonymous, and the distinction is material. Anonymous data cannot be traced to a person by any party under any circumstances. Pseudonymous data is bound to a durable pseudonym rather than to a name, so that no single party is able to trace a purchase to the person who made it, but the link is not destroyed.

This is a deliberate design choice and a stronger one than the alternative. Conventional anonymization of transaction data has repeatedly been shown to be reversible, which is why such records are in practice either deleted or retained in personally attributable form. PCX takes the opposite approach: identity is never embedded in the record at all, and the elements required to reconstruct it are divided among separate custodians.

By design, no single party holds enough to identify a customer:

• The merchant observes transactions within its own store and partner network and computes loyalty upon them. It does not learn who the customer is.
• The bank or card issuer knows that a customer has spent, but not what was purchased. Transaction records are never shared with it.
• The PCX server platform holds transaction detail against a token, but not the person behind the token. The issuer is under no obligation to disclose the mapping. This applies to ValiDeck itself: the detail exists, the identity does not travel with it, and the platform cannot bridge the two on its own.
• The customer is the only party in possession of the complete picture, and the only party able to connect those records to a named identity.

Reconnecting a purchase to a named person therefore requires both halves, the platform’s transaction records and the bank’s identity records, which in practice requires a lawful process compelling both. That is the accountability pathway, and it is intentional. A system that cannot be audited under any circumstances is not a system that regulators or banks would adopt.

In the reference implementation, the customer’s device generates a cryptographic key pair locally. The customer then asks the card issuer to attest the public key against the KYC records the issuer already holds. The attested key is what the platform uses to create the account.

No email address, telephone number, or payment card detail is disclosed to the platform at account creation. The issuer already knows who the customer is, and the platform never needs to. Verification is performed once, by the party that has already performed it under regulatory obligation, and the result is carried forward as an attestation rather than as a second copy of the underlying identity data.

No password is required. The account is opened and subsequently accessed by the customer’s own device using a key held on that device. There is nothing for the customer to choose, remember, or reset, and no credential store on the platform for an attacker to obtain. This removes an entire class of exposure: credential stuffing, password reuse, and the compromise of a central authentication database have no purchase against an architecture that never holds a shared secret in the first place.

Two things must be restored, and they are restored separately. The account itself is recovered through the issuer or identity provider that vouched for the customer originally. That party verifies the customer again and attests a new key, and the platform reconnects the new key to the existing pseudonym. Reward balances and accrued history carry across without interruption.

Reading the records again requires the recovery code. Transaction records are held in a vault that only the customer is able to open, and a new key does not open the existing vault on its own. Entering the recovery code on the new device restores access. The records themselves are neither decrypted nor re-encrypted during this process, so recovery takes the same amount of time whether the history is one month old or ten years old.

The recovery code is a one-time code issued at account creation, intended to be written down and kept somewhere safe, in the same spirit as the recovery codes issued by banks and device manufacturers. It is never transmitted to the platform and is never stored there in usable form. It does not change, so the same code remains valid however many times the device key is replaced. Any party holding the code is able to read the transaction history, and it should accordingly be treated as a spare key to a safe.

The honest answer on losing both: a customer who loses the key on the device and the recovery code cannot recover the transaction history, and neither can ValiDeck. That is the unavoidable cost of an architecture in which no party other than the customer is able to read the records.

The records already exist. They are simply held somewhere the customer cannot see them. A customer who takes a national retailer’s loyalty card today has that retailer recording purchases at line-item detail and tying them to the identity handed over at signup: name, email address, or telephone number. What the customer receives in return is an aggregate, a points balance or a running total. The merchant holds the granular record and the customer holds the summary. Visibility runs in one direction only.

PCX reverses that relationship without creating a new exposure. The record must exist for any loyalty program to function. The questions worth asking are who holds it, what is attached to it, and who is able to read it.

The customer’s name is removed from the record. Participation occurs through a platform account keyed to a pseudonym the customer controls, rather than through a form at the till. No name, email address, or telephone number reaches the merchant. The merchant continues to see its own transactions, which it requires in order to operate the program, but it does not learn who the customer is, and the customer does not take a co-branded card.

The customer obtains the granular view. The complete purchase history arrives in a single account under the customer’s control, at the same line-item detail the merchant has always held for its own store. Only the customer is able to connect that record to a named identity.

A breach yields less. A merchant loyalty database breached today discloses named purchase histories. Under the granted PCX architecture, each record is decoupled from the person behind it, so a comparable breach yields transactions against tokens rather than attributable purchase histories. The pending applications go further, hardening how the records themselves are stored: each record is decomposed, encrypted under the customer’s public key, and separated, such that no single point of compromise yields a readable history. Those applications remain pending, and their mechanism is set out in the filings rather than described here.

Storing records on PCX is therefore not a new privacy cost. It is the same record the customer already generates, relocated to a place where it carries a pseudonym rather than a name, and where control rests with the customer rather than the merchant.