Banking Law And Platform Liability Spain

Banking Law and Platform Liability — Spain

1. Introduction

Platform liability in Spanish banking law concerns responsibility when financial products or payment services are supplied through digital platforms involving several entities rather than through a traditional bank branch.

Typical participants include:

Customer → Platform/App → Fintech → Bank/Payment Institution → Processor/Cloud Provider

If something goes wrong—an unauthorized payment, misleading loan offer, data breach, algorithmic decision, service outage, or fraud—the central question becomes:

Which participant is legally responsible?

Spain does not have one statute called the “Banking Platform Liability Act.” Liability comes from overlapping Spanish and EU regimes governing banking, payments, consumer protection, data protection, digital services, outsourcing and operational resilience.

The most important principle is that using a platform does not normally allow a regulated financial institution to contract away mandatory regulatory responsibility.

2. What is a banking platform?

A banking platform can include:

  • mobile banking applications;
  • online marketplaces offering loans;
  • embedded-finance platforms;
  • payment apps;
  • digital wallets;
  • banking-as-a-service arrangements;
  • account-information platforms;
  • payment-initiation services;
  • investment platforms;
  • crowdfunding platforms;
  • comparison websites.

The legal classification depends on what the platform actually does.

A company calling itself merely a “technology platform” can still perform regulated financial activities.

3. Functional regulation

Spanish/EU financial regulation generally follows a functional approach.

The important question is not simply:

“What does the company call itself?”

Instead:

What service is actually being performed?

If a platform:

  • holds customer funds;
  • executes payments;
  • initiates payments;
  • grants credit;
  • provides investment services;
  • receives deposits;

special authorization requirements may arise.

A contractual disclaimer stating “we are only a technology company” cannot change the actual economic function.

4. Main Spanish and EU framework

Depending on the platform, important legislation includes:

  • Law 10/2014 on the regulation, supervision and solvency of credit institutions;
  • Spanish payment-services legislation;
  • PSD2 — Directive (EU) 2015/2366, as implemented in Spain;
  • GDPR — Regulation (EU) 2016/679;
  • Organic Law 3/2018 on data protection;
  • DORA — Regulation (EU) 2022/2554;
  • Law 16/2011 on consumer credit;
  • Law 5/2019 regulating real-estate credit contracts;
  • Spanish general consumer-protection legislation;
  • MiFID II where investment services are involved;
  • Digital Services Act (DSA) where the relevant activity falls within its intermediary-platform framework;
  • general Spanish Civil and Commercial Code principles.

Which regime applies depends on the platform's activities.

5. First question: who is the regulated provider?

Consider:

Shopping App X

↓

offers consumer loan

↓

loan actually provided by Bank Y

The customer may experience the entire transaction through App X.

But Bank Y may legally remain the lender.

Therefore, the customer interface and the regulated financial provider may be different entities.

The legal documents should clearly identify:

  • lender;
  • payment provider;
  • intermediary;
  • platform operator;
  • data controller;
  • technology provider.

6. Platform as intermediary

A platform may merely introduce customers to banks.

For example:

Customer enters loan requirements → platform displays offers from five lenders.

If the platform does not itself lend money, its banking obligations differ from those of the lender.

Nevertheless, the platform may still face liability for:

  • misleading information;
  • unlawful advertising;
  • data-protection violations;
  • contractual breaches;
  • unauthorized regulated activity.

7. Platform as regulated provider

The position changes if the platform itself performs regulated functions.

Suppose it:

  • holds customer funds;
  • provides payment accounts;
  • initiates payments;
  • provides regulated investment advice.

It may require financial authorization or registration.

A platform cannot escape licensing merely by operating exclusively through an application.

8. Unauthorized payment liability

Payment platforms create one of the most important liability questions.

Suppose:

Customer's account → fraudulent transfer → €4,000 lost.

The legal analysis asks:

  • Was the transaction authorized?
  • Was strong customer authentication required?
  • Was it correctly implemented?
  • Did the customer act fraudulently?
  • Was there gross negligence?
  • Which payment-service provider executed the transaction?

PSD2 and Spanish implementing legislation contain detailed rules governing unauthorized payment transactions.

