Threat Landscape in Digital Banking

What digital banks defend against and how exposures connect

Map threats to the financial service

Digital banking exposes customer devices, applications, sessions, APIs, employee access and provider infrastructure. Physical security, cash, document fraud and insider risks can also remain. There is no universal claim that a digital bank has no physical assets or that one exposure dominates every institution.

Identify assets, actors, entry points, trust boundaries and possible financial effects. Threat categories overlap. A campaign can combine phishing, account compromise, a payment and movement through receiving accounts; that does not make every compromised-account payment an authorised push payment scam.

Customer and identity attacks

Social engineering can deceive customers into disclosing access information, registering an attacker-controlled authenticator or initiating payments. Device malware and malicious extensions may observe or alter interactions. Credential stuffing tests reused credentials; password spraying tries common passwords across accounts. These can occur at different rates and need contextual detection.

SIM swap can divert calls or SMS where the number is used. It does not automatically transfer app push access, every passkey or all channels. Avoid building account recovery around one assumed unbreakable trust anchor. A new device, shared phone or changed network can also be legitimate.

Session theft can bypass a fresh login if a usable token is compromised. Authentication, token protection, authorisation and action controls address different parts of that risk. Strong login does not alone prove that every later instruction is authorised or safe.

API, transaction and decision attacks

Broken resource authorisation can expose another customer's data or permit an action beyond the caller's scope. Parameter manipulation, replay and duplicate financial effects require server-side validation and appropriate idempotency. Rate limiting cannot compensate for permission checks that grant access to the wrong accounts.

Attackers may exploit legitimate workflows rather than only technical vulnerabilities. Account takeover, false applications, merchant abuse and customer-authorised scams require different evidence. A matched payee name does not prove the recipient is trustworthy or the payment purpose genuine.

Rules and models can be evaded or degraded as behaviour changes. Signals should be interpreted with their source, quality and uncertainty. A fraud score alone is not proof of a crime, while an unflagged payment is not proof that no scam occurred.

Infrastructure, providers and insiders

Ransomware, destructive changes, denial of service, compromised updates and excessive privileges can affect availability, confidentiality and financial integrity. Several services may share one identity provider, region, software dependency or operator account. Vendor count alone does not prove independent recovery.

The NIST Cybersecurity Framework 2.0 provides a public framework for governing, identifying, protecting, detecting, responding and recovering. It is a risk framework, not a global banking statute or a guarantee against compromise.

Fictional example: suspicious access and payment

A customer reports an unfamiliar login followed by a new beneficiary and payment. The bank joins session, authenticator, change and payment evidence. It uses an appropriate independent contact route because contact details may also have changed.

Containment preserves evidence and checks actual payment status before requesting recovery or making an adjustment. The classification and customer rights depend on who initiated and authorised the transfer, not just whether the login succeeded.

Takeaway

Prioritise threats by credible harm and actual controls, including legitimate customer recovery. Measure exposure reduction and incident outcomes alongside alert volume, and update the map when products or dependencies change.

Continue to Authentication Authorisation Digital Channels.