PSD2, the European regulations for Open Banking, is designed to allow a more open and competitive Financial Services sector across the EU. There are pages and pages of information on managing the market, allowing companies large and small to compete, and the Security / Strong Authentication required to allow 3rd parties open access to banking APIs.

The thing is, these APIs have been effectively in the open for years. 

Mobile Apps and other software have been communicating via APIs for some years now. Major enterprises across multiple markets have found the principle of the API to be useful in creating new networks and new value with the APIs being the conduits (and the glue) that brings them together. Many enterprises have freed their developers' creativity and the product teams have been able to diversify and thrive as rarely before.

This same advantage has been seized upon by Fintechs and established players alike.

How does your mobile Banking App communicate to the Banks' servers? How do you on-board to a new Mobile Financial service, such as Travel Insurance or a Savings product? How do Mobile Payment solutions ensure that they are connecting to the correct Card Schemes?

APIs.

Lets look at the last of these 3 examples; Mobile Payments. This is something about which Inside Secure can talk authoritatively as we've been working in this space with the card schemes now for 5 years and the principles, process and architectures are both well established and are also now pretty much standardised.

The Card Schemes (generally) have been standing up their Token Services, the means by which your credit card number is converted to an apparently random number and is used to allow contactless payments. Among the drivers for these services have also been the OEM Pays and both they and the Banks' own Payment Services connect to the Token Services via APIs. Of course Payment generally is a very well regulated market, that is PCI and EMVCo, as well as the card schemes realise that any loss of trust in a system is extraordinarily difficult to regain and there for security is paramount.

The same, unfortunately, cannot be said for other Mobile Financial Applications.

The problem is simple, Mobile Devices are not network device, they aren't even analogous to laptops. They have many more input and output requirements and a Mobile App is afar more sophisticated piece of software than simply opening a browser window. All the information needed to connect to a Bank's servers, via the Banks' carefully crafted APIs are contained within the application.

To some degree this is recognised, as we found in our first research into the Wild West of Mobile Banking in 2017, there are a number of features that some of the App Developers used that demonstrates their awareness of the challenge - the inclusion of SSL or CertPinning in an attempt to ensure the app connects security to the correct server are examples. 

However, while these are useful tools, what they don't do is to prevent an attacker analysing the application in order to reverse-engineer access to the API to which the app connects, worse still it also gives the attacker the correct SSL and Certificates to utilise in a later attack on the Bank's systems.

We've seen examples of this in the wild, one of our largest Banking customers (a US household name) tells us they see multiple attacks on their Mobile Apps every day.

A more benign example is a small UK company who pre-empted the PSD2 requirements for Open APIs by several years. They (correctly in my opinion) determined that offering a mobile App that consolidated a consumer's entire Financial life into one aggregated application would be attractive to many.

Indeed HSBC has just successfully launched something similar - under PSD2. 

But, as this UK Start-up was 4 years ahead of the ECB's requirements they had no way to access the banks' APIs in order to pull all the account data together for their customers. Their business was stalled, until they realised that the API data was generally sitting, unprotected within each an every Banking App that is sitting on the Google PlayStore, all they needed to do was analyse the Apps at a source code level. So they did, they can now access the Banks' data with impunity.

Of course, this latter example was a small company using ingenuity to offer a new service, well ahead of the industry, but those same techniques are equally useful to less scrupulous hackers who see Financial Services as the next big pay day (as the Credit Card market becomes ever more difficult).

The answer is very simple -  follow the model of our US Banking Customer and stop the analysis (and compromise) of Financial Services apps in the first place.