Technical Controls for a Secure Open Banking Initiative

Interesting and innovative technology is disrupting the financial services market in a good way. Open Banking is one such initiative that can put the customer’s data to use to serve the user’s needs while also extending financial services to populations with no previous access to banking services. The positive impacts of Open Banking are leading to greater adoption, and financial regulators around the world are promoting its application by implementing regulations and guidelines. This article focuses on some of the security controls for Open Banking from various sources, including Australia’s Consumer Data Right (CDR) law,¹ Singapore’s Finance-as-a-Service: API Playbook,² Hong Kong’s Open API Framework,³ the U.K.’s Competition and Markets Authority (CMA) Open Banking guidelines,⁴ and the European Union’s Payment Services Directive 2 (PSD2).⁵

What is Open Banking?

Technologically, Open Banking is the use of APIs to enable third-party providers (TPPs) and financial technology (fintech) firms to build services around financial institutions. TPPs or fintechs can utilize APIs to provide customized services to banking customers, provide sustainable services to underserved markets, and fuel innovation. Financial regulators in different regions recommend or require that financial services institutions (FSIs) open up data for products, consumers, and services to facilitate the building an API economy. This ecosystem requires financial institutions to pass various litmus tests to ensure the safety and integrity of data.

Security in Open Banking

Increased use of APIs in all industries has garnered attention from cybercriminals. Gartner predicted that by 2022, API abuses will be the most frequent attack vector against enterprise web applications that lead to data breaches.⁶ Financial regulators are aware of this fact and numerous guidelines have been recommended to prevent these attacks. While individual guidelines and implementation details might differ from region to region, there are some common technical security controls.

In our current analysis, the focus is on common security controls across various regulations, including authentication controls, authorization and consent management, transaction security, security standards, and operational risks (see Figure 1).

Authentication Controls

All regulations and guidelines noted in this article emphasize the need for authentication. The three distinct identification cases include the following:

• TPP and bank authentication: Identifying participants like fintech and banks prior to granting them access to API endpoints is mandated. Most regulations require Mutual Transport Layer Security (mTLS) authentication. Australia’s CDR tightens the control by mandating a signed JSON Web Token (JWT) for identification using a JWT profile for OAuth 2.0 client authentication and authorization grants. Hong Kong’s guidelines require X.509 certificates to identify genuine bank sites.
• User authentication: Identifying the owner of the data. This is mostly done prior to registration of consent and therefore implementing strong customer authentication is mandated. Regulators require the system include a minimum of two factors. Banks can utilize their existing mechanism for authenticating credentials combined with a one-time password (OTP).
• API authentication: Once user consent is received and the TPP accesses the user’s data from the bank API endpoint, identification is needed at the API level. Most regulators use OpenID Connect (OIDC).¹

Authorization and Consent Management Controls

Open Banking is driven by end users, who need to explicitly authorize TPPs by providing consent to share their data or to perform transactions on their behalf. Consent management should be easy, intuitive, and integrated into the sign-in experience. Some of the keys aspects for this control are:

• Protocol: Regulators in Singapore, Australia, Hong Kong, and the U.K. recommend using OAuth/OIDC. Scopes and claims available in OAuth/OIDC can be used to register consent.
• Lifecycle limit: The lifecycle of consent varies across regulations. For example, Australia’s CDR mandates a maximum validity period of 12 months,² while others have no specific time limit.
• Consent revocation: Most regulations permit revocation of consent. The E.U.’s PSD2 provides that the right to withdraw consent lies only with the user,³ but FSIs may deny access to accounts for such reasons as unauthorized or fraudulent access.

Transaction Security

Open Banking facilitates the transfer of financial data from FSIs to fintechs, hence requirements are necessary to ensure integrity during transit. Transport Layer Security (TLS) is used to provide communication security over the network. Some key points for TLS are:

• TLS version: Regulators in Singapore recommend using TLS version 1.2, while Australia’s CDR recommends TLS version 1.2 or later; others simply mandate the use of TLS.
• Use of mTLS: The U.K.’s CMA Open Banking guidelines require mutually authenticated TLS to provide a robust security profile. Australia’s CDR requires mTLS and mandates that a CDR certificate authority issue the certificate.
• Cipher support: Only Australia’s CDR explicitly restricts support to ciphers listed by financial-grade APIs (FAPIs).⁴

Security Standards

Some guidelines explicitly recommend standards for Open Banking, while others inherit them from overarching banking regulations. For example:

• Singapore’s API Playbook mentions ISO 27001, ISO 22301, and PCI DSS.
• The U.K.’s CMA guidelines recommend implementing security controls for ISO 27001:2013 and ISO 27032:2012.
• The E.U.’s PSD2 recommends ISO 20022 and ISO 27001.

Operational Risks

Opening up APIs means there will be transactions from myriad different parties, so FSIs need to ensure compliance with financial regulations. With multiple partners in the ecosystem, malicious actors have multiple endpoints for introducing fraud into the ecosystem. Some regulators have explicitly called out the need for these capabilities, for example:

• Singapore’s regulators recommend that FSIs maintain risk catalogs across APIs. This includes capabilities such as fraud detection, anti-money laundering (AML), and data privacy.
• The U.K.’s CMA guidelines recommend using specialist counter fraud operations as well as specifying that APIs include risk indicators in a transaction to aid in fraud detection.

Conclusion

Open Banking has the power to transform the banking experience and create new revenue streams for financial institutions. This is seen in the fact that many financial institutions around the globe are opening their data (with or without regulatory mandates). Security is key to the success of an Open Banking initiative. This review of five Open Banking guidelines shows that authentication controls, authorization and consent management, transaction security, security standards, and operational risks are important security vectors that need to be accounted for. While technological implementations might differ, in principle they seek to achieve similar goals.