Financial Sector Cyberattacks in 2026 and the Growing Risks of Interconnected Banking Systems

It's been a particularly difficult few weeks for the global financial sector.

From the multibillion-dollar Binance cyberattack to the theft of approximately €100 million from French banking group Crédit Mutuel Arkéa, several major incidents have raised serious questions about the security of modern financial infrastructure.

Taiwan's Bank SinoPac reported 427 unauthorised transactions affecting 419 customers following an attack involving a supplier's banking system. In India, two financial institutions reportedly lost around $2 million through attacks involving payment APIs.

South Korea's Financial Services Commission also reported 40 hacking incidents involving 37 financial companies between 30 September and 3 November, with approximately 473,000 personal information records exposed.

Separately, a Google Cloud outage disrupted services at several UK banks and fintech providers, including Revolut, Lloyds and HSBC.

We're seeing increased activity first-hand at REDSECLABS as well. We've been handling a record number of incident response engagements recently, alongside our regular penetration testing and red teaming work.

While we can't discuss individual investigations, our work has reinforced how important it is to understand what happens after attackers gain their initial foothold, particularly the privileges they can obtain, the systems they can reach and whether existing controls can prevent further damage.

These incidents have different causes and consequences. Some involved financial theft, others data breaches or operational disruptions, and the precise technical causes of some attacks are still under investigation.

The wider data points in the same direction. IBM’s 2026 Cost of a Data Breach Report puts the average financial services breach at US$6.29 million, compared with US$5.56 million a year earlier and a global average of US$4.99 million. The IMF estimates that nearly one-fifth of reported cyber incidents over the past two decades affected financial firms, causing roughly US$12 billion in direct losses.

Looking at these incidents, a few common concerns stand out.

Why are these risks becoming more significant?

1. Third-party providers are becoming critical parts of financial infrastructure

Financial institutions are increasingly dependent on cloud providers, payment processors, fintech partners and external technology platforms.

Many of these integrations require access to sensitive applications, financial data and, in some cases, transaction-processing functions. A compromised service provider can therefore create risks beyond its own environment. Verizon’s 2026 Data Breach Investigations Report found that a third party was involved in 48% of breaches, up from 30% a year earlier; in financial services the figure was 34%. Among the third parties involved, only 23% fully remediated missing or improperly secured multi-factor authentication on their cloud accounts.

The Arkéa incident raises important questions about how a third-party platform could be involved in fraudulent transactions affecting the bank's accounts.

Bank SinoPac presents another example, where attackers reportedly exploited security settings associated with a supplier's banking system.

The $1.5 billion Bybit attack in February 2025 also demonstrated the risks associated with third-party infrastructure. Attackers compromised a developer at wallet provider Safe and manipulated the transaction-signing interface, leading to the approval of a malicious transaction. Chainalysis estimates that Bybit alone accounted for around 44% of the US$3.4 billion stolen from crypto services in 2025, and attributes at least US$2.02 billion of that year’s thefts to North Korea-linked actors.

These incidents highlight the importance of understanding what third-party services are authorised to do, rather than relying solely on the security of the provider itself.

Security certifications and contractual assurances remain important, but institutions also need independent controls that limit what a compromised supplier or integration can actually access and execute.

2. Attackers are exploiting trusted identities and infrastructure

The Binance incident is particularly interesting from a technical perspective.

Attackers reportedly compromised engineers' devices, obtained deployment credentials and gained access to legitimate wallet-signing infrastructure.

They then abused that infrastructure to generate valid authorisations without needing to extract the underlying private keys protected by multi-party computation (MPC).

Ethereum's EIP-7702 mechanism was also used to establish malicious delegation permissions, allowing the attackers to retain certain execution capabilities even after normal withdrawals were suspended.

What concerns us here is how access intended for development and deployment could ultimately influence financial transaction authorisation.

An attacker may not need to defeat every security control if they can compromise something those controls already trust.

This raises questions about privilege boundaries, segregation of duties and whether sensitive financial operations can be authorised through systems that were never intended to have that level of control.

