Open banking APIs – opportunities, challenges and uncertainty (blog)

Man wearing a suit standing in front of a white screen

There are increasing calls for the use of open banking APIs from industry groups and even the UK Treasury. Open banking APIs are also a key element of the European Commission’s revised Directive on Payment Services (PSD2). They are designed to open up connectivity and data sharing to existing and new market entrants, with a view to increasing competition and choice for consumers and businesses.

Achieving the aims of PSD2 hinges on banks sharing their customer data with anyone who holds the required license. The third-party ‘access to account’ provision (XS2A) means that banks can no longer block the move to a new payment services market. It encourages new entrants to the market that would allow consumers to make payments from their bank accounts directly to the merchant. A single portal that consolidates all of a consumer’s financial information: banking, insurance and investments, will also be possible.

It is clear that this market shift is inevitable, but while this openness will facilitate innovation and drive competition, there is uncertainty. Much of this is centered around the potential to dramatically increase threat levels and opportunities for cybercriminals to exploit weaknesses in online payment and banking systems. And while the security impact cannot yet be fully assessed, risks will rise at least in kind with a dramatically increased number of new online access points and connections.

Although security standards may become more rigorous to meet the new challenges of these environments, there are inherent vulnerabilities in Internet-based applications (and APIs) that: 1) will be exacerbated by these new regulations, 2) are not addressed by current security standards, and 3) are not anticipated to be addressed in the near term. This is because eliminating these vulnerabilities has not been traditionally thought possible.

It’s perhaps unsurprising then that there is apprehension about the coming “all access” environment. Banks will not only lose direct control of their customers, they will incur yet more operational costs required to overhaul platforms and processes, while at the same time being exposed to even greater risk that will most likely not be directly addressed by these overhauls.

In order to thrive in this new, more connected world, banks and payment service providers (PSPs) must balance innovation and their desire to maximally capitalize on new opportunities with the right security to protect their brand and customers from a significantly increased threat profile.

 

Security challenges in an open environment

The underlying issue is that web and mobile applications are a particularly soft target for cybercriminals for a number of reasons:

  • There are inherent vulnerabilities in the APIs that transfer data and communicate with back- end systems
  • Constant exposure to the Internet makes them easy to probe
  • The openness of the web allows hackers to view source code and data and learn how to attack it
  • Insecure web browsers leave the UI and APIs vulnerable to attack

As underscored by the PSD2 directives, APIs play a key role in creating the open environment they seek. In web and mobile applications, APIs provide a conduit for access to devices and online services, and for banks to communicate with each other. Unfortunately, due to the factors described above, they are also an attractive entry point for hackers and cybercriminals. Vulnerabilities are the result not only of constant exposure to an inherently open and insecure environment, but also of lax development practices and the increasing use of insecure, cloud-based tools and services. Hackers use algorithms to search web sites for exposed APIs. Then, through parameter tampering, spoofing, or man-in-the-middle (MITM) attacks, they steal the keys to the application and gain access to customer data and other critical company assets.

APIs have been compromised in a number of very high profile attacks that have caused significant losses and embarrassment for many well-known brands and their customers. And XS2A increases not only the number of APIs, but adds layers of complexity to the online banking/payments environment, meaning that there is a chance that can also be exploited.

A prime example of a third-party relationship vulnerability being exploited was in the recent breaches of SWIFT, the global financial network that banks use to transfer billions of dollars every day. A number of global banks have reported or are investigating the theft of millions of dollars through these cybercrimes, with SWIFT admitting that all the attacks involved internal and/or external attackers who compromised the banks’ environments to obtain valid operator credentials that would allow them to submit SWIFT messages from financial institutions.

 

Balancing openness with data protection

It’s important to note that PSD2 hasn’t yet had technical standards defined and it’s therefore very uncertain what will happen, until the regulators finish their consultation. However, it’s important to understand that achieving the balance between openness and security means that web and mobile applications must be hardened and defended to the same level as back office systems.

The proliferation of open APIs being heralded by the PSD2 directives means that APIs in particular must become a focal point of security efforts. APIs are the conduit to consumer access and information, and a successful attack on them can cause inestimable damage.  There are two critical aspects to safeguarding an API: 1) preventing the keys that unlock access to API data from being stolen, and 2) verifying the authenticity of the code that is trying to access the API from the application.

Technologies exist on the market today that make it possible to execute APIs without putting data at risk, no matter how hostile the environment. Whitebox cryptography can be used to ensure that API keys are held securely at all times, preventing network data from being tracked or accessed by unauthorized users. Code obfuscation and integrity verification can be used to detect and prevent code tampering, hinder reverse engineering of the code, and continuously verify the integrity of code that is attempting to access the API. These techniques ensure that only code that has been authorized by the operator is able to access the API.

The bottom line is that the opening up of connectivity and data sharing in the financial services industry is going to happen. To maximize the benefits of this opportunity and not become victims of it, banks and PSPs must ensure that they’re properly secured at the application (and API) level as well as at the perimeter.

 


David W. Jones, Sr. Director – Global Business Development

David joined Irdeto in 2008, since that time his responsibilities have included Global partnership strategy and management, and technical partner support services. Dave has extensive international experience working with diverse global partnerships and their introduction to Irdeto’s global customers. In 2014 David moved to the Business Development team to drive entry into new markets/segments which can benefit from Irdeto’s core technologies. David now leads Irdeto’s Payments and Banking segment, delivering solutions to the Financial Services industry and driving relevant partnerships and channels.

Related reading

london
screen-shot-2016-12-06-at-09-31-48
onlineshoppingfrog
pexels-photo