9. Case 1 — CJEU C-287/19, DenizBank

DenizBank AG v Verein für Konsumenteninformation concerned payment services and contactless card functionality.

The CJEU considered important questions concerning:

  • payment instruments;
  • contactless functionality;
  • contractual modification;
  • liability/security aspects.

Platform relevance

The judgment demonstrates that new technological payment interfaces remain subject to payment-services law.

A transaction does not escape financial regulation simply because it is:

  • contactless;
  • automated;
  • app-based.

Technology changes the interface, not necessarily the applicable legal protections.

10. Payment initiation platforms

PSD2 introduced a regulated framework for payment initiation service providers (PISPs).

A customer may authorize a third-party platform to initiate payment from an account maintained by a bank.

Structure:

Customer

↓

Payment Platform/PISP

↓

Customer's Bank

↓

Recipient

This creates potential liability between multiple providers.

Payment-services law therefore allocates responsibilities rather than forcing the customer to understand the entire technical chain.

11. Account information platforms

PSD2 also recognizes account information service providers (AISPs).

Such platforms can aggregate financial information from several accounts.

Example:

Bank A account
Bank B account
Bank C account

↓

one financial dashboard

This raises important liability issues concerning:

  • consent;
  • authentication;
  • security;
  • data access;
  • GDPR.

12. Outsourcing liability

Banks increasingly outsource platform technology.

For example:

Spanish Bank

↓

outsources cloud infrastructure

↓

Technology Provider

A basic regulatory principle is:

Outsourcing an activity does not automatically outsource the regulated institution's responsibility.

The bank remains responsible for complying with applicable regulatory obligations.

It must manage third-party risk.

13. DORA

The Digital Operational Resilience Act (DORA), Regulation (EU) 2022/2554, has applied since 17 January 2025.

It is highly important for platform banking.

DORA addresses:

  • ICT risk management;
  • incident management;
  • resilience testing;
  • ICT third-party risk;
  • contractual requirements;
  • oversight of critical ICT providers.

A bank cannot simply argue:

“The platform failed because our cloud company failed.”

The third party's contractual liability and the bank's regulatory responsibilities are separate questions.

14. Platform outage

Suppose an online bank platform stops functioning for 12 hours.

Customers cannot:

  • transfer funds;
  • access accounts;
  • execute business payments.

Possible legal consequences can include:

  • regulatory investigation;
  • contractual liability;
  • operational-resilience obligations;
  • customer compensation claims where legally established.

The precise outcome depends on cause, contractual duties, applicable financial regulations and proven damage.

15. Cyberattack liability

Suppose hackers compromise a banking platform.

Relevant questions include:

  1. Did the institution maintain legally required security?
  2. Was personal data compromised?
  3. Were payment credentials compromised?
  4. Were customers notified where required?
  5. Was the regulator notified?
  6. Was the incident properly managed?

One event can simultaneously engage:

  • banking law;
  • payment law;
  • DORA;
  • GDPR;
  • contract law.

16. GDPR liability

Banking platforms process substantial personal data, including:

  • identification;
  • account balances;
  • transaction history;
  • credit information;
  • device data;
  • behavioral data.

The platform may be:

  • controller;
  • joint controller;
  • processor.

The classification matters because GDPR obligations differ.

17. Case 2 — CJEU C-210/16, Wirtschaftsakademie Schleswig-Holstein

This case concerned a Facebook fan page rather than banking, but it is important for platform liability.

The Court adopted a significant approach to joint controllership.

An organization can potentially share responsibility for processing even though it does not control every technical component.

Banking relevance

A bank cannot automatically assume:

“The platform provider processes the data, therefore GDPR is entirely its problem.”

The actual roles of the parties must be examined.

18. Case 3 — CJEU C-40/17, Fashion ID

This case involved a website embedding a Facebook social plugin.

The Court further developed the concept of joint controllership.

An entity may have responsibility for particular stages of processing without being responsible for every stage.

Platform-banking relevance

Modern financial platforms integrate:

  • analytics;
  • identity services;
  • payment APIs;
  • credit scoring;
  • external widgets.

GDPR responsibility should therefore be allocated according to the actual processing activities.

