Banking-as-a-Service (BaaS) in Spain — Fintech Regulation and Case Law

1. Introduction

Banking-as-a-Service (BaaS) is a business model in which a regulated bank or other authorised financial institution provides banking infrastructure to a fintech, technology company or other business through APIs and embedded-finance arrangements.

The customer may interact primarily with the fintech brand, while the regulated institution actually provides some of the regulated services.

A simplified structure is:

Customer → Fintech/App → BaaS provider → Payment/banking infrastructure

For example, a Spanish fintech might offer:

• payment accounts;
• cards;
• IBANs;
• payment initiation;
• money transfers;
• account information;
• merchant acquiring;
• lending;
• deposits;

while a licensed bank or payment institution supplies the underlying regulated infrastructure.

The critical legal principle is:

BaaS does not transfer regulatory responsibility merely because banking services are delivered through another company's technology platform.

2. Spain's regulatory architecture

Spanish BaaS arrangements generally sit within several overlapping legal regimes:

EU level

• Capital Requirements Regulation (CRR)
• Capital Requirements Directive (CRD)
• Payment Services Directive 2 (PSD2)
• Electronic Money Directive (EMD2)
• Bank Recovery and Resolution Directive (BRRD)
• GDPR
• Digital Operational Resilience Act (DORA)
• EU AML framework
• EU sanctions law
• consumer-protection legislation

Spanish level

Important legislation includes:

• Ley 10/2014, on the organisation, supervision and solvency of credit institutions;
• Real Decreto-ley 19/2018, concerning payment services and payment institutions;
• Ley 21/2011, on electronic money;
• Spanish AML legislation, principally Ley 10/2010;
• Spanish consumer and data-protection rules;
• regulations and supervisory guidance issued by Banco de España and other competent authorities.

The precise legal regime depends heavily on what service the BaaS arrangement actually provides.

3. Why legal classification is the first question

There is no single Spanish "BaaS licence."

Instead, the regulator asks:

What regulated activity is actually being performed?

For example:

Taking deposits from the public may require a credit-institution licence.

Issuing electronic money may require authorisation as an electronic-money institution.

Providing payment services may require authorisation as a payment institution or another legally recognised status.

Providing technology only may not itself constitute a regulated financial service.

Therefore:

BaaS is a business model, not a standalone regulatory licence.

4. Typical BaaS structure

Consider:

Company A — fintech

Owns the mobile application and customer relationship.

Company B — Spanish/EU bank

Provides:

• customer accounts;
• payment infrastructure;
• safeguarding;
• card issuing;
• regulated banking services.

Company C — technology provider

Provides:

• APIs;
• cloud hosting;
• fraud systems;
• identity verification.

The legal analysis must determine which entity performs each regulated function.

A contract saying:

"Company A is only a technology company"

does not necessarily settle the issue.

Regulators look at substance as well as contractual form.

5. Bank versus fintech responsibility

A fundamental BaaS issue is allocation of responsibility.

Suppose a fintech markets:

"Open your bank account instantly."

But the actual account is held with Bank B.

Customers may reasonably believe the fintech itself is the bank.

This creates legal risks involving:

• misleading commercial communications;
• disclosure;
• complaints;
• AML;
• safeguarding;
• data protection;
• customer funds;
• operational failures.

The parties must therefore clearly establish:

Who is licensed?
Who holds the money?
Who performs KYC?
Who makes the payment decision?
Who handles complaints?
Who reports suspicious transactions?
Who is responsible when the API fails?

6. Deposit-taking

One of the most important distinctions is between a bank deposit and customer funds held by a payment institution/e-money institution.

A licensed bank may accept deposits subject to its banking authorisation.

A payment institution generally cannot simply present itself as a deposit-taking bank.

Similarly, an EMI's customer funds are subject to safeguarding requirements, rather than automatically receiving the same legal treatment as ordinary bank deposits.

This distinction is crucial for BaaS marketing.

7. Deposit Guarantee Scheme

Where the BaaS provider is an authorised bank and eligible deposits are held with that bank, the relevant deposit-guarantee framework may apply.

In Spain, the Fondo de Garantía de Depósitos de Entidades de Crédito (FGD) operates within the EU deposit-guarantee framework.

The standard EU protection level is generally:

€100,000 per depositor per credit institution, subject to the applicable rules and exceptions.

But a fintech customer should not assume that every balance displayed in an app is a protected bank deposit.

