Seven steps to build security into Financial Services apps

AdamFleming's picture

The growth of smartphones and tablets has opened up a hugely diverse platform for financial mobile applications, writes Adam Fleming, chief technology officer of Apadmi.

With more and more apps entering the market and rapidly becoming the preferred means to conduct trades and transactions, it has never been more important to make sure that mobile applications offered by a financial institution are safe, secure and appropriately reflect the brand values of that institution.

It is vital that any mobile application upholds the trust and security which underpin the relationship between the investor or customer and the financial institution. Here are seven steps that will guide you to ensure your financial mobile app is safe, secure and improves this relationship:

1.       Planning

The first thing to consider is what you want your mobile app to do for your customers and business. Plan a roadmap for your app and then spend time identifying the security risks at each point.

2.       Which device do your customers use?

Different smartphones run on different operating systems (or platforms) each providing slightly different services for different users. Deciding whether your app will support Apple iOS, Android, BlackBerry or WindowsPhone devices will be the first decision you need to make.

Your app developer should be able to look at your roadmap and help determine which mobile platform(s) are most appropriate based on the functionality and your user demographics.

3.       Device-level security

Mobile phones are inherently insecure devices - they fall out of pockets, get left in taxis and get stolen. The implications of this are that the device is an insecure part of the security chain and additional requirements must be placed on any mobile app dealing with sensitive information.

Perhaps the simplest countermeasure to these threats is to ensure that sensitive information is never stored on the device. This can work very well as certain types of information, such as credit card details, should never be stored on a mobile device. However it can also massively compromise user experience.

For example, an app would be more secure if it required the user to enter a long username and password and then 3 or 4 further pieces of information on each login, but it would also lead to users abandoning the app.

In the majority of cases, it is impossible to get away from the need to store some sensitive information on the device, so this should always be minimal and encrypted. Where encryption is used, it is vital to ensure that it is also used in any backups made of the device.

4.       User Identification

Although it is reasonable from a user-experience perspective to have some degree of association between the application and an account, it’s important to ensure that the user is who you think they are, by requiring a password or pin-code.

It’s also essential to consider that while mobile phones tend to be personal devices, tablets are frequently shared between multiple people. If your application is going to be used on tablet devices, spend some time considering how to handle the multi-user scenario and the implications this has for security.

5.       Privilege Partitioning

The basis of privilege partitioning is to associate different functionalities within the app with different levels of privilege. This means that certain low-risk areas of an app, for example accessing an area that grants access to statements may require the user to re-enter the password – which would allow them access for 30 minutes. Performing a trade though, could require the re-entry of the password, plus a pin-number and only allow access for 5 minutes.

The number of different privilege levels needed, and the mechanisms for moving between them can be customised to the requirements of the financial institution and balanced against the user-experience required within the application.

6.       Connectivity and Endpoints

Providing services over the Internet is a well-understood space and there are many technologies already available to help make this simple and secure – primarily HTTPS, public key infrastructure and certificate management. The good news is that virtually all of these technologies are supported by mobile platforms directly.

That said, a mobile device – particularly one connected over a cellular-radio network (such as 3G) should be considered to be a “partially connected” device. This means there is a possibility that connectivity between the device and the back-end may drop – particularly if the user is travelling by road or rail. This can place additional requirements on the endpoints exposed from within the financial institution.

It’s also worth mentioning that the link to a mobile device is likely to be low- or variable-bandwidth, so any communications between the device and the back-end need to be as small as possible.

7.       User Experience

It has often been said that an application is only as good as its interface and this is especially true for financial apps. A mobile app in the finance space must absolutely reflect the institution’s design, values and branding to reassure the user that it is part of its portfolio.

It should extend your corporate brand onto a device which is implicitly trusted by the user – the challenge is to make sure that the experience is good and that you can build upon that trust. The more you can do to deliver the feeling of what it’s like to do business with your institution to the app, the better it will be received.

Adam Fleming is chief technical officer at Apadmi in Manchester, you can read the full report here.