Frequently Asked Questions (FAQs)
Section 1: The basics
Privacy-Compliant eXtensible (PCX) is a proposed protocol for structuring authoritative records so that they retain their utility without making user identity a part of the record-linkage layer. It is infrastructure rather than a product — a common framework for capturing, structuring, protecting, and reusing authoritative records, not an end-user application.
PCX-CTR is the first commerce application of that protocol, focused on customer transaction records (CTR). It records each transaction such that the record may be stored, linked, and reused for loyalty, analytics, and search without carrying the identity of the person behind it. The record is bound to a pseudonym at the moment of creation rather than to a named individual. A token, not a card number and not a name, carries the record from the point of sale into an account that the customer controls on the PCX Platform. Records accumulate in that account across every participating merchant under a single pseudonym, and that customer-controlled record set is the substrate on which loyalty, analytics, and search are built.
The distinction between protocol and product is deliberate. A protocol defines the rules and interfaces; a platform implements those rules; and products and services can operate on top. ValiDeck intends its reference platform to prove interoperability and privacy boundaries while allowing other qualified parties to implement compatible products and services. PCX is therefore neither a consumer app nor a claim that ValiDeck must own every application built on the infrastructure.
No. PCX has been specified end to end, but the reference PCX Platform has not yet been built, and no public demonstration is available. Foundational patents have been granted in the United States, Australia, and India, while related filings and newer PCX-related patent applications remain pending. Phase I will build the reference PCX Platform.
The ValiDeck Roadmap sets out the phased build in full — platform design, backend development, analytics and compliance, and integration proof — carried through to a working prototype and an independent privacy audit, and from there toward enterprise pilots. The prototype scope comprises a payment-transaction simulator, a point-of-sale integration layer, and a loyalty server. The independent audit is treated as a gating condition rather than a closing formality, on the principle that a privacy claim asserted by its own author is worth very little.
ValiDeck is preparing to develop this prototype as a small, focused effort, building on institutional support received through IPON and Communitech. The honest answer on timing is that the schedule depends on funding, build progress, and the partnerships now being pursued. This page will state that plainly rather than commit to a date it cannot yet defend.
Investors, payments partners, and researchers who wish to review the architecture in detail are invited to get in touch.
Section 2: Privacy
Customer transaction records captured on the platform are pseudonymous, not anonymous, and the distinction is material. Anonymous data is intended to be no longer linkable to an identifiable person in the relevant context. Pseudonymous data remains linked to a durable pseudonym rather than to a name. In the PCX-CTR design, transaction detail and the identity mapping are held on separate sides of the architecture, preserving continuity without making identity part of the record-linkage layer.
This is a deliberate design choice. Granular transaction data can remain vulnerable to re-identification even after conventional anonymization. PCX-CTR therefore separates identity from the record-linkage layer instead of relying on anonymization alone, with the elements required for lawful re-identification divided across separate participants.
By design, PCX-CTR separates transaction detail from identity mapping by giving each participant a deliberately bounded view of the relevant information:
- The merchant observes the transactions within its own program scope and computes loyalty upon them. The PCX-CTR design does not require the merchant to learn who the customer is.
- The bank or card issuer knows the customer and the payment-related information it ordinarily processes, but it does not receive the PCX-CTR line-item transaction record.
- The PCX Platform holds transaction detail against a token or pseudonymous account, but not the person behind it. The identity mapping remains with the issuer or other authorized custodian and is not disclosed to the platform in normal operation. This applies to ValiDeck itself: the transaction detail exists, the identity does not travel with it, and the platform does not receive the custodian’s mapping between the two.
- The customer is intended to be the only participant able to view the complete cross-merchant record together with their own identity.
The designed accountability pathway for reconnecting a PCX-CTR record to a named person requires controlled access to both the transaction-side record and the custodian’s identity mapping, ordinarily under lawful authority. That accountability pathway is intentional: privacy should prevent routine identity exposure without making legitimate oversight impossible.
In the proposed reference implementation, the PCX app generates a public/private cryptographic key pair locally on the customer’s phone or computer. The private key remains on the customer’s device while the public key is submitted to an authorized custodian or identity provider for attestation. In the card-based PCX-CTR path, the customer’s card issuer can perform this role.
The custodian verifies the customer through its existing identity-verification process and records the association between the customer and the submitted public key. It then issues a digitally signed attestation of the public key. The customer’s identity records and the identity-to-key association remain with the custodian. No customer name, email address, telephone number, or payment card detail is included in the attestation sent to the PCX Platform. The platform receives confirmation that a trusted custodian has attested the key, without receiving the underlying identity data.
The PCX Platform verifies the custodian’s signature and, at first enrollment, derives a pseudonymous ValiDeck ID (VAID) from the attested public key. This creates the account under that VAID and registers the public key as the account’s first authorized device credential. The VAID identifies the persistent account; the registered public key enables authentication of the customer’s device. Additional or replacement devices can subsequently register their own public keys against the same VAID through the authorization procedures described in Q5.
The customer activates the account by proving possession of the corresponding private key. The PCX Platform issues a cryptographic challenge, the device signs it using its private key, and the platform checks the signature using the registered public key. Subsequent access follows the same principle, using a fresh challenge. The private key is never sent to the platform. No PCX password is required. There is no password to choose, remember, or reset, and the platform does not need a central database of password hashes or other shared secrets for account authentication. This avoids exposure to password reuse and credential stuffing against PCX passwords. Security instead depends on protecting device keys and on the authorization and recovery procedures described in Q5 and Q7–Q9.
Account creation also establishes the scope of ongoing transaction capture that the customer is agreeing to. From enrollment onward, qualifying transactions made with an attested payment credential at any participating merchant may be added to the customer’s PCX-CTR record, whether or not the customer has separately joined that merchant’s loyalty program. The intended model is a single enrollment with the PCX Platform covering ongoing capture across participating merchants, broadly comparable to a bank or card statement that records transactions across merchants. This scope is disclosed and agreed to at account creation, so the customer does not need to repeat that enrollment at each participating merchant. See Q12 for how transaction capture and merchant loyalty enrollment relate.
The PCX Platform does not require a user’s devices to share the same private cryptographic key. Each authorized device — such as a phone, laptop, or tablet — generates and retains its own cryptographic key pair. The private key remains on that device, while the corresponding public key is registered with the PCX Platform.
All authorized devices for the same customer are associated with the same ValiDeck ID (VAID). The VAID identifies the customer’s persistent account on the PCX Platform, while each registered public key serves as a separate authentication credential for one authorized device. The VAID is not recalculated when a device key is added, replaced, or retired. Each device’s public key is stored under its own credential ID linked to that VAID, so several device credentials can be active under one VAID. Adding or replacing a device key does not create a new account. A customer using a phone and a laptop therefore has one VAID but two independently generated cryptographic key pairs.
When an additional or replacement device is added, it generates its own key pair independently. Its public key is registered against the existing VAID and authorized through an already authorized device or, when no authorized device remains, through the recovery process. Once authorized, each device can authenticate to the same account on the PCX Platform without a password. For subsequent access, the PCX Platform issues a fresh, single-use challenge bound to the sign-in attempt. The device signs the challenge and returns the response with its credential ID. The PCX Platform uses that ID to retrieve the registered public key and associated VAID, verifies the signature and challenge, and checks that the credential remains authorized before opening the session.
This approach allows devices to be managed independently. If one device is lost, replaced, or compromised, its public-key authorization can be revoked without changing the VAID or the cryptographic credentials of the customer’s other devices. Private keys therefore do not need to be copied or shared between devices.
Not routinely. The PCX Platform is not designed to provide regulators with routine access to individual customer transaction histories. Regulatory outputs are intended to be population-level, thresholded, and privacy-preserving, supporting oversight, market analysis, and policy evaluation without exposing identifiable customer histories. Any exceptional identity-linked access would require a separately governed lawful process.
Section 3: Account Access and Recovery
The PCX Platform separates device authentication from record encryption. Customer transaction records are encrypted using a separately provisioned, customer-controlled symmetric data-encryption key rather than directly with a device’s authentication key. Successful authentication alone does not supply that key.
For each authorized device, the same symmetric data-encryption key is wrapped separately using that device’s public key. When the device needs to access a transaction record, it uses its private key to recover the data-encryption key and then uses that key to decrypt the record. This allows a phone, laptop, or other authorized device to access the same encrypted transaction history without sharing private keys. Each device retains its own cryptographic credentials, while access to the common record-encryption key is provisioned separately for that device.
When a new device is authorized, an existing authorized device can provision access to the same data-encryption key for the new device without requiring the customer’s transaction history to be decrypted and re-encrypted. If no authorized device remains, the recovery code is needed to recover that key, as described in Q9.
Yes. If the user still has access to another authorized device, that device can be used to authorize a replacement or reset device without requiring the customer to re-verify with the custodian.
The replacement device first generates a new cryptographic key pair. Its private key remains on the device, while the new public key is submitted to the PCX Platform for registration with the customer’s existing account. The surviving authorized device then approves the new public key after the user authenticates locally. Once registered and authorized, the new device can authenticate directly with the PCX Platform. During login, the PCX Platform issues a cryptographic challenge, the device proves possession of the corresponding private key, and the PCX Platform verifies the response using the registered public key.
The authorization associated with the lost or reset device can then be retired. Custodian re-verification is required only when the user no longer has access to any authorized device capable of approving a new device key.
If every authorized device is lost, the replacement device generates a new key pair and the customer re-verifies with the original custodian. The custodian issues a one-time continuity proof linking 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 ValiDeck ID (VAID). The PCX Platform then registers the new key and retires the lost-device credentials.
The VAID is the account number; the private key proves control of an authorized device. Neither a newly attested key nor knowledge of a VAID is sufficient by itself. The custodian need not learn the VAID, the PCX Platform receives no identity, and the customer does not have to remember the VAID. Encrypted records are recovered separately. With no surviving authorized device, the customer uses the recovery code to restore the encryption key on the replacement device. The code should therefore be stored apart from the devices and treated as a high-value secret.
If the devices and recovery code are all lost, the custodian can restore the account and reward balances, but neither ValiDeck nor the customer can recover the previously encrypted transaction history.
Transaction records already exist within merchant systems, but a PCX-CTR implementation would create an additional protected record store and therefore an additional attack surface. The relevant questions are what each store contains, whether it carries identity, who can read it, and how compromise is contained. Conventional loyalty systems often bind detailed purchase histories to identifiers collected at enrollment. Under the granted PCX foundation, the PCX-CTR-held record is associated with a token and pseudonymous account rather than the customer’s name or PAN. The merchant continues to retain its own transaction record and any information it needs for ordinary operations.
PCX-CTR changes the exposure; it does not eliminate it. Pseudonymous transaction histories can still be sensitive, correlated, or misused, so they require encryption, access controls, monitoring, retention rules, incident response, and independent review.
Under the granted foundation, a compromise of the PCX-CTR record store would expose token-linked records rather than a ready-made list of named purchase histories. That reduces direct attribution but does not make the breached data harmless. The PCX-CTR linkage does not require a merchant to collect extra identity for loyalty. If the merchant already knows the customer for delivery, payment, or another purpose, PCX-CTR does not erase that separate relationship.
The customer is intended to receive the cross-merchant view through a customer-controlled account. The platform’s ability to assemble records does not entitle ValiDeck, a merchant, or a sponsor to use the customer’s complete history outside the defined purpose.
The pending 2026 architecture is designed to reduce exposure further by separating each transaction into customer, merchant, and synthetic records. The customer record is complete and encrypted with a customer-controlled data-encryption key, with access to that key protected separately for each authorized device; the merchant record supports the merchant’s own operations; and the synthetic record retains only the limited parameters needed to evaluate defined rules across merchants.
That separation is intended to reduce direct attribution and the impact of a single compromise. It remains a design claim until the implementation is built, tested, and independently reviewed. The applications are pending, and this page describes the intended outcome at a high level.
PCX-CTR is therefore a different allocation of control and exposure, not a risk-free repository. The goal is to keep identity out of the linkage layer, give the customer the useful record, and minimize what any other participant can learn.
Section 4: For customers
A customer joining a merchant loyalty program implemented using PCX-CTR is intended to receive three benefits together in one architecture.
- One consolidated purchase history across participating merchants. A customer’s records are presently scattered across merchants, inboxes, and paper receipts, in formats that cannot be assembled into a single view. PCX-CTR is designed to consolidate them into one account the customer controls, at line-item detail.
- Loyalty without disclosure. Joining a merchant’s loyalty program is designed to require no name, email address, or telephone number. Pseudonymous token linkage performs the recognition function that identity often performs in conventional loyalty systems.
- Rewards that follow behavior rather than identity. The pending architecture is designed so that a brand may define a rewards policy that the platform applies across unaffiliated stores, with the brand receiving only scoped eligibility indicators, never the underlying records and never the person behind them.
One point of clarification is worth stating explicitly, because the question is frequently asked in this form: PCX-CTR is not a scheme by which customers sell their purchase data. The architecture is built to keep records out of the hands of parties that would profile the person behind them, and that constraint includes ValiDeck.
Customers and participating merchants first establish their accounts on the reference PCX platform. For the customer, this is a one-time process in which the platform establishes the account through the customer’s attested public key. The customer does not need to create a new identity, acquire a merchant-specific loyalty card, or provide an email address or telephone number to join a loyalty program.
To join a merchant’s loyalty program, the customer signs up through the merchant’s portal and consents to establishing a loyalty relationship between the customer’s PCX-CTR account and the merchant’s PCX-CTR account. The customer can establish separate relationships with an unlimited number of participating merchants.
A customer does not have to join a merchant’s loyalty program for the PCX-CTR implementation to capture their transactions at that merchant. Those transactions can still accumulate as part of the customer’s records, but they do not count toward the merchant’s rewards program, and the PCX Platform does not disclose a loyalty-account linkage to the merchant solely because the transaction was captured. This broader capture is part of what the customer agrees to once, at account creation, rather than merchant by merchant, as described in Q4: creating a PCX-CTR account means qualifying transactions at any participating merchant may be added to the customer’s record, whether or not the customer has joined that merchant’s loyalty program.
Once the customer joins, qualifying purchases can contribute to rewards and the merchant can understand that customer’s purchasing behavior within its own program. This allows the merchant to provide rewards and more relevant offers without receiving the customer’s underlying identity or gaining access to the customer’s records with other merchants.Â
Section 5: For businesses
Because the core loyalty requirement is usually recognition of repeat behavior, not possession of a customer’s identity. Conventional programs often use names, email addresses, or telephone numbers as the mechanism for recognizing a returning customer. PCX-CTR is designed to provide recognition and reward through pseudonymous linkage instead. The merchant can evaluate activity within its own program scope and reward on that basis without requiring identity for the loyalty function.
What the merchant gives up is identity data it may not need for the loyalty function. Personal information or personal data must be secured, governed, retained appropriately, and handled under applicable privacy law, and it increases the consequences of a breach. What the merchant gains is lower disclosure friction at enrollment and a loyalty model that does not depend on collecting a telephone number or email address simply to recognize repeat behavior.
Large businesses can absorb the cost of issuing cards, integrating loyalty systems, and managing customer data. A stationery shop, boutique, or café may not be able to justify the same operational and compliance overhead.
The PCX-CTR design is intended to lower that overhead by using reusable payment and point-of-sale integrations rather than merchant-specific identity infrastructure. There is no co-branded loyalty card to issue and no need to collect customer identity solely for loyalty, reducing both implementation complexity and the amount of personal information the merchant must manage.
The more consequential shift concerns what a small business is able to learn. A conventional café loyalty program sees only the café’s own activity. Under the pending architecture, a small business could receive aggregated or scoped indicators derived from synthetic records across participating merchants without receiving another merchant’s records or identifying an individual customer. The exact analytics, governance, and commercial terms remain to be validated.
Search does not need a named customer or access to the complete customer record. It needs reliable, appropriately bounded signals about products, merchants, and transactions.
A transaction-linked record can establish that a verified transaction occurred. Repeat purchase, verified reviews, and cohort-level patterns can contribute additional signals, but none should be treated as proof of satisfaction on its own. The reasons for repeat or discontinued purchase are varied, so ranking rules require testing, transparency, and safeguards against manipulation.
The granted foundation supports transaction-linked record capture and linkage. Separate 2026 applications extend the architecture to bounded search and analytics signals derived from privacy-protected records without exposing the complete customer record or identity. The search design remains subject to implementation, validation, and governance.
Section 6: Governance and participation
The transaction-data repository within the PCX Platform is not designed to be a proprietary asset permanently owned or controlled by ValiDeck. The CTR/SATR substrate is intended to operate as shared, jurisdictionally governed infrastructure under defined privacy, access and participation rules.
ValiDeck’s role is to develop the PCX protocol and build a reference PCX Platform demonstrating what the architecture makes possible. During the reference-platform stage, ValiDeck operates the system. At scale, however, the shared infrastructure is intended to operate under jurisdictional governance rather than as ValiDeck’s private data asset.
This separation is deliberate. The shared transaction-data commons provides the common substrate, while ValiDeck and other companies can compete in building applications and services that use the outputs the infrastructure permits.
No. Participation in the shared infrastructure is reciprocal by design. A business cannot withhold qualifying Customer Transaction Records (CTRs) while obtaining permitted insights derived from records contributed by other participants.
Participating businesses therefore contribute qualifying CTRs under the same rules that govern other participants. Contribution, however, does not expose one business’s raw transaction records to another. Applications operate only on the privacy-bounded representations, aggregates and outputs permitted by the PCX protocol.
The purpose of reciprocity is to prevent free-riding while allowing the shared transaction-data commons to become more useful as participation grows.
Section 7: Adoption and intellectual property
Receipt-reward and receipt-scanning applications are useful comparisons, but PCX-CTR is intended to occupy a different layer — transaction infrastructure rather than a single consumer rewards application. That distinction is clearest across four areas: capture point, system role, identity and control, and interoperability and reach.
Capture point: Receipt-scanning applications generally reconstruct a purchase after the transaction, from a submitted image or electronic receipt. PCX-CTR is designed to capture a structured transaction record through the participating merchant’s transaction path.
System role: A receipt application typically operates its own program and handles records under its own account and terms. PCX-CTR is a commerce implementation of the broader PCX protocol. It is intended to run on the reference PCX Platform, which can support multiple loyalty, analytics, search, and review services.
Identity and control: PCX-CTR is designed so that transaction-record linkage does not require the reference PCX Platform to hold the customer’s name or PAN. Under the pending architecture, the complete customer record is customer-controlled, while other parties receive only the records or scoped results required for their roles.
Interoperability and reach: A conventional merchant program is limited to its own stores or partner network. The PCX Platform is designed as shared infrastructure; PCX-CTR implements the PCX protocol across participating and unaffiliated merchants under common technical and governance rules.
The pending 2026 commerce architecture is designed to evaluate defined rules across participating and unaffiliated merchants using synthetic records, while returning only bounded results to the sponsor. The distinction is therefore architectural: PCX-CTR is intended as shared transaction infrastructure built on the broader PCX protocol, not as an application-specific receipt-reward service.
The card-based implementation depends on issuer participation but PCX itself is not limited to payment-card records. In the granted card-based architecture, the issuer resolves the payment card to a protected PCX token, and that token — not the PAN — supports routing the transaction record to the correct pseudonymous account. Commercial deployment of that card-based path therefore requires cooperation across issuers, payment networks, acquirers, merchants, and point-of-sale providers.
Existing payment tokenization demonstrates that surrogate card values can be issued and carried through payment systems, but it does not automatically provide PCX-CTR’s account-linkage semantics, cross-merchant scope, or governance. Phase I can use a simulator, reference connectors, and a controlled tokenization service to test the protocol and integration boundaries. That would validate a reference implementation; it would not by itself establish network-wide interoperability. Commercialization depends on representative partner integrations, compliance work, defined responsibilities, and eventually standardization. The Roadmap treats standardization as a parallel workstream so that implementation evidence and formal standards can reinforce one another.
Those working in payments who wish to discuss the integration path in detail are invited to get in touch.
ValiDeck owns a foundation patent family covering the core tokenized transaction-capture and linkage architecture. Patents have been granted in the United States, Australia, and India. Related applications and prosecution continue in Canada, Europe, China, and through a further U.S. continuation. Separate applications filed in the U.S. and Europe in 2026 cover the newer customer, merchant, and synthetic record architecture and bounded cross-merchant computation; those applications remain pending and subject to examination. Additional applications filed in the U.S. and Europe in 2026 cover on-device domain-specific assistance using authoritative canonical records across multiple domains, including commerce, health, automotive, and travel.
ValiDeck is also developing the PCX specification and building the reference PCX Platform. These rights do not mean ValiDeck owns customer records, merchant records, payment networks, or any future public standard. For details, see the Patents and About pages.