Why open banking standards mean a security-first approach to API management is needed

The UK’s own Open Banking Standards and the European Payment Services Directive current wave (PSD2) are both indications that a more open approach to transactions between financial services institutions and their customers continues to gain groundswell.  

The idea is sound: use application programming interfaces (APIs) to connect all the currently disparate financial services providers and their systems. Consumers get faster, more friction-free payment and flexibility around how they make or receive payments, but without compromising the security of those payments.  The latest Payment Services Directive (usually referred to as PSD2) prescribes the normative frame of reference as it applies to strong customer authentication, and the secured exchange of account and payment data.  security requirements that apply to payment transactions (in particular but not only Strong Customer Authentication (SCA, which is also supported in the UK Open Banking Standard). 

This focus on security is vitally important, because the proliferation of APIs that open banking standards introduce potentially increases security risk.  Put simply, the number of ingress points for would-be attackers is escalating, creating a far bigger landscape for fraud and data breaches. 

So, mitigating these risks has meant a greater focus on API security, but what is often overlooked is the need to secure the entire API lifecycle, right from the very start, and not treat it as something that gets addressed at a later stage.

Let me explain what I mean.  App developers are focused on creating great software.  They look at creating an appealing user experience, compelling features and making sure that the app performs well, particularly across the proliferation of platforms available to end users today.  That’s all important and understandable, but in many cases, that may mean less focus on security from the get-go.

That matters, because as soon as that piece of software is published, it is at risk.  It is well known that as soon as many websites go up, there will be someone in the world trying to hack it, and the same is true for APIs.  Sure, remedial action can be taken, but there is a very small window of time in which to do that, so locking down the security of an API once it has been published means damage-limitation.  No-one wants that, so prevention is better than cure. 

This is why financial institutions and their app development agencies need to adopt security-first API management strategies.  They are not alone, many other industries face the same challenge, such as online retail.  In other words, security needs to be baked in as a priority right from the start of an API’s creation, alongside the user experience, feature development and performance.  

Improving API security

A good starting point is addressing the development culture itself.  These days, there are a lot more people developing APIs, with varying skillsets, and this can include external agencies who may have less of a mandate to focus on security than the corporate team. This is why educating everyone involved about the potential risks around API, and their own roles in mitigating those risks, is important.  The status of security needs to be elevated.

Second, some of the new software development techniques and processes can support more rigorous control of API security throughout the entire process.  For example, Continuous Integration (CI) and Continuous Delivery (CD) principles include establishing 

the right policies, approval workflows, users, groups and roles.  This means that the right people will review an API before it is published, so that nothing is exposed to the outside world without formal, time-stamped sign-off.  This will also help create an audit trail for regulatory compliance reporting.

With the vast amount of data involved, as well as typical fast timescales, it is not feasible to depend purely on manual processes (although of course, human intervention and approval needs to happen somewhere along the way).  Automating as much as possible and avoiding unnecessary duplication of effort is going to be essential for efficient API security as it continues to scale.

Rather than reinventing the wheel every time a new API is created, or a new team member comes on board (with the risk they decide to do security their own way), it is better to create a single API security process, with automation built-in wherever feasible, to ensure on-going repeatability and consistency.  The foundation for this is using API management tools, which ensure that those security processes simply happen, without needing to be switched on or off, remembered or forgotten.  That can extend to third parties outside the organization, to ensure that everyone involved in API creation is working to the same security standards.  

Better security of APIs throughout their entire lifecycles requires some work, but not only is it achievable, in today’s financial services world, it is essential.  In a market so targeted by criminals and so heavily regulated, making sure that APIs do not become an unmanageable sprawl has to be a priority.  A security-first approach to APIs helps puts financial institutions back in control.