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 outlined 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 persistent, pseudonymous ValiDeck ID (VAID) 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. At first enrollment, a pseudonymous VAID is derived from the initially attested public key and registered on the PCX Platform. The VAID remains the account identifier when device keys are added, replaced, or retired.
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. To add a new device, the customer initiates device registration using the installed ValiDeck application. The application generates a key pair locally and displays a temporary QR code identifying the pending registration request. The customer scans that code using the ValiDeck application on an already authorized device. That application retrieves the pending request and automatically includes the customer’s existing VAID as a parameter alongside the new public key. The customer does not have to remember or type the VAID.

After the customer authenticates locally on the authorized device and approves the addition, that device signs an approval covering the VAID, the new public key, and a fresh platform challenge. The PCX Platform verifies the approval and requires the new device to prove possession of its private key by signing a fresh cryptographic challenge. Once the platform has verified the signed response using the submitted public key, it registers the new public key and its credential ID against the same VAID. Providing the VAID alone does not authorize registration. When no authorized device remains, custodian-assisted recovery locates the existing VAID and authorizes the replacement key, as explained under “Key recovery and continuity.” Each device retains its own private key and is provisioned separately with access to the customer’s record-encryption key.

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 device 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 app-mediated access, the PCX Platform uses a passwordless public-key challenge–response protocol. Each authorized device has its own public/private key pair and a credential ID identifying that credential. The platform registers each credential ID and its corresponding public key against the customer’s VAID. The device retains its credential ID and private key.

Multiple device credentials can be authorized under the same VAID. The VAID identifies the customer’s persistent account, while the credential ID identifies the particular key being used for authentication.

1.  When the app starts, the PCX Platform issues a fresh cryptographic challenge for that authentication attempt.
2. The device signs an authentication response containing the challenge using its own private key, which never leaves the device.
3. The app returns the signed response together with its credential ID and the authentication-request reference.
4. The PCX Platform uses the credential ID to retrieve the corresponding public key from its registration records and identify the VAID associated with that credential.
5. The platform verifies the signature using that registered public key. It also checks that the response matches the outstanding challenge, that the challenge has not expired or already been used, and that the credential remains authorized for the account.
6. If these checks pass, the challenge is marked as used and the platform opens a session for the associated VAID. The device may then synchronize with the customer’s encrypted vault.

The credential ID serves as a lookup reference. Possession of that identifier alone does not grant access: the device must produce a valid signature using the private key corresponding to the registered public key.

Authentication and decryption are separate steps. After authentication, the app can retrieve encrypted records and use the device-resident sealed copy of the customer-controlled symmetric data-encryption key. The device uses its private key to unseal that copy and decrypt records locally as needed. Access to the record-encryption key must have been provisioned separately for that device; registering an authentication credential alone does not provide it.

The session flow is passwordless and cryptographic: the platform authenticates control of a specific authorized device credential and grants access to the associated pseudonymous account. No PCX password or personal identifier is required for this authentication, while the real-world identity relationship 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

This design separates device authorization from access to encrypted CTRs. If another authorized device remains available, it can approve a replacement device key and provision access to the existing data-encryption key. If all authorized devices are lost or reset, account continuity is restored through the custodian, while the recovery code is needed to recover access to the encrypted records. The custodian-assisted path is:

1. The user re-verifies or re-establishes the identity relationship with the custodian.
2. The custodian attests the replacement device’s public key and issues a recovery attestation for the existing account.
3. The PCX Platform verifies a continuity proof and registers the replacement device key against the existing VAID.
4. The previous device authorizations and superseded attestations are retired. The reward balance and the audit trail remain associated with the existing VAID.

A newly attested key is not enough by itself. The replacement device can prove control of that key, but this does not tell the PCX Platform which existing account to open. The VAID is the account number, not a secret, so knowing it cannot authorize recovery. The custodian’s continuity proof links the new key to the public key attested at enrollment. The PCX Platform processes that proof inside a Trusted Execution Environment (TEE). The TEE uses the earlier attested public key to locate the existing VAID. The PCX Platform then registers the new key and retires the lost credentials. The custodian need not learn the VAID, the PCX Platform receives no identity, and the customer does not have to remember the VAID. The PCX Platform rejects account substitution and reuse of a completed proof.

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-controlled symmetric data-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. Each authorized device stores its own sealed copy of the same customer encryption key; the PCX Platform does not hold these device-resident copies. 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 data-encryption key is established at account creation and need not change during routine device replacement. The architecture maintains two types of protected representation of that key: a separate device-bound sealed representation for each authorized device and a recovery-sealed representation accessible through the recovery code. When no authorized device remains, 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. Routine recovery replaces the device-bound sealed copy; 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 all authorized devices have been lost or reset, 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 need not be decrypted or re-encrypted during recovery, so the process does not require reprocessing the customer’s transaction history. A customer who loses access to all authorized devices and the recovery code cannot recover their transaction history, and neither can the PCX Platform. This recovery limit preserves customer control of the encryption keys and must be made explicit during enrollment.

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.

The planned recovery checks include adding a second device without changing the VAID; replacing a lost device using a surviving authorized device; recovering through the custodian and recovery code when all devices are lost; rejecting retired keys, account substitution, and replayed recovery proofs; and confirming that loss of all device-held keys and the recovery code prevents decryption of prior CTRs.

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.