The legal nature of the funds must be established.

8. Payment services

A major category of BaaS involves payment services.

PSD2 regulates services including:

• execution of payment transactions;
• credit transfers;
• direct debits;
• card payments;
• payment initiation services;
• account information services;
• issuing payment instruments;
• acquiring.

In Spain, these rules are implemented principally through Real Decreto-ley 19/2018 and related regulations.

A fintech offering these services may need to operate through an authorised institution.

9. Embedded finance

BaaS frequently forms the infrastructure behind embedded finance.

For example:

E-commerce platform → embedded wallet

Travel application → embedded card

Payroll platform → employee payment account

Marketplace → seller payment accounts

The customer may not even recognise that a regulated financial institution is behind the service.

This creates an important legal principle:

Embedding a financial service into a non-financial application does not remove the financial-service regulation applicable to the underlying activity.

10. Passporting and Spain

Because Spain is part of the EU Single Market, an appropriately authorised EU financial institution may be able to provide services in Spain under the relevant passporting framework, subject to the applicable notification and regulatory requirements.

This is important for BaaS companies because a fintech operating in Spain might use:

Spanish bank

or

another EU-authorised bank/payment institution providing cross-border services.

The precise structure depends on the institution's authorisation and the service being provided.

11. Outsourcing

BaaS creates extensive outsourcing relationships.

A bank may outsource:

• application development;
• cloud infrastructure;
• customer onboarding technology;
• fraud detection;
• customer service;
• payment processing;
• API management.

But outsourcing does not normally mean outsourcing regulatory accountability.

The regulated institution remains responsible for complying with its prudential and supervisory obligations.

This principle has become particularly important under DORA.

12. DORA and BaaS

The Digital Operational Resilience Act (DORA) became applicable across the EU on 17 January 2025.

It significantly affects BaaS arrangements.

DORA addresses:

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

This is highly relevant because BaaS is fundamentally dependent on technology.

Imagine:

Fintech app → BaaS API → bank core system → cloud provider

If the cloud provider fails, the customer may experience a complete banking-service outage.

The regulated institution therefore needs appropriate operational-resilience controls.

13. Critical ICT third-party risk

BaaS arrangements may create concentration risk.

Suppose 30 fintechs use the same BaaS provider.

The BaaS provider uses one cloud platform.

Then:

cloud failure → BaaS failure → 30 fintechs affected → thousands/millions of customers affected.

This is no longer merely a technology problem.

It becomes a financial-stability and operational-resilience problem.

DORA therefore strengthens governance around ICT third-party relationships.

14. AML/KYC responsibilities

BaaS presents a particularly difficult AML question:

Who knows the customer?

Suppose:

Customer → Fintech → BaaS Bank

The bank may technically hold the account, but the fintech may control the customer relationship.

The parties must determine:

• who performs customer identification;
• who verifies beneficial ownership;
• who performs sanctions screening;
• who identifies PEPs;
• who monitors transactions;
• who files suspicious transaction reports;
• who conducts enhanced due diligence.

Under Spanish AML law, regulated responsibility cannot simply disappear into a commercial outsourcing contract.

15. The "KYC utility" problem

Many BaaS models attempt:

Fintech collects customer data → sends data to bank → bank relies on it.

This can be operationally efficient but legally sensitive.

The bank needs adequate assurance concerning:

• identity verification;
• source of funds;
• beneficial ownership;
• risk classification;
• sanctions screening;
• documentation quality.

A bank cannot simply assume:

"The fintech performed KYC, so our AML responsibility is finished."

The regulated institution must maintain appropriate oversight consistent with the applicable legal framework.

16. Transaction monitoring

BaaS also creates questions about transaction monitoring.

Suppose a fintech has:

100,000 customers

and the bank provides payment accounts.

Who monitors:

rapid transfers → unusual jurisdictions → structuring → mule accounts → circular payments?

The answer must be contractually and operationally clear.

A strong model may involve:

Fintech behavioural monitoring + bank transaction monitoring + shared escalation procedures.

17. Sanctions screening

Sanctions compliance is particularly sensitive.

Suppose a BaaS bank has a real-time sanctions-screening system.

The fintech initiates a payment through an API.

The system should establish:

Who is screened?

• payer;
• beneficiary;
• relevant intermediaries;
• account holders;
• connected parties.

And:

When is the screening performed?

Ideally, where required by the applicable regime:

before the payment is executed or funds are made available.

