Not so long ago, banks were able to offer a mobile app as an added extra. Now it’s expected. A bank without a mobile offering is as unimaginable as one without online banking facilities. Last year, there were 42 million mobile banking users and that’s expected to increase to 99 million by 2018. Yet, banks face a problem that many other app developers do not: banking-grade security requirements severely limit the options banks have when developing banking apps, especially if they want to deliver an excellent user experience.
HTML5 vs native
One of the first decisions that needs to be made before a single line of code is written is which of the two main ways to deploy the app to use: a native app or a HTML5-based mobile web app?
Native apps are what we tend to think of when we hear the word ‘app’ – downloadable from an app store, installed on the device and accessible from the home screen. Web apps on the other hand are accessed through the browser just as you would any other website, but the advances made in HTML5 means that more app-like functionality is available. Both have their advantages, but neither seems to be ‘winning’ the debate. Many big organizations employ both. For example, Google has a native Gmail app installed as default in every Android phone, and a mobile web version of its email system that’s almost as slick. Big news organizations such as the BBC and CNN have iOS and Android apps available, and their stories are available on their responsive websites that detect if you’re browsing by mobile.
There are many advantages to HTML5-based mobile web apps that can make it a more attractive development platform for banks. Mobile web apps are device-agnostic; the app can be accessed via a browser on any device. This means that there’s no need to develop a separate iOS and Android app, and there’s no need to even think about whether it’s worth developing for Blackberry or Windows Mobile. This cuts down on costs and time-to-market. Updates can be rolled out silently rather than through the app store, which makes fixing bugs and updating the user interface far more efficient. There can also be accessibility advantages, as many calculations can be done remotely rather than on the device; the owner of a couple-of-generations-old iPhone can enjoy the same experience as the owner of the latest Android device.
There are other advantages that could prove especially useful to banks. The quick time-to-market could allow banks to develop different apps for different segments of their customer base, from simple payment apps to wealth management. Again, these would be optimized to the device, allowing banks to pack more functionality into the app viewed on a tablet, which has a bigger screen over a smartphone. A/B testing of new features can be done silently without the need to download an update, offering a non-disruptive route to innovation and experimentation.
Security vs user experience
Where mobile web apps come unstuck is security. Of course, banking apps require extremely high security, not just because it’s preferable, but because it’s required by regulation. The Payment Services Directive 2, draft legislation currently making its way into European law, demands that any online transaction must use ‘strong authentication’. The European Commission’s definition of strong authentication demands at least two-factor authentication. A simple password can never be sufficient for a banking app, putting aside for the moment the argument that a simple password is never any use. It’s possible to enable two-factor authentication for HTML5 mobile web apps, but they require hardware or software-based one-time passwords, such as a through a key fob or a code delivered by SMS.
Logging in then becomes a hassle – users are required to copy and paste codes from other applications or carry around tokens in order to identify themselves. This can hamper adoption, which is a problem in an already crowded marketplace. In the past few years, we’ve even seen angry Facebook campaigns because of mandatory one-time password hardware. Native apps, on the other hand, are able to use the device itself to enable this sort of authentication.
Deciding between the better user experience of native apps and the benefits of the mobile web is tough. It’s also far from simple to switch strategy several years down the line. Much of a bank’s coding time would have to be considered sunk costs, and the applications rebuilt from the ground up to make sure it’s optimized for the new platform. Plus, as is obvious every time Facebook or Twitter makes a user interface change, people can get upset at changes to their everyday apps.
So, banks face a dilemma. Do they deploy a native app with a slick, secure login process, or do you go down the HTML5 route, burdening your users with a login process that leaves them irritated and heading to the competition?
The solution lies in a nifty mixture of native and mobile web apps – ‘hybrid apps’. A hybrid app is a native app ‘wrapper’ containing a browser dedicated to accessing a single mobile web app. The user experience is of accessing a mobile web app, but through a downloaded app rather than a browser shortcut. The native app ‘wrapper’ is where authentication takes place, barely noticeable to the user, so innovative multi-factor methods that use the device itself as an authentication factor can be used, rather than a token.
In the last few years, we’ve seen increased competition for banks in the form of new entrants to the market and disruptive startups. Banks will increasingly face churn because of marginal benefits such as small interest rate differences, friendlier customer service, and better online and mobile offerings. Banks need to ensure that they offer the best digital experience possible to keep their customers happy.