Open Banking Security Risks May Open Pandora’s Box

The open banking initiative could be put in jeopardy if data is not sufficiently secured, say Peter Lancos, Jonathan Naismith and Suraj Nittoor at Exate Technology.

Open Banking is a set of reforms that were first introduced in the EU, alongside PSD2 (the second Payment Services Directive), which was enforced from January 2018. Since its original launch in the EU, Open Banking is increasingly being adopted in Asia as a way to promote greater innovation and competition in financial services.

Broadly, it is the use of Open APIs (Application Programme Interfaces) to enable developers to build applications and services around financial institutions’ offerings. The deployment of Open Banking gives power back to the consumer, allowing them to decide who should have access to their data and what services they can provide based on the data.

Under Open Banking, increased competition and innovation in financial services is expected to lead to better financial products, easier comparison between the various offerings, and ultimately better outcomes for consumers.

However, not enough attention is being paid to the potential security risks that may arise as a broader set of entities start to gain access to customer data.

Open Banking in Asia

Singapore is frequently named as the leader in Open Banking in Asia, driven largely by MAS (the Monetary Authority of Singapore), which laid out its policies in this area from as early as 2016. Unlike its European counterparts, MAS favours an organic approach where instead of putting 2019 deadlines in place, the regulator published an API playbook to encourage financial institutions to participate on a voluntary basis.

In Hong Kong, the HKMA (Hong Kong Monetary Authority) published an Open API guideline for banks in July 2018. The HKMA itself opened up the first 50 sets of information covering financial data and important information on 23 July 2018, and a second set of 20 sets of financial data covering statistics related to capital markets, economy, banking and the monetary system on 25 March 2019. The remaining 60 sets of data are expected to be made available by mid-2019. Earlier this year, Hong Kong also got its first Open API exchange, which connects banks to third-party service providers and developers under a single platform, allowing opportunities for greater collaboration on product development.

In Malaysia, BNM (Bank Negara Malaysia) published new policy document a version of Open Banking guidelines in January 2019, focusing on 3 areas: motor insurance, credit card and SME financing. Though slightly less comprehensive than the approach in Singapore, Malaysia’s approach has been to establish a non-mandatory framework and support banking transformation by creating implementation teams. In June 2016, BNM established the FTEG (Financial Technology Enabler Group) to support innovations in the financial sector. In accordance with this initiative, it also launched a FinTech regulatory sandbox framework in mid-2017 to allow the testing of new technologies, including Open Banking. In March 2018, BNM also set up an Open API Implementation Group and an Interoperable Credit Transfer Framework (ICTF).

Meanwhile, the Australian government has been working on implementing their regulatory framework for Open Banking in line with the February 2018 Farrell Review recommendations, including the Consumer Data Right, which will improve consumers’ ability to compare and switch between products and services. Open Banking is expected to officially begin in Australia from 1 July 2019, when CBA, ANZ, Westpac and NAB are expected to make credit/debit card, deposit and transaction account data available under the framework. These banks will then need to make mortgage data available by 1 February 2020, and product data by 1 July 2020. All other banks will have a 12-month delay on the timelines.

Elsewhere in Asia, Japan has been working to establish Open APIs by 2020 with an initial focus on the payments industry; China’s private sector firms have been allowing third parties to offer their financial services via Open APIs thereby incentivising regulators to consider a framework to govern Open Banking; and India is increasingly creating a collaborative ecosystem for startups, FinTechs and developers which also includes the use of Open APIs.

At the regional level, the ASEAN Financial Innovation Network – a cross-border financial industry sandbox co-founded by the International Finance Corporation, MAS, and the ASEAN Bankers Association – launched APIX (the API Exchange) last year to facilitate collaboration between financial institutions and FinTechs. Participating countries include Indonesia, Malaysia, the Philippines, Singapore, Thailand and Vietnam.

Security Risks

The main concern that arises from Open Banking regulations is that the traditional security barriers will come down. The infrastructure behind it, which involves changes to bank/customer transactional relationships, is still very much developing.

Furthermore, Open Banking comes with the expectation that banks make their customers’ personal or business account information accessible externally. This means opening communication ports, typically done via APIs, to provide access to third-party providers that sit outside the banks’ perimeter, and potentially interacting with these providers without fully understanding the security measures they have in place.

In this way, the banks’ security perimeters have been extended beyond their own infrastructure, increasing the risk of cyber-attacks.

Areas of risk in the use of Open APIs include:

1) Inauthentic software – When software and applications are available for free, it is wise to first check the authenticity of the software before allowing it to connect to the banking system. Open source software must go through tough IT due diligence and quarantine testing.

