Banking Law and Platform Liability in Banking Ecosystems — Spain

Jurisdiction: Spain
Area: Banking law, platform banking, payment services, fintech, open banking, outsourcing, consumer protection, data protection and operational resilience

1. Introduction

Platform liability in banking ecosystems concerns responsibility when banking services are delivered through interconnected digital platforms rather than solely through a traditional bank.

A modern Spanish customer may interact with:

• a bank;
• mobile-banking application;
• payment institution;
• electronic-money institution;
• account-information service provider (AISP);
• payment-initiation service provider (PISP);
• fintech lender;
• digital wallet;
• card processor;
• cloud provider;
• identity-verification provider; and
• other outsourced technology companies.

This creates an important legal question:

When something goes wrong in a multi-party banking platform, which entity is legally responsible?

Spain has no single statute called the “Banking Platform Liability Act.” Liability depends on the activity involved and can arise under Spanish banking law, EU payment-services law, consumer law, contract law, GDPR, cybersecurity rules and DORA.

2. Main legal framework

Important sources include:

• Law 10/2014 on the organisation, supervision and solvency of credit institutions;
• Royal Decree 84/2015;
• Royal Decree-Law 19/2018 on payment services and other urgent financial measures;
• the EU payment-services framework derived from PSD2, Directive (EU) 2015/2366;
• Regulation (EU) 2016/679 — GDPR;
• Royal Legislative Decree 1/2007 on consumer and user protection;
• Directive 93/13/EEC on unfair terms;
• Regulation (EU) 2022/2554 — DORA;
• Spanish Civil Code contractual principles; and
• EU rules concerning electronic identification, cybersecurity and digital finance where applicable.

The precise legal regime depends on what each participant actually does.

3. What is a banking ecosystem?

A traditional model is:

Customer ↔ Bank

A platform model can be:

Customer

↓

Fintech application

↓

Payment initiation provider

↓

Bank API

↓

Customer's bank account

while simultaneously:

Cloud provider → hosts platform

Identity provider → authenticates customer

Analytics company → assesses fraud

Card processor → processes payments

The customer sees one interface, but legally several businesses may participate.

4. Liability follows functions

A useful starting principle is:

Liability should be analysed according to the function performed by each participant, not merely according to the brand visible on the customer's screen.

For example:

• the bank may maintain the payment account;
• the PISP may initiate the payment;
• a processor may transmit information;
• a cloud provider may host infrastructure.

The legal duties of each entity differ.

5. Banks remain regulated institutions

A Spanish bank cannot avoid banking-law obligations merely by distributing services through a digital platform.

A credit institution remains subject to requirements concerning:

• governance;
• capital;
• liquidity;
• risk management;
• customer protection;
• outsourcing;
• cybersecurity;
• operational resilience.

Digital distribution changes the operational architecture, not the bank's basic regulated status.

6. Outsourcing and liability

Suppose Bank A outsources its mobile platform to Technology Company B.

If Company B's software fails, the bank cannot automatically tell customers:

“The problem belongs to our technology provider.”

Contractually, the bank may have claims against the vendor.

But regulatory outsourcing generally does not permit a regulated institution simply to outsource its regulatory accountability.

This distinction is crucial:

Customer/regulatory responsibility

is different from

bank/vendor contractual allocation of loss.

7. Open banking

PSD2 transformed the banking ecosystem by recognising third-party payment services.

Two especially important participants are:

AISP — Account Information Service Provider

With appropriate customer permission, provides consolidated information concerning payment accounts.

PISP — Payment Initiation Service Provider

Initiates a payment at the customer's request from an account held with another provider.

This creates direct legal relationships between banks, customers and third-party providers.

8. Consent

Platform access does not mean unlimited access.

Third-party payment services depend on the customer's authorisation/consent under the applicable payment-services framework.

A PISP cannot simply conclude:

“The customer uses our application, therefore we may access everything.”

Access must correspond to the legally permitted service.

9. Strong Customer Authentication