BaaS architecture therefore needs sanctions controls embedded into the payment flow.

18. Consumer protection

The customer may think:

"I use Fintech X, therefore Fintech X is my bank."

This creates significant consumer-law risk.

The user should be able to understand:

• identity of the regulated entity;
• nature of the account;
• applicable deposit/safeguarding protection;
• fees;
• complaints procedure;
• liability allocation;
• payment-service terms.

Misrepresentation concerning regulatory status can be particularly serious.

19. Liability when the BaaS API fails

Imagine:

Fintech → payment instruction → BaaS bank

The API fails.

The payment is not executed.

The customer loses money because a contractual deadline is missed.

Who is responsible?

The answer depends on:

• applicable payment-services law;
• contractual arrangements;
• the nature of the service;
• whether the failure was attributable to the bank, fintech or ICT provider;
• consumer-protection rules.

BaaS contracts therefore need detailed provisions covering:

service levels + incident response + customer compensation + regulatory reporting + data + audit + termination.

20. Safeguarding customer funds

Where the BaaS structure involves a payment institution or EMI rather than a bank, customer funds may be subject to safeguarding.

This generally means customer money must be protected through the legally prescribed mechanism rather than freely used to finance the institution's own activities.

The legal distinction is important:

Bank deposit

Potentially covered by deposit-guarantee legislation where eligible.

Payment/e-money funds

Subject to safeguarding rules and not automatically equivalent to insured bank deposits.

A fintech must communicate this distinction accurately.

21. Data protection

BaaS necessarily involves extensive data sharing.

Possible participants include:

customer → fintech → bank → KYC provider → fraud provider → cloud provider.

GDPR therefore becomes central.

Questions include:

• Who is the controller?
• Is another party a processor?
• Is there joint controllership?
• What is the lawful basis?
• How long is data retained?
• Who can access transaction information?
• Where is data processed?
• How are security incidents handled?

The answer cannot simply be:

"The customer accepted the privacy policy."

The legal roles must actually reflect the processing arrangements.

22. Automated decision-making

Many BaaS arrangements use algorithms for:

• fraud scoring;
• credit decisions;
• account opening;
• transaction blocking;
• customer-risk classification.

Where automated decision-making significantly affects customers, GDPR requirements may become relevant, including the rules concerning automated decision-making and appropriate safeguards.

The bank and fintech need to know:

Who designed the model?
Who validates it?
Who monitors errors?
Who handles customer challenges?

23. BaaS and credit

A BaaS platform may also provide embedded lending.

For example:

e-commerce platform → "Pay later" product → regulated lender

This introduces additional regulation concerning:

• creditworthiness;
• consumer credit;
• affordability;
• disclosure;
• interest;
• responsible lending;
• arrears;
• collections.

The fintech's attractive user interface does not remove the lender's regulatory responsibilities.

24. Case law — Fédération bancaire française v ECB

European banking-supervision litigation has repeatedly established that prudential obligations are matters of public regulatory law and cannot simply be contracted away between private parties.

For BaaS, this supports a fundamental proposition:

A private outsourcing agreement cannot eliminate the supervisory responsibility of the regulated institution.

The bank remains subject to its competent authority even where significant operational functions are performed by third parties.

25. Landeskreditbank Baden-Württemberg v ECB — C-450/17 P

This is an important CJEU case concerning the Single Supervisory Mechanism (SSM).

The Court upheld the broad institutional architecture under which the ECB exercises supervisory responsibilities.

BaaS significance

A BaaS bank operating in Spain or another Banking Union jurisdiction remains subject to the applicable prudential supervisory architecture.

Using a fintech brand does not move the bank outside:

• capital requirements;
• liquidity requirements;
• governance requirements;
• supervisory review.

26. Berlusconi and Fininvest — C-219/17

The case concerned the ECB's role in assessing a qualifying holding in a bank and the interaction between national and EU authorities.

BaaS relevance

Ownership and control structures matter.

Suppose a fintech effectively controls the customer-facing banking operation while the licensed bank is merely the regulatory shell.

That arrangement may raise questions concerning:

• governance;
• qualifying holdings;
• effective control;
• suitability;
• outsourcing;
• supervisory access.

The case demonstrates the importance of understanding the institutional structure rather than merely the technology layer.

27. Trasta Komercbanka and Others v ECB — C-663/17 P and related cases

The litigation concerned the withdrawal of a bank's authorisation and judicial protection.

