Top Risks

Cyberattacks at Banks and Financial Services Organizations, and a Look at Open Banking

A review of 2018-2020 cyberattacks at brokerages, investment funds, payment processors, and financial services organizations as well as API security incidents and open banking.
June 01, 2021
4 min. read
Previous article in this series

This is part two of a deeper dive into the reported security incidents at financial organizations. In part one, we looked at data from the F5 Security Incident Response Team (F5 SIRT) for incidents at banks, credit unions, insurance companies, government-sponsored financial institutions, and stock exchanges. Now we’ll examine the reported security incidents at other financial organizations, including investment funds, payment processors, consumer finance lenders, brokerages, and financial services companies. We’ll also discuss how the move to open banking affects the security of these organizations.

First, let’s see how these various types of nonbank financial organizations stack up against each other and the overall average of all financial organizations. Figure 1 shows how different organizations experience different types of attacks. Let’s go deeper into each.

Figure 1. Reported security incidents at payment processors, financial services organizations, investment funds, consumer lenders, and brokerages, 2018-2020.

Cyberattack Incidents at Payment Processors

Payment processors are not financial institutions but private companies that handle large numbers of individual transactions for banks and credit unions. They act as go-betweens for things like payment card transactions and help smooth the flow of commerce.

The security incident data shows that the proportion of denial-of-service (DoS) incidents at payment processors is 56%, which is much higher than the average of all financial organizations at 36%. Conversely, their proportion of password login attacks is 17%, much lower than the average of 29%. Since payment processors take data from merchants (such as stores and retailers), they do not often allow direct customer logins. Therefore, their password login and direct fraud attack surface is lower. However, shutting down a payment processor shuts down both the merchant processing through them and staunches the flow of revenue to the bank. This makes them good candidates for DoS and extortion.

Since DoS is such a big deal here, it’s useful to break down exactly the data. Figure 2 shows the types of DoS attacks payment processors experienced from 2018 through 2020. Network volumetric attacks, at 40%, were the most common type of DoS attack reported. This is where attacker-generated traffic floods the network to consume all available network bandwidth. DNS application attacks (20%) were the second most identified type, where the attacker hits the DNS service with illegitimate requests, clogging up the system for authorized users (see our deeper analysis of DNS attacks). Web application, or layer7, attacks on the payment processor's web applications were the third most identified type, at 10%. To view DoS attacks across all industries, F5 Labs recently explored 2020 distributed DoS (DDoS) trends at F5 Silverline.

Figure 2. DoS incident types seen at payment processors, 2018-2020.

Cyberattack Incidents at Financial Services Companies

Like payment processors, financial services companies are private companies that serve the financial sector by providing data processing for banks, credit unions, and other financial institutions. They can perform loan analyses, credit ratings, check printing, data storage, or analytics. Basically, they provide any outsourced service except payment processing (the previous category).

Overall, these companies saw just about less of everything: they were way below average in DoS incidents at 38%, way below average in password login attacks at 25%, and reported no web attack incidents at all. This left an unusually high number of incidents we bucketed under “miscellaneous” for things like web scraping and malware infections. The financial organizational average for miscellaneous incidents was 5%, while financial services companies clocked in at 38%. In terms of security incidents, these kinds of companies do not look like other financial services companies. In fact, the only other industry that has a comparable proportion of miscellaneous incidents is health care, at 26%. One thing to keep in mind: this data is a slice of a slice of data, so we don’t have the same level of confidence in our conclusions that we would for larger data sets.

Cyberattack Incidents at Investment Funds, Consumer Finance Lenders, and Brokerages

We combined direct consumer finance lenders, stock brokerages, and investment funds since their data was smaller, and they had similar attack patterns to each other. This group reported a high percentage of password login attacks (80%) with the rest of the incidents being DoS attacks.

API Attacks and Open Banking

About 6% of our financial services cyber incident data from 2018 to 2020 involved attacks on APIs. For more information on APIs, refer to our learning series on what APIs are and why they matter.

More than half of the reported API security incidents (55%) happened in 2020. API security incidents are rising and are likely to continue to increase. We also saw 50% more API incidents in the financial sector than any other sector, as the industry average was 4%.

Figure 3 provides an overview of all API-like security incidents reported to the F5 SIRT from 2018 through 2020. These incidents were nearly all password login attacks, which were split evenly between credit unions and banks. Also note that all the API incidents involved APIs that serviced mobile banking clients.

Figure 3. API-related security incidents reported by financial services organizations to the F5 SIRT, 2018-2020.

Implications for the Security of Open Banking

The security of Internet-visible APIs for financial services organizations is a significant concern when it comes to open banking. This is because open banking relies on APIs to enable third-party providers and financial services organizations to build services around financial institutions. Before open banking, technologies like the open-source Open Financial Exchange (OFX) protocol were used for exchanging financial data. OFX is still used today, which is why we’re including OFX-related incidents in this data set. Over time, APIs are on track to replace them.

In the 2021 Application Protection Report, we found that two-thirds of API incidents in 2020 were due to either no authentication, no authorization, or failed authentication and authorization. It seems that the tech world is still struggling with managing fundamental API security controls. Given that open banking increases the financial industry’s use of APIs, we can expect the attack surface to expand along with it.

The security of open banking rests on robust authentication, comprehensive authorization, and sufficient encryption of the data in transit. The F5 article Technical Controls for a Secure Open Banking Initiative explores this more deeply.


Financial organizations often have some of the most comprehensive and mature security controls in all the industry sectors. This is also because they are highly targeted by attackers. It goes without saying that the rewards are high for gaining direct access to a bank account. We can see from this data that attackers continue to move away from traditional software exploits to softer targets like password logins and APIs (which also act as logins). With the help of our colleagues in the F5 SIRT, F5 Labs will continue to monitor these events, looking for patterns that suggest shifts and changes in cyber attacker tactics.

Previous article in this series

Security Controls for Password Login Attacks

  • Regularly review web-facing logs to spot potential credential stuffing and brute force attacks.
  • Ensure email accounts capable of account reset for critical logins are sufficiently protected against password login attacks.
  • Deploy an intelligent antibot solution that uses more advanced controls beyond just IP address blocking, rate limiting, or CAPTCHA.

Security Controls for DoS Attacks

  • Implement DDoS protection using an on-premises solution, DDoS scrubbing service, or hybrid.
  • Use both network and web application firewalls.
  • Use antivirus solutions to curb malware infections.
  • Use a network-based intrusion-detection system.
  • Apply patches promptly.
  • Block traffic with spoofed source IP addresses.
  • Use rate limiting to restrict the volume of incoming traffic.

Security Controls for API Attacks

  • Use established libraries and best practices for API authentication, such as OpenID Connect.
  • Use an API gateway to manage API authentication and authorization.
  • Conduct frequent inventories to maintain awareness of attack surface.
  • External scans of the environment can help identify vulnerabilities in practice, especially in complex environments.
Join the Discussion
Authors & Contributors
Raymond Pompon (Author)

Read More from F5 Labs

2023 Identity Threat Report: The Unpatchables
Top Risks
2023 Identity Threat Report: The Unpatchables
11/01/2023 report 80 min. read
Scanning for TP-Link Wifi Router Vulnerability Increases by 100%
Sensor Intel Series
Scanning for TP-Link Wifi Router Vulnerability Increases by 100%
06/21/2024 article 4 min. read
2024 Bad Bots Review
Bots and Automated Attacks
2024 Bad Bots Review
03/14/2024 article 15 min. read