Skip to main content
Article | FI Observer

Risk vs reward: Open Banking

The quest for greater competition

Financial, Executive and Professional Risks (FINEX)
N/A

By Marcus Porter-Wright | November 16, 2021

What risks are banks exposed to when it comes to open banking and digitalisation?

How are banks upping their game when it comes to innovation and technology-based solutions?

How are banks upping their game when it comes to innovation and technology-based solutions? What risks are banks exposed to when it comes to open banking and digitalisation? This FI Observer piece brings the use of technology to the forefront and what risks are associated with Application Programming Interfaces (APIs).

History

Many banks around the world have a rich long-standing heritage of conservative growth built on traditional deposit and lending practices. The use of digital technology is a relatively new concept when compared to the 100+ years of history that many of these organisations have.

Though banks have seen a significant uptake of digitalisation across in-house operations and externally via distribution and engagement, the banking sector has been slow to innovate technology-based solutions when compared to traditional online retail.

Broadly speaking, over the past decade, since online banking has been widely accepted by customers, banks have played it safe by simply using technology such as websites and mobile apps to do what banks already do rather than going further and innovating into new product and service lines.

Open Banking: the game changer?

Open Banking (OB) went into effect on 13 January 2018 across the UK banking industry and, more widely across Europe, banking under the Revised Payment Service Directive (PSD2). Two key drivers behind these regulations were to:

  • Increase consumer protection whilst making online payments safer; and
  • Create a level playing field to foster innovation and competition in banking services and payments.

To achieve these goals, OB and PSD2 introduced new rights for authorised third-party providers to directly access online payment accounts via APIs.

What is an API?

API can be defined as a set of protocols, procedures, and tools that allow two applications to interact. It is the software intermediary that delivers a request to the server and then relays a response back to the client.

There are great examples circulating online that helps to explain the role of APIs; however, let’s imagine you are dining at a restaurant:

  • You engage with a waiter to ask questions about the menu, place an order for food or drinks, and pay your bill.
  • The waiter is the interface between you and the restaurant, shielding you from all the complicated variables within the restaurant (inventory, ovens, hobs, dishes, pricing, payments and staff).
  • The waiter is the API of the restaurant and you intuitively understand their role without having to fully understand the intricacies of how to run a restaurant; you simply interact with the waiter for your dining experience.

APIs are a menu system by which developers interact with a bank’s digital infrastructure to collaborate in developing new apps and offerings for the bank’s clients.

APIs perform four key roles:

  • Enable the exchange of information between applications and other APIs;
  • Hide complexity and encourage developers to engage and focus on developing solutions;
  • Extending functionality but also allowing the developer or user to customise applications and improve usability;
  • Providing a layer of security with applications.

The use of APIs in encouraging developer interaction has opened banking innovation from previously in-house or in-hired expertise to now being able to utilise a global developer community. APIs help programmers to avoid creating something that already exists every time the developer creates an application and simplify high frequently complex processes without a lot of coding.

Online retailers have successfully used APIs to encourage the development of software and enhance the customer experience, by creating entire eco-systems centred around their brands. This goes beyond just selling third party products and moves into creating their own branded products and diversifying across multiple product and service lines. The ability to continually innovate and access more of the customer’s wallet share, is seeing the most successful retailers outpace their competitors.

Are there risks associated with APIs?

The use of APIs aims to create a simplified menu system by which banks allow developers pre-set functions to utilise. APIs give banks control over what information is accessible, what is not accessible and how any information is accessed. Secure APIs therefore ensure that information remains confidential by only making it visible to the users and servers authorised to consume it.

The control of information and how it is accessed is what gives APIs their secure credentials; however too limited a menu system can stifle innovation. There is a fine balance between too much or too little functionality which provides developers with just the right amount of access to develop and help innovate without giving the keys to too many functions.

In 2019 API calls represented 83% of all web traffic.

An API call is a process that takes place when you send a request for information after setting up your API with the correct endpoints (sources of information). Your information is transferred, processed, and feedback is returned. In 2019 API calls represented 83% of all web traffic. This figure is expected to increase to 90% in 2021 and according to Gartner, by 2022 API abuses will become the most-frequent method of Cyber-attack.1

Looking ahead into the future, if the volume of API calls are steadily rising, then APIs are an obvious area for attackers to target and exploit weaknesses.

Customer impact of API abuse

There are three broad categories of digital risks from a customer perspective: Confidentiality, Integrity and Availability.

Confidentiality: Unintended access to confidential information or other customers’ account information resulting in a data breach.

An attacker was able to query the USPS website and scrape a database of over 60 million corporate users.

Example: In 2018, an issue with the web API for the US Postal Service (USPS) was published. An attacker was able to query the USPS website and scrape a database of over 60 million corporate users, email addresses, account numbers, addresses, campaign data, and phone numbers2. The attacker exploited an API called “Informed Visibility” which provided live tracking data. The weakness in the system meant that the attacker would modify search parameters without escalated privileges. The lack of anti-scraping controls meant that a mass amount of data was exposed during the attack.

Integrity: Being able to make changes beyond the original intended remit.

Example: Man-in-the-middle (MITM) attacks allow an attacker to alter legitimate API requests/responses if a secure channel is not properly authenticated. In 2017, credit score company Equifax was subject to a MITM attack and it was discovered that an Equifax app did not consistently use Hypertext Transfer Protocol Secure (HTTPS) (i.e. a secure way to send data between a web server and a web browser), allowing attackers to intercept data as users accessed their accounts3. When HTTPS is not consistently used, attackers can operate in less secure plaintext HTTP. Despite Equifax being a data breach incident, MITM attacks can result in customer funds being fraudulently redirected.

Availability: An instance where an application is overloaded and loses functionality. Depending on the application’s rights, if the application is enabled to move customer money or make other changes, an availability issue could potentially create a systemic issue such as payment services being unavailable causing users disruption to their intended services.

Example: Flooding is an example of a Denial-of-Service (DoS) attack that can affect the availability of the API. Flooding cripples the API by overwhelming it with requests affecting the quality and reliability of the service causing disruption or even total failure of the service during the API attack.

Implications for insurance

The increasing use of APIs and the array of potential losses and liabilities that could arise from API abuses, as we have seen in the examples above, means heightened exposure for the banking sector. There is a potential that these events can be recoverable under a variety of insurance policies including Directors & Officers Liability, Crime, Cyber as well as Professional Indemnity. This is the time to ensure your current insurance is fit for purpose and reflects this changing landscape. Talk to your broker to discuss the appropriate insurance solution for your needs.


Footnotes

1 https://www.forbes.com/sites/forbestechcouncil/2020/07/21/whats-under-the-hood-of-api-security/?sh=7942604554d9

2 https://www.siliconrepublic.com/enterprise/us-postal-service-data-breach

3 https://csoonline.com/article/3444488/equifax-data-breach-faq-what-happened-who-was-affected-what-was-the-impact.html

Disclaimer

Willis Towers Watson offers insurance-related services through its appropriately licensed and authorized companies in each country in which Willis Towers Watson operates. For further authorization and regulatory details about our Willis Towers Watson legal entities, operating in your country, please refer to our Willis Towers Watson website. It is a regulatory requirement for us to consider our local licensing requirements.

Author

GB Head FINEX Financial Institutions

Contact

Heather Kane
U.S. Head of FINEX Financial Institutions

Related Capabilities

Contact Us