Banking Law and Identity Theft in Spain

1. Introduction

Banking identity theft occurs when a person unlawfully obtains or uses another person’s identity, banking credentials, payment card, mobile number or authentication information to access financial services or transfer money.

Common forms include:

• Phishing emails and fraudulent banking websites
• SMS phishing or “smishing”
• Telephone impersonation or “vishing”
• SIM-swapping attacks
• Theft of online-banking passwords
• Unauthorised card transactions
• Opening accounts or obtaining credit with stolen identity documents
• Manipulating customers into approving fraudulent transfers
• Taking control of a banking application
• Using money-mule accounts to receive stolen funds
• Business-email compromise and invoice fraud
• Forged identity documents used during digital onboarding

Spanish law addresses these activities through payment-services law, criminal law, data-protection law, consumer law and banking cybersecurity regulations.

2. Principal Spanish Legal Framework

2.1 Royal Decree-Law 19/2018 on Payment Services

Royal Decree-Law 19/2018 implements the EU’s second Payment Services Directive, commonly called PSD2. It establishes the principal liability regime for unauthorised electronic payments.

It applies to:

• Banks
• Payment institutions
• Electronic-money institutions
• Card issuers
• Account-information providers
• Payment-initiation service providers

The legislation distinguishes between:

1. A payment genuinely authorised by the customer;
2. A payment made without the customer’s consent; and
3. A payment apparently approved by the customer because the customer was manipulated by a fraudster.

The third category creates the greatest difficulty. In an authorised push-payment scam, the customer technically enters the transfer or verification code, but does so because a criminal pretends to be the bank, police, supplier or another trusted person.

2.2 Spanish Criminal Code

Identity-based banking fraud can involve several Criminal Code offences.

Fraud and computer fraud

Articles 248 and following deal with fraud, including obtaining an unlawful transfer of assets through computer manipulation or a similar device.

A criminal may be liable where that person:

• Manipulates banking systems;
• Obtains confidential credentials;
• Uses a fake website;
• Deceives the account holder;
• Generates an unauthorised transfer; or
• Uses stolen payment information.

Identity usurpation

Article 401 criminalises the usurpation of another person’s civil status or identity where the offender assumes that identity with sufficient continuity and seriousness.

Not every isolated use of another person’s name necessarily amounts to identity usurpation. The conduct must normally involve a meaningful assumption of the victim’s identity. An isolated fraudulent use may instead be prosecuted as fraud, falsification or unlawful access.

Forgery

Articles 390–392 may apply where an offender creates or uses:

• Forged identity documents
• False bank applications
• Altered payslips
• False signatures
• Fabricated account-opening documents
• Manipulated electronic certificates

Unlawful access and disclosure

Article 197 and related provisions may apply where criminals unlawfully obtain, intercept, access or disclose personal and confidential information.

Money laundering

Persons who receive or move stolen banking funds may be prosecuted under Article 301 where they know, or are legally considered to know, the criminal origin of the money. Money mules can therefore face liability even when they did not design the phishing operation.

3. When Is a Banking Transaction Authorised?

A payment is authorised only when the payer has given legally valid consent in the agreed manner.

The bank should be able to demonstrate:

• How the customer was authenticated;
• Which credentials were used;
• The device and channel used;
• The transaction amount and beneficiary;
• Whether strong customer authentication was applied;
• Whether the authentication code was linked to that specific amount and beneficiary;
• Whether fraud warnings or risk alerts were triggered; and
• Whether the transaction differed materially from the customer’s normal behaviour.

The mere fact that the correct password or one-time code was used does not automatically prove genuine authorisation. Criminals can obtain credentials through malware, impersonation, SIM swapping, remote-access software or social engineering.

EU payment law expressly states that the recorded use of a payment instrument is not necessarily sufficient to prove authorisation, fraud or gross negligence by the customer.

4. Burden of Proof

When a customer denies authorising a transaction, the payment-service provider normally has the burden of proving that the transaction:

• Was authenticated;
• Was accurately recorded;
• Was correctly entered in the accounts;
• Was not affected by a technical failure; and
• Was not affected by another service deficiency.

If the bank alleges fraud or gross negligence by the customer, it must provide evidence supporting that allegation.

Evidence that the bank’s system recorded the correct credentials is relevant, but it may not prove that the customer personally and knowingly authorised the payment.

The bank may need to produce:

• Authentication records
• Device-identification information
• IP and geolocation data
• Login history
• Call recordings
• SMS delivery records
• Risk-scoring results
• Fraud-monitoring alerts
• Changes to the registered telephone number
• Details of newly registered devices
• Beneficiary-registration records

5. Bank’s Refund Obligation