19. Case 4 — CJEU C-683/21, Nacionalinis visuomenės sveikatos centras

This judgment is relevant to controller responsibility where software or applications are developed or operated through multiple actors.

Relevance

It reinforces a broader principle:

Data-protection responsibility is determined by actual influence over purposes and means of processing, not merely by software ownership.

This is particularly important for banking platforms built by third-party developers.

20. Algorithmic platform liability

Suppose a platform uses AI to:

  • score customers;
  • approve loans;
  • set interest rates;
  • block transactions.

The platform may say:

“The algorithm made the decision.”

Legally, that answer is insufficient.

Relevant responsibility remains with identifiable legal actors, potentially including:

  • the bank;
  • platform operator;
  • AI provider;
  • data controller.

The precise allocation depends on the activity and governing law.

21. Case 5 — CJEU C-634/21, SCHUFA Holding (Scoring)

This case is particularly important for financial platforms.

The CJEU considered automated credit scoring under GDPR Article 22.

It held, in substance, that the automated generation of a probability value can itself amount to automated decision-making where another party relies strongly on the score to establish, implement or terminate a contractual relationship.

Platform relevance

Consider:

Fintech Platform

→ AI score

↓

Bank

→ automatic rejection.

The platform cannot necessarily characterize its role as “mere information supply” if its score effectively determines the customer's financial outcome.

22. Consumer-credit platforms

Online marketplaces may distribute:

  • personal loans;
  • BNPL products;
  • credit cards;
  • installment financing.

Consumer-credit legislation can impose requirements concerning:

  • pre-contractual information;
  • advertising;
  • creditworthiness;
  • interest;
  • total cost;
  • withdrawal rights.

A digital interface does not remove these protections.

23. Case 6 — CJEU C-42/15, Home Credit Slovakia

This case concerned the Consumer Credit Directive and information that consumer-credit agreements must contain.

Platform relevance

A consumer obtaining credit through a mobile application retains applicable information rights.

The platform cannot reduce mandatory disclosures merely because:

“Mobile screens are small.”

Digital design must accommodate legal requirements.

24. Case 7 — CJEU C-383/18, Lexitor

Lexitor concerned the reduction of the total cost of consumer credit following early repayment.

It is important for platform lending because consumer-credit rights attach to the underlying financial product regardless of distribution channel.

If a loan is sold entirely through an app, applicable statutory rights do not disappear.

25. Platform design and dark patterns

A banking platform can influence consumer choices through interface design.

Potentially problematic practices include:

  • hiding important charges;
  • making cancellation unnecessarily difficult;
  • pre-selecting optional products;
  • emphasizing “accept” while obscuring alternatives;
  • repeated pressure prompts.

Depending on the circumstances, these practices may raise issues under:

  • consumer law;
  • financial conduct rules;
  • data-protection law;
  • potentially digital-services rules.

Interface design can therefore create legal risk.

26. Misleading financial advertising

Suppose a platform advertises:

“Loan at 0%.”

But the transaction includes significant mandatory charges.

This may raise consumer-protection and advertising issues.

Responsibility may potentially involve:

  • the lender;
  • intermediary;
  • platform;
  • advertiser,

depending on who created, approved and communicated the misleading representation.

27. Marketplace liability

Consider a marketplace displaying financial products from several institutions.

It may argue:

“We only provide the marketplace.”

But its responsibility depends on its conduct.

Relevant questions include:

  • Does it rank products?
  • Is ranking paid?
  • Does it recommend particular loans?
  • Does it collect customer information?
  • Does it conclude contracts?
  • Does it receive commission?
  • Does it handle money?

The more active its role, the more legal obligations may arise.

28. Digital Services Act

The Digital Services Act, Regulation (EU) 2022/2065, regulates certain online intermediary services and platforms.

However, it should not be treated as a replacement for financial regulation.

A platform may simultaneously fall within:

financial-sector rules

and, where relevant,

horizontal digital-platform rules.

Special financial rules continue to govern regulated financial services.

29. Embedded finance

Embedded finance makes platform liability particularly difficult.

Example:

Customer buys furniture online → retailer app offers installment credit → loan supplied by Bank X.

The customer may believe the retailer is the lender.