These relationships deserve considerably more attention during security assessments, particularly the boundaries between development environments, production infrastructure, privileged services and transaction-processing systems. The wider data supports this concern: Chainalysis found that the three largest hacks accounted for 69% of the value stolen from services in 2025, and identifies infiltration of privileged access, such as IT workers placed inside crypto firms, as a key North Korean tactic.

3. Payment automation is creating new opportunities for financial fraud

Modern financial applications increasingly rely on APIs to initiate payments, manage customer accounts and process transactions.

While this improves efficiency, it also increases the consequences of weak authorisation controls. Akamai’s 2026 API Security Impact Study found that 96% of financial services leaders had experienced at least one API security incident in the past 12 months, the highest rate of any industry, and its telemetry shows that banking accounted for 83% of incursions against API endpoints in 2025.

Recent attacks against Indian financial institutions demonstrate how compromised payment credentials and integrations can potentially be used to initiate unauthorised transactions.

A technically valid API request does not necessarily represent an authorised financial transaction.

For example, an application may perform checks on a payment or loan disbursement before sending instructions to a banking API. If an attacker can invoke that API directly using compromised credentials, those earlier checks may be bypassed unless they are independently enforced.

Institutions need to verify payment amounts, beneficiaries, transaction limits and the underlying business authorisation before funds are released.

The security of the API itself is important, but so is ensuring that an authenticated request cannot bypass the financial controls that should govern the transaction.

4. Financial infrastructure is highly interconnected

The recent Google Cloud outage affected multiple banking and financial services in the UK. The disruption on 20 October 2026, reported to stem from a power outage at a Google Cloud data centre near London, affected customers of Revolut, Lloyds and HSBC, and also disrupted Royal Mail, DPD and UK court services.

This was an operational failure rather than a reported cyberattack, but it illustrates an important concern.

A cloud outage, compromised service provider or poorly controlled payment interface can affect institutions that otherwise maintain strong internal security.

A relatively limited failure can create a domino effect across interconnected financial services. The IMF has warned that, although cyber incidents have not yet been systemic, a severe incident at a major financial institution could undermine trust in the financial system, and that the risk of extreme direct losses of at least US$2.5 billion has increased.

A compromised supplier may expose several customers. A failure affecting a shared payment platform can disrupt multiple institutions. An attacker who obtains privileged access to a commonly used integration may have opportunities to target other connected systems.

This is becoming particularly relevant as more institutions depend on the same cloud platforms, payment networks, software providers and technology integrations.

Institutions also need to understand how quickly they can isolate a compromised supplier or critical integration without disrupting essential banking operations.

Operational resilience should account for failures originating outside the institution's own infrastructure, including situations where several critical dependencies are affected simultaneously.

5. Attacks are becoming faster, while many weaknesses remain familiar

AI-assisted offensive tools may be accelerating vulnerability discovery, reconnaissance and exploitation.

Attackers can increasingly automate parts of the attack process, identify exposed services and test weaknesses across large numbers of systems. IBM’s 2026 study found that one in four malicious breaches were AI-enabled, a 56% increase on the previous year, with financial services and energy organisations seeing the highest concentration of AI-driven attacks.

However, many of the weaknesses being exploited are not new.

Excessive privileges, insecure integrations, inadequate segregation of duties, poor visibility and weak transaction authorisation continue to create serious risks. Verizon’s 2026 data underlines this: vulnerability exploitation, at 31% of breaches, became the most common initial access vector, overtaking credential abuse for the first time in the report’s 19-year history.

During incident response, understanding the initial entry point is important, but it is only part of the investigation.

We also need to establish what attackers could access afterwards, which security boundaries they crossed, what allowed the incident to escalate and whether existing controls could have limited its impact.

A compromised workstation, for example, should not automatically provide a path to production infrastructure. Similarly, access to a service account should not provide unrestricted authority to execute sensitive financial operations.

Yet these are precisely the kinds of relationships that need to be examined during realistic security testing.

These questions should be answered before an incident, rather than exclusively during forensic investigations afterwards. The cost of leaving them unanswered is measurable: IBM reports that financial services organisations took an average of 165 days to identify a breach and a further 55 days to contain it.

