The new wallet uses Virtual Card Numbers (VCNs) vs. storing REAL card credentials on the phone. The actual card credentials are now stored securely in the cloud. Using VCNs, rather than storing REAL card credentials on the secure element or SIM card of the phone, is a big step in the right direction. If one loses their phone users may login online and turn off or disable their app, making the phone and apparently, the Virtual Card Number on the phone, useless to cyber thieves.
A question that comes to mind is, with this new method, willl Google Wallet transactions be treated as a card-present transaction? I could find no answer online to this question. My opinion is that the new Google Wallet transactions should be processed as card-present. The higher processing fees for card-not-present transactions are charged for the increased risk of fraud. Since the chance of fraud is seemingly reduced the way Google Wallet now processes transactions, they should be card-present transactions.
This past week I attended RetailNOW 2012. Tony Abruzzio, an executive with ISIS, explained how the ISIS mobile wallet uses Dynamic CVVs to secure data stored in 'Secure Element. on the phone.
For those unfamiliar with CVVs, CVV stands for Card Verification Value. The first type of CVV code, CVV1, is encoded onto the magnetic stripe of a credit or debit card, along with your card number, expiration date, bank routing info and data that identifies the transaction as a "Card-Present" transaction. The information encoded onto this card is "static," but may be "skimmed" by thieves to make a copy and used just as original card. The second type, CVV2, is the 3-digit value on the back of your Mastercard, Visa or Discover card or 4-digit number on the front an Amex card. CVV2, is of course used for phone or e-commerce transactions and is also a static number.
ISIS uses, a Dynamic CVV. This is a one-time use, random CVV code. Use of Dynamic CVV2s is a relatively new practice with card not present (e-commerce and phone) transactions.
Without using Dynamic CVVs, if a phone was compromised by a thief, they would have the same data as would one when they skim it from your mag-striped debit or credit card. With ISIS it appears to be the case that REAL card data is still stored on the phone. Tony Abruzzio shared "This is not a viable enterprise for data thieves." It could also be the case the CVV has an expiration date?
Like Google Wallet, The ISIS wallet can also be locked remotely. My question is will ISIS switch to adopt Google's Virtual Card Numbers to further reduce the risk of fraud and increase speed to market? Tony Abruzzio stated "The bottleneck we are having is due to limited TSMs (Trusted Service Managers)." Google Wallet still uses NFC, to complete the transaction, but with only virtual card numbers being passed along to complete a transaction, it seems to make it even more secure. Does Google also pair Dynamic CVVs along with their VCNs as well?
Dynamic CVVs Go Mainstream
A company named M2 Systems has patented technology it is licensing to banks to provide Dynamic CVVs to consumers for use to secure their card credentials when conducting card-not-present transactions. M2 announced their technology and how it works just six weeks ago. According to the release, M2 Systems offers their "SAFE Technology" to consumers through use of their "SAFE App."
M2 Systems tells us how it works: "Cardholders request a unique Dynamic CVV code via the SAFE app for iPhone and Android devices, or via text messaging request. The one-time use CVV code is issued and available for a single transaction, allowing the authorized transaction to occur, and then immediately becoming invalid."
Alternative Methods to Conduct Secure Retail Mobile Transactions at POS
While the cutting edge security spoke of using Dynamic CVCs and VCNs shows much promise, there are several other methods to securely conduct transactions. It is possible to complete a mobile transaction at retail Point of Sale (POS) without ever sharing real or virtual card data at POS to complete a transaction.
If the card data is never shared with merchant, the merchant should be relieved of the burden of PCI compliance. I see this as a huge trend in retail payments. Merchants already are overwhelmed with just retailing, a down economy and the transition to mobile, social and local. I say let the nuclear plant (PCI-Compliant Service Providers) handle the radioactive material and the customers (retailers) benefit from the electricity they need to run their stores. The question that needs answering with this model is 'Why should this not be the future of data security?" The merchant has no need or desire to know the card data, they just need an integrated solution that also serves real-time payment confirmation. So long as the merchant can apply a tag to track the customer for marketing and data analytics purposes, they would rather not be responsible for managing the card credentials.
Starbucks Card Mobile paved the way in 2011 by generating 2D barcodes, that when scanned, work like a plastic gift card. The beauty here is that the bar code does not contain credit card credentials. The adoption and usage rates have been through the roof. Starbucks enhanced loyalty, convenience, profits & security. Starbucks, I love the innovation. Thanks for delivering the 'Venti Mocha Mobile Simple Secure.' LevelUp seems to have taken the ball and run with Starbucks-like technology. It works like Starbucks Card Mobile, but it is enabled to work with multiple retailers. The app stores tokenized card numbers on the phone. One never has to hand their phone over to process a payment, as the 2D barcode generated on the phone is scanned at POS or table side by a mobile device with a scanner. Paydiant has a built in 2D bar code scanner in the app. It is used to scan barcodes generated by the Paydiant software stored on the POS and to complete the transaction. With Paydiant the card credentials are never shared with the merchant. They are stored "remotely in PCI level 1-compliant, SAS70 secure data center." This is a big win for security. The only downside I can see is the burden of the consumer scanning the barcode to complete the transaction. Some people will perform it as fast as swipe or tap, while others could "Scan like a snail at Point of Sale!" Digimo also has a 2D scanner built-into their phone app. It too is used to complete transactions. In the Digimo video, the Digimo app is used to scan a printed 2D barcode. The barcode is obviously assigned to the POS register or even an advertisement for a product. The solution claims to require no integration to POS and does not appear to ever share card data with the POS. It is not clear if they store card data on the phone or remotely in a secure server. It is a unique, creative and a broad-based solution. As I mentioned last week in my prior article, I quoted Jay Donovon, author a TechCrunch article about Digimo, "The first thing I thought was wow, why didn't somebody think of this before. Its a pretty good idea and solves many of the problems that plague mobile, face-to-face payments."
PayPal has not shown it's method of connecting to POS for mobile payments yet, nor has Apple, though Passbook sure looks like a mobile wallet with training wheels.
With Mobile POS An Even Greater Need for a Secure Network/WIFI
Apple led the way and now retailers like JCPenny and Nordstrums are going ALL IN on mobile POS, ASAP. EVP and president of stores Erik Nordstrom during a recent conference call discussing Q1 financial results stated "We're at about 75% of the functionality of a register on our mobile devices right now. By the end of the year, we will be at 100% . . . And next year, we'll actually have additional functionality that we don't even have on the registers."
This trend to mobile started in the 90's, but is finally taking hold this year. It is the iphone and ipad that brought us to this tipping point of mass adoption. These devices now extend and expand the POS to do nearly anything one can imagine or can afford to develop. Of course to be grounded, this is new technology and it's implementation requires an improvement on logistics and the bottom line, without compromising security or speed. Rushing to adopt mobile without planning, researching and paying attention to what has worked, or what can work, must be the foundation of adopting Mobile POS.
Square is a small cube with a built in mag-stripe reader. It is plugged into the audio port of a smartphone to accept credit cards. This product helped spark a huge trend to enable credit card payments by only using a iphone or ipad. In 2010 when it bolted onto the scene, it's volume has grown rapidly, but their initial readers did not encrypt card data. This problem has been resolved in it's current dongles, but it should serve as a warning sign to other forms of incorporating mobile POS in retail stores.
We are sure to see some funny videos posted this December when the first "Mobile Christmas" has it's grand debut in retailers across the nation. Will it look like a 'Conga Line at a Wedding' or will it be one of mass efficiency, order and speed? We are also sure to find out about nightmare breaches that occur due to skipping steps to having a secure retail WIFI and proprietary network.
While at RetailNOW I spoke with Brad Cyprus, the Chief of Security and Compliance with VendorSafe Technologies, a 23-year old company that sets up and manages secure networks for retailers. Brad made it clear in stating "If you are going mobile, just assume you are going WIFI too . . . blindly moving forward with mobile will result in breach." The point here is that beyond secure mobile payment transactions, if there is secure data to be stored or passed along, especially card credentials, that without technical experts, well versed in PCI compliance, you will have your system breached in due time.
What if Every Transaction Required Consumer Authorization?
Another solution, I personally invented and blueprinted, is written about here on Mobile Wallet Media: Secure Our Future Transactions or SOFT. This method would enable ALL card transactions to require consumer authorization prior to a confirmation being sent to the merchant. This is an alternative method to Dynamic CVVs, and works to make card, bank account and social security numbers useless in the hands of thieves. This technology could be incorporated seamlessly into any mobile wallet and work to secure all cash and credit accounts, not just retail transactions. Also, without requiring overhaul of legacy systems, there are ways to seamlessly route the transaction to receive the purchaser's authorization.
With this model the user signs up through their financial institution. The user can use mobile GPS to automatically turn ON all cards or just one card for use in the local area or they may manually set parameters by zip or area code or country. The user may require, they themselves, pre-approve every transaction by logging into the SOFT mobile app/site and enabling a single transaction for a specific merchant or area code. With this method, if their wallet or payment account was not turned ON for use, and a transaction was run, both the end-user and the merchant would recieve a decline code telling them the card was denied because it was turned OFF for use.
Users may set parameters to have all cards and accounts turned OFF for ALL card-not-present transactions, and require pre-authorization for a transaction to be approved.
This method if implemented by all banks could end most card fraud and eliminate the need for PCI by making card credentials useless without mobile authorization by from the cardholder. To clarify, regarding PCI, what I mean is that it would alter PCI's scope and purpose. SOFT teamed with tokenized, dynamic CVVs, could make for an all-star security team to secure all future transactions.
This week 2 in a 7-week series: "The 7 S's Required for Success in Mobile Payments."
Join the conversation! Get first notice of new articles, posts and latest industry news!