Where a payment is unauthorised, the bank must generally refund the amount immediately and, in principle, no later than the end of the following business day after it becomes aware of the transaction.

The customer’s account should normally be restored to the position it would have occupied if the unauthorised payment had not occurred.

A bank may resist an immediate refund if it has reasonable grounds to suspect customer fraud and reports those grounds to the appropriate authority. A general suspicion or reliance on the successful use of security credentials is insufficient.

The refund obligation may be affected where:

• The customer acted fraudulently;
• The customer intentionally breached security duties;
• The customer was grossly negligent;
• The customer failed to report the transaction within the applicable period; or
• A statutory exception applies.

6. Customer’s Obligations

Customers must take reasonable steps to protect their personalised security credentials. They must also notify the bank without unjustified delay after discovering:

• Loss of a payment card;
• Theft of a mobile device;
• SIM replacement not requested by the customer;
• Unauthorised account access;
• Suspicious transactions;
• Disclosure of banking credentials; or
• Any unauthorised payment.

The maximum statutory notification period is generally 13 months from the debit date, although waiting unnecessarily after discovering the fraud can create difficulties.

The customer should immediately:

1. Contact the bank through an official channel.
2. Block the card and online-banking access.
3. Request blocking of fraudulent beneficiaries.
4. Ask the bank to recall or trace the transfer.
5. Preserve messages, emails, call records and screenshots.
6. Notify the mobile operator in a SIM-swapping case.
7. Report the incident to the police.
8. Submit a written reimbursement claim to the bank.
9. Change passwords from a secure device.

7. Fraud, Negligence and Gross Negligence

Ordinary negligence

Ordinary carelessness does not automatically make the customer responsible for the entire loss.

Examples might include:

• Failing to notice a convincing fraudulent message;
• Clicking a professionally reproduced fake banking website;
• Responding to a message that appeared within a genuine SMS thread; or
• Trusting a caller who possessed detailed personal information.

Gross negligence

Gross negligence requires a serious departure from the conduct expected of a reasonable payment-service user. It should not be presumed merely because the fraud succeeded.

Potential examples include:

• Writing the PIN directly on the card;
• Repeatedly providing full credentials despite explicit and specific warnings;
• Allowing an unknown person to control the device remotely;
• Ignoring obvious evidence that the caller is not connected with the bank;
• Deliberately giving a complete authentication code to a third party without checking the transaction information;
• Waiting an unjustifiably long time to report known fraud.

Whether conduct amounts to gross negligence depends on all circumstances, including:

• The sophistication of the fraud;
• The customer’s age and experience;
• The information possessed by the criminal;
• The appearance of the fraudulent communication;
• The bank’s warnings;
• Whether the bank’s real telephone number or SMS channel was spoofed;
• Whether the payment was unusual;
• Whether the bank detected or should have detected warning signs.

The bank carries the burden of proving fraud or gross negligence; it cannot establish gross negligence simply by showing that authentication technically succeeded.

8. Strong Customer Authentication

PSD2 normally requires strong customer authentication based on at least two independent elements from different categories:

• Knowledge: password or PIN;
• Possession: registered mobile device or token; and
• Inherence: fingerprint, face or another biometric characteristic.

For many remote electronic payments, dynamic linking is also required. The authentication must be linked to:

• The specific amount; and
• The specific beneficiary.

If the amount or beneficiary changes, the authentication code should become invalid.

The detailed requirements appear in Commission Delegated Regulation (EU) 2018/389. Banks must also monitor fraud rates when relying on exemptions from strong authentication.

Strong authentication does not automatically remove bank liability. A payment may still be disputed where:

• A criminal registered a new device;
• The customer’s SIM was fraudulently replaced;
• Malware intercepted authentication information;
• The bank failed to detect abnormal transactions;
• The customer was misled about what was being authenticated; or
• The bank’s process did not clearly display the genuine beneficiary and amount.

9. SIM-Swapping Fraud

SIM swapping occurs when a criminal persuades or corruptly induces a telecommunications provider to issue a replacement SIM linked to the victim’s telephone number.

The criminal can then receive:

• Banking verification messages;
• Password-reset codes;
• Transaction alerts;
• One-time authentication codes.

Potential liability may involve both the bank and the telecommunications provider.

Relevant questions include:

• Did the mobile operator adequately verify the SIM-replacement request?
• Did the bank treat possession of the telephone number as sufficient proof of identity?
• Was a new device registered immediately before the transfer?
• Were the transactions inconsistent with the customer’s history?
• Did the bank detect simultaneous password, device and beneficiary changes?
• Were large transfers completed shortly after the SIM replacement?
• Did the bank provide an effective alert or blocking mechanism?

