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.
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
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.
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 mess it was in.
We've patched up the glaring holes but is this enough?
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
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.
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:
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.
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.
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.
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.