Replacing customer identity with a pseudonym on every transaction record
The PCX pipeline
PCX links each transaction record to a pseudonym rather than to the person behind it, at the moment the record is created. The pipeline behind this transformation is the chain that carries each record from the point of sale into a customer-controlled account on the PCX Platform, without exposing the customer’s identity along the way. A single purchase travels the chain twice. The request runs down the chain: Merchant → Acquiring Bank → Payment Network → Card Issuer to authorize the payment and retrieve the token linked to the card. The response runs back up, and one step further: Card Issuer → Payment Network → Acquiring Bank → Merchant → PCX Platform carrying the authorization and the encrypted token so the platform can record the transaction against the customer’s account.
Every capability named in the Concept page (loyalty, analytics, and search) runs on the records this pipeline produces. Tokenization, described next, is one component of it: the key that lets a record travel the chain and land in the right account while the customer’s identity stays decoupled from it. In the diagrams below, “PCX Platform” refers to the server-side infrastructure implementing the PCX protocol.
How tokenization works in PCX
Tokenization is the process of converting meaningful data, such as the payment card number, into a random string of characters called a token that has no value if breached. Tokens reference the original data, but cannot be used to extract the information behind the token. They are widely used in the payment card industry to protect the primary account number (PAN) of cardholders from hacking or unauthorized use. Both Apple Pay and Google Pay use tokens to facilitate contactless (NFC) payment via mobile devices.
PCX repurposes this established mechanism for a different end. The token linked with a transaction tells the PCX Platform where the transaction record belongs. The PCX Platform resolves the token to the customer’s pseudonymous account and delivers the record to that destination, without knowing who the customer is. The customer’s identity remains with the card issuer.
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 payment card is tokenized by its issuer and registered to that account. Third, whenever a registered card is used, the token accompanying the transaction allows PCX to identify the correct pseudonymous account and record the transaction automatically. Account creation happens once, card registration happens once per card, and transaction recording thereafter requires no action from the customer.
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. 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 attested key 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 and proves possession of the matching private key. No email address, phone number, or payment card detail reaches the platform at this step.
The PCX Platform creates the pseudonymous customer account and confirms that payment cards can now be registered into it. From this point onward, the customer accesses the account using the private key held on their device.
Account creation happens once. The card-registration steps that follow assume an account and pseudonymous identifier already exist.
Registering tokenized cards on the PCX Platform
The customer asks each of their card issuers to tokenize the card. Nothing reaches the platform yet.
The issuer generates a token for the card and encrypts it with the platform’s public key. The token is stored in the issuer’s database as a key–value pair against the matching card number, so the card-to-token mapping stays with the issuer.
The issuer sends the encrypted token to the PCX Platform. It can be decrypted only with the matching private key held at the platform, so no party in transit can read it.
The platform decrypts the token and places it in a queue. It then sends a notification of this to the issuer, which notifies the customer that the token is available for registration.
The customer registers the token into the account they control on the platform. From this point, transactions on that card can be linked to that account by token alone.
Registration happens once per card. The card number never leaves the issuer; only an encrypted token reaches the platform.
Recording tokenized card transactions on the PCX Platform
The customer pays with a tokenized card the way they always would: tapped, swiped, or inserted at a payment cube, or used at an online store. That purchase is what gets captured into their account.
The merchant asks its acquiring bank to authorize the transaction and return the token linked to the card. The acquiring bank forwards the request to the payment network, which passes it to the card issuer.
The issuer checks the account balance, authorizes the transaction, and returns the authorization together with the linked token (encrypted with the platform’s public key) back through the payment network to the acquiring bank.
The merchant receives the authorization and the encrypted token from the acquiring bank, links the transaction record to the token via an API call, and transmits it to the PCX Platform.
The platform decrypts the token and looks up the account that holds it. Once resolved, the transaction record is written into the platform database against that customer account. (If the token exists but the customer hasn’t yet registered it into their account, the platform can’t resolve it and returns an “Unknown Card” message to the PoS; the customer then adds the token to their account, after which the token resolves and the record is appended.)
A transaction record can reach the platform in two ways — via a tokenized card, or sans any card. Both converge on the same step: the platform resolves the customer account and appends the record to it.
Recording non-card transactions
Not every transaction runs through a payment card reader. A customer’s app can present its platform account identifier directly (as a QR code, barcode, or NFC credential) which the PoS reads; or the PoS can print the transaction record as a QR code that the customer scans with the app. Either way, the platform receives the account identifier and the record, and appends the record to the same account. The underlying payment can be settled by cash, check, or e-transfer. The payment rail is independent of the capture. What links the record to the account is the account identifier the customer presents, exactly as the token does on the card path.
This second path is a deliberately claimed capability, not a side effect: it lets a customer build a complete, cross-merchant purchase history regardless of how they pay, and join a merchant’s loyalty program without surrendering identifying information.
What each party can see
In the capture pipeline as granted, every party in the system sees only what it holds by design, and no party but the customer holds enough to reconstruct the whole.
The merchant
The merchant sees the customer’s transactions within its own store and partner network, and uses them to compute loyalty credits. Anything beyond that (what the customer buys elsewhere) requires the customer’s consent.
The bank or issuer
The bank or issuer knows that the customer spent, across market segments, but not what was bought: the transaction records are never shared with the bank.
The PCX platform
The PCX Platform holds transaction records against a pseudonymous customer account rather than against the customer’s identity. It can associate transactions with the correct account, but it does not know who the customer is.
The customer
The customer is the only party with the full picture and the only one who can connect their records to their own identity. They can share bounded information derived from those records for specific purposes, while PCX keeps the underlying canonical records protected and does not disclose them.
Card transactions are associated with the customer’s pseudonymous PCX account through the registered payment 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.
Reconnecting a transaction to a named person therefore 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.
Beyond capture — rewards without exposure
Granted
Foundation
Capture pipeline
The capture pipeline described above is the granted foundation. New patent applications filed in the US and Europe in 2026 describe an architecture that goes further. Each record exists in three variants. The merchant holds a copy that contains the transaction details without any customer information. The customer holds a copy, encrypted with the customer’s public key. The platform holds a synthetic copy that is useful for analysis but cannot be traced back to the original transaction. Only the customer copy is complete and attributable.
New applications
Pending
Cross-merchant rewards
Conventional rewards programs require a merchant or partner network to have access to a customer’s transactions to determine eligibility. The synthetic copy creates a different model: a brand can define a rewards policy that the platform applies across unaffiliated stores, while receiving only scoped eligibility indicators — never the underlying records or the person behind them. The patent applications covering this architecture are pending; the mechanism is set out in the filings and is not detailed here.