Building the PCX prototype

Almost every large retailer runs a loyalty program, and most did not set out to become custodians of the personal and confidential data of their customers. Yet conventional loyalty programs often link names or contact details to purchase history so the merchant can recognize a returning customer. That creates continuing consent, security, retention, and deletion obligations. PCX is designed to preserve the loyalty function while reducing the amount of identity data the loyalty system itself needs to hold, separating record integrity from identity custody.

At the heart of this design lies the Privacy-Compliant eXtensible (PCX) protocol — an architecture in which transaction records can be tokenized, pseudonymized, and audited without requiring the PCX Platform to store a direct customer identifier. Rather than using identity as the organizing key, PCX combines attestation, tokenization, and structured records to preserve continuity under a pseudonymous reference. This turns privacy from a policy objective into an architectural constraint. The protocol is described in full in the PCX White Paper.

The Phase-I PCX Prototype is the planned feasibility implementation of this principle. It is designed around simulated multi-merchant transactions and a reference integration so that the architecture can be tested before live commercial deployment. Everything that follows describes what the Phase I reference implementation is intended to prove.

Prototype objective

The Phase-I PCX Prototype is designed to validate the PCX operational chain — attest, tokenize, pseudonymize, compute, audit — in a controlled environment using simulated transactions from multiple merchants. The custodian role represents the party that has the authorized identity relationship, can attest a customer key, and can issue or manage the token used in the transaction flow. In a production deployment, that role could be performed by a regulated card issuer or another authorized custodian. Phase I is structured so that the custodian role can be substituted without redesigning the downstream PCX interfaces.

Phase I does not depend on production banking interfaces. The PCX Prototype will therefore use a simulated issuer/custodian service to reproduce the required attestation and encrypted-token flows. The objective is to validate the interface boundary and downstream PCX behavior without assuming a live bank integration before a partner is committed. In later phases, the simulated custodian can be replaced by an authorized production participant implementing the same interface contract.

This phase focuses on three deliverables:

• A multi-merchant payment transaction simulator that reproduces representative point-of-sale activity and tokenized transaction flows.
• A reference implementation of the PCX Platform for ingesting, storing, and querying pseudonymous Customer Transaction Records (CTRs), together with loyalty and analytics functions.
• A reference integration and connector blueprint showing how a target PoS environment can connect to the PCX Platform without requiring a live production deployment.

Together, these components are intended to demonstrate technical feasibility, privacy boundaries, and integration readiness before ValiDeck moves to live partner pilots.

Custodial and attestation flow

During Phase I, a simulated issuer/custodian service performs the pre-platform functions that an authorized bank, payment participant, or identity framework could assume in production.

1. Identity relationship: the PCX Prototype models the fact that the custodian has already established or is authorized to establish the customer’s identity.
2. Public-key attestation: the simulated custodian signs the customer’s public key, producing an attestation that the PCX Platform can validate without receiving the customer’s direct identity.
3. Token issuance: the simulated issuer generates representative payment tokens and protects them for delivery to the PCX Platform.
4. Custodial separation: the identity-to-key relationship remains on the custodian side of the architectural boundary rather than in the PCX data store.

In the reference design, a protected token is processed inside an attested environment and used to derive the pseudonymous reference required for processing by the PCX Platform. Direct personal identifiers are not carried into the PCX data store, and raw token material is not intended to persist beyond the protected processing step. What persists is the derived reference used to associate the transaction with the pseudonymous ValiDeck account.

Acquiring a ValiDeck account

In the reference design, customers obtain a pseudonymous ValiDeck ID through an onboarding flow connected to the custodian.

1. The onboarding flow initiates attestation with the custodian.
2. The customer’s key pair is generated locally on the device. The public key is submitted for attestation, while the private key remains on the device.
3. The custodian validates or relies on its existing identity relationship, signs the public key, and returns an attestation certificate.
4. A pseudonymous ValiDeck ID is derived from the attested public key and registered on the PCX Platform.
5. The customer activates the account by proving possession of the corresponding private key. The reference design does not require an email address, phone number, or password to serve as the platform identity.

The custodian retains the identity and attestation relationship, while the PCX Platform stores the pseudonymous platform identifier and the encrypted records required for the service.

Accessing the PCX platform

The reference design uses app-mediated, passwordless access rather than an identity-bearing username and password. The user’s device provides the cryptographic credential needed to establish a session with the PCX Platform.

When the app launches, it establishes a cryptographically authenticated session with the PCX Platform. No username, email, or phone number is required for platform identification; possession of the corresponding private key proves control of the pseudonymous account credential.

The PCX Platform therefore authenticates control of an attested key rather than a conventional personal profile. The custodian, not the PCX Platform, remains responsible for the identity relationship.

Establishing a secure session

To establish this app-mediated access, the PCX Platform relies on a passwordless public-key challenge–response protocol:

1. When the app starts, the PCX Platform issues a cryptographic challenge.
2. The edge device signs this challenge using the user’s private key, which never leaves the device.
3. The PCX Platform verifies the signature with the attested public key linked to the ValiDeck ID.
4. If the signature is valid, the session is opened, and the device may synchronize with the user’s encrypted vault.

Authentication and decryption are separate steps. After the session is authenticated, the app can access the normal-access sealed copy of the customer’s encryption key, use the device’s private key to unseal it, and decrypt records locally as needed. The session flow is passwordless and cryptographic: the platform recognizes control of the attested key rather than asking the user to disclose a personal identifier. This reinforces the core principle that the platform account is addressed through a pseudonymous credential, while the real-world identity remains with the custodian.