What should financial institutions do differently?

Based on our security assessment, red teaming and incident response work, we would encourage financial institutions to focus on the following areas.

1. Conduct intelligence-led red teaming and assumed-breach exercises.

Test what an attacker can accomplish after gaining access to a workstation, supplier account or trusted application, including whether they can reach critical payment infrastructure.

These exercises should examine complete attack paths, privilege escalation opportunities and the effectiveness of controls separating sensitive systems.

2. Independently enforce transaction authorisation.

Valid credentials, trusted applications and digital signatures should not automatically establish that a financial transaction is legitimate.

Transaction limits, beneficiary verification, approval workflows and segregation of duties should be enforced independently of the applications initiating payment requests.

3. Review third-party access and privileged identities.

Understand precisely what service accounts, supplier integrations and deployment credentials can access or execute.

Restrict unnecessary privileges and assess whether compromising a trusted identity could provide unintended access to production systems or sensitive financial operations.

4. Improve detection of financial abuse.

Correlate security events with unusual payments, beneficiary changes, transaction volumes and reconciliation discrepancies.

Monitoring should consider financial activity alongside traditional indicators of compromise, particularly where attackers may be using legitimate credentials or trusted applications.

5. Test containment and recovery.

Confirm that disabling compromised accounts, revoking credentials and suspending services actually removes an attacker's ability to initiate further transactions.

Permissions, delegated authorisations and active sessions that remain valid elsewhere need particular attention.

The Binance incident provides an example of why suspending normal operations may not immediately eliminate an attacker's ability to act.

6. Assess critical third-party dependencies.

Financial institutions should test how quickly they can isolate compromised suppliers, suspend affected payment integrations and recover from outages involving critical technology providers.

These exercises should involve security, fraud, payment operations and incident response teams to establish whether the organisation can limit the impact without unnecessarily disrupting essential services.

Banks: compliance is not the same as containment

For banks in particular, our concern is that regulatory assurance can be mistaken for proof that an attacker cannot move money. Frameworks such as DORA and the SWIFT Customer Security Programme set important baseline expectations, and DORA, for example, now expects threat-led testing. But a bank can meet its attestation requirements while a path from a compromised supplier credential, developer account or service identity to payment release remains unexamined. Under Articles 26 and 27 of DORA, financial entities designated by their supervisors must carry out advanced threat-led penetration testing at least every three years.

A second concern is organisational. In many banks, security operations, fraud, payment operations and third-party risk sit in separate teams with separate tooling. An attacker abusing a trusted identity can look routine in each view: a valid login to the security team, a properly authenticated instruction to payments, an approved supplier to vendor risk. Unless these functions are tested together, the first time they share a single picture of an incident may be during the incident itself.

Looking beyond individual incidents

Our recent incident response work has reinforced the importance of examining the entire attack path.

An initial compromise may be relatively limited. The consequences depend on the additional systems, privileges and capabilities the attacker can reach.

Financial institutions continue to invest heavily in cybersecurity, but greater emphasis needs to be placed on validating how effectively individual controls work together.

A privileged identity may be properly authenticated but have excessive permissions. A payment API may accept a valid request without independently verifying its business authorisation. A supplier may have strong security controls but retain access that creates significant risks if compromised.

Individually, these weaknesses may appear manageable. Combined, they can result in serious financial and operational consequences.

If an attacker compromises a trusted application, supplier integration or privileged identity, what independently prevents that access from being used to move money?

And has that control actually been tested?

These are questions financial institutions need to address through realistic security assessments, continuous monitoring and incident response exercises.

At REDSECLABS, we work with banks, fintech companies and financial service providers on incident response, intelligence-led red teaming, adversary emulation, penetration testing and security assessments of critical infrastructure.

Our work focuses on identifying realistic attack paths, validating security controls and helping organisations understand how an attacker could move from an initial compromise towards sensitive financial systems.

If your organisation wants to assess these risks, including third-party access, privileged identities, payment APIs or incident response readiness, contact REDSECLABS to discuss an assessment of your environment.