Visa To Pull Back On Mobile/Online Verification For Low-Risk Transactions

With a goal of trying to get mobile transactions moving, Visa on Monday (Nov. 26) floated a way to let shoppers not be bothered by password or other authentication for transactions the brand considers low-risk. The approach, dubbed the Visa Consumer Authentication Service, is designed for traditional E-Commerce transactions but will also work for any in-store mobile transactions that use the Internet (meaning it won't work for direct mobile-to-POS transactions, such as those fueled by NFC).

One new element here is Visa's use of various phone and tablet attributes to try and authenticate the device being used. (Sign of the times: In Visa parlance, laptops are no longer considered mobile.) "There are more than 100 different fields that we can get back from a particular device," including frequency, operating system version, the existence of antivirus software and physical location, said Mark Nelsen, Visa's head of risk and authentication product development. To varying degrees, Visa uses all of those elements to make its determination.

Nelsen—for obvious reasons—wouldn’t specify how those elements are weighted by Visa in its authentication process, except to say that Visa has opted to not consider the phone's contacts list. At least one vendor has opted to include that list and to use the most frequently called friends names to verify that it is likely the same phone.

The idea is that this new approach would authenticate the shopper before any attempt is made to authorize the transaction. If the transaction is deemed low-risk ("the vast majority are low-risk," Nelsen said), the transaction will be processed without authentication. The shopper might be sent an E-mail with a dynamic one-time password, with the theory being that the shopper would need to enter an E-mail password.

There's little question that this is a good move by Visa, in the sense that anything that cuts back unnecessary security (anything that doesn't meaningfully make transactions more secure) is to be encouraged. Apple's iTunes recently stopped requiring a password for every update of every already installed application, for example, which makes sense because the fraud risk from updating an existing app seems all but nonexistent.

But by the same token (OK, play on word intended), it's hard to envision this delivering any meaningful boost for either E-Commerce or mobile transactions. That's because, although password entry is annoying for consumers, it's not causing a lot of abandoned transactions.

For the mature E-Commerce space, by the time shoppers get to the payment area, they're committed to the purchase. A larger than expected delivery charge—or a significantly slower than expected shipment date—could cause E-Commerce transactions to be abandoned, but the typing in of a memorized password is unlikely to change anything. Customers would rather not do it, but they're unlikely to surrender their purchases if they're asked to give that password.

Embryonic mobile transactions get to the same place, but for a very different reason than their older E-Commerce counterparts. Shoppers are less committed to mobile purchases: just a little bit of static is often enough to push them to change their mind, given that a mobile purchase already represents a steep behavioral change.

What that means, though, is that mobile purchasers today overwhelmingly represent tech pioneers (those who have to have the latest iPhone/Android devices). They are comfortable experimenting and enjoy the newness of cutting-edge purchases. There are far fewer of them, but those who are making such mobile purchases won't be put off by being asked to give a password.

In time, though, as more of the masses migrate to mobile payments, this commonsense keystroke reduction could prove to be quite a help.