Tokenization and CTR creation

When customers tokenize their payment cards, the process mirrors the custodial logic:

• The simulated issuer creates a representative card token and protects it for delivery to the PCX Platform.
• The reference design processes the protected token inside an attested environment and derives the pseudonymous reference required for processing by the PCX Platform.
• The design minimizes persistence of raw token material and stores the derived reference required to resolve the transaction to the pseudonymous account.

Each simulated transaction produces a structured Customer Transaction Record (CTR) containing the fields needed for the reference use case, such as merchant information, item details, value, time information, and integrity metadata. The PCX Platform uses the protected token flow to resolve the record to a pseudonymous account reference rather than to a direct customer identity. Phase I will test the record schema, token linkage, integrity controls, and performance of that flow before production integration.

Merchant visibility and rewards

The merchant-facing implementation is designed to expose the information needed to operate the loyalty program — such as qualifying transactions, reward status, redemption activity, and program-level reporting — under a pseudonymous customer reference rather than a direct identity-bearing profile.

The precise data available to a merchant will be governed by the program design and permissions; unrelated cross-merchant activity is not exposed simply because the customer participates in PCX.

In the PCX Prototype, reward logic and aggregate analytics are tested against pseudonymous records. The same architectural primitives are intended to support additional participating merchants later, while keeping one merchant from seeing another merchant’s customer-level activity. Phase II will determine how those capabilities operate with live partners and controlled pilots.

Key recovery and continuity

Because the PCX Platform holds no passwords or personal identifiers, recovery has two distinct parts: restoring account continuity through the custodian and restoring access to encrypted CTRs through the recovery code. Account continuity begins with the custodian’s attestation records:

1. The user re-verifies or re-establishes the identity relationship with the custodian.
2. The custodian re-attests a new public key and revokes or supersedes the previous attestation.
3. The PCX Platform derives a new ValiDeck ID from the new attested key and links it to the prior pseudonym using a continuity proof.
4. The old device key and attestation are retired. The reward balance and the audit trail carry across to the new identifier without interruption.

This linkage is the one deliberate exception to pseudonym separation, and it is worth being precise about it. The continuity proof links a user’s own successive identifiers to each other so that their reward balance and history survive the loss of the previous device key. It is generated only on a user-initiated recovery, only after the custodian has re-verified that user, and it links nothing beyond that single user’s prior and current identifiers. It gives neither the PCX Platform nor the merchant any ability to link a pseudonym to a real-world identity, which remains solely with the custodian.

Re-attestation restores account continuity but does not by itself restore the ability to read what is inside it. Every customer’s transaction records are encrypted with a customer-specific encryption key. The PCX Platform stores the encrypted records but retains no secret that can open them. There are two routes to the customer’s encryption key, and the customer controls both. The device-resident copy of the customer’s encryption key is stored on the customer’s device, and the PCX Platform does not hold this copy. For everyday access, the app uses the device private key to unseal the device-resident copy when the customer accesses the account. The recovery route uses a recovery code, issued once when the account is created and meant to be written down and kept somewhere safe, in the same spirit as recovery codes issued by banks and phone manufacturers. The code itself is never sent to the PCX Platform. Instead, the PCX Platform holds a separate recovery-sealed copy of the same customer encryption key, which only the recovery code can unseal.

It is worth being precise about what changes and what does not. The customer’s encryption key is generated once, when the account is created, and remains the key used to encrypt that customer’s CTRs. The architecture maintains two protected representations of that key: a device-bound sealed representation used for normal access and a recovery-sealed representation accessible through the recovery code. During recovery, the recovery code opens the recovery-sealed representation and restores access to the existing customer encryption key. The app then creates a new device-bound sealed representation of that same key, protected by the newly attested device credential, and retires the previous device-bound representation. Only the device-bound sealed representation is replaced; the customer encryption key itself, the recovery-sealed representation, and the encrypted CTRs remain unchanged. Because the recovery-sealed representation is not replaced, the same recovery code can be used after later device-key replacements.

When a customer replaces a lost device, the custodian attests a new public key and the recovery code restores access to the customer’s encryption key so that a fresh normal-access copy can be sealed for the new device credential. The records themselves are never decrypted, moved, or re-encrypted during recovery, so the process does not require reprocessing the customer’s transaction history. A customer who loses both access to the device private key and the recovery code cannot recover their transaction history, and neither can the PCX Platform. That is the price of an architecture in which nobody but the customer can read the records, and we consider it the right one.

Governance and transition

Phase I is designed to run under a sandbox governance model that can test the supervisory assumptions of a production deployment. Security-sensitive operations and interfaces will produce integrity and audit evidence so that reviewers can examine system behavior rather than rely only on policy assertions. Independent privacy and security review is part of the program, and any supervisory access would remain subject to the authority’s legal mandate.

Once the PCX Prototype and reference integration are validated, later deployment changes the operating environment more than the core protocol:

• Simulated custodianship can transition to an authorized bank, payment participant, or identity framework.
• Sandbox governance can transition to the oversight model required by the deployment jurisdiction.
• Live merchants and payment partners can be added through controlled integrations.
• The objective is to preserve the validated interface and record contracts so that these transitions do not require redesigning the core PCX architecture.

Through this staged progression, ValiDeck intends to demonstrate that privacy-preserving loyalty and transaction intelligence can be implemented without making direct customer identity the organizing key of the PCX Platform — and that the same reference architecture can support broader services as partner and regulatory requirements are validated.