The legal framework therefore needs clear identification of:

  • actual creditor;
  • intermediary;
  • applicable fees;
  • contractual rights;
  • complaints mechanism.

A seamless interface should not produce legal ambiguity.

30. Banking-as-a-Service

A BaaS structure could involve:

Licensed Bank

↓

API infrastructure

↓

Fintech Platform

↓

Customer

The fintech may control the brand and customer interface while the bank supplies regulated infrastructure.

This arrangement creates risks concerning:

  • regulatory perimeter;
  • outsourcing;
  • customer communications;
  • AML/KYC;
  • complaints;
  • data;
  • operational resilience.

The parties' contract is important, but contractual allocation cannot override mandatory regulatory responsibilities.

31. KYC platform liability

Banks often use external providers for:

  • identity verification;
  • document checking;
  • biometric verification;
  • sanctions screening.

Suppose an external system incorrectly approves a fraudulent identity.

The vendor may potentially have contractual liability toward the bank.

But the bank may still have regulatory obligations concerning customer due diligence.

Thus:

Vendor liability does not automatically equal regulatory exoneration for the bank.

32. Cloud-provider liability

Suppose a cloud provider's failure causes a bank outage.

Two liability layers exist:

Contractual layer

Bank may have contractual rights against the cloud provider.

Regulatory layer

The bank remains responsible for its own DORA and financial-sector obligations.

These layers should not be confused.

33. Platform terms and exclusions

Platform contracts frequently contain provisions such as:

“We accept no liability for third-party services.”

Such clauses do not automatically determine the legal outcome.

Their enforceability depends on:

  • mandatory consumer law;
  • financial regulation;
  • nature of the breach;
  • applicable contract law.

A platform cannot necessarily contract out of mandatory statutory responsibility.

34. Spanish Civil Code

General Spanish contract law also remains relevant.

Potential claims may involve:

  • breach of contract;
  • negligence;
  • damages;
  • causation;
  • interpretation.

Financial regulation often determines the duties, while civil law helps determine consequences between private parties.

35. Spanish Supreme Court and banking transparency

The Tribunal Supremo has developed extensive jurisprudence concerning banking-contract transparency, standardized terms and consumer protection, particularly in mortgage disputes.

These cases are relevant to digital platforms because moving a contract from paper to an app does not eliminate the need for legally adequate information.

The medium changes.

The substantive legal duties remain.

36. Case 8 — CJEU C-415/11, Aziz

Aziz arose from Spanish mortgage enforcement and unfair contractual terms.

The CJEU emphasized effective consumer protection under Directive 93/13.

Platform relevance

Digital execution does not insulate financial terms from judicial scrutiny.

A platform contract remains subject to mandatory rules on unfair terms and effective judicial protection.

37. Case 9 — CJEU C-125/18, Gómez del Moral Guasch v Bankia

This Spanish mortgage case concerned transparency surrounding the IRPH interest-rate index.

Platform relevance

Financial pricing mechanisms delivered digitally must still satisfy applicable transparency requirements.

A sophisticated user interface cannot compensate for legally inadequate information about the economic consequences of a product.

38. Allocation of liability

A simplified matrix is:

EventPotentially relevant actor
Unauthorized paymentPayment provider / other responsible participant
Misleading loan informationLender/platform/intermediary
Data breachController/processor according to GDPR roles
Algorithmic rejectionBank/platform/model provider depending roles
Platform outageBank/platform/ICT provider
Cloud failureProvider contractually; bank regulatorily
KYC failureBank plus vendor depending cause
Unfair contract termFinancial provider
Misleading rankingPlatform/intermediary
Fraudulent paymentPayment-law liability rules
Poor credit disclosureCreditor/intermediary
Cyber incidentRelevant regulated and technology entities

Liability must always be determined from the specific statutory role and facts rather than this table alone.

39. Regulatory authorities

Several regulators can become involved.

Banco de España

Relevant to banks, payment institutions and banking conduct within its competence.

European Central Bank

Relevant to prudential supervision of significant Spanish banks within the Single Supervisory Mechanism.

CNMV

Relevant where platforms provide investment or securities-related services.

AEPD

