Tony Robinson, head of operations, Penrillian
Tony Robinson, head of operations, Penrillian

The Competitions and Markets Authority has ruled that all banks must offer customers mobile banking by 2018. This push to harness the so-called “FinTech Revolution” has been welcomed by many, including the banks themselves who are all striving anyway towards omni-channel banking as part of the battle for competitive advantage. 

Consumers, the banking industry and the regulators alike all agree that mobile banking as standard will be fantastic, on the other hand the security experts are genuinely worried about the reality. As has been the case for mobile developers for years, there will be a tension between functionality and security.

For mobile banking to work, and win the trust of customers, it has to have exemplary security, and every party in the game has to deliver. The key to success is to have open Application Programming Interfaces (APIs) that allow every component to work together seamlessly. The mobile developer, the bank, the card issuer, the security provider, the servicer and so on, all need to combine in a tech ecosystem, the front end of which works seamlessly for the customer. This is the sought-after “frictionless” user experience.

So the APIs themselves have to be well designed, and banks need to be amazing at delivering them. For their part, app developers have to make sure their apps are secure. But how do they achieve that? Because if their product has security flaws, customers could suffer serious losses and the bank could be liable.

The Government has recently published a framework and a set of standards for the creation of the APIs, and the responsibility of implementing them will lie with the individual banks as they work towards the CMA's 2018 mobile banking target. This will be challenging for the banks, most of whom already have massive investment in equally massive legacy IT systems. They will likely look to outsourced IT providers such as market leader Unisys, to create or modify ecosystems into which FinTech and mobile developers such as Penrillian can plug in.

This is where security risks can appear. Mobile banking apps of course already exist, and these will have been developed with suitable diligence. But as the number of implementations increase, the incentive for attackers increases, leading to greater risks for both banks and users.

The question is how can the bank and its tech partners defend users against these attacks? The FinTech revolution has seen a whole new generation of creative, innovative young companies and developers creating astonishingly clever and user-friendly new tech and ideas - which banks and customers alike find highly desirable – but this technology won't be allowed to communicate with a banking API without serious consideration of security first.

So what might a security expert's specific advice be when considering mobile banking risks?

The technical answer for mobile banking apps is that (1) the server is the most likely place to be attacked; (2) even ‘secure' storage on a mobile phone can be accessed by jailbreaking or sophisticated electronic attacks on the device (and that was the source of the first Google Pay exploit that was found); and (3) even HTTPS communication with the server can be intercepted with skill.

A good banking app therefore needs to address all three of these: (1) lots of server defences against brute force attack and Apache server weaknesses. (2) keeping sensitive data on the device disk encrypted with a password known only to the server, and (3) a technique called SSL Pinning, which prevents even quite sophisticated ‘man in the middle' attacks.

However the real answer for mobile apps is that some of the biggest threats are those related to banking, not apps. So if we make logging on so complicated that users need to write down their credentials, that's a threat, because someone might see and use those credentials. If the app provides notification, and it's possible for an attacker to break into the notification service and send notifications that look authentic, then attackers might use them to help persuade customers to pay money to them; that's a threat. If security for the call centre depends  only on things that can all be deduced from data on the phone such as birthday, address, and names of family – someone might steal the phone and that too is a threat. So the mobile developer needs to address all these too.

As ever, the pull between user experience (UX) and security is the big consideration here. UX may be the buzz-phrase of the moment, but without cutting-edge security tech behind it, it's not just useless – it's dangerous.

Contributed by Tony Robinson, head of operations, Penrillian