2) Testing and verification of APIs – Exposing thousands of APIs without rigorous quality checks can expose data to huge risks. Testing and verification of APIs is more of a validation of API endpoints, formatting and integration testing. This is mainly done during the development and integration phase. The challenge is that testing and verifying Open APIs requires a much higher quantum of effort compared to what is required for their development.

3) Coding standards – Bad or inefficient coding can cause serious API security risks. Tough coding standards should be in place by regulatory mandate. It should be noted that Singapore has recently included the adoption of security awareness training programmes and secure software development best practices in the MAS’ latest Technology Risk Guidelines. Once the guidelines enter into force, they will require financial institutions to ensure their software developers are trained to apply secure coding, source code review and AppSec testing standards when developing software. Financial institutions should require assurances around this from third party providers.

4) Inadequate SSL validation – To safeguard the security of APIs, validation of SSL certificates is necessary. These certificates authenticate users who access a server by exchanging the client authentication certificate. Typically a user, machine or device that has been properly identified can be granted access to a resource, network or application. Inadequate validation can result in API keys, passwords and usernames being stolen.

5) XML risks – The XML format is intertwined with the SOAP (Simple Object Access Protocol), a message format that has several areas of security risks. There is a common misconception about using SOAP while sending messages using HTTPS and SSL. SSL encrypts the SOAP messages while they travel on the wire. However, sometimes you need to route the message between multiple intermediaries, and you don’t want (1) to have to decrypt and encrypt the message for each intermediary and (2) each intermediary to be able to see the confidential information in the message. It is important to mitigate this risk to avoid a security breach.

6) Endpoints security – Endpoints can remain vulnerable and pose serious security risks. Valid API formats must be used to protect the security of third-party APIs. Endpoint security/protection refers to the approach of protecting a business network when accessed by remote devices such as smartphones, laptops, tablets or other wireless devices. It includes activities, status monitoring and software.

7) Security measure – API connection suitability and eligibility standards to integrate with third-parties and proper security measures should be in place to prevent unauthorised external and internal access.

While customer data is being transferred to and from third-party providers, it can be compromised, whether during transit, at-rest (storage) or in-use. Third-party providers are now responsible for the security controls that protect any shared data they process, not just banks.

If the data is not sufficiently secured, this could result in potential fraudulent financial activity, theft, fines and reputational damage, thereby undermining the trust customers have placed in their banks and ultimately putting the Open Banking initiative in jeopardy.

Given this, Open Banking requires cyber security and a well-defined cyber risk management framework to operate.

OAuth 2.0

To ensure secure communication channels and guarantee customer data confidentiality, secure encryption methods should be used. In the UK, for example, the authentication protocol OAuth 2.0 has been adopted, an industry-recognised secure method for verifying identities digitally. This means consumer consent can be obtained and transferred safely between entities.

The OAuth 2.0 protocol uses tokens that can be passed between parties for authentication. These tokens should be kept secure since they act as entry-keys for the authentication process of an Open Banking data transfer.

The risk of OAuth 2.0, however, is that due to its ‘pass-key’ nature, it is particularly appealing to cyber criminals. If a token doesn’t have a built-in expiry, or isn’t specific to a particular transaction, it could become compromised, such as where attackers reply the same token to gain unauthorised access to account details.

In order to reduce the risk of this occurring, one can use transaction specific tokens, short expiry periods and mutual authentication processes; the latter requires both entities involved to authenticate each other.

It is important to note that OAuth 2.0 might not protect against all the vulnerabilities, such as phishing, and it does not provide support for signature, encryption, channel binding, or client verification. Every potential vulnerability needs to be considered and addressed fully.

The Future of Open Banking

Open Banking will continue to be rapidly adopted globally, especially within Asia where regulators are actively seeking to increase competition and foster innovation, with the intent of providing consumers with better product and service offerings.

The use of Open APIs provides significant opportunities to improve customer outcomes, but it does come with inherent risks that need to be mitigated. The main concern arising from Open Banking is that traditional security barriers will come down, and the infrastructure behind it is still very much developing.

It is critically important for regulators to provide guidance to financial institutions and third-party providers that can ensure the secure sharing of sensitive financial and consumer data, effective handling of consumer consent and guaranteed data compliance.

Given the broad reach of Open Banking, and the cross-border nature of financial services, it would be helpful for authorities to come together to develop a comprehensive and consistent framework to mitigate the security risks.

Peter Lancos is CEO and co-founder, Jonathan Naismith is business development manager, and Suraj Nittoor if chief information officer at Exate Technology, which provides a data middleware solution to protect sensitive data.

To Top
Share via
Copy link
Powered by Social Snap