What your card number is for, and what it does

There is a card in your wallet, and on the front of it is a number.

The merchant you paid yesterday has it. So does the merchant you paid two years ago. Their payment processors have it. The companies those processors work with have records tied to it. In the ordinary course of business, brokers downstream hold files derived from it. None of this required a breach.

What a card number is

The card number has a name in the standards that govern it. It is the primary account number, the PAN, and its structure is set out in ISO/IEC 7812, the international standard for identification cards. The standard was first published in 1989, with substantive revisions in 2017 and 2022.

A PAN has three parts. The first six digits are the issuer identification number, or IIN, which names the network and the issuing institution. Sixteen digits is the dominant UK length, on Visa and Mastercard cards; American Express uses fifteen. The 2017 revision provides for eight-digit IINs, and the conversion is gradually rolling out across the schemes; the six-digit form remains common in cards already in circulation. The middle portion is the individual account identifier, assigned by the issuer to a specific account. The last digit is a check digit, calculated from all the preceding digits using the Luhn algorithm, a checksum patented by IBM's Hans Peter Luhn in 1954 and now mandated by Annex B of the ISO standard.

The check digit's purpose is error detection during data entry. When you mistype a digit when paying online, the form rejects the number before it leaves your browser, because the Luhn check fails. The IIN's purpose is routing. When a payment terminal or a checkout form sees a number beginning with 4, it knows to send the authorisation request to the Visa network, because that is what the leading digit in that position means. When the network receives the message, it reads the rest of the IIN to identify the issuing bank, and forwards the request there. The bank uses the individual account identifier to find the cardholder's account, decides whether to approve the transaction, and sends the answer back along the same path.

That is what the standard is for. A name for a card account, structured so that any system in the world can route a request to the right place and verify that the digits arrived intact. There is nothing in ISO 7812 about how the number ought to behave once it has reached the merchant, nor any requirement on the merchant about how long it should be retained, nor any statement about whether the same number should be used for the next purchase or a different one. Those are properties of how the system has been built around the standard, not of the standard itself.

Where the number goes after you pay

The first stop after the merchant is the merchant's payment processor. The processor is the company the merchant has contracted to handle card transactions on their behalf: Stripe, Adyen, Worldpay, Checkout.com, and several dozen others operating in the UK and EU. The processor receives the PAN in the authorisation request, forwards it through the card network to the issuing bank, and returns the bank's answer to the merchant. The PAN is in the message at every hop. After the transaction completes, the processor retains a record of it, partly to enable refunds and chargebacks, partly because card scheme rules and PCI-DSS impose minimum logging requirements.

The merchant retains a record too. In some cases, the merchant stores the PAN in tokenised or hashed form for future use. Subscription merchants need it to charge the card again next month. Marketplaces store it to enable repeat purchases without re-entering details. Even merchants who do not store the PAN typically store a token issued by their processor that resolves to the PAN when needed. The token is not the PAN, but it is a stable identifier of the same account at the same merchant, and it stays in place as long as you keep paying that merchant.

A separate piece on this site walks through what a merchant actually sees when you pay by card online, at the level of the individual transaction.

Beyond the processor and the merchant, the picture becomes harder to draw with precision. Card data flows through gateway providers, fraud-scoring services, analytics services, and (in some commercial arrangements) third-party customer data platforms. Each of these holds records derived from the PAN: hashes, tokens, identifiers built up from the same payment events. The exact downstream geography varies by merchant and by jurisdiction. The PAN is the original key from which the downstream identifiers are derived.

The PAN itself stays the same for the life of the card, which in the UK is typically three to four years between issue and expiry. During that time it is your stable identifier across every merchant you pay. When the card is replaced, the new card has a different PAN, but your identity at the issuing bank does not change; the bank can connect the old PAN's transaction history to the new card if it chooses, because both sit under the same account.

This stability has legitimate uses. Refunds need it: a refund to a card that no longer exists fails, and the merchant needs a way to reach the original payment account. Chargeback procedures need it: disputes can be raised months after a transaction, and the network's ability to credit you depends on the PAN still routing to the right place. Subscription billing needs it: charging a card every month requires a number that does not change between charges. The system as a whole would not work without it.

What aggregated payment data becomes

The Tesco shop on Tuesday is not a privacy crisis. Neither is the Spotify subscription on the third of every month, nor the Boots receipt from 2022 still sitting in a database somewhere. None of these records is troubling in isolation. The trouble is the pattern they form when they can be joined together.

This is the aggregation problem. Bruce Schneier names it as the core mechanism of modern surveillance: individual data points are not the harm, the combination is. Knowing what someone bought at one shop reveals little. Knowing every purchase at every shop, over years, indexed against time of day and location and amount and merchant category, reveals more than you know about yourself. The shape of a life is in the pattern, not in any single line of it.

The PAN is what allows the joining to happen. It is the same number at every merchant you pay. Without a stable identifier shared between merchants and the parties downstream of merchants, the records would sit in unconnected silos: Tesco knows what you bought at Tesco, Spotify knows what you subscribed to, Boots knows what you bought at Boots, and the records do not speak to each other. With a stable identifier, they do speak. Or more precisely, they speak through intermediaries that hold identifiers derived from the PAN and broker the connections: data brokers, credit reference agencies, fraud-scoring services, advertising networks, marketing platforms. The PAN is not always the literal join key in the broker's system. But the chain of derived identifiers begins with it.

