Although not considered official supervisory guidance, the most recent FDIC Supervisory Insights newsletter offers an instructive early look into how the agency might examine this emerging electronic banking delivery method in the future. (Before you tune out and decide to wait for the formal guidance, remember it was the Winter 2009 issue that first introduced us to the concept of the Enterprise-wide risk assessment as the preferred replacement for the traditional information security risk assessment. I consider these Supervisory Insight newsletters to be a pretty accurate peek into the regulatory crystal ball.)
The article is titled “Mobile Banking: Rewards and Risks”, and is a fairly deep dive into this relatively new banking service. Mobile banking is defined as the use of a mobile device, commonly a cell phone or tablet computer, to conduct banking activities. The article starts by discussing the current, and estimated future, market for this service, quoting a survey placing the potential adoption of mobile banking at 38 million households by 2015. Clearly, if institutions have not already considered adopting this delivery method, they certainly will in the near future. They separate the mobile service offerings into 3 broad categories based on the delivery method:
- Text messaging/short message service (SMS)
- Mobile-enabled Internet browser
- Mobile applications (apps)
They then discuss the channel-specific mobile banking risks, and this was one of the most interesting parts of the article for me:
A recent study looked at the security of four types of mobile applications – financial services, social networking, productivity, and retail. The study focused on the types of sensitive data that mobile applications store on the device and whether these data were stored securely. Each application was rated “Pass,” “Warn,” or “Fail.” A “Pass” rating means sensitive data are not stored on the device or are encrypted. A “Warning” rating means certain data are stored on the device, but this does not put the user at significant risk of fraud. A “Fail” rating indicates sensitive data, such as account numbers and passwords, are stored on the device in clear text, placing the user at an increased risk of identity theft or other financial fraud.
As you can see, although financial institutions had the highest “pass” rate for mobile applications, they also had uncomfortably high “warn” and “fail” rates. (Also note the extremely high “fail” rates for social networking apps…this only confirms my concerns.) Although they don’t go into great detail on the availability and proper use of controls to mitigate the risks, they do make the point that proper vendor management is key. This is particularly true for community institutions who rely heavily, and almost exclusively, on the built-in controls provided by their product’s vendor.
But they also refer to the updated FFIEC Authentication guidance, stating that it “applies to mobile banking“. This is a bit of a news flash, as the term “mobile banking” is not specifically mentioned anywhere in the updated guidance. In fact this was one of the major criticisms of the update when it was released (although I disagreed). I think it’s clear now that the FFIEC intended for the updated guidance to be broad enough include new and emerging technology, and that we shouldn’t expect a new update every time technology changes. This also means that you should include mobile capabilities in your Electronic Banking risk assessment, as well as the associated controls.
So consider this an early Christmas present from the FDIC, and make sure to incorporate the mobile banking risk management concepts discussed in this article into your electronic banking risk assessment. In summary:
Financial institutions are challenged to ensure their mobile banking service is designed and offered in a secure manner, and customers are made aware of steps they can take to protect the integrity of their mobile banking transactions. (Edit – so does making customers aware mean mobile banking customer training will be a requirement?)
