Technorati Tags: payments
I love the programme Mythbusters on the Discovery channel and watch it with my boys. I admire the way that they conduct experiments themselves, building from scratch and not relying on other people’s opinions. Hence, when my new Barclays chip & PIN card arrived a couple of days before the old one expired, I decided to do my own chip & PIN experiment to see if this story is true. I took the chip out of my card and went off to try it out stripe-wise. I put it in a Nationwide ATM: transaction not authorised after PIN entry. I put it in an in-store ATM: transaction not authorised after PIN entry. I tried to pay with it in a supermarket and the card was rejected even before PIN entry. Well done to Barclays, who were clearly rejecting cards with a chip service code but stripe read. So clearly, the fraud here is not as simple as making magnetic stripe counterfeits and then using them in U.K. ATMs.
In fact, the main problem is that U.K. magnetic stripe counterfeits are being used in foreign ATMs.
So there is a genuine issue. , there’s an issue and we ought to consider what is to be done? There are few people around who know more about the issue than the head our banking practice Richard Allen and senior consultant Tony Pickup so I was discussing it with them earlier. The discussion was rather interesting, so I thought it might be a further experiment in corporate social networking to open up part of the discussion (with all client information and some other details removed) for blog readers…[Anthony Pickup] The issue relates to the card scheme-agreed process which means that in the ATM environment, online PIN checking is performed for all transactions. For a number of reasons the PIN is not validated by the card — even for chip and PIn cards — but is sent to the card issuer for authentication. There is some techie stuff over the PINs being encrypted by the PIN entry device also at ATMs (my pet subject). Therefore to resolve the issue of magnetic stripe data cloned onto cards being used with a PIN values captured from a transaction either physically (shouldering) or electronically (compromised terminal), there are decisions to be made by the card issuer or ATM operator.
The decision that can be made by the issuer is to reject transactions. In short, they simply turn off “fall back to magnetic stripe at ATMs”. The issue here is that ATM chip card readers can fail but remain operating with the magnetic stripe reader working. An issuer can pick this condition up if the data elements from the device are trusted. Another, perhaps better, solution would be for the ATM owner to reject the transaction if the service code on the magnetic stripe indicates a chip on the card and the ATM chip card reader fails to read the chip data due to either a card or a device failure. This would need to be mandated by the card schemes but would address the issue for their card issuers and ATM service providers, although it may mean the ATM owners losing a small number of legitimate transaction. This I believe would resolve the majority of the issue of fraudulent transactions, rejecting valid customer transactions and ensuring maximum ATM availability.[Richard Allen] I’m not so sure. It is not up to the accepting party (either the retailer or the ATM owner) to make this decision — it has to be the card issuer. The information necessary to make the “risk” decision is with the issuer, not the ATM owner. If the card issuer is willing to accept the risk, then why not allow fallback (and accept any consequent loss)? For example, I’ve already reported to my bank that my chip doesn’t work, for some reason. They’ll take two weeks to get a new card out to me, but will happily allow fallback in the meantime. On the other hand, someone else (let’s say a long-standing customer working at CHYP) wants to take out £250 cash at 23:59 on a Friday night in London having only ever taken out less than £50 in a day prior to this. Clearly this fallback transaction is fraudulent (they may have visited a Shell garage two days previous). I think that only the issuer has all the information to make the right decision.
Also, who pays the loss? Clearly, if the issuer makes the risk decision, then they must accept the consequent loss — and that’s what happens now with the overseas ATM fraud Dave mentioned (which is, as an aside, the fastest rising card fraud in the UK). So, my issuer would only approve my ATM withdrawl in Buenos Aires if I called the bank to say I was going to a there (of course, in the future, when my card is in my phone, this will be a simply query to T-Mobile). If Tony goes to Thailand and doesn’t tell the bank, then his ATM withdrawl will be declined. Admittedly this is not a fallback issue, but it’s a magnetic stripe issue just the same and the same fraud risk I don’t think an issuer would want an ATM operator declining customers on their own. Maybe they’re not likely to — because they depend on the fees — but the point holds. Issuers do not want their legitimate customers being inconvenienced and they are prepared to accept a losses as a consequence. Declining everything lights up the call centre and the customers go elsewhere. Declining nothing means losses. But again, it’s the issuers problem to find their ideal decline ratio to balance loss and churn.[Anthony Pickup] Surely this is why we have schemes and rules, isn’t it? It’s to resolve issues like this. Personally, I think an obvious solution is to use chip cards in a more intelligent way. They are computers, not secure stripes. Since the card knows whether it’s in an ATM or not, why not get the cards to give different PANs at ATM and POS (and through the contactless interface). The PAN on the card (and in the stripe) should not be the same PAN as given up to EMV POS. That way, if fraudsters compromise the POS and capture card details and PINs, they can’t make cards for use in foreign magnetic stripe ATMs or U.K. ATMs where the ATM is doing as little processing as possible.
These opinions are my own (I think) and presented solely in my capacity as an interested member of the general public [posted with ecto]