Strong Customer Authentication (SCA) is an important component of European payment law.

Authentication generally involves independent elements drawn from categories such as:

• knowledge;
• possession;
• inherence.

Example:

Password/PIN + registered device

or another compliant combination.

SCA seeks to reduce fraud in electronic payments.

10. Unauthorised payment transactions

One of the most important platform-liability questions arises when a customer says:

“I did not authorise this payment.”

Payment-services legislation establishes rules concerning:

• notification;
• evidence;
• authentication;
• reimbursement;
• payer conduct;
• provider responsibility.

A transaction appearing in a computer system does not automatically resolve the legal question of authorisation.

11. Burden of proof and authentication

Where a payment is disputed, technical evidence can include:

• authentication records;
• device information;
• transaction timestamps;
• API logs;
• security credentials.

But successful authentication and legal authorisation are conceptually distinct.

The applicable payment-services rules determine the evidential and liability consequences.

This makes high-quality audit logs essential.

12. Platform fraud example

Assume:

1. Customer uses a Spanish fintech app.
2. The app connects to Bank A.
3. Fraudsters compromise the customer's credentials.
4. €8,000 is transferred.
5. Customer denies authorisation.

Potentially relevant parties include:

• account-servicing bank;
• PISP;
• fintech platform;
• authentication provider.

The investigation should establish:

Where did the failure occur?

The answer determines which legal regime and liability rules apply.

13. PISP liability

A payment-initiation provider has statutory obligations relating to its own payment-initiation activities.

If a payment is:

• incorrectly initiated;
• duplicated;
• improperly transmitted,

the legal analysis must distinguish the responsibilities of the PISP from those of the account-servicing bank.

The ecosystem does not eliminate responsibility—it divides responsibilities according to regulated functions.

14. AISP liability

Account-information providers ordinarily do not move customer money simply by providing account-information services.

Their principal risks can therefore concern:

• unauthorised data access;
• incorrect information;
• security failures;
• GDPR breaches;
• misuse of credentials.

Liability depends on the nature of the failure.

15. GDPR

Platform banking involves intensive processing of personal data.

Relevant data can include:

• account balances;
• transactions;
• salary information;
• merchants;
• payment history;
• device identifiers;
• behavioural data.

The GDPR therefore plays a major role in determining platform liability.

16. Controller and processor

An important distinction is between:

Controller

Determines the purposes and means of processing.

Processor

Processes personal data on behalf of a controller.

However, contractual labels do not necessarily determine the GDPR classification.

An agreement cannot conclusively say:

“Company B is only a processor”

if Company B actually determines relevant purposes and means itself.

The real functions matter.

17. Joint controllers

Some ecosystems can involve joint controllers.

This can arise where multiple parties jointly determine purposes and means of particular processing.

Joint involvement does not necessarily mean that every participant is responsible for every processing operation in exactly the same manner.

The specific role of each participant must be examined.

18. Wirtschaftsakademie case

Wirtschaftsakademie Schleswig-Holstein

CJEU, Case C-210/16, 5 June 2018

The case was not a banking dispute, but it is important for digital-platform liability.

The CJEU recognised joint-controller responsibility in connection with a Facebook fan page.

Banking significance

A financial platform cannot necessarily avoid GDPR responsibility merely because another technology company physically performs data processing.

The actual participation in determining processing matters.

19. Fashion ID

Fashion ID GmbH & Co. KG v Verbraucherzentrale NRW

CJEU, Case C-40/17, 29 July 2019

The CJEU examined responsibility involving a website operator and Facebook social plugins.

It held, in substance, that joint responsibility can relate to specific processing operations for which parties jointly determine purposes and means.

Banking relevance

A banking ecosystem must map responsibility operation by operation.

A participant may have responsibility for one stage of data collection without becoming responsible for every later activity performed by another company.

20. Google Spain

Google Spain SL and Google Inc. v AEPD and Mario Costeja González

CJEU, Case C-131/12, 13 May 2014