BaaS significance

A BaaS provider's authorisation is foundational.

If the regulated institution loses its licence, the fintech cannot simply continue representing itself as though the underlying banking infrastructure remains authorised.

This makes business-continuity and exit planning essential.

28. Safe Interenvios — C-235/14

This CJEU case concerned AML controls in the payment-services sector.

The Court considered measures addressing money-laundering and terrorist-financing risks in the payment environment.

BaaS significance

Payment technology does not displace AML regulation.

A BaaS platform providing payment infrastructure must integrate appropriate AML controls into the payment chain.

29. Adyen and payment-services jurisprudence

CJEU payment-services jurisprudence has repeatedly emphasised the importance of correctly identifying the regulated payment service and the legal obligations attached to it.

The important BaaS lesson is:

The regulatory classification follows the substance of the payment activity rather than simply the branding used by the fintech.

This is particularly important where one entity technically interfaces with the customer while another legally performs the regulated payment service.

30. Kadi and Al Barakaat — C-402/05 P and C-415/05 P

Although not a BaaS case, Kadi is a foundational EU sanctions authority.

The CJEU confirmed that EU measures implementing international sanctions remain subject to EU legal principles and judicial review.

BaaS relevance

A BaaS provider cannot treat sanctions screening as merely a commercial risk-control exercise.

It forms part of a binding legal framework.

31. Möllendorf — C-117/06

The case concerned EU restrictive measures and the prohibition on making funds or economic resources available to designated persons.

BaaS relevance

Automated payment infrastructure must be capable of preventing prohibited transactions where applicable.

This is particularly important where BaaS services permit near-instantaneous payments.

32. Banking secrecy and customer information

BaaS also creates confidentiality issues.

The fintech may know:

• transaction history;
• account balances;
• beneficiaries;
• salary information;
• merchant activity.

The bank may separately hold the same information.

The parties need appropriate legal bases and contractual arrangements governing:

access + confidentiality + data security + disclosure to authorities.

Banking secrecy, AML obligations and GDPR must be analysed together rather than separately.

33. Operational resilience

A traditional bank may have multiple channels:

branch + ATM + web + mobile + call centre.

A BaaS fintech may have:

one API + one mobile application + one cloud environment.

If that infrastructure fails, the entire service may become unavailable.

Consequently, a BaaS agreement should address:

• redundancy;
• backup;
• disaster recovery;
• recovery time objectives;
• recovery point objectives;
• incident notification;
• penetration testing;
• business continuity;
• exit plans.

DORA significantly strengthens these requirements for entities within its scope.

34. BaaS concentration risk

Imagine:

Bank X provides infrastructure to 100 fintechs.

A technical failure at Bank X could affect:

• 100 fintech brands;
• millions of customers;
• card payments;
• transfers;
• wallets;
• merchant settlements.

This creates concentration risk.

Regulators therefore have an interest not merely in the resilience of each fintech, but also in the resilience of the underlying BaaS infrastructure.

35. Contractual provisions in a Spanish BaaS agreement

A sophisticated BaaS contract should address at least:

Regulatory status

Exactly which party is licensed and for which activities.

Compliance

Who performs AML/KYC, sanctions and consumer compliance.

Customer ownership

Who contracts with the customer and in what capacity.

Funds

Who holds customer money and what legal protection applies.

Data

Controller/processor roles and permitted data use.

Outsourcing

Subcontracting and third-party approval.

Technology

API availability, security and resilience.

Audit

Bank and regulator access to relevant records.

Incidents

Immediate notification and regulatory cooperation.

Complaints

Customer complaint allocation and response times.

Business continuity

Alternative infrastructure and disaster recovery.

Termination

How customers and funds are migrated if the relationship ends.

Regulatory change

Mechanism for adapting to new EU/Spanish requirements.

36. Regulatory perimeter problem

A particularly important Spanish legal question is:

Has the fintech crossed the regulatory perimeter?

For example, a fintech says:

"We are only a technology platform."

But it:

• accepts customer funds;
• controls payment accounts;
• determines payment execution;
• markets itself as the provider;
• controls customer onboarding;
• determines financial terms.

The more functions it performs, the greater the risk that its activities may fall within a regulated perimeter.

The answer depends on the exact statutory definitions and facts.

37. Bank-led versus fintech-led BaaS

Bank-led model

Bank → provides regulated infrastructure → fintech distributes product.

This generally makes the regulatory allocation clearer.