The allocation of liability depends on causation, regulatory duties, security controls and the conduct of each party.

10. Phishing, Smishing and Vishing

Phishing

The criminal sends an email or creates a fraudulent website resembling the bank’s genuine website.

Smishing

The criminal uses SMS messages. Modern attacks may cause the fraudulent message to appear in the same message thread as genuine bank notifications.

Vishing

The criminal telephones the victim and impersonates a bank employee, police officer or fraud investigator.

A bank should anticipate these forms of fraud. Reasonable controls may include:

• Transaction-risk analysis;
• Behavioural monitoring;
• New-device alerts;
• Delays on high-risk beneficiary changes;
• Confirmation of unusual transfers;
• Clear transaction information in authentication messages;
• Restrictions on remote-access applications;
• Detection of rapid account depletion;
• Accessible emergency reporting;
• Monitoring of spoofed websites and applications.

A disclaimer stating that the bank never requests credentials does not automatically remove the bank’s statutory liability.

11. Data-Protection Responsibilities

Identity theft frequently begins with a personal-data breach. Banks must comply with:

• The General Data Protection Regulation;
• Organic Law 3/2018 on Personal Data Protection and Digital Rights;
• Banking secrecy and confidentiality obligations;
• Cybersecurity and operational-resilience requirements.

Banks must adopt security measures appropriate to the risks associated with financial and identity data.

Where a personal-data breach occurs, the bank must determine whether it must notify:

• The Spanish Data Protection Agency;
• Affected customers;
• The Banco de España;
• Other competent authorities.

Notification to the Spanish Data Protection Agency is generally required within 72 hours where the breach is likely to create a risk to individuals’ rights and freedoms. Affected persons must also be informed where the breach is likely to create a high risk.

12. DORA and Identity-Theft Prevention

Since 17 January 2025, the EU Digital Operational Resilience Act, known as DORA, applies to banks and many other financial entities.

DORA requires institutions to maintain:

• ICT-risk management;
• Incident detection and reporting;
• Digital operational-resilience testing;
• Third-party technology-risk controls;
• Business-continuity arrangements;
• Recovery procedures;
• Governance and management accountability.

Identity theft may expose weaknesses in authentication, customer-data protection, outsourced platforms or incident detection. A serious fraud campaign may therefore constitute both a customer-liability issue and an ICT-risk incident.

13. Important Case Laws

Case 1: Audiencia Provincial de A Coruña—Unauthorised online transfers

In a recent case, the Provincial Court of A Coruña ordered a bank to reimburse transfers that the customer denied authorising.

The bank showed that the customer’s credentials and telephone line had been used. The court held that this did not prove genuine authorisation. Fraudsters can obtain credentials without the customer voluntarily providing them.

The court stressed that the bank must prove legitimate authorisation, not merely technical authentication. The reported decision was subject to a possible appeal to the Supreme Court.

Principle: Use of correct credentials is not conclusive proof that the customer consented.

Case 2: Audiencia Provincial de Badajoz—Phishing liability

The Provincial Court of Badajoz upheld an order requiring a bank to compensate a customer who had suffered a phishing fraud.

The bank argued that the customer was responsible because authentication information had been used. The court rejected the attempt to transfer full responsibility to the customer and considered whether the bank had maintained adequate mechanisms to prevent the fraud.

Principle: The bank must demonstrate adequate security and cannot automatically classify every successful phishing attack as customer negligence.

Case 3: Spanish Provincial Court—Fraudulent SMS transactions

In another Spanish appellate decision, a bank was ordered to refund fraudulent card transactions produced through deceptive text messages.

The court found inadequate cybersecurity measures, particularly because multiple unusual transactions occurred within a short period. It also questioned why certain transfers were blocked while related card transactions were allowed to proceed.

Principle: Banks must detect abnormal transaction patterns and respond consistently across different payment channels.

Case 4: Audiencia Provincial de Zaragoza—Bank employee impersonation

A fraudster impersonated an employee of the victim’s bank, claimed that a fraudulent card movement had occurred and obtained the information needed to remove money from the account.

The Provincial Court of Zaragoza treated the conduct as computer-related fraud because the offender used deception and banking information to produce a non-consensual transfer of assets.

Principle: Telephone impersonation combined with the manipulation of electronic banking systems can constitute criminal computer fraud.

Case 5: Audiencia Provincial de Zaragoza—Organised phishing network

The Provincial Court of Zaragoza convicted members of a network that obtained personal and banking information through phishing and used it for purchases, gambling, virtual-card transfers and other transactions.

The stolen information included:

• Scanned identity documents;
• Bank-account details;
• Online-banking credentials;
• Payment-card images;
• Email accounts; and
• Secret access numbers.