The Agencia Española de Protección de Datos supervises data protection.

Consumer authorities and courts

May address unfair commercial practices, contractual terms and consumer claims.

A single platform incident can therefore become a multi-regulator problem.

40. Practical example

Assume:

Spanish Bank A

provides accounts.

Fintech B

provides the customer app.

Cloud Company C

hosts the platform.

AI Company D

provides fraud detection.

A customer loses €5,000 through an unauthorized transfer during a system incident.

The analysis would consider:

Payment law

Who is responsible for the unauthorized transaction?

DORA

Were ICT and third-party risks properly managed?

GDPR

Was personal data compromised?

Bank–fintech contract

Did Fintech B breach its obligations?

Cloud contract

Did Company C cause the outage?

AI contract

Did Company D's model fail?

Consumer law

Was the customer treated according to mandatory protections?

The customer should not necessarily be expected to solve this entire technical supply chain before statutory protections can operate.

41. Key case-law framework

The following authorities are particularly useful:

C-287/19, DenizBank
Payment instruments and modern payment functionality.

C-210/16, Wirtschaftsakademie
Joint responsibility in platform data processing.

C-40/17, Fashion ID
Responsibility can attach to particular stages of integrated data processing.

C-634/21, SCHUFA Holding (Scoring)
Automated credit scoring and effective decision-making.

C-42/15, Home Credit Slovakia
Mandatory consumer-credit information.

C-383/18, Lexitor
Consumer-credit rights and early repayment.

C-415/11, Aziz
Effective consumer protection in Spanish banking disputes.

C-125/18, Gómez del Moral Guasch
Transparency in Spanish mortgage contracts.

Not all these judgments concern digital banking platforms directly. They supply the payment, data, automated-decision and consumer-law principles that determine platform liability.

42. Core compliance principles

Spanish banks and financial platforms should therefore follow several basic principles:

  1. Identify the regulated activity.
  2. Identify the regulated entity.
  3. Clearly identify the provider to customers.
  4. Allocate contractual responsibilities between participants.
  5. Do not rely on outsourcing to eliminate regulatory accountability.
  6. Maintain DORA-compliant ICT governance where applicable.
  7. Determine GDPR controller/processor roles.
  8. Protect payment authentication.
  9. Maintain consumer disclosures.
  10. Monitor algorithms.
  11. Maintain effective complaints processes.
  12. Control outsourcing and cloud dependencies.
  13. Maintain audit trails.
  14. Ensure platform marketing is not misleading.
  15. Preserve regulatory access to relevant outsourced functions.

43. Central legal principle

Spanish banking platform liability can ultimately be summarized as:

Digital distribution changes the technological chain, but it does not eliminate the legal chain of responsibility.

The law attempts to identify the regulated actors behind the interface.

A bank cannot automatically avoid responsibility by blaming its fintech.

A fintech cannot avoid regulation merely by calling itself a platform.

A cloud provider's failure does not automatically remove a bank's operational-resilience obligations.

An AI provider's score does not automatically remove responsibility for a credit decision.

44. Conclusion

Banking platform liability in Spain is governed by a layered framework rather than one dedicated platform-liability statute.

The key layers are:

Banking regulation
→ authorization, governance and institutional responsibility.

Payment law/PSD2
→ payment initiation, account access, authentication and unauthorized transactions.

DORA
→ ICT resilience, outsourcing and third-party technology risk.

GDPR
→ data processing, profiling and automated decisions.

Consumer law
→ transparency, unfair terms and financial-product protection.

Civil law
→ contractual liability, damages and causation.

The most useful case-law framework includes DenizBank (C-287/19), Wirtschaftsakademie (C-210/16), Fashion ID (C-40/17), SCHUFA (C-634/21), Home Credit Slovakia (C-42/15), Lexitor (C-383/18), Aziz (C-415/11), and Gómez del Moral Guasch (C-125/18).

Together, these authorities support the central idea that Spain's digital banking ecosystem may distribute technical functions among banks, fintechs, platforms, AI vendors and cloud companies, but mandatory financial and consumer responsibilities remain attached to identifiable legal actors and cannot simply disappear into the technological supply chain.

LEAVE A COMMENT