Replacing customer identity with a pseudonym on every transaction record
The PCX pipeline
PCX is designed to link each transaction record to a pseudonymous customer account, beginning at the point where the record enters the PCX pipeline. In the proposed card integration, the payment response carries the authorization result and an encrypted, issuer-supplied PCX linkage token. The PCX Platform uses the registered token to associate the completed transaction with the correct account without using the customer’s real-world identity as the transaction-record key.
A card purchase involves a payment-authorization request and a corresponding response. First, the merchant sends the request through the existing payment infrastructure: Merchant → Acquiring Bank → Payment Network → Card Issuer. The Card Issuer evaluates the transaction for authorization. In a PCX-enabled integration, the issuer also retrieves the card’s PCX linkage token and encrypts it with the platform’s token-resolution public key. The payment-authorization response travels back through the payment chain: Card Issuer → Payment Network → Acquiring Bank → Merchant.
In a PCX-enabled transaction, the merchant forwards the completed transaction record, together with the relevant authorization information and encrypted token, one step further: Merchant → PCX Platform. The platform’s protected token resolver decrypts the token and looks up the pseudonymous account to which it is registered. The qualified record can then become part of the customer’s consolidated transaction history without requiring the PCX Platform to use the customer’s name, email address, phone number, or payment-card number as the linkage mechanism.
The transaction-based capabilities described on the Concept page — including loyalty, reviews, analytics and search — depend on records produced through this pipeline. Tokenization is one component of the broader architecture: it provides a linkage reference that allows a transaction originating at a merchant to reach the correct pseudonymous PCX account. In the diagrams below, “PCX Platform” refers to the server-side infrastructure that implements the PCX protocol, resolves the protected transaction linkage, and performs the record-processing functions required by the architecture.
This PCX record-linkage flow requires agreed issuer, network, acquirer, and merchant interfaces, including a way to carry the encrypted token with the payment response. Token replacement and renewal must preserve an authorized association with the same account. Existing payment tokenization does not, on its own, establish this PCX integration.
How tokenization works in PCX
Tokenization replaces sensitive data, such as a payment card’s primary account number (PAN), with a substitute value called a token. Tokens are widely used in the payment card industry to reduce exposure of PANs and limit the consequences if payment data is compromised. Tokenization does not, however, make the substituted value inherently harmless. Its security depends on restrictions on where and how the token can be used, protection of the token-to-PAN mapping, and the security of the systems that process it.
PCX uses a dedicated token for a related but distinct purpose: linking a transaction record to a pseudonymous PCX account. Think of the PCX linkage token described in the preceding section as a protected routing label accompanying the record. The card issuer creates the token and retains the card-to-token mapping and its direct relationship with the customer. The PCX Platform maintains a separate association between the token and the customer’s pseudonymous account. When a qualifying transaction occurs, the encrypted token allows the protected resolver to determine which account should receive the record — without requiring the card number or the customer’s real-world identity in the PCX record-linkage layer.
The three workflows below show how this relationship is established and then used. First, the customer opens a PCX account using a locally generated key pair attested by their card issuer. Second, each participating payment card is tokenized by its issuer and the token is registered to that account. Third, qualifying transactions from participating merchants can be added automatically using the registered token. Initial account and card registration enable ongoing capture within the agreed enrolment scope; token lifecycle changes and recovery are handled separately.
Opening an account on the PCX Platform
The customer initiates account creation on their device. The device generates a public/private key pair locally. The private key remains on the device, and the public key is prepared for attestation.
The customer device sends the public key to the payment card issuer and requests attestation. The issuer verifies the customer through its existing relationship before attesting the key. No customer identifier is shared with the platform at this step.
The issuer attests the public key against the customer record it already holds and returns the key with a digitally signed attestation to the customer device. The issuer carries its verification forward as an attestation on the key, rather than sharing the underlying identity data.
The customer device submits the attested key to the PCX Platform. The platform verifies the trusted issuer’s signature and checks that the attestation covers the submitted public key. The device proves possession of the matching private key by signing a fresh challenge. No email address, phone number, or payment card information reaches the platform at this step.
The PCX Platform creates a persistent pseudonymous account, assigns its ValiDeck ID (VAID), and associates the attested device key with it. Additional authorized devices can use their own keys to access the same account.
Account creation happens once; authorizing another device does not create another account or VAID.
Registering tokenized cards on the PCX Platform
The customer asks each participating card issuer to tokenize the card for PCX. The issuer verifies the customer’s authority to register that card. Nothing reaches the platform yet.
The issuer generates a PCX linkage token for the card, retains the card-to-token mapping, and encrypts the token for the PCX Platform. The card number remains outside the PCX Platform.
The issuer sends the encrypted token to the PCX Platform through an authenticated registration request.
The PCX Platform places the token in a pending-registration queue and notifies the customer through the issuer’s authenticated channel. The customer’s identity and card number are not disclosed to the PCX Platform.
The customer authenticates with an authorized device and approves linking the pending token to their VAID. The PCX Platform verifies the issuer-confirmed request and completes the registration. Future qualifying transactions on that card can then be linked to the account.
Registration happens once per participating card. The card number does not enter the PCX record-linkage pathway; only the encrypted PCX linkage token reaches the PCX Platform.
Recording tokenized card transactions on the PCX Platform
The customer pays with a participating card already registered with PCX in the usual way — by tapping, inserting, swiping where supported, or using it online. PCX capture requires a participating merchant and a payment integration that supports the PCX flow. The token must be registered to the customer’s account before the transaction record can be appended.
In a PCX-enabled transaction, the merchant asks its acquiring bank to authorize the transaction and return the PCX linkage token associated with the card. The acquiring bank forwards the request to the payment network, which passes it to the card issuer.
The issuer applies its payment-authorization checks. For an authorized PCX-enabled purchase, it returns the authorization together with the linked token, encrypted with the platform’s token-resolution public key, back through the payment network to the acquiring bank.
The merchant receives the authorization and the encrypted token from the acquiring bank, associates the completed transaction record with that token, and submits the record, authorization information, and encrypted token to the PCX Platform through an API. The PCX Platform checks the required provenance, integrity, and record fields before accepting the record.
The PCX Platform resolves the encrypted token to the registered VAID and, after verifying the transaction record, appends the qualified record to that account. If the token is not yet registered, the platform returns a registration-required status so the record can be retried after registration. This affects only PCX record capture, not the payment authorization.
A transaction record reaches the PCX Platform through a registered PCX linkage token or a supported non-card path. The platform verifies the account association before adding the record to the customer’s consolidated transaction history.
Recording non-card transactions
Not every transaction runs through a payment card reader. In the proposed non-card path, the customer’s app presents a short-lived, transaction-bound account credential using a QR code, a barcode, or NFC. The credential enables linkage to the customer’s account without exposing a reusable VAID to the merchant. Alternatively, the PoS can present the transaction record as a QR code for the customer’s authenticated app to scan. The PCX Platform processes the short-lived credential inside a Trusted Execution Environment (TEE), where it is resolved to the customer’s VAID, the authorized account linkage is confirmed, and the verified record is appended to the correct transaction history without exposing the VAID outside the TEE. The underlying payment can be settled by cash, check, or e-transfer. The capture interface must establish the record’s provenance and account linkage independently of the payment method.
This path extends the customer’s purchase history across supported payment methods and participating merchants. Within a Trusted Execution Environment (TEE), the short-lived credential is resolved to the customer’s VAID, allowing verified transactions to be added to the correct pseudonymous account and used for loyalty participation without exposing the VAID to the merchant.
What each party can see
The following describes the intended access boundaries across the proposed PCX stack. Token-based capture and pseudonymous aggregation form the granted foundation; canonical-record separation, customer-controlled key custody, privacy-bounded analytics, and regulatory outputs depend on the pending 2026 architectures. Their effectiveness must be demonstrated through implementation, testing, and independent review; a patent grant does not itself demonstrate those controls.
The merchant
The merchant holds the records of its own transactions and receives the information permitted for its loyalty program. Participation does not provide unrestricted access to the customer’s purchases elsewhere. Cross-merchant rewards can use scoped eligibility results instead of disclosing unrelated transaction histories. A merchant may independently know the customer through other services, but PCX does not require that identity for record linkage.
The bank or issuer
The bank or issuer retains its customer relationship, the card-to-token mapping, and the payment information it ordinarily processes. For PCX enrollment, it verifies the customer and attests the device’s public key; it also generates the token used to associate a participating card with the customer’s pseudonymous account. Acting as identity custodian does not give it routine access to the customer’s consolidated PCX line-item history or records from other merchants.
The PCX platform
The PCX Platform associates records with a pseudonymous account and does not routinely receive the custodian’s identity mapping. The customer’s canonical record is protected with a customer-controlled data-encryption key. Protected resolution and permitted analytical processing have defined access boundaries; pseudonymous linkage alone does not prevent inference from other information.
The customer
The customer controls access to their consolidated record through authorized devices. Each device’s access to the common data-encryption key is provisioned separately from its authentication credential. Services can receive bounded information derived from those records for permitted purposes while the customer’s canonical records remain protected.
The regulator
The regulator is not treated as another consumer of customer transaction records. PCX is designed to generate purpose-limited regulatory outputs from privacy-bounded analytical data rather than expose the underlying customer record store. Before information is made available for regulatory analysis, outputs can be aggregated, thresholded, or suppressed so that market conditions and economic patterns can be examined without exposing individual longitudinal transaction histories.
This allows regulators to evaluate issues such as market activity, concentration, spending patterns, or other policy-relevant indicators while preserving the separation between regulatory analysis and customer-level records. Routine regulatory reporting therefore operates on derived statistical outputs, not browsable customer histories. Any exceptional identity-linked access would remain a separate, narrowly governed lawful process rather than part of the normal analytical pathway.
Card transactions are associated with the customer’s pseudonymous PCX account through the registered PCX linkage token. Non-card transactions can instead use an account credential presented by the customer. In either case, the PCX Platform can associate the record with the correct account without receiving the customer’s identity.
Within the designed accountability pathway, reconnecting a transaction to a named person requires controlled access to both sides of the separation — the PCX transaction record and the identity information held outside PCX — under the applicable legal or regulatory process. This does not eliminate the need to assess re-identification risks involving outside information.
Beyond capture — contextual reviews, scoped rewards and analytics
The granted foundation covers token-based record capture and pseudonymous linkage. A related U.S. continuation applies the PoS-linked transaction-record workflow to contextual review forms. Separate applications filed in 2026 address purpose-specific record separation and privacy-bounded analytics, including the proposed architecture for cross-merchant rewards.
Granted
Foundation
Capture pipeline
US 12,125,054 B2 covers the capture of a qualified customer transaction record and its linkage, through a protected token, to a persistent pseudonymous account. The issuer retains the card-to-token mapping and its direct identity relationship with the customer; PCX does not require the customer’s name, email address, telephone number or primary account number (PAN) in the record-linkage layer.
The related U.S. continuation, US 12,749,086 B2, claims a PoS-linked workflow that uses transaction-record attributes to generate feedback forms relevant to the purchased product or service. Reviewer choices update the parameters used to generate future forms. The transaction record supplies evidence and product or service context; the protected token supplies account linkage. This separation lets feedback draw on a qualified transaction without using the customer’s name as the record key.
What it establishes: a token-linked path from qualified transaction capture to pseudonymous account linkage and contextual feedback forms based on transaction attributes.
New applications
Pending
Three-record architecture
Applications filed in the United States and Europe in 2026 extend the granted foundation. At ingestion, the proposed three-record architecture separates each verified, completed transaction into three representations: a Customer Canonical Transaction Record (CCTR), a Merchant Canonical Transaction Record (MCTR), and a Synthetic Analytical Transaction Record (SATR).
CCTR preserves authoritative customer-side evidence, MCTR supports merchant operations, and SATR carries only selected or derived attributes needed for permitted analysis. Customer identity and unnecessary merchant-sensitive information are withheld from SATR, while the canonical records remain separate from downstream analytical use. This “separate first, compute later” structure preserves the economic evidence needed by each participant without creating a single unrestricted transaction record.
What it establishes: structural separation of customer, merchant, and analytical records before permitted downstream computation.
New applications
Pending
Privacy-bounded analytics
The Synthetic Analytical Transaction Record provides a transaction-grounded substrate for permitted analysis across participating merchants. Instead of exposing the customer’s canonical history, the PCX analytical layer operates on selected or derived SATR attributes and returns only the result authorized for the requesting application. The analytical layer is therefore separated from the complete customer and merchant records.
Thresholds, suppression rules, purpose restrictions, access controls, auditability, and limits on repeated queries are intended to reduce disclosure, linkage, and reconstruction risk. These safeguards must be tested against the defined threat model and independently evaluated. The objective is to preserve useful cross-merchant signals without turning the analytical layer into another browsable longitudinal customer history.
What it establishes: privacy-bounded cross-merchant analysis without routine access to complete canonical transaction histories.
New applications
Pending
Cross-merchant rewards
In the proposed rewards model, a brand defines an eligibility policy that the PCX Platform applies across participating unaffiliated merchants. The sponsor receives only the result required to operate the policy — such as eligible or not eligible — rather than the customer’s identity, underlying transaction records, or complete purchase history. The customer’s broader activity therefore remains outside the sponsor’s routine view.
Each merchant continues to see transactions and program activity within its own permitted scope. The architecture is intended to support sponsor-blind cross-merchant rewards grounded in verified economic activity without creating a centralized, sponsor-controlled customer profile. Policy rules and permitted outputs are applied through constrained interfaces while the underlying canonical records remain outside the sponsor’s routine access.
What it establishes: cross-merchant reward eligibility without disclosing unrelated purchases or creating sponsor-controlled customer profiles.