Making every transaction record usable to customers as well as merchants
How transaction records work today
Billions of purchases happen every day, and every one of them creates a record: what was bought, where, when, and for how much. When the purchase transaction completes, each record immediately splits in two. The merchant files the authoritative copy into its own database, structured, electronic, and retained because the business needs it for accounting, tax, and inventory. The customer’s copy takes whatever form the sales channel dictates: a paper receipt at a store counter, an emailed invoice for an online order, an entry in a platform’s order history. A few large platforms, such as Amazon, maintain a complete purchase history inside the customer’s platform account; most businesses simply give the customer a copy and keep the original in their own database.
The result is that the same economic fact (this person bought this item at this price) exists in several places at once, in incompatible forms, under different custodians. The merchant’s copy sits in a silo built for that merchant’s operations. The customer’s copies sit in shoeboxes, inboxes, and scattered platform accounts, mostly discarded shortly after purchase unless needed for a warranty or a return. No party, including the customer who created the records, holds a complete, machine-readable picture of what was actually bought across merchants.
Why the records stay fragmented
The fragmentation of transaction records is not an oversight. It is the result of constraints that each exist for a sound reason.
Payment security
Payment security imposes the first constraint. PCI DSS places strict controls on the storage and handling of primary account numbers (PANs), so merchants generally avoid using the card number itself as a persistent customer identifier. A merchant that runs a loyalty program therefore links purchases to a locally issued membership identifier rather than to the card itself. That identifier is created by the merchant, resolved by the merchant’s point of sale, and is meaningful only within the merchant’s own systems. A customer who shops at five stores carries five unrelated identifiers, and no store can connect its identifier to any other.
Enrollment
Enrollment imposes the second constraint. To join a loyalty program, a customer must disclose identity: an email address or phone number for an ID-based program, copies of official identification for a card-based one. The disclosure is the price of participation: customers who decline remain invisible to the program, and customers who accept are tracked under their real identity, with the attendant exposure to misuse and breach.
Anonymization
Anonymization, the apparent remedy, imposes the third constraint by failing. Removing names and account numbers from transaction data does not remove identity; purchase histories are distinctive enough that de-identified records have repeatedly been re-identified by linking them to outside information. Organizations that hold transaction data therefore face a binary choice: delete the records when regulation requires it, or retain them in personally attributable form under security controls. What is missing is a widely adopted mechanism for retaining and reusing transaction records across contexts while keeping customer identity structurally separated from the records themselves.
What the fragmentation costs
Transaction record fragmentation imposes a cost across the commerce ecosystem: customers, merchants, brands, manufacturers, and service businesses.
Customers
Customers cannot see their own economic activity. The transaction records they created are scattered across formats and custodians, so there is no practical way to review spending across merchants, compare purchases over time, or carry a verifiable purchase history from one context to another. The data exists; the customer simply has no usable copy of it.
Merchants
Merchants see only their own counter. A store knows what a customer bought under its roof and nothing beyond it. The surrounding picture (what the same customer buys elsewhere, which products they abandoned, where their loyalty actually lies) is invisible, so merchandising, inventory, and marketing decisions are made from a fragment of the customer’s behavior.
Brands & Manufacturers
Brands and manufacturers are blind in a different way: their customers are hidden behind the retailers who sell for them. A shopper who buys the same shampoo five times from five different stores is, by any reasonable definition, a loyal customer of that brand, yet no single store can see the pattern, and the manufacturer cannot see it at all. The brand has no way to recognize its most loyal customers, let alone reward them.
How PCX solves fragmentation
The Privacy-Compliant eXtensible (PCX) protocol links each transaction record to a pseudonym rather than to the person behind it when the record is generated. For card transactions, a tokenized payment credential travels with the authorization and allows the record to be resolved to a customer account on the PCX Platform without exposing the card number or the customer’s name. Non-card transactions can use an account-linked credential to establish the same association. The PCX Platform is the server-side infrastructure that implements the protocol. Transaction records accumulate in a cloud account the customer controls, keyed to a pseudonym that persists across merchants. Reviews attach to the same pseudonymous account. When a customer joins a merchant’s loyalty program, the merchant sees that customer’s purchases at its own store and partner network and rewards on volume; it sees nothing beyond. The platform holds transaction detail; the identity behind it is never captured. This PCX pipeline is protected by a granted patent family, with grants in the US, Australia, and India.
How PCX is governed
PCX is designed as shared commercial infrastructure rather than a proprietary data platform. Customer Transaction Records (CTRs) contributed through PCX form a governed data commons whose value is created collectively and is intended to persist independently of any single participant, including ValiDeck. These records are governed by common privacy, access, and reciprocity rules rather than treated as proprietary data belonging to the platform operator. The governance model rests on four principles: a shared data commons, reciprocal participation, an open application layer, and jurisdictional oversight.
Shared data commons
PCX establishes a common transaction-record substrate for the participating ecosystem. The commons is not a public database and is not intended to become a proprietary data asset of ValiDeck or any other participant. Records remain subject to PCX privacy, access, and governance controls, while participants receive only the representations or outputs they are authorized to use.
Reciprocal participation
Access to the commons is reciprocal. Businesses that benefit from permitted outputs derived from shared transaction records must contribute their own qualifying CTRs under the same framework. A participant cannot withhold eligible records while benefiting from records contributed by others.
Open application layer
PCX separates the common infrastructure from the services built on top of it. ValiDeck and independent providers can develop competing search, loyalty, analytics, AI-assistance, and other applications through defined interfaces and privacy-bounded outputs. Participation in PCX does not require using a ValiDeck application.
Jurisdictional oversight
ValiDeck is leading the initial development of the PCX protocol and reference implementation, with broader technical and institutional participation expected as the platform evolves. The shared infrastructure is intended to operate under jurisdictionally defined governance rather than ValiDeck’s unilateral control.
2026 patent filings
Extending the protocol
The 2026 patent filings extend the PCX architecture in ways that support the governance model described above. Each transaction record is separated into customer, merchant, and synthetic components so that the complete, attributable customer record can remain under customer control while privacy-bounded representations can support the shared commercial infrastructure. This separation provides the technical basis for a shared data commons without turning that commons into a repository of openly accessible customer records.
The synthetic component also enables qualifying transaction information to contribute to common capabilities without exposing the underlying customer record or identity. This makes reciprocal participation practical: businesses can contribute to and benefit from the shared substrate under common rules rather than exchanging raw transaction databases. Because applications operate on defined records and permitted outputs rather than requiring ownership of the underlying commons, the same substrate can support an open application layer for loyalty, analytics, search, and other services.
The patent filings do not themselves determine who governs the infrastructure. They provide a technical architecture in which custody of customer records, operation of the shared substrate, and delivery of application services can remain structurally separated. That separation makes it possible for the common infrastructure to operate under jurisdictional oversight while ValiDeck and other providers compete at the application and service layers.