Open banking is quickly becoming a global phenomenon. Spurred by EU PSD2 legislation, companies within Europe and other regions have begun to embrace open banking style practices, either driven by government regulation or market pressure.

Banks are opening APIs for FinTechs to integrate with customer data, spawning a whole new economy of composable financial services that improve the end banking customer experience. However, bank data is a sensitive touchpoint. Opening bank infrastructure brings significant risk, and it requires an improved security posture to meet compliances and data regulations. So, how can we secure open banking?

Below, we’ll discuss discussing how to open banks without making them vulnerable. We’ll introduce what open banking is and cover state-of-the-art bank-grade security standards to ensure banking APIs and data privacy meet the latest regulations and compliances.

What is Open Banking Security?

It’s been over ten years since the Open Bank Project proposed an open banking model. And, it’s been over five years since PSD2 legislation was introduced in the EU. These initiatives propose banks adopt an open interface for third-party providers (TPPs) to integrate with. These banking APIs enable tightly-controlled TPPs to access customer accounts, retrieve information, initiate payments, and perform other actions to improve the customer experience associated with open finance.

Yet, disrupting the online banking journey by introducing third-parties into the mix brings inherent risk. Not to mention, rising cyber threats and breaches associated with sensitive digital information. Thus, open banking security standards have emerged to protect sensitive Personal Identifiable Information (PII), authenticate TPPs, and offer ways to share authorizations among a new network of financial services — all without sacrificing the end-user experience. For open banking to succeed, we really “need to make sure APIs are secure,” said Chris Wood. Customer data must remain safe and only accessible by authorized TPPs.

Five Open Banking Security Standards

So, how do we secure this new paradigm? As Wood describes, many different API standards are being created in various parts of the world to ensure open banking can evolve and remain safe. Wood proposes adopting these standards to control the transport, authentication, authorization, and delegation of credentials. Top standards include HTTPS, mTLS, OAuth 2.0, OpenID Connect, FAPI, and others. Below, we’ll provide a high-level overview of these standards and see where they fit within the open banking security puzzle.

1. mTLS

First off, Wood stresses the importance of Mutual Authentication over Transport Layer Security (mTLS), in which both clients and servers present and validate certificates. Validating server certificates with two-way authentication is tried and true, and quite ubiquitous, meaning it’s readily available for the market to implement. This can help avoid man-in-the-middle, replay, and spoofing attacks.

2. eIDAS

But it doesn’t stop there. There are additional layers over mTLS to consider. eIDAS (electronic IDentification, Authentication and trust Services) is an EU standard for electronic identification which PSD2 requires quality trust service providers (QTSPs) to adopt. This specifies using ASN.1, a data format, to carry extra attributes.

3. OAuth 2.0

OAuth 2.0 is quite ubiquitous and well-known in the land of APIs — most provers use it in some form. OAuth grants unique security powers. For example, with OAuth, an app consuming the Twitter API doesn’t need to see the user’s password. OAuth is supported in open banking initiatives such as the Berlin Group, as well as STET.

Other open banking institutions have yet to adopt OAuth. According to Wood, there are “certainly ways to improve OAuth… upgrading OAuth to add extra security and features is considered important.” He advocates for a combination of OAuth 2.0 and mTLS. This is also where OpenID Connect comes in.

4. OpenID Connect

OpenID Connect sits on top of OAuth to provide further proof of authentication with an ID token. The specification describes it as “a simple identity layer on top of the OAuth 2.0 protocol.” In the form of a JSON Web Token (JWT), this token says the user has authenticated and offers many additional features to extend capabilities.

5. FAPI

Financial-grade API (FAPI) is an OpenID Foundation profile that sits on OpenID Connect, providing extra security for financial organizations. The standard provides additional security features at the authorization server, tightening behaviors by segmenting TPP permissions. FAPI is organized into four drafts: a Read-Only API Security Profile, a Read and Write API Security Profile, JWT Secured Authorization Response Mode for OAuth 2.0 (JARM), and Client-Initiated Backchannel Authentication (CIBA), which provides a new means of requesting the authentication of a user. Wood sees FAPI as “an important building block for the future growth of open banking.”

An Open Banking Security Implementation

Now that we have a broad introduction to open banking security standards, what does a secure open banking implementation look like? Well, it turns out, the same techniques for securing APIs largely apply to securing open banking architectures, says Daniel Lindau, Solution Architect at Curity. Lindau walked through a sample implementation flow to enable financial-grade security and compliance.

Implementation Flow

Lindau describes four main players within an open banking security setup: a Third Party, a Bank Token Service, Open Banking APIs, and at the heart of it all, an API Gateway. To generate a key or certificate for a Third Party to call APIs, Lindau walked through a sample flow:

1. We’ll assume the Third Party is already registered. To begin, they must request access to a user account, likely through an OAuth Code Flow.
2. Then, the Token Service then authenticates the user. As part of open banking standards, the Token Service must support multi-factor authentication.
3. The Token Service now asks the user if they allow the Third Party to access their information. This could involve a pop-up, web page UI, or an authenticator app. Regardless, PSD2 requires a cryptographically signed consent.
4. Next, the Token Service issues a token to the Third Party, proving the consent has occurred. Lindau recommends transforming this into a Sender-Constrained Token, so only the one who holds the token can use it, thus improving security.
5. Next, the Third Party sends the token to the API Gateway. Since it is a Sender-Constrained Token, mTLS must be used.
6. The API Gateway then validates the token, introspects it with the Bank Token Service, and receives a value token, a JWT, allowing the API Gateway to enforce the sender and provide coarse-grained access control holding scopes for specific policies.
7. This JWT is passed to the APIs, containing the data and claims they need to authorize the request. The API authorization then uses a fine-grained access decision to accept the request.

According to Lindau, the flow above demonstrates a secure process to keep sensitive data from reaching the outside world. The key here is using open protocols to enforce sender-constrained access, which is verified within JWTs throughout the entire process. This ensures the user’s direct affirmation from end-to-end.

To enable a firm setup, Lindau stresses a few other areas: TPP Registration, as in Dynamic client registration (RFC 7591) and Dynamic Client Registration Management (RFC 7592), as well as Strong Customer Authentication. He also underscores the benefits of using a Hypermedia API for authentication, a concept Curity is pushing to standardize. Using a hypermedia authentication API would allow the server to drive the entire authentication flow and receive hypermedia links that highlight further abilities.

Open Banking Security Standards: Present and Future Standards

Open banking is rising in importance in the EU and spreading to other global markets. Opening bank API access to third parties could enable many time-saving innovations, like easier loan applications, external payment initiation, or more seamless account aggregations.

To construct a secure open banking implementation, Lindau covered some essential concerns:

• Use dynamic client registration for TPPS — this will help collect client settings.
• Always use sender-constrained tokens — there is no need for bearer tokens when you have trusted keys with your clients.
• Centralize authentication and use multi-factor methods
• Use layered access control decisions, with coarse-grained in the gateway and fine-grained for the APIs.
• Lastly, Daniel recommends consulting the standards!

On that last point, standards are bound to evolve. In terms of future standards adoption, Wood foresees increased use of CIBA or “CIBA-style” interactions and increased use of biometrics standards, such as FIDO2. He also expects access management at a policy level to become more common, along with improvements to native mobile banking experiences.