Fintech-led model

Fintech controls customer experience and business → bank supplies licence/infrastructure.

This can produce greater regulatory complexity.

The bank must retain sufficient control and oversight to satisfy supervisory expectations.

A bank cannot safely become a passive "licence rental" arrangement.

38. The "rent-a-bank" concern

A particularly problematic structure would be:

Fintech designs the product + controls customers + controls risk + controls money

while

bank merely lends its licence.

Regulators may view such a structure critically because the licensed institution must maintain genuine governance and control over the regulated activities for which it is authorised.

The exact legal consequences depend on the activities and applicable legislation, but the principle is clear:

A banking licence is not a commodity that can simply be rented while the regulated entity relinquishes effective control.

39. Spain-specific supervisory perspective

For a Spanish BaaS structure, the key authorities may include:

Banco de España

Relevant to:

• credit institutions;
• payment institutions;
• electronic-money institutions;
• payment-system matters;
• certain AML/supervisory functions.

ECB

Relevant where the institution falls within the Single Supervisory Mechanism.

SEPBLAC

Central to Spain's AML institutional framework.

CNMV

Relevant where the BaaS product involves regulated investment services or securities activities.

AEPD

Relevant to data-protection compliance.

European authorities

Depending on the matter:

• EBA;
• ECB;
• European Commission;
• AMLA;
• SRB.

40. Practical example

Suppose SpanishPay operates an online marketplace.

It offers sellers:

"Open your business account instantly."

Behind the application:

SpanishPay → API → Bank X

Bank X:

• holds the funds;
• performs regulated payment/account services;
• performs required AML controls.

SpanishPay:

• markets the service;
• collects customer information;
• provides the interface;
• sends payment instructions.

CloudCo:

• provides cloud infrastructure.

The legal structure should allocate:

Bank X → regulated financial service + regulatory responsibility

SpanishPay → technology/distribution functions within agreed regulatory boundaries

CloudCo → ICT service

But this is not enough by itself.

Bank X must maintain:

• oversight;
• audit rights;
• risk management;
• compliance controls;
• incident management;
• regulatory access.

41. Major BaaS legal risks in Spain

42. Case-law takeaway

There is not yet a large body of Spanish Supreme Court or CJEU judgments specifically labelled "Banking-as-a-Service."

That is important to state clearly.

BaaS is a relatively modern commercial model. Its legal treatment is instead derived from established bodies of jurisprudence concerning:

banking supervision + payment services + AML + sanctions + outsourcing + data protection + consumer law.

The most useful authorities therefore establish broader principles rather than providing a single BaaS precedent.

43. Overall legal model

The Spanish BaaS structure can be summarised as:

BaaS business model

↓

Identify regulated activity

↓

Identify licensed entity

↓

Determine customer/funds relationship

↓

Apply CRR/CRD or PSD2/payment/e-money rules as applicable

↓

AML/KYC + sanctions

↓

GDPR

↓

DORA/ICT outsourcing

↓

Consumer protection

↓

Supervisory oversight

↓

Recovery/resolution arrangements

The key is that each layer has to work simultaneously.

44. Conclusion

Banking-as-a-Service in Spain is not a separate banking licence. It is a delivery and infrastructure model operating within existing EU and Spanish financial regulation.

The most important legal principle is:

The use of APIs, fintech branding or outsourced infrastructure does not remove the licensing, prudential, AML, consumer-protection or operational-resilience obligations attached to the underlying regulated activity.

A Spanish BaaS structure therefore needs to determine precisely:

1. Who is legally providing the financial service?
2. Which entity is licensed?
3. Who holds customer funds?
4. Who performs KYC and AML monitoring?
5. Who screens sanctions?
6. Who is responsible for payment execution?
7. Who controls the technology and outsourced providers?
8. What happens if the bank or fintech fails?
9. What protection does the customer actually have?
10. Can the regulated bank demonstrate effective oversight of the entire arrangement?

Cases such as Landeskreditbank v ECB*, Berlusconi and Fininvest, Trasta Komercbanka, Safe Interenvios, Kadi and *Möllendorf illustrate the underlying European principles concerning banking supervision, payment services, AML and sanctions.

For Spain, the strongest legal approach is therefore substance over branding: a fintech cannot avoid financial regulation merely by describing itself as a technology company, and a licensed bank cannot discharge its regulatory responsibilities merely by placing its banking infrastructure behind an API.