How easily can records of this kind be re-attached to a specific person? More easily than most people assume. In 2015, Yves-Alexandre de Montjoye and colleagues published a study in Science using three months of credit-card metadata for 1.1 million people. They found that four spatiotemporal points, the date and shop of four purchases, were enough to uniquely identify ninety per cent of individuals in the dataset. Adding price information raised the figure further. A subsequent comment in the same journal pushed back on the methodology, arguing that the headline figure was likely overestimated under different assumptions about the population the dataset was drawn from. The qualitative finding has held: anonymity in card metadata is not a property data has by default. It is much harder to maintain than commonly assumed.

You can hold all this and still not feel the argument applies to you. The objection is honest, and it runs something like: "Even if my purchases are aggregated, my pattern is boring. Nobody is interested in the shape of a forty-year-old's monthly spending in the south of England."

The de Montjoye study did not find that famous people were uniquely identifiable. It found that ninety per cent of ordinary people in the dataset were uniquely identifiable from four purchases. Boring patterns are the ones the finding describes. The word "boring" maps closely to "typical," and typical is what the reidentification mechanism exploits, because typical patterns are still individually unique at sufficient resolution. Four purchases is sufficient resolution.

The pattern is also not valuable because you are interesting. It is valuable because it is the input to a system that prices you, sorts you, decides what you are shown, and decides what you are charged. Schneier calls this weblining: commercial discrimination based on data profiles. Insurance premiums, credit terms, employment screening, advertising prices, all are decisions made using inputs that include purchase history. You do not need to be interesting for the system to act on you. It acts on everyone the same way: by reading the pattern, comparing it to other patterns, and applying a rule. A boring pattern produces a boring decision. The decision is still made, and it still affects you.

There is also a collective dimension to the argument, which Carissa Véliz develops in Privacy is Power. Privacy is similar to environmental conditions in this respect: an individual's data is rarely valuable on its own, and the system that values it depends on millions of patterns, including the boring ones. Your ordinary pattern is an input the system relies on to function. Opting out of caring about your own pattern is a position available to anyone. It does not remove the pattern from the system; it leaves the pattern in place, contributing to the infrastructure that operates on everyone, including the people for whom the consequences are not boring at all.

Aggregation, then, is what an identifier shared widely becomes. The PAN makes aggregation possible at the payment layer, because the same number stays attached to every transaction across years of use. The two together produce a profile that does not need anyone to be interesting in order to be commercially valuable.

What the standard does and does not specify

ISO/IEC 7812 specifies the format of card numbers and not much else. There is nothing in it about how the number ought to behave once it has reached the merchant. There is no requirement on the merchant about how long the number should be retained. There is no statement about whether the same number should be used for the next purchase or a different one. There is no provision for you to share a different number with each merchant you pay.

The standard does what its drafters intended it to do. It allows any payment terminal in the world to read a card number, identify the issuer, route the authorisation request, and verify that the digits arrived intact. The aggregation property described above is not in the standard, because aggregation is not what the standard is for. It is a property of the system that has been built around the standard: a system in which the same number is shared with every merchant you pay, and in which the parties downstream of merchants have built business models that depend on records derived from that sharing.

This distinction matters because it tells you where the change has to happen. If the cross-merchant property of the PAN were a feature of the standard itself, changing it would mean revising an international standard adopted by every card scheme on earth. That is a generational project. It is not a property of the standard but of how cards are used. Properties of use can change. They change when issuers offer you the ability to generate a different number for each merchant, when those numbers can be revoked or constrained without affecting the underlying account, when the technology that makes the original PAN convenient is also the technology that makes alternatives possible. The infrastructure for this exists. It is the same card networks, the same authorisation flow, the same standards. What is different is what you are allowed to do at the level of the number.

What this changes

The card number is doing more than the standard intends. It is the join key for records held by every party that has ever received it. The privacy problem is not that someone steals the number; it is that the number works as designed and is shared with thousands of parties over years, and the resulting records are joined back together by people you never agreed to share anything with. None of this is the standard's fault. None of it is the merchant's fault either, in any individual sense. It is what happens when an identifier designed to route an authorisation message becomes, by accumulation, the spine of a profile.

Once you see the card this way, the conventional advice about card security does not become wrong. Keep the number off public surfaces. Watch for suspicious transactions. Replace the card if it has been compromised. All of that is still good practice. It is just that it stops being the whole story. The whole story includes what the number is doing between the moments of purchase, in the records of every party that has ever held it, and in the patterns those records collectively describe.

What you can do with that knowledge is a separate question, with several legitimate answers. Some come from the law: UK GDPR gives you rights to ask merchants what they hold and to ask them to delete it. Some come from how you choose to pay: cash where it is practical, mobile wallets where the merchant receives a token rather than your real number, fewer cards in fewer places. Some come from architectural responses being built where the law and the consumer options do not reach. There is more than one mechanism, and they work in combination. Whatever you do with this knowledge is a choice you make. The choice is more honest if it is made with the right picture of what is going on.