Securing Mobile Payments – It’s Still Early
Written by David TaylorGuestView Columnist David Taylor is the Founder of the PCI Knowledge Base and former E-Commerce and Security analyst with Gartner.
Mobile payments are exciting, no question about it. The very idea of allowing consumers to buy stuff anywhere, at any time, with the touch of a button, gets retail, banking and communications executives to the point where you almost have to hose them down. So, what better way to ruin the party than to bring up security and compliance issues?
Actually, the need for this emerging payment “channel” and the specific payment platforms, software and services to be PCI compliant should be obvious. After all, the PCI standards have been around for about 5 years, so one would assume that PCI compliance would be “built in” to mobile payment products and services.
However, if you assumed that, you’d be wrong. We’re still far more focused on selling mobile payment to merchants, and much less focused on securing mobile payment and ensuring that the approaches are PCI compliant.
Mobile payment is all about pilots. There are currently hundreds, perhaps thousands of them. It makes sense. Between technical viability, transaction management and consumer usability there are a ton of issues that have to be resolved. There are also myriad ways to do mobile payment: contactless smart cards, RFID stickers on mobile phones, payment-capable chips for phones and next generation PDAs. It’s difficult for a retailer to decide which of the dozen possible mobile payment pilots are worth pursuing.
It’s not my place to help select one platform over another. However, I believe it is very reasonable for merchants to add PCI compliance to the requirements for mobile payment pilots. While that may seem obvious to some, it isn’t.
We started work on mobile payment security for a restaurant industry project and we were surprised that two recent, and otherwise comprehensive, reports on mobile payments and security either didn’t mention PCI compliance at all, or mentioned it only in passing.
In April 2009, Global Platform (“the standard for the smart card infrastructure”) wrote a 35-page report on Near Field Communication (NFC) Mobile Payment and Secure Element Management that doesn’t mention PCI compliance whatsoever. A May 2009 paper from the Smartcard Alliance on the Security of Proximity Mobile Payments says only that NFC payment platforms should be designed to address “industry best practices, such as PCI DSS, dynamic cryptograms and multi-factor authentication.”
-Marc
August 3rd, 2009 at 6:00 am
Just one point. The TSM provides end-to-end security ‘ISSUANCE’ not end-to-end ‘Payment Security’. In short, the TSM is responsible for the personalization of data to the Secure Element in the mobile device. The TSM is not responsible for the payment transaction between the Secure Element in the device and the conventional payment terminals.
August 3rd, 2009 at 9:08 am
TY, you’re right. I am hopeful that the model will evolve and the role of the TSM will expand to include end-to-end payment security. I think it’s a matter of the market demand not existing today. As more merchants insist on end-to-end payment security (e.g., encryption, tokenization) managed by a third party, the TSM (as managed by a bank, telco, network provider, or a combination) will become the provider of this service. There is a real issue as to HOW the market evolves to this, and how long it will take, but that is my expectation, based on things I’ve heard from several of the players in the space and our interviews with leading retailers and restaurants.
Thanks for the comment. Dave T.