Approximately 172 individuals and numerous banking institutions were affected.

Principle: Phishing operations may involve multiple offences, including computer fraud, document misuse, identity-related offences and laundering activities.

Case 6: DenizBank AG v Verein für Konsumenteninformation

CJEU, Case C-287/19, 2020

The case concerned contactless payment functionality and contractual rules governing payment instruments.

The Court examined when contactless functionality constitutes a payment instrument and when special liability rules for low-value or anonymous payment instruments may apply.

It also subjected contractual terms based on tacit acceptance to consumer-protection requirements.

Principle: Banks cannot use broad contractual terms to circumvent mandatory payment-service and consumer protections.

Case 7: ZG v Beobank SA

CJEU, Case C-351/21, 2023

The customer disputed payments appearing on a bank statement under an unclear merchant description. The Court held that the payment-service provider must provide information enabling the payer to identify the natural or legal person who benefited from the transaction.

Providing only incomplete technical references may not satisfy the bank’s information duty.

Principle: Customers must receive sufficient transaction information to recognise a payee and investigate suspected identity theft or unauthorised payments.

Case 8: DM and LR v Caisse Régionale de Crédit Agricole Mutuel Alpes-Provence

CJEU, Case C-337/20, 2021

This case examined the consequences of failing to notify a bank promptly about the unauthorised use of a payment instrument.

The Court distinguished between the general notification period and the customer’s obligation to report unauthorised use without unjustified delay after becoming aware of it.

Principle: A customer who discovers fraudulent transactions must act promptly. However, loss of reimbursement rights must be assessed under the statutory rules rather than imposed automatically.

Case 9: Caixabank SA v Asociación de Usuarios de Bancos, Cajas de Ahorros y Seguros de España

CJEU, Case C-91/20, 2021

Although the case was not exclusively about identity theft, it concerned consumer protection and banking contract terms.

The decision reinforces the requirement that contractual terms imposed by banks must be transparent and must not create an unfair imbalance contrary to EU consumer law.

Principle: A bank cannot rely on obscure standard terms to shift mandatory payment-security or fraud risks unfairly to consumers.

14. When Will the Bank Probably Be Liable?

A bank is more likely to be required to reimburse the customer where:

• The customer did not consent to the transaction;
• The bank proves only that credentials were used;
• Strong customer authentication was not properly applied;
• Authentication was not linked to the amount and beneficiary;
• A new device was registered shortly before the fraud;
• The transaction was highly unusual;
• Several suspicious transfers rapidly emptied the account;
• The bank ignored fraud-monitoring alerts;
• The bank failed to block the account after prompt notification;
• The bank cannot produce adequate authentication evidence;
• The customer was deceived by highly sophisticated impersonation;
• The bank’s own communication channel or telephone number was convincingly spoofed.

15. When Might the Customer Bear the Loss?

The customer may bear some or all of the loss where the bank proves that the customer:

• Acted fraudulently;
• Knowingly participated in the transaction;
• Deliberately disclosed credentials;
• Committed gross negligence;
• Ignored clear and transaction-specific warnings;
• Failed to report known fraud without justification;
• Failed to dispute the transaction within the statutory period.

Gross negligence must be established through evidence. It should not be inferred solely from the fact that a password, code or registered telephone was used.

16. Claims Procedure

A victim should generally follow these steps:

1. Immediately notify the bank.
2. Block cards, accounts and digital-banking access.
3. Request an immediate refund under the payment-services legislation.
4. Submit a police complaint.
5. Preserve all electronic evidence.
6. Contact the telecommunications provider in a SIM-swapping case.
7. Complain to the bank’s customer-service department.
8. If unresolved, submit a complaint to the Banco de España’s complaints service.
9. Consider a complaint to the Spanish Data Protection Agency where personal-data security is involved.
10. Bring civil proceedings where reimbursement remains unpaid.

A Banco de España complaint can be influential, but an ordinary court may be required to issue a binding judgment ordering repayment.

17. Conclusion

Spanish banking identity-theft law places significant responsibility on banks to maintain secure authentication, monitor suspicious activity and reimburse genuinely unauthorised transactions.

The governing principle is that technical authentication is not always equivalent to legal authorisation. The fact that a fraudster used the correct password, telephone number or verification code does not by itself prove that the customer knowingly approved the transaction or acted with gross negligence.

Each dispute therefore depends on:

• The customer’s actual consent;
• The sophistication of the fraud;
• The bank’s authentication system;
• Transaction-monitoring evidence;
• The speed of the customer’s notification;
• Whether strong customer authentication was correctly applied; and
• Whether the bank can prove fraud or gross negligence by the customer.