An overview of the Open Banking process and of the security requirements needed when implementing Open Banking solutions.

What is Open Banking?

On this page

Open Banking Explained

Open Banking refers to the process of enabling third-party financial providers to gain access to consumer data, transactions, and other relevant information, directly from banks and non-bank financial institutions. This is done through application programming interfaces (APIs). This process enables consumers to benefit from enhanced and personalized services.

Our article answering the question What is PSD2? provides an overview of PSD2 security requirements. In this article we will provide further details on an approach for meeting these requirements, for Open Banking solutions.

Open Banking Platform

The PSD2 directive has led to a 'Banking as a Service' API platform in the UK, and in simplified terms this involves the following parties:

  • Banks act as 'Account Servicing Payment Service Providers' (ASPSPs) and host API endpoints
  • Merchants and Fintechs act as 'Third Party Providers' (TPPs) by building apps that call the above APIs
  • Consumers act as 'Payment Service Users' (PSUs) and use apps that access their bank accounts

The platform is designed to be dynamic, so that a consumer can use many merchant apps, and qualifying merchants can call the APIs of many banks.

Open Banking and Security Implementations

In order to establish a concrete best practice on meeting regulations and achieving interoperability, financial working groups have published guidance such as the Open Banking UK Implementer's Draft.

This involves adapting the OAuth and OpenID Connect frameworks into a 'profile' that conforms to PSD2 and deals securely with threats. The profile is used both by banks implementing APIs, and by businesses who call those APIs.

Strong Customer Authentication

Financial security profiles usually require Level of Assurance (LoA) 3 for payment transactions, which in turn requires Multi Factor Authentication. It is also recommended to be able to dynamically change factors used by apps, as part of an Authentication Policy.

How Open Banking Works

Mutual Trust Between Companies

In order to participate in Open Banking, apps call bank APIs over a Mutual TLS tunnel, within a restricted Public Key Infrastructure (PKI). Businesses calling the APIs must present a valid eIDAS client certificate both during authentication and when accessing data.

Open Banking - Mutual TLS Authentication

Automated API Onboarding

After approval by eIDAS, PSD2 mandates that a merchant must be able to begin interoperating with bank APIs without delay. Traditionally however, mutual TLS clients are cumbersome to manage, requiring both OAuth clients and certificates to be configured.

OpenID Connect has a mechanism for Dynamic Client Registration which should be used in this case, so that any approved company can sign up quickly and reliably via HTTPS calls. This is done by sending the eIDAS client certificate to the Authorization Server, to create an OAuth client, whose details can then be used to call the API.

This registration endpoint is protected by mutual TLS and allows any client in possession of a client key signed by an eIDAS authority to connect. This allows for immediate on boarding to take place without delay.

The Dynamic Client Registration Management article provides further details on how DCR can be used with client certificates, and the below video provides details on the Curity Identity Server's implementation.

User Consent

Before taking payment from a customer in an app that uses Open Banking, the PSD2 requirement of user consent must be satisfied. This involves asking the user to confirm the runtime amount of money and merchant being paid.

Consent must also be non-repudiable, audited and linked to access token claims, so that banking APIs have clear proof of the user's intent and can authorize the request.

The built in OAuth consent mechanism does not fully meet these requirements, and a complete solution may involve asking the customer to use an additional app, which makes an out of band call to a third party signing service.

Evolving Financial Grade Security

Since Open Banking involves highly sensitive data, its best practice will evolve further over time, to deal better with threats. The article on Financial Grade Security highlights some of the newer OAuth and OpenID Connect standards related to financial systems.

Conclusion

Open banking implementations require you to meet difficult PSD2 regulations such as the UK Open Banking. This is best managed by implementing a financial security profile designed by experts, based on OAuth and OpenID Connect. You will then need an Authorization Server that supports up to date standards.

One of the key goals of the Curity Identity Server is to enable banking grade security and we continually improve our support for related standards. This provides a toolbox that banks and other businesses can use to build and maintain Open Banking services and clients.

Photo of Gary Archer

Gary Archer

Product Marketing Engineer at Curity

Join our Newsletter

Get the latest on identity management, API Security and authentication straight to your inbox.

Start Free Trial

Try the Curity Identity Server for Free. Get up and running in 10 minutes.

Start Free Trial