Card Numbers

How did we get here?

It wasn't long ago that it was reasonable to identify your bank account at Point Of Sale (POS) using just your Primary Account Number or PAN. This PAN was encoded on a magnetic strip on a plastic card. This made it very easy to transfer a sizable (in those days) number into the POS system in a seamless fashion using inexpensive equipment. The equipment was inexpensive because it made use of existing and ubiquitous magnetic tape playback equipment which had been available in the recording industry for many years. With this number the merchant could arrange for the transfer of funds from your account to theirs.

From card to Till - Swipe.

You would hand your card to the cashier who would swipe the card in a Magnetic Swipe Reader (MSR) and hand it back. This would read the recorded data on the card, including your PAN, the start and expiry date of the card and often your name, and transfer it into the till.

From store to Acquirer - Authorisation.

Now the merchant must try to find out if you have enough funds to pay for this. This involves a call to their acquirer, via modem - how cute is that - who then either calls your bank or decides for itself. Whichever route it takes it responds with either a "Yes" or a "No". If "Yes", you were asked to sign your receipt and after a quick, inexpert comparison of your signature with the one on the back of your card you are allowed to walk away with the goods.

From store to Acquirer again - Settlement.

As each successful authorisation occurs the details of the card and amount are pushed up to head-office. At the end of the day these are gathered together and sent off to the acquirer in a single batch. This batch is then "settled" amongst the various banks in question resulting in an amount of money being added to the merchants bank account and an amount of money being removed from each customer's account.

The old way.
The mess it was in.

What was wrong?

  1. No checks (apart from an inexpert glance at their signature) were made to confirm whether the customer was paying with their own card or a stolen one.
  2. The card PAN was stored in clear text in almost every location possible from till to head-office.
  3. Anyone who could tap a 'phone line or install a key-logger (most MSRs emulate a keyboard) or sniff a network could pull thousands of credit card numbers out of the traffic.

What has changed?

  1. We replaced the MSR with a Pin Entry Device (PED). We can now kind of check that you are who you say you are.
  2. We encrypt all storage of card data. We are not so free with your personal data.
  3. We moved from modems to ISDN T/As to secure leased lines. Quicker and a little more secure.

We've patched up the glaring holes but is this enough?

Nowadays - not so different

We are now seeing more and more methods becoming available for confirming the customer's identity but we cannot use them because we are locked in to pins and we all know what the problems are with pins.
The move to EMV Chip and Pin has merely made the fraudsters work more difficult, not impossible. Pins can be obtained by force, PANs can be use online or overseas and even leased lines can be hacked. Encryption merely delays the inevitable.

The obvious answer!

It's simple really - first stop using PANs!

We need to go to a proper transactional system using a unique ID for each transaction. We can then store the customer's identity against the ID at the acquirer where it is needed and nowhere else. The only way someone could obtain PANs would then be to break into the acquirers network. Just one place instead of any PED or any till or any store server or the head office system or any of the communications lines between any of those. It just makes sense.

Here's what it should look like:

New form.
The way it should be.

Here the customer initiates a transaction with their bank by identifying themselves to their bank - not to the till. I imagine a simple phone app could perform a call-out to the customer's bank using one of many methods of identification. The request could (but need not) include the amount they intend to pay or some upper limit. It could also include some form of merchant or acquirer identifier gleaned from location data or a wireless transfer from in-store.
In return, the customer receives a unique ID for the transaction. This ID is registered by the issuer with the acquirer (if supplied) or a central repository. This ID is only valid during it's lifetime and will never be reused - ever.

Who holds what data?

  1. Your bank connects your transaction with its version of you. No other player in the game ever has any way of connecting this transaction with you without your express permission.
    Currently some stores will identify you by your card number and derive much meta-data about you from that detail.
  2. The acquirer holds a connection between the ID and your issuer so it knows who to forward the settlement records to at settlement time. After authorisation the acquirer will hold the exact transaction amount and the merchant identifier.
  3. The merchant knows how much the ID is worth but no more.

As a result, once the transaction has been authorised by the acquirer it cannot be used for anything other than transferring a specific amount of money from your account to the merchants account. No other accounts could be used and the value cannot be adjusted. Complete safety for all parties with no encryption.
Unlike with Chip and Pin transactions this scenario actually gets easier when you move it online. You visit your PayPal account and request a voucher worth a specific amount of money to a specific merchant. If you go ahead and buy the goods the merchant presents the voucher code to PayPal for payment.

Why it is not already happening?

The one-word answer to this question is "Collusion". The problem is that this system would require banks and acquirers to work together to get the mechanisms in place and there are rules that discourage this sort of practice. The rules make sense too - after all, if the banks colluded they would be accused of price fixing or some such crime.

There are standards bodies who are capable of driving this process but sadly they are not motivated to improve the security of your card purchases = they are motivated to continue to exist.

What am I doing to fix it?

I am offering to provide a sequence of unique-forever numbers. I can split this sequence into salable parts so anyone anywhere can hold their own unique sequence for a trivial amount of money. If one of my generators was used to generate one number per millisecond it would last over 60 years. Each generator will produce its own sequence of numbers and no two generators will ever produce the same number.
The numbers are 95 bits wide. This allows you to encode them in a standard base-32 format in just 19 characters. This width was chosen deliberately because the current standards can handle up to 19 digits. A simple adjustment to the standard to allow 19 characters is all that would be required.

To make the sequence difficult to crack I recommend using the generators in clusters of between 10 and 100.

This is just a start. It will take a major player to support this before it really takes off. I hope some of the online payments people such as PayPal will be interested. I understand many of the mobile phone operators are trying to get into the payments market - perhaps this is the way to go.

Powered by Google App Engine