Barclays’ Rollout of HCE Identifies the Unique Challenges U.S. Banks Face
I read with interest a September 16 article in PaymentEye trumpeting the fact that Barclaycard has released an Android mobile wallet well before Android Pay arrives. The interesting bit U.S. banks should pay attention to is the dollar limit that Barclays applied to the implementation of host card emulation (HCE) in order to manage risk:
“The credit card provider has confirmed that in November, existing Android customers will be able to take advantage of a new update to Barclaycard’s mobile banking application that will enable their smartphones to make contactless ‘touch and go’ payments.
This feature will allow customers to pay for goods and services in over 300,000 locations nationwide without the use of a debit or credit card.
‘‘Barclaycard has a strong history of innovation and we’re constantly looking for new ways to revolutionise payments,’’ explained Mike Saunders, managing director of digital consumer payments at Barclaycard.
Saunders added that through the new application, customers could manage their bank account on the move, as well as making contactless payments up to £100, which is £70 greater than the current limit for contactless card spending.
The application will also continue to work if their card is lost or stolen, with the user instantly getting another one re-issued.”
The limits are needed because most Android devices have no hardware security, so the cloud is the only thing protecting the token credential.
Customers in the United Kingdom have been introduced to contactless cards and mobile wallets as a convenience for small-ticket purchases, not as a full-blown card replacement product. This is not the case in the United States, where larger-ticket items simply generate a request for the cardholder’s signature. So how will banks in the U.S. manage the increased risk of fraud associated with credentials protected not by hardware but by cloud software?
It would clearly be unwise for U.S. banks to simply deploy a solution and then wait to determine just how bad the fraud loss is—an approach that Barclays wisely rejected. I assume there are other options being investigated, but no one appears willing to discuss this topic openly. Here are all the approaches I can fabricate that might address the concern:
• A preferred solution is to upgrade the back-end real-time fraud management systems to recognize cloud-related alerts; such as “unable to replenish token after last purchase”. This approach leverages current investments in enterprise fraud solutions, but nobody I have talked to indicates this solution is under way. MasterCard and Visa have both told me that the signal from the cloud will simply be passed through to the processor for action. It is unclear what system will receive the signals and how that system will decide what action should be taken for any given signal or series of signals. In theory, Google might form a strategic partnership with an enterprise fraud management provider to encourage banks to upgrade their enterprise fraud solutions, but in the past Google’s attitude has been “as long as our piece of the solution works . . . any problem that comes up isn’t our fault.” Of course, in payments that attitude is dead wrong and will inhibit adoption. Apple understood this based on its closed ecosystem approach and captured significant acceptance by banks.
• Since the cloud is Google’s software, maybe Google, as a sign of trust in its own technology, will agree to accept liability (or a percentage of it). If we assume that Google has not made Trusted Execution Environment (TEE) or Secure Element (SE) a requirement is because it wants a solution that is as broadly available as possible within the Android ecosystem, then covering some liability may be in its best interest to get banks on board.
• Or perhaps U.S. banks will follow Europe’s lead and set dollar limits. If so, then HCE-only mobile payment implementations are not a replacement for the card; rather, they’re a convenience for low-value purchases. Banks that take this approach will need to present the value of mobile payments differently and educate consumers regarding the dollar limit and why it exists.
• Will banks deploy credentials only into Android handsets that have secure hardware implementations? This would help solve the primary concern, but it goes against the marketing message Google is delivering to consumers that Android, regardless of device, is secure.
• Maybe the solution will be a combination of the two approaches mentioned above. If the handset has a hardware Trusted Execution Environment or Secure Element, then the standard “open to buy” option remains. If the device has no hardware security, then perhaps a dollar limit would be applied. This would enable the bank to address the entire NFC-enabled HCE market requiring an education program that only needs to address consumers still using older handsets.
What will you recommend?