Although not a banking case, this foundational Spanish-referred data-protection judgment demonstrated that digital intermediaries can have independent data-protection responsibilities.

Banking significance

Financial platforms handling customer information should not assume that intermediary status automatically eliminates legal responsibility.

21. Consumer protection

Digital banking customers are also protected by Spanish and EU consumer law.

A platform cannot make an unfair contractual term lawful simply by requiring the customer to click:

“I agree.”

Terms must satisfy applicable rules concerning:

• transparency;
• fairness;
• information;
• contractual balance.

22. Banco Español de Crédito

Banco Español de Crédito SA v Joaquín Calderón Camino

CJEU, Case C-618/10, 14 June 2012

The CJEU addressed unfair terms in consumer-credit contracts.

It emphasised the protective function of Directive 93/13/EEC and the role of national courts.

Platform relevance

Digital contracting does not weaken mandatory consumer protection.

An unfair term remains subject to legal review even if the customer accepted it electronically.

23. Aziz

Mohamed Aziz v Caixa d'Estalvis de Catalunya

CJEU, Case C-415/11, 14 March 2013

The case concerned Spanish mortgage enforcement and unfair contractual terms.

The Court reinforced effective consumer protection.

Platform significance

A bank or fintech cannot rely on digital efficiency to avoid substantive consumer protections.

Effective remedies must remain available.

24. Gómez del Moral Guasch

Gómez del Moral Guasch v Bankia

CJEU, Case C-125/18, 3 March 2020

The case concerned transparency surrounding an IRPH-linked Spanish mortgage.

Platform relevance

Financial terms must be presented so that customers can understand relevant economic consequences where the applicable transparency standard requires this.

A sophisticated digital interface cannot compensate for materially opaque financial terms.

25. DenizBank

DenizBank AG v Verein für Konsumenteninformation

CJEU, Case C-287/19, 11 November 2020

This case is especially relevant to digital payment services.

It concerned contractual provisions relating to payment services, including contactless functionality and the application of payment-services rules.

Importance

The case illustrates that technological payment functionality must be classified according to the actual payment-services legal framework.

It also demonstrates the continuing interaction between:

• payment technology;
• contractual terms;
• consumer rights.

26. DORA

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

DORA is highly significant for platform banking.

It establishes harmonised requirements concerning:

• ICT risk management;
• ICT-related incident reporting;
• digital operational-resilience testing;
• ICT third-party risk;
• information sharing; and
• oversight of certain critical ICT third-party providers.

27. Third-party ICT risk

Imagine five major Spanish banks all rely on the same cloud provider.

The provider fails.

Several banks simultaneously lose important services.

This creates:

concentration risk.

DORA responds to the reality that financial stability increasingly depends on technology companies that may themselves not be traditional banks.

28. Contractual outsourcing controls

Financial institutions need robust agreements with ICT providers.

Relevant contractual matters can include:

• service description;
• security;
• data location;
• access;
• audit;
• incident notification;
• subcontracting;
• continuity;
• termination;
• exit arrangements.

But contract clauses alone do not satisfy regulatory governance.

The financial institution must actually monitor third-party risk.

29. Cloud-provider failure

Consider:

Bank A → Cloud Provider X

Cloud Provider X suffers a major outage.

Bank customers cannot:

• log in;
• initiate payments;
• access account information.

Potential legal consequences can involve:

• DORA;
• payment-services obligations;
• contractual liability;
• regulatory reporting;
• consumer complaints.

Bank A may separately have contractual claims against Cloud Provider X.

30. APIs

Open banking depends heavily on application programming interfaces (APIs).

Potential failures include:

• incorrect account information;
• duplicated payment requests;
• unavailable interfaces;
• authentication failures;
• excessive data access.

Banks and third-party providers need mechanisms to determine where an API failure originated.

Without reliable technical logs, allocating responsibility becomes difficult.

31. Platform terms cannot eliminate mandatory rights

A platform may state:

“We accept no responsibility for any payment failure.”

Such a clause cannot automatically override mandatory legal rights.

Consumer and payment-services law may make certain duties non-excludable.

Therefore, contractual risk allocation works only within the limits of mandatory law.

32. AI platforms

Banks increasingly use AI for:

• credit scoring;
• fraud detection;
• customer support;
• transaction monitoring.

If a platform provider supplies the AI, the bank should determine:

• who controls the model;
• what data are processed;
• how outputs are validated;
• whether customers are materially affected;
• who handles errors.

Outsourcing an algorithm does not necessarily outsource legal accountability.

33. Platform lending

Suppose a fintech website connects borrowers with Bank A.

The customer sees only the fintech brand.

But Bank A legally grants the loan.

The ecosystem should clearly disclose:

• identity of lender;
• applicable interest/charges;
• intermediary role;
• contractual counterparty;
• complaint route.

Customers should not be left uncertain about whom they owe money to.

34. Embedded finance

A retailer may offer:

“Instant financing at checkout.”

Behind the interface:

Retailer

↓

Fintech platform

↓

Spanish bank

↓

Loan

This is embedded finance.

The convenience of embedding financial products inside non-financial platforms does not remove banking and consumer-law requirements.

35. Liability mapping

A useful method is to create a responsibility map:

This is only a starting point. Contractual and statutory responsibilities may overlap.

36. Case-law principle: substance over platform label

The combined effect of EU financial, consumer and data-protection jurisprudence supports an important principle:

Legal responsibility follows actual functions and statutory obligations rather than marketing terminology.

Calling a company:

• “technology partner”;
• “marketplace”;
• “gateway”;
• “ecosystem provider”

does not by itself determine its legal position.

37. Case-law principle: effective consumer protection

Aziz and Banco Español de Crédito establish particularly important principles concerning effective consumer protection and unfair terms.

Applied to digital banking:

digital acceptance ≠ automatic fairness.

Courts may still examine whether mandatory consumer protections have been respected.

38. Case-law principle: data responsibility can be shared

Wirtschaftsakademie and Fashion ID demonstrate that digital ecosystems can create shared or joint responsibility for particular data-processing operations.

Applied to banking, this means institutions should not assume that only the company physically storing data bears GDPR responsibility.

39. Case-law principle: payment technology must fit legal categories

DenizBank demonstrates that innovative payment technology still has to be analysed within the legal categories established by payment-services legislation.

A new technical design does not automatically create a regulatory exemption.

40. Eight relevant cases

Not all of these cases concern banking platforms directly. Their significance is that their legal principles apply to the components—payments, consumer contracts and personal data—from which banking ecosystems are constructed.

41. Hypothetical case: embedded loan

Customer purchases a €2,000 laptop through Platform X.

Platform X displays:

“Pay later.”

Bank Y actually provides the financing.

The customer later disputes unexpected charges.

Relevant questions include:

1. Was Bank Y clearly identified?
2. Were financial terms disclosed?
3. What role did Platform X perform?
4. Who concluded the credit agreement?
5. Were mandatory consumer rules satisfied?
6. Was the disputed fee contractually valid?

The platform design cannot hide the identity of the regulated lender.

42. Hypothetical case: API payment duplication

Customer requests one €500 transfer.

Because of an API error, the payment is initiated twice.

Potentially responsible systems include:

• customer application;
• PISP;
• bank API;
• payment-processing infrastructure.

Technical logs should establish:

one customer instruction → two technical requests

and identify where duplication occurred.

Payment-services law then determines the relevant reimbursement and responsibility framework.

43. Hypothetical case: data leak

A fintech platform obtains customer transaction data from Bank A.

The fintech's database is breached.

Potential questions include:

• Was the fintech controller or processor?
• What was Bank A's role?
• Were security measures adequate?
• Was the data access properly authorised?
• Were notification obligations triggered?
• Did outsourcing/third-party controls fail?

GDPR responsibility must be assessed according to the actual processing roles.

44. Hypothetical case: cloud outage

Cloud Provider Z hosts Bank B's mobile banking system.

A six-hour outage prevents customers from accessing the service.

Legal analysis may involve:

Customer ↔ Bank

contract/payment obligations

plus

Bank ↔ Cloud provider

outsourcing contract

plus

Bank ↔ Supervisor

DORA/regulatory obligations.

One event can therefore generate several separate legal relationships.

45. Liability does not always mean damages

This distinction is important.

A platform failure may generate:

• regulatory investigation;
• remediation requirements;
• customer reimbursement;
• administrative sanctions;
• contractual damages;
• data-protection consequences.

These are different legal consequences.

A breach does not automatically mean that every affected customer is entitled to unlimited compensation.

46. Causation and loss

For ordinary damages claims, the claimant generally needs to establish the applicable requirements concerning:

breach

↓

damage

↓

causal connection

Suppose a platform is unavailable for ten minutes and a trader claims €5 million in lost profit.

The existence of an outage alone does not establish the claimed €5 million loss.

Evidence and applicable liability rules remain necessary.

47. Governance checklist for Spanish banks

A Spanish bank participating in a platform ecosystem should identify:

1. every participant;
2. each regulated activity;
3. contractual counterparty;
4. payment-service responsibilities;
5. GDPR roles;
6. customer-facing disclosures;
7. outsourcing arrangements;
8. ICT dependencies;
9. cloud concentration;
10. API security;
11. authentication responsibilities;
12. incident-reporting obligations;
13. complaint ownership;
14. audit rights;
15. subcontractors;
16. business continuity;
17. exit strategy;
18. customer reimbursement procedures;
19. data-retention arrangements;
20. supervisory responsibilities.

48. Regulatory structure

The system can be summarised as:

BANKING PLATFORM

↓

Banking law
Authorisation • governance • prudential responsibility

Payment-services law
PISP • AISP • authentication • unauthorised payments

Consumer law
Transparency • unfair terms • remedies

GDPR
Controllers • processors • security • data rights

DORA
ICT risk • incidents • third-party providers • resilience

Contract law
Allocation of commercial risk between participants

49. Overall legal position

Spanish platform banking therefore operates on three different levels of responsibility.

Level 1 — Customer responsibility

Who owes the customer the relevant banking, payment or contractual obligation?

Level 2 — Regulatory responsibility

Which entity is responsible to the ECB, Banco de España or another competent authority for the regulated activity?

Level 3 — Ecosystem responsibility

How have the bank, fintech, processor and technology providers contractually allocated losses between themselves?

These levels should not be confused.

A bank may have to reimburse a customer first and subsequently pursue a technology provider under a separate contract where the legal conditions for doing so are satisfied.

50. Conclusion

Banking Platform Liability in Spain is governed not by a single platform-liability statute but by an interconnected system of Spanish banking law, EU payment-services law, consumer law, GDPR, DORA and ordinary contractual liability.

The strongest legal principles are:

• regulated responsibility cannot simply be outsourced;
• liability depends on the function actually performed;
• mandatory consumer rights cannot be eliminated through platform terms;
• payment authorisation and authentication require proper legal and technical analysis;
• GDPR responsibility may be divided or shared according to actual processing roles;
• ICT outsourcing requires continuing financial-sector oversight; and
• digital innovation does not place banking activity outside established financial law.

Cases including Banco Español de Crédito (C-618/10), Aziz (C-415/11), Gómez del Moral Guasch (C-125/18), DenizBank (C-287/19), Google Spain (C-131/12), Wirtschaftsakademie (C-210/16), Fashion ID (C-40/17), and Ibercaja Banco (C-600/19) provide important principles for understanding the consumer, payment and data dimensions of these ecosystems.

The practical rule for Spanish financial institutions is therefore to map every platform participant, every regulated function and every flow of money and data. A customer may experience a banking ecosystem as one application, but legally it may contain several separate institutions—and responsibility must be allocated according to what each institution actually does.