OTP Bot Attacks in Financial Services: the Regulatory Exposure Most Compliance Teams haven’t fully mapped
Table des matières
Financial institutions have two distinct OTP bot problems in 2026. The first is operational: attackers are using automated social engineering to bypass two-factor authentication and access customer accounts, payment systems, and internal platforms. The second is regulatory: the controls being bypassed are the same controls that DORA, PCI DSS 4.0, PSD2, and FCA operational resilience rules require you to demonstrate are working.
When an OTP bot attack succeeds, it is not just a fraud incident. It is potential evidence that a mandated control has failed — with reporting obligations, supervisory scrutiny, and penalty exposure that follows.
This article maps the regulatory frame for financial services teams evaluating their OTP bot exposure. For the technical detail on how these attacks work, read how OTP bots are exploiting two-factor authentication.
DORA: what an OTP bot attack triggers
DORA became applicable across EU financial institutions in January 2025, establishing uniform requirements for ICT risk management, incident reporting, and operational resilience across banks, insurers, investment firms, payment institutions, and electronic money institutions. UK institutions serving EU clients are effectively subject to the same requirements in practice, with the FCA and PRA having signalled alignment with DORA’s principles.
The critical point for OTP bot exposure is how DORA classifies incidents. DORA’s incident classification framework does not distinguish between a bot attack and a technical breach — the classification criterion is the impact on availability, integrity, and confidentiality of ICT systems and the data they hold. A successful OTP bot attack that results in unauthorised access to customer accounts or internal financial platforms meets the threshold for a major ICT incident under DORA, triggering fast reporting obligations — sometimes within hours — using harmonised templates submitted to the relevant national competent authority.
DORA also places ICT risk management squarely at board level. Senior leadership must take responsibility for resilience — not delegate it to IT. This means the board cannot credibly say they were unaware that SMS-based authentication was being used for systems in scope, or that the organisation had no visibility into whether employee credentials were circulating in breach datasets. Both are governance failures under DORA’s framework, not just operational ones.
PCI DSS 4.0: the compliance gap SMS OTP creates
PCI DSS 4.0 became fully mandatory in March 2025, with 51 previously recommended requirements now enforceable. The MFA requirements in PCI DSS 4.0 — specifically Requirements 8.4.2 and 8.5.1 — mandate MFA for all access to the cardholder data environment, not just administrative access, and explicitly require that MFA implementations are not susceptible to replay attacks.
SMS-based OTP is vulnerable to replay attacks by design. An OTP bot intercepts the code through social engineering and replays it to complete authentication — precisely the attack vector that PCI DSS 4.0’s MFA requirements are designed to prevent. Organisations still using SMS OTP for any access to cardholder data environments are operating out of compliance with a requirement that has been mandatory since March 2025.
Le PCI SSC confirmed in August 2025 that FIDO2/WebAuthn passkeys satisfy Requirement 8.4.2 as a single phishing-resistant authentication factor. For financial institutions, migrating high-risk accounts to hardware security keys or FIDO2 tokens simultaneously resolves the security gap and the compliance gap — making this one of the clearer cost-benefit cases in authentication security.
PSD2 and strong customer authentication
The EU’s revised Payment Services Directive (PSD2) requires strong customer authentication (SCA) for payment initiation and account access — combining two or more independent authentication factors. The regulatory interpretation of “independent” matters here: if both factors can be compromised through the same social engineering call, they are not functionally independent even if they are technically distinct.
An OTP bot attack that collects both a password and an SMS OTP through the same fraudulent phone call represents a single social engineering event that has bypassed what should be two independent controls. Payment services firms operating under PSD2 should assess whether their current SCA implementation would withstand regulatory scrutiny following an OTP bot incident, not just whether it technically meets the two-factor requirement on paper.
What a compliant and effective response looks like
Compliance teams and CISOs evaluating their position should work through the following in order.
- Audit authentication methods against regulatory requirements first. Map every system in scope for DORA, PCI DSS, and PSD2 against the authentication method it currently uses. Any system using SMS OTP for access that is in scope for these frameworks has a documented compliance gap that needs a remediation plan and timeline.
- Establish credential exposure monitoring as a regulatory control, not just a security one. Under DORA’s ICT risk management requirements, organisations must identify and assess ICT risks proactively. An organisation with no visibility into whether employee credentials are circulating in breach datasets or dark web markets cannot demonstrate it is managing ICT risk proactively — it is only managing it reactively, after an incident has occurred. CybelAngel’s credential intelligence et surveillance du dark web provide the continuous external visibility that satisfies this requirement, surfacing compromised credentials and attacker reconnaissance before an OTP bot campaign launches.
- Document the migration timeline for SMS-based authentication. For any system still using SMS OTP in scope for PCI DSS or DORA, having a documented remediation plan with a specific timeline is better than having no plan. Regulators evaluating compliance take into account whether organisations have identified gaps and are actively remediating — not just whether every control is already perfect.
If your compliance or security team needs a current view of what is externally visible about your organisation — which credentials are circulating, what reconnaissance activity is present, and where your authentication stack has regulatory exposure — our analysts can provide that assessment.